Zusammenfassung

  • Ohne signierte Attribute signiert Pure SLH-DSA nach RFC 9814 den Inhalt; mit signierten Attributen signiert es DER(SignedAttributes), während message-digest den Inhalt einbindet.
  • Das HSM kann im zweiten Pfad eine kleine Eingabe erhalten. Dadurch werden Inhaltsleser, Hash-Dienst und DER-Konstruktor zu eigenständigen Kontrollstellen, deren Aussagen ein HSM-Beleg nicht ersetzt.
  • Der CMS-Hash ist nicht der Prehash-Modus von SLH-DSA. Falsche Benennung gefährdet Algorithmuskennungen, Rekonstruktion und langfristige Beweisfähigkeit.

Die Schlüsselgrenze ist nicht die Inhaltsgrenze

In vielen Sicherheitsmodellen endet die Diskussion am HSM: Der Schlüssel kann nicht exportiert werden, Rollen sind getrennt, jede Operation wird protokolliert. Für RFC 9814 reicht das nicht. Ein erfolgreiches Signaturprotokoll kann nur belegen, dass das Modul eine bestimmte kleine Bytefolge verarbeitet hat. Ob diese Bytefolge den freigegebenen Geschäftsinhalt korrekt repräsentiert, entscheidet sich möglicherweise vollständig außerhalb des Moduls.

RFC 9814 wurde im Juli 2025 als Standards-Track-Dokument veröffentlicht. Es profiliert Pure SLH-DSA mit leerem Kontext für CMS SignedData. Die Anwesenheit von SignerInfo.signedAttrs entscheidet, welche Nachricht die Pure-Operation erhält.

Pfad ohne signierte Attribute

Fehlen signedAttrs, ist der Inhalt selbst die zu signierende Nachricht. Das Feld digestAlgorithm in SignerInfo weist Pure SLH-DSA nicht an, den Inhalt vorher durch einen externen Hash zu ersetzen. Der RFC stellt fest, dass dieses Feld in diesem Pfad für die Signaturberechnung ohne Bedeutung ist.

Ein Remote-Signer, der ausschließlich Digests annimmt, kann diesen Pfad deshalb nicht durch eine bloße Beschriftung nachbilden. Wird Hash(Inhalt) als Nachricht übergeben, ist die Operation verändert. Auch ein SHA-256-Identifier in CMS beweist nicht, dass HashSLH-DSA ausgeführt wurde.

Bei großen Objekten muss die Architektur die tatsächliche Nachricht zur Pure-Implementierung bringen. Auf Verifikationsseite genügt ein während des Streams gespeicherter CMS-Digest nicht automatisch, um später die Pure-Signatur dieses Pfades zu prüfen. Inhaltsspeicherung, erneuter Abruf oder eine passende Streaming-Schnittstelle müssen geplant werden.

Pfad mit signierten Attributen

Sind signedAttrs vorhanden, wird der Inhalt mit dem angegebenen Digest-Algorithmus gehasht. Das Ergebnis steht im obligatorischen Attribut message-digest. Das ebenfalls obligatorische content-type benennt den CMS-Inhaltstyp. Die vollständige Attributmenge wird nach DER codiert; diese Bytes sind die Nachricht für Pure SLH-DSA.

Damit entstehen getrennte Beweisschritte:

  • Ein unveränderlicher Objektbezeichner verweist auf genau die gelesenen Bytes.
  • Hash-Algorithmus, Bytezahl und Digest beschreiben die vollständige Verarbeitung.
  • content-type stimmt mit dem eingebetteten oder externen CMS-Typ überein.
  • Alle Attribute erzeugen genau eine dokumentierte DER-Bytefolge.
  • Signaturalgorithmus, öffentlicher Schlüssel und Signatur sind konsistent.
  • Zertifikatspfad und Richtlinie erlauben die konkrete Verwendung.

Das HSM besitzt regelmäßig nur den vorletzten Schritt. Der Hash-Dienst besitzt die Behauptung, dass der Digest aus dem richtigen Inhalt stammt. Der Attribut-Builder besitzt die Behauptung, dass Digest, Typ und weitere Aussagen gemeinsam autorisiert wurden. Wer diese Komponenten als belanglose Vorverarbeitung behandelt, verschiebt Verantwortung ohne Kontrolle.

Der Verifikator muss den Digest über den tatsächlich erhaltenen Inhalt neu berechnen. Er muss außerdem das signierte content-type gegen encapContentInfo.eContentType prüfen. Der Typ kann Parser, Aufbewahrung, Automatisierung und Berechtigungen steuern; gleiche Bytes unter einer anderen Semantik sind nicht dieselbe Entscheidung.

DER ist Teil des genehmigten Sachverhalts

Attribute sind logisch strukturiert, Signaturen gelten aber für Bytes. DER fixiert Tags, Längen, Werttypen und die kanonische Ordnung einer Menge. Eine Audit-Tabelle mit lesbaren Namen kann unbekannte Attribute, exakte Typen oder Codierungsdetails verlieren.

