DE102020121805A1 - Sichern der fahrzeugprivatsphäre in einer fahrinfrastruktur - Google Patents

Sichern der fahrzeugprivatsphäre in einer fahrinfrastruktur Download PDF

Info

Publication number
DE102020121805A1
DE102020121805A1 DE102020121805.2A DE102020121805A DE102020121805A1 DE 102020121805 A1 DE102020121805 A1 DE 102020121805A1 DE 102020121805 A DE102020121805 A DE 102020121805A DE 102020121805 A1 DE102020121805 A1 DE 102020121805A1
Authority
DE
Germany
Prior art keywords
vehicle
group
infrastructure
driving infrastructure
attachment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020121805.2A
Other languages
English (en)
Inventor
Rafael Rosales
Liuyang Lily Yang
Xiruo Liu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102020121805A1 publication Critical patent/DE102020121805A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Abstract

Systeme und Techniken zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur werden hierin beschrieben. Ein Fahrzeug kann einen Gruppenidentifikation- (ID-) Herausgeber kontaktieren, um sich zu registrieren. Eine Gruppen-ID kann von dem Gruppen-ID-Herausgeber empfangen werden, um die Aufnahme als ein Mitglied anzuzeigen. Das Fahrzeug kann dann die Fahrinfrastruktur kontaktieren zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug zu identifizieren. Ansprechend darauf empfängt das Fahrzeug eine Anbringungs-ID von der Fahrinfrastruktur. Hier wird die Anbringungs-ID zum Sichern der Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur verwendet.

