-
Die Erfindung betrifft ein Verfahren zur sicheren Nutzung von kryptografischem Material in mehreren Systemkomponenten eines vernetzten Systems, nach der im Oberbegriff von Anspruch 1 näher definierten Art.
-
Das Verfahren zur sicheren Nutzung von kryptografischem Material beschäftigt sich im Wesentlichen damit, dass in Entwicklungsphasen von Systemkomponenten eines vernetzten Systems, welche mit dem kryptografischem Material ausgestattet sind, anderes kryptografisches Material Verwendung finden muss, als in der späteren Produktivphase dieser Systemkomponenten. Dies bezieht sich insbesondere, nicht jedoch ausschließlich, auf das Gebiet der sogenannten CarIT-Security für Fahrzeuge.
-
Moderne Fahrzeuge, aber auch andere Systeme, zeichnen sich durch eine zunehmende Vernetzung aus. Die Fahrzeuge sind dabei nicht nur mit allgemeinen zugänglichen Systemen wie dem WorldWideWeb verbunden sondern auch mit dezidierten vom Fahrzeughersteller bzw. OEM betriebenen Systemen und Servern, beispielsweise herstellereigenen Applikationen und einem herstellereigenen Server, welcher häufig auch als Backendserver bezeichnet wird. Diese werden vom Hersteller exklusiv für die eigene Fahrzeugflotte entwickelt, vermarktet und betrieben. All dies zusammen wird auch als Fahrzeug-Ökosystem bezeichnet.
-
In der Praxis ist es nun so, dass durch die vielfältigen Kommunikationsbeziehungen zwischen den einzelnen Systemkomponenten innerhalb eines solchen Fahrzeug-Ökosystems eine Vielzahl neuer Schnittstellen und Anwendungen entsteht, die allesamt durch geeignete kryptografische Verfahren, wie beispielsweise Mechanismen, Protokolle usw., abgesichert werden müssen. Diese kryptografischen Verfahren, welche so prinzipiell aus dem Stand der Technik bekannt sind, benötigen dafür vielfältiges kryptografisches Material wie beispielsweise asymmetrische Schlüsselpaare, symmetrische Schlüssel, Zertifikate, Zufallszahlen usw. All diese sind aufeinander abgestimmt und werden vor ihrer Inbetriebnahme in dem Fahrzeug-Ökosystems in alle teilnehmenden Systemkomponenten eingebracht und müssen von diesen genutzt werden. Die Bereitstellung des kryptografischen Materials, das sogenannte Provisioning, erfolgt beispielsweise im Rahmen des Herstellungsprozesses. Die Systemkomponenten umfassen dabei insbesondere in den Fahrzeugen verbaute Steuergeräte, aber auch andere Komponenten wie beispielsweise im Fahrzeug installierte Applikationen, auf einem Smartphone verfügbare Applikationen des OEM und dergleichen.
-
Um zuverlässig zu verhindern, dass in die geschützte Kommunikation eingegriffen werden kann, ist es zwingend notwendig, zwischen kryptografischem Material, welches während der Entwicklungsphase verwendet wird, und kryptografischem Material, das während der Produktivphase, also dem realen Einsatz des fertig entwickelten Produkts, zum Einsatz kommt, unterschieden wird. Das kryptografische Material für die Entwicklungsphase, wird nachfolgend auch als Test-Kryptomaterial bezeichnet. In der Entwicklungsphase darf nur ausschließlich dieses Test-Kryptomaterial verwendet werden. Das Produktiv-Kryptomaterial, und hier insbesondere geheimes Produktiv-Kryptomaterial, muss nämlich während des gesamten Lebenszyklus der Systemkomponente vor unberechtigtem Zugriff geschützt werden. Dieser Schutz sollte dabei im Idealfall durch das Einhalten eines speziellen abgesicherten Prozesses und die Verwendung spezieller Schutzmechanismen in den jeweiligen Entwicklungsabteilungen und Produktionsstätten gewährleistet werden. In der Entwicklungsphase ist dies jedoch meist nur unzureichend gewährleistet, da verschiedene Bausteine des vernetzten Systems in dieser Entwicklungsphase meist nicht oder noch nicht umgesetzt bzw. implementiert sind.
-
So kann beispielsweise die sichere Erzeugung des benötigten kryptografischen Materials noch nicht vollständig umgesetzt oder getestet sein. Die sichere Übertragung des kryptografischen Materials vom Erzeugungsserver, dem sogenannten Kryptomaterial-Server, zum Systemhersteller, beispielsweise einem Zulieferer, ist gegebenenfalls noch nicht sichergestellt. Das sichere Einbringen des Kryptomaterials in die Systemkomponente ist noch nicht oder noch nicht endgültig umgesetzt. Das sichere Speichern des kryptografischen Materials in dieser Systemkomponente ist eventuell noch nicht umgesetzt, weil beispielsweise das Zielsystem noch kein Hardwaresicherheitsmodul (Hardware Security Module; HSM) verbaut hat, obwohl dies zu einem späteren Zeitpunkt noch eingebaut werden soll. Die sichere Nutzung des kryptografischen Materials in dem System ist ggf. noch nicht umgesetzt, beispielsweise weil zum Testen und Debuggen benötigte Entwicklungsschnittstellen vorhanden sind, welche einen lesenden und schreibenden Zugriff auf das gesamte System haben und damit insbesondere auch einen Zugriff auf das installierte kryptografische Material während der Entwicklungsphase erlauben. Diese sind aber notwendigerweise während der Entwicklung vorhanden und meist auch für alle beteiligten Personen und/oder Firmen im Entwicklungsprozess offen zugänglich.
-
Dies führt also dazu, dass nicht sichergestellt werden kann, dass das Test-Kryptomaterial nicht manipuliert oder ausgelesen wird. Dabei ist es jedoch so, dass dieses Test-Kryptomaterial in seiner Struktur und Form identisch zu dem später genutzten Produktiv-Kryptomaterial ist. Es eignet sich somit auch für den Einsatz im späteren Betrieb, also in der Produktivphase der jeweiligen Systemkomponente. Deshalb ist es besonders wichtig, dass das relativ schlecht gesicherte und daher mit einer hohen Wahrscheinlichkeit korrumpierte Test-Kryptomaterial im Produktivsystem nicht missbräuchlich eingesetzt wird. Noch gravierender ist es, wenn Produktiv-Kryptomaterial auf eine Systemkomponente in der Entwicklungsphase gelangt Dieses eigentlich als sehr sicher eingestufte Material kann dann ebenfalls manipuliert oder ganz oder teilweise ausgelesen werden. Es ist damit nicht mehr geheim und kann nicht verwendet werden. Falls der Fehler unbemerkt bleibt oder bewusst vertuscht wird, verliert die später in die Produktivphase wechselnde Systemkomponente ihre Absicherung.
-
In der Praxis ist es so, dass die Sicherheitsvorschriften und Richtlinien durch die in den Phasen mit den Systemkomponenten beschäftigten Personen umgesetzt werden. Deshalb sind Fehler, Versehen und auch bewusste Manipulationen nicht auszuschließen. Von daher besteht prinzipiell immer die Gefahr, dass Test-Kryptomaterial in einer bereits in die Produktivphase gewechselten Systemkomponente verbliebt oder das Produktiv-Kryptomaterial auf einer Systemkomponente eingesetzt wird, die noch in der Entwicklungsphase ist. Jeglichen bewusst oder versehentlich in der Entwicklungsphase genutzte Kryptomaterial ist, aufgrund der vielen noch offenen Schnittstellen etc. mit hoher Wahrscheinlichkeit korrumpiert. Diese Gefahren führen letztlich zu einem erhöhten Sicherheitsrisiko. Dies stellt einen gravierenden Nachteil der bestehenden Vorgehensweise dar.
-
Zum weiteren Stand der Technik kann nun außerdem auf die
EP 0 735 722 B1 hingewiesen werden. In dieser Schrift ist ein Schlüsselverwaltungssystem zur Erzeugung, Verteilung und Verwaltung von kryptografischen Schlüsseln, also kryptografischem Material, beschrieben. Dabei sind mehrere einzelne Verarbeitungselemente und Domänen beteiligt, welche über einen zentralen Computer oder Server entsprechend verwaltet werden, um einen sicheren Austausch der Schlüssel zwischen diesen Systempartnern des vernetzten Systems zu gewährleisten.
-
Die Aufgabe der hier vorliegenden Erfindung besteht nun darin, ein verbessertes Verfahren zum Umgang mit kryptografischem Material bei Systemkomponenten mit einer Entwicklungsphase und einer Produktivphase anzugeben, welches insbesondere die oben genannten Nachteile bezüglich der Sicherheit effektiv löst.
-
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1, und hier insbesondere im kennzeichnenden Teil des Anspruchs 1, gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen des Verfahrens ergeben sich aus den hiervon abhängigen Unteransprüchen.
-
Das erfindungsgemäße Verfahren dient zur sicheren Nutzung von kryptografischem Material in mehreren Systemkomponenten wie beispielsweise Steuergeräten, Applikationen und dergleichen. Diese sind Teile eines vernetzten Systems und sind mit kryptografischem Material ausgestattet. Die Systemkomponenten haben dabei einen Lebenszyklus, welcher zumindest eine Entwicklungsphase und eine Produktivphase umfasst. Um nun zuverlässig und ohne die Gefahr eines menschlichen Versagens zu verhindern, dass kryptografisches Material aus der Entwicklungsphase in der Produktivphase eingesetzt wird, und um gekehrt, sieht das erfindungsgemäße Verfahren nun mehrere Schritte vor. Diese umfassen, dass das gesamte kryptografische Material zumindest mittelbar als Entwicklungs- oder Produktivmaterial sicher markiert wird. Einzelne Elemente, wie z.B. Schlüssel, die nicht direkt markiert werden können, lassen sich dabei mittelbar über die zugeordneten Zertifikate markieren. Dies kann z.B. kryptografisch abgesichert werden. Die entsprechende Markierung , beispielweise mit TEST und PROD, weist das Kryptomaterial als Test-Kryptomaterial oder als Produktiv-Kryptomaterial aus. Sie kann jederzeit unter Zuhilfenahme der entsprechend ihrer Absicherung geeigneten kryptografischen Maßnahmen ausgelesen und verifiziert werden.
-
Nun ist es so, dass die kryptografisch abgesicherte Markierung alleine nicht ausreicht, um den Einsatz des Testmaterials in den realen in der Produktivphase befindlichen Systemkomponenten oder umgekehrt, den Einsatz von Produktiv-Kryptomaterial in der Entwicklungsphase zu verhindern. Zwar kann die kryptografisch abgesicherte Markierung genutzt werden, um eindeutig Test-Kryptomaterial von Produktiv-Kryptomaterial zu unterscheiden. Es kann jedoch nicht gewährleistet werden, dass in der in die Produktivphase eingetretenen Systemkomponente tatsächlich dieses Material vorliegt. Um das nun zu erreichen ist es notwendig, dass die Systemkomponente automatisch und manipulationssicher erkennen kann, ob sie sich in der Entwicklungsphase oder in der Produktivphase befindet.
-
Das erfindungsgemäße Verfahren nutzt dazu einen binären Zustandsflag, welcher die Entwicklungsphase bzw. die Produktivphase anzeigt. Dieser wird in die Systemkomponente implementiert und ist gegen unberechtigte Manipulation abgesichert. Durch diese beiden Maßnahmen ist man nun der Lage zu erreichen, dass jede Systemkomponente in sich selbst eindeutig erkennen kann, welches kryptografisches Material geladen ist oder für die Komponenten zum Laden bereitgestellt wird. Außerdem ist die Systemkomponente in der Lage, ihren eigenen Zustand anhand des Zustandsflags zu bestimmen, sie weiß also, ob sie in der Entwicklungsphase oder der Produktivphase ist.
-
Die Systemkomponente führt dann in dem erfindungsgemäßen Verfahren eine Überprüfung durch, im Rahmen welcher die aktuelle Phase, also Entwicklungsphase oder Produktivphase, und die Markierung des kryptografischen Materials verglichen werden. Falls keine Übereinstimmung vorliegt, also in der aktuellen Phase das falsche kryptografische Material installiert ist oder zur Installation bereitgestellt wird, werden geeignete Sicherungsmaßnahmen eingeleitet, um so die hinsichtlich der Sicherheit kritische Nutzung des „falschen“ kryptografischen Materials in der entsprechenden Phase zu unterbinden. Die Sicherungsmaßnahmen können dabei verschiedenartig ausgebildet sein, solange sie in der Lage sind, einen unsicheren Zustand zu beheben oder zumindest anzuzeigen. Auf Details zu den Sicherungsmaßnahmen wird später noch weiter eingegangen.
-
Das erfindungsgemäße Verfahren hat dabei ganz entscheidende Vorteile. Es stellt einerseits sicher, dass eine Systemkomponente in der Entwicklungsphase weder absichtlich noch versehentlich mit gegebenenfalls unzureichend geschütztem Produktiv-Kryptomaterial betrieben werden kann. Und das Verfahren stellt andererseits sicher, dass eine Systemkomponente in der Produktivphase weder absichtlich noch versehentlich mit potenziell unsicherem Test-Kryptomaterial betrieben werden kann. Die Systemkomponente selbst ist nun also in der Lage, ihren sicheren Betrieb mit dem hierfür geeigneten kryptografischen Material zu gewährleisten. Weder eine absichtliche Manipulation noch versehentliche Fehler im Herstellungsprozess können damit den sicheren Betrieb der jeweiligen Systemkomponente aushebeln.
-
Sowohl das Zustandsflag als auch die Markierung des kryptografischen Materials kann dabei gemäß einer vorteilhaften Ausgestaltung der Erfindung über kryptografische Maßnahmen abgesichert werden. So kann beispielsweise die Markierung in den Schlüsseln zugeordneten Zertifikaten gesetzt und mit einem privaten Schlüssel entsprechend signiert werden. Die entsprechende Markierung kann dann jederzeit unter Zuhilfenahme des zugehörigen öffentlichen Schlüssels abgefragt und verifiziert werden. Anstelle einer solchen digitalen Signatur können selbstverständlich auch andere zur Absicherung der Integrität des markierten kryptografischen Materials geeignete kryptografische Verfahren, beispielsweise symmetrische Message Authentification Codes (MAC) eingesetzt werden.
-
Insbesondere für das Zustandsflag gibt es gemäß einer sehr günstigen Weiterbildung des erfindungsgemäßen Verfahrens alternativ oder ergänzend weitere Möglichkeiten, dieses manipulationssicher zu gestalten. Diese Möglichkeiten sind im Wesentlichen hardwarebasiert und sichern das Zustandsflag beispielsweise dadurch ab, dass dieses in einen WORM-Speicher geschrieben wird. Ein solcher WORM (Wright Once Read Many)-Speicher lässt sich nur einmal hinsichtlich seines Zustands ändern, indem beispielsweise ausgehend von einem Entwicklungsflag mit dem Wert Null der Wert auf Eins gesetzt wird, was dem Produktivflag entspricht. Dies ist relativ sicher, hat jedoch den eventuellen Nachteil, dass einmal in die Produktivphase geschaltete Systemkomponenten nicht zurückschaltbar sind, was gegebenenfalls die Entwicklungskosten erhöhen kann, falls nach dem ersten Wechsel doch noch ein Fehler behoben werden müsste. Als Alternative kann das Zustandsflag daher auch in einem Hardwaresicherheitsmodul, einem sogenannten Hardware Security Module, gespeichert werden, indem es vor Manipulation weitgehend gesichert ist, durch den Hersteller oder den OEM jedoch bei Bedarf noch nochmals geändert werden kann.
-
Ist eine solche hardwarebasierte Absicherung aus technischen Gründen nicht möglich, weil beispielsweise kein WORM bzw. kein HSM vorgesehen sind, oder weil die Hardware des Systems nicht in der Hoheit der OEMs liegt, beispielsweise bei Smartphone-Apps, dann kann, wie bereits erwähnt, auch die oben geschilderte softwaregestützte Absicherung über kryptografische Maßnahmen in Betracht gezogen werden. Prinzipiell ließe sich diese bei vorhandenem WORM-Speicher oder HSM auch mit der Hardwarelösung kombinieren, was für die Praxis jedoch meist unnötig erscheint.
-
Durch die beiden Maßnahmen des erfindungsgemäßen Verfahrens, nämlich die Markierung des kryptografischen Materials und die Implementierung des Zustandsflags, kann die Systemkomponente nun sicher erkennen, ob das eingebrachte kryptografische Material entsprechend der eingestellten Betriebsphase markiert ist. Dies sollte idealerweise vor der Verwendung des kryptografischen Materials sichergestellt werden. Dazu kann die Überprüfung der Übereinstimmung unmittelbar zu verschiedenen Zeitpunkten durchgeführt werden. Gemäß einer besonders vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens sind dabei zwei generelle Vorgehensweisen möglich. Dies ist einmal die Überprüfung der Übereinstimmung vor dem jeweiligen Gebrauch des kryptografischen Materials, also eine Einzelüberprüfung, bevor das entsprechende Material beispielsweise ein bestimmter Schlüssel oder ein bestimmtes Zertifikat unmittelbar zum Einsatz kommt. Alternativ und vorzugsweise erfolgt die Übereinstimmungsprüfung einmalig für das gesamte kryptografische Material.
-
Dabei ist es gemäß einer sehr günstigen Ausgestaltung des erfindungsgemäßen Verfahrens vorgesehen, dass diese Überprüfung der Übereinstimmung für das gesamte kryptografische Material direkt bei dessen Bereitstellung, also dem Einbringen in die Systemkomponente, durchgeführt wird. Eine Überprüfung bei diesem sogenannten Provisioning des kryptografischen Materials ist sehr sicher, da das kryptografische Material bis zu diesem Zeitpunkt nirgends innerhalb der Systemkomponente gespeichert oder angewandt worden ist. In der Praxis ist dies allerdings nicht immer möglich, da die Durchführung der Überprüfung auf Übereinstimmung eine hochgefahrene Systemkomponente, welche also laufen muss, erfordert. Je nach Ausgestaltung kann die Bereitstellung bzw. das Provisioning jedoch auch direkt in den Speicher erfolgen, ohne dass die Systemkomponente dazu hochgefahren werden muss. Dies kann beispielsweise dann erfolgen, wenn das Hochfahren der Systemkomponente das Vorhandensein von kryptografischem Material bereits voraussetzt. In diesen Fällen sollte dann die Überprüfung der Übereinstimmung so früh wie möglich erfolgen, also insbesondere beim bzw. innerhalb des ersten Hochfahrens der Systemkomponente nach dem Bereitstellen des kryptografischen Materials. Vergleichbares gilt insbesondere auch dann, wenn kryptografisches Material beispielsweise im Rahmen eines Systemupdates oder dergleichen nachgeliefert wird, dann gilt dies entsprechend für das erste Hochfahren nach dem erneuten Bereitstellen von beispielsweise erweitertem kryptografischem Material im Rahmen eines Systemupdates.
-
Das Zustandsflag ist wie bereits erwähnt ein manipulationssicherer Indikator dafür, in welcher Phase sich die Systemkomponente befindet. Diese kann beispielsweise zu einem passenden Zeitpunkt während der Geräteherstellung von einer Instanz mit der entsprechenden Vollmacht gesetzt werden. Ein auf „Produktiv“ gesetztes Zustandsflag ist jedoch in der Praxis keine Garantie dafür, dass das installierte kryptografische Material in der Systemkomponente tatsächlich ausreichend geschützt ist. Beispielsweise können Entwicklungs- und Debugging-Schnittstellen noch vorhanden sein, wenn deren Abschalten oder deren Deinstallation beispielsweise bewusst oder versehentlich vergessen wurde. Eine besonders günstige Ausgestaltung des erfindungsgemäßen Verfahrens schlägt es deshalb vor, dass die Systemkomponente eine Plausibilitätsprüfung für die Produktivphase durchführt, falls die Feststellungsfunktion ergeben hat, dass die Systemkomponente in der Produktivphase ist, das Zustandsflag also entsprechend auf „produktiv“ gesetzt ist. Dafür werden für die Produktivphase vorgegebene Bedingungen überprüft, um zu verifizieren, dass tatsächlich alle Anforderungen an die Produktivphase gegeben sind und somit der Schutz des Produktiv-Kryptomaterials gewährleistet ist. Die typischerweise vorgegebenen Bedingungen, welche bei der Plausibilitätsprüfung abgeprüft werden, können sich beispielsweise auf eine vordefinierte Liste von Entwicklungs- und Debugging-Schnittstellen beziehen, für die festgelegt ist, dass sie in der Produktivphase nicht mehr nutzbar sein dürfen. Die Überprüfung stellt also fest, ob diese Schnittstellen entsprechend abgeschaltet oder deinstalliert sind.
-
Die Plausibilitätsprüfung für die Produktivphase stellt somit das Einhalten von Bedingungen für den Produktivmodus sicher. Sie spielt für die Entwicklungsphase keine Rolle, sodass hier keine Überprüfung erfolgt bzw. diese nicht dazu führt, dass entsprechende Sicherheitsmaßnahmen eingeleitet werden, wie es für den Fall, dass in der Produktivphase einzelne Schnittstellen noch nicht deaktiviert sind, der Fall wäre.
-
Analog zur Überprüfung der Übereinstimmung kann die Plausibilitätsprüfung dabei zu verschiedenen Zeitpunkten durchgeführt werden. Bevorzugt wird sie vor dem Bereitstellen des kryptografischen Materials für die jeweilige Systemkomponente durchgeführt. Damit kann sichergestellt werden, dass die Bereitstellung bzw. das Provisioning gar nicht erst erfolgt, und dass das für die Produktivphase vorgesehene kryptografische Material gar nicht erst in die potenziell unsichere Systemkomponente gelangt. Wie oben bereits erwähnt ist dies jedoch nicht immer möglich, da für die Durchführung der Plausibilitätsprüfung die Systemkomponente hochgefahren sein muss. Erfolgt das Provisioning, wie oben beschrieben, direkt in dem Speicher, dann kann die Plausibilitätsprüfung auch vor dem ersten Hochfahren der Systemkomponente nach dem Bereitstellen oder auch nach einem erneuten Bereitstellen des kryptografischen Materials, wie es oben beschrieben ist, erfolgen. Wichtig ist es dabei, dass diese so früh als irgend möglich, und vorzugsweise vor der Überprüfung der Übereinstimmung erfolgt.
-
Schlägt die Überprüfung der Übereinstimmung oder auch die Plausibilitätsprüfung fehl, dann wird die Systemkomponente entsprechende Sicherungsmaßnahmen ergreifen. Diese Umfassen gemäß einer sehr vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens zumindest eine Warnmeldung, um den Betreiber des vernetzten Systems und/oder andere Systemkomponenten über das aufgetretene „Problem“ in Kenntnis zu setzen. Stellt die Überprüfung der Übereinstimmung beispielsweise fest, dass Test-Kryptomaterial in der Produktivphase verwendet wird, liegt ein potenziell unsicherer Zustand der Systemkomponente vor. Neben der Warnung, welche die Systemkomponente erzeugt, wären anderen geeignete Maßnahmen, beispielsweise eine Nutzung einzuschränken oder sich ganz abzuschalten, möglich.
-
Ergibt beispielsweise die Überprüfung der Übereinstimmung in der Entwicklungsphase oder die Plausibilitätsprüfung in der Produktivphase einen Fehler, muss die Systemkomponente davon ausgehen, dass das installierte kryptografische Material nicht mehr sicher ist. Dabei ist es nicht möglich, dass einmal potenziell offengelegte geheime kryptografische Material wieder sicher zu machen, da sein Geheimnis nicht wieder herstellbar ist. Es kann beispielsweise in der folgenden Weise als Sicherungsmaßnahme reagiert werden. Zuerst kann die noch nicht (vollständig) erfolgte Bereitstellung des kryptografischen Materials, also das Provisioning, unterbunden oder zumindest abgebrochen werden. Außerdem kann das potenziell korrumpierte kryptografische Material einer Verwendung entzogen werden, beispielsweise indem dieses in der Systemkomponente sicher gelöscht wird. Ist das kryptografisch Material bereits hochgeladen und eine der Überprüfungen schlägt beim ersten Hochfahren der Systemkomponente fehl, dann kann ebenfalls eine Warnung ausgegeben werden, beispielsweise in eine Log-Datei eingeschrieben und/oder versendet werden. Ist ein Anzeigegerät verfügbar, kann diese auch unmittelbar angezeigt werden. In der Produktion der Systemkomponenten wäre beispielsweise auch eine akustische Anzeige oder dergleichen denkbar. Es wird damit darüber informiert, dass das potenziell installierte Produktiv-Kryptomaterial nicht mehr sicher ist und entsprechend verworfen werden muss. Falls die Systemkomponente dabei die Verbindung zu einem zentralen Server, beispielsweise einem Kryptomaterial-Server, hat, dann kann die Warnung auch die Benachrichtigung dieser Zentrale beinhalten.
-
Dabei kann es in der Praxis auch Fälle geben, in denen auf die Nutzung des installierten kryptografischen Materials bei den anderen teilnehmenden Systemkomponenten des Fahrzeug-Ökosystems trotz der potenziellen Korrumpierung des kryptografischen Materials einer Systemkomponente aus Kostengründen oder technischen Gründen nicht generell verzichtet werden kann. Dies kann beispielsweise der Fall sein, wenn das kryptografische Material in den anderen teilnehmenden Systemkomponenten nicht mehr ausgetauscht werden kann. In einem solchen Fall kann das Stoppen der Ausführung der Systemkomponente helfen, um die Wahrscheinlichkeit einer tatsächlichen Korrumpierung des Produktiv-Kryptomaterials zu minimieren. Das installierte Produktiv-Kryptomaterial wird dann in der betroffenen Systemkomponente sofort sicher gelöscht, wie es oben bereits angedeutet ist.
-
Wie bereits erwähnt kann das Verfahren für verschiedene Systemkomponenten in verschiedenartigen vernetzten Systemen eingesetzt werden. Besonders effizient ist seine Nutzung dann, wenn das vernetzte System ein Fahrzeug-Ökosystem ist, da hier die entsprechenden Anforderungen hinsichtlich einer aufwändigen Entwicklung mit vielen beteiligten Partnern das Einhalten von Sicherheitsrichtlinien in der Praxis häufig sehr schwierig macht. Durch die Implementierung des erfindungsgemäßen Verfahrens und damit einer Selbstüberprüfung durch die jeweilige Systemkomponente kann die Gefahr einer potenziellen Sicherheitslücke drastisch minimiert werden.
-
Weitere vorteilhafte Ausgestaltungen ergeben sich auch aus dem Ausführungsbeispiel, welches nachfolgend unter Bezugnahme auf die Figur näher beschrieben ist.
-
Die einzige beigefügte Figur zeigt eine schematische Darstellung eines möglichen Ausführungsbeispiels des erfindungsgemäßen Verfahrens.
-
In der einzigen beigefügten Figur ist das erfindungsgemäße Verfahren in einer möglichen Ausführungsform dargestellt. Das Verfahren stellt dabei sicher, dass eine Systemkomponente SK im Testmodus weder absichtlich noch versehentlich mit dem falschen Kryptomaterial KM betrieben werden kann. Ziel ist es dabei, eine sichere Nutzung von kryptografischem Material KM sowohl in einer Entwicklungsphase als auch einer Produktivphase der Systemkomponente SK, welche Teil eines Fahrzeug-Ökosystems sein soll, sicherzustellen. Es kann sich bei der Systemkomponente SK beispielsweise um Fahrzeuge, einzelne Steuergeräte, externe Geräte, Applikationen des OEMs, einen Backend-Server beispielsweise des OEMs und dergleichen handeln. All diese Systemkomponenten SK sind mit dem kryptografischen Material KM ausgestattet und haben einen Lebenszyklus, welcher aus mindestens zwei Phasen besteht, einer Entwicklungsphase einerseits und einer Produktivphase andererseits.
-
Das gesamte kryptografische Material KM wird in einem ersten Schritt 1 auf einem Kryptomaterial-Server KMS generiert und in einem zweiten Schritt entsprechend markiert und mit einem privaten Schlüssel PrivKey des Kryptomaterial-Servers KMS signiert. Die entsprechende Markierung M weist das Kryptomaterial KM als Test-Kryptomaterial oder als Produktiv-Kryptomaterial aus. Sie kann jederzeit unter Zuhilfenahme des öffentlichen Schlüssels PubKeyKMS des Kryptomaterial-Servers KMS verifiziert werden.
-
In der Abbildung ist also eine Absicherung der Markierung über kryptografische Methoden dargestellt. Im Detail könnte eine solche manipulationssichere syntaktische Markierung beispielsweise bei X.509-Zertifikaten durch das Anhängen an eines der Teilfelder des X.509-Subjektfeldes erfolgen, indem hier ein String TEST für die Entwicklungsphase oder PROD für die Produktivphase angehängt wird. Alternativ dazu können bei derartigen Zertifikaten für diesen Zweck auch spezielle Extensions mit entsprechendem Inhalt, beispielsweise TEST und PROD angeführt und genutzt werden. Durch die Markierung M des Zertifikats selbst wird dann auch der zugehörige private Schlüssel PrivKey indirekt, also mittelbar, entsprechend markiert. Nicht mit den Zertifikaten in Zusammenhang stehendes Kryptomaterial KM, beispielsweise symmetrisches Kryptomaterial, kann in Anlehnung an die Zertifikate ebenfalls mit einer Markierung M, sinnvollerweise wiederum TEST und PROD, konkateniert werden, wobei diese Konkatenierung nachfolgend durch die Doppelstriche dargestellt ist. Das Ergebnis wird anschließend von einer zentralen Stelle, hier beispielsweise dem Kryptomaterial-Server KMS, signiert. Die Korrektheit des Zertifikats bzw. der Signatur SIGN kann jederzeit mit dem öffentlichen Schlüssel PubKeyKMS des Austellers überprüft werden, wodurch die Markierung M des jeweiligen kryptografischen Materials KM sicher festgestellt werden kann. Diese Überprüfung kann beispielsweise auch während der Laufzeit der Systemkomponenten SK, in denen das signierte kryptografische Material KM installiert ist, jederzeit sicher vorgenommen werden.
-
Der dritte Schritt ist jetzt die Bereitstellung dieses kryptografischen Materials KM, welches mit dem entsprechenden Merkmal M verknüpft ist. Das kryptografische Material KM ist entsprechend signiert und gelangt nun beim Provisioning in die Systemkomponente SK und wird dort entsprechend in einem Speicher abgelegt. Hierfür dient ein Hardware Security Module HSM, in welchem außerdem ein Zustandsflag gespeichert ist, welcher in der Abbildung der Figur mit „FLAG“ dargestellt ist. Der Zustandsflag FLAG ist hier also über das HSM und seine Speicherung im HSM gegen Manipulation geschützt. Wie eingangs bereits erwähnt, sind alternative Methoden, beispielsweise ein WORM-Speicher und/oder eine kryptografische Methode, ebenso denkbar.
-
Im vierten Schritt wird dann eine Feststellungsfunktion durchgeführt, über welche die Systemkomponente SK feststellen kann, in welcher Phase sie sich befindet, also in der Produktivphase oder in der Entwicklungsphase. Dafür wird das FLAG ausgewertet. Wird nach dieser Feststellungsfunktion festgestellt, dass die Systemkomponente SK in der Produktivphase ist, erfolgt im fünften Schritt eine Plausibilitätsprüfung. Im Rahmen dieser Plausibilitätsprüfung wird in der Systemkomponente geprüft, ob alle vorgegebenen Schnittstellen, welche nur für die Entwicklung implementiert waren, abgeschaltet und/oder deinstalliert sind, um so sicherzustellen, dass auf die Systemkomponente SK kein ungewollter und unerlaubter Zugriff mehr erfolgen kann. Ist auch diese Plausibilitätsprüfung positiv abgeschlossen, wird im sechsten Schritt die Überprüfung der Übereinstimmung vorgenommen. Für den Fall, dass die Feststellungsfunktion ergeben hat, dass die Systemkomponente SK sich nicht in der Produktivphase sondern der Entwicklungsphase befindet, wird der fünfte Schritt übersprungen.
-
Im Rahmen der Überprüfung der Übereinstimmung wird nun geprüft, ob die Markierung M des Kryptomaterials KM zu der über die Feststellungsfunktion erfassten Phase passt. Befindet sich die Systemkomponente SK also in der Entwicklungsphase, müsste die Markierung M des Kryptomaterials KM „TEST“ lauten. Befindet sie sich in der Produktivphase müsste diese dementsprechend „PROD“ lauten. Ist dies der Fall, liegt also das für die entsprechende Phase passende Kryptomaterial in der Systemkomponente SK vor. Dann wird das Verfahren weitergeführt und die Systemkomponente kann den für sie vorgesehenen Betrieb innerhalb des vernetzten Fahrzeug-Ökosystems aufnehmen.
-
Wird nun bei der Plausibilitätsprüfung im fünften Schritt, sofern dieser durchgeführt wird, die Systemkomponente SK also in der Produktivphase ist, festgestellt, dass einzelne Schnittstellen nicht deinstalliert oder geschlossen wurden, dann können sofort Sicherungsmaßnahmen eingeleitet werden, bevor überhaupt die Überprüfung der Übereinstimmung erfolgt. Wird die Plausibilitätsprüfung positiv abgeschlossen, sind also alle Voraussetzungen in der Systemkomponente SK für die Produktivphase, in welche sie geschaltet ist, erfüllt, dann erfolgt auch hier die Überprüfung der Übereinstimmung, wie oben bereits erwähnt. Auch das Ergebnis bei der Überprüfung der Übereinstimmung kann nun anzeigen, dass ein Fehler vorliegt. So kann beispielsweise in der Produktivphase Test-Kryptomaterial eingesetzt sein, welches potenziell korrumpiert ist, oder in der Entwicklungsphase kann Produktiv-Kryptomaterial eingesetzt sein, welches so in der Entwicklungsphase nicht verwendet werden sollte, dass es hierdurch korrumpiert werden könnte, und da ein einmal gelüftetes Geheimnis des Kryptomaterials KM ja auch nicht wieder hergestellt werden kann. Auch in diesen beiden Fällen der nicht erfolgreichen Überprüfung der Übereinstimmung werden dann Sicherungsmaßnahmen eingeleitet, welche sich im Wesentlichen nicht von denen bei der Plausibilitätsprüfung unterschieden müssen.
-
Sowohl die Überprüfung der Übereinstimmung als auch die Plausibilitätsprüfung sollten, soweit möglich, bereits beim Provisioning direkt erfolgen. Falls in dieser Phase festgestellt wird, dass die Plausibilitätsprüfung oder die Überprüfung der Übereinstimmung nicht ok sind, kann eine geeignete Sicherungsmaßnahme eingeleitet werden, beispielsweise kann eine Warnmeldung ausgegeben oder in dem Netzwerk verbreitet und gespeichert werden und es kann vorzugsweise der Provisioning-Vorgang abgebrochen werden. Ist bereits Kryptomaterial KM eingebracht, so wird dieses sicher gelöscht. Ist die Durchführung der Überprüfung der Übereinstimmung beim Provisioning nicht möglich, und ebenso die Plausibilitätsprüfung, weil beispielsweise das Provisioning so erfolgt, dass die Systemkomponente SK noch nicht hochgefahren ist, dann sollte dennoch möglichst schnell die Plausibilitätsprüfung und die Überprüfung der Übereinstimmung erfolgen. In diesem Fall kann dies beispielsweise dann erfolgen, wenn die Systemkomponente hochgefahren wird, also vorzugsweise bei ihrem ersten Bootvorgang. Auch hier können im Fall, dass die Plausibilitätsprüfung und/oder die Überprüfung der Übereinstimmung nicht ok sind, die entsprechenden Sicherungsmaßnahmen eingeleitet werden, welche in diesem Fall zusätzlich ein Stoppen der Systemkomponente SK oder einen zumindest nur sehr stark eingeschränkter Betrieb der Systemkomponente SK zusätzlich vorsehen können.
