10. Frische

10. Frische

Ein Verifizierer oder eine vertrauende Partei muss möglicherweise den Zeitpunkt (d. h. die „Epoche") erfahren, zu dem ein Nachweis oder ein Attestierungsergebnis erstellt wurde. Dies ist entscheidend für die Entscheidung, ob die enthaltenen Ansprüche als frisch angesehen werden können, was bedeutet, dass sie immer noch den neuesten Zustand des Attestierers widerspiegeln und dass jedes Attestierungsergebnis unter Verwendung der neuesten Bewertungsrichtlinie für Nachweise, Endorsements und Referenzwerte generiert wurde.

Dieser Abschnitt bietet eine Reihe von Details. Er definiert jedoch keine Protokollformate, und die gezeigten Interaktionen sind abstrakt. Dieser Abschnitt richtet sich an diejenigen, die Protokolle und Lösungen erstellen, um die verfügbaren Optionen zur Gewährleistung der Frische zu verstehen. Die Art und Weise, wie Frische in einem Protokoll bereitgestellt wird, ist eine architektonische Entscheidung. Die Bereitstellung von Frische hat Auswirkungen auf die Anzahl der erforderlichen Roundtrips in einem Protokoll; daher muss sie sehr früh im Design getroffen werden. Unterschiedliche Entscheidungen werden erhebliche Auswirkungen auf die resultierende Interoperabilität haben, weshalb dieser Abschnitt ausreichend detailliert ist, damit Entscheidungen zur Frische über interagierende Protokolle hinweg kompatibel sind, wie in Abbildung 9 dargestellt.

Frische wird basierend auf der Bewertungsrichtlinie für Nachweise oder Attestierungsergebnisse bewertet, die die geschätzte Epoche mit einem lokal für diese Richtlinie definierten „Ablauf"-Schwellenwert vergleicht. Es ist jedoch immer eine Race-Condition möglich, da sich der Zustand des Attestierers und die Bewertungsrichtlinien unmittelbar nach der Generierung des Nachweises oder des Attestierungsergebnisses ändern können. Das Ziel besteht lediglich darin, deren Aktualität auf etwas einzugrenzen, das der Verifizierer (für Nachweise) oder die vertrauende Partei (für Attestierungsergebnisse) zu akzeptieren bereit ist. Eine gewisse Flexibilität bei der Frischeanforderung ist eine Schlüsselkomponente für die Aktivierung von Caching und Wiederverwendung sowohl von Nachweisen als auch von Attestierungsergebnissen, was besonders wertvoll ist, wenn deren Berechnung einen erheblichen Teil des Ressourcenbudgets verwendet (z. B. Energie in eingeschränkten Geräten).

Es gibt drei gängige Ansätze zur Bestimmung der Epoche eines Nachweises oder eines Attestierungsergebnisses.

10.1. Explizite Zeiterfassung mit synchronisierten Uhren

Der erste Ansatz besteht darin, sich auf synchronisierte und vertrauenswürdige Uhren zu verlassen und einen signierten Zeitstempel (siehe [RATS-TUDA]) zusammen mit den Ansprüchen im Nachweis oder Attestierungsergebnis einzuschließen. Zeitstempel können auch pro Anspruch hinzugefügt werden, um die Zeit der Generierung von Nachweisen oder Attestierungsergebnissen von der Zeit zu unterscheiden, zu der ein bestimmter Anspruch generiert wurde. Die Vertrauenswürdigkeit der Uhr kann im Allgemeinen über Endorsements festgestellt werden und erfordert typischerweise zusätzliche Ansprüche über den Zeitsynchronisierungsmechanismus des Unterzeichners.

Eine vertrauenswürdige Uhr ist jedoch in einigen Anwendungsfällen möglicherweise nicht verfügbar. Beispielsweise ist in vielen heutigen TEEs eine Uhr nur außerhalb der TEE verfügbar; daher kann die TEE ihr nicht vertrauen.

10.2. Implizite Zeiterfassung mit Nonces

Ein zweiter Ansatz legt die Last der Zeiterfassung allein auf den Verifizierer (für Nachweise) oder die vertrauende Partei (für Attestierungsergebnisse). Dieser Ansatz könnte beispielsweise geeignet sein, wenn der Attestierer keine vertrauenswürdige Uhr hat oder die Zeitsynchronisierung anderweitig beeinträchtigt ist. Bei diesem Ansatz wird eine unvorhersehbare Nonce von der bewertenden Entität gesendet, und die Nonce wird dann signiert und zusammen mit den Ansprüchen im Nachweis oder Attestierungsergebnis eingeschlossen. Nach der Überprüfung, dass die gesendeten und empfangenen Nonces identisch sind, weiß die bewertende Entität, dass die Ansprüche nach der Generierung der Nonce signiert wurden. Dies ermöglicht die Zuordnung einer „groben" Epoche zum Nachweis oder Attestierungsergebnis. In diesem Fall wird die Epoche als grob bezeichnet, weil:

• Die Epoche auf den gesamten Anspruchssatz anstatt auf eine granularere Zuordnung angewendet wird, und

• Die Zeit zwischen der Erstellung von Ansprüchen und der Sammlung von Ansprüchen nicht unterscheidbar ist.

10.3. Implizite Zeiterfassung mit Epochen-IDs

Ein dritter Ansatz beruht darauf, dass Epochen-Identifikatoren (IDs) periodisch sowohl an den Sender als auch an den Empfänger von Nachweisen oder Attestierungsergebnissen durch einen „Epochen-ID-Verteiler" gesendet werden.

Epochen-IDs unterscheiden sich von Nonces, da sie mehr als einmal verwendet werden können und sogar gleichzeitig von mehr als einer Entität verwendet werden können. Epochen-IDs unterscheiden sich von Zeitstempeln, da sie keine Informationen über einen Zeitpunkt vermitteln müssen, d. h. sie sind nicht notwendigerweise monoton steigende Ganzzahlen.

Wie beim Nonce-Ansatz ermöglicht dies die Zuordnung einer „groben" Epoche, ohne dass eine vertrauenswürdige Uhr oder Zeitsynchronisierung erforderlich ist, um die Frische von Nachweisen oder Attestierungsergebnissen zu generieren oder zu bewerten. Nur der Epochen-ID-Verteiler benötigt Zugriff auf eine Uhr, damit er periodisch neue Epochen-IDs senden kann.

Die neueste Epochen-ID ist in den produzierten Nachweisen oder Attestierungsergebnissen enthalten, und die bewertende Entität kann die Epochen-ID in empfangenen Nachweisen oder Attestierungsergebnissen mit der neuesten Epochen-ID vergleichen, die sie vom Epochen-ID-Verteiler erhalten hat, um festzustellen, ob sie sich innerhalb der aktuellen Epoche befindet. Eine tatsächliche Lösung muss auch Race-Conditions beim Übergang zu einer neuen Epoche berücksichtigen, beispielsweise durch Verwendung eines vom Epochen-ID-Verteiler signierten Zählers als Epochen-ID, durch Einbeziehung sowohl der aktuellen als auch der vorherigen Epochen-IDs in Nachrichten und/oder Überprüfungen durch Anforderung von Wiederholungsversuchen bei nicht übereinstimmenden Epochen-IDs oder durch Pufferung eingehender Nachrichten, die möglicherweise mit einer Epochen-ID verknüpft sind, die der Empfänger noch nicht erhalten hat.

Allgemeiner gesagt, sollte die bewertende Entität ein „Epochenfenster" bestehend aus den zuletzt empfangenen Epochen-IDs aufrechterhalten, um zu verhindern, dass sie falsch negative Ergebnisse generiert (z. B. Verwerfen von Nachweisen, die als veraltet eingestuft werden, obwohl sie es nicht sind). Die Tiefe eines solchen Epochenfensters ist direkt proportional zur maximalen Netzwerkausbreitungsverzögerung zwischen dem ersten Empfänger der Epochen-ID und dem letzten Empfänger der Epochen-ID und umgekehrt proportional zur Epochendauer. Die bewertende Entität muss die in den empfangenen Nachweisen oder Attestierungsergebnissen enthaltene Epochen-ID mit den Epochen-IDs in ihrem Epochenfenster vergleichen, um eine geeignete Übereinstimmung zu finden.

Während der Nonce-Ansatz typischerweise erfordert, dass die bewertende Entität einen Zustand für jede generierte Nonce beibehält, minimiert der Epochen-ID-Ansatz den beibehaltenen Zustand so, dass er unabhängig von der Anzahl der Attestierer oder Verifizierer ist, von denen er erwartet, Nachweise oder Attestierungsergebnisse zu erhalten, solange alle denselben Epochen-ID-Verteiler verwenden.

10.4. Diskussion

Implizite und explizite Zeiterfassung können zu hybriden Mechanismen kombiniert werden. Wenn beispielsweise Uhren in der Attestierungsumgebung vorhanden sind und als vertrauenswürdig (manipulationssicher) angesehen werden, aber nicht synchronisiert sind, kann ein Nonce-basierter Austausch verwendet werden, um den (relativen) Zeitversatz zwischen den beteiligten Peers zu bestimmen, gefolgt von einer beliebigen Anzahl von Zeitstempel-basierten Austauschen.

Es ist wichtig zu beachten, dass die tatsächlichen Werte in Ansprüchen möglicherweise lange vor der Unterzeichnung der Ansprüche generiert wurden. Wenn dies der Fall ist, liegt es in der Verantwortung des Unterzeichners sicherzustellen, dass die Werte zum Zeitpunkt der Unterzeichnung noch frisch sind. Beispielsweise können beim Booten generierte Werte im sicheren Speicher gespeichert worden sein, bis die Netzwerkverbindung zum entfernten Verifizierer hergestellt ist und eine Nonce erhalten wird.

Eine ausführlichere Diskussion mit Beispielen findet sich in Anhang A.

Für eine Diskussion über die Sicherheit von Epochen-IDs siehe Abschnitt 12.3.