Waarom post-kwantumvertrouwen in de hardware begint

Gepubliceerd: september 2025. Bijgewerkt: augustus 2026. Beoordeeld door de HSM Services- en PQC Advisory-teams van Encryption Consulting.

Elk migratieplan naar het post-kwantumtijdperk loopt uiteindelijk tegen dezelfde muur aan: het algoritme kan worden gestandaardiseerd, de applicatie kan worden gepatcht en het certificaatbeleid kan worden herschreven, maar niets daarvan betekent iets als de privésleutel waar alles van afhangt, is gegenereerd, opgeslagen of ondertekend op hardware die niet te vertrouwen is om dit correct te doen. Een softwarebibliotheek kan post-kwantumcryptografie (PQC) perfect implementeren en toch worden ondermijnd door een sleutel die via een nevenkanaal is gelekt, een willekeurige-getallengenerator die niet echt willekeurig is, of firmware die onder belasting stilletjes terugvalt op een klassiek algoritme. Daarom moet vertrouwen in het post-kwantumtijdperk beginnen in de hardware, met name in de Hardware Security Module (HSM) die de sleutelgeneratie en -ondertekening verankert voor alles wat ernaast gebeurt.

Dit is nu belangrijk omdat de standaarden niet langer theoretisch zijn. NIST heeft FIPS 203 (ML-KEM) , FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) op 13 augustus 2024 definitief vastgesteld, en HSM-leveranciers hebben het afgelopen jaar besteed aan het omzetten van deze standaardisatie in firmware. De resterende vraag voor de meeste bedrijven is niet welk algoritme ze moeten kiezen, maar of de hardware onder hun PKI, TLS-terminators, codeondertekeningspipeline en sleutelbeheersystemen deze algoritmen daadwerkelijk binnen een gevalideerde beveiligingsgrens, op productieschaal, kan uitvoeren zonder de beschikbaarheid te ondermijnen.

Waarom begint de voorbereiding op het post-kwantumtijdperk op hardware- en HSM-niveau?

De voorbereiding op PQC begint op hardwareniveau, omdat de HSM de vertrouwensbasis vormt voor elke sleutel die het algoritme ooit gebruikt. Als de module die een ML-KEM- of ML-DSA-sleutel genereert, opslaat en gebruikt zelf niet betrouwbaar is, is de wiskundige sterkte van het algoritme irrelevant. Vier garanties op hardwareniveau worden direct overgedragen naar het PQC-tijdperk, en elk daarvan verandert op een specifieke, testbare manier zodra grotere post-kwantumsleutels in beeld komen.

• Onveranderlijke apparaatidentiteit. Een hardware-gebonden identiteit die niet gekloond of vervalst kan worden, authenticeert de HSM zelf bij de systemen die ervan afhankelijk zijn. In een post-kwantumcontext moet deze identiteit steeds vaker worden ondertekend met een kwantumresistent algoritme, zodat een aanvaller met toekomstige kwantumcapaciteit deze niet achteraf kan vervalsen.
• Sleutelkluis met fraudebestendige opbergruimte. Sleutels die binnen de cryptografische grens van de HSM worden gegenereerd en gebruikt, verlaten deze nooit in platte tekst. Dit is des te belangrijker bij PQC, omdat de privésleutels van ML-DSA en SLH-DSA en de operationele status die sommige ondertekeningsschema's vereisen, groter zijn en duurder om opnieuw te genereren als ze gecompromitteerd raken.
• Echte willekeurige getallengeneratie. Roostergebaseerde schema's zoals ML-KEM en ML-DSA zijn afhankelijk van hoogwaardige entropie voor sleutelgeneratie en, in sommige implementaties, voor gerandomiseerde ondertekening. Een hardwarematige True Random Number Generator (TRNG) die gebruikmaakt van fysieke ruis vormt een sterkere basis voor PQC-sleutelmateriaal dan een softwarematige pseudo-willekeurige generator.
• Beveiligd opstarten en firmwareondertekening. De HSM valideert zijn eigen firmware voordat deze wordt uitgevoerd. Naarmate PQC-firmware-updates routine worden, moet beveiligd opstarten deze updates verifiëren met kwantumresistente handtekeningen. Dit is precies waarvoor CNSA 2.0 LMS, XMSS of ML-DSA vereist in de context van firmware- en softwareondertekening.

Geen van deze vier garanties is nieuw. Wat wel verandert in het PQC-tijdperk, is de omvang en de aard van het materiaal dat ze beschermen, en dat is waar de meeste tekortkomingen op het gebied van PQC-gereedheid in productieomgevingen met HSM-systemen zich daadwerkelijk openbaren.

CBOM Secure

Verkrijg volledig inzicht met continue cryptografische detectie, geautomatiseerde inventarisatie en datagestuurde PQC-correctie.

Boek een adviesgesprek

