När organisationer förbereder sig för att utfärda sina första post-kvantcertifikat dyker en praktisk och överraskande fråga upp: kräver PQC -certifikat en speciell "kvantsäker" hårdvarusäkerhetsmodul, eller kommer de HSM:er som redan är i produktion att hantera dem utan problem?
Det är en rimlig fråga, och svaret är mer intressant än ett enkelt ja eller nej. Termen "kvantsäker HSM" förekommer i leverantörsmarknadsföring, checklistor för upphandling och arkitekturdiskussioner, ofta utan en tydlig definition av vad det egentligen betyder. Vissa organisationer antar att deras befintliga HSM:er är föråldrade i samma ögonblick som de vidrör ett PQC-certifikat. Andra antar motsatsen, att en HSM bara är en säker låda och att algoritmerna inuti certifikatet inte alls berör den. Båda antagandena är felaktiga på lärorika sätt.
Den här bloggen förklarar vad en HSM faktiskt gör, vad "kvantsäker" betyder när den tillämpas på en, varför skillnaden är viktig för att skydda PQC-certifikat och vad du faktiskt bör verifiera innan du antar att din hårdvara är redo.
Vad en HSM faktiskt skyddar
För att generera, lagra och använda de privata nycklarna bakom PQC-certifikat med samma säkerhetsgarantier som du förväntar dig av klassiska nycklar, behöver du en HSM som har nativt stöd för de involverade postkvantumalgoritmerna, främst ML-DSA (FIPS 204) för signaturer och ML-KEM (FIPS 203) för nyckeletablering. En HSM som inte stöder dessa algoritmer kan inte utföra PQC-nyckeloperationer inom sin säkra gräns, vilket motverkar hela syftet med att använda en HSM från första början.
Men frasen ”kvantsäker HSM” gör en hel del outtalat arbete, och det är där förvirringen börjar. En HSM görs inte ”kvantsäker” på samma sätt som en algoritm är kvantresistent. Hårdvaran i sig är inte sårbar för kvantattacker. Det som spelar roll är om HSM:s firmware och kryptografiska bibliotek kan utföra post-kvantalgoritmoperationer direkt, inom hårdvarugränsen, så att den privata nyckeln aldrig lämnar skyddad hårdvara.
När du signerar ett certifikat eller en programvara med hjälp av en HSM fungerar operationen så här: data som ska signeras, eller mer vanligt en hash av den, skickas till HSM. HSM utför signeringsoperationen internt med hjälp av den privata nyckeln som finns inuti den och returnerar endast signaturen. Den privata nyckeln lämnar aldrig hårdvaran. Detta är hela värdet med en HSM. Det betyder att även om alla andra system i din miljö komprometteras, förblir den privata nyckeln skyddad.
FIPS 140-3-skiftet
FIPS 140 är den amerikanska regeringens standard för validering av kryptografiska moduler, inklusive HSM:er. Valideringen bekräftar att en modul korrekt implementerar godkända algoritmer och uppfyller definierade fysiska och logiska säkerhetskrav. I årtionden var FIPS 140-2 den relevanta versionen. Den introducerades för cirka 25 år sedan och togs officiellt bort från nya valideringar 2021. Varje validering sedan dess har skett mot FIPS 140-3.
Denna tidpunkt skapar en direkt och viktig konsekvens för postkvantkryptografi: alla PQC FIPS-valideringar är FIPS 140-3-valideringar, inte FIPS 140-2. Postkvantalgoritmerna standardiserades av NIST i augusti 2024, långt efter att FIPS 140-2 slutat acceptera nya valideringar. CMVP uppdaterade sina standarder och verktyg så att ML-KEM, ML-DSA och SLH-DSA kan inkluderas i nya FIPS 140-3-inlämningar. Det finns ingen väg genom vilken en PQC-algoritm får en FIPS 140-2-validering, eftersom det programmet inte längre accepterar nya inlämningar.
Det finns också en deadline som skärper brådskan: NIST flyttar alla FIPS 140-2-certifikat till historisk status i september 2026. Moduler på den historiska listan kanske inte längre är lämpliga för nya upphandlingar i många federala och reglerade sammanhang.
Den praktiska slutsatsen är att en organisation som tar PQC-certifikat på allvar bör leta specifikt efter HSM:er med FIPS 140-3 -validering som inkluderar relevanta PQC-algoritmer, eller med en tydlig, engagerad färdplan för den valideringen. Flera leverantörer har redan uppnått milstolpar här. I slutet av 2025 och in på 2026 erhöll leverantörer inklusive Crypto4A, Entrust, Idemia, Kryptus, Marvell, Securosys och Utimaco CAVP-algoritmcertifiering för ML-KEM, ML-DSA och SLH-DSA, och HSM:er inklusive Entrust nShield 5, Marvell LiquidSecurity 2 och Thales Luna G7 och K7 har gått igenom FIPS 140-3-validering med PQC-stöd.
Tekniska utmaningar med PQC-nycklar i hårdvara
Att stödja PQC i HSM:er är inte en trivial firmwareuppdatering, och att förstå de tekniska utmaningarna förklarar varför leverantörsstöd har rullats ut gradvis snarare än allt på en gång.
Större nyckel- och signaturstorlekar belastar hårdvarubegränsningar
PQC-nycklar är betydligt större än deras klassiska motsvarigheter. En privat nyckel för ML-DSA kan variera från ungefär 1.6 KB till 4 KB beroende på parameteruppsättningen, jämfört med några hundra byte för ECDSA . HSM:er arbetar med fasta minnes- och lagringsbudgetar, och vissa begränsade moduler kämpar med det större PQC-nyckelmaterialet. Detta är en hårdvarubegränsning, inte en brist, men det illustrerar varför inte alla HSM-modeller hanterar PQC lika bra.
Fröbaserad nyckelgenerering introducerar en avvägning
ML-DSA och SLH-DSA stöder generering av nycklar från ett kompakt frö, ibland så litet som 32 till 64 byte, snarare än att lagra den fullständiga expanderade privata nyckeln. Detta mildrar lagringsproblemet genom att endast det lilla fröet behålls i HSM. Avvägningen är beräkningsmässig: den fullständiga privata nyckeln måste härledas från fröet på begäran varje gång den behövs, vilket ökar bearbetningskostnaden för varje operation. IETF har arbetat igenom konsekvenserna av detta dubbla nyckelformat, där en nyckel kan representeras antingen som ett kompakt frö eller som en större expanderad nyckel, eftersom det komplicerar PKCS#12-filhantering, HSM-integration och interoperabilitet mellan system som förväntar sig olika format.
Prestandakostnader är verkliga
Postkvantalgoritmer kräver mer beräkningsresurser än deras klassiska motsvarigheter. ML-KEM-nyckelgenerering använder ungefär tre gånger fler cykler än ECDH, och ML-DSA-signering kräver ungefär fem gånger fler cykler än ECDSA på motsvarande hårdvara. HSM:er med fasta beräkningsbudgetar kan se minskat dataflöde efter migrering till PQC. För signering med hög volym eller nyckeletablering måste denna effekt på dataflödet testas och planeras snarare än antas bort.
Stora nyttolaster når nätverksgränser
Vid signering av stora objekt, såsom stora certifikatåterkallningslistor, är mängden data som kan skickas till en HSM över nätverket ofta begränsad. Det är därför klientsidig hashning, där endast hashen av data skickas till HSM snarare än hela nyttolasten, är det rekommenderade mönstret för PQC-signering. Det håller datamängden som korsar HSM-gränsen liten oavsett storleken på den artefakt som signeras.
Standardiseringen håller fortfarande på att avgöras
PKCS#11 , standardgränssnittet för HSM-operationer, håller fortfarande på att komma ikapp. LMS och HSS standardiserades i PKCS#11 version 3.1, medan ML-DSA, SLH-DSA och ML-KEM standardiseras i PKCS#11 version 3.2. Flera REST-baserade HSM:er stöder redan dessa algoritmer inför fullständig PKCS#11-standardisering, men det praktiska resultatet är att PQC-stödet varierar avsevärt mellan leverantörer och till och med mellan firmwareversioner av samma produkt.
Bästa praxis för PQC-nyckelskydd
Här är de metoder som konsekvent utmärker väl utformade PQC-certifikatdistributioner.
Förvara PQC-privata nycklar i hårdvara, tillsammans med klassiska nycklar
Den enskilt viktigaste principen är konsekvens. Den hårdvaruskyddsstandard som du tillämpar på klassiska certifikatnycklar måste gälla lika för PQC-nycklar. Detta kräver PQC-kompatibla HSM:er, inte för att hårdvaran var sårbar, utan för att hårdvaruskydd kräver hårdvarubaserade algoritmstöd.
Standardisera på FIPS 140-3-validerad hårdvara
Med FIPS 140-2 som går över till historisk status och alla PQC-valideringar är FIPS 140-3, positionerar en anpassning av HSM-upphandling till FIPS 140-3 med PQC-algoritmstöd organisationen korrekt för både nuvarande verksamheter och regulatoriska förväntningar.
Använd klientsidans hashing för signeringsåtgärder
Att endast skicka hashvärden till HSM snarare än fulla nyttolaster håller data som korsar gränsen liten, vilket är mer viktigt med PQC med tanke på de större signaturerna och nätverksbegränsningarna för HSM-kommunikation.
Använd hybridcertifikat under övergången
Hybrid är den rekommenderade övergångsvägen. Se till att HSM skyddar både den klassiska och post-kvantumhalvan, så att hybridmetoden inte introducerar en programvaruhållen nyckel.
Testa i produktionsskala innan du genomför
Eftersom PQC-stöd varierar beroende på leverantör och firmwareversion, och eftersom nyckelstorlekar och dataflödesegenskaper skiljer sig avsevärt från klassiska algoritmer, är tidig testning i produktionsskala avgörande. Validera att operationer som stor CRL-signering fungerar inom din HSM:s begränsningar innan du förlitar dig på dem.
Bygg för kryptoagilitet
Designa certifikat- och signeringsinfrastruktur så att algoritmer kan ändras utan att hela systemet behöver byggas om. PQC-övergången är inte den sista kryptografiska förändringen du kommer att hantera, och infrastruktur utformad för flexibilitet absorberar framtida förändringar till en betydligt lägre kostnad.
Hur krypteringskonsulting kan hjälpa
Frågan om huruvida PQC-certifikat kräver kvantsäkra HSM:er ligger i skärningspunkten mellan kryptografisk arkitektur, hårdvaruupphandling och PKI-styrning, vilket är just där Encryption Consultings produktportfölj och rådgivningstjänster verkar.
Med vår CodeSign Secure- plattform, som är byggd kring principen vi diskuterade, det vill säga att privata PQC-nycklar förtjänar samma hårdvaruskydd som klassiska nycklar, kan du utföra ML-DSA- och SLH-DSA-signeringsoperationer inuti FIPS-validerade HSM:er från Thales, Entrust, Utimaco och Securosys, utan att den privata nyckeln lämnar hårdvarugränsen. Den stöder LMS för firmwaresignering och använder klientsidig hashning så att endast hashkoder, inte fullständiga artefakter, korsar HSM-gränsen. För organisationer som utfärdar eller använder PQC-certifikat för kod- och firmwaresignering tillhandahåller CodeSign Secure den hårdvaruanpassade förtroendekedjan från nyckelgenerering till signatur.
CertSecure Manager är en annan plattform som hjälper dig att hantera certifikatlivscykeln genom PQC-övergången, inklusive utfärdande och hantering av post-kvantumcertifikat. Dess kryptoagilitet stöder parallellkörning av klassiska och post-kvantumalgoritmer under hybriddistributionsfasen, och dess centraliserade styrning säkerställer att PQC-certifikat spåras, förnyas och hanteras med samma noggrannhet som klassiska certifikat.
Våra rådgivningstjänster efter kvantkryptografi hjälper organisationer att svara på exakt den typ av arkitektur- och upphandlingsfrågor som vi behandlade i den här bloggen: vilka HSM:er i er miljö är PQC-kompatibla, vilka som behöver uppgraderas eller bytas ut av firmware, hur man strukturerar en hybridcertifikatdistribution och hur man anpassar er hårdvaruplan till FIPS 140-3-övergången och deadline i september 2026 för FIPS 140-2:s historiska status.
Slutsats
Så, kräver PQC-certifikat kvantsäkra HSM:er? Det mest exakta svaret är detta: PQC-certifikat kräver HSM:er som har nativt stöd för postkvantalgoritmer, om du vill att de privata nycklarna bakom dessa certifikat ska ha hårdvaruskydd. Etiketten "kvantsäker HSM" är egentligen en förkortning för en HSM vars firmware kan utföra ML-DSA, ML-KEM och relaterade operationer inom dess säkra gräns.
HSM-hårdvaran var aldrig kvantsårbar. Det som förändrats är att för att skydda ett kvantsäkert certifikats privata nyckel i hårdvaran krävs det att hårdvaran förstår nyckelns algoritm. En HSM som inte kan utföra ML-DSA-operationer kan inte skydda en ML-DSA-nyckel, och ett kvantsäkert certifikat vars privata nyckel sitter oskyddad i programvaran har en svag länk som omintetgör migreringens hela syfte.
På Encryption Consulting är våra produkter och rådgivningstjänster utformade för att hjälpa dig att fatta dessa beslut korrekt, från att upptäcka ditt kryptografiska lager till att utfärda PQC-certifikat som backas upp av hårdvaruskyddade nycklar.