Description

  • TECHNISCHES GEBIET
  • Die hierin beschriebenen Ausführungsbeispiele beziehen sich im Allgemeinen auf selbstfahrende oder unterstütztes-Fahren-Fahrzeug-Technologien und im Besonderen auf das Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur.
  • HINTERGRUND
  • Vehicle-to-Everything (V2X) ist ein Kommunikationsmodell für den Informationsaustausch zwischen Entitäten in Fahrzeugumgebungen. Solche Entitäten können unter anderem Fahrzeuge, Straßenrandeinheiten (RSUs; road side units) oder andere Infrastrukturelemente und Fußgänger (z.B. über getragene oder mitgeführte mobile Geräte) umfassen. V2X-Informationen können Daten erweitern, die durch Onboard-Sensoren (z. B. Radar, Lidar, Ultraschall, Kamera, usw.) gesammelt werden, die für autonomes Fahren verwendet werden, um Fahrzeuge zu befähigen, Umgebungen, die über die Reichweite der Onboard-Sensoren hinausgehen, besser zu modellieren.
  • Aufgrund der oft wichtigen Abhängigkeit von V2X-Daten können einige Schutzmaßnahmen eingesetzt werden, um sicherzustellen, dass falsche V2X-Daten (z.B. durch eine böswillige Entität als Teil eines Angriffs bereitgestellt) durch das Fahrzeug nicht akzeptiert werden. Um die Authentizität zu gewährleisten und V2X-Nachrichten zu vertrauen, wird im Allgemeinen ein Vertrauensanker (root of trust) durch eine Öffentlicher-Schlüssel-Infrastruktur- (PKI; Public Key Infrastructure) Implementierung eingerichtet. Hierbei wird die wahre Identität der Fahrzeuge authentifiziert und dann werden die Fahrzeuge mit Pseudonymzertifikaten oder Authentifizierungstickets bereitgestellt, um ihre Identität während der Interaktion mit anderen Entitäten auf der Straße zu schützen. Somit kann die Infrastruktur zwar immer die Quelle der Nachrichten identifizieren, und andere Entitäten können in der Lage sein zu verifizieren, welches Pseudonym Informationen gesendet hat, aber die tatsächliche Identität eines gegebenen Fahrzeugs kann vor den anderen Entitäten verschleiert werden.
  • Figurenliste
  • In den Zeichnungen, die nicht zwingend maßstabsgetreu sind, können gleiche Bezugszeichen ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Bezugszeichen, die unterschiedliche Buchstabenendungen aufweisen, können unterschiedliche Beispiele ähnlicher Komponenten repräsentieren. Die Zeichnungen stellen im Allgemeinen beispielhaft, aber nicht einschränkend, verschiedene, in dem vorliegenden Dokument erörterte Ausführungsbeispiele dar.
    • 1 stellt ein Beispiel einer Umgebung mit einem System, um die Fahrzeugprivatsphäre in einer Fahrinfrastruktur zu sichern, gemäß einem Ausführungsbeispiel dar.
    • 2 stellt ein Beispiel einer Fahrzeugregistrierung gemäß einem Ausführungsbeispiel dar.
    • 3 stellt ein Beispiel einer Fahrzeuganbringung (vehicle attachment) an eine Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar.
    • 4 ist ein Blockdiagramm von Beispielen von Straßenrandnetzwerkelementen gemäß einem Ausführungsbeispiel.
    • 5 stellt ein Beispiel eines Anwendungsfalls gemäß einem Ausführungsbeispiel dar, bei dem eine Fahrinfrastruktur ein Fahrzeug durch ein Pseudonym anspricht.
    • 6 stellt ein Beispiel von physischen Elementen in einem System, um die Fahrzeugprivatsphäre in einer Fahrinfrastruktur zu sichern, gemäß einem Ausführungsbeispiel dar.
    • 7 stellt ein Flussdiagramm einer vertrauenswürdigen Authentifizierungsentität während einer Fahrzeugmitgliedschaft gemäß einem Ausführungsbeispiel dar.
    • 8 stellt ein Diagramm von Nachrichtenflüssen zwischen einem Fahrzeug und einer vertrauenswürdigen Authentifizierungsentität während einer Mitgliedschaftsregistrierung gemäß einem Ausführungsbeispiel dar.
    • 9 stellt ein Diagramm von Nachrichtenflüssen zwischen einem Fahrzeug, einer Straßenrandeinheit und einer vertrauenswürdigen Authentifizierungsentität während einer Fahrzeuganbringung an die Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar.
    • 10A-10B stellen ein Flussdiagramm einer vertrauenswürdigen Authentifizierungsentität und einer Fahrinfrastruktur während der Fahrzeuganbringung an die Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar.
    • 11 stellt ein Flussdiagramm eines Fahrzeugs während der Mitgliedschaftsregistrierung bei einer vertrauenswürdigen Authentifizierungsentität und Anbringung bei einer Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar.
    • 12 stellt ein Diagramm von Nachrichtenflüssen zwischen einem Fahrzeug, einer Straßenrandeinheit und einer vertrauenswürdigen Authentifizierungsentität während einer Fahrzeugüberwachung auf böswillige Aktivität gemäß einem Ausführungsbeispiel dar.
    • 13 ist ein Beispiel eines Verfahrens zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur gemäß einem Ausführungsbeispiel.
    • 14 ist ein Blockdiagramm, das ein Beispiel einer Maschine darstellt, auf der ein oder mehrere Ausführungsbeispiele implementiert werden können.
  • DETAILLIERTE BESCHREIBUNG
  • Einige V2X-Implementierungen erlauben eine mögliche Offenlegung der Identität des Fahrzeugs (und damit vielleicht der Identität des Fahrers). Insbesondere weil die Pseudonyme des Fahrzeugs durch die Fahrinfrastruktur mit der tatsächlichen Identität verknüpft werden können, sind die Betreiber der Fahrinfrastruktur in der Lage, die wahre Identität irgendeines gegebenen Fahrzeugs offenzulegen. Eine solche Entdeckung kann es z.B. Fahrinfrastrukturoperationen ermöglichen, Fahrzeugbewegungen zu verfolgen oder die Fahrzeugidentitäten an Dritte zu verkaufen. Somit wird die Privatsphäre zu einem Anliegen für die Annahme der V2X-Technologie bei Fahrinfrastrukturen durch Verbraucher.
  • Bestehende und vorgeschlagene Ansätze für V2X-Kommunikationen, wie z.B. die 802.11-basierte dedizierte Nahbereichskommunikation (DSRC; dedicated shortrange communication) des Institute of Electrical and Electronics Engineers (IEEE) und die zellular basierte V2X-Kommunikation (4G LTE und 5G) stellen unterschiedliche Niveaus des Schutzes der Privatsphäre für die Identität der teilnehmenden Fahrzeuge bereit. Bei DSRC werden den Fahrzeugen zeitlich wechselnde Pseudonymzertifikate, genannt Authentifizierungstickets, zugeordnet, um ihre Identität während der V2X-Kommunikationen zu verbergen. Die Identität des Fahrzeugs wird jedoch in der Registrierungsphase offenbart. Im „Evolved Packet System - Authentication and Key Agreement“- (Authentifizierungs- und Schlüssel-Vereinbarungs-) Protokoll (EPS AKA) von LTE wird die internationale Identität eines mobilen Teilnehmers (IMSI; International mobile subscriber identity) des Benutzers immer unverschlüsselt - und damit öffentlich exponiert - zum Anbringen an das Netzwerk gesendet. Das 5G Authenticated Key Agreement- (Authentifiziertes Schlüssel-Vereinbarungs-) Protokoll (5G-AKA) hingegen verschlüsselt diese Informationen vor der Übertragung, indem es den öffentlichen Schlüssel des Heimnetzwerks (HN; home network) verwendet, der während der Registrierung der Teilnehmer-Identitätsmodul- (SIM-; Subscriber Identity Module) Karte bereitgestellt wird. Die Fahrzeugidentität wird der Authentifizierungsstelle während der erstmaligen Anbringung an das Netzwerk jedoch weiterhin offenbart.
  • In der wissenschaftlichen Gemeinschaft sind Verbesserungen des Pseudonym-Ansatzes vorgeschlagen worden, um die Angriffsfläche für potenzielle Fahrzeugidentitäts-Lecks zu begrenzen. Es wurde beispielsweise vorgeschlagen, dass Gruppensignaturen verwendet werden, um zu ermöglichen, dass Fahrzeuge ihre eigenen Pseudonyme erzeugen und zertifizieren. Außerdem wurde vorgeschlagen, „Misch-Zonen“ zu verwenden, um Pseudonyme an Kreuzungen zwischen Fahrzeugen zu tauschen. Ferner wurde im Zusammenhang mit dem Internet der Dinge (Internet of Things; IoT) das von der Intel Corporation vorgeschlagene „Secure Device Onboarding“ (SDO; sicheres Vorrichtungs-Onboarding) verwendet, um Enhanced Privacy IDs (EPIDs; Erweiterte Datenschutz-IDs) - die während der Herstellung bereitgestellt werden - zu nutzen, um die automatische Anbringung von IoT-Vorrichtungen an ihre jeweiligen Dienstanbieter zu ermöglichen, ohne ihre Identität preiszugeben.
  • Diese Ansätze zur Zusicherung der Fahrzeugprivatsphäre (vehicle privacy assurance) weisen einige Probleme auf. Zum Beispiel stellen DSRC V2X-Ansätze oft Pseudonymität statt Anonymität bereit, wie definiert in der Internationalen Organisation für Normung (ISO; International Organization for Standardization) und der Internationalen Elektrotechnischen Kommission (IEC; International Electrotechnical Commission) (ISO/IEC) 15408-2 „Informationstechnologie - Sicherheitstechniken - Bewertungskriterien für IT-Sicherheit - Teil 2: Sicherheitsfunktionale Komponenten“. Dies bedeutet, dass bei Pseudonymität die zentralen Stellen, die die Pseudonyme bereitstellen, die Fähigkeit haben, die wahre Identität eines Fahrzeugs offenzulegen. Das PKI-System in der US-DSRC versucht, den einzelnen Ausfallpunkt (single-point-failure) der Stelle für Insider-Angriffe zu vermeiden, indem es zwei Stellen für die Verknüpfung von Pseudonymen verwendet, aber ein Angriff, der die Privatsphäre offenbart, ist bei beiden Stellen immer noch möglich.
  • Zellular basiertes V2X schützt die Fahrzeugidentität nicht vor Enthüllung, da das Fahrzeug immer dem Heimnetzwerk zum legalen Abfangen offengelegt wird. Somit stellen die derzeitigen infrastrukturgestützten Ansätze unter Verwendung von zellularem V2X eine doppelte Angriffsfläche bereit, um die Identität des Fahrzeugs aufzudecken: 1) der Mobilfunkbetreiber; und 2) der Anbieter der Infrastrukturdienste.
  • Die vorgeschlagene gruppenbasierte Authentifizierung, die oben erwähnt wurde, verwendet ein Gruppensignaturschema, das es dem Gruppenmanager ermöglicht, die Identität des verwendeten privaten Schlüssels offenzulegen. Ferner wird es für Ad-hoc-Fahrzeugnetzwerke (VANETs; Vehicular Ad-hoc Networks) vorgeschlagen, was die folgenden Herausforderungen für seine praktische Implementierung darstellt: 1) die Wahl eines Gruppenanführers ist in Fahrzeug-zu-Fahrzeug- (V2V-) Ad-hoc-Netzwerken schwierig; und 2) die Gruppenbildung ist aufgrund der hohen Mobilität und der Veränderungen der Netzwerktopologie eine Herausforderung. Eine weitere Herausforderung bei der Verwendung von gruppenbasierten Signaturen, wie z.B. EPID im V2X-Kontext, ist der erhöhte Rechenaufwand. Die anonyme Identitätsbescheinigung in Ad-hoc-V2X ist aufgrund der Erzeugung von Hochfrequenz-Authentifizierungssignaturen oft zu rechenintensiv. Ferner ist eine direkte Anwendung von SDO bei infrastrukturgestütztem V2X oft nicht ausreichend, da die Mitgliedschaft von Fahrzeugen in einem Straßenrand-Infrastrukturnetzwerk dynamisch ist. Im Gegensatz dazu wird erwartet, dass IoT-Vorrichtungen während ihres Lebenszyklus einen einzigen statischen privaten EPID-Schlüssel haben, wohingegen Fahrzeuge mit privaten EPID-Schlüsseln auf Anforderung (on-demand) bereitgestellt sein sollten. Auch während die privaten EPID-Schlüssel an registrierte beitretende Fahrzeuge Anonymität bereitstellen können, sind die Informationen über den zurückgelegten Weg des Fahrzeugs nicht vor externen Beobachtern geschützt, die möglicherweise versuchen, sie zu verfolgen. Die Verwendung von Zertifikatspseudonymen zur Authentifizierung von übertragenen Nachrichten nach der erstmaligen Anbringung ist für V2X-Nachrichten immer noch nützlich, um sehr enge Latenzzeitanforderungen von Sicherheitsanwendungen zu erfüllen, die durch die aufwendige Berechnung von EPID-basierten Signaturen möglicherweise verletzt werden.
  • Um diese Bedenken anzugehen, wird hierin ein System beschrieben, bei dem sich ein Fahrzeug bei einer vertrauenswürdigen Authentifizierungsentität (z. B. Anbieter, Gruppe, Partei, usw.) registriert, um eine Gruppenidentifikation, wie z. B. einen privaten EPID-Schlüssel, zu empfangen. Die Gruppen-ID wird dann während der Fahrzeuganbringung an eine Fahrinfrastruktur verwendet, um Pseudonymzertifikate zu empfangen, die bei Interaktion mit der Fahrzeuginfrastruktur oder anderen Fahrzeugen zu verwenden sind. Bei einem Beispiel werden die Pseudonymzertifikate periodisch aktualisiert, um eine anhaltende Anonymität zu gewährleisten. Ein solches System stellt einen einzigartigen und wirklich anonymen Fahrzeugidentifizierer bereit, während es die Privatsphäre der Identität des Fahrzeugs sicherstellt, indem es die dynamische Mitgliedschaftsregistrierung eines Fahrzeugs bei der Fahrinfrastruktur von der anfänglichen Anbringungsprozedur, um auf die Infrastrukturdienste unter Verwendung der Gruppensignaturen zuzugreifen, entkoppelt. Bei Verwendung einer Gruppen-ID wie z.B. einer EPID kann die Straßenrand-Infrastruktur individualisierte Dienste bereitstellen, die Bewegung des Fahrzeugs verfolgen oder den Zugriff von sich falsch verhaltenden Fahrzeugen widerrufen, ohne dass die wahre Identität des Fahrzeugs jemals bekannt wird. Zusätzliche Beispiele und Details werden nachfolgend bereitgestellt.
  • 1 stellt ein Beispiel einer Umgebung mit einem System, um die Fahrzeugprivatsphäre in einer Fahrinfrastruktur zu sichern, gemäß einem Ausführungsbeispiel dar. Wie dargestellt, umfasst die Umgebung eine vertrauenswürdige Authentifizierungsentität 110, ein Fahrzeug 105 und eine Fahrinfrastruktur, die eine RSU 115 als Teil eines Straßenrandnetzwerks und einen Server 120 zur Koordinierung zwischen den RSUs umfasst.
  • Das Fahrzeug 105 umfasst eine Verarbeitungsschaltungsanordnung, die ausgebildet ist (z.B. fest verdrahtet oder über Software), um eine Vielzahl von Operationen in Bezug auf die zweistufige Mitgliedschafts- und Anbringungs-Prozedur durchzuführen. Somit ist das Fahrzeug 105 ausgebildet, um einen Gruppen-ID-Herausgeber (z. B. die vertrauenswürdige Authentifizierungsentität 110) zu kontaktieren, um das Fahrzeug als ein Mitglied bei der Fahrinfrastruktur zu registrieren. Wenn die Registrierung vollständig ist, ermöglicht sie dem Fahrzeug den Versuch einer Anbringung, wenn es z.B. in eine Fahrbahn einfährt, über welche die Fahrinfrastruktur ein Straßenrandnetzwerk unterhält.
  • Bei einem Beispiel umfasst das Kontaktieren des Gruppen-ID-Herausgebers das Verwenden einer Fahrzeug-ID zur Registrierung als das Mitglied. Hierbei kann die Fahrzeug-ID eine Seriennummer, eine Fahrzeug-Identifikationsnummer (VIN; vehicle identification number) oder ein anderer einzigartiger Identifizierer sein, der bei Fahrzeugen üblich ist. Bei einem Beispiel kann eine sichere Fahrzeug-ID, wie z.B. ein kryptographischer privater Schlüssel, der zum Zeitpunkt der Herstellung in die Verarbeitungsschaltungsanordnung des Fahrzeugs installiert wurde, verwendet werden. Eine solche kryptographische Identität kann schwieriger zu fälschen sein, wenn eine böswillige Entität wünschen sollte, ein legitimes Fahrzeug zu täuschen.
  • Die vertrauenswürdige Authentifizierungsentität 110 kann eine Anzahl von Prüfungen der Mitgliedschaftsanforderung durch das Fahrzeug 105 durchführen. Beispielsweise kann die vertrauenswürdige Authentifizierungsentität 110 eine Zählung, oder Häufigkeit, von Mitgliedschaftsanforderungen aufrechterhalten, um zu bestimmen, ob sich das Fahrzeug 105 wie andere Fahrzeuge verhält (z. B. gemäß statistischen Modellen des Fahrzeugverhaltens) oder nicht. Wenn das Fahrzeug 105 ein Ausreißer zu sein scheint, kann die Mitgliedschaft verweigert werden. Unter der Annahme, dass die Mitgliedschaft akzeptiert wird, kann die vertrauenswürdige Authentifizierungsentität 110 jedoch eine Gruppen-ID 125 erzeugen und sie an das Fahrzeug 105 liefern. Somit ist das Fahrzeug 105 ausgebildet, um die Gruppen-ID 125 vom Gruppen-ID-Herausgeber zu empfangen, um die Aufnahme als ein Mitglied anzuzeigen.
  • Bei einem Beispiel umfasst die Gruppen-ID 125 ein asymmetrisches Schlüsselpaar. Hierbei ist ein privater Schlüssel des Schlüsselpaares für das Fahrzeug 105 einzigartig, und ein öffentlicher Schlüssel des Schlüsselpaares ist mehreren privaten Schlüsseln gemeinsam, umfassend den privaten Schlüssel, der für das Fahrzeug 105 einzigartig ist. Bei einem Beispiel ist die Gruppen-ID 125 einfach der private Schlüssel des Paares. Ein solcher privater Schlüssel kann immer noch verwendet werden, um die Gruppensignatur für spätere Anbringungs-Operationen bereitzustellen. Bei einem Beispiel entspricht die Gruppen-ID 125 einer Enhanced Privacy ID (EPID). EPID - und ähnliche Gruppen-ID-Systeme - ermöglichen es der vertrauenswürdigen Authentifizierungsentität 110, eine Signatur mit dem spezifischen privaten Schlüssel, der für das Fahrzeug 105 ausgegeben wurde, abzugleichen. Dies kann eine stabilere Überwachung verdächtiger Fahrzeuge und die Fähigkeit für die vertrauenswürdige Authentifizierungsentität 110 ermöglichen, Fahrzeuge auf eine schwarze Liste zu setzen, selbst wenn die Gruppensignatur der Fahrinfrastruktur nicht irgendwelche Einzelheiten über die Identität des Fahrzeugs bereitstellt.
  • Sobald das Fahrzeug 105 die Gruppen-ID 125 vorliegend hat, ist das Fahrzeug 105 ausgebildet, die Fahrinfrastruktur (z. B. Server 120 über die RSU 115) zu kontaktieren, zum Anbringen an die Fahrinfrastruktur. Hier verwendet das Fahrzeug 105 die Gruppen-ID 125, um das Fahrzeug 105 bei der Fahrinfrastruktur 115, 120 zu identifizieren. Die Fahrinfrastruktur 115, 120 kann dann die vertrauenswürdige Authentifizierungsentität 110 kontaktieren, um zu ermitteln, ob das Fahrzeug 105 ein Mitglied ist oder nicht. Die Fahrinfrastruktur 115, 120 kann auch ermitteln, ob das Fahrzeug 105 unter anderem beispielsweise wegen böswilligen Datenverhaltens (z.B. Senden falscher Daten) oder Fahrverhaltens (z.B. (unberechenbar Fahren) auf einer schwarzen Liste steht oder nicht. Wenn das Fahrzeug 105 nicht Mitglied ist oder auf einer schwarzen Liste steht, kann die Fahrinfrastruktur 115, 120 das Fahrzeug 105 über diese Bedingung benachrichtigen oder einfach nicht antworten. Eine Nichtbeantwortung kann Infrastrukturressourcen einsparen und auch einen Angriff auf die Infrastruktur verzögern.
  • Wenn jedoch die Fahrinfrastruktur 115, 120 die Anbringung des Fahrzeugs 105 erlaubt, erzeugt die Fahrinfrastruktur 115, 120 eine Anbringungs-ID 130 für das Fahrzeug 105. Somit ist das Fahrzeug 105 ausgebildet, um die Anbringungs-ID 130 von der Fahrinfrastruktur zu empfangen. Wie bereits an anderer Stelle erwähnt, wird die Anbringungs-ID 130 verwendet, um Kommunikationen zwischen dem Fahrzeug 105 und der Fahrinfrastruktur 115, 120 unter Beibehaltung der Anonymität für die wahre Identität des Fahrzeugs 105 zu sichern. Die Elemente der Fahrinfrastruktur 115, 120, die diese Anbringungs-ID 130 für das Fahrzeug 105 verwenden können, umfassen die RSU 115, den Server 120 und andere Fahrzeuge, die an einer V2X-Fahrinfrastruktur teilnehmen.
  • Bei einem Beispiel ist die Anbringungs-ID 130 eine Pseudonym-ID für das Fahrzeug. Dieses Pseudonym kann auch Zertifikate und öffentlich-private Schlüsselpaare für das Fahrzeug 105 umfassen. Bei einem Beispiel kann das Fahrzeug 105 periodisch eine neue Pseudonym-ID erhalten, die sich von einer früheren Pseudonym-ID für das Fahrzeug 105 von der Fahrinfrastruktur unterscheidet. Das periodische Austauschen der Anbringungs-ID 130 hilft, eine Fahrzeugverfolgung durch Dritte zu verhindern.
  • 2 stellt ein Beispiel einer Fahrzeugregistrierung gemäß einem Ausführungsbeispiel dar. Diese Registrierung kann als eine Mitgliedschaftsregistrierungs-Stufe bezeichnet werden. Hierbei kann die wahre Identität des Fahrzeugs (z.B. Fahrzeug-ID, wie z.B. eine Fahrzeug-Identifikationsnummer (VIN)) für die Registrierung verwendet werden. Das Ergebnis dieser Stufe ist die Bereitstellung einer Gruppen-ID, wie z.B. eines privaten EPID-Schlüssels, den das Fahrzeug für die künftige anonyme Authentifizierung bei einer Fahrinfrastruktur verwenden kann.
  • Wie dargestellt, beantragt ein Fahrzeug, bevor es versucht, an eine Fahrinfrastruktur anzubringen, ein Teil des Infrastrukturnetzwerks zu sein, indem es eine vertrauenswürdige ID (z.B. Fahrzeug-ID) zur Authentifizierung an eine vertrauenswürdige Authentifizierungspartei bereitstellt (Nachricht 205). Ein sicherer (z.B. verschlüsselter) Kanal wird eingerichtet (Nachrichtenaustausch 210). Dieser Kanal wird verwendet, um eine Gruppen-ID an das Fahrzeug bereitzustellen (Nachricht 215). Diese Gruppen-ID kann dann durch das Fahrzeug verwendet werden, wenn es versucht, sich an die Fahrinfrastruktur (z.B. Straßenrandnetzwerk) anzubringen. Bei einem Beispiel kann ein SDO unter Verwendung einer fahrzeugspezifischen EPID als die vertrauenswürdige Fahrzeug-ID verwendet werden.
  • 3 stellt ein Beispiel einer Fahrzeuganbringung an eine Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar. Nachdem die Gruppen-ID bei der Mitgliedschaftsregistrierung empfangen wurde, kann das Fahrzeug anonym anfordern, dem Fahrinfrastrukturnetzwerk unter Verwendung seiner Gruppen-ID beizutreten. Aufgrund des Wesens von Gruppen-IDs ist die Fahrinfrastruktur darauf beschränkt, in der Lage zu sein zu verifizieren, dass die Signatur zu einem der Schlüssel der Gruppenmitglieder gehört, aber nicht zu welchem bestimmten Mitglied der Gruppe. Die Fahrinfrastruktur kann nach Verifizierung der Mitgliedschaft des Fahrzeugs in der Gruppe an das Fahrzeug ein anfängliches Pseudonym für zukünftige Kommunikations-Handshakes bereitstellen.
  • Wie dargestellt, fährt diese Anbringungsstufe mit der Erzeugung, durch das Fahrzeug, einer Gruppensignatur unter Verwendung des privaten Gruppenschlüssels fort (Operation 303). Das Fahrzeug kann dann z.B. bei einer RSU (Nachricht 305) die Anbringung an die Fahrinfrastruktur anfordern. Es kann ein sicherer Kanal zwischen dem Fahrzeug und der Fahrinfrastruktur eingerichtet werden (Nachrichtenaustausch 310), wobei die Fahrinfrastruktur die Gruppensignatur zur anonymen Authentifizierung des Fahrzeugs verwendet. Die Fahrinfrastruktur stellt dann eine Pseudonym-ID und einen Satz von Pseudonym-Zertifikaten für zukünftige Kommunikations-Handshakes bereit (Nachricht 315). Nach der anfänglichen Anbringungsprozedur kann das Fahrzeug in der Lage sein, seine Privatsphäre weiter zu schützen, indem es seine Pseudonym-ID und Zertifikate verwendet und ändert. Wie vorangehend erwähnt wurde, kann die Pseudonym-Identität nicht der wahren Identität des Fahrzeugs zugeordnet werden, da die Fahrinfrastruktur die wahre Identität des Fahrzeugs nicht kennt, da sie der Fahrinfrastruktur unbekannt ist.
  • 4 ist ein Blockdiagramm von Beispielen von Straßenrandnetzwerkelementen gemäß einem Ausführungsbeispiel. Kollaboratives automatisiertes Fahren ermöglicht die Erweiterung der Fähigkeiten und der Sicherheit von automatisierten Fahrzeugen durch den umgehenden Austausch von Informationen über Fahrabsichten oder Umgebungssituationen. Dies ermöglicht es den Fahrzeugen, besser informierte Fahrentscheidungen zu treffen. Ad-hoc-Fahrzeugnetzwerke (z.B. VANETs) sind jedoch oft nicht in der Lage, ein Mindestmaß an Sichtreichweite (visibility range) über die fahrzeugeigenen Sensoren hinaus zu garantieren, somit stellen VANETs im Allgemeinen keine geeignete Lösung für eine hochzuverlässige Kommunikation von Daten über Umgebungsbedingungen bereit. Fahrinfrastruktursysteme können automatisierten Fahrzeugen auf kosteneffiziente Weise verlässlichere Umgebungsinformationen bereitstellen - was ein wichtiger Aspekt der Fahrzeugsicherheit sein kann - und können die Sichtreichweite des Fahrzeugs über die Grenzen der Onboard-Sensoren hinaus erweitern.
  • Die hier dargestellten Komponenten sind Beispiele eines Straßenrand-Infrastruktursystems, das ein physisches Straßenrandnetzwerk mit Sensor, Kommunikationsantennen, CPUs und einer Backbone-Kommunikation zur Verbindung dieser Elemente definiert. Diese physischen Ressourcen ermöglichen der Fahrinfrastruktur: 1) die Überwachung der Straßenumgebung durch Straßenrandsensoren; 2) die Bereitstellung von Hochperformance-Rechenressourcen mit geringer Latenz für die Verarbeitung von Daten; oder 3) die Verteilung von Umgebungsinformationen an oder von Fahrzeugen durch drahtlose Kommunikationen.
  • 5 stellt ein Beispiel eines Anwendungsfalls gemäß einem Ausführungsbeispiel dar, bei dem eine Fahrinfrastruktur ein Fahrzeug durch ein Pseudonym anspricht. In diesem Szenario detektiert ein Fahrinfrastuktursensor (z.B. Radar, dargestellt als gestrichelte Dreiecke) an einer RSU 510 die überhöhte Geschwindigkeit eines Fahrzeugs 520, während sich das Fahrzeug 520 dem Mitgliedsfahrzeug 525 nähert. Wie dargestellt, wurde dem Mitgliedsfahrzeug 525 eine Pseudonym-ID von ‚Bob‘ bereitgestellt. Nach dem Erkennen der Gefahr, die von dem zu schnell fahrenden Fahrzeug 520 für das Mitgliedsfahrzeug 525 ausgeht, spricht die Infrastruktur - z.B. Server 505 über einen entfernten Funkkopf (remote radio head) 515 - das Mitgliedsfahrzeug 525 mit einer Warnmeldung 530 unter Verwendung seines Pseudonyms ‚Bob‘ an. Da das Mitgliedsfahrzeug 525 eine Gruppen-ID für die Anbringung an die Fahrinfrastruktur verwendete, kennt hier keine Entität, nicht einmal die Fahrinfrastruktur, die wahre Identität des Mitgliedsfahrzeugs 525 mit dem Pseudonym ‚Bob‘.
  • 6 stellt ein Beispiel von physischen Elementen in einem System, um die Fahrzeugprivatsphäre in einer Fahrinfrastruktur zu sichern, gemäß einem Ausführungsbeispiel dar. Die primären physischen Entitäten sind ein Fahrzeug 605, eine Fahrinfrastruktureinheit 610 (z.B. RSU) und eine vertrauenswürdige Authentifizierungsentität 615. Wie dargestellt, umfassen sowohl das Fahrzeug 605 als auch die RSU 610 Sensor-, Rechen- und Speicherungs-Ressourcen.
  • Im Stadt- oder Autobahnbetrieb kann die RSU 610 ihre Speicherungs-, Rechen-, Erfassungs- oder drahtlosen Kommunikations-Ressourcen verwenden, um dem Fahrzeug 605 Dienste für Sicherheits- oder Verkehrsinformationsanwendungen bereitzustellen. Bei einem Beispiel kommuniziert die RSU 610 über einen sicheren Kanal mit der vertrauenswürdigen Authentifizierungsentität 615, um die Ausgabe von öffentlichen und privaten Gruppenschlüsseln zu delegieren sowie Gruppen-IDs oder Widerrufslisten zu führen.
  • Die RSU 610 ist ausgebildet, um die Bewegung von Fahrzeugen entlang der Straße zu überwachen und verfolgen, z.B. unter Verwendung von Radar oder anderen Sensoren. Fahrzeuge, die mit Rechen- und Kommunikationsressourcen bereitgestellt sind, wie z.B. das Fahrzeug 605, können ausgebildet sein, um mit der Straßenrand-Infrastruktur zu kommunizieren oder zusammenzuarbeiten.
  • Die Kommunikation zwischen der vertrauenswürdigen Authentifizierungsentität 615 und dem Fahrzeug 605 kann z.B. ganz oder teilweise über einen Cloud-basierten Kommunikationslink erfolgen. Dieser Link kann durch das Fahrzeug 605 verwendet werden, um die Gruppen-ID zu erhalten, die beim Kommunizieren mit der RSU 610 verwendet wird. Der Cloud-basierte Link kann ein zellulares Netzwerk verwenden, um die physische Verbindung vom Fahrzeug 605 zum größeren Cloud-Netzwerk einzurichten.
  • Die Kommunikation zwischen der RSU 610 und dem Fahrzeug 605 kann über einen einzelnen oder mehrere Over-the-Air-Links zwischen der RSU 610 und dem Fahrzeug 605 erfolgen. Hier kann davon ausgegangen werden, dass die teilnehmenden Fahrzeuge bereits mit einem vertrauenswürdigen einzigartigen Fahrzeugidentifizierer (vID) für die Zwecke der Mitgliedschaftsregistrierung bereitgestellt wurden. Diese vID kann beispielsweise eine zellulare SIM-Karten-ID, wie z.B. die internationale Identität eines mobilen Teilnehmers (International Mobile Subscriber Identity; IMSI) oder eine VIN sein.
  • Einige Dienste, die durch die Fahrinfrastruktur bereitgestellt werden, können nach weiteren Fahrzeugdaten fragen, wie z. B. Hardware-Fähigkeiten, Präferenzen usw., die die Identität des Fahrzeugs aufdecken könnten. Das Fahrzeug müsste dies jedoch akzeptieren oder ablehnen.
  • 7 stellt ein Flussdiagramm einer vertrauenswürdigen Authentifizierungsentität während einer Fahrzeugmitgliedschaft gemäß einem Ausführungsbeispiel dar. Hier wird die Mitgliedschaftsregistrierung zwischen Fahrzeugen und der vertrauenswürdigen Authentifizierungsentität durchgeführt. Der Prozessablauf beginnt mit der vertrauenswürdigen Authentifizierungsentität in einem Zustand, in dem sie auf Anforderungen für Fahrzeugmitgliedschaft wartet. Somit wartet die vertrauenswürdige Authentifizierungsentität auf eine Anforderung (Operation 705). Wenn eine Anforderung empfangen wird, bestimmt die vertrauenswürdige Authentifizierungsentität, ob es zu viele (z. B. gemessen durch eine Schwelle) Anforderungen von einem Fahrzeug gibt (Entscheidung 710). Falls ja, Registrieren von verdächtigem Verhalten des Fahrzeugs in der Mitgliedschaftsauthentifizierungs-Datenbank und Warten auf eine neue Anforderung (Operation 745).
  • Wenn das Fahrzeug nicht eine übermäßige Anzahl von Anforderungen hat, registriert die vertrauenswürdige Authentifizierungsentität das Fahrzeug und zeichnet die Registrierung in der Mitgliedschaftsauthentifizierungs-Datenbank auf (Operation 715). Die vertrauenswürdige Authentifizierungsentität kann dann fortfahren, einen privaten Gruppenschlüssel für das Fahrzeug zu erzeugen (Operation 720) und ihn in der Mitgliedschaftsauthentifizierungs-Datenbank zu speichern (Operation 725).
  • Die vertrauenswürdige Authentifizierungsentität kann einen sicheren Kommunikationskanal mit dem Fahrzeug einrichten (Operation 730). Sobald das Fahrzeug registriert ist und die Gruppen-ID (z. B. der private Gruppenschlüssel) und der sichere Kanal eingerichtet sind, kann die vertrauenswürdige Authentifizierungsentität die Gruppen-ID an das Fahrzeug senden (Vorgang 735) und fortfahren, auf zusätzliche Mitgliedschaftsanforderungen zu warten.
  • 8 stellt ein Diagramm von Nachrichtenflüssen zwischen einem Fahrzeug und einer vertrauenswürdigen Authentifizierungsentität (z.B. Anbieter) während einer Mitgliedschaftsregistrierung gemäß einem Ausführungsbeispiel dar. Der Ablauf beginnt damit, dass das Fahrzeug in einem Zustand 805 ist, in dem es weder ein Mitglied noch an eine Fahrinfrastruktur angebracht ist. Das Fahrzeug erzeugt eine Mitgliedschaftsanforderungsnachricht 810 an die vertrauenswürdige Authentifizierungsentität, die die Fahrzeug-vID bereitstellt. Diese Anforderung 810 kann z.B. über das Internet oder eine andere Cloud übertragen werden. Um die Fahrzeugidentität zu schützen, kann die vID über einen bereits bereitgestellten Schlüssel übertragen werden, analog zum 5G AKA-Protokoll.
  • Die vertrauenswürdige Authentifizierungsentität zeichnet die vID (Operation 815) in der Liste der Fahrzeugmitglieder auf und gibt eine neue Gruppen-ID (z. B. privater EPID-Schlüssel) aus (Operation 820). Ein sicherer Kanal 825 wird zwischen dem Fahrzeug und der vertrauenswürdigen Authentifizierungsentität eingerichtet. Dann bestätigt die vertrauenswürdige Authentifizierungsentität die Anforderung und sendet die Gruppen-ID an das Fahrzeug (Nachricht 830). Zu diesem Zeitpunkt ist das Fahrzeug nun ein Mitglied des Netzwerks, aber noch nicht angebracht (Zustand 835).
  • 9 stellt ein Diagramm von Nachrichtenflüssen zwischen einem Fahrzeug, einer Straßenrandeinheit und einer vertrauenswürdigen Authentifizierungsentität während einer Fahrzeuganbringung an die Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar. Das Ergebnis dieser Anbringung ist die Bereitstellung einer Pseudonym-ID und von Pseudonymzertifikaten von der Fahrinfrastruktur an das Fahrzeug, die nicht mit der wahren Identität des Fahrzeugs verknüpft sind.
  • Das Fahrzeug beginnt diese Interaktion mit einem Zustand, in dem es ein Mitglied, aber noch nicht an die Fahrinfrastruktur angebracht ist. Das Fahrzeug ist somit bereits bei dem Fahrinfrastruktur-Netzwerk registriert worden und befindet sich physisch an einer Straße (z.B. soeben beim Beitreten oder bereits innerhalb des durch die Infrastruktur abgedeckten Sektors) und möchte die Infrastrukturdienste nutzen, erzeugt und sendet eine Anbringungsanforderung (Nachricht 910). Diese Anforderung umfasst eine Gruppensignatur, die mit der Gruppen-ID des Fahrzeugs (z.B. privater EPID-Schlüssel) erzeugt wird (Operation 905).
  • Die Fahrinfrastruktur empfängt diese Nachricht (z.B. über einen drahtlosen Link oder über die Cloud) und delegiert die Verifizierung der Signatur an die vertrauenswürdige Authentifizierungsentität (Nachricht 915). Wenn die Verifizierung erfolgreich ist, wird der Infrastruktur nun zugesichert, dass das Fahrzeug eine gültige Gruppen-ID darstellt, obwohl sie nicht identifizieren kann, welcher private Schlüssel die Nachricht signiert hat.
  • Die vertrauenswürdige Authentifizierungsentität verifiziert die Signatur (Operation 920) und prüft auch, ob die Signatur in ihrer eigenen Widerrufsliste auf eine schwarze Liste gesetzt wurde (Operation 925). Diese schwarze Liste ist eine Datenstruktur, die mit Signaturen von Fahrzeugen befüllt ist, die in der Vergangenheit böswilliges Verhalten - wie z.B. atypische Kommunikationsmuster (z.B. Flooding-(Überflutungs-) Versuche oder DoS-Angriffe), gefährliche Manöver, Übertragung falscher Informationen über die Straßenumgebung, usw. - gezeigt haben.
  • Wenn die Verifizierung erfolgreich verläuft, kommuniziert die vertrauenswürdige Authentifizierungsentität diesen Erfolg an die Fahrinfrastruktur (Nachricht 930). Die Fahrinfrastruktur kann dann den Anbringungsprozess (Operation 935) starten, bei dem eine neue zeitliche (z. B. verlängerbare, temporäre, usw.) Pseudonym-ID für das Fahrzeug erzeugt wird (Operation 945). Das Pseudonym und die entsprechende Signatur werden durch die Infrastruktur gespeichert, um einen Widerruf der Anbringung zu ermöglichen, wenn böswilliges Verhalten identifiziert wird. Dieser Prozess kann auch einen Prozess zur Aufrechterhaltung der Verbindung (Operation 940) umfassen, der ein periodisches Ausgeben neuer Pseudonyme umfassen kann.
  • Die vertrauenswürdige Authentifizierungsentität und das Fahrzeug können einen sicheren Kommunikationskanal 950 einrichten, und dann können die Pseudonym-ID und Pseudonymzertifikate an das Fahrzeug gesendet werden (Nachricht 955). Irgendwelche weitere Kommunikationen zwischen der Infrastruktur und dem Fahrzeug können nun die Pseudonyme verwenden, um den Urheber oder Empfänger einer Nachricht zu adressieren oder um Nachrichten zur Authentifizierung zu signieren.
  • Zu diesem Zeitpunkt ist der Fahrzeugzustand ein Mitglied, das angebracht ist. Somit ist das Fahrzeug sowohl ein Mitglied als auch ein angebrachter Agent im Straßenrandnetzwerk. Bei einem Beispiel werden die Pseudonym-ID und die Zertifikate aufgefrischt (z.B. aktualisiert) (Austausch 960), um die Verfolgung des Fahrzeugs vor Außenstehenden zu schützen.
  • 10A-10B stellen ein Flussdiagramm einer vertrauenswürdigen Authentifizierungsentität und einer Fahrinfrastruktur während der Fahrzeuganbringung an die Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar. Die anfängliche Anbringung der Fahrzeuge, die der Straße beitreten, wird zwischen den Fahrzeugen und der Straßenrand-Infrastruktur zusammen mit der vertrauenswürdigen Authentifizierungsentität durchgeführt. Die vertrauenswürdige Authentifizierungsentität hat einen anfänglichen Zustand 1002, bei dem sie auf Fahrzeuganforderungen wartet, und die Fahrinfrastruktur hat einen anfänglichen Zustand 1010, bei dem sie auf eine Fahrzeug-Anbringungsanforderung wartet. Die Infrastruktur empfängt eine Anbringungsanforderung 1012 und leitet sie an die vertrauenswürdige Authentifizierungsentität 1014 weiter. Die Fahr-Restrukturierung (driving restructure) wartet dann auf eine zusätzliche Anbringungsanforderung.
  • Nach Empfangen der Anbringungsanforderung 1004 bestimmt die vertrauenswürdige Authentifizierungsentität, ob die Signatur für die Gruppe gültig ist und dass das Fahrzeug nicht auf einer schwarzen Liste steht (Entscheidung 1006). Wenn entweder die Signatur ungültig ist oder das Fahrzeug auf einer schwarzen Liste steht, reagiert die vertrauenswürdige Authentifizierungsentität nicht auf die Fahrinfrastruktur und wartet auf eine weitere Verifizierungsanforderung. Wenn sowohl die Signatur gültig ist als auch das Fahrzeug nicht auf einer schwarzen Liste steht, kommuniziert die vertrauenswürdige Authentifizierungsentität dies an die Fahrinfrastruktur 1008 und kann Straßenranddienste 1026 erzeugen.
  • Nach Verifizierung der Gruppen-ID startet die Fahrinfrastruktur einen Verbindungsaufrechterhaltungs-Prozess 1016 für das Fahrzeug und richtet einen sicheren Kanal mit dem Fahrzeug 1018 ein. Die Fahrinfrastruktur erzeugt auch Pseudonym-IDs und Zertifikate für das Fahrzeug 1020, die dann in einer Anbringungsdatenstruktur gespeichert werden 1022. Die Pseudonym-ID und die Zertifikate werden dann an das Fahrzeug gesendet 1024.
  • In der Fahrinfrastruktur kann es zu einer Zeitüberschreitung (Timeout) bezüglich der Pseudonyminformation 1030 kommen und die Fahrinfrastruktur kann entscheiden, ob das Fahrzeug abgetrennt oder auf eine schwarze Liste gesetzt werden soll. Wenn keine dieser Maßnahmen ergriffen wird, kann die Infrastruktur neue Pseudonymdaten für das Fahrzeug erzeugen. Wenn das Fahrzeug abgetrennt wird, leitet die Fahrinfrastruktur einen Abtrennungs-Handshake 1034 ein und beendet die Verbindung zum Fahrzeug 1036.
  • Die Fahrinfrastruktur kann auch einen Zustand 1038 haben, um das Fahrzeug auf böswilliges Verhalten zu überwachen. In diesem Zustand kann die Infrastruktur das Fahrzeugverhalten 1040 überwachen. Wenn böswilliges Verhalten detektiert wird (Entscheidung 1042), kann die Fahrinfrastruktur die Fahrzeugsignatur in einer Mitgliedschaftsdatenstruktur aufzeichnen 1044, die von der vertrauenswürdigen Authentifizierungsentität für die künftige Führung einer schwarzen Liste gehalten wird. Die Fahrinfrastruktur kann dann die Verbindung zum Fahrzeug 1046 beenden.
  • 11 stellt ein Flussdiagramm eines Fahrzeugs während der Mitgliedschaftsregistrierung bei einer vertrauenswürdigen Authentifizierungsentität und Anbringung bei einer Fahrinfrastruktur gemäß einem Ausführungsbeispiel dar. Das Fahrzeug hat einen anfänglichen Zustand 1102, weder ein Mitglied zu sein noch an eine Fahrinfrastruktur (z.B. Straßenrandnetzwerk) angebracht zu sein. Das Fahrzeug kann eine vID 1104, wie z. B. seine VIN, verschlüsseln, eine Mitgliedschaftsanforderung 1106 an eine vertrauenswürdige Authentifizierungsentität senden und auf eine Antwort 1108 warten. Das Fahrzeug speichert 1110 bei Empfang der Wiedergabe die Gruppen-ID (z. B. den privaten Gruppenschlüssel) in seiner Fahrzeugdatenstruktur und geht in den Zustand 1112, Mitglied, nicht angebracht, über.
  • Von diesem Zustand aus kann das Fahrzeug eine Gruppensignatur 1116 erzeugen und eine angebrachte Anforderung 1118 an ein Straßenrandnetzwerk senden, wobei die Gruppensignatur zur Authentifizierung des Fahrzeugs verwendet wird. Bei Empfang neuer Pseudonym-Informationen 1120 bestimmt das Fahrzeug, ob diese gültig sind, z.B. basierend auf einem Timeout (Entscheidung 1122). Wenn sie nicht gültig sind, wird eine maximale Wiederanlauf-Bewertung (retry evaluation) (Entscheidung 1126) vorgenommen. Wenn es zu viele Wiederanläufe gegeben hat, geht das Fahrzeug in seinen anfänglichen Zustand 1102 zurück. Wenn nicht, sendet das Fahrzeug eine weitere Anbringungsanforderung 1118.
  • Wenn die Pseudonymdaten akzeptiert werden, werden sie 1124 in der Fahrzeugdatenstruktur gespeichert und das Fahrzeug entscheidet 1128, ob es sich vom Straßenrandnetzwerk abtrennen will. Wenn nein, bleibt das Fahrzeug in dem Zustand 1130, Mitglied, angebracht. Wenn ja, leitet das Fahrzeug den Abtrennungs-Handshake 1114 ein und gibt den Zustand 1112 Mitglied, nicht angebracht, wieder.
  • 12 stellt ein Diagramm von Nachrichtenflüssen zwischen einem Fahrzeug, einer Straßenrandeinheit und einer vertrauenswürdigen Authentifizierungsentität während einer Fahrzeugüberwachung auf böswillige Aktivität gemäß einem Ausführungsbeispiel dar. Dieser Ablauf tritt auf, wenn identifiziert wird, dass das Fahrzeug sich böswillig verhält, führt zum Widerruf des Zugriffs auf das Straßenrandnetzwerk.
  • Ein Fahrzeug, das bereits Mitglied ist und an das Straßenrandnetzwerk angebracht ist, kann sich in einer Weise verhalten, die von der Infrastruktur als böswillig angesehen wird (Operation 1202). Die Infrastruktur trennt das Fahrzeug vom Netzwerk ab - was zur Folge haben kann, dass an das Fahrzeug keine Dienste mehr bereitgestellt werden - und teilt dem Fahrzeug die Gründe für die Abtrennung mit (Nachricht 1210).
  • Das Netzwerk kann die vertrauenswürdige Authentifizierungsentität (Nachricht 1204) benachrichtigen, das Fahrzeug auf eine schwarze Liste zu setzen. Die vertrauenswürdige Authentifizierungsentität kann dann die der letzten Pseudonym-ID des Fahrzeugs zugeordnete Signatur auf eine schwarze Liste setzen (Operation 1206) und den Abschluss des Hinzufügens zu einer schwarzen Liste (Blacklisting) bestätigen (Nachricht 1208).
  • Das Fahrzeug kann versuchen, sich wieder anzubringen, indem es eine andere Gruppensignatur erzeugt (Operation 1212) und eine Anbringung anfordert (Nachricht 1214). Die Signatur wird an die vertrauenswürdige Authentifizierungsentität (Nachricht 1216) weitergegeben, wo eine Signaturverifizierung (Operation 1218) durchgeführt wird. Die vertrauenswürdige Authentifizierungsentität erkennt jedoch, dass das Fahrzeug auf einer schwarzen Liste steht (Operation 1220) und stellt eine negative Bestätigung (negative acknowledgment) (Nachricht 1222) an das Straßenrandnetzwerk bereit. Dies hat wiederum zur Folge, dass die Anbringung des Fahrzeugs verweigert und durch eine negative Bestätigung dem Fahrzeug mitgeteilt wird (Nachricht 1224). Die einzige Art und Weise, das Fahrzeug wieder anzubringen wäre, über die vertrauenswürdige Authentifizierungsentität erneut die Mitgliedschaft beim Netzwerk anzufordern. Dies würde massive Angriffe behindern, da sie aufgrund einer hohen Anzahl von Mitgliedschaftsanforderungsversuchen für eine einzelne vID leicht detektiert werden könnten.
  • 13 ist ein Beispiel eines Verfahrens 1300 zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur gemäß einem Ausführungsbeispiel. Die Operationen des Verfahrens 1300 werden mit Computer-Hardware, wie die oben oder unten beschriebene, durchgeführt (z. B. Verarbeitungsschaltungsanordnung).
  • Bei Operation 1305 kontaktiert ein Fahrzeug einen Gruppen-ID-Herausgeber, um das Fahrzeug zu registrieren. Bei einem Beispiel umfasst das Kontaktieren des Gruppen-ID-Herausgebers das Verwenden einer Fahrzeug-ID zur Registrierung als das Mitglied.
  • Bei Operation 1310 wird eine Gruppen-ID, durch das Fahrzeug, von dem Gruppen-Id-Herausgeber empfangen, um die Aufnahme als ein Mitglied anzuzeigen.
  • Bei Operation 1315 kontaktiert das Fahrzeug eine Fahrinfrastruktur, zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug bei der Fahrinfrastruktur zu identifizieren. Bei einem Beispiel umfasst das Kontaktieren der Fahrzeuginfrastruktur ein Kommunizieren mit einer RSU oder einem anderen Element des Straßenrandnetzwerks.
  • Bei einem Beispiel umfasst die Gruppen-ID ein asymmetrisches Schlüsselpaar. Hierbei ist ein privater Schlüssel des Schlüsselpaares für das Fahrzeug einzigartig, und ein öffentlicher Schlüssel des Schlüsselpaares ist mehreren privaten Schlüsseln gemeinsam, umfassend den privaten Schlüssel, der für das Fahrzeug einzigartig ist. Bei einem Beispiel entspricht die Gruppen-ID der Enhanced Privacy ID- (EPID-) Normenfamilie.
  • Bei Operation 1320 empfängt das Fahrzeug eine Anbringungs-ID von der Fahrinfrastruktur. Hier wird die Anbringungs-ID zum Sichern der Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur, umfassend andere Fahrzeuge, verwendet. Bei einem Beispiel ist die Anbringungs-ID eine Pseudonym-ID für das Fahrzeug. Bei einem Beispiel kann das Fahrzeug periodisch eine neue Pseudonym-ID erhalten, die sich von einer früheren Pseudonym-ID für das Fahrzeug unterscheidet.
  • Bei einem Beispiel wird dem Fahrzeug ansprechend auf eine Verletzung einer Richtlinie der Fahrinfrastruktur der Zugriff auf die Fahrinfrastruktur verweigert. Bei einem Beispiel, in dem EPID oder eine ähnliche Signatur als die Gruppen-ID verwendet wird, wird die Gruppen-ID verwendet, um das Fahrzeug unter Verwendung der mehreren privaten Schlüssel, die nicht der private Schlüssel des Fahrzeugs sind, von anderen Entitäten zu unterscheiden.
  • Die oben beschriebenen Systeme und Techniken gewährleisten die Privatsphäre der Fahrzeugidentität, wodurch ein Hindernis für die öffentliche Akzeptanz des kollaborativen automatisierten Fahrens auf der Anwendungsebene (Application Layer) abgeschwächt wird. Eine solche Annahme ermöglicht die praktische Implementierung einer rechnerisch aufwendigen Authentifizierung zur Wahrung der Privatsphäre basierend auf Gruppensignaturen, da im Gegensatz zu VANETs die Authentifizierung nur einmal pro Fahrt durchgeführt werden muss. Ferner ermöglicht die Verwendung von EPID o.ä. zusammen mit Fahrzeugpseudonymen das dynamische Hinzufügen oder Entfernen von Fahrzeugen aus dem Netzwerk, ohne ihre Identität zu beeinträchtigen. Echte Identitätsprivatsphäre kann somit bei Anbringung an das Straßenrandnetzwerk erreicht werden, wenn der gewählte drahtlose Transport sie nicht offenbart. Ansonsten wird die Angriffsfläche für die Privatsphäre zumindest auf die Mobilfunkbetreiber minimiert.
  • 14 stellt ein Blockdiagramm einer beispielhaften Maschine 1400 dar, auf der irgendeine oder mehrere der Techniken (z.B. Methodologien), die hierin erörtert sind, durchgeführt werden können. Beispiele, wie sie hierin beschrieben sind, können Logik oder eine Anzahl von Komponenten oder Mechanismen in der Maschine 1400 umfassen oder nach denselben arbeiten. Eine Schaltungsanordnung (z.B. eine Verarbeitungsschaltungsanordnung) ist eine Sammlung von Schaltungen, die in greifbaren Entitäten der Maschine 1400 implementiert sind, die Hardware (z.B. einfache Schaltungen, Gates, Logik, etc.) umfassen. Schaltungsanordnungsmitgliedschaft kann im Laufe der Zeit flexibel sein. Schaltungsanordnungen umfassen Mitglieder, die allein oder in Kombination während eines Betriebs festgelegte Operationen durchführen können. Bei einem Beispiel kann eine Hardware der Schaltungsanordnung unveränderlich entworfen sein, um eine spezifische Operation (z.B. fest verdrahtet) auszuführen. Bei einem Beispiel kann die Hardware der Schaltungsanordnung variabel verbundene physikalische Komponenten (z.B. Ausführungseinheiten, Transistoren, einfache Schaltungen, etc.) umfassen, umfassend ein maschinenlesbares Medium, das physikalisch modifiziert (z.B. magnetisch, elektrisch, bewegliche Platzierung von invarianten, mit Masse versehenen Partikeln, etc.) ist, um Anweisungen der spezifischen Operation zu kodieren. Bei einem Verbinden der physikalischen Komponenten werden die zugrunde liegenden elektrischen Eigenschaften eines Hardwarebestandteils verändert, beispielsweise von einem Isolator zu einem Leiter oder umgekehrt. Die Anweisungen ermöglichen es eingebetteter Hardware (z.B. den Ausführungseinheiten oder einem Belastungsmechanismus), Mitglieder der Schaltungsanordnung in Hardware über die variablen Verbindungen zu erzeugen, um, wenn in Betrieb, Abschnitte der spezifischen Operation auszuführen. Dementsprechend sind bei einem Beispiel die maschinenlesbaren Medienelemente Teil der Schaltungsanordnung oder sind, wenn die Vorrichtung in Betrieb ist, kommunikativ mit den anderen Komponenten der Schaltungsanordnung gekoppelt. Bei einem Beispiel kann irgendeine der physikalischen Komponenten in mehr als einem Mitglied von mehr als einer Schaltungsanordnung verwendet werden. Beispielsweise können während einer Operation Ausführungseinheiten in einer ersten Schaltung einer ersten Schaltungsanordnung zu einem Zeitpunkt verwendet werden und von einer zweiten Schaltung in der ersten Schaltungsanordnung oder von einer dritten Schaltung in einer zweiten Schaltungsanordnung zu einem anderen Zeitpunkt wiederverwendet werden. Zusätzliche Beispiele dieser Komponenten im Hinblick auf die Maschine 1400 folgen nach.
  • Bei alternativen Ausführungsbeispielen kann die Maschine 1400 als eine eigenständige Vorrichtung arbeiten, oder kann mit anderen Maschinen verbunden (z.B. vernetzt) sein. In einer vernetzten Bereitstellung kann die Maschine 1400 in der Funktion einer Servermaschine, einer Client-Maschine oder in sowohl Server- als auch Client-Netzwerkumgebungen arbeiten. Bei einem Beispiel kann die Maschine 1400 als eine Peer-Maschine in Peer-to-Peer- (P2P) (oder anderen verteilten) Netzwerkumgebungen agieren. Die Maschine 1400 kann ein Personal-Computer (PC), ein Tablet-PC, eine Set-Top-Box (STB), ein persönlicher digitaler Assistent (PDA; Personal Digital Assistant), ein Mobiltelefon, eine Web-Anwendung, ein Netzwerk-Router, Netzwerk-Schalter (switch) oder Netzwerk-Brücke, oder irgendeine Maschine sein, die fähig zum Ausführen von Anweisungen (sequentiell oder anderweitig) ist, die Aktionen spezifizieren, die durch die Maschine ausgeführt werden sollen. Ferner, während nur eine einzige Maschine dargestellt ist, umfasst der Begriff „Maschine“ auch irgendeine Ansammlung von Maschinen, die individuell oder gemeinsam einen Satz (oder mehrere Sätze) von Anweisungen ausführen, um irgendeine oder mehrere der hierin erörterten Methodologien durchzuführen, wie etwa Cloud-Computing, Software as a Service (SaaS), andere Computer-Cluster-Konfigurationen.
  • Die Maschine (z.B. Computersystem) 1400 kann einen Hardware-Prozessor 1402 (z.B. eine zentrale Verarbeitungseinheit (CPU), eine Graphikverarbeitungseinheit (GPU), einen Hardware-Prozessorkern oder irgendeine Kombination davon), einen Hauptspeicher 1404, einen statischen Speicher (z.B. Speicher (memory) oder Speicherung (storage) für Firmware, Mikrocode, ein BIOS (Basic-Input-Output), eine UEFI (Unified Extensible Firmware Interface), etc.) 1406, und Massenspeicher 1408 (z.B. Festplatte, Bandlaufwerk, Flash-Speicher oder andere Blockvorrichtungen) umfassen, von denen einige oder alle möglicherweise miteinander über einen Zwischenlink (z.B. Bus) 1430 kommunizieren. Die Maschine 1400 kann ferner eine Anzeigeeinheit 1410, eine alphanumerische Eingabevorrichtung 1412 (z.B. eine Tastatur), und eine Benutzerschnittstellen (UI; user interface) - Navigationsvorrichtung 1414 (z.B. eine Maus) umfassen. Bei einem Beispiel können die Anzeigeeinheit 1410, die Eingabevorrichtung 1412 und die UI-Navigationsvorrichtung 1414 eine Touchscreen-Anzeige sein. Die Maschine 1400 kann zusätzlich eine Speichervorrichtung (z.B. Laufwerkeinheit) 1408, eine Signalerzeugungsvorrichtung 1418 (z.B. einen Lautsprecher), eine Netzwerkschnittstellenvorrichtung 1420, und einen oder mehrere Sensoren 1416, wie beispielsweise einen Globales-Positionsbestimmungssystem- (GPS-) Sensor, einen Kompass, einen Beschleunigungssensor oder anderen Sensor umfassen. Die Maschine 1400 kann eine Ausgangssteuerung 1428, wie beispielsweise eine serielle (z.B. einen universellen seriellen Bus (USB; universal serial bus), eine parallele oder andere drahtgebundene oder drahtlose (z. B. Infrarot (IR) Nahfeldkommunikation (NFC), usw.) Verbindung umfassen, um mit einer oder mehreren Peripherievorrichtungen (z. B. einem Drucker, einem Kartenlesegerät etc.) zu kommunizieren oder diese zu steuern.
  • Register des Prozessors 1402, der Hauptspeicher 1404, der statische Speicher 1406, oder der Massenspeicher 1408 können ein maschinenlesbares Medium 1422 sein oder umfassen, auf dem ein oder mehrere Sätze von Datenstrukturen oder Anweisungen 1424 (z.B. Software) gespeichert sind, die irgendeine oder mehrere der hierin beschriebenen Techniken oder Funktionen verkörpern oder durch dieselben verwendet werden. Die Anweisungen 1424 können sich auch vollständig oder zumindest teilweise innerhalb irgendeines der Register des Prozessors 1402, des Hauptspeichers 1404, des statischen Speichers 1406, oder des Massenspeichers 1408 während deren Ausführung durch die Maschine 1400 befinden. Bei einem Beispiel kann eines von oder irgendeine Kombination aus dem Hardware-Prozessor 1402, dem Hauptspeicher 1404, dem statischen Speicher 1406, oder dem Massenspeicher 1408 die maschinenlesbaren Medien 1422 bilden. Während das maschinenlesbare Medium 1422 als ein einzelnes Medium dargestellt ist, kann der Begriff „maschinenlesbares Medium“ ein einzelnes Medium oder mehrere Medien umfassen (z.B. eine zentralisierte oder verteilte Datenbank und/oder zugeordnete Zwischenspeicher und Server), die ausgebildet sind, die eine oder mehreren Anweisungen 1424 zu speichern.
  • Der Begriff „maschinenlesbares Medium“ kann irgendein Medium umfassen, das in der Lage ist, Anweisungen zur Ausführung durch die Maschine 1400 zu speichern, zu kodieren und zu tragen, und das die Maschine 1400 dazu veranlassen kann, irgendeine oder mehrere der Techniken der vorliegenden Offenbarung durchzuführen, oder das zum Speichern, Kodieren oder Tragen von Datenstrukturen in der Lage ist, die durch derartige Anweisungen verwendet werden oder diesen zugeordnet sind. Nicht einschränkende maschinenlesbare Medienbeispiele können Festkörperspeicher (solid-state memories), optische Medien, magnetische Medien und Signale (z.B. Radiofrequenzsignale, andere photonenbasierte Signale, Tonsignale, etc.) umfassen. Bei einem Beispiel umfasst ein nichtflüchtiges, maschinenlesbares Medium ein maschinenlesbares Medium mit einer Mehrzahl von Partikeln, die eine invariante (z.B. Ruhe-) Masse aufweisen und somit Materialzusammensetzungen sind. Dementsprechend sind nichtflüchtige maschinenlesbare Medien maschinenlesbare Medien, die keine flüchtigen, sich ausbreitenden Signale umfassen. Spezifische Beispiele von nichtflüchtigen maschinenlesbaren Medien können umfassen: nichtflüchtigen Speicher, wie beispielsweise Halbleiterspeicherbauelemente (z. B. elektrisch programmierbaren Nur-Lese-Speicher (EPROM; Electrically Programmable Read-Only Memory), elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM; Electrically Erasable Programmable Read-Only Memory)) und Flash-Speicher-Bauelemente; Magnetplatten wie beispielsweise interne Festplatten und Wechselplatten; magnetooptische Platten; und CD-ROM- und DVD-ROM-Platten.
  • Die Anweisungen 1424 können ferner über ein Kommunikationsnetzwerk 1426 gesendet oder empfangen werden, unter Verwendung eines Übertragungsmediums über die Netzwerkschnittstellenvorrichtung 1420, die irgendeines von einer Anzahl von Übertragungsprotokollen (z. B. Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.) nutzt. Beispielhafte Kommunikationsnetzwerke können unter anderem ein Lokales Netzwerk (LAN; Local Area Network), ein Weitbereichs-Netzwerk (WAN; Wide Area Network), ein Paketdatennetzwerk (z. B. das Internet), Mobiltelefonnetze (z. B. zelluläre Netze), Plain Old Telephone (einfacher alter Telefondienst; POTS) -Netzwerke und drahtlose Datennetzwerke (z. B. Institute of Electrical and Electronics Engineers- (IEEE-) 802.11 - Standardfamilie, bekannt als Wi-Fi®, IEEE 802.16 -Standardfamilie, bekannt als WiMax®), IEEE 802.15.4 -Standardfamilie, Peer-to-Peer- (P2P-) Netzwerke umfassen. Bei einem Beispiel kann die Netzwerkschnittstellenvorrichtung 1420 eine oder mehrere physische Buchsen (z.B. Ethernet, koaxial oder Telefonbuchsen) oder eine oder mehrere Antennen zum Verbinden mit dem Kommunikationsnetzwerk 1426 umfassen. Bei einem Beispiel kann die Netzwerkschnittstellenvorrichtung 1420 eine Mehrzahl von Antennen umfassen, um drahtlos zu kommunizieren, unter Verwendung von zumindest einer von einer Einzel-Eingang-Mehrfach-Ausgang-(SIMO-; Single-Input Multiple-Output), Mehrfach-Eingang-Mehrfach-Ausgang-(MIMO-; Multiple-Input Multiple-Output) oder Mehrfach-Eingang-Einzel-Ausgang-(MISO-; Multiple-Input Single-Output) Technik. Der Begriff „Übertragungsmedium“ ist so aufzufassen, dass er irgendein nicht greifbares Medium umfasst, das fähig ist zum Speichern, Kodieren oder Tragen von Anweisungen zur Ausführung durch die Maschine 1400, und digitale oder analoge Kommunikationssignale oder ein anderes nicht greifbares Medium zum Ermöglichen von Kommunikation solcher Software umfasst. Ein Übertragungsmedium ist ein maschinenlesbares Medium.
  • Zusätzliche Anmerkungen & Beispiele
  • Beispiel 1 ist eine Vorrichtung zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur, die Vorrichtung umfassend: eine Schnittstelle zum Kommunizieren mit einer Funkeinrichtung eines Fahrzeugs; eine Befestigung zum Anbringen der Vorrichtung an dem Fahrzeug; und eine Verarbeitungsschaltungsanordnung, die ausgebildet ist zum: Kontaktieren, über die Schnittstelle, eines Gruppenidentifikation- (ID-) Herausgebers, um das Fahrzeug zu registrieren; Empfangen, über die Schnittstelle, einer Gruppen-ID von dem Gruppen-ID-Herausgeber, um die Aufnahme als ein Mitglied anzuzeigen; Kontaktieren, über die Schnittstelle, der Fahrinfrastruktur zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug bei der Fahrinfrastruktur zu identifizieren; und Empfangen, über die Schnittstelle, einer Anbringungs-ID von der Fahrinfrastruktur, wobei die Anbringungs-ID verwendet wird, um Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur zu sichern.
  • Bei Beispiel 2 der Gegenstand von Beispiel 1, wobei die Gruppen-ID ein asymmetrisches Schlüsselpaar umfasst, mit einem privaten Schlüssel, der für das Fahrzeug einzigartig ist, und einem öffentlichen Schlüssel, der mehreren privaten Schlüsseln umfassend den für das Fahrzeug einzigartigen privaten Schlüssel gemeinsam ist.
  • Bei Beispiel 3 der Gegenstand von Beispiel 2, wobei die Gruppen-ID der Enhanced Privacy ID- (EPID-) Normenfamilie entspricht.
  • Bei Beispiel 4 der Gegenstand von Beispiel 3, wobei dem Fahrzeug ansprechend auf eine Verletzung einer Richtlinie der Fahrinfrastruktur ein Zugriff auf die Fahrinfrastruktur verweigert wird, wobei die EPID verwendet wird, um das Fahrzeug unter Verwendung der mehreren privaten Schlüssel, die nicht der private Schlüssel des Fahrzeugs sind, von anderen Entitäten zu unterscheiden.
  • Bei Beispiel 5 der Gegenstand von einem der Beispiele 1-4, wobei die Anbringungs-ID eine Pseudonym-ID und einen Satz von Öffentlicher-Schlüssel-Authentifizierungszertifikaten für das Fahrzeug umfasst.
  • Bei Beispiel 6 der Gegenstand von Beispiel 5, wobei die Verarbeitungsschaltungsanordnung ausgebildet ist, um eine neue Pseudonym-ID für das Fahrzeug periodisch zu erhalten, die sich von einer früheren Pseudonym-ID für das Fahrzeug unterscheidet.
  • Bei Beispiel 7 der Gegenstand von einem der Beispiele 1-6, wobei, zum Kontaktieren des Gruppen-ID-Herausgebers, die Verarbeitungsschaltungsanordnung eine Fahrzeug-ID verwendet, um als das Mitglied zu registrieren.
  • Bei Beispiel 8 der Gegenstand von einem der Beispiele 1-7, wobei, zum Kontaktieren der Fahrzeuginfrastruktur, die Verarbeitungsschaltungsanordnung mit einer Straßenrandeinheit kommuniziert.
  • Beispiel 9 ist ein Verfahren zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur, das Verfahren umfassend: Kontaktieren, von einem Fahrzeug, eines Gruppenidentifikation- (ID-) Herausgebers, um das Fahrzeug zu registrieren; Empfangen einer Gruppen-ID von dem Gruppen-ID-Herausgeber, um die Aufnahme als ein Mitglied anzuzeigen; Kontaktieren der Fahrinfrastruktur zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug bei der Fahrinfrastruktur zu identifizieren; und Empfangen einer Anbringungs-ID von der Fahrinfrastruktur, wobei die Anbringungs-ID verwendet wird, um Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur zu sichern.
  • Bei Beispiel 10 der Gegenstand von Beispiel 9, wobei die Gruppen-ID ein asymmetrisches Schlüsselpaar umfasst, mit einem privaten Schlüssel, der für das Fahrzeug einzigartig ist, und einem öffentlichen Schlüssel, der mehreren privaten Schlüsseln umfassend den für das Fahrzeug einzigartigen privaten Schlüssel gemeinsam ist.
  • Bei Beispiel 11 der Gegenstand von Beispiel 10, wobei die Gruppen-ID der Enhanced Privacy ID- (EPID-) Normenfamilie entspricht.
  • Bei Beispiel 12 der Gegenstand von Beispiel 11, wobei dem Fahrzeug ansprechend auf eine Verletzung einer Richtlinie der Fahrinfrastruktur ein Zugriff auf die Fahrinfrastruktur verweigert wird, wobei die EPID verwendet wird, um das Fahrzeug unter Verwendung der mehreren privaten Schlüssel, die nicht der private Schlüssel des Fahrzeugs sind, von anderen Entitäten zu unterscheiden.
  • Bei Beispiel 13 der Gegenstand von einem der Beispiele 9-12, wobei die Anbringungs-ID eine Pseudonym-ID und einen Satz von Öffentlicher-Schlüssel-Authentifizierungszertifikaten für das Fahrzeug umfasst.
  • Bei Beispiel 14 der Gegenstand von Beispiel 13, umfassend periodisch Erhalten einer neuen Pseudonym-ID für das Fahrzeug, die sich von einer früheren Pseudonym-ID für das Fahrzeug unterscheidet.
  • Bei Beispiel 15 der Gegenstand von einem der Beispiele 9-14, wobei das Kontaktieren des Gruppen-ID-Herausgebers ein Verwenden einer Fahrzeug-ID umfasst, um als das Mitglied zu registrieren.
  • Bei Beispiel 16 der Gegenstand von einem der Beispiele 9-15, wobei das Kontaktieren der Fahrzeuginfrastruktur ein Kommunizieren mit einer Straßenrandeinheit umfasst.
  • Beispiel 17 ist zumindest ein maschinenlesbares Medium umfassend Anweisungen zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur, wobei die Anweisungen, wenn sie durch eine Verarbeitungsschaltungsanordnung eines Fahrzeugs ausgeführt werden, verursachen, dass die Verarbeitungsschaltungsanordnung Operationen durchführt umfassend: Kontaktieren eines Gruppenidentifikation- (ID-) Herausgebers, um das Fahrzeug zu registrieren; Empfangen einer Gruppen-ID von dem Gruppen-ID-Herausgeber, um die Aufnahme als ein Mitglied anzuzeigen; Kontaktieren der Fahrinfrastruktur zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug bei der Fahrinfrastruktur zu identifizieren; und Empfangen einer Anbringungs-ID von der Fahrinfrastruktur, wobei die Anbringungs-ID verwendet wird, um Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur zu sichern.
  • Bei Beispiel 18 der Gegenstand von Beispiel 17, wobei die Gruppen-ID ein asymmetrisches Schlüsselpaar umfasst, mit einem privaten Schlüssel, der für das Fahrzeug einzigartig ist, und einem öffentlichen Schlüssel, der mehreren privaten Schlüsseln umfassend den für das Fahrzeug einzigartigen privaten Schlüssel gemeinsam ist.
  • Bei Beispiel 19 der Gegenstand von Beispiel 18, wobei die Gruppen-ID der Enhanced Privacy ID- (EPID-) Normenfamilie entspricht.
  • Bei Beispiel 20 der Gegenstand von Beispiel 19, wobei dem Fahrzeug ansprechend auf eine Verletzung einer Richtlinie der Fahrinfrastruktur ein Zugriff auf die Fahrinfrastruktur verweigert wird, wobei die EPID verwendet wird, um das Fahrzeug unter Verwendung der mehreren privaten Schlüssel, die nicht der private Schlüssel des Fahrzeugs sind, von anderen Entitäten zu unterscheiden.
  • Bei Beispiel 21 der Gegenstand von einem der Beispiele 17-20, wobei die Anbringungs-ID eine Pseudonym-ID und einen Satz von Öffentlicher-Schlüssel-Authentifizierungszertifikaten für das Fahrzeug umfasst.
  • Bei Beispiel 22 der Gegenstand von Beispiel 21, wobei die Operationen periodisch Erhalten einer neuen Pseudonym-ID für das Fahrzeug umfassen, die sich von einer früheren Pseudonym-ID für das Fahrzeug unterscheidet.
  • Bei Beispiel 23 der Gegenstand von einem der Beispiele 17-22, wobei das Kontaktieren des Gruppen-ID-Herausgebers ein Verwenden einer Fahrzeug-ID umfasst, um als das Mitglied zu registrieren.
  • Bei Beispiel 24 der Gegenstand von einem der Beispiele 17-23, wobei das Kontaktieren der Fahrzeuginfrastruktur ein Kommunizieren mit einer Straßenrandeinheit umfasst.
  • Beispiel 25 ist ein System zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur, das System umfassend: Mittel zum Kontaktieren, von einem Fahrzeug, eines Gruppenidentifikation- (ID-) Herausgebers, um das Fahrzeug zu registrieren; Mittel zum Empfangen einer Gruppen-ID von dem Gruppen-ID-Herausgeber, um die Aufnahme als ein Mitglied anzuzeigen; Mittel zum Kontaktieren der Fahrinfrastruktur zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug bei der Fahrinfrastruktur zu identifizieren; und Mittel zum Empfangen einer Anbringungs-ID von der Fahrinfrastruktur, wobei die Anbringungs-ID verwendet wird, um Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur zu sichern.
  • Bei Beispiel 26 der Gegenstand von Beispiel 25, wobei die Gruppen-ID ein asymmetrisches Schlüsselpaar umfasst, mit einem privaten Schlüssel, der für das Fahrzeug einzigartig ist, und einem öffentlichen Schlüssel, der mehreren privaten Schlüsseln umfassend den für das Fahrzeug einzigartigen privaten Schlüssel gemeinsam ist.
  • Bei Beispiel 27 der Gegenstand von Beispiel 26, wobei die Gruppen-ID der Enhanced Privacy ID- (EPID-) Normenfamilie entspricht.
  • Bei Beispiel 28 der Gegenstand von Beispiel 27, wobei dem Fahrzeug ansprechend auf eine Verletzung einer Richtlinie der Fahrinfrastruktur ein Zugriff auf die Fahrinfrastruktur verweigert wird, wobei die EPID verwendet wird, um das Fahrzeug unter Verwendung der mehreren privaten Schlüssel, die nicht der private Schlüssel des Fahrzeugs sind, von anderen Entitäten zu unterscheiden.
  • Bei Beispiel 29 der Gegenstand von einem der Beispiele 25-28, wobei die Anbringungs-ID eine Pseudonym-ID und einen Satz von Öffentlicher-Schlüssel-Authentifizierungszertifikaten für das Fahrzeug umfasst.
  • Bei Beispiel 30 der Gegenstand von Beispiel 29, umfassend Mittel zum periodisch Erhalten einer neuen Pseudonym-ID für das Fahrzeug, die sich von einer früheren Pseudonym-ID für das Fahrzeug unterscheidet.
  • Bei Beispiel 31 der Gegenstand von einem der Beispiele 25-30, wobei die Mittel zum Kontaktieren des Gruppen-ID-Herausgebers Mittel zum Verwenden einer Fahrzeug-ID umfassen, um als das Mitglied zu registrieren.
  • Bei Beispiel 32 der Gegenstand von einem der Beispiele 25-31, wobei die Mittel zum Kontaktieren der Fahrzeuginfrastruktur Mittel zum Kommunizieren mit einer Straßenrandeinheit umfassen.
  • Beispiel 33 ist zumindest ein maschinenlesbares Medium, umfassend Anweisungen, die, wenn sie durch eine Verarbeitungsschaltungsanordnung ausgeführt werden, verursachen, dass die Verarbeitungsschaltungsanordnung Operationen durchführt, um irgendeines der Beispiele 1-32 zu implementieren.
  • Beispiel 34 ist eine Vorrichtung umfassend Mittel, um irgendeines der Beispiele 1-32 zu implementieren.
  • Beispiel 35 ist ein System, um irgendeines der Beispiele 1-32 zu implementieren.
  • Beispiel 36 ist ein Verfahren, um irgendeines der Beispiele 1-32 zu implementieren.
  • Die obige detaillierte Beschreibung nimmt Bezug auf die beiliegenden Zeichnungen, die Bestandteil der detaillierten Beschreibung sind. Veranschaulichend zeigen die Zeichnungen spezifische Ausführungsbeispiele, die ausgeführt werden können. Diese Ausführungsbeispiele werden hierin auch als „Beispiele“ bezeichnet. Solche Beispiele können Elemente zusätzlich zu den Gezeigten oder Beschriebenen umfassen. Allerdings betrachten die vorliegenden Erfinder auch Beispiele, bei denen nur jene Elemente, die gezeigt oder beschrieben sind, bereitgestellt sind. Ferner betrachten die vorliegenden Erfinder auch Beispiele, die irgendeine Kombination oder Permutation jener gezeigten oder beschriebenen Elemente (oder einen oder mehrere Aspekte derselben) verwenden, entweder im Hinblick auf ein bestimmtes Beispiel (oder einen oder mehrere Aspekte desselben) oder im Hinblick auf andere hierin gezeigte oder beschriebene Beispiele (oder einen oder mehrere Aspekte derselben).
  • Alle Offenlegungen, Patente und Patentdokumente, auf die in diesem Dokument Bezug genommen ist, sind hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen, als ob sie individuell durch Bezugnahme aufgenommen sind. Im Fall von inkonsistenten Verwendungen zwischen diesem Dokument und jenen Dokumenten, die durch Bezugnahme aufgenommen sind, ist die Verwendung in der einen oder den mehreren aufgenommenen Bezugnahme(n) ergänzend zu diesem Dokument zu betrachten; bei unvereinbaren Inkonsistenzen gilt die Verwendung in diesem Dokument.
  • In diesem Dokument werden die Begriffe „ein, eine“ verwendet, wie in Patentdokumenten üblich, um einen oder mehr als einen zu umfassen, unabhängig von irgendwelchen anderen Fällen oder Verwendungen von „zumindest ein,e,s“ oder „ein,e,s oder mehrere“. In diesem Dokument wird der Begriff „oder“ verwendet, um auf ein nicht-exklusives oder Bezug zu nehmen, derart, dass „A oder B“ „A aber nicht B“, „B aber nicht A“ und „A und B“ umfasst, sofern es nicht anderweitig angegeben ist. In den beigefügten Ansprüchen werden die Begriffe „aufweisend“ und „bei dem,r“ als die einfachen Entsprechungen der jeweiligen Begriffe „umfassend“ und „wobei“ verwendet. In den folgenden Ansprüchen sind ferner die Begriffe „aufweisend“ und „umfassend“ offene Begriffe, d.h. ein System, Bauelement/Vorrichtung (device), Artikel oder Prozess, der Elemente zusätzlich zu jenen umfasst, die nach einem solchen Begriff in einem Anspruch aufgeführt sind, fällt immer noch in den Schutzbereich dieses Anspruchs. Ferner werden in den folgenden Ansprüchen die Begriffe „erste,r,s“ „zweite,r,s“ und „dritte,r,s“ etc. lediglich als Kennzeichnungen verwendet und sollen ihren Objekten keine numerischen Anforderungen auferlegen.
  • Die obige Beschreibung soll veranschaulichend und nicht einschränkend sein. Zum Beispiel können die vorangehend beschriebenen Beispiele (oder einer oder mehrere Aspekte derselben) in Kombination miteinander verwendet werden. Andere Ausführungsbeispiele können verwendet werden, wie beispielsweise durch einen Fachmann nach Prüfung der vorangehenden Beschreibung. Die Zusammenfassung ist bereitgestellt, um es dem Leser zu ermöglichen, das Wesen der technischen Offenbarung schnell zu verstehen, und wird mit dem Verständnis eingereicht, dass sie nicht verwendet wird, um den Schutzbereich oder die Bedeutung der Ansprüche zu interpretieren oder einzuschränken. Ferner können in der obigen detaillierten Beschreibung verschiedene Merkmale zu einer Gruppe zusammengefasst werden, um die Offenbarung zu vereinheitlichen. Dies soll nicht so ausgelegt werden, als ob beabsichtigt sei, dass ein nicht beanspruchtes, offenbartes Merkmal für einen Anspruch wesentlich ist. Im Gegenteil, der erfinderische Gegenstand kann in weniger als allen Merkmalen eines bestimmten offenbarten Ausführungsbeispiels liegen. Somit sind die folgenden Ansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch als ein getrenntes Ausführungsbeispiel für sich steht. Der Schutzbereich der Ausführungsbeispiele sollte Bezug nehmend auf die beigefügten Ansprüche bestimmt werden, zusammen mit dem vollständigen Schutzbereich von Entsprechungen, auf welche solche Ansprüche Anrecht haben.

