WO2023057506A1 - Recheneinheit für ein fahrzeug und verfahren und computerprogramm für eine recheneinheit für ein fahrzeug - Google Patents

Abstract

Die vorliegende Erfindung bezieht sich auf eine Recheneinheit für ein Fahrzeug, auf ein Verfahren und ein Computerprogramm für eine Recheneinheit für ein Fahrzeug, sowie auf ein Fahrzeug mit einer solchen Recheneinheit. Die Recheneinheit umfasst ein oder mehrere Speichergeräte, ausgebildet zum Speichern eines kryptographisch gesicherten Start-Basissystems der Recheneinheit, eines Betriebssystems der Recheneinheit und von ein oder mehreren Rechen-Funktionsblöcken des Fahrzeugs. Die Recheneinheit umfasst ferner ein oder mehrere Prozessoren, ausgebildet zum Starten des kryptographisch gesicherten Start-Basissystems der Recheneinheit. Die ein oder mehreren Prozessoren sind ausgebildet zum Überprüfen, durch das kryptographisch gesicherte Start-Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems. Die ein oder mehreren Prozessoren sind ausgebildet zum Starten des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde. Die ein oder mehreren Prozessoren sind ausgebildet zum Überprüfen, durch das kryptographisch gesicherte Start-Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen-Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke. Die ein oder mehreren Prozessoren sind ausgebildet zum Starten der ein oder mehreren Rechen-Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen-Funktionsblöcke festgestellt wurde.

Description

Beschreibung

Recheneinheit für ein Fahrzeug und Verfahren und Computerprogramm für eine Recheneinheit für ein Fahrzeug

Die vorliegende Erfindung bezieht sich auf eine Recheneinheit für ein Fahrzeug, auf ein Verfahren und ein Computerprogramm für eine Recheneinheit für ein Fahrzeug, sowie auf ein Fahrzeug mit einer solchen Recheneinheit.

In modernen Fahrzeugen wird eine immer größer werdende Anzahl von Funktionen durch Software bereitgestellt. Diese Funktionen werden meist durch Dienste implementiert (engl. „Services“), die auf Recheneinheiten des Fahrzeugs ausgeführt werden. Diese Funktionen können beispielsweise als Rechen-Funktionsblöcke (auch engl. „Container“) implementiert werden, die in Laufzeitumgebungen des Fahrzeugs ausgeführt werden.

Aus diesem Grund wird in Fahrzeugen häufig zwischen zwei Softwarekomponenten unterschieden - der Systemsoftware, und den Rechen-Funktionsblöcken. Dabei stellt die Systemsoftware meist die Laufzeitumgebung für die Rechen-Funktionsblöcke bereit.

Dieses Konzept wird auch in der sogenannten „Automotive Edge“ (wörtlich „Automotiver Rand“) verwendet, welche die Rechen-Funktionsblöcke und die Systemsoftware umfassen kann. Ein Ziel der Automotive Edge kann es sein, zu jedem Zeitpunkt die Möglichkeit zu haben, neue Funktionscontainer zu aktualisieren oder zu installieren. Beispielsweise kann es wünschenswert sein, dass die Software-Elemente der Automotive Edge jederzeit aktualisiert werden können (etwa mit einem Aktualisierungszyklus von zumindest einer Woche), ohne Auswirkungen auf den Rest des Systems, wobei nur die jeweiligen Anwendungen (Rechen-Funktionsblöcke) innerhalb des Edge aktualisiert werden, um neue Funktionen zu installieren. Die Automotive Edge kann dabei als Basisplattform für alle Online-Dienste im Fahrzeug genutzt werden.

Die eigentliche Systemsoftware wird durch die Aktualisierung großer Bereiche der Hardware aktualisiert, wobei komplexe Freigabeprozesse verwendet werden. Der Aktualisierungszyklus der Systemsoftware beträgt häufig etwa sechs Monate. Im vielen Automotive Edge-Systemen prüft ein sicherer Boot-Prozess (Start-Prozess) die Integrität der installierten Software. Wenn die installierte Software unverändert ist, startet der Boot-Prozess die Software. Ein solches "sicheres Starten” kann dort im Allgemeinen nur für statische Rechen-Funktionsblöcke verwendet werden, die in den statisch sicheren Boot- Prozess eingebunden sind - dynamische Software-Updates sind unter Umständen nicht möglich. Alternativ kann für dynamische Rechen-Funktionsblöcke auf eine Absicherung des Starts verzichtet werden. In anderen Systemen wird der meist statische sichere Startvorgang daher für statische Software verwendet (wie oben beschrieben). Außerdem können die Datenbereiche (die keine ausführbare Software enthalten) ungesichert bleiben.

Aus US 2020/0320201 A1 ist ein Konzept zum sicheren Booten von Fahrzeug-Prozessoren bekannt. Jedoch wird in diesem Konzept nicht zwischen Systemsoftware, die langen Veröffentlichungs-Zyklen unterliegt und Rechen-Funktionsblöcken unterschieden, die häufig aktualisiert werden sollen.

Aus WO 2020/070061 A1 und US 2019/0391802 A1 sind weitere Konzepte zum Erhöhen der Sicherheit von Software in Fahrzeugen bekannt. Jedoch nutzen beide Konzepte keinen sicheren Boot-Vorgang (engl. Secure Boot).

Es besteht der Bedarf, ein verbessertes Konzept zum sicheren Booten von Software-basierter Fahrzeugfunktionalität bereitzustellen.

Diesem Bedarf wird durch den Gegenstand der unabhängigen Ansprüche entsprochen.

Die vorliegende Erfindung basiert auf der Erkenntnis, dass ein sicherer Boot-Vorgang von Software eines Fahrzeugs in drei Bestandteile unterteilt werden kann. So kann ein Start- Basissystem über das Secure-Boot-Konzept gestartet werden. Innerhalb des derart gesicherten Start-Basissystems kann nun Funktionalität und kryptographische Information umfasst sein, die genutzt werden können, um die Integrität eines Betriebssystems (also der System software) anhand einer kryptographisch erzeugten Signatur des Betriebssystems zu überprüfen und, sofern das Betriebssystem integer ist, das Betriebssystem zu starten. Nun kann wiederum das Betriebssystem, oder alternativ das Start-Basissystem, genutzt werden, um die Integrität der Rechen-Funktionsblöcke mittels entsprechender kryptographisch erzeugter Signaturen der Rechen-Funktionsblöcke zu überprüfen und diese zu starten, sofern diese integer sind. So wird eine Vertrauenskette (engl. „chain of trust“) von dem über Secure Boot gesicherten Start- Basissystem zu dem Betriebssystem und den Rechen-Funktionsblöcken gebildet, so dass auch diese gesichert gestartet werden können. Dabei können die Rechen-Funktionsblöcke, zusammen mit den dazugehörigen kryptographisch erzeugten Signaturen, in einem kürzeren Zyklus als etwa das Betriebssystem, und insbesondere als das Start-Basissystem aktualisiert werden, wobei die Vertrauenskette intakt bleibt. Damit bezieht sich das vorgestellte Konzept auf ein sicheres Starten für dynamische Rechen-Funktionsblöcke (Container).

