PQC-codeondertekening: architectuurstrategieën voor veilige softwareleveringsketens

De softwareleveringsketen draait op vertrouwen, en elk ondertekend binair bestand is afhankelijk van één fundamentele aanname: dat de cryptografische algoritmen die die handtekeningen beschermen, met name RSA en ECDSA, niet kunnen worden gekraakt door een aanvaller met de beschikbare rekenkracht. Maar die aanname is niet langer voor onbepaalde tijd veilig.

De opkomst van cryptografisch relevante kwantumcomputers (CRQC's) introduceert een systemisch risico voor elk digitaal handtekeningsysteem dat momenteel in gebruik is. NIST heeft in augustus 2024 zijn eerste post-kwantum cryptografische standaarden afgerond en systeembeheerders expliciet aangespoord om onmiddellijk met de integratie te beginnen. Regelgevers en technologieleiders bewegen zich eensgezind, van het CNSA 2.0-mandaat van de NSA dat de implementatie van ML-DSA voor nationale veiligheidssystemen vereist, tot het doel van Google en Cloudflare om tegen 2029 volledige PQC-implementatie in hun infrastructuur te realiseren.

De vraag is niet langer of organisaties hun infrastructuur voor codeondertekening moeten overzetten naar post-kwantumalgoritmen. De vraag is of ze die overgang zullen voltooien voordat een CRQC de vertraging onaanvaardbaar maakt.

We zullen het PQC-algoritmelandschap, de specifieke implementatie-uitdagingen voor codeondertekening, de architectuurstrategieën en het gefaseerde migratieplan bespreken. Dit plan biedt softwareteams een duidelijk pad vooruit, zonder operationele downtime. Voor de tijdstempeling, HSM-gereedheid en de mechanismen voor langetermijnverificatie die bepalen of een vandaag toegepaste handtekening over twintig jaar nog steeds geldig is, verwijzen we u naar ons artikel PQC voor codeondertekening: Bescherming van langlevende software en firmware.

De PQC-codeondertekeningsstrategie, gedefinieerd als: een geprioriteerd, gefaseerd plan voor het overzetten van de ondertekeningsinfrastructuur van een softwareleveringsketen naar kwantumresistente algoritmen, ML-DSA, SLH-DSA of FN-DSA, gekozen op basis van de werklast in plaats van een standaardinstelling, ingezet naast klassieke handtekeningen tijdens de overgang, en gesequenced zodat wijzigingen in de vertrouwensbasis plaatsvinden vóór afhankelijke systemen in plaats van erna.

Key Takeaways

• FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) zijn sinds augustus 2024 definitieve NIST-standaarden. FN-DSA (FIPS 206) is nog een eerste openbaar ontwerp, dat naar verwachting eind 2026 of begin 2027 zal worden afgerond en nog niet als standaard is gepubliceerd.
• De keuze voor een algoritme hangt af van de werklast: ML-DSA voor CI/CD-ondertekening met een hoog volume, waar het in gepubliceerde benchmarks doorgaans concurrerend presteert met of sneller is dan RSA; SLH-DSA voor langdurige vertrouwensankers waar het conservatievere, tragere profiel acceptabel is; FN-DSA (na de definitieve versie) voor IoT/embedded apparaten met beperkte resources.
• Hybride ondertekening (klassieke en PQC-ondertekening, parallel toegepast) is tegenwoordig de gangbare praktijk, omdat de ondersteuning van PQC-ondertekeningen door verificatoren nog steeds ongelijk verdeeld is over het ecosysteem. Dit is dezelfde aanpak met dubbele ondertekening die specifiek voor CI/CD is beschreven in ons artikel over de SLSA Level 3-architectuur.
• Deze pagina vormt de prioriterings- en architectuurstrategielaag voor de algemene softwareleveringsketen. Voor het CNSA 2.0-specifieke transitieplan en de migratie in vijf fasen, zie Het ontwerpen van de transitiestrategieën voor CNSA 2.0; voor een specifieke keuze tussen hash-gebaseerde ondertekeningsschema's, zie Vergelijking van SLH-DSA, LMS en XMSS.
• Je kunt niet migreren wat je niet kunt inventariseren; 34% van de bedrijven noemt een gebrek aan gecentraliseerd cryptografisch inzicht als een belangrijke belemmering voor PQC-gereedheid.

