-
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Hardware-Sicherheits-Moduls für ein Rechensystem, das einen Speicher aufweist, sowie ein Hardware-Sicherheits-Modul und ein Computerprogramm zu dessen Durchführung.
-
Stand der Technik
-
Ein Hardware-Sicherheits-Modul (engl. „Hardware Security Module“ HSM) bezeichnet ein typischerweise internes oder externes Peripheriegerät für eine effiziente und sichere Ausführung z.B. kryptographischer Operationen oder Applikationen. Beim HSM handelt es sich um eine Hardwarekomponente, die Sicherheitsfunktionen physikalisch kapselt. Als integrierte Chips sind sie speziell für IT-Sicherheitsanwendungen ausgelegt. Typischerweise verfügen sie über einen eigenen CPU-Core, verschiedene Datenspeicher (z. B. RAM, ROM oder Flash) und kryptografische Hardwarebeschleuniger. Dies ermöglicht zum Beispiel, die Vertrauenswürdigkeit und die Integrität von Daten und den damit verbundenen Informationen sicherzustellen oder Daten sicher zu speichern. Beispielsweise können HSM in Mikrocontroller implementiert sein.
-
Im Bereich Automotive, also in Fahrzeugen bzw. dort in Steuergeräten, können solche HSMs z.B. im Rahmen vernetzter Fahrzeuge Anwendung finden. In Fahrzeugen werden immer mehr Sensoren, Bauteile und Geräte mit Software-Anwendungen vernetzt und über elektronische Module gesteuert, um systemweit Informationen über Betriebszustände und weitere relevante Daten im Fahrzeug auszutauschen.
-
HSMs unterstützen bei der Vernetzung dieser Komponenten untereinander sowie mit der Fahrzeugumgebung und können die Kommunikation zwischen den Steuergeräten absichern. Sie können sicherstellen, dass durch unberechtigte Zugriffe Dritter einzelne Fahrzeugfunktionen nicht beeinträchtigt oder deaktiviert werden können(z.B. durch Aufspielen von Schadsoftware auf ein Steuergerät), oder auch dass bestimmte Fahrzeugeigenschaften oder -funktionen nicht verändert werden (z. B. Chip-Tuning, Fälschung des Tachometerstandes).
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Betreiben eines Hardware-Sicherheits-Moduls sowie ein Hardware-Sicherheits-Modul oder ein Rechensystem hiermit und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
Die Erfindung beschäftigt sich mit dem Betreiben eines Hardware-Sicherheits-Moduls (HSM) für ein Rechensystem wie z.B. einen Mikrocontroller oder ein Steuergerät eines Fahrzeugs, das einen Speicher aufweist. Das Hardware-Sicherheits-Moduls interagiert hierzu in der Regel mit einem (Haupt-)Prozessor mit einem oder typischerweise mit mehreren Prozessor-Kernen (vereinfacht auch als Host bzw. Hostsystem bezeichnet, der typischerweise, insbesondere wenn es sich bei dem Rechensystem um einen Mikrocontroller oder ein Steuergerät handelt, ebenfalls in dem Rechensystem vorgesehen ist, über entsprechende Schnittstellen oder Datenschnittstellen.
-
In einem HSM können fest vorgegebene Daten bzw. Arten von Daten zu auftretenden Ereignissen (oder Events), die z.B. eine Manipulation (oder Änderung) der Host Software anzeigen, hinterlegt bzw. gespeichert werden, d.h. eine Implementierung kann rein statisch sein und nur bereits definierte Daten (die im HSM hinterlegt werden können) im definierten Format im Sinne einer Plattformlösung anbieten. Wenn bei einer konkreten Verwendung eines HSMs, z.B. von einem bestimmten Kunden, andere Daten oder andere Arten von Daten (z.B. mit anderem Datenformat) im HSM hinterlegt werden sollen, so sind bislang - um die nötige Sicherheit des HSM weiterhin zu gewährleisten - Anpassungen und Neuentwicklungen an der HSM-Firmware und ggf. an ihrer Schnittstelle notwendig sind. Dies sorgt für einen erheblichen Mehraufwand und Mehrkosten.
-
Vor diesem Hintergrund wird vorgeschlagen, dass mittels des Hardware-Sicherheits-Moduls ein oder mehrere Logdaten-Speicherbereiche, die jeweils einem Ereignistyp zugeordnet sind, und insbesondere auch ein Ereignisdaten-Speicherbereich bereitgestellt werden. Wenn von dem Hardware-Sicherheits-Modul zu einem bestimmen Ereignis ein Logdatensatz empfangen werden soll bzw. empfangen wird, der z.B. von dem erwähnten Host stammt, wird von dem Hardware-Sicherheits-Modul überprüft, ob der Logdatensatz angenommen werden darf. Wenn bestimmt wird, dass der Logdatensatz angenommen werden darf, wird der Logdatensatz in dem dem Ereignistyp des bestimmen Ereignisses zugeordneten Logdaten-Speicherbereich hinterlegt.
-
Ein solcher Logdatensatz kann z.B. Daten zu dem bestimmen Ereignis, die dieses näher spezifizieren oder anderweitig charakterisieren, umfassen, insbesondere aber auch andere Daten wie Umweltdaten, z.B. einen aktuellen Kilometerstand des Fahrzeugs, eine Fahrzeugidentifikationsnummer und dergleichen. Wie später noch erläutert wird, kann der Inhalt des Logdatensatzes einfach und gezielt gewählt bzw. vorgegeben werden. Hierdurch wird ermöglicht, dass beliebige Logdatensatzformate definiert und im HSM gespeichert werden können, ohne dass dafür Einfluss auf die Software des HSM genommen werden müsste, da dies rein hostseitig gelöst ist.
-
Grundsätzlich kann bei solchen Ereignissen zwischen zwei Arten unterschieden werden, nämlich internen Ereignissen, die bzw. deren Auftreten dem HSM bekannt sind, und externen Ereignissen, die bzw. deren Auftreten dem HSM zunächst nicht bekannt sind, sondern nur von extern, nämlich vom Host, angezeigt werden. Um ein bestimmtes Ereignis zu verarbeiten, wird bevorzugt von dem Hardware-Sicherheits-Modul bestimmt, dass der Logdatensatz angenommen werden darf, wenn der Ereignistyp, insbesondere anhand einer den Ereignistyp kennzeichnenden ID, in dem Hardware-Sicherheits-Modul als zulässig hinterlegt ist. Dies gilt bevorzugt für ein externes Ereignis, funktioniert jedoch auch mit einem internen Ereignis.
-
Interne Ereignisse bzw. Events sind solche, die intern im HSM auftreten und auf die denen z.B. die Firmware des HSM reagieren und die Ereignis-Zähler inkrementieren kann. Dies sind z.B. interne Hardware-Fehler oder auch Events von Features (oder Funktionen), die die Firmware unterstützt wie z.B.: ein nicht erfolgreiches Verifizieren einer neuen HSM-Firmware beim HSM-Update oder ein Erkennen einer Manipulation der Host-Software durch eine „Runtime Tuning Detection“, die auf dem HSM durchgeführt wird.
-
Externe Ereignisse bzw. Events sind hingegen solche, die der HSM nicht erkennen kann, da die Quelle auf der Host-Seite entsteht und die Host-Software die Kontrolle über diese Quellen hat. Das kann z. B. eine nicht erfolgreiche Verifikation eines Host-Software-Updates oder eine nicht erfolgreich verifizierte Nachricht von einem Kommunikationspartner bzw. von einem potentiellen Angreifer sein. Auch wären z.B. Zustandswechsel der Host-Software potentielle, externe Events.
-
Zum Hinterlegen von externen Ereignissen als zulässig kann initial z.B. das HSM hinsichtlich sämtlicher Ereignistypen (bzw. mit deren IDs zur Identifikation) mit einer Liste aller zulässigen IDs oder dergleichen konfiguriert werden. Wenn das HSM nun einen Logdatensatz zu einem bestimmen Ereignis (mit einer entsprechenden den Ereignistyp kennzeichnenden ID) empfangen soll, kann es überprüfen, ob die ID in der Liste vorhanden ist. Wenn dies der Fall ist, kann der Logdatensatz entsprechend hinterlegt werden. Wenn dies nicht der Fall ist, kann der Logdatensatz abgelehnt werden.
-
Ebenso kann, um ein bestimmtes Ereignis zu verarbeiten, bevorzugt von dem Hardware-Sicherheits-Modul bestimmt werden, dass der Logdatensatz angenommen werden darf, wenn, insbesondere anhand einer den Ereignistyp kennzeichnenden ID des Ereignisses, bestimmt wird, dass in dem Hardware-Sicherheits-Modul bekannt ist, dass ein Ereignis dieses Ereignistyps aufgetreten ist. Dies gilt bevorzugt für ein internes Ereignis, funktioniert jedoch auch mit einem externen Ereignis. Hierzu kann insbesondere ein Ereignis-Zählerstand für ein Auftreten eines Ereignisses dieses Ereignistyps mit einem Logdaten-Zählerstand über Schreibvorgänge von Logdatensätzen zu dem Ereignistyp in den Logdaten-Speicherbereich verglichen werden. Mit anderen Worten kann jedes Mal, wenn ein Ereignis (ein internes, das bekannt ist, oder ein externes, das gemeldet wird) eines bestimmten Ereignistyps auftritt, ein den Ereignistyp kennzeichnender Ereignis-Zähler (bzw. ein Zählerstand) hochgezählt werden. Ebenso kann jedes Mal, wenn zu einem solchen Ereignis ein Logdatensatz empfangen und hinterlegt wird, der Logdaten-Zähler (bzw. ein Logdaten-Zählerstand) hochgezählt werden. Diese Zähler bzw. Zählerstände können in dem betreffenden Ereignisdaten-Speicherbereich hinterlegt werden. Denkbar ist, dass in dem Ereignisdaten-Speicherbereich zu jedem solchen Ereignistyp auch noch ein Betriebsstunden- oder anderer geeigneter Zähler hinterlegt wird.
-
Wenn nun die Anzahl an aufgetretenen Ereignissen eines Ereignistyps (also dieselbe Art von Ereignis) höher als die Anzahl der hierzu hinterlegten Logdatensätze ist, kann angenommen werden, dass der zu empfangende Logdatensatz ordnungsgemäß erstellt wurde. Andernfalls kann davon ausgegangen werden, dass der Logdatensatz auf unerlaubte oder manipulative Weise erzeugt und an das HSM gesendet wurde und kann abgelehnt werden.
-
Vorzugsweise wird von dem Hardware-Sicherheits-Modul wiederholt, insbesondere regelmäßig, eine Anfrage empfangen, ob neue Ereignisse aufgetreten sind. Mit anderen Worten kann also der Host wiederholt bzw. regelmäßig beim HSM anfragen, ob es neue Ereignisse gibt. Wenn von dem HSM dann an den Host mittgeteilt wird, dass es eines oder mehrere neue Ereignisse gibt, kann der Host hierzu einen entsprechenden Logdatensatz (bzw. jeweils einen für jedes Ereignis) erstellen und an den HSM übermitteln, der dann wiederum prüft, ob er den Logdatensatz annehmen darf.
-
Vorteilhafterweise umfasst jeder jeweils einem Ereignistyp zugeordnete Logdaten-Speicherbereich einen ersten, nur einmal beschreibbaren, Bereich und einen zweiten, mehrfach beschreibbaren Bereich (z.B. einen Ringpufferspeicher).
-
Zweckmäßig ist es dann, wenn ein neu zu hinterlegender Logdatensatz, wenn möglich, zumindest zum Teil in dem ersten Bereich, und ansonsten (d.h. wenn für das konkrete Ereignis kein erster Bereich zum Beschreiben mehr vorhanden ist) in dem zweiten Bereich hinterlegt wird. Damit wird für jeden Ereignistyp (also z.B. für jede ID)wenigstens ein Eintrag in dem Logdaten-Speicherbereich erzeugt, der - z.B. im Wege einer gezielten Manipulation - nicht mehr gelöscht werden kann, was die Sicherheit erhöht.
-
Mit dem vorgeschlagenen Vorgehen wird es also ermöglicht, flexibel kundenspezifische Daten (in den Logdatensätzen), zu definierten Ereignistypen z.B. im Steuergerät abzuspeichern. Dabei können individuelle Formate zu den Daten erstellt werden, die vollständig nach Kundenanforderungen umgesetzt werden können. Zudem können ohne nennenswerten Mehraufwand spezifische Kundenereignisse, die an sich nicht in der Plattform bekannt sind, mitgeloggt werden.
-
Die Vorteile liegen insbesondere darin, dass keinerlei Anpassungen an der HSM-Firmware benötigt werden. Die Umsetzung des Dateiformats ist lediglich auf Host-Seite des Steuergerätes zu implementieren. Bei diesem Konzept wird aber trotzdem sichergestellt, dass aufgetretene Ereignisse nicht (oder zumindest nicht vollständig) verloren gehen können. Hierzu wird das erwähnte Konzept mit nur einmal und mehrfach beschreibbarem Speicherbereich eingesetzt. Dieses Konzept wird dabei insbesondere für jeden Ereignistyp genutzt. Durch die einmal beschreibbaren Bereiche (oder Elemente oder Blöcke) des Logdaten-Speicherbereichs wird sichergestellt, dass ein Angreifer durch manipulierte Software eine gewisse Anzahl an Einträgen darin nicht manipulieren kann. Dadurch ist aus Sicherheits-Sicht (oder Security-Sicht) sichergestellt, dass mögliche Auffähigkeiten nicht vertuscht werden können, da zumindest diese Einträge nicht gelöscht werden können.
-
Ein erfindungsgemäßes Rechensystem, z.B. ein Steuergerät eines Kraftfahrzeugs, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt schematisch ein Rechensystem mit HSM, bei dem ein erfindungsgemäßes Verfahren durchführbar ist.
- 2 zeigt schematisch eine Aufteilung eines Speichers des HSM aus 1.
-
Ausführungsform(en) der Erfindung
-
In 1 ist schematisch ein Rechensystem 100 gemäß einer bevorzugten Ausführungsform der Erfindung gezeigt, bei dem es sich z.B. um ein Steuergerät eines Fahrzeugs handelt kann. Das Rechensystem 100 weist ein Hardware-Sicherheits-Modul 110 (HSM) und einen Host 120 auf, die beide für sich funktionsfähig sind und dementsprechend auch weitere (hier nicht gezeigte) Komponenten wie Prozessorkerne und dergleichen aufweisen. Ebenso könne zwischen HSM 110 und Host 120 Daten ausgetauscht werden. Mit dem Rechensystem 100, insbesondere dem HSM 110, ist ein erfindungsgemäßes Verfahren durchführbar, das nachfolgend anhand der 1 für eine bevorzugte Ausführungsform näher erläutert werden soll.
-
Bei dem vorgeschlagenen Vorgehen, einem „Secure-Logging-Konzept“, sind zwei Arten von Daten vorgesehen, die in dem HSM 110 zu hinterlegen oder zu speichern sind, nämlich Ereignisdaten (oder auch Event-Daten) und Logdaten, insbesondere in Form vom Logdatensätzen. Beide Arten von Daten werden auf dem HSM 110 im Speicher, z. B. einem Flash-Speicher, in abgekapselten Komponenten gespeichert und verwaltet. Hierzu sind für die Ereignisdaten ein Ereignisdaten-Speicherbereich 140 (verwaltet von einem Ereignisdaten-Handler 130) und für die Logdaten Logdaten-Speicherbereiche 160 (verwaltet von einem Logdaten-Handler150) vorgesehen, die von dem HSM 110 bereitgestellt werden und damit Teil dessen Speichers sein können.
-
Hierdurch ist sichergestellt, dass die Daten von keinen Anwendungen des Hosts manipuliert werden können. Ereignisdaten repräsentieren ein aufgetretenes Ereignis bzw. Event. Bei Events erfolgt eine weitere Unterteilung zwischen dem HSM 110 internen Events bzw. Ereignissen EI und externen Events bzw. Ereignissen EE. Insbesondere interne Events können beispielsweise durch Zähler und einer dazugehörigen ID (bzw. Event-ID, diese spezifiziert den Event-Typ bzw. die Art des Ereignisses) dargestellt werden.
-
In 2 sind hierzu Ereignisdaten-Speicherbereich 140 und ein Logdaten-Speicherbereich 160 schematisch und detaillierter dargestellt. Dabei repräsentiert ein Zählerstand eines Ereignis-Zählers Cnt i einer Zeile 141, wie oft ein bestimmter Ereignistyp aufgetreten ist. Weiterhin wird zu dem Ereignistyp gespeichert, wie oft ein Log-Eintrag, d.h. ein Logdatensatz zu diesem Ereignistyp, geschrieben wurde, hier durch einen Logdaten-Zähler bzw. Zählerstand WCnt. Hiermit kann das HSM 110 ermitteln, ob neue Ereignisse dieses Ereignistyps aufgetreten sind und wie viele. Um einen Zeitangabe zu den auftretenden Ereignissen zu erhalten, kann zusätzlich ein Betriebsstunden-Zählerstand bzw. Zähler Upt zum Ereignis gespeichert werden. Interne Ereignisse EI werden vom HSM 110 selbstständig verwaltet, externe Ereignisse EE hingegen können vom HSM 110 nicht verwaltet werden und können daher vom Host 120 verwaltet und/oder dem HSM gemeldet und dort wie interne Ereignisse verwaltet werden.
-
Logdaten in Logdatensätzen beschreiben den erstellten Log-Eintrag und umfassen insbesondere Daten zu den Ereignissen sowie Umgebungsdaten wie z.B. Kilometerstand, Fahrzeugidentifikationsnummer, etc. Diese können individuell nach Kundenanforderungen zusätzlich zu den Ereignisdaten gespeichert werden. Für jeden Ereignistyp (intern wie extern) wird der Logdaten-Speicherbereich 160 als Ringpufferspeicher bereitgestellt, der einen fixen Bereich 161 und einen Ringbereich 162 umfasst, wobei letzterer überschrieben werden kann. Insofern stellt der fixe Bereich 161 einen ersten, nur einmal beschreibbaren Bereich dar, der Ringbereich 162 hingegen einen zweiten, mehrmals beschreibbaren Bereich.
-
In 2 sind für den erwähnten Ereignisdaten-Speicherbereich 140 beispielhaft zwei Ereignistypen mit den IDs 0x07 und 0x02 gezeigt, wobei die vorstehend erwähnten Zähler initial alle auf Null stehen. Für den Logdaten-Speicherbereich ist ein Ringpufferspeicher 160 für beispielhaft nur einen der genannten Ereignistypen (z.B. mit der ID 0x07, bei dem es sich beispielsweise um das Ereignis RTMD, „Runtime Manipulation Detection“ handeln kann) gezeigt, der wiederum mehrere Blöcke von erstem Bereich 161 und zweitem Bereich 162 umfasst. Diese sind initial alle leer. Es versteht sich, dass es für jeden Ereignistyp einen solchen Ringpufferspeicher 160 geben kann.
-
Die erwähnten Umgebungsdaten, die in die Logdatensätze L geschrieben werden, sind dabei nur dem Host 110 bekannt und in 1 im Rahmen eines Umgebungsdatenhandlers 170 gezeigt, der z.B. einen Kilometerstand 171 und eine Fahrzeugidentifikationsnummer 172 ermittelt. Der Host 120 bereitet die Event-Daten als Teil des Logdatensatzes L daher individuell vor und übergibt diese zum Abspeichern dem HSM 110.
-
Initial, d.h. nach der Produktion des Rechensystems 110, sind alle Daten/Einträge genullt oder als leer markiert, wie vorstehend schon erwähnt und auch in 2 angedeutet. Tritt während der Lebenszeit ein (internes) Ereignis EI auf, z. B. eine Manipulation der Host Software (RTMD), verarbeitet der HSM 110 das Ereignis, indem z. B. der Zähler Cnt des Ereignistyps mit der ID 0x07 hochgezählt und der Betriebszählerstand Upt zum Ereignistyp abgespeichert wird. Die Werte dieser beiden Zähler Cnt und Upt für diese ID 0x07 würden dann z.B. von Null auf Eins geändert.
-
In z.B. einem definierten (Zeit-)Intervall fragt der Host 120 beim HSM 120 nach neuen (internen) Ereignissen EI an. Der HSM 110 bearbeitet die Anfrage und überprüft zunächst, ob neue Ereignisse aufgetreten sind, z. B. indem der Zähler WCnt bzw. dessen Zählerstand, mit dem die Anzahl der geschriebenen Logdatensätze zu einem bestimmten Ereignistyp gezählt werden, mit dem Zählerstand des Ereigniszählers Cnt verglichen werden. Hierbei wird bestimmt, wie viele Ereignisse mit gleicher ID (also dieses Ereignistyps) angefallen sind, indem z. B. der Zählerstand WCnt vom Zählerstand des Cnt abgezogen wird. Nachdem der HSM 110 bestimmt hat, wie viele Ereignisse des jeweiligen Ereignistyps angefallen sind, überträgt er die Daten hierzu an den Host 120.
-
Der Host 120 bereitet die Daten der Events in z.B. einer Einheit 181 dann für das kundenspezifische Format auf und fügt ihnen die Umgebungsdaten, z.B. Kilometerstand 171 und Fahrzeugidentifikationsnummer 172 hinzu, um aus ihnen einen Logdatensatz L zu generieren. Dann übergibt der Host 120 den Logdatensatz L an den HSM 110, um einen Log-Eintrag in seinem Logdatenspeicher 150 zu hinterlegen bzw. zu speichern.
-
Um sicherzustellen, dass kein falscher (oder Fake-) Log-Eintrag geschrieben wird, um z. B. ein Element bzw. einen zu überschreiben, muss der HSM im Fall eines internen Ereignisses prüfen, ob überhaupt neue Ereignisse zu dem Log-Eintrag existieren. Andernfalls wird der HSM 110 den Logdatensatz vom Host 120 ablehnen. Um externe Ereignisse EE, die z.B. von der Einheit 182 ermittelt werden, abzusichern, müssen die IDs der externen Ereignisse z. B. über Konfiguration dem HSM 110 bekannt gemacht werden. Hier werden dann alle nicht definierten IDs abgelehnt.
-
Wenn der erste Bereich 161 und der zweite Bereich 162 eines Ereignistyps im Logdaten-Speicherbereich 156 über- bzw. geschrieben wurden und ein neuer Log-Eintrag akzeptiert und geschrieben werden soll, wird der erste Eintrag bzw. Block des zweiten Bereichs 162 überschrieben. So wird sichergestellt, dass ein Angreifer den ersten Bereich 161 nicht überschreiben kann und damit schon gespeicherte Log-Einträge nicht verloren gehen.