Ein Aspekt der vorliegenden Offenbarung bezieht sich auf eine Recheneinheit für ein Fahrzeug. Die Recheneinheit umfasst ein oder mehrere Speichergeräte, ausgebildet zum Speichern eines kryptographisch gesicherten Start-Basissystems der Recheneinheit, eines Betriebssystems der Recheneinheit und von ein oder mehreren Rechen-Funktionsblöcken des Fahrzeugs. Die Recheneinheit umfasst ferner ein oder mehrere Prozessoren, ausgebildet zum Starten des kryptographisch gesicherten Start-Basissystems der Recheneinheit. Die ein oder mehreren Prozessoren sind ausgebildet zum Überprüfen, durch das kryptographisch gesicherte Start- Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems. Die ein oder mehreren Prozessoren sind ausgebildet zum Starten des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde. Die ein oder mehreren Prozessoren sind ausgebildet zum Überprüfen, durch das kryptographisch gesicherte Start-Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen-Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke. Die ein oder mehreren Prozessoren sind ausgebildet zum Starten der ein oder mehreren Rechen-Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen- Funktionsblöcke festgestellt wurde. Dabei können die Rechen-Funktionsblöcke, zusammen mit den dazugehörigen kryptographisch erzeugten Signaturen, in einem kürzeren Zyklus als etwa das Betriebssystem, und insbesondere als das Start-Basissystem aktualisiert werden, wobei die Vertrauenskette intakt bleibt.

Durch die vorgeschlagene Recheneinheit wird eine Vertrauenskette (engl. „chain of trust“) von dem kryptographisch gesicherten Start-Basissystem zu dem Betriebssystem und den ein oder mehreren Rechen-Funktionsblöcken gebildet, so dass auch diese gesichert gestartet werden können. Folglich kann die Überprüfung der ein oder mehreren Rechen-Funktionsblöcke auf einer Vertrauenskette basieren, die auf das kryptographisch gesicherte Start-Basissystem zurückführt. In manchen Beispielen erfolgt das Überprüfen der Integrität der ein oder mehreren Rechen- Funktionsblöcke durch das kryptographisch gesicherte Start-Basissystem der Recheneinheit. Dabei kann beispielsweise die Funktionalität, die für das Überprüfen des Betriebssystems verwendet wurde, wiederverwendet werden. Allerdings muss dies möglicherweise außerhalb des Betriebssystems geschehen.

Alternativ kann das Überprüfen der Integrität der ein oder mehreren Rechen-Funktionsblöcke durch das Betriebssystem der Recheneinheit erfolgen. Hier kann die Überprüfung innerhalb des Betriebssystems erfolgen, so dass ein Wechsel in das Start-Basissystem nicht nötig ist.

Das kryptographisch gesicherte Start-Basissystem und/oder das Betriebssystem kann beispielsweise in einem kryptographisch gesicherten Speicherbereich oder in einem Nur-Lese- Speicherbereich der ein oder mehreren Speichergeräte gespeichert sein. Dies kann Veränderungen des Start-Basissystems oder des Betriebssystems erschweren oder verhindern. Allerdings wird ein Aufwand für die Aktualisierung erhöht, da der Speicherbereich ersetzt werden muss oder eine kryptographische Absicherung implementiert werden muss.

Demgegenüber können die ein oder mehreren Rechen-Funktionsblöcke in einem beschreibbaren Speicherbereich der ein oder mehreren Speichergeräte gespeichert sein. Dies vereinfacht die Aktualisierung der ein oder mehreren Rechen-Funktionsblöcke. Durch die Überprüfung der kryptographisch erzeugten Signatur der ein oder mehreren Rechen- Funktionsblöcke kann dabei die Sicherheit gewahrt werden.

Beispielsweise können die ein oder mehreren Prozessoren ausgebildet sein, um, durch das Betriebssystem, eine Rechen-Funktionseinheit dadurch zu aktualisieren, dass die aktualisierte Rechen-Funktionseinheit zusammen mit einer entsprechenden kryptographisch erzeugten Signatur empfangen und in den beschreibbaren Speicherbereich gespeichert wird. Die Integrität der aktualisierten Rechen-Funktionseinheit kann dabei basierend auf der entsprechenden kryptographisch erzeugten Signatur überprüft werden.

Die ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen- Funktionsblöcke können beispielsweise fahrzeugspezifisch sein. Hierdurch können Szenarien vermieden werden, in denen die Sicherheit dadurch kompromittiert wird, dass ein Rechen- Funktionsblocks eines anderen Fahrzeugs oder Fahrzeugtyps, der basierend auf derselben Art von kryptographisch erzeugten Signaturen gesichert ist, auf einem nicht unterstützten Fahrzeug ausgeführt wird. Die Überprüfung der fahrzeugspezifischen kryptographisch erzeugten Signaturen kann dabei an fahrzeugspezifische Gegenstände gekoppelt werden. So können die ein oder mehreren Prozessoren ausgebildet sein, um einen kryptographischen Schlüssel zur Überprüfung der ein oder mehreren Rechen-Funktionsblöcke von einem Fahrzeugschlüssel des Fahrzeugs abzurufen. In anderen Worten kann der Fahrzeugschlüssel des Fahrzeugs einen Speicher umfassen, der einen fahrzeugspezifischen kryptographischen Schlüssel zur Überprüfung der ein oder mehreren Rechen-Funktionsblöcke umfasst, etwa einen fahrzeugspezifischen öffentlichen Schlüssel eines Public-Key-Infrastruktur (PKI, Öffentlicher-Schlüssel-Infrastruktur).

Wie bereits zuvor erwähnt, können ein oder mehreren Rechen-Funktionsblöcke unabhängig von dem Betriebssystem aktualisierbar sein. Hierdurch kann ein deutlich kürzerer Aktualisierungszyklus für die ein oder mehreren Rechen-Funktionsblöcke als für das Betriebssystem erreicht werden.

Das Starten der ein oder mehreren Rechen-Funktionsblöcke kann verweigert werden, falls die Überprüfung der ein oder mehreren kryptographisch erzeugten Signaturen fehlschlägt. Somit kann eine Ausführung möglicherweise unsicherer Rechen-Funktionsblöcke verhindert werden.