Waarom PQC-codeondertekening niet langer kan wachten

De meeste organisaties beschouwen de kwantumdreiging als een probleem voor de toekomst. Maar voor softwareleveringsketens zorgen verbeteringen in algoritmes ervoor dat er minder qubits nodig zijn om RSA-2048 te kraken. In 2019 werd geschat dat er ongeveer 20 miljoen qubits nodig waren om RSA-2048 te kraken, maar tegen 2025 hebben nieuwere architecturen die gebruikmaken van Quantum Low-Density Parity-Check (QLDPC)-codes die schatting teruggebracht tot ongeveer 100,000 qubits. Dat is een twintigvoudige reductie, puur te danken aan algoritmische innovatie en niet aan hardware, in minder dan zes jaar tijd.

In tegenstelling tot versleutelde communicatie, waar het principe "nu verzamelen, later decoderen" geldt voor vertrouwelijkheid, brengt ondertekende software een ander risico met zich mee: " nu vertrouwen, later vervalsen ". Een ondertekend installatieprogramma, een firmware-image, een software-updatepakket: deze artefacten blijven jaren of zelfs decennia in omloop. Als er een CRQC (Criminal Reporting Qualifications) verschijnt en klassieke ondertekeningsalgoritmen worden gekraakt, kan een aanvaller achteraf handtekeningen vervalsen op kwaadaardige artefacten die niet te onderscheiden zijn van legitieme, historisch ondertekende software. Het risico bestaat niet alleen wanneer een CRQC verschijnt, maar gedurende de gehele levensduur van elk klassiek ondertekend artefact dat op dat moment nog in gebruik is.

Het rapport van het Citi Institute uit januari 2026 , 'Quantum Threat: The Trillion-Dollar Security Race Is On', schat de kans dat een kwantumcomputer RSA-2048 tegen 2034 zal kraken op 19 tot 34%. Wereldwijd zijn er momenteel ongeveer 20 miljard actieve IoT-apparaten die tijdens hun levensduur aan deze kwantumdreiging zijn blootgesteld. Voor softwareteams die producten beheren met een levensduur van meerdere jaren, is de overstap naar PQC-codeondertekening niet langer een voordeel voor de eerste gebruiker. Het is een risicobeperking in de toeleveringsketen die nu al moet worden doorgevoerd.

NIST PQC-algoritmen voor codeondertekening

NIST heeft op 13 augustus 2024 de eerste drie post-kwantum cryptografische standaarden afgerond. Deze zijn onmiddellijk van kracht voor gebruik door de Amerikaanse federale overheid en dienen als wereldwijde maatstaf voor acceptatie in de industrie. Voor digitale handtekeningen, die de basis vormen voor codeondertekening, zijn drie algoritmen beschikbaar of in de fase van afronding.

Het kiezen van het juiste algoritme is een cruciale architectuurbeslissing die alles beïnvloedt, van de prestaties van CI/CD-pipelines tot de levensduur van de root-of-trust. Hieronder een vergelijking van de NIST-signatuuralgoritmen voor toepassingen voor codeondertekening:

Algoritme	Standaard	Kern Principe	Handtekeninggrootte	Doorvoer	Best geschikt voor
ML-DSA (KRISTALLEN - Dilithium)	FIPS 204 (afgerond)	Gestructureerd rooster (Module-LWE)	2–3 KB	Over het algemeen even goed als of sneller dan klassieke methoden in gepubliceerde benchmarks.	Algemene pakketondertekening, DevOps, CI/CD-toeleveringsketen
SLH-DSA (SPHINCS+)	FIPS 205 (afgerond)	Staatloos hash-gebaseerd (SHA-2/SHAKE)	8–50 KB	Aanzienlijk lager; aanzienlijke overheadkosten	Langetermijnarchivering, missiekritische vertrouwensankers
FN-DSA (FALCON)	FIPS 206 (eerste openbare ontwerpversie; definitieve versie verwacht eind 2026 of begin 2027)	Compact rooster (NTRU-gebaseerd)	0.6–1.2 KB	Snel (geoptimaliseerd voor apparaten met beperkte mogelijkheden)	IoT-firmware, ingebedde systemen, hardware met beperkte resources

