DE102022104090A1 - Vorrichtung zum Identifizieren eines Eigentümers, Server, Benutzerendgerät, Fahrzeug, Verfahren zum Identifizieren eines Eigentümers - Google Patents

Vorrichtung zum Identifizieren eines Eigentümers, Server, Benutzerendgerät, Fahrzeug, Verfahren zum Identifizieren eines Eigentümers Download PDF

Info

Publication number
DE102022104090A1
DE102022104090A1 DE102022104090.9A DE102022104090A DE102022104090A1 DE 102022104090 A1 DE102022104090 A1 DE 102022104090A1 DE 102022104090 A DE102022104090 A DE 102022104090A DE 102022104090 A1 DE102022104090 A1 DE 102022104090A1
Authority
DE
Germany
Prior art keywords
information
user terminal
owner
server
signed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102022104090.9A
Other languages
English (en)
Inventor
Sven Hofmann
Thorsten KNOTT
Christoph Ruester
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Priority to DE102022104090.9A priority Critical patent/DE102022104090A1/de
Priority to PCT/EP2022/083783 priority patent/WO2023160848A1/de
Publication of DE102022104090A1 publication Critical patent/DE102022104090A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Abstract

Ausführungsbeispiele der vorliegenden Erfindung schaffen eine Vorrichtung 30 zum Identifizieren eines Eigentümers. Die Vorrichtung 30 umfasst eine Schnittstelle 32 dazu ausgebildet, um mit einem Benutzerendgerät zu kommunizieren und eine Kontrolleinheit 34 dazu ausgebildet, um die Schnittstelle 32 zu kontrollieren. Ferner ist das Kontrollmodul 34 dazu ausgebildet eine Information über eine beabsichtigte Identifizierung von dem Benutzerendgerät zu empfangen und eine signierte Information basierend auf der Information über eine beabsichtigte Identifizierung zu generieren. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner ist das Kontrollmodul 34 dazu geeignet die signierte Information an das Benutzerendgerät zu senden.