Wat is de huidige stand van zaken met betrekking tot de PQC-ondersteuning van HSM-leveranciers?

Alle drie de grote HSM-leveranciers, Thales, Entrust en Utimaco, bieden nu NIST CAVP-gevalideerde ML-KEM- en ML-DSA-ondersteuning in hun huidige firmware, als upgrade in plaats van als hardwarevervanging. De ondersteuning van SLH-DSA en de stateful hash-gebaseerde handtekeningschema's is waar de leveranciers nog van mening verschillen, en de FIPS 140-3-modulevalidatie, waarbij PQC-algoritmen binnen de gecertificeerde grenzen worden gecombineerd (en niet alleen de algoritmen afzonderlijk), is het nieuwste en meest belangrijke onderscheidende kenmerk.

Leverancier en productlijn	PQC-algoritmen verzending	Levering Wijze	Status van FIPS 140-3 (vanaf de laatste update)
Thales Luna HSM (firmware 7.9, juli 2025)	ML-KEM (FIPS 203), ML-DSA (FIPS 204), hybride PQC voor back-up en sleutelsynchronisatie	Firmware-upgrade voor bestaande Luna-hardware, geen externe functionaliteitsmodule nodig.	Validatie volgens FIPS 140-3 niveau 3 is naar verluidt in uitvoering bij publicatie.
Thales Trusted Cyber ​​Technologies Luna T-serie (firmware 7.15.1, certificaat 5450)	ML-DSA, ML-KEM, LMS, de volledige CNSA 2.0 PQC-set	In de VS geproduceerde Luna PCIe HSM, Luna Network HSM, Luna as a Service, CipherTrust Manager	FIPS 140-3 Niveau 3 gevalideerd vanaf augustus 2026, de eerste HSM-lijn die alle CNSA 2.0 PQC-algoritmen combineert in één FIPS 140-3-validatie.
Thales Luna 8 (aangekondigd augustus 2026)	Klassieke en post-kwantumalgoritmen op een op maat gemaakte cryptografische processor.	Nieuwe hardwaregeneratie, speciaal ontworpen voor PQC- en AI-tijdperk-workloads.	De beoordeling volgens FIPS 140-3 niveau 3 en de Common Criteria is in uitvoering en nog niet afgerond op het moment van aankondiging.
Entrust nShield (firmware 13.8.0, uitgebracht op 22 augustus 2025)	ML-DSA, ML-KEM, SLH-DSA, alle drie NIST CAVP gevalideerd	Ondersteuning voor native firmware, aangekondigd met NIST CAVP-validatie op 10 september 2025.	Validatie van CAVP op algoritmeniveau bevestigd; controleer de huidige FIPS 140-3-status op moduleniveau vóór de aanschaf.
Utimaco u.trust GP HSM (Se-serie en CSe-serie)	ML-DSA (FIPS 204), ML-KEM (FIPS 203), LMS, met SLH-DSA op de roadmap.	Quantum Protect-applicatiepakket, geactiveerd op bestaande hardware, geen hardwarevervanging nodig.	Validatie van CAVP op algoritmeniveau bevestigd voor verzendalgoritmen; inclusief een eigen ontwerp voor statusbeheer voor LMS en XMSS in HA- en back-upscenario's.

Twee zaken verdienen hier nadere toelichting. Ten eerste zijn algoritmevalidatie en modulevalidatie niet hetzelfde, en het is een veelgemaakte fout om een ​​CAVP-aankondiging van een leverancier te beschouwen als bewijs dat een specifiek HSM-apparaat volledig FIPS 140-3-gevalideerd is met PQC binnen de gestelde kaders. Encryption Consulting behandelt dit onderscheid in detail in " Zijn uw HSM's PQC-klaar?" . Ten tweede is de ondersteuning voor SLH-DSA (FIPS 205) echt ongelijk verdeeld: Entrust heeft het gevalideerd, Utimaco vermeldt het als onderdeel van de roadmap, en de Thales-bronnen die voor deze update zijn geraadpleegd, bevestigen het niet in de firmware die wordt geleverd. Als uw PQC-roadmap specifiek afhankelijk is van SLH-DSA, bijvoorbeeld als een conservatieve hash-gebaseerde fallback voor langlevende ondertekeningssleutels, controleer dan de huidige status van de leverancier rechtstreeks voordat u zich aan een platform verbindt.

Wat is crypto-flexibiliteit op hardwareniveau en waarom is het belangrijk?

Cryptografische flexibiliteit op hardwareniveau betekent dat een HSM nieuwe algoritmen kan implementeren via een firmware-update en een modulaire SDK, zonder dat de fysieke hardware vervangen hoeft te worden of de applicaties die de HSM aanroepen opnieuw ontworpen hoeven te worden. De bovenstaande firmware-updates van Thales, Entrust en Utimaco zijn hiervan het praktische bewijs: alle drie voegden ML-KEM en ML-DSA toe aan hardware die klanten al bezaten, via een upgrade in plaats van een complete vervanging.

