DE102014208838A1

DE102014208838A1 - Verfahren zum Betreiben eines Steuergeräts

Info

Publication number: DE102014208838A1
Application number: DE102014208838.0A
Authority: DE
Inventors: Stefan Schneider; Andreas SOENKENS; Thomas Keller; Martin Emele
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2014-05-12
Filing date: 2014-05-12
Publication date: 2015-11-12
Also published as: CN105892348A; US20150324583A1; CN105892348B; US10025954B2

Abstract

Es werden ein Verfahren zum Betreiben eines Steuergeräts (202, 204), ein solches Steuergerät (202, 204) und ein elektronisches Hardware-Sicherheitsmodul (214, 234) vorgestellt. Dabei wird eine Manipulation einer Hauptrecheneinheit (210, 230) durch das elektronische Hardware-Sicherheitsmodul (214, 234) erkannt und es wird überprüft, ob eine Reprogrammierung möglich ist.

Description

Die Erfindung betrifft ein Verfahren zum Betreiben eines Steuergeräts, ein solches Steuergerät sowie ein elektronisches Hardware-Sicherheitsmodul, das in einem Steuergerät verwendet wird. Das Steuergerät kommt insbesondere in einem Kraftfahrzeug zum Einsatz.
Stand der Technik
Steuergeräte sind elektronische Module, die bspw. in Kraftfahrzeugen eingesetzt werden, um Abläufe zu steuern und zu regeln. Hierzu sind die Steuergeräte Komponenten des Kraftfahrzeugs zugeordnet, deren Betrieb mit dem zugeordneten Steuergerät kontrolliert wird. Hierzu liest das Steuergerät von Sensoren erfasste Daten ein und wirkt durch die Ansteuerung von Aktoren auf den Betrieb ein.
Das beschriebene Verfahren kommt in Verbindung mit einem elektronischen Sicherheitsmodul zur Anwendung, das in einem Steuergerät, insbesondere im Automotive-Bereich, in sicherheitsrelevanten Bereichen eingesetzt wird. Bei den meisten Anwendungen in den sicherheitsrelevanten Bereichen ist das unmanipulierbare oder nicht einsehbare Speichern von Daten eine wesentliche Anforderung. Hierbei werden kryptographische Schlüssel eingesetzt, die in symmetrischen oder asymmetrischen Verschlüsselungsverfahren zur Anwendung kommen.
Die verwendeten Schlüssel und Verschlüsselungsverfahren stellen Geheimnisse dar, die vor Angreifern geheim gehalten werden müssen. Andere Anwendungen in sicherheitsrelevanten Bereichen betreffen bspw. den Schutz vor unerlaubten Veränderung, bspw. das Speichern von geänderten Seriennummern oder Kilometerständen, das Unterbinden von nicht genehmigten Tuning-Maßnahmen usw.
Daher ist es erforderlich, in Steuergeräten sichere Umgebungen bereitzustellen, in denen Funktionen ausgeführt werden können, die diese Geheimnisse einsehen und/oder verändern müssen. Diese Umgebungen weisen regelmäßig eine sichere Recheneinheit bzw. CPU, die auch als secure CPU bezeichnet wird, sowie ein Speichermodul auf. Eine solche Umgebung wird hierin als Hardware-Sicherheitsmodul (HSM: Hardware Security Module) bezeichnet. Dieses stellt ein leistungsfähiges Modul mit Hardware- und Software-Komponenten dar, welches den Schutz und die Vertrauenswürdigkeit von eingebetteten Systemen verbessert. Insbesondere unterstützt das HSM dabei, sicherheitskritische Anwendungen und Daten zu schützen. Mit einem HSM können ebenfalls die Sicherheitskosten reduziert werden, während zugleich ein wirksamer Schutz vor Angreifern geboten werden kann. Bezüglich des grundlegenden Aufbaus eines HSM wird auf 3 verwiesen.
Bei Angriffen Dritter auf ein Steuergerät versuchen diese, den Betrieb des im Steuergerät vorgesehenen Hauptrechners und/oder den Ablauf der Steuergeräte-Software zu manipulieren. Bei einer erkannten Manipulation wird im Bereich eingebetteter Systeme bzw. im Embedded-Bereich entweder nur die Manipulation detektiert oder ein Notlaufbetrieb ausgelöst. Eine Heilung des Systems, d. h. des Steuergeräts und der darauf ablaufenden Software, findet nur mit expliziter Reprogrammierung in der Kundenwerkstatt statt. Im Consumer-Electronic-Bereich, z. B. bei TV-Receivern, Smartphones usw., wird die Selbstheilung von außen getriggert, bspw. von einem Anwender, Server usw.
Offenbarung der Erfindung
Vor diesem Hintergrund werden ein Verfahren mit den Merkmalen des Anspruchs 1, ein elektronisches Hardware-Sicherheitsmodul nach Anspruch 9 und ein Steuergerät gemäß Anspruch 11 vorgestellt. Ausgestaltungen gehen aus den abhängigen Ansprüchen und der Beschreibung hervor.
Gemäß dem vorgestellten Verfahren startet bei einer erkannten Manipulation das HSM in Ausgestaltung automatisch, nachdem überprüft wurde, ob eine Reprogrammierung möglich ist, eine Reprogrammierung zur Selbstheilung des Systems bzw. des Steuergeräts. Es erfolgt somit eine eigenständige Erkennung und Selbstheilung durch eine Art integrierten Sicherheits- bzw. Security Watchdog, dem elektronischen Hardware-Sicherheitsmodul (HSM), im korrupten System bzw. Steuergerät. So werden Sicherheitsrisiken und Komforteinbußen minimiert.
Das HSM erkennt die Manipulation des Hauptrechners bzw. Maincores in dem Steuergerät bzw. der ECU und startet die Selbstheilung. Die Selbstheilung wird durch Reprogrammierung durchgeführt. Die vertrauenswürdige Software zur Reprogrammierung liegt entweder