Description

  • Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf eine Vorrichtung zum Identifizieren eines Eigentümers, einen Server, ein Benutzerendgerät, ein Fahrzeug, und Verfahren zum Identifizieren eines Eigentümers, insbesondere aber nicht ausschließlich auf ein Konzept zur Identifizierung eines Eigentümers, beispielsweise eines Eigentümers eines Fahrzeugs.
  • Damit ein Nutzer, beispielsweise ein Eigentümer, ein Eigentümer-Pairing mit einer Vorrichtung, beispielsweise einem Fahrzeug, durchführen kann, muss sichergestellt sein, dass dieser Nutzer der tatsächliche Eigentümer des Fahrzeugs ist. Hierzu können beispielsweise zwei physische Schlüssel verwendet werden. Diese beiden physischen Schlüssel können beispielsweise im Fahrzeug angeordnet werden, um ein Eigentum an dem Fahrzeug nachzuweisen. Dies beruht auf der Annahme, dass nur der Eigentümer eines Fahrzeugs Zugang zu den beiden physischen Schlüsseln hat. Ein anderer Nutzer, der möglicherweise vorübergehend im Besitz eines physischen Schlüssels ist, kann nicht in der Lage sein ein Eigentümer-Pairing mit dem Fahrzeug durchzuführen, weil ihm der zweite Schlüssel fehlt, z. B. bei einem Parkservice, einer Tankstelle, etc. Alternativ kann eine Verifizierung eines Eigentümers auch bei einem Händler eines Fahrzeugs, beispielsweise mit den Fahrzeugunterlagen erfolgen. Das Anordnen einer Mehrzahl an Schlüsseln in einem Fahrzeug zum Nachweis eines Eigentums oder das Aufsuchen eines Händlers kann eine Nutzererfahrung beeinträchtigen bzw. reduzieren.
  • Es besteht daher ein Bedarf daran, eine alternative Vorrichtung zum Identifizieren eines Eigentümers bereitzustellen. Diesem Bedarf tragen die Vorrichtungen sowie das Fahrzeug und die Verfahren nach den unabhängigen Ansprüchen Rechnung.
  • Ausführungsbeispiele betreffen eine Vorrichtung zum Identifizieren eines Eigentümers, umfassend eine Schnittstelle dazu ausgebildet, um mit einem Benutzerendgerät zu kommunizieren und ein Kontrollmodul dazu ausgebildet, um die Schnittstelle zu kontrollieren. Ferner ist das Kontrollmodul dazu ausgebildet eine Information über eine beabsichtigte Identifizierung von dem Benutzerendgerät zu empfangen und eine signierte Information basierend auf der Information über eine beabsichtigte Identifizierung zu generieren. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner ist das Kontrollmodul dazu geeignet die signierte Information an das Benutzerendgerät zu senden. Dadurch kann das Benutzerendgerät von der Vorrichtung eine signierte Information erhalten, die es dem Benutzerendgerät, beispielsweise einem Nutzer des Benutzerendgeräts, ermöglicht eine Eigentümerschaft nachzuweisen. Dadurch kann ein Nutzer lediglich ein Benutzerendgerät, z. B. sein Smartphone, und die Vorrichtung benötigen, um sich als Eigentümer zu identifizieren.
  • In einem Ausführungsbeispiel kann eine Kommunikation zwischen Vorrichtung und Benutzerendgerät mittels Nahfeldkommunikation (NFC) erfolgen. Dadurch kann beispielsweise ein Empfangen der signierten Information verbessert erfolgen. Insbesondere kann ein Missbrauch durch Dritte auf Grund der Nahfeldkommunikation minimiert werden.
  • In einem Ausführungsbeispiel kann die signierte Information eine Zeitinformation über eine Generierung der signierten Information umfassen. Dadurch kann sichergestellt werden, dass ein ehemaliger Eigentümer der Vorrichtung nicht mehr im Besitz einer gültigen signierten Information sein kann. Insbesondere können die signierten Informationen, welche ein ehemaliger Eigentümer der Vorrichtung erzeugt hat, ungültig sein, beispielsweise weil die Zeitinformation auf eine zu lange her liegende Generierung schließen lässt.
  • Ausführungsbeispiele betreffen auch einen Server zum Identifizieren eines Eigentümers, umfassend eine Schnittstelle dazu ausgebildet, um mit einem Benutzerendgerät zu kommunizieren und ein Kontrollmodul dazu ausgebildet, um die Schnittstelle zu kontrollieren. Ferner ist das Kontrollmodul dazu ausgebildet eine Information über eine beabsichtigte Identifizierung an das Benutzerendgerät zu senden und eine signierte Information basierend auf der gesendeten Information von dem Benutzerendgerät zu empfangen. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner ist das Kontrollmodul dazu ausgebildet, eine Gültigkeit der signierten Information zu verifizieren und wenn die signierte Information gültig ist, eine Information zur Identifikation des Eigentümers an das Benutzerendgerät zu senden. Dadurch kann ein Server als zentrale Instanz, beispielsweise ein Backend, eine Überwachung einer Identifikation übernehmen. Beispielsweise kann der Server eine Information über eine Identität der Vorrichtung besitzen, so dass der Server eine Gültigkeitsprüfung durchführen kann.
  • In einem Ausführungsbeispiel kann die Information über eine beabsichtigte Identifizierung eine Gültigkeitsdauer der beabsichtigen Identifizierung umfassen. Dadurch kann sichergestellt werden, dass ein ehemaliger Eigentümer der Vorrichtung nicht mehr im Besitz einer gültigen signierten Information sein kann. Insbesondere können die signierten Informationen, welche ein ehemaliger Eigentümer der Vorrichtung erzeugt hat, ungültig sein, beispielsweise weil die Gültigkeitsdauer der beabsichtigen Identifizierung überschritten ist.
  • In einem Ausführungsbeispiel kann das Kontrollmodul ferner dazu ausgebildet sein eine Anfrage über eine beabsichtigte Identifizierung von einem Benutzerendgerät zu empfangen. Dadurch kann ein Nutzer eines Benutzerendgeräts aktiv eine Identifikation als Eigentümer durch den Server starten.
  • In einem Ausführungsbeispiel kann das Kontrollmodul ferner dazu ausgebildet sein eine digitale Signatur basierend auf der signierten Information zu generieren. Die digitale Signatur kann eine eindeutige Identifikation des Eigentümers ermöglichen. Ferner kann das Kontrollmodul dazu ausgebildet sein die digitale Signatur an das Benutzerendgerät zu senden. Dadurch kann beispielsweise eine Information in Form der digitalen Signatur erzeugt werden, welche den Nutzer des Benutzerendgeräts als Eigentümer des Fahrzeugs ausweist, beispielsweise ein digitaler Fahrzeugbrief.
  • Ausführungsbeispiele betreffen auch ein Benutzerendgerät zum Identifizieren eines Eigentümers umfassend eine Schnittstelle dazu ausgebildet, um mit einem Server und einem Hardware-Token zu kommunizieren und eine Kontrolleinheit dazu ausgebildet, um die Schnittstelle zu kontrollieren. Ferner ist das Kontrollmodul dazu ausgebildet eine Anfrage über eine beabsichtigte Identifizierung an den Server zu senden und eine Information über eine beabsichtigte Identifizierung von dem Server zu empfangen. Ferner ist das Kontrollmodul dazu ausgebildet, die Information über die beabsichtigte Identifizierung an den Hardware-Token zu senden und eine signierte Information basierend auf der Information über die beabsichtigte Identifizierung von dem Hardware-Token zu empfangen. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner ist das Kontrollmodul dazu ausgebildet die signierte Information an den Server zu senden und eine Information zur Identifikation des Eigentümers von dem Server zu empfangen. Damit kann ein Nutzer des Benutzerendgeräts, sofern er im physischen Besitz der Vorrichtung ist, allein mit seinem Benutzerendgerät ein Eigentümer-Pairing durchführen.
  • In einem Ausführungsbeispiel kann das Kontrollmodul ferner dazu ausgebildet sein eine Überprüfung der signierten Information basierend auf der beabsichtigen Identifizierung durchzuführen. Dadurch kann eine Kontrolle erfolgen, ob eine Vorrichtung zu einer Anfrage einer Identifikation passt.
  • In einem Ausführungsbeispiel kann das Kontrollmodul ferner dazu ausgebildet sein eine digitale Signatur von dem Server zu empfangen. Die digitale Signatur kann eine eindeutige Identifikation des Eigentümers ermöglichen. Dadurch kann ein Nutzer des Benutzerendgeräts insbesondere eine Eigentümerschaft nachweisen, beispielsweise kann die digitale Signatur ein digitaler Fahrzeugbrief sein.
  • In einem Ausführungsbeispiel kann das Kontrollmodul ferner dazu ausgebildet sein ein Pairing, insbesondere ein Eigentümer-Pairing, mit einem Fahrzeug basierend auf der Information zur Identifikation des Eigentümers durchzuführen. Dadurch kann ein Nutzer des Benutzerendgeräts vereinfacht ein (Eigentümer-)Pairing mit seinem Fahrzeug durchführen.
  • Ausführungsbeispiele schaffen darüber hinaus ein Fahrzeug mit einer Vorrichtung wie hierin beschrieben.
  • Ausführungsbeispiele betreffen auch ein Verfahren (für eine Vorrichtung) zum Identifizieren eines Eigentümers, umfassend Empfangen einer Information über eine beabsichtigte Identifizierung von einem Benutzerendgerät und Generieren einer signierten Information basierend auf der Information über eine beabsichtigte Identifizierung. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner umfasst das Verfahren Senden der signierten Information an das Benutzerendgerät.
  • Ausführungsbeispiele betreffen auch ein Verfahren für einen Server umfassend Senden einer Information über eine beabsichtigte Identifizierung an ein Benutzerendgerät und Empfangen einer signierten Information basierend auf der gesendeten Information von dem Benutzerendgerät. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner umfasst das Verfahren Verifizieren einer Gültigkeit der signierten Information und Senden einer Information zur Identifikation des Eigentümers an das Benutzerendgerät, wenn die signierte Information gültig ist.
  • Ausführungsbeispiele betreffen auch ein Verfahren für ein Benutzerendgerät umfassend Senden einer Anfrage über eine beabsichtigte Identifizierung an einen Server und Empfangen einer Information über eine beabsichtigte Identifizierung von dem Server. Ferner umfasst das Verfahren Senden der Information über die beabsichtigte Identifizierung an einen Hardware-Token und Empfangen einer signierten Information basierend auf der Information über eine beabsichtigte Identifizierung von dem Hardware-Token. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner umfasst das Verfahren Senden der signierten Information an den Server und Empfangen einer Information zur Identifikation des Eigentümers von dem Server.
  • Ausführungsbeispiele schaffen auch ein Computerprogramm zur Durchführung eines der hierin beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
  • Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert:
    • 1 zeigt ein Blockdiagramm eines Ausführungsbeispiels einer Vorrichtung;
    • 2 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Servers;
    • 3 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Benutzerendgeräts;
    • 4 zeigt ein Flussdiagramm eines Beispiels eines Verfahrens;
    • 5 zeigt eine schematische Darstellung eines Beispiels eines Verfahrens;
    • 6 zeigt eine schematische Darstellung eines weiteren Beispiels eines Verfahrens; und
    • 7 zeigt eine schematische Darstellung eines weiteren Beispiels eines Verfahrens.
  • Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
  • 1 zeigt ein Blockdiagramm eines Ausführungsbeispiels einer Vorrichtung 30. Die Vorrichtung 30 zum Identifizieren eines Eigentümers umfasst eine Schnittstelle 32 dazu ausgebildet, um mit einem Benutzerendgerät zu kommunizieren und eine Kontrolleinheit 34 dazu ausgebildet, um die Schnittstelle 32 zu kontrollieren. Ferner ist das Kontrollmodul 34 dazu ausgebildet eine Information über eine beabsichtigte Identifizierung von dem Benutzerendgerät zu empfangen und eine signierte Information basierend auf der Information über eine beabsichtigte Identifizierung zu generieren. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner ist das Kontrollmodul 34 dazu geeignet die signierte Information an das Benutzerendgerät zu senden. Dadurch kann die Vorrichtung 30 dazu verwendet werden, um eine Eigentümerschaft nachzuweisen.
  • Beispielsweise kann die Vorrichtung 30 benötigte Informationen zur Identifikation einer Eigentümerschaft umfassen. Beispielsweise können auf einem Speichermedium der Vorrichtung 30 Informationen gespeichert sein, die eine eindeutige Identifikation ermöglichen. Beispielsweise kann die Vorrichtung 30 einem Fahrzeug zugeordnet sein. Die Vorrichtung 30 kann dann Information umfassen, die es einem Besitzer der Vorrichtung 30 ermöglichen eine Eigentümerschaft über eine zugeordnete Vorrichtung, beispielsweise ein Fahrzeug, nachzuweisen. Insbesondere kann die Vorrichtung 30 als Eigentumsnachweis für das Fahrzeug fungieren. Dadurch kann ein Nutzer eines Benutzerendgeräts allein mit der Vorrichtung 30, beispielsweise einem Hardware-Token, eine Eigentümerschaft über ein Fahrzeug nachweisen.
  • Insbesondere kann ein Besitzer der Vorrichtung 30 ohne sich physisch bei einer der Vorrichtung 30 zugeordneten Vorrichtung, z. B. einem Fahrzeug, befinden zu müssen, eine Eigentümerschaft über das Fahrzeug nachweisen. Dadurch kann eine Nutzererfahrung verbessert werden. Ferner kann allein die Vorrichtung 30 zur eindeutigen Identifikation verwendet werden, wodurch Kosten, beispielsweise für eine Mehrzahl an Fahrzeugschlüsseln, reduziert werden können.
  • Einem Fahrzeugkäufer kann beispielsweise die Vorrichtung 30, z. B. ein Hardware-Token 30 ausgeliefert werden, welchen der Fahrzeugkäufer nutzen kann, um sich digital als Fahrzeugbesitzer zu identifizieren. Der Hardware-Token 30 kann insbesondere kostengünstiger sein als eine Mehrzahl an Fahrzeugschlüsseln. Ferner kann der Hardware-Token 30 eindeutig einem Fahrzeug zugeordnet sein. Ferner kann der Hardware-Token 30 mit einem Smart Device (z. B. via NFC) kommunizieren. Dadurch kann insbesondere ein Informationsaustausch zwischen dem Benutzerendgerät und dem Hardware-Token 30 vereinfacht werden. Ferner kann der Hardware-Token 30 kryptografische Signaturen erstellen. Dadurch kann insbesondere eine Sicherheit einer signierten Information verbessert werden. Beispielsweise kann die signierte Information mittels Kryptographie, beispielsweise mittels asymmetrischer Kryptographie verschlüsselt sein. Beispielsweise kann ein Fahrzeugkäufer mit seinem Benutzerendgerät den Hardware-Token 30 scannen. Dadurch kann insbesondere eine Identifikation gegenüber einer weiteren Instanz, beispielsweise einem Server erfolgen, wodurch sich der Fahrzeugkäufer als Eigentümer ausweisen kann. Insbesondere kann auch eine Verifizierung von Fahrzeugunterlagen durch einen Händler, welche kostspielig und nicht kundenfreundlich sein kann, entfallen.
  • Die Information über eine beabsichtigte Identifizierung kann beispielsweise von dem Benutzerendgerät eines Nutzers empfangen werden, der sich als Eigentümer einer zu der Vorrichtung 30 gehörenden Vorrichtung, beispielsweise einem Fahrzeug, identifizieren möchte. Der Nutzer kann beispielsweise mittels seines Benutzerendgeräts eine Anfrage, z. B. in Form einer Challenge, an die Vorrichtung 30 schicken. Die Anfrage kann die beabsichtigte Identifizierung umfassen, z. B. nach einem Fahrzeugkauf und einem in Besitz nehmen der Vorrichtung 30.
  • Die signierte Information kann insbesondere eine Information umfassen, die eine eindeutige Zuordnung der zu der Vorrichtung 30 gehörenden Vorrichtung umfasst. Beispielsweise kann die Vorrichtung 30 einem Fahrzeug zugeordnet sein. Die Vorrichtung 30 kann dann beispielsweise eine signierte Information generieren, beispielsweise mittels Kryptographie, welche eindeutig dem Fahrzeug zugeordnet ist. Dadurch kann eine weitere Instanz, beispielsweise ein Server eine Identifikation durchführen.
  • In einem Ausführungsbeispiel kann eine Kommunikation zwischen Vorrichtung 30 und Benutzerendgerät mittels Nahfeldkommunikation erfolgen. Dadurch kann beispielsweise ein Auslesen der Vorrichtung 30 durch einen Dritten erschwert werden, weil dieser sehr nah an die Vorrichtung 30 heranmuss. Insbesondere kann auf Grund der Nahfeldkommunikation nur ein Nutzer, der in direktem physischem Besitz der Vorrichtungen 30 ist, mit dieser mittels einem Benutzerendgerät kommunizieren.
  • In einem Ausführungsbeispiel kann die Vorrichtung 30 von einem Fahrzeug umfasst sein, bzw. in ein Fahrzeug integriert sein. Beispielsweise kann jeder Nutzer, der Zugang zu dem Fahrzeug hat auch Zugang zu der Vorrichtung 30 haben. Dadurch kann beispielsweise ein Nutzer des Fahrzeugs sich mittels der Vorrichtung 30 bei einem Server authentifizieren. Beispielsweise kann der Server annehmen, dass ein Nutzer, der Zugang zu dem Hardware-Token hat, auch berechtigt ist das Fahrzeug zu besitzen, beispielsweise ohne Eigentümer zu sein. Beispielsweise kann ein Mietfahrzeug mit einem Flotten-Backend-Server verbunden sein. Ein Nutzer innerhalb des Mietfahrzeugs kann dann mittels seines Benutzerendgeräts mit der Vorrichtung 30 kommunizieren, wodurch im beispielsweise ein Starten eines Motors erlaubt werden kann. Insbesondere kann der Flotten-Backend-Server Information über eine bevorstehende Benutzung erhalten. Insbesondere kann ein Kommunizieren mit der Vorrichtung 30 mittels des Benutzerendgeräts also nur dann zu einer Authentifizierung als Benutzer führen, wenn der Flotten-Backend-Server vorher eine Information hierüber erhalten hat.
  • In einem Ausführungsbeispiel kann die signierte Information eine Zeitinformation über eine Generierung der signierten Information umfassen. Dadurch kann insbesondere eine Gültigkeitsdauer der signierten Informationen generiert werden. Beispielsweise kann nach einem Fahrzeugverkauf ein ehemaliger Besitzer der Vorrichtung nicht mehr eine zuvor generierte signierte Information verwenden. Dadurch kann insbesondere eine Aktualität der Information über eine Identifikation eines Eigentümers verbessert werden.
  • Wie in 1 dargestellt, sind die eine oder mehreren Schnittstellen 32 mit dem jeweiligen Kontrollmodul 34 der Vorrichtung 30 gekoppelt. In Beispielen kann die Vorrichtung 34 durch eine oder mehrere Verarbeitungseinheiten, ein oder mehrere Verarbeitungsgeräte, ein beliebiges Mittel zur Verarbeitung, wie z.B. einen Prozessor, einen Computer oder eine programmierbare Hardwarekomponente, die mit entsprechend angepasster Software betrieben werden kann, implementiert werden. Ebenso können die beschriebenen Funktionen des Kontrollmoduls 34 auch in eine Software implementiert werden, die dann auf einer oder mehreren programmierbaren Hardwarekomponenten ausgeführt wird. Solche Hardwarekomponenten können ein Mehrzweckprozessor, ein digitaler Signalprozessor (DSP), ein Mikrocontroller usw. sein. Das Kontrollmodul 34 kann in der Lage sein, die eine oder mehrere Schnittstellen 32 zu steuern, so dass jede Datenübertragung, die über die eine oder mehrere Schnittstellen 32 erfolgt, und/oder jede Interaktion, an der die eine oder mehrere Schnittstellen 32 beteiligt sein können, von dem Kontrollmodul 34 gesteuert werden kann.
  • In einer Ausführungsform kann die Vorrichtung 30 einen Speicher und mindestens ein Kontrollmodul 34 umfassen, das funktionsfähig mit dem Speicher gekoppelt und so konfiguriert ist, dass sie das unten beschriebene Verfahren durchführt.
  • In Beispielen können die eine oder mehrere Schnittstellen 32 jedem Mittel zum Erhalten, Empfangen, Übertragen oder Bereitstellen von analogen oder digitalen Signalen oder Informationen entsprechen, z. B. jedem Anschluss, Kontakt, Stift, Register, Eingangsanschluss, Ausgangsanschluss, Leiter, Spur usw., der die Bereitstellung oder den Erhalt eines Signals oder einer Information ermöglicht. Die eine oder mehreren Schnittstellen 32 können drahtlos oder drahtgebunden sein und können so konfiguriert sein, dass sie mit weiteren internen oder externen Komponenten kommunizieren können, z. B. Signale oder Informationen senden oder empfangen können.
  • Bei der Vorrichtung 30 kann es insbesondere um einen Hardware-Token, einen Prozessor, eine anwendungsspezifische integrierte Schaltung (ASIC), eine integrierte Schaltung (IC) oder ein System-on-a-Chip-System (SoC), etc. handeln.
  • Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten beschriebenen Ausführungsbeispielen erwähnt. Das in 1 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren unten beschriebenen Ausführungsbeispielen (z. B. 2 - 7) erwähnt wurden.
  • 2 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Servers 50. Der Server 50 zum Identifizieren eines Eigentümers umfasst eine Schnittstelle 52 dazu ausgebildet, um mit einem Benutzerendgerät zu kommunizieren und ein Kontrollmodul 54 dazu ausgebildet, um die Schnittstelle zu kontrollieren. Ferner ist das Kontrollmodul 54 dazu ausgebildet eine Information über eine beabsichtigte Identifizierung an das Benutzerendgerät zu senden und eine signierte Information basierend auf der gesendeten Information von dem Benutzerendgerät zu empfangen. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner ist das Kontrollmodul 54 dazu ausgebildet, eine Gültigkeit der signierten Information zu verifizieren und wenn die signierte Information gültig ist, eine Information zur Identifikation des Eigentümers an das Benutzerendgerät zu senden. Der Server 50 kann also insbesondere dazu ausgebildet sein eine Identifikation des Eigentümers zu verifizieren. Der Server 50 kann beispielsweise Informationen über die Vorrichtung aus 1 umfassen, sodass der Server 50 die signierte Information verifizieren kann. Die signierte Information kann beispielsweise durch eine Vorrichtung wie oben beschrieben, insbesondere im Zusammenhang mit 1, generiert worden sein. Beispielsweise kann die Information über die beabsichtigte Identifizierung dieselbe Information sein wie mit Bezug zu 1 beschrieben. Der Server 50 kann insbesondere mit dem Benutzerendgerät des Eigentümers, der eine Identifikation ausführen möchte und der Vorrichtung aus 1 zusammenwirken, um eine Identifikation des Eigentümers zu ermöglichen. Der Server 50 kann beispielsweise eine Kontrollinstanz sein, die eine Gültigkeit der signierten Information überprüfen kann, beispielsweise basierend auf einer Information über eine Zuordnung der Vorrichtung aus 1 und einer zugeordneten Vorrichtung. Diese Information kann beispielsweise auf einem Speichermedium des Server 50 gespeichert sein und/oder von dem Server von einem kommunikativ gekoppelten Speichermedium, z. B. eine Cloud, abgerufen werden.
  • Die Information zur Identifikation des Eigentümers kann es dem Nutzer des Benutzerendgeräts ermöglichen ein Eigentümer-Pairing mit der zugeordneten Vorrichtung, beispielsweise einem Fahrzeug, durchzuführen.
  • In einem Ausführungsbeispiel kann die Information über eine beabsichtigte Identifizierung eine Gültigkeitsdauer der beabsichtigen Identifizierung umfassen. Beispielsweise kann der Server 50 eine Gültigkeit der beabsichtigen Identifizierung beschränken, sodass auch eine Gültigkeit einer generierten signierten Information beschränkt sein kann. Dadurch kann insbesondere ein Missbrauch einer veralteten generierten signierten Information verhindert werden.
  • In einem Ausführungsbeispiel kann das Kontrollmodul 54 ferner dazu ausgebildet sein eine Anfrage über eine beabsichtigte Identifizierung von einem Benutzerendgerät zu empfangen. Beispielsweise kann ein Nutzer des Benutzerendgeräts, beispielsweise ein Fahrzeugkäufer, eine Identifikation bei dem Server 50 Anfragen und dann erst die Information über eine beabsichtigte Identifikation erhalten, beispielsweise eine Challenge. Die Information über die beabsichtigte Identifikation kann insbesondere benötigt werden, damit die Vorrichtung aus 1 eine signierte Information generieren kann. Dadurch kann insbesondere der gesamte Prozess der Identifikation des Eigentümers durch den Server 50 gesteuert werden. Insbesondere kann nicht jedes Benutzerendgerät an die Vorrichtung aus 1 eine Information über eine beabsichtigte Identifikation senden, sondern erst dann, wenn diese von dem Server 50 erhalten wurde. Dadurch kann eine Kontrolle durch den Server 50 erfolgen. Beispielsweise kann ein Fahrzeugverkäufer den Server 50 über einen Fahrzeugverkauf informieren, sodass dieser bei einer Anfrage eines Benutzerendgeräts eine Information über eine beabsichtigte Information erstellen kann.
  • In einem Ausführungsbeispiel kann das Kontrollmodul ferner dazu ausgebildet sein eine digitale Signatur basierend auf der signierten Information zu generieren. Die digitale Signatur kann insbesondere eine eindeutige Identifikation des Eigentümers ermöglichen. Beispielsweise kann die digitale Signatur ein digitales Dokument sein, welches den Besitzer dieser Signatur als Eigentümer der zugehörenden Vorrichtung, beispielsweise des Fahrzeugs, ausweist. Beispielsweise kann die digitale Signatur ein digitaler Fahrzeugbrief sein.
  • Wie in 2 dargestellt, sind die eine oder mehreren Schnittstellen 52 mit dem jeweiligen Kontrollmodul 54 des Severs 50 gekoppelt. In Beispielen kann die Vorrichtung 54 durch eine oder mehrere Verarbeitungseinheiten, ein oder mehrere Verarbeitungsgeräte, ein beliebiges Mittel zur Verarbeitung, wie z.B. einen Prozessor, einen Computer oder eine programmierbare Hardwarekomponente, die mit entsprechend angepasster Software betrieben werden kann, implementiert werden. Ebenso können die beschriebenen Funktionen des Kontrollmoduls 54 auch in Software implementiert werden, die dann auf einer oder mehreren programmierbaren Hardwarekomponenten ausgeführt wird. Solche Hardwarekomponenten können ein Mehrzweckprozessor, ein digitaler Signalprozessor (DSP), ein Mikrocontroller usw. sein. Das Kontrollmodul 54 kann in der Lage sein, die eine oder mehrere Schnittstellen 52 zu steuern, so dass jede Datenübertragung, die über die eine oder mehrere Schnittstellen 52 erfolgt, und/oder jede Interaktion, an der die eine oder mehrere Schnittstellen 52 beteiligt sein können, von dem Kontrollmodul 54 gesteuert werden kann.
  • In einer Ausführungsform kann der Server 50 einen Speicher und mindestens ein Kontrollmodul 54 umfassen, das funktionsfähig mit dem Speicher gekoppelt und so konfiguriert ist, dass sie das unten beschriebene Verfahren durchführt.
  • In Beispielen können die eine oder mehrere Schnittstellen 52 jedem Mittel zum Erhalten, Empfangen, Übertragen oder Bereitstellen von analogen oder digitalen Signalen oder Informationen entsprechen, z. B. jedem Anschluss, Kontakt, Stift, Register, Eingangsanschluss, Ausgangsanschluss, Leiter, Spur usw., der die Bereitstellung oder den Erhalt eines Signals oder einer Information ermöglicht. Die eine oder mehreren Schnittstellen 52 können drahtlos oder drahtgebunden sein und können so konfiguriert sein, dass sie mit weiteren internen oder externen Komponenten kommunizieren können, z. B. Signale oder Informationen senden oder empfangen können.
  • Der Server 50 kann beispielsweise einen Computer, einen Prozessor, eine Steuereinheit, ein (feld)programmierbares Logik-Array ((F)PLA), ein (feld)programmierbares Gate-Array ((F)PGA), eine Grafikprozessoreinheit (GPU), eine anwendungsspezifische integrierte Schaltung (ASIC), eine integrierte Schaltung (IC) oder ein System-on-a-Chip-System (SoC) umfassen.
  • Der Server 50 kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Der Server 50 kann ein Gerät im Sinne der jeweiligen Kommunikationsstandards sein, die für die mobile Kommunikation verwendet werden.
  • Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in 2 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1) und/oder unten beschriebenen Ausführungsbeispielen (z. B. 3 - 7) erwähnt wurden.
  • 3 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Benutzerendgeräts 70. Das Benutzerendgerät 70 zum Identifizieren eines Eigentümers umfasst eine Schnittstelle 72 dazu ausgebildet, um mit einem Server (beispielsweise der Server wie oben beschrieben, z. B. mit Referenz zu 2) und einem Hardware-Token (beispielsweise die Vorrichtung wie oben beschrieben, z. B. mit Referenz zu 1) zu kommunizieren und eine Kontrolleinheit 74 dazu ausgebildet, um die Schnittstelle 72 zu kontrollieren. Ferner ist das Kontrollmodul 74 dazu ausgebildet eine Anfrage über eine beabsichtigte Identifizierung an den Server zu senden und eine Information über eine beabsichtigte Identifizierung von dem Server zu empfangen. Ferner ist das Kontrollmodul 74 dazu ausgebildet, die Information über die beabsichtigte Identifizierung an den Hardware-Token zu senden und eine signierte Information basierend auf der Information über die beabsichtigte Identifizierung von dem Hardware-Token zu empfangen. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner ist das Kontrollmodul 74 dazu ausgebildet die signierte Information an den Server zu senden und eine Information zur Identifikation des Eigentümers von dem Server zu empfangen. Das Benutzerendgerät 70 kann einem Nutzer also insbesondere eine Identifikation als Eigentümer ermöglichen. Hierzu benötigt der Nutzer lediglich den Hardware-Token, eine kommunikative Verbindung zu dem Hardware-Token, beispielsweise über Nahfeldkommunikation und eine kommunikative Verbindung zu einem Server, beispielsweise über eine mobile Datenverbindung. Dadurch kann eine Identifikation als Eigentümer für einen Nutzer verbessert werden. Ferner können Kosten für eine Mehrzahl an Fahrzeugschlüsseln reduziert werden.
  • In einem Ausführungsbeispiel kann das Kontrollmodul 74 ferner dazu ausgebildet sein eine Überprüfung der signierten Information basierend auf der beabsichtigen Identifizierung durchzuführen. Dadurch kann das Benutzerendgerät 70 beispielsweise überprüfen, ob ein korrekter Hardware-Token für eine beabsichtigte Identifikation verwendet wurde. Beispielsweise kann ein Nutzer des Benutzerendgeräts 70 eine Mehrzahl an Hardware-Token für eine Mehrzahl an Fahrzeugen besitzen. Die empfangene signierte Information kann dann beispielsweise auf eine Konsistenz mit der Information über eine beabsichtigte Identifikation verglichen werden. Dadurch kann dem Nutzer beispielsweise eine Rückmeldung gegeben werden, wenn er einen falschen Hardware-Token verwendet hat.
  • In einem Ausführungsbeispiel kann das Kontrollmodul 74 ferner dazu ausgebildet sein eine digitale Signatur von dem Server zu empfangen. Die digitale Signatur kann eine eindeutige Identifikation des Eigentümers ermöglichen. Dadurch kann ein Nutzer des Benutzerendgeräts insbesondere eine Eigentümerschaft nachweisen, beispielsweise kann die digitale Signatur ein digitaler Fahrzeugbrief sein.
  • In einem Ausführungsbeispiel kann das Kontrollmodul 74 ferner dazu ausgebildet sein ein Pairing, insbesondere ein Eigentümer-Pairing, mit einem Fahrzeug basierend auf der Information zur Identifikation des Eigentümers durchzuführen. Insbesondere kann das Eigentümer-Pairing ein Master-Benutzerendgerät 70 dazu ausbilden, über einen Zugriff auf das Fahrzeug zu verfügen, so dass das Master-Benutzerendgerät 70 beispielsweise das Fahrzeug Starten, Öffnen, Verschließen, etc. kann. Nach dem Eigentümer-Pairing kann das Master-Benutzerendgerät 70 beispielsweise dazu ausgebildet sein Freundesschlüssel zur Anmeldung ans Fahrzeug für weitere Benutzerendgeräte zu vergeben.
  • Wie in 3 dargestellt, sind die eine oder mehreren Schnittstellen 72 mit dem jeweiligen Kontrollmodul 74 des Benutzerendgeräts 70 gekoppelt. In Beispielen kann die Vorrichtung 74 durch eine oder mehrere Verarbeitungseinheiten, ein oder mehrere Verarbeitungsgeräte, ein beliebiges Mittel zur Verarbeitung, wie z.B. einen Prozessor, einen Computer oder eine programmierbare Hardwarekomponente, die mit entsprechend angepasster Software betrieben werden kann, implementiert werden. Ebenso können die beschriebenen Funktionen des Kontrollmoduls 74 auch in eine Software implementiert werden, die dann auf einer oder mehreren programmierbaren Hardwarekomponenten ausgeführt wird. Solche Hardwarekomponenten können ein Mehrzweckprozessor, ein digitaler Signalprozessor (DSP), ein Mikrocontroller usw. sein. Das Kontrollmodul 74 kann in der Lage sein, die eine oder mehrere Schnittstellen 72 zu steuern, so dass jede Datenübertragung, die über die eine oder mehrere Schnittstellen 72 erfolgt, und/oder jede Interaktion, an der die eine oder mehrere Schnittstellen 72 beteiligt sein können, von dem Kontrollmodul 74 gesteuert werden kann.
  • In einer Ausführungsform kann das Benutzerendgerät 70 einen Speicher und mindestens ein Kontrollmodul 74 umfassen, das funktionsfähig mit dem Speicher gekoppelt und so konfiguriert ist, dass sie das unten beschriebene Verfahren durchführt.
  • In Beispielen können die eine oder mehrere Schnittstellen 72 jedem Mittel zum Erhalten, Empfangen, Übertragen oder Bereitstellen von analogen oder digitalen Signalen oder Informationen entsprechen, z. B. jedem Anschluss, Kontakt, Stift, Register, Eingangsanschluss, Ausgangsanschluss, Leiter, Spur usw., der die Bereitstellung oder den Erhalt eines Signals oder einer Information ermöglicht. Die eine oder mehreren Schnittstellen 72 können drahtlos oder drahtgebunden sein und können so konfiguriert sein, dass sie mit weiteren internen oder externen Komponenten kommunizieren können, z. B. Signale oder Informationen senden oder empfangen können.
  • Das Benutzerendgerät 70 kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Insbesondere kann das Benutzerendgerät 70 ein mobiles Benutzerendgerät sein, z.B. ein Benutzerendgerät, das geeignet ist, von einem Nutzer mitgeführt zu werden. Das Benutzerendgerät kann z.B. ein User Terminal (UT) oder User Equipment (UE) im Sinne der jeweiligen Kommunikationsstandards sein, die für die mobile Kommunikation verwendet werden. Bei dem UE kann es sich beispielsweise um ein Mobiltelefon, wie ein Smartphone, oder eine andere Art von mobilem Kommunikationsgerät, wie eine Smartwatch, einen Laptop, einen Tablet-Computer, eine autonome Augmented-Reality-Brille, etc. handeln.
  • In zumindest manchen Ausführungsbeispielen kann das Benutzerendgerät 70 von einem Fahrzeug umfasst sein. Das Fahrzeug kann beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Bus, einem Motorrad, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen.
  • Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in 3 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1 - 2) und/oder unten beschriebenen Ausführungsbeispielen (z. B. 4 - 7) erwähnt wurden.
  • 4 zeigt ein Flussdiagramm eines Beispiels eines Verfahrens 400. Ein Nutzer kann mittels seines Benutzerendgeräts 70 eine Identifikation als Eigentümer starten 400. Insbesondere kann der Nutzer, beispielsweise ein Fahrzeugeigentümer, einen Vorgang zur Einrichtung eines digitalen Schlüssels für ein Fahrzeug starten. Beispielsweise kann der Nutzer hierzu eine Applikation auf dem Benutzerendgerät 70 starten, insbesondere eine Applikation, die zu einem Hersteller eines Fahrzeugs zugeordnet ist. Das Benutzerendgerät 70, beispielsweise die Applikation, kann dann eine Anfrage zu einer Information über eine beabsichtigte Identifikation an den Server 50 senden 405. Der Server 50 kann beispielsweise ein Backend für eine Mehrzahl an Fahrzeugen sein.
  • Der Server 50 kann eine Information über eine beabsichtigte Identifikation generieren 410. Optional kann der Server 50 die generierte Information über eine beabsichtigte Information mit einer Gültigkeitsdauer versehen. Insbesondere kann der Server Information umfassen (beispielsweise auf einem Speichermedium gespeichert), welcher Hardware-Token zu welcher zugehörenden Vorrichtung gehört. Der Server 50 kann dann die Information über eine beabsichtigte Identifikation an das Benutzerendgerät 70 senden 415. Optional kann der Server 50 auch eine Information über eine der Information über die beabsichtigte Information zugehörenden Hardware-Token, eine Tokeninformation, 30 senden.
  • Der Nutzer kann den Hardware-Token 30 an eine Nahfeldkommunikations-Schnittstelle seines Benutzerendgeräts 70 halten. Das Benutzerendgerät 70 kann dann eine Verbindung zu dem Hardware-Token 30 aufbauen und die Information über die beabsichtigte Identifikation an den Hardware-Token 30 senden 435, beispielsweise mittels der Applikation. Der Hardware-Token 30 kann dann eine signierte Information generieren 440 und diese an das Benutzerendgerät 70 senden 445, beispielsweise mittels Nahfeldkommunikation. Die signierte Information kann insbesondere mittels asymmetrischer Kryptografie erstellt werden.
  • Optional, wenn das Benutzerendgerät 70 eine Tokeninformation erhalten hat, kann eine Überprüfung eines verwendeten Hardware-Tokens 30 stattfinden. Beispielsweise kann das Benutzerendgerät 70 zuerst eine Anfrage über eine Tokeninformation an den Hardware-Token 30 senden 420. Der Hardware-Token 30 kann dann eine Antwort auf die Anfrage an das Benutzerendgerät 70 senden 425. Das Benutzerendgerät 70 kann dann die Tokeninformation überprüfen 430 und erst wenn eine Überstimmung festgestellt wird, der Nutzer also einen Hardware-Token, der zu der Information der beabsichtigen Identifikation passt, verwendet hat, kann das Senden 435 der Information der beabsichtigten Information erfolgen.
  • Das Benutzerendgerät 70 kann die signierte Information an den Server 50 senden 450. Der Server 50 kann die signierte Information verifizieren 460. Optional kann der Server 50 eine Gültigkeitsdauer resetten 455, beispielsweise einen Timer für eine Gültigkeitsdauer stoppen. Wenn die signierte Information verifiziert ist, kann der Server 50 eine Information zur Identifikation des Eigentümers an das Benutzerendgerät senden 465. Basierend auf der Information zur Identifikation des Eigentümers kann das Benutzerendgerät 70 dann ein Eigentümer-Pairing mit dem zu dem Hardware-Token 30 zugehörenden Fahrzeug starten 470.
  • Alternativ kann der Hardware-Token 30 nicht durch eine Applikation des Benutzerendgeräts 70, sondern beispielsweise durch einen Standard im Betriebssystem verifiziert werden. Insbesondere kann auch eine Kommunikation zwischen Benutzerendgerät 70 und Hardware-Token 30 unabhängig von einer Applikation des Benutzerendgeräts 70 erfolgen. Beispielsweise kann das Benutzerendgerät 70 mit dem Hardware-Token im Sinne eines Digital Key des Car Connectivity Consortium (CCC) Standards kommunizieren. Insbesondere kann der Hardware-Token ein Digital Key im Sinne des CCC-Standards sein. Beispielsweise kann der Standard CCC-TS-101 Digital Key Technical Specification Release 3, Version 1.0.0 zur Kommunikation zwischen Benutzerendgerät und Hardware-Token verwendet werden.
  • Beispielsweise ist in Kapitel 6.3.2 auf S. 80 der Einstieg ins Owner-Pairing (Mastergerät-Pairing) beschrieben. („To start owner pairing mode (Step 3 of Figure 6-2), the device receives the password, either through user input, a URL (see Section 6.3.7), or through an API directly from the Vehicle OEM app, if installed.“). Insbesondere kann also Kapitel 6.3.2 angepasst werden, um einen Hardware-Token zu implementieren, welcher dazu dienen kann eine Eigentümerschaft nachzuweisen. Insbesondere kann ein Protokoll, welches zur Kommunikation zwischen Benutzerendgerät und Hardware-Token verwendet werden kann als eigene Transaktion definiert werden. Beispielsweise kann vergleichbar zu den Kapiteln „7 Standard Transaction / 8 fast Transaction / 10 Check Presence Transaction“ solch eine Kommunikation aufgenommen werden. Einzelnen Kommandos für solch eine Transaktion können in Kapitel „15.3.2 Commands“ eingebunden werden.
  • Alternativ kann das Benutzerendgerät 70 in dem zu dem Hardware-Token 30 zugehörenden Fahrzeug fest angeordnet sein. Beispielsweise kann ein Fahrzeug einen Nahfeldkommunikation-Leser umfassen, der als Benutzerendgerät 70 dient. Ein Hardware-Token 30 kann dann besonders einfach durch das zugehörende Fahrzeug ausgelesen werden.
  • Optional oder alternativ kann der Hardware-Token 30 nicht direkt Freigabe eines Eigentümer-Pairings fungieren. Der Hardware-Token 30 kann beispielsweise dazu verwendet werden, eine Information in einer Applikation des Benutzerendgeräts 70 zu generieren, beispielsweise die digitale Signatur, beispielsweise einen Fahrzeugbrief. Die digitale Signatur kann dann in einem weiteren optionalen Schritt dazu verwendet die Information für eine Identifikation, also insbesondere für die Durchführung eines Eigentümer-Pairings, zu generieren.
  • Nachfolgend ist eine konkrete Ausgestaltung des Verfahren 400 dargestellt. Das Verfahren 400 kann insbesondere mittels einer Applikation auf dem Benutzerendgerät 70 durchgeführt werden. Die Applikation kann insbesondere eine Eigentümer-Pairing ermöglichen (Tag: [App-NFCT-123]). Der Server 50 kann insbesondere alle digitalen Schlüssel, die mit einem Backend einer Mehrzahl an Fahrzeugen verknüpft sind, darstellen (Tag: [BE-NFCT-123]). Der Hardware-Token 30 kann, insbesondere wie in [HWT-NFCT-100] spezifiziert sein (Tag: [HWT-NFCT-123]).
  • Auf folgende Dokumente wird im Folgenden Bezug genommen: [CCC-R3] Digital Key Technical Specification Release 3 v1.0.0 und [FIPS-186] FIPS PUB 186-4 - Digital Signature Standard - July 2013.
  • Spezifikation für [HWT-NFCT-100]:
  • Der Hardware-Token 30 kann die folgenden Eigenschaften aufweisen:
    • • TokenKeypair
      • ◯ ECC key pair, generiert nach [FIPS-186] mit ‚ECC NIST P-256‘
      • ◯ Token.SK (32 Bytes) & Token.PK (64 Bytes)
    • • Tokeninformation/TokenIdentifier (20 Byte) = SHA-1 hash des Wertes des BIT STRING subjectPublicKey (=Token.PK)
    • • Für jeden Hardware-Token 30 speichert der Server, insbesondere ein Backend eine 1 zu 1 Assosiation mit dem zugehörenden Fahrzeug. (Binding process spec in progress)
    • • Der Hardware-Token 30 unterstützt die folgenden NFC-Kommandos, die weiter unten im Detail ausgeführt werden:
      • ◯ SELECT Befehl / Antwort
      • ◯ SIGN Befehl / Antwort
  • [HWT-NFCT-101]: Wenn der Hardware-Token 30 für das zugehörende Fahrzeug nicht verfügbar ist, soll die Applikation ein Verfahren 400 abbrechen. Wenn der Hardware-Token 30 verfügbar ist, kann die Applikation den Nutzer darüber informieren, dass der Nutzer den Hardware-Token 30 mit dem Benutzerendgerät verbinden muss, um ein Eigentümer-Pairing zu starten. Das Verfahren 400 kann dann mit [APP-NFCT-102] fortgesetzt werden. Es wird hierbei davon ausgegangen, dass die Applikation eine Information über eine Unterstützung eines Hardware-Tokens durch ein Fahrzeug umfasst.
  • [APP-NFCT-102]: Die Applikation fragt die Information über die beabsichtigte Identifikation an von dem Server 50 an. Hierzu kann beispielsweise der Befehl:
    • requestTokenChallenge(vehicleIdentifier)
    • info: interface needs to be specified in detail.
  • [BE-NFCT-103]: Der Server 50 kann eine Überprüfung durchführen, ob das ausgewählte Fahrzeug einem Hardware-Token 30 zugeordnet ist bzw. unterstützt. Insbesondere kann der Server 50 eine Information erhalten, von welchem Benutzerendgerät 70 die Anfrage stammt und/oder für welches Fahrzeug die Anfrage ist. Wenn das angefragte Fahrzeug keinem Hardware-Token 30 zugeordnet ist, kann der Server 50 eine Fehlermeldung „HardwareTokenNotSupported“ an das Benutzerendgerät senden. Sonst kann der Server 50 eine Tokeninformation (auch als TokenIdentifier bezeichnet), welche dem Fahrzeug zugeordnet ist, bestimmen. Ferner kann der Server 50 eine zufällige Information über eine beabsichtigte Identifikation generieren, beispielsweise mit einer Länge von 32 Byte. Optional kann der Server 50 eine Gültigkeitsdauer definieren und/oder einen Timer starten, beispielsweise einen TokenChallengeTimer = 10 s, der mit der Information über eine beabsichtigte Identifikation (auch als TokenChallenge bezeichnet) assoziiert ist.
  • [BE-NFCT-104]: Der Server 50 antwortet auf requestTokenChallenge mit dem Payload:
    • • TokenChallenge von [BE-NFCT-103]
    • • TokenIdentifier von [BE-NFCT-103]
  • [APP-NFCT-105]: Die Applikation kann die folgenden APDU über ein NFC-Interface an den Hardware-Token 30 senden: Tabelle: SELECT Befehl - APDU Struktur:
    CLA INS P1 P2 Lc Data Le
    00h A4h 04h 00h var. tbd [HWT-AID] 00h
  • [HWT-NFCT-106]: Der Hardware-Token kann mit der folgen APDU antworten: Tabelle: SELECT Antwort - APDU Struktur:
    Data SW
    [table: SELECT response - payload TLV] 90 00h
    Tabelle: SELECT Antwort - payload TLV:
    Tag Länge Wert Beschreibung
    41h 01h (1d) 01h version
    5Dh 14h(20d) var. [HWT.TokenIdentifier]
  • [NFCT-107]: Die Applikation kann den BETokenIdentifier empfangen in [BE-NFCT-104] mit dem HWT.TokenIdentifier [HWT-NFCT-106]. Wenn der BETokenIdentifier != HWT.TokenIdentifier dann soll die Applikation den Nutzer darüber informieren, dass nicht der richtige zu dem zugehörenden Fahrzeug gehörende Hardware-Token präsentiert/verbunden wurde. Das Verfahren 400 kann dann beendet werden. Ansonsten, wenn der richtige Hardware-Token präsentiert/verbunden wurde kann [APP-NFCT-108] ausgeführt werden.
  • [APP-NFCT-108]: Die Applikation kann die folgenden APDU über ein NFC-Interface des Benutzerendgeräts 70 and den Hardware-Token 30 senden (insbesondere in Übereinstimmung mit [CCC-R3] - Kapitel 15.3.2.23): Tabelle: SIGN Befehl - APDU Struktur:
    CLA INS P1 P2 Lc Data Le
    80h 30h 01h (UA nicht benötigt) 00h var. [Tabelle: Sign Befehl - payload TLV] 00h
    Tabelle: SIGN Befehl - payload TLV:
    Tag Länge Wert Beschreibung
    50h 14h (20d) [TokenIdentifier] BE.TokenIdentifier empfangen in [BE-NFCT-104]
    58h 20h (32d) [TokenChallenge] BE.TokenChallenge empfangen in [BE-NFCT-104]
  • [HWT-NFCT-109]: Der Hardware-Token 30 kann die signierte Information, auch als TokenSignature bezeichnet, wie folgt generieren:
    • Algorithmus: ECDSA mit SHA-256 mit ‚ECC NIST P-256‘ nach [FIPS-186] Information die signiert werden muss (Data to be signed): [Tabelle: SIGN Data fields], Geheimer Schlüssel (Secret Key): Token.SK wie definiert in [HWT-NFCT-100] Output: TokenSignature -Länge: 64Byte
    Tabelle: SIGN Data fields
    Tag Länge Wert Beschreibung
    41h 01h (1d) 01h version
    92h 08h (8d) var. [zufällig] - generiert durch den Hardware-Token
    5Dh 14h (20d) var. [HWT.TokenIdentifier] .
    58h 20h (32d) var. [TokenChallenge]
    93h 04h (4d) FC6F4C17h usage - UA nicht durchgeführt
  • [HWT-NFCT-110]: Der Hardware-Token 30 kann mit folgender APDU antworten: Tabelle: SIGN Antwort- APDU Struktur:
    Data SW
    [table: SIGN response - payload TLV] 90 00h
    Tabelle: SIGN Antwort - payload TLV:
    Tag Länge Wert Beschreibung
    41h 01h (1d) 01h version
    92h 08h (8d) var. [random] - generiert in [HWT-NFCT-109]
    5Dh 14h (20d) var. [HWT.TokenIdentifier]
    9Eh 40h (64d) var. [TokenSignature] generiert in [HWT-NFCT-109]
  • [APP-NFCT-111]: Die Applikation kann dann eine Eigentümer-Pairing Passwort bei dem Server 50 anfragen, insbesondere durch Senden der TokenSignature wie folgt:
    • getPairingPassword (vehicleIdentifier, TokenSignature)
    • Information: Interface muss erweitert werden für die TokenSignature.
  • [BE-NFCT-112]: Wenn ein getPairingPassword für ein Fahrzeug vom dem Benutzerendgerät 70 vom Server 50 empfangen wird, welches eine TokenSignature benötigt, kann der Server 50 verifizieren, ob der TokenChallengeTimer ([BE-NFCT-103]) abgelaufen ist. Wenn der TokenChallengeTimer abgelaufen ist, kann eine Fehlermeldung an das Benutzerendgerät 70 von dem Server 50 gesendet werden, beispielsweise, „TokenChallengeTimer expired“. Das Verfahren 400 kann dann beendet werden. Falls der TokenChallengeTimer nicht abgelaufen ist, kann das Verfahren 400 mit [BE-NFCT-113] fortgesetzt werden.
  • [BE-NFCT-1 13]: Der Server kann eine Gültigkeit der TokenSignature wie folgt verifizieren:
    • Hash: SHA-256 mittels [Tabelle: SIGN Data fields] Public Key: Token.PK wie definiert in [HWT-NFCT-100]. Ein Algorithmus kann sein: verifizieren ECDSA mit ‚ECC NIST P-256‘ wie in [FIPS-186]; IF signature == invalid: gib eine Fehlermeldung, z. B. „TokenSignature invalid“ aus und beende das Verfahren 400. Ansonsten kann das Verfahren 400 mit [BE-NFCT-114] fortgesetzt werden.
  • [BE-NFCT-114]: Der Server 50 kann die Information für die Identifikation (beispielsweise ein Eigentümer-Pairing Passwort) an das Benutzerendgerät senden. Insbesondere in Antwort auf die Anfrage nach dem Eigentümer-Pairing Passwort.
  • [BE-NFCT-115]: Die Applikation kann ein Eigentümer-Pairing starten, insbesondere basierend auf einem Aufruf einer Betriebssoftware des Benutzerendgeräts. Hierzu kann die Applikation insbesondere das Eigentümer-Pairing Passwort verwenden.
  • Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in 4 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1 - 3) und/oder unten beschriebenen Ausführungsbeispielen (z. B. 5 - 7) erwähnt wurden.
  • 5 zeigt eine schematische Darstellung eines Beispiels eines Verfahrens 500. Das Verfahren 500 zum Identifizieren eines Eigentümers umfasst Empfangen 510 einer Information über eine beabsichtigte Identifizierung von einem Benutzerendgerät und Generieren 520 einer signierten Information basierend auf der Information über eine beabsichtigte Identifizierung. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner umfasst das Verfahren 500 Senden 530 der signierten Information an das Benutzerendgerät. Das Verfahren kann beispielsweise von einer Vorrichtung wie oben beschrieben, insbesondere mit Referenz zu 1, ausgeführt werden.
  • Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in 5 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1 - 4) und/oder unten beschriebenen Ausführungsbeispielen (z. B. 6 - 7) erwähnt wurden.
  • 6 zeigt eine schematische Darstellung eines Beispiels eines weiteren Verfahrens 600. Das Verfahren 600 für einen Server umfasst Senden 610 einer Information über eine beabsichtigte Identifizierung an ein Benutzerendgerät und Empfangen 620 einer signierten Information basierend auf der gesendeten Information von dem Benutzerendgerät. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner umfasst das Verfahren Verifizieren 630 einer Gültigkeit der signierten Information und Senden 640 einer Information zur Identifikation des Eigentümers an das Benutzerendgerät, wenn die signierte Information gültig ist. Das Verfahren 600 kann insbesondere von einem Server wie oben beschrieben, beispielsweise mit Bezug zu 2, ausgeführt werden.
  • Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in 6 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1 - 5) und/oder unten beschriebenen Ausführungsbeispielen (z. B. 7) erwähnt wurden.
  • 7 zeigt eine schematische Darstellung eines Beispiels eines weiteren Verfahren 700. Das Verfahren 700 für ein Benutzerendgerät umfasst Senden 710 einer Anfrage über eine beabsichtigte Identifizierung an einen Server und Empfangen 720 einer Information über eine beabsichtigte Identifizierung von dem Server. Ferner umfasst das Verfahren 700 Senden 730 der Information über die beabsichtigte Identifizierung an einen Hardware-Token und Empfangen 740 einer signierten Information basierend auf der Information über eine beabsichtigte Identifizierung von dem Hardware-Token. Die signierte Information kann zur Identifikation des Eigentümers verwendet werden. Ferner umfasst das Verfahren 700 Senden 750 der signierten Information an den Server und Empfangen einer Information zur Identifikation des Eigentümers von dem Server. Das Verfahren 700 kann insbesondere von einem Benutzerendgerät wie oben beschrieben, beispielsweise mit Referenz zu 3, ausgeführt werden.
  • Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den oben beschriebenen Ausführungsbeispielen erwähnt. Das in 7 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1 - 6) beschriebenen Ausführungsbeispielen erwähnt wurden.
  • Bezugszeichenliste
    • 30
    Vorrichtung
    32
    Schnittstelle
    34
    Kontrollmodul
    50
    Server
    52
    Schnittstelle
    54
    Kontrollmodul
    70
    Benutzerendgerät
    72
    Schnittstelle
    74
    Kontrollmodul
    500
    Verfahren zum Identifizieren eines Eigentümers
    510
    Empfangen einer Information
    520
    Generieren einer signierten Information
    530
    Senden der signierten Information
    600
    Verfahren für einen Server
    610
    Senden einer Information
    620
    Empfangen einer signierten Information
    630
    Verifizieren einer Gültigkeit
    640
    Senden einer Information
    700
    Verfahren für ein Benutzerendgerät
    710
    Senden einer Anfrage
    720
    Empfangen einer Information
    730
    Senden der Information
    740
    Empfangen einer signierten Information
    750
    Senden der signierten Information
    760
    Empfangen einer Information

