Proof of Existence via HTTPS

Proof of existence

“Proof of Existence” hilft, später nachzuweisen, dass man zu einem bestimmten Zeitpunkt eine bestimmte Datei oder einen bestimmten Datenbestand vorliegen hatte.

Zum Beispiel kann man damit beweisen, wann man eine bestimmte Idee hatte; der “Datenbestand” ist in dem Fall einfach eine Text- oder Officedatei, in die hinein man die Idee aufgeschrieben hat (und hoffentlich sich selbst als Autor genannt).

Die Datei selbst verwahrt man gut geschützt auf. Als ihr Stellvertreter wird ihr “Fingerabdruck” genutzt, also ein kryptographisch sicherer Hashwert, zum Beispiel der SHA256.

Um später beweisen zu können, wann man die Idee hatte, möchte man diesen SHA256-Fingerabdruck möglichst unfälschbar mit einem Zeitstempel verknüpfen, zu dem er vorlag.

Die HTTPS-Idee

Eine gängige Möglichkeit, das zu tun, ist es, den Hash in die Blockchain einer Kryptowährung einzubetten. Die Luxembourger Börse nutzt ein entsprechendes Verfahren. Ein entsprechender Dienst ist öffentlich verfügbar.

Eine andere einfache Möglichkeit, das zu tun, ist es, den SHA256-Wert in einen Hostnamen einzubetten und sich ein gängiges HTTPS-Zertifikat für diesen Hostnamen zu besorgen. Im Zertifikat wird der Hostname von einer (hoffentlich) vertrauenswürdigen Stelle digital unterschrieben. Diese digitale Unterschrift ist mit einem Zeitstempel versehen: Dem Beginn der Gültigkeit des Zertifikats.

Durch bloßes Vorweisen des Zertifikats kann man beweisen, zu diesem Zeitstempel über ein Dokument mit dem fraglichen Hash verfügt zu haben.

Beispielhafte Umsetzung

Dieses Konzept wurde probehalber in die Praxis umgesetzt wie folgt:

Eine Zusammenfassung (Vorabversion) dieser Idee wurde zunächst in einer eigenen Datei idea.txt abgelegt. Wichtig ist, dass der Autor mit dabei steht. Um zu schauen, wie lange die Umsetzung dauert, habe ich auch einen Zeitstempel mit hinein geschrieben.

Die sha256sum Prüfsumme dieser Datei ist, hexadezimal ausgedrückt:

b42edb7736acfe1f990596d8de2f9f66a8b286785f6ccbf845bc90b378bbf30d

Leider erlaubt DNS nur Namen von maximal 63 Zeichen Länge. Dieser Hexstring ist aber 64 Zeichen lang. Als Behelf wird er durch einen “.” in zwei DNS-Namen zerlegt (Host und Subdomain).

Ich habe auf die Schnelle meine private Domain famsik.de für dieses Experiment herangezogen. Das war bequem, denn für diese Domain habe ich die nötigen Skripte für lets' encrypt schon installiert und volle Kontrolle über DNS und Webserver. Man hätte die Umsetzung auch über eine beliebige andere eigene Domain machen können, die in einer Cloud gehostet ist.

Ich habe also zunächst im DNS einen Eintrag angelegt

b42edb7736acfe1f990596d8de2f9f66.a8b286785f6ccbf845bc90b378bbf30d.famsik.de

und gewartet, bis er global zur Verfügung steht. Zwischendurch habe ich den Webserver passend konfiguriert und dann das HTTPS-Zertifikat besorgt und eingespielt.

Überprüfung

Nun kann jeder meine Behauptung überprüfen, dass ich mir diese Idee am oder vor dem 13.2.2018 ausgedacht habe. Das geht so:

Man besorgt sich die Datei idea.txt, und überprüft erstens, dass sie inhaltlich diese Idee beschreibt und zweitens die Prüfsumme:

$ sha256sum idea.txt
b42edb7736acfe1f990596d8de2f9f66a8b286785f6ccbf845bc90b378bbf30d  idea.txt

Nun besorgt man sich den Schlüssel, den mein Webserver ausliefert. Solange der noch nicht abgelaufen ist, kann man das tun mit

name=b42edb7736acfe1f990596d8de2f9f66.a8b286785f6ccbf845bc90b378bbf30d.famsik.de
openssl s_client -connect $name:443 -servername $name -verify_return_error -showcerts  < /dev/null

Später gibt es den Schlüssel hier: key1.pem.

Nun überprüft man, dass im Output von

openssl x509 -in key1.pem -noout -text

erstens ein passender Zeitstempel auftaucht

Validity
    Not Before: Feb 13 14:06:01 2018 GMT

und zweitens der gesuchte Hash-Wert:

X509v3 Subject Alternative Name: 
    DNS:b42edb7736acfe1f990596d8de2f9f66.a8b286785f6ccbf845bc90b378bbf30d.famsik.de, ...

Schließlich ist (wie üblich) zu überprüfen, ob der Schlüssel valide ist. Dazu benötigt man den Zwischenschlüssel key2.pem und kann sich zum Beispiel des folgenden Befehls bedienen:

$ openssl verify -untrusted key2.pem key1.pem
key1.pem: OK

Probleme dieses Ansatzes

Zeitstempel-Genauigkeit

Ich habe das Zertifikat laut Log um 15:05:47 UTC bei lets' encrypt angefordert, das entspricht 16:05:47 MEZ. Das ausgestellte Zertifikat gilt aber bereits knapp eine Stunde eher. Offensichtlich umgeht lets' encrypt so Probleme mit ungenau gehenden Uhren. Für “Proof of Existence”-Zwecke wären präzise Zeitstempel nützlicher.

Ob die Zeitstempel-Ungenauigkeit vorhanden ist und stört, kommt auf den verwendeten Zertifikats-Ausstellerdienst an und den Anwendungsfall.

Abgelaufende Zertifikate

Der “Proof of Existence” gelingt, so lange das Zertifikat gültig ist.

Nach Ablauf seiner Gültigkeit lässt sich noch überprüfen, ob es zu einem relevanten früheren Zeitpunkt gültig war. Zum Beispiel kann man openssl fragen: “War dieses Zertifikat am 2018–02–13 16:00 MEZ gültig?”

Dazu vergewissert man sich, dass “2018–02–13 16:00 MEZ” einem UNIX-Zeitstempel von 1518534000 entspricht, und führt aus:

openssl verify -attime 1518534000 -untrusted key2.pem key1.pem

Das Hantieren mit bereits abgelaufenen Zertifikaten ist natürlich eine zunächst etwas anrüchige Angelegenheit.

Man kann dieses Problem dadurch angehen, dass man eine Kette baut: Kurz vor Ablauf der Gültigkeit des Zertifikats erstellt man ein neues Dokument. Dieses Dokument enthält Hash-Werte des ursprünglichen, zu schützenden Dokuments sowie den Hash-Wert des (zu diesem Zeitpunkt noch gültigen) Zertifikats (Hash-Werte beider Keys o.ä.). Für dieses Dokument erstellt man nun einen neuen “Proof of Existence”, wofür ein neues Zertifikat besorgt wird. Das Ziel dieser Übung: Dieses neue Zertifikat gilt nun weiter in die Zukunft hinein als das alte. Ehe es abläuft, schmiedet man analog wieder ein neues Glied an die Kette.

Selbst, wenn man an eine Zertifizierungsstelle gerät, die nach Ablauf der Zertifikate die zu ihrer Ausstellung benutzten privaten Schlüssel veröffentlicht, kann man mit Hilfe dieser Kette doch nachweisen, dass man die Zertifikate schon hatte, ehe die jeweiligen Schlüssel veröffentlicht wurden.

TAGS

Comments

Please accept our cookie agreement to see full comments functionality. Read more