De cryptografische flexibiliteit van hardware hangt af van een aantal specifieke ontwerpkeuzes die het overwegen waard zijn bij elke beslissing over de aanschaf of vervanging van een HSM:

• Mechanisme voor firmware-updates. Kan nieuwe algoritmeondersteuning worden geleverd als een ondertekende firmware-update, en is dat updateproces zelf beschermd door een kwantumresistente handtekening, zodat het tijdens de overgang niet vervalst kan worden?
• Modulaire cryptografische providers. Is PQC-ondersteuning ingebouwd in de kernfirmware, zoals bij de Thales Luna-aanpak, of wordt het geleverd als een apart applicatiepakket, zoals bij Utimaco's Quantum Protect? Beide modellen werken, maar de implicaties voor aanschaf en licenties verschillen.
• API en afstemming op standaarden. Biedt de HSM toegang tot PQC-bewerkingen via de huidige PKCS#11-mechanisme-identificaties en leveranciers-SDK-versies die uw applicaties al aanroepen, of is hiervoor een parallelle integratie nodig?
• Ruimte voor de volgende standaard. NIST evalueert nog steeds aanvullende handtekeningschema's naast de drie oorspronkelijke FIPS-standaarden. Een flexibel HSM-platform zou een vierde algoritmefamilie moeten kunnen integreren zonder een nieuwe hardware-update.

Cryptografische flexibiliteit is een voorzorgsmaatregel, geen einddoel. Een HSM die theoretisch kan worden geüpgraded, is in de praktijk alleen flexibel als uw organisatie beschikt over het firmware-updateproces, de testomgeving en de discipline voor wijzigingsbeheer om die upgrade daadwerkelijk door te voeren voordat de algoritmen die het beschermt de zwakke schakel worden.

Hoe ziet een hybride HSM-implementatietopologie met klassieke architectuur en PQC eruit?

Vrijwel geen enkele organisatie stapt direct over van uitsluitend klassieke naar PQC-native HSM-werking. De realistische implementatietopologie draait klassieke en post-kwantumalgoritmen naast elkaar binnen hetzelfde HSM-cluster gedurende een overgangsperiode van meerdere jaren, met behulp van hybride sleuteluitwisseling en, waar de applicatie dit ondersteunt, dubbele of samengestelde handtekeningen.

Een typische hybride topologie bestaat uit drie lagen:

1. De HSM-clusterlaag. Een HSM-cluster met hoge beschikbaarheid, of het nu gaat om on-premises apparaten, HSM-instanties in de cloud of een HSM-as-a-Service De implementatie draait firmware die gelijktijdig zowel klassieke (RSA, ECC) als PQC-algoritmen (ML-KEM, ML-DSA) ondersteunt, met partitionering zodat verschillende applicatiegroepen onafhankelijk van elkaar kunnen worden gemigreerd.
2. De protocollaag. TLS-terminators en PKI-uitgiftesystemen onderhandelen over hybride sleuteluitwisseling, bijvoorbeeld X25519 in combinatie met ML-KEM-768, zodat een sessie veilig blijft, zelfs als de klassieke of de post-kwantumcomponent wordt verbroken. Certificeringsinstanties geven samengestelde of dubbele certificaten uit wanneer het clientecosysteem dit ondersteunt, en vallen terug op een klassieke sleuteluitwisseling voor clients die nog geen PQC-overeenkomst hebben.
3. De applicatielaag. Codeondertekening, databaseversleuteling en workflows voor het ondertekenen van langlopende documenten roepen de HSM het juiste algoritme aan voor elk gebruiksscenario, op basis van hoe lang de handtekening of versleutelde tekst betrouwbaar moet blijven, in plaats van elke workload op dezelfde dag over te schakelen naar PQC.

De beslissing welke laag als eerste gemigreerd moet worden, moet gebaseerd zijn op de mate van kwetsbaarheid, niet op gemak. Sleutelgeneratie die gebruikt wordt voor vertrouwelijkheid (TLS-sessiesleutels, VPN-tunnels, versleutelde back-ups) is momenteel kwetsbaar voor aanvallen waarbij gegevens nu worden onderschept en later worden gedecodeerd, omdat onderschepte versleutelde tekst achteraf kan worden gedecodeerd zodra er een cryptografisch relevante kwantumcomputer bestaat. Digitale handtekeningen die gebruikt worden voor authenticatie hebben een ander risicoprofiel: een handtekening die vandaag gevalideerd wordt, wordt niet achteraf ongeldig. Daarom kunnen ondertekeningstaken over het algemeen iets later worden uitgevoerd dan versleutelingstaken, met de belangrijke uitzondering van langlevende code- en firmware-ondertekeningssleutels, waarbij een vervalste handtekening over jaren nog steeds schadelijk zou zijn. Deze op kwetsbaarheid gebaseerde prioritering is dezelfde logica die Encryption Consulting toepast in RSA: Secure Today, Scheduled for Retirement , waarin de klassieke algoritme-kant van deze migratie wordt beschreven.

