Zusammenfassung

  • RFC 9708 legt fest, wie HSS/LMS-Schlüssel und -Signaturen in X.509, PKIX und CMS verwendet werden. Ein privater LM-OTS-Schlüssel darf genau einmal signieren; der Signierer muss daher dauerhaft wissen, welche Blätter bereits verbraucht sind.
  • Die erfolgreiche Prüfung einer einzelnen Signatur beweist keine ungeteilte Zustandsgeschichte. Ein fehlgeschlagener persistenter Schreibvorgang, die Wiederherstellung eines VM-Snapshots oder ein Klon kann ein Blatt erneut anbieten, dessen Signatur längst ausgeliefert wurde.
  • Entscheidend ist die Reihenfolge: den Folgezustand verbindlich speichern, bevor die Signatur die Sicherheitsgrenze verlässt, nur einen wirksamen Schreiber zulassen und jede Ausgabe einem unumkehrbaren Verbrauch zuordnen.

Die wiederhergestellte Maschine wirkt gesund. Ihre Schnittstelle antwortet, das Zertifikat passt, jede neue Signatur lässt sich prüfen. Trotzdem kann sie mit einem kryptografischen Gedächtnis aus der Vergangenheit arbeiten. Signaturen, die nach dem Snapshot ausgegeben wurden, sind außerhalb der Maschine weiterhin vorhanden; nur der wiederhergestellte Signierer hat sie vergessen.

Genau dort liegt die operative Aussage von RFC 9708. Das im Januar 2025 auf dem Standards Track veröffentlichte Dokument aktualisiert die Einbindung des Hierarchical Signature System und des Leighton–Micali Signature Scheme in Zertifikate und Cryptographic Message Syntax. Es ersetzt RFC 8708, richtet Kodierungsdetails an der Zertifikatspraxis aus, erledigt dokumentierte Errata und ergänzt Parametersätze. Die Interoperabilität wird besser, der zustandsbehaftete Charakter bleibt.

Die Grundlage beschreibt RFC 8554. Zum privaten Schlüsselzustand gehört der Index der nächsten Einmalsignatur. Der Signaturvorgang liefert eine Signatur und einen privaten Folgezustand. Ist die feste Zahl von Blättern erschöpft, existiert kein Folgezustand mehr. Wird derselbe geheime Zustand zweimal benutzt, bestehen keine kryptografischen Sicherheitsgarantien; eine Fälschung kann möglich werden.

Geschützt werden muss folglich nicht nur geheimes Material. Geschützt werden muss die Einheit aus Geheimnis und wahrer Verbrauchsgeschichte.

Der Prüfer sieht ein Objekt, nicht alle Kopien des Signierers

LM-OTS ordnet jedem privaten Schlüssel eine Signatur zu. LMS fasst viele solche Schlüssel unter einer Merkle-Wurzel zusammen, HSS kann mehrere Bäume hierarchisch verbinden. So entsteht ein nützliches, aber endliches Signaturbudget. Die einzelne Signatur nennt eine Blattposition und enthält den Nachweispfad zur öffentlichen Wurzel.

Aus diesem Objekt geht nicht hervor, ob ein anderer Rechner dieselbe Position benutzt hat. Prüfung ist eine lokale Aussage über vorliegende Bytes. Zustands-Eindeutigkeit ist eine globale Aussage über Instanzen, Backups, Klone, Schreiber und Umschaltwege. Die Belege bleiben getrennt:

Beleg Begrenzte Aussage
öffentlicher Schlüssel angenommen eine Richtlinie akzeptiert diesen HSS/LMS-Schlüssel
Algorithmuskennung verstanden Kodierung und Parametersatz sind bekannt
Signatur geprüft das Objekt erfüllt das Prüfverfahren
Blattindex gesehen eine bestimmte Baumposition ist genannt
Zustand reserviert ein Schreiber hat diese Position zugeteilt
Folgezustand persistiert nichtflüchtiger Speicher bietet sie nicht wieder an
Signatur exportiert das Ergebnis hat die Sicherheitsgrenze überschritten
Geschichte abgeglichen keine weitere Ausgabe nutzt dieselbe Position
Wirkung beobachtet ein Empfänger handelte auf Grundlage des Inhalts

Die dritte Zeile ersetzt nicht die achte. RFC 9708 verlangt die Nachverfolgung verbrauchter Blätter und warnt, dass ein Integritätsverlust dieser Aufzeichnung zur Wiederverwendung führen kann. Das Dokument nennt fehlgeschlagene persistente Schreibvorgänge, VM-Snapshots und Klone. Gewöhnliche Infrastruktur kann also eine ungewöhnlich strenge kryptografische Zeitordnung verletzen.

Erst den Zustand festschreiben, dann die Signatur freigeben

Berechnet ein Dienst die Signatur, sendet sie an den Auftraggeber und speichert erst danach den erhöhten Index, reicht ein Ausfall zwischen Antwort und Speicherung. Die Außenwelt besitzt die Signatur, während der Neustart dasselbe Blatt wieder auswählt. Auch eine bestätigte Schreiboperation ist kein hinreichender Beleg, wenn Daten noch in einem flüchtigen Cache liegen.

NIST SP 800-208 behandelt diese Zustandsführung als zentrale Schwierigkeit zustandsbehafteter Hashsignaturen. In seinem Profil muss ein konformes Modul die Blattkennung erhöhen und diese Erhöhung nichtflüchtig speichern, bevor es die Signatur exportiert oder einen weiteren Auftrag annimmt. Die sichere Sequenz lautet: Position reservieren, Verbrauch dauerhaft festhalten, Signatur kontrolliert fertigstellen, Ergebnis mit Reservierungsbeleg ausgeben und unklare Ausgänge abgleichen, ohne die Position wieder freizugeben.

