Zusammenfassung

  • Statisches Geheimnis und veränderlicher Verbrauchsstand erfüllen verschiedene Aufgaben. Ein Backup kann authentisch sein, obwohl sein OTS-Index hinter bereits freigegebenen Signaturen zurückliegt.
  • Freigabe einer vollständigen Signatur und dauerhaftes Fortschreiben des Zustands müssen wie eine einzige Transaktion wirken. Sektoren, reservierte Intervalle und Zeitfenster helfen nur, wenn ihre Zuständigkeiten nach der Wiederherstellung nicht überlappen.
  • HSM-Selbsttest und gültige Testsignatur belegen Funktionsfähigkeit, nicht die ausschließliche Verfügung über unbenutzte Indizes. Dafür braucht die Aktivierung einen nachvollziehbaren Verwahrungsbeleg.

Die gefährlichste Wiederherstellung sieht erfolgreich aus. Das Backup lässt sich entschlüsseln, sein Hash stimmt, das HSM nimmt den Import an und eine Testsignatur wird unter dem bekannten öffentlichen Schlüssel verifiziert. Bei einer zustandsbehafteten Hash-Signatur bleibt dennoch offen, ob der verwendete Index schon vor dem Ausfall in einer anderen Signatur sichtbar wurde.

Genau diese Betriebslücke ordnet RFC 10033, ein Informational-Dokument im IETF-Stream. XMSS und LMS verbinden viele Einmalsignaturschlüssel, OTS, zu einer langlebigen Struktur. Wird dasselbe OTS-Geheimnis für unterschiedliche Nachrichten benutzt, kann die Offenlegung eine Fälschung rechnerisch praktikabel machen. Die Sicherheit beruht daher auf Geheimhaltung und auf einer Geschichte, die nicht zurückspringen darf.

Das echte Backup aus der Vergangenheit

Ein Backup wird etwa beim nächsten freien Index 25.000 erstellt. Der aktive Signierer gibt danach 600 Signaturen aus und erreicht 25.600. Nach Verlust des aktuellen Zustands wird die ältere Kopie geladen. Das Geheimnis ist richtig und seine Signaturen sind gültig, doch die Indizes 25.000 bis 25.599 erscheinen wieder frei. Außerhalb des Systems sind sie längst verbraucht.

Nicht die Datei ist gefälscht, sondern ihre zeitliche Aussage ist überholt. Eine Prüfsumme schließt weder eine spätere Version noch einen weiterlaufenden Klon aus. RFC 9802 warnt entsprechend, dass herkömmliches Kopieren und Wiederherstellen privater Schlüssel ohne richtige Zustandskoordination wahrscheinlich zur OTS-Wiederverwendung führt.

NIST SP 800-208 zieht für zugelassene Profile eine enge Grenze: Schlüssel und Signaturen entstehen in Hardware-Kryptomodulen, privates Schlüsselmaterial wird nicht exportiert. RFC 10033 behandelt zusätzlich Verfahren außerhalb dieses Profils. Beides ist auseinanderzuhalten. Eine beschriebene Exportmethode macht den Export in einem NIST-konformen Modul nicht zulässig.

Statisches Geheimnis, bewegliche Zuständigkeit

Das Geheimnis ermöglicht eine gültige Signatur. Der Zustand entscheidet, welche Kapazität noch exklusiv ist. Zähler, Reservierungen, Geräteidentität, Antwortprotokolle, Warteschlangen, VM-Snapshots und der Nachweis einer stillgelegten Quelle gehören deshalb zur Sicherheitsgrenze.

Wiederherstellung wird damit zur Prüfung von Exklusivität statt bloß von Integrität. Zwei echte Kopien können technisch richtig signieren und dennoch denselben Bereich beanspruchen. Prozess-Forks, ungepufferte Schreibvorgänge, VM-Klone oder eine parallele Notfallaktivierung an zwei Standorten schaffen solche Überschneidungen.

