Wie validiert man einen Timestamp und was sagt er aus?

vorhergehende Artikel in: PKI-X.509-CA Security
30.04.2023

Ich wundere mich wirklich, wie oft es vorkomt, dass Leute nur halb verstanden haben, wie das mit der IT-Security funktioniert. Das inzwischen vorletzte Mal hatte ich mich über Github echauffiert. Diesmal möchte ich die Gelegenheit nutzen, hier einmal aufzuschreiben, was beim Erstellen eines kryptographisch abgesicherten Zeitstempels wirklich geschieht und was bei dessen Verifizierung zu beachten ist.

Bereits in einem früheren Artikel wies ich darauf hin, dass in der heutigen schnellebigen Zeit einfache Sachverhalte von einer überraschend großen Anzahl der Menschen missverstanden und nicht hinterfragt werden - besonders von solchen, die eigentlich dem Sachverhalt und Fachgebiet doch recht nahestehen. Mein Aufhänger war dabei die allfällige Kritik an biometrischen Merkmalen im Ausweis und Reisepass.

Es existiert aber in diesem Dunstkreis der IT-Sicherheit ein weiterer Bereich, der oft missverstanden wird: der des kryptographisch abgesicherten Zeitstempels. Prinzipiell dient er dazu, einen Anwendungsfall abzudecken, denm auch ein klassischer Notar anbietet: Die Verbriefung des Sachverhalts, dass eine bestimmte Information in genau dieser Form bereits ab einem bestimmten Zeitpunkt vorlag.

Bildet man diesen Sachverhalt mit einem kryptographisch abgesicherten Zeitstempel ab, geschieht auf technischer Ebene folgendes: Der Sachverhalt, dessen Vorhandensein zu einem bestimmten Zeitpunkt verbrieft werden soll, liegt in elektronischer Form als Sammlung von Bit vor - als ein Dokument. Von diesem Dokument berechnet derjenige, der die Bestätigung für dessen Vorhandensein erlangen möchte einen Hashwert und lässt diesen durch eine Timestamping Authority bestätigen. Ergebnis dieses Prozesses ist eben besagter kryptographisch abgesicherte Zeitstempel.

Die Integrität dieses Zeitstempels kann nun überprüft werden. Mit OpenSSL funktioniert das zum Beispiel mit diesem Kommando:

openssl ts -verify -config tsa.conf -queryfile <request>.tsq -in <reply>.tsr -CAfile chain.pem

Der interessante Teil ist hier .tsq - dieser Request enthält lediglich den Hashwert - nicht das Dokument! Verlässt man sich auf diese Verifikation, die lediglich bestätigt, dass der Timestamping Request zu dem in der Reply angegebenen Zeitpunkt existiert hat, hat man über den eigentlichen Fall, dass das Dokument, aus dem der Hashwert erzeugt wurde, nichts erfahren.

Ich illustriere das mal an einem Beispiel: Man stelle sich vor, es existiert eine bösartige Agentur, die auf Gewinnmaximierung aus ist. Man stelle sich weiter vor, dass alle aktuellen Hashalgorithmen mit einem Male unsicher werden und deshalb durch einen neuen ersetzt werden müssen. Dann könnte besagte Agentur einfach alle möglichen Hashwerte generieren und damit Timestamps erzeugen. Sobald jetzt jemand daherkommt und seine Ansprüche auf eine wichtige Erfindung oder ein erfolgreiches Werk mittels seines Timestamps anmelden, kann die Agentur einfach ihren eigenen mit einem früheren Zeitstempel versehenen Hashwert vorweisen und diese Ansprüche bestreiten.

Daher ist es immens wichtig, dass bei der Verifikation eines Zeitstempels unmittelbar nicht nur der Request zur Verifikation herangezogen wird, sondern nachgewiesen wird, dass das Dokument genau den im Request angegebenen Hashwert erzeugt!

Alle Artikel rss Wochenübersicht Monatsübersicht Codeberg Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Links - Verschiedenes

    03.11.2020

    Hier einmal einige Links, die einfach in keine Kategorie passen...

    Weiterlesen

Neueste Artikel

  • Immich, Karakeep und Radicale neu im Docker-Zoo

    Ich habe längere Zeit keine Erweiterung meines Docker-Zoos vorgenommen - auch weil ich mir einige konzeptionelle Gedanken dazu gemacht habe. Aber ich habe auch Ideen gesammelt, was in meinem @homelab noch fehlt und was dringend ergänzt werden sollte.

    Weiterlesen
  • Thin Client als Notfall-NAS?

    Eine Diskussion brachte mich neulich auf eine Idee - und im Urlaub hatte ich an einem regnerischen Tag genug Zeit, die entsprechenden Experimente zu machen...

    Weiterlesen
  • Cloud - das unentdeckte Neuland (oder FDP: Digital first, Bedenken second)...

    Nachdem die Öffentlichkeit letzte Woche wieder mal mitgekriegt haben sollte, dass die Konzentration in der Cloud Schwachsinn ist und - vielleicht nicht - die ganze Öffentlichkeit vor zwei Wochen wieder einmal herzlich gelacht hat über die, die dennoch alles in die Cloud auslagern, aber offensichtlich nicht verstehen, wie sie funktioniert - hier einige Gedanken von mir dazu...

    Weiterlesen

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muss damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen Codeberg-Repositories findet man hier.