– im HSM-Flash-Speicher der betroffenen ECU,
– in einem Flash-Speicher einer nicht betroffenen ECU, vernetzt mit der betroffenen ECU,
– im HSM-Flash-Speicher einer nicht betroffenen ECU, vernetzt mit der betroffenen ECU,
– im abgesicherten Speicher einer Trusted Cloud, vernetzt mit der betroffenen ECU,
– im abgesicherten Speicher einer Trusted Cloud, vernetzt mit einer nicht betroffenen ECU, die vernetzt mit der betroffenen ECU ist.

Für die Übertragung können ein klassisches Bussystem oder ein abgesichertes Bussystem verwendet werden. So kann bspw. der HSM-Security-Bus verwendet werden.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Kurze Beschreibung der Zeichnungen
1 zeigt eine Vertrauenspyramide.
2 zeigt in einer schematischen Darstellung Funktionen eines HSM.
3 zeigt in einer schematischen Darstellung den Aufbau einer Ausführung des HSM.
4 zeigt einen Steuergeräteverbund.
5 zeigt einen möglichen Ablauf des vorgestellten Verfahrens.
Ausführungsformen der Erfindung
Die Erfindung ist anhand von Ausführungsformen in den Zeichnungen schematisch dargestellt und wird nachfolgend unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
Um einem IT-System dahingegen zu vertrauen, dass es immer so agiert, wie dies erwartet ist, erfordert es, aufeinanderfolgend allen Schichten zu vertrauen, die eingebunden sind, um ein vertrauenswürdiges IT-System zu erzeugen.
1 zeigt eine Pyramide des Vertrauens, die als Trust Pyramid bezeichnet wird, für ein typisches IT-System. Diese ist insgesamt mit der Bezugsziffer 10 bezeichnet und umfasst eine Schicht für eine organisatorische Sicherheit 12, eine Schicht für eine Systemsicherheit 14, eine Schicht für eine Hardware-Sicherheit 16, eine Schicht für eine Software-Sicherheit 18 und eine oberste Schicht für Vertrauen 20 bzw. Trust.
Um dem gesamten IT-System vertrauen zu können, ist es erforderlich, dass jede Schicht auf die wirksame Sicherheit der darunterliegenden Schicht vertrauen kann, ohne in der Lage zu sein, dies direkt zu verifizieren. Dies bedeutet bspw., dass sich eine perfekte Software- und Hardware-Sicherheitslösung durch eine schwache darunterliegende Sicherheitssystemgestaltung als nutzlos erweisen kann. Darüber hinaus kann gegeben sein, dass eine mögliche Schwäche in der Systemgestaltung nicht erfasst oder durch die oberen Hard- und Software-Schichten verhindert wird.
Im Gegensatz zu typischen Back- und IT-Systemen ist die Hardware-Schicht von eingebetteten Systemen oftmals physischen Angriffen ausgesetzt, die Hardware- oder Software-Funktionen durch physische Mittel beeinflussen, bspw. einen Flash-Speicher manipulieren oder Alarmfunktionen deaktivieren. Ein Ansatz, solche physischen Attacken zu erschweren, besteht darin, insbesondere manipuliergeschützte Hardware-Sicherheitsmodule (HSM) einzusetzen, wie diese bspw. in 2 gezeigt sind. Ein solches HSM schützt wichtige Informationen, bspw. Personen-Identifikationsnummern (PIN), sichere Schlüssel und kritische Operationen, bspw. eine PIN-Verifikation, eine Datenverschlüsselung, bspw. durch starke physische Abschirmung.
Wie ein HSM ausgebildet sein kann und was für Funktionen von diesem durchgeführt werden können, um die Sicherheit eines eingebetteten Systems zu verbessern, wird im Folgenden dargestellt.
2 zeigt die Kernfunktionen eines typischen Hardware-Sicherheitsmoduls. Die Darstellung zeigt eine Software-Schicht 30 und eine Hardware-Schicht 32, die vor unberechtigten Zugriffen geschützt ist.
Die Software-Schicht 30 umfasst eine Reihe von Anwendungen 34, von denen hier drei dargestellt sind. Weiterhin ist ein Betriebssystem 36 vorgesehen. Die Hardware-Schicht 32 umfasst eingebettete Standard-Hardware 38 und ein Hardware-Sicherheitsmodul (HSM) 40. In diesem HSM 40 ist ein erster Block 42 für Schnittstellen und Steuerung, ein zweiter Block 44 für sichere Verschlüsselungsfunktionen, ein dritter Block 46 für sichere Funktionen und ein sicherer Speicher 48 vorgesehen.
Der sichere Speicher 48 ist ein kleiner, nicht flüchtiger Datenspeicher, bspw. mit einer Kapazität von einigen Kilobyte, innerhalb des manipuliergeschützten HSM 40, um ein nicht autorisiertes Auslesen, eine Manipulation oder ein Löschen von kritischen Informationen, wie bspw. von kryptographischen Schlüsseln, kryptographischen Zertifikaten oder Authentifizierungsdaten, bspw. PINs oder Passwörter zu verhindern. Der sichere Speicher 48 des HSM 40 enthält weiterhin alle HSM-Konfigurationsinformationen, bspw. Informationen zum Eigentümer des HSM 40 oder Zugriffautorisierungen zu gesicherten internen Einheiten.
Im zweiten Block 44 für sichere Verschlüsselungsfunktionen sind kryptographische Algorithmen, die für eine Datenverschlüsselung und -entschlüsselung verwendet werden, bspw. AES oder 3DES, eine Datenintegritätsverstärkung, bspw. MAC oder HMAC, oder eine Datenursprungsverifikation, bspw. durch Verwenden von digitalen Signatur-Algorithmen, wie bspw. RSA oder ECC, und alle zugehörigen kryptographischen Aktivitäten, wie bspw. Schlüsselerzeugung, Schlüsselverifikation, enthalten.
Sichere Funktionen im dritten Block 46 umfassen alle geschützten Funktionen, die nicht direkt einem kryptographischen Verfahren zugeordnet sind, wobei das HSM 40 als physisch geschützter "Trust Anchor" dient. Dies kann bspw. ein physisch geschütztes Taktsignal, ein interner Zufallszahlengenerator, ein Ladeprogramm-Schutzmechanismus oder irgendeine kritische Anwendungsfunktion sein, bspw. um einen sicheren Dongle zu realisieren.
Der erste Block 42 für Schnittstellen und Steuerung umfasst die interne HSM-Logik, welche die HSM-Kommunikation mit der Außenwelt implementiert und die den Betrieb aller internen Basiskomponenten, wie diese vorstehend erwähnt sind, verwaltet.
Alle funktionalen Basiskomponenten des Hardware-Sicherheitsmoduls 40, wie dies vorstehend beschrieben ist, sind von einer kontinuierlichen physischen Grenze umgeben, was verhindert, dass interne Daten und Prozesse abgehört, kopiert bzw. nachgebildet oder manipuliert werden können. Dies könnte dazu führen, dass ein nicht autorisierter Nutzer interne Geheimnisse verwenden oder kompromittieren kann. Die kryptographische Grenze wird üblicherweise mit algorithmischen und physischen Zeitkanal-Gegenmaßnahmen mit dedizierten Zugriffsschutzmitteln implementiert, bspw. eine spezielle Abschirmung oder Beschichtungen, um einen Seitenkanalwiderstand, einen Zugriffshinweis, einen Zugriffswiderstand oder eine Zugriffsantwort zu ermöglichen.
Wie das HSM 40 die Sicherheit einer eingebetteten Produktlösung verbessern kann, wird nachstehend dargelegt:
Das HSM 40 schützt kritische Informationen, bspw. Identitäten, Signierschlüssel oder Schlüssel, durch die physische Abschirmung, die nicht durch eine Software-Anfälligkeit umgangen werden kann.
Das HSM 40 kann dabei helfen, mächtige POI-Angreifer (POI: Point of Interest) zu erfassen, abzuschwächen oder abzuhalten, indem wirksame Seitenkanal-Widerstand- und Zugriffsschutz-Barrieren implementiert werden, die u. a. starke Zugriffsrestriktionen haben, selbst für autorisierte Nutzer. Es werden bspw. einige Informationen immer exklusiv innerhalb des HSM 40 gehalten.
Das HSM 40 kann Sicherheitsmechanismen beschleunigen, bei denen bestimmte Beschleunigungsschaltkreise angewendet werden.
Mit dem HSM 40 können Sicherheitskosten reduziert werden, indem hoch optimierte Spezialschaltkreise hinzugefügt werden, bspw. für eine standardisierte Kryptographie.
Ein möglicher Aufbau des HSM ist in 3 dargestellt. Diese zeigt das HSM 70, das in eine Umgebung eingebettet ist. Die Darstellung zeigt eine Hauptrecheneinheit 72, einen Systembus 74, einen RAM-Baustein 76 mit einem gemeinsam zu nutzenden Bereich und ein Testprogramm 78 bzw. Debugger mit zugeordneter Hardware 80 und Schnittstelle 82, die wiederum ein Register 84 umfasst. Die Darstellung zeigt weiterhin einen Speicherbaustein 86 für Flash-Code mit einem Datenbereich 88 und einem sicheren Bereich 90, in dem sichere Kerndaten enthalten sind.
In dem HSM 70 sind eine Schnittstelle 100 zum Testprogram 78, ein sicherer Rechenkern 102, ein sicherer RAM-Baustein 104, ein Zufallsgenerator 106, bspw. ein TRNG oder PRNG, und Schlüssel 108, bspw. AES, vorgesehen.
4 zeigt einen Steuergeräteverbund, der insgesamt mit der Bezugsziffer 200 bezeichnet ist. Dieser Steuergeräteverbund 200 umfasst ein erstes Steuergerät 202 und ein zweites Steuergerät 204. Weiterhin zeigt die Darstellung eine Cloud 206, in diesem Fall eine vertrauenswürdige Cloud bzw. Trusted Cloud.
Das erste Steuergerät 202 weist eine erste Hauptrecheneinheit 210, eine erste Kommunikationsschnittstelle 212 und ein erstes elektronisches Hardware-Sicherheitsmodul (HSM) 214 auf, dem wiederum eine Schnittstelle 216, ein Flash-Speicher 218 als nicht flüchtiger Speicher und als flüchtiger Speicher ein RAM-Baustein 220 zugeordnet sind.
Das zweite Steuergerät 204 weist eine zweite Hauptrecheneinheit 230, eine zweite Kommunikationsschnittstelle 232 und ein zweites elektronisches Hardware-Sicherheitsmodul (HSM) 234 auf, dem wiederum eine Schnittstelle 236, ein Flash-Speicher 238 als nicht flüchtiger Speicher und als flüchtiger Speicher ein RAM-Baustein 240 zugeordnet sind. Weiterhin ist eine zusätzliche Kommunikationsschnittstelle 242 vorgesehen.
Die Cloud 206 weist einen abgesicherten Speicher 246 auf, in dem Daten bzw. eine Software für eine Reprogrammierung abgelegt sein können bzw. kann. Alternativ oder ergänzend kann die Software im ersten Flash-Speicher 218 und/oder dem zweiten Flash-Speicher 238 abgelegt sein. Im Falle einer Manipulation des ersten Steuergeräts 202 bzw. der ersten Hauptrecheneinheit 210 des ersten Steuergeräts 202 wird dies durch das erste HSM 214 erkannt. Dieses startet dann auch die Reprogrammierung, wobei die für die Reprogrammierung erforderliche Software im ersten Flash-Speicher 218, im zweiten Flash-Speicher 238 und/oder im abgesicherten Speicher 246 der Cloud 206 abgelegt sein kann.
In 5 ist in einem Flussdiagramm ein möglicher Ablauf des beschriebenen Verfahrens dargestellt. In einem ersten Schritt 250 wird überprüft, ob ein Fehler im Betrieb des Steuergeräts vorliegt. Ist dies der Fall, erfolgt in einem nächsten Schritt 252 die Überprüfung, ob eine Reprogrammierung möglich ist. Dies kann bspw. vom Betriebszustand des Kraftfahrzeugs abhängen. Es kann bspw. erforderlich sein, dass das Kraftfahrzeug steht. Dies kann weiterhin davon abhängen, ob ein vertrauenswürdiger Code für eine Reprogrammierung überhaupt zur Verfügung steht. Ist eine Reprogrammierung nicht möglich, erfolgt in einem Schritt 254 eine Ersatzreaktion, bspw. die Einleitung eines Notlaufs.
Ergibt die Überprüfung in Schritt 252, dass eine Reprogrammierung möglich ist, so wird diese in einem abschließenden Schritt 256 durchgeführt. Dabei kann die Steuergeräte-Software, einschließlich Code und Daten, wieder hergestellt werden.

