DE112016001047B4

DE112016001047B4 - System und Vorrichtung zum Verifizieren der Integrität eines Systems von seinen Komponenten

Info

Publication number: DE112016001047B4
Application number: DE112016001047.8T
Authority: DE
Inventors: John Ross Wallrabenstein
Original assignee: Analog Devices Inc
Current assignee: Analog Devices Inc
Priority date: 2015-03-05
Filing date: 2016-03-07
Publication date: 2022-08-18
Anticipated expiration: 2036-03-08
Also published as: WO2016141383A1; DE112016001047T5

Abstract

Vorrichtung zum Verifizieren der Integrität eines Systems mit einer Vielzahl von Komponenten von denen jede einen physikalischen Zustand und eine physikalisch unklonbare Funktion (‚PUF‘) hat, aufweisend eine PUF-Eingabe und eine PUF-Ausgabe und dafür ausgebildet, als Antwort auf die Eingabe einer spezifischen Challenge, einen Ausgabewert zu erzeugen, der charakteristisch ist für die PUF, den physikalischen Zustand der Komponente und die spezifische Challenge, die Vorrichtung mit einem Speicher und mit einem Prozessor (10), der mit jeder der Komponenten verbunden ist, die eine PUF enthalten, und dafür ausgebildet ist, eine Schwellwertverifikation durchzuführen durch:a) Berechnen von kryptographischen Schwellwertoperationen über mehrere Shares, wobei jedes der mehreren Shares einer spezifischen Komponente und einer Antwort von der PUF der Komponente zugeordnet ist und wobei die Shares der jeweiligen Komponenten nach jeder kryptographischen Schwellwertoperation aktualisiert werden;b) Kombinieren der berechneten kryptographischen Schwellwertoperationen; undc) Überprüfen, ob eine ausreichende Gruppe von mehreren Komponenten, die eine PUF enthalten und durch die mehreren Shares repräsentiert sind, valide ist.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft eine Integritätsverifikation von Systemen mit elektronischen Komponenten.
BEZUG AUF VERBUNDENE ANMELDUNGEN
Diese internationale Anmeldung beansprucht den Vorteil der Priorität aus der nicht-provisorischen US-Patentanmeldungen Anmeldungsnummer 14/704,947 („die '947-Anmeldung“), eingereicht am 5. Mai 2015, und Anmeldungsnummer 14/746,090 , eingereicht am 22. Juni 2015 (die eine teilweise Fortsetzung der '947-Anmeldung war), und von den vorläufigen US-Patentanmeldungen, Anmeldenummer 62/150,254 , eingereicht am 20. April 2015, Anmeldenummer 62/128,920 , eingereicht am 5. März 2015 („die '920-Anmeldung“) und Anmeldenummer 62/150,586 , eingereicht am 21. April 2015 („die'586-Anmeldung“). Der Inhalt der '920- und '586-Anmeldungen und der provisorischen US-Patentanmeldung, Anmeldenummer 61/988,848 , eingereicht am 5. Mai 2014 (veröffentlicht im Rahmen der Verfolgung der US-Patentanmeldungsveröffentlichung Nr. 20150317480).
HINTERGRUND DER ERFINDUNG
Bei vielen Applikationen kann es hilfreich sein, Mittel zum Verifizieren der Integrität eines Systems einzusetzen, indem die Komponenten abgefragt werden, aus denen es besteht. Zum Beispiel kann es ein Waffensystem erfordern, dass Komponenten während eines Bootvorgangs intern validiert werden oder ein Fahrzeug kann kritische elektronische Steuereinheiten beim Starten validieren. Der Stand der Technik hat die Verifikation einer Komponente durch eine Demonstration erreicht, dass sie einen geheimen Wert besitzt, zum Beispiel durch einen kenntnisfreien Beweis (zero knowledge proof) von Kenntnis. Dieses Verfahren der Verifikation kann jedoch mit einer oder mehreren Rahmenbedingungen bezogen auf eine Hardwareintegrität oder die Sicherheit von privater bzw. nicht-öffentlicher Information verbunden sein. Bezüglich der Hardwareintegrität verifizieren bestehende Komponenten-Authentifizierungsprotokolle nur, dass eine Einheit einen privaten Wert besitzt und leiten üblicherweise daraus einfach die Hardwareintegrität ab, wenn die Vorrichtung (device) einen physikalisch Aufbau hat, der dafür ausgelegt ist, Manipulieren zu verhindern (z.B. ein Hardwaresicherheitsmodul). Selbst bei einem manipulationssicheren physikalischen Aufbau ist die Integrität des physikalischen Aufbaus nicht untrennbar mit der Integrität der Vorrichtung selbst verknüpft. Im Hinblick auf die Sicherheit von privater Information erfordern es bestehende Komponenten-Authentifizierungsprotokolle, dass die Komponente private Information (typischerweise einen privaten Schlüssel für kryptographische Authentifizierungsprotokolle) speichert und schützt. Falls die private Information kompromittiert wird, kann es einem Angreifer (adversary) möglich sein, sich als gültige Komponente in dem größeren System auszugeben.
Asim et al. („Physical Unclonable Functions and Their Applications to Vehicle System Security,“ Vehicular Technology Conference, VTC Spring 2009, IEEE 69th) diskutieren die Verwendung von PUFs in Fahrzeugkomponenten als ein Verfahren zum Regenerieren von privaten Schlüsseln, wobei es sich um eine gut bekannte Anwendung handelt. Die Autoren geben jedoch keinen realisierbaren Aufbau an, mit dem eine systemweite Identität aus jeder der individuellen Komponenten hergestellt werden kann.
Rigaud (Editor) in „D3.1 Report on Protocol choice and implementation,“ Holistic Approaches for Integrity of ICT-Systems (2014) beschreibt das Anwenden von PUFs auf Chips als ein Verfahren zum Authentifizieren eines Chips (die zu testende Vorrichtung) für die Testausrüstung, die gefälschte Chips erkennen könnte. Es gibt jedoch keinen Aufbau, der es ermöglichen würde, eine systemweite Identität aus jedem der individuellen Chips herzustellen.
Ibrahim et al. („Cyber-physical security using system-level pufs,“ Wireless Communications und Mobile Computing Conference (IWCMC), 2011 7th Int'l, IEEE) diskutieren das generelle Konzept eines Kombinierens von PUFs von separaten Systemkomponenten, um eine kombinierte Identität zu bilden, aber die Autoren geben keinen realisierbaren Aufbau an. In ihren abschließenden Bemerkungen weisen die Autoren ausdrücklich darauf hin, dass es ihnen an einer realisierten Lösung fehlt.
Peeters („Security Architecture for Things That Think,“ Diss. Ph. D. thesis, KU Leuven, June 2012) beschreibt die Verwendung einer PUF in Vorrichtungen, die hinsichtlich ihrer Ressourcen beschränkt sind, zum Erneuern eines Share bzw. geteilten Bereichs von einem externen Schwellwertsystem bestehend aus Vorrichtungen eines Benutzers. Die PUF wird nur als Speichermechanismus verwendet, wodurch die Notwendigkeit eliminiert wird, das Share Bereich in Klartext (plaintext) auf der Vorrichtung zu speichern. Es wird jedoch keine interne Schwellwertapplikation angegeben und das Challenge-Hilfspaar (challenge-helper pair) wird nie erneuert.
Krzywiecki et al. („Coalition resistant anonymous broadcast encryption scheme based on PUF,“ Trust und Trustworthy Computing. Springer Berlin Heidelberg, 2011, 48-62) beschreiben ein Broadcast-Verschlüsselungsschema, bei dem Teilnehmer eine PUF-aktivierte Karte verwenden müssen, um Shares eines Schwellwertsystems zu erneuern. Der Aufbau erfordert einen unkorrumpierbaren Distributor, um die unverarbeitete (raw) PUF-Ausgabe zu speichern und zu schützen. Das System ist dafür ausgelegt, es einem Endgerät nur dann zu erlauben, einen symmetrischen Schlüssel wiederzuerlangen, wenn er nicht von dem Broadcaster widerrufen wurde. Das PUF-aktivierte Empfangsgerät muss den vollständigen symmetrischen Schlüssel aus seinen Shares herstellen, um die eingehende Übertragung zu entschlüsseln. Es ist keine interne Schwellwertapplikation vorhanden, und das Challenge-Hilfspaar wird nie erneuert.
Khoshroo et al. („Design and Evaluation of FPGA-based Hybrid Physically Unclonable Functions,“ Diss. Western University London, 2013) beschreiben ein modifiziertes Teilungsschema für ein Geheimnis (secret), wobei jeder Share eines Players bzw. Teilnehmers ein Challenge-Hilfspaar ist, das von der PUF des Dealers bzw. Verwalters erzeugt wurde. Die tatsächlichen Shares für das Schwellwertsystem werden nur wiedergewonnen, wenn das Challenge-Hilfspaar und ein Zugang zu der PUF vorhanden ist, die das Share aus dem Challenge-Hilfspaar regeneriert. Da jedes Share ohne Zugang zu der PUF wertlos ist, kann ein Angreifer alle Endgeräte kompromittieren und ist trotzdem nicht in der Lage das Geheimnis ohne Zugang zu der PUF zu erlangen. Es sind keine kryptographischen Operationen über diese Pseudo-Shares möglich. Das gesharete bzw. geteilte Geheimnis kann nur erlangt werden, wenn alle Shares regeneriert werden, und es wird angenommen, dass der Dealer unkorrumpierbar ist. Die PUF des Dealers wird nur als ein Verfahren zum Verschleiern (obfuscating) des Share verwendet, die an die Player verteilt werden.
Die Aufgabe der Erfindung ist es die zuvor genannten Nachteile wenigstens teilweise zu überwinden und die Integrität eines zusammengesetzten Systems mit mehreren Komponenten zu verifizieren.
Diese Aufgabe wird durch den Patentanspruch 1 gelöst. Vorteilhafte Weiterbildungen ergeben sich aus den Unteransprüchen.
ZUSAMMENFASSENDE DARSTELLUNG DER ERFINDUNG
Verschiedene Ausführungsformen der Erfindung bieten die Verifikation einer Gruppe von Komponenten eines elektronischen Systems, so dass die Integrität des Systems insgesamt daraus abgeleitet werden kann. Eine Ausführungsform der Erfindung verwendet physikalisch unklonbare Funktionen (physical unclonable functions, PUFs) zum Detektieren einer Hardwaremanipulation in integrierten Schaltungen und kenntnisfreie Beweisprotokolle zur Authentifizierung. Bei einer Ausführungsform wird dies durch eine individuelle Verifikation von Komponenten durchgeführt; bei einer anderen Ausführungsform können relevante Komponenten zusammen verifiziert werden, wobei jede einen lokalen Beweis (proof) der Validität erzeugt und zusammenarbeitet, um ihre lokalen Beweise in einen einzelnen Beweis zu kombinieren, der die Integrität des Systems insgesamt validiert.
Bei einer anderen Ausführungsform, die individuell oder in Kombination mit einer oder mehrerer der vorstehenden Ausführungsformen eingesetzt werden kann, kann ein systemisches Vertrauen (systemic trust) etabliert werden, selbst wenn die Komponenten des Systems selbst unvertrauenswürdig (untrusted) bzw. nicht-vertrauenswürdig sind, indem eine Root-Of-Trust (Wurzel des Vertrauens) als Hardware verwendet wird, die iterativ die Vertrauensgrenze (trust boundary) vergrößert, so wie jede Komponente verifiziert wird.
Figurenliste

1 ist eine Darstellung, die eine (1,1) Integritätsverifikation von Komponenten darstellt;
2 ist eine Darstellung, die eine (n,1) Integritätsverifikation von Komponenten darstellt; und
3 zeigt ein System, das ein Vertrauen durch eine geschichtete Sicherheit etabliert, die von einem High-Assurance-Prozessor abgeleitet wird.

DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Bei einer Ausführungsform kann jede von n relevanten Komponenten eines Systems abgefragt werden (z.B. sequentiell) durch einen interaktiven oder nicht-interaktiven kenntnisfreien Beweis von Kenntnis. Authentifizierungsalgorithmen wie sie bspw. in den '848- und '586-Anmeldungen (basierend auf elliptischen Kurven) oder im US-Patent Nr. 8,918,647 (basierend auf diskretem Logarithmus; „das '647-Patent“, welches hier durch Bezugnahme aufgenommen wird) können zum Beispiel verwendet werden, um die Hardwareintegrität von Komponenten zu etablieren, die vertrauenswürdige Mittel zum Sammeln von privater Information haben, wie zum Beispiel physikalisch unklonbare Funktionen. Eine PUF verbindet die Auswertung einer Funktion mit der Hardware, auf der sie ausgeführt wird, so dass jede bösartige Manipulation der Hardware die Auswertung der Funktion betrifft. Indem man ferner die PUF-Ausgabe mit der Herstellung des kenntnisfreien Beweises verbindet, kann die Hardwareintegrität der Vorrichtung von einem externen Verifier bzw. Überprüfer aus seiner Fähigkeit abgeleitet werden, das Protokoll des kenntnisfreien Beweises vollständig abzuschließen. Die PUF kann auch dafür ausgebildet sein, nur aus öffentlicher Information private Information dynamisch zu erzeugen, so dass die Komponenten die private Information nicht speichern und schützen müssen. Bei einer anderen Ausführungsform kann die Integrität des Systems durch eine einzelne kollaborative Antwort von allen (oder einer Untergruppe davon) Komponenten etabliert werden indem ein Schwellwertbeweis (threshold proof) hergestellt wird, der es erfordert, dass alle oder eine Untergruppe der n Komponenten korrekt funktioniert. In diesem Fall erzeugten sie kollaborativ, statt dass ein separater Beweis für jede der n Komponenten hergestellt wird, einen einzelnen Beweis, der die Validität von allen oder einer Untergruppe der n Komponenten gleichzeitig etabliert.
Eine Ausführungsform einer Komponente kann eine Plattform mit einem Xilinx Artix 7 feldprogrammierbaren Gate Array (FPGA) aufweisen, die z.B. mit 215.000 logischen Zellen, 13 Megabyte von Block-Direktzugriffsspeicher (block random access memory) und 700 Digitalverarbeitungs-(DSP-)Slices. Bei einer Ausführungsform, die Kryptographie mit elliptischen Kurven verwendet, kann zum Beispiel eine Hardware-Mathematikmaschine in den On-Board-DSP-Slices eingerichtet werden, wobei die PUF-Herstellung in den logischen Zellen positioniert ist, und einem logischen Verarbeitungskern, der eine Eingabe und eine Ausgabe an die PUF aufweist und dafür ausgebildet ist, diese und die externen Eingänge und Ausgänge der Komponente zu steuern und Algorithmen durchzuführen (das Senden von elliptischen Kurven und anderen mathematischen Berechnungen an die Mathematikmaschine), wie oben beschrieben. Ein Verifier kann ein Xilinx Artix 7 FPGA wie oben beschrieben aufweisen oder einen Servercomputer mit einem 8-Kern-3,1 GHz-Prozessor und 16 GB RAM oder andere geeignete Mittel, die kabelgebunden oder kabellos mit den Komponenten des Systems verbunden sind.
Komponentenauthentifizierung
Bei der individuellen Abfragemethode der Verifikation, oder „(1,1)-Verifikation“, interagiert jede Komponente direkt mit dem Verifier v. Bei der interaktiven (1,1)-Verifikation gibt der Verifier v ein Nonce als Teil eines Zwei-Nachrichten-Protokolls bei jeder Komponente aus. Bei der nicht-interaktiven (1,1)-Verifikation sendet jede Komponente nur eine einzelne Nachricht an den Verifier v und nimmt einen Wert äquivalent zu einem Nonce (z.B. ein Zeitstempel) auf, der nicht von der Komponente manipuliert werden kann. Bei dem kollaborativen Verfahren der Verifikation, oder „(n,1)-Verifikation“, erzeugt eine Untergruppe der n Komponenten kollaborativ einen einzelnen gemeinsamen Beweis, der den Verifier v von der Integrität der Untergruppe der n Komponenten überzeugt. Bei der interaktiven (n,1)-Verifikation gibt der Verifier v ein Nonce als Teil eines Zwei-Nachrichten-Protokolls aus, wobei eine Untergruppe der Komponenten gemeinsam agiert und nur eine einzelne Antwort sendet. Bei der nicht-interaktiven (n,1)-Verifikation sendet eine Untergruppe von Komponenten nur eine einzelne Nachricht an den Verifier v, die einen Wert äquivalent zu einem Nonce (z.B. einen Zeitstempel) aufweist, der von keiner Untergruppe der Komponenten manipuliert werden kann.
Zum Zwecke des Aufzeigens einer detaillierten Beschreibung einer Ausführungsform wird das Beispiel einer Herstellung (construction) auf Basis von elliptischen Kurven verwendet, wobei E eine elliptische Kurve angibt, die über ein finites Feld $F_{p}$
definiert ist, wobei G ein Basispunkt der Ordnung q ist. Der Fachmann erkennt, dass die Erfindung (sei es (1,1), (n,1) und/oder geschichtete Sicherheit (layered security)) unmittelbar unter Verwendung anderer Herstellungen (constructions) implementiert werden kann (wobei die Herstellung mittels des diskreten Logarithmus aus dem '647-Patent nur eine beispielhafte Alternative ist). Die Erfindung ist daher nicht auf eine bestimmte Herstellung beschränkt, sofern dies nicht ausdrücklich in den Ansprüchen angegeben ist.
Ein kenntnisfreies Authentifizierungsprotokoll erfordert üblicherweise ein einzigartiges und zufälliges Nonce, das vom Verifier v während jedes Protokollaufrufs ausgegeben wird. Das Nonce verhindert, dass der Beweis von dem Verifier in der Zukunft erneut verwendet wird (z.B. bei einem Angriff mittels Wiederabspielen (replay)), und die sich beweisende Komponente darf nicht in der Lage sein, seinen Wert zu beeinflussen. Zum Beispiel offenbart die '848-Anmeldung ein Token-basiertes Protokoll eines kenntnisfreien Beweises, wobei die entsprechenden Lehren hier durch Bezugnahme aufgenommen werden, das wie folgt zusammengefasst werden kann
Interaktiver Authentifizierungsalgorithmus für eine individuelle Vorrichtung
wobei N ein Nonce ist, P der Hilfsstring ist, PUF (·) die PUF-Funktion ist, D ein Fehlerdecodierschema ist, random ein zufälliges Gruppenelement ist und Hash (G, B, A, N) ein Hash, keine Challenge ist.
Dieser Algorithmus läuft wie folgt ab:

• Vor der Authentifizierung hat der Server eine zufällige Challenge-Variable c an die Vorrichtung gesendet, die verwendet wird, um eine PUF-Challenge-Eingabe x zu bilden. Der Enrollment-Server und die Vorrichtung einigen sich auf eine elliptische Kurve E, die in einem finiten Feld $F_{p}$
definiert ist, wobei G ein Basispunkt der Ordnung q ist. Die Vorrichtung d_i liefert ein öffentliches Commitment $A = p_{i}^{p r i v} \cdot G$
an den Server, der seine PUF mit der Challenge-Variablen c (von dem die Challenge-Eingabe x abhängt) verbindet, und einen öffentlichen Hilfswert P, der die rauschbehaftete (noisy) PUF-Ausgabe korrigiert.
• Wenn der Server die Vorrichtung authentifizieren will, sendet er eine Authentifizierungsanforderung und das Tupel {c, F, G, p, q, P, N} wird an die Vorrichtung gesendet.
• Die Vorrichtung erstellt die PUF-Challenge-Eingabe x ← H(c, E, G, p, q), die die Challenge-Variable c mit den öffentlichen Parametern der elliptischen Kurve verbindet und sendet sie an die PUF, die die Ausgabe O' liefert, die durch ⊕ mit dem Hilfswert P verknüpft wird und das Ergebnis unter Verwendung eines Fehlerdecodierschemas D decodiert wird.
• Da die PUF-Ausgabe rausch behaftet ist, wenn eine erneute Abfrage mit der Challenge x in der Zukunft erfolgt, kann die neue Ausgabe O' eventuell nicht exakt mit dem vorherigen Ausgabewert 0 übereinstimmen. Es wird jedoch davon ausgegangen, dass 0 und 0' sich t nahe sind unter Bezug auf eine Distanzmetrik (z.B. eine Hamming-Distanz). Es kann daher ein Fehlerkorrekturcode auf die PUF-Ausgabe angewendet werden, so dass höchstens t Fehler immer noch 0 wiederherstellen. Während des Enrollments wurde eine Fehlerkorrektur auf das zufällige Gruppenelement $p_{i}^{p r i v}$
angewendet und dann wurde dieser Wert mit der Ausgabe 0 der PUF verblendet (blinded), so dass der finale Hilfswert $P = E E C (p_{i}^{p r i v}) \oplus 0$
keine Information über $p_{i}^{p r i v}$
offenbart. Während der Wiederherstellung zur Authentifizierung liefert das Berechnen des Exklusiven-OR von EEC (rand) ⊕ 0 ⊕ 0' den Wert $p_{i}^{p r i v},$
wenn sich 0 und 0' um t nahe sind. Diesen Prozess bezeichnet man als unscharfe Extrahierung (fuzzy extraction) und wird in der '848-Anmeldung näher beschrieben (siehe „Gen Algorithm,“, „Rep Algorithm,“ und die Definition 3).
• Die Vorrichtung wählt ein zufälliges Gruppenelement $r \in F_{q}$
und berechnet den Punkt B = r · G.
• Das Nonce N des Servers wird mit dem Beweis verbunden, indem ein Hash c' erzeugt wird, das auch den Basispunkt G, das Nonce B der Vorrichtung und seinen öffentlichen Schlüssel A kombiniert.
• Die Vorrichtung konstruiert das Token $(B, m = r + c' \cdot p_{i}^{p r i v} m o d p)$
des kenntnisfreien Beweises und liefert dieses Tupel an den Server.
• Der Server überprüft dass: $\begin{matrix} {(m \cdot G) - c' \cdot A)} = {((r + c' \cdot p_{i}^{priv}) \cdot G) - (c' \cdot p_{i}^{priv} \cdot G)} \\ \begin{matrix} = {r \cdot G +' c \cdot p_{i}^{priv} \cdot G -' c \cdot p_{i}^{priv} \cdot G} \\ = r \cdot G \\ = B \end{matrix} \end{matrix}$

(1,1)-Verifikation
Bei der (1,1)-Verifikation fragt der Verifier individuell jede Komponente ab, um die Integrität des größeren Systems zu etablieren; alle (oder alle angegebenen) Komponenten führen erfolgreich einen kenntnisfreien Beweis mit dem Verifier durch, damit die Verifikation der Integrität des Systems als Gesamtes erfolgreich ist. In 1 ist der Verifier so gezeigt, dass er jede der Komponenten des Systems sequentiell validiert. Bei der ersten Verifikation 1 und der zweiten Verifikation 2 validiert der Verifier jede kritische Systemkomponente. Bei der dritten Verifikation 3 und der vierten Verifikation 4 validiert der Verifier jede nicht-kritische Systemkomponente. Eine interaktive Version dieses Prozesses ist im Algorithmus 1 dargelegt.
wobei N_i ein Nonce ist, P_i der Hilfsstring ist, PUF (·) die PUF-Ausgabe-Funktion ist, D ein Fehlerdecodierschema ist, random ein zufälliges Gruppenelement ist und $A_{i} = p_{i}^{p r i v} \cdot G m o d p$

vom Enrollment der Vorrichtung gespeichert ist.
Die Anforderung bezüglich der Kommunikation von dem Verifier v bei dem interaktiven kenntnisfreien Beweis ist es, einen Nonce-Wert spezifisch bezüglich des aktuellen Beweises zu erhalten. Dies verhindert, dass ein mithörender (eavesdropping) Angreifer vorherige Beweise von einer gültigen Komponente verwendet, um ein Authentifizierungsprotokoll erfolgreich abzuschließen und sich als gültige Komponente auszugeben. Bei einem nicht-interaktiven kenntnisfreien Beweis ist diese Kommunikationsanforderung nicht gegeben. Eine nicht-interaktive Version des Algorithmus 1 kann man erstellen, indem man die Komponente so ausgestaltet, dass sie ein Nonce in einer Art und Weise erzeugt die verhindert, dass die sich beweisende (proving) Komponente den Beweis manipuliert. Um dies zu erreichen, erstellt das Komponentenvorrichtung d_i das Nonce als $N \leftarrow H a s h (p_{i}^{p r i v} \cdot G m o d p ‖ τ)$

wobei τ ein Zeitstempel ist und II ein Zusammenfügen (concatenation) bezeichnet. Der Zeitstempel stellt sicher, dass vorherige Beweise, die von der sich beweisenden Komponente erstellt wurden, nicht von einem Angreifer in der Zukunft wieder abgespielt werden können, wohingegen die Hash-Funktion sicherstellt, dass die sich beweisende Komponente die Challenge nicht in bösartiger Weise manipulieren kann. Der Verifier überprüft vorteilhafterweise, dass der Zeitstempel hinreichend aktuell ist (z.B. eine zweite Granularität) und sich monoton erhöht, um Angriffe durch Wiederabspielen zu verhindern. Alternativ können global synchronisierte Zeitgeber statt eines Zeitstempels verwendet werden, wenn bspw. die Netzwerklatenz nicht nennenswert ist. Eine nicht-interaktive Version der (1,1)-Verifikation ist im Algorithmus 2 dargelegt, wobei jede Komponente lokal einen aktuellen Zeitstempel τ wählt, um Nonce zu erstellen.
Algorithmus 2: Nicht-interaktive (1,1)-Systemverifikation
wobei PUF (·) die PUF-Ausgabe-Funktion ist, D ein Fehlerdecodierschema ist, random ein zufälliges Gruppenelement ist, τ der aktuelle Zeitstempel ist und $A = p_{i}^{p r i v} \cdot G m o d p$
vom Enrollment der Vorrichtung gespeichert ist.
(n,1)-Verifikation
Im Hinblick auf die Schwellwertverfahren, die in der '920-Anmeldung offenbart sind, die durch Bezugnahme aufgenommen werden, kann man zum Beispiel, um die Anforderung zu erfüllen, dass alle k kritischen Komponenten ordnungsgemäß funktionieren, eine (k,k)-Teilung erstellen, so dass alle k Komponenten zusammenarbeiten müssen, um einen gemeinsamen Beweis abzuschließen. Für ein System, das kritische Komponenten sowie nicht-kritische oder redundante Komponenten aufweist, kann es wünschenswert sein zu prüfen, dass alle kritischen und einige nicht-kritische oder redundante Komponenten betriebsbereit sind. Ein Verfahren zum Verifizieren eines solchen Systems ist es ein separates Sharing bzw. eine separate Teilung für jede Gruppe zu erzeugen, wobei der Verifier zwei Beweise prüft.
Alternativ können sowohl kritische als auch nicht-kritische Komponenten gemeinsam verifiziert werden, indem man einen einzelnen (t,n) Schwellwertbeweis verwendet, bei dem n Shares bereitgestellt sind, um so die Integrität von allen kritischen Komponenten und einer spezifizierten Untergruppe von nicht-kritischen Komponenten sicherzustellen. Man nehme zum Beispiel an, dass es zwei kritische Komponenten (von denen beide betriebsbereit sein müssen) und zwei nicht-kritische Komponenten (von denen zumindest eine betriebsbereit sein muss) gegeben sind. n = 6 Shares können verteilt werden, wobei jede kritische Komponente zwei Shares erhält und jede nicht-kritische Komponente eins erhält, und die minimale Anzahl von Teilungen zur Verifikation t beträgt 5 (d.h., ein (5,6)-Sharing). Falls eine der kritischen Komponenten ausfällt oder beide nicht-kritische Komponenten ausfallen, schlägt die Verifikation fehl, da die verbleibenden betriebsbereiten Komponenten nur eine Gesamtzahl von vier Shares bereitstellen können; falls beide kritische Komponenten und zumindest eine nicht-kritische Komponente betriebsbereit sind, können die für eine erfolgreiche Verifikation benötigten fünf Shares beigesteuert werden. Im Allgemeinen bezeichnet man diese Herangehensweise als ein Erstellen einer Schwellwertzugriffsstruktur (threshold access structure), die eine Gruppe von Regeln (z.B. alle kritischen Komponenten und die Hälfte der nicht-kritischen Komponenten müssen funktional sein, damit das System authentifiziert wird), durch die Verteilung von Shares zu erzwingen. Wie in 2 gezeigt ist, siehe den ersten Schwellwertbeweis 5 und den zweiten Schwellwertbeweis 6, tragen die kritischen Komponenten ihre lokalen Beweise bei. Beim dritten Schwellwertbeweis 7 und vierten Schwellwertbeweis 8, tragen die verbleibenden Komponenten ihre lokalen Beweise bei, um einen einzelnen, gemeinsamen Beweis zu bilden. Bei der kombinierten Verifikation 9 validiert der Verifier den gemeinsamen Beweis (wie zum Beispiel durch den Algorithmus 6) um die Validität des Systems insgesamt zu etablieren. In gleicher Weise kann eine (t,n) Teilung für redundante Systeme erstellt werden, so dass t der n redundanten Systeme funktionsbereit sein müssen, um den Beweis abzuschließen. Daher, statt O(n) Beweise für n Systeme abzuschließen, können die Systeme gemeinsam einen einzelnen Schwellwertbeweis erstellen, um das System zu repräsentieren, das sie bilden.
Algorithmus 3 zeigt ein Beispiel einer Untergruppe von Komponentenvorrichtungen D̅ ⊆ D, |D̅| = m ≤ n, die einen gemeinsamen Schwellwertbeweis für den Verifier v erstellen. Auch wenn der Verifier bei diesem Beispiel partielle Beweise kombiniert (somit annehmend, dass O(n) für v arbeitet, da die Anzahl von partiellen Beweise n ist), könnte stattdessen ein Sekretär (secretary) die partiellen Shares kombinieren und das Ergebnis an den Verifier weiterleiten. Als andere Alternative könnten die Komponenten einen Ring bilden und ihre partiellen Shares an die nächste Komponente weiterreichen, die ihren eigenen partiellen Beweis kombiniert, bevor eine Weiterleitung an die nächste Komponente stattfindet. Der Enrollment-Algorithmus, der Distributed-Key-Generation-Algorithmus und das PUF-Retrieve sind in der'920-Anmeldung dargelegt.
In gleicher Weise kann Algorithmus 3 nicht-interaktiv durchgeführt werden. Dies erreicht man, indem man das Nonce N des Verifiers mit einem Zeitstempel τ ersetzt, der von den Komponenten erzeugt wird, wie es im Algorithmus 4 gezeigt ist. Der Zeitstempel dient als Ersatz für die Zufälligkeit N des Servers und verhindert Angriffe durch Wiederabspielen indem eine zeitliche Anforderung zu dem Beweis hinzugefügt wird. Das heißt, der Zeitstempel erhöht sich monoton, und der Verifier überprüft einfach, dass der bei dem Beweis verwendete Zeitstempel hinreichend aktuell ist (z.B. eine zweite Granularität).
Algorithmus 5 zeigt eine weitere Verfeinerung des Algorithmus 3, die ein Aktualisieren des Challenge-Hilfspaars und Share nach jeder Operation aktualisiert. Die PUF-Share-Update- und PUF-Store-Algorithmen sind in der'920-Anmeldung dargelegt.
Geschichtete Sicherheit
Wenn die Komponenten selbst nicht in der Lage sind, einen Beweis der Korrektheit zu erzeugen, muss die Integrität des Systems insgesamt von einer Root-Of-Trust abgeleitet werden. Eine zusätzliche Ausführungsform der Erfindung ist ein System, das einen Ansatz von geschichteter Sicherheit (layered security) über alle Verarbeitungsebenen (computing levels) durch Ableiten einer Hardware-Root-Of-Trust von einem High-Assurance-Prozessor ableitet. Der High-Assurance-Prozessor wird verwendet, um alle Schichten in einer Verarbeitungsarchitektur zu validieren, wodurch eine sichere Startsteuerung (secure boot control), eine Veränderungserkennung, Alarmhinweise und Überprüfungsfunktionen bereitgestellt werden. 3 zeigt den High-Assurance-Prozessor in einer beispielhaften Verarbeitungsarchitektur.
Sichere Verarbeitungsarchitekturen erzeugen eine Herangehensweise von geschichteter Sicherheit, wobei die vertrauenswürdige Grenze iterativ von einer Kern-Root-Of-Trust (core root of trust) vergrößert wird. Zum Beispiel nimmt eine vertrauenswürdige Startprozedur eine minimale Vertrauensgrenze an (z.B. eine Root-Of-Trust, wie zum Beispiel ein vertrauenswürdiges Plattformmodul (trusted platform module, TPM)) und erweitert die Vertrauensgrenze iterativ, indem jede Komponente des Systems validiert wird, wenn es startet. Dies beseitigt das Risiko von Komponenten, die für eine bösartige Modifikation empfänglicher sind, wie zum Beispiel das Betriebssystem oder Applikationen. Die Root-Of-Trust wird verwendet, um Modifikationen an Systemkomponenten zu detektieren und schließt die Startsequenz nur ab, falls alle Komponente als korrekt validiert sind. Existierende vertrauenswürdige Startsysteme verlassen sich üblicherweise jedoch auf Roots-Of-Trust, die der Vorrichtung zugewiesen sind (statt intrinsisch zu sein). Zum Beispiel enthalten TPMs einen privaten Schlüssel in einem geschützten Speicher, der die Identität des Systems repräsentiert. Ein Angreifer, der die zugewiesene Identität extrahiert, kann sich als das System ausgeben. Ferner bieten existierende Systeme keine intrinsische Manipulationsdetektion und verlassen sich auf eine manipulationsdetektierende Hardwareumgebung bezüglich der Sicherheit. Existierende Roots-Of-Trust sind in 3 an der Wurzel (root) der Vertrauensschicht (trust layer) 14 dargestellt, die sich über der Hardwareschicht befindet.
Eine Ausführungsform der Erfindung verwendet einen High-Assurance-Prozessor basierend auf einer PUF, die intrinsische und einzigartige Eigenschaften der Hardware erfasst und bevorzugt eine intrinsische Hardware-Manipulationsdetektion aufweist. Da die PUF-Zuordnung (PUF mapping) eine Funktion der physikalischen Eigenschaften der Hardware ist, kann sie verwendet werden, um eine Hardware-intrinsische Identität zu erzeugen, die den physikalischen Zustand des Systems repräsentiert. Wie in 3 gezeigt, wird der High-Assurance-Prozessor 10, der sich auf der Hardwareschicht befindet, als die Root-Of-Trust des Systems etabliert und bildet eine geschichtete Sicherheitsarchitekturinteraktion mit der Applikationsschicht 11, der Betriebssystemschicht 12, der Netzwerkschicht 13, der Root-Of-Trust-Schicht 14 und der Hardwareschicht 15. Der High-Assurance-Prozessor 10 erfüllt die Sicherheitsfähigkeit NIST SP 800-53 Rev. 4 („Security and Privacy Controls for Federal Information Systems and Organizations“), wobei Vertrauen aus den Interaktionen der Systemkomponenten untereinander abgeleitet wird. Der High-Assurance-Prozessor 10 kann in gemeinsamen Verstärkungssteuerungen (reinforcement controls) innerhalb des Systems verwendet werden, wobei der High-Assurance-Prozessor 10 eine existierende Root-Of-Trust und andersrum validieren kann.
Der High-Assurance-Prozessor 10 ist bevorzugt dafür ausgelegt, mit dem System durch allgemeine kommerzielle Standardschnittstellen (z.B. USB, Ethernet) zu interagieren, um eine Interaktion mit allgemein erhältlichen Vorrichtungen ohne Hardwareveränderung zu ermöglichen, und eine Integration und fortlaufender Support kann durch Firmware und/oder Softwareupgrades erzielt werden. In der Root-Of-Trust-Schicht 14 kann der High-Assurance-Prozessor 10 verwendet werden, existierende Roots-Of-Trust (z.B. TPM, ARM TrustZone) zu erweitern und/oder mit ihnen zu interagieren. Dies ermöglicht es dem System mit einem bestehenden vertrauenswürdigen Startprozess im Wesentlichen unverändert zu bleiben, da der High-Assurance-Prozessor 10 zunächst die existierende Root-Of-Trust validieren kann (die nachfolgend den existierenden vertrauenswürdigen Startprozess abschließen kann). Bei der Applikationsschicht 11 kann der High-Assurance-Prozessor 10 verwendet werden, um Applikationen vor der Ausführung zu validieren, indem zum Beispiel ein kryptographischer Hash des Applikationscodes oder der binären ausführbaren Datei gespeichert wird, wenn sie das erste Mal von einer gesicherten Quelle installiert wird. Der High-Assurance-Prozessor 10 signiert das kryptographische Hash, das in dem System gespeichert werden kann. Bevor eine Applikation durch das System ausgeführt werden darf, berechnet der High-Assurance-Prozessor 10 zunächst ein kryptographisches Hash des aktuellen Applikationscodes oder der binären ausführbaren Datei, validiert dessen Signatur bezüglich des gespeicherten kryptographischen Hashs und validiert, dass die zwei Hash-Ausgaben übereinstimmen. Falls eine dieser Überprüfungen fehlschlägt, hält der High-Assurance-Prozessor 10 bevorzugt die Ausführung der Applikation an und gibt einen Alarm aus.

Claims

Vorrichtung zum Verifizieren der Integrität eines Systems mit einer Vielzahl von Komponenten von denen jede einen physikalischen Zustand und eine physikalisch unklonbare Funktion (‚PUF‘) hat, aufweisend eine PUF-Eingabe und eine PUF-Ausgabe und dafür ausgebildet, als Antwort auf die Eingabe einer spezifischen Challenge, einen Ausgabewert zu erzeugen, der charakteristisch ist für die PUF, den physikalischen Zustand der Komponente und die spezifische Challenge, die Vorrichtung mit einem Speicher und mit einem Prozessor (10), der mit jeder der Komponenten verbunden ist, die eine PUF enthalten, und dafür ausgebildet ist, eine Schwellwertverifikation durchzuführen durch: a) Berechnen von kryptographischen Schwellwertoperationen über mehrere Shares, wobei jedes der mehreren Shares einer spezifischen Komponente und einer Antwort von der PUF der Komponente zugeordnet ist und wobei die Shares der jeweiligen Komponenten nach jeder kryptographischen Schwellwertoperation aktualisiert werden; b) Kombinieren der berechneten kryptographischen Schwellwertoperationen; und c) Überprüfen, ob eine ausreichende Gruppe von mehreren Komponenten, die eine PUF enthalten und durch die mehreren Shares repräsentiert sind, valide ist.
Vorrichtung nach Anspruch 1, wobei der Prozessor (10) dafür ausgebildet ist, eine interaktive Verifikation durchzuführen.
Vorrichtung nach Anspruch 1, wobei der Prozessor (10) dafür ausgebildet ist, eine nicht-interaktive Verifikation durchzuführen.
Vorrichtung nach Anspruch 1, wobei der Prozessor (10) dafür ausgebildet ist, eine Verifikation von einer oder mehreren spezifizierten Gruppen von Komponenten durchzuführen.
Vorrichtung nach Anspruch 4, wobei das System kritische Komponenten aufweist und der Prozessor (10) dafür ausgebildet ist, eine Verifikation von k kritischen Komponenten durch eine (k,k)-Sharing-Erstellung durchzuführen.
Vorrichtung nach Anspruch 1, wobei das System insgesamt n kritische und nichtkritische Komponenten aufweist und der Prozessor (10) dafür ausgebildet ist, eine Verifikation durch eine (t,n)- Sharing-Erstellung durchzuführen.
Vorrichtung nach einem der Ansprüche 1, 2, 3, 4, 5 oder 6, wobei der Prozessor (10) dafür ausgebildet ist, eine kenntnisfreie Beweisauthentifizierung durchzuführen.
Vorrichtung nach einem der Ansprüche 1, 2, 3, 4, 5 oder 6, wobei der Prozessor (10) dafür ausgebildet ist, eine Elliptische-Kurve-Kryptographie auszuführen.
System von Komponenten, ausgebildet die Integrität des Systems einer verifizierenden Vorrichtung nach einem der Ansprüche 1 bis 8 zu bestätigen, wobei jede Komponente einen physikalischen Zustand hat und aufweist: a) eine physikalisch unklonbare Funktion (‚PUF‘) aufweisend eine PUF Eingabe und eine PUF-Ausgabe und dafür ausgebildet, als Antwort auf die Eingabe einer spezifischen Challenge, einen Ausgabewert zu erzeugen, der charakteristisch ist für: i) die PUF, ii) den physikalischen Zustand der Komponente, und iii) die spezifische Challenge; und b) einen Prozessor (10), der mit der PUF verbunden ist und dafür ausgebildet ist, als Antwort auf eine Verifikationsanfrage von der verifizierenden Vorrichtung eine Eingabe an die PUF-Eingabe bereitzustellen und eine Antwort von der PUF Ausgabe zu empfangen und der verifizierenden Vorrichtung ein Share für die Komponente, die eine PUF enthält, eines gemeinsamen Schwellwertbeweises zu berechnen und zu übermitteln, der Shares von mehreren Komponenten erfordert, die eine PUF enthalten.
Vorrichtung nach Anspruch 9, wobei das System insgesamt n kritische und nichtkritische Komponenten aufweist und der kenntnisfreie Beweis auf einer (t,n)- Sharing-Erstellung basiert.
Vorrichtung nach Anspruch 9, wobei der kenntnisfreie Beweis auf einer (k,k)- Sharing-Erstellung basiert.
Vorrichtung nach Anspruch 9, wobei der kenntnisfreie Beweis interaktiv ist.
Vorrichtung nach Anspruch 9, wobei der kenntnisfreie Beweis nicht-interaktiv ist.
Vorrichtung nach einem der Ansprüche 9, 10, 11, 12 oder 13, wobei der kenntnisfreie Beweis auf einer mathematischen Basis von elliptischen Kurven basiert.
Vorrichtung nach einem der Ansprüche 9, 10, 11, 12 oder 13, wobei der gemeinsame Schwellwertbeweis ein kenntnisfreier Beweis ist.