Hoe is de FIPS 140-3-grens van toepassing op PQC-gevalideerde HSM's?

De FIPS 140-3- validatie is van toepassing op een gedefinieerd cryptografisch modulegebied, niet op een algoritme in abstracte zin. Dat onderscheid is het meest misbegrepen aspect van de PQC-inkoop voor HSM's. Het Cryptographic Algorithm Validation Program (CAVP) van NIST test of een implementatie van ML-KEM of ML-DSA wiskundig correct is. Het Cryptographic Module Validation Program (CMVP) van NIST test of de gehele hardware- en firmwaremodule, inclusief de algoritme-implementatie, sleutelbeheer, fysieke sabotagebeveiliging en zelftests, als geheel voldoet aan de FIPS 140-3-vereisten. Een leverancier kan een geldig CAVP-certificaat voor ML-KEM bezitten, ruim voordat het HSM-apparaat waarop dit draait een bijgewerkt FIPS 140-3-modulecertificaat heeft dat PQC-bewerkingen binnen het gedefinieerde gebied dekt.

Deze kloof is niet hypothetisch. De firmware-update van Thales Luna in juli 2025 bevatte ondersteuning voor ML-KEM en ML-DSA, waarbij de FIPS 140-3 Level 3-validatie als 'in uitvoering' werd beschreven. Dit betekent dat de algoritmen beschikbaar waren voordat het modulecertificaat dat ze dekte, was afgerond. Pas in augustus 2026 werd de Luna T-serie van Thales Trusted Cyber ​​Technologies, met firmware 7.15.1 onder certificaat 5450, de eerste HSM-lijn waarvan is aangetoond dat deze de volledige CNSA 2.0 PQC-algoritmeset, ML-DSA, ML-KEM en LMS, combineert binnen een voltooide FIPS 140-3 Level 3-validatie. Dat is ongeveer een jaar tussen de beschikbaarheid van de algoritmen en een gevalideerde modulegrens die gereguleerde kopers daadwerkelijk in een audit kunnen aanhalen.

Voor organisaties in gereguleerde omgevingen, zoals DFARS, FedRAMP, PCI DSS of agentschappen die onder CNSA 2.0 vallen, geldt in de praktijk de regel: beschouw een aankondiging van een leverancier over een PQC-algoritme niet als gelijkwaardig aan een gevalideerde module die u in een gereguleerde omgeving kunt implementeren. Vraag specifiek welk FIPS 140-3-certificaatnummer betrekking heeft op de firmwareversie die u wilt gebruiken en bevestig dat de lijst met gevalideerde algoritmen in dat certificaat de PQC-algoritmen bevat die u wilt gebruiken, en niet alleen de oorspronkelijke klassieke algoritmen van de module.

Welke wijzigingen zijn er in de sleutelceremonie voor het genereren van PQC-sleutels?

Een PQC-sleutelceremonie volgt dezelfde bestuursstructuur als een klassieke ceremonie: dubbele controle, getuige bij de generatie van de sleutel en gedocumenteerde beheerdersrollen. De technische details binnen die ceremonie verschillen echter op manieren die niet in een script voor RSA of ECC worden weergegeven.

• Grotere sleutel- en handtekeningmaterialen. Een ML-KEM-768 publieke sleutel is ongeveer 1.2 KB groot en een ML-DSA-65 publieke sleutel met handtekening is samen enkele kilobytes, vergeleken met 32 ​​tot 64 bytes voor een ECC-sleutel van vergelijkbare sterkte. Ceremoniescripts, de planning van de capaciteit van back-upmedia en elk proces dat handmatig sleutelvingerafdrukken transcribeert of verifieert, moeten hiermee rekening houden vóór de ceremonie, niet tijdens de ceremonie zelf.
• Entropievereisten. Sleutelgeneratie op basis van een rooster verbruikt meer entropie per bewerking dan sleutelgeneratie met ECC. Controleer of de doorvoer van de hardwarematige TRNG van de HSM is gevalideerd voor de PQC-sleutelgeneratievolumes die uw ceremonieplan vereist, met name voor grootschalige sleutelgeneratie-evenementen voorafgaand aan een migratiegolf.
• Bij stateful hash-gebaseerde handtekeningen is niet alleen sleuteldiscipline nodig, maar ook statusdiscipline. LMS en XMSS, de stateful hash-gebaseerde schema's die CNSA 2.0 goedkeurt voor het ondertekenen van firmware en software, genereren een vast aantal eenmalige handtekeningbladeren per sleutel. Ceremonieprocedures moeten documenteren hoe de ondertekeningsstatus van de privésleutel wordt bijgehouden en nooit opnieuw wordt gebruikt, ook niet in back-ups of klonen van die sleutel, omdat het hergebruiken van een eenmalig handtekeningblad de veiligheidsgarantie volledig tenietdoet.
• Ceremoniescript en training voor getuigen. Getuigen en beheerders die getraind zijn in RSA- en ECC-ceremonies hebben een korte, specifieke briefing nodig over wat een verificatiestap van een PQC-ceremonie nu precies bevestigt. Het visueel vergelijken van een publieke sleutelvingerafdruk van meerdere kilobytes is immers niet hetzelfde als het vergelijken van een korte ECC-vingerafdruk.