Mindestens das ursprüngliche CMS-Objekt muss erhalten bleiben. Für hochwertige Nachweise sollten auch die exakt an den Signer übergebenen DER-Bytes, ein Audit-Hash, die Builder-Version und das Ergebnis einer unabhängigen Rekonstruktion gespeichert werden. Kann nur eine proprietäre Bibliothek diese Bytes erklären, besteht Lock-in auf Beweisebene.

Ein HSM mit hoher Zertifizierungsstufe behebt keinen Adapter, der das falsche Objekt liest, den Typ aus einem veränderlichen HTTP-Header übernimmt oder Attribute nach der Benutzerfreigabe neu aufbaut. Nachrichtenerstellung und Schlüsselverwendung sind zwei Kontrollflächen.

Die Algorithmusangaben müssen zusammenpassen

Bei signierten Attributen bezeichnet SignerInfo.digestAlgorithm den Hash für message-digest; SignedData.digestAlgorithms repräsentiert die von den Signern verwendeten Algorithmen. RFC 9814 verlangt eine Digest-Ausgabe, deren Kollisionssicherheit zum gewählten SLH-DSA-Parametersatz passt. Eine generische Positivliste ohne Kombinationsprüfung ist unzureichend.

Der RFC definiert zwölf Signaturalgorithmus-Kennungen für Pure SLH-DSA; Parameter müssen fehlen. Der Verifikator prüft die Konsistenz mit dem Public-Key-Algorithmus. RFC 9909 liefert den verwandten X.509-Rahmen. Ein gültiger Zertifikatspfad beweist jedoch nicht, dass der externe Hasher das richtige Objekt gelesen hat.

Das signierte Attribut CMSAlgorithmProtection aus RFC 6211 sollte enthalten sein. Es nimmt Digest- und Signaturkennungen in den geschützten Attributsatz auf und erschwert ihre Substitution in äußeren Feldern. Weil SHOULD Ausnahmen zulässt, muss eine Organisation das Fehlen ausdrücklich behandeln: ablehnen, isolieren oder zeitlich begrenzt akzeptieren und messen.

CMS-Attribute sind kein HashSLH-DSA

Architektonisch ähnelt der zweite Pfad einer Prehash-API: Ein großes Objekt wird extern reduziert, das HSM sieht wenig. Kryptografisch signiert Pure SLH-DSA aber nicht nur den Inhaltsdigest. Es signiert DER mit Digest, Typ und weiteren Attributen. FIPS 205 definiert Pure und Prehash als unterschiedliche Varianten; HashSLH-DSA besitzt eigene Identität.

Ein Inventar sollte deshalb „Pure SLH-DSA über SignedAttributes; Inhalt per message-digest gebunden“ schreiben. Die Kurzform „SLH-DSA prehash“ kann einen falschen OID, eine falsche Verifikationseingabe und ein unvollständiges Auditarchiv verursachen.

Streaming macht den Hasher zum Systembestandteil

Der Attributpfad erlaubt, große Inhalte während des Empfangs zu hashen und Blöcke freizugeben. Das HSM muss nicht mit Gigabytes belastet werden. Der RFC macht jedoch keine Aussage über konkrete Produktleistung. Ob ein System schneller wird, hängt von Bibliothek, Modul, I/O und Pipeline ab.

Unabhängig von der Geschwindigkeit muss der externe Hasher geprüft werden. Unterbrechen und starten Sie Streams neu. Tauschen Sie Versionen unter demselben Objektnamen. Variieren Sie Chunk-Grenzen, Länge und Typquelle. Das System muss zeigen, ob es bei null beginnt, einen authentisierten Zustand fortsetzt oder einen inkonsistenten Lauf verwirft.

Ein Transaktionsbeleg umfasst unveränderliche Inhalts-ID und Version, Länge, Hash-Algorithmus und Digest, CMS-Typ, sämtliche Attribute, exaktes DER, Parametersatz, Schlüssel- und Zertifikats-ID, Signatur, Richtlinienversion, Zeitpunkt und getrennte Ergebnisse jedes Prüfschritts.

In Akzeptanztests sollte jeweils nur Inhalt, Digest, Typ, ein Attribut, DER, eine Algorithmuskennung, Schlüssel oder Zertifikat verändert werden. Jeder Fehler braucht eine stabile Stufenbezeichnung. „Signatur ungültig“ allein erlaubt keine Verantwortungszuordnung.

RFC 9814 verspricht keine Marktdurchdringung, HSM-Leistung oder quantensichere Gesamtlösung. Verschlüsselung, Zertifikatskette, Zufall, Seitenkanäle, Fehlerresistenz und Schlüsselverwahrung bleiben eigene Themen. Auch die Grenze von weniger als 2^64 Signaturen pro SLH-DSA-Schlüssel braucht Zählung und Rotation.

Heng Lus Gedanke einer minimalen Anfangsspezifikation verlangt hier einen kleinen, testbaren Vertrag zwischen Beteiligten. Die Realitätsschicht ist nicht das Produktetikett, sondern die reproduzierbare Abbildung von Inhaltsbytes zu Digest, von Attributen zu DER und von DER zu Signatur und Richtlinienurteil.

Quellen