Zusammenfassung

  • Ohne signierte Attribute verarbeitet reines ML-DSA die Inhaltsoktette direkt. digestAlgorithm muss SHA-512 nennen, wird bei der Prüfung aber inhaltlich ignoriert.
  • Mit signierten Attributen ist der Inhalts-Digest Teil der geschützten Daten, muss neu berechnet und verglichen werden und kann die Sicherheit der Gesamtkonstruktion begrenzen.
  • Ein belastbarer Nachweis trennt CMS-Zweig, exakte Signaturbytes, Parameter-OID, Digest-Vergleich, Algorithmusschutz, Schlüssel- und μ-Grenzen, Berechtigung und Folgewirkung.

In einem Prüfbericht können die Angaben SHA-512, ML-DSA-65 und „Signatur gültig“ nebeneinanderstehen und sämtlich stimmen. Sie belegen dennoch weder, dass SHA-512 den Inhalt für ML-DSA gehasht hat, noch dass der private Schlüssel im HSM verblieb oder der identifizierte Unterzeichner die nachfolgende Entscheidung treffen durfte.

RFC 9882 wurde im Oktober 2025 als Proposed Standard der IETF veröffentlicht. Das Dokument beschreibt den Einsatz der in FIPS 204 definierten Parametersätze ML-DSA-44, ML-DSA-65 und ML-DSA-87 in der Cryptographic Message Syntax. Jeder Satz besitzt eine eigene Signaturalgorithmus-OID; Parameter im jeweiligen AlgorithmIdentifier müssen fehlen. Spezifiziert wird reines ML-DSA, nicht HashML-DSA in CMS. Die frühere Bezeichnung Dilithium bedeutet keine Formatkompatibilität.

Für die Auslegung ist zuerst festzustellen, ob signedAttrs vorhanden ist.

Fehlen signierte Attribute, erhält ML-DSA die Oktette des Werts des OCTET STRING in encapContentInfo eContent; Tag und Längenoktette gehören nicht dazu. Reines ML-DSA verarbeitet die Nachricht direkt. SignerInfo.digestAlgorithm hat deshalb in diesem Zweig keine Bedeutung für die Signaturberechnung.

Der Absender muss dort trotzdem SHA-512 eintragen, damit Implementierungen möglichst zuverlässig zusammenarbeiten. Der Empfänger muss den Inhalt des Felds zugleich ignorieren. SHA-512 belegt hier also die Einhaltung einer Kompatibilitätskonvention, nicht einen vorgelagerten Hash-Schritt. Ein Parser kann das Feld korrekt erfassen, während die nachgelagerte Auswertung ihm fälschlich eine kausale Rolle zuschreibt.

Mit signierten Attributen ändert sich das Signaturobjekt. Eingabe ist die vollständige DER-Codierung des SignedAttrs-Werts einschließlich Tag und Länge, und zwar mit dem EXPLICIT-SET-OF-Tag statt des IMPLICIT-[0]-Tags in der fertigen Nachricht. Mindestens content-type und message-digest müssen enthalten sein. Der Empfänger berechnet den Inhalts-Digest neu und vergleicht ihn mit dem geschützten Attribut. Auf diesem Pfad ist die Digest-Wahl tatsächlich wirksam; ein schwaches Verfahren kann die Gesamtsicherheit deckeln. SHA-512 muss unterstützt werden, SHAKE256 soll unterstützt werden, wobei dessen Parameter ebenfalls fehlen müssen.

Der kleine syntaktische Unterschied erzeugt zwei grundverschiedene Evidenzlagen. Ohne Angabe des verarbeiteten Zweigs lässt sich weder erklären, was digestAlgorithm bedeutete, noch welche Bytes unter ML-DSA standen oder ob der Inhaltsvergleich erfolgte. Das grüne Ergebnis „gültig“ bewahrt seine Voraussetzungen nicht von selbst.

Auch die Algorithmusidentität verlangt einen eigenen Prüfschritt. Die OID muss zum verwendeten ML-DSA-Parametersatz passen, verbotene Parameter sind zurückzuweisen. Das in RFC 6211 definierte CMSAlgorithmProtection nimmt relevante Algorithmuskennungen in ein signiertes Attribut auf. RFC 9882 empfiehlt es als Schutz gegen Algorithmussubstitution. Vorhandensein und Konsistenz sind eigenständige Befunde, keine Nebenwirkung einer korrekten mathematischen Signatur.

Die Schlüsselverwahrung bleibt eine weitere Ebene. Wird ein privater ML-DSA-Schlüssel kompromittiert, sind Fälschungen möglich. FIPS 204 sieht standardmäßig eine gehärtete Erzeugung vor, die frische Zufälligkeit mit vorab im Schlüssel abgelegten Zufallsdaten kombiniert, erlaubt jedoch auch deterministisches Signieren. RFC 9882 rät davon auf Plattformen ab, bei denen Seitenkanal- oder Fehlerangriffe relevant sind. Das CMS-Objekt allein verrät die tatsächlich gewählte Betriebsart nicht.

Ein Hardwaremodul beseitigt die Evidenzgrenze ebenfalls nicht. Bei signierten Attributen kann lediglich deren kleine DER-Struktur statt des gesamten Inhalts an das HSM gehen. Außerdem kann ein anderes Kryptomodul den Nachrichtenrepräsentanten μ berechnen und dem Signierer liefern. „Im HSM signiert“ beweist daher weder, dass das Gerät den Originalinhalt sah, noch dass es μ selbst berechnete. Schnittstelle und Bindung an die aufbewahrten Bytes müssen dokumentiert werden.

Ein belastbarer Vorgang bewahrt zunächst das exakte CMS-Objekt, erfasst die Attributverzweigung und rekonstruiert die Signaturbytes. Danach folgen OID- und Parameterprüfung, gegebenenfalls Neuberechnung und Vergleich des Inhalts-Digests, Algorithmusschutz und kryptografische Verifikation. Erst anschließend werden Zufallsmodus, μ-Herkunft, Zertifikatspfad, Identität, Anwendungsberechtigung und ausgelöste Wirkung als getrennte Feststellungen bewertet.

Quellen