Zusammenfassung

  • Eine gültige Antwort belegt eine signierte, begrenzte Zeitbehauptung und die Einbeziehung der Anfrage; sie belegt nicht die Richtigkeit der Uhr.
  • Ein Malfeasance-Bericht kann Reihenfolge und Widerspruch beweisen und zeigen, dass mindestens ein Server falsch lag. Zurechnung und Widerruf bleiben eigene Entscheidungen.

Drei Zeitserver liefern gültige Signaturen. Die Antworten sind so verkettet, dass ihre Empfangsfolge nicht nachträglich vertauscht werden kann. Trotzdem passen die gemeldeten Intervalle nicht zusammen. Der Widerspruch steht fest. Der Verursacher nicht.

Diese Unterscheidung ist die stärkste operative Aussage von Roughtime Revision 19. Der aktive NTP-Working-Group-Entwurf ist für Experimental vorgesehen und befindet sich im RFC-Editor-Prozess, ist aber noch kein RFC. Gegenüber Revision 18 überwiegen redaktionelle Änderungen; eine neue Zurechnungsregel wird nicht behauptet.

Signiert heißt nicht wahr

Der Client sendet einen Nonce. Der Server bindet die Anfrage als Blatt in einen Merkle-Baum ein und signiert eine Antwort mit Mittelpunkt MIDP, Unsicherheitsradius RADI und Baumwurzel. Ein temporärer Ed25519-Schlüssel signiert die Antwort, der Langzeitschlüssel die Delegation mit MINT und MAXT.

Geprüft werden Delegationssignatur, Antwortsignatur, Anfrageeinschluss und Gültigkeitsintervall. Danach ist die Antwort gültig. Der Entwurf sagt ausdrücklich, dass damit der Zeitwert nicht bewiesen ist. Belegt ist die Garantie des Servers, die Behauptung im Intervall (MIDP-RADI, MIDP+RADI) signiert zu haben. Kryptografie schützt die Herkunft der Aussage, nicht automatisch die physische Uhr dahinter.

Eine Kette, mehrere mögliche Täter

Für den Mehrserverbetrieb braucht der Client mindestens drei erreichbare Server unterschiedlicher Betreiber. Er fragt sie nacheinander ab und wiederholt dieselbe Reihenfolge. Jeder spätere Nonce hängt von der vollständigen vorigen Antwort und neuer Zufälligkeit ab. So wird aus Einzelantworten eine kausale Beweiskette.

Verletzen gültige Intervalle die Empfangsordnung, nennt der Entwurf das Malfeasance. Der Bericht enthält erwartete Schlüssel, Zufallswerte, Anfragen und Antworten in Reihenfolge. Er kann zeigen, dass mindestens ein Server die falsche Zeit geliefert hat.

Er kann nicht allein zeigen, welcher. Zwei korrelierte Quellen können einen ehrlichen Außenseiter wie den Fehler aussehen lassen. Betreiberdiversität, unabhängige Zeitquellen und die Herkunft der Serverliste sind daher Teil der Evidenz, nicht nur Betriebsdetails.

Die Entscheidungsinstanz fehlt mit Absicht

Spezifiziert sind Listen- und Berichtsformat. Nicht spezifiziert sind Aufnahme, Entfernung, Beweismaß, Fallannahme, Zurechnung, Berufung und Schlüsselwiderruf. Ein Forum menschlicher Beobachter erscheint nur als mögliche einfache Lösung. Gleichzeitig bezeichnet der Text Listenpflege und Regelverletzungsentscheidung als sicherheitswesentlich.

Ein Betreiber sollte deshalb Rohantwort, kryptografische Gültigkeit, widersprüchliches Paar, Listenversion, Einreichung, Prüfung, Zurechnung, Widerruf und Verteilung getrennt speichern. Ein versandter Bericht ist kein angenommener Fall; ein angenommener Fall ist keine Zurechnung; ein Widerruf ist noch keine behobene Folgewirkung.

Auch MAXT beseitigt keine Vergangenheit. Wird ein delegierter privater Schlüssel später kompromittiert, lassen sich falsche Aussagen in sein altes Intervall zurückdatieren. Rotation ist notwendig, aber kein Radiergummi für historische Evidenz.

Roughtime kann Zertifikatsprüfung anstoßen und NTP/PTP-Beobachtungen begrenzen. Es ist weder gesetzlicher Zeitstempel noch Transaktionsreihenfolge, Geräteintegritätsbeweis oder Ausführungsquittung.