-
GEBIET DER TECHNIK
-
Aspekte der vorliegenden Offenbarung betreffen im Allgemeinen Ansätze zur sicheren Registrierung für Fahrzeugdienste zur Verwendung mit Fahrzeug-zu-Allem-Kommunikation (vehicle-to-everything communication - V2X-Kommunikation).
-
ALLGEMEINER STAND DER TECHNIK
-
V2X ermöglicht es Fahrzeugen, mit anderen Fahrzeugen sowie mit Infrastruktur, Fußgängern, Netzwerken und anderen Vorrichtungen zu kommunizieren und Informationen auszutauschen. Fahrzeug-zu-Infrastruktur-Kommunikation (vehicle-to-infrastructure communication - V2I-Kommunikation) ermöglicht es Anwendungen, eine Kommunikation oder Transaktionen zwischen Fahrzeugen und Infrastruktur zu erleichtern und zu beschleunigen.
-
KURZDARSTELLUNG
-
In einem oder mehreren veranschaulichenden Beispielen wird ein Fahrzeug zur sicheren Dienstregistrierung bereitgestellt. Das Fahrzeug beinhaltet einen Sendeempfänger; und eine Steuerung, die dazu programmiert ist, den Sendeempfänger zu nutzen, um eine sichere Verbindung mit einem Verwaltungssystem einzurichten, eine Dienstanforderung zum Zugreifen auf einen V2X-Dienst an das Verwaltungssystem zu senden, wobei die Dienstanforderung einen öffentlichen Schlüssel des Fahrzeugs eines Paares aus öffentlichem/privatem Schlüssel des Fahrzeugs beinhaltet, von dem Verwaltungssystem ein Zertifikatsbündel, das unter Verwendung des öffentlichen Schlüssels des Fahrzeugs verschlüsselt ist, zu empfangen, wobei das Zertifikatsbündel ein Paar aus öffentlichem/privatem Schlüssel des Dienstes und ein Zertifikat zum Zugreifen auf den V2X-Dienst beinhaltet, das Zertifikatsbündel unter Verwendung eines privaten Schlüssels des Fahrzeugs, der dem öffentlichen Schlüssel des Fahrzeugs entspricht, zu entschlüsseln und das Paar aus öffentlichem/privatem Schlüssel des Dienstes und das Zertifikat zu nutzen, um auf den V2X-Dienst zuzugreifen.
-
In einem oder mehreren veranschaulichenden Beispielen wird ein System zur sicheren Dienstregistrierung bereitgestellt. Ein Verwaltungssystem ist dazu programmiert, von einem Fahrzeug eine Dienstanforderung zum Zugreifen auf einen V2X-Dienst zu empfangen, wobei die Dienstanforderung einen öffentlichen Schlüssel des Fahrzeugs eines Paares aus öffentlichem/privatem Schlüssel des Fahrzeugs beinhaltet; ein Zertifikatsbündel vorzubereiten, das ein Paar aus öffentlichem/privatem Schlüssel des Dienstes und ein Zertifikat zum Zugreifen auf den V2X-Dienst beinhaltet; das Zertifikatsbündel unter Verwendung des öffentlichen Schlüssels des Fahrzeugs zu verschlüsseln; und das Zertifikatsbündel, wie verschlüsselt, als Reaktion auf die Dienstanforderung an das Fahrzeug zu übertragen.
-
In einem oder mehreren veranschaulichenden Beispielen wird ein Verfahren zur sicheren Dienstregistrierung bereitgestellt. Eine sichere Verbindung wird zwischen einem Fahrzeug und einem Verwaltungssystem eingerichtet. Eine Dienstanforderung wird an das Verwaltungssystem gesendet, um auf einen V2X-Dienst zuzugreifen, wobei die Dienstanforderung einen öffentlichen Schlüssel des Fahrzeugs eines Paares aus öffentlichem/privatem Schlüssel des Fahrzeugs beinhaltet. Es wird von dem Verwaltungssystem ein Zertifikatsbündel empfangen, das unter Verwendung des öffentlichen Schlüssels des Fahrzeugs verschlüsselt ist, wobei das Zertifikatsbündel ein Paar aus öffentlichem/privatem Schlüssel des Dienstes und ein Zertifikat zum Zugreifen auf den V2X-Dienst beinhaltet. Das Zertifikatsbündel wird unter Verwendung eines privaten Schlüssels des Fahrzeugs, der dem öffentlichen Schlüssel des Fahrzeugs entspricht, entschlüsselt. Das Paar aus öffentlichem/privatem Schlüssel des Dienstes und das Zertifikat werden verwendet, um auf den V2X-Dienst zuzugreifen.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
- 1 veranschaulicht ein beispielhaftes System zur sicheren Registrierung für V2X-Fahrzeugdienste;
- 2 veranschaulicht ein Beispiel für den Kommunikationsfluss (i) zur Schlüsseleinrichtung im Hinblick auf die Elemente des Systems aus 1;
- 3 veranschaulicht ein Beispiel für den Datenfluss des Kommunikationsflusses (i) zur Schlüsseleinrichtung für das Beispiel aus 2;
- 4 veranschaulicht weitere Details der Generierung der Schlüssel, die verwendet werden, um die in dieser Schrift erörterten Vorgänge durchzuführen;
- 5 veranschaulicht einen beispielhaften Datenfluss für den Kommunikationsfluss auf einem sicheren Kanal zwischen dem Fahrzeug und dem Dienst;
- 6 veranschaulicht ein Beispiel für das Fahrzeug, das einen Kommunikationsfluss auf einem sicheren Kanal zwischen den Fahrzeugen und einer straßenseitigen Einheit (roadside unit - RSU) eines Fahrbahnmautdienstes durchführt;
- 7 veranschaulicht ein Beispiel für das Fahrzeug, das einen Kommunikationsfluss auf einem sicheren Kanal zwischen den Fahrzeugen und einer RSU eines Händlerdienstes durchführt;
- 8 veranschaulicht ein Beispiel für das Fahrzeug, das einen Kommunikationsfluss auf einem sicheren Kanal zwischen den Fahrzeugen und einer RSU eines Parkdienstes durchführt;
- 9 veranschaulicht eine beispielhafte Rechenvorrichtung.
-
DETAILLIERTE BESCHREIBUNG
-
In dieser Schrift werden Ausführungsformen der vorliegenden Offenbarung beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale könnten vergrößert oder verkleinert dargestellt sein, um Details konkreter Komponenten zu zeigen. Deshalb sind in dieser Schrift offenbarte spezifische strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann zu lehren, die Ausführungsformen verschiedenartig einzusetzen. Für den Durchschnittsfachmann versteht es sich, dass verschiedene Merkmale, die unter Bezugnahme auf eine beliebige der Figuren veranschaulicht und beschrieben sind, mit Merkmalen kombiniert werden können, die in einer oder mehreren anderen Figuren veranschaulicht sind, um Ausführungsformen zu produzieren, die nicht ausdrücklich veranschaulicht oder beschrieben sind. Die veranschaulichten Kombinationen von Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Verschiedene Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung vereinbar sind, könnten jedoch für konkrete Anwendungen gewünscht sein.
-
Vernetzte Fahrzeuge können Fahrzeug-zu-Allem-Mobilfunk (cellular vehicle-to-everything - C-V2X) oder dedizierte Nahbereichskommunikation (dedicated short range communication - DSRC) verwenden, um mehrere Kundendienste zu unterstützen, wie etwa Mauterhebung und Autowäsche, Lebensmitteleinkauf, Parken usw. Zur Unterstützung von C-V2X- oder DSRC-Kundendiensten kann ein Fahrzeug Zertifikate für ein dienstorientiertes Sicherheitsanmeldeverwaltungssystem (security credential management system - SCMS) verwenden, die durch die Dienstanbieter generiert werden. Wenn ein Kunde von einem Dienst zu einem neuen anderen Dienst wechselt, kann der vorherige Dienstanbieter die Zertifikate, die für den Kunden generiert wurden, sperren, nachdem sich der Kunde abgemeldet hat. Eine Liste gesperrter Zertifikate kann den Dienststandorten bereitgestellt werden, sodass bestätigt wird, dass der Kunde nicht mehr in der Lage ist, auf diesen Dienstanbieter zuzugreifen.
-
Basierend darauf, wie die Zertifikate generiert werden, kann die Vorrichtung des Kunden gesperrt werden. Beispielsweise können öffentliche Schlüssel und private Schlüssel, die während der Generierung des Zertifikats für den Kunden verwendet werden, möglicherweise nicht mehr verwendet werden. Somit kann in der Situation, dass der Kunde den Dienstanbieter wechselt, die Vorrichtung des Kunden dauerhaft gesperrt sein und nicht in der Lage sein, unter Verwendung des gesperrten öffentlichen Schlüssels der Vorrichtung, der für die Zertifikatsgenerierung über ein Hardwaresicherheitsmodul (HSM) der Vorrichtung verwendet wird, an jeglicher C-V2X-Kommunikation teilzunehmen.
-
Wie in dieser Schrift ausführlich erörtert, wird eine verbesserte sichere Registrierung für V2X-Fahrzeugdienste bereitgestellt. Beispielsweise können ein Verfahren und ein System zum Generieren, Verteilen, Anwenden und Verwerfen von dienstbasierten Sicherheitszertifikaten und zugeordneten Paaren aus öffentlichen und privaten Schlüsseln eine bordeigene Einheit (onboard unit - OBU), wie etwa eine Telematiksteuereinheit (telematics control unit - TCU), die einen Dienst erfordert, und einen Cloud-Dienst beinhalten, der dazu ausgestattet ist, Paare aus öffentlichem/privatem Schlüssel und Zertifikate zu generieren.
-
Die übertragende OBU kann eine Dienstanforderung an die Dienstzentrale senden und eine sichere Kommunikationsverbindung mit der Dienstzentrale einrichten. Die OBU kann einen öffentlichen und einen privaten Schlüssel generieren, ohne das HSM des Fahrzeugs zu verwenden, und kann den öffentlichen Schlüssel zusammen mit einer Dienstanforderung anhängen. Als Reaktion auf das Empfangen einer Abonnementanforderung kann die Dienstzentrale Paare aus privatem/öffentlichem Schlüssel zusammen mit dem Zertifikatsbündel generieren, kann das Bündel mit dem empfangenen öffentlichen Schlüssel des Fahrzeugs verschlüsseln und kann die verschlüsselten Daten über den eingerichteten sicheren Kanal an die OBU übertragen.
-
Um Vorrichtungszertifikate zu generieren, kann der Dienstanbieter, anstatt den privaten und öffentlichen Schlüssel des Fahrzeug-HSM zu verwenden, einen privaten Schlüssel und einen öffentlichen Schlüssel und Dienstzertifikate generieren und diese an das Fahrzeug übermitteln. Die OBU kann das Zertifikatsbündel empfangen und das Bündel mit dem privaten Schlüssel des Fahrzeugs entschlüsseln, der während der Dienstregistrierung generiert wird. Die OBU kann die Schlüssel und die Zertifikate zur Verwendung speichern, wenn das Fahrzeug mit der Infrastruktur des Dienstes kommuniziert.
-
Die Dienstzentrale kann den öffentlichen Schlüssel an alle an dem Dienst beteiligten Infrastrukturzugriffspunkte kommunizieren, wenn die übertragende OBU Dienste ablehnt oder nicht mehr der Kunde für einen konkreten Dienst ist. Der Dienstanbieter kann eine Liste mit nicht abonnierten Zertifikaten erstellen und für jede Dienstzentrale aktualisieren. Die vorgeschlagene Lösung kann dementsprechend Merkmale vernetzter Fahrzeuge nutzen, um sicherere Registrierungskundendienste bereitzustellen, und vermeidet Probleme, dass das HSM des Fahrzeugs auf die schwarze Liste gesetzt wird.
-
Bei dieser vorgeschlagenen Lösung kann der Kunde mehrere vernetzte Dienste registrieren. Jede Dienstzentrale-RSU kann jede empfangene Nachricht anhand der Liste der nicht abonnierten Zertifikate verifizieren, sodass, wenn eine Nachricht mit diesen Zertifikaten empfangen wird, die RSU einen Bericht über Fehlverhalten (misbehavior report - MBR) generieren und Autoritäten aktualisieren kann. Der Kunde kann einen beliebigen anderen Dienst abonnieren, ohne die Fahrzeug-HSM-Schlüssel zu verwenden, da das Fahrzeug Dienstanbieterschlüssel und Zertifikatsbündel für die Dienstkommunikation verwendet.
-
Die Registrierung ermöglicht Kunden die Flexibilität, unterschiedliche Dienstanbieter zu wählen. Wenn ein Kunde ein Dienstmerkmal abmeldet, kann das Fahrzeug dennoch in der Lage sein, an anderen C-V2X-Kommunikationen für andere Dienste teilzunehmen. Dieser Ansatz vermeidet, dass das Fahrzeug von allen Diensten auf die schwarze Liste gesetzt wird, indem ein einzelner Dienst abgemeldet wird. Weitere Aspekte der sicheren Registrierung für V2X-Fahrzeugdienste werden in dieser Schrift ausführlich erörtert.
-
1 veranschaulicht ein beispielhaftes System 100 zur sicheren Registrierung von V2X-Fahrzeugdiensten. Wie gezeigt, beinhaltet das System 100 ein Fahrzeug 102, das mit einer TCU 106 ausgestattet ist, die V2X-Funktionalität umsetzt. Das System 100 beinhaltet ferner eine RSU 110, die ebenfalls V2X-Funktionalität umsetzt. Ein Backend-Verwaltungsdienst 114 ist ebenfalls beinhaltet, der dazu konfiguriert ist, Berechnungen und Aufzeichnungsvorgänge durchzuführen. Es ist zu beachten, dass das System 100 lediglich ein Beispiel ist und Systeme 100 verwendet werden können, die mehr, weniger und andere Anordnungen von Elementen aufweisen. Beispielsweise können eines oder mehrere von der RSU 110 und dem Backend-Verwaltungsdienst 114 in einer einzelnen Vorrichtung kombiniert sein. Darüber hinaus wird, obwohl nur ein Fahrzeug 102 und eine RSU 110 in Verbindung mit einem Dienst 112 gezeigt sind, in Betracht gezogen, dass Systeme 100 viele Fahrzeuge 102, RSUs 110 und Dienste 112 beinhalten würden.
-
Die Fahrzeuge 102 können verschiedene andere Arten von Personenkraftwagen beinhalten, wie etwa Limousinen, Softroader (crossover utility vehicles - CUVs), Vans, Geländewagen (sport utility vehicles - SUVs), Trucks, Wohnmobile (recreational vehicles - RVs), Roller, Drohnen oder andere mobile Maschinen zum Transportieren von Personen oder Gütern. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine angetrieben werden. In derartigen Fällen kann die Kraftstoffquelle Benzin oder Dieselkraftstoff sein. Als eine andere Möglichkeit kann das Fahrzeug 102 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch eine Brennkraftmaschine als auch durch einen oder mehrere Elektromotoren mit Leistung versorgt wird, wie etwa ein Serienhybridelektrofahrzeug (series hybrid electric vehicle - SHEV), ein Parallelhybridelektrofahrzeug (parallel hybrid electric vehicle - PHEV) oder ein Parallel-/Serienhybridelektrofahrzeug (parallel/series hybrid electric vehicle - PSHEV). Als noch eine weitere Möglichkeit kann das Fahrzeug 102 ein Elektrofahrzeug (electric vehicle - EV) ohne Brennkraftmaschine sein, das durch Elektromotoren mit Leistung versorgt wird. Da die Art und die Konfiguration von Fahrzeugen 102 variieren können, können entsprechend die Fähigkeiten der Fahrzeuge 102 variieren. Als einige andere Möglichkeiten können Fahrzeuge 102 unterschiedliche Fähigkeiten in Bezug auf die Fahrgastkapazität, die Schleppfähigkeit und -kapazität und den Stauraum aufweisen. Zu Registrierungs-, Inventar- und anderen Zwecken kann dem Fahrzeug 102 eine eindeutige Kennung zugeordnet sein, wie etwa eine Fahrzeugidentifizierungsnummer (FIN).
-
Das Fahrzeug 102 beinhaltet im Allgemeinen mehrere Sensoren 104, die verwendet werden, um verschiedene Aspekte des Fahrzeugs 102 zu betreiben. Diese Sensoren 104 können mit Steuerungen an Bord des Fahrzeugs 102 verbunden sein, welche die Sensoreingaben verfolgen und verschiedene nützliche Datenelemente daraus berechnen. Diese Sensordaten können als einige nicht einschränkende Beispiele Folgendes beinhalten: den absoluten Standort und die Koordinaten (z. B. den Standort, wie gemäß einem globalen nationalen Satellitensystem (GNSS) bestimmt), den Standort relativ zu der Karte und spezifischen Straßen, den Standort relativ zu einem bestimmten Fahrstreifen, die Fahrzeuggröße, das Fahrzeuggewicht, die Anzahl der Achsen und die Anzahl der Fahrgäste. Es ist anzumerken, dass das Fahrzeug 102 zusätzlich oder alternativ Koppelnavigation verwenden kann, z. B. über Controller-Area-Network (CAN) oder andere fahrzeugseitige Nachrichten), um den Standort des Fahrzeugs für die Straßennutzung zu schätzen, wenn GNSS nicht verfügbar ist (wie etwa in Innenstadtbereichen, Straßenschluchten oder Parkstrukturen, die GNSS-Signale blockieren können). Wenn Positionsinformationen noch immer nicht verfügbar sind, kann das Fahrzeug 102 eine Fehlerzeit und einen letzten bekannten Standort protokollieren, die gesammelt und zur Fehlersuche für schwierige Bereiche verwendet werden können.
-
Die TCU 106 kann dazu konfiguriert sein, dem Fahrzeug 102 Telematikdienste bereitzustellen. Diese Dienste können als einige nicht einschränkende Möglichkeiten Navigation, Turn-by-Turn-Wegbeschreibungen, Fahrzeugzustandsmeldungen, lokale Unternehmenssuche, Unfallmeldung und Freisprecheinrichtung beinhalten. Die TCU 106 kann dementsprechend dazu konfiguriert sein, über verschiedene Protokolle zu kommunizieren, wie etwa mit einem Kommunikationsnetzwerk 108 über ein Netzwerkprotokoll (wie etwa Uu). Die TCU 106 kann zusätzlich dazu konfiguriert sein, über ein Peer-to-Peer-Übertragungsprotokoll (wie etwa PC5) zu kommunizieren, um C-V2X-Kommunikationen mit Vorrichtungen, wie etwa der RSU 110, zu ermöglichen. Es ist anzumerken, dass diese Protokolle lediglich Beispiele sind und unterschiedliche Peer-to-Peer- und/oder Mobilfunktechnologien verwendet werden können.
-
Das Kommunikationsnetzwerk 108 kann Vorrichtungen, die mit dem Kommunikationsnetzwerk 108 verbunden sind, Kommunikationsdienste bereitstellen, wie etwa paketvermittelte Netzwerkdienste (z. B. Internetzugang, Voice-over-Internet-Protocol-Kommunikationsdienste (VoIP-Kommunikationsdienste)). Ein Beispiel für ein Kommunikationsnetzwerk 108 ist ein Mobilfunktelefonnetzwerk. Beispielsweise kann die TCU 106 über eine Verbindung mit einem oder mehreren Mobilfunktürmen auf das Mobilfunknetzwerk zugreifen. Um die Kommunikation über das Kommunikationsnetzwerk 108 zu ermöglichen, kann die TCU 106 eindeutigen Vorrichtungskennungen (z. B. Nummern mobiler Vorrichtungen (mobile device numbers - MDNs), Internetprotokoll-Adressen (IP-Adressen) usw.) zugeordnet sein, um zu identifizieren, dass die Kommunikation der TCU 106 über das Kommunikationsnetzwerk 108 dem Fahrzeug 102 zugeordnet ist.
-
Die RSU 110 kann eine Vorrichtung mit Verarbeitungsfähigkeiten und Netzwerkfähigkeiten sein und kann dazu ausgelegt sein, zur Verwendung bei der Kommunikation mit Fahrzeugen 102 in der Nähe eines Dienstes 112 platziert zu werden. In einem Beispiel kann die RSU 110 Hardware beinhalten, die dazu konfiguriert ist, über das Peer-to-Peer-Übertragungsprotokoll (wie etwa PC5) zu kommunizieren, um C-V2X-Kommunikationen mit den Fahrzeugen 102 zu ermöglichen. Die RSU 110 kann dementsprechend dazu in der Lage sein, mit mehreren Fahrzeugen 102 entlang einer spezifischen Fahrbahn oder in einem spezifischen Bereich zu kommunizieren. Die RSU 110 kann zudem eine drahtgebundene oder drahtlose Backhaul-Fähigkeit aufweisen, um eine Kommunikation mit anderen Elementen des Kommunikationsnetzwerkes 108, wie etwa dem Backend-Verwaltungsdienst 114, zu ermöglichen.
-
Der Backend-Verwaltungsdienst 114 kann eine oder mehrere vernetzte Rechenvorrichtungen beinhalten, die dazu konfiguriert sind, Vorgänge zur Unterstützung der Funktionalität der RSU 110 durchzuführen. In einem Beispiel kann der Backend-Verwaltungsdienst 114 über das Kommunikationsnetzwerk 108 mit der RSU 110 in Kommunikation stehen.
-
Das System 100 kann einen Kommunikationsfluss zur Schlüsseleinrichtung zwischen den Fahrzeugen 102 und dem Backend-Verwaltungsdienst 114 unterstützen. Dieser Kommunikationsfluss ist in dem System 100 als Fluss (i) gezeigt und ist als kurzgestrichelte Linie dargestellt. Das System 100 kann zudem einen Kommunikationsfluss auf einem sicheren Kanal zwischen den Fahrzeugen 102 und den RSUs 110 unterstützen. Dieser Kommunikationsfluss ist in dem System 100 als Fluss (ii) gezeigt und ist als Strich-Punkt-Linie dargestellt. Das System 100 kann zudem einen Backend-Kommunikationsfluss zwischen den RSUs 110 und dem Backend-Verwaltungsdienst 114 unterstützen. Dieser Kommunikationsfluss ist in dem System 100 als Fluss (iii) gezeigt und ist als langgestrichelte Linie dargestellt. Weitere Aspekte des Betriebs des Backend-Verwaltungsdienstes 114 und die Flüsse (i), (ii) und (iii) werden in dieser Schrift ausführlich erörtert.
-
2 veranschaulicht ein Beispiel 200 für den Kommunikationsfluss (i) zur Schlüsseleinrichtung im Hinblick auf die Elemente des Systems 100. 3 veranschaulicht ein Beispiel für einen Datenfluss 300 des Kommunikationsflusses (i) zur Schlüsseleinrichtung. Unter Bezugnahme auf 2 und 3 wird bei Index (A) ein Registrierungsdienst eingeleitet. In einem Beispiel kann der Fluss (i) zu einem bestimmten Zeitpunkt eingeleitet werden, bevor das Fahrzeug 102 die Verwendung eines Dienstes 112 erfordert. In einem anderen Beispiel kann das Fahrzeug 102 seine Sensoren 104 nutzen, um zu bestimmen, dass sich eine RSU 110, die einen Dienst 112 steuert, in der Nähe des Fahrzeugs 102 befindet, und kann den Fluss (i) als Reaktion auf den Wunsch, den detektierten Dienst 112 zu nutzen, einleiten.
-
Bei Index (B) generiert das Fahrzeug 102 ein Paar aus öffentlichem/privatem Schlüssel. Dies ist in dem Beispiel 200 als öffentlicher Schlüssel 202 des Fahrzeugs und privater Schlüssel 204 des Fahrzeugs gezeigt. Diese Schlüssel können durch die TCU 106 des Fahrzeugs 102 generiert werden, anstatt den privaten Schlüssel des HSM 410 des Fahrzeugs 102 bereitzustellen (nachstehend ausführlicher erörtert). Dies kann vermieden werden, da das Paar aus dem öffentlichen Schlüssel 202 des Fahrzeugs und dem privaten Schlüssel 204 des Fahrzeugs leichter widerrufen werden kann als andere Ansätze, die stärker an ein spezifisches HSM 410 gebunden sind. Weitere Aspekte der Schlüsselgenerierung sind in 4 gezeigt.
-
Bei Index (C) initiiert das Fahrzeug 102 die Einrichtung einer sicheren Verbindung mit dem Backend-Verwaltungsdienst 114. Diese Verbindungsanforderung kann in einem Beispiel über das Kommunikationsnetzwerk 108 gesendet werden. Der Backend-Verwaltungsdienst 114 kann die Anforderung bei Index (D) empfangen und kann die Einrichtung der sicheren Verbindung mit dem Fahrzeug 102 abschließen.
-
Bei Index (E) bereitet das Fahrzeug 102 eine Dienstanforderung 206 zum Senden an den Backend-Verwaltungsdienst 114 vor. Die Dienstanforderung 206 kann eine Anforderung zur Verwendung der Merkmale des Dienstes 112 beinhalten. Einige nicht einschränkende Beispiele für die Dienste 112 können Mautstraßen, wie in 6 gezeigt, Händler, wie in 7 gezeigt, und Parken beinhalten, wie in 8 gezeigt. Die Dienstanforderung 206 kann den öffentlichen Schlüssel 202 des Fahrzeugs beinhalten. Die Fahrzeuge 102 können den privaten Schlüssel 204 des Fahrzeugs in einem Datenspeicher in dem Fahrzeug 102 pflegen. Bei Index (F) wird die Dienstanforderung 206 an den Backend-Verwaltungsdienst 114 gesendet. Die Dienstanforderung 206 wird bei Index (G) an dem Backend-Verwaltungsdienst 114 empfangen.
-
Bei Index (H) bereitet der Backend-Verwaltungsdienst 114 ein Zertifikatsbündel 208 vor. Das Zertifikatsbündel 208 kann Informationen beinhalten, die es dem Fahrzeug 102 ermöglichen, mit dem Dienst 112 zu kommunizieren. In einem Beispiel kann das Zertifikatsbündel 208 einen öffentlich Schlüssel 210 des Dienstes und einen privaten Schlüssel 212 des Dienstes beinhalten. Der öffentliche Schlüssel 210 des Dienstes und der private Schlüssel 212 des Dienstes können ein asymmetrisches Schlüsselpaar sein, das für den Backend-Verwaltungsdienst 114 generiert wurde oder anderweitig verfügbar ist. In einigen Beispielen kann das Zertifikatsbündel 208 Informationen beinhalten, die es dem Fahrzeug 102 ermöglichen, einen einzelnen Dienst 112 zu nutzen. In anderen Beispielen kann das Zertifikatsbündel 208 Informationen beinhalten, die es dem Fahrzeug 102 ermöglichen, mehrere unterschiedliche Dienste 112 zu nutzen (z. B. zwei oder mehr von Parken, Händler, Mauterhebung usw.).
-
Bei Index (I) verschlüsselt der Backend-Verwaltungsdienst 114 das Zertifikatsbündel 208 unter Verwendung des öffentlichen Schlüssels 202 des Fahrzeugs. Dies führt zur Generierung eines verschlüsselten Zertifikatsbündels 214, das den öffentlichen Schlüssel 210 des Dienstes und den privaten Schlüssel 212 des Dienstes beinhaltet. Bei Index (J) sendet der Backend-Verwaltungsdienst 114 das verschlüsselte Zertifikatsbündel 214 an das Fahrzeug 102, das dann von der TCU 106 des Fahrzeugs 102 empfangen werden kann.
-
Bei Index (K) entschlüsselt das Fahrzeug 102 das verschlüsselte Zertifikatsbündel 214 unter Verwendung des privaten Schlüssels 204 des Fahrzeugs. Der öffentliche Schlüssel 210 des Dienstes und der private Schlüssel 212 des Dienstes werden dementsprechend während der Übertragung aufgrund der Verschlüsselung des verschlüsselten Zertifikatsbündels 214 unter Verwendung des öffentlichen Schlüssels 202 des Fahrzeugs sicher aufbewahrt. Da nur das Fahrzeug 102 über Zugriff auf den privaten Schlüssel 204 des Fahrzeugs verfügt, sind Vermittler möglicherweise nicht in der Lage, den öffentlichen Schlüssel 210 des Dienstes und den privaten Schlüssel 212 des Dienstes während der Übertragung zu entschlüsseln. Bei Index (L) stehen die Informationen des Zertifikatsbündels 208 dem Fahrzeug 102 zur Verwendung beim Kommunizieren mit dem Dienst 112 zur Verfügung.
-
4 veranschaulicht weitere Details der Generierung der Schlüssel, die verwendet werden, um die in dieser Schrift erörterten Vorgänge durchzuführen. Wie ausführlicher gezeigt, können die Dienste 112 durch eine oder mehrere Anbieter-Clouds 402 umgesetzt sein. Die Anbieter-Cloud 402 kann über das Kommunikationsnetzwerk 108 zugreifbar sein und kann dem Fahrzeug 102 Umsetzungen der Dienste 112 bereitstellen.
-
Jeder der Dienste 112 kann dazu konfiguriert sein, dem Fahrzeug 102 einen Dienstidentitätsschlüssel 404 bereitzustellen. Dieser Dienstidentitätsschlüssel 404 kann dem Dienst 112 entsprechen und kann in vielen Beispielen auch für das Fahrzeug 102 spezifisch sein. In einem nicht einschränkenden Beispiel kann jeder Dienstidentitätsschlüssel 404 einen Teilsatz von Bits, der den spezifischen Dienst 112 identifiziert, und einen Rest der Bits, der das spezifische Fahrzeug 102 identifiziert, beinhalten.
-
Ein Identitätsschlüsselverwalter 406 des Fahrzeugs 102 kann dazu konfiguriert sein, über das Kommunikationsnetzwerk 108 mit der Anbieter-Cloud 402 in Kommunikation zu stehen. Der Identitätsschlüsselverwalter 406 kann dazu konfiguriert sein, die Dienstidentitätsschlüssel 404 von den Diensten 112 unter Verwendung eines Empfängers 408 zu empfangen. Als Reaktion auf den Empfang der Dienstidentitätsschlüssel 404 kann der Identitätsschlüsselverwalter 406 dazu konfiguriert sein, mit einem HSM 410 des Fahrzeugs 102 zu kommunizieren, um Vorgänge durchzuführen, wie etwa eine Registrierung des Fahrzeugs 102 bei dem Dienst 112 zu aktualisieren und den Dienstidentitätsschlüssel 404 gegenüber dem HSM 410 anzugeben.
-
Der Identitätsschlüsselverwalter 406 kann einen Generator 412 beinhalten, der dazu konfiguriert ist, mit dem HSM 410 zu kommunizieren, um private Schlüssel 416 des Dienstes für das Fahrzeug 102 zu generieren, die dem Dienstidentitätsschlüssel 404 entsprechen. Die privaten Schlüssel 416 des Dienstes und die öffentlichen Schlüssel 414 des Dienstes können für das Fahrzeug 102 spezifische Schlüssel zur Verwendung beim Zugreifen auf den Dienst 112 sein, der dem Dienstidentitätsschlüssel 404 entspricht. Das HSM 410 kann eine Zuordnungsgleichung 416 für den privaten Schlüssel und den öffentlichen Schlüssel 414 des Dienstes aus dem Dienstidentitätsschlüssel 404 zum Signieren der dienstspezifischen Anwendung 420 verwenden. In einem Beispiel kann die Zuordnungsgleichung 416 für den privaten Schlüssel eine Gleichung sein, die den privaten Schlüssel für das HSM 410 algorithmisch unter Verwendung des Dienstidentitätsschlüssels 404 generiert. Während der öffentliche Schlüssel 414 des Dienstes auf dem generierten privaten Schlüssel 416 des Dienstes des HSM 410 basieren kann, kann der öffentliche Schlüssel 414 des Dienstes auch für den Dienst 112 und das Fahrzeug 102 spezifisch sein. Somit wird, wenn der öffentliche Schlüssel 414 des Dienstes widerrufen wird, der private Schlüssel des HSM 410 selbst nicht widerrufen und kann noch für andere Zwecke verwendet werden. In einigen Beispielen kann die Zuordnungsgleichung 416 für den privaten Schlüssel für den Dienst 112 spezifisch sein, während in anderen Beispielen die gleiche Zuordnungsgleichung 416 für den privaten Schlüssel über die Dienste 112 hinweg verwendet werden kann.
-
Ein Anwendungsdienstmanager 418 des Fahrzeugs 102 kann mit dem Identitätsschlüsselmanager 406 in Kommunikation stehen. Der Anwendungsdienstmanager 418 kann dazu konfiguriert sein, es dem Identitätsschlüsselmanager 406 zu ermöglichen, die richtige Anwendung 420 des Fahrzeugs 102 zu identifizieren, um den Betrieb des Dienstes 112 zu unterstützen. Beispielsweise können die Anwendungen 420 Informationen beinhalten, die angeben, welche Dienstidentitätsschlüssel 404 (z. B. der Teilsatz von Bits, der den spezifischen Dienst 112 identifiziert) und somit welche Dienste 112 durch die jeweiligen Anwendungen 420 unterstützt werden. Der Anwendungsdienstmanager 418 kann dementsprechend den Dienstidentitätsschlüssel 404 verwenden, um zu identifizieren, welche Anwendung 420 (oder Anwendungen 420) dem Dienstidentitätsschlüssel 404 entspricht.
-
Das Fahrzeug 102 kann zudem mit dem Backend-Verwaltungsdienst 114 kommunizieren. Dies kann in einigen Beispielen über die RSU 110 oder direkt über Mobilfunk über das Kommunikationsnetzwerk 108 durchgeführt werden. Dies kann den Empfang des Zertifikatsbündels 208, wie vorstehend in Bezug auf 2 erörtert, sowie die jeweilige Aktualisierung der Zertifikatsregistrierung, wie vorstehend in Bezug auf 3 erörtert, beinhalten. Das Zertifikatsbündel 208 kann Anmeldeinformationen oder Schlüssel für jede unterschiedliche Nachricht beinhalten, die zwischen dem Fahrzeug 102 und dem Dienst 112 gesendet werden kann. Beispielsweise kann das Fahrzeug 102 Signieren 424 von Nachrichten durchführen, die durch den Sendeempfänger 426 (z. B. die TCU 106) unter Verwendung der Anmeldeinformationen oder der Schlüssel aus dem Zertifikatsbündel 208 gesendet werden, und kann eine Verifizierung 428 unter Verwendung der Anmeldeinformationen oder der Schlüssel für die Nachricht durchführen, die durch den Sendeempfänger 426 empfangen werden.
-
5 veranschaulicht einen beispielhaften Datenfluss 500 für den Kommunikationsfluss (ii) auf einem sicheren Kanal zwischen dem Fahrzeug 102 und dem Dienst 112. Der Datenfluss 500 kann zum Beispiel nach Abschluss des Datenflusses 300 durchgeführt werden.
-
Bei Index (A) generiert das Fahrzeug 102 C-V2X-Nachrichtennutzdaten. Diese Nachrichtennutzdaten können für die Vorgänge spezifisch sein, die durch das Fahrzeug 102 mit dem Dienst 112 durchgeführt werden. Bei Index (B) codiert das Fahrzeug 102 die Nutzdaten. Dies kann in einem nicht einschränkenden Beispiel unter Verwendung einer Codierung mit unausgerichteten gepackten Codierungsregeln (unaligned encoding rules - UPER) erfolgen. In anderen Beispielen können andere Codierungsschemata verwendet werden, wie etwa grundlegende Codierungsregeln (basic encoding rules - BER), unterschiedene Codierungsregeln (distinguished encoding rules - DER), Packet-Codierungsregeln (packet encoding rules - PER), Oktettcodierungsregeln (octet encoding rules - OER), kanonische Oktettcodierungsregeln (canonical octed encoding rules - COER), JavaScript Object Notation (JSON), Extensible Markup Language (XML) usw.
-
Bei Index (C) signiert das Fahrzeug 102 die codierten Nutzdaten unter Verwendung des privaten Schlüssels 204 des Fahrzeugs. Dieser private Schlüssel 212 des Dienstes kann durch das Fahrzeug 102 empfangen worden sein, wie vorstehend in dem Datenfluss 300 angemerkt. Bei Index (D) fügt das Fahrzeug 102 die Signatur zu den Nutzdaten hinzu. Bei Index (E) fügt das Fahrzeug 102 ein Zertifikat aus dem Zertifikatsbündel 208 zu den Nutzdaten hinzu, einschließlich des öffentlichen Schlüssels 202 des Fahrzeugs. Bei Index (F) sendet das Fahrzeug 102 die V2X-Nachricht einschließlich der Nutzdaten an den Dienst 112. Die Nachricht wird durch den Dienst 112 empfangen.
-
Bei Index (G) verifiziert der Dienst 112, dass das Fahrzeug 102 über Zugriff auf den Dienst 112 verfügt. In einem Beispiel kann der Dienst 112 eine Zertifikatswiderrufsliste (certificate revocation list - CRL) von dem Backend-Verwaltungsdienst 114 empfangen. Beispielsweise kann der Dienst 112 die CRL über den Backend-Kommunikationsfluss (iii) zwischen den RSUs 110 und dem Backend-Verwaltungsdienst 114 empfangen. Der Dienst 112 kann diese CRL überprüfen, um zu sehen, ob das Zertifikat aus der empfangenen V2X-Nachricht widerrufen wurde. Wenn dies der Fall ist, lehnt der Dienst 112 das Fahrzeug 102 ab und wird der Zugriff auf den Dienst 112 verweigert.
-
Bei Index (H) bestätigt der Dienst 112 die Signatur in den Nachrichtennutzdaten. In einem Beispiel verifiziert der Dienst 112 die Signatur unter Verwendung des öffentlichen Schlüssels 202 des Fahrzeugs. Wenn die Nachricht bestätigt wird, verarbeitet der Dienst 112 bei Index (I) die V2X-Nachricht.
-
6 veranschaulicht ein Beispiel 600 für das Fahrzeug 102, das einen Kommunikationsfluss (ii) auf einem sicheren Kanal zwischen den Fahrzeugen 102 und einer RSU 110 eines Fahrbahnmautdienstes 112A durchführt. Der Kommunikationsfluss (ii) auf einem sicheren Kanal kann durch das Fahrzeug 102 unter Verwendung der Informationen des Zertifikatsbündels 208 durchgeführt werden, die unter Verwendung des in Bezug auf 2-5 erörterten Ansatzes abgerufen werden.
-
Zum Beispiel kann das Fahrzeug 102 mit der RSU 110 des Fahrbahnmautdienstes 112A kommunizieren. Das Fahrzeug 102 kann in einem Beispiel eine Mautankündigungsnachricht (toll advertisement message - TAM) 602 von der RSU 110 des Fahrbahnmautdienstes 112A empfangen. Die TAM 602 kann Informationen beinhalten, um das Fahrzeug 102 über die Nutzungsrate einer Fahrbahn 604 zu informieren, die durch den Fahrbahnmautdienst 112A gesteuert wird.
-
Die TAM 602 kann verschiedene Informationen beinhalten, die für das Fahrzeug 102 nützlich sind, um die Nutzung der Fahrbahn 604 zu verstehen, die durch den Fahrbahnmautdienst 112A gesteuert wird. Dies kann Felder beinhalten, wie etwa Folgende: einen Zeitstempel, der die Zeit angibt, zu der die TAM erstellt oder gesendet wurde, Mautarten und Mautbeträge, die angeben, wie die Mautinformationen erhoben werden (z. B. basierend auf der Mautratentabelle), eine Schichtart, eine Schichtkennung, eine Kennung eines zur Bezahlung der Maut zu verwendenden Bezahldienstes usw. Die Schichtart kann ein Datenelement sein, das verwendet wird, um eine Informationsart, die in einer Schicht eines geografischen Kartenfragments, wie etwa einer Kreuzung, zu finden ist, eindeutig zu identifizieren. Die Schichtkennung kann dementsprechend eine Kennung von Karteninformationen sein.
-
Die TAM 602 kann zudem Karteninformationen beinhalten, die das Layout der Fahrbahn 604 angeben, wie etwa eine Kreuzungsgeometrieliste und eine Straßensegmentliste. Die Straßensegmentliste kann verschiedene Eigenschaften der Fahrbahn beinhalten, einschließlich Fahrstreifenbeschreibung, eines Status mit hoher Belegung und so weiter. Diese Informationen können beispielsweise Angaben des Layouts der Fahrstreifen der Fahrbahn 604 beinhalten, die verwendet werden können, um den Fahrzeugen 102 zu ermöglichen, zu identifizieren, wann ein mautpflichtiger Bereich angefahren wird, sowie auf welchem Fahrstreifen das Fahrzeug 102 fährt.
-
Zum Beispiel kann die TAM 602 einen oder mehrere Auslöseknotenpunkte definieren, die gemeinsam die Grenzen einer Auslösezone definieren können. Weitere Aspekte von Kartendaten und andere Details von in dieser Schrift beschriebenen Nachrichtenelementen sind ferner im J2735-Standard DSRC Message Set Dictionary (TM), veröffentlicht von der Society of Automotive Engineers (SAE) International, definiert, wobei der Standard durch Bezugnahme vollumfänglich in diese Schrift aufgenommen wird.
-
Als Reaktion darauf, dass das Fahrzeug 102 den Standort erreicht, kann die TCU 106 des Fahrzeugs 102 eine Mautnutzungsnachricht (toll usage message - TUM) 606 generieren. Die TUM 606 beinhaltet verschiedene Informationen, die den RSUs 110 durch die Fahrzeuge 102 bereitgestellt werden und die Nutzung der Fahrbahn 604 durch das Fahrzeug 102 angeben. Diese Informationen können Felder beinhalten, wie etwa einen Nachrichtenzähler, der eine eindeutige Nummer der TUM 606 für die Transaktion angibt. Der Nachrichtenzähler kann verwendet werden, um beim Identifizieren zu helfen, ob ein Paketverlust aufgetreten ist. Die TUM 606 kann zudem eine eindeutige zufällige Kennung beinhalten, die als eine vorübergehende Kontokennung oder -markierung verwendet werden kann, um die Nachrichtentransaktion zwischen dem Fahrzeug 102 und der Nachrichtenübertragungsschnittstelle der RSU 110 zu verfolgen, während eine relative Anonymität des Fahrzeugs 102 gewahrt wird.
-
Die TUM 606 kann zudem Informationen über den Eintritt des Fahrzeugs 102 in den Mautbereich beinhalten. Beispielsweise kann die TUM 606 einen Zeitstempel der Zeit, zu der die TUM 606 erstellt wurde, den Breitengrad, den Längengrad und die Höhenlage des Fahrzeugs 102, die Positionsgenauigkeit des Breitengrads, des Längengrads und der Höhenlage, die Geschwindigkeit des Fahrzeugs 102 und den Kurs des Fahrzeugs 102 beinhalten. Die TUM 606 kann zudem andere Informationen beinhalten, wie etwa die Art des Fahrzeugs 102, eine Kennung der Mautbezahlzentrale. Die Kennungen können global eindeutige Kennungen (globally unique identifiers - GUIDs) sein, um zu ermöglichen, dass der Bezahldienst für die Fahrbahn 604 eindeutig identifiziert wird. Die TUM 606 kann zudem eine Kreuzungskennung der Kreuzung beinhalten, über die das Fahrzeug 102 in die Fahrbahn 604 eingetreten ist, wobei die Kreuzungskennung durch das Fahrzeug 102 in der TAM 602 empfangen wurde (z. B. über die Kreuzungsgeometrieliste und/oder die Straßensegmentliste). Die TUM 606 kann zudem einen Gebührenbetrag für die Fahrt in dem mautpflichtigen Bereich beinhalten, wie durch das Fahrzeug 102 unter Verwendung der Informationen in der TAM 602 bestimmt. Andere Informationen können ebenfalls in der TUM 606 beinhaltet sein, wie etwa die durch das Fahrzeug 102 zurückgelegte Strecke, eine Anzahl von Fahrgästen in dem Fahrzeug 102 und ein Nummernschild oder eine andere Kennung des Fahrzeugs 102.
-
Die TCU 106 kann die TUM 606 an die RSU 110 senden. In einem Beispiel kann die TUM 606 mit einem Schlüssel codiert und/oder unter Verwendung eines Zertifikats signiert sein und kann die RSU 110 einen Schlüssel oder andere Informationen nutzen, um den Sender der TUM 606 als die TCU 106 zu entschlüsseln und/oder zu bestätigen. Die RSU 110 kann die TUM 606 an ein Bezahlzentrale weiterleiten, um die Transaktion abzuschließen.
-
7 veranschaulicht ein Beispiel 700 für das Fahrzeug 102, das einen Kommunikationsfluss auf einem sicheren Kanal zwischen den Fahrzeugen 102 und einer RSU 110 eines Händlerdienstes 112B durchführt. Ähnlich wie in dem Beispiel 600 kommuniziert das Fahrzeug 102 in dem Beispiel 700 V2X-Nachrichten mit der RSU 110 des Händlerdienstes 112B, um einen Kauf von dem Händlerdienst 112B durchzuführen.
-
8 veranschaulicht ein Beispiel 800 für das Fahrzeug 102, das einen Kommunikationsfluss auf einem sicheren Kanal zwischen den Fahrzeugen 102 und einer RSU 110 eines Parkdienstes 112C durchführt. Ähnlich wie in dem Beispiel 600 und dem Beispiel 700 kommuniziert das Fahrzeug 102 in dem Beispiel 800 V2X-Nachrichten mit der RSU 110 des Parkdienstes 112C, um für das Parken von dem Parkdienst 112C zu bezahlen.
-
Wie vorstehend angemerkt, kann den Diensten 112 eine CRL von dem Backend-Verwaltungsdienst 114 bereitgestellt werden, um es den Diensten 112 zu ermöglichen, zu identifizieren, wann Fahrzeuge 102 von den Diensten 112 abgemeldet wurden. Die Abmeldung kann in einem Beispiel dadurch eingeleitet werden, dass ein Fahrzeug 102 den Dienstanbieter von einem Dienst 112 zu einem anderen wechselt. Oder in einem anderen Beispiel kann die Abmeldung daraus resultieren, dass der Dienst 112 das Fahrzeug 102 wegen Nichtzahlung oder eines anderen Problems entfernt. Unabhängig davon kann das Fahrzeug 102 in der Lage sein, sich von einem Dienst 112 abzumelden, ohne die Abonnements des Fahrzeugs 102 für andere Dienste 112 zu beeinflussen, da das Fahrzeug 102 unterschiedliche Schlüssel und Zertifikatsbündel 208 für unterschiedliche Dienste verwenden kann.
-
9 veranschaulicht ein Beispiel 900 für eine Rechenvorrichtung 902. Unter Bezugnahme auf 9 und unter Bezugnahme auf 1-8 können die TCU 106, die RSU 110 und der Backend-Verwaltungsdienst 114 Beispiele für derartige Rechenvorrichtungen 902 sein. Wie gezeigt, kann die Rechenvorrichtung 902 einen Prozessor 904 beinhalten, der mit einem Datenspeicher 906, einer Netzwerkvorrichtung 908, einer Ausgabevorrichtung 910 und einer Eingabevorrichtung 912 wirkverbunden ist. Es ist zu beachten, dass dies lediglich ein Beispiel ist und Rechenvorrichtungen 902 mit mehr, weniger oder anderen Komponenten verwendet werden können.
-
Der Prozessor 904 kann eine oder mehrere integrierte Schaltungen beinhalten, welche die Funktionalität einer zentralen Verarbeitungseinheit (central processing unit - CPU) und/oder Grafikverarbeitungseinheit (graphics processing unit - GPU) umsetzen. In einigen Beispielen handelt es sich bei den Prozessoren 904 um ein System auf einem Chip (system on a chip - SoC), in dem die Funktionalität der CPU und der GPU integriert ist. Das SoC kann gegebenenfalls andere Komponenten, wie zum Beispiel den Datenspeicher 906 und die Netzwerkvorrichtung 908 in einer einzelnen integrierten Vorrichtung beinhalten. In anderen Beispielen sind die CPU und die GPU über eine Peripherieverbindungsvorrichtung, wie etwa Peripheral Component Interconnect (PCI) Express oder eine andere geeignete Peripheriedatenverbindung, miteinander verbunden. In einem Beispiel ist die CPU eine im Handel erhältliche zentrale Verarbeitungsvorrichtung, die einen Anweisungssatz umsetzt, wie etwa einen der Anweisungssatzfamilien x86, ARM, Power oder Microprocessor without Interlocked Pipeline Stage (MIPS).
-
Unabhängig von den Einzelheiten führt der Prozessor 904 während des Betriebs gespeicherte Programmanweisungen aus, die aus dem Datenspeicher 906 abgerufen werden. Die gespeicherten Programmanweisungen beinhalten dementsprechend Software, die den Betrieb der Prozessoren 904 steuert, um die in dieser Schrift beschriebenen Vorgänge durchzuführen. Der Datenspeicher 906 kann sowohl nicht flüchtige als auch flüchtige Speichervorrichtungen beinhalten. Der nicht flüchtige Speicher beinhaltet Festkörperspeicher, wie etwa Negative-AND-(NAND-)Flash-Speicher, magnetische und optische Speichermedien oder eine beliebige andere geeignete Datenspeichervorrichtung, die Daten beibehält, wenn das System 100 abgeschaltet wird oder dessen Versorgung mit elektrischer Leistung unterbrochen wird. Der flüchtige Speicher beinhaltet einen statischen und dynamischen Direktzugriffsspeicher (random-access memory - RAM), auf dem während des Betriebs des Systems 100 Programmanweisungen und Daten gespeichert werden.
-
Die GPU kann Hardware und Software zur Anzeige von mindestens zweidimensionalen (2D-) und gegebenenfalls dreidimensionalen (3D-)Grafiken auf der Ausgabevorrichtung 910 beinhalten. Die Ausgabevorrichtung 910 kann eine grafische oder visuelle Anzeigevorrichtung, wie etwa einen elektronischen Anzeigebildschirm, einen Projektor, einen Drucker oder eine beliebige andere geeignete Vorrichtung, die eine grafische Anzeige wiedergibt, beinhalten. Als ein anderes Beispiel kann die Ausgabevorrichtung 910 eine Audiovorrichtung, wie etwa einen Lautsprecher oder einen Kopfhörer, beinhalten. Als noch ein weiteres Beispiel kann die Ausgabevorrichtung 910 eine taktile Vorrichtung, wie etwa eine mechanisch erhöhbare Vorrichtung, beinhalten, die in einem Beispiel dazu konfiguriert sein kann, Blindenschrift oder eine andere physische Ausgabe anzuzeigen, die berührt werden kann, um einem Benutzer Informationen bereitzustellen.
-
Die Eingabevorrichtung 912 kann eine beliebige von verschiedenen Vorrichtungen beinhalten, die es der Rechenvorrichtung 902 ermöglichen, Steuereingaben von Benutzern zu empfangen. Beispiele für geeignete Eingabevorrichtungen, die Eingaben über eine menschliche Schnittstelle empfangen, können Tastaturen, Mäuse, Trackballs, Touchscreens, Spracheingabevorrichtungen, Grafiktablets und dergleichen beinhalten.
-
Die Netzwerkvorrichtungen 908 können jeweils eine beliebige von verschiedenen Vorrichtungen beinhalten, die es der TCU 106, der RSU 110 und dem Backend-Verwaltungsdienst 114 ermöglichen, Daten von externen Vorrichtungen über Netzwerke (wie etwa das Kommunikationsnetzwerk 108) zu senden und/oder zu empfangen. Beispiele für geeignete Netzwerkvorrichtungen 908 beinhalten eine Ethernet-Schnittstelle, einen Wi-Fi-Sendeempfänger, einen Mobilfunk-Sendeempfänger, einen BLUETOOTH- oder BLUETOOTH-Low-Energy-Sendeempfänger (BLE-Sendeempfänger) oder einen anderen Netzwerkadapter oder eine andere Peripherie-Verbindungsvorrichtung, der/die Daten von einem anderen Computer oder einer externen Datenspeichervorrichtung empfängt, was zum Empfangen großer Datensätze auf effiziente Weise nützlich sein kann.
-
Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen beschreiben, die durch die Patentansprüche eingeschlossen sind. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale unterschiedlicher Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden, die möglicherweise nicht ausdrücklich beschrieben oder veranschaulicht sind. Wenngleich verschiedene Ausführungsformen gegenüber anderen Ausführungsformen oder Umsetzungen nach dem Stand der Technik in Bezug auf eine oder mehrere gewünschte Eigenschaften als vorteilhaft oder bevorzugt beschrieben worden sein könnten, erkennt der Durchschnittsfachmann, dass bei einem/einer oder mehreren Merkmalen oder Eigenschaften Kompromisse eingegangen werden können, um die gewünschten Gesamtattribute des Systems zu erzielen, die von der spezifischen Anwendung und Umsetzung abhängen. Diese Attribute können Festigkeit, Haltbarkeit, Lebenszyklus, Marktfähigkeit, Erscheinungsbild, Verbauung, Größe, Wartbarkeit, Gewicht, Herstellbarkeit, Einfachheit der Montage usw. beinhalten, sind aber nicht darauf beschränkt. Soweit beliebige Ausführungsformen in Bezug auf eine oder mehrere Eigenschaften als weniger wünschenswert als andere Ausführungsformen oder Umsetzungen nach dem Stand der Technik beschrieben werden, liegen diese Ausführungsformen demnach nicht außerhalb des Umfangs der Offenbarung und können für konkrete Anwendungen wünschenswert sein.
-
Gemäß der vorliegenden Erfindung ist ein Fahrzeug zur sicheren Dienstregistrierung bereitgestellt, das Folgendes aufweist: einen Sendeempfänger; und eine Steuerung, die dazu programmiert ist, den Sendeempfänger zu Folgendem zu nutzen: Einrichten einer sicheren Verbindung mit einem Verwaltungssystem, Senden einer Dienstanforderung zum Zugreifen auf einen Fahrzeug-zu-Allem-Dienst (V2X-Dienst) an das Verwaltungssystem, wobei die Dienstanforderung einen öffentlichen Schlüssel des Fahrzeugs eines Paares aus öffentlichem/privatem Schlüssel des Fahrzeugs beinhaltet, Empfangen eines Zertifikatsbündels von dem Verwaltungssystem, das unter Verwendung des öffentlichen Schlüssels des Fahrzeugs verschlüsselt ist, wobei das Zertifikatsbündel ein Paar aus öffentlichem/privatem Schlüssel des Dienstes und ein Zertifikat zum Zugreifen auf den V2X-Dienst beinhaltet, Entschlüsseln des Zertifikatsbündels unter Verwendung eines privaten Schlüssels des Fahrzeugs, der dem öffentlichen Schlüssel des Fahrzeugs entspricht, und Nutzen des Paares aus öffentlichem/privatem Schlüssel des Dienstes und des Zertifikats, um auf den V2X-Dienst zuzugreifen.
-
Gemäß einer Ausführungsform ist das Paar aus öffentlichem/privatem Schlüssel des Fahrzeugs spezifisch für den V2X-Dienst, und wobei die Steuerung ferner dazu programmiert ist, den dienstspezifischen öffentlichen Schlüssel des Fahrzeugs und den dienstspezifischen privaten Schlüssel des Fahrzeugs unter Verwendung eines Dienstidentitätsschlüsselzuordnungsmoduls zu generieren.
-
Gemäß einer Ausführungsform ist die Steuerung ferner zu Folgendem programmiert: Generieren von V2X-Nachrichtennutzdaten zum Abgeben an den V2X-Dienst; Signieren der V2X-Nachrichtennutzdaten unter Verwendung des privaten Schlüssels des Dienstes; und Senden der V2X-Nachrichtennutzdaten, wie signiert, an den V2X-Dienst.
-
Gemäß einer Ausführungsform ist die Erfindung ferner gekennzeichnet durch Einbeziehen des Zertifikatsbündels und des öffentlichen Schlüssels des Fahrzeugs in die V2X-Nachrichtennutzdaten.
-
Gemäß einer Ausführungsform ist der V2X-Dienst eine mautpflichtige Fahrbahn.
-
Gemäß einer Ausführungsform ist der V2X-Dienst ein Händler.
-
Gemäß einer Ausführungsform ist der V2X-Dienst ein Parken für das Fahrzeug.
-
Gemäß der vorliegenden Erfindung ist ein System zur sicheren Dienstregistrierung bereitgestellt, das Folgendes aufweist: ein Verwaltungssystem, das dazu programmiert ist, von einem Fahrzeug eine Dienstanforderung zum Zugreifen auf einen Fahrzeug-zu-Allem-Dienst (V2X-Dienst) zu empfangen, wobei die Dienstanforderung einen öffentlichen Schlüssel des Fahrzeugs eines Paares aus öffentlichem/privatem Schlüssel des Fahrzeugs beinhaltet; ein Zertifikatsbündel vorzubereiten, das ein Paar aus öffentlichem/privatem Schlüssel des Dienstes und ein Zertifikat zum Zugreifen auf den V2X-Dienst beinhaltet; das Zertifikatsbündel unter Verwendung des öffentlichen Schlüssels des Fahrzeugs zu verschlüsseln; und das Zertifikatsbündel, wie verschlüsselt, als Reaktion auf die Dienstanforderung an das Fahrzeug zu übertragen.
-
Gemäß einer Ausführungsform ist das Verwaltungssystem ferner zu Folgendem programmiert: Empfangen einer Angabe zum Widerrufen des Zertifikats, und Senden einer Zertifikatswiderrufsliste, die das Zertifikat als widerrufen beinhaltet, an den V2X-Dienst.
-
Gemäß einer Ausführungsform wird die Angabe zum Widerrufen des Zertifikats von dem Fahrzeug empfangen.
-
Gemäß einer Ausführungsform wird die Angabe zum Widerrufen des Zertifikats von dem V2X-Dienst empfangen, wobei das Widerrufen des Zertifikats keine Auswirkungen auf andere Paare aus öffentlichem/privatem Schlüssel des Dienstes für andere V2X-Dienste hat.
-
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren zur sicheren Dienstregistrierung Folgendes: Einrichten einer sicheren Verbindung zwischen einem Fahrzeug und einem Verwaltungssystem; Senden einer Dienstanforderung zum Zugreifen auf einen Fahrzeug-zu-Allem-Dienst (V2X-Dienst) an das Verwaltungssystem, wobei die Dienstanforderung einen öffentlichen Schlüssel des Fahrzeugs eines Paares aus öffentlichem/privatem Schlüssel des Fahrzeugs beinhaltet; Empfangen eines Zertifikatsbündels von dem Verwaltungssystem, das unter Verwendung des öffentlichen Schlüssels des Fahrzeugs verschlüsselt ist, wobei das Zertifikatsbündel ein Paar aus öffentlichem/privatem Schlüssel des Dienstes und ein Zertifikat zum Zugreifen auf den V2X-Dienst beinhaltet; Entschlüsseln des Zertifikatsbündels unter Verwendung eines privaten Schlüssels des Fahrzeugs, der dem öffentlichen Schlüssel des Fahrzeugs entspricht; und Nutzen des Paares aus öffentlichem/privatem Schlüssel des Dienstes und des Zertifikats, um auf den V2X-Dienst zuzugreifen.
-
In einem Aspekt der Erfindung ist das Paar aus öffentlichem/privatem Schlüssel des Fahrzeugs spezifisch für den V2X-Dienst, und ferner umfassend Generieren des dienstspezifischen öffentlichen Schlüssels des Fahrzeugs und des dienstspezifischen privaten Schlüssels des Fahrzeugs unter Verwendung eines Dienstidentitätsschlüsselzuordnungsmoduls.
-
In einem Aspekt der Erfindung beinhaltet das Verfahren Folgendes: Generieren von V2X-Nachrichtennutzdaten zum Abgeben an den V2X-Dienst; Signieren der V2X-Nachrichtennutzdaten unter Verwendung des privaten Schlüssels des Dienstes; und Senden der V2X-Nachrichtennutzdaten, wie signiert, an den V2X-Dienst.
-
In einem Aspekt der Erfindung beinhaltet das Verfahren Einbeziehen des Zertifikatsbündels und des öffentlichen Schlüssels des Fahrzeugs in die V2X-Nachrichtennutzdaten.
-
In einem Aspekt der Erfindung ist der V2X-Dienst eine mautpflichtige Fahrbahn.
-
In einem Aspekt der Erfindung ist der V2X-Dienst ein Händler.
-
In einem Aspekt der Erfindung ist der V2X-Dienst ein Parken für das Fahrzeug.
-
In einem Aspekt der Erfindung beinhaltet das Verfahren Folgendes: Vorbereiten des Zertifikatsbündels, welches das Paar aus öffentlichem/privatem Schlüssel des Dienstes und das Zertifikat zum Zugreifen auf den V2X-Dienst beinhaltet, durch das Verwaltungssystem; Verschlüsseln des Zertifikatsbündels unter Verwendung des öffentlichen Schlüssels des Fahrzeugs; und Übertragen des Zertifikatsbündels, wie verschlüsselt, als Reaktion auf die Dienstanforderung an das Fahrzeug.
-
In einem Aspekt der Erfindung beinhaltet das Verfahren Folgendes: Empfangen einer Angabe zum Widerrufen des Zertifikats an dem Verwaltungssystem; und Senden einer Zertifikatswiderrufsliste, die das Zertifikat als widerrufen beinhaltet, von dem Verwaltungssystem an den V2X-Dienst, wobei das Widerrufen des Zertifikats keine Auswirkungen auf andere Paare aus öffentlichem/privatem Schlüssel des Dienstes für andere V2X-Dienste hat.
