Nu organisaties zich voorbereiden op het uitgeven van hun eerste post-quantumcertificaten, duikt er steeds weer een praktische en verrassende vraag op: vereisen PQC -certificaten een speciale "quantumveilige" hardwarebeveiligingsmodule, of kunnen de reeds in gebruik zijnde HSM's ze gewoon aan?
Het is een terechte vraag, en het antwoord is interessanter dan een simpel ja of nee. De term 'quantumveilige HSM' duikt op in marketingmateriaal van leveranciers, checklists voor inkoop en architectuurdiscussies, vaak zonder een duidelijke definitie van wat het nu eigenlijk betekent. Sommige organisaties gaan ervan uit dat hun bestaande HSM's verouderd zijn zodra ze een PQC-certificaat gebruiken. Anderen gaan juist van het tegenovergestelde uit: dat een HSM slechts een beveiligde box is en dat de algoritmes in het certificaat er helemaal niet toe doen. Beide aannames zijn op een leerzame manier onjuist.
Deze blog legt uit wat een HSM precies doet, wat "kwantumveilig" betekent in de context van een HSM, waarom dit onderscheid belangrijk is voor de bescherming van PQC-certificaten, en wat je daadwerkelijk moet controleren voordat je ervan uitgaat dat je hardware klaar is voor gebruik.
Wat een HSM daadwerkelijk beschermt
Om de privésleutels achter PQC-certificaten te genereren, op te slaan en te gebruiken met dezelfde beveiligingsgaranties als voor klassieke sleutels, hebt u een HSM nodig die de betrokken post-kwantumalgoritmen native ondersteunt, met name ML-DSA (FIPS 204) voor handtekeningen en ML-KEM (FIPS 203) voor sleuteluitwisseling. Een HSM die deze algoritmen niet ondersteunt, kan geen PQC-sleutelbewerkingen uitvoeren binnen zijn beveiligde bereik, wat het hele doel van het gebruik van een HSM tenietdoet.
Maar de term "kwantumveilige HSM" vervult een onuitgesproken rol, en dat is waar de verwarring begint. Een HSM wordt niet "kwantumveilig" gemaakt op dezelfde manier als een algoritme kwantumresistent is. De hardware zelf is niet kwetsbaar voor een kwantumaanval. Waar het om gaat, is of de firmware en de cryptografische bibliotheek van de HSM post-kwantumalgoritmebewerkingen native, binnen de hardwaregrenzen, kunnen uitvoeren, zodat de privésleutel de beveiligde hardware nooit verlaat.
Wanneer u een certificaat of software ondertekent met een HSM, werkt het proces als volgt: de te ondertekenen gegevens, of vaker een hash ervan, worden naar de HSM gestuurd. De HSM voert de ondertekening intern uit met behulp van de privésleutel die erin is opgeslagen en stuurt alleen de handtekening terug. De privésleutel verlaat de hardware nooit. Dit is de kern van de waarde van een HSM. Het betekent dat zelfs als alle andere systemen in uw omgeving gecompromitteerd raken, de privésleutel beschermd blijft.
De FIPS 140-3-verschuiving
FIPS 140 is de Amerikaanse overheidsstandaard voor het valideren van cryptografische modules, waaronder HSM's. De validatie bevestigt dat een module goedgekeurde algoritmen correct implementeert en voldoet aan de gedefinieerde fysieke en logische beveiligingsvereisten. Decennialang was FIPS 140-2 de relevante versie. Deze werd ongeveer 25 jaar geleden geïntroduceerd en is in 2021 officieel uitgefaseerd voor nieuwe validaties. Sindsdien worden alle validaties uitgevoerd volgens FIPS 140-3.
Deze timing heeft een direct en belangrijk gevolg voor post-kwantumcryptografie: alle PQC FIPS-validaties zijn FIPS 140-3-validaties, niet FIPS 140-2. De post-kwantumalgoritmen werden in augustus 2024 door NIST gestandaardiseerd , ruim nadat FIPS 140-2 geen nieuwe validaties meer accepteerde. Het CMVP heeft zijn standaarden en tools bijgewerkt, zodat ML-KEM, ML-DSA en SLH-DSA kunnen worden opgenomen in nieuwe FIPS 140-3-inzendingen. Er is geen manier waarop een PQC-algoritme een FIPS 140-2-validatie kan verkrijgen, omdat dat programma geen nieuwe inzendingen meer accepteert.
Er is ook een deadline die de urgentie vergroot: NIST zet alle FIPS 140-2-certificaten in september 2026 over naar de historische status. Modules op de historische lijst zijn mogelijk niet langer geschikt voor nieuwe aanbestedingen in veel federale en gereguleerde contexten.
De praktische conclusie is dat een organisatie die serieus werk maakt van het verkrijgen van een PQC-certificaat, specifiek moet zoeken naar HSM's met FIPS 140-3- validatie die de relevante PQC-algoritmen omvat, of met een duidelijke, concrete routekaart naar die validatie. Verschillende leveranciers hebben hier al mijlpalen bereikt. Eind 2025 en in 2026 behaalden leveranciers zoals Crypto4A, Entrust, Idemia, Kryptus, Marvell, Securosys en Utimaco CAVP-algoritmecertificering voor ML-KEM, ML-DSA en SLH-DSA, en HSM's zoals de Entrust nShield 5, Marvell LiquidSecurity 2 en Thales Luna G7 en K7 zijn bezig met de FIPS 140-3-validatie met PQC-ondersteuning.
Technische uitdagingen van PQC-sleutels in hardware
Het implementeren van PQC in HSM's is geen eenvoudige firmware-update, en inzicht in de technische uitdagingen verklaart waarom de ondersteuning van de leverancier geleidelijk is uitgerold in plaats van in één keer.
Grotere sleutel- en handtekeningformaten belasten de hardware.
PQC-sleutels zijn aanzienlijk groter dan hun klassieke equivalenten. Een ML-DSA-privésleutel kan variëren van ongeveer 1.6 KB tot 4 KB, afhankelijk van de parameterinstellingen, vergeleken met een paar honderd bytes voor ECDSA . HSM's werken met vaste geheugen- en opslagbudgetten, en sommige modules met beperkte capaciteit hebben moeite met het grotere PQC-sleutelmateriaal. Dit is een hardwarebeperking, geen fout, maar het illustreert wel waarom niet elk HSM-model PQC even goed aankan.
Generatie van sleutels op basis van een seed brengt een compromis met zich mee.
ML-DSA en SLH-DSA ondersteunen het genereren van sleutels vanuit een compacte seed, soms zo klein als 32 tot 64 bytes, in plaats van de volledige uitgebreide privésleutel op te slaan. Dit vermindert het opslagprobleem doordat alleen de kleine seed in de HSM wordt bewaard. De keerzijde is computationeel: de volledige privésleutel moet telkens opnieuw worden afgeleid van de seed wanneer deze nodig is, wat de verwerkingskosten per bewerking verhoogt. De IETF heeft de implicaties van dit dubbele sleutelformaat, waarbij een sleutel kan worden weergegeven als een compacte seed of als een grotere uitgebreide sleutel, onderzocht, omdat het de verwerking van PKCS#12-bestanden, HSM-integratie en interoperabiliteit tussen systemen die verschillende formaten verwachten, bemoeilijkt.
Prestatieoverhead is reëel.
Post-kwantumalgoritmen vereisen meer rekenkracht dan hun klassieke equivalenten. Sleutelgeneratie met ML-KEM gebruikt ongeveer drie keer zoveel cycli als met ECDH, en ondertekening met ML-DSA vereist ongeveer vijf keer zoveel cycli als met ECDSA op vergelijkbare hardware. HSM's met een vast rekenbudget kunnen een lagere doorvoersnelheid ervaren na de migratie naar PQC. Voor grootschalige ondertekenings- of sleuteluitwisselingsprocessen moet deze impact op de doorvoersnelheid worden getest en ingecalculeerd, in plaats van zomaar te worden genegeerd.
Grote datastromen bereiken netwerklimieten
Bij het ondertekenen van grote objecten, zoals omvangrijke certificaatintrekkingslijsten, is de hoeveelheid data die via het netwerk naar een HSM kan worden verzonden vaak beperkt. Daarom is client-side hashing, waarbij alleen de hash van de data naar de HSM wordt verzonden in plaats van de volledige payload, de aanbevolen methode voor PQC-ondertekening. Dit zorgt ervoor dat de hoeveelheid data die de HSM passeert klein blijft, ongeacht de grootte van het te ondertekenen object.
Standaardisatie is nog steeds in ontwikkeling.
PKCS#11 , de standaardinterface voor HSM-bewerkingen, is nog in ontwikkeling. LMS en HSS werden gestandaardiseerd in PKCS#11 versie 3.1, terwijl ML-DSA, SLH-DSA en ML-KEM worden gestandaardiseerd in PKCS#11 versie 3.2. Verschillende REST-gebaseerde HSM's ondersteunen deze algoritmen al vóór de volledige PKCS#11-standaardisatie, maar het praktische gevolg is dat de PQC-ondersteuning aanzienlijk verschilt tussen leveranciers en zelfs tussen firmwareversies van hetzelfde product.
Beste praktijken voor PQC-sleutelbeveiliging
Hieronder volgen de werkwijzen die consistent kenmerkend zijn voor goed ontworpen PQC-certificaatimplementaties.
Bewaar PQC-privésleutels in hardware, samen met klassieke sleutels.
Het allerbelangrijkste principe is consistentie. De hardwarebeveiligingsstandaard die u toepast op klassieke certificaatsleutels moet eveneens van toepassing zijn op PQC-sleutels. Dit vereist PQC-compatibele HSM's, niet omdat de hardware kwetsbaar was, maar omdat hardwarebeveiliging hardware-native algoritmeondersteuning vereist.
Standaardiseer op hardware die is gevalideerd volgens FIPS 140-3.
Nu FIPS 140-2 de status 'historisch' heeft gekregen en alle PQC-validaties volgens FIPS 140-3 verlopen, zorgt de afstemming van de HSM-inkoop op FIPS 140-3 met ondersteuning van het PQC-algoritme ervoor dat de organisatie correct is gepositioneerd voor zowel de huidige bedrijfsvoering als de wettelijke vereisten.
Gebruik client-side hashing voor ondertekeningsbewerkingen.
Door alleen hashes naar de HSM te sturen in plaats van volledige payloads, blijft de hoeveelheid data die de grens overgaat klein. Dit is vooral belangrijk bij PQC, gezien de grotere signatures en de netwerklimieten voor HSM-communicatie.
Gebruik hybride certificaten tijdens de overgangsperiode.
De hybride aanpak is de aanbevolen overgangsroute. Zorg ervoor dat de HSM zowel het klassieke als het post-kwantumgedeelte beschermt, zodat de hybride aanpak geen softwarematig opgeslagen sleutel introduceert.
Test op productieschaal voordat u zich vastlegt.
Omdat PQC-ondersteuning verschilt per leverancier en firmwareversie, en omdat sleutelgroottes en doorvoereigenschappen aanzienlijk afwijken van klassieke algoritmen, is vroegtijdig testen op productieschaal essentieel. Valideer of bewerkingen zoals het ondertekenen van grote CRL's binnen de beperkingen van uw HSM werken voordat u erop vertrouwt.
Bouw voor crypto-wendbaarheid
Ontwerp de infrastructuur voor certificaten en digitale handtekeningen zodanig dat algoritmes kunnen worden gewijzigd zonder het hele systeem opnieuw op te bouwen. De PQC-overgang is niet de laatste cryptografische wijziging die u zult beheren, en een infrastructuur die is ontworpen voor flexibiliteit kan toekomstige wijzigingen tegen veel lagere kosten opvangen.
Hoe encryptieconsultancy kan helpen
De vraag of PQC-certificaten kwantumveilige HSM's vereisen, bevindt zich op het snijvlak van cryptografische architectuur, hardware-aanschaf en PKI-governance, precies waar het productportfolio en de adviesdiensten van Encryption Consulting op gericht zijn.
Met ons CodeSign Secure- platform, dat is gebouwd rond het eerder besproken principe dat PQC-privésleutels dezelfde hardwarematige bescherming verdienen als klassieke sleutels, kunt u ML-DSA- en SLH-DSA-ondertekeningsbewerkingen uitvoeren binnen FIPS-gevalideerde HSM's van Thales, Entrust, Utimaco en Securosys, zonder dat de privésleutel de hardwaregrens verlaat. Het platform ondersteunt LMS voor firmwareondertekening en maakt gebruik van client-side hashing, zodat alleen hashes, en niet de volledige artefacten, de HSM-grens passeren. Voor organisaties die PQC-certificaten uitgeven of gebruiken voor code- en firmwareondertekening, biedt CodeSign Secure de hardware-gealigneerde vertrouwensketen van sleutelgeneratie tot ondertekening.
CertSecure Manager is een ander platform waarmee u de certificaatlevenscyclus kunt beheren tijdens de PQC-transitie, inclusief de uitgifte en het beheer van post-quantumcertificaten. De crypto-flexibiliteit maakt het mogelijk om klassieke en post-quantumalgoritmen parallel uit te voeren tijdens de hybride implementatiefase, en het gecentraliseerde beheer zorgt ervoor dat PQC-certificaten met dezelfde nauwkeurigheid worden gevolgd, verlengd en beheerd als klassieke certificaten.
Onze adviesdiensten op het gebied van post-kwantumcryptografie helpen organisaties bij het beantwoorden van precies de architectuur- en inkoopvragen die we in deze blog hebben behandeld: welke HSM's in uw omgeving zijn geschikt voor PQC, welke hebben een firmware-upgrade of vervanging nodig, hoe structureert u een hybride certificaatimplementatie en hoe stemt u uw hardware-roadmap af op de overgang naar FIPS 140-3 en de deadline van september 2026 voor de historische status van FIPS 140-2.
Conclusie
Vereisen PQC-certificaten kwantumveilige HSM's? Het meest accurate antwoord is: PQC-certificaten vereisen HSM's die van nature post-kwantumalgoritmen ondersteunen, als u wilt dat de privésleutels achter die certificaten hardwarematig beveiligd zijn. De term "kwantumveilige HSM" is eigenlijk een verkorte aanduiding voor een HSM waarvan de firmware ML-DSA, ML-KEM en gerelateerde bewerkingen binnen de beveiligde omgeving kan uitvoeren.
De HSM-hardware was nooit kwetsbaar voor kwantumaanvallen. Wat wel veranderd is, is dat het beschermen van de privésleutel van een kwantumresistent certificaat in hardware vereist dat de hardware het algoritme van die sleutel begrijpt. Een HSM die geen ML-DSA-bewerkingen kan uitvoeren, kan een ML-DSA-sleutel niet beschermen, en een kwantumresistent certificaat waarvan de privésleutel onbeschermd in software staat, heeft een zwakke schakel die het hele doel van de migratie tenietdoet.
Bij Encryption Consulting zijn onze producten en adviesdiensten erop gericht u te helpen de juiste beslissingen te nemen, van het in kaart brengen van uw cryptografische inventaris tot het uitgeven van PQC-certificaten die worden ondersteund door hardwarematig beveiligde sleutels.
