DE102020117552A1

DE102020117552A1 - Sichere hybrid-boot-systeme und sichere boot-verfahren für hybridsysteme

Info

Publication number: DE102020117552A1
Application number: DE102020117552.3A
Authority: DE
Inventors: Alexander Zeh; Berndt Gammel; Veit Kleeberger
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2019-07-18
Filing date: 2020-07-03
Publication date: 2021-01-21
Also published as: US11100229B2; CN112242903B; US20210019417A1; CN112242903A

Abstract

Eine Hybridvorrichtung umfasst eine Vielzahl verschiedener Subsysteme, einschließlich eines ersten und eines zweiten Subsystems. Das erste Subsystem umfasst mindestens eine erste gesicherte Speichervorrichtung, die zum Speichern einer ersten Software konfiguriert ist, und eine erste CPU, die zum Booten und Ausführen der ersten Software konfiguriert ist. Das zweite Subsystem umfasst mindestens eine zweite gesicherte Speichervorrichtung, die zum Speichern einer zweiten Software konfiguriert ist, und eine zweite CPU, die zum Booten und Ausführen der zweiten Software konfiguriert ist. Die erste CPU ist so konfiguriert, dass sie den ersten Hash der ersten Software erzeugt und den erzeugten ersten Hash der ersten Software an das zweite Subsystem überträgt. Die zweite CPU ist so konfiguriert, dass sie eine erste Authentizitätsvalidierungsprüfung der ersten Software unter Verwendung des empfangenen ersten Hash der ersten Software durchführt und ein Fehlersignal unter der Bedingung erzeugt, dass die erste Authentizitätsvalidierungsprüfung der ersten Software fehlschlägt.

Description

GEBIET
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf sichere Hybridsysteme und auf Verfahren zu deren Betrieb.
HINTERGRUND
Die funktionale Sicherheit elektronischer Systeme in Kraftfahrzeugen ist angesichts der zunehmenden Automatisierung und des zunehmenden Halbleiteranteils in modernen Fahrzeugen ein wichtiges Thema. Es ist wünschenswert, eine zuverlässige und sichere Funktionalität für die im System eingesetzten sicherheitskritischen Teile zu haben.
Neben der funktionalen Sicherheit ist die Cybersicherheit zu einem wichtigen Aspekt in der Fahrzeugelektronik geworden. Es ist unvermeidlich, sowohl die funktionale Sicherheit als auch die automobile Cybersicherheit von Anfang an in das Design eines elektronischen Produkts einzubeziehen. Die funktionale Sicherheit hat einen Reifegrad erreicht, aber Cybersicherheit ist relativ neu. Möglicherweise werden bald Sicherheitsteile benötigt, die sowohl sicher als auch geschützt sind.
Sichere Bootvorgänge sind wichtig in der Automobilelektronik, deren Funktionalitäten weitgehend über Software (SW) definiert werden. Solche Software sollte gut vor Änderungen geschützt werden, damit die vom Anbieter beabsichtigte Funktionalität gewährleistet ist und die Einführung von Schadsoftware verhindert wird. Hybridsysteme sind Systeme, die aus mindestens zwei verschiedenen Arten von Subsystemen bestehen, die zum Beispiel aus verschiedenen CPUs (Central Processing Units), Speicher- und Bussystemen bestehen können. Die Wirksamkeit eines sicheren Bootvorgangs hängt direkt von dem Teil des Systems ab, der kompromittiert werden muss, um eine andere Funktionalität einzuführen. Je höher die Anzahl der Teile ist, die in einer bestimmten Reihenfolge kompromittiert oder gestört werden müssen, desto größer ist die Wahrscheinlichkeit, dass eine bösartige Software erfolgreich eingeführt wird.
Daher kann ein verbessertes System wünschenswert sein, das in der Lage ist, hybride Bootvorgänge mit einer höheren Sicherheit durchzuführen.
KURZDARSTELLUNG
Ausführungsformen beziehen sich auf Hybridsysteme und auf sichere Bootverfahren für Hybridsysteme. Ein Hybridsystem ist ein System, das mindestens zwei verschiedene Arten von Subsystemen aufweist, die beispielsweise aus verschiedenen CPUs (Central Processing Units), Speichern und/oder Bussystemen bestehen können.
Eine oder mehrere Ausführungsformen stellen eine Hybridvorrichtung bereit, die eine Vielzahl verschiedener Subsysteme umfasst, darunter ein erstes und ein zweites Subsystem. Das erste Subsystem umfasst mindestens eine erste gesicherte Speichervorrichtung, die so konfiguriert ist, dass sie eine erste Software speichert, und eine erste CPU (Central Processing Unit), die so konfiguriert ist, dass sie die erste Software bootet und ausführt. Das zweite Subsystem umfasst mindestens eine zweite gesicherte Speichervorrichtung, die zur Speicherung einer zweiten Software konfiguriert ist, und eine zweite CPU, die zum Booten und Ausführen der zweiten Software konfiguriert ist. Die mindestens eine erste gesicherte Speichervorrichtung ist ferner so konfiguriert, dass sie einen ersten geheimen Schlüssel und eine erste gespeicherte Signatur speichert, die einem ersten Hash der ersten Software entspricht. Die mindestens eine zweite gesicherte Speichervorrichtung ist ferner so konfiguriert, dass sie einen zweiten geheimen Schlüssel, eine zweite gespeicherte Signatur, die dem ersten Hash der ersten Software entspricht, und eine dritte gespeicherte Signatur, die einem ersten Hash der zweiten Software entspricht, speichert. Die erste CPU ist so konfiguriert, dass sie den ersten Hash der ersten Software erzeugt und den erzeugten ersten Hash der ersten Software an das zweite Subsystem überträgt. Die zweite CPU ist so konfiguriert, dass sie eine erste Authentizitätsvalidierungsprüfung der ersten Software unter Verwendung des empfangenen ersten Hash der ersten Software durchführt und ein Fehlersignal unter der Bedingung erzeugt, dass die erste Authentizitätsvalidierungsprüfung der ersten Software fehlschlägt.
Eine oder mehrere Ausführungsformen stellen ein Verfahren zum Durchführen einer sicheren Ausführungsprozedur für eine Hybridvorrichtung bereit, die eine Vielzahl verschiedener Subsysteme enthält, einschließlich eines ersten Subsystems, das eine erste Software, die in mindestens einer ersten gesicherten Speichervorrichtung gespeichert ist, bootet und ausführt, und eines zweiten Subsystems, das eine zweite Software, die in einer zweiten gesicherten Speichervorrichtung gespeichert ist, bootet und ausführt, wobei ein erster geheimer Schlüssel und eine erste gespeicherte Signatur, die einem ersten Hash der ersten Software entspricht, in dem mindestens einen ersten gesicherten Speicher gespeichert sind, und wobei ein zweiter geheimer Schlüssel, eine zweite gespeicherte Signatur, die dem ersten Hash der ersten Software entspricht, und eine dritte gespeicherte Signatur, die einem ersten Hash der zweiten Software entspricht, in der mindestens einen zweiten gesicherten Speichervorrichtung gespeichert sind. Das Verfahren umfasst Erzeugen des ersten Hash der ersten Software durch das erste Subsystem; Übertragen des erzeugten ersten Hash der ersten Software durch das erste Subsystem an das zweite Subsystem; Durchführen einer ersten Authentizitätsvalidierungsprüfung der ersten Software durch das zweite Subsystem unter Verwendung des empfangenen ersten Hash der ersten Software; und Erzeugen eines Fehlersignals durch das zweite Subsystem unter der Bedingung, dass die erste Authentizitätsvalidierungsprüfung der ersten Software fehlschlägt.
Figurenliste
Ausführungsformen sind hierin unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.

1 ist ein Blockdiagramm eines sicheren Boot-Systems gemäß einer oder mehreren Ausführungsformen;
2 ist ein Blockdiagramm eines Hybridsystems, das ein sicheres Hybrid-Boot-Verfahren gemäß einem oder mehreren Beispielen implementiert; und
3 ist ein Flussdiagramm eines sicheren Hybrid-Boot-Verfahrens, das in einer Hybridvorrichtung gemäß einer oder mehreren Ausführungsformen implementiert ist.

