Verfahren und Prozessorschaltung zum Absichern eines Codes gegen Manipulationen einer Anwendungssoftware, sowie Kraftfahrzeug-Steuergerät und Kraftfahrzeug mit einem solchen Steuergerät

Die Erfindung betrifft ein Verfahren und eine Prozessorschaltung zum Absichern eines Codes gegen Manipulationen einer Anwendungssoftware bei Ausführung in einer Prozessorschaltung. Wenn der Code nach einer Manipulation in der Prozessorschaltung gestartet wird, wird eine Selbstblockade der Prozessorschaltung ausgelöst, um eine Ausführung eines Schadcodes zu verhindern. Die Erfindung umfasst auch ein Kraftfahrzeug-Steuergerät, welches eine entsprechend eingerichtete Prozessorschaltung aufweist, sowie Kraftfahrzeug mit zumindest einem solchen Steuergerät.

Um die Integrität oder Authentizität eines Programmcodes zu überprüfen, können kryptographische Hashverfahren eingesetzt werden, und der resultierende Ist- Hashwert mit einem erwarteten Referenzhashwert verglichen werden. Bei Übereinstimmung lässt man die Ausführung des Programmcodes zu, im anderen Fall nicht, da man von nicht-authentischem Code ausgehen muss, was durch einen Angriff erfolgt sein kann. Diese Überprüfung findet typischerweise durch einen besonders gesicherten Bootloader statt, die Speicherung des erwarteten Hashwertes erfolgt in einem besonders gesicherten Teil der Hardware, einem Hardware Security Module, HSM, das Verfahren ist als „Secure-Boot“ bekannt.

Für ein Steuergerät eines Kraftfahrzeugs kann beim Starten oder Aktivieren ein solches Secure Boot Verfahren vorgesehen sein, das die Authentisierung von auszuführendem Code in einer Applikations-CPU durch ein Hardware Security Module (HSM) vorsieht, bevor dieser Code ausgeführt wird (Prinzip „verify before execute“). Fig. 3 veranschaulicht dieses Secure Boot Verfahren. Die Authentizität wird dabei mit Hilfe des kryptographischen Hashverfahrens (mit oder ohne kryptographischem Schlüssel / Key) in der Weise sichergestellt, dass der zur Ausführung anstehende Programmcode der Anwendungssoftware (Anwendungscode - Application Code, AC1 ) als Eingang für ein solches Hashverfahren dient. Beispiele für verfügbare Hashverfahren sind AES-CMAC und SHA-HMAC.

Nachdem das Ergebnis h1 vorliegt, wird dieses mit dem erwarteten Ergebnis H1 , welches im HSM gesichert vorliegt, verglichen. Bei Übereinstimmung gilt der Anwendungscode AC1 als authentisch und wird vom HSM zur Ausführung freigegeben. Der Vergleich des tatsächlich vorliegenden Hashwertes h1 mit dem manipulationssicher im HSM gespeicherten erwarteten Wert H1 liefert somit eine Aussage, ob der zugrundeliegende Code authentisch und integer ist (1 ), oder nicht (0), für beide Ergebnisse wird die Laufzeit AT benötigt, was einer Verzögerung des Starts des Codes in der CPU bedeutet.

Das Hardware Security Module, HSM, ist vor Manipulationen besonders geschützt. So wird dessen boot code aus einem nur einmal beschreibbaren Speicher ausgeführt (= Bootloader), bevor jedweder Code der Applikationssoftware ausgeführt werden kann. Erst wenn der applikationsseitige Anwendungscode AC1 (hier auch in Kurzform als „Code“ bezeichnet) auf Authentizität und Integrität überprüft wurde (verify), wird ist dieser zur Ausführung freigegeben (enable).

Typischerweise gibt es in einem Code mehrere Applikations-Codeblöcke (AC1 , AC2, ... ) mit jeweils unterschiedlichen Anforderungen an deren zeitliche Verfügbarkeit, so dass die ersten verifizierten Codeblöcke meist die mit den kürzesten Zeitanforderungen für das Aktivieren oder Starten sind. Grundsätzlich entsteht somit eine Wartesituation für verschiedene Applikations-Codeblöcke, was im Hinblick auf die Forderung nach Einhaltung maximaler Startzeiten kritisch ist. Eine Startzeit kann zum Beispiel dann kritisch sein, wenn es sich bei dem Steuergerät um eine Steuerung handelt, die mittels Taste durch einen Benutzer aktiviert wird. Betätigt der Benutzer die Taste, so erwartet er in der Regel, dass innerhalb von 50 Millisekunden eine Reaktion des Steuergeräts eintritt. Ein Beispiel für solche Steuergeräte sind jeweils: ein Fensterheber, ein Schiebedach, eine Sitzverstellung. Um im deaktivierten Zustand Energie zu sparen, kann das Steuergerät beispielsweise stromlos geschaltet sein. Wird dann die Taste betätigt, muss in dem Steuergerät dessen Prozessorschaltung, beispielsweise ein Mikrocontroller, starten oder booten und dann innerhalb der maximalen Startzeit, also beispielsweise innerhalb von 50 Millisekunden, den Anwendungscode, beispielsweise das Ansteuern des Motors für den Fensterheber, ausführen. Durch die zusätzliche Verifizierung („verify before execute“) verzögert sich der Start oder das Booten um die besagte Zeitdauer AT. Hierdurch bleibt weniger Zeit für die eigentliche Startfunktion oder Bootfunktion des Anwendungscodes selbst.

Der Erfindung liegt die Aufgabe zugrunde, eine reaktionsschnelle Prozessorschaltung bereitzustellen, die dennoch eine Überprüfung des Programmcodes oder Applikationscodes einer Anwendungssoftware ermöglicht.

Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Weiterentwicklungen oder Weiterbildungen der Erfindung sind durch die abhängigen Patentansprüche, die folgende Beschreibung sowie die Figuren beschrieben.

Als eine Lösung umfasst die Erfindung ein Verfahren zum Absichern einer Prozessorschaltung gegen eine Ausführung eines manipulierten Codes einer Anwendungssoftware. Der hier genannte „Code“ kann insbesondere der Binärcode oder Maschinencode sein, der durch eine CPU (central processing unit) der Prozessorschaltung, z.B. eines Mikroprozessors oder eines Mikrocontrollers, auszuführen ist, um die Anwendungsfunktion der Anwendungssoftware bereitzustellen, also beispielsweise das Steuern eines Fensterhebers oder eines Schiebedaches oder eines Sitzmotors. Hier könnte ein Benutzer (Angreifer) der Prozessorschaltung daran interessiert sein, den Code zu manipulieren, um die Anwendungsfunktion zu verändern. Die hier beschriebe Lösung soll vor allem einen Schutz dafür bieten, dass der Code bei deaktivierter Prozessorschaltung manipuliert wird, indem beispielsweise ein Flash-Speicher, in welchem der Code nicht-flüchtig gespeichert ist, verändert wird. Wird dann die Prozessorschaltung in Betrieb gesetzt oder aktiviert, würde ein Programmzähler der Prozessorschaltung entsprechend die Steuerbefehle oder Maschinenbefehle des manipulierten Codes einlesen und so das Ausführen des Codes beginnen.