Beispielsweise können die ein oder mehreren Prozessoren ausgebildet sein, um ein Fehlschlagen der Prüfung der ein oder mehreren kryptographisch erzeugten Signaturen an eine entfernte Gegenstelle zu melden. Hierdurch können Fehler im Signierprozess nachvollzogen werden und fehlgeschlagene Angriffe auf die Sicherheit der Recheneinheit protokolliert werden.

Ein Aspekt der vorliegenden Offenbarung bezieht sich auf ein Fahrzeug, umfassend die zuvor vorgestellte Recheneinheit.

Ein Aspekt der vorliegenden Offenbarung bezieht sich auf ein entsprechendes Verfahren für eine Recheneinheit für ein Fahrzeug. Das Verfahren umfasst ein Speichern eines kryptographisch gesicherten Start-Basissystems der Recheneinheit, eines Betriebssystems der Recheneinheit und von ein oder mehreren Rechen-Funktionsblöcken des Fahrzeugs. Das Verfahren umfasst ferner ein Starten des kryptographisch gesicherten Start-Basissystems der Recheneinheit. Das Verfahren umfasst ferner ein Überprüfen, durch das kryptographisch gesicherte Start-Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems. Das Verfahren umfasst ferner ein Starten des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde. Das Verfahren umfasst ferner ein Überprüfen, durch das kryptographisch gesicherte Start-Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen-Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen- Funktionsblöcke. Das Verfahren umfasst ferner ein Starten der ein oder mehreren Rechen- Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen-Funktionsblöcke festgestellt wurde.

Ein Aspekt der vorliegenden Offenbarung bezieht sich auf ein entsprechendes Programm mit einem Programmcode zum Durchführen des zuvor vorgestellten Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.

Einige Beispiele von Vorrichtungen und/oder Verfahren werden nachfolgend bezugnehmend auf die beiliegenden Figuren lediglich beispielhaft näher erläutert. Es zeigen:

Fig. lazeigt ein Blockdiagramm eines Beispiels einer Recheneinheit für ein Fahrzeug;

Fig. 1b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs mit einer Recheneinheit für ein Fahrzeug;

Fig. 1c zeigt ein Flussdiagramm eines Beispiels eines Verfahrens für eine Recheneinheit für ein Fahrzeug; und

Fig. 2 zeigt ein schematisches Diagramm eines Beispiels eines Zusammenspiels verschiedener Komponenten in einer Recheneinheit für ein Fahrzeug.

Einige Beispiele werden nun ausführlicher Bezug nehmend auf die beiliegenden Figuren beschrieben. Weitere mögliche Beispiele sind jedoch nicht auf die Merkmale dieser detailliert beschriebenen Ausführungsformen beschränkt. Diese können Modifikationen der Merkmale sowie Entsprechungen und Alternativen zu den Merkmalen aufweisen. Ferner soll die Terminologie, die hierin zum Beschreiben bestimmter Beispiele verwendet wird, nicht einschränkend für weitere mögliche Beispiele sein.

Gleiche oder ähnliche Bezugszeichen beziehen sich in der gesamten Beschreibung der Figuren auf gleiche oder ähnliche Elemente beziehungsweise Merkmale, die jeweils identisch oder auch in abgewandelter Form implementiert sein können, während sie die gleiche oder eine ähnliche Funktion bereitstellen. In den Figuren können ferner die Stärken von Linien, Schichten und/oder Bereichen zur Verdeutlichung übertrieben sein.

Wenn zwei Elemente A und B unter Verwendung eines „oder“ kombiniert werden, ist dies so zu verstehen, dass alle möglichen Kombinationen offenbart sind, d. h. nur A, nur B sowie A und B, sofern nicht im Einzelfall ausdrücklich anders definiert. Als alternative Formulierung für die gleichen Kombinationen kann „zumindest eines von A und B“ oder „A und/oder B“ verwendet werden. Das gilt Äquivalent für Kombinationen von mehr als zwei Elementen.

Wenn eine Singularform, beispielsweise „ein, eine“ und „der, die, das“ verwendet wird und die Verwendung nur eines einzelnen Elements weder explizit noch implizit als verpflichtend definiert ist, können weitere Beispiele auch mehrere Elemente verwenden, um die gleiche Funktion zu implementieren. Wenn eine Funktion im Folgenden als unter Verwendung mehrerer Elemente implementiert beschrieben ist, können weitere Beispiele die gleiche Funktion unter Verwendung eines einzelnen Elements oder einer einzelnen Verarbeitungsentität implementieren. Es versteht sich weiterhin, dass die Begriffe „umfasst", „umfassend“, „aufweist“ und/oder „aufweisend“ bei deren Gebrauch das Vorhandensein der angegebenen Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/oder einer Gruppe derselben beschreiben, dabei aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/einer Gruppe derselben ausschließen.

Fig. 1a zeigt ein Blockdiagramm eines Beispiels einer Recheneinheit 10 für ein Fahrzeug 100. Die Recheneinheit 10 umfasst ein oder mehrere Speichergeräte 16, ausgebildet zum Speichern eines kryptographisch gesicherten Start-Basissystems 18a der Recheneinheit, eines Betriebssystems 18b der Recheneinheit und von ein oder mehreren Rechen-Funktionsblöcken 18d des Fahrzeugs. Die Recheneinheit 10 umfasst ferner ein oder mehrere Prozessoren 14, und optional ein oder mehrere Schnittstellen 12. Die ein oder mehreren Prozessoren 14 sind mit den eine oder mehreren Speichergeräten 16 sowie den ein oder mehreren, optionalen Schnittstelle 12 gekoppelt. Im Allgemeinen wird die Funktionalität der Recheneinheit 10 von den ein oder mehreren Prozessoren 14 bereitgestellt, mit Hilfe der ein oder mehreren Schnittstellen 12 (zum Austausch von Informationen, etwa zur Kommunikation mit einem Backend-Server, einem entfernten Server) und/oder mit Hilfe der ein oder mehreren Speichergeräte 16 (zum Speichern und Abrufen von Informationen). Die ein oder mehreren Prozessoren sind ausgebildet zum Starten des kryptographisch gesicherten Start-Basissystems der Recheneinheit. Die ein oder mehreren Prozessoren sind ausgebildet zum Überprüfen, durch das kryptographisch gesicherte Start-Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems. Die ein oder mehreren Prozessoren sind ausgebildet zum Starten des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde. Die ein oder mehreren Prozessoren sind ausgebildet zum Überprüfen, durch das kryptographisch gesicherte Start-Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen-Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen- Funktionsblöcke. Die ein oder mehreren Prozessoren sind ausgebildet zum Starten der ein oder mehreren Rechen-Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen- Funktionsblöcke festgestellt wurde.