Implementatie-uitdagingen

De PQC-codeondertekeningsalgoritmen zijn gestandaardiseerd en de beveiligingsbewijzen zijn solide. Het is een operationele en infrastructurele uitdaging. Maar er zijn een paar zaken die expliciete planning vereisen:

Inflatie van handtekening- en sleutelgrootte

De meest direct zichtbare verandering bij de overstap van klassieke naar PQC-algoritmen is de aanzienlijke toename van de sleutel- en handtekeninggrootte.

Bestanddeel	RSA-3072 (Klassiek)	ML-DSA-65 (PQC)
public Key	~384 bytes	~1,952 bytes
private Key	~384 bytes	~4,032 bytes
Signature	~384 bytes	~3,309 bytes

Gebruikmakend van een onbewerkte 64-byte P-256 ECDSA-handtekening als vergelijkingspunt, is een ML-DSA-65-handtekening (3,309 bytes) ongeveer 52 keer groter. Deze verhouding geldt specifiek voor de onbewerkte 64-byte representatie; ECDSA-handtekeningen die in de praktijk gecodeerd zijn (DER) zijn doorgaans iets groter dan 64 bytes. Deze vergelijking moet daarom worden gezien als een illustratie van de omvang van de toename, en niet als een universele vermenigvuldigingsfactor voor ECDSA-handtekeningen in het algemeen. Voor grootschalige ondertekeningsprocessen die duizenden artefacten per dag verwerken, heeft deze toename in omvang gevolgen voor de opslagvereisten, de netwerkoverdrachtstijden voor ondertekende artefacten en de capaciteit van systemen die handtekeningen verwerken, valideren of cachen.