Claims (15)

  1. Eine Vorrichtung zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur, die Vorrichtung umfassend: eine Schnittstelle zum Kommunizieren mit einer Funkeinrichtung eines Fahrzeugs; eine Befestigung zum Anbringen der Vorrichtung an dem Fahrzeug; und eine Verarbeitungsschaltungsanordnung, die ausgebildet ist zum: Kontaktieren, über die Schnittstelle, eines Gruppenidentifikation- (ID-) Herausgebers, um das Fahrzeug zu registrieren; Empfangen, über die Schnittstelle, einer Gruppen-ID von dem Gruppen-ID-Herausgeber, um die Aufnahme als ein Mitglied anzuzeigen; Kontaktieren, über die Schnittstelle, der Fahrinfrastruktur zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug bei der Fahrinfrastruktur zu identifizieren; und Empfangen, über die Schnittstelle, einer Anbringungs-ID von der Fahrinfrastruktur, wobei die Anbringungs-ID verwendet wird, um Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur zu sichern.
  2. Die Vorrichtung gemäß Anspruch 1, wobei die Gruppen-ID ein asymmetrisches Schlüsselpaar umfasst, mit einem privaten Schlüssel, der für das Fahrzeug einzigartig ist, und einem öffentlichen Schlüssel, der mehreren privaten Schlüsseln umfassend den für das Fahrzeug einzigartigen privaten Schlüssel gemeinsam ist.
  3. Die Vorrichtung gemäß Anspruch 2, wobei die Gruppen-ID der Enhanced Privacy ID- (EPID-) Normenfamilie entspricht.
  4. Die Vorrichtung gemäß Anspruch 3, wobei das Fahrzeug ansprechend auf eine Verletzung einer Richtlinie der Fahrinfrastruktur aus der Fahrinfrastruktur ausgestoßen wird, wobei die EPID verwendet wird, um das Fahrzeug unter Verwendung der mehreren privaten Schlüssel, die nicht der private Schlüssel des Fahrzeugs sind, von anderen Entitäten zu unterscheiden.
  5. Die Vorrichtung gemäß einem der Ansprüche 1-4, wobei die Anbringungs-ID eine Pseudonym-ID und einen Satz von Öffentlicher-Schlüssel-Authentifizierungszertifikaten für das Fahrzeug umfasst.
  6. Ein Verfahren zum Sichern der Fahrzeugprivatsphäre in einer Fahrinfrastruktur, das Verfahren umfassend: Kontaktieren, von einem Fahrzeug, eines Gruppenidentifikation- (ID-) Herausgebers, um das Fahrzeug zu registrieren; Empfangen einer Gruppen-ID von dem Gruppen-ID-Herausgeber, um die Aufnahme als ein Mitglied anzuzeigen; Kontaktieren der Fahrinfrastruktur zum Anbringen an die Fahrinfrastruktur unter Verwendung der Gruppen-ID, um das Fahrzeug bei der Fahrinfrastruktur zu identifizieren; und Empfangen einer Anbringungs-ID von der Fahrinfrastruktur, wobei die Anbringungs-ID verwendet wird, um Kommunikationen zwischen dem Fahrzeug und der Fahrinfrastruktur zu sichern.
  7. Das Verfahren gemäß Anspruch 6, wobei die Gruppen-ID ein asymmetrisches Schlüsselpaar umfasst, mit einem privaten Schlüssel, der für das Fahrzeug einzigartig ist, und einem öffentlichen Schlüssel, der mehreren privaten Schlüsseln umfassend den für das Fahrzeug einzigartigen privaten Schlüssel gemeinsam ist.
  8. Das Verfahren gemäß Anspruch 7, wobei die Gruppen-ID der Enhanced Privacy ID- (EPID-) Normenfamilie entspricht.
  9. Das Verfahren gemäß Anspruch 8, wobei das Fahrzeug ansprechend auf eine Verletzung einer Richtlinie der Fahrinfrastruktur aus der Fahrinfrastruktur ausgestoßen wird, wobei die EPID verwendet wird, um das Fahrzeug unter Verwendung der mehreren privaten Schlüssel, die nicht der private Schlüssel des Fahrzeugs sind, von anderen Entitäten zu unterscheiden.
  10. Das Verfahren gemäß einem der Ansprüche 6-9, wobei die Anbringungs-ID eine Pseudonym-ID und einen Satz von Öffentlicher-Schlüssel-Authentifizierungszertifikaten für das Fahrzeug umfasst.
  11. Das Verfahren gemäß Anspruch 10, umfassend periodisch Erhalten einer neuen Pseudonym-ID für das Fahrzeug, die sich von einer früheren Pseudonym-ID für das Fahrzeug unterscheidet.
  12. Das Verfahren gemäß einem der Ansprüche 6-11, wobei das Kontaktieren des Gruppen-ID-Herausgebers ein Verwenden einer Fahrzeug-ID umfasst, um als das Mitglied zu registrieren.
  13. Das Verfahren gemäß einem der Ansprüche 6-12, wobei das Kontaktieren der Fahrzeuginfrastruktur ein Kommunizieren mit einer Straßenrandeinheit umfasst.
  14. Ein maschinenlesbares Medium umfassend Anweisungen, die, wenn sie durch eine Schaltungsanordnung ausgeführt werden, verursachen, dass die Schaltungsanordnung irgendein Verfahren gemäß Ansprüchen 6-12 durchführt.
  15. Ein System umfassend Mittel zum Durchführen von irgendeinem Verfahren gemäß Ansprüchen 6-13.
