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

  • Demonstration und Beispiele für die Nutzung eines RFC3161-Servers aus Java heraus

    15.05.2021

    Ich habe ein Begleitprojekt zu meiner Implementierung meines Timestamping Server Projekts erstellt: eine Demonstration und ein Beispiel dafür, wie man einen solchen Timestamping-Server von Java aus nutzen kann.

    Weiterlesen

Neueste Artikel

  • Asymmetrische Kryptographie

    Ich habe mich mit der Idee schon länger getragen: Nochmal einen Rundumschlag zu asymmetrischer Kryptographie zu machen. Dabei werde ich mich auf Demonstrationen der einzelnen Konzepte und Operationen mit Beispielcode konzentrieren und zu jedem der vorgestellten Konzepte mehr oder weniger ausführlich bezüglich der Einsatzszenarien und Vor- und Nachteile Stellung beziehen

    Weiterlesen
  • Absichern von Truststores und Keystores

    Hin und wieder erlebe ich es persönlich oder lese davon, dass jemand die Frage stellt, wie kryptographische Geheimnisse gesichert werden können. Ich gebe hier mal einen Anstoß, darüber aus der Sicht der Software-Architektur auf Systemebene nachzudenken...

    Weiterlesen
  • Futro-Thin-Clients und PCI Express Mini Cards

    Ich habe mich von einigen Artikeln anderer Besitzer und Upcycler von Futro-Thin-Clients inspirieren lassen - das hat dazu geführt, dass ich von meinem eigentlichen Projekt (Bauen eines kleinen Clusters) abgekommen bin und die Hardware ein wenig genauer unter die Lupe genommen habe...

    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.