Deze gevolgen zijn beheersbaar met een goede architectuurplanning. Hashing aan de clientzijde zorgt ervoor dat alleen hashes, en niet volledige binaire bestanden, de ondertekeningsinfrastructuur passeren, en hardwareversnelling in moderne Hardware Security Modules (HSM's) vermindert de rekenoverhead.

Legacy HSM Gap

Organisaties moeten de PQC-roadmap van hun specifieke HSM-model controleren en firmware-upgrades dienovereenkomstig plannen. De meeste oudere, FIPS 140-2-gecertificeerde HSM's bieden geen native ondersteuning voor NIST PQC-standaarden. Organisaties die oudere HSM-firmware gebruiken, moeten ofwel upgraden naar FIPS 140-3-compatibele firmware met PQC-ondersteuning, ofwel een 'dual-stack'-aanpak hanteren tijdens de overgangsperiode, waarbij klassieke ondertekening blijft werken op bestaande HSM's, terwijl PQC-ondertekening wordt uitgevoerd op bijgewerkte of nieuwe hardware.

De FIPS 140-3-certificering voor HSM-firmware met PQC-ondersteuning vordert gestaag. Entrust , Thales , Securosys en Utimaco hebben allemaal PQC-compatibele firmware-updates uitgebracht of aangekondigd.

Prestatieverschillen

De drie NIST PQC-handtekeningalgoritmen hebben wezenlijk verschillende prestatiekarakteristieken, hoewel de exacte cijfers sterk variëren afhankelijk van de parameterinstellingen, de gebruikte RSA-sleutelgrootte als vergelijkingsbasis, of u ondertekening of verificatie meet, de specifieke softwarebibliotheek en CPU-architectuur, HSM-implementatie, hardwareversnelling en of berichtvooraf hashen wordt gebruikt. Beschouw elk specifiek doorvoerpercentage, inclusief de algemene karakteriseringen hieronder, als illustratief en niet als universeel toepasbaar in verschillende omgevingen; voer benchmarks uit met uw eigen bibliotheek, hardware en parameterinstellingen voordat u op een getal vertrouwt.

• ML-DSA presteert over het algemeen vergelijkbaar met, en in veel gepubliceerde benchmarks zelfs sneller dan, klassieke RSA. voor ondertekeningsoperaties, dankzij het efficiënte, op een raster gebaseerde ontwerp.
• SLH-DSA is aanzienlijk trager dan klassieke RSA. In de meeste configuraties is het verschil vaak één tot twee ordes van grootte, waardoor het minder geschikt is als primair ondertekeningsalgoritme in pijplijnen met een hoog volume.

Dit prestatieverschil is cruciaal voor de algoritmekeuze. Het kiezen van SLH-DSA voor een CI/CD-pipeline die honderden artefacten per buildcyclus ondertekent, brengt het risico met zich mee van een doorvoerknelpunt dat het doel van een geautomatiseerde pipeline tenietdoet. ML-DSA is over het algemeen de betere keuze voor prestatiegevoelige ondertekeningscontexten; SLH-DSA wordt doorgaans gereserveerd voor langdurige vertrouwensankers, waar het conservatieve beveiligingsprofiel de prestatiekosten rechtvaardigt.

Validatieknelpunt

Elk besturingssysteem, elke browser, beveiligingstool en software-installatieplatform dat handtekeningen op ondertekende artefacten valideert, moet worden bijgewerkt om PQC-handtekeningen te herkennen en te valideren. Dit is een meerjarige uitdaging voor de synchronisatie van het ecosysteem. Een organisatie die vandaag de dag begint met ondertekenen met ML-DSA, zal artefacten produceren waarvan de PQC-handtekeningen niet kunnen worden geverifieerd door systemen die nog niet zijn bijgewerkt. Juist daarom is hybride ondertekening, waarbij zowel een klassieke als een PQC-handtekening op elk artefact wordt toegepast, de juiste architectuur voor de overgangsperiode.

Volgens onderzoek geeft 48% van de bedrijven aan momenteel niet voorbereid te zijn op kwantumdreigingen , terwijl 34% een gebrek aan gecentraliseerd inzicht in hun cryptografische activa noemt als een belangrijke belemmering voor PQC-gereedheid . Je kunt niet migreren wat je niet kunt inventariseren.

De eerste stap in elk PQC-migratieprogramma is een volledige cryptografische inventarisatie, waarbij elk certificaat, elke sleutel en elke ondertekeningsbewerking in de gehele productie-, ondertekenings- en distributiepipeline wordt geïdentificeerd. Encryption Consulting biedt CBOM Secure aan om u te helpen een inventaris bij te houden van alle cryptografische objecten in uw omgeving. Zonder deze inventarisatie zijn PQC-migratieplannen gebaseerd op onvolledige informatie.

Hybride ondertekening: dubbele handtekeningen, geen samengesteld formaat.

Het is belangrijk om precies te zijn over wat "hybride" hier betekent, aangezien het begrip vaak losjes wordt gebruikt. De praktische aanpak is momenteel het gebruik van dubbele, parallelle handtekeningen: het artefact bevat een klassieke handtekening en een PQC-handtekening als twee onafhankelijke handtekeningblokken. Een verificator die niet is bijgewerkt, controleert de klassieke handtekening en negeert de handtekening die hij niet herkent; een bijgewerkte verificator kan beide controleren. Een enkel gecombineerd "composiet" handtekeningformaat voor X.509-certificaten is in 2026 nog steeds een IETF Internet-Draft en geen definitieve standaard, dus het is voorbarig om daar productietools voor te ontwikkelen. Dubbele ondertekening is voorlopig de minst risicovolle optie.

Migratieafhankelijkheden: De bouwvolgorde

Het onderstaande prioriteitenkader geeft aan wat het belangrijkst is; dit is de technische volgorde waarin die zaken daadwerkelijk moeten plaatsvinden.

1. Controleer of de HSM-firmware het specifieke algoritme (ML-DSA, SLH-DSA of later FN-DSA) ondersteunt dat u wilt gebruiken; dit moet per model worden geverifieerd en kan niet worden aangenomen op basis van de algemene PQC-roadmap van een leverancier.
2. Upgrade de infrastructuur van de root- en intermediaire CA's, aangezien deze de vertrouwensbasis vormen voor alles wat stroomafwaarts wordt ondertekend en moeten worden geüpgraded vóór de afhankelijke systemen.
3. Integreer PQC-ondertekening in de CI/CD-pipeline als een extra, parallelle ondertekeningsstap, niet als vervanging, zodat de klassieke ondertekening ononderbroken kan doorgaan.
4. Bevestig welke downstream-verificatiesystemen (vertrouwensarchieven van het besturingssysteem, pakketbeheerders, interne implementatiepoorten) de nieuwe handtekening kunnen controleren en beschouw alle systemen die dat niet kunnen als nog steeds afhankelijk van de klassieke handtekening.
5. Test het product eerst op een gecontroleerde productlijn met een lager risico voordat u opschaalt, en vervang de klassieke digitale handtekening pas wanneer de verificatiedekking in uw daadwerkelijke distributiekanalen is bevestigd, en niet slechts verondersteld.

Testen

Voordat u verder gaat dan een pilot, test u het artefact met elke verificator die het in de productieomgeving daadwerkelijk zal tegenkomen, niet alleen met degene die tijdens de ontwikkeling is gebruikt. De afhandeling van onbekende handtekeningen is namelijk niet gegarandeerd consistent op verschillende platforms. Meet de impact van PQC-handtekeningen op de grootte van het artefact en de overdrachtstijd voor elk distributiekanaal met beperkte bandbreedte. Test de doorvoer van de ondertekening onder belasting met het daadwerkelijke algoritme en volume, met name als SLH-DSA wordt gebruikt, gezien de aanzienlijk lagere doorvoer in vergelijking met ML-DSA.

Rollback

Omdat dubbele ondertekening een tweede, onafhankelijke handtekening toevoegt in plaats van de eerste te vervangen, is terugdraaien tijdens een pilotfase een laag risico: als de PQC-handtekening ergens in het veld een onverwachte verificatiefout veroorzaakt, blijft de klassieke handtekening geldig en is de oplossing om het toevoegen van de tweede handtekening voor die artefactstroom te pauzeren totdat de incompatibiliteit is vastgesteld. De situatie die echte voorzichtigheid vereist, is het volledig buiten gebruik stellen van de klassieke handtekening; doe dit alleen nadat de verificatiedekking is bevestigd, aangezien het terugdraaien van die beslissing achteraf betekent dat dubbele ondertekening opnieuw moet worden ingeschakeld in plaats van een eenvoudige configuratiewijziging.

Gedateerde routekaart

Milestone	Datum
FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) zijn afgerond.	August 13, 2024
FIPS 206 (FN-DSA) wordt naar verwachting definitief afgerond	Eind 2026 of begin 2027 (nog steeds concept)
CNSA 2.0 ondersteunings- en voorkeursdatum voor software-/firmwareondertekening	2025 (reeds voorbij)
CNSA 2.0-datum exclusief voor software-/firmwareondertekening	2030
Google en Cloudflare streven naar volledige implementatie van PQC in hun infrastructuur.	2029
Volledige NSS-overgang (conform NSM-10)	2035