Um die Prozessorschaltung im Falle einer Manipulation des Codes selbstblockierend auszugestalten, umfasst die Erfindung, dass in dem Code ein sogenanntes Nonce bereitgestellt wird, welches in Kombination mit dem übrigen, unmanipulierten Code bei Anwenden einer Hashfunktion auf den Code einen Hashwert ergibt, der ein vorbestimmtes Soll-Muster aufweist. Ein „Nonce“ stellt hier eine Bitfolge oder Bytefolge dar, die zusätzlich zum eigentlichen Anwendungsfunktionalität in den Code eingefügt ist, damit hierdurch Einfluss auf das Resultat oder den Hashwert der Hashfunktion genommen wird, ohne dass hierzu der übrige Code, der die eigentliche Anwendungsfunktionalität bereitstellt, verändert werden müsste. Es handelt sich also um ein Datum, das für die eigentliche Anwendungssoftware selbst nicht verwendet wird. Durch Verändern des Werts des Nonce kann aber der durch die Hashfunktion gebildete Hashwert verändert oder eingestellt werden, ohne dass der übrige Code verändert werden muss, also derjenige Teil des Codes, der die Anwendungsfunktion bildet oder erzeugt. Der Begriff „Nonce“ ist aus dem Bereich der Kryptowährungen bekannt, wo zu einem Datenblock ein solches Nonce hinzugefügt wird, um einen Hashwert des Datenblocks dahingehend zu manipulieren, dass er ein vollbestimmtes Soll- Muster, beispielsweise eine vorgegebene Anzahl an führenden Nullen im Hashwert, ergibt. Im Zusammenhang mit dem hier beschriebenen Hashwert ist der Begriff „Muster“ des Hashwerts dahingehend zu verstehen, dass es sich auf nur einen Teil des Hashwerts bezieht (z.B. 32 von insgesamt 256 Bits des Hashwerts) und für diesen Teil eine Vorgabe in Bezug auf die Bitfolge oder den Zahlenwert dieses Teils bezieht. Wird also beispielsweise ein Soll-Muster vorgegeben, so kann der ursprüngliche unmanipulierte Code verwendet werden und in diesen noch das Nonce eingefügt werden und dann die Hashfunktion über dieser Kombination ausgeführt werden. Ergibt der Hashwert nicht das Soll-Muster, so kann nach dem Prinzip Trial-and-Error der Nonce so oft wiederholt verändert werden, bis die Kombination aus dem übrigen, unmanipulierten Code und dem Nonce den Hashwert mit dem vorgegebenen Soll-Muster ergibt. Der übrige Teil des Hashwerts kann dabei beliebig ausfallen.

Zum Starten der Ausführung des Codes ist vorgesehen, dass eine codeinterne oder codeexterne Startfunktion auf den Code mit dem darin integrierten Nonce die Hashfunktion anwendet, um so den aktuellen Hashwert des zu prüfenden Codes zu berechnen, wobei der aktuelle Hashwert ein Ist-Muster ergibt. Die Ausführung des Codes wird dann in Abhängigkeit von dem Ist-Muster gesteuert. Mit dem Begriff „codeintern“ ist hierbei gemeint, dass die Anwendungssoftware selbst die Startfunktion umfasst, also die Anwendungssoftware einen Code aufweist, der zunächst sich selbst in Bezug auf den Hashwert überprüft. Dagegen ist eine „codeexterne“ Startfunktion eine Startfunktion, die in der Prozessorschaltung zunächst ausgeführt wird und welche darüber entscheidet, ob oder an welcher Startadresse der eigentliche Code der Anwendungssoftware gestartet oder begonnen werden soll. Es kann sich hierbei beispielsweise um eine Ladefunktion eines Betriebssystems der Prozessorschaltung handeln. Für den Fall, dass der Code manipuliert wurde, also nicht mehr den unmanipulierten Zustand aufweist, ergibt sich ein aktueller Hashwert, dessen resultierendes Ist-Muster von dem Soll- Muster verschieden ist oder zumindest besteht eine ausreichend große Wahrscheinlichkeit für einen solchen Unterschied. Da das Muster nur einen Teil des Hashwerts umfasst, ist theoretisch auch eine Manipulation des Codes möglich, bei welcher sich bei gleichbleibendem Nonce ein Ist-Muster ergibt, das mit dem Soll-Muster übereinstimmt, dies ist aber derart unwahrscheinlich, dass hierin ein ausreichend großer Schutz gesehen wird. Der Hashwert kann eine Bitsequenz aus mehreren Bits sein (z.B. 256 Bits oder 512 Bits) und das Soll- Muster und das Ist-Muster stellen jeweils nur eine Teilmenge dieser mehreren Bits dar, beispielsweise eine Teilmenge umfassend 8 Bits bis 64 Bit, um nur Beispiele zu nennen. Zu beachten ist hier, dass in der Startfunktion kein Vergleich mit einem vollständigen Referenz-Hashwert erfolgen muss. Zudem kann das Soll-Muster unabhängig von dem übrigen, unmanipulierten Code vorgegeben sein. Z.B. kann als Soll-Muster vorgegeben werden, dass sich eine bestimmte Anzahl von führenden Nullen ergeben muss. In dem Hashwert des Codes wird mittels des Nonce das Soll-Muster eingestellt oder der Hashwert wird an dieses angepasst.

In vorteilhafter Weise muss kein Vergleich mit einem vollständigen Referenz- Hashwert vorgenommen werden, das heißt im Code muss auch kein Referenz- Hashwert gespeichert sein. Ansonsten könnte der Speicher derart manipuliert werden, dass sowohl der Code selbst, also die Anwendungsfunktionalität, als auch der Referenz-Hashwert im Speicher entsprechend angepasst oder manipuliert würde, damit manipulierter Code und manipulierter Referenz-Hashwert wieder zusammenpassen, ohne dass das Nonce neu ermittelt werden müsste. Hierdurch wäre dann die Manipulation kaschierbar. Kann stattdessen nur der Code manipuliert werden (mangels Referenz-Hashwert) und ist ein allgemeingültiges Soll-Muster für den Ist-Hashwert vorgegeben (z.B. eine bestimmte Anzahl führender Nullen), so muss nach einer Codemanipulation ein passendes Nonce gefunden werden, was in der beschriebenen Weise einen entsprechenden Aufwand für das Trial-and-Error-Suchverfahren zum Suchen eines passenden Nonce erfordert. Dies erschwert somit in vorteilhafter Weise das Manipulieren des Codes.