Hoe beoordeelt u de PQC-gereedheid binnen uw HSM-organisatie?

Een gestructureerde beoordeling geeft antwoord op de vraag of elke HSM in uw omgeving momenteel PQC kan uitvoeren, of deze kan worden geüpgraded om PQC te kunnen uitvoeren, of dat deze moet worden vervangen vóór de deadline voor uw migratie. Encryption Consulting voert dit uit als een proces in vijf stappen:

1. Inventariseer elke HSM en de bijbehorende firmwareversie. Stel een complete cryptografische inventaris samen van alle apparaten, waaronder on-premises apparaten, cloud-HSM-instanties en embedded modules, inclusief opnamemodel, firmwareversie en de huidige FIPS 140-3-certificaatstatus.
2. Koppel het gebruik van algoritmen aan de zakelijke exposure. Identificeer welke HSM's de sleuteluitwisseling beschermen voor langdurig vertrouwelijke gegevens (gegevens die direct worden verzameld en later worden gedecodeerd) en welke de handtekeningen beschermen voor langdurig vertrouwde artefacten zoals root-CA's en firmware-ondertekeningssleutels, aangezien dit verschillende migratie-urgentie met zich meebrengt.
3. Bevestig de PQC-roadmap van de leverancier en de validatiestatus per model. Controleer voor elk HSM-model in het netwerk de actuele beschikbaarheid van de firmware voor ML-KEM, ML-DSA en, indien nodig, SLH-DSA of LMS/XMSS, en het FIPS 140-3-certificaat dat betrekking heeft op die firmware, en niet alleen de algemene PQC-aankondiging van de leverancier.
4. Test de hybride werking in een niet-productieomgeving. Valideer firmware-upgrades, hybride sleuteluitwisseling en de verwerking van grotere sleutels en handtekeningen aan de hand van daadwerkelijk applicatieverkeer voordat u ze in productie neemt, inclusief doorvoer en latentie onder de verwachte belasting.
5. Stel het plan op voor de gefaseerde migratie en ontmanteling. Plan upgrades op basis van blootstelling en bedrijfsrisico, markeer alle HSM's die via firmware niet aan de PQC-vereisten voldoen en vervangen moeten worden, en stel data voor buitenbedrijfstelling vast die aansluiten op uw CNSA 2.0- of interne compliance-tijdlijn.

Welke overwegingen met betrekking tot hoge beschikbaarheid en back-up gelden voor HSM's met PQC-functionaliteit?

Het ontwerp voor hoge beschikbaarheid en back-up van PQC-compatibele HSM's moet twee problemen oplossen die klassieke HSM-clustering niet had: het verplaatsen van grotere hoeveelheden sleutelmateriaal tussen clusterleden en, voor stateful hash-gebaseerde handtekeningen, het voorkomen dat een back-up of failover ooit een ondertekeningsstatus hergebruikt.

Standaard HSM-clustering repliceert sleutels over de leden, zodat een uitval van een knooppunt de ondertekenings- of decryptieprocessen niet onderbreekt. Bij ML-KEM en ML-DSA verplaatst die replicatie simpelweg meer data per sleutel, wat een kwestie van capaciteits- en bandbreedteplanning is, geen structureel probleem. LMS en XMSS vormen een lastiger geval: als een cluster overschakelt naar een back-up die niet synchroon loopt met welke eenmalige handtekeningen al zijn gebruikt, kan dezelfde handtekening twee keer worden ondertekend, wat de beveiligingsgarantie van het algoritme volledig tenietdoet. Utimaco's Quantum Protect-pakket pakt dit direct aan met wat de leverancier beschrijft als een gepatenteerde state-management-aanpak die specifiek is ontwikkeld voor HA- en back-upscenario's met stateful algoritmen. Elke leverancier of HSM-platform dat u evalueert op LMS- of XMSS-ondersteuning, moet in specifieke technische termen kunnen uitleggen hoe het hergebruik van de status voorkomt bij clusterfailover en back-upherstel, en niet alleen dat het het algoritme ondersteunt.