Fig. 1b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs 100 mit der Recheneinheit 10. Folglich kann die Recheneinheit 10 eine Recheneinheit des Fahrzeugs 100 sein, etwa eine Fahrzeug-Recheneinheit. Die Recheneinheit 10 kann ausgebildet sein zum Bereitstellen von Software-basierter Fahrzeug-Funktionalität.

Fig. 1c zeigt ein Flussdiagramm eines Beispiels eines entsprechenden Verfahrens für die Recheneinheit für das Fahrzeug. Das Verfahren umfasst ein Speichern 110 eines kryptographisch gesicherten Start-Basissystems der Recheneinheit, eines Betriebssystems der Recheneinheit und von ein oder mehreren Rechen-Funktionsblöcken des Fahrzeugs. Das Verfahren umfasst ein Starten 120 des kryptographisch gesicherten Start-Basissystems der Recheneinheit. Das Verfahren umfasst ein Überprüfen 130, durch das kryptographisch gesicherte Start-Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems. Das Verfahren umfasst ein Starten 140 des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde. Das Verfahren umfasst ein Überprüfen 150, durch das kryptographisch gesicherte Start-Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen-Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke. Das Verfahren umfasst ein Starten 160 der ein oder mehreren Rechen-Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen-Funktionsblöcke festgestellt wurde. Beispielsweise kann das Verfahren durch die Recheneinheit 10 durchgeführt werden, etwa durch die ein oder mehreren Prozessoren 14 der Recheneinheit oder durch die ein oder mehreren Speichergeräte 16 der Recheneinheit (zum Speichern des kryptographisch gesicherten Start-Basissystems der Recheneinheit, des Betriebssystems der Recheneinheit und von den ein oder mehreren Rechen-Funktionsblöcken des Fahrzeugs).

Im Folgenden wird die Funktionalität der Recheneinheit in Bezug auf die Recheneinheit 10 der Fign. 1a und 1b eingeführt. Merkmale, die im Rahmen der Recheneinheit 10 der Fign. 1a und/oder 1 b eingeführt werden, können ebenfalls in das entsprechende Verfahren von Fig. 1c übernommen werden.

Die vorliegende Offenbarung befasst sich mit der Recheneinheit 10 für ein Fahrzeug. Diese Recheneinheit kann beispielsweise eine Recheneinheit einer Mehrzahl von Recheneinheiten eines Fahrzeugs sein. Beispielsweise kann die Recheneinheit, wie bereits angesprochen, eine Recheneinheit zum Bereitstellen von Software-basierte Fahrzeug-Funktionalität sein.

Diese Fahrzeug-Funktionalität wird im Wesentlichen von der Mehrzahl von Rechen- Funktionsblöcken bereitgestellt. Die Rechen-Funktionsblöcke sind logische Einheiten, die software-basierte Fahrzeugfunktionalitäten bereitstellen. Dabei kann eine Technik genutzt werden, in der Dienste, die Software-Funktionalitäten des Fahrzeugs bereitstellen, in die Rechen-Funktionsblöcke verpackt werden. Diese Rechen-Funktionsblöcke können wiederum durch sogenannte Software-Container implementiert werden oder diesen entsprechen. Ein oder mehrere Dienste können mit all ihren Abhängigkeiten in einem Software-Container gekapselt werden. Diese Container sind insbesondere zur Nutzung auf Servern und Entwicklergeräten bekannt. Beispielsweise können solche Container von verschiedenen Container-Engines (Docker, Podman, Crio, ...) bereitgestellt werden. Die vorliegende Offenbarung stellt eine Nutzung solcher Container in einem Fahrzeug bereit. Dabei kann die Recheneinheit 10 ausgebildet sein, um eine Laufzeitumgebung (18c in Fig. 1a) für die Rechen- Funktionsblöcke/Container bereitzustellen. Diese Laufzeitumgebung kann wiederum von dem Betriebssystem der Recheneinheit bereitgestellt werden.

Die ein oder mehreren Rechen-Funktionsblöcke sind somit an der Spitze eines Schichtenmodells - Die ein oder mehreren Rechenfunktionsblöcke 18d werden, wie in Fig. 1a gezeigt ist, in einer Laufzeitumgebung 18c ausgeführt, welche wiederum in dem Betriebssystem 18b ausgeführt oder von dem Betriebssystem 18b bereitgestellt wird. Dieses wiederum wird von dem Start-Basissystem 18a überprüft und gestartet. Dabei geht von dem Start-Basissystem eine Vertrauenskette aus, mit der die Ausführung des Betriebssystems, und entweder direkt oder transitiv über das Betriebssystem, die Ausführung der ein oder mehreren Rechen- Funktionsblöcke abgesichert wird.

Ausgangspunkt der Vertrauenskette ist das Start-Basissystem, das, wie das Betriebssystem und die ein oder mehreren Rechen-Funktionsblöcke auch, in den ein oder mehreren Speichergeräten der Recheneinheit gespeichert sind. Dabei können das Start-Basissystem und das Betriebssystem auf der einen Seite, und die ein oder mehreren Rechen-Funktionseinheiten auf der anderen Seite, durchaus unterschiedlich behandelt werden und unterschiedlich gespeichert sein. So kann das Start-Basissystem beispielsweise in einem Nur-Lese-Speicher (Englisch „read only memory”) der Recheneinheit gespeichert sein. Beispiels kann da Start- Basissystem ein Teil einer sogenannten Firmware der Recheneinheit sein. Dieses Start- Basissystem kann beispielsweise nur durch sogenanntes „Flashen“ der Firmware verändert werden. Alternativ kann das Start-Basissystem zusammen mit dem Betriebssystem verändert werden, etwa durch „Flashen“ der Firmware, oder durch Speichern des Start-Basissystems und des Betriebssystems in einem zusätzlich abgesicherten Speicherbereich der ein oder mehreren Speichergeräte. Beispielsweise kann das kryptographisch gesicherte Start-Basissystem und das Betriebssystem in einem kryptographisch gesicherten Speicherbereich oder in einem Nur- Lese-Speicherbereich der ein oder mehreren Speichergeräte gespeichert sein. Dabei kann der Nur-Lese-Speicherbereich einen Hardware-Schutz gegen Veränderungen aufweisen, der etwa nur durch „Flashen“ der Firmware (oder durch eine Hardware-Überbrückung) überwunden werden kann. Der kryptographisch gesicherte Speicherbereich kann eine kryptographisch generierte Signatur aufweisen, wobei Anhand der kryptographisch generierten Signatur Änderungen des kryptographisch gesicherten Speicherbereichs erkannt werden können. Dabei kann die kryptographisch generierte Signatur auf einem Hash-Wert (Verwürflungswert) der in dem kryptographischen gesicherten Speicherbereich gespeicherten Daten basieren, wobei der Hash-Wert basierend auf einem privaten kryptographischen Schlüssel (etwa des Herstellers der Recheneinheit oder des Fahrzeugherstellers) verschlüsselt wurde, um die kryptographisch generierte Signatur zu erzeugen. Die Signatur, d.h. der kryptographisch verschlüsselte Hash- Wert kann mittels eines zu dem privaten Schlüssel passenden öffentlichen Schlüssels überprüft werden, um die Integrität des kryptographisch gesicherten Speicherberichts zu überprüfen.