Claims

Verfahren zum Betreiben eines Steuergeräts (202, 204), das eine Hauptrecheneinheit (210, 230) und ein elektronisches Hardware-Sicherheitsmodul (40, 70, 214, 234) aufweist, wobei eine Manipulation der Hauptrecheneinheit (210, 230) durch das elektronische Hardware-Sicherheitsmodul (40, 70, 214, 234) erkannt wird und überprüft wird, ob eine Reprogrammierung möglich ist.
Verfahren nach Anspruch 1, bei dem, wenn eine Reprogrammierung möglich ist, diese durchgeführt wird.
Verfahren nach Anspruch 1, bei dem, wenn eine Reprogrammierung nicht möglich ist, eine Ersatzreaktion ausgelöst wird.
Verfahren nach einem der Ansprüche 1 bis 3, bei dem die zur Reprogrammierung erforderliche Software in einem nicht flüchtigen Speicher des elektronischen Hardware-Sicherheitsmoduls (40, 70, 214, 234) des Steuergeräts (202, 204) abgelegt ist.
Verfahren nach einem der Ansprüche 1 bis 3, bei dem die zur Reprogrammierung erforderliche Software in einem nicht flüchtigen Speicher eines elektronischen Hardware-Sicherheitsmoduls (40, 70, 214, 234) eines weiteren Steuergeräts (202, 204) abgelegt ist.
Verfahren nach einem der Ansprüche 1 bis 5, bei dem die zur Reprogrammierung erforderliche Software in einem Speicher (246) einer Cloud (206) abgelegt ist.
Verfahren nach Anspruch 6, bei dem die Cloud (206) mit dem Steuergerät (202, 204) verbunden ist.
Verfahren nach Anspruch 6 oder 7, bei dem die Cloud (206) mit einem weiteren Steuergerät (202, 204), das mit dem Steuergerät (202, 204) vernetzt ist, verbunden ist.
Elektronisches Hardware-Sicherheitsmodul, insbesondere zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 8, das in einem Steuergerät (202, 204) mit einer Hauptrecheneinheit (210, 230) zum Einsatz kommt, wobei das elektronische Hardware-Sicherheitsmodul dazu eingerichtet ist, eine Manipulation der Hauptrecheneinheit (210, 230) zu erkennen und zu überprüfen, ob eine Reprogrammierung möglich ist.
Elektronisches Hardware-Sicherheitsmodul nach Anspruch 9 mit einem Flash-Speicher (218, 238), in dem eine zur Reprogrammierung erforderliche Software abgelegt ist.
Steuergerät mit einer Hauptrecheneinheit (210, 230) und einem elektronischen Hardware-Sicherheitsmodul (40, 70, 214, 234) nach Anspruch 9 oder 10.