Code Signing auf ML-DSA migrieren: ein praxisnaher Plan

Code Signing folgt einem anderen Zeitplan als TLS. Aufgezeichneter Datenverkehr ist nur durch den Schlüsselaustausch geschützt, deshalb steht dort hybrides ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) an erster Stelle. Eine Signatur muss nur so lange fälschungssicher sein, wie ihr Vertrauensanker gültig ist. Der Verifier, der sie prüft, kann jedoch ein Jahrzehnt lang in einem Bootloader stecken, und Sie können einen Verifier nicht mit einem Update patchen, das dieser Verifier nicht prüfen kann. Diese Vorlaufzeit, nicht die Dringlichkeit der Bedrohung, ist der Grund, warum die offiziellen Zeitpläne Software- und Firmware-Signaturen früh ansetzen: NSA CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) verlangt für US National Security Systems bis Ende 2030 die ausschließliche Verwendung von ML-DSA-87 oder LMS/XMSS für Software- und Firmware-Signaturen, drei Jahre vor Browsern, Servern, Cloud-Diensten und Betriebssystemen.

Warum Fristen für Signaturen vor denen für den Schlüsselaustausch liegen

Harvest now, decrypt later gilt nicht für Signaturen. Niemand kann heute eine Signatur aufzeichnen und daraus später eine neue fälschen. Das Risiko ist ein anderes: Ein Angreifer mit Quantenfähigkeiten, der einen privaten Signaturschlüssel aus dem zugehörigen öffentlichen Schlüssel ableiten kann, könnte Firmware signieren, der Ihre installierte Basis weiterhin vertraut. Die Gegenmaßnahme besteht darin, einen Post-Quanten-Verifier in diese installierte Basis zu bringen, lange bevor der Schlüssel fälschbar wird, und installierte Basen bewegen sich langsam.

Drei Eigenschaften machen Signaturen zum längsten Pfad. Erstens sind Verifier überall und oft unveränderlich: ROM-Bootstufen, Secure Elements, vom Netz getrennte Provisionierungswerkzeuge, Appliances bei Kunden, Offline-Installer. Zweitens sind Vertrauensanker eingebettet, ein Algorithmuswechsel bedeutet also, neue öffentliche Schlüssel über einen Kanal zu verteilen, der selbst signiert ist. Drittens muss das letzte Update, das ein Gerät unter dem alten Algorithmus akzeptiert, ihm den neuen beibringen. Ein Gerät, das vor diesem Zeitpunkt aus Ihrer Update-Pipeline ausscheidet, bleibt für immer klassisch. Planen Sie diese End-of-Life-Entscheidung ausdrücklich, statt sie im Jahr 2030 zu entdecken.

Nichts davon setzt eine Prognose voraus, wann ein kryptographisch relevanter Quantencomputer existiert. Die unten aufgeführten Daten stammen aus veröffentlichten Vorgaben und Leitlinien, und an ihnen muss sich Ihre Roadmap für das Release Engineering ausrichten.

ML-DSA, SLH-DSA, LMS und XMSS: Auswahl nach Anwendungsfall

NIST hat FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Algorithm) und FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Algorithm) am 13.08.2024 als finale Standards veröffentlicht (FIPS 204, FIPS 205). Die zustandsbehafteten hashbasierten Verfahren LMS und XMSS sind unter NIST SP 800-208 zugelassen. CNSA 2.0 nennt ML-DSA-87 und LMS/XMSS für Software- und Firmware-Signaturen, mit SHA-384 oder SHA-512 als Hashfunktion.

Für die meisten Release-Pipelines ist ML-DSA die Standardwahl, weil es zustandslos und daher sicher in einem verteilten CI-System mit mehreren Signierenden einsetzbar ist. Zustandsbehaftete Verfahren sind für ressourcenbeschränkte Bootloader attraktiv, doch die betriebliche Regel ist unnachgiebig: Der Zustand des Signierers darf niemals dupliziert werden. Das schließt gewöhnliche VM-Snapshots, Warm-Standby-Klone und die Wiederherstellung eines Signaturhosts aus einem Backup aus. Wenn Sie dies in Ihrer Umgebung nicht garantieren können, wählen Sie ein zustandsloses Verfahren.

Die Größe spielt eine Rolle, wie es bei ECDSA nicht der Fall war. Öffentliche Schlüssel und Signaturen im Post-Quanten-Bereich sind deutlich größer, SLH-DSA-Signaturen nochmals größer. Lesen Sie die Parametertabellen in FIPS 204 und FIPS 205, bevor Sie ein Signaturfeld in einem Firmware-Header, eine Flash-Partition, ein Manifest-Schema oder ein Budget für Over-the-Air-Updates dimensionieren. Ein Signaturfeld fester Breite in einem bestehenden Image-Format ist ein häufiges Hindernis, und es handelt sich um eine Formatänderung, nicht um eine kryptographische Änderung.