Claims (15)

  1. Eine Vorrichtung (30) zum Identifizieren eines Eigentümers, umfassend: eine Schnittstelle (32) dazu ausgebildet, um mit einem Benutzerendgerät zu kommunizieren; und ein Kontrollmodul (34) dazu ausgebildet, um die Schnittstelle (32) zu kontrollieren und ferner dazu ausgebildet: eine Information über eine beabsichtigte Identifizierung von dem Benutzerendgerät zu empfangen; eine signierte Information basierend auf der Information über eine beabsichtigte Identifizierung zu generieren, wobei die signierte Information zur Identifikation des Eigentümers verwendet werden kann; und die signierte Information an das Benutzerendgerät zu senden.
  2. Die Vorrichtung (30) nach Anspruch 1, wobei eine Kommunikation zwischen Vorrichtung und Benutzerendgerät mittels Nahfeldkommunikation erfolgt.
  3. Die Vorrichtung (30) nach einem der vorhergehenden Ansprüche, wobei die signierte Information eine Zeitinformation über eine Generierung der signierten Information umfasst.
  4. Ein Server (50) zum Identifizieren eines Eigentümers, umfassend: eine Schnittstelle (52) dazu ausgebildet, um mit einem Benutzerendgerät zu kommunizieren; und ein Kontrollmodul (54) dazu ausgebildet, um die Schnittstelle (52) zu kontrollieren und ferner dazu ausgebildet: eine Information über eine beabsichtigte Identifizierung an das Benutzerendgerät zu senden; eine signierte Information basierend auf der gesendeten Information von dem Benutzerendgerät zu empfangen, wobei die signierte Information zur Identifikation des Eigentümers verwendet werden kann; eine Gültigkeit der signierten Information zu verifizieren; und wenn die signierte Information gültig ist, eine Information zur Identifikation des Eigentümers an das Benutzerendgerät zu senden.
  5. Der Server (50) nach Anspruch 4, wobei die Information über eine beabsichtigte Identifizierung eine Gültigkeitsdauer der beabsichtigen Identifizierung umfasst.
  6. Der Server (50) nach einem der Ansprüche 4 oder 5, wobei das Kontrollmodul (54) ferner dazu ausgebildet ist eine Anfrage über eine beabsichtigte Identifizierung von einem Benutzerendgerät zu empfangen.
  7. Der Server (50) nach einem der Ansprüche 4-6, wobei das Kontrollmodul (54) ferner dazu ausgebildet ist: eine digitale Signatur basierend auf der signierten Information zu generieren, wobei die digitale Signatur eine eindeutige Identifikation des Eigentümers ermöglicht; und die digitale Signatur an das Benutzerendgerät zu senden.
  8. Benutzerendgerät (70) zum Identifizieren eines Eigentümers, umfassend: eine Schnittstelle (72) dazu ausgebildet, um mit einem Server und einem Hardware-Token zu kommunizieren; und ein Kontrollmodul (74) dazu ausgebildet, um die Schnittstelle (72) zu kontrollieren und ferner dazu ausgebildet: eine Anfrage über eine beabsichtigte Identifizierung an den Server zu senden; eine Information über eine beabsichtigte Identifizierung von dem Server zu empfangen; die Information über die beabsichtigte Identifizierung an den Hardware-Token zu senden; eine signierte Information basierend auf der Information über die beabsichtigte Identifizierung von dem Hardware-Token zu empfangen, wobei die signierte Information zur Identifikation des Eigentümers verwendet werden kann; die signierte Information an den Server zu senden; und eine Information zur Identifikation des Eigentümers von dem Server zu empfangen.
  9. Das Benutzerendgerät (70) nach Anspruch 8, wobei das Kontrollmodul (74) ferner dazu ausgebildet ist eine Überprüfung der signierten Information basierend auf der beabsichtigen Identifizierung durchzuführen.
  10. Das Benutzerendgerät (70) nach einem der Ansprüche 8 oder 9, wobei das Kontrollmodul (74) ferner dazu ausgebildet ist eine digitale Signatur von dem Server zu empfangen, wobei die digitale Signatur eine eindeutige Identifikation des Eigentümers ermöglicht.
  11. Ein Fahrzeug mit einer Vorrichtung (70) nach einem der Ansprüche 8-10.
  12. Verfahren (500) zum Identifizieren eines Eigentümers, umfassend: Empfangen (510) einer Information über eine beabsichtigte Identifizierung von einem Benutzerendgerät; Generieren (520) einer signierten Information basierend auf der Information über eine beabsichtigte Identifizierung, wobei die signierte Information zur Identifikation des Eigentümers verwendet werden kann; und Senden (530) der signierten Information an das Benutzerendgerät.
  13. Verfahren (600) für einen Server zum Identifizieren eines Eigentümers, umfassend: Senden (610) einer Information über eine beabsichtigte Identifizierung an ein Benutzerendgerät; Empfangen (620) einer signierten Information basierend auf der gesendeten Information von dem Benutzerendgerät, wobei die signierte Information zur Identifikation des Eigentümers verwendet werden kann; Verifizieren (630) einer Gültigkeit der signierten Information; und Senden (640) einer Information zur Identifikation des Eigentümers an das Benutzerendgerät, wenn die signierte Information gültig ist.
  14. Verfahren (700) für ein Benutzerendgerät zum Identifizieren eines Eigentümers, umfassend: Senden (710) einer Anfrage über eine beabsichtigte Identifizierung an einen Server; Empfangen (720) einer Information über eine beabsichtigte Identifizierung von dem Server; Senden (730) der Information über die beabsichtigte Identifizierung an einen Hardware-Token; Empfangen (740) einer signierten Information basierend auf der Information über eine beabsichtigte Identifizierung von dem Hardware-Token, wobei die signierte Information zur Identifikation des Eigentümers verwendet werden kann; Senden (750) der signierten Information an den Server; und Empfangen (760) einer Information zur Identifikation des Eigentümers von dem Server.
  15. Ein Computerprogramm zur Durchführung eines der Verfahren (500; 600; 700) nach einem der Ansprüche 12-14, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