Strategische prioritering

Organisaties die proberen alle aspecten van de PQC-transitie tegelijkertijd aan te pakken, zullen het moeilijk vinden om de taken te volgen en te prioriteren. Het onderstaande raamwerk, rechtstreeks afgeleid van het risicoprofiel van de toeleveringsketen, categoriseert acties op basis van urgentie en belang.

Direct inzetten: Belangrijk en urgent

• Het upgraden van de root- en tussenliggende componenten certificeringsinstanties (CA's) naar PQC-compatibele algoritmen, aangezien de CA-infrastructuur het vertrouwensanker is voor alles wat daarop volgt en als eerste moet worden verplaatst.
• Het oplossen Nu oogsten, later decoderen (HNDL) risico's voor waardevolle ondertekende artefacten door langlopende software opnieuw te ondertekenen met hybride handtekeningen voordat het dreigingsvenster zich voordoet.
• Het aanpakken van de gevolgen voor de prestaties en latentie van grotere PQC-sleutel- en handtekeninggroottes voordat deze de doorvoer van de productiepipeline beïnvloeden.
• Valideer de hybride ondertekeningsarchitectuur op achterwaartse compatibiliteit met uw daadwerkelijke distributie- en verificatie-infrastructuur vóór de uitrol naar productie.

Strategische planning: belangrijk, maar minder urgent.

• Het ontwikkelen en testen van hybride handtekeningschema's voor representatieve gebruiksscenario's binnen uw specifieke software-ecosysteem.
• Het selecteren van PQC-algoritmen voor elke productlijn en elk gebruiksscenario voor ondertekening op basis van prestatievereisten, apparaatbeperkingen en de gewenste levensduur van de handtekening.
• Het ontwerpen van een crypto-flexibele architectuur zodat de ondertekeningsinfrastructuur algoritmes kan wisselen en sleutels kan roteren zonder dat de hele pipeline telkens opnieuw hoeft te worden opgebouwd.
• Het in kaart brengen van de compatibiliteit van de toeleveringsketen met derden om te begrijpen welke downstreampartners, distributieplatformen en verificatietools klaar zijn om PQC-ondertekende software te gebruiken.

Tactische taken: urgent maar operationeel gericht

• Het beheren van de toename in certificaatvolumes die gepaard gaat met sleutelrotatie tijdens migratie.
• Het voldoen aan rapportageverplichtingen naar aanleiding van vragen van toezichthouders.
• Het integreren van PQC-ondertekening in CI/CD-pipelines naast bestaande tools tijdens de overgang.

Monitor: Minder urgent en minder belangrijk nu

• Analyse na implementatie van de stabiliteit van het PQC-algoritme in de loop van de tijd.
• PQC-migratie voor niet-kritieke, verouderde systemen.
• Het volgen van toekomstige ontwikkelingen op het gebied van kwantumaanvalstechnologie.

Hoe CodeSign Secure van Encryption Consulting helpt

CodeSign Secure is het platform voor het beheer van codeondertekening op bedrijfsniveau van Encryption Consulting, en is specifiek ontworpen om de migratie naar PQC-codeondertekening in elke fase van het bovenstaande stappenplan te ondersteunen.

PQC-algoritmeondersteuning

CodeSign Secure v3.02 ondersteunt digitale handtekeningen van productiekwaliteit met alle belangrijke NIST PQC-algoritmen als een afneembare handtekening voor ondertekenings- en verificatieprocessen:

• ML-DSA (FIPS 204) op alle drie beveiligingsniveaus (ML-DSA-44, ML-DSA-65 en ML-DSA-87) voor algemene pakket- en toeleveringsketens.
• SLH-DSA (FIPS 205) voor langdurige archivering en bedrijfskritische vertrouwensankerapplicaties
• LMS (NIST SP 800-208) voor firmware- en IoT-ondertekeningstoepassingen waar hash-gebaseerde, stateful kwantumresistentie de voorkeur heeft.

HSM-ondersteund sleutelbeheer voor PQC-sleutels

CodeSign Secure slaat alle privésleutels voor ondertekening, zowel klassieke als PQC-sleutels, op in FIPS 140-2 Level 3-gecertificeerde hardwarebeveiligingsmodules . Het platform integreert met Entrust nCipher, Thales Luna, Securosys, Utimaco, evenals cloud-HSM's van AWS en Azure, die allemaal ML-DSA- en SLH-DSA-ondersteuning hebben geleverd of aangekondigd in hun PQC-compatibele firmware.

Integratie van CI/CD-pijplijn

CodeSign Secure integreert naadloos met Azure DevOps, Jenkins, GitLab CI, TeamCity en andere belangrijke pipelineplatformen, en ondersteunt zowel API-gebaseerde als commandoregel-aanroepen. PQC- ondertekeningsbewerkingen kunnen worden geconfigureerd als gecontroleerde, door beleid afgedwongen fasen in releasepipelines, vanuit het perspectief van de ontwikkelaar niet anders dan bestaande klassieke ondertekeningsworkflows.

Gedetailleerde toegangscontrole en auditregistratie

Rolgebaseerde toegangscontrole in CodeSign Secure bepaalt wie PQC-ondertekeningsbewerkingen mag aanvragen, welke artefacten met welk algoritme en certificaat mogen worden ondertekend en welke goedkeuringsstappen vereist zijn. Elke ondertekeningsgebeurtenis, inclusief het gebruikte algoritme, het certificaat, de hash van het artefact, het tijdstempel en de goedkeurende identiteit, wordt onveranderlijk vastgelegd.

Software kwetsbaarheidsscannen

CodeSign Secure omvat het scannen op softwarekwetsbaarheden vóór het ondertekenen en het controleren van hashes vóór en na het ondertekenen als onderdeel van de workflow. Voordat een PQC-handtekening wordt toegepast, kan het platform valideren of het te ondertekenen object voldoet aan de gedefinieerde beveiligingscriteria. Dit garandeert dat de kwantumresistente handtekening wordt toegepast op een veilig object en niet slechts op een cryptografisch beschermd object.

Veelgestelde Vragen / FAQ

Welk PQC-signatuuralgoritme moet ik gebruiken voor het ondertekenen van CI/CD-code?

ML-DSA (FIPS 204). In de meeste gepubliceerde benchmarks presteert het vergelijkbaar met of sneller dan klassieke RSA, waardoor het geschikt is voor pipelines met een hoog volume, hoewel de exacte doorvoer afhangt van uw specifieke bibliotheek, hardware en parameterinstellingen. De doorvoer van SLH-DSA is aanzienlijk lager, vaak een factor tien of meer, waardoor het minder geschikt is voor routinematige ondertekening tijdens het buildproces; het is beter geschikt voor langdurige vertrouwensankers.

Is FN-DSA vandaag al gebruiksklaar?

Nog niet. FN-DSA (FIPS 206) is in 2026 nog steeds een conceptversie voor het publiek, die naar verwachting eind 2026 of begin 2027 definitief zal worden. Houd er rekening mee, maar bouw er geen productieafhankelijkheden van voordat het een officiële standaard is.

Moet ik de klassieke signatuur direct vervangen?

Nee, en dat zou je ook niet moeten doen. Dubbele, parallelle ondertekening, zowel een klassieke als een PQC-ondertekening op hetzelfde artefact, is de praktische aanpak, terwijl de ondersteuning voor PQC-ondertekeningen door verificatoren in het ecosysteem nog steeds ongelijk is.

Wat is de grootste hindernis die organisaties onderschatten?

Compatibiliteit van de verificator. Een artefact kan vandaag de dag correct worden ondertekend met ML-DSA, maar die handtekening is alleen bruikbaar voor systemen die zijn bijgewerkt om deze te herkennen; dit is een synchronisatieprobleem binnen het ecosysteem dat al jaren speelt, geen probleem met de ondertekening zelf.

Waar moet ik beginnen als ik mijn infrastructuur voor digitale handtekeningen nog niet in kaart heb gebracht?

Met cryptografische ontdekking: een complete inventarisatie van elk certificaat, elke sleutel en elke ondertekeningsbewerking in het gehele bouw-, ondertekenings- en distributieproces. Migratieplannen die zonder deze inventarisatie zijn opgesteld, werken met onvolledige informatie.

Conclusie

De overgang naar een post-kwantumtijdperk voor codeondertekening is geen eenmalige gebeurtenis. Het is een architectonische evolutie die meerdere jaren in beslag neemt en die weloverwogen planning, gefaseerde uitvoering en een infrastructuur vereist die zowel klassieke als kwantumresistente ondertekeningsprocessen gelijktijdig kan ondersteunen gedurende de overgangsperiode.

Regelgeving zoals de deadlines van NIST voor 2030 en 2035, de ML-DSA-implementatievereisten van CNSA 2.0 en de migratiemijlpalen van het Britse NCSC scheppen concrete verwachtingen waaraan organisaties in zowel de publieke als de private sector al werken. De dreiging van 'Trust Now, Forge Later' betekent dat elk klassiek ondertekend document met een lange distributielevensduur nu al risico's opbouwt die zich zullen materialiseren wanneer een CRQC (Clinical Reference Quality Control) arriveert.

Bij Encryption Consulting hebben we CodeSign Secure ontwikkeld om de PQC-overgang vandaag nog mogelijk te maken, met ondersteuning voor ML-DSA en SLH-DSA met verwijderbare handtekeningen, en de infrastructuurcontroles die compliance- en governanceprogramma's vereisen.