Ook bij back-up- en herstelprocedures zijn actuele capaciteits- en timingveronderstellingen nodig. Grotere PQC-sleutels en handtekeningen betekenen dat back-upmedia, versleutelde exportbestanden en herstelvensters voor noodherstel opnieuw moeten worden vastgesteld in plaats van te worden aangenomen dat ze overeenkomen met de afmetingen en timing uit het klassieke tijdperk.

Wat zijn de integratievoorwaarden voordat PQC op productie-HSM's kan worden ingeschakeld?

Voordat u PQC-bewerkingen inschakelt op een productie-HSM, moet u controleren of aan de volgende voorwaarden is voldaan, aangezien een ontbrekende voorwaarde een geplande upgrade in een storing verandert:

• Client SDK- en PKCS#11-providerversies. Applicaties integreren met de HSM via een clientbibliotheek en PKCS#11 of een leverancierspecifieke SDK; die bibliotheek moet een versie hebben die de nieuwe PQC-mechanisme-identificaties herkent vóór de firmware-upgrade, anders zullen aanroepen mislukken, zelfs als de HSM-firmware het algoritme ondersteunt.
• Compatibiliteit tussen PKI- en CA-software. Uw certificeringsinstantiesoftware, of deze nu lokaal (on-premises) of extern (on-premises) wordt geïnstalleerd, beheerde PKI-as-a-Service Een platform, of een integratie met een openbare CA, moet het uitgeven van certificaten op basis van PQC- of hybride openbare sleutels ondersteunen voordat die sleutels in een productieomgeving bruikbaar zijn.
• Ondersteuning bij netwerk- en protocolonderhandelingen. TLS-terminators, loadbalancers en VPN-gateways in het verkeerspad hebben TLS-stacks nodig die hybride sleuteluitwisselingsgroepen ondersteunen; een HSM die ML-KEM-sleutels kan genereren, is niet nuttig als niets in het verbindingspad deze sleutels kan onderhandelen.
• MTU- en fragmentatieverwerking. Grotere PQC-sleutels en -certificaten vergroten de omvang van TLS-handshakeberichten, waardoor handshakes op sommige netwerkpaden de MTU-limieten kunnen overschrijden en fouten in de fragmentatieafhandeling van oudere netwerkapparatuur aan het licht kunnen komen die bij handshakes van klassieke omvang nooit voorkwamen.
• Monitoring en meldingen over updates. Operationele dashboards en waarschuwingsdrempels die zijn afgestemd op de latentie van klassieke sleutelgeneratie en -ondertekening, vereisen bijgewerkte basislijnen, aangezien PQC-bewerkingen andere, doorgaans hogere, rekenkosten per bewerking met zich meebrengen.

Een cryptografisch ontdekkings- en inventarisatieplatform is de snelste manier om deze vereisten binnen een grote omgeving te bevestigen, in plaats van applicatie voor applicatie te controleren; dit is precies de lacune die CBOM Secure wil opvullen.

Op welke soorten storingen moet u zich voorbereiden?

De meeste PQC-fouten op hardwareniveau vallen in een klein aantal voorspelbare categorieën. Door hierop te anticiperen vóór de migratie, wordt de kans op een ongeplande uitval of een nalevingstekort dat tijdens een audit aan het licht komt, verkleind.

Faal modus	Waarom het gebeurt	Risicovermindering
De firmware van PQC kan niet worden bijgewerkt.	Voor HSM-hardware die het einde van zijn levenscyclus of ondersteuning heeft bereikt, wordt nooit een PQC-firmware-update van de leverancier uitgebracht.	De firmware voor voorraadbeheer zal nu niet meer worden ondersteund; budgetvriendelijke hardware-upgrade voor elk model waarvoor geen bevestigde PQC-firmware roadmap beschikbaar is.
De doorvoer en latentie nemen af ​​onder PQC-belasting.	ML-DSA-ondertekening en de verwerking van grotere sleutels vergen meer rekenkracht per bewerking dan RSA of ECC op dezelfde hardware.	Test de PQC-processen op het verwachte productievolume vóór de omschakeling; vergelijk de door de leverancier gepubliceerde prestatiecijfers met uw eigen verkeerspatronen.
Hergebruik van de status van de handtekening tijdens failover	HA-clusterleden of back-upherstelbewerkingen raken niet meer gesynchroniseerd met de LMS- of XMSS-one-time signature-status.	Gebruik HSM-platforms met gedocumenteerde en geteste garanties voor statussynchronisatie voor stateful algoritmen in HA- en back-upomgevingen.
Handshake of berichtgrootte verstoort traditionele netwerkverbindingen.	Grotere PQC-sleutels en -certificaten overschrijden de MTU- of bufferlimieten in oudere netwerkapparatuur.	Test hybride TLS-handshakes over het daadwerkelijke netwerkpad, inclusief eventuele oudere loadbalancers of middleware, voordat u de implementatie in productie neemt.
Algoritme gevalideerd, maar modulegrens niet.	De validatie van het CAVP-algoritme wordt gelijkgesteld aan een voltooid FIPS 140-3-modulecertificaat.	Controleer het specifieke FIPS 140-3-certificaatnummer en de bijbehorende lijst met gevalideerde algoritmen voor de exacte firmwareversie die is geïnstalleerd.
Incompatibiliteit van de client- of applicatiebibliotheek	De PKCS#11-provider of SDK-versie dateert van vóór de PQC-mechanisme-identificaties die de nieuwe firmware beschikbaar stelt.	Voer de upgrade en test de clientbibliotheken in een testomgeving uit vóór de firmware-upgrade, niet gelijktijdig ermee.

