-
Die Erfindung bezieht sich auf ein Verfahren zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere „Key BLOBs“, gemäß dem Oberbegriff des Patentanspruches 1 und eine Validierungseinheit zum Steuern des Ladens von IT-Systemen, insbesondere Eingebetteten Systemen, Krypto-Schlüsseln, insbesondere „Key BLOBs“, gemäß dem Oberbegriff des Patentanspruches 10.
-
Ein integrierter kryptographischer Schutz für Komponenten von Informationstechnischen Systemen, so genannten IT-Systemen ist erforderlich, um Angriffe (z.B. Manipulation, Ausspähen etc.) gegen die Informationssicherheit solcher Systeme abzuwehren.
-
Ein IT-System ist ein elektronisch-datenverarbeitendes System, zu dem weil VNA-basierend (beruht auf der Basis einer Von-Neumann-Architektur) z.B. jegliche Art von Verteilten Systemen und Eingebetteten Systemen, aber auch auf einer Harvard-Architektur basierende elektronisch-datenverarbeitende Systeme, einzelne Computer, Großrechner, Hochleistungsrechner etc., teilweise auch Kommunikationssysteme sowie das Internet in seiner Gesamtheit zu zählen sind.
-
Die Implementierung des kryptografischen Schutzes in die genannten IT-Systeme erfolgt bislang überwiegend softwarebasiert. In letzter Zeit kommen aber insbesondere in Eingebetteten Systemen immer mehr leistungsfähigere, hochintegrierte Prozessorsysteme mit Krypto-Hardwareeinheiten, vorzugsweise Krypto-Prozessoren, die als Co-Prozessoren zu in dem Prozessorsystem vorhandenen Haupt-Prozessoren fungieren, oder Krypto-Module, die in den Haupt-Prozessoren integriert sind, zum Einsatz, um die für die Implementierung des kryptografischen Schutzes notwendigen kryptographische Operationen sicherer oder schneller ausführen zu können als dieses bei der softwarebasierten Implementierung der Fall ist.
-
Beispiele für solche Krypto-Hardwareeinheiten sind Trusted Platform Modules (TPMs), z.B. von Infineon® oder Intel®, oder aber Krypto-Prozessoren bzw. Co-Prozessoren, wie das „Cryptographic Acceleration and Assurance“-Modul (CAA-Modul) des „i.MX6“-Prozessorsystems von NXP Semiconductors®.
-
Manche dieser Krypto-Hardwareeinheiten (Krypto-Prozessoren oder Krypto-Module) erlauben das Speichern von geheimen Schlüsseln in ihrem integrierten nicht-flüchtigen Speicher, jedoch ist dieser meist nur für eine sehr kleine Anzahl von Schlüsseln ausreichend. Andere ermöglichen das Ablegen von Schlüsseln in dedizierten, integrierten flüchtigen Schlüsselspeichern. In diesem Fall müssen die Schlüssel extern gespeichert und zur Laufzeit in die Krypto-Hardwareeinheit geladen werden.
-
Um jedoch Schlüssel auch extern, also außerhalb der Krypto-Hardwareeinheit, sicher speichern zu können, werden diese mit einem internen Schlüssel verschlüsselt und extern als sogenannte „Key BLOBs“ oder „Wrapped Keys“ abgelegt. Beim Einlesen wird der „Key BLOB“ entschlüsselt und steht anschließend der Krypto-Hardwareeinheit zur Verfügung.
-
Daraus ergibt sich jedoch das Problem, dass die extern abgelegten „Key BLOBs“ durch veraltete „Key BLOBs“ oder von einem Angreifer generierte „Key BLOBs“ ausgetauscht werden können.
-
So ergibt sich die Möglichkeit für den Angreifer Schlüssel einzubringen, die ihnen beim Angriff auf das IT-System weiterhelfen können, was es zu verhindern gilt.
-
Bisher wurden „Key BLOBs“ eher selten eingesetzt, da es kaum Chips gab, die eine Krypto-Hardwareeinheit respektive einen Krypto-Prozessor bzw. Co-Prozessor oder ein Krypto-Modul hatten, die/der/das es erlaubt, verschlüsselte „Key BLOBs“ zu laden.
-
Eine bekannte Lösung, die einen gewissen Schutz für die Unversehrtheit eines „Key BLOBs“ bietet, wäre „Secure Boot“, bei dem ein „Key BLOB“ zusammen mit einem Betriebssystem-Image signiert und beim Booten verifiziert würde. Jedoch ist es oft so, dass die „Key BLOBs“ spezifisch in Bezug auf das Prozessorsystem sind und daher nicht in einem allgemeinen Image signiert werden können. Sie werden deshalb meist in einer Initialisierungsphase des Prozessorsystems bei der Produktion erstellt. Da zudem für das Prozessorsystem spezifische Firmware-Images meist aus praktischen Gründen nicht möglich sind, muss man die „Key BLOBs“ dann außerhalb des Images ablegen. Dadurch würden sie aber nicht mehr dem Schutz von „Secure Boot“ unterliegen.
-
Daher ist dieser aus bekannten Überlegungen resultierende Lösungsansatz eher schwer umsetzbar. Zusätzlich bietet diese Lösung keinen Schutz gegen Angriffe, die den „Key BLOB“ zur Laufzeit des Prozessorsystems mit der Krypto-Hardwareeinheit austauschen.
-
Es sind aber auch herstellerspezifische Methoden (Vorgehensweisen) bekannt, die einen Austausch von externen „Key BLOBs“ erschweren sollen. So ermöglicht das CAA-Modul (Krypto-Modul) des „i.MX6“-Prozessorsystems zum Beispiel, dass bei der Erzeugung eines „Key BLOBs“ auch ein vom Hersteller gewählter Wert, ein sogenannter „Key Modifier“, ins CAA-Modul geladen wird. Dieser „Key Modifier“ wird getrennt vom „Key BLOB“ gespeichert und sollte sich bei der Aktualisierung des „Key BLOBs“ ebenfalls ändern. Dadurch wird eine Bindung zwischen dem „Key BLOB“ und dem „Key Modifier“ erzeugt. So können zum Beispiel „Key BLOBs“ weder ausgetauscht noch vertauscht werden und sie lassen sich durch eine vom Hersteller getriebene (z.B. initiierte, veranlasste) Änderung des verwendeten „Key Modifier“ revozieren.
-
Die der Erfindung zugrundeliegende Aufgabe besteht darin, ein Verfahren und eine Validierungseinheit zum Steuern des Ladens von IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere „Key BLOBs“, anzugeben, bei dem bzw. bei der ein manipuliertes Laden der Krypto-Schlüssel, insbesondere der „Key BLOBs“, beispielsweise dadurch, dass die extern abgelegten „Key BLOBs“ durch veraltete „Key BLOBs“ oder bei einem Hacker-Angriff auf das System von dem Angreifer (Hacker) generierte „Key BLOBs“ ausgetauscht werden können, womit sich die Möglichkeit für den Angreifer (Hacker) ergibt, Schlüssel einzubringen, die ihm beim weitergehenden Hacker-Angriff auf das System behilflich sind, zu verhindern.
-
Diese Aufgabe wird ausgehend von dem im Oberbegriff des Patentanspruchs 1 definierten Verfahren durch die im Kennzeichen des Patentanspruches 1 angegebenen Merkmale gelöst.
-
Darüber hinaus wird die Aufgabe ausgehend von der im Oberbegriff des Patentanspruchs 10 definierten Validierungseinheit durch die im Kennzeichen des Patentanspruches 10 angegebenen Merkmale gelöst.
-
Die der Erfindung zugrundeliegende Idee gemäß der in den Ansprüchen 1 und 10 jeweils angegebenen technischen Lehre besteht darin, dass zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren und in einer Krypto-Hardwareeinheit ladbaren Krypto-Schlüsseln, insbesondere „Key BLOBs“, der Krypto-Schlüssel vor dem Laden in die Krypto-Hardwareeinheit auf Validität geprüft wird. Die Validitätsprüfung, ob der der Krypto-Schlüssel valide ist, geschieht dabei insbesondere bevor der Krypto-Schlüssel in der Krypto-Hardwareeinheit verwendet und durch eine systemspezifische Anwendungssoftware genutzt wird.
-
Das Kernelement der Erfindung sind dabei gemäß Anspruch 1 ein Validität-Prüfungsverfahren, das dem Ladevorgang des Krypto-Schlüssels, insbesondere des „Key BLOB“, vorgelagert wird, und gemäß dem Anspruch 10 eine Validierungseinheit, die der Krypto-Hardwareeinheit, in die der Krypto-Schlüssel, insbesondere der „Key BLOB“, geladen werden soll, vorgeschaltet ist.
-
Die gemäß dem Anspruch 10 spezifizierte Validierungseinheit, vorzugsweise integraler funktionaler Bestandteil der Krypto-Hardwareeinheit, fungiert dabei als Schnittstelle zu der Krypto-Hardwareeinheit.
-
Die Validierungseinheit kann in vorteilhaften Ausgestaltungen gemäß der Ansprüche 19 und 20 in einem Betriebssystem-Kernel integriert, als signiertes Kernel-Modul implementiert (Anspruch 19) oder als Digitale Schaltung eines „Field Programmable Gate Array“-basierten Schaltkreis, kurz auch FPGA-Schaltkreis genannt, (Anspruch 20) realisiert werden. Dabei soll „Secure Boot“ gegebenenfalls den Betriebssystem-Kernel und/oder den Bitstream des FPGA-Schaltkreises vor Manipulationen schützen. Ein direkter Zugriff auf die Krypto-Hardwareeinheit, vorbei an der Validierungseinheit, soll nicht möglich sein.
-
In einer vorteilhaften Weiterbildung der Erfindung kommen bei der Prüfung auf Validität vorzugsweise sowohl für das Validität-Prüfungsverfahren (Ansprüche 2, 4, 6 und 8) als auch für die Validierungseinheit (Ansprüche 11, 13, 15 und 17) verschiedene Prinzipien (Prüfungsvarianten) in Frage, z.B. die nachfolgenden vier Prüfungsvarianten (I)...(IV).
- (I) Die Prüfung auf Validität erfolgt auf der Basis einer Hashfunktion-Abbildung mit in einer ersten „Positivliste (Whitelist)“ enthaltenen, zu erlaubten Krypto-Schlüsseln (Referenz-Krypto-Schlüsseln), insbesondere erlaubten „Key BLOBs“ (Referenz-„Key BLOBs“), korrespondierenden Referenz-Hash-Werten. Dabei wird durch „Hashen“ von zu ladenden Krypto-Schlüsseln, insbesondere „Key BLOBs“, (Generieren von zu den Krypto-Schlüsseln, insbesondere „Key BLOBs“, korrespondierenden Hash-Werten) und anschließendes Vergleichen dieser Hash-Werte mit den Referenz-Hash-Werten in der „Positivliste (Whitelist)“ die Validität geprüft. Nicht in der „Positivliste (Whitelist)“ vorhandene Krypto-Schlüssel, insbesondere „Key BLOBs“, werden nicht zum Laden an die Krypto-Hardwareeinheit weitergeleitet.
-
Im Fall einer Änderung/einem Austausch, insbesondere einer Krypto-Schlüssel-Aktualisierung, der Krypto-Schlüssel, insbesondere der „Key BLOBs“, muss auch die „Positivliste (Whitelist)“ entsprechend aktualisiert werden (vgl. Ansprüche 3 und 12).
-
Der Vorteil dieser Prüfungsvariante (I) besteht darin, dass die Krypto-Schlüssel, insbesondere „Key BLOBs“, nicht verändert werden müssen. Jedoch müssen die Krypto-Schlüssel, insbesondere „Key BLOBs“, zum Zeitpunkt der Erstellung der „Positivliste (Whitelist)“ bekannt sein, sodass korrespondierende Referenz-Hash-Werte berechnet werden können. Alternativ sind auch Prozessorsystem-spezifische „Positivlisten (Whitelists)“ im Falle von Prozessorsystem-spezifischen Krypto-Schlüsseln, insbesondere „Key BLOBs“, prinzipiell möglich, aber die Implementierung ist sehr aufwändig und daher eher unpraktisch.
- (II) Die Prüfung auf Validität erfolgt auf der Basis der Verifikation einer digitalen Signatur. Dabei werden private Signatur-Schlüssel <„privat keys“>, mit denen Krypto-Schlüssel, insbesondere „Key BLOBs“, z.B. vom Krypto-Schlüssel-Hersteller, signiert worden sind, mit öffentlichen, z.B. in der Validierungseinheit enthaltenen, Verifikation-Schlüsseln <„public keys“>, die zu den privaten Signatur-Schlüsseln korrespondieren und dementsprechende Schlüsselpaare bilden, verifiziert. Schlägt die Signatur-Verifikation fehl, wird der jeweilige private Signatur-Schlüssel <„privat key“> nicht akzeptiert, weshalb der mit diesem privaten Signatur-Schlüssel <„privat key“> signierte Krypto-Schlüssel, insbesondere der signierte „Key BLOB“, nicht zum Laden an die Krypto-Hardwareeinheit weitergeleitet wird.
-
Bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, der Krypto-Schlüssel, insbesondere der „Key BLOBs“, werden paarweise sowohl neue private Signatur-Schlüssel als auch neue öffentliche Verifikation-Schlüssel generiert, die öffentliche Verifikation-Schlüssel durch die neuen öffentlichen Verifikation-Schlüssel aktualisiert und insbesondere in die Validierungseinheit integriert/gespeichert sowie alle Krypto-Schlüssel, insbesondere alle „Key BLOBs“, d.h. sowohl neue Krypto-Schlüssel, insbesondere neue „Key BLOBs“, als auch die geänderten Krypto-Schlüssel, insbesondere die geänderten „Key BLOBs“, mit den neuen zu den neuen öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüsseln signiert (vgl. Ansprüche 5 und 14).
-
Der Vorteil dieser Prüfungsvariante (II) besteht darin, dass die öffentlichen Verifikation-Schlüssel in die Validierungseinheit integriert/gespeichert werden können, ohne die Krypto-Schlüssel, insbesondere die „Key BLOBs“, zu kennen. Die (Prozessorsystem-spezifischen) Krypto-Schlüssel, insbesondere „Key BLOBs“, müssen jedoch später mit den passenden privaten Signatur-Schlüsseln signiert werden.
- (III) Die Prüfung auf Validität erfolgt auf der Basis der Verifikation einer erweiterten digitalen Signatur. Dabei werden private Signatur-Schlüssel <„privat keys“>, mit denen Krypto-Schlüssel, insbesondere „Key BLOBs“, einschließlich Krypto-Schlüssel-spezifischer Metadaten, vorzugsweise Versionsnummern, Erzeugungsdaten etc., z.B. vom Krypto-Schlüssel-Hersteller, signiert worden sind, mit öffentlichen, z.B. in der Validierungseinheit enthaltenen, Verifikation-Schlüsseln <„public keys“>, die zu den privaten Signatur-Schlüsseln korrespondieren und dementsprechende Schlüsselpaare bilden, verifiziert. Nur wenn die Signatur-Verifikation erfolgreich ist, also der jeweilige private Signatur-Schlüssel <„privat key“> eigentlich akzeptiert werden könnte, kommt es, bevor der mit diesem privaten Signatur-Schlüssel <„privat key“> signierte Krypto-Schlüssel, insbesondere der signierte „Key BLOB“, zum Laden an die Krypto-Hardwareeinheit weitergeleitet werden kann, zu einem Abgleich der Krypto-Schlüsselspezifischen Metadaten. Bei diesem Abgleich werden die Metadaten mit zu den Metadaten korrespondierenden, in einer zweiten „Positivliste (Whitelist)“ enthaltenen Referenz-Metadaten abgeglichen.
-
Ergibt der Abgleich, dass die Metadaten mit den Referenz-Metadaten nicht übereinstimmen, weil z.B. eine metadatenspezifische Versionsnummer älter ist als eine Referenz-Metadaten-spezifische Versionsnummer, so wird der jeweilige private Signatur-Schlüssel <„privat key“> nicht akzeptiert, weshalb der mit diesem privaten Signatur-Schlüssel <„privat key“> signierte Krypto-Schlüssel, insbesondere der signierte „Key BLOB“, nicht zum Laden an die Krypto-Hardwareeinheit weitergeleitet wird.
-
Bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, der Krypto-Schlüssel, insbesondere der „Key BLOBs“, werden, insbesondere paarweise sowohl neue private Signatur-Schlüssel als auch neue öffentliche Verifikation-Schlüssel generiert, die Metadaten, vorzugsweise die Versionsnummern, die Erzeugungsdaten etc., in der zweiten „Positivliste (Whitelist)“ angepasst und insbesondere in die Validierungseinheit integriert/gespeichert sowie neue Krypto-Schlüssel, insbesondere neue „Key BLOBs“ mit den zu den öffentlichen Verifikation-Schlüsseln korrespondierenden privaten Signatur-Schlüsseln und den angepassten Metadaten, vorzugsweise den angepassten Versionsnummern, den angepassten Erzeugungsdaten etc., signiert (vgl. Ansprüche 7 und 16).
-
Der Vorteil dieser Prüfungsvariante (III) besteht darin, dass nur die Metadaten bzw. die Versionsnummern, die Erzeugungsdaten etc., in der zweiten „Positivliste (Whitelist)“ geändert werden, während neue Schlüsselpaare, jeweils bestehend aus einem neuen privaten Signatur-Schlüssel und einem neuen öffentlichen Verifikation-Schlüssel, nicht zwingend erzeugt werden müssen, sondern optional erzeugt werden können.
-
Darüber hinaus können die Metadaten, insbesondere die Versionsnummern, die Erzeugungsdaten etc., in der zweiten „Positivliste (Whitelist)“, vorzugsweise in die Validierungseinheit, festgelegt werden, ohne dass die Krypto-Schlüssel, insbesondere die „Key BLOBs“ zu diesem Zeitpunkt bekannt sind.
-
Allerdings müssen die (Prozessorsystem-spezifischen) Krypto-Schlüssel, insbesondere die „Key BLOBs“, jedoch später mit den zu den öffentlichen Verifikation-Schlüsseln korrespondierenden privaten Signatur-Schlüsseln signiert und den angepassten Metadaten, vorzugsweise den angepassten Versionsnummern, den angepassten Erzeugungsdaten etc., versehen und signiert werden.
- (IV) Die Prüfung auf Validität erfolgt auf der Basis einer CHALLENGE-RESPONSE-Prozedur mit in einer dritten „Positivliste (Whitelist)“ enthaltenen CHALLENGE-RESPONSE-Zahlenpaaren. Hierzu wird zunächst ein Krypto-Schlüssel, insbesondere „Key BLOB“, in die Krypto-Hardwareeinheit geladen. Danach wird mit der Krypto-Hardwareeinheit eine vorgegebene, auf einem aus der dritten „Positivliste (Whitelist)“ ausgewählten CHALLENGE-RESPONSE-Zahlenpaar basierende Krypto-Operation, vorzugsweise eine Verschlüsselung, mit dem geladenen Krypto-Schlüssel und einer CHALLENGE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars durchgeführt.
-
Ist das Ergebnis der durchgeführten Krypto-Operation eine RESPONSE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars, so wird der geladene Krypto-Schlüssel als valide eingestuft/angesehen, und vorzugsweise in der Krypto-Hardwareeinheit gespeichert, anderenfalls wird der geladene Krypto-Schlüssel als invalide eingestuft/angesehen, und vorzugsweise aus der Krypto-Hardwareeinheit entfernt bzw. ein Zugriff auf die Krypto-Hardwareeinheit verweigert.
-
Bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels, insbesondere des „Key BLOB“, wird die dritte „Positivliste (Whitelist)“ für einen neuen Krypto-Schlüssel aktualisiert (vgl. Ansprüche 9 und 18).
-
Der Vorteil dieser Prüfungsvariante (IV) besteht darin, dass die Krypto-Schlüssel, insbesondere die „Key BLOBs“, nicht verändert (z.B. signiert) werden müssen und dass keine Public Key Kryptographie notwendig ist. Weiterhin können die CHALLENGE-RESPONSE-Zahlenpaare alleine durch die Kenntnis des im Krypto-Schlüssel, insbesondere im „Key BLOB“, verschlüsselten Schlüssels berechnet werden. Der Krypto-Schlüssel, insbesondere „Key BLOB“, selbst kann daher Prozessorsystem-spezifisch sein und braucht deshalb auch erst während dessen Produktion erzeugt werden.
-
Fazit: Das auf diese Prinzipien beruhende Validität-Prüfungsverfahren oder die darauf beruhende Validierungseinheit bietet den Vorteil, dass Angriffe verhindert werden können, die darauf aufbauen, den Krypto-Schlüssel, insbesondere den „Key BLOB“, austauschen zu können. Des Weiteren lässt sich das auf diesen Prinzipien beruhende Validität-Prüfungsverfahren oder die darauf beruhende Validierungseinheit je nach Anwendungs- und Produktionsszenario effizient und unabhängig von der Zielplattform umsetzen.
-
Weitere Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung eines Ausführungsbeispieles der Erfindung anhand der 1 und 2. Diese zeigen:
- 1 eine aus Krypto-Prozessor und Validierungseinheit gebildete erste Funktionseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere „Key BLOBs“,
- 2 eine aus Krypto-Modul und Validierungseinheit gebildete zweite Funktionseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere „Key BLOBs“.
-
1 zeigt eine aus einer als Krypto-Prozessor KPZ ausgebildeten Krypto-Hardwareeinheit KHWE und einer Validierungseinheit VDE gebildete erste Funktionseinheit FTE-1 zum Steuern des Ladens von in einem IT-System ITS, das vorzugsweise als ein Eingebettetes System EBS ausgebildet ist, benutzbaren, vorzugsweise in Form von „Key BLOBs“ oder „Wrapped Keys“ gebildeten, Krypto-Schlüsseln KS-A..KS-X. Die erste Funktionseinheit FTE-1 führt dazu in dem/für das IT-System ITS, EBS, also systembezogen, kryptografische Operationen aus, die bisher (gemäß dem Stand der Technik) von der Krypto-Hardwareeinheit KHWE bzw. von dem Krypto-Prozessor KPZ ausgeführt worden sind.
-
Ausgangspunkt für das Laden der Krypto-Schlüssel bzw. „Key BLOBs“ KS-A..KS-X ist in dem IT-System ITS, EBS eine systemspezifische Anwendungssoftware ASW mit mehreren, jeweils einen separaten Krypto-Schlüssel bzw. „Key BLOB“ KS-A, KS-B,...KS-X der benutzbaren Krypto-Schlüsseln KS-A..KS-X bzw. „Key BLOBs“ zugewiesenen/beinhaltenden Software-Anwendungen (SW-Anwendungen) SW-A, SW-B,...SW-X. Jede dieser Software-Anwendungen (SW-Anwendungen) SW-A, SW-B,...SW-X greift mittelbar, über die Validierungseinheit VDE, (und nicht mehr unmittelbar wie beim Stand der Technik) auf die Krypto-Hardwareeinheit KHWE bzw. den Krypto-Prozessor KPZ zu, der als Co-Prozessor zu einem in der 1 nicht dargestellten Haupt-Prozessor fungiert. Mit dem durch die jeweilige SW-Anwendung SW-A..SW-X der Anwendungssoftware ASW erfolgten Zugriff soll der korrespondierende Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen werden. Dieses Laden passiert jedoch nicht wie beim Stand der Technik unmittelbar, sondern unter Zwischenschaltung der Validierungseinheit VDE. In dieser Validierungseinheit VDE wird der Krypto-Schlüssel bzw. der „Key BLOB“ KS-A..KS-X vor dem Laden in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ auf Validität geprüft.
-
Die Validierungseinheit VDE weist hierzu auf:
- 1) Eine Krypto-Schnittstelle KSS, über die die Validierungseinheit VDE zur Ausführung der systembezogenen kryptografischen Operationen mit der Krypto-Hardwareeinheit KHWE bzw. mit dem Krypto-Prozessor KPZ verbunden ist,
- 2) eine Software-Schnittstelle SWSS, über die jede einzelne SW-Anwendungen SW-A..SW-X der systemspezifischen Anwendungssoftware ASW auf die Krypto-Hardwareeinheit KHWE bzw. den Krypto-Prozessor KPZ initial zugreift,
- 3) eine Steuereinrichtung STE, die verbunden mit der Krypto-Schnittstelle KSS und der Software-Schnittstelle SWSS und dabei eine Funktionseinheit bildend derart ausgebildet ist, dass auf den über die Software-Schnittstelle SWSS erfolgten Zugriff jeder einzelnen SW-Anwendungen SW-A..SW-X der systemspezifischen Anwendungssoftware ASW der mit dem Zugriff zu ladende Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in der Steuereinrichtung STE auf Validität geprüft wird, bevor der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X KS-A..KS-X über die Krypto-Schnittstelle KSS in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird.
-
Für die Validitätsprüfung des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X enthält die Steuereinrichtung STE (i) einen nicht-flüchtigen, lesbaren Speicher SP, in dem rechenwerklesbare Steuerprogrammbefehle eines das Laden steuernden Programm-Moduls PGM gespeichert sind, und (ii) ein mit dem Speicher SP verbundenes Rechenwerk RW, das die Steuerprogrammbefehle des Programm-Moduls PGM ausführt.
-
Die in der 1 dargestellte Validierungseinheit VDE kann vorzugsweise - in einer ersten Ausführungsform - als eine Komponente eines Betriebssystem-Kernels des IT-Systems ITS, EBS mit den zum IT-System ITS, EBS gehörenden Haupt-Prozessor (in der 1 nicht dargestellt) und dem Krypto-Prozessor KPZ ausgebildet sein. Die in diesem Fall als Software-Modul ausgebildete Validierungseinheit VDE ist dabei entweder in dem Betriebssystem-Kernel integriert oder als signiertes Kernel-Modul implementiert. Die Funktion der Steuereinrichtung STE sowie die Funktionalität der Steuereinrichtung STE repräsentiert durch das das Programm-Modul PGM ausführende Rechenwerk RW und den das Programm-Modul PGM speichernde Speicher SP wird in dieser ersten Ausführungsform durch den Haupt-Prozessor ausgeübt.
-
Alternativ dazu kann die in der 1 dargestellte Validierungseinheit VDE wieder vorzugsweise - in einer zweiten Ausführungsform - als Digitale Schaltung eines FPGA-Schaltkreis des IT-Systems ITS, EBS mit den zum IT-System ITS, EBS gehörenden Haupt-Prozessor und dem Krypto-Prozessor KPZ ausgebildet sein.
-
Bei der Prüfung auf Validität in der Steuereinrichtung STE gibt es vorzugsweise verschiedene Prinzipien [Prüfungsvarianten(I)...(IV)], die im Zuge der Ausführung der systembezogenen kryptografischen Operationen durchgeführt werden können.
-
In einer ersten Variante (I) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Basis einer Hashfunktion-Abbildung
zunächst in dem die Steuerprogrammbefehle des Programm-Moduls PGM ausführenden Rechenwerk RW der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X und ein durch die Hashfunktion-Abbildung generierter und zum Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X korrespondierender Hash-Wert mit mindestens einem für das Laden in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ erlaubten Referenz-Krypto-Schlüssel und mindestens einem durch die Hashfunktion-Abbildung generierten, zu dem erlaubten Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X korrespondierenden Referenz-Hash-Wert, der in dem Speicher SP in einer ersten „Positivliste (Whitelist)“ gespeichert ist, verglichen wird, und
dann, wenn der Vergleich ergibt, dass der Hash-Wert des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X mit einem Hash-Wert des Referenz-Krypto-Schlüssels in der ersten „Positivliste (Whitelist)“ übereinstimmt also in der „Positivliste (Whitelist)“ enthalten ist, dass dann der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird.
-
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. „Key BLOB“ in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ.
-
In Bezug auf die erste Prüfungsvariante (I) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X die erste „Positivliste (Whitelist)“ für einen neuen Krypto-Schlüssel bzw. „Key BLOB“ aktualisiert wird.
-
In einer zweiten Variante (II) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Basis einer digitalen Signatur
zunächst der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X mit einem privaten Signatur-Schlüssel <„privat key“> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffentlichen Verifikation-Schlüssel <„public key“>, der in dem Speicher SP gespeichert ist, verifiziert wird, und
schließlich, wenn die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X gültig ist, der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird.
-
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ.
-
In Bezug auf die zweite Prüfungsvariante (II) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch des Krypto-Schlüssels „Key BLOB“ KS-A..KS-X paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffentlicher Verifikation-Schlüssel generiert werden, der öffentliche Verifikation-Schlüssel durch den neuen öffentlichen Verifikation-Schlüssel aktualisiert wird und sowohl ein neuer Krypto-Schlüssel bzw. „Key BLOB“ als auch der geänderte Krypto-Schlüssel bzw. „Key BLOB“ mit dem neuen zu dem neuen öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel signiert werden.
-
In einer dritten Variante (III) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Basis einer erweiterten digitalen Signatur
zunächst der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X einschließlich Krypto-Schlüssel-spezifischer Metadaten, vorzugsweise einer Versionsnummer, einem Erzeugungsdatum etc., mit einem privaten Signatur-Schlüssel <„privat key“> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffentlichen Verifikation-Schlüssel <„public
key“>, der in dem Speicher SP gespeichert ist, verifiziert wird,
dann, wenn die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X gültig ist, die Metadaten mit zu den Metadaten korrespondierenden, in dem Speicher SP in einer zweiten „Positivliste (Whitelist)“ gespeicherten Referenz-Metadaten abgeglichen werden anderenfalls wird das Laden des Krypto-Schlüssels bzw. „Key BLOB“ KS-A...KS-X abgebrochen und schließlich, wenn der Abgleich ergibt, dass die Metadaten mit den Referenz-Metadaten übereinstimmen, dass dann der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird.
-
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ.
-
In Bezug auf die dritte Prüfungsvariante (III) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X, insbesondere paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffentlicher Verifikation-Schlüssel generiert werden, die Metadaten in der zweiten „Positivliste (Whitelist)“ angepasst werden und ein neuer Krypto-Schlüssel bzw. „Key BLOB“ mit dem zu dem öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel und den angepassten Metadaten signiert wird.
-
In einer vierten Variante (IV) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf Basis einer CHALLENGE-RESPONSE-Prozedur mit in dem Speicher SP in einer dritten „Positivliste (Whitelist)“ gespeicherten CHALLENGE-RESPONSE-Zahlenpaaren
zunächst der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in den Krypto-Prozessor KPZ geladen wird,
dann mit der Krypto-Hardwareeinheit (KHWE) eine vorgegebene, auf einem aus der dritten „Positivliste (Whitelist)“ ausgewählten CHALLENGE-RESPONSE-Zahlenpaar basierende Krypto-Operation, vorzugsweise eine Verschlüsselung, mit dem geladenen Krypto-Schlüssel bzw. „Key BLOB“ KS-A...KS-X und einer CHALLENGE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars durchgeführt wird, und
schließlich, wenn das Ergebnis der durchgeführten Krypto-Operation der RESPONSE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars entspricht, dass dann der geladene Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X als valide eingestuft/angesehen, und vorzugsweise in der Krypto-Hardwareeinheit KHWE bzw. in dem Krypto-Prozessor KPZ gespeichert, wird.
-
Liefert die durchgeführte Krypto-Operation hingegen ein anderes Ergebnis, so wird der geladene Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X als invalide eingestuft/angesehen, und vorzugsweise aus der Krypto-Hardwareeinheit KHWE bzw. aus dem Krypto-Prozessor KPZ entfernt oder ein Zugriff auf die Krypto-Hardwareeinheit KHWE bzw. auf den Krypto-Prozessor KPZ verweigert.
-
In Bezug auf die vierte Prüfungsvariante (IV) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X die dritte „Positivliste (Whitelist)“ für einen neuen Krypto-Schlüssel bzw. „Key BLOB“ aktualisiert wird.
-
2 zeigt eine aus einer als Krypto-Modul KM ausgebildete Krypto-Hardwareeinheit KHWE und einer Validierungseinheit VDE gebildete zweite Funktionseinheit FTE-2 zum Steuern des Ladens von in einem IT-System ITS, das vorzugsweise als ein Eingebettetes System EBS ausgebildet ist, benutzbaren, vorzugsweise in Form von „Key BLOBs“ oder „Wrapped Keys“ gebildeten, Krypto-Schlüsseln KS-A..KS-X. Die zweite Funktionseinheit FTE-2 führt dazu in dem/für das IT-System ITS, EBS, also systembezogen, kryptografische Operationen aus, die bisher (gemäß dem Stand der Technik) von der Krypto-Hardwareeinheit KHWE bzw. von dem Krypto-Modul KM ausgeführt worden sind.
-
Ausgangspunkt für das Laden der Krypto-Schlüssel bzw. „Key BLOBs“ KS-A..KS-X ist in dem IT-System ITS, EBS wieder die systemspezifische Anwendungssoftware ASW mit den mehreren, jeweils die separaten Krypto-Schlüssel bzw. „Key BLOB“ KS-A, KS-B,...KS-X der benutzbaren Krypto-Schlüsseln KS-A..KS-X bzw. „Key BLOBs“ zugewiesenen/beinhaltenden Software-Anwendungen (SW-Anwendungen) SW-A, SW-B,...SW-X. Jede dieser Software-Anwendungen (SW-Anwendungen) SW-A, SW-B,...SW-X greift mittelbar, über die Validierungseinheit VDE, (und nicht mehr unmittelbar wie beim Stand der Technik) auf die Krypto-Hardwareeinheit KHWE bzw. das Krypto-Modul KM zu, das wie die Validierungseinheit VDE in einem Haupt-Prozessor HPZ des IT-Systems ITS, EBS integriert/implementiert ist. Auf das Verhältnis zwischen dem aus der Krypto-Hardwareeinheit KHWE bzw. dem Krypto-Modul KM und der Validierungseinheit VDE gebildeten zweiten Funktionseinheit FTE-2 einerseits sowie und dem Haupt-Prozessor HPZ andererseits wird weiter unten noch näher eingegangen.
-
Mit dem durch die jeweilige SW-Anwendung SW-A..SW-X der Anwendungssoftware ASW erfolgten Zugriff soll der korrespondierende Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen werden. Dieses Laden passiert jedoch wieder nicht wie beim Stand der Technik unmittelbar, sondern unter Zwischenschaltung der Validierungseinheit VDE. In dieser Validierungseinheit VDE wird der Krypto-Schlüssel bzw. der „Key BLOB“ KS-A..KS-X vor dem Laden in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM auf Validität geprüft.
-
Die Validierungseinheit VDE weist hierzu auf:
- 1) Eine Krypto-Schnittstelle KSS, über die die Validierungseinheit VDE zur Ausführung der systembezogenen kryptografischen Operationen mit der Krypto-Hardwareeinheit KHWE bzw. mit dem Krypto-Modul KM verbunden ist,
- 2) eine Software-Schnittstelle SWSS, über die jede einzelne SW-Anwendungen SW-A..SW-X der systemspezifischen Anwendungssoftware ASW auf die Krypto-Hardwareeinheit KHWE bzw. das Krypto-Modul KM initial zugreift,
- 3) eine Steuereinrichtung STE, die verbunden mit der Krypto-Schnittstelle KSS und der Software-Schnittstelle SWSS und dabei eine Funktionseinheit bildend derart ausgebildet ist, dass auf den über die Software-Schnittstelle SWSS erfolgten Zugriff jeder einzelnen SW-Anwendungen SW-A..SW-X der systemspezifischen Anwendungssoftware ASW der mit dem Zugriff zu ladende Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in der Steuereinrichtung STE auf Validität geprüft wird, bevor der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X KS-A..KS-X über die Krypto-Schnittstelle KSS in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird.
-
Für die Validitätsprüfung des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X enthält die Steuereinrichtung STE (i) einen nicht-flüchtigen, lesbaren Speicher SP, in dem rechenwerklesbare Steuerprogrammbefehle eines das Laden steuernden Programm-Moduls PGM gespeichert sind, und (ii) ein mit dem Speicher SP verbundenes Rechenwerk RW, das die Steuerprogrammbefehle des Programm-Moduls PGM ausführt.
-
Die in der 2 dargestellte Validierungseinheit VDE und das Krypto-Modul KM können vorzugsweise - in einer bevorzugten Ausführungsform - als Komponenten eines Betriebssystem-Kernels des IT-Systems ITS, EBS mit den zum IT-System ITS, EBS gehörenden Haupt-Prozessor HPZ ausgebildet sein. Die in diesem Fall als Software-Modul ausgebildete zweite Funktionseinheit FTE-2, also die Validierungseinheit VDE und das Krypto-Modul KM, ist dabei entweder in dem Betriebssystem-Kernel integriert oder als signiertes Kernel-Modul implementiert. Die Funktion der Steuereinrichtung STE sowie die Funktionalität der Steuereinrichtung STE repräsentiert durch das das Programm-Modul PGM ausführende Rechenwerk RW und den das Programm-Modul PGM speichernde Speicher SP wird in dieser ersten Ausführungsform durch den Haupt-Prozessor HPZ ausgeübt.
-
Bei der Prüfung auf Validität in der Steuereinrichtung STE gibt es vorzugsweise verschiedene Prinzipien [Prüfungsvarianten(I)...(IV)], die im Zuge der Ausführung der systembezogenen kryptografischen Operationen durchgeführt werden können.
-
In einer ersten Variante (I) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Basis einer Hashfunktion-Abbildung
zunächst in dem die Steuerprogrammbefehle des Programm-Moduls PGM ausführenden Rechenwerk RW der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X und ein durch die Hashfunktion-Abbildung generierter und zum Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X korrespondierender Hash-Wert mit mindestens einem für das Laden in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM erlaubten Referenz-Krypto-Schlüssel und mindestens einem durch die Hashfunktion-Abbildung generierten, zu dem erlaubten Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X korrespondierenden Referenz-Hash-Wert, der in dem Speicher SP in einer ersten „Positivliste (Whitelist)“ gespeichert ist, verglichen wird, und
dann, wenn der Vergleich ergibt, dass der Hash-Wert des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X mit einem Hash-Wert des Referenz-Krypto-Schlüssels in der ersten „Positivliste (Whitelist)“ übereinstimmt also in der „Positivliste (Whitelist)“ enthalten ist, dass dann der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird.
-
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. „Key BLOB“ in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM.
-
In Bezug auf die erste Prüfungsvariante (I) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X die erste „Positivliste (Whitelist)“ für einen neuen Krypto-Schlüssel bzw. „Key BLOB“ aktualisiert wird.
-
In einer zweiten Variante (II) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Basis einer digitalen Signatur
zunächst der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X mit einem privaten Signatur-Schlüssel <„privat key“> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffentlichen Verifikation-Schlüssel <„public key“>, der in dem Speicher SP gespeichert ist, verifiziert wird, und
schließlich, wenn die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X gültig ist, der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird.
-
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM.
-
In Bezug auf die zweite Prüfungsvariante (II) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch des Krypto-Schlüssels „Key BLOB“ KS-A..KS-X paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffentlicher Verifikation-Schlüssel generiert werden, der öffentliche Verifikation-Schlüssel durch den neuen öffentlichen Verifikation-Schlüssel aktualisiert wird und sowohl ein neuer Krypto-Schlüssel bzw. „Key BLOB“ als auch der geänderte Krypto-Schlüssel bzw. „Key BLOB“ mit dem neuen zu dem neuen öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel signiert werden.
-
Hierzu jetzt ein in der Praxis mögliches Implementierungsszenario:
- - Als Prozessorsystem ist ein Linux System mit „Secure Boot“ auf einem „i.MX6“-Prozessor (inkl. CAA-Krypto-Co-Prozessor und Secure Memory Store mit „Key BLOB“-Lade-Funktion) von Freescale®.
- - Die Validierungseinheit ist als signiertes Linux Kernel Modul ausgeführt und enthält einen ECC-Public Key (Elliptic Curve Cryptography).
- - „Key BLOBs“ wurden in der Produktion generiert und mit passendem „Private Key“ signiert.
- - Beim Laden des „Key BLOB“ und der dazugehörigen Signatur in die Validierungseinheit wird zuerst die Signatur verifiziert und nur dann der „Key BLOB“in den Secure Memory Store geladen, wenn die Verifikation erfolgreich war.
- - Ein „Key BLOB“-Update erfolgt durch Generierung von
- o neuem „Public Key“/„Private Key“-Paar,
- o neuen „Key BLOBs“, signiert mit neuem „Private Key“ und
- o neuem signierten Validierungs-Modul mit neuem „Public Key“.
-
In einer dritten Variante (III) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Basis einer erweiterten digitalen Signatur
zunächst der Krypto-Schlüssel bzw. „Key BLOB“ KS-A...KS-X einschließlich Krypto-Schlüssel-spezifischer Metadaten, vorzugsweise einer Versionsnummer, einem Erzeugungsdatum etc., mit einem privaten Signatur-Schlüssel <„privat key“> signiert wird,
dann die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X mit einem zu dem privaten Signatur-Schlüssel korrespondierenden öffentlichen Verifikation-Schlüssel <„public key“>, der in dem Speicher SP gespeichert ist, verifiziert wird,
dann, wenn die Signatur des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X gültig ist, die Metadaten mit zu den Metadaten korrespondierenden, in dem Speicher SP in einer zweiten „Positivliste (Whitelist)“ gespeicherten Referenz-Metadaten abgeglichen werden anderenfalls wird das Laden des Krypto-Schlüssels bzw. „Key BLOB“ KS-A...KS-X abgebrochen und schließlich, wenn der Abgleich ergibt, dass die Metadaten mit den Referenz-Metadaten übereinstimmen, dass dann der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird.
-
Liefert der Vergleich hingegen ein anderes Ergebnis, so unterbleibt ein Laden des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM.
-
In Bezug auf die dritte Prüfungsvariante (III) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X, insbesondere paarweise sowohl ein neuer privater Signatur-Schlüssel als auch ein neuer öffentlicher Verifikation-Schlüssel generiert werden, die Metadaten in der zweiten „Positivliste (Whitelist)“ angepasst werden und ein neuer Krypto-Schlüssel bzw. „Key BLOB“ mit dem zu dem öffentlichen Verifikation-Schlüssel korrespondierenden privaten Signatur-Schlüssel und den angepassten Metadaten signiert wird.
-
Hierzu jetzt ein in der Praxis mögliches Implementierungsszenario:
- - Als Prozessorsystem wird ein Linux System mit „Secure Boot“ (inkl. Bitstream) auf einem „Cyclone V SoC“ von Altera® mit proprietärem FPGA-spezifischen Trust Anchor mit „Key BLOB“-Lade-Funktion verwendet.
- - Die Validierungseinheit ist als Digitale Schaltung in einem FPGA-Modul realisiert und enthält ECC-Public Key (Elliptic Curve Cryptography)und Versionsnummer.
- - „Key BLOBs“ wurden in der Produktion generiert, mit aktueller Versionsnummer versehen und mit passendem „Private Key“ signiert.
- - Beim Laden des „Key BLOB“ und der dazugehörigen Signatur in die Validierungseinheit wird zuerst die Signatur verifiziert und die Versionsnummer überprüft. Nur wenn die Signaturverifikation erfolgreich war und die Versionsnummer mit der der Validierungseinheit übereinstimmt wird der „Key BLOB“ in den Trust Anchor geladen.
- - Ein Update der „Key BLOBs“ erfolgt durch Bereitstellung von
- o neuer Versionsnummer,
- o neuen „Key BLOBs“, versehen mit neuer Versionsnummer und signiert mit aktuellem „Private Key“ und
- o neuem FPGA-Bitstream mit neuer Versionsnummer, signiert für „Secure Boot“.
-
In einer vierten Variante (IV) zur Prüfung der Validität des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE derart ausgebildet, dass auf der Basis einer CHALLENGE-RESPONSE-Prozedur mit in dem Speicher SP in einer dritten „Positivliste (Whitelist)“ gespeicherten CHALLENGE-RESPONSE-Zahlenpaaren
zunächst der Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X in die Krypto-Hardwareeinheit KHWE bzw. in das Krypto-Modul KM geladen wird,
dann mit der Krypto-Hardwareeinheit (KHWE) eine vorgegebene, auf einem aus der dritten „Positivliste (Whitelist)“ ausgewählten CHALLENGE-RESPONSE-Zahlenpaar basierende Krypto-Operation, vorzugsweise eine Verschlüsselung, mit dem geladenen Krypto-Schlüssel bzw. „Key BLOB“ KS-A...KS-X und einer CHALLENGE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars durchgeführt wird, und
schließlich, wenn das Ergebnis der durchgeführten Krypto-Operation der RESPONSE-Zahl des ausgewählten CHALLENGE-RESPONSE-Zahlenpaars entspricht, dass dann der geladene Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X als valide eingestuft/angesehen, und vorzugsweise in der Krypto-Hardwareeinheit KHWE bzw. in dem Krypto-Modul KM gespeichert, wird.
-
Liefert die durchgeführte Krypto-Operation hingegen ein anderes Ergebnis, so wird der geladene Krypto-Schlüssel bzw. „Key BLOB“ KS-A..KS-X als invalide eingestuft/angesehen, und vorzugsweise aus der Krypto-Hardwareeinheit KHWE bzw. aus dem Krypto-Modul KM entfernt oder ein Zugriff auf die Krypto-Hardwareeinheit KHWE bzw. auf das Krypto-Modul KM verweigert.
-
In Bezug auf die vierte Prüfungsvariante (IV) sind der Speicher SP und das das Programm-Modul PGM ausführende Rechenwerk RW in der Steuereinheit STE weiterhin derart ausgebildet, dass bei einer Änderung/einem Austausch, insbesondere bei einer Krypto-Schlüssel-Aktualisierung, des Krypto-Schlüssels bzw. „Key BLOB“ KS-A..KS-X die dritte „Positivliste (Whitelist)“ für einen neuen Krypto-Schlüssel bzw. „Key BLOB“ aktualisiert wird
-
Hierzu jetzt ein in der Praxis mögliches Implementierungsszenario:
- - Als Prozessorsystem wird ein Linux System mit „Secure Boot“ auf CPU von Intel® mit einer integrierten „Trusted Platform Module (TPM)“-Firmware.
- - Die Validierungseinheit ist in einem Linux Kernel integriert und enthält in einer „Positivliste (Whitelist)“ gespeicherte CHALLENGE-RESPONSE-Zahlenpaare, die offline mit den korrekten Schlüsseln erzeugt wurden.
- - „Key BLOBs“ oder „Wrapped Keys“ wurden in der Produktion generiert.
- - Die Validierungseinheit lädt den zu ladenden „Key BLOB“ oder „Wrapped Key“ in das „Trusted Platform Module (TPM)“ und berechnet damit einen „keyed-Hash Message Authentication Code (HMAC)“ von der gespeicherten CHALLENGE.
- - Das HMAC-Ergebnis wird mit der gespeicherten RESPONSE verglichen; bei Gleichheit wird der Schlüssel im „Trusted Platform Module (TPM)“ belassen, bei Ungleichheit wird dieser wieder aus dem „Trusted Platform Module (TPM)“ entfernt.
- - Eine Aktualisierung von „Key BLOBs“ oder „Wrapped Keys“ erfolgt durch Erzeugung von
- o neuen „Key BLOBs“ oder „Wrapped Keys“,
- o neuem Kernel inkl. Validierungsmodul mit neuen CHALLENGE-RESPONSE-Zahlenpaaren, signiert für „Secure Boot“.