DE102022104090.9A 2022-02-22 2022-02-22 Vorrichtung zum Identifizieren eines Eigentümers, Server, Benutzerendgerät, Fahrzeug, Verfahren zum Identifizieren eines Eigentümers Pending DE102022104090A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102022104090.9A DE102022104090A1 (de) 2022-02-22 2022-02-22 Vorrichtung zum Identifizieren eines Eigentümers, Server, Benutzerendgerät, Fahrzeug, Verfahren zum Identifizieren eines Eigentümers
PCT/EP2022/083783 WO2023160848A1 (de) 2022-02-22 2022-11-30 Vorrichtung zum identifizieren eines eigentümers, server, benutzerendgerät, fahrzeug, verfahren zum identifizieren eines eigentümers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102022104090.9A DE102022104090A1 (de) 2022-02-22 2022-02-22 Vorrichtung zum Identifizieren eines Eigentümers, Server, Benutzerendgerät, Fahrzeug, Verfahren zum Identifizieren eines Eigentümers

Publications (1)

Publication Number Publication Date
DE102022104090A1 true DE102022104090A1 (de) 2023-08-24

Family

ID=84488055

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022104090.9A Pending DE102022104090A1 (de) 2022-02-22 2022-02-22 Vorrichtung zum Identifizieren eines Eigentümers, Server, Benutzerendgerät, Fahrzeug, Verfahren zum Identifizieren eines Eigentümers