Die vorliegende Offenbarung basiert auf kryptographisch erzeugten Signaturen sowie kryptographischen Schlüsseln. Wie die Nutzung der Terme „privater Schlüssel“ und „öffentlicher Schlüssel“ bereits andeutet wird im Folgenden von der Nutzung eines Public-Key-Verfahrens ausgegangen, das auf einem öffentlichen und einem dazugehörigen privaten Schlüssel basiert. Die ein oder mehreren Rechen-Funktionsblöcke können dagegen in einem beschreibbaren Speicherbereich der ein oder mehreren Speichergeräte gespeichert sein. Dies kann getan werden, um zu ermöglichen, dass die ein oder mehreren Rechen-Funktionsblöcke unabhängig von dem Start-Basissystem und unabhängig von dem Betriebssystem aktualisiert werden können. In anderen Worten können die ein oder mehreren Rechen-Funktionsblöcke unabhängig von dem Betriebssystem aktualisierbar sein. Die Aktualisierung eines Rechen- Funktionsblocks kann dabei durch das Betriebssystem durchgeführt werden, indem der aktualisierte Rechen-Funktionsblock empfangen wird, etwa von einem Backend-Server (etwa dem Backend-Server 200 von Fig. 2), und eine entsprechende kryptographisch erzeugte Signatur des aktualisierten Rechen-Funktionsblocks zusammen mit dem aktualisierten Rechen- Funktionsblock empfangen wird. Bei dem vorgeschlagenen Konzept kann der Rechen- Funktionsblock etwa von einem Backend-Server heruntergeladen und in einem (ungesicherten) Datenspeicher, wie etwa dem beschreibbaren Speicherbereich, abgelegt werden. Auf diesen (ungesicherten) Datenspeicher können Angreifer gegebenenfalls zugreifen und ihn verändern/überschreiben, was jedoch durch die Prüfung der Signatur erkannt werden kann. Beispielsweise können die ein oder mehreren Prozessoren ausgebildet sein, um, durch das Betriebssystem, eine Rechen-Funktionseinheit dadurch zu aktualisieren, dass die aktualisierte Rechen-Funktionseinheit zusammen mit einer entsprechenden kryptographisch erzeugten Signatur empfangen und in den beschreibbaren Speicherbereich gespeichert wird. Der Rechen- Funktionsblock ist jedoch durch eine auf dem Backend-Server laufende Operation verifiziert und erhält ein Zertifikat, Token usw. (die kryptographisch erzeugte Signatur), wenn die Backend- Prüfungen erfolgreich sind.

Dem Backend-Server kann dabei die Rolle zukommen, die verwendeten kryptographisch erzeugten Signaturen (der ein oder mehreren Rechen-Funktionsblöcke, sowie optional des Betriebssystems und/oder des Start-Basissystems) zu erzeugen. In anderen Worten können die verwendeten kryptographisch erzeugten Signaturen von dem Backend -Server erzeugt sein. Ferner können die ein oder mehreren Rechen-Funktionsblöcke von dem Backend-Server zusammen mit den ein oder mehreren Signaturen für die Recheneinheit bereitgestellt, und daher auch aktualisiert werden. Wird ein Rechen-Funktionsblock aktualisiert, wird gleichzeitig auch die entsprechende Signatur aktualisiert und mit dem Rechen-Funktionsblock bereitgestellt.

In dem vorgeschlagenen Konzept wird eine zweistufige Sicherheitsstrategie verwendet. In diesem zweistufigen Konzept verwendet die Systemsoftware weiterhin die bestehende sichere Boot-Operation (engl. Secure Boot) - und wird daher als sicher angesehen. Folglich sind die ein oder mehreren Prozessoren ausgebildet zum Starten des kryptographisch gesicherten Start- Basissystems der Recheneinheit. Dabei wird die kryptographische Sicherung des Start- Basissystems genutzt, um die Secure Boot-Funktionalität oder eine Secure Boot-ähnliche Funktionalität bereitzustellen. Das Start-Basissystem kann wiederum durch eine kryptographisch erzeugte Signatur gesichert sein, die von der Recheneinheit, etwa von einem sogenannten UEFI (Unified Extensible Firmware Interface, Vereinheitliche, erweiterbare Firmware-Schnittstelle) geprüft wird und nach Prüfung gestartet wird. Dabei kann das Start- Basissystem etwa einen Boot-Lader bereitstellen, der wiederum genutzt werden kann, um das Betriebssystem zu prüfen und zu starten. Die Rechen-Funktionsblöcke verwenden im Gegensatz dazu nicht die bestehende Secure Boot-Operation.

Ist der Start des Start-Basissystems erfolgreich, etwa weil die kryptographische Sicherung des Start-Basissystems intakt ist, kann nun das Betriebssystem überprüft und gestartet werden. Die ein oder mehreren Prozessoren sind ausgebildet, zum Überprüfen, durch das kryptographisch gesicherte Start-Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems. Ähnlich wie in Bezug auf den kryptographisch gesicherten Speicherbereich geschrieben, kann das Überprüfen darauf basieren, dass die kryptographisch erzeugte Signatur basierend auf einem Hash-Wert des (integren) Betriebssystem und basierend auf einem privaten Schlüssel (etwa des Herstellers der Recheneinheit, des Fahrzeugs oder des Betriebssystems) erzeugt ist, wobei die Signatur basierend auf einem dazugehörigen öffentlichen Schlüssel (etwa des Herstellers der Recheneinheit, des Fahrzeugs oder des Betriebssystems) und dem Hash-Wert des Betriebssystems überprüft werden kann. Der öffentliche Schlüssel kann beispielsweise in dem Start-Basissystem umfasst sein und daher über die Secure Boot-Funktionalität geschützt sein. Die ein oder mehreren Prozessoren sind ausgebildet zum Starten des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde. Somit konnte zum Überprüfen und Starten des Betriebssystems die Vertrauenskette von dem Start-Basissystem auf das Betriebssystem ausgeweitet werden.

