DE102023101864A1

DE102023101864A1 - System und verfahren zum generieren einer digitalen fahrzeugidentifikationsnummer

Info

Publication number: DE102023101864A1
Application number: DE102023101864.7A
Authority: DE
Inventors: Sekar Kulandaivel; Jorge Guajardo Merchan
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2022-01-26
Filing date: 2023-01-26
Publication date: 2023-07-27
Also published as: US20230237507A1; CN116506146A

Abstract

Ein System und Verfahren zum Generieren einer digitalen Identität eines Fahrzeugs. Eine erste Mehrzahl von Messungen kann von einer Mehrzahl von im Fahrzeug befindlichen elektronischen Steuereinheiten generiert werden. Die Messungen können von einem Back-End-Service oder von einer gesicherten im Fahrzeug befindlichen Steuervorrichtung empfangen werden. Die Messungen können mittels physik-basierter Metriken generiert werden, die jedem der Mehrzahl von elektronischen Steuereinheiten eigen sind. Aus den Messwerten kann ein Datenpool erzeugt werden. Außerdem kann durch Kombinieren des Datenpools mit Fehlerkorrekturdaten ein eindeutiger Schlüssel generiert werden, der zur Verifizierung der digitalen Identität des Fahrzeugs funktionsfähig ist.

Description

TECHNISCHES GEBIET
Die vorliegende Offenlegung betrifft die Verbesserung der Fahrzeugsicherheit durch Generierung einer digitalen Fahrzeugidentifikationsnummer basierend auf einem oder mehreren Steuereinheiten in einem Fahrzeug.
HINTERGRUND
Fahrzeuge haben üblicherweise eine „Fahrzeugidentifikationsnummer“ oder „VIN“, die ein eindeutiger, vom Erstausrüster (engl. Original Equipment Manufacturer, OEM) erzeugter Code ist. Wurde die VIN einmal vergeben, kann der Hersteller sie in verschiedene Originalteile des Fahrzeugs (z. B. Motorblock, Türrahmen usw.) einätzen. Beim Verkauf des Fahrzeugs können die verschiedenen Teile dann visuell überprüft werden, und die VIN kann verwendet werden, um den Besitz des Fahrzeugs nachzuweisen oder um zu bestätigen, dass ein bestimmtes Teil zum entsprechenden Fahrzeug gehört. Die VIN eines Fahrzeugs kann auch eine eindeutige Kennung sein, die von den elektronischen Steuereinheiten (ECUs) des Fahrzeugs verwendet wird, z. B. um das Fahrzeug zu authentifizieren, wenn es mit Diagnosegeräten und Remote-Back-End-Services verbunden ist. Da jedoch als einziges Verfahren zum Verifizieren der Fahrzeugidentifikationsnummer ein physischer Zugang erforderlich ist, verfügt ein digitales System derzeit über kein Verfahren, um die Gültigkeit eines Fahrzeugs sicherzustellen, das seine zugewiesene VIN für sich angibt. Einem Unbefugten (oder einem nicht autorisierten Nutzer) könnte es gelingen, die physische VIN zu fälschen, die gefälschte VIN mit digitalen Diensten zu authentifizieren und schließlich die mit einer bestimmten VIN assoziierten Daten zu fälschen.
FAZIT
Ein System und Verfahren zum Generieren einer digitalen Identität für ein Fahrzeug. Das System und das Verfahren empfangen eine erste Mehrzahl von Messungen, die von in dem Fahrzeug befindlichen elektronischen Steuereinheiten erfasst werden. Die erste Mehrzahl von Messungen können physik-basierte Metriken sein, die generiert werden und jedem der Mehrzahl von elektronischen Steuereinheiten eigen sind. Die physik-basierten Metriken können ein momentaner Energiewert sein, der von einer mit der Mehrzahl der elektronischen Steuereinheiten assoziierten Energiequelle empfangen wird. Die erste Mehrzahl von Messungen kann auch vom Fahrzeug zu einem externen Server mittels eines gesicherten Übertragungskanal-Protokolls empfangen werden.
Aus der ersten Mehrzahl von Messwerten können Hilfsdaten generiert werden. Anschließend kann aus der ersten Mehrzahl von Messungen ein Datenpool erzeugt werden. Als nächstes kann eine eindeutige Kennung generiert werden, indem mindestens zwei der ersten Mehrzahl von Messungen innerhalb des Datenpools kombiniert werden. Die eindeutige Kennung kann auch dazu dienen, die digitale Identität des Fahrzeugs zu verifizieren. Es wird in Betracht gezogen, dass der eindeutige Schlüssel auch auf dem externen Server gespeichert werden kann. Auch kann der eindeutige Schlüssel mit einem einzelnen Authentifizierungsprotokoll kombiniert werden. Der eindeutige Schlüssel lässt sich auch mit einem gegenseitigen Authentifizierungsprotokoll kombinieren. Schließlich kann eine mit dem Fahrzeug assoziierte physische Fahrzeugidentifikationsnummer (VIN) empfangen werden, die auch zum Generieren des eindeutigen Schlüssels verwendet werden kann.
Es wird in Betracht gezogen, dass das Erzeugen des Datenpools wiederholt werden kann, so dass der Datenpool ein oder mehrere eindeutige Merkmale des Fahrzeugs enthält. Die erste Mehrzahl von Messungen kann auch als ein einzelnes Datenarray dargestellt werden. Ein eindeutiger Schlüssel kann auch unter Verwendung eines Fuzzy-Extraktionsalgorithmus erzeugt werden, der einen Rauschpegel innerhalb der ersten Vielzahl von Messungen verarbeiten kann, wobei der Fuzzy-Extraktionsalgorithmus die Fehlerkorrekturdaten zur Anpassung eines gemessenen Fuzzy-Signals verwendet. Außerdem kann ein unscharfer Fingerabdruck generiert werden, der eine Identität und einen vorbestimmten Abweichungswert für die erste Mehrzahl von Messungen enthält. Schließlich können Fehlerkorrekturdaten mittels eines Back-End-Services aus dem Datenpool berechnet werden.
Es wird in Betracht gezogen, dass das vorliegende Verfahren und System eine Identitätsprüfungs-Anforderung an das Fahrzeug senden kann. Eine zweite Mehrzahl von Messungen kann von der Mehrzahl der im Fahrzeug befindlichen elektronischen Steuereinheiten erfasst werden. Die zweite Mehrzahl von Messungen können physik-basierte Metriken sein, die generiert werden und jedem der Mehrzahl von elektronischen Steuereinheiten eigen sind. Der eindeutige Schlüssel, der mit der zweiten Mehrzahl von Messungen assoziiert ist, kann dann durch Kombinieren der zweiten Mehrzahl von Messungen mit Hilfsdaten, die aus der ersten Mehrzahl von Messungen generiert wurden, rekonstruiert werden. Die digitale Identität des Fahrzeugs kann dann mittels eines Authentifizierungsprotokolls als gültig verifiziert werden, um den eindeutigen Schlüssel zu verifizieren.
Figurenliste

1 veranschaulicht ein beispielhaftes Blockdiagramm für die Implementierung einer digitalen Fahrzeugidentifikationsnummer (DVIN).
2 veranschaulicht ein alternatives beispielhaftes Blockdiagramm für die Implementierung einer digitalen Fahrzeugidentifikationsnummer (DVIN).
3 veranschaulicht beispielhaft einen Registrierungsprozess, der bei der digitalen Identifizierung verwendet werden kann.
4 veranschaulicht beispielhaft einen Verifizierungsprozess, der bei der digitalen Identifizierung verwendet werden kann.

