Post-kwantumcryptografie (PQC) omvat een reeks wiskundige algoritmen die bestand zijn tegen aanvallen door kwantumcomputers, in tegenstelling tot de huidige RSA- en ECC-gebaseerde standaarden. Voor Europese organisaties die gevoelige data soeverein on-premise beheren, is het geen abstracte toekomstvraag maar een concrete hardwareplanning.
Wat PQC-algoritmen van uw server vragen
ML-KEM (FIPS 203) en ML-DSA (FIPS 204) zijn fundamenteel anders opgebouwd dan RSA of ECDH, en die wiskundige complexiteit vertaalt zich direct naar hogere eisen aan rekenkracht en geheugen.
RSA-2048-encryptie is geoptimaliseerd voor modulaire exponentiatie, een bewerking die efficiënt door speciale hardwareversnellers wordt afgehandeld. ML-KEM en ML-DSA zijn gebaseerd op roosterproblematiek (lattice-based cryptography), waarvoor die bestaande coprocessors niet zijn ontworpen. Op een standaard x86-64 processor met AVX2-instructieset vergt een ML-KEM-768 sleuteluitwisseling op softwareniveau ongeveer 4 tot 6 keer meer CPU-cycli dan een vergelijkbare ECDH P-256-operatie, aldus benchmarks gepubliceerd door de ETSI Quantum Safe Cryptography werkgroep in ETSI GR QSC 006 (2023).
Voor het geheugen geldt een vergelijkbaar beeld. Waar ECDH P-256-sleutelmateriaal enkele tientallen bytes beslaat, heeft ML-KEM-768 een publieke sleutel van 1184 bytes en een geencapsuleerde sleutel van 1088 bytes nodig. ML-DSA-65 (FIPS 204) gaat verder: de publieke sleutel bedraagt 1952 bytes en een handtekening 3293 bytes, vergeleken met respectievelijk 64 en 64 bytes voor ECDSA P-256. Dit zijn gestandaardiseerde waarden uit NIST FIPS 204, gepubliceerd in augustus 2024.
Voor opslagcapaciteit zijn de gevolgen beperkt op serverniveau, maar certificaatarchieven en sleutelopslag groeien wel merkbaar. Een PKI-infrastructuur met SLH-DSA (FIPS 205, hashgebaseerde handtekeningen) genereert handtekeningen van meerdere kilobytes per certificaat, wat bij grote deployments van smartcards of apparaatcertificaten schaalbaar opslagbeheer vereist.
Bandbreedte en latency in TLS en VPN
De toegenomen sleutel- en handtekeningformaten hebben directe gevolgen voor het netwerk, in het bijzonder voor TLS-handshakes en site-to-site VPN-verbindingen binnen soevereine organisatienetwerken.
Een standaard ethernet-frame heeft een MTU van 1500 bytes. Een TLS 1.3-handshake met ML-DSA-65 kan de omvang van een enkel certificaatbericht laten uitstijgen tot ruim boven die grens, wat leidt tot fragmentatie op IP-niveau. Fragmentatie verhoogt latency, verhoogt de kans op hertrasmissies en belast routers en firewalls zwaarder. In een WAN-omgeving met honderden VPN-tunnels is dit een realistisch prestatieknelpunt dat vraagt om aanpassing van MSS-clamp-instellingen en vergroting van socketbuffers.
Voor IKEv2-gebaseerde VPN-verbindingen geldt een vergelijkbaar probleem: de initiële uitwisseling van Diffie-Hellman-parameters wordt bij hybride PQC-sleuteluitwisseling (klassiek ECDH gecombineerd met ML-KEM) aanzienlijk groter. Organisaties die nu al starten met hybride modi kunnen prestatieverlies in gedeeltelijk beperken door sessiontickets en TLS-sessiehervatting te gebruiken, zodat de zware handshake minder frequent plaatsvindt.
HSM’s en TPM 2.0: wat is nu al beschikbaar?
Hardwarebeveiligingsmodules (HSM’s) zijn de hoeksteen van soeverein sleutelbeheer. Twee Europese leveranciers zijn relevant voor organisaties die PQC-ondersteuning zoeken zonder afhankelijkheid van Amerikaanse of Chinese hardware.
| Leverancier | Product | Herkomst | PQC-status | FIPS 140-3 |
|---|---|---|---|---|
| Thales | Luna Network HSM 7 | Frans-Canadees | Experimentele PQC-firmware beschikbaar | Level 3 gecertificeerd |
| Utimaco | SecurityServer Se Series | Duits | PQC-algoritmen in roadmap, SDK beschikbaar | Level 3 gecertificeerd |
Beide leveranciers bieden firmware-updatepaden die PQC-algoritmen in bestaande HSM-hardware introduceren zonder vervanging van het volledige apparaat. Volledige FIPS 140-3-certificering voor PQC-operaties is echter nog in behandeling bij het NIST Cryptographic Module Validation Program (CMVP). Organisaties moeten de actuele CMVP-lijst raadplegen via www.nist.gov voor de meest recente validatiestatus.
TPM 2.0-chips die momenteel in servers en werkstations zijn ingebouwd, ondersteunen nog geen native PQC-algoritmen. De Trusted Computing Group werkt aan een uitbreiding van de TPM-specificatie, maar chips die deze uitbreiding implementeren zijn naar verwachting pas later in dit decennium breed beschikbaar. Tot die tijd functioneert TPM 2.0 als een aanvullende integriteitslaag voor platform-attestation, terwijl PQC-sleutelbeheer via een apart HSM loopt.
Zoals NIST-projectleider Dustin Moody stelt: “Organizations should not wait for quantum computers to become a reality before starting their migration. The time to act is now, because cryptographic transitions take years.” Dit geldt ook voor de HSM-aanschaf: door nu apparaten te kiezen met firmware-upgradepaden, vermijden organisaties vroegtijdige vervanging van duur hardwaremateriaal.
Een gefaseerde hardware-upgradekalender
NIST schat dat organisaties die nu beginnen met migreren gemiddeld 5 tot 10 jaar nodig hebben om hun volledige cryptografische inventaris te vernieuwen, afhankelijk van de complexiteit van hun omgeving (NIST PQC Migration Project, 2024). Een gefaseerde aanpak maakt het mogelijk om investeringen te spreiden over de levenscyclus van bestaande infrastructuur.
Een praktische indeling in drie fasen:
Fase 1 (nu tot 2026): inventarisatie en hybride gereedheid. Breng alle cryptografische afhankelijkheden in kaart met behulp van een cryptografische bill of materials (CBOM). Selecteer HSM’s met PQC-firmware-updatemogelijkheid. Implementeer hybride TLS (ECDH plus ML-KEM) op interne servers die regelmatig worden vervangen. Pas MTU- en bufferinstellingen aan op kernrouters en firewalls.
Fase 2 (2026 tot 2028): graduele vervanging van kritieke knooppunten. Vervang servers ouder dan 7 jaar bij reguliere hardware-refresh met modellen met ingebouwde AVX-512-ondersteuning. Migreer certificaatautoriteiten naar ML-DSA of SLH-DSA handtekeningen. Sluit VPN-gateways aan op FIPS 140-3-gecertificeerde PQC-HSM’s.
Fase 3 (2028 en verder): pure PQC en decommissioning klassieke systemen. Schakel hybride modi uit waar interoperabiliteit met legacy-systemen dat toelaat. Vernieuw IoT-apparaten en embedded controllers met PQC-capabele microcontrollers. Documenteer de volledige PQC-transitie conform NIST SP 800-38B en de eisen van NIS-2.
IoT en embedded systemen: het zwakke schakel
De ETSI Quantum Safe Cryptography werkgroep waarschuwt in ETSI GR QSC 006 expliciet: “The performance overhead of post-quantum algorithms is manageable on modern server hardware, but embedded and IoT environments require careful profiling before deployment.”
Op microcontrollers met ARM Cortex-M4 of vergelijkbare architecturen (256 KB RAM, kloksnelheid 120 MHz) is ML-DSA-handtekeningverificatie tot 100 keer trager dan op een moderne server-CPU. SLH-DSA, de hashgebaseerde variant (FIPS 205), heeft een kleiner rekenkrachtprofiel voor verificatie maar veel grotere handtekeningen, wat opslagproblemen oplevert op flash-geheugenbeperkte apparaten. ML-KEM heeft een gunstiger profiel voor sleuteluitwisseling op embedded hardware dan ML-DSA, maar vereist alsnog zorgvuldig geheugenbeheer vanwege de buffergrootten.
Voor kritieke infrastructuur, waarbij sensoren, PLC’s of medische apparatuur jaren in gebruik blijven, is het realistisch dat sommige apparaten niet kunnen worden geüpgraded naar PQC. In dat geval moeten organisaties netwerkisolatie en PQC-afsluitende gateways inzetten die de communicatie namens het apparaat encrypteren en verifiëren.
Hybride PQC versus pure PQC bij beperkte servercapaciteit
Hybride sleuteluitwisseling combineert een klassieke ECDH P-256-operatie met een ML-KEM-768-operatie en berekent de uiteindelijke sessiesleutel uit beide resultaten. Dit biedt betere achterwaartse compatibiliteit en beschermt bij een eventuele implementatiefout in het kwantumveilige deel. De rekenkracht die hiervoor nodig is, is echter ruwweg de som van beide operaties.
Voor servers met een hoog transactievolume, zoals een TLS-terminatiepunt dat tienduizenden verbindingen per seconde verwerkt, kan hybride modus een significante belasting vormen. Pure ML-KEM-768 is op moderne hardware efficiënter dan de hybride combinatie, maar vereist dat alle clients en partners ook PQC ondersteunen. Zolang de markt overstapt, is hybride modus de pragmatische keuze voor externe communicatie en pure PQC de voorkeur voor interne, volledig gecontroleerde netwerken.
Organisaties met beperkte servercapaciteit kunnen offloading naar een HSM overwegen: moderne HSM’s kunnen PQC-operaties in hardware uitvoeren, wat de CPU-belasting op de applicatieserver vermindert. Dit maakt hybride modus ook bij hoge volumes haalbaar zonder dat servers direct vervangen hoeven te worden.
FAQ
Kan mijn huidige on-premise server ML-KEM en ML-DSA draaien zonder hardware-upgrade?
In veel gevallen wel, mits de server beschikt over een moderne x86-64-processor met AVX2-instructies en voldoende RAM. De prestatie-overhead is in software acceptabel voor lage transactievolumes, maar voor hoge volumes of real-time communicatie is een HSM met PQC-ondersteuning sterk aanbevolen.
Welke Europese HSM-leveranciers ondersteunen al FIPS 140-3 en PQC?
Thales Luna HSM (Frans-Canadees) en Utimaco SecurityServer (Duits) bieden beide modellen met experimentele of vroege PQC-ondersteuning. Volledige FIPS 140-3-certificering voor PQC-algoritmen is nog in behandeling. Raadpleeg de NIST CMVP-database op www.nist.gov voor de actuele status.
Hoe groot is de impact van PQC op TLS-handshakes in een VPN-omgeving?
Grotere sleutelformaten verhogen de omvang van TLS-handshakepakketten aanzienlijk. ML-DSA-handtekeningen kunnen TLS-berichten laten uitgroeien tot buiten de standaard MTU van 1500 bytes, wat fragmentatie en extra latency veroorzaakt. Organisaties met smalband VPN-verbindingen moeten hun MTU-instellingen en buffergrootten aanpassen.
Is TPM 2.0 voldoende voor PQC-beveiliging op werkstations?
Nee. TPM 2.0-chips in de huidige generatie apparaten bieden geen native PQC-ondersteuning. Ze zijn nuttig als aanvullende integriteitslaag, maar PQC-sleutelbeheer vereist een apart PQC-capabele HSM of een software-implementatie totdat TPM-standaarden zijn uitgebreid.
Wat is het verschil in rekenkracht tussen hybride PQC-sleuteluitwisseling en pure PQC?
Hybride sleuteluitwisseling voert twee volledige operaties uit (ECDH plus ML-KEM) en verdubbelt daarmee ruwweg de CPU-belasting ten opzichte van pure ML-KEM. Voor servers met beperkte capaciteit is pure PQC efficiënter zodra volledige interoperabiliteit is bereikt. Hybride modus blijft de aanbevolen keuze tijdens de overgangsfase voor externe verbindingen.