Erst fortschreiben, dann ausgeben

RFC 8391 verlangt für XMSS die Aktualisierung des privaten Zustands vor der Signaturausgabe; RFC 8554 setzt die entsprechende Regel für LMS. RFC 10033 beschreibt Zustandsfortschritt und Signaturfreigabe als Vorgang, der Atomarität, Konsistenz, Isolation und Dauerhaftigkeit braucht.

Wird der Fortschritt zuerst gespeichert und fällt das System vor der Antwort aus, geht ein Index verloren, wird aber nicht wiederverwendet. Geht die Signatur zuerst hinaus und die Zustandsänderung danach verloren, hält das System einen extern verbrauchten Index für frei. Kapazitätsverlust und Integritätsrisiko sind nicht gleichwertig. Bei Unsicherheit ist das Verwerfen eines begrenzten Bereichs die sichere Richtung.

Sektoren, Intervalle und Zeitfenster

Sektoren teilen unabhängige Fragmente unter einem gemeinsamen öffentlichen Schlüssel auf. Vorabzuweisungen geben Geräten überschneidungsfreie Bereiche. Intervallreservierung verpflichtet einen ganzen Block vor dem Signieren und verwirft bei einem Absturz den unbenutzten Rest. Zeitfenster binden Kapazität an Perioden; dabei darf die logische Uhr nie zurückgestellt und ein abgelaufenes Fenster nie wieder geöffnet werden.

Diese Werkzeuge definieren eine Verwahrungseinheit, beseitigen den Zustand aber nicht. Bei einer Übertragung muss die Quelle aufhören, und das Ziel darf weder mit aktiven oder ausgefallenen Geräten noch mit Offline-Kopien kollidieren. Teilübertragungen und spätere Zusammenführungen brauchen dieselbe lückenlose Zuordnung.

Außerhalb des nicht exportierbaren NIST-Profils beschreibt RFC 10033 vorbereitete untere Bäume. Ihre Wurzel wird mit einem unbenutzten oberen OTS-Schlüssel signiert; Seed, Signatur, Index und Hash werden exportiert und die Quellkopie unwiderruflich gelöscht. Die Wiederherstellung importiert den ersten unbenutzten Seed, erzeugt den Baum neu, vergleicht den Hash und löscht den Seed vom Backupmedium. Das macht den Eigentumswechsel sichtbar. Gerade nach einem Totalausfall oder bei externer Verwahrung bleibt aber schwer beweisbar, dass jede Quelle gelöscht wurde.

Der Verwahrungsbeleg

RFC 10033 schreibt keinen universellen Beleg vor. Der hier vorgeschlagene Beleg soll die Notfallentscheidung nachprüfbar machen.

Er sollte öffentlichen Schlüssel, Algorithmus und Parameter, Signierer und HSM, Backupgeneration und Erstellungszeit, wiederhergestellten Zustand, höchsten beobachteten Index einer vollständigen Signatur, Sektor-, Intervall- oder Zeitgrenzen, verworfene Reservierungen, Stilllegungs- und Löschbelege, Pakethashes, Bediener, Freigabeverantwortlichen sowie Aktivierungs- und Abgleichzeit enthalten.

Auch Unsicherheit gehört hinein. Steht der letzte dauerhafte Zustand bei 80.000, während eine Antwortwarteschlange bis 80.095 ausgeliefert haben könnte, beginnt die Wiederherstellung hinter diesem gesamten Bereich. Lässt sich die alte Quelle nicht als inaktiv belegen, bleibt ihr Sektor gesperrt. Eine nicht zurückgeholte Offline-Kopie ist ein fortbestehendes Überschneidungsrisiko.

Der Beleg ist kein kryptografischer Beweis. Er erklärt, warum die Organisation von einem ausschließlich besessenen, nie verwendeten Bereich ausgeht und welche Kapazität sie geopfert hat, um Unsicherheit sicher zu behandeln.

Quellen