DETAILLIERTE BESCHREIBUNG
Hier werden Ausführungsformen der vorliegenden Offenbarung beschrieben. Es versteht sich allerdings, dass die offenbarten Ausführungsformen lediglich Beispiele sind und weitere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Details bestimmter Komponenten zu zeigen. Deshalb sollen spezifische strukturelle und funktionelle Details, die hier offenbart werden, nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis zur Unterweisung eines Fachmanns, die Ausführungsformen unterschiedlich einzusetzen. Wie einschlägige Fachleute verstehen werden, können verschieden Merkmale, die unter Bezugnahme auf eine beliebige Figur veranschaulicht und beschrieben werden, mit Merkmalen, die in einer oder mehreren weiteren Figuren veranschaulicht werden, kombiniert werden, um Ausführungsformen zu erzeugen, die nicht ausdrücklich veranschaulicht oder beschrieben sind. Die Kombinationen veranschaulichter Merkmale schaffen repräsentative Ausführungsformen für typische Anwendungen. Verschiedene Kombinationen und Modifikationen der Merkmale im Einklang mit den Unterweisungen dieser Offenbarung können allerdings für bestimmte Anwendungen oder Implementierungen wünschenswert sein.
Auch hier haben Fahrzeuge üblicherweise eine „Fahrzeugidentifikationsnummer“ oder „VIN“, die ein eindeutiger, vom Erstausrüster (engl. Original Equipment Manufacturer, OEM) erzeugter Code ist. Wurde die VIN einmal vergeben, kann der Hersteller sie in verschiedene Originalteile des Fahrzeugs (z. B. Motorblock, Türrahmen usw.) einätzen. Beim Verkauf des Fahrzeugs können die verschiedenen Teile dann visuell überprüft werden, und die VIN kann verwendet werden, um den Besitz des Fahrzeugs nachzuweisen oder um zu bestätigen, dass ein bestimmtes Teil zum entsprechenden Fahrzeug gehört. Die VIN eines Fahrzeugs kann auch eine eindeutige Kennung sein, die von den elektronischen Steuereinheiten (ECUs) des Fahrzeugs verwendet wird, z. B. um das Fahrzeug zu authentifizieren, wenn es mit Diagnosegeräten und Remote-Back-End-Services verbunden ist. Da jedoch als einziges Verfahren zum Verifizieren der Fahrzeugidentifikationsnummer ein physischer Zugang erforderlich ist, verfügt ein digitales System derzeit über kein Verfahren, um die Gültigkeit eines Fahrzeugs sicherzustellen, das seine zugewiesene VIN für sich angibt. Einem Unbefugten (oder einem nicht autorisierten Nutzer) könnte es gelingen, die physische VIN zu fälschen, die gefälschte VIN mit digitalen Diensten zu authentifizieren und schließlich die mit einer bestimmten VIN assoziierten Daten zu fälschen.
Um potenzielle Sicherheitsprobleme zu überwinden, stellt die vorliegende Anwendung ein System und Verfahren zur Generierung einer digitalen Fahrzeugidentifikationsnummer (DVIN) bereit. Die DVIN kann durch Kombinieren der vom Hersteller normalerweise vergebenen physischen Fahrzeugidentifikationsnummer (VIN) mit einem eindeutigen digitalen Fingerabdruck generiert werden, der mittels eines Satzes (oder einer Teilmenge) von Steuergeräten oder elektronischen Steuereinheiten (ECUs) eines Fahrzeugs und ihrem entsprechenden Verhalten während des normalen Betriebs oder während eines Registrierungsprozesses für Fingerabdrücke generiert wird. Die generierte DVIN kann dann von Diagnosegeräten und Remote-Back-End-Services verwendet werden, um ein Fahrzeug zu verifizieren. Die DVIN kann beispielsweise dazu verwendet werden, um zu verifizieren, dass ein Fahrzeug die physikalische Fahrzeugidentifikationsnummer (VIN), die sich physisch auf einem oder mehreren Teilen des Fahrzeugs befindet, auch tatsächlich trägt. Ein weiteres Beispiel könnte ein Fahrzeug sein, das Zugang zu einem Cloud-Dienst anfordert. Die DVIN könnte als zusätzliches Verfahren verwendet werden, um zu verifizieren, dass dem Fahrzeug Zugang zu dem Dienst gewährt werden sollte (zusätzlich zur Vorlage der Standard-VIN).
1 veranschaulicht beispielsweise eine DVIN 100, die durch Kombinieren der physischen VIN 102 und der digitalen Fingerabdrücke von einer drahtlosen Steuereinheit 104, einer Airbag-Steuereinheit 106, einer Bremssystem-Steuereinheit 108 und einer Motor-Steuereinheit 110 generiert werden kann. Die VIN 102 kann von einem Hersteller (z. B. OEM) oder einem Lieferanten für ein bestimmtes Fahrzeug 112 vergeben werden. Ebenso können die digitalen Fingerabdrücke einer bestimmten Steuereinheit (z. B. drahtlose Steuereinheit 104, Airbag-Steuereinheit 106, Bremssystem-Steuereinheit 108 und Motor-Steuereinheit 110) bei der Fertigung oder beim Einbau in das Fahrzeug 112 vergeben werden.
Es wird in Betracht gezogen, dass die DVIN physischen Messungen, die für Steuereinheiten eindeutig sind, zusammen mit digitalen Signaturverfahren verwenden kann, um Diagnosegeräte und Remote-Back-End-Services dazu zu bringen, die behauptete Identität eines Fahrzeugs erfolgreich zu verifizieren. Das offenbarte System und die Methoden sehen zum Beispiel vor, einen digitalen Fingerabdruck zu generieren, ohne auf ein Hardware-Sicherheitsmodul (HSM) oder ein zuverlässiges Plattform-Modul bzw. Trusted Platform Module (TPM) angewiesen zu sein.
Auch hier identifizieren die Hersteller ein Fahrzeug auf herkömmliche Weise anhand der physischen VIN (z. B. VIN 102), die ein eindeutiger, bei der Herstellung erzeugter Code sein kann, der auf mehreren physischen Komponenten eines Fahrzeugs angebracht (z. B. eingeprägt) werden kann. Die physische VIN kann an ein bestimmtes Fahrzeug (z. B. Fahrzeug 112) gebunden sein und soll die Wahrscheinlichkeit verringern, dass ein Unbefugter die Identität eines Fahrzeugs fälschen kann. Da der Nachweis der VIN eines Fahrzeugs jedoch physisch ist, ist in der Regel ein physischer Zugang erforderlich, um die Identität des Fahrzeugs zu bestätigen. Eine eventuelle Lücke bei einem solchen Vorgehen besteht darin, dass eine oder mehrere elektronische Einheiten innerhalb eines Fahrzeugs (z. B. elektronische Steuereinheiten oder „ECUs“) die physische VIN des Fahrzeugs im Speicher oder einem anderen digitalen Datenträger speichern können. Da diese Steuereinheiten im Rahmen eines Rückrufs oder einer Reparatur ausgetauscht werden können, kann die physische VIN beim Austausch von Geräten im Auto mit Hilfe spezieller Diagnosewerkzeuge des Herstellers kopiert werden.
Die mit der physischen VIN verbundenen Gefahren haben sich durch die jüngsten Verletzungen von Datenbanken, in denen Millionen von Fahrzeug-VINs assoziiert mit persönlichen Daten des Fahrzeugbesitzers (z. B. Kundennamen, Telefonnummern, Adressen, Geburtsdaten, Geschlecht usw.) gespeichert sind, immer mehr erhöht. Betrüger könnten die gestohlenen physischen VINs und persönlichen Daten verwenden, um ein neues VIN-Kennzeichen zu erstellen und einen gefälschten Eigentumsnachweis für ein Fahrzeug zu erhalten. Sobald die Betrüger das gestohlene Auto und die physische VIN-Nummer aus der Datenbank haben, kann das Fahrzeug an einen arglosen Käufer weiterverkauft werden. Leider merkt der Käufer möglicherweise nicht, dass das Fahrzeug gestohlen ist, so dass er keinerlei Regressansprüche gegen die Täter geltend machen kann, auch nicht gegen das Geld, das zum Kauf des gestohlenen Fahrzeugs verwendet wurde.
Es wird in Betracht gezogen, dass die DVIN mehrere Vorteile gegenüber den herkömmlichen physischen VINs bieten könnte. Erstens kann die DVIN in jeder Datenbank eindeutig festgelegt werden. Zweitens wäre die DVIN kein physischer Wert, der in einem Fahrzeug vorhanden oder auf Fahrzeugteilen sichtbar wäre, wodurch die Möglichkeit des Diebstahls oder der Duplizierung der DVIN ausgeschlossen wäre. Drittens kann die DVIN so generiert werden, dass sie ohne ordnungsgemäße und verifizierte Berechtigungsnachweise nur schwer zu vervielfältigen sein dürfte.
Darüber hinaus kann eine physische VIN, die über eine oder mehrere bekannte Datenübertragungsschnittstellen (z. B. drahtgebunden oder drahtlos) übertragen wird, gefälscht werden, da es sich um Daten handelt, die physisch im Speicher des Fahrzeugs gespeichert sind oder sich visuell auf einem oder mehreren Fahrzeugteilen befinden. Ohne die Möglichkeit, die physische VIN zu verifizieren, ist ein ferngesteuertes System möglicherweise nicht in der Lage zu bestätigen, dass eine physische VIN einem bestimmten Fahrzeug gehört (d. h. zugeordnet ist).
Die DVIN kann daher ähnlich funktionsfähig sein wie die physische VIN, jedoch ist zum Verifizieren der Authentizität kein physischer Zugang erforderlich. Stattdessen werden verschiedene Softwareanwendungen in Betracht gezogen, um einen digitalen Dienst zu ermöglichen, der wiederum die Identität eines Fahrzeugs authentifizieren kann. Außerdem ist die herkömmlich verwendete physische VIN sichtbar und kann möglicherweise von jedem, der Zugang zum Fahrzeug hat, erfasst werden, wenn sie in einem Speichergerät im Fahrzeug gespeichert ist. Eine DVIN kann jedoch für den Fahrzeugeigentümer privat zugänglich sein, da sie normalerweise nicht an andere Dritte weitergegeben wird. Die Verwendung einer programmierten physischen VIN kann nicht ausreichend authentisch sein, da sie von einem Betrüger leicht geändert oder modifiziert werden kann. Die DVIN kann jedoch Fahrzeuge eindeutig identifizieren, indem sie die physische VIN mit einem oder mehreren digitalen Fingerabdrücken kombiniert.
Die Generierung des offenbarten DVIN kann auch auf erweiterten Zufallsquellen aus verschiedenen Quellen innerhalb eines Fahrzeugs basieren. Zu den Quellen können beispielsweise die zeitliche Verteilung von Antwortnachrichten auf Unified Diagnostic Service (UDS)-Nachrichten oder andere ausgewählte CAN-Nachrichten zwischen bestimmten Steuereinheiten des Fahrzeugs, die Leistungsverteilung einer Fahrzeugbatterie, die Leistungssignatur der in bestimmten Steuereinheiten laufenden Software, die durch Messung des Energieverbrauchs der Steuereinheit bei der Ausführung bestimmter Softwareversionen ermittelt wird, oder der Einschaltzustand des statischen Speichers mit wahlfreiem Zugriff (SRAM) gehören. Die Generierung, der Betrieb und die Verwendung verbesserter Zufallsquellen werden in der US-Patentanmeldung Nr. 17/445,758 in Betracht gezogen und offenbar gemacht, die hier durch Bezugnahme aufgenommen wird.
Die Quellen, die starke Zufallsquellen generieren können, können auch zur Bereitstellung oder Generierung von Fingerabdrücken verwendet werden, die wiederum zum Generieren des DVIN verwendet werden. Die Motor-Steuereinheit 110 kann zum Beispiel einen SRAM-Speicher enthalten. Die Zellen innerhalb des SRAM-Speichers können neutral verschoben sein, um sichere Zufallszahlen zu erzeugen, sie können aber auch positiv oder negativ verschoben sein, um sichere Fingerabdrücke für eine bestimmte Person zu erzeugen. Die Auswahl des richtigen Satzes von Messungen kann dann verwendet werden, um einen Fingerabdruck für ein einzelnes Gerät (z.B. Steuereinheit 110) zu erstellen. In der vorliegenden Offenbarung wird in Betracht gezogen, einen oder mehrere Fingerabdrücke zu verwenden, um eine Identität für das gesamte Fahrzeug zu generieren. Das offenbarte System und Verfahren kann dann verwendet werden, um einen Fingerabdruck zu erstellen, der auf ein Fahrzeug und nicht nur auf eine einzelne Steuereinheit oder Steuerrichtung hinweist. Der digitale Fingerabdruck kann dazu verwendet werden, die DVIN zu erzeugen, um sicherzustellen, dass nicht kompromittierte Fahrzeuge nur eine bestimmte VIN für sich beanspruchen können.
Das offenbarte System und Verfahren kann auch einen digitalen Fingerabdruck für die Steuereinheit des Fahrzeugs liefern, der wiederum zur eindeutigen Identifizierung eines Fahrzeugs verwendet werden kann. So kann der digitale Fingerabdruck beispielsweise Messungen von allen oder einer Teilmenge der Steuereinheiten eines Fahrzeugs enthalten, ohne dass zusätzliche Hardware (z. B. ein zusätzliches Hardware-Sicherheitsmodul oder ein zuverlässiges Plattform-Modul) erforderlich ist. Ohne die Notwendigkeit zusätzlicher oder eindeutiger Hardware kann das offenbarte System und Verfahren bei zahlreichen Aktivitäten eingesetzt werden, bei denen eine Verifizierung der Identität eines Fahrzeugs erforderlich ist, aber der physische Zugang zum Fahrzeug möglicherweise nicht leicht möglich ist. Die Systeme und Verfahren können beispielsweise dazu verwendet werden, Fingerabdrücke für Fahrzeugflotten (z. B. für Ridesharing oder autonome Fahrzeugflotten), für eine bestimmte Marke und ein bestimmtes Modell des Fahrzeugs (z. B. Ford Mustang Mach-E) oder für ein Fahrzeug mit einer bestimmten physischen Komponente (z. B. ein Elektrofahrzeug mit einem bestimmten Batteriemodul) zu erstellen.
Es wird weiterhin erwogen, dass das offenbarte System und Verfahren keine Änderungen oder Hardware erfordert, die über das hinausgeht, was derzeit in einem Fahrzeug vorhanden ist. Stattdessen können das offenbarte System und die Methode mit der vorhandenen Hardware betrieben werden, die derzeit in einem Fahrzeug enthalten ist, und können durch Software-Modifikationen an derzeit vorhandenen Steuereinheiten implementiert werden. Es wird auch in Betracht gezogen, dass das offenbarte System und Verfahren keine intensiven Prozessoroperationen erfordert, da ein Großteil der erforderlichen Verarbeitung zur Generierung eines Fingerabdrucks von einem entfernten Remote-Back-End-Server ausgeführt werden kann. Der Fingerabdruck selbst kann daher außerhalb eines bestimmten Fahrzeugs gespeichert werden, und der Back-End-Server kann die Vorgänge zum Bestimmen des digitalen Fingerabdrucks eines beliebigen Fahrzeugs ausführen. Schließlich kann das vorgeschlagene System und Verfahren auch in anderen Bereichen als dem Automobilbau eingesetzt werden, z. B. in der Luft- und Raumfahrt, in der industriellen Steuerrichtung und in der Gebäudesteuerungstechnik.
Das in Betracht gezogene DVIN kann daher Sicherheitseigenschaften bieten, die über die derzeit von einem Fahrzeug gebotenen Eigenschaften hinausgehen, die von Betrügern gefährdet werden können. Zum Beispiel können das offenbarte System und das Verfahren dazu beitragen, die Wahrscheinlichkeit zu verringern, dass ein Betrüger die Hardware und/oder Software eines Fahrzeugs kompromittieren kann. Wenn der Betrüger die Hardware oder Software des Fahrzeugs nicht kompromittieren kann, ist ein Remote-Back-End möglicherweise dazu in der Lage, eine DVIN anzufordern und einen gültigen Fingerabdruck für das Fahrzeug zu erhalten.
Das offenbarte System und Verfahren kann auch bei Hardware-Modifikationen oder Änderungen helfen, die an einem bestimmten Fahrzeug (z. B. Fahrzeug 112) vorgenommen werden können. 2 veranschaulicht zum Beispiel die vorstehend unter Bezugnahme auf 1 beschriebene DVIN 100. Wie veranschaulicht, kann ein Fahrzeugbesitzer die Hardware seines Fahrzeugs freiwillig ändern (z. B. die Motor-Steuereinheit 110 durch die Motor-Steuereinheit 110a ersetzen). Bei einer solchen Änderung sollte ein gesicherter Mechanismus verwendet werden, um den Fingerabdruck für die neue Hardware oder das Subsystem zu registrieren. Wenn zum Beispiel die Motor-Steuereinheit 110 durch die Motor-Steuereinheit 110a ersetzt wird, kann der Installateur die bisherige DVIN (z. B. DVIN 100) und den Fingerabdruck für die neue Motor-Steuereinheit 110a bereitstellen, um eine neue DVIN (nicht veranschaulicht) für das Fahrzeug 112 zu generieren.
Darüber hinaus können das offenbarte System und Verfahren bei einer Softwarekompromittierung eingesetzt werden. Wenn der Betrüger die Software einer Steuereinheit im Fahrzeug (z. B. Steuereinheit 110) kompromittieren kann, wäre es wichtig, eine solche Kompromittierung zu erkennen, da ein Betrüger versuchen könnte, eine neue DVIN zu fälschen. Wenn der Betrüger jedoch die Software einer einzelnen Steuereinheit (oder einer Teilmenge davon) kompromittiert (z. B. Steuereinheit 110), ohne alle anderen Steuereinheiten (z. B. Steuereinheiten 104, 106, 108) zu beeinflussen oder zu kompromittieren, kann der Betrüger bei der Kompromittierung der DVIN erfolglos sein. Es wird auch in Betracht gezogen, einen ungültigen Fingerabdruck oder eine ungültige DVIN zu identifizieren, wenn ein Betrüger den Verkehr beeinträchtigt, indem er den Ausgang einer oder mehrerer Steuereinheiten kompromittiert.
Das vorliegende System und Verfahren sollen die Möglichkeit verringern, dass ein Fingerabdruck verändert oder gefälscht wird, da der Fingerabdruck für das Fahrzeug 112 nicht auf einer einzelnen Steuereinheit, sondern auf einer Vielzahl von Steuereinheiten (d. h. den Steuereinheiten 104-110) basieren kann. Um DVIN 100 zu fälschen, müsste ein Betrüger den Fingerabdruck einer großen Anzahl von Steuereinheiten im Fahrzeug 112 verändern. Wenn die DVIN 100 beispielsweise mit den Fingerabdrücken von 20 Geräten innerhalb des Fahrzeugs 112 (einschließlich der Steuereinheiten 104-110) generiert wird, bräuchte der Betrüger alle 20 eindeutigen Fingerabdrücke, die zur Generierung der DVIN verwendet werden. Ein Betrüger müsste daher die Fingerabdrücke aller Geräte (d. h. Steuereinheiten) des Fahrzeugs 112 verändern, was schwierig und teuer wäre.
Schließlich können das vorliegende System und die Methode auch bei einer Hardware-Kompromittierung eingesetzt werden. Zum Beispiel könnte ein Betrüger in der Lage sein, die Hardware der Steuereinheit 110 zu kompromittieren. Nach der Kompromittierung könnten die von der Steuereinheit 110 erhaltenen Informationen dazu verwendet werden, eine Handvoll Fahrzeuge auf einmal anzugreifen. Ebenso kann ein Betrüger, der über diese Zugriffsmöglichkeit verfügt, Angriffe mit größerer Wirkung (z. B. Fernzugriff auf die Steuerrichtung des Fahrzeugs) starten, bei denen die Änderung des Fingerabdrucks nicht das beabsichtigte Ziel ist. Durch die Generierung einer DVIN aus mehreren eindeutigen Fingerabdrücken kann eine physische Sicherheit geschaffen werden, die es Betrügern unmöglich macht, auf ein Fahrzeug zuzugreifen oder es zu steuern, das ihnen nicht gehört. Die DVIN (z. B. DVIN 100) kann daher funktionsfähig sein, um einen digitalen Fingerabdruck zu erzeugen, der mit einer physischen VIN (z. B. VIN 102) verknüpft ist, solange ein Betrüger nicht die eigentliche Hardware des Fahrzeugs 112 kompromittiert.
Um einen digitalen Fingerabdruck für das Fahrzeug 112 zu generieren, muss eine gesicherte Quelle für die Identität des Fahrzeugs ausgewählt werden. Dies kann durch die Suche nach einer Metrik erreicht werden, die für eine bestimmte Steuereinheit (z. B. Steuereinheit 110) gemessen werden kann. Sobald eine Metrik ausgewählt ist, kann der Fingerabdruck aus der Kombination dieser Multi-Steuereinheit-Messungen generiert werden (d. h. Messungen für alle verwendeten Steuereinheiten). Auch hier können mehrere Einheiten innerhalb des Fahrzeugs 112 (z. B. Steuereinheiten 104-110) verwendet werden, um sicherzustellen, dass ein Angreifer, der die Kontrolle über mindestens eine Steuereinheit (z. B. Steuereinheit 104) hat, die Identität des Fahrzeugs nicht fälschen oder verschleiern kann. Die gewählte Metrik kann sich auch auf physische Eigenschaften stützen, die schwer zu fälschen, zu replizieren, zu simulieren und/oder zu kopieren sind (z. B. wie die menschliche Biometrie).
Da es für einen Angreifer schwierig sein kann, ein physisches Fahrzeug zu verändern (insbesondere bei groß angelegten Angriffen), können physik-basierte Metriken wie Spannung und Zeitmessung verwendet werden. Die Auswertung der Messungen physik-basierter Metriken, die gesammelt wurden, muss unter Umständen ebenfalls ausgewertet werden, um sicherzustellen, dass ein gesicherter Fingerabdruck generiert wird. Wie oben erläutert, kann beispielsweise eine schiefe Speichereinheit innerhalb einer bestimmten Steuereinheit (z. B. eine SRAM-Zelle) zur Erstellung eines Fingerabdrucks verwendet werden. Wenn also eine bestimmte Steuereinheit (z.B. Steuereinheit 110) ausgewählt wird, kann sie aufgefordert werden, eine Messung ihres SRAM vorzunehmen. Unter der Annahme, dass die Steuereinheit 110 nicht manipuliert wurde, könnte ein Angreifer, der die Kontrolle über die Software der Steuereinheit 110 hat, in der Lage sein, den SRAM-Fingerabdruck zu verändern. Es wird daher in Betracht gezogen, für jede einzelne Steuereinheit (z.B. Steuereinheit 110), die aufgefordert wird, Messungen zu liefern, zu überlegen, wie ein Unbefugter diese Messungen kompromittieren könnte. Dabei sollte sichergestellt werden, dass sowohl die physischen als auch die Software-Komponenten einer Steuereinheit nicht gefährdet werden können.
Wie oben erläutert, können Leistungsmessungen erfasst werden, wie in der US-Patentanmeldung 17/445,758 offenbart, die hier durch Bezugnahme aufgenommen wird. Die Leistungsmessungen können auch erfasst werden, während die Software läuft, und ein Software-Fingerabdruck kann generiert werden. Die Stärke des Fingerabdrucks kann von der gewählten Metrik und der Fähigkeit eines Gegners abhängen, den Fingerabdruck zu duplizieren oder zu simulieren. Wenn jedoch eine kompromittierte Steuereinheit den Netzwerkverkehr beeinträchtigt, dann kann jede Sammlung von Nachrichtenzeitpunkten eine gefälschte DVIN identifizieren und die Anwesenheit eines Betrügers erkennen.
Es wird auch in Betracht gezogen, dass die Fingerabdruckdaten für eine bestimmte Steuereinheit nur von einem System außerhalb des Fahrzeugs 112 messbar sein sollten. 1 veranschaulicht zum Beispiel, dass das Fahrzeug 112 funktionsfähig ist, um mit einem externen Server 114 zu kommunizieren. Es wird in Betracht gezogen, dass das Fahrzeug 112 mit dem externen Server über ein drahtloses Kommunikationsprotokoll (z. B. WIFI, Mobilfunk oder BlueTooth) oder ein kabelgebundenes Kommunikationsprotokoll kommunizieren kann. Es wird auch in Betracht gezogen, dass die Steuereinheiten (z. B. die Steuergeräte 104-110) im Fahrzeug 112 den auf dem Server 114 gespeicherten Fingerabdruck nicht speichern sollten. Stattdessen sollten die Steuereinheiten funktionsfähig sein, um Metriken für den Server 114 (d.h. ein externes System) zur Messung bereitzustellen. Die Speicherung auf dem externen System wie Server 114 sollte manipulationssicher sein. Es wird auch in Betracht gezogen, dass das Fahrzeug 112 nicht funktionsfähig ist, um mit dem Server 114 während oder im Hinblick auf die Erstellung der Signatur zu kommunizieren. Stattdessen kann der Server 114 einen Back-End-Service betreiben, um die Signatur zu erzeugen, nachdem er die physischen Messungen von den Steuereinheiten des Fahrzeugs in einer gesicherten Umgebung gesammelt hat (eine Umgebung, die garantiert nicht unter der Kontrolle eines böswilligen Angreifers für eine begrenzte Zeitspanne steht).
Die Signatur darf nicht in einer Speichereinheit innerhalb des Fahrzeugs 112 gespeichert werden, und das Fahrzeug 112 sollte nicht mit dem Server 114 zusammenarbeiten, der die Signatur erzeugt, um die Sicherheit einer eindeutigen Kennung zu gewährleisten (d. h. einer Signatur, die nicht von einem Betrüger beeinträchtigt oder kompromittiert wurde). So kann der Back-End-Service, der auf dem Server 114 arbeitet, verwendet werden, um einen Fingerabdruck aus den Messungen zu erstellen, die das Fahrzeug 112 liefert. In bestimmten Anwendungen kann der Fingerabdruck des Fahrzeugs von Dritten bereitgestellt und verifiziert werden, und die Fähigkeit, den Fingerabdruck zu verifizieren, darf nicht auf eine einzige vertrauenswürdige Partei beschränkt sein. Der Fingerabdruck sollte auch vom Fahrzeug 112 generiert werden, dessen Fingerabdruck verifiziert werden soll. Wenn eine Partei den Fingerabdruck nicht ändern kann, kann das Fahrzeug 112 zu Werbezwecken, zur Mautüberwachung usw. verfolgt werden. Außerdem kann der Fingerabdruck so gestaltet werden, dass er unveränderliche Merkmale des Fahrzeugs 112 enthält, wodurch sichergestellt wird, dass ein Betrüger einen bestimmten Fingerabdruck nicht fälschen kann.
Auch hier kann die physik-basierte Metrik, die zur Generierung der für den Fingerabdruck verwendeten Messungen verwendet wird, wie die Methoden zur Generierung biometrischer menschlicher Fingerabdrücke generiert werden. Bei biometrischen Fingerabdrücken wird beispielsweise versucht, eindeutige Merkmale zur Identifizierung einer bestimmten Person zu ermitteln. Würde man versuchen, jeden einzelnen Grat auf dem Finger einer Person zu vermessen, wäre eine aussagekräftige Unterschrift möglicherweise nicht zu erzielen. In der Praxis ist es möglich, dass die vom Fingerabdruck einer Person erhaltenen Messungen nicht immer gleich sind (z. B. können Abweichungen aufgrund von Rauschen auftreten). Infolge physischer Abweichungen bei der Erfassung (z. B. Druck, Tintenauftrag, Rauschen usw.) sieht ein Fingerabdruck nicht immer gleich aus, aber es können dennoch bestimmte Merkmale gemessen werden, die einer Person zugeordnet werden können. Das vorliegende System und Verfahren zieht ähnliche Herausforderungen in Betracht, wenn Messungen in der digitalen Welt durchgeführt werden. Zum Beispiel können die gesammelten Metriken einen Fingerabdruck ergeben, der eine „unscharfe Signatur“ erzeugt (d. h. eine Signatur, die nicht jedes Mal genau gleich aussieht). Es wird in Betracht gezogen, dass verschiedene kryptografische Techniken nicht verwendet werden können, wenn nicht immer die gleiche Signatur erzeugt wird, da der gleiche Schlüssel erwartet wird.
Es wird daher in Betracht gezogen, einen unscharfen kryptografischen Algorithmus einzusetzen, um eine eindeutige digitale Identität des Fahrzeugs zu erzeugen, die für kryptografische Signaturverfahren verwendet werden kann. Der „unscharfe Fingerabdruck“ kann (1) eine Identität und (2) eine akzeptable Abweichung zwischen einzelnen Messungen enthalten. Ein Fuzzy-Extraktor kann dann eingesetzt werden, um die generierte Identität aus der Eingabe zu extrahieren, wenn die extrahierte Identität innerhalb der akzeptablen Abweichung liegt. Diese Varianz hängt von dem vom Fuzzy-Extraktor verwendeten Konstrukt ab. Der Extraktor stützt sich auf fehlerkorrigierende Codes, um die gemessene Fuzzy-Signatur anzupassen und die wahre Fuzzy-Signatur zu erzeugen. Diese Codes funktionieren nur innerhalb dieser akzeptablen Varianz, so dass wir sicherstellen können, dass eine Identität wahr ist, solange ein Angreifer die Eingaben nicht replizieren kann (oder auch nur in die Nähe davon kommt). Sobald wir den Fuzzy-Extraktor zur Ableitung eines Schlüssels verwenden, können wir diesen Schlüssel als eindeutige digitale Kennung des Fahrzeugs und für alle bekannten kryptografischen Signaturverfahren verwenden.
3 veranschaulicht ein Flussdiagramm 300 eines Registrierungsprozesses, der zur Ableitung einer Fahrzeugidentität in Form eines Schlüssels unter Verwendung eines Fuzzy-Extraktors verwendet wird. In Schritt 302 kann zunächst ein Back-End/Registrierungs-Service initiiert werden. Der Back-End-/Registrierungs-Service kann auf dem Server 114 außerhalb des Fahrzeugs 112 betrieben werden. Der Back-End-/Registrierungs-Dienst kann Prozesse initiieren, die in Abhängigkeit von der gewählten Metrik für die digitale Identifizierung gestartet werden sollten. So kann das Fahrzeug 112 beispielsweise die physische VIN 112 an das Backend (d. h. den Server 114) übermitteln, wo eine Datenbank durchsucht werden kann, um den erwarteten Fingerabdruck durch seine Registrierung zu finden. Auch hier sollte die gewählte Metrik physikbasiert sein und von einem entfernten Angreifer nicht leicht verändert (kopiert, simuliert, gefälscht usw.) werden können. Es wird auch in Betracht gezogen, den Registrierungsprozess für eine DVIN (z. B. DVIN 100) in einer gesicherten Umgebung/an einem gesicherten Ort (z. B. in einem manipulationssicheren Speicher auf dem Server 114) zu speichern, der für einen Betrüger nicht zugänglich ist oder von ihm kontrolliert werden kann. Alternativ könnte die Datenbank durch die VIN indiziert werden, so dass man nicht nach der nächstliegenden Übereinstimmung des Fingerabdrucks suchen muss, sondern einfach verifizieren kann, dass der Fingerabdruck der VIN entspricht. Bei der VIN kann es sich in diesem Fall um die herkömmliche VIN oder eine zusätzliche eindeutige Kennung handeln, die vom Diensteanbieter zur Identifizierung des Fahrzeugs verwendet wird. Ein weiteres Beispiel für eine solche Kennung könnte durch Berechnung des Hashwerts der Hilfsdaten (Fehlerkorrekturdaten) erzeugt werden, die mit einer bestimmten DVIN assoziiert sind. In diesem Fall würde die Datenbank wahrscheinlich aus mindestens drei Spalten bestehen: eine Spalte mit dem Hash der Hilfsdaten (Fehlerkorrekturdaten), eine Spalte mit den Hilfsdaten selbst und eine Spalte mit dem erwarteten Fingerabdruck. Bei einigen Implementierungen muss die dritte Spalte nicht unbedingt enthalten sein.
In Schritt 304 kann das Fahrzeug 112 auch die erfassten Messwerte an den Server 114 übertragen, der den Back-End-Service betreibt. Der Back-End-Service kann die „Fuzzy-Signaturen“ (d. h. Signale) sammeln und die gesammelten Fuzzy-Signaturen verwenden, um einen Datenpool zu erstellen. In Schritt 306 bestimmt das Flussdiagramm 300, ob der Erfassungs- und Datenpoolprozess wiederholt werden sollte. Falls ja, kann Schritt 304 wiederholt werden, damit der Back-End-Service die Merkmale charakterisieren kann, die für das Fahrzeug 112 eindeutig sind oder die als optimal (d. h. robuster) für die Identifizierung des Fahrzeugs 112 angesehen werden können. Es wird in Betracht gezogen, dass diese Messungen von mehreren Steuereinheiten (z. B. den Steuereinheiten 104-110) im Fahrzeugnetzwerk vorgenommen werden können. Wie bereits erwähnt, sollten die Messungen vorzugsweise nicht von einer einzelnen Quelle (d. h. einer einzelnen Steuereinheit) stammen. Die Messungen von mehreren Steuereinheiten können auch als ein einzelnes Datenarray dargestellt werden. Das erzeugte Datenarray kann eine Verkettung aller Messungen sein, wodurch die verrauschten Messungen innerhalb des Fahrzeugs 112 berücksichtigt werden.
In Schritt 308 kann der Back-End-Service dann einen Fehlerkorrekturalgorithmus an den Daten im Datenpool durchführen. Die Art der Fehlerkorrektur kann je nach dem gewählten Konstrukt variieren. In Schritt 310 kann der Back-End-Service die Fehlerkorrekturdaten mit dem Datenpool kombinieren. In Schritt 312 kann der Back-End-Service bestätigen, dass der abgeleitete Schlüssel mit hoher Wahrscheinlichkeit aus den Fahrzeugmessungen rekonstruiert werden kann. Es wird in Betracht gezogen, dass die Bestätigung einen Identitätsnachweis liefert und je nach Anwendung mit einem einzelnen oder gegenseitigen Authentifizierungsprotokoll kombiniert werden kann. In Schritt 314 können die Fehlerkorrekturinformationen dann mit den Messungen (d. h. „Hilfsdaten“) kombiniert werden, die sicher auf dem Server 114 gespeichert werden können, auf dem der Back-End-Service arbeitet.
4 veranschaulicht ein Flussdiagramm 400 eines Verifizierungsprozesses, der vom Back-End-Service bei einer Abfrage oder Verifizierung eines DVIN (z. B. DVIN 100) durchgeführt werden kann. In Schritt 402 kann der Back-End-Service damit beginnen, die Verifizierung der Identität vom Fahrzeug 112 anzufordern. In Schritt 404 kann das Fahrzeug 112 eine Mehrzahl von Messungen, die von internen Steuereinheiten (z. B. den Steuereinheiten 104-110) erfasst wurden, über einen vertraulichen und authentifizierten Kanal an das Back-End übertragen. Beispielsweise kann das Fahrzeug 112 die Messungen über einen gesicherten Kanal wie Transport Layer Security (TLS) übertragen, der zur Verschlüsselung der übertragenen Daten verwendet werden kann.
In Schritt 406 kann der Back-End-Service den Schlüssel rekonstruieren, der mit den vom Fahrzeug 112 empfangenen Messungen assoziiert ist. Der Back-End-Service kann einen Hilfsdaten-Algorithmus enthalten, der den Schlüssel rekonstruiert, indem er die aktuelle Messung mit den Hilfsdaten kombiniert. In Schritt 408 kann der Back-End-Service ein gegenseitiges Authentifizierungsprotokoll mit dem Fahrzeug 112 initiieren. In Schritt 410 kann der Back-End-Service bestimmen, ob das Authentifizierungsprotokoll gültig ist. Wenn ja, kann das Backend bestimmen, welches Fahrzeug (z. B. Fahrzeug 112) der behaupteten Identität entspricht oder mit ihr assoziiert ist. Falls nein, kann der Back-End-Service bestimmen, dass die Anfrage ungültig ist und zu Schritt 402 zurückkehren, um die Anfrage erneut zu initiieren. Es wird auch in Betracht gezogen, eine Fehlermeldung zu generieren, die darauf hinweist, dass eine ungültige Authentifizierung generiert wurde.
Es wird in Betracht gezogen, dass das Flussdiagramm 400 von einer beanspruchten Identität ausgeht, die mit den Fahrzeugmessungen assoziiert ist. Die beanspruchte Identität könnte die physische VIN (z. B. VIN 402) in Anwendungen sein, die darauf abzielen, die mit dem Fahrzeug 112 assoziierten Informationen zu verifizieren. Beispielsweise kann die beanspruchte Identität verwendet werden, um zu verhindern, dass das Fahrzeug 112 gestohlen wird und eine gefälschte VIN, die mit dem Fahrzeug 112 assoziiert ist, generiert und einem unverdächtigen Käufer vorgelegt wird.
In anderen Anwendungen können die Flussdiagramme 300 und 400 verwendet werden, wenn die Möglichkeit einer gefälschten Identität besteht. Zum Beispiel könnte der Back-End-Service dem Fahrzeug eine zufällige Identität zuweisen. Alternativ dazu kann es in einigen Anwendungen keine feste Identität geben, die vom Fahrzeug beansprucht wird. In solchen Fällen kann der Back-End-Service versuchen, das Fahrzeug 112 basierend auf den durchgeführten Messungen zu identifizieren. In diesem Fall kann ein linearer Berechnungsaufwand mit der Suche nach der besten Übereinstimmung für eine bestimmte Identität assoziiert sein.
Ferner wird in Betracht gezogen, bei der Implementierung des Fuzzy-Extraktors einen Fingerabdruck jedes Mal mit demselben Schlüssel zu rekonstruieren. Als solcher kann der Schlüssel für normale Unterschriftssysteme, wie digitale Unterschriften und die Überprüfung der Identität, verwendet werden. Um jedoch zu gewährleisten, dass der Schlüssel für solche Signaturen oder Verifizierungen verwendet werden kann, können auch zusätzliche Funktionen eingebaut werden.
So kann beispielsweise ein fahrzeugexternes Fingerabdruck-Verfahren implementiert werden, bei dem die Messungen, die als Eingabe für den Fuzzy-Extraktor dienen (wie z. B. das Timing von Netzwerknachrichten oder die Spannung von Datenpunkten), vom Fahrzeug 112 an den Server 114 (d. h. den Back-End-Service) übertragen werden können. Der Back-End-Service kann den Fingerabdruck berechnen, und wenn der Back-End-Service bestimmt, dass der Fingerabdruck verwendet werden kann, um jedes Mal denselben Schlüssel zu rekonstruieren, kann der abgeleitete Schlüssel für normale Signaturverfahren (z. B. digitale Signatur und Identitätsprüfung) verwendet werden.
Bei einem fahrzeugexternen Fingerabdruck-Verfahren kann ein sicheres Gateway oder eine vertrauenswürdige Gruppe von Steuereinheiten eingesetzt werden, um die Netzdaten über einen verschlüsselten sicheren Kanal an den Back-End-Service zu übertragen. Der gesicherte Kanal kann so eingerichtet werden, dass ein Betrüger diese Netzwerkdaten nicht abhören und möglicherweise den Fingerabdruck ableiten kann. Für den Back-End-Service kann ein Fehlerkorrekturcode für den Fuzzy-Extraktor und die Rekonstruktion des Schlüssels verwendet werden. Der fehlerkorrigierende Code kann so eingerichtet werden, dass ein normales Signaturschema implementiert werden kann.
Es wird auch in Betracht gezogen, den Fingerabdruck außerhalb des Fahrzeugs für andere Anwendungen zu verwenden, z. B. zwischen einem Erstausrüster und einem Anbieter (oder einem anderen Dritten, der kein Erstausrüster ist). So kann der Erstausrüster beispielsweise als Vermittler zwischen einem Anbieter und dem Fahrzeug 112 fungieren. In diesem Beispiel kann der Anbieter eine Bestätigung verlangen, dass seine Werbung ein geeignetes Fahrzeug (z. B. das Fahrzeug 112) erreicht. Der Anbieter kann auch verhindern wollen, dass der OEM bestimmte Informationen oder Daten vom Anbietern abgreift. So kann das Fahrzeug 112 Netzwerkdaten zum Zweck des Fingerabdrucks an einen Back-End-Service des OEM (z. B. über Server 114) übermitteln. Basierend auf der Anfrage kann der OEM die vom Fahrzeug 112 empfangenen Netzwerkdaten an einen oder mehrere Anbieter weiterleiten. Die Anbieter können einen individuellen Fuzzy-Extraktor verwenden, der sich von dem oben beschriebenen Fuzzy-Extraktor unterscheiden kann. Da jeder Anbieter seinen eigenen Fuzzy-Extraktor implementieren kann, kann der Anbieter seine eigene Version der Identität eines bestimmten Fahrzeugs (z. B. die Identität des Fahrzeugs 112) beibehalten. Der Anbieter muss also nicht unbedingt einen einzelnen Fingerabdruck mit dem OEM oder einem Dritten teilen. Der separate Fingerabdruck kann es dem Inserenten (oder Dritten) ermöglichen, die Sicherheit der Identitäten zu wahren (d. h. die Identitäten zu verbergen), falls die abgeleiteten Identitäten als für den Inserenten geschützt angesehen werden.
In Betracht gezogen wird auch die Implementierung eines fahrzeuginternen Fingerabdruck-Verfahrens, bei dem ein einzelnes gesichertes Gateway oder eine vertrauenswürdige Gruppe von Steuereinheiten (z. B. die Steuereinheiten 104-110) die Netzwerkdaten des Fahrzeugs 112 messen kann. Basierend auf der Messung kann das fahrzeuginterne Fingerabdruck-Verfahren einen Schlüssel mit einem eingebauten Fuzzy-Extraktor errechnen. Dabei können die gesicherten Steuereinheiten des Fahrzeugs 112 alle erforderlichen Vorverarbeitungen durchführen und die Schlüssel berechnen, die an den Back-End-Service (z. B. den auf dem Server 114 betriebenen Back-End-Service) übermittelt werden. Das fahrzeuginterne Fingerabdruck-Verfahren sollte sicherstellen, dass jede Steuereinheit (z. B. Steuereinheit 110) Daten an den Fuzzy-Extraktor liefert, die jedes Mal die gleiche Antwort liefern können. Auch hier kann die Antwort von der verwendeten Metrik abhängen. Da ein Unbefugter in der Lage sein könnte, die Daten zu fälschen, die von nicht physik-basierten Informationen stammen (z.B. SRAM-Fingerabdruck), wird in Betracht gezogen, den Fingerabdruck zu diversifizieren. Auch das fahrzeuginterne Fingerabdruck-Verfahren sollte sicherstellen, dass es nicht leicht von einem Hacker oder Betrüger missbraucht werden kann. Dies wird in der Praxis häufig durch den Einsatz manipulationssicherer oder resistenter Hardware oder eines Systems zur Erkennung von Eindringlingen erreicht, das erkennt, wenn das System kompromittiert wurde.
Ein alternativer Ansatz für das fahrzeuginterne Fingerabdruck-Verfahren kann darin bestehen, die Fingerabdrücke der einzelnen Steuereinheiten (z. B. der Steuereinheiten 104-110) zu verknüpfen. Bei diesem Verfahren kann davon ausgegangen werden, dass jeder Teil-Fingerabdruck (z. B. der Fingerabdruck der Steuereinheit 110) etwas unscharf ist. Der Prozess kann auch fehlerkorrigierende Codes enthalten, um mögliche Fehler in der verketteten Fuzzy-Eingabe zu korrigieren. Um die Wirksamkeit zu bestimmen, kann der Prozess messen, wie weit jede Sub-Identität von der erwarteten Sub-Identität entfernt ist, und einen Schwellenwert festlegen. Solange die Sub-Identität innerhalb des durch die gewählten Fehlerkorrekturcodes definierten Schwellenwerts liegt, kann das Verfahren einen digitalen Fingerabdruck generieren und einen Schlüssel für ein beliebiges normales Signaturverfahren erzeugen. Das Verfahren kann so funktionieren, dass Fingerabdrücke ohne den Fehlerkorrekturcode weiter verglichen werden, um zu verifizieren, dass ein Fahrzeug seine vorgegebene Identität korrekt angibt. Es sollte darauf geachtet werden, dass nicht alle Fingerabdrücke von einem Angreifer, der die Kommunikation zwischen den Steuereinheiten (deren Fingerabdrücke gemessen werden) und dem Server, der die Fingerabdrücke zur Verifizierung sammelt, abhört, leicht gelesen werden können.
Es wird in Betracht gezogen, dass bei dem oben beschriebenen Ansatz keine einzelne Steuereinheit Kenntnis von ihren Fingerabdruck-Informationen haben kann. Stattdessen würden die Fingerabdruck-Informationen lediglich als Eingabe für den Fuzzy-Extraktor dienen. So kann ein Unbefugter, der eine Steuereinheit (z.B. Steuereinheit 110) manipuliert, den Fingerabdruck nicht verändern, weil er den eigentlichen Fingerabdruck nicht kennt. Ebenso funktionieren die oben genannten Verfahren basierend auf einem Fingerabdruck, der von mehreren Steuereinheiten (z. B. den Steuereinheiten 104-110) und nicht nur von einer einzelnen Steuereinheit (z. B. der Steuereinheit 110) stammt.
Es wird auch in Betracht gezogen, dass die Anzahl der zu verwendenden Metriken davon abhängt, welche Art von Metriken verwendet werden kann. Zum Beispiel können das offenbarte System und die Methoden je nach gewählter Metrik verschiedene Ansätze für den Fingerabdruck definieren. Der definierte Ansatz kann sich auf nur eine einzelne Metrik und nur eine Art von Messung von allen Steuereinheiten stützen (d. h. homogener Fingerabdruck). In Betracht gezogen wird, dass ein homogener Fingerabdruck durch die Auswahl einer Metrik funktioniert, die es einem Angreifer nicht ermöglicht, die Identität eines Fahrzeugs zu fälschen (z. B. die Identität von Fahrzeug 112). Die Metrik kann für jede Steuereinheit des Fahrzeugs 112 dieselbe sein. So kann man sich auf die ausgewählten Metriken (z. B. Leistungs- oder Zeitverteilungen) verlassen, da es für einen Angreifer schwierig wäre, sie zu fälschen und zu kontrollieren.
Das vorliegende Verfahren und die Systeme sehen jedoch vor, dass ein Angreifer einige der Daten fälschen kann, um den Back-End-Service zu zwingen, eine andere Identität zu erzeugen. Das offenbarte System und die Methoden können zum Beispiel SRAM-Fingerabdrücke als gewünschte Eingabe auswählen. Da der SRAM-Fingerabdruck mit Software gemessen werden kann und der Fingerabdruck von jeder Steuereinheit (z.B. Steuereinheit 110) an den Back-End-Service gesendet werden kann, kann ein Angreifer, der die Kontrolle über die Software hat, den generierten Fingerabdruck oder die Informationen gefährden. Infolgedessen kann ein heterogenes Fingerabdruck-Verfahren eingesetzt werden, bei dem eine andere physik-basierte Metrik ausgewählt wird, die in Kombination mit dieser software-gemessenen Metrik verwendet werden kann. Durch die Diversifizierung der Metriken kann die Wahrscheinlichkeit erhöht werden, dass ein falscher Fingerabdruck erkannt wird.
Es wird in Betracht gezogen, dass die Fähigkeit, ein eindeutiges Fahrzeug digital zu identifizieren, im Automobilbereich eine wichtige Rolle spielen kann. Das offenbarte System und Verfahren zur digitalen Authentifizierung eines Fahrzeugs kann zum Beispiel Folgendes umfassen: (1) die Bereitstellung maßgeschneiderter oder gezielter Dienste in Abhängigkeit von der Identität des Fahrzeugs; (2) die Fähigkeit, Betrug zu erkennen, wenn ein Fahrzeug eine VIN angibt, die ihm nicht gehört; (3) die Erkennung von Betrug durch die Identifizierung geänderter Fahrzeugfunktionen; (4) und die Erkennung einer Verletzung der fahrzeuginternen Netzkommunikation.
Im Hinblick auf die Bereitstellung maßgeschneiderter oder gezielter Dienste kann der Remote-Back-End-Service funktionsfähig sein, um Dienste basierend auf der Identität eines bestimmten Fahrzeugs (z. B. Fahrzeug 112) bereitzustellen. Wie oben beschrieben, können die maßgeschneiderten oder gezielten Dienste die Verwendung gezielter Anzeigen beinhalten, die die DVIN 100 des Fahrzeugs 112 empfangen und Daten aus dem Fahrzeugnetzwerk (d. h. Netzwerkdaten oder -informationen) verwenden, um bestimmte Anzeigen auszuwählen, die innerhalb des Fahrzeugs (z. B. auf einem Infotainmentsystem) angezeigt werden können. Solche zielgerichteten Anzeigen könnten ähnlich wie Webbrowser funktionieren, die dazu eingerichtet sind, die Benutzeroperationen beim Navigieren zwischen Websites durch Überwachung eines Computerprozesses zu verfolgen.
Für gezielte Dienste oder Werbung kann mit dem offenbarten System und Verfahren ein digitaler Fingerabdruck als Teil des DVIN (z. B. DVIN 100) generiert werden, der dann an den Remote-Back-End-Service (d. h. Server 114) übermittelt werden kann. Der Back-End-Service sollte funktionsfähig sein, um die DVIN 100 und einige Daten aus dem Fahrzeug 112 zu extrahieren, um maßgeschneiderte oder gezielte Dienste (z. B. Werbung) anzubieten. So kann beispielsweise davon ausgegangen werden, dass ein Angreifer das Fahrzeug 112 oder eine oder mehrere seiner Steuereinheiten (z. B. die Steuereinheiten 104-110) nicht manipuliert hat. Wenn ein Betrüger weder die Hardware noch die Software des Fahrzeugs 112 manipulieren kann, sollte der Remote-Back-End-Service funktionsfähig sein, um die Übermittlung von DVIN 100 anzufordern, und der Back-End-Service sollte funktionsfähig sein, um einen gültigen Fingerabdruck zu erhalten, ohne dass Spoofing zu befürchten ist.
Für gezielte Dienste oder Werbung kann das Fahrzeug 112 sowohl seine behauptete VIN (z. B. VIN 102) als auch Netzwerkdaten an einen Werbeserver übertragen. Der Werbeserver kann ähnlich wie der oben beschriebene Server 114 funktionieren, und das Fahrzeug 112 kann über eine drahtlose oder drahtgebundene Verbindung mit dem Werbeserver verbunden werden, wie oben beschrieben. Aus den vom Fahrzeug 112 übertragenen Daten kann der Anzeigenserver funktionsfähig sein, um einen Fingerabdruck zu generieren, indem er nach bestimmten Merkmalen im Timing von Netzwerknachrichten und möglicherweise der Spannung bestimmter Nachrichtendatenpunkte sucht. Sobald der Werbeserver einen digitalen Fingerabdruck generiert hat, verfügt er über eine DVIN (z. B. DVIN 100) für das Fahrzeug 112, die im Wesentlichen eine digital verifizierte VIN ist.
Der Anzeigenserver kann dann zielgerichtete Inhalte an das Fahrzeug 112 senden, da er weiß, dass die Werbung zu dem gewünschten Fahrzeug passt. Darüber hinaus kann der Anzeigenserver im Namen des Fahrzeugs 112 mit anderen Back-End-Services kommunizieren. So kann beispielsweise ein Anzeigenserver, der dem Erstausrüster gehört, mit anderen angeschlossenen Werbefirmen kommunizieren. Der Erstausrüster könnte also den Zugang zu den vom Fahrzeug 112 übertragenen Netzdaten oder Informationen kontrollieren. Der Erstausrüster könnte somit sicherstellen, dass Daten von Werbefirmen sicher und ordnungsgemäß an ein bestimmtes Fahrzeug (z. B. Fahrzeug 112) gesendet werden.
Im Hinblick auf die Fähigkeit, Betrug zu erkennen, wenn ein Fahrzeug eine VIN angibt, die ihm nicht gehört, kann es mehrere Anwendungen geben, bei denen ein Back-End-Service Betrug erkennen muss, wenn ein Fahrzeug angibt, die VIN eines anderen Fahrzeugs zu besitzen (z. B. VIN 102). Eine Anwendung kann zum Beispiel die Fähigkeit beinhalten, das Fahrzeug 112 und/oder eine Infrastruktur zu authentifizieren, die Teil eines Vehicle-to-Alles (V2X)-Kommunikationsprotokolls sind. Da V2X-Systeme auf gültige Informationen von anderen Fahrzeugen oder der Infrastruktur angewiesen sind, muss das offenbarte System und Verfahren möglicherweise ein bestimmtes Fahrzeug (z. B. Fahrzeug 112) authentifizieren und identifizieren. Wenn das Fahrzeug 112 seine Fahrzeuginformationen an nahegelegene V2X-Knoten überträgt, können diese Geräte die DVIN 100 bestätigen und verhindern, dass das Fahrzeug 112 seine Übertragungen zurückweist. Die Bestätigung kann das Fahrzeug 112 vor Betrügern schützen, die absichtlich bösartige Informationen fälschen, indem sie die übertragenen Informationen mit dem sendenden Fahrzeug in Verbindung bringen. Ebenso könnte die DVIN 100 verwendet werden, um ein Mauterfassungsgerät direkt mit dem Fahrzeug 112 zu verbinden. Auch dies kann Betrüger daran hindern, Fahrzeugkennzeichen oder Mauterfassungsgeräte zu vertauschen, um die Zahlung der Maut zu vermeiden, indem sie die Maut für andere Fahrzeuge als das Fahrzeug 112 erheben.
Wie bereits erwähnt, kann eine DVIN (wie DVIN 100) auch eine schwache (nicht kryptografisch erzwungene) Form der Nichtabstreitbarkeit bieten, die den Nachweis ermöglicht, dass ein Betrüger das Mauterfassungsgerät missbraucht hat. Der Vorteil einer DVIN gegenüber einer physischen VIN (wie VIN 102) besteht darin, dass durch die Verwendung der DVIN 100 sichergestellt werden kann, dass das Fahrzeug 112 tatsächlich die VIN 102 besitzt, für die es sich ausgibt, und dass jede Fälschung erkannt werden kann, ohne dass eine physische Überprüfung erforderlich ist. Eine solche Erkennung kann nur probabilistisch sein, da sie mit einer bestimmten, nicht zu vernachlässigenden Wahrscheinlichkeit fehlschlagen kann, im Gegensatz zu einer Methode, die auf Kryptographie beruht. Das offenbarte System und Verfahren kann jedoch auch ohne Kryptographie oder in Kombination mit Kryptographie verwendet werden, einschließlich Fällen, in denen die Kryptographie auf Anonymität ausgelegt ist.
Bei der Erkennung eines falschen Mauterhebungsgeräts (ähnlich wie bei der früheren Anwendung im Zusammenhang mit gezielter Werbung oder Diensten) kann ein Betrüger absichtlich versuchen, die falschen Mauterhebungsgeräte zu verwenden, damit alle Mautgebühren auf das Konto des Opfers überwiesen werden. Stellen Sie sich zum Beispiel vor, jemand stiehlt das Mautgerät eines anderen Fahrzeugs und verwendet es in seinem eigenen Fahrzeug. Wäre dieses Mautgerät mit dem Fahrzeug 112 verbunden, könnte das Mautgerät die Fahrzeugnetzwerkdaten erfassen und diese Daten an einen entfernten Server (z. B. Server 114) wie eine Mautstation senden. In ihrer Funktion als Back-End-Service könnte die Mautstation die empfangenen Daten zur Bestätigung der DVIN 100 verwenden, indem sie einen digitalen Fingerabdruck generiert. Ohne diese Bestätigung kann die Mautstation das mit der angegebenen VIN (z. B. VIN 102) verbundene Konto nicht belasten und stattdessen eine Warnung ausgeben, die auf eine mögliche Fälschung oder einen Betrug hinweist.
Ein weiteres Beispiel ist die Erkennung eines gefälschten Fahrzeugs oder von Anwendungen, bei denen ein Fahrzeug mit einem Dongle ausgestattet ist, der von einer Versicherung oder einer Autovermietung bereitgestellt wird. In einer solchen Anwendung kann ein Back-End-Service zur Erkennung von Betrug eingesetzt werden, wenn ein Betrüger den Betrieb des Fahrzeugs 112 absichtlich verändert.
Beispielsweise kann das Fahrzeug 112 funktionsfähig sein, um über eine drahtlose Verbindung ein Over-the-Air-Update (OTA) durchzuführen. Bei der Durchführung der OTA-Aktualisierung muss das Fahrzeug 112 möglicherweise seine Identität gegenüber einem Back-End-Service offenlegen (d. h. Daten an den Server 114 übermitteln). Eine mögliche Methode zur Bereitstellung einer gesicherten Kommunikation wäre, dass das Fahrzeug 112 eine Fernbescheinigung oder eine Kryptographie mit öffentlichem Schlüssel bereitstellt. Eine solche gesicherte Kommunikation erfordert jedoch in der Regel erhebliche Änderungen an der Fahrzeughardware und erhöht damit die Kosten. Wenn jedoch ein Unbefugter den Netzwerkverkehr innerhalb eines Fahrzeugs manipuliert und den Betrieb des Fahrzeugs 112 verändert hat, könnte DVIN 100 diese Veränderungen erkennen.
Zu den Back-End-Services, die eine Fahrzeugidentifizierung erfordern können, gehören auch die Dongles von Versicherungen oder Autovermietungen, die die Bewegungen eines Fahrzeugs verfolgen. Bei Dongles für Versicherungen kann es erforderlich sein, dass die Versicherungsgesellschaften verifizieren, dass der Dongle mit dem versicherten Fahrzeug verbunden ist (z. B. Fahrzeug 112). Wenn der Dongle lediglich die VIN 102 abfragt, können die gelieferten Informationen über das fahrzeuginterne Netzwerk leicht gefälscht werden. Wie bei der oben beschriebenen Überlistung eines Mautgeräts kann ein Betrüger einen mit dem Fahrzeug 112 assoziierten Dongle in ein anderes Fahrzeug einstecken, was zu einem niedrigeren Versicherungstarif führen kann. Der niedrigere Tarif kann zum Beispiel mit einem Pay-as-you-drive- oder Pay-how-you-drive-Tarif assoziiert sein. Ein Angreifer könnte nicht nur die falsche VIN angeben, sondern auch die Fahrdaten simulieren, um den niedrigeren Tarif zu erhalten.
Die Verwendung von DVIN 100 würde solche unerwünschten Aktivitäten verhindern, da der Angreifer sowohl die VIN (z. B. VIN 100) als auch den Netzwerkverkehr ändern müsste. Ebenso können Autovermieter, die die Aktionen eines Fahrzeugs verfolgen, DVIN 100 verwenden, um sicherzustellen, dass ein Tracker nicht von Fahrzeug 112 in ein anderes Fahrzeug verlegt wurde. Die DVIN 100 kann auch eine Versicherungsgesellschaft schützen, wenn die Autovermietung versucht, den Standort eines Fahrzeugs zu verfolgen, zu überwachen, ob ein Fahrzeug sicher gefahren wird, oder die Nutzung zu überprüfen, um den Mietpreis zu bestimmen. Der Vorteil einer DVIN (d. h. DVIN 100) gegenüber einer VIN (d. h. VIN 102) besteht darin, dass die DVIN den Betrieb des Fahrzeugs 112 funktionsfähig mit der VIN 102 verknüpfen kann, indem sie einen digitalen Fingerabdruck generiert, der aus den eindeutigen Netzwerk- und physischen Merkmalen des Fahrzeugs besteht. Wie bereits erwähnt, könnte ein Angreifer versuchen, die ursprüngliche VIN (d. h. VIN 102) zu entfernen und sie durch eine gefälschte zu ersetzen, in der Hoffnung, dass ein ahnungsloser Käufer nicht merkt, dass das Fahrzeug 112 gestohlen worden ist. In diesem Fall kann die DVIN 100 auch deutlich machen, dass die VIN 102 nicht mit der DVIN 100 übereinstimmt.
In Betracht gezogen wird ferner, dass das Aufspüren von gefälschten Fahrzeugfunktionen zum Betrug mit Dongles auch beinhalten kann, ob der Betrüger entweder (1) ein neues Gerät an seinem eigenen Fahrzeug anbringt, um Netzwerkdaten über Fahrzeuggeschwindigkeit, Abbiegen usw. zu fälschen, mit der Absicht, einen „besseren“ Fahrer zu simulieren, oder (2) seinen Dongle für die Versicherung an das Fahrzeug einer anderen Person (d. h. ein anderes als das Fahrzeug 112) anschließt, mit der Absicht, eine „bessere“ Fahrweise für einen niedrigeren Tarif zu nutzen. Mit einem Dongle, der an den Diagnoseanschluss des Fahrzeugs 112 angeschlossen ist, kann ein Unternehmen die VIN (z. B. VIN 102) überprüfen, die über das Netz leicht gefälscht werden kann. In beiden Fällen würde das Unternehmen betrogen werden und einen niedrigeren Tarif berechnen. Mit einer DVIN (z. B. DVIN 100) kann das Unternehmen jedoch in beiden Fällen Betrug erkennen. Beispiel (1): Das Unternehmen kann falsche Zeitpunkte für Nachrichten erkennen, die darauf zurückzuführen sind, dass der Betrüger seine eigenen Übertragungen sendet, was dazu führt, dass der digitale Fingerabdruck nicht mit dem erwarteten Fingerabdruck übereinstimmt. Beispiel (2): Das Unternehmen kann den digitalen Fingerabdruck des Netzwerks des anderen Fahrzeugs messen und feststellen, dass der Fingerabdruck nicht mit der angegebenen VIN (d. h. VIN 102) übereinstimmt.
Schließlich kann es verschiedene Anwendungen geben, bei denen ein Remote-Back-End-Server eine Beeinträchtigung der fahrzeuginternen Netzwerkkommunikation feststellen kann. So kann DVIN 100 beispielsweise dazu verwendet werden, böswillige Änderungen am Netzwerkverkehr eines Fahrzeugs zu erkennen, um alle Dienste zu schützen, die mit dem Fahrzeug verbunden sind. Eine solche Anwendung kann anwendbar sein, wenn ein Angreifer aus der Ferne eine oder mehrere Steuereinheiten (d. h. die Steuereinheiten 104-110) im Fahrzeug 112 manipuliert und dann eine Steuereinheit (z. B. die Steuereinheit 110) verwendet, um den Netzwerkverkehr zu manipulieren. Wenn zum Beispiel ein Fahrzeug 112 gefährdet und an eine Ladestation für Elektrofahrzeuge angeschlossen ist, könnte die Station DVIN 100 erfassen, bevor sie Strom liefert. So kann die Verifizierung dazu dienen, sicherzustellen (1) dem entsprechenden Fahrzeug die Stromkosten in Rechnung gestellt werden; (2) das Fahrzeug oder ein Betrüger nicht in der Lage sind, die Ladestation (oder andere entfernte Server) zu infizieren; (3) der Standort des Fahrzeugs basierend auf dem Standort der Ladestation verfolgt werden kann.
Auch wenn ein Fahrzeug nicht aktualisiert wird oder aufgrund einer betrügerischen Gefährdung eine Zwangsaktualisierung erforderlich ist, könnte ein Back-End-Service die Zwangsaktualisierung oder die betrügerische Gefährdung erkennen, wenn DVIN 100 korrekt generiert wird. Der Vorteil einer DVIN gegenüber einer VIN besteht darin, dass die DVIN 100 nicht gefälscht werden kann und daher gewährleistet, dass das Fahrzeug 112 und sein Netzbetrieb nicht böswillig verändert werden. Die Verwendung der DVIN 100 kann sowohl das Fahrzeug 112 als auch die Dienste, mit denen es sich verbindet, schützen und ein gewisses Maß an Vertrauen zwischen diesen beiden Parteien ermöglichen.
So kann ein Betrüger beispielsweise erfolgreich Steuereinheiten (d.h. die Steuergeräte 102-110) in einem Elektrofahrzeug (d.h. Fahrzeug 112) manipulieren. Der Betrüger kann auch die Absicht haben, einen Virus oder Wurm in das Fahrzeug 112 einzuschleusen, in der Hoffnung, dass er den Virus oder Wurm an eine Ladestation weitergeben kann, wenn das Fahrzeug 112 das nächste Mal aufgeladen werden muss. Der Virus oder Wurm, der zwischen Fahrzeug 112 und anderen Fahrzeugen oder Stationen übertragen wird, kann sich sehr schnell verbreiten. Um sowohl die Ladeinfrastruktur als auch andere Fahrzeuge zu schützen, kann die Ladestation DVIN 100 verwenden, um sicherzustellen, dass das Fahrzeug 112 nicht gefährdet wird. Dies wird wiederum durch die Anwendung des Fahrzeugs 112 demonstriert, das an eine externe Ladestation angeschlossen ist. Sobald es angeschlossen ist, kann die Station den Netzwerkverkehr und die Spannung der Datenpunkte von Fahrzeug 112 beobachten. Solange der Betrüger nur die Software im Fahrzeug 112 manipuliert hat und bösartige Daten über das Netz überträgt, kann die Station einen ungültigen digitalen Fingerabdruck erkennen und das Fahrzeug 112 für die weitere Kommunikation mit der Station sperren. Da die Ladestation möglicherweise mit Zahlungsdiensten kommunizieren muss, kann man davon ausgehen, dass die Ladestation als Zwischenschritt mit einem Registrierungs-Service kommuniziert. Durch die Erkennung eines solchen bösartigen Verhaltens kann die Station sich selbst und andere Fahrzeuge, die sich in Zukunft anschließen, wirksam schützen. Ähnlich wie bei anderen oben beschriebenen Anwendungen kann DVIN 100 verhindern, dass der Besitzer eines Elektrofahrzeugs einfach die VIN eines anderen Fahrzeugs fälscht, wodurch einem anderen Fahrer die Gebühr für die Ladezeit berechnet werden könnte.
Auch wenn die oben genannten Beispiele keine vollständige Liste aller möglichen Anwendungen darstellen, so sollen sie doch die Flexibilität und Vielfalt der Möglichkeiten aufzeigen, wie eine DVIN (z. B. DVIN 100) zur Verbesserung der Sicherheit eingesetzt werden kann, wenn die Bestätigung der Identität eines Fahrzeugs entscheidend ist.
Die Prozesse, die Verfahren oder die Algorithmen, die hier offenbart werden, können zu einer Verarbeitungsvorrichtung, einer Steuereinheit oder einem Computer, die bzw. der eine beliebige vorhandene programmierbare elektronische Steuereinheit oder eine fest zugeordnete elektronische Steuereinheit enthalten kann, übermittelbar sein/durch sie implementiert werden. Entsprechend können die Prozesse, die Verfahren oder die Algorithmen als Daten und Anweisungen gespeichert werden, die durch eine Steuereinheit oder einen Computer in vielen Formen ausführbar sind und die Informationen, die in schreibgeschützten Speichermedien wie z. B. ROM-Vorrichtungen dauerhaft gespeichert sind, und Informationen, die änderbar in beschreibbaren Speichermedien wie z. B. Disketten, Magnetbändern, CDs, RAM-Vorrichtungen und weiteren magnetischen und optischen Medien gespeichert sind, enthalten, jedoch nicht darauf beschränkt sind. Die Prozesse, Verfahren oder Algorithmen können auch in einem ausführbaren Software-Objekt implementiert werden. Alternativ können die Prozesse, Verfahren oder Algorithmen vollständig oder teilweise unter Verwendung geeigneter Hardware-Komponenten wie z. B. anwendungsspezifischer integrierter Schaltungen (ASICs), feldprogrammierbarer Gate-Anordnungen (FPGAs), Zustandsmaschinen, Steuereinheiten oder weiterer Hardware-Komponenten oder Vorrichtungen oder einer Kombination von Hardware-, Software- und Firmware-Komponenten verkörpert werden.
Während oben beispielhafte Ausführungsformen beschrieben werden, ist nicht vorgesehen, dass diese Ausführungsformen alle möglichen Formen, die durch die Ansprüche eingeschlossen sind, beschreiben. Die Wörter, die in der Spezifikation verwendet werden, sind Wörter einer Beschreibung statt einer Einschränkung und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und vom Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben wurde, können die Merkmale verschiedener Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung, die nicht ausdrücklich beschrieben oder veranschaulicht sein müssen, zu bilden. Während verschiedene Ausführungsformen derart beschrieben sein können, dass sie Vorteile schaffen oder über weitere Ausführungsformen oder Implementierungen des Stands der Technik in Bezug auf eine oder mehrere gewünschte Eigenschaften bevorzugt werden, erkennen einschlägige Fachleute, dass ein bzw. eine oder mehrere Merkmale oder Eigenschaften beeinträchtigt werden können, um gewünschte Gesamtsystemeigenschaften, die von der spezifischen Anwendung und Implementierung abhängen, zu erreichen. Diese Eigenschaften können Kosten, Festigkeit, Haltbarkeit, Lebenszykluskosten, Vermarktbarkeit, Erscheinungsform, Verpackung, Größe, Wartbarkeit, Gewicht, Herstellbarkeit, Einfachheit der Montage usw. enthalten, sind jedoch nicht darauf beschränkt. Daher liegen in dem Umfang, in dem jegliche Ausführungsformen als weniger wünschenswert als weitere Ausführungsformen oder Implementierungen des Stands der Technik in Bezug auf eine oder mehrere Eigenschaften beschrieben werden, diese Ausführungsformen nicht außerhalb des Umfangs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 17/445758 [0017]
US 17445758 [0028]

