-
Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf ein Verfahren, auf eine Fahrzeugkomponente und auf ein Computerprogramm zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs, und auf ein Fahrzeug mit einer entsprechenden Fahrzeugkomponente.
-
Moderne Fahrzeuge verfügen über eine Vielzahl von verschiedenen Fahrzeugkomponenten, wobei auf manchen Fahrzeugkomponenten Computerprogramme ausführbar sind. Beispielsweise verfügen Fahrzeuge über ein Infotainment- und Navigationssystem, dessen Funktionalität durch Software bereitgestellt wird. Doch auch andere Fahrzeugkomponenten, wie etwa ein E-Call-System (Elektronisches Anrufsystem) wird zumindest durch einen Prozessor implementiert, auf dem ein Computerprogram ausgeführt wird. Im Sinne der Fahrsicherheit hat der Hersteller des Fahrzeugs jedoch ein Interesse daran, dass Computerprogramme, die auf dem Fahrzeug ausgeführt werden, getestet und durch den Hersteller freigegeben sind. Daher kann der Fahrzeughersteller sich darum bemühen, auf den Komponenten des Fahrzeugs die Integrität und Authentizität der Software sicherzustellen. Dies erfolgt durch kryptographische Maßnahmen. Beispiele hierfür sind in den Schriften
DE 101 40 721 A1 und
DE 103 54 107 A1 gegeben.
-
Im Entwicklungsprozess eines Fahrzeugs werden viele der Fahrzeugkomponenten von Zulieferern bereitgestellt. Diese stellen im Allgemeinen auch die dazugehörige Software bereit, nach Spezifikation der Fahrzeugherstellen. Zudem wird nach und nach auch Software von Drittherstellern bereitgestellt, etwa Software zum Zugriff auf Online-Musikbibliotheken, Software zum Verknüpfen von Fahrzeugen und Mobilgeräten, oder Software zum Lokalisieren und Abfragen von Ladesäulen. Diese Zulieferer oder Dritthersteller benötigen Möglichkeiten, um die von Ihnen entwickelte Software auf den jeweiligen Fahrzeugkomponenten, oder direkt im Fahrzeug, zu testen, möglichst auf der Serienfassung der jeweiligen Fahrzeugkomponente. Um zu verhindern, dass Fahrzeugkomponenten ohne kryptographische Absicherung auf dem grauen Markt gehandelt werden, wird diese Software, genau wie die in den Serienfahrzeugen eingesetzte Software, durch den Fahrzeughersteller signiert und kann dann im Fahrzeug oder auf der Fahrzeugkomponente getestet werden. Dies erhöhte den Aufwand und die Anforderungen an das kryptographiebasierte Sicherheitssystem des Fahrzeugherstellers und stellt ein Nadelöhr und eine Fehlerquelle im Entwicklungsprozess dar.
-
Es besteht daher ein Bedarf daran, ein verbessertes Konzept zum Entwickeln und Testen von Computerprogrammen für Fahrzeugkomponenten eines Fahrzeugs bereitzustellen.
-
Diesem Bedarf tragen das Verfahren, die Fahrzeugkomponente sowie das Computerprogramm nach den unabhängigen Ansprüchen Rechnung.
-
Verschiedene Aspekte der vorliegenden Erfindung basieren auf der Erkenntnis, dass der Entwicklungs- und Testablauf für Computerprogramme für eine Fahrzeugkomponente dadurch verbessert werden kann, dass, zusätzlich zu den für den Serienbetrieb der Fahrzeugkomponente vorgesehenen kryptographischen Maßnahmen, eine Identifikationsinformation und ein zusätzlicher Prüfschlüssel in die Fahrzeugkomponente eingebracht werden können. Dabei wird der zusätzliche Prüfschlüssel genutzt, um die Ausführung des zu testenden Computerprogramms abzusichern. Dieser zusätzliche Prüfschlüssel ist zudem kryptographisch an die Identifikationsinformation geknüpft, so dass dieser Prüfschlüssel nur in genau dieser Fahrzeugkomponente verwendet werden kann. Das auszuführende Computerprogramm wird nun von dem Entwickler kryptographisch signiert. Diese Signatur wird nun geprüft und für gültig erklärt, falls sie einerseits mittels des zusätzlichen Prüfschlüssel geprüft werden kann und andererseits auf der Identifikationsinformation basiert. Somit kann den Entwicklern des Zulieferers oder des Drittherstellern die Möglichkeit eingeräumt werden, möglichst eigenständig Software auf Serienkomponenten zu testen, ohne dass hierbei die Sicherheit der Serienkomponente, wie sie in anderen Fahrzeugen verbaut ist, beeinträchtigt wird. Nach Beendigung des Entwicklungsprozesses wird der zusätzliche Prüfschlüssel wieder entfernt.
-
Ausführungsbeispiele schaffen ein Verfahren zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs. Das Verfahren umfasst ein Hinterlegen, im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente. Die Identifikationsinformation ist spezifisch für die Fahrzeugkomponente. Das Verfahren umfasst ferner ein Hinterlegen eines zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses, der an die Identifikationsinformation durch eine kryptografische Signatur gekoppelt ist. Das Verfahren umfasst ferner ein Erhalten des Computerprogramms für die Fahrzeugkomponente. Das Computerprogramm ist kryptographisch signiert. Das Verfahren umfasst ferner ein Ausführen des Computerprogramms, falls die kryptographische Signatur des Computerprogramms nach Prüfung mit dem eingebrachten Prüfschlüssel gültig ist und auf der Identifikationsinformation basiert. Optional umfasst das Verfahren ferner ein Entfernen des zusätzlichen Prüfschlüssels, nachdem der Entwicklungsprozess abgeschlossen ist. Durch das vorgeschlagene Verfahren kann den Entwicklern des Zulieferers oder des Drittherstellern die Möglichkeit eingeräumt werden, möglichst eigenständig Software auf Serienkomponenten zu testen, ohne dass hierbei die Sicherheit der Serienkomponente, wie sie in anderen Fahrzeugen verbaut ist, beeinträchtigt wird.
-
Wie zuvor ausgeführt wird der Prüfschlüssel verwendet, um während des Entwicklungsprozesses die kryptographische Infrastruktur des Fahrzeugherstellers nicht über Gebühr zu beanspruchen. Beispielsweise kann der zusätzliche Prüfschlüssel dazu vorgesehen sein, die Ausführung von Computerprogrammen zusätzlich zu einer Public-Key-Infrastruktur (Öffentlicher Schlüssel-Infrastruktur) eines Herstellers des Fahrzeugs zu ermöglichen.
-
Die Identifikationsinformation ist an die spezifische Fahrzeugkomponente gebunden. Diese Eigenschaft kann nun genutzt werden, um die Verwendbarkeit des signierten Computerprogramms auf eine Fahrzeugkomponente oder wenige Fahrzeugkomponenten einzuschränken. So kann die kryptographische Signatur des Computerprogramms spezifisch für eine einzige Fahrzeugkomponente oder ein einziges Fahrzeug sein. Alternativ kann die kryptographische Signatur des Computerprogramms spezifisch für eine definierte Menge an Fahrzeugkomponenten oder Fahrzeugen sein.
-
Dies kann dadurch geschehen, dass die jeweilige Identifikationsinformation einer oder mehrerer Fahrzeugkomponenten Eingang in die Signatur das Computerprogramms findet. Beispielsweise kann das Computerprogramm zusammen mit ein oder mehreren Identifikationsinformationen ein oder mehrerer Fahrzeugkomponenten oder Fahrzeuge signiert sein.
-
Das vorgestellte Verfahren hat das Ziel, die Entwicklungsarbeit der Zulieferer und Dritthersteller von Software zu erleichtern. Gleichzeitig ist zu beachten, dass diese Funktionalität nicht auf eine beliebige Anzahl Fahrzeugkomponenten erweiterbar ist. Daher kann der zusätzliche Prüfschlüssel seinerseits von dem Fahrzeughersteller signiert und damit an die Identifikationsinformation gebunden werden. In anderen Worten kann die kryptographische Signatur, mit der der zusätzliche Prüfschlüssel an die Identifikationsinformation gekoppelt ist von dem Hersteller des Fahrzeugs generiert sein.
-
Die kryptographische Signatur des Computerprogramms wiederum kann basierend auf der Identifikationsinformation der Fahrzeugkomponente oder des Fahrzeugs durch einen Hersteller der Fahrzeugkomponente oder durch einen Dritten generiert sein, also ausdrücklich nicht durch den Fahrzeughersteller, so dass die Kryptographieinfrastruktur des Fahrzeugherstellers nicht in Anspruch genommen werden muss, wenn eine neue Testfassung in die Fahrzeugkomponente übermittelt wird.
-
Die zusätzlichen Aspekte werden in das Sicherheitskonzept der Fahrzeugkomponente integriert. So kann kryptographische Signatur des Computerprogramms, der zusätzliche Prüfschlüssel und die Identifikationsinformation durch einen Bootloader der Fahrzeugkomponente geprüft werden. Somit kann verhindert werden, dass etwa der zusätzliche Prüfschlüssel auch auf anderen Fahrzeugkomponenten zum Einsatz kommt.
-
Ausführungsbeispiele schaffern ferner ein Programm mit einem Programmcode zum Durchführen des zuvor beschriebenen Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
-
Ausführungsbeispiele schaffern ferner eine Fahrzeugkomponente, umfassend ein oder mehrere Prozessoren und ein oder mehrere Speichergeräte, wobei die Fahrzeugkomponente ausgebildet ist zum Ausführen des zuvor beschriebenen Verfahrens.
-
Ausführungsbeispiele schaffen ferner ein Fahrzeug, umfassend ein oder mehrere der Fahrzeugkomponenten.
-
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
- 1 zeigt ein Flussdiagramm eines Beispiels eines Verfahrens zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs;
- 2a zeigt ein Blockdiagramm eines Beispiels einer Fahrzeugkomponente; und
- 2b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs mit ein oder mehreren Fahrzeugkomponenten.
-
Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
-
Verschiedene Ausführungsbeispiele der vorliegenden Offenbarung beziehen sich auf eine kryptographische Absicherung, um neben der Serien-Software auf ausgewählten Komponenten zusätzliche Software freischalten zu können.
-
Wie bereits zuvor ausgeführt wird im Rahmen der Entwicklung und Absicherung von Fahrzeugkomponenten oder der Entwicklung von Software durch Dritthersteller Software entwickelt, welche auf Serienhardware getestet werden soll. Dazu gehören beispielsweise ein Computerprogramm zum Zugriff auf Online-Musikbibliotheken, ein Computerprogramm zum Verknüpfen von Fahrzeugen und Mobilgeräten, oder ein Computerprogramm zum Lokalisieren und Abfragen von Ladesäulen. Diese Software soll aber gleichzeitig nicht unkontrolliert auf Kundenfahrzeugen verwendbar sein. Die erlaubte Software auf den Kundenfahrzeugen soll auf das Minimum beschränkt sein. Für die Entwicklung soll jedoch identische Hardware verwendet werden, um keine Abweichung von der Serie zu haben. Für diese Komponenten in der Entwicklung sollen die Restriktionen möglichst weit reduziert werden, sodass eine ungestörte Entwicklung und Absicherung möglich ist. Im Allgemeinen wird bei einer solche Absicherung direkt, oder über eine Chain-of-trust (Sicherheitskette) einer Public-Key-Infrastruktur vertraut. So wird für die Software-Integrität und - Authentizität auf Fahrzeugkomponenten werden Zertifikate und Signaturen verwendet. Die Korrektheit wird beispielsweise beim Installieren bzw. Starten der Software überprüft.
-
Einerseits könnte für die Entwicklung Spezialhardware verwendet werden, die gegenüber der serienmäßig genutzten Hardware ein unterschiedliches Sicherheitskonzept einsetzt. Jedoch ist die Produktion von Spezialhardware für die Entwicklung mit ausgeschaltetem Sicherheitsmechanismus zur Verifikation der Software aufwendig und birgt die Gefahr, dass diese Hardware auch für ungewollte Abnehmer produziert wird. Für die Entwicklung von Applikationen auf Mobilfunkgeräten werden beispielsweise Entwicklerprogramme genutzt, über die man sich freischalten lassen kann, um auf dedizierten Geräten eigene Software zu installieren.
-
1 zeigt ein Flussdiagramm eines Beispiels eines (computerimplementierten) Verfahrens zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs. Das Verfahren umfasst ferner ein Hinterlegen 110, im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente. Die Identifikationsinformation ist spezifisch für die Fahrzeugkomponente. Das Verfahren umfasst ferner ein Hinterlegen 120 eines zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses. Der zusätzliche Prüfschlüssel ist an die Identifikationsinformation durch eine kryptografische Signatur gekoppelt. Das Verfahren umfasst ferner ein Erhalten 130 des Computerprogramms für die Fahrzeugkomponente. Das Computerprogramm ist kryptographisch signiert. Das Verfahren umfasst ferner ein Ausführen 150 des Computerprogramms, falls die kryptographische Signatur des Computerprogramms nach Prüfung 140 mit dem eingebrachten Prüfschlüssel gültig ist und auf der Identifikationsinformation basiert. Das Verfahren wird beispielsweise von der Fahrzeugkomponente ausgeführt, etwa durch ein oder mehrere Prozessoren der Fahrzeugkomponente, in Verbindung mit ein oder mehreren Speichergeräten und ein oder mehreren Schnittstellen der Fahrzeugkomponente.
-
Die vorliegende Offenbarung bezieht sich auf ein Verfahren, eine Fahrzeugkomponente sowie auf ein Computerprogramm zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs.
-
Im Allgemeinen basiert die Absicherung der Ausführung von Computerprogrammen (also Software) auf Fahrzeugkomponenten auf einer Kryptographieinfrastruktur des Fahrzeugherstellers, etwa auf einer Public-Key-Infrastruktur (PKI, Öffentlicher-Schlüssel-Infrastruktur) des Fahrzeugherstellers. Software, die auf den Fahrzeugkomponenten ausgeführt werden soll, wird durch den Fahrzeughersteller signiert. Diese Signatur wird dann durch die Fahrzeugkomponente, etwa durch einen sogenannten Bootloader (eines Systems zum Initialisieren der Software der Fahrzeugkomponente beim Start) der Fahrzeugkomponente, geprüft, und die Ausführung der Software ermöglicht, falls die Prüfung ermöglicht ist. Wird eine Public-Key-Infrastruktur genutzt, kommt dabei eine Kombination aus einem sogenannten privaten Schlüssel und einem sogenannten öffentlichen Schlüssel des Fahrzeugherstellers zum Einsatz. Diese beiden Schlüssel bilden ein sogenanntes Schlüsselpaar, wobei der öffentliche Schlüssel aus dem privaten Schlüssel abgeleitet ist. Der private Schlüssel ist dabei ein wohlgehütetes Geheimnis des Fahrzeugherstellers, während der öffentliche Schlüssel weitergegeben werden kann. Der private Schlüssel kann nun durch den Fahrzeughersteller genutzt werden, um das Computerprogramm kryptographisch zu signieren. Der öffentliche Schlüssel wiederum wird auf der Fahrzeugkomponente hinterlegt und kann genutzt werden, um die durch den privaten Schlüssel erzeugte Signatur des Computerprogramms zu überprüfen. Dabei wird meist ein sogenannter Hashwert (Zerwürflungswert) des Computerprogramm gebildet und die Signatur basierend auf dem Hashwert erstellt. Entspricht der Hashwert des Computerprogramms dem Hashwert, der in der Signatur hinterlegt ist, und „passt“ die Signatur zum öffentlichen Schlüssel des Fahrzeugherstellers, ist die Prüfung des Computerprogramms erfolgreich. Dieses Vorgehen wird in den Serienversionen der Fahrzeugkomponenten eingesetzt, um die Ausführung der Software strikt abzusichern.
-
Entwickelt nun der Hersteller der Fahrzeugkomponente oder ein Dritthersteller ein Computerprogramm für die Fahrzeugkomponente, so müsste dieser, für jede Testversion, das Computerprogramm von dem Fahrzeughersteller signieren lassen, was einen hohen Aufwand bei dem Fahrzeughersteller erzeugt und Verzögerungen erzeugen kann. An dieser Stelle setzt die vorliegende Erfindung an. Zusätzlich zu der bereits genutzten Prüfinfrastruktur wird nun ein weiterer Prüfschlüssel in die Fahrzeugkomponente eingebracht, der auf einer Identifikationsinformation der Fahrzeugkomponente basiert und daher spezifisch für die Fahrzeugkomponente ist. Um für die Entwicklung und Absicherung auf den Serienkomponenten eine möglichst freie Entwicklung zu erlauben, wird hierdurch für ausgewählte Komponenten die Verwendung von der Software aus der Entwicklung freigeschaltet. Dieses kann über die existierende Public-Key-Infrastruktur erfolgen.
-
Die Freischaltung der Fahrzeugkomponente erfolgt mit Hilfe von zwei Komponenten: Der Identifikationsinformation und des zusätzlichen Prüfschlüssels. Daher umfasst das Verfahren das Hinterlegen 110, im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente und das Hinterlegen 120 des zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses. Hierbei wird deutlich, dass dies zu unterschiedlichen Zeitpunkten geschehen kann. So wird die Identifikationsinformation bereits während des Herstellungsprozesses, d.h., während der ursprünglichen Fertigung eingebracht. Die Identifikationsinformation ist eineindeutig, d.h., eindeutig in beide Richtungen, so dass einer Fahrzeugkomponente (oder einem Fahrzeug) genau eine Identifikationsinformation zugewiesen ist und die Identifikationsinformation genau einer Fahrzeugkomponente (oder einem Fahrzeug) zugewiesen ist. In anderen Worten ist eine Identifikationsinformation genau einer Fahrzeugkomponente (oder einem Fahrzeug) zugewiesen. Die Identifikationsinformation kann beispielsweise ein Binärkode oder ein Alphanumerischer Kode sein oder als solcher ausgedrückt sein. Zudem kann die Identifikationsinformation unveränderlich sein. Beispielsweise kann die Identifikationsinformation in einem Nur-Lese-Speicher der Fahrzeugkomponente eingebracht sein, der nach dem Ende des Herstellungsprozesses unveränderlich ist.
-
Der zusätzliche Prüfschlüssel wird nun basierend auf der Identifikationsinformation in die Fahrzeugkomponente eingebracht. Dazu wird der zusätzliche Prüfschlüssel beispielsweise basierend auf der Identifikationsinformation generiert. Hiermit wird die Freigabe der Fahrzeugkomponente, über die Signatur/das Zertifikat, an die Identifikationsinformation gekoppelt. Beispielsweise kann ein Entwickler die Identifikationsinformation der Fahrzeugkomponente auslesen, an den Fahrzeughersteller übermitteln, welcher wiederum den zusätzlichen Prüfschlüssel basierend auf der Identifikationsinformation zusammen mit der kryptographischen Signatur generieren kann. Alternativ kann die zusätzliche Prüfschlüssel durch den Entwickler (oder den Zulieferer/Dritthersteller) generiert werden, und anschließend über die kryptographische Signatur mit der Identifikationsinformation gekoppelt werden. In beiden Fällen ist die kryptographische Signatur, mit der der zusätzliche Prüfschlüssel an die Identifikationsinformation gekoppelt ist, von dem Hersteller des Fahrzeugs generiert. Dabei kann die kryptographische Signatur ebenfalls mit dem privaten Schlüssel des Fahrzeugherstellers generiert werden. Die kryptographische Signatur kann so ebenfalls mit dem öffentlichen Schlüssel des Fahrzeugherstellers geprüft werden.
-
Der zusätzliche Prüfschlüssel ist dazu vorgesehen, die Ausführung von Computerprogrammen zusätzlich zu einer Public-Key-Infrastruktur eines Herstellers des Fahrzeugs zu ermöglichen. Daher wird der zusätzliche Prüfschlüssel beispielsweise zusätzlich zu dem öffentlichen Schlüssel des Fahrzeugherstellers eingebracht. Oder, genereller, wird der zusätzliche Prüfschlüssel zusätzlich zu einem weiteren Prüfschlüssel, wie dem öffentlichen Schlüssel des Fahrzeugherstellers, eingebracht, der genutzt wird, um die Ausführung von Computerprogrammen im Serienbetrieb der Fahrzeugkomponente zu beschränken.
-
Nun wird das Computerprogramm durch die Fahrzeugkomponente erhalten, etwa durch Aufspielen des Computerprogramms über eine Diagnoseschnittstelle der Fahrzeugkomponente, oder durch Abrufen des Computerprogramms aus einer Plattform zum Abrufen von Computerprogrammen. Das Computerprogramm ist kryptographisch signiert. Diese Signatur ist beispielsweise nicht von dem Fahrzeughersteller generiert, sondern wird stattdessen von dem Entwickler selbst, oder von einer Kryptographieinfrastruktur der Zulieferers/Drittherstellers generiert. Dies kann beispielsweise dann geschehen, wenn der zusätzliche Prüfschlüssel von dem Entwickler, Zulieferer oder Dritthersteller stammt, und lediglich die Signatur, mit der der Prüfschlüssel an die Identifikationsinformation gebunden ist, von dem Fahrzeughersteller selbst. So kann es dem Entwickler erlaubt werden die Signatur für die Software selbständig zu erzeugen indem der Öffentliche Schlüssel, d.h. der zusätzliche Prüfschlüssel, für diese Signatur in die Freigabe mit aufgenommen wird. Der Entwickler, Zulieferer oder Dritthersteller kann nun die Signatur mit Hilfe des dazugehörigen Privaten Schlüssels erzeugen. Somit kann die kryptographische Signatur des Computerprogramms basierend auf der Identifikationsinformation der Fahrzeugkomponente oder des Fahrzeugs durch einen Hersteller der Fahrzeugkomponente oder durch einen Dritten generiert sein. Alternativ kann der Zwang einer Signatur ganz entfallen oder die Signatur der Entwickler-Software muss weiter über die Infrastruktur für die Seriensoftware signiert werden.
-
Um zu verhindern, dass das so signierte Computerprogramm auf beliebigen Fahrzeugkomponenten mit zusätzlichem Prüfschlüssel verwendet werden kann (etwa auf allen Fahrzeugkomponenten, die von dem Zulieferer oder Dritthersteller mit einem zusätzlichen Prüfschlüssel ausgerüstet sind), kann nun die Ausführung mittels der Identifikationsinformation auf einzelne Identifikationsinformationen beschränkt werden. So kann beispielsweise die kryptographische Signatur des Computerprogramms spezifisch für eine einzige Fahrzeugkomponente oder ein einziges Fahrzeug sein, oder die kryptographische Signatur des Computerprogramms spezifisch für eine definierte Menge an Fahrzeugkomponenten oder Fahrzeugen sein. Dies kann dadurch geschehen, dass die Signatur, neben einem Hashwert des Computerprogramms auch auf ein oder mehreren Identifikationsinformationen basiert, d.h. die Signatur wird für ein Paket aus Computerprogramm und ein oder mehreren Identifikationsinformationen generiert. So können auch mehrere Identifikationsinformationen auf einmal freigegeben werden. Das Computerprogramm kann etwa zusammen mit ein oder mehreren Identifikationsinformationen ein oder mehrerer Fahrzeugkomponenten oder Fahrzeuge signiert sein. Dies kann dadurch geschehen, dass ein Manifest mit dem Hashwert des Computerprogramms und den ein oder mehreren Identifikationsinformationen kryptographisch signiert wird. Dies entspricht dann der kryptographischen Signierung des Computerprogramms.
-
Dies kann nun im Rahmen der Prüfung der kryptographischen Signatur überprüft werden. Das Verfahren umfasst das Prüfung 140 der kryptographischen Signatur mit dem eingebrachten Prüfschlüssel, wobei die Prüfung umfasst, zu überprüfen, ob die kryptographische Signatur auf der Identifikationsinformation basiert. Somit werden drei Aspekte geprüft - a) ob der eingebrachte zusätzliche Prüfschlüssel über eine kryptographische Signatur an die Identifikationsinformation gekoppelt ist, b) ob die kryptographische Signatur des Computerprogramms durch den zusätzlichen Prüfschlüssel als gültig erkannt wird, und c) ob die kryptographische Signatur des Computerprogramms auf der Identifikationsinformation basiert. Durch a) und b) wird eine Sicherheitskette (Chain of Trust) von dem Fahrzeughersteller bis zu dem signierten Computerprogramm aufgespannt. Durch a) und c) wird verhindert, dass das Computerprogramm auf beliebigen Fahrzeugkomponenten auf beliebigen Fahrzeugkomponenten mit zusätzlichem Prüfschlüssel ausführbar ist. Zur Prüfung von c) kann der Hashwert des Computerprogramms (der lokal berechnet wird) mit dem Hashwert, der im Manifest gespeichert ist, verglichen werden sowie die eingebrachte Identifikationsinformation mit den ein oder mehreren Identifikationsinformationen verglichen werden, die im Manifest umfasst ist oder sind. Beispielsweise kann die kryptographische Signatur des Computerprogramms (Prüfaspekte b) und c)), der zusätzliche Prüfschlüssel (Prüfaspekt a)) und die Identifikationsinformation (Prüfaspekt a)) durch einen Bootloader der Fahrzeugkomponente geprüft 140 werden.
-
Ist die Prüfung erfolgreich, so wird das Computerprogramm ausgeführt 150. Dies kann im Rahmen einer Ausführungsumgebung, die von der Fahrzeugkomponente bereitgestellt wird, etwa neben anderen Computerprogrammen, geschehen. Alternativ kann das Computerprogramm als Abbild (engl. Image) geladen und (alleinig) ausgeführt werden.
-
Das vorgeschlagene Verfahren ermöglicht eine kontrollierte Freigabe der Software aus der Entwicklung für die Fahrzeuge/Komponenten mit den ausgewählten Identifikationsinformationen. Es kann durch andere Prozesse sichergestellt werden, dass diese Fahrzeuge/IDs nicht in den freien Verkauf gelangen. Ist der Entwicklungsprozess abgeschlossen, wird auch der zusätzliche Prüfschlüssel wieder entfernt. Somit kann das Verfahren ferner ein Entfernen 160 des zusätzlichen Prüfschlüssels, nachdem der Entwicklungsprozess abgeschlossen ist, umfassen. Dies kann beispielsweise der Fall sein, wenn der Entwicklungsprozess tatsächlich als abgeschlossen gelten kann, etwa bei sicherheitskritischer Software, die zu einem bestimmten Zeitpunkt abgenommen wird. In vielen Fällen, etwa in Fällen, in denen Dritthersteller Software für ein Infotainmentsystem des Fahrzeugs entwickeln, schreitet die Entwicklung jedoch kontinuierlich fort. Hier kann während des Fortschreitenden Entwicklungsprozesses der zusätzliche Prüfschlüssel auf der Fahrzeugkomponente verweilen.
-
Im Folgenden wird Anhand von Beispielen kurz ausgeführt, inwiefern sich die Signaturprüfung im „Normalfall“, d.h. ohne zusätzlichen Prüfschlüssel, von dem hier vorgestellten Konzept unterschiedet. Im Normalfall ist die Seriensoftware ist über eine kryptographische Signatur gesichert. Diese Signatur stammt beispielsweise aus einer PKI des Herstellers. Der Bootloader überprüft die Signatur und startet die Software nur wenn die Signatur stimmt.
-
Im vorgestellten Fall, d.h. im Fall, dass die Fahrzeugkomponente für die Entwicklung eingestellt wird, wird (la) die Entwicklungssoftware (d.h. das Computerprogramm) ist über die Signatur des Entwicklers signiert. (1b) Eine PKI des Hersteller hat ein Paket aus eineindeutiger Identifikationsinformation der Komponente und Schlüssel für Signatur des Entwicklers (also den zusätzlichen Prüfschlüssel) signiert. (2a) Der Bootloader erkennt, dass das zusätzliche Paket aus Identifikationsinformation und Entwicklerschlüssel vorhanden ist und prüft diese Signatur. (2b) Wenn die Signaturprüfung erfolgreich war, wird die Software mit dem Schüssel für die Entwicklersignatur geprüft. (3) Bei erfolgreicher Prüfung startet das Steuergerät die Entwicklungssoftware.
-
2a zeigt ein Blockdiagramm eines Beispiels einer Fahrzeugkomponente 20. Diese Fahrzeugkomponente 20 kann nun beispielsweise genutzt werden, um das in 1 vorgestellte Verfahren auszuführen. Insbesondere umfasst die Fahrzeugkomponente ein oder mehrere Prozessoren 24 und ein oder mehrere Speichergeräte 26. Optional umfasst die Fahrzeugkomponente ferner ein oder mehrere Schnittstellen 22. Die ein oder mehreren Prozessoren 24 sind mit den ein oder mehreren Speichergeräten 26 und den ein oder mehreren Schnittstellen 22 gekoppelt. Die Funktionalität der Fahrzeugkomponente wird, zumindest in Bezug auf das obige Verfahren, von den ein oder mehreren Prozessoren 24 bereitgestellt, unter Zuhilfenahme der ein oder mehreren Speichergeräte 26 (zum Speichern von Informationen wie etwa der Identifikationsinformation, des zusätzlichen Prüfschlüssels, des öffentlichen Schlüssels des Fahrzeugherstellers und des Computerprogramms) und der ein oder mehreren Schnittstellen (zum Austausch von Informationen). Dabei kann die Fahrzeugkomponente beispielsweise eine computerbasierte Fahrzeugkomponente sein, etwa ein computerbasiertes Steuergerät oder eine zentrale Computereinheit (etwa ein Infotainmentsystem) des Fahrzeugs.
-
Die ein oder mehreren Schnittstellen 22 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 24 können einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Funktionalität der ein oder mehreren Prozessoren 24 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern können die ein oder mehreren Prozessoren 24 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 (Unified Extensible Firmware Interface, Vereinheitliche und erweiterbare Firmware-Schnittstelle), dazu ausgebildet sein, eine Secure Boot-Operation (Sichere-Initialisierung-Operation) bereitzustellen, um das Computerprogramm zu laden.
-
Die ein oder mehreren Speichergeräte 26 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.
-
In der vorliegenden Offenbarung ist die Rede von Fahrzeugkomponenten. Diese sind (computerbasierte) Komponenten, die in Fahrzeugen zum Einsatz kommen. Entsprechend schaffen Ausführungsbeispiele auch ein Fahrzeug 200, umfassend ein oder mehrere Fahrzeugkomponenten 20. 2b zeigt ein schematisches Diagramm eines Beispiels eines solchen Fahrzeugs 200 mit ein oder mehreren Fahrzeugkomponenten 20, wie sie im Zusammenhang mit den 1 bis 2a vorgestellt wurden. Das Fahrzeug 200 kann beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen.
-
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 Ausführen 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
-
- 20
- Fahrzeugkomponente
- 22
- Schnittstelle
- 24
- Prozessor
- 26
- Speichergerät
- 110
- Hinterlegen einer Identifikationsinformation
- 120
- Hinterlegen eines zusätzlichen Prüfschlüssels
- 130
- Erhalten eines Computerprogramms
- 140
- Prüfen einer kryptographischen Signatur des Computerprogramms
- 150
- Ausführen des Computerprogramms
- 160
- Entfernen des zusätzlichen Prüfschlüssels
- 200
- Fahrzeug
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 10140721 A1 [0002]
- DE 10354107 A1 [0002]
