Een PQC-rollbackaanval (post-quantum cryptography downgrade attack) is een actieve aanval waarbij een tegenstander een lopende TLS 1.3-handshake manipuleert zodat server en client terugvallen op klassieke, kwantum-onveilige algoritmen, ook al ondersteunt de server officieel post-kwantumcryptografie. Het risico is geen theoretische curiositeit: het ontstaat rechtstreeks uit de hybride transitieperiode waarin organisaties zich nu bevinden.
Hoe een PQC-rollbackaanval in TLS 1.3 werkt
TLS 1.3, gedefinieerd in RFC 8446, biedt een sterkere handshake dan zijn voorgangers, maar het protocol schrijft niet dwingend voor welke cryptografische algoritmen moeten worden gebruikt. Tijdens de handshake stuurt de client een lijst van ondersteunde sleuteluitwisselingsmechanismen en handtekeningalgoritmen. De server kiest de beste optie die zij allebei begrijpen.
Wanneer een server zowel klassieke certificaten (RSA of ECDSA) als post-kwantumcertificaten op basis van NIST FIPS 204 (ML-DSA) aanbiedt, is er een fundamenteel probleem: een actieve aanvaller op het pad tussen client en server kan de PQC-extensies of de ondersteunde algoritmenlijst verwijderen of aanpassen. De server, die geen bewijs heeft dat de client PQC daadwerkelijk ondersteunt, valt terug op het klassieke algoritme. Het resultaat is een verbinding die kwantum-kwetsbaar is, terwijl beide partijen veronderstellen veilig te communiceren.
Uit het ENISA Threat Landscape 2023 blijkt dat “harvest now, decrypt later”-aanvallen, waarbij versleuteld verkeer nu wordt onderschept en later met een kwantumcomputer wordt ontsleuteld, als een reëel en groeiend risico voor overheden en financiële instellingen worden beschouwd. Een rollbackaanval verergert dit scenario: het afgedwongen klassieke verkeer is direct kwetsbaar voor toekomstige ontsleuteling.
PQC Continuity als bescherming: het IETF-mechanisme
Het IETF-draft draft-sheffer-tls-pqc-continuity-02 introduceert een mechanisme dat conceptueel verwant is aan HSTS (HTTP Strict Transport Security), maar op het niveau van cryptografische algoritmekeuze werkt in plaats van protocolkeuze.
Het kernidee is een “PQC commitment” dat een server aan een client communiceert. Zodra een client een succesvolle TLS-verbinding heeft opgebouwd met PQC-bescherming, slaat hij dit commitment op. Bij een volgende verbinding met dezelfde server weigert de client elke handshake die geen PQC-algoritme bevat, net zoals een browser na een HSTS-header weigert om via onversleuteld HTTP te verbinden.
Auteur Yaron Sheffer formuleert het risico als volgt:
“The existence of a hybrid or dual-certificate mode creates a downgrade surface that did not exist when only classical certificates were deployed. An attacker who can interfere with the handshake can systematically strip PQC extensions.” (Yaron Sheffer, auteur van IETF draft-sheffer-tls-pqc-continuity-02, Principal Engineer bij Intuit)
De vergelijking met HSTS is instructief maar niet volledig. HSTS werkt via een HTTP-header en heeft een rijpe browserimplementatie. PQC Continuity vereist aanpassingen op TLS-stackniveau, zowel bij clients als bij servers. Op het moment van schrijven is het draft nog niet tot RFC verheven, wat betekent dat implementaties experimenteel zijn en interoperabiliteitstests nog lopen.
Dual-certificate versus composite certificates: operationele gevolgen voor een soevereine PKI
Organisaties die nu al een eigen, soevereine PKI-infrastructuur beheren, staan voor een concrete keuze: hoe rollen zij post-kwantumcertificaten uit naast bestaande klassieke certificaten?
De dual-certificate strategie
Bij de aanpak beschreven in IETF draft-yusef-tls-pqt-dual-certs-03 beheert een server twee afzonderlijke certificaatketens: één gebaseerd op een klassiek algoritme en één gebaseerd op een post-kwantumalgoritme. De client selecteert welk certificaat hij accepteert op basis van zijn capaciteiten. Dit is operationeel flexibel, maar vergroot precies het aanvalsoppervlak waarover PQC Continuity gaat: een aanvaller kan de PQC-keten “wegmanipuleren” en de server dwingen de klassieke keten te presenteren.
Voor PKI-beheerders betekent dit ook dubbele beheerlast: afzonderlijke certificaatverlenging, afzonderlijke revocatie via OCSP of CRL, en afzonderlijke monitoring van verloopdata.
De composite-certificaatstrategie
De IETF LAMPS Working Group werkt aan een alternatief waarbij één enkel X.509-certificaat meerdere handtekeningen bevat: een klassieke (ECDSA of RSA) en een post-kwantum (ML-DSA). De LAMPS Working Group beschrijft de voordelen als volgt:
“Composite certificates allow a single certificate to carry both a classical and a post-quantum signature, reducing the attack surface compared to dual-certificate approaches while maintaining backward compatibility for clients that only understand one algorithm.” (IETF LAMPS Working Group)
Een aanvaller kan bij composite certificates niet meer één algoritme isoleren en uitschakelen: hij zou het gehele certificaat moeten verwerpen, wat de verbinding verbreekt en zichtbaar is. De keerzijde is dat composite-certificaatformaten grotere certificaatgroottes produceren en dat niet alle huidige TLS-implementaties ze al volledig ondersteunen.
| Kenmerk | Dual-certificate (draft-yusef-tls-pqt-dual-certs-03) | Composite certificate (IETF LAMPS) |
|---|---|---|
| Aanvalsoppervlak downgrade | Groter: aanvaller kan PQC-keten onderdrukken | Kleiner: beide handtekeningen onlosmakelijk verbonden |
| PKI-beheerlast | Dubbele certificaatketens, dubbele revocatie | Eén certificaatketen, gecombineerde revocatie |
| Legacy-compatibiliteit | Hoog: clients kiezen hun keten | Matig: vereist ondersteuning voor composite-formaat |
| Certificaatgrootte | Twee aparte certificaten | Één groter certificaat |
| Standaardisatiestatus (2024) | IETF draft, experimenteel | IETF draft, experimenteel |
CDN’s, TLS-terminerende proxies en load balancers als zwakke schakel
PQC-commitments en composite-certificaten bieden geen bescherming als de TLS-verbinding halverwege wordt beëindigd door een tussenliggende component. Dit is het meest over het hoofd geziene risico bij on-premise en co-locatieomgevingen.
Een CDN of een TLS-terminerende load balancer beëindigt de externe TLS-sessie en bouwt intern een nieuwe op. Als dat interne segment geen PQC-algoritmen gebruikt, zijn alle externe PQC-maatregelen zinloos voor de vertrouwelijkheid van het interne verkeer. Erger nog: als de load balancer de PQC Continuity-signalen niet doorgeeft aan de backend, merkt de client niet dat de PQC-bescherming op het interne pad ontbreekt.
Concrete maatregelen voor organisaties in dit segment:
- Inventariseer alle TLS-terminerende componenten, inclusief WAF’s, API-gateways en interne reverse proxies.
- Vereis dat leveranciers van netwerkcomponenten een tijdlijn geven voor ML-DSA-ondersteuning.
- Overweeg end-to-end TLS zonder tussenliggende terminatie voor de meest gevoelige datastromen, zoals communicatie met een soevereine Nextcloud-instantie of interne CA.
- Controleer of uw interne CA (Certificate Authority) al composite-certificaatprofielen kan uitgeven.
Stappen voor IT-teams: rollbackbescherming activeren zonder legacy-compatibiliteit te verliezen
De transitie naar PQC-beschermde verbindingen is geen schakelaar die in één keer wordt omgezet. Een gefaseerde aanpak stelt organisaties in staat om bescherming op te bouwen terwijl legacy-clients operationeel blijven.
Het NCSC-NL erkende in het Cybersecuritybeeld Nederland 2023 dat ransomware nog steeds de meest impactvolle cybercriminaliteitsvorm is voor Nederlandse organisaties. PQC-migratie vereist een gestructureerde aanpak die de bestaande beveiligingsoperaties niet verstoort.
Een praktisch stappenplan:
- Cryptografische inventarisatie: Breng in kaart welke algoritmen momenteel in gebruik zijn op alle TLS-eindpunten, interne CA’s en VPN-gateways. Identificeer welke systemen RSA-2048, ECDH of ECDSA gebruiken.
- Pilotimplementatie met hybride modus: Activeer ML-DSA (NIST FIPS 204) naast het klassieke algoritme op een beperkte subset van servers. Gebruik een hybride sleuteluitwisselingsmechanisme zoals X25519+ML-KEM-768 zodat verbindingen met legacy-clients niet verbroken worden.
- Monitoring van algoritmeverhandelingen: Implementeer logging op TLS-handshakes om bij te houden welk percentage van verbindingen daadwerkelijk PQC-algoritmen onderhandelt. Dit geeft inzicht in het aandeel legacy-clients.
- PQC Continuity activeren voor interne systemen: Zodra interne clients (servers, applicaties, beheertools) PQC ondersteunen, activeer dan PQC Continuity op basis van draft-sheffer-tls-pqc-continuity-02 voor de interne communicatiestromen. Externe publieke clients worden in een later stadium meegenomen.
- Composite-certificaten uitrollen vanuit de interne CA: Werk samen met de LAMPS Working Group-documenten als referentie en test composite-certificaatuitgifte via uw interne CA voor de systemen die het ondersteunen.
- Legacy-sunset plannen: Stel een datum vast waarop klassieke algoritmen intern worden uitgeschakeld, en communiceer dit aan applicatie-eigenaren die nog legacy-clients ondersteunen. NIS-2-naleving vereist dat risicoafwegingen worden gedocumenteerd.
Het NIST publiceerde FIPS 204 (ML-DSA) in augustus 2024, waarmee de eerste gestandaardiseerde post-kwantumhandtekeningstandaard beschikbaar is. Dit vormt het fundament voor elk migratieplan: leveranciers van TLS-stacks, HSM’s (Hardware Security Modules) en PKI-software beginnen nu actief ondersteuning te implementeren.
Consequenties voor NIS-2- en GDPR-compliance
Voor organisaties in de overheid, juridische sector en andere gereguleerde sectoren is PQC-migratie geen vrijwillige exercitie. NIS-2 (Richtlijn (EU) 2022/2555) verplicht “passende en evenredige technische maatregelen” voor netwerk- en informatiebeveiliging. De combinatie van harvest-now-decrypt-later-risico’s en de beschikbaarheid van gestandaardiseerde PQC-algoritmen maakt het steeds lastiger om bij een toezichthouder te verdedigen dat klassieke cryptografie nog “passend” is voor gevoelige datastromen.
GDPR (Verordening (EU) 2016/679) vereist onder artikel 32 dat verwerkingsverantwoordelijken passende versleuteling toepassen. Wanneer onderschept versleuteld verkeer in de toekomst kan worden ontsleuteld door kwantumcomputers, is de vraag gerechtvaardigd of huidige klassieke versleuteling nog als “passend” geldt voor gegevens met een lange vertrouwelijkheidshorizon, zoals medische dossiers, juridische communicatie en overheidsclassificaties.
FAQ: PQC-rollbackaanvallen en TLS 1.3-bescherming
Wat is precies een PQC-rollbackaanval in TLS 1.3?
Een PQC-rollbackaanval is een actieve aanval waarbij een aanvaller de TLS 1.3-handshake manipuleert zodat de verbinding terugvalt op een klassiek, kwantum-onveilig algoritme. Dit is mogelijk zolang de server beide algoritmen accepteert en de client geen mechanisme heeft om PQC-gebruik af te dwingen.
Hoe verschilt PQC Continuity van HSTS?
HSTS dwingt af dat een browser altijd HTTPS gebruikt in plaats van HTTP. PQC Continuity werkt een laag dieper: het dwingt af dat een client die eerder een PQC-verbinding heeft gezien, geen verbinding meer accepteert zonder PQC-bescherming. De analogie is sterk, maar het toepassingsgebied is de cryptografische algoritmekeuze in de TLS-handshake.
Wat is het verschil tussen een dual-certificate en een composite-certificate aanpak?
Bij dual certificates heeft een server twee afzonderlijke certificaten: één klassiek en één post-kwantum. Bij een composite certificate (via de IETF LAMPS Working Group) bevat één certificaat beide handtekeningen, zodat een aanvaller niet meer één algoritme kan isoleren en uitschakelen zonder de gehele verbinding te verbreken.
Hoe beïnvloeden TLS-terminerende CDN’s en load balancers de PQC-afdwinging?
Wanneer een CDN of load balancer TLS termineert, beëindigt hij de verbinding namens de server en bouwt intern een nieuwe op. Als dat interne segment geen PQC-bescherming heeft of geen PQC Continuity-signalen doorgeeft, is de afdwinging gebroken. Organisaties moeten elk TLS-terminatiepunt in kaart brengen en controleren.
Moeten NIS-2- of GDPR-plichtige organisaties nu al actie ondernemen?
Ja. ENISA erkent harvest-now-decrypt-later als actueel risico, en NIST heeft FIPS 204 (ML-DSA) al gestandaardiseerd. Wachten totdat kwantumcomputers operationeel zijn, is te laat: verkeer dat nu wordt onderschept, kan later worden ontsleuteld. Een cryptografische inventarisatie en een gedocumenteerd migratieplan zijn een concrete eerste stap die ook aantoonbaar bijdraagt aan NIS-2-naleving.