Verifier zuerst: die Update-Reihenfolge, die sich nicht umstellen lässt

Die folgende Abfolge ist der gesamte Plan. Die Schritte 2 und 3 müssen in der gesamten Flotte abgeschlossen sein, bevor Schritt 5 beginnt.

1. Inventarisieren Sie Verifier, nicht nur Signierende. Listen Sie jede Stelle auf, an der eine Signatur geprüft wird: Bootloader, Secure Elements, Paketmanager, Installer-Frameworks, Update-Agenten, Admission Controller, Provisionierungswerkzeuge, Validierungsskripte von Partnern. Halten Sie fest, welche Sie über welchen Kanal aktualisieren können und welche eingefroren sind.
2. Ergänzen Sie die Post-Quanten-Prüfung, während der klassische Algorithmus weiterhin akzeptiert wird. Der neue Verifier muss tolerant sein: alte Signaturen akzeptieren, neue akzeptieren und protokollieren, welche er gesehen hat.
3. Liefern Sie diesen Verifier über den bestehenden, klassisch signierten Pfad aus und verteilen Sie anschließend die neuen Vertrauensanker. Messen Sie die Abdeckung mit realer Telemetrie, nach Gerät und nach Version, nicht anhand von Annahmen.
4. Registrieren Sie Signaturschlüssel in Hardware und betreiben Sie eine parallele, nicht produktive Signatur-Pipeline durchgängig, einschließlich Widerruf und Zeitstempelung.
5. Beginnen Sie mit der Doppelsignatur von Produktionsartefakten, sobald der tolerante Verifier die überwältigende Mehrheit stellt.
6. Verlangen Sie Post-Quanten-Signaturen erst, wenn die Telemetrie zeigt, dass die alten Verifier verschwunden sind, mit einer schriftlichen Entscheidung für die Nachzügler: erweiterter Support, Austausch im Feld oder dokumentiertes End of Life.
7. Entfernen Sie die klassische Signatur zuletzt und behalten Sie die Möglichkeit, archivierte Artefakte neu zu signieren, damit alte Releases unter dem neuen Verfahren prüfbar bleiben.

Doppelsignatur: die zwei Modi und die Falle

Doppelsignatur bedeutet, demselben Artefakt zwei unabhängige Signaturen beizufügen (eine klassische, eine Post-Quanten-Signatur), meist in einem Containerformat, das mehrere Signaturplätze unterstützt. Prüfen Sie, ob Ihres das tut, bevor Sie irgendetwas anderes entwerfen: Manche Formate erlauben mehrere Signierende nativ, andere erfordern eine separate, abgetrennte Signatur oder eine Formatrevision.

Die entscheidende Designfrage ist die Prüfrichtlinie. Im permissiven Modus akzeptiert ein Verifier das Artefakt, wenn eine der beiden Signaturen gültig ist. Das hält alte Clients funktionsfähig, bedeutet aber, dass Ihre effektive Sicherheit der des schwächeren der beiden Algorithmen entspricht. Im strikten Modus verlangt der Verifier beide Signaturen. Das erhöht die Sicherheit, schafft aber ein Verfügbarkeitsrisiko: Ein einziger Fehler in einer der beiden Pipelines blockiert jedes Release. Der übliche Weg ist permissiv während des Rollouts, strikt, sobald die Flotte bereit ist, und danach ausschließlich Post-Quanten. Halten Sie die Richtlinie je Verifier-Klasse und je Artefakttyp schriftlich fest und legen Sie die Übergangsdaten ausdrücklich fest. Genau diese Art geplanter Algorithmuswechsel soll Krypto-Agilität zur Routine machen.

Unterstützung durch HSM, PKI und Toolchain: prüfen, nicht annehmen

Die Unterstützung für Post-Quanten-Signaturen entwickelt sich bei Hardware-Sicherheitsmodulen, Zertifizierungsstellen und Signaturwerkzeugen schnell, und die Versionsanforderungen unterscheiden sich zwischen Produkten und sogar zwischen Firmware-Zweigen desselben Produkts. Betrachten Sie einen Blogbeitrag eines Herstellers nicht als Zusage. Fordern Sie die Release Notes und den Validierungsnachweis an und testen Sie in einer Staging-Umgebung. Die folgenden Punkte sind die Fragen, die Sie schriftlich stellen sollten:

• Implementiert die HSM-Firmware ML-DSA, mit welchen Parametersätzen, und gibt es eine nach FIPS 140-3 validierte Version oder eine datierte Roadmap dorthin? Wenn CNSA 2.0 für Sie gilt, ist ML-DSA-87 der maßgebliche Parametersatz.
• Ist die Funktion über die Schnittstelle erreichbar, die Ihre Pipeline nutzt (PKCS#11-Mechanismus, KMIP-Objekttypen, Cloud-KMS-API, Hersteller-SDK), und können Schlüssel in Hardware erzeugt und niemals exportiert werden?
• Für LMS oder XMSS: Erfolgen Schlüsselerzeugung und Zustandsfortschreibung innerhalb des kryptographischen Moduls, ohne einen Mechanismus, der den Zustand duplizieren könnte, wie SP 800-208 es verlangt?
• Kann Ihre Zertifizierungsstelle Zertifikate mit Post-Quanten-Subject-Keys ausstellen, und kann sie Widerrufsdaten signieren, die Ihre Verifier akzeptieren? Hierarchien benötigen unter Umständen eine parallele Post-Quanten-Kette statt einer Änderung an Ort und Stelle.
• Unterstützt Ihr Zeitstempeldienst den neuen Algorithmus, sodass Signaturen nach Ablauf des Zertifikats prüfbar bleiben?
• Unterstützen Ihre Werkzeuge für Artefaktsignatur und Transparenz, Ihre Paket-Build-Systeme und Ihre Prüfbibliotheken den Algorithmus in genau den Versionen, die Sie einsetzen? OpenSSL beispielsweise erfordert für die ML-KEM-TLS-Gruppen Version 3.5 oder neuer. Prüfen Sie für die Signaturunterstützung die Release Notes der konkreten Version, die Sie ausliefern, sowohl in der Signatur- als auch in der Prüfumgebung.
• Durchsatz und Latenz: Größere Signaturen und neue Codepfade verändern die Signaturdauer pro Artefakt und die Downloadgröße. Führen Sie Benchmarks mit Ihrem realen Release-Volumen durch.

Die Daten für Ihre Planung

Die folgenden Angaben dienen der Information und stellen keine Rechtsberatung dar. Der Status ist ebenso wichtig wie das Datum: Ein Entwurf ist kein Standard, und Leitlinien für Mitgliedstaaten sind keine Verpflichtung für Unternehmen.

Primärquellen: OMB M-26-15, die EU Coordinated Implementation Roadmap, die PQC-FAQ der ANSSI, die Migrationszeitpläne des UK NCSC und NIST IR 8547 ipd. Für CNSA 2.0 sind die veröffentlichten Quellen die CNSA 2.0 FAQ v2.1 (Dezember 2024) und das CNSA 2.0 Algorithms Advisory (30.05.2025).

Hersteller sollten außerdem beachten, dass der Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e), den Schutz der Vertraulichkeit durch Mechanismen nach dem Stand der Technik verlangt und keine Post-Quanten-Algorithmen nennt. Seine Meldepflichten gelten ab dem 11.09.2026, vollständig anwendbar ist er ab dem 11.12.2027 (EUR-Lex). Behandeln Sie sichere Updates und Signaturprüfung als Teil dieser Argumentation zum Stand der Technik, und führen Sie das Inventar der Signaturschlüssel im selben Register wie den Rest Ihrer Kryptographie.

Beginnen Sie mit dem, was Sie heute messen können

Die Migration der Signaturen ist ein mehrjähriges Flottenprogramm. Beginnen Sie daher mit den zwei kostengünstigen Schritten: einer Liste aller Verifier in Ihrer Verantwortung mit ihrem jeweiligen Update-Kanal und einer Staging-Signatur-Pipeline, die durchgängig ein doppelt signiertes Artefakt erzeugt. Bestätigen Sie parallel, dass die Transportseite bereits hybriden Schlüsselaustausch nutzt, denn dort steht aufgezeichneter Datenverkehr auf dem Spiel, und die Abhilfe ist eine Konfigurationsänderung statt eines Flotten-Rollouts. Sie können Ihre Domain mit PQC Status scannen, um zu sehen, ob Ihre Release-, Update- und Artefakt-Hosts X25519MLKEM768 aushandeln, welche TLS-Versionen und Cipher Suites sie anbieten und wie ihre Zertifikatskette aussieht. Der Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist keine Zertifizierung und untersucht Ihre Code-Signing-Pipeline nicht. Kombinieren Sie ihn daher mit dem oben beschriebenen Verifier-Inventar.