DETAILLIERTE BESCHREIBUNG
Im Folgenden wird eine Vielzahl von Details aufgeführt, um die beispielhaften Ausführungsformen eingehender zu erläutern. Allerdings wird es für diejenigen, die sich in der Technik auskennen, offensichtlich sein, dass Ausführungsformen auch ohne diese spezifischen Details ausgeübt werden können. In anderen Fällen werden bekannte Strukturen und Vorrichtungen eher in Blockdiagrammform oder in einer schematischen Ansicht als im Detail dargestellt, um die Ausführungsformen nicht zu verdecken. Darüber hinaus können Merkmale der verschiedenen nachstehend beschriebenen Ausführungsformen miteinander kombiniert werden, sofern nicht ausdrücklich anders angegeben. Beispielsweise können Variationen oder Modifikationen, die in Bezug auf eine der Ausführungsformen beschrieben sind, auch auf andere Ausführungsformen anwendbar sein, sofern nicht anders angegeben. Optionale Elemente oder Elemente, die aktiviert und deaktiviert werden können, können durch die Verwendung von gestrichelten Linien und Blöcken in den Abbildungen veranschaulicht sein.
Weitere, äquivalente oder ähnliche Elemente oder Elemente mit äquivalenter oder ähnlicher Funktionalität werden in der folgenden Beschreibung mit äquivalenten oder ähnlichen Bezugszeichen bezeichnet. Da die gleichen oder funktionell gleichwertigen Elemente in den Abbildungen die gleichen Bezugszeichen erhalten, kann eine wiederholte Beschreibung für Elemente, die mit den gleichen Bezugszeichen versehen sind, entfallen. Daher sind die Beschreibungen für Elemente mit gleichen oder ähnlichen Bezugszeichen gegenseitig austauschbar.
Verbindungen oder Kopplungen zwischen Elementen, die in den Zeichnungen gezeigt oder hierin beschrieben werden, können drahtgebundene Verbindungen oder drahtlose Verbindungen sein, sofern nicht anders angegeben. Darüber hinaus können solche Verbindungen oder Kopplungen direkte Verbindungen oder Kopplungen ohne zusätzliche Zwischenelemente oder indirekte Verbindungen oder Kopplungen mit einem oder mehreren zusätzlichen Zwischenelementen sein, solange der allgemeine Zweck der Verbindung oder Kopplung, z.B. die Übertragung einer bestimmten Art von Signal oder die Übertragung einer bestimmten Art von Information, im Wesentlichen erhalten bleibt.
Es ist möglich, dass die Begriffe „Mikroprozessoren“, „Prozessoren“, „Prozessorkerne“, „Verarbeitungseinheiten“ und „Verarbeitungsschaltkreise“ in dieser Offenbarung austauschbar verwendet werden können. Ein Prozessor kann spezielle Hardware für die Verarbeitung, Speicherung und/oder Verteilung von Daten und Informationen enthalten. Zwei oder mehr Prozessoren können auch kombiniert werden, um eine Verarbeitungsfunktion auszuführen, und können als ein Prozessor angesehen werden.
Ausführungsformen beziehen sich auf Hybridsysteme und auf sichere Bootverfahren für Hybridsysteme. Ein Hybridsystem ist ein System, das mindestens zwei verschiedene Arten von Subsystemen aufweist, die beispielsweise aus unterschiedlichen CPUs (Central Processing Units), Speicher- und Bussystemen bestehen können. Eine CPU wird im Allgemeinen als eine Vorrichtung zur Ausführung von Software (Computerprogramm) definiert. In sicheren Systemen kann eine CPU so konfiguriert werden, dass sie eine Schnittstelle zu Software bildet, die in einem sicheren Speichermodul wie eine solche Speichervorrichtung gespeichert ist. Insbesondere kann die CPU die Anweisungen ausführen, aus denen das sichere Softwareprogramm besteht. Wie weiter unten ausführlicher beschrieben wird, kann ein Hybridsystem zwei oder mehr Domänen (Domains) umfassen, die jeweils ein eigenes Subsystem enthalten (z.B. jede Domäne mit eigener CPU, eigenem sicheren Speichermodul und eigener Software).
Ein Logikblock kann einen oder mehrere Prozessoren und/oder andere Logikschaltungen enthalten, die so konfiguriert sind, dass sie einen oder mehrere Eingaben empfangen und verarbeiten, um eine Ausgabe zu erzeugen. Insbesondere kann ein logischer Block jeder Rechenvorrichtung wie ein Prozessor, eine CPU, eine kryptographische Maschine, ein Computersystem oder ähnliches sein.
Ausführungsformen beziehen sich auf ECUs (Electronic Control Units) und Fahrzeugkommunikationsnetzwerke (z.B. CANs (Controller Area Networks), CAN mit flexibler Datenrate (CAN FD), ETH (Ethernet), PCIe (Peripheral Component Interconnect Express) oder einen anderen Busstandard). Eine ECU ist jedes eingebettete System in der Automobilelektronik, das eines oder mehrere der elektrischen Systeme oder Subsysteme in einem Fahrzeug steuert. Jede ECU umfasst einen Mikrocontroller (d.h. eine MCU (Microcontroller Unit)), einen Speicher, verschiedene Eingänge (z.B. Versorgungsspannung, digitale Eingänge und/oder analoge Eingänge) und Ausgänge (z.B. Relaistreiber, H-Brückentreiber, Injektortreiber und/oder Logikausgänge) sowie Kommunikationsverbindungen. So sind die ECUs die Knotenpunkte von fahrzeuginternen automotiven Netzwerken, während die Ränder dieser Netzwerke Kommunikationsnetzwerke sind (z.B. CAN, CAN FD, ETH, PCIe usw.).
Eine nicht erschöpfende Liste von ECU-Typen umfasst eine elektronische Steuereinheit, ein ECM (Engine Control Module), eine Motorsteuereinheit, eine TCU (Transmission Control Unit), ein TCM (Transmission Control Module), ein BCM (Brake Control Unit) oder EBCM, ein CCM (Central Control Module), ein CTM (Central Timing Module), ein GEM (General Electronic Module), ein BCM (Body Control Module), ein SCM (Suspension Control Module), eine DCU (Door Control Unit), eine PSCU (Electric Power Steering Control Unit), eine HMI (Human Machine Interface), eine Sitz-Steuereinheit, eine SCU (Speed Control Unit), eine TCU (Telematic Control Unit) und ein BMS (Battery Management System). Manchmal werden die Funktionen der Motorsteuervorrichtung und der TCU in einer einzigen ECU kombiniert, die als PCM (Powertrain Control Module) bezeichnet wird. Darüber hinaus kann der BCM so konfiguriert werden, dass er ein ABS (Anti-Lock Braking System), eine ESC (Electronic Stability Control) und/oder eine DSC (Dynamic Stability Control) steuert.
Ausführungsformen beziehen sich ferner auf kryptographische Hash-Werte und digitale Signaturen, die zur Überprüfung der Authentizität von Software verwendet werden. Eine kryptographische Hash-Funktion oder ein Hash-Algorithmus ist jede Funktion oder jeder mathematische Algorithmus, die bzw. der verwendet werden kann, um Daten beliebiger Größe auf Daten einer festen Größe abzubilden (d.h. einen Hash zu erzeugen). Der Hash ist eine Zeichenfolge fester Länge aus Zahlen und/oder Buchstaben, die aus dem mathematischen Algorithmus und der Nachricht beliebiger Größe erzeugt wird, wie eine E-Mail, ein Dokument, ein Bild, eine Software oder eine andere Art von Daten. Die von der Hash-Funktion zurückgegebenen Werte werden Hash-Werte, Hash-Codes, Digests oder einfach Hashes genannt. Eine Hash-Funktion ist deterministisch, so dass die gleiche Eingabe immer zum gleichen Hash führt. Dies bedeutet, dass die erzeugte Zeichenfolge für die zu hashende Datei eindeutig ist und eine Einwegfunktion darstellt, so dass es nicht möglich ist, zwei verschiedene Eingaben mit demselben Hashwert zu finden. Hash-Werte können in der Länge variieren. Im Allgemeinen erzeugt eine stärkere Hash-Funktion einen längeren Hash-Wert, und je länger der Hash-Wert, desto sicherer oder stärker ist der Hash-Wert. In der Regel ist jedoch die Rechenlast bei stärkeren Hash-Werten intensiver, was zu längeren Verarbeitungszeiten führt. Mit anderen Worten hat ein stärkerer Hash im Vergleich zu einem schwächeren Hash eine geringere Kollisionswahrscheinlichkeit und damit auch eine längere Rechenzeit.
Zu den üblicherweise verwendeten Hashing-Algorithmen gehören SHA-1, SHA-2 und SHA-3, aber die hier beschriebenen Ausführungsformen sind nicht darauf beschränkt. Hashing kann überall dort eingesetzt werden, wo ein Wert mit einem gespeicherten Wert verglichen wird, kann aber aus Sicherheitsgründen seine einfache Darstellung nicht speichern.
Wenn zum Beispiel eine sichere Nachricht übertragen wird, wird ein Hash der beabsichtigten Nachricht erzeugt und verschlüsselt und zusammen mit der Nachricht gesendet. Wenn die Nachricht empfangen wird, entschlüsselt der Empfänger sowohl den Hash als auch die Nachricht. Dann erstellt der Empfänger einen weiteren Hash aus der entschlüsselten Nachricht. Wenn die beiden Hashes beim Vergleich identisch sind, dann ist eine sichere Übertragung erfolgt. Sowohl der Sender als auch der Empfänger müssen dieselbe Hash-Funktion oder denselben Algorithmus verwenden. In einigen Fällen kann der Sender dem Empfänger den Algorithmus zusammen mit dem Hash-Wert der Nachricht senden. Dieser Hashing-Prozess stellt sicher, dass die Nachricht nicht von einem nicht autorisierten Endbenutzer verändert wird. Der Zweck des Hashings besteht also darin, die Authentizität der übertragenen Nachricht zu verifizieren, aber es kann auch zur Authentifizierung verwendet werden, wenn ein Schlüssel verwendet wird.
Eine digitale Signatur bezieht sich auf eine Reihe von Algorithmen und Verschlüsselungsschutzmechanismen, die zur Validierung der Authentizität einer Nachricht, Software oder eines digitalen Dokuments verwendet werden. Digitale Signaturen beweisen, dass eine digitale Nachricht, Software oder ein Dokument ab dem Zeitpunkt der Signierung weder absichtlich noch unabsichtlich verändert wurde. Digitale Signaturen tun dies, indem sie einen eindeutigen Hash der Nachricht oder des Dokuments erzeugen und diesen mit dem privaten Schlüssel des Absenders verschlüsseln. Der erzeugte Hash ist einzigartig für die Nachricht, die Software oder das Dokument, und wenn ein Teil davon geändert wird, verändert sich der Hash vollständig.
Nach der Fertigstellung wird die Nachricht oder das digitale Dokument digital signiert und an den Empfänger gesendet. Der Empfänger erzeugt dann einen eigenen Hash der Nachricht oder des digitalen Dokuments und entschlüsselt den (in der ursprünglichen Nachricht enthaltenen) Hash des Absenders mit Hilfe des öffentlichen Schlüssels des Absenders. Der Empfänger vergleicht den von ihm erzeugten Hash mit dem entschlüsselten Hash des Absenders; wenn sie übereinstimmen, wurde die Nachricht oder das digitale Dokument nicht verändert und der Absender ist authentifiziert.
Die allgemeine Notation H=HASH(X) stellt einen Hash-Wert H dar, der durch Hashing von Daten X mittels Hash-Funktion/Algorithmus HASH erhalten wird. Beispielsweise stellt X_A=HASH-A(SW-A) einen Hash-Wert X_A dar, der durch Hashing von Software A (SW-A) über eine Hash-Funktion/einen Hash-Algorithmus HASH-A erhalten wird. X_B=HASH-B(SW-B) steht für einen Hash-Wert X_B, der durch Hashing von Software B (SW-B) über eine Hash-Funktion/einen Hash-Algorithmus HASH-B erhalten wird. X*_A=HASH-B(SW-A) steht für einen Hash-Wert X*_A, der durch Hashing von Software A (SW-A) über eine Hash-Funktion/einen Hash-Algorithmus HASH-B erhalten wird. Ein doppeltes Gleichheitszeichen „= =“ stellt eine Vergleichsfunktion dar. Beispielsweise können zwei Hash-Werte, die von zwei verschiedenen Quellen erzeugt wurden, verglichen werden (z.B. X_A = = X_A).
In ähnlicher Weise stellt die allgemeine Notation S=SIGN_K(X) eine Signatur S dar, die durch Signieren des Hash-Wertes X unter Verwendung eines Schlüssels k über die Vorzeichenfunktion/-algorithmus SIGN erhalten wird. Beispielsweise stellt SA₁=SIGN-A_K1(XA) eine Signatur SA₁ dar, die durch Signieren des Hashwerts X_A unter Verwendung des Schlüssels K1 über die Signierfunktion/-algorithmus SIGN-A erhalten wurde. SA₂=SIGN-B_K2(X_A) stellt eine Signatur SA₂ dar, die durch Signieren des Hash-Wertes X_A unter Verwendung des Schlüssels K₂ über die Signierfunktion/-algorithmus SIGN-B erhalten wird. SB₁=SIGN-A_K1(X_B) stellt eine Signatur SB₁ dar, die durch Signieren des Hash-Wertes X_B unter Verwendung des Schlüssels K1 über die Signierfunktion/-algorithmus SIGN-A erhalten wird. SB₂=SIGN-B_K2(X_B) stellt eine Signatur SB₂ dar, die durch Signieren des Hash-Wertes X_B unter Verwendung des Schlüssels K2 über die Signierfunktion/-algorithmus SIGN-B erhalten wird. SA*₁=SIGN-A_K1(X*_A) stellt eine Signatur SA*_i dar, die durch Signieren des Hash-Wertes X*_A unter Verwendung des Schlüssels K1 über die Signierfunktion/-algorithmus SIGN-A erhalten wird. SA*₂=SIGN-B_K2(X*_A) stellt eine Signatur SA*₂ dar, die durch Signieren des Hash-Wertes X*_A unter Verwendung des Schlüssels K2 über die Signierfunktion/-algorithmus SIGN-B erhalten wird. Ein doppeltes Gleichheitszeichen „= =“ stellt eine Vergleichsfunktion dar. Zum Beispiel können zwei Signaturen, die von zwei verschiedenen Quellen erzeugt wurden, verglichen werden (z.B. SIGN-A_K, (X_A) = = SA₁).
1 ist ein Blockdiagramm eines sicheren Boot-Systems 100 nach einer oder mehreren Ausführungsformen. Das sichere Boot-System umfasst eine externe Vorrichtung 1 und eine MCU (Microcontroller Unit) 2, die jeweils einen gemeinsamen geheimen Schlüssel K speichern. Zusätzlich speichert die externe Vorrichtung 1 zunächst Software SW zum Laden auf die MCU 2. Zunächst wird die Software SW von der externen Vorrichtung 1 extern signiert, indem zunächst ein Hash X der Software SW erzeugt wird (d.h. X=HASH(SW) und dann eine Signatur S' des Hash X erzeugt wird (d.h. S'=SIGN_K(X)). Dann wird die Software SW und die Signatur S' von der externen Vorrichtung 1 auf die MCU 2 übertragen. Um einen sicheren Bootvorgang der Software durchzuführen, prüft die MCU 2 zunächst die Authentizität der Software SW vor der Ausführung des Bootvorgangs und schließlich vor der Ausführung der Software SW selbst. Um die Authentizität der Software SW zu prüfen, erzeugt die MCU 2 einen eigenen Hash der Software SW und berechnet dann die Signatur S. Abschließend wird die Signatur S mit der gespeicherten Signatur S' (d.h. S = = S') verglichen. Wenn die beiden Signaturen gleich sind, fährt die MCU 2 mit dem Bootvorgang der Software SW fort. Wenn die beiden Signaturen unterschiedlich sind, wird der Bootvorgang unterbrochen und ein Fehler erzeugt.
Traditionelle sichere Boot-Prozeduren in automotiven Systemen sind vollständig sequentiell, wobei die Boot-Software vor der Ausführung überprüft wird. Mit zunehmendem Umfang der Authentisierung wird dies zu einem Flaschenhals, da der Zeitplan für die Inbetriebnahme von Fahrzeugen stark eingeschränkt ist und verschiedene andere Aufgaben (z.B. Test der Missionsmodus-Logik) vor der Ausführung der Software ausgeführt werden müssen.
2 ist ein Blockdiagramm eines Hybridsystems 200, das ein sicheres Hybrid-Boot-Verfahren nach einem oder mehreren Beispielen implementiert. Das Hybridsystem 200 umfasst mindestens zwei verschiedene Domänen (d.h. Subsysteme), Domäne A und Domäne B, wobei jede Domäne so konfiguriert ist, dass sie verschiedene Arten von Rechenaufgaben ausführen kann. Das heißt, Domäne A und Domäne B repräsentieren zwei verschiedene Arten von Subsystemen, bei denen mindestens eine ihrer CPUs, Speichervorrichtungen (nichtflüchtig und flüchtig) und/oder Bussysteme sich von den anderen unterscheidet.
Beispielsweise kann Domäne A so konfiguriert sein, dass sie Echtzeit-Computing-Aufgaben ausführt, die schnell und auf Anforderung ausgeführt werden müssen. Infolgedessen kann Domäne A als Echtzeit-Steuerungsmodul dienen und als Echtzeit-Domäne bezeichnet werden. Beispielsweise kann Domäne A so konfiguriert sein, dass sie Aufgaben ausführt, die sicherheitsbezogenen Aufgaben entsprechen. In einer Fahrzeugumgebung sind sicherheitsrelevante Aufgaben entscheidend, um einen sicheren Betrieb des Fahrzeugs aufrechtzuerhalten und schnell auf sich ändernde Umweltbedingungen und -faktoren zu reagieren. Daher ist es wichtig, dass Domäne A's in der Lage ist, die Ausführung ihrer Software in Echtzeit durchzuführen.
Im Gegensatz dazu kann Domäne B so konfiguriert werden, dass sie rechenintensive Algorithmen oder andere Aufgaben ausführt, die ein hohes Maß an Rechenleistung erfordern. Infolgedessen kann Domäne B als Leistungsberechnungsmodul oder als Anwendungskern dienen und als Rechendomäne bezeichnet werden. Hier ist es vielleicht nicht so entscheidend, dass die Aufgaben in Echtzeit ausgeführt werden. In einer Fahrzeugumgebung können diese Aufgaben mit Infotainmentverarbeitung, Bilddatenverarbeitung usw. zusammenhängen. Alternativ kann Domäne B dazu dienen, Domäne A durch Bereitstellung zusätzlicher Rechenbandbreite zu ergänzen. Zum Beispiel kann Domäne B Leistungszusätze für den Echtzeitteil von Domäne A liefern.
Jede Domäne umfasst eine eigene CPU, einen RAM (Random Access Memory), der Daten und Maschinencode speichert, die gerade von der CPU verwendet werden, und eine gesicherte Speichervorrichtung, die Software sicher speichert, die von der entsprechenden CPU ausgeführt werden soll. Somit umfasst Domäne A eine CPU-A 21, RAM-A 22 und einen gesicherten Speicher-A 23, der Software SW-A, Signaturen und kryptographische Schlüssel (z.B. geheime Schlüssel) sicher speichert. In ähnlicher Weise umfasst Domäne B eine CPU-B 24, RAM-B 25 und einen gesicherten Speicher-A 26, der Software SW-B, Signaturen und kryptographische Schlüssel (z.B. geheime Schlüssel) sicher speichert, wobei Software SW-A und Software SW-B verschiedene Softwareteile sind (d.h. sie unterscheiden sich voneinander).
Eine externe Vorrichtung, wie z.B. die externe Vorrichtung 2, kann so konfiguriert sein, dass sie entsprechende Software, geheime Schlüssel und Signaturen an eine entsprechende Domäne (z.B. an eine entsprechende gesicherte Speichervorrichtung) verteilt, lädt oder gemeinsam nutzt.
Zum Beispiel kann die externe Vorrichtung einen geheimen Schlüssel K1 mit Domäne A und einen geheimen Schlüssel K2 mit Domäne B teilen. Jeder geheime Schlüssel K1 und K2 kann gespeichert, verschlüsselt, in eingebettetem Flash, Sicherungen (Fuses) oder externem NOR- oder NAND-Flash gespeichert werden. Zum Beispiel kann Domäne A eingebettetes Flash oder Sicherungen verwenden, um ihren Schlüssel zu speichern (z.B. Schlüssel K1), während Domäne B externes NOR- oder NAND-Flash verwenden kann, um ihren Schlüssel zu speichern (z.B. Schlüssel K2). Die geheimen Schlüssel K1 und K2 können unterschiedliche Schlüssellängen haben, so dass das „Sicherheitsniveau“ und die geforderte Leistung zwischen den beiden Domänen variabel sein können. Zum Beispiel kann in den hier vorgestellten Beispielen der geheime Schlüssel K2 eine größere Schlüssellänge haben als der geheime Schlüssel K1.
Wenn eine entsprechende Domäne Zugang zu ihrem geheimen Schlüssel benötigt, kann der geheime Schlüssel in ein dediziertes Kryptomodul geladen werden. Es wird darauf hingewiesen, dass das dedizierte Kryptomodul der Domäne A vom dedizierten Kryptomodul der Domäne B abweichen kann. Beispielsweise kann das dedizierte Kryptomodul der Domäne A ein AES (Advanced Encryption Standard)-Kryptomodul sein, während das dedizierte Kryptomodul der Domäne B ein Salsa20-Kryptomodul, ein ChaCha-Kryptomodul oder ähnliches sein kann.
Zusätzlich berechnet die externe Vorrichtung verschiedene Hashes und Signaturen und transferiert die Software SW-A und die Signaturen SA1, SA*1 und SB1 nach Domäne A. Ebenso berechnet die externe Vorrichtung verschiedene Hashes und Signaturen und transferiert die Software SW-B und die Signaturen SB₂, SA₂ und SA*₂ nach Domäne B. Um die Signaturen zu berechnen, muss die externe Vorrichtung die entsprechenden Hashing-Algorithmen und Signaturalgorithmen kennen.
Software SW-A kann in eingebettetem Flash gespeichert sein und kann aufgrund der ECU-Registrierung in einem Fahrzeugbordnetz eine harte Boot-Zeitbeschränkung haben. Im Gegensatz dazu kann Software SW-B gespeichert, verschlüsselt, in externem Flash gespeichert sein und kann keine Boot-Zeitbeschränkung oder eine Soft-Boot-Zeitbeschränkung aufgrund der spät erforderlichen Verfügbarkeit beim Systemstart haben. So kann Software SW-B von externem Flash gebootet werden, das aus Sicherheitsgründen verschlüsselt sein muss.
Zur weiteren Diversifizierung von Domäne A und Domäne B können beide Domänen außerdem verschiedene Hash-Algorithmen (z.B. HASH-A bzw. HASH-B) und verschiedene Signaturalgorithmen (z.B. SIGN-A bzw. SIGN-B) verwenden.
3 ist ein Flussdiagramm eines sicheren Hybrid-Boot-Verfahrens 300, das in einer Hybridvorrichtung nach einer oder mehreren Ausführungsformen implementiert ist. Insbesondere zeigt das Flussdiagramm die jeweiligen Vorgänge von Domäne A und Domäne B während des sicheren hybriden Bootvorgangs (d.h. im Laufe der Zeit t), der das Booten der Software SW-A und SW-B umfasst. Gestrichelte Linien werden zur Kennzeichnung von Stellen verwendet, an denen ein Bootvorgang von Software oder ein Ausführungsvorgang von Software unterbrochen wird, um eine Authentizitätsverifikationsoperation durchzuführen.
Jede Authentizitätsverifikationsoperation kann dazu führen, dass die Authentizität von Software überprüft (d.h. genehmigt) oder für fehlerhaft befunden wird. Im letzteren Fall kann ein Fehler detektiert und ein Boot- oder Ausführungsinterrupt erzeugt werden, der den Boot- oder Ausführungsprozess in der jeweiligen Domäne stoppt und/oder dazu verwendet wird, einen Benutzer vor möglichen Manipulationen oder Beschädigungen der Software zu warnen.
Das sichere Hybrid-Boot-Verfahren 300 startet beide Domänen parallel. Beispielsweise können beide Domänen in den Vorgängen 305A bzw. 305B zu Beginn eines Fahrzeugfahrzyklus (d.h. zu einem Zeitpunkt, zu dem ein Fahrzeug gestartet wird) zurückgesetzt werden. Bei den Vorgängen 310A und 310B tauschen die beiden Domänen Sitzungsschlüssel aus, die für die sichere Kommunikation zwischen den beiden Domänen verwendet werden. Daher sind alle Austausche (d.h. Kommunikationen) über Domänen hinweg durch den Sitzungsschlüssel und Zeitstempel geschützt, um Wiederholungen und MITM (Man-in-the-Middle)-Angriffe zu verhindern. Das heißt, die beiden Domänen tauschen Informationen nur über gesicherte Kommunikation aus.
Bei den Vorgängen 315A und 320A ist die CPU 21 der Domäne A so konfiguriert, dass sie eine Authentizitätsverifikationsoperation für Software SW-A durchführt, um eine Echtzeitbeschränkung beim Booten und Ausführen von Software SW-A zu erfüllen. So berechnet die CPU 21 der Domäne A in Vorgang 315A den Hash X_A der Software SW-A unter Verwendung des Hashing-Algorithmus HASH-A. CPU 21/Domäne A sendet auch eine Kommunikation an Domäne B, die Hash X_A enthält, und Domäne B speichert den Hash X_A im gesicherten Speicher B 26 oder RAM-B 25 (siehe Vorgang 320B).
In Vorgang 320A berechnet die CPU 21 die Signatur von Hash X_A unter Verwendung des Signaturalgorithmus SIGN-A und des geheimen Schlüssels K1 und prüft die Authentizität der Software SW-A durch Vergleich der berechneten Signatur mit der gespeicherten Signatur SA₁. Wenn die beiden Signaturen übereinstimmen, fährt die CPU 21 fort zu booten und die Software SW-A in Vorgang 325A-1 auszuführen. Wenn die beiden Signaturen nicht übereinstimmen, erzeugt die CPU 21 einen Fehler.
Durch die Durchführung einer anfänglichen Authentizitätsverifikationsoperation führt die CPU 21 ihre eigene Software-Verifizierung durch, so dass die kritische Funktionalität der Software SW-A so schnell wie möglich zur Ausführung gelangen kann, um echtzeit- (z.B. sicherheits-) kritische Funktionalitäten online zu bringen. In der Zwischenzeit ist die CPU 24 der Domäne B auch so konfiguriert, dass sie parallel eine Authentizitätsverifikationsoperation an der Software SW-A durchführt.
In Vorgang 315B-1 ist die CPU 24 von Domäne B als Teil einer Authentizitätsverifikationsoperation der Software SW-B so konfiguriert, dass sie den Hash-Wert X_B der Software SW-B unter Verwendung des Hash-Algorithmus HASH-B berechnet, der in ihrer eigenen Authentizitätsverifikationsoperation verwendet wird. Darüber hinaus hat die CPU 24 möglicherweise Zugriff auf die Software SW-A auf Speicher 23 und kann daher den entsprechenden Hash X*_A unter Verwendung des Hashing-Algorithmus HASH-B berechnen. Diese Authentizitätsverifikationsoperation wird jedoch beim Empfang von Hash X_A von Domäne A unterbrochen, um eine zweite Authentizitätsverifikationsoperation für die Software SW-A durchzuführen.
In Vorgang 320B ist die CPU 24 so konfiguriert, dass sie eine zweite Authentizitätsverifikationsoperation an der Software SW-A unter Verwendung des Hashing-Algorithmus HASH-B durchführt. Der Hashing-Algorithmus HASH-B ist möglicherweise eine stärkere Hash-Funktion als der Hashing-Algorithmus HASH-A. Durch die Verwendung des Hashing-Algorithmus HASH-B bietet Domäne B somit eine vielfältige Authentizitätsprüfung für Software SW-A, die robuster gegen Angriffe ist als der Hashing-Algorithmus HASH-A. Der Kompromiss besteht darin, dass eine stärkere Hash-Funktion mehr Zeit für die Erzeugung und Überprüfung erfordert. Daher verwendet Domäne A eine weniger sichere Hashing-Funktion, die weniger Verarbeitungszeit benötigt, um ihre Echtzeitbeschränkung zu erfüllen. Im Gegensatz dazu verfügt Domäne B, die die Echtzeitbeschränkung von Domäne A nicht erfüllen muss, über ausreichend Zeit und Verarbeitungsbandbreite, um eine stärkere Hash-Funktion einzusetzen.
Mit anderen Worten muss die CPU 21 die Software SW-A innerhalb einer Zeitbeschränkung booten, so dass z.B. sicherheitskritische Funktionalitäten online gebracht werden, um eine Echtzeitbeschränkung zu erfüllen. Im Gegensatz dazu ist die CPU 24 so konfiguriert, dass sie die Software SW-B ohne jede Zeitbeschränkung oder mit einer geringeren Zeitbeschränkung im Vergleich zur Software SW-A bootet. Dies ermöglicht es der CPU 24, den Bootvorgang ihrer eigenen Software zu unterbrechen, um die Authentifizierungsprüfung der Software von der CPU 21 durchzuführen, die hinsichtlich der Funktionalität des Gesamtsystems (z.B. des gesamten Fahrzeugsystems) eine hohe Priorität hat. Sobald die CPU 24 die Authentifizierungsprüfung der Software SW-A abgeschlossen hat, nimmt sie den Bootvorgang der Software SW-B wieder auf.
Zurück zu Vorgang 320B empfängt die CPU 24 den Hash X_A von Domäne A, berechnet die Signatur des Hash X_A unter Verwendung des Signaturalgorithmus SIGN-B und des geheimen Schlüssels K2 und prüft die Authentizität der Software SW-A durch Vergleich der berechneten Signatur mit der gespeicherten Signatur SA₂. Wenn die beiden Signaturen übereinstimmen, erzeugt die CPU 24 keinen Fehler und die CPU 21 fährt mit der Ausführung der Software SW-A ohne Zwischenfall fort. Andererseits erzeugt die CPU 24 bei einer Nichtübereinstimmung zwischen den beiden Signaturen einen Fehler und benachrichtigt Domäne A. Es wird darauf hingewiesen, dass der geheime Schlüssel K2 eine größere Schlüssellänge als der geheime Schlüssel K1 haben kann, um eine höhere Sicherheitsstufe zu gewährleisten. Längere Verarbeitungszeiten, die mit größeren Schlüssellängen verbunden sind, können von der CPU 24 leichter absorbiert werden, da beim Booten der Software SW-B im Vergleich zu CPU 21 und der Software SW-A, die eine Echtzeitbeschränkung für die Boot-Zeit hat, keine Echtzeitbeschränkung besteht.
Nachdem die CPU 24 eine zweite Authentizitätsverifikationsoperation an der Software SW-A in Vorgang 320B durchgeführt hat, wird die Authentizitätsverifikationsoperation der Software SW-B in Vorgang 315B-2 fortgesetzt. Wenn die CPU 24 also die Erzeugung der Hashes X_B und X*_A (falls erforderlich) nicht abschließen konnte, schließt die CPU 24 die Erzeugung der Hashes in Vorgang 315B-2 ab und fährt dann mit Vorgang 325B fort. Darüber hinaus kann die CPU 24 so konfiguriert werden, dass sie die Hashes X_B und X*_A an Domäne A für eine zusätzliche Authentizitätsverifikationsoperation überträgt (siehe Vorgang 330A).
In Vorgang 325B führt die CPU 24 der Domäne B weiterhin die Authentizitätsverifikationsoperation der Software SW-B durch, indem sie die Signatur des Hash X_B unter Verwendung des Signaturalgorithmus SIGN-B und des geheimen Schlüssels K2 berechnet und die Authentizität der Software SW-B durch Vergleich der berechneten Signatur mit der gespeicherten Signatur SB₂ prüft. Wenn die beiden Signaturen übereinstimmen, dann bootet die CPU 24 weiter und führt die Software SW-B in Vorgang 330B aus. Wenn die beiden Signaturen nicht übereinstimmen, erzeugt die CPU 24 einen Fehler.
Darüber hinaus kann die CPU 24 in Vorgang 325B eine zusätzliche (d.h. dritte) Authentizitätsverifikationsoperation an der Software SW-A durchführen, indem sie die Signatur des Hash X*_A unter Verwendung des Signaturalgorithmus SIGN-B und des geheimen Schlüssels K2 berechnet und die Authentizität der Software SW-A durch Vergleich der berechneten Signatur mit der gespeicherten Signatur SA*₂ prüft. Wenn die beiden Signaturen übereinstimmen, wird kein Fehler erzeugt und Domäne A fährt mit dem Status Quo fort. Wenn die beiden Signaturen jedoch nicht übereinstimmen, erzeugt die CPU 24 einen Fehler und kann Domäne A benachrichtigen.
Um zu Domäne A zurückzukehren, führt die CPU 21 in Vorgang 330A als Reaktion auf den Empfang des Hash X_B von Domäne B eine zweite Authentizitätsverifikationsoperation der Software SW-B durch. Um diese Prüfung durchzuführen, unterbricht die CPU 21 die Ausführung der Software SW-A. Als Reaktion auf den Empfang von Hash X_B berechnet die CPU 21 die Signatur von Hash X_B unter Verwendung des Signaturalgorithmus SIGN-A und des geheimen Schlüssels K1 und prüft die Authentizität der Software SW-B durch Vergleich der berechneten Signatur mit der gespeicherten Signatur SB₁. Wenn die beiden Signaturen übereinstimmen, erzeugt die CPU 21 keinen Fehler und die CPU 24 fährt mit der Ausführung der Software SW-B ohne Zwischenfall fort. Wenn andererseits eine Nichtübereinstimmung zwischen den beiden Signaturen besteht, erzeugt die CPU 21 einen Fehler und benachrichtigt Domäne B.
Darüber hinaus kann die CPU 21 eine zusätzliche (d.h. vierte) Authentizitätsverifikationsoperation an der Software SW-A durchführen, indem sie die Signatur des Hash X*_A unter Verwendung des Signaturalgorithmus SIGN-A und des geheimen Schlüssels K1 berechnet und die Authentizität der Software SW-A durch Vergleich der berechneten Signatur mit der gespeicherten Signatur SA*₁ prüft. Wenn die beiden Signaturen übereinstimmen, wird kein Fehler erzeugt, und Domäne A fährt mit der Ausführung der Software SW-2 in Vorgang 325A-2 fort. Wenn die beiden Signaturen jedoch nicht übereinstimmen, erzeugt die CPU 21 einen Fehler.
In Anbetracht des oben Gesagten sind beide Domänen dafür verantwortlich, eine Authentizitätsverifikationsoperation mit ihrer jeweiligen Software durchzuführen. Darüber hinaus ist mindestens eine der Domänen so konfiguriert, dass sie eine Authentizitätsverifikationsoperation für die Software der anderen Domäne durchführt.
Weitere Varianten sind ebenfalls möglich. Es kann erforderlich sein, dass sowohl Domäne A als auch Domäne B so konfiguriert sind, dass sie die Authentizität der Hashes bestätigen (z.B. SA₁ und SA₂ im Fall von Domäne A). Beispielsweise prüft Domäne A den Hash X_A mit der Signatur SA₁ und Domäne B den Hash X_A mit der Signatur SA₂. Zusätzlich oder alternativ kann Domäne B den Hash X*_A mit der Signatur SA*₂ prüfen. Es ist möglich, dass Domäne A in ähnlicher Weise Prüfungen auf Hash X_B für Domäne B durchführen kann, wie oben beschrieben.
Dies kann aufgrund der vielfältigen Authentizitätsprüfung als „Sicherheitsmodus“ bezeichnet werden. Dies schließt eine Vielfalt bei der Hash-Berechnung ein, bei der Domänen A und B einen Hash für Domäne A berechnen (d.h. für Software SW-A). Domäne A verwendet einen schnelleren, aber schwächeren Hash (X_A) , während Domäne B einen stärkeren, aber langsameren Hash (X*_A) verwendet. Dies ermöglicht somit einen schnellen Boot-Start von Domäne A mit einfacher Authentizität, die durch eine hohe Authentizität durch den diversen, aus Domäne B berechneten Hash X*_A ergänzt wird. Im Allgemeinen bezieht sich der Sicherheitsmodus auf eine Konfiguration, bei der die Software einer Domäne mindestens zweimal überprüft wird, unter anderem durch die eigene Domäne und mindestens eine Gegenprüfung durch mindestens eine andere Domäne. Es kann auch verschiedene Stufen von Sicherheitsmodi geben, wobei ein höherer Sicherheitsmodus eine höhere Anzahl von Authentizitätsverifikationsoperationen oder Authentizitätsprüfungen umfasst, die in einer Domäne oder in zwei oder mehr Domänen durchgeführt werden.
In einer anderen Variante ist nur eine Domäne (A oder B) erforderlich, um die Authentizität der Software SW-A zu bestätigen, und nur eine Domäne (A oder B) ist erforderlich, um die Authentizität der Software SW-B zu bestätigen. Dies kann als „Fail Operational Mode“ bezeichnet werden und ermöglicht eine erhöhte Verfügbarkeit zum Beispiel bei zufälligen Hardware-Fehlern. So können in einer Variante eines Fehlerbetriebsmodus Domäne A und B getrennt voneinander booten, ohne sich gegenseitig zu überprüfen.
Eine Kombination verschiedener Modi oder Varianten kann während eines Fahrzyklus eines Fahrzeugs verwendet werden, wobei ein Fahrzyklus durch einen Zeitraum von einem Zeitpunkt des Einschaltens bis zu einem Zeitpunkt des Ausschaltens eines Fahrzeugs definiert ist. So kann zum Beispiel ein Sicherheitsmodus bei Kalteinschaltung (d.h. beim ersten Start des Fahrzeugs) und ein Ausfallbetriebsmodus oder ein niedrigerer Sicherheitsmodus nach der ersten Startphase oder nachdem das System eine vorbestimmte Zeit lang gelaufen ist, implementiert werden. Alternativ können verschiedene Modi beim Start nach dem Zufallsprinzip ausgewählt werden.
Eine Überwachungsfunktion einer ersten Domäne auf einer zweiten Domäne (d.h. die erste Domäne überwacht die zweite Domäne) kann in bestimmten konstanten oder zufälligen Intervallen ausgeführt werden.
Darüber hinaus wird parallel zur Hash-Berechnung ein Überwachungsmechanismus implementiert, bei dem eine Domäne so konfiguriert werden kann, dass sie die Hash-Berechnung der anderen Domäne überwacht, um sicherzustellen, dass es tatsächlich die überwachte Domäne ist, die den Hash der jeweiligen Software SW-X erzeugt hat. Dies ist von Interesse, um eine Situation zu verhindern, in der die überwachte Domäne einen „erfundenen Wert“ als Hash-Wert für ihre jeweilige Software SW-X darstellt. Beispielsweise kann die CPU 24 so konfiguriert sein, dass sie eine Hash-Erzeugungsoperation von Hash X_A überwacht, um sicherzustellen, dass die CPU 21 tatsächlich Hash X_A erzeugt oder erkennt, dass ein falscher Hash von der CPU 21 erzeugt oder von einem Angreifer eingespeist wurde.
Beispielsweise kann mindestens ein Hash-Erzeugungsparameter oder eine Metrik von der CPU 24 überwacht werden, die der Erzeugung von Hash X_A durch Domäne A entspricht. Zu den überwachten Parametern oder Metriken können gehören: die vergangene Ausführungszeit (z.B. basierend auf einer gemeinsamen Zeitbasis), der aktuelle CPU-Zustand (z.B. Programmzählerwerte), die Authentizität der Hash-Berechnungsfunktion und/oder die Authentizität der CPU-Konfiguration (z.B. Interrupt-Konfiguration, Debug-System-Konfiguration), von denen einer oder mehrere für die Erzeugung von Hash X_A durch Domäne A eindeutig sein können.
So kann die CPU 24 beim Empfang von Hash X_A (siehe z.B. Vorgang 320B in 3) prüfen, ob Hash X_A von der CPU 21 erzeugt wurde, indem sie jeden der einen oder mehreren überwachten Parameter oder Metriken von Domäne A mit einem entsprechenden vorgegebenen Parameter oder einer entsprechenden Metrik vergleicht. Sollte es eine Übereinstimmung geben, bestätigt die CPU 24, dass der Hash X_A von der CPU 21 erzeugt wurde. Sollte jedoch eine Abweichung in einem der überwachten Parameter oder einer der Metriken vorliegen, kennzeichnet die CPU 24 den empfangenen Hash X_A als fehlerhaft und gibt eine Warnung aus.
Die Überwachung von Domäne B durch Domäne A kann in ähnlicher Weise für jeden von der CPU 24 erzeugten Hash durchgeführt werden.
Es gibt mehrere Angriffsszenarien zur Prävention. Nachfolgend sind Beispiele für Angriffsszenarien für die Domäne A aufgeführt, die auch auf andere Domänen angewendet werden können und auch in beliebiger Kombination miteinander verwendet werden können.
In einem ersten Angriffsszenario wird Domäne A kompromittiert, der eigene sichere Bootvorgang von Domäne A wird nicht umgangen, und Domäne B zeigt den Fehler (d.h. den Angriff) an, nachdem der Fehler bestimmt wurde.
In einem zweiten Angriffsszenario ist Domäne A kompromittiert, der eigene sichere Bootvorgang von Domäne A wird umgangen, und Domäne A sendet seinen Hash-Wert nicht wie erwartet.
In einem dritten Angriffsszenario wird Domäne A kompromittiert, der eigene sichere Bootvorgang von Domäne A wird umgangen, und Domäne A sendet den falschen Hash-Wert, der von Domäne B detektiert wird.
In einem vierten Angriffsszenario ist der Signaturalgorithmus von Domäne A gebrochen (unsicher), und es wird ein Ausweichmechanismus über den noch sicheren Signaturalgorithmus von Domäne B bereitgestellt.
In einem fünften Angriffsszenario wird aufgrund einer zufälligen Sicherheitsüberprüfung von Domäne A durch Domäne B festgestellt, dass Domäne A nicht ordnungsgemäß funktioniert. So kann ein Angriff durch eine redundante Sicherheitsüberprüfung in Domäne B verhindert werden.
In einem sechsten Angriffsszenario wird eine Domäne kompromittiert, und die Ausführung von Schadsoftware weist unterschiedliche Merkmale auf, die über die Überwachungsfunktion (z.B. Laufzeit, Speicher,...) der anderen Domäne erkannt werden können.
In einem siebten Angriffsszenario wird die Kommunikation zwischen Domäne A und B durch einen „Dritten“ gestört (z.B. Überlastung des Busses,...), was zum Beispiel durch eine Zeitüberwachung erkannt werden kann.
In einem achten Angriffsszenario können Seitenkanalangriffe (z.B. Glitches), die in eine Domäne eingeführt werden und zu anomalem Verhalten führen, über eine Überwachungsfunktion (z.B. Laufzeit, Speicher) von einer anderen Domäne erkannt werden.
Obwohl sich die hier beschriebenen Ausführungsformen auf Fahrzeugsysteme beziehen, ist klar, dass die hier beschriebenen Konzepte in ähnlicher Weise auf jedes Hybridsystem ausgedehnt werden können, das mindestens zwei verschiedene Arten von Subsystemen verwendet, bei denen ein sicheres Bootverfahren wünschenswert ist.
Darüber hinaus sind zwar einige Aspekte im Zusammenhang mit einer Vorrichtung beschrieben worden, aber es ist klar, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, wobei ein Block oder eine Vorrichtung einem Verfahrensschritt oder einem Merkmal eines Verfahrensschrittes entspricht. Analog dazu stellen Aspekte, die im Zusammenhang mit einem Verfahrensschritt beschrieben werden, auch eine Beschreibung eines entsprechenden Blocks oder Elements oder Merkmals einer entsprechenden Vorrichtung dar. Einige oder alle Verfahrensschritte können von (oder unter Verwendung von) einer Hardwarevorrichtung, wie z.B. einem Mikroprozessor, einem programmierbaren Computer oder einer elektronischen Schaltung, ausgeführt werden. In einigen Ausführungsformen kann eine solche Vorrichtung einen oder mehrere der Verfahrensschritte ausführen.
Abhängig von bestimmten Implementierungsanforderungen können die hier zur Verfügung gestellten Ausführungsformen in Hardware und/oder in Software implementiert werden. Die Implementierung kann mit einem computerlesbaren, digitalen Speichermedium, z.B. einer DVD, einem Blue-Ray, einer CD, einem RAM-, einem ROM-, einem PROM-, einem EPROM-, einem EEPROM- oder einem FLASH-Speicher durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem zusammenarbeiten (oder zusammenarbeiten können), so dass das jeweilige Verfahren durchgeführt wird.
Befehle können von einem oder mehreren Prozessoren ausgeführt werden, wie z.B. einer oder mehreren CPUs (Central Processing Units), DSPs (Digital Signal Processors), Allzweck-Mikroprozessoren, ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays) oder anderen gleichwertigen integrierten oder diskreten Logikschaltungen. Dementsprechend bezieht sich der Begriff „Prozessor“, wie er hier verwendet wird, auf jede der vorstehenden Strukturen oder jede andere Struktur, die für die Implementierung der hier beschriebenen Techniken geeignet ist. Darüber hinaus kann die hier beschriebene Funktionalität in einigen Aspekten in speziellen Hardware- und/oder Softwaremodulen bereitgestellt werden. Außerdem könnten die Techniken vollständig in einer oder mehreren Schaltungen oder Logikelementen implementiert werden.
Die oben beschriebenen beispielhaften Ausführungsformen dienen lediglich der Veranschaulichung. Es wird davon ausgegangen, dass Änderungen und Variationen der Anordnungen und der hier beschriebenen Einzelheiten für den Fachmann offensichtlich sind. Es ist daher beabsichtigt, nur durch den Umfang der folgenden Patentansprüche begrenzt zu sein und nicht durch die spezifischen Einzelheiten, die durch die Beschreibung und die Erläuterung der Ausführungsformen hierin dargestellt sind.

