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

  • Styles für GeoJSON in EBMap4D

    22.08.2021

    Ich habe bereits darüber berichtet, dass EBMap4D jetzt über die Möglichkeit verfügt, beliebige GeoJSON-Layer darzustellen. Nun ist die Anwendung um die Möglichkeit erweitert worden, in diesen GeoJSON-Daten enthaltene Stilinformationen für die Darstellung zu nutzen.

    Weiterlesen

Neueste Artikel

  • Linux-System SBOM visualisiert als Graph - für YUM!

    Ich schrieb vor einiger Zeit über die Visualisierung und Analyse von Abhängigkeiten in Linux-Distributionen, die auf Debian aufbauen. Damals habe ich noch behauptet, dass andere Distributionen, die zum Beispiel auf yum als Paketmanagement-Lösung setzen nur schwer in dieser Art und Weise analysierbar sind. Ich habe weiter recherchiert und nun auch dafür eine Lösung gefunden.

    Weiterlesen
  • 35 Jahre Antipatterns in Datenmodellen

    Ich habe inzwischen 35 Jahre Softwareentwicklung auf dem Buckel - viele davon für Geld...

    Weiterlesen
  • Highlights der DefCon 34

    Hier meine Highlights der DefCon 34 in Las Vegas

    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.