-
Aufgabenstellung
-
In vielen unterschiedlichen Verfahren nach dem Stand der Technik prüft ein Hauptgerät, ob eine Komponente zu einer Prüfungsfrage (Challenge) eine gültige Lösung (Response) findet zu dessen Authentifizierung. Die folgenden Schritte beschreiben einen allgemeinen Ablauf eines solchen Verfahrens:
- a) Speicherung einer Liste von mindestens einem Datenpaar, bestehend aus einer Prüfungsaufgabe und einer Referenzlösung, durch das Hauptgerät vor seiner Inbetriebnahme,
- b) Auswahl eines ersten gespeicherten Datenpaars, bestehend aus einer ersten Prüfungsaufgabe und einer ersten Referenzlösung durch das Hauptgerät und Senden der ersten Prüfungsaufgabe an die Komponente,
- c) Generierung einer ersten Lösung durch die Komponente und Senden der ersten Lösung an das Hauptgerät,
- d) Empfang einer ersten Lösung durch das Hauptgerät oder Abbruch der Authentifizierung bei Überschreitung eines Zeitlimits,
- e) Vergleich der ersten Lösung mit der ersten Referenzlösung im Hauptgerät,
- f) erste Entscheidung des Hauptgeräts zur Freischaltung der Hauptfunktion, dem Abbruch der Authentifizierung oder zur Durchführung zusätzlicher Schritte,
- g) Auswahl eines zweiten gespeicherten Datenpaars, bestehend aus einer zweiten Prüfungsaufgabe und einer zweiten Referenzlösung durch das Hauptgerät und Senden der zweiten Prüfungsaufgabe an die Komponente,
- h) Generierung einer zweiten Lösung durch die Komponente und Senden der zweiten Lösung an das Hauptgerät,
- i) Empfang einer zweiten Lösung durch das Hauptgerät oder Abbruch der Authentifizierung bei Überschreitung eines Zeitlimits,
- j) Vergleich der zweiten Lösung mit der zweiten Referenzlösung im Hauptgerät,
- k) zweite Entscheidung zur Freischaltung der Hauptfunktion durch das Hauptgerät
-
Zielsetzung der Authentifizierung ist beispielsweise die Erkennung gefälschter Komponenten. Dabei lassen sich Hauptgeräte in zwei Klassen unterteilen:
- In die erste Klasse fallen Hauptgeräte, die in der Lage sind, zu einer zufällig erzeugten Prüfungsfrage (Challenge) eine empfangene Lösung (Response) zu überprüfen.
- In die zweite Klasse fallen Hauptgeräte, die statt dessen auf gespeicherte Datenpaare, bestehend aus Prüfungsaufgabe und Referenzlösung zugreifen müssen.
-
Bei einem kryptographischen Verfahren bestehen für die Implementierung der Hauptgeräte beide Möglichkeiten: das Hauptgerät kann entweder mit einem geeigneten kryptographischen Schlüssel oder mit einer Liste von Datenpaaren (Challenge-Response-Liste) versehen werden. Bei symmetrischen Verfahren ist der erste Ansatz flexibler, der zweite allerdings sicherer, weil ein Hauptgerät nicht zur Kompromittierung eines geheimen Schlüssels missbraucht werden kann.
-
Bei Verfahren, die auf inhärenten Gruppen-Merkmalen von Schaltkreisen und der beschränkten Verfügbarkeit dieser Schaltkreise basieren (ein solches Verfahren ist z.B. in der noch unveröffentlichten Druckschrift
DE 10 2018 009 143 A1 beschrieben), ist ebenfalls beides möglich: ein Hauptgerät der ersten Klasse muss über eine integrierte, authentische Schaltkreis-Instanz zu Erzeugung von Referenz-Lösungen verfügen. Eine solche Implementierung ist allerdings teurer als eine Implementierung mittels gespeicherter Datenpaare.
-
Bei Verfahren, die auf inhärenten Merkmalen einzelner Hardware-Instanzen basieren, z.B. nicht-kryptographische PUF-Lösungen [Pa], fallen die Hauptgeräte stets in die zweite Klasse. Zusammengefasst sind Hauptgeräte der zweiten Klasse für die Authentifizierung einer Komponente entweder bezüglich der Sicherheit oder des Preises von Vorteil, oder sie sind sogar die einzige Möglichkeit der Wahl.
-
Ein Nachteil von Hauptgeräte der zweiten Klasse, insbesondere im Offline-Einsatz besteht darin, dass Datenpaare nur begrenzt zur Verfügung stehen. Um den Verbrauch von Datenpaaren einzuschränken, stellt sich die Frage, ob das Hauptgerät ein gespeichertes Datenpaar zur Authentifizierung angeschlossener Komponenten mehrfach benutzen kann und wenn ja, wie häufig.
-
Ziel des offen gelegten Verfahrens ist es, unter der nachfolgenden Annahmen die Wiederverwendung gespeicherte Datenpaare zu maximieren, ohne die Sicherheit im Vergleich zu einmalig genutzten Datenpaaren einzuschränken.
-
Das offen gelegte Verfahren eignet sich dann zu Authentifizierung, wenn Hauptgerät und Komponente in einer „freundlichen Umgebung“ zum Einsatz kommen, d.h. wenn die Authentifizierung unter Aufsicht des Benutzers stattfindet und der Benutzer selbst kein Hacker ist. Unter dieser Annahme erhalten Angreifer oder böswillige Geräte keinen physikalischen Zugriff auf die Datenschnittstelle zwischen Hauptgerät und Komponente. Ein sogenannter „Replay“-Angriff, bei welchem in einem ersten Schritt die Kommunikation bei der Prüfung einer authentischen Komponente durch das Hauptgerät an dieser Datenschnittstelle mitgelesen wird und später, im zweiten Schritt die mitgeschnittene Lösung in der Prüfung einer böswilligen Komponente als Antwort auf die selbe Prüfungsaufgabe wieder eingespielt wird, kommt damit nicht in Betracht. Ein Anwendungsfall auf den die Annahme zutrifft ist die Erkennung gefälschter Zubehörkomponenten, sofern die Erkennung auch im Interesse des Käufers liegt.
-
Um ein Authentifizierungsverfahren mit einer beschränkten Liste gespeicherter Challenge-Response-Paare sicher zu gestalten, muss das Hauptgerät Informationen zur Testhistorie speichern und bei der Auswahl eines Challenge-Response-Paars für einen anstehenden Challenge-Response-Test berücksichtigen. Zur Testhistorie kann das Hauptgerät z.B. die Information nachhalten, ob die zuletzt durchgeführte Authentifizierung einer Komponente erfolgreich oder erfolglos war. Als zweites Besipiel zur Testhistorie kann das Hauptgerät zu jedem Challenge-Response-Paar ein Attribut speichern, welches anzeigt, ob das Challenge-Response-Paar „fehlerfrei“ oder „fehlerbehaftet“ ist. „Fehlerfrei“ bedeutet, dass in jedem vorangegangenen Test einer Komponente mit dem selben Challenge-Response-Paar nach dem Senden der Challenge die Response innerhalb eines festgelegten Zeitlimits eingetroffen ist und mit dem gespeicherten Referenzwert übereingestimmt hat.
-
Stand der Technik
-
Druckschrift D1 beschreibt Merkmale eines Verfahrens zur Authentifizierung einer Komponente („Authentication Device“) durch ein Hauptgerät („Interrogator Device“), welche sich in folgenden Aspekten mit der vorliegenden Erfindung überschneidet: der Verwaltung von Challenge-Response-Paaren durch das Hauptgerät, der Verwendung von einem oder mehrerer Challenge-Response-Tests zur Authentifizierung einer Komponente, der mehrfachen Verwendung von Challenge-Response-Paaren und der Auswahl des Challenge-Response-Paars zu einem Challenge-Response-Test abhängig von einer durch das Hauptgerät nachgehaltenen Testhistorie. D1 soll gewährleisten, dass ein Angreifer, der die Datenschnittstelle während der Kommunikation zwischen authentischen Geräten abhören kann, möglichst lange braucht, um alle gespeicherten Challenge-Response-Paare zu erlernen. Dazu schränkt das Hauptgerät die Auswahlwahrscheinlichkeiten bestimmter Challenge-Response-Paare ein. D1 legt dem Hauptgerät nahe, insbesondere dann, wenn es einen Angriff vermutet (z.B. wegen häufiger Authentifizierungs-Anforderungen innerhalb eines Zeitfensters), möglichst wenig frische Challenge-Response-Paare einzusetzen und statt dessen fehlerbehaftete Challenge-Response-Paare wiederzuverwenden.
-
Im Gegensatz zur vorliegenden Druckschrift liefert D1 kein hinreichendes Kriterium, nach welchem eine Komponente nach einem oder mehreren Challenge-Response-Tests freizuschalten ist. D1 gibt insbesondere keine Situation an, in welcher ein fehlerfreies Challenge-Response-Paar genutzt werden soll.
-
Die vorliegende Erfindung liefert als Neuerung eine genaue Anweisung, wann ein fehlerfreies Challenge-Response-Paar in einem Challenge-Response-Test zum Einsatz kommt (sofern ein oder mehrere gespeicherte Challenge-Response-Paare fehlerbehaftet sind): genau dann, wenn die zuletzt durchgeführte Authentifizierung einer Komponente nicht erfolgreich, und erst nachdem ein erster Challenge-Response-Test mit einem fehlerbehafteten Challenge-Response-Paar erfolgreich war. Dieses Merkmal geht aus D1 nicht naheliegend hervor. Sie liefert einen erheblichen Sicherheitsvorteil.
-
Druckschrift D2 beschreibt ein Challenge-Response-Protokoll zwischen einem Hardware-Token und einem nicht vertrauenswürdigen Gerät, bei welchem das Hardware-Token - in Überschneidung mit Merkmalen der vorliegenden Erfindung - eine Response innerhalb einer festgelegten Response-Zeit erwartet, um gewisse Aktionen des nicht vertrauenswürdigen Geräts zu authentifizieren.
-
Auch aus der Kombination der Druckschriften D1 und D2 geht die genannte Neuerung der vorliegenden Erfindung nicht in naheliegender Weise hervor.
-
Naheliegende Verfahren
-
Naheliegende Verfahren zur Reduzierung des Verbrauchs an Datenpaaren wären zum Beispiel:
- - Verfahren, bei welchen das Hauptgerät immer das selbe Datenpaar einsetzt,
- - Verfahren, bei welchen das Hauptgerät ein Datenpaar zeitlich begrenzt einsetzt,
- - Verfahren, bei welchen das Datenpaar direkt nach einer falschen Lösung gewechselt wird.
-
Um die Schwächen des Stands der Technik und naheliegender Verfahren zu verdeutlichen, genügt es, nicht-authentischen Komponenten in zwei extremen Ausprägungen zu betrachten:
- Bei starken böswillige Komponenten ist davon auszugehen, dass sie die Lösung zu einer unbenutzten Prüfungsaufgabe genau im zweiten Versuch finden. Hardware-inhärente Authentisierungsmerkmale nach dem SIMPL-Paradigma [SIMPL] gehen grundsätzlich davon aus, dass böswillige Komponenten so stark sind, weil sie authentische Komponenten verlangsamt simulieren können. Die Annahme ist allerdings auch für kryptographische Verfahren zweckmäßig, da sie viele Angriffe implizit modelliert: „Relay“-Angriffe (nicht zu verwechseln mit „Replay“-Angriffen), bei welchen die böswillige Komponente gegenüber einer authentische Komponente ein Hauptgerät vorspielt, um an eine gültige Lösung zu einer empfangenen Prüfungsaufgabe zu kommen oder Angriffe mittels Verbindung zu einem Backend Server.
-
Bei schwachen böswilligen Komponenten ist davon auszugehen, dass sie die Lösung nie finden.
-
Die ersten beiden naheliegenden Verfahren sind nicht sicher gegen starke böswillige Komponenten. Das dritte naheliegende Verfahren löst die Aufgabenstellung nicht: Eine schwache böswillige Komponente könnte zu einem sogenannten „Denial-of-Service“-Angriff eingesetzt werden, mit dem Ziel ein Hauptgerät durch einen provozierten schnellen Verbrauch seiner gespeicherten Datenpaare außer Kraft zu setzten.
-
Idee
-
Die Lösung basiert auf der Äquivalenz von bislang unbenutzten Datenpaaren und „fehlerfreien“ Datenpaaren, d.h. solchen, die noch nie zu einer falschen Lösung geführt haben. Unter den beiden genannten Annahmen lässt sich ableiten, dass eine starke böswillige Komponente nicht in der Lage ist, zur Prüfungsaufgabe eines fehlerfreien Datenpaars innerhalb des zulässigen Zeitrahmens eine gültige Antwort zu finden. Solange ein Datenpaar fehlerfrei ist, dient es zur Komponenten-Authentifizierung mittels einer einzigen Prüfung.
-
Nach einem negatives Prüfungsergebnis sollte das Datenpaar nicht mehr alleine zur Komponenten-Authentifizierung genutzt werden. Falls eine starke böswillige Komponente der Empfänger war, muss davon ausgegangen werden, dass diese bis zur nächsten Prüfung die Lösung ermitteln kann.
-
Das Datenpaar erfüllt allerdings immer noch den Zweck, schwache böswillige Komponenten zu erkennen, ohne ungenutzte Datenpaare zu verschwenden. Das fehlerbehaftete Datenpaar kann so lange eingesetzt werden, bis eine korrekte Lösung zu seiner Prüfungsaufgabe innerhalb eines gesetzten Zeitlimits eintrifft. Dann wird davon ausgegangen, dass böswillige Komponenten die Lösung kennen.
-
Es muss eine zweite Prüfung mit einem fehlerfreien Datenpaar folgen, um zwischen einer authentischen und einer starken böswilligen Komponente zu unterscheiden.
-
Technische Ausführung
-
Die Speicherung von Datenpaaren vor der Inbetriebnahme in Schritt a) geschieht typischerweise in einer geschützten Umgebung des Herstellers. Ein Referenzgerät verfügt über einen Zufallszahlengenerator, um zufällige Prüfungsaufgaben zu erzeugen und nutzt angeschlossene Komponenten als Generator für Referenzlösungen. Die gebildeten Datenpaare bestehend aus Prüfungsaufgabe und Referenzlösung werden auf einem Server gespeichert.
-
Der Server dient dem Einbringen von Datenpaaren in die Hauptgeräte in der Herstellerumgebung. Jedes Datenpaar wird nur in ein Hauptgerät eingebracht und anschließend Server-seitig gelöscht.
-
Bei Online-Applikationen dient der Server auch zum Update von Datenpaaren für Hauptgeräte im Feld über ein geeignetes Update-Protokoll. Der Online-Update erfordert die verschlüsselte Datenübertragung zwischen Server und Hauptgerät.
-
In der einfachsten Ausführung speichert das Hauptgerät Datenpaaren als Folge D[1],D[2], ...,D[M], wobei M die maximale Anzahl der speicherbaren Datenpaare ist. Ein Datenpaar D besteht aus einer Prüfungsaufgabe P und einer Referenzlösung R.
-
Die Datenpaare kommen nacheinander zur Prüfung von Komponenten zum Einsatz.
-
Eine Zeigervariable Z zeigt auf das aktuelle Datenpaar D[Z]. Die Auswahl eines Datenpaars in den Schritten b) und g) ist in der einfachsten Ausführung durch den aktuellen Wert von Z vorgegeben.
-
Eine binäre Variable L zeigt mit dem Wert 0 bzw. 1 an, dass die zuletzt durchgeführte Authentifizierung einer Komponente positiv bzw. negativ verlaufen ist. Sie entspricht der ersten Information aus Anspruch 1 (I). Die zweite Information aus Anspruch 1 (m) ist in dieser Ausführung in Z und L enthalten: Die Paare D[1],..., D[Z-1] sind fehlerbehaftet. Das Paar D[Z] ist fehlerfrei, wenn L null ist. Die Paare D[Z+1],..., D[M] sind unbenutzt und fehlerfrei.
-
Die Authentifizierung einer angeschlossenen Komponente lässt sich in der einfachsten Ausführung wie in Zeichnung 1 dargestellt realisieren: Nach dem Empfang eines Signals „aufwachen“ (101) führt das Hauptgerät direkt eine Prüfung (102) mittels aktuellem Datenpaar D[Z] durch, d.h. es sendet die Prüfungsaufgabe P[Z] und führt die Schritte d) - e) aus. Falls die angeschlossene Komponente die Prüfung bestanden hat (103), d.h. in Schritt e) eine Übereinstimmung von empfangener Lösung und R[Z] festgestellt wurde, wird der Wert der Information L ausgewertet (104). Im positiven Fall L = 0 folgt die Freischaltung der Hauptfunktion direkt (105). Im Fall L = 1 wird zunächst geprüft, ob bereits Z = M erreicht ist (106). In diesem Fall stehen keine fehlerfreien Datenpaare mehr zur Verfügung und es erfolgt der Abbruch der Authentifizierung. Der Abbruch beinhaltet das Setzten der Variablen L auf den Wert 1 (107). Falls bei (106) gilt Z < M, so wird durch die Erhöhung Z=Z+1 das aktuelle Datenpaar ausgewechselt und die Variable L zurück gesetzt (108). Dann wird die angeschlossene Komponente mit dem unverbrauchten Datenpaar D[Z] erneut geprüft (109), d.h. die Prüfungsaufgabe P[Z] wird gesendet und die Schritte h)-j) ausgeführt.
-
Abhängig vom Vergleich (110) in Schritt j) wird entweder die Hauptfunktion (105) gestartet oder es erfolgt ein Abbruch (107). Zum Schluss geht das Hauptgerät wieder in den Schlafmodus (111).
-
Falls die Zeigervariable Z die Speichergrenze der Datenpaare erreicht, d.h. falls in Zeichnung 1 bei (106) ein Abbruch erfolgt, und das Gerät dann nicht außer Betrieb gesetzt werden soll, bleiben mehrere Möglichkeiten. In einer Variante nach Anspruch 2 setzt das Hauptgerät dann L und Z zurück. Das Verfahren büßt damit seine absolute Sicherheit ein. Für manche Anwendungsfälle hat es seinen Zweck allerdings an der Stelle schon erfüllt. In einer günstigen Ausführung wird L statt als binäre Variable als Fehlerzähler implementiert. Vor der Prüfung (102) fügt das Hauptgerät eine Wartezeit ein. Die Wartezeit wird mit steigendem Fehlerzähler L erhöht. Somit kann der Verbrauch von Datenpaaren zeitlich gedrosselt werden, und das Zurücksetzen findet erst nach genügend langer Zeit statt, so dass der Einsatz gefälschter Komponenten schlichtweg nicht komfortabel ist.
-
In einem Spezialfall ist für das Hauptgerät die in Zeichnung 2 dargestellte Implementierung günstiger: ist die Komponente ein Akku ist, so ist eine Gegenmaßnahme gegen einen sogenannten „Tear-Down“-Angriff erforderlich. Bei diesem Angriff würde ein böswilliger Akku nach einer nicht bestandenen Prüfung in Zeichnung 1 (103) versuchen, dem Hauptgerät die Stromversorgung zu kappen, bevor die Information L bei (107) auf den Wert eins gesetzt wird. Ein starker böswilliger Akku wäre dann im nächsten Durchlauf in der Lage als authentisch durch zu gehen. Für diesen Anwendungsfall wird die Information L in einer volatilen Variable VL und einer nicht-volatil (z.B. in einem EEPROM-Speicher) zu speichernden Variable PL aufgeteilt. Der Zeiger Z ist ebenfalls nicht-volatil zu speichern. Bei nicht-volatilen Daten bleibt die Information bei Abbruch der Stromversorgung erhalten. Die nicht-volatile Variable PL wird, wie in Zeichnung 2 (201) dargestellt, zu Beginn des Verfahrens auf 1 gesetzt und erst direkt vor dem Start der Hauptfunktion (203) wieder zurück gesetzt. Statt dem Wert von L wird nach der ersten Prüfung in (202) der Wert von VL geprüft. Dieser zeigt das Ergebnis der vorangegangenen Authentifizierung einer Komponente an. Damit wird der genannte Tear-Down-Angriff wirksam verhindert.
-
Authentisierungsapplikation in der Komponente
-
Jede Komponente wird in der Herstellerumgebung mit einer Authentisierungsapplikation versehen. Diese beinhaltet die Lösungsfunktion zur Generierung einer Lösung zu einer Prüfungsaufgabe.
Bei einer kryptographischen Authentisierung entsprechend Anspruch 3 kann zum Beispiel der symmetrische Standard-Algorithmus HMAC-SHA256 eingesetzt werden. Die Lösung zu einer Prüfungsaufgabe hat dann die Form HMAC(Schlüssel, Prüfungsaufgabe), wobei der Schlüssel ein gruppenspezifisches Geheimnis authentischer Komponenten ist. In einer günstigen Ausführung beinhaltet die Komponente ein sicheres Hardware-Element zur Speicherung des geheimen Schlüssels und zur Erzeugung der Lösung. Die Authentisierungsapplikation der Komponente muss dann nur die Prüfungsaufgabe empfangen, in ein Register des sicheren Hardware-Elements schreiben und anschließend die Lösung an die Hauptkomponente senden. Die Einbringung des Schlüssels geschieht in einer streng gesicherten Umgebung.
-
Bei einer Implementierung entsprechend Anspruch 4 beinhaltet die Authentisierungsapplikation der Komponente ein Testprogramm, welches in MCU-interne Peripherie-Register schreibt, Werte aus MCU-internen Peripherie-Register ausließt und über die ausgelesenen Werte eine Hashsumme bildet. Die Authentisierungsapplikation setzt zum einen einen Initialen Hashpuffer abhängig von der Prüfungsaufgabe fest und vertauscht zum anderen Programminstruktionen des Testprogramms und führt das veränderte Testprogramm aus. Der vom veränderten Testprogramm gebildete Hashwert wird als Lösung der Prüfungsaufgabe an die Antwort geschickt. Eine solche Authentisierungsapplikation ist in der noch unveröffentlichten Druckschrift [FS2] im Detail beschrieben.
-
Referenzierte Patentschriften
-
- D1 WO 2012 / 129 641 A1
- D2 US 2013 / 0 111 211 A1
- DE 10 2018 009 143 A1 Verfahren zur Authentifizierung eines Geräts durch ein Hostsystem, noch unveröffentlicht
-
Sonstige Referenzen
-
- [MSU] Michigan State University, „Defining the threat of product counterfeiting,“ 2019. https://www.michiganstateuniversityonline.com/resources/ acapp/threat-of-product-counterfeiting/.
- [Pa] R. S. Pappu, „Physical one-way functions,“ PhD thesis, MIT, 2001.
- [SIMPL] U. Rührmair, „SIMPL systems as a keyless cryptographic and security primitive,“ D. Naccache (Editor), Cryptography and Security: From Theory to Applications - Essays Dedicated to Jean-Jacques Quisquater on the Occasi on of His 65th Birthday. Lecture Notes in Computer Science, Vol. 6805, Sprin ger, 2012.
- [FS1] F. Schuhmacher, „MCU intrinsic group features for component authentication“, 2020, noch unveröffentlicht.
- [FS2] F. Schuhmacher, „Relaxed freshness in component authentication“, 2020, noch unveröffentlicht.