Die Erfindung umfasst auch Weiterentwicklungen oder Weiterbildungen, durch die sich zusätzliche Vorteile ergeben.

Um zu verhindern, dass der aktuelle Hashwert mit seinem Ist-Muster nicht ebenfalls einfach mit einem vorgegebenen Soll-Muster verglichen werden muss und damit durch Manipulieren des Speicherinhalts, der das Soll-Muster beschreibt, ebenfalls die Manipulation insgesamt kaschiert werden könnte, hat es sich als vorteilhaft erwiesen, das Ist-Muster zum Steuern des Ablaufs des Codes selbst dahingehend zu nutzen, dass kein Vergleich mit dem Soll-Muster stattfinden braucht, sondern das Ist-Muster als Steuersignal für den Ablauf des Codes an sich genutzt wird. Es gibt also kein „falsches“ Ist-Muster, sondern der Code nimmt nur unterschiedliche Verläufe, je nach Ist-Muster. Eine Weiterentwicklung umfasst hierzu, dass die Startfunktion in Abhängigkeit von dem Ist-Muster ein Einsprungziel oder Sprungziel oder einen Funktionsaufruf in dem Code auswählt und das Ausführen des Codes durch einen Sprung zu dem Einsprungziel oder den Funktionsaufruf beginnt oder fortsetzt. Man kann also dem Code nicht „ansehen“, welches Ist-Muster das „richtige“ ist, um die Anwendungssoftware bestimmungsgemäß ablaufen zu lassen, also die Anwendungsfunktionalität auszulösen. Vielmehr ist die Startfunktion derart ausgestaltet, dass der Code an der Stelle ausgeführt wird, auf die durch das Ist-Muster verwiesen wird. Beispielsweise kann ein Programmzähler der CPU eines Mikroprozessors oder Mikrocontrollers gemäß dem Ist-Muster eingestellt werden. Es kann dabei entweder das Ist-Muster direkt als Sprungadresse in einen Speicherbereich, in welchem sich der Code befindet oder in welchem er abgelegt ist, interpretiert werden oder es kann das Ist-Muster indirekt mittels einer vorbestimmten Abbildungsfunktion in eine Speicheradresse oder Sprungadresse umgewandelt werden. Stimmt dann das Ist-Muster nicht mit dem Soll-Muster überein, erfolgt ein Einsprung in den Code an einer falschen oder ungeeigneten Stelle und es kommt nicht zu einem erfolgreichen Ausführen des Codes. Hier liegt die Erkenntnis zugrunde, dass für den Fall, dass man versucht, den Code zu manipulieren, dem Code in binärer Form (Binärcode) nicht anzusehen ist, welche Bitmuster gültige Einsprungadressen darstellen, dies würde zunächst ein aufwendiges Reverse- Engineering erfordern, was die Hürde für eine erfolgreiche Manipulation entsprechend hoch oder höher setzt.

Allerdings ist man daran interessiert, dass durch ein falsches Einsprungziel, wenn also das Ist-Muster nicht mit dem Soll-Muster übereinstimmt, hierdurch nicht ein unbeabsichtigtes Verhalten der Prozessortschaltung resultiert. Eine Weiterentwicklung umfasst hierzu, dass die Startfunktion eine Sprungtabelle vorsieht oder nutzt, in welcher mehrere mögliche Sprungadressen einem jeweiligen Tabellenindex zugeordnet sind, und die Startfunktion mittels des Ist- Musters einen Tabellenindex auswählt und die dem ausgewählten Tabellenindex zugeordnete Sprungadresse als Einsprungziel festlegt. Das Soll-Muster entspricht natürlich demjenigen Tabellenindex, dem die Startadresse einer Bootfunktion oder Haupt-Funktion (main function) der Anwendungssoftware zugeordnet ist. Eine Sprungtabelle kann eine Liste oder Aneinanderreihung von mehreren möglichen oder vorgesehenen Sprungadressen enthalten. Es können die Funktionsadressen direkt nacheinander angeordnet sein, wodurch sich der entsprechende Tabellenindex implizit als Offset ergibt. Alternativ kann eine paarweise Zuordnung eines Tabellenindex zu einer entsprechenden Sprungadresse vorgesehen sein, wodurch mögliche Ist-Muster als jeweiliger Tabellenindex explizit angegeben werden können. Das Ist-Muster kann also als Tabellenindex direkt genutzt werden oder es kann eine Abbildungsfunktion zwischengeschaltet sein, die das Ist-Muster auf einen Tabellenindex abbildet. Ist das Ist-Muster mit dem Soll-Muster identisch, so ergibt sich als Auswahl die Startadresse der Bootfunktion der Anwendungssoftware, das heißt die Anwendungssoftware wird in diesem Fall korrekt oder bestimmungsgemäß gestartet. Jede andere Sprungadresse in der Sprungtabelle kann dagegen von dieser Startadresse der Bootfunktion wegweisen oder von dieser verschieden sein.

Eine Weiterentwicklung umfasst hierzu, dass auch bei falschem Ist-Muster ein kontrollierter Sprung erfolgt. Die Sprungtabelle enthält dazu an zumindest einem übrigen, von dem Soll-Muster verschiedenen Tabellenindex eine Sprungadresse zu einer Endlosschleife und/oder zu einer Signalisierungsfunktion zum Signalisieren einer Codemanipulation. Indem die Prozessorschaltung oder das Ausführen des Codes in einer Endlosschleife gehalten wird, insbesondere in einer Endlosschleife ohne zusätzliche Funktionsausführung (auch als „Idling“ bezeichnet) bleibt die Prozessorschaltung funktionslos, nachdem das Ist-Muster in die Endlosschleife geführt hat. Somit ist sichergestellt, dass keine unerwünschte oder unvorhergesehene Signalerzeugung durch die Prozessorschaltung erfolgt. Wird vor dem Eintritt in die Endlosschleife oder alternativ dazu zu einer Signalisierungsfunktion geführt oder zu dieser gesprungen, so kann zum Signalisieren der Codemanipulation beispielsweise ein Fehlereintrag in einem Fehlerspeicher erzeugt werden. Somit kann auch im Nachhinein erkannt werden, dass der Code im manipulierten Zustand gestartet wurde oder versucht wurde, ihn auszuführen. Dies kann zum Beispiel als Nachweis im Zusammenhang mit einer Garantiefrage genutzt werden.