DE102020121805.2A 2019-09-27 2020-08-19 Sichern der fahrzeugprivatsphäre in einer fahrinfrastruktur Pending DE102020121805A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/586,540 2019-09-27
US16/586,540 US11490249B2 (en) 2019-09-27 2019-09-27 Securing vehicle privacy in a driving infrastructure

Publications (1)

Publication Number Publication Date
DE102020121805A1 true DE102020121805A1 (de) 2021-04-01

Family

ID=69162219

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020121805.2A Pending DE102020121805A1 (de) 2019-09-27 2020-08-19 Sichern der fahrzeugprivatsphäre in einer fahrinfrastruktur

Country Status (3)

Country Link
US (1) US11490249B2 (de)
CN (1) CN112584376A (de)
DE (1) DE102020121805A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022019932A1 (en) * 2020-07-21 2022-01-27 Harman International Industries, Incorporated Systems and methods for data security in autonomous vehicles
CN114301611B (zh) * 2020-09-22 2023-11-07 如般量子科技有限公司 车联网保密通信方法及能够进行保密通信的车联网系统
WO2023069635A1 (en) * 2021-10-21 2023-04-27 Tesla, Inc. Vehicle prognostics utilizing psuedonymous logging and directives
CN114286332B (zh) * 2021-12-08 2023-10-20 重庆邮电大学 一种具有隐私保护的动态高效车载云管理方法
CN114460579B (zh) * 2022-04-12 2022-07-12 广东中科四创科技有限公司 一种侦控近海船只的方法、系统和存储介质

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005062919A2 (en) * 2003-12-22 2005-07-14 Wachovia Corporation Public key encryption for groups
EP2137875B1 (de) * 2007-03-19 2016-03-16 Telcordia Technologies, Inc. Verwaltung von fahrzeugsegmentzertifikaten über gemeinsam genutzte zertifikatschemata
US8230215B2 (en) * 2008-04-11 2012-07-24 Toyota Motor Engineering & Manufacturing North America, Inc. Method for allocating multiple authentication certificates to vehicles in a vehicle-to-vehicle communication network
US9536361B2 (en) * 2012-03-14 2017-01-03 Autoconnect Holdings Llc Universal vehicle notification system
US10319039B1 (en) * 2014-05-20 2019-06-11 State Farm Mutual Automobile Insurance Company Accident fault determination for autonomous vehicles
WO2016013944A1 (en) * 2014-07-24 2016-01-28 Intel Corporation Secure wireless charging
US20160132296A1 (en) * 2014-11-11 2016-05-12 Electronics And Telecommunications Research Institute Apparatus and method for generating digital value
US20170015263A1 (en) * 2015-07-14 2017-01-19 Ford Global Technologies, Llc Vehicle Emergency Broadcast
DE102015114285B4 (de) * 2015-08-27 2018-10-31 Volkswagen Aktiengesellschaft Vorrichtung, Verfahren und Computerprogramm zum Bereitstellen von Übertragungsparametern
WO2017147207A1 (en) * 2016-02-22 2017-08-31 Continental Automotive Systems, Inc. Method to establish and update keys for secure in-vehicle network communication
CN109863545B (zh) * 2016-10-21 2022-04-26 三菱电机株式会社 自动驾驶辅助装置、自动驾驶车、自动驾驶辅助方法及计算机可读取存储介质
WO2018160724A1 (en) * 2017-02-28 2018-09-07 Wayfarer, Inc. Transportation system
JP6838211B2 (ja) * 2017-07-31 2021-03-03 日立Astemo株式会社 自律運転制御装置、自律移動車及び自律移動車制御システム
US10518729B2 (en) * 2017-08-02 2019-12-31 Allstate Insurance Company Event-based connected vehicle control and response systems
DE102017222434A1 (de) * 2017-12-12 2019-06-13 Audi Ag Verfahren zur Authentifizierung eines Kraftfahrzeugs
US11095660B2 (en) * 2019-01-30 2021-08-17 Toyota Motor Engineering & Manufacturing North America, Inc. Blockchain enabled encryption