Diese Vertrauenskette wird nun auf die Rechen-Funktionsblöcke ausgeweitet.

Während des Startvorgangs der Rechen-Funktionsblöcke im Fahrzeug kann nun die Systemsoftware, also das Betriebssystem oder das Start-Basissystem, das Zertifikat, das Token usw. (also die Signatur) sowie die Integrität des Funktionscontainers prüfen, beispielsweise durch eine Hash/Prüfsummenprüfung und/oder eine Zertifikatsprüfung. Die ein oder mehreren Prozessoren sind ausgebildet zum Überprüfen, durch das kryptographisch gesicherte Start- Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen- Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke. Ähnlich wie auch die Prüfung der Integrität des Betriebssystems kommen wieder kryptographisch erzeugte Signaturen zum Einsatz. Wiederum kann das Überprüfen eines Rechen-Funktionsblocks darauf basieren, dass die kryptographisch erzeugte Signatur basierend auf einem Hash-Wert des (integren) Rechen- Funktionsblocks und basierend auf einem privaten Schlüssel (etwa des Herstellers der Recheneinheit, des Fahrzeugs oder des Rechen-Funktionsblocks) erzeugt ist, wobei die Signatur basierend auf einem dazugehörigen öffentlichen Schlüssel (etwa des Herstellers der Recheneinheit, des Fahrzeugs oder des Rechen-Funktionsblocks) und dem Hash-Wert des Rechen-Funktionsblocks überprüft werden kann. Der öffentliche Schlüssel kann beispielsweise in dem Start-Basissystem umfasst sein und daher über die Secure Boot-Funktionalität geschützt sein, oder der öffentliche Schlüssel kann in dem Betriebssystem umfasst und daher transitiv über das Start-Basissystem geschützt sein. Daher kann die Überprüfung der ein oder mehreren Rechen-Funktionsblöcke auf einer Vertrauenskette basieren, die auf das kryptographisch gesicherte Start-Basissystem zurückführt, etwa direkt oder transitiv über das Start-Basissystem.

Bisher wurde davon ausgegangen, dass die kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke mit einem nicht fahrzeug-spezifischen Schlüssel erzeugt wurden, etwa einem privaten Schlüssel des Herstellers der Recheneinheit, des Fahrzeugs oder des jeweiligen Rechen-Funktionsblocks. In manchen Fällen kann das Konzept jedoch dahingehend erweitert werden, dass hier ein kryptographischer Schlüssel zum Einsatz kommt, der fahrzeugspezifisch ist (d.h. für ein einziges Fahrzeug verwendet wird). Folglich können die ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen- Funktionsblöcke fahrzeugspezifisch sein. Dazu kann beispielsweise von einem (privaten) kryptographischen Schlüssel des Herstellers der Recheneinheit, des Fahrzeugs oder des Rechen-Funktionsblocks ein fahrzeug-spezifischer (privater) Schlüssel abgeleitet werden, der wiederum genutzt wird, um die kryptographisch erzeugte Signatur des Rechen-Funktionsblocks zu erzeugen. Die Signatur kann dann beispielsweise anhand eines entsprechenden fahrzeugspezifischen öffentlichen Schlüssels geprüft werden. Die Herkunft dieses fahrzeugspezifischen öffentlichen Schlüssels kann nun basierend auf dem öffentlichen Schlüssel des Herstellers der Recheneinheit, des Fahrzeugs oder des Rechen-Funktionsblocks überprüft werden. Der fahrzeugspezifische (öffentliche) Schlüssel kann nun in dem Start- Basissystem oder in dem Betriebssystem hinterlegt werden. Optional kann eine Synchronisierung über einen Autoschlüssel durchgeführt werden (beispielsweise kann die Backend-Verifizierung den Rechen-Funktionsblock mit einem privaten Schlüssel signieren, wobei dem Autoschlüssel ein entsprechender öffentlicher Schlüssel zugewiesen wird). Die ein oder mehreren Prozessoren können somit ausgebildet sein, um den (öffentlichen) kryptographischen Schlüssel zur Überprüfung der ein oder mehreren Rechen-Funktionsblöcke von einem (physikalischen) Fahrzeugschlüssel des Fahrzeugs abzurufen, etwa über die ein oder mehreren Schnittstellen 12.

Sind diese Prüfungen erfolgreich, darf der Systemcontainer gestartet werden, da eine vertrauenswürdige Kette aus dem sicheren Boot-Prozess des Fahrzeugs, der Systemsoftware, den Backend-Prüfungen (zur Generierung der Signaturen) und dem Funktionscontainer aufgebaut ist. Die ein oder mehreren Prozessoren sind daher ausgebildet zum Starten der ein oder mehreren Rechen-Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen- Funktionsblöcke festgestellt wurde. Sind diese Prüfungen nicht erfolgreich (weil beispielsweise die Funktionssoftware durch einen Angreifer verändert wurde), wird die Software nicht gestartet. Folglich wird das Starten der ein oder mehreren Rechen-Funktionsblöcke verweigert, falls die Überprüfung der ein oder mehreren kryptographisch erzeugten Signaturen fehlschlägt.

Optional kann im Backend ein Alarm ausgelöst werden, wenn eine modifizierte Software erkannt wird, und es können zusätzliche Abschaltungen für andere Funktionen / Operationen durchgeführt werden. Folglich können die ein oder mehreren Prozessoren ausgebildet sein, um ein Fehlschlagen der Prüfung der ein oder mehreren kryptographisch erzeugten Signaturen an eine entfernte Gegenstelle zu melden. Auch können die ein oder mehreren Prozessoren ausgebildet sein, um eine Ausführung des Betriebssystems, der Laufzeitumgebung und/oder zumindest eines Rechen-Funktionsblocks einzuschränken, falls die Prüfung der ein oder mehreren kryptographisch erzeugten Signaturen fehlschlägt.

Das vorgeschlagene Konzept schafft somit einen zweistufigen (oder dreistufigen) sicheren Boot-Prozess für Systemsoftware und Rechen-Funktionsblöcke. Sicheres Booten wird auf Systemebene ermöglicht, und eine Verifizierung der in die sichere Systemsoftware eingebauten Rechen-Funktionsblocks wird genutzt, um den sicheren Boot-Prozess auf die Rechen- Funktionsblocks auszuweiten. Dabei kann die Verifizierung durch das Backend durchgeführt werden, indem die Signaturen von dem Backend erzeugt werden. Somit wird eine Kombination aus Secure Boot für System software und eine Backend-Prüfung der Rechen-Funktionsblöcke bereitgestellt. Eine Vertrauenskette wird ausgehend von der sicheren Systemsoftware über die Verifikationsfunktionalität in der Systemsoftware und die Verifikation durch das Backend aufgebaut. Das gleiche Konzept kann beispielsweise für sicherheitsrelevante Rechen-Funktionsblocks- Aktualisierungen für industrielle Anwendungen genutzt werden.