Bisher wurde beschrieben, dass die Hashfunktion den aktuellen Hashwert auf der Grundlage des Codes (mit dem darin integrierten Nonce) erzeugt. Mit entsprechendem Aufwand könnte eine Manipulation dahingehend versucht werden, dass eine Kopie des Codes (zusammen mit dem Nonce) beschafft wird und vor einer Manipulation der Hashwert berechnet wird, um nach der Manipulation zu wissen, wie zusätzlich auch das Nonce verändert werden müsste (falls man dessen Position im Code kennt), um die Manipulation zu kaschieren. Dies kann zusätzlich in folgender Weise erschwert werden.

Eine Weiterentwicklung umfasst, dass die Hashfunktion eine kryptographische Hashfunktion ist, die den Hashwert aus einer Kombination aus dem Code und einem kryptographischen Schlüssel der Prozessorschaltung bildet. Bei der Hashfunktion ist somit der resultierende oder sich ergebende Hashwert auch zusätzlich abhängig von dem kryptographischen Schlüssel, also einer weiteren Bitfolge oder Ziffernfolge, die für eine erfolgreiche Manipulation bekannt sein muss. Dieser Schlüssel kann der Prozessorschaltung zugeordnet sein, beispielsweise in einem Register der Prozessorschaltung gespeichert sein. Ist der Schlüssel unbekannt, so nützt die Kenntnis des ursprünglichen Hashwerts mit dem Soll-Muster und die Kenntnis des Nonce nichts oder reicht nicht aus, um eine Manipulation durch Anpassen des Nonce zu kaschieren.

Allerdings kann versucht werden, aus der Prozessorschaltung auch einen solchen kryptographischen Schlüssel auszulesen. Eine Weiterentwicklung umfasst deshalb, dass der kryptographische Schlüssel zur Laufzeit der Startfunktion aus einem Sicherheitsmodul der Prozessorschaltung empfangen wird. Mit anderen Worten ist der kryptographische Schlüssel im deaktivierten oder abgeschalteten Zustand der Prozessorschaltung nicht auslesbar oder unerreichbar. Wird die Prozessorschaltung gestartet, so wird der kryptographische Schlüssel zur Laufzeit an die Startfunktion übergeben, sodass nur in demjenigen Zeitraum, während der kryptographische Schlüssel an die Startfunktion als Eingabeparameter übergeben wird, dieser Schlüssel sichtbar ist. Zu einem solchen Zeitpunkt muss aber die Prozessorschaltung laufen, was einen Zustand darstellt, der sich im RAM (Random Access Memory) der Prozessorschaltung abspielt und in der Regel um ein Vielfaches aufwändiger zu beobachten oder auszuspionieren ist als der nichtflüchtige Speicher einer deaktivierten oder abgeschalteten Prozessorschaltung. Somit wird das Manipulieren des Codes zusätzlich erschwert.

Eine Weiterentwicklung umfasst, dass durch die Hashfunktion der Hashwert mittels eines HMAC-Verfahrens (Hash-based Message Authentication Code) ermittelt wird. Die Hashfunktion bietet die Möglichkeit der Kombination aus einer Berechnung des Hashwerts aus dem Code an sich sowie eines zusätzlichen kryptographischen Schlüssels. Die RFC 2104 (RFC - Request for Comment Dokument) definiert eine kryptographische Hashfunktion für gängige Hashing- Algorithmen, wie dem SHA2 oder SHA3 als Hash-Funktion. Ein Hashwert ist damit ein für alle praktischen Fälle eindeutiger Fingerabdruck einer Nachricht MSG, der einen geheimen Key verwendet, um die Authentizität einer Nachricht zu sichern.