Ein Ausfall nach dem Speichern und vor dem Export kann ein Blatt ungenutzt kosten. Das ist verlorene Kapazität, aber kein gebrochenes Einmalversprechen. Die umgekehrte Reihenfolge spart ein Blatt und riskiert Wiederverwendung. Bei Ungewissheit ist eine Lücke im Zähler sicherer als zwei öffentliche Signaturen mit demselben Einmalgeheimnis.

Damit ändern bekannte Betriebswörter ihre Bedeutung. Wiederholung ist nicht zwingend idempotent. Wiederherstellung ist nicht zwingend sicher. Klonen ist nicht bloß horizontales Skalieren. Der Zustand eines aktiven HSS/LMS-Schlüssels darf nur vorwärts laufen.

Hochverfügbarkeit kann die Signaturgewalt verdoppeln

Zwei aktive Instanzen mit demselben privaten Zustand können jeweils gültige Signaturen erzeugen und dennoch überlappende Blätter vergeben. Eine gemeinsame Datenbank hilft nicht, wenn eine Instanz vor dem dauerhaften Commit ausgeben darf. Auch Hardwaremodule lösen das Problem nicht, wenn identischer Zustand ohne disjunkte Teilbäume in mehrere Module gelangt.

Ein einziges maßgebliches Modul kann alle Verbräuche serialisieren. Alternativ lassen sich nicht überlappende Teilbäume vergeben, monotone Hardwarezähler einsetzen oder der alte Schreiber vor dem Failover einzäunen. Die jeweilige Eigenschaft muss konkret belegt werden. „Hardwaregestützt“ beweist keinen exklusiven Zustand; „hochverfügbar“ beweist keinen einzigen Schreiber.

Das NIST-Profil ist strenger als die allgemeine IETF-Darstellung. Es beschränkt zugelassene Parametersätze, verlangt Schlüssel- und Signaturerzeugung in Hardware-Kryptomodulen und untersagt den Export des geheimen Schlüssels. Das gilt für Systeme, die Konformität mit diesem Profil beanspruchen, nicht automatisch für jede RFC-9708-Implementierung. Ein Standard dokumentiert Regeln; nur Laufzeitbelege dokumentieren einen konkreten Wiederanlauf.

Zertifikate tragen den öffentlichen Schlüssel, nicht das private Gedächtnis

RFC 9708 definiert die Objektkennung, verlangt fehlende Parameter in AlgorithmIdentifier und transportiert den HSS/LMS-Public-Key ohne zusätzliche ASN.1-Hülle. In X.509 muss keyUsage zur Signatur passen, nicht zu Verschlüsselung oder Schlüsselaustausch. Damit fügt sich die Darstellung in RFC 5280 und die ASN.1-Module aus RFC 5912 ein.

Im CMS nach RFC 5652 hängt der signierte Eingang von Signed Attributes ab. Ohne sie wird der Inhalt direkt signiert. Mit ihnen wird der Inhalt gehasht und die DER-Kodierung von SignedAttributes, einschließlich Inhaltstyp und Message Digest, signiert. Ökosysteme wie die Firmware-Verpackung aus RFC 4108 können HSS/LMS so in bekannten Containern einsetzen.

Diese Regeln legen Bytes und Prüfung fest. Ein Zertifikat bindet einen öffentlichen Schlüssel unter einer Ausstellerpolitik an ein Subjekt, zählt aber keine alten privaten Snapshots auf. Der CMS-Prüfer sieht geschützte Attribute, nicht den verlorenen Plattenschreibvorgang beim Signierer. Eine breitere Nutzung verteilt die Bedeutung des Schlüssels, nicht den Nachweis seiner Zustandskontinuität.

Endliche Kapazität gehört in die Steuerung

Parametersatz und Baumaufbau begrenzen die Signaturzahl. Der Betreiber braucht eine Prognose für Rate, Lebensdauer, Reserve und die Zeit zur Zertifizierung und Verteilung des Nachfolgers. Ein Verbrauchssprung kann Angriff, legitime Veröffentlichung oder Messfehler sein; in jedem Fall sinkt die Reserve. Ein alter Index schafft keine Kapazität, sondern fälscht das Verbrauchsbuch.

Das IANA-Register für LMS führt standardisierte Typcodes. Die RFC-Editor-Seite, die Fassungen als Text und XML, die IETF-Historie und das Errata-Verzeichnis belegen Status und Herkunft der Spezifikation. Sie belegen weder den Blattbestand eines Betreibers noch dessen Wiederherstellungsdisziplin.

Heng Lus Prüfung am laufenden Code lenkt den Blick auf den ausführbaren Übergang: War der Verbrauch dauerhaft, bevor das Ergebnis hinausging? Die minimale Ausgangsspezifikation stellt den gemeinsamen Interoperabilitätsboden bereit, ersetzt aber keine lokalen Entscheidungen über Isolation und Failover. Die Trennung der Realitätsebenen verhindert, dass Normstatus, Objektprüfung und sichere Betriebsgeschichte zu einem Symbol verschmelzen.

HSS/LMS beseitigt betriebliche Verantwortung nicht, sondern verlagert sie. Weniger Abhängigkeit von bestimmten, langfristig quantengefährdeten Annahmen wird mit einer strengeren Pflicht zum Erinnern bezahlt. Ein Schlüssel ist das Geheimnis und sein unumkehrbarer Lebenslauf.

Quellen