Beperkingen

• NIST IR 8547 is op het moment van deze update nog steeds een eerste openbaar ontwerp; de commentaarperiode sloot op 10 januari 2025 en het voorgestelde overgangsschema is nog niet definitief en kan nog veranderen.
• De ondersteuning van leveranciers voor PQC en de status van het FIPS 140-3-certificaat wijzigen regelmatig. De leveranciersgegevens in dit artikel weerspiegelen de openbaar beschikbare informatie zoals die actueel was op het moment van deze update; controleer de exacte firmwareversie en het certificaatnummer bij de leverancier vóór aanschaf of implementatie.
• De verplichte mijlpalen van CNSA 2.0 zijn rechtstreeks van toepassing op de Amerikaanse nationale veiligheidssystemen; commerciële bedrijven zijn niet gebonden aan CNSA 2.0, maar velen gebruiken het als planningsreferentie voor de selectie en timing van algoritmen.
• De prestatiecijfers voor PQC-bewerkingen variëren aanzienlijk per HSM-model, firmwareversie en werkbelasting; beschouw de algemene richtlijnen hier als een uitgangspunt voor uw eigen belastingstests, niet als een vervanging daarvan.

Wat zou Encryption Consulting aanbevelen?

Beschouw de HSM-laag als de eerste controlepost bij elke PQC-migratie, niet als de laatste. Concreet betekent dit dat u begint met een cryptografische inventarisatie in plaats van een algoritme-pilot, dat u de FIPS 140-3-modulestatus bevestigt in plaats van te vertrouwen op een CAVP-headline, en dat u de sleutelceremonie en de wijzigingen in het HA-runbook opstelt voordat er ook maar één productiesleutel wordt gegenereerd.

De PQC Advisory Services van Encryption Consulting voeren dit uit als een gestructureerd stappenplan van negen fasen, dat cryptografische ontdekking, risicogebaseerde prioritering, leveranciers- en hardware-evaluatie, hybride architectuurontwerp en gefaseerde implementatie omvat. Hierdoor migreren de hardwarelaag en de applicatielaag volgens een gecoördineerd schema in plaats van onafhankelijk van elkaar.

Wanneer de lacune specifiek in de hardware zit, evalueert ons HSM Services- team de huidige HSM-firmware en FIPS-validatiestatus aan de hand van uw PQC-vereisten, voert proof-of-concept-tests uit voor hybride en PQC-native configuraties en ontwerpt de HA- en sleutelceremoniewijzigingen die stateful algoritmen vereisen. Voor omgevingen waar het eerste probleem simpelweg is dat niet bekend is wat waar is geïmplementeerd, bouwt en onderhoudt CBOM Secure de continue cryptografische inventaris die elke volgende stap mogelijk maakt.

PQC Adviesdiensten

Bereik post-quantum paraatheid met een door experts geleide cryptografische beoordeling, migratiestrategie en praktische implementatie conform de NIST-normen.

Meer informatie

Conclusie

Algoritmen krijgen in de meeste PQC-gesprekken de meeste aandacht, maar de HSM-laag bepaalt in de praktijk of die algoritmen betrouwbaar zijn. De hardware moet PQC-sleutels genereren met echte entropie, deze opslaan binnen een gevalideerde grens, een firmware-upgrade doorstaan ​​die gelijke tred houdt met een evoluerende standaard, en HA- en back-upprocedures ondersteunen die voldoen aan de specifieke eisen die stateful signature-schema's stellen. Thales, Entrust en Utimaco hebben het afgelopen jaar het grootste deel van de kloof in algoritmeondersteuning gedicht, en de eerste FIPS 140-3 gevalideerde modules die de volledige CNSA 2.0 PQC-suite combineren, verschijnen in 2026. Wat overblijft is operationeel: het inventariseren van uw HSM-omgeving, het bevestigen van validatie op moduleniveau in plaats van aankondigingen op algoritmeniveau, en het opnieuw opbouwen van sleutelceremonie- en HA-runbooks rond grotere sleutels en, waar relevant, eenmalige handtekeningstatus. Organisaties die de hardwarelaag als uitgangspunt nemen bij de PQC-migratie, in plaats van deze pas achteraf aan de applicatielaag toe te voegen, zullen er klaar voor zijn wanneer de voor hen belangrijke deadlines daadwerkelijk aanbreken.