Country Status (2)

Country Link
DE (1) DE102022104090A1 (de)
WO (1) WO2023160848A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160358186A1 (en) 2015-06-04 2016-12-08 Chronicled, Inc. Open registry for identity of things

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010030590A1 (de) * 2010-06-28 2011-12-29 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Zertifikats
DE102014105241A1 (de) * 2013-12-05 2015-06-11 Deutsche Post Ag Verriegelungseinheit, Gehäuse mit Verriegelungseinheit und Verfahren zum Entriegeln von ein oder mehreren Türen des Gehäuses
DE102014017618B4 (de) * 2014-11-28 2017-11-09 Audi Ag Verfahren zur Freigabe und/oder Auslösung einer Fahrzeugfunktion eines Kraftfahrzeugs und Kraftfahrzeug
JP7202688B2 (ja) * 2018-06-15 2023-01-12 Ｃａｐｙ株式会社 認証システム、認証方法、アプリケーション提供装置、認証装置、及び認証用プログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160358186A1 (en) 2015-06-04 2016-12-08 Chronicled, Inc. Open registry for identity of things

Also Published As

Publication number Publication date
WO2023160848A1 (de) 2023-08-31

Similar Documents

Publication Publication Date Title
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
EP3262859B1 (de) System zur verwendung mobiler endgeräte als schlüssel für fahrzeuge
EP2332313B1 (de) Verfahren zur speicherung von daten, computerprogrammprodukt, id-token und computersystem
DE102012219618B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
EP2443853A1 (de) Verfahren zum einbuchen eines mobilfunkgeräts in ein mobilfunknetz
DE102015202308A1 (de) Computerimplementiertes Verfahren zur Zugriffskontrolle
WO2013030060A1 (de) Verfahren zur erzeugung eines soft-tokens, computerprogrammprodukt und dienst-computersystem
DE102010028133A1 (de) Verfahren zum Lesen eines Attributs aus einem ID-Token
DE102008042262A1 (de) Verfahren zur Speicherung von Daten, Computerprogrammprodukt, ID-Token und Computersystem
DE102010005422A1 (de) System und Verfahren zum Aufbauen einer sicheren Verbindung mit einer mobilen Vorrichtung
DE102017208503A1 (de) Verfahren, Computerlesbares Medium, System und Fahrzeug umfassend das System zum Bereitstellen eines Datensatzes eines Fahrzeugs an einen Dritten
DE102009001959A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token über eine Mobilfunkverbindung
DE102008043123A1 (de) Kraftfahrzeug-Anzeigevorrichtung, Kraftfahrzeug-Elektroniksystem, Kraftfahrzeug, Verfahren zur Anzeige von Daten und Computerprogrammprodukt
DE102012221288A1 (de) Verfahren, Vorrichtung und Dienstleistungsmittel zur Authentifizierung eines Kunden für eine durch ein Dienstleistungsmittel zu erbringende Dienstleistung
DE102018005038A1 (de) Smartcard als Sicherheitstoken
EP3422628A1 (de) Verfahren, sicherheitseinrichtung und sicherheitssystem
DE60203041T2 (de) Verfahren und vorrichtung zum beglaubigen einer transaktion
DE102016222100A1 (de) Verfahren und System zum Nachweis eines Besitzes eines Fahrzeugs
EP2199944A2 (de) Verfahren zur Authentifizierung einer Person gegenüber einer elektronischen Datenverarbeitungsanlage mittels eines elektronischen Schlüssels
DE102008042582A1 (de) Telekommunikationsverfahren, Computerprogrammprodukt und Computersystem
DE102022104090A1 (de) Vorrichtung zum Identifizieren eines Eigentümers, Server, Benutzerendgerät, Fahrzeug, Verfahren zum Identifizieren eines Eigentümers
DE102015209073B4 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
DE102011119103A1 (de) Verfahren zum Authentisieren einer Person an einer Serverinstanz
WO2016146726A1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
EP2381712B1 (de) Sicheres Auslesen von Daten aus einem Funkgerät mit festintegriertem TPM

Legal Events

Date Code Title Description
R163 Identified publications notified