Claims

Verfahren zum Generieren einer digitalen Identität für ein Fahrzeug, umfassend: Empfangen einer ersten Mehrzahl von Messungen, die von einer Mehrzahl von im Fahrzeug befindlichen elektronischen Steuereinheiten erfasst werden, wobei die erste Mehrzahl von Messungen physik-basierte Metriken sind, die generiert werden und jedem der Mehrzahl von elektronischen Steuereinheiten eigen sind; Erzeugen eines Datenpools aus der ersten Mehrzahl von Messungen; und und Generieren einer eindeutigen Kennung durch Kombinieren von mindestens zwei der ersten Mehrzahl von Messungen innerhalb des Datenpools, wobei die eindeutige Kennung funktionsfähig ist, um die digitale Identität für das Fahrzeug zu verifizieren.
Verfahren nach Anspruch 1, wobei der Schritt des Erzeugens des Datenpools wiederholt wird, so dass der Datenpool ein oder mehrere für das Fahrzeug eindeutige Merkmale enthält.
Verfahren nach Anspruch 1, wobei die erste Mehrzahl von Messungen als ein einzelnes Datenarray dargestellt wird.
Verfahren nach Anspruch 1, wobei ein eindeutiger Schlüssel mittels eines Fuzzy-Extraktionsalgorithmus generiert wird, der funktionsfähig ist, um einen Rauschpegel innerhalb der ersten Mehrzahl von Messungen zu verarbeiten, wobei der Fuzzy-Extraktionsalgorithmus Fehlerkorrekturdaten verwendet, die aus einem vordefinierten Rauschparameter berechnet werden, und verwendet wird, um ein gemessenes Fuzzy-Signal anzupassen.
Verfahren nach Anspruch 4, ferner umfassend: Berechnen mittels eines Back-End-Service der Fehlerkorrekturdaten aus dem Datenpool.
Verfahren nach Anspruch 4, ferner umfassend: Kombinieren des eindeutigen Schlüssels mit einem einzelnen Authentifizierungsprotokoll.
Verfahren nach Anspruch 4, ferner umfassend: Kombinieren des eindeutigen Schlüssels mit einem gegenseitigen Authentifizierungsprotokoll.
Verfahren nach Anspruch 4, wobei der eindeutige Schlüssel auf einem externen Server gespeichert ist.
Verfahren nach Anspruch 4, das ferner umfasst: Empfangen einer physikalischen Fahrzeugidentifikationsnummer (VIN), die mit dem Fahrzeug assoziiert ist, wobei die physische VIN verwendet wird, um den eindeutigen Schlüssel zu generieren.
Verfahren nach Anspruch 4 ferner umfassend: Senden einer Identitätsprüfungs-Anforderung an das Fahrzeug; Empfangen einer zweiten Mehrzahl von Messungen, die von der Mehrzahl von im Fahrzeug befindlichen elektronischen Steuereinheiten erfasst werden, wobei die zweite Mehrzahl von Messungen physik-basierte Metriken sind, die generiert werden und jedem der Mehrzahl von elektronischen Steuereinheiten eigen sind; Rekonstruieren des eindeutigen Schlüssels, der mit der zweiten Mehrzahl von Messungen assoziiert ist, wobei der eindeutige Schlüssel durch Kombinieren der zweiten Mehrzahl von Messungen mit Hilfsdaten rekonstruiert wird, die aus der ersten Mehrzahl von Messungen generiert wurden; und Verifizieren der Gültigkeit der digitalen Identität des Fahrzeugs mittels eines Authentifizierungsprotokolls um den eindeutigen Schlüssel zu verifizieren.
Verfahren nach Anspruch 10, wobei das Authentifizierungsprotokoll ein gegenseitiges Authentifizierungsprotokoll ist.
Verfahren nach Anspruch 10, wobei das Authentifizierungsprotokoll ein einzelnes Authentifizierungsprotokoll ist.
Verfahren nach Anspruch 1, ferner umfassend: Generieren der Hilfsdaten aus der ersten Mehrzahl von Messungen.
Verfahren nach Anspruch 1, ferner umfassend: Generieren eines unscharfen Fingerabdrucks, der eine Identität und einen vorbestimmten Abweichungswert für die erste Mehrzahl von Messungen enthält.
Verfahren nach Anspruch 1, wobei die physik-basierte Metrik ein momentaner Energiewert ist, der von einer mit der Mehrzahl der elektronischen Steuereinheiten assoziierten Energiequelle empfangen wird.
Verfahren nach Anspruch 1, wobei die erste Mehrzahl von Messungen von dem Fahrzeug zu einem externen Server mittels eines gesicherten Übertragungskanal-Protokolls empfangen wird.
Ein nicht flüchtiges computerlesbares Medium, das funktionsfähig ist, um eine digitale Identität für ein Fahrzeug zu generieren, wobei das nicht flüchtige computerlesbare Medium computerlesbare Befehle darauf gespeichert hat, die funktionsfähig sind, um ausgeführt zu werden, um die folgenden Funktionen auszuführen: eine erste Mehrzahl von Messungen zu empfangen, die von einer Mehrzahl von im Fahrzeug befindlichen elektronischen Steuereinheiten erfasst werden, wobei die erste Mehrzahl von Messungen physik-basierte Metriken sind, die generiert werden und jedem der Mehrzahl von elektronischen Steuereinheiten eigen sind; einen Datenpools aus der ersten Mehrzahl von Messungen zu erzeugen; und und eine eindeutige Kennung durch Kombinieren von mindestens zwei der ersten Mehrzahl von Messungen innerhalb des Datenpools zu generieren, wobei die eindeutige Kennung funktionsfähig ist, um die digitale Identität für das Fahrzeug zu verifizieren.
Nicht flüchtiges computerlesbares Medium nach Anspruch 17, wobei die erste Mehrzahl von Messungen als ein einzelnes Datenarray dargestellt wird.
Nicht flüchtiges computerlesbares Medium nach Anspruch 17, wobei ein eindeutiger Schlüssel mittels eines Fuzzy-Extraktionsalgorithmus generiert wird, der funktionsfähig ist, um einen Rauschpegel innerhalb der ersten Mehrzahl von Messungen zu verarbeiten, wobei der Fuzzy-Extraktionsalgorithmus Fehlerkorrekturdaten verwendet, um ein gemessenes Fuzzy-Signal anzupassen.
System zum Generieren einer digitalen Identität für ein Fahrzeug, umfassend: einen vom Fahrzeug Remote-Back-End-Service, der funktionsfähig ist, um: eine erste Mehrzahl von Messungen zu empfangen, die von einer Mehrzahl von im Fahrzeug befindlichen elektronischen Steuereinheiten erfasst werden, wobei die erste Mehrzahl von Messungen physik-basierte Metriken sind, die generiert werden und jedem der Mehrzahl von elektronischen Steuereinheiten eigen sind; einen Datenpools aus der ersten Mehrzahl von Messungen zu erzeugen; und und eine eindeutige Kennung durch Kombinieren von mindestens zwei der ersten Mehrzahl von Messungen innerhalb des Datenpools zu generieren, wobei die eindeutige Kennung funktionsfähig ist, um die digitale Identität für das Fahrzeug zu verifizieren.