Also Published As

Publication number Publication date
US11490249B2 (en) 2022-11-01
US20200029210A1 (en) 2020-01-23
CN112584376A (zh) 2021-03-30

Similar Documents

Publication Publication Date Title
DE102020121805A1 (de) Sichern der fahrzeugprivatsphäre in einer fahrinfrastruktur
Zhang et al. Blockchain based secure data sharing system for Internet of vehicles: A position paper
DE102019103890A1 (de) Vertrauenswürdige Übertragung des Besitzes von Peripherievorrichtungen
DE112019003309T5 (de) Vorrichtung für einen sicheren sendungsempfang mit delegierungskette
DE112018005260T5 (de) Sichere Gerät-Onboarding-Techniken
DE102011016513A1 (de) Bedrohungsmilderung in einem Fahrzeug-zu-Fahrzeug-Kommunikationsnetz
DE102016121151A1 (de) Authentifizierung zwischen Fahrzeugen unter Verwendung von visuellen kontextbezogenen Informationen
DE112012005564T5 (de) Sichere Peer-Ermittlung und Authentifizierung unter Verwendung eines gemeinsamen Geheimnisses
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
DE112017000483T5 (de) System, gerät und verfahren für schlüsselbereitstellungsdelegation
DE112019001209T5 (de) Sicheres Ble-Just-Works-Koppelverfahren gegen Man-In-The-Middle-Angriffe
DE102019103927A1 (de) Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan
DE102015122518A1 (de) Authentifizierung von Datenkommunikationen
DE112017007393T5 (de) System und verfahren für netzwerkvorrichtungssicherheits- und vertrauenswertbestimmung
DE102020204846A1 (de) Inhaltsablieferung auf namenraumrichtlinien-basis in informationszentrischen netzwerken
DE112018003798T5 (de) Erzeugen und analysieren von netzprofildaten
CN116235464A (zh) 认证方法和系统
DE112020003699B4 (de) Gleichzeitige aktivierung von verschlüsselung auf einem betriebspfad an einem speicheranschluss
DE112008002860T5 (de) Verfahren und Vorrichtung für das Bereitstellen einer sicheren Verknüpfung mit einer Benutzeridentität in einem System für digitale Rechteverwaltung
EP3699791A1 (de) Zugangskontrolle mit einem mobilfunkgerät
EP3114600A1 (de) Sicherheitssystem mit Zugriffskontrolle
DE102020204476A1 (de) Notfalldatensammlung in einem informationszentrischen netzwerk
DE102021133346A1 (de) Sitzungsschlüsselerzeugung für einen betrieb autonomer fahrzeuge
DE102015219517B4 (de) Zertifizierungsmodul, Vorrichtung, Berechtigungsprüfungsmodul, Verfahren und Computerprogramm zum Berechnen, Bereitstellen und Prüfen von digitalen Kurzzeitzertifikaten
EP3373545A1 (de) Sicherheitseinheit insbesondere ein für iot-gerät und verfahren zur ausführung einer oder mehrerer applikationen zum gesicherten datenaustausch mit einem oder mehrere web-dienste bereitstellenden servern