Die Software-Lieferkette basiert auf Vertrauen, und jede signierte Binärdatei beruht auf einer grundlegenden Annahme: dass die kryptografischen Algorithmen, die diese Signaturen schützen – insbesondere RSA und ECDSA –, von keinem Angreifer mit den verfügbaren Rechenressourcen geknackt werden können. Doch diese Annahme ist nicht mehr unbegrenzt sicher.
Die Entwicklung kryptografisch relevanter Quantencomputer (CRQCs) birgt ein systemisches Risiko für alle heute eingesetzten digitalen Signaturverfahren. Das NIST finalisierte seine ersten Post-Quanten-Kryptografiestandards im August 2024 und forderte Systemadministratoren ausdrücklich auf, die Integration unverzüglich zu beginnen. Regulierungsbehörden und Technologieführer agieren parallel: von der CNSA-2.0-Richtlinie der NSA, die die Einführung von ML-DSA für nationale Sicherheitssysteme vorschreibt, bis hin zum Ziel von Google und Cloudflare, bis 2029 ihre gesamte Infrastruktur vollständig auf Post-Quanten-Kryptografie (PQC) umzustellen.
Die Frage ist nicht mehr, ob Unternehmen ihre Codesignatur-Infrastruktur auf Post-Quanten-Algorithmen umstellen müssen. Vielmehr geht es darum, ob sie diese Umstellung abschließen, bevor eine CRQC die Verzögerung relevant macht.
Wir werden die PQC-Algorithmenlandschaft, die spezifischen Herausforderungen bei der Implementierung von Codesignaturen, die Architekturstrategien und den stufenweisen Migrationsplan erläutern, der Software-Lieferkettenteams einen klaren Weg ohne Betriebsunterbrechungen aufzeigt. Informationen zu Zeitstempelung, HSM-Bereitschaft und Langzeitverifizierungsmechanismen, die bestimmen, ob eine heute angewendete Signatur auch in zwanzig Jahren noch gültig ist, finden Sie in unserer Publikation „PQC für Codesignaturen: Schutz langlebiger Software und Firmware“.
Die PQC-Codesignierungsstrategie ist definiert als ein priorisierter, phasenweiser Plan für die Umstellung der Signaturinfrastruktur einer Software-Lieferkette auf quantenresistente Algorithmen, ML-DSA, SLH-DSA oder FN-DSA, die je nach Arbeitslast und nicht standardmäßig ausgewählt werden, während des Übergangs parallel zu klassischen Signaturen eingesetzt werden und so sequenziert sind, dass Änderungen am Vertrauensanker vor abhängigen Systemen und nicht danach erfolgen.
Wichtige Erkenntnisse
- FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) sind seit August 2024 endgültige NIST-Standards. FN-DSA (FIPS 206) ist noch ein erster öffentlicher Entwurf (Initial Public Draft), dessen endgültige Fassung für Ende 2026 oder Anfang 2027 erwartet wird; es handelt sich also noch nicht um einen veröffentlichten Standard.
- Die Wahl des Algorithmus ist workloadspezifisch: ML-DSA für CI/CD-Signaturen mit hohem Volumen, wo er in veröffentlichten Benchmarks im Allgemeinen konkurrenzfähig mit oder schneller als RSA ist, SLH-DSA für langlebige Vertrauensanker, wo sein konservatives, langsameres Profil akzeptabel ist, FN-DSA (sobald final) für eingeschränkte IoT-/eingebettete Geräte.
- Hybrid-Signatur (klassisch plus PQC, parallel angewendet) ist heute das gängige Verfahren, da die Unterstützung von PQC-Signaturen durch Verifizierer im gesamten Ökosystem noch uneinheitlich ist; es handelt sich um denselben Dual-Signatur-Ansatz, der speziell für CI/CD in unserem SLSA Level 3 Architekturteil detailliert beschrieben wird.
- Diese Seite dient der Priorisierung und der Festlegung der Architekturstrategie für die allgemeine Software-Lieferkette. Den spezifischen Übergangsplan für CNSA 2.0 und die fünfphasige Migration finden Sie hier: Gestaltung der CNSA 2.0-ÜbergangsstrategienZur Auswahl zwischen verschiedenen Hash-basierten Signaturverfahren siehe Vergleich von SLH-DSA, LMS und XMSS.
- Was man nicht inventarisieren kann, kann man nicht migrieren; 34 % der Unternehmen nennen mangelnde zentrale kryptografische Transparenz als Haupthindernis für die PQC-Bereitschaft.
Warum PQC-Codierung nicht warten kann
Die meisten Organisationen betrachten die Bedrohung durch Quantencomputer als ein zukünftiges Problem. Doch für Software-Lieferketten reduzieren algorithmische Verbesserungen den Qubit-Bedarf für das Knacken von RSA-2048. Im Jahr 2019 wurde der Bedarf für das Knacken von RSA-2048 auf etwa 20 Millionen Qubits geschätzt. Bis 2025 haben neuere Architekturen mit Quantum Low-Density Parity-Check (QLDPC)-Codes diese Schätzung auf etwa 100,000 Qubits gesenkt – eine Reduzierung um das Zwanzigfache, die allein durch algorithmische Innovationen und nicht durch Hardware-Wechsel in weniger als sechs Jahren erreicht wurde.
Anders als bei verschlüsselter Kommunikation, wo das Prinzip „Erfassen und später entschlüsseln“ für die Vertraulichkeit gilt, birgt signierte Software ein anderes Risiko: „ Vertrauen und später fälschen “. Ein signiertes Installationsprogramm, ein Firmware-Image, ein Software-Update-Paket: Diese Artefakte bleiben jahre- oder jahrzehntelang im Umlauf. Wenn eine CRQC (Certificate of Reverse Speculation Code) auftaucht und klassische Signaturalgorithmen geknackt werden, kann ein Angreifer nachträglich Signaturen auf bösartigen Artefakten fälschen, die von legitimer, historisch signierter Software nicht zu unterscheiden sind. Das Risikofenster beginnt nicht mit dem Eintreffen einer CRQC, sondern umfasst die gesamte Lebensdauer aller klassisch signierten Artefakte, die zu diesem Zeitpunkt noch im Einsatz sind.
Der Bericht des Citi Institute vom Januar 2026 mit dem Titel „Quantenbedrohung: Das Billionen-Dollar-Sicherheitsrennen hat begonnen“ schätzt die Wahrscheinlichkeit, dass ein Quantencomputer bis 2034 den RSA-2048-Verschlüsselungsalgorithmus knackt, auf 19 bis 34 %. Weltweit sind derzeit etwa 20 Milliarden aktive IoT-Geräte während ihrer gesamten Betriebsdauer dieser Quantenbedrohung ausgesetzt. Für Softwareteams, die Produkte mit mehrjähriger Nutzungsdauer betreuen, ist die Umstellung auf PQC-Codesignierung kein Wettbewerbsvorteil mehr. Sie ist vielmehr eine Maßnahme zur Risikominderung in der Lieferkette, die jetzt umgesetzt werden muss.
NIST PQC-Algorithmen für die Codesignierung
Das NIST finalisierte am 13. August 2024 seine ersten drei Post-Quanten-Kryptografiestandards, die ab sofort für die US-Bundesregierung gelten und als globaler Maßstab für die branchenweite Einführung dienen. Für digitale Signaturen, die die Grundlage der Codesignierung bilden, stehen drei Algorithmen zur Verfügung oder stehen kurz vor der Finalisierung.
Die Wahl des richtigen Algorithmus ist eine entscheidende Architekturfrage, die alles beeinflusst – von der Leistung der CI/CD-Pipeline bis zur Langlebigkeit des Root-of-Trust. Hier ein Vergleich der NIST-Signaturalgorithmen für Codesignierungsanwendungen:
| Algorithmus | Standard | Kernprinzip | Signaturgröße | Durchsatz | Am besten geeignet für |
|---|---|---|---|---|---|
| ML-DSA (KRISTALLE-Dilithium) | FIPS 204 (abgeschlossen) | Strukturiertes Gitter (Modul-LWE) | 2–3 KB | Im Allgemeinen konkurrenzfähig mit oder schneller als klassische Verfahren in veröffentlichten Benchmarks. | Allgemeine Paketsignierung, DevOps, CI/CD-Lieferkette |
| SLH-DSA (SPHINCS+) | FIPS 205 (abgeschlossen) | Zustandslose Hash-basierte (SHA-2/SHAKE) | 8–50 KB | Deutlich niedriger; erheblicher Gemeinkostenaufwand | Langfristige Archivierung, missionskritische Vertrauensanker |
| FN-DSA (FALCON) | FIPS 206 (Erster öffentlicher Entwurf; voraussichtliche endgültige Fassung Ende 2026 oder Anfang 2027) | Kompaktes Gitter (NTRU-basiert) | 0.6–1.2 KB | Schnell (optimiert für ressourcenbeschränkte Geräte) | IoT-Firmware, eingebettete Systeme, ressourcenbeschränkte Hardware |
Implementierungsherausforderungen
Die PQC-Codesignaturalgorithmen sind standardisiert und die Sicherheitsnachweise solide. Es handelt sich um eine operative und infrastrukturelle Herausforderung. Einige Punkte erfordern jedoch eine explizite Planung:
Inflation bei Unterschrift und Schlüsselgröße
Die unmittelbar sichtbarste Veränderung beim Übergang von klassischen zu PQC-Algorithmen ist die signifikante Vergrößerung der Schlüssel- und Signaturgrößen.
| Komponente | RSA-3072 (Klassisch) | ML-DSA-65 (PQC) |
|---|---|---|
| public Key | ~384 Byte | ~1,952 Byte |
| Private Key | ~384 Byte | ~4,032 Byte |
| Signature | ~384 Byte | ~3,309 Byte |
Vergleicht man eine rohe 64-Byte-P-256-ECDSA-Signatur, so ist eine ML-DSA-65-Signatur (3,309 Byte) etwa 52-mal größer. Dieses Verhältnis gilt speziell für die rohe 64-Byte-Darstellung; in der Praxis kodierte (DER) ECDSA-Signaturen sind üblicherweise etwas größer als 64 Byte. Daher sollte dieser Vergleich lediglich das Ausmaß der Vergrößerung verdeutlichen und nicht als allgemeingültiger Multiplikator für ECDSA-Signaturen verstanden werden. Bei Signaturprozessen mit hohem Durchsatz, die Tausende von Artefakten pro Tag verarbeiten, wirkt sich diese Größenzunahme auf den Speicherbedarf, die Netzwerkübertragungszeiten für signierte Artefakte und die Kapazität aller Systeme aus, die Signaturen verarbeiten, validieren oder zwischenspeichern.
Diese Auswirkungen lassen sich durch eine sorgfältige Architekturplanung beherrschen. Clientseitiges Hashing stellt sicher, dass nur Hashes und nicht die vollständigen Binärdateien die Signaturinfrastruktur durchlaufen, und die Hardwarebeschleunigung in modernen Hardware-Sicherheitsmodulen (HSM) reduziert den Rechenaufwand.
Legacy HSM-Lücke
Organisationen sollten den PQC-Fahrplan ihres jeweiligen HSM-Modells prüfen und Firmware-Upgrades entsprechend planen. Die meisten älteren, FIPS 140-2-zertifizierten HSMs unterstützen die NIST-PQC-Standards nicht nativ. Organisationen, die ältere HSM-Firmware verwenden, müssen entweder auf FIPS 140-3-fähige Firmware mit PQC-Unterstützung aktualisieren oder während der Übergangsphase einen Dual-Stack-Ansatz verfolgen, bei dem die klassische Signierung auf den bestehenden HSMs fortgesetzt wird, während die PQC-Signierung auf aktualisierter oder neuer Hardware erfolgt.
Die FIPS 140-3-Zertifizierung für HSM-Firmware mit PQC-Unterstützung schreitet voran. Entrust , Thales , Securosys und Utimaco haben bereits PQC-fähige Firmware-Updates ausgeliefert oder angekündigt.
Leistungsunterschiede
Die drei NIST PQC-Signaturalgorithmen weisen deutlich unterschiedliche Leistungsmerkmale auf. Die genauen Werte variieren jedoch erheblich je nach Parametersatz, verwendeter RSA-Schlüssellänge (als Vergleichsbasis), Art der Messung (Signierung oder Verifizierung), verwendeter Softwarebibliothek und CPU-Architektur, HSM-Implementierung, Hardwarebeschleunigung und Verwendung von Message-Pre-Hashing. Betrachten Sie daher alle angegebenen Durchsatzprozentsätze, einschließlich der unten aufgeführten allgemeinen Charakterisierungen, lediglich als Richtwerte und nicht als allgemeingültige Größen. Führen Sie daher Benchmarks mit Ihrer eigenen Bibliothek, Hardware und Ihrem eigenen Parametersatz durch, bevor Sie sich auf einen Wert verlassen.
- ML-DSA schneidet im Allgemeinen konkurrenzfähig ab und ist in vielen veröffentlichten Benchmarks sogar schneller als klassisches RSA. für Signiervorgänge, aufgrund seines effizienten gitterbasierten Designs.
- SLH-DSA ist wesentlich langsamer als die klassische RSA. in den meisten Konfigurationen, oft um ein bis zwei Größenordnungen, was es zu einem ungeeigneten primären Signaturalgorithmus für Pipelines mit hohem Datenaufkommen macht.
Dieser Leistungsunterschied ist entscheidend für die Algorithmuswahl. Die Verwendung von SLH-DSA in einer CI/CD-Pipeline, die Hunderte von Artefakten pro Build-Zyklus signiert, birgt das Risiko eines Durchsatzengpasses, der den Zweck einer automatisierten Pipeline zunichtemacht. ML-DSA ist im Allgemeinen die bessere Wahl für leistungssensible Signaturkontexte; SLH-DSA ist in der Regel Anwendungsfällen mit langlebigen Vertrauensankern vorbehalten, bei denen das konservative Sicherheitsprofil die Leistungseinbußen rechtfertigt.
Validierungsengpass
Jedes Betriebssystem, jeder Browser, jedes Sicherheitstool und jede Softwareinstallationsplattform, die Signaturen auf signierten Artefakten validiert, muss aktualisiert werden, um PQC-Signaturen zu erkennen und zu validieren. Dies stellt eine mehrjährige Herausforderung für die Synchronisierung des Ökosystems dar. Organisationen, die heute mit ML-DSA signieren, erzeugen Artefakte, deren PQC-Signaturen von Systemen, die noch nicht aktualisiert wurden, nicht verifiziert werden können. Genau deshalb ist die hybride Signatur, die sowohl eine klassische als auch eine PQC-Signatur auf jedes Artefakt anwendet, die richtige Architektur für die Übergangszeit.
Einer Studie zufolge geben 48 % der Unternehmen an, derzeit nicht auf Quantenangriffe vorbereitet zu sein , während 34 % fehlende zentrale Transparenz ihrer kryptografischen Assets als Haupthindernis für die PQC-Bereitschaft nennen . Man kann nicht migrieren, was man nicht inventarisiert.
Grundvoraussetzung für jedes PQC-Migrationsprogramm ist eine umfassende kryptografische Bestandsaufnahme, die jedes Zertifikat, jeden Schlüssel und jeden Signaturvorgang entlang der gesamten Build-, Signierungs- und Verteilungskette identifiziert. Encryption Consulting stellt Ihnen CBOM Secure zur Verfügung , um Sie bei der Erstellung eines Inventars aller kryptografischen Objekte in Ihrer Umgebung zu unterstützen. Ohne dieses Inventar basieren PQC-Migrationspläne auf unvollständigen Informationen.
Hybrid-Signatur: Zwei Unterschriften, kein zusammengesetztes Format
Es ist wichtig, den Begriff „Hybrid“ hier genau zu definieren, da er oft ungenau verwendet wird. Der gängige Ansatz besteht derzeit in der Verwendung zweier paralleler Signaturen: Das Zertifikat enthält eine klassische Signatur und eine PQC-Signatur als zwei unabhängige Signaturblöcke. Ein veralteter Verifizierer prüft die klassische Signatur und ignoriert die nicht erkannte; ein aktualisierter Verifizierer kann beide prüfen. Ein einzelnes kombiniertes „Composite“-Signaturformat für X.509-Zertifikate ist (Stand 2026) noch ein IETF Internet-Draft und kein finalisierter Standard. Daher ist es verfrüht, Produktionswerkzeuge darauf aufzubauen. Die doppelte Signatur ist derzeit die risikoärmere Option.
Migrationsabhängigkeiten: Die Build-Reihenfolge
Das untenstehende Prioritätenschema zeigt Ihnen, was am wichtigsten ist; dies ist die technische Reihenfolge, in der diese Punkte tatsächlich erledigt werden müssen.
- Prüfen Sie, ob die HSM-Firmware den von Ihnen beabsichtigten spezifischen Algorithmus (ML-DSA, SLH-DSA oder später FN-DSA) unterstützt; dies muss für jedes Modell einzeln überprüft werden und kann nicht anhand der allgemeinen PQC-Roadmap eines Herstellers angenommen werden.
- Aktualisieren Sie die Root- und Zwischenzertifizierungsstelleninfrastruktur, da diese den Vertrauensanker für alle nachgelagerten signierten Systeme darstellt und vor abhängigen Systemen aktualisiert werden muss.
- Integrieren Sie die PQC-Signierung als zusätzlichen, parallelen Signierungsschritt in die CI/CD-Pipeline, nicht als Ersatz, damit die klassische Signierung ununterbrochen fortgesetzt werden kann.
- Prüfen Sie, welche nachgelagerten Verifizierer (OS-Truststores, Paketmanager, interne Bereitstellungsgates) die neue Signatur überprüfen können, und behandeln Sie alle, die dies nicht können, als weiterhin von der klassischen Signatur abhängig.
- Führen Sie Pilotprojekte mit einer kontrollierten, risikoärmeren Produktlinie durch, bevor Sie die Produktion ausweiten, und verzichten Sie erst dann auf die klassische Signatur, wenn die Verifiziererabdeckung über Ihre tatsächlichen Vertriebskanäle hinweg bestätigt und nicht nur angenommen ist.
Tests
Bevor Sie die Skalierung über die Pilotphase hinaus fortsetzen, testen Sie die Signaturen mit allen Verifizierern, denen das Artefakt im Produktivbetrieb tatsächlich begegnen wird, nicht nur mit dem in der Entwicklung verwendeten. Die konsistente Behandlung nicht erkannter Signaturen ist nämlich nicht plattformübergreifend gewährleistet. Messen Sie die Auswirkungen der PQC-Signaturen auf die Artefaktgröße und die Übertragungszeit für jeden bandbreitenbeschränkten Verteilungskanal und führen Sie Lasttests des Signaturdurchsatzes unter dem realen Algorithmus und Volumen durch, insbesondere wenn SLH-DSA verwendet wird, da dessen Durchsatz im Vergleich zu ML-DSA deutlich geringer ist.
Rollback
Da die doppelte Signatur eine zweite, unabhängige Signatur hinzufügt, anstatt die erste zu ersetzen, ist ein Rollback während einer Pilotphase mit geringem Risiko verbunden: Sollte die PQC-Signatur irgendwo im Feld einen unerwarteten Verifizierungsfehler verursachen, bleibt die klassische Signatur gültig. Die Lösung besteht darin, das Hinzufügen der zweiten Signatur für diesen Artefaktstrom zu pausieren, bis die Inkompatibilität diagnostiziert ist. Besondere Vorsicht ist jedoch geboten, wenn die klassische Signatur vollständig außer Betrieb genommen wird. Dies sollte erst erfolgen, nachdem die Verifizierungsabdeckung bestätigt wurde, da eine nachträgliche Rücknahme der Entscheidung die erneute Aktivierung der doppelten Signatur erfordert und nicht nur eine einfache Konfigurationsänderung darstellt.
Datierter Fahrplan
| Milestone | Datum |
|---|---|
| FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) finalisiert | August 13, 2024 |
| FIPS 206 (FN-DSA) – voraussichtliche Fertigstellung | Ende 2026 oder Anfang 2027 (noch Entwurf) |
| CNSA 2.0 unterstützt und bevorzugt das Datum für die Signierung von Software/Firmware. | 2025 (bereits verstrichen) |
| CNSA 2.0 – ausschließliches Verwendungsdatum für die Signierung von Software/Firmware | 2030 |
| Google und Cloudflare streben eine vollständige PQC-Einführung in ihrer gesamten Infrastruktur an. | 2029 |
| Vollständiger NSS-Übergang (gemäß NSM-10) | 2035 |
Strategische Priorisierung
Organisationen, die versuchen, alle Aspekte des PQC-Übergangs gleichzeitig anzugehen, werden Schwierigkeiten haben, die Aufgaben zu verfolgen und zu priorisieren. Das untenstehende Rahmenwerk, das direkt aus dem Risikoprofil der Lieferkette abgeleitet wurde, kategorisiert Maßnahmen nach Dringlichkeit und Wichtigkeit.
Jetzt einsetzen: Wichtig und dringend
- Aktualisierung von Root und Zwischenversion Zertifizierungsstellen (CAs) zu PQC-konformen Algorithmen, da die CA-Infrastruktur der Vertrauensanker für alles nachgelagerte ist und zuerst angepasst werden muss.
- Lösung Jetzt ernten, später entschlüsseln (HNDL) Risiken für hochwertige signierte Artefakte durch erneutes Signieren langlebiger Software mit hybriden Signaturen, bevor sich das Bedrohungsfenster öffnet.
- Die Auswirkungen größerer PQC-Schlüssel- und Signaturgrößen auf Leistung und Latenz sollten angegangen werden, bevor sie den Durchsatz der Produktionspipeline beeinträchtigen.
- Validierung der hybriden Signaturarchitektur auf Abwärtskompatibilität mit Ihrer tatsächlichen Vertriebs- und Verifizierungsinfrastruktur vor jeglicher Produktionsfreigabe.
Strategische Planung: Wichtig, aber weniger dringlich
- Entwicklung und Test von hybriden Signaturverfahren anhand repräsentativer Anwendungsfälle in Ihrem spezifischen Software-Ökosystem.
- Die Auswahl der PQC-Algorithmen für jede Produktlinie und jeden Anwendungsfall der Signatur erfolgt auf der Grundlage von Leistungsanforderungen, Gerätebeschränkungen und Anforderungen an die Langlebigkeit der Signatur.
- Entwicklung einer agilen Krypto-Architektur, die es der Signaturinfrastruktur ermöglicht, Algorithmen auszutauschen und Schlüssel zu rotieren, ohne dass jedes Mal ein vollständiger Pipeline-Neubau erforderlich ist.
- Die Kompatibilität von Drittanbieter-Lieferketten wird analysiert, um zu verstehen, welche nachgelagerten Partner, Vertriebsplattformen und Verifizierungstools bereit sind, PQC-signierte Software zu nutzen.
Taktische Aufgaben: Dringend, aber operativ ausgerichtet
- Die Bewältigung des erhöhten Zertifikatsvolumens, das mit der Schlüsselrotation während der Migration einhergeht.
- Beantwortung von Berichtspflichten im Rahmen behördlicher Anfragen.
- Integration der PQC-Signatur in CI/CD-Pipelines neben bestehenden Tools während der Übergangsphase.
Monitor: Weniger dringlich und jetzt weniger wichtig
- Analyse der Stabilität des PQC-Algorithmus im Zeitverlauf nach der Implementierung.
- PQC-Migration für nicht kritische Altsysteme.
- Verfolgung zukünftiger Entwicklungen von Anbietern von Quantenangriffen.
Wie CodeSign Secure von Encryption Consulting hilft
CodeSign Secure ist die Enterprise-Codesignatur-Management-Plattform von Encryption Consulting und wurde speziell entwickelt, um die Migration der PQC-Codesignatur in jeder Phase des oben beschriebenen Fahrplans zu unterstützen.
PQC-Algorithmusunterstützung
CodeSign Secure v3.02 unterstützt produktionsreife Signaturen mit allen primären NIST PQC-Algorithmen als abtrennbare Signatur für Signier- und Verifizierungsprozesse:
- ML-DSA (FIPS 204) auf allen drei Sicherheitsstufen (ML-DSA-44, ML-DSA-65 und ML-DSA-87) für allgemeine Paket- und Lieferketten
- SLH-DSA (FIPS 205) für langfristige Archivierungssignaturen und unternehmenskritische Vertrauensankeranwendungen
- LMS (NIST SP 800-208) für Firmware- und IoT-Signaturanwendungen, bei denen hashbasierte, zustandsbehaftete Quantenresistenz bevorzugt wird
HSM-gestütztes Schlüsselmanagement für PQC-Schlüssel
CodeSign Secure speichert alle privaten Signaturschlüssel, sowohl klassische als auch PQC-Schlüssel, in FIPS 140-2 Level 3-zertifizierten Hardware-Sicherheitsmodulen . Die Plattform ist kompatibel mit Entrust nCipher, Thales Luna, Securosys, Utimaco sowie Cloud-HSMs von AWS und Azure, die alle ML-DSA- und SLH-DSA-Unterstützung in ihrer PQC-fähigen Firmware anbieten oder angekündigt haben.
CI/CD-Pipeline-Integration
CodeSign Secure integriert sich nativ in Azure DevOps, Jenkins, GitLab CI, TeamCity und andere gängige Pipeline-Plattformen und unterstützt sowohl API-basierte als auch Befehlszeilenaufrufe. PQC -Signaturvorgänge lassen sich als kontrollierte, richtlinienbasierte Phasen in Release-Pipelines konfigurieren, was sich aus Entwicklersicht nicht von bestehenden klassischen Signatur-Workflows unterscheidet.
Granulare Zugriffskontrolle und Audit-Protokollierung
Die rollenbasierte Zugriffskontrolle in CodeSign Secure regelt, wer PQC-Signaturvorgänge anfordern darf, welche Artefakte mit welchem Algorithmus und Zertifikat signiert werden können und welche Genehmigungsschritte erforderlich sind. Jeder Signiervorgang, einschließlich des verwendeten Algorithmus, des Zertifikats, des Artefakt-Hashs, des Zeitstempels und der genehmigenden Identität, wird unveränderlich protokolliert.
Scannen nach Software-Sicherheitslücken
CodeSign Secure umfasst vor der Signierung durchgeführte Software-Schwachstellenscans sowie die Hash-Verifizierung vor und nach der Signatur. Bevor eine PQC-Signatur angewendet wird, kann die Plattform überprüfen, ob das zu signierende Artefakt definierte Sicherheitskriterien erfüllt. Dadurch wird sichergestellt, dass die quantenresistente Signatur auf ein sicheres und nicht nur auf ein kryptografisch geschütztes Artefakt angewendet wird.
Häufig gestellte Fragen
Welchen PQC-Signaturalgorithmus sollte ich für die CI/CD-Codesignierung verwenden?
ML-DSA (FIPS 204) erzielt in den meisten veröffentlichten Benchmarks vergleichbare oder sogar schnellere Ergebnisse als klassisches RSA und eignet sich daher für Pipelines mit hohem Durchsatz. Der genaue Durchsatz hängt jedoch von der verwendeten Bibliothek, Hardware und den Parametereinstellungen ab. Der Durchsatz von SLH-DSA ist deutlich geringer, oft um eine Größenordnung oder mehr, weshalb es sich schlecht für die routinemäßige Signierung während des Build-Prozesses eignet; es sollte besser für langlebige Vertrauensanker reserviert werden.
Ist FN-DSA heute schon einsatzbereit?
Noch nicht. FN-DSA (FIPS 206) ist mit Stand 2026 noch ein erster öffentlicher Entwurf und wird voraussichtlich Ende 2026 oder Anfang 2027 finalisiert. Planen Sie es ein, aber bauen Sie keine Produktionsabhängigkeiten darauf auf, bevor es ein veröffentlichter Standard ist.
Muss ich die klassischen Signaturen sofort ersetzen?
Nein, und das sollten Sie auch nicht. Die duale, parallele Signierung – sowohl eine klassische als auch eine PQC-Signatur auf demselben Artefakt – ist der praktikable Ansatz, solange die Unterstützung von PQC-Signaturen durch die Verifizierer im gesamten Ökosystem noch uneinheitlich ist.
Was ist der größte Hemmschuh, den Organisationen unterschätzen?
Verifiziererkompatibilität. Ein Artefakt kann zwar heute mit ML-DSA korrekt signiert werden, diese Signatur ist jedoch nur für Systeme nützlich, die entsprechend aktualisiert wurden; es handelt sich hierbei um ein mehrjähriges Problem der Ökosystemsynchronisierung, nicht um ein Problem der Signatur selbst.
Wo fange ich an, wenn ich meine Signaturinfrastruktur noch nicht erfasst habe?
Mit kryptografischer Erkennung: eine vollständige Bestandsaufnahme aller Zertifikate, Schlüssel und Signaturvorgänge entlang der gesamten Build-, Signierungs- und Verteilungspipeline. Migrationspläne, die ohne diese Bestandsaufnahme erstellt werden, basieren auf unvollständigen Informationen.
Fazit
Der Übergang zur Post-Quanten-Technologie für die Codesignierung ist kein einmaliges Ereignis. Es handelt sich um eine mehrjährige architektonische Weiterentwicklung, die sorgfältige Planung, schrittweise Umsetzung und eine Infrastruktur erfordert, die während der Übergangsphase sowohl klassische als auch quantenresistente Signaturvorgänge gleichzeitig durchführen kann.
Regulatorische Vorgaben wie die NIST-Fristen für 2030 und 2035, die ML-DSA-Einführungsanforderungen von CNSA 2.0 und die Migrationsmeilensteine des britischen NCSC definieren konkrete Erwartungen, an deren Erfüllung Organisationen im öffentlichen und privaten Sektor bereits arbeiten. Die Bedrohung durch „Vertrauen jetzt, Nachbearbeitung später“ bedeutet, dass jedes klassisch signierte Artefakt mit langer Lebensdauer heute ein Risiko birgt, das sich bei der Ankunft eines CRQC manifestiert.
Bei Encryption Consulting haben wir CodeSign Secure entwickelt , um den Übergang zu PQC schon heute umsetzbar zu machen – mit Unterstützung für ML-DSA und SLH-DSA mit abtrennbaren Signaturen sowie den Infrastrukturkontrollen, die Compliance- und Governance-Programme erfordern.
