Een PQC IPsec VPN kwantumbestendig maken betekent dat de sleuteluitwisseling en authenticatie in IKEv2/IPsec-tunnels worden vervangen of aangevuld met post-kwantumcryptografische algoritmen, zodat versleuteld verkeer ook na de komst van cryptografisch relevante kwantumcomputers vertrouwelijk blijft. Voor overheidsorganisaties, advocatenkantoren en andere gereguleerde sectoren is dit geen theoretisch vraagstuk meer.
Waarom IKEv2/IPsec nu al een risico vormt
De kern van het probleem is de zogenoemde harvest-now-decrypt-later-aanval: een tegenstander onderschept en bewaart vandaag versleuteld VPN-verkeer, met de bedoeling het te ontsleutelen zodra een kwantumcomputer daartoe in staat is.
IKEv2/IPsec (gestandaardiseerd in RFC 7296) maakt voor de sleuteluitwisseling gebruik van ECDH of Diffie-Hellman-varianten. Deze algoritmen zijn mathematisch kwetsbaar voor het Shor-algoritme op een kwantumcomputer. De encryptie van de tunnel zelf (AES) blijft vooralsnog buiten gevaar, maar de sessiesleutels die via de IKE-handshake worden uitgewisseld, zijn dat niet. Wie die handshake vandaag opneemt, kan de sessiesleutels later terugrekenen en het volledige tunnelverkeer ontsleutelen, inclusief VPN-sessies uit het verleden.
Langlopende site-to-site VPN-tunnels, bijvoorbeeld tussen datacenters of tussen een gemeente en haar cloudomgeving, zijn extra kwetsbaar. De gegevens die daarin worden getransporteerd, zoals persoonsgegevens, juridische dossiers of overheidscommunicatie, hebben een vertrouwelijkheidshorizon die jaren of decennia overspant. Precies die horizon maakt harvest-now-decrypt-later relevant.
“Organisaties moeten ervan uitgaan dat tegenstanders vandaag al versleuteld verkeer opslaan met de intentie het later te ontsleutelen zodra kwantumcomputers beschikbaar zijn. De urgentie is nu, niet over vijf jaar.” (Dustin Moody, wiskundige en PQC-projectleider bij NIST)
Beschikbare NIST PQC-algoritmen voor VPN
NIST heeft in augustus 2024 drie definitieve standaarden gepubliceerd die direct toepasbaar zijn op VPN-infrastructuur.
| Algoritme | Standaard | Toepassing in IKEv2 | Beschikbaar in |
|---|---|---|---|
| ML-KEM | FIPS 203 | Sleuteluitwisseling (vervangt ECDH) | strongSwan 6.0, Cisco IOS-XE (2024), OpenIKEv2 |
| ML-DSA | FIPS 204 | Authenticatie (vervangt ECDSA/RSA in certificaten) | strongSwan 6.0 (via liboqs), OpenSSL 3.x (experimenteel) |
| SLH-DSA | FIPS 205 | Alternatieve handtekening (stateless hash-based) | Beperkt, voornamelijk bibliotheekondersteuning |
ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) is het primaire algoritme voor sleuteluitwisseling in VPN-context. ML-DSA (Module-Lattice-Based Digital Signature Algorithm) vervangt de digitale handtekeningen die in IKEv2 worden gebruikt voor wederzijdse authenticatie van VPN-eindpunten.
NIST SP 1800-38B, de praktijkgids voor PQC-migratie van TLS, SSH en IPsec, beschrijft concrete configuratiepaden en testprofielen voor IKEv2-implementaties. De BSI onderschrijft vergelijkbare aanbevelingen in TR-02102-3, specifiek gericht op IPsec, en stelt dat klassieke ECDH-methoden op termijn niet langer toereikend zijn.
“Voor IPsec-verbindingen geldt dat de keuze van sleuteluitwisselingsmechanisme bepalend is voor de langetermijnvertrouwelijkheid; het gebruik van klassieke ECDH-methoden is op termijn niet langer voldoende.” (BSI, Bundesamt für Sicherheit in der Informationstechnik, TR-02102-3)
Hybride IKEv2-handshake: werking en configuratierisico’s
De meest hanteerbare overgangsroute is een hybride handshake, waarbij ML-KEM en klassieke ECDH gelijktijdig worden uitgevoerd en de resulterende sessiesleutels worden gecombineerd.
Technisch werkt dit via aanvullende IKEv2 Key Exchange-payloads, gedefinieerd in RFC-9370 (Multiple Key Exchanges in IKEv2). strongSwan ondersteunt dit mechanisme vanaf versie 6.0 via de liboqs-koppeling. De tunnel is veilig zolang ten minste één van beide algoritmen niet gecompromitteerd is: als de kwantumcomputer ECDH breekt maar ML-KEM intact is, blijft de sessiesleutel vertrouwelijk.
Naast downgrade-aanvallen is ook rollback een aandachtspunt: als een firmware-update of configuratiewijziging aan één kant van de tunnel de PQC-algoritmen verwijdert of uitschakelt, valt de verbinding terug op klassiek ECDH zonder dat beheerders dit direct opmerken. Monitoring van de IKE-SA-parameters via SNMP of syslog is daarom essentieel.
Prestatieoverhead op bestaande hardware
ML-KEM introduceert grotere publieke sleutels en encapsulatieboodschappen dan klassiek ECDH. ML-KEM-768 genereert encapsulatieboodschappen van circa 1.088 bytes; een klassieke ECDH P-256 uitwisseling produceert slechts 65 bytes. Dit heeft gevolgen voor organisaties met beperkte WAN-bandbreedte of verouderde hardware.
| Parameter | ECDH P-256 | ML-KEM-768 | Impact |
|---|---|---|---|
| Publieke sleutel (bytes) | 65 | 1.184 | Grotere IKE-berichten, risico op fragmentatie |
| Ciphertext (bytes) | 65 | 1.088 | Extra bandbreedte bij handshake |
| CPU-belasting handshake | Laag | Laag tot matig | Beperkt op moderne hardware |
| Hardware-acceleratie | Breed beschikbaar | Beperkt beschikbaar | Legacy appliances kwetsbaar voor latentie |
Op moderne x86-64 hardware is de CPU-overhead van ML-KEM verwaarloosbaar: de rekencomplexiteit is lager dan bij klassieke RSA-sleutelwisseling. De grotere berichtomvang is echter wel een aandachtspunt voor organisaties die via MPLS-lijnen met lage MTU-instellingen werken, omdat IKEv2-berichten dan gefragmenteerd kunnen raken. IKEv2-fragmentatie (RFC 7383) is de aangewezen oplossing, maar vereist ondersteuning aan beide kanten van de tunnel. Op oudere UTM-appliances zonder hardware-acceleratie voor latticecryptografie verdient het aanbeveling eerst te testen in een geïsoleerde omgeving voordat productietunnels worden gemigreerd.
Aansluiting op NIS-2, DORA en BIO2
PQC-VPN-migratie is geen vrijblijvende best practice. Europese regelgeving legt concrete verplichtingen op die encryptie als technische maatregel uitdrukkelijk noemen.
NIS-2 artikel 21 lid 2 sub h verplicht essentiële en belangrijke entiteiten, waaronder overheidsorganisaties, aanbieders van digitale infrastructuur en zorgverleners, tot het toepassen van encryptie als onderdeel van hun risicobeheermaatregelen. De Europese toezichthouders verwachten dat “passende encryptie” meegaat met de stand van de techniek. Nu NIST FIPS 203 en 204 zijn gepubliceerd, verschuift de norm.
DORA (Digital Operational Resilience Act), van toepassing op financiële instellingen vanaf januari 2025, stelt eisen aan de netwerkveiligheid en ICT-risicobeheer die functioneel equivalent zijn aan NIS-2 op het punt van encryptie en toegangsbeveiliging. Kwetsbare VPN-verbindingen vallen onder de risicocategorieën die DORA beheersbaar wil maken.
De Nederlandse Baseline Informatiebeveiliging Overheid versie 2 (BIO2) vertaalt NIS-2-verplichtingen naar concrete controls voor overheidsnetwerken. BIO2 verwijst voor cryptografische implementaties naar de actuele BSI-aanbevelingen en naar NIST-standaarden. Organisaties die BIO2-compliant willen zijn, kunnen een “legacy ECDH-only” IKEv2-configuratie niet langer als voldoende aanmerken zodra ML-KEM breed beschikbaar is in hun platform.
Migratievolgorde zonder operationele onderbreking
Een geordende aanpak voorkomt dat de overgang naar PQC leidt tot onbereikbare tunnels of configuratiefouten in productie. De aanbevolen volgorde onderscheidt twee tracksen: remote access VPN (medewerkers thuis) en site-to-site VPN (datacenterverbindingen).
Fase 1: inventarisatie en platformcontrole
Stel vast welke VPN-platformen in gebruik zijn en welke versies draaien. Controleer of strongSwan al versie 6.0 heeft, of Cisco IOS-XE de PQC-update bevat, en of firewalls IKEv2-fragmentatie ondersteunen. Breng ook de certificaatinfrastructuur in kaart: ML-DSA vereist een CA die post-kwantum certificaten kan uitgeven, wat in veel organisaties een aparte PKI-vernieuwing vergt.
Fase 2: pilotomgeving met hybride configuratie
Implementeer hybride IKEv2 (ECDH plus ML-KEM) in een geïsoleerde omgeving met representatieve hardware. Meet de handshake-tijden, MTU-gedrag en foutmeldingen bij fragmentatie. Valideer dat downgrade-aanvallen geblokkeerd worden door de proposal-configuratie. Documenteer de testresultaten voor de auditlog die NIS-2 toezichthouders kunnen opvragen.
Fase 3: remote access VPN als eerste productiegroep
Remote access clients bieden de meeste flexibiliteit: software-VPN-clients worden via push-update bijgewerkt, zonder fysieke toegang tot hardware. Begin met een vrijwillige groep medewerkers of een specifieke afdeling. Controleer na twee weken de logging op IKE-SA-parameters om te bevestigen dat ML-KEM actief is, niet alleen geconfigureerd.
Fase 4: site-to-site VPN per verbinding
Migreer datacenterverbindingen per tunnel, te beginnen met tunnels met de langste vertrouwelijkheidshorizon, zoals verbindingen met archiefopslag of juridische systemen. Houd klassieke ECDH tijdelijk als fallback totdat beide kanten de PQC-configuratie stabiel hebben gedraaid, en verwijder de fallback daarna expliciet uit de proposal-set.
Fase 5: certificaatmigratie naar ML-DSA
Sleuteluitwisseling (ML-KEM) en authenticatie (ML-DSA) zijn gescheiden stappen. Authenticatie via ML-DSA-certificaten vergt een vernieuwd PKI-traject en is technisch complexer dan de sleuteluitwisselingsmigratie. Plan deze fase nadat de sleuteluitwisseling stabiel draait, en stem de certificaatlooptijden af op de verwachte beschikbaarheid van kwantumcomputers.
Veelgestelde vragen
Moet een organisatie direct al haar VPN-verbindingen vervangen om kwantumbestendig te worden?
Nee. Een hybride aanpak, waarbij ML-KEM naast klassieke ECDH wordt ingezet in dezelfde IKEv2-handshake, maakt een gefaseerde overgang mogelijk zonder bestaande verbindingen te verbreken. Vervanging kan per segment worden doorgevoerd, waarbij de volgorde wordt bepaald door de gevoeligheid en de vertrouwelijkheidshorizon van de gegevens in elke tunnel.
Werkt PQC-VPN ook op bestaande hardware zoals oudere firewalls of UTM-appliances?
Dat hangt af van de verwerkingscapaciteit en het besturingssysteem van het apparaat. ML-KEM introduceert grotere sleutels en berichten, wat extra bandbreedte en soms extra CPU vergt. Op legacy hardware zonder ondersteuning voor IKEv2-fragmentatie kan dit leiden tot verbindingsproblemen. Een laboratoriumtest met representatief verkeer is altijd noodzakelijk voor productie-inzet.
Is strongSwan geschikt voor productieomgevingen in de publieke sector?
Ja. strongSwan is een volwassen open-sourceplatform dat breed wordt ingezet in overheidsnetwerken en kritieke infrastructuur. Vanaf versie 6.0 biedt het native ML-KEM-ondersteuning via de liboqs-koppeling. De BSI verwijst in TR-02102-3 naar IKEv2-implementaties die voldoen aan de cryptografische aanbevelingen voor gebruik in overheidsnetwerken, en strongSwan valt binnen die categorie mits correct geconfigureerd.
Wat is een downgrade-aanval in hybride PQC-IKEv2 en hoe voorkom je die?
Bij een downgrade-aanval manipuleert een actieve aanvaller de IKEv2-onderhandeling zo dat beide partijen terugvallen op alleen klassieke ECDH, waardoor de PQC-laag omzeild wordt. De mitigatie is technisch eenvoudig: stel in de IKEv2-proposal aan beide kanten in dat ML-KEM verplicht is en sta geen voorstel zonder PQC-algoritme toe. Monitor actief of de SA-parameters na elke heronderhandeling daadwerkelijk ML-KEM bevatten.
Welke regelgeving verplicht Europese organisaties nu al tot actie?
NIS-2 artikel 21 lid 2 sub h verplicht essentiële en belangrijke entiteiten tot passende encryptie als beveiligingsmaatregel. DORA stelt vergelijkbare eisen aan financiële instellingen. De Nederlandse BIO2-baseline voor overheidsorganisaties sluit op beide regelingen aan. Geen van deze kaders noemt PQC expliciet bij naam, maar toezichthouders hanteren het criterium “stand van de techniek”. Nu FIPS 203 en 204 definitief zijn, vormt een alleen-ECDH configuratie een aanwijsbaar risico bij toezichtonderzoek.