Claims

Hybridvorrichtung, umfassend: eine Vielzahl verschiedener Subsysteme, einschließlich eines ersten Subsystems und eines zweiten Subsystems, wobei das erste Subsystem mindestens eine erste gesicherte Speichervorrichtung, die zum Speichern einer ersten Software konfiguriert ist, und eine erste CPU (Central Processing Unit), die zum Booten und Ausführen der ersten Software konfiguriert ist, umfasst, wobei das zweite Subsystem mindestens eine zweite gesicherte Speichervorrichtung, die zum Speichern einer zweiten Software konfiguriert ist, und eine zweite CPU, die zum Booten und Ausführen der zweiten Software konfiguriert ist, umfasst, wobei die mindestens eine erste gesicherte Speichervorrichtung ferner so konfiguriert ist, dass sie einen ersten geheimen Schlüssel und eine erste gespeicherte Signatur speichert, die einem ersten Hash der ersten Software entspricht, wobei die mindestens eine zweite gesicherte Speichervorrichtung ferner so konfiguriert ist, dass sie einen zweiten geheimen Schlüssel, eine zweite gespeicherte Signatur, die dem ersten Hash der ersten Software entspricht, und eine dritte gespeicherte Signatur, die einem ersten Hash der zweiten Software entspricht, speichert, wobei die erste CPU so konfiguriert ist, dass sie den ersten Hash der ersten Software erzeugt und den erzeugten ersten Hash der ersten Software an das zweite Subsystem überträgt, und wobei die zweite CPU so konfiguriert ist, dass sie eine erste Authentizitätsvalidierungsprüfung an der ersten Software unter Verwendung des empfangenen ersten Hash der ersten Software durchführt, und ein Fehlersignal unter einer Bedingung erzeugt, dass die erste Authentizitätsvalidierungsprüfung an der ersten Software fehlschlägt.
Hybridvorrichtung nach Anspruch 1, wobei die erste CPU so konfiguriert ist, dass sie die erste Software innerhalb einer Zeitbeschränkung bootet.
Hybridvorrichtung nach Anspruch 2, wobei die zweite CPU so konfiguriert ist, dass sie die zweite Software ohne Zeitbeschränkung bootet.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei die zweite CPU so konfiguriert ist, dass sie eine Hash-Erzeugungsoperation des ersten Subsystems überwacht und verifiziert, dass die erste CPU den ersten Hash erzeugt hat, basierend auf der Überwachung mindestens eines Hash-Erzeugungsparameters des ersten Subsystems.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei die erste CPU und die zweite CPU so konfiguriert sind, dass sie Sitzungsschlüssel austauschen und über eine gesicherte Kommunikation unter Verwendung der ausgetauschten Sitzungsschlüssel kommunizieren.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei: die erste CPU so konfiguriert ist, dass sie den ersten Hash der ersten Software erzeugt durch Anwenden einer ersten Hash-Funktion auf die erste Software, die zweite CPU so konfiguriert ist, dass sie die erste Authentizitätsvalidierungsprüfung durchführt durch Erzeugen einer erzeugten Signatur, die dem empfangenen ersten Hash der ersten Software entspricht, Vergleichen der erzeugten Signatur mit der zweiten gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der ersten Software basierend auf dem Vergleichsergebnis.
Hybridvorrichtung nach Anspruch 6, wobei: die erste CPU so konfiguriert ist, dass sie eine erste Hash-Funktion und einen ersten Signatur-Algorithmus anwendet, um jeweils Hashes und Signaturen in dem ersten Subsystem zu erzeugen, die zweite CPU so konfiguriert ist, dass sie eine zweite Hash-Funktion und einen zweiten Signatur-Algorithmus anwendet, um jeweils Hashes und Signaturen in dem zweiten Subsystem zu erzeugen, die erste Hash-Funktion und die zweite Hash-Funktion unterschiedlich sind, der erste Signatur-Algorithmus und der zweite Signatur-Algorithmus unterschiedlich sind, und eine erste Schlüssellänge des ersten geheimen Schlüssels sich von einer zweiten Schlüssellänge des zweiten geheimen Schlüssels unterscheidet, und die zweite CPU so konfiguriert ist, dass sie die erzeugte Signatur entsprechend dem empfangenen ersten Hash der ersten Software unter Verwendung des zweiten Signaturalgorithmus und des zweiten geheimen Schlüssels erzeugt.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei die erste CPU so konfiguriert ist, dass sie eine zweite Authentizitätsvalidierungsprüfung an der ersten Software durchführt durch Erzeugen einer erzeugten Signatur, die dem erzeugten ersten Hash der ersten Software entspricht, Vergleichen der erzeugten Signatur mit der ersten gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der ersten Software basierend auf dem Vergleichsergebnis.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei die zweite CPU so konfiguriert ist, dass sie den ersten Hash der zweiten Software erzeugt und eine erste Authentizitätsvalidierungsprüfung an der zweiten Software durchführt durch Erzeugen einer erzeugten Signatur, die dem erzeugten ersten Hash der zweiten Software entspricht, Vergleichen der erzeugten Signatur mit der dritten gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der zweiten Software basierend auf dem Vergleichsergebnis.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei: die erste CPU so konfiguriert ist, dass sie eine erste Hash-Funktion und einen ersten Signatur-Algorithmus anwendet, um jeweils Hashes und Signaturen in dem ersten Subsystem zu erzeugen, die zweite CPU so konfiguriert ist, dass sie eine zweite Hash-Funktion und einen zweiten Signatur-Algorithmus anwendet, um jeweils Hashes und Signaturen in dem zweiten Subsystem zu erzeugen, und die erste Hash-Funktion und die zweite Hash-Funktion unterschiedlich sind, und der erste Signatur-Algorithmus und der zweite Signatur-Algorithmus unterschiedlich sind.
Hybridvorrichtung nach Anspruch 10, wobei: die erste CPU so konfiguriert ist, dass sie eine zweite Authentizitätsvalidierungsprüfung an der ersten Software durchführt durch Erzeugen einer ersten erzeugten Signatur, die dem erzeugten ersten Hash der ersten Software entspricht unter Verwendung des ersten Signaturalgorithmus und des ersten geheimen Schlüssels, Vergleichen der ersten erzeugten Signatur mit der ersten gespeicherten Signatur, um ein erstes Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der ersten Software basierend auf dem ersten Vergleichsergebnis, die zweite CPU so konfiguriert ist, dass sie die erste Authentizitätsvalidierungsprüfung an der ersten Software durchführt durch Erzeugen einer zweiten erzeugten Signatur, die dem empfangenen ersten Hash der ersten Software unter Verwendung des zweiten Signaturalgorithmus und des zweiten geheimen Schlüssels entspricht, Vergleichen der zweiten erzeugten Signatur mit der zweiten gespeicherten Signatur, um ein zweites Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der ersten Software basierend auf dem zweiten Vergleichsergebnis.
Hybridvorrichtung nach Anspruch 11, wobei die zweite Hash-Funktion stärker ist als die erste Hash-Funktion.
Hybridvorrichtung nach Anspruch 11 oder 12, wobei die zweite CPU so konfiguriert ist, dass sie die erste Authentizitätsvalidierungsprüfung durchführt, während die erste CPU die erste Software ausführt.
Hybridvorrichtung nach einem der Ansprüche 11 bis 13, wobei die zweite CPU so konfiguriert ist, dass sie den ersten Hash der zweiten Software erzeugt und eine erste Authentizitätsvalidierungsprüfung der zweiten Software durchführt durch Erzeugen einer dritten erzeugten Signatur, die dem erzeugten ersten Hash der zweiten Software entspricht unter Verwendung des zweiten Signaturalgorithmus und des zweiten geheimen Schlüssels, Vergleichen der dritten erzeugten Signatur mit der dritten gespeicherten Signatur, um ein drittes Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der zweiten Software basierend auf dem dritten Vergleichsergebnis.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei: die zweite CPU so konfiguriert ist, dass sie den ersten Hash der zweiten Software erzeugt und den erzeugten ersten Hash der zweiten Software an das erste Subsystem überträgt, und die erste CPU so konfiguriert ist, dass sie eine erste Authentizitätsvalidierungsprüfung der zweiten Software unter Verwendung des empfangenen ersten Hash der zweiten Software durchführt, und ein Fehlersignal unter der Bedingung erzeugt, dass die erste Authentizitätsvalidierungsprüfung bei der zweiten Softwareprüfung fehlschlägt.
Hybridvorrichtung nach einem der vorhergehenden Ansprüche, wobei: die erste gespeicherte Signatur aus einem ersten Signaturalgorithmus unter Verwendung des ersten geheimen Schlüssels und des ersten Hash der ersten Software abgeleitet ist, der erste Hash der ersten Software aus einer ersten Hash-Funktion und der ersten Software abgeleitet ist, die zweite gespeicherte Signatur von einem zweiten Signaturalgorithmus abgeleitet ist unter Verwendung des zweiten geheimen Schlüssels und des ersten Hash der ersten Software, die dritte gespeicherte Signatur aus dem zweiten Signaturalgorithmus abgeleitet ist unter Verwendung des zweiten geheimen Schlüssels und des ersten Hash der zweiten Software, der erste Hash der zweiten Software von einer zweiten Hash-Funktion und der zweiten Software abgeleitet ist, wobei der erste geheime Schlüssel und der zweite geheime Schlüssel unterschiedliche Schlüssellängen haben, die erste Hash-Funktion und die zweite Hash-Funktion unterschiedlich sind und der erste Signaturalgorithmus und der zweite Signaturalgorithmus unterschiedlich sind.
Hybridvorrichtung nach Anspruch 16, wobei: die mindestens eine erste gesicherte Speichervorrichtung ferner so konfiguriert ist, dass sie eine vierte gespeicherte Signatur speichert, die dem ersten Hash der zweiten Software entspricht, die vierte Signatur aus dem ersten Signatur-Algorithmus unter Verwendung des ersten geheimen Schlüssels und des ersten Hash der zweiten Software abgeleitet ist, und der erste Hash der zweiten Software von der zweiten Hash-Funktion und der zweiten Software abgeleitet ist.
Hybridvorrichtung nach Anspruch 17, wobei: die zweite CPU so konfiguriert ist, dass sie den ersten Hash der zweiten Software erzeugt und den erzeugten ersten Hash der zweiten Software an das erste Subsystem überträgt, und die erste CPU so konfiguriert ist, dass sie eine erste Authentizitätsvalidierungsprüfung an der zweiten Software durchführt durch Verwenden des empfangenen ersten Hash der zweiten Software, um eine vierte erzeugte Signatur zu erzeugen, Vergleichen der vierten erzeugten Signatur mit der vierten gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und Verifizieren der Authentizität der zweiten Software basierend auf dem Vergleichsergebnis.
Hybridvorrichtung nach Anspruch 17 oder 18, wobei: die mindestens eine zweite gesicherte Speichervorrichtung ferner so konfiguriert ist, dass sie eine fünfte gespeicherte Signatur speichert, die einem zweiten Hash der ersten Software entspricht, die fünfte gespeicherte Signatur aus dem zweiten Signatur-Algorithmus unter Verwendung des zweiten geheimen Schlüssels und des zweiten Hash der ersten Software abgeleitet ist, und der zweite Hash der ersten Software von der zweiten Hash-Funktion und der ersten Software abgeleitet ist.
Hybridvorrichtung nach Anspruch 19, wobei: die zweite CPU konfiguriert ist, um auf die erste Software von der mindestens einen ersten gesicherten Speichervorrichtung zuzugreifen, den zweiten Hash der ersten Software basierend auf der zugegriffenen ersten Software zu erzeugen, und eine zweite Authentizitätsvalidierungsprüfung der ersten Software durchzuführen durch Erzeugen einer fünften erzeugten Signatur, die dem erzeugten zweiten Hash der ersten Software entspricht unter Verwendung des zweiten Signaturalgorithmus und des zweite geheimen Schlüssels, Vergleichen der fünften erzeugten Signatur mit der fünften gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der ersten Software basierend auf dem Vergleichsergebnis.
Verfahren zum Durchführen einer sicheren Ausführungsprozedur für eine Hybridvorrichtung, die mehrere verschiedene Subsysteme enthält, einschließlich eines ersten Subsystems, das eine erste Software, die in mindestens einer ersten gesicherten Speichervorrichtung gespeichert ist, bootet und ausführt, und eines zweiten Subsystems, das eine zweite Software, die in einer zweiten gesicherten Speichervorrichtung gespeichert ist, bootet und ausführt, wobei ein erster geheimer Schlüssel und eine erste gespeicherte Signatur, die einem ersten Hash der ersten Software entspricht, in dem mindestens einen ersten gesicherten Speicher gespeichert sind, und wobei ein zweiter geheimer Schlüssel, eine zweite gespeicherte Signatur, die dem ersten Hash der ersten Software entspricht, und eine dritte gespeicherte Signatur, die einem ersten Hash der zweiten Software entspricht, in der mindestens einen zweiten gesicherten Speichervorrichtung gespeichert sind, wobei das Verfahren umfasst: Erzeugen, durch das erste Subsystem, des ersten Hash der ersten Software; Übertragen, durch das erste Subsystem, des erzeugten ersten Hash der ersten Software an das zweite Subsystem; Durchführen, durch das zweite Subsystem, einer ersten Authentizitätsvalidierungsprüfung der ersten Software unter Verwendung des empfangenen ersten Hash der ersten Software; und Erzeugen, durch das zweite Subsystem, eines Fehlersignals unter der Bedingung, dass die erste Authentizitätsvalidierungsprüfung der ersten Software fehlschlägt.
Verfahren nach Anspruch 21, wobei: das Erzeugen, durch das erste Subsystem, des ersten Hash der ersten Software ein Anwenden einer ersten Hash-Funktion auf die erste Software aufweist, und das Durchführen, durch das zweite Subsystem, der ersten Authentizitätsvalidierungsprüfung der ersten Software ein Erzeugen einer erzeugten Signatur, die dem empfangenen ersten Hash der ersten Software entspricht, ein Vergleichen der erzeugten Signatur mit der zweiten gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und ein Verifizieren der Authentizität der ersten Software basierend auf dem Vergleichsergebnis, aufweist.
Verfahren nach Anspruch 21 oder 22, ferner umfassend: Durchführen, durch das erste Subsystem, einer zweiten Authentizitätsvalidierungsprüfung der ersten Software durch Erzeugen einer erzeugten Signatur, die dem erzeugten ersten Hash der ersten Software entspricht, Vergleichen der erzeugten Signatur mit der ersten gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und Verifizieren der Authentizität der ersten Software basierend auf dem Vergleichsergebnis.
Verfahren nach einem der Ansprüche 21 bis 23, ferner umfassend: Durchführen, durch das zweite Subsystem, einer ersten Authentizitätsvalidierungsprüfung der zweiten Software durch Erzeugen des ersten Hash der zweiten Software, Erzeugen einer erzeugten Signatur, die dem erzeugten ersten Hash der zweiten Software entspricht, Vergleichen der erzeugten Signatur mit der dritten gespeicherten Signatur, um ein Vergleichsergebnis zu erzeugen, und Verifizieren der Authentizität der zweiten Software basierend auf dem Vergleichsergebnis.
Verfahren nach einem der Ansprüche 21 bis 24, ferner umfassend: Anwenden, durch das erste Subsystem, einer ersten Hash-Funktion, um Hashes in dem ersten Subsystem zu erzeugen; Anwenden, durch das erste Subsystem, eines ersten Signaturalgorithmus unter Verwendung des ersten geheimen Schlüssels zur Erzeugung von Signaturen im ersten Subsystem; Anwenden, durch das zweite Subsystem, einer zweiten Hash-Funktion, um Hashes in dem zweiten Subsystem zu erzeugen; Anwenden, durch das zweite Subsystem, eines zweiten Signaturalgorithmus unter Verwendung des zweiten geheimen Schlüssels zur Erzeugung von Signaturen in dem zweiten Subsystem; wobei die erste Hash-Funktion und die zweite Hash-Funktion unterschiedlich sind, der erste Signaturalgorithmus und der zweite Signaturalgorithmus unterschiedlich sind, und der erste geheime Schlüssel und der zweite geheime Schlüssel unterschiedliche Schlüssellängen haben.
Verfahren nach Anspruch 25, ferner umfassend: Durchführen, durch das erste Subsystem, einer zweiten Authentizitätsvalidierungsprüfung der ersten Software durch Erzeugen einer ersten erzeugten Signatur, die dem erzeugten ersten Hash der ersten Software entspricht unter Verwendung des ersten Signaturalgorithmus und des ersten geheimen Schlüssels, Vergleichen der ersten erzeugten Signatur mit der ersten gespeicherten Signatur, um ein erstes Vergleichsergebnis zu erzeugen, und Verifizieren einer Authentizität der ersten Software basierend auf dem ersten Vergleichsergebnis, wobei das Durchführen, durch das zweite Subsystem, der ersten Authentizitätsvalidierungsprüfung der ersten Software ein Erzeugen einer zweiten erzeugten Signatur, die dem empfangenen ersten Hash der ersten Software entspricht unter Verwendung des zweiten Signaturalgorithmus und des zweiten geheimen Schlüssels, ein Vergleichen der zweiten erzeugten Signatur mit der zweiten gespeicherten Signatur, um ein zweites Vergleichsergebnis zu erzeugen, und ein Verifizieren einer Authentizität der ersten Software basierend auf dem zweiten Vergleichsergebnis, umfasst.