Zusammenfassung

  • Erneuerung oder Rotation verändert den Schlüssel für künftige Releases, macht aber korrekt signierte und rechtzeitig gestempelte Binärdateien nicht automatisch ungültig.
  • Der Wechsel muss artefaktweise belegt werden: Hash, Signaturzertifikat, RFC-3161-Token, wirksame Sperrzeit, Verteilort und beobachtetes Ergebnis des Prüfers gehören in einen gemeinsamen Nachweis.

Mittags stellt ein Softwarehersteller seine Release-Pipeline auf ein neues Zertifikat um. Der erste Build wird korrekt signiert, das Dashboard ist grün. Dennoch liegt eine Datei vom Vorabend weiter auf einem regionalen Spiegel, besitzt einen gültigen Zeitstempel und besteht die Prüfung auf Kundensystemen.

Das ist nicht zwingend ein Fehler. Der Kontrollfehler wäre, die Zertifikatsrotation mit einem abgeschlossenen Vertrauenswechsel gleichzusetzen.

Codesignatur verbindet Bytes mit einer Signaturidentität. Zeitstempel ergänzen eine andere Aussage: Eine vertrauenswürdige Stelle bestätigt, dass ein bestimmter Hash zu einem bestimmten Zeitpunkt existierte. Diese Kombination kann eine Signatur über den normalen Ablauf des Zertifikats hinaus akzeptabel halten. Bei einem später vermuteten Schlüsselverlust kann sie Artefakte vor und nach der wirksamen Sperrzeit trennen.

Damit besitzt das Zertifikat zwei betriebliche Enden. Das erste ist der Ablauf, nach dem keine neue gültige Signatur mehr entstehen sollte. Das zweite ist der Zeitpunkt, ab dem ein Prüfer die Signaturautorität nicht mehr anerkennt. Beide können zusammenfallen, müssen es aber nicht.

Was der Zeitstempel tatsächlich belegt

RFC 3161 definiert einen MessageImprint aus Kennung des Hashverfahrens und Hashwert der Daten. Die Zeitstempelstelle prüft Verfahren und Länge, nicht das Programm. Das Token enthält Richtlinie, eindeutige Seriennummer und genTime und wird mit einem ausschließlich dafür bestimmten Schlüssel signiert.

Das Token sagt daher nicht, dass Software sicher ist. Es belegt, dass ein bestimmter Hash unter einer bestimmten Richtlinie vorgelegt wurde. Es beweist weder die Kontrolle über alle Signaturwege noch die Entfernung der Altversion von allen Spiegeln.

Prüfung bleibt aktive Arbeit. RFC 3161 verlangt die Kontrolle von Antwort, Zertifikat der Zeitstempelstelle, Datenhash, Verfahren, Signatur und zeitlicher Plausibilität. Microsoft bildet dieselbe Trennung in SignTool ab: sign, timestamp und verify sind eigene Befehle. Für RFC 3161 bezeichnet /tr den Server und /td das Digestverfahren. Die Verifikation kann Zertifikatskette und Sperrstatus prüfen, statt nur eine Signaturstruktur festzustellen.

Die ClickOnce-Dokumentation beschreibt die praktische Folge: Mit gültigem Zeitstempel kann eine Anwendung auch nach Ablauf des Signaturzertifikats akzeptiert werden. Das ist sinnvoll, weil nicht jedes einwandfreie historische Paket bei jeder Erneuerung neu signiert werden muss. Gerade diese Beständigkeit macht aber den nächsten Build als alleinigen Erfolgsmaßstab unbrauchbar.

Sperrung erzeugt eine Zeitgrenze

Die Code-Signing-Anforderungen des CA/Browser Forum gelten für öffentlich vertrauenswürdige Zertifikate und zugehörige Zeitstempelstellen. Ausstellende CAs müssen einen RFC-3161-konformen Dienst betreiben, seine Nutzung empfehlen und MessageImprint-Anfragen mit SHA-1 ablehnen.

Die Regeln erklären auch, weshalb Sperrung kein Löschen ist. Ein Zertifikat kann ein Objekt oder Tausende signiert haben; seine Sperrung kann einwandfreie Software zusammen mit verdächtiger Software treffen. Eine CA muss bei einem plausiblen Problembericht binnen vierundzwanzig Stunden mit der Untersuchung beginnen. Bei Schlüsselkompromittierung sollte die wirksame Sperrzeit der früheste belegte Verdachtszeitpunkt sein.

Diese Zeit kann die betroffene Menge begrenzen. Die Anforderungen sagen, dass Objekte mit einem Zeitstempel vor der Sperrzeit weiter als gültig behandelt werden sollten. Das ist eine Programmregel, kein Beweis für identische Ergebnisse auf jeder Plattform.

Die Zeitstempelstelle hat eine eigene Fehlergrenze. RFC 3161 trennt reguläre Stilllegung von Schlüsselkompromittierung. Wird eine Stelle ohne Kompromittierung eingestellt und der Sperrgrund korrekt ausgedrückt, können frühere Tokens gültig bleiben. Wurde der Schlüssel kompromittiert, verdienen seine Tokens kein automatisches Vertrauen; Auditprotokolle oder ein zweiter unabhängiger Zeitstempel können entscheidend werden.

Der Nenner umfasst alle verteilten Artefakte

Ein Zertifikatsinventar genügt nicht. Der Hersteller muss wissen, welches Artefakt signiert wurde, welches Token dazugehört, wo es noch verfügbar ist und wie Zielprüfer es behandeln.

Dazu zählen Downloadseiten, Paketablagen, Caches, Unternehmens-Stores, Updatekanäle, Offline-Installer und Wiederherstellungsmedien. Das Entfernen von der neuesten Seite zieht eine Datei nicht aus allen anderen Flächen zurück. Umgekehrt kann eine breite Sperrung ohne Kenntnis einwandfreier Altpakete eine Sicherheitsreaktion in eine vermeidbare Unterbrechung verwandeln.

Die Mindestkontrolle ist ein Register für den Autoritätswechsel der Artefakte. Für jeden Hash enthält es Build, Version, Zertifikatsfingerabdruck und Seriennummer, Signaturverfahren, Token und Zeitstempelstelle, genTime, Ablauf, Sperrstatus und wirksame Sperrzeit. Diese Angaben werden mit jedem Verteilort, Rückzugs- oder Ersatzstatus, der Prüfrichtlinie und dem beobachteten Ergebnis verbunden.

Damit wird der Abschluss widerlegbar. Der Wechsel ist erst fertig, wenn künftige Builds den vorgesehenen Signierer nutzen, jedes behaltene Altartefakt eine ausdrückliche Entscheidung besitzt, zurückgezogene Dateien aus kontrollierten Flächen verschwunden sind und repräsentative Prüfer das erwartete Ergebnis liefern.

Grenzen der Evidenz

RFC 3161 spezifiziert Token und Prüfung, zertifiziert aber keinen Anbieter. Die Anforderungen des CA/Browser Forum vereinheitlichen nicht alle Betriebssysteme. Microsoft dokumentiert SignTool, Authenticode und ClickOnce, nicht jedes Softwareökosystem.

Hier wird keine Kompromittierung behauptet. Ablauf, Rotation, Sperrung und Ausfall der Zeitstempelstelle sind verschiedene Ereignisse. Ein belastbarer Wechsel hält sie in Beleg und Entscheidung auseinander.

Quellen