Zusammenfassung

  • RFC 1805 sah ein signiertes Zertifikat mit Datei-Hash, Datum und Angaben zum Autor vor; seine Prüfung war vom Speicherort der Datei unabhängig.
  • Die Art der Identitätsprüfung war im Protokoll offen. Bellcores Betsi-Implementierung nutzte die Telefonauskunft und einen Rückruf, um Registrierung und öffentlichen Schlüssel zu bestätigen.

Das Internet transportierte Dateien schon 1995 mühelos von einem Ort zum anderen. Vertrauen in den angeblichen Verfasser ließ sich nicht einfach mitkopieren. Aviel Rubin beschrieb in RFC 1805 eine Lösung mit einem Autor, einem Nutzer und einer vertrauenswürdigen dritten Stelle. Ein Zertifikat sollte Hash und Zeitpunkt einer Datei bestätigen, ganz gleich, woher die Kopie kam. Die Pointe steckt bei der Identität: In der beschriebenen Bellcore-Anwendung Betsi suchte die dritte Stelle eine Telefonnummer über die örtliche Auskunft und rief zurück. Der Datensatz reiste elektronisch; der Vertrauensanker hatte noch einen Hörer.

Rubin stellte zunächst die Prüfsoftware selbst unter Verdacht. Ein Angreifer könnte sowohl die Datei als auch das Programm verändern, das ihre Unversehrtheit behauptet. Ein grünes Ergebnis aus einem kompromittierten Prüfer hilft dann wenig. Deshalb setzte der Vorschlag auf ASCII-Nachrichten und bekannte Signaturverfahren. Leser konnten ein Prüfprogramm selbst bauen oder aus einer unabhängigen vertrauenswürdigen Quelle beziehen. Die Autorität lag in wiederholbaren Schritten und Schlüsseln, nicht im Glanz eines einzigen Programms.

Der Ablauf war in fünf Phasen gegliedert: Anmeldung des Autors, Überprüfung der Identität, Zertifizierung der Datei, Verteilung und Integritätsprüfung. Gerade Phase zwei ließ das Protokoll bewusst offen. Verschiedene Anwendungen durften Personen unterschiedlich prüfen, mussten die gewählte Methode aber im späteren Zertifikat benennen. Eine digitale Signatur verbindet eine Erklärung mit einem Schlüssel; wem der Schlüssel gehört, ist eine eigene Frage. Betsi verwendete laut RFC in den USA die Telefonauskunft im Wohnort des Autors, rief die gefundene Nummer an und prüfte die Anmeldedaten einschließlich des öffentlichen Schlüssels.

Der Telefonweg war eine konkrete Implementierungsentscheidung, keine allgemeine Pflicht.

Nach der Anmeldung berechnete der Autor einen kryptografischen Hash seiner Datei und schickte eine signierte Bitte um Zertifizierung an die dritte Stelle. Diese prüfte die Bitte und signierte ein Zertifikat mit Hash, Hash-Verfahren, Datum, Autorname und Methode der Identitätsprüfung. Der Ablageort der Datei war im Antrag optional. Das ist der Kern der Ortsunabhängigkeit: Die Aussage betraf die Bytes und ihre Zeit, nicht die Adresse eines FTP-Verzeichnisses. Datei und Zertifikat konnten zusammen auch über unsichere Wege verteilt werden.

Beim Empfänger begann die Arbeit von vorn, aber mit anderen Aufgaben. Er musste den öffentlichen Schlüssel der dritten Stelle aus unabhängigen Quellen beziehen, ihre Signatur prüfen und entscheiden, ob er der angegebenen Autorenprüfung vertraute. Anschließend berechnete er den Hash der tatsächlich erhaltenen Datei und verglich ihn mit dem zertifizierten Wert. Falls das Datum wichtig war, prüfte er auch dieses. Schließlich sah er in einer aktuellen, vollständigen und signierten Sperrliste nach, ob das Zertifikat widerrufen worden war. Ein hübsches Siegel mit übergangener Sperrliste ist Bürokratie als Dekoration.

Erst diese Kette trägt die eng begrenzte Aussage, dass die vorliegenden Bytes zu einer unter bestimmten Bedingungen bestätigten Datei und einem Datum passen. Ob die Software ausgeführt werden sollte, entscheidet das Zertifikat nicht. Gerade der Rückruf zeigt die Spannung in Rubins Architektur: Der Vertriebsweg wurde beweglich, während die Identität eine überprüfbare Handlung mit benanntem Verantwortlichen brauchte.