Die ein oder mehreren Schnittstellen 12 können beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.

Die ein oder mehreren Prozessoren 14 können einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Funktionalität der ein oder mehreren Prozessoren 14 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern können die ein oder mehreren Prozessoren 14 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung denkbar. Dabei können die ein oder mehreren Prozessoren, etwa im Zusammenspiel mit einer Firmware/UEFI, dazu ausgebildet sein, eine Secure Boot-Operation bereitzustellen (um das Start-Basissystem zu Überprüfen oder zu starten).

Die ein oder mehreren Speichergeräte 16 können beispielsweise zumindest ein Element der Gruppe von computerlesbares Speichermedium, magnetisches Speichermedium, optisches Speichermedium, Festplatte, Flash-Speicher, Diskette, Zufallszugriffsspeicher (auch engl. Random Access Memory), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), Electronically Erasable Programmable Read Only Memory (EEPROM), und Netzwerkspeicher umfassen.

Mehr Details und Aspekte der Recheneinheit sowie des entsprechenden Verfahrens und Computerprogramms und des Fahrzeugs werden in Verbindung mit dem Konzept oder Beispielen genannt, die vorher oder nachher beschrieben werden (siehe Fig. 2). Die Recheneinheit, das entsprechende Verfahren und/oder Computerprogramm und das Fahrzeug können ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben wurden. Fig. 2 zeigt ein schematisches Diagramm eines Beispiels eines Zusammenspiels verschiedener Komponenten in einer Recheneinheit 10 für ein Fahrzeug. Dabei kann die Recheneinheit 10 der Recheneinheit 10 der Fign. 1a und/oder 1b entsprechen. Die Recheneinheit 10, die in einem Fahrzeug angeordnet ist, umfasst einen Secure Boot-Block 18a, der das Start-Basissystem umfasst und als erstes gestartet wird (gezeigt durch die Zahl 1 im Kreis). Basierend auf dem Secure Boot-Block 18a wird das Betriebssystem 18b sowie ein Rechen-Funktionsblock (RFB)- Boot-System 18e gestartet (gezeigt durch die Zahl 2 im Kreis). Dabei kann das RFB-Boot- System 18e Teil des Betriebssystems sein. Das RFB-Boot-System 18e kann dazu ausgebildet sein, die Integrität der Rechen-Funktionsblöcke RFB1-RFB4 18d durchzuführen. Das Betriebssystem 18b, das RFB-Boot-System 18e und die Rechen-Funktionsblöcke RFB1-FRB4 18d sind durch kryptographisch erzeugte Signaturen geschützt (dargestellt durch die Zahl 2 im eckigen Kasten), die von dem Backend-Server 200 erzeugt sind. Das RFB-Boot-System 18e kann einen fahrzeugspezifischen öffentlichen Schlüssel von dem Fahrzeugschlüssel 105 empfangen.

Mehr Details und Aspekte der Recheneinheit werden in Verbindung mit dem Konzept oder Beispielen genannt, die vorher oder nachher beschrieben werden (siehe Fign. 1a bis 1c). Die Recheneinheit kann ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben wurden.

Die Aspekte und Merkmale, die im Zusammenhang mit einem bestimmten der vorherigen Beispiele beschrieben sind, können auch mit einem oder mehreren der weiteren Beispiele kombiniert werden, um ein identisches oder ähnliches Merkmal dieses weiteren Beispiels zu ersetzen oder um das Merkmal in das weitere Beispiel zusätzlich einzuführen.

Beispiele können weiterhin ein (Computer-)Programm mit einem Programmcode zum Ausführen eines oder mehrerer der obigen Verfahren sein oder sich darauf beziehen, wenn das Programm auf einem Computer, einem Prozessor oder einer sonstigen programmierbaren Hardwarekomponente ausgeführt wird. Schritte, Operationen oder Prozesse von verschiedenen der oben beschriebenen Verfahren können also auch durch programmierte Computer, Prozessoren oder sonstige programmierbare Hardwarekomponenten ausgeführt werden. Beispiele können auch Programmspeichervorrichtungen, beispielsweise Digitaldatenspeichermedien, abdecken, die maschinen-, Prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme und Anweisungen codieren beziehungsweise enthalten. Die Programmspeichervorrichtungen können beispielsweise Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren, Steuereinheiten, (feld-)programmierbare Logik-Arrays ((F)PLAs = (Field) Programmable Logic Arrays), (feld-)programmierbare Gate-Arrays ((F)PGA = (Field) Programmable Gate Arrays), Grafikprozessoren (GPU = Graphics Processor Unit), anwendungsspezifische integrierte Schaltungen (ASIC = application-specific integrated circuit), integrierte Schaltungen (IC= Integrated Circuit) oder Ein-Chip-Systeme (SoC = System-on-a- Chip) abdecken, die zum Ausfuhren der Schritte der oben beschriebenen Verfahren programmiert sind.

Es versteht sich ferner, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Schritte, Prozesse, Operationen oder Funktionen nicht als zwingend in der beschriebenen Reihenfolge befindlich ausgelegt werden soll, sofern dies nicht im Einzelfall explizit angegeben oder aus technischen Gründen zwingend erforderlich ist. Daher wird durch die vorhergehende Beschreibung die Durchführung von mehreren Schritten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt. Ferner kann bei weiteren Beispielen ein einzelner Schritt, eine einzelne Funktion, ein einzelner Prozess oder eine einzelne Operation mehrere Teilschritte, -funktionen, -prozesse oder -Operationen einschließen und/oder in dieselben aufgebrochen werden.

Wenn einige Aspekte in den vorhergehenden Abschnitten im Zusammenhang mit einer Vorrichtung oder einem System beschrieben wurden, sind diese Aspekte auch als eine Beschreibung des entsprechenden Verfahrens zu verstehen. Dabei kann beispielsweise ein Block, eine Vorrichtung oder ein funktionaler Aspekt der Vorrichtung oder des Systems einem Merkmal, etwa einem Verfahrensschritt, des entsprechenden Verfahrens entsprechen. Entsprechend dazu sind Aspekte, die im Zusammenhang mit einem Verfahren beschrieben werden, auch als eine Beschreibung eines entsprechenden Blocks, eines entsprechenden Elements, einer Eigenschaft oder eines funktionalen Merkmals einer entsprechenden Vorrichtung oder eines entsprechenden Systems zu verstehen.