Veelgestelde Vragen / FAQ

Hebben we nieuwe HSM-hardware nodig ter ondersteuning van PQC, of ​​is een firmware-upgrade voldoende? Voor de meeste HSM's van de huidige generatie is een firmware-upgrade voldoende. Thales, Entrust en Utimaco hebben allemaal ML-KEM- en ML-DSA-ondersteuning toegevoegd aan bestaande hardware via firmware-updates. Oudere of verouderde HSM-modellen die nooit een PQC-firmware-update zullen ontvangen, vormen hierop een uitzondering. Deze modellen moeten nu worden geïdentificeerd en de vervanging ervan moet in het budget worden opgenomen.

Is de aankondiging van een PQC-algoritme door een leverancier hetzelfde als een FIPS 140-3-gevalideerde PQC-compatibele module? Nee. Algoritmevalidatie via het CAVP-programma van NIST en modulevalidatie via CMVP zijn aparte processen, en een periode van ongeveer een jaar tussen beide is gebruikelijk bij de huidige generatie PQC-firmware-releases. Controleer het specifieke FIPS 140-3-certificaatnummer dat betrekking heeft op de firmwareversie die u wilt implementeren.

Welk PQC-algoritme moet onze HSM als eerste ondersteunen, ML-KEM of ML-DSA? Prioriteer op basis van kwetsbaarheid, niet op voorkeur. ML-KEM beschermt sleuteluitwisseling, die momenteel kwetsbaar is voor aanvallen waarbij gegevens nu worden verzameld en later worden gedecodeerd. Deze aanvallen kunnen worden uitgevoerd op al het verkeer dat nu wordt onderschept en gedecodeerd zodra een cryptografisch relevante kwantumcomputer beschikbaar is. ML-DSA beschermt digitale handtekeningen, waarbij de kwetsbaarheid voor de meeste toepassingen later ontstaat, met uitzondering van lang bestaande codes en firmware-ondertekeningssleutels. Deze moeten met dezelfde urgentie worden behandeld als sleuteluitwisseling.

Vereisen LMS en XMSS een andere operationele aanpak dan ML-DSA? Ja. LMS en XMSS zijn stateful hash-gebaseerde ondertekeningsschema's met een vast aantal eenmalige ondertekeningsbladeren per sleutel; het hergebruiken van een blad, wat kan gebeuren tijdens een slecht beheerde HA-failover of back-upherstel, ondermijnt de beveiligingsgarantie. ML-DSA en ML-KEM kennen deze vereiste voor statusbeheer niet.

Hoeveel groter zijn PQC-sleutels en -handtekeningen in de praktijk dan RSA- of ECC-sleutels? Een ML-KEM-768-publieke sleutel is ongeveer 1.2 KB, vergeleken met ongeveer 32 tot 64 bytes voor een ECC-sleutel met een vergelijkbare sterkte. ML-DSA-publieke sleutels en -handtekeningen samen zijn slechts enkele kilobytes groot. Houd hier rekening mee bij het bepalen van de capaciteit van back-upmedia, de maximale grootte van certificaten en handshakes, en eventuele ceremoniële processen waarbij sleutelmateriaal handmatig wordt geverifieerd.

Referenties

• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, Module-Lattice-Based Digital Signature Standard: https://csrc.nist.gov/pubs/fips/204/final
• NIST FIPS 205, Stateless Hash-Based Digital Signature Standard: https://csrc.nist.gov/pubs/fips/205/final
• NIST IR 8547 (eerste openbare conceptversie, november 2024), Overgang naar post-kwantumcryptografiestandaarden: https://csrc.nist.gov/pubs/ir/8547/ipd
• NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) richtlijnen: https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
• Thales, Luna HSM v7.9 levert PQC-gereedheid op grote schaal: https://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
• Thales Trusted Cyber ​​Technologies, in de VS geproduceerde post-kwantum HSM behaalt FIPS 140-3 niveau 3: https://www.thalestct.com/hsm-fips140-3-validation/
• Thales Group, Thales bouwt cryptografische beveiliging voor het tijdperk van AI en post-kwantumcomputing (Luna 8): https://www.thalesgroup.com/en/news-centre/press-releases/thales-builds-cryptographic-security-age-ai-and-post-quantum-computing
• Entrust en nShield HSM's: Post-kwantumcryptografie-algoritmen ontvangen validatie van het NIST Cryptographic Algorithm Validation Program. https://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
• Utimaco, De deadline van 2029 na het kwantumtijdperk: kunnen uw HSM's de migratie aan? https://utimaco.com/news/blog-posts/post-quantum-hsm-migration-2029