Beschreibung

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:

Fig. 1 zeigt ein Blockdiagramm eines Ausführungsbeispiels einer Vorrichtung;

Fig. 2 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Servers;

Fig. 3 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Benutzerendgeräts;

Fig. 4 zeigt ein Flussdiagramm eines Beispiels eines Verfahrens;

Fig. 5 zeigt eine schematische Darstellung eines Beispiels eines Verfahrens;

Fig. 6 zeigt eine schematische Darstellung eines weiteren Beispiels eines Verfahrens; und

Fig. 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.

Fig. 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 Ausfuhrungsbeispiel 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 Fig. 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 Fig. 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. Fig. 2 - 7) erwähnt wurden.

Fig. 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 Fig. 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 Fig. 1, generiert worden sein. Beispielsweise kann die Information über die beabsichtigte Identifizierung dieselbe Information sein wie mit Bezug zu Fig. 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 Fig. 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 Fig. 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 Fig. 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 Fig. 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 Fig. 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 Fig. 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. Fig. 1) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 3 - 7) erwähnt wurden.

Fig. 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 Fig. 2) und einem Hardware-Token (beispielsweise die Vorrichtung wie oben beschrieben, z. B. mit Referenz zu Fig. 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 Fig. 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 Fig. 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. Fig. 1 - 2) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 4 - 7) erwähnt wurden.

Fig. 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 stattfmden. 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 vl.0.0 und [FIPS-186] FIPS PUB 186-4 - Digital Signatare Standard - July 2013.

Spezifikation für [HWT-NFCT-100]:

Der Hardware -Token 30 kann die folgenden Eigenschaften aufweisen:

• TokenKeypair o ECC key pair, generiert nach [FIPS-186] mit 'ECC NIST P-256' o Token. SK (32 Bytes) & Token.PK (64 Bytes)

• Tokeninformation/Tokenldentifier (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 Izul 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: o SELECT Befehl / Antwort o 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(vehicleldentifier) 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:

[HWT-NFCT-106]: Der Hardware -Token kann mit der folgen APDU antworten:

Tabelle: SELECT Antwort - APDU Struktur:

Tabelle: SELECT Antwort - payload TLV:

[NFCT-107]: Die Applikation kann den BE.Tokenldentifier empfangen in [BE-NFCT-104] mit dem HWT.Tokenldentifier [HWT-NFCT-106], Wenn der BE.Tokenldentifier != HWT.Tokenldentifier 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:

Tabelle: SIGN Befehl - payload TLV:

[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

[HWT-NFCT-110]: Der Hardware -Token 30 kann mit folgender APDU antworten:

Tabelle: SIGN Antwort- APDU Struktur:

Tabelle: SIGN Antwort - payload TLV:

[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 (vehicleldentifier, 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-113]: 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 Fig. 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. Fig. 1 - 3) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 5 - 7) erwähnt wurden.

Fig. 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 Fig. 1, ausgeführt werden.

Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 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. Fig. 1 - 4) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 6 - 7) erwähnt wurden.

Fig. 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 Fig. 2, ausgeführt werden.

Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 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. Fig. 1 - 5) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 7) erwähnt wurden.

Fig. 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 Fig. 3, ausgeführt werden.

Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 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. Fig. 1 - 6) beschriebenen Ausführungsbeispielen erwähnt wurden.

Bezugszeichenliste

Vorrichtung

Schnittstelle

Kontrollmodul

Server

Schnittstelle

Kontrollmodul

Benutzerendgerät

Schnittstelle

Kontrollmodul

Verfahren zum Identifizieren eines Eigentümers

Empfangen einer Information

Generieren einer signierten Information

Senden der signierten Information

Verfahren für einen Server

Senden einer Information

Empfangen einer signierten Information

Verifizieren einer Gültigkeit

Senden einer Information

Verfahren für ein Benutzerendgerät

Senden einer Anfrage

Empfangen einer Information

Senden der Information

Empfangen einer signierten Information

Senden der signierten Information

Empfangen einer Information