Die folgenden Ansprüche werden hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch als getrenntes Beispiel für sich stehen kann. Ferner ist zu beachten, dass - obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine bestimmte Kombination mit einem oder mehreren anderen Ansprüchen bezieht - andere Beispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs umfassen können. Solche Kombinationen werden hiermit explizit vorgeschlagen, sofern nicht im Einzelfall angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Ferner sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt als abhängig von diesem anderen unabhängigen Anspruch definiert ist.

Bezugszeichenliste 10 Recheneinheit 12 Schnitstelle 14 Prozessor

Speichergerät a Start-Basissystem b Betriebssystem c Laufzeitumgebung d Rechen-Funktionsblöcke e Rechen-Funktionsblock-Boot-Prozess 0 Fahrzeug 5 Fahrzeugschlüssel 0 Speichern eines kryptographisch gesicherten Start-Basissystems, eines Betriebssystems und von ein oder mehreren Rechen-Funktionsblöcken 0 Starten des kryptographisch gesicherten Start-Basissystems 0 Überprüfen des Betriebssystems 0 Starten des Betriebssystems 0 Überprüfen der ein oder mehreren Rechen-Funktionsblöcke 0 Starten der ein oder mehreren Rechen-Funktionsblöcke 0 Backend-Server

Claims

Patentansprüche Eine Recheneinheit (10) für ein Fahrzeug, umfassend:

Ein oder mehrere Speichergeräte (16), ausgebildet zum Speichern eines kryptographisch gesicherten Start-Basissystems (18a) der Recheneinheit, eines Betriebssystems (18b) der Recheneinheit und von ein oder mehreren Rechen- Funktionsblöcken (18d) des Fahrzeugs; und

Ein oder mehrere Prozessoren (14), ausgebildet zum:

Starten des kryptographisch gesicherten Start-Basissystems der Recheneinheit;

Überprüfen, durch das kryptographisch gesicherte Start- Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems;

Starten des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde;

Überprüfen, durch das kryptographisch gesicherte Start-Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen-Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke; und

Starten der ein oder mehreren Rechen-Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen-Funktionsblöcke festgestellt wurde. Die Vorrichtung gemäß Anspruch 1, wobei die Überprüfung der ein oder mehreren Rechen-Funktionsblöcke auf einer Vertrauenskette basiert, die auf das kryptographisch gesicherte Start-Basissystem zurückführt. Die Vorrichtung gemäß einem der Ansprüche 1 oder 2, wobei das Überprüfen der Integrität der ein oder mehreren Rechen-Funktionsblöcke durch das kryptographisch gesicherte Start-Basissystem der Recheneinheit erfolgt. Die Vorrichtung gemäß einem der Ansprüche 1 oder 2, wobei das Überprüfen der Integrität der ein oder mehreren Rechen-Funktionsblöcke durch das Betriebssystem der Recheneinheit erfolgt. Die Vorrichtung gemäß einem der Ansprüche 1 bis 4, wobei das kryptographisch gesicherte Start-Basissystem und das Betriebssystem in einem kryptographisch gesicherten Speicherbereich oder in einem Nur-Lese-Speicherbereich der ein oder mehreren Speichergeräte gespeichert sind. Die Vorrichtung gemäß einem der Ansprüche 1 bis 5, wobei die ein oder mehreren Rechen-Funktionsblöcke in einem beschreibbaren Speicherbereich der ein oder mehreren Speichergeräte gespeichert sind. Die Vorrichtung gemäß Anspruch 6, wobei die ein oder mehreren Prozessoren ausgebildet sind, um, durch das Betriebssystem, eine Rechen-Funktionseinheit dadurch zu aktualisieren, dass die aktualisierte Rechen-Funktionseinheit zusammen mit einer entsprechenden kryptographisch erzeugten Signatur empfangen und in den beschreibbaren Speicherbereich gespeichert wird. Die Vorrichtung gemäß einem der Ansprüche 1 bis 7, wobei die ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke fahrzeugspezifisch sind. Die Vorrichtung gemäß Anspruch 8, wobei die ein oder mehreren Prozessoren ausgebildet sind, um einen kryptographischen Schlüssel zur Überprüfung der ein oder mehreren Rechen-Funktionsblöcke von einem Fahrzeugschlüssel des Fahrzeugs abzurufen. Die Vorrichtung gemäß einem der Ansprüche 1 bis 9, wobei die ein oder mehreren Rechen-Funktionsblöcke unabhängig von dem Betriebssystem aktualisierbar sind. Die Vorrichtung gemäß einem der Ansprüche 1 bis 10, wobei das Starten der ein oder mehreren Rechen-Funktionsblöcke verweigert wird, falls die Überprüfung der ein oder mehreren kryptographisch erzeugten Signaturen fehlschlägt. , Die Vorrichtung gemäß einem der Ansprüche 1 bis 11 , wobei die ein oder mehreren Prozessoren ausgebildet sind, um ein Fehlschlagen der Prüfung der ein oder mehreren kryptographisch erzeugten Signaturen an eine entfernte Gegenstelle zu melden. . Ein Fahrzeug (100), umfassend die Recheneinheit (10) gemäß einem der Ansprüche 1 bis 12. . Ein Verfahren für eine Recheneinheit für ein Fahrzeug, umfassend:

Speichern (110) eines kryptographisch gesicherten Start-Basissystems der Recheneinheit, eines Betriebssystems der Recheneinheit und von ein oder mehreren Rechen-Funktionsblöcken des Fahrzeugs;

Starten (120) des kryptographisch gesicherten Start-Basissystems der Recheneinheit;

Überprüfen (130), durch das kryptographisch gesicherte Start-Basissystem, einer Integrität des Betriebssystems der Recheneinheit basierend auf einer kryptographisch erzeugten Signatur des Betriebssystems;

Starten (140) des Betriebssystems der Recheneinheit, falls die Integrität des Betriebssystems festgestellt wurde;

Überprüfen (150), durch das kryptographisch gesicherte Start-Basissystem oder durch das Betriebssystem, einer Integrität der ein oder mehreren Rechen-Funktionsblöcke des Fahrzeugs basierend auf ein oder mehreren kryptographisch erzeugten Signaturen der ein oder mehreren Rechen-Funktionsblöcke; und

Starten (160) der ein oder mehreren Rechen-Funktionsblöcke, falls die Integrität der ein oder mehreren Rechen-Funktionsblöcke festgestellt wurde. , Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß Anspruch 14, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.