-
Die Erfindung betrifft ein Verfahren zum Überprüfen von kryptografischen Geheimnissen auf Gleichheit, wobei zumindest eines der Geheimnisse in einem sicheren System lesegeschützt abgelegt ist.
-
Moderne Fahrzeug sind heute Teil eines großen informationstechnischen Fahrzeug-Ökosystems. Ein zentraler Teil dieses Fahrzeug-Ökosystems ist dabei das sogenannte Vehicle Backend, kurz Backend. Dies ist ein typischerweise vom Fahrzeughersteller betriebener Server, mit welchem die Fahrzeuge verbunden sind und über welchen sie sich beispielsweise mit dem Internet oder auch untereinander vernetzen. Die Kommunikationsverbindung zwischen dem Backend und dem Fahrzeug wird dabei mit Hilfe von bekannten Standardverfahren der Informationssicherheit abgesichert. Meist handelt es sich dabei um TLS, manchmal auch um IPSec. All diese Standardverfahren beruhen dabei auf einer sogenannten asymmetrischen Kryptografie wie beispielsweise ECC oder RSA. Das Fahrzeug-Ökosystem kann dabei weitere Komponenten umfassen, beispielsweise einzelne in den Fahrzeugen verbaute Steuergeräte, Smartphones mit darauf laufenden Applikationen, die beispielsweise vom Fahrzeughersteller zur Verfügung gestellt werden, und die sowohl mit dem Fahrzeug bzw. seinen Steuergeräten als auch mit dem Backend kommunizieren. Die Kommunikation innerhalb des Fahrzeugs kann beispielsweise über WLAN oder Bluetooth erfolgen, die fahrzeugexterne Kommunikation typischerweise über gängige Mobilfunknetze. Weitere Bestandteile des Fahrzeug-Ökosystems können auch herstellerspezifische externe Geräte sein, wie beispielsweise sogenannte OBD-Dongles, die in der Regel über eine Hardwareschnittstelle ausschließlich mit den Fahrzeugen kommunizieren. Auch diese Kommunikationsbeziehungen sind in der Regel mit Hilfe asymmetrischer kryptografischer Verfahren abgesichert, beispielsweise wiederum über TLS oder IPSec.
-
Daneben gibt es jedoch auch Fälle, in denen es effizienter ist oder aufgrund der Sicherheitsanforderungen auch notwendig ist, zwei oder mehr Teilnehmer des Fahrzeug-Ökosystems auf eine sichere Weise mit geteilten Geheimnissen auszustatten, die anschließend dazu genutzt werden können, die Kommunikation zwischen diesen Teilnehmern mit Hilfe auf geteilten Geheimnissen basierenden kryptografischen Verfahren, typischerweise einer sogenannten symmetrischen Kryptografie, abzusichern. Beispiele für geteilte Geheimnisse und darauf basierenden kryptografischen Verfahren können beispielsweise geteilte 128-Bit-Schlüssel mit AES für die Verschlüsselung, 256-Bit-Schlüssel mit HMAC für die Authentifizierung bzw. Integrität oder auch individuelle Passwörter für die Passwortauthentifizierung sein.
-
Derartige geteilte Geheimnisse werden dann in den diese Geheimnisse nutzenden Systemen so gut es geht gegen unberechtigten Zugriff, und hier insbesondere gegen einen unberechtigten Lesezugriff, geschützt. Dies kann erreicht werden, indem nur Schnittstellen für lokale Aufrufe von diesen Geheimnissen nutzenden kryptografischen Operationen vorgesehen sind, nicht jedoch für das Auslesen der Geheimnisse selbst. Des Weiteren werden solche Geheimnisse möglichst gut gegen Reverse Engineering geschützt, beispielsweise durch softwarebasierte Obfuskierungstechniken oder die Nutzung eines Hardware Security Modules (HSM) als sicheres System, in dem die Geheimnisse abgelegt werden. Sie verlassen dieses anschließend nicht mehr.
-
Der Vorteil dieser Vorgehensweise liegt nun darin, dass niemand, im Falle der Nutzung eines Hardware Security Modules, insbesondere auch kein Angreifer, der vollen Zugriff auf das System hat, einen Zugriff auf den Wert des Geheimnisses hat und dieses mit vertretbarem Aufwand im Klartext erlangen kann. Alle kryptografischen Operationen, bei denen der Schlüssel genutzt wird, werden ebenfalls innerhalb des sicheren Systems, also beispielsweise des HSM, durchgeführt. Ein Nachteil dieser Vorgehensweise ist jedoch die erschwerte Fehlersuche bei Fehlschlägen einer kryptografischen Operation. Ein solcher Fehler kann beispielsweise beim Empfänger bei der Entschlüsselung oder Prüfung des Message Authentication Codes (MAC) oder auch des Passworts auftreten. Schlägt beispielsweise die Entschlüsselung, Integritätsprüfung oder Authentifizierung beim Empfänger fehl, so liegt natürlich der Verdacht nahe, dass das vom Sender genutzte Geheimnis, also beispielsweise der Schlüssel, mit dem die Nachricht verschlüsselt und/oder authentifiziert worden ist, und der Schlüssel, mit dem die Nachricht vom Empfänger entschlüsselt und/oder mit dessen Hilfe deren Integrität geprüft wird, voneinander abweichen. Der Verdacht liegt insbesondere dann nahe, wenn, und so ist es aus Sicherheitsgründen durchaus sinnvoll, ein Geheimnis regelmäßig erneuert wird, also beispielsweise neu ausgetauscht bzw. neu ausgehandelt wird. Wenn bis zu diesem Zeitpunkt noch keine erfolgreiche Operation mit einem solchen erst kürzlich erneuerten Geheimnis durchgeführt worden ist, liegt der Verdacht des Fehlers sehr schnell beim Geheimnis. Wird das betroffene Geheimnis dann jedoch von mindestens einem der beteiligten Kommunikationspartner in einem sicheren System wie beispielsweise dem oben angesprochenen HSM aufbewahrt, lässt es sich jedoch nicht ohne weiteres nachprüfen, ob alle betroffenen Partner das gleiche Geheimnis verwenden. Der Wert dieses Geheimnisses, welches sicher in dem System abgelegt ist, lässt sich, und so ist es ja auch gedacht, nämlich nicht ohne weiteres auslesen. Damit ist das Auslesen auch in einer Debug-Situation trotz vollem Zugriff auf das System oder Gerät im Allgemeinen nicht möglich.
-
Ein möglicher Ansatz für eine solche Gleichheitsprüfung könnte an sich die Verwendung einer kryptografischen Hashfunktion sein. Es könnte dann anstelle des Geheimnisses selbst ein Hash auf dieses Geheimnis ausgelesen werden. Auf diese Weise lassen sich dann Hashwerte verschiedener Instanzen desselben Geheimnisses aus verschiedenen sicheren Systemen oder aus verschiedenen Systemen, von denen zumindest eines sicher ist, auslesen und anschließend auf Gleichheit prüfen, indem die Hashwerte verglichen werden. Dies hat den Vorteil, dass der Schlüssel bzw. das Geheimnis selbst nicht ausgelesen werden kann und typischerweise durch den kryptografischen Hashwert auch nicht auf dieses zurückgeschlossen werden kann.
-
Den gattungsgemäßen Stand der Technik bildet hier die
JP 2010 - 178 394 A1 . Darin werden Zertifikate über ihre Hashwerte auf Gleichheit geprüft.
-
Die
US 2017/0366527 A1 nutzt die Bildung von Hashwerten und ihren Vergleich zur Absicherung von Geheimnissen beim Provisioning und ermöglicht so das Schaffen eines Sicherheitsindikators, welcher im Falle der Gleichheit eines Vorgabewerts von extern und eines aus einem Schlüssel generierten Hashwerts ein „Sicher-Flag“ aktiviert.
-
Die Vorgehensweise ist jedoch insbesondere dann problematisch, wenn das betroffene Geheimnis, beispielsweise ein Passwort, nicht genug Entropie besitzt, weil es beispielsweise zu kurz ist oder bestimmte bekannte Muster aufweist. In diesem Fall ist es möglich, beispielsweise über gängige im IT-Bereich bekannte Angriffsmöglichkeiten, wie einen Brute-Force-Angriff, einen Wörterbuchangriff oder auch einen Angriff mit einer Rainbow-Tabelle, von dem Hashwert auf das Geheimnis schließen zu können.
-
Die Aufgabe der hier vorliegenden Erfindung ist es nun, ein geeignetes Verfahren zur Überprüfung von kryptografischen Geheimnissen auf Gleichheit anzugeben, bei welchen die Geheimnisse selbst geheim bleiben und dennoch bei hoher Sicherheit gegen externe Angriffe ein Vergleich von Geheimnissen möglich ist.
-
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1, und hier insbesondere im kennzeichnenden Teil des Anspruchs 1, gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Unteransprüchen.
-
Das erfindungsgemäße Verfahren zur Überprüfung von kryptografischen Geheimnissen auf Gleichheit nutzt dabei zumindest ein Geheimnis, das in einem sicheren System, welches gemäß einer außerordentlich günstigen Weiterbildung des erfindungsgemäßen Verfahrens als Hardware Security Modul (HSM) ausgebildet sein kann, lesegeschützt abgelegt ist. Das wenigstens eine sichere System, also beispielsweise das HSM, verfügt nun über eine Hashwert-Schnittstelle. Über diese Schnittstelle kann ein kryptografischer Hashwert des in dem sicheren System abgelegten Geheimnisses ausgelesen werden. Zusätzlich ist das sichere System in der Lage, vor dem Erstellen des Hashwerts das Geheimnis mit einem sogenannten Salt oder dem Hashwert eines solchen Salts zu versehen. Der kryptografische Hashwert wird dann von dem Geheimnis und dem hinzugefügten Salt oder seinem Hashwert erstellt, um so einen Angriff auf dieses Geheimnis beispielsweise über eine Rainbow-Tabelle entsprechend zu erschweren, da deren Erstellung dann extrem aufwändig und teuer werden würde, so dass sich dieser Aufwand nicht lohnt.
-
Besonders effizient ist es, wenn das Salt, welches ja per allgemeiner Definition einen nicht geheimen Wert darstellt, nicht von außen vorgegeben wird und vorzugsweise auch nicht für alle Abfragen feststeht. Das Salt sollte also nach Möglichkeit in dem sicheren System erstellt und dabei frei gewählt werden. Auf diese Weise lässt sich sicherstellen, dass das sichere System, in dem das Geheimnis gegen Auslesen gesichert gespeichert ist, jederzeit ausschließlich sichere Salts nutzt. Dabei ist es essentiell, dass die Salts immer eine ausreichende Länge haben und sich ausreichend unterscheiden.
-
Problematisch ist es nun, dass durch das Salt dann jedoch dem zu speichernden Geheimnis etwas hinzufügt wird, was in verschiedenen Systemen nicht zwingend gleich ist, und typischerweise nicht gleich sein wird, wenn das Salt jeweils vom System selbst vorgegeben ist. Die erhöhte Sicherheit stellt damit die Prüfung der Gleichheit in Frage. Erfindungsgemäß ist es deshalb vorgesehen, dass das Salt als mehrteiliges Salt aufgebaut wird, wobei ein Salt-Anteil von dem wenigstens einen sicheren System bestimmt wird und wobei die anderen Salt-Anteile an das sichere System übertragen werden.
-
Damit nutzt man einerseits die Möglichkeit, über das sichere System ein hinsichtlich bekannter Angriffe sehr sicheres Salt zu generieren, wobei dieses gemäß einer außerordentlich günstigen Weiterbildung des erfindungsgemäßen Verfahrens als eigenbestimmter Salt-Anteil immer neu und insbesondere immer über einen sicheren Zufallszahlengenerator erzeugt werden kann. Die anderen Salt-Anteile werden dann an das sichere System übertragen.
-
Eine sehr günstige Ausgestaltung des erfindungsgemäßen Verfahrens kann es ferner vorsehen, dass der vom sicheren System eigenbestimmte Salt-Anteil vor der Bildung des Hashwerts des Geheimnisses offengelegt wird. Hierdurch ist der vorzugsweise jeweils für die jeweilige Situation erzeugte Salt-Anteil des sicheren Systems, beispielsweise für eine vergleichende Instanz, bekannt, welche wiederum die fremdbestimmten Anteile an das sichere System übertragen kann.
-
Eine weitere sehr günstige Ausgestaltung sieht es dabei vor, dass die Reihenfolge, in welcher die Anteile des Salts und das Geheimnis konkateniert werden, im sicheren System festgelegt oder diesem von außen vorgegeben wird. Diese Reihenfolge des Geheimnisses und der Anteile des Salts hat entscheidenden Einfluss auf den Hashwert der Kombination aus Salt und Geheimnis. Die Reihenfolge kann dabei beispielsweise von außen vorgegeben werden, wobei theoretisch immer dieselbe Reihenfolge verwendet werden kann, beispielsweise eigenbestimmtes Salt, fremdbestimmtes Salt und Geheimnis in dem einen System und dementsprechend ein Aufbau mit umgekehrter Reihenfolge der Salt-Anteile in dem anderen System, sodass von beiden Systemen der gleiche kryptografische Hashwert für die Kombination aus Geheimnis und Salt-Anteilen generiert wird und zuverlässig verglichen werden kann.
-
Eine sehr günstige Ausgestaltung sieht es dabei vor, dass das Salt selbst als zweiteiliges Salt mit einem eigenbestimmten Salt-Anteil und einem fremdbestimmten Salt-Anteil ausgebildet ist. In diesem Fall ist der Vergleich von zwei Geheimnissen möglich, wobei das Verfahren beliebig oft wiederholt werden kann, um beispielsweise mehrere Geheimnisse von mehreren beteiligten Instanzen, insbesondere im Rahmen eines Debugging-Prozesses, untereinander abzugleichen.
-
Bei der Überprüfung mehrerer in verschiedenen sicheren Systemen abgelegter Geheimnisse auf Gleichheit kann gemäß einer außerordentlich günstigen Weiterbildung des erfindungsgemäßen Verfahrens nun so vorgegangen werden, dass bei einem ersten System dessen eigenbestimmter Salt-Anteil angefragt wird, wonach dieser an ein weiteres System übermittelt wird, welches seinen eigenbestimmten Salt-Anteil zusammen mit einem Hashwert seines Geheimnisses und der beiden Salt-Anteile übermittelt, wobei der eigenbestimmte Salt-Anteil des weiteren Systems als fremdbestimmter Salt-Anteil an das erste System zurückgemeldet wird, welches seinerseits einen Hashwert aus seinem Geheimnis und den beiden Salt-Anteilen ermittelt, wonach die Hashwerte, die von beiden Systemen übermittelt wurden, verglichen werden. Somit kann sicher und effizient, insbesondere in der schon mehrfach angesprochenen Debugging-Prozedur, die Gleichheit der Geheimnisse überprüft werden.
-
Insbesondere hier lässt sich gemäß einer sehr vorteilhaften Weiterbildung der erfindungsgemäßen Lösung nun anstelle des Salts ein Hashwert der konkatenierten Salt-Anteile verwenden. Das Geheimnis wird dann mit diesem Hashwert der bereits konkatenierten und gehashten Salt-Anteile versehen und erneut gehasht. Der Vergleich erfolgt auf Basis dieses zweiten Hashwerts. Dies kann die Sicherheit gegenüber Chosen Plaintext Angriffen erhöhen.
-
Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens kann es vorgesehen sein, dass in der Reihenfolge der Konkatenationen des ersten Systems die Salt-Anteile gegenüber der des weiteren Systems getauscht werden, womit also zumindest das erste System die Reihenfolge als Fremdvorgabe übermittelt bekommt. Die Reihenfolge ist dann also immer die von dem jeweiligen sicheren System aus „gesehene“ Reihenfolge. Sofern eine feste Reihenfolge der Konkatenation festgelegt ist, kann dies entsprechend ohne weitere Maßnahmen durchgeführt werden. Vorzugsweise kann gemäß einer sehr vorteilhaften Weiterbildung dieser Idee das weitere System die Reihenfolge selbst festlegen und entsprechend offenlegen, beispielsweise zusammen mit seinem eigenbestimmten Salt-Anteil und dem Hashwert des Geheimnisses und der beiden Salt-Anteile übermitteln. Diese Reihenfolge, welche von dem weiteren System eigenbestimmt ist, dient dann als fremdvorgegebene an das erste System übermittelte Reihenfolge. Wird dabei die Reihenfolge der Salt-Anteile aus Sicht des jeweiligen sicheren Systems gegeneinander vertauscht, ist in jedem Fall sichergestellt, dass bei höchster denkbarer Sicherheit die kryptografischen Hashwerte der Geheimnisse mit den beiden Salt-Anteilen übereinstimmen, wenn die Geheimnisse in den beiden sicheren Systemen dies ebenfalls tun. Dabei ist es entsprechend vorgesehen, dass immer eigenbestimmte Salt-Anteile, vorzugsweise ausreichender Länge und/oder Entropie, erzeugt und genutzt werden, sodass quasi der fremdvorgegebene Salt-Anteil für das eine System der eigenerzeugte Salt-Anteil des anderen Systems ist, um so keine fixen Werte und gänzlich von extern stammende Vorgaben für die Salts zu erlauben, was die Sicherheit des Verfahrens weiter erhöht.
-
Durch diese Verwendung eines eigenbestimmten Salt-Anteils ist es möglich, die Kategorie der sogenannten Chosen-Plaintext-Angriffe zu verhindern, da solche potenziellen Chosen-Plaintext-Angriffe durch die Verwendung eigenbestimmter Salt-Anteile schwieriger werden. Auch andere Angriffsmöglichkeiten werden dadurch massiv eingeschränkt, beispielsweise eine Attacke über eine Rainbow-Tabelle, da eine solche für jeden Salt eine eigene Rainbow-Tabelle benötigen würde, was alleine aus Gründen der Wirtschaftlichkeit kaum realisierbar ist, insbesondere dann, wenn das eingesetzte Salt bzw. seine Anteile eine ausreichende Länge bzw. Entropie mitbringen.
-
Anstelle einer konventionellen kryptografischen Hashfunktion, um den Hashwert des Geheimnisses und der Salt-Anteile zu ermitteln, kann dabei gemäß einer außerordentlich günstigen Weiterbildung des erfindungsgemäßen Verfahrens eine komplexe, auf Hashfunktionen basierende kryptografische Einwegfunktion verwendet werden, beispielsweise ein HMAC oder eine sogenannte Key Derivation Function (KDF). Der Hashwert wird dann über diese Funktion entsprechend berechnet, was gegenüber einer herkömmlichen Berechnung von Hashwerten, beispielsweise über SHA-256, weitere Sicherheitsvorteile mit sich bringt.
-
Dabei lassen sich jeweils zwei Geheimnisse über die Hashwerte der jeweiligen Geheimnisse und Salts miteinander vergleichen. Für mehrere Geheimnisse ließe sich das dann iterativ wiederholen. Es ginge aber auch mit dem Verfahren direkt drei oder mehr Geheimnisse zu vergleichen. Aufgrund der mit einer höheren Zahl der Geheimnisse immer größer werdenden Menge der Möglichkeiten die Geheimisse und Salts bzw. Salt-Anteile zu konkatenieren, kommt dann der hier vorzugsweise festgelegten Reihenfolge der Konkatenation und ihrer Umsetzung in den jeweils beteiligten sicheren Systemen eine zunehmende Bedeutung zu.
-
Eine weitere sehr günstige Ausgestaltung des erfindungsgemäßen Verfahrens sieht es ferner vor, dass eine sichere Konfigurationsmöglichkeit für die einzelnen Teilfunktionen der kryptografischen Hash-Schnittstelle in dem sicheren System, beispielsweise dem HSM, vorgesehen ist, über welche zumindest die nachfolgenden Einstellungen manipulationssicher konfiguriert werden können. Diese Einstellungen sollen zumindest eine oder vorzugsweise alle der Fragen umfassen:
- - wird ein eigenbestimmter Salt-Anteil genutzt?
- - wird der eigenbestimmte Salt-Anteil der Umgebung vor Erstellen des Hash-Werts offengelegt?
- - wird ein fremdbestimmter Salt-Anteil benutzt?
- - wie viele fremdbestimmte Salt-Anteile werden benutzt?
- - wird die Reihenfolge der Konkatenation in dem sicheren System festgelegt oder kann sie von außen vorgegeben werden?
- - kommt bei der Reihenfolge der Konkatenation das Geheimnis immer an einer vorgegebenen Stelle, insbesondere zuerst?
- - wird der aus den konkatenierten Salt-Anteilen bestehende Salt vorab gehasht?
- - wird das Geheimnis vorab gehasht?
-
Über diese verschiedenen Festlegungen lassen sich die Systeme zur Nutzung mit dem erfindungsgemäßen Verfahren beispielsweise aneinander oder an eine vorgegebene Prüfungsstrategie entsprechend anpassen. Je nach Konfiguration der entsprechenden Schnittstelle können so an sich identisch aufgebaute Systeme alleine durch die Konfiguration nochmals unterschiedlich gestaltet werden, was die Sicherheit noch weiter erhöht. Insbesondere die letzte Frage könnte dabei entfallen, z.B. wenn das vorab Hashen der Geheimnisse als die übliche Vorgehensweise vorab festgelegt wird.
-
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich außerdem aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figuren näher beschrieben sind.
-
Dabei zeigen:
- 1 eine schematische Darstellung geteilter Geheimnisse in einem Fahrzeug-Ökosystem;
- 2 eine schematische Darstellung des Ablaufs in einem ersten Ausführungsbeispiel des erfindungsgemäßen Verfahrens; und
- 3 eine schematische Darstellung eines alternativen Ablaufs des erfindungsgemäßen Verfahrens.
-
In der Darstellung der 1 ist ein Fahrzeug-Ökosystem 1 beziehungsweise ein Ausschnitt aus einem solchen schematisch dargestellt. Der gezeigte Ausschnitt umfasst zwei beispielhafte Fahrzeuge V1 und V2, welche jeweils über zwei Steuergeräte ECU1 und ECU2 verfügen. Daneben ist ein Vehicle Backend B angedeutet, welches häufig auch verkürzt als Backend bezeichnet wird. Das Backend B ist nun in der Lage mit den Fahrzeugen V1, V2 beziehungsweise ihren Steuergeräten ECU1, ECU2 zu kommunizieren. Es verfügt dafür über ein sicheres System in Form eines Hardwaresicherheitsmoduls HSM, in welchem in diesem Ausführungsbeispiel zwei Geheimnisse SEC3 und SEC4 entsprechend abgelegt sind. In den beiden Fahrzeugen V1, V2 ist es so, dass dort die dazu korrespondierenden Geheimnisse SEC5 und SEC6 beispielsweise in dem jeweils zweiten Steuergerät ECU2, in dortigen Hardwaresicherheitsmodulen HSM3 und HSM4 abgelegt sind. In dem hier dargestellten Ausführungsbeispiel des Ausschnitts aus dem Fahrzeug-Ökosystem 1 sollen die beiden Fahrzeuge V1, V2 auch in der Lage sein untereinander zu kommunizieren. Hierfür dienen rein beispielhaft die beiden ersten Steuergeräte ECU1 mit ihren Hardwaresicherheitsmodulen HSM1 im ersten Fahrzeug V1 und HSM2 im zweiten Fahrzeug V2. Die korrespondierenden Geheimnisse sind dann mit SEC1 und SEC2 bezeichnet.
-
Kommt es nun zu einer Schwierigkeit in einer der Kommunikationen, welche sich auf die kryptografischen Verfahren zurückführen lässt, dann kann immer auch ein Problem bei dem jeweiligen Geheimnis SEC1, SEC2 vorliegen. Für das nachfolgende Ausführungsbeispiel soll daher erläutert werden, wie einfach, sicher und dennoch effizient die beiden Geheimnisse SEC1 und SEC2 in den jeweiligen Hardwaresicherheitsmodulen HSM1 und HSM2 der Steuergeräte ECU1 der beiden Fahrzeuge V1, V2 auf Gleichheit überprüft werden können, ohne dabei die Geheimnisse SEC1, SEC2 selbst auslesen zu müssen, was in sicheren Systemen typischerweise, auch im Falle eines vollen Zugriffs während eines Debugging-Prozesses, nicht möglich ist.
Anstatt die Geheimnisse SEC1, SEC2 selbst auszulesen, werden daher Hashwerte HASH1, HASH2 dieser Geheimnisse SEC1, SEC2 ausgelesen. Zur Erzeugung der Hashwerte HASH1, HASH2 können gängige Funktionen zur Erzeugung von Hashwerten eingesetzt werden, beispielsweise SHA-256. Anstelle einer solchen konventionellen kryptografischen Hashfunktion, welche nachfolgend für die Beschreibung der Ausführungsbeispiele genutzt wird, kann jedoch auch eine komplexere auf kryptografischen Hashfunktionen basierende kryptografische Einwegfunktion Verwendung finden. Beispielsweise HMAC oder eine Key Derivation Function KDF. In diesem Fall würde beispielsweise an die Stelle der Ermittlung eines Hashs aus einem Geheimnis und einem Salt HASH(SEC||SALT) die Funktion HMAC(SEC, SALT) oder KDF(SEC,SALT, Iterations) treten. Unter den Iterations ist dabei eine freigewählte natürliche Zahl zu verstehen, die die Anzahl der Anwendungswiederholungen der Key Derivation Function entsprechend festlegt.
-
Im Nachfolgenden anhand der 2 beschriebenen Ausführungsbeispiel soll nun ein Geheimnis SEC1, SEC2 in zwei verschiedenen Hardwaresicherheitsmodulen, HSM1, HSM2, auf Gleichheit überprüft werden. Dazu dient eine in der Darstellung der 2 mit 3 bezeichnete Prüfeinheit. Die beiden Hardwaresicherheitsmodule HSM1, HSM2 besitzen dabei jeweils eine Hashwert-Schnittstelle 2, welche jeweils alle der obigen Eigenschaften implementiert hat beziehungsweise entsprechend diesen konfiguriert werden kann. Über diese Schnittstelle 2 wird also sowohl die Vorabfrage des eigenbestimmten Salt-Anteils als auch die Möglichkeit der Festlegung der Reihenfolge der Konkatenation der Salt-Anteile ermöglicht. Die Prüfeinheit 3 bezeichnet dann ein System, welches dazu ausgelegt ist, die in den beiden Hardwaresicherheitsmodulen HSM1, HSM2 abgelegten Geheimnisse SEC1, SEC2 auf Gleichheit zu prüfen.
-
Der Ablauf im Detail ist dabei der folgende und findet sich so auch in der Darstellung der 2 durch die entsprechenden Kommunikationspfeile zwischen der Prüfeinheit 3 und den Schnittstellen 2 beziehungsweise den mit ihnen ausgestatteten Hardwaresicherheitsmodulen HSM1 und HSM2 wieder.
- 1. Die Prüfeinheit 3 übermittelt gleichzeitig an das Hardwaresicherheitsmodul HSM1 und an das Hardwaresicherheitsmodul HSM2 den Bezeichner sec des jeweiligen Geheimnisses SEC1, SEC2, dessen Hashwert sie zum Überprüfen der Gleichheit der Geheimnisse SEC1, SEC2 erhalten möchte. Außerdem wird die Aufforderung übermittelt, den jeweils zu verwendenden Eigenanteil des Salts offenzulegen.
- 2. Die beiden Hardwaresicherheitsmodule HSM1 und HSM2 generieren jeweils einen neuen zufälligen Salt-Eigenanteil ausreichender Länger, beispielsweise mit jeweils 256 Bit. Die Eigenanteile SALT1 des Hardwaresicherheitsmoduls HSM1 und SALT2 des Hardwaresicherheitsmoduls HSM2 werden dann an die Prüfeinheit 3 übertragen, wie es in der Darstellung der 2 zu erkennen ist.
- 3. Die Prüfeinheit 3 legt fest, in welcher Reihenfolge R die Salt-Anteile konkateniert werden sollen. F steht dabei für den fremdbestimmten Salt-Anteil, E für den eigenbestimmten Salt-Anteil.
- 4. Die Prüfeinheit 3 übermittelt die jeweils fremdbestimmten Salt-Anteile SALT2, SALT1 an das jeweilige Hardwaresicherheitsmodul HSM1, HSM2. Das Hardwaresicherheitsmodul HSM1 erhält also den vom Hardwaresicherheitsmodul HSM2 eigenbestimmten Salt-Anteil SALT2 als fremdbestimmten Salt-Anteil übermittelt. Dazu die Reihenfolge der Konkatenation, hier also R(F, E). Das andere Hardwaresicherheitsmodul HSM2 bekommt dementsprechend den Salt-Eigenanteil SALT1 des ersten Hardwaresicherheitsmoduls HSM1 als Salt-Fremdanteil F übermittelt und dementsprechend die umgedrehte Reihenfolge R der Salt-Anteile, da für das zweite Hardwaresicherheitsmodul HSM2 SALT2 der Salt-Eigenanteil E ist.
- 5. Das erste Hardwaresicherheitsmodul HSM1 bildet nun einen Hashwert mit der Konkatenation entsprechend der vorgegebenen Reihenfolge R, also HASH1:=HASH(SEC1 ||SALT2||SALT1). Das zweite Hardwaresicherheitsmodul HSM2 ermittelt seinen Hashwert HASH2:=HASH(SEC2||SALT2||SALT1). Diese beiden Hashwerte HASH 1 und HASH2 werden dann an die Prüfeinheit 3 übermittelt.
- 6. Die Prüfeinheit 3 prüft die beiden empfangenen Hashwerte HASH1 und HASH2 auf Gleichheit. Die beiden Geheimnisse SEC1 und SEC2 sind genau dann gleich, wenn es auch die empfangenen Hashwerte HASH1, HASH2 sind. Kommt es hier zu Abweichungen, sind die Geheimnisse SEC1, SEC2 offensichtlich nicht gleich und der Fehler, nach welchem gesucht worden ist, lässt sich im Bereich dieser Geheimnisse SEC1, SEC2 orten.
-
Das nachfolgende zweite Ausführungsbeispiel ist im Wesentlichen analog aufgebaut. Jeweils ein Geheimnis SEC1, SEC2 mit dem Bezeichner sec ist in jeweils einem Hardwaresicherheitsmodul HSM1, HSM2 abgelegt. Dabei ist es so, dass nur das erste Hardwaresicherheitsmodul HSM1 über die Schnittstelle 2 verfügt, die alle der oben genannten Eigenschaften implementiert hat, insbesondere also sowohl die Vorabfrage des verwendeten eigenbestimmten Salt-Anteils als auch die Möglichkeit der Festlegung der Reihenfolge der Konkatenation der beiden Salt-Anteile erlaubt. Das weitere Hardwaresicherheitsmodul HSM2 ist hingegen über eine einfachere Schnittstelle 4 nur in der Lage einen fremdbestimmten Salt-Anteil entgegenzunehmen und diesen sofort zu verarbeiten, wenn die Reihenfolge R der Konkatenation zuvor festgelegt ist, beispielsweise Salt-Eigenanteil, Salt-Fremdanteil R(E,F) mit vorausgestelltem Geheimnis aus Sicht des zweiten Hardwaresicherheitsmoduls HSM2. 3 beschreibt dann den Ablauf analog zur Darstellung in 2 im Detail.
- 1. Die Prüfeinheit 3 übermittelt an das erste Hardwaresicherheitsmodul HSM1 den Bezeichner sec des Geheimnisses SEC1, dessen Hashwert HASH1 sie erhalten möchte, zusammen mit der Aufforderung, den zu verwendenden Salt-Eigenanteil SALT1 offenzulegen.
- 2. Das erste Hardwaresicherheitsmodul HSM1 generiert einen neuen zufälligen Salt-Eigenanteil SAL T1 ausreichender Länge und liefert ihn an die Prüfeinheit 3.
- 3. Die Prüfeinheit 3 übermittelt dem zweiten Hardwaresicherheitsmodul HSM2 den Bezeichner sec des Geheimnisses SEC2, dessen Hashwert sie erhalten möchte, zusammen mit dem vom ersten Hardwaresicherheitsmodul HSM1 empfangenen Salt-Eigenanteil SALT1 und der Aufforderung, den Hashwert zu berechnen und diesen samt des dazu verwendeten Salt-Eigenanteils SALT2 zu übermitteln.
- 4. Das zweite Hardwaresicherheitsmodul HSM2 generiert einen neuen zufälligen Salt-Eigenanteil SALT2 ausreichender Länge, berechnet den angeforderten Hashwert als HASH2:=HASH(SEC2||SALT2||SALT1) und übermittelt den Hashwert HASH2 zusammen mit dem bei dessen Berechnung verwendeten Salt-Eigenanteil SALT2 an die Prüfeinheit 3.
- 5. Die Prüfeinheit 3 übermittelt nun an das erste Hardwaresicherheitsmodul HSM1 den zu verwendenden Salt-Fremdanteil SALT2 und die zu verwendende Reihenfolge R der Konkatenation R(F, E), dieses Mal aus Sicht des ersten Hardwaresicherheitsmoduls HSM1, also mit vertauschtem Salt-Fremdanteil und Salt-Eigenanteil.
- 6. Das erste Hardwaresicherheitsmodul HSM1 berechnet seinen Hashwert HASH1: =HASH(SEC1||SALT2||SALT1) und übermittelt diesen Hashwert HASH1 an die Prüfeinheit 3.
- 7. Die Prüfeinheit 3 prüft die beiden empfangenen Hashwerte HASH1 und HASH2 auf Gleichheit. Die Geheimnisse SEC1 und SEC2 sind genau dann gleich, wenn die empfangenen Hashwerte HASH1, HASH2 es ebenfalls sind, vergleichbar wie oben.