Eine Weiterentwicklung umfasst, dass durch die Hashfunktion der Hashwert mittels eines CMAC-Verfahrens (Cipher-based Message Authentication Code) ermittelt wird, welches einen symmetrischen Blockcipher-Algorithmus verwendet (z.B. AES, SIMECK). Bei CMAC wird eine Blockchiffre (BC) eingesetzt, um die allgemeine Forderung nach Kollisionssicherheit und der Eigenschaft als Einwegfunktion zu erfüllen. Ein besonderer Vorteil eines CMAC ist, dass es als Hardware-Implementierung (also Software-unabhängig beispielsweise als FPGA oder ASIC (Application Specific Integrated Circuit) verfügbar ist. Dies ist insbesondere bei Mikrocontrollern der Fall, die für Steuergeräte insbesondere für Kraftfahrzeuge verfügbar sind. Ein AES-basierter CMAC Algorithmus ist in ein Hardware-Security-Module, HSM, integriert und mit Hardware-beschleunigung implementiert, was in vorteilhafter Weise dazu beiträgt, die beschriebene Zeitdauer AT für die CMAC Berechnung für einen Applikations-Codeblock zu minimieren (die „Message“ MSG für den CMAC ist hierbei der Code AC der Anwendungssoftware). Häufig wird dabei der AES128 Algorithmus verwendet, der schon in der Automotive-Industrie im Rahmen der EVITA Initiative als Standard für Secure Boot spezifiziert wurde. Heute findet man SHE Module (SHE = Security Hardware Extension) nach dem EVITA-Light Standard (-Light, -Medium, -Full) sogar in kleineren Mikrocontrollern integriert, während man die Unterstützung der Hashing-Algorithmen und der asymmetrischen Verschlüsselungsverfahren nur bei größeren Mikrocontrollern unter dem Begriff HSM oder HSE findet.

Eine Weiterentwicklung umfasst, dass die Startfunktion als ein Bestandteil einer Parallel-Boot-Prozedur ausgeführt wird. Das Verfahren steht somit der eingangs beschriebenen Parallel-Boot-Prozedur nicht entgegen, sondern kann in diese integriert werden.

Die Parallel-Boot-Prozedur umfasst, dass die Startfunktion in einer CPU eines Mikroprozessors oder eines Mikrocontrollers der Prozessorschaltung ausgeführt wird, wo auch der Code auszuführen ist, und währenddessen in einem Hardware- Security-Module, HSM, der Prozessorschaltung (hardwarebasiertes Sicherheitsmodul) mittels einer weiteren Hashfunktion ein weiterer Hashwert des Codes berechnet und vollständig mit einem vorgegeben Referenz-Hashwert (nicht nur einem Muster) verglichen wird. Falls erkannt wird, dass der weitere Hashwert von dem Referenz-Hashwert verschieden ist, wird durch das HSM mittels eines Blockiersignals eine weitere Ausführung des Codes blockiert. Durch die beschriebene Steuerung des Ablaufs des Codes der Anwendungssoftware in Abhängigkeit von dem Ist-Muster oder durch das Ist-Muster wird erreicht, dass der Start des Codes selbstblockierend ausgestaltet ist, falls der Code manipuliert wurde. Sollte aber die Manipulation erfolgreich kaschiert werden können, so kann im Nachhinein durch die Überprüfung im HSM nach Ablauf der Zeitdauer AT dennoch eine Manipulation erkannt werden und dann mittels des Blockiersignals zumindest die weitere Ausführung des Codes blockiert werden. Das Blockiersignal kann beispielsweise ein Reset-Signal sein, welches die Prozessorschaltung durch einen Reset neu startet. Alternativ dazu kann durch das Blockiersignal ein Programmzähler der Prozessorschaltung angehalten werden, was ein weiteres Beispiel für ein wirkungsvolles Blockieren der Ausführung des Codes darstellt. Als eine weitere Lösung umfasst die Erfindung eine Prozessorschaltung, in welcher ein Code einer Software zum Ausführen gespeichert ist, wobei die Prozessorschaltung zum Absichern des Codes gegen eine Ausführung nach einer Manipulation dazu angepasst ist, eine Ausführungsform des beschriebenen Verfahrens durchzuführen. Die Prozessorschaltung kann insbesondere als ein Mikrocontroller ausgestaltet sein, wie er für ein Steuergerät eines Kraftfahrzeugs vorgesehen sein kann. In einer solchen Prozessorschaltung kann zum einen die CPU (Central Processing Unit) für das Ausführen des Codes der Anwendungssoftware vorgesehen sein. Zusätzlich kann in der beschriebenen Weise ein Hardware-Security-Module, HSM, in einem solchen Mikroprozessor bereitgestellt sein. In dem HSM kann in an sich bekannter Weise ein kryptographischer Schlüssel gespeichert sein, der zudem individuell für die Prozessorschaltung ausgelegt oder erzeugt sein kann. Zudem kann in der HSM ein Referenz-Hashwert oder Soll-Hashwert gespeichert sein, welcher als Vergleichsgrundlage für den Vergleich mit dem Ist-Hashwert oder dem aktuellen Hashwert des Codes zugrundegelegt werden kann. Unabhängig davon kann in der CPU der Prozessorschaltung selbst, die auch für das Ausführen des Codes der Anwendungssoftware genutzt wird, vorab in der beschriebenen Weise anhand des Ist-Musters das Ablaufen des Codes gesteuert werden, sodass hierdurch noch vor Ablauf der Prüfung des Hashwerts durch das HSM erkannt werden kann, ob der Code manipuliert wurde. Die CPU kann eine CMAC oder HMAC schneller ausführen als ein HSM, sodass sich keine Verzögerung von AT ergibt.

Als eine weitere Lösung umfasst die Erfindung ein Steuergerät für ein Kraftfahrzeug, wobei das Steuergerät eine Ausführungsform der beschriebenen Prozessorschaltung umfasst. Das Steuergerät kann beispielsweise in an sich bekannter Weise zum Steuern einer Fahrzeugkomponente, beispielsweise eines Aktors oder eines Sensors oder zum Bereitstellen einer Fahrzeugfunktionalität, wie beispielsweise das Ausgeben eines Audiosignals oder Videosignals, vorgesehen sein. Beispiele für Steuergeräte sind: ein Fensterheber, eine Schiebedachsteuerung, eine Sitzstellung, ein Kombiinstrument, ein Motorsteuergerät, eine Zentralverriegelung, um nur Beispiele zu nennen. Insbesondere handelt es sich um ein Steuergerät, das deaktiviert gehalten wird (Programmzähler steht still oder ist angehalten), und bei Betätigen einer Taste oder allgemein eines Bedienelements durch einen Benutzer wird die Prozessorschaltung gebootet. Die hier genannte Fahrzeugfunktionalität entspricht der bereits beschriebenen allgemeinen Applikationsfunktionalität.

Als eine weitere Lösung umfasst die Erfindung ein Kraftfahrzeug mit zumindest einem Steuergerät, das eine jeweilige Ausführungsform des beschriebenen Steuergeräts darstellt. Das Kraftfahrzeug kann beispielsweise als Personenkraftwagen oder Lastkraftwagen oder Motorrad oder Flurförderfahrzeug ausgestaltet sein.

Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Weiterbildungen.

Im Folgenden ist ein Ausführungsbeispiel der Erfindung beschrieben. Hierzu zeigt:

Fig. 1 eine schematische Darstellung einer Ausführungsform des erfindungsgemäßen Kraftfahrzeugs;

Fig. 2 eine schematische Darstellung einer Prozessorschaltung, wie sie in einem Steuergerät des Kraftfahrzeugs von Fig. 1 bereitgestellt sein kann;

Fig. 3 ein Diagramm zur Veranschaulichung eines Secure-Boot-Verfahrens.

Bei dem im Folgenden erläuterten Ausführungsbeispiel handelt es sich um eine bevorzugte Ausführungsform der Erfindung. Bei dem Ausführungsbeispiel stellen die beschriebenen Komponenten der Ausführungsform jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden und damit auch einzeln oder in einer anderen als der gezeigten Kombination als Bestandteil der Erfindung anzusehen sind. Des Weiteren ist die beschriebene Ausführungsform auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar. In den Figuren sind funktionsgleiche Elemente jeweils mit denselben Bezugszeichen versehen.

Fig. 1 zeigt ein Kraftfahrzeug 10, bei dem es sich beispielsweise um einen Kraftwagen handeln kann, der beispielsweise als Personenkraftwagen oder Lastkraftwagen ausgestaltet sein kann. In dem Kraftfahrzeug 10 kann sich ein Steuergerät 11 befinden, das eine Fahrzeugkomponente 12 steuern kann. Die Fahrzeugkomponente 12 kann beispielsweise ein Aktor sein, beispielsweise ein Elektromotor, und/oder sie kann ein Sensor sein, beispielsweise ein Temperatursensor. Wie bereits beschrieben, kann es sich bei der Fahrzeugkomponente 12 beispielsweise um einen Fensterheber oder ein Schiebedach oder eine Schließanlage des Kraftfahrzeugs 10 handeln, um nur Beispiele zu nennen.

Zum Erzeugen von Steuersignalen 13 kann in dem Steuergerät 11 eine Prozessorschaltung 14 bereitgestellt sein, die die Steuersignale 13 gemäß einer Anwendungsfunktionalität 15 erzeugen kann, die durch eine Anwendungssoftware AC1 festgelegt oder erzeugt sein kann. Die Anwendungssoftware AC1 kann hierzu einen Programmcode oder kurz Code 16 umfassen, der in einem nicht-flüchtigen Datenspeicher 17, beispielsweise einem Flash-Speicher, in der Prozessorschaltung 14 gespeichert sein kann. Um die Anwendungsfunktionalität 15 auszulösen oder zu starten, beispielsweise bei einem Fensterheber das Öffnen oder Schließen eines Fensters zu starten, kann ein Bedienelement 18 bereitgestellt sein, das beispielsweise eine Taste oder einen Kippschalter oder eine berührungssensitive Oberfläche aufweisen kann. Wird durch einen Benutzer eine Bedienhandlung 19 an dem Bedienelement 18 ausgeführt (z.B. Drücken einer Taste), so kann hierdurch in dem Steuergerät 11 die Prozessorschaltung 14 dahingehend aktiviert werden, dass die Applikationssoftware gestartet wird und somit der Code AC1 durch die Prozessorschaltung 14 ausgeführt wird, was zum Erzeugen der Steuersignale 13 führt.

Bei dem Kraftfahrzeug 10 und dessen Steuergerät 11 ist vermieden oder zumindest erschwert, dass durch eine Manipulation des Codes AC1 erreicht werden kann, dass unerwünschte oder von einem Hersteller des Steuergeräts 11 unerwünschte oder ungeplante Steuersignale 13 erzeugt werden. Hierdurch kann beispielsweise ein sogenanntes Chip-Tuning erschwert oder blockiert werden.

Fig. 2 veranschaulicht, wie in der Prozessorschaltung 14 der Code 16 der Anwendungssoftware AC1 beim Starten der Ausführung oder des Ausführens des Codes AC1 auf Authentizität oder Echtheit oder Manipulationsfreiheit geprüft werden kann.

Fig. 2 stellt hierzu dar, wie die Prozessorschaltung 14 für das Ausführen des Codes AC1 eine CPU aufweisen kann. Der Code AC1 kann in einen Arbeitsspeicher 20 (RAM) geladen werden, von wo aus er durch die CPU abgearbeitet oder ausgeführt werden kann, wie dies an sich bekannt ist. Es kann auch eine Ausführung aus dem Datenspeicher 17 heraus vorgesehen sein. In dem Code AC1 kann zusätzlich ein Nonce 21 integriert sein, das heißt ein Speicherbereich, in welchem eine Zahl oder Bitfolge gespeichert ist, deren Inhalt verändert werden kann oder nach dem Fertigstellen der Anwendungsfunktionalität 15 hinzugefügt werden kann, ohne die Anwendungsfunktionalität 15 an sich zu verändern. Es kann sich beispielsweise um ein Array aus Bytes handeln.

In der Prozessorschaltung 14 kann zusätzlich zur CPU ein Hardware-basiertes Sicherheitsmodul HSM vorgesehen sein, in welchem in an sich bekannter Weise ein von außerhalb des HSM nicht auslesbarer kryptographischer Prozessorschlüssel 22 (hier dargestellt als Symbol „Key“) gespeichert sein kann. Des Weiteren kann eine Speicherstelle 23 vorgesehen sein, die ebenfalls nichtauslesbar ausgestaltet sein kann, deren Inhalt (hier repräsentiert als C1 ) beim Speichern des Codes AC1 festgelegt werden kann. Es kann sich hierbei um einen Referenz-Hashwert 24 handeln, der für den Code AC1 in dessen unmanipulierten oder werksseitigen Zustand gebildet wurde.

Zum Starten der Ausführung des Codes AC1 kann vorgesehen sein, dass der

Code AC1 in das HSM eingelesen wird, damit (angestoßen durch ein

Verifizierungssignal V der CPU) mittels einer Hashfunktion 25 über den Code AC1 und einen abgeleiteten kryptographischen Schlüssel 26 ein aktueller Hashwert c1 des Codes AC1 zusammen in Kombination mit dem abgeleiteten kryptographischen Schlüssel 26 berechnet wird. Die Hashfunktion 25 kann hierzu ein CMAC-Algorithmus sein. In einem Hashwertvergleich 27 kann überprüft werden, ob der aktuelle Hashwert c1 mit dem Referenz-Hashwert 24 (symbolisiert durch C1 ) übereinstimmt. Ist dies der Fall, so ist kein weiterer Eingriff notwendig, das heißt die CPU kann mit der Ausführung des Codes AC1 fortfahren, das heißt es kann eine Inaktivität 28 des HSM folgen. Stimmen dagegen der aktuelle Hashwert c1 und der Referenz-Hashwert C1 nicht überein, so kann ein Blockiersignal 29 erzeugt werden, welches eine weitere Ausführung des Codes AC1 in der CPU blockiert, z.B. durch einen Reset.

Diese Überprüfung benötigt allerdings eine Zeitdauer AT, die allerdings bei der Prozessorschaltung 14 nicht dazu führt, dass das Ausführen oder der Start der Ausführung des Codes AC1 entsprechend verzögert wird.

Vielmehr ist vorgesehen, dass der abgeleitete kryptographische Schlüssel 26 mittels einer KDF (Key Derivation Function) aus dem Prozessorschlüssel 22 erzeugt oder abgeleitet wird (wofür die KDF beispielsweise eine Hashfunktion sein kann) und der abgeleitete kryptographische Schlüssel 26 auch in der CPU bereitgestellt wird, wo er durch eine Startfunktion 30 empfangen oder genutzt werden kann.

Mittels der Startfunktion 30 kann auf Grundlage einer Hashfunktion 31 , die von der Hashfunktion 25 verschieden sein kann oder mit dieser übereinstimmen kann, aus dem Code AC1 und dem kryptographischen Schlüssel 26 ein aktueller Hashwert berechnet werden, von dem aber lediglich ein Ist-Muster 32 (respräsentiert als pat - pattern) genutzt oder ausgewertet wird, also nur eine Teilmenge der Bits des vollständigen aktuellen Hashwerts. Beispielsweise kann vorgesehen sein, dass das Ist-Muster 32 als eine Sprungadresse 33 (@pat) oder ein Einsprungziel 34 in den Code AC1 interpretiert wird und ein entsprechender Sprung 35 an die Sprungadresse 33 ausgeführt wird (in Fig. 2 symbolisiert durch den Maschinenbefehl Jump: JMP pat). Dies bedeutet, dass beispielsweise der Programmzähler der CPU auf die Sprungadresse 33 im Code AC1 gestellt wird. Von da ausgehend kann dann das Ausführen 36 des Codes AC1 fortgeführt werden.

Das Berechnen der Hashfunktion 31 durch die CPU und der Sprung 35 können in weniger als der Zeitdauer AT erfolgen, während welcher in dem HSM die Berechnung oder Ausführung der Hashfunktion 25 und der Hashwertvergleich 27 durchgeführt werden. Somit kann das Ausführen des Codes AC1 in der CPU bereits begonnen werden, bevor der Hashwertvergleich 27 fertig ausgeführt ist. Ist der Code AC1 manipuliert, so ergibt bei gleichbleibendem oder unverändertem Nonce 21 das Ausführen der Hashfunktion 31 ein Ist-Muster 32, das bei dem Sprung 35 nicht zu der Sprungadresse 33 führt. Die korrekte Sprungadresse 33 / das korrekte Einsprungziel 34 stellt somit ein Soll-Muster dar. Somit ergibt sich eine nicht-funktionsfähige Anwendungssoftware AC1 in der Prozessorschaltung 14 im Falle eines manipulierten Codes AC1 . An der Sprungadresse 33 kann beispielsweise eine Bootfunktion oder Hauptfunktion für die Anwendungssoftware AC1 oder die Anwendungsfunktionalität 15 beginnen.

Insgesamt ergibt sich durch den parallelen vorzeitigen Start an der Sprungadresse 33 und der nachträglichen Verifizierung mittels des Hashwertvergleichs 27 eine Parallel-Boot-Prozedur 40 in der Prozessorschaltung 14.

Fig. 3 veranschaulicht noch einmal, wie ohne die Nutzung der Startfunktion 30 in einer herkömmlichen Prozessorschaltung 50 mittels eines HSM und einer CPU der Start der Ausführung des Codes AC1 durch die CPU erst nach Empfang eines Aktivierungssignals 51 aus dem Hashvergleich 27 (aktueller Hashwert h1 ist identisch zum Referenz-Hashwert H1 ) beginnen kann.

Hierbei kann der Prozessorschlüssel 22 (Key) unmittelbar in der Hashfunktion HMAC verwendet werden, da der Prozessorschlüssel 22 nicht ausgegeben wird an die CPU und somit nie von außen sichtbar ist. In Fig. 2 ist dagegen durch die KDF sichergestellt, dass bei Nutzung des abgeleiteten kryptographischen Schlüssels 26 in der CPU hieraus kein Rückschluss auf den Prozessorschlüssel 22 möglich ist. Die KDF ist hierzu insbesondere eine sogenannte Einwegfunktion, wie es beispielsweise mittels einer Modulo-Operation und/oder einer Hash- Funktion, beispielsweise SHA256, erreicht werden kann.

Die beiden Algorithmen AES bzw. SHA sind ebenfalls Einwegfunktionen und damit nicht umkehrbar, das heißt zur Bestimmung eines gewünschten CMAC oder HMAC müsste man mittels „Durchprobieren“ oder Trial-and-Error (brute-force) selbst mit den größten zur Verfügung stehenden Rechnern extrem lange probieren: Schon bei einem 128 bit CMAC benötigte man dazu im Mittel 2 ¹²⁷ « 10 ³⁸ Versuche. Selbst wenn man pro Versuch nur 1 ps brauchte, würden doch noch mehr als 10 ²⁴ Jahre benötigt, was als praktisch unmöglich gilt. Darauf beruht die kryptographische Stärke der Verfahren.

Wenn man aber nicht den gesamten möglichen Wertebereich des CMAC von 128 bit durchsucht, sondern gerade so viel, wie man durchaus mit vorbestimmten Aufwand noch leisten kann, so kann man sich auf bestimmte CMAC Werte beschränken, welche ein bestimmtes vorgegebenes Muster z.B. in 32 bit des CMAC erreicht wird. Ein solches 32 bit Muster kann im Mittel in 2 10 ⁹ Versuchen ermittelt werden, und zwar offline, keinesfalls in der Prozessorschaltung (also weder in der / CPU noch im HSM).

Um in Echtzeit auf dem Embedded-System nur einen CMAC berechnen zu müssen, wird zunächst die Nachricht MSG, in diesem Fall der Applikationscode AC1 oder AC in eine Anzahl N Blöcke mit gleicher Anzahl Bytes unterteilt:

Man bestimmt einen Codeblock m _x , den man als Nonce (= beliebige, zufällige Bytefolge) verwendet, den man beliebig verändern kann, ohne das Verhalten der Applikation zu beeinflussen, etwa weil m _x Teil eines unbenutzten oder redundanten Speicherbereichs ist. Mit dieser Festlegung kann man eine Suche mit zufälligen Nonce-Werten starten, die einen CMAC (oder HMAC) zum Ergebnis hat, in dem ein bestimmtes Muster (pattern) im Ergebnis zu finden ist.

Diese Mustersuche ist zunächst ähnlich dem „proof-of-work“ Prinzip bei Kryptowährungen, die einen zufällig gewählten Nonce derart erfolgt, dass ein Hashwert (typ. 256 bit) über den Nonce und über Hashwerte zuvor ermittelter Währungseinheiten eine vorgegebene Mindestanzahl von führenden Nullen aufweist (z.B.: 19 Hex-Stellen) und damit als „wertvoll“ im Sinne einer Krypto- währung gilt. Die Mindestanzahl und damit der Schwierigkeitsgrad wird fortlaufend erhöht, so dass das „Schürfen“ von derartigen Kryptowährungen nur mit bekanntermaßen großem und stets steigendem Aufwand an Ressourcen geleistet werden kann.

Ähnlich dazu wird auch in dieser offengelegten Erfindung ein Muster in einem CMAC (oder HMAC) bestimmt, mit dem Ziel ein Muster (pattem pat), mit dem in kurzer Zeit die CMAC Berechnung falsifiziert werden kann, also festgestellt werden kann, ob der Applikationscode NICHT authentisch oder NICHT integer ist (siehe das „0“ Ergebnis in Fig. 2). Damit kann etwa die Applikation oder allgemein eine Startfunktion, unabhängig vom HSM den CMAC (oder HMAC) berechnen, und sicher bestimmen, ob der zugrunde liegende Code AC NICHT authentisch ist: Dies ist möglich ohne explizite Speicherung des erwarteten Werts C (oder H) im Code der Applikation. Ein explizites Speichern eines Referenz-Hashwerts C (oder H) außerhalb des HSM ist aus Gründen der Sicherheit (Security) nicht gewünscht und auch aufwändig zu realisieren, da man den Speicherbereich für den erwarteten Wert C (oder H) von der Berechnung ausnehmen müsste, ähnlich der Signatureinbettung beim PE (Portable Executable) Format.

Gemäß der Idee wird ein somit Verfahren gemäß Fig. 2 vorgeschlagen. Das HSM erreicht eine Nachricht oder eine Signal V, den Applikationscode (AC1 ) zu überprüfen (verify). Das HSM sendet daraufhin einen per kryptographischer Schlüsselableitung (KDF) ermittelten abgeleiteten key an den Applikations- Mikrocontroller CPU, der unmittelbar nach Erhalt des key die Berechnung eines CMAC beginnt, die das Ergebnis c1 mit der vorberechneten Muster-Eigenschaft pat hat. Bei unverändertem, also authentischem Applikationscode AC1 kann diese Eigenschaft verwendet werden, um den Applikations-Code AC1 durch einen berechneten Sprung (JMP pat) auszuführen. Je nach gewähltem Schwierigkeitsgrad bei der Musterberechnung ist die Wahrscheinlichkeit, dass der Applikationscode AC1 NICHT authentisch und integer ist, wenn pat richtig ist, sehr klein.

Gemäß der Idee kann mit dieser -nicht endgültigen Sicherheit- der Applikationscode AC1 ausgeführt werden, während das HSM möglicherweise noch mit anderen Aufträgen beschäftigt ist. Wenn dann im HSM tatsächlich der Auftrag zur Berechnung des CMAC c1 abgearbeitet wird, steht als vorläufiges Ergebnis fest, dass AC1 mit hoher Wahrscheinlichkeit authentisch ist, und schon ausgeführt wird, denn dann wurde das Sprungziel applikationsseitig korrekt berechnet.

Für den Fall, dass der Code nicht authentisch (integer) ist, wird als erste Konsequenz die vorberechnete Eigenschaft pat und damit das Sprungziel falsch sein. Eine vorteilhafte Ausprägung des erfindungsgemäßen Verfahrens kann darin bestehen, alle anderen möglichen Sprungziele als pat durch auf eine endlose Warteschleife zu leiten.

Nachdem das HSM nach einer Zeit bestätigen kann, dass der berechnete CMAC c1 ungleich C1 ist (Ergebnis „0“), kann die Applikations-CPU endgültig deaktiviert werden, etwa durch einen nicht maskierbaren Reset.

Das folgende Beispiel veranschaulicht noch einmal den zusätzlichen Berechnungsaufwand, der für eine Manipulation notwendig wäre. Ein Applikationscode-Datei habe eine Größe von 131072 byte = 8192- 16 byte. Darin enthalten ist ein 16-byte Nonce, der nach (3.1 ) willkürlich durch den ersten Block rm des Applikationscode AC definiert wird. Die Zahl der 16 byte Blöcke beträgt also A/ = 8192. Die Berechnung eines AES128 Blocks benötigt dabei knapp 5 ns (PC). Die Berechnung eines kompletten CMAC benötigt damit auf einem PC

TCMAC ~ 8000 5 ns = 40 ps: c = AES128-CMAC([/T?I = random(), m2, m3, ... m/v], Key)

Als Muster wird der 32 bit Wert pat = 0x04030201 definiert, der auf der Applikations-CPU die Anfangsadresse ist, an dem der Applikationscode nach dem erfindungsgemäßen Verfahren gemäß Bild 2 bei authentischem Code ausgeführt werden soll.

Nach ca. M = 2 10 ⁹ Berechnungen mit jeweils unterschiedlichen Zufallswerten mi = random() erhält man das Ergebnis mit dem definierten Muster pat, wofür man die mittlere Zeit

T _pat = M TCMAC = 2 10 ⁹ ■ 4 10- ⁵ s = 1.2-10 ⁵ s = 22 h benötigt:

Zu jedem beliebigen anderen 32 bit Muster pat ist ein vergleichbarer mittlerer Zeitaufwand auf einem PC notwendig. Auf der Applikationsseite wird zur Erreichung des Ergebnisses nur die Berechnung genau eines CMAC benötigt, unter der Annahme, dass die Applikations-CPU für einen AES Block etwa 2 ps benötigt, gelingt dies in Tc = 8000 2 ps = 16 ms, was für die meisten Echtzeitanwendungen im Fahrzeug hinreichend kurz ist (typische Forderung: maximale Startzeit kleiner 50 ms).

Bemerkenswert ist weiterhin, dass einem möglichen Angreifer die Festlegung der Adresse des Nonce ebenso verborgen bleibt, wie der Key. Somit ist der Aufwand, das erfindungsgemäße Verfahren anzugreifen, sehr viel größer, als die Berechnungszeit T _pa t zur Ermittlung eines Nonce im Sinne des erfindungsgemäßen Verfahrens.

Vorteilsbringende Aspekte der Erfindung sind hierbei insbesondere die folgenden:

1. Verfahren und Einrichtungen welche zur Absicherung von Code, der an beliebiger Stelle einen Nonce (= ausgewählte, zufällige Bytefolge) beinhaltet, einen kryptographischen Hashwert ermitteln, welcher nach dem offengelegten Verfahren ein vordefiniertes Muster aufweist, um die Authentizität einer Applikation zu verifizieren oder zu falsifizieren. Dabei findet kein expliziter Vergleich mit einem erwarteten Hashwert statt, wie bei einem klassischen Signaturverfahren.

2. Verfahren nach Aspekt 1 , welche den Hashwert mittels HMAC Verfahren ermitteln.

3. Verfahren nach Aspekt 1 , welche den Hashwert mittels CMAC Verfahren ermitteln, und dabei einen symmetrischen Blockcipher-Algorithmus verwenden (AES, SIMECK).

4. Verfahren nach Aspekt 1 , welche einen Hashwert mit einer vordefinierten Mustereigenschaft bestimmen, um damit ein berechnetes Sprungziel in vorliegenden Code zu realisieren, welches durch Analyse des Applikationscode nicht ermittelbar ist.

Insgesamt zeigt das Beispiel, wie eine Programmcode-Absicherung bereitgestellt werden kann. Bezugszeichenliste

10 Kraftfahrzeug

11 Steuergerät

12 Fahrzeugkomponente

13 Steuersignale

14 Prozessorschaltung

15 Anwendungsfunktionalität

16 Code

17 Datenspeicher

18 Bedienelement

19 Bedienhandlung

20 Arbeitsspeicher

21 Nonce

22 Prozessorschlüssel

23 Speicherstelle

24 Referenz-Hashwert

25 Hashfunktion

26 Schlüssel

27 Hashvergleich

28 Inaktivität

29 Blockiersignal

30 Startfunktion

31 Hashfunktion

32 Ist-Muster

33 Sprungadresse

34 Einsprungziel

35 Sprung

36 Ausführen

40 Parallel-Boot-Prozedur

50 Prozessorschaltung

51 Aktivierungssignals