Post-quantum TLS voor defensie-API's: hybride handshakes in productie

Elke defensie-API die vandaag in productie is, wordt beschermd door een sleuteluitwisseling — doorgaans X25519 of een elliptische curve — die een voldoende krachtige kwantumcomputer uiteindelijk zal kraken. Die machine bestaat nog niet, maar de data die over die API's stroomt heeft een vertrouwelijkheidslevensduur van jaren of decennia. Een tegenstander kan het versleutelde verkeer nu opnemen en later ontsleutelen, zodra de hardware beschikbaar is. Post-quantum TLS sluit dat venster door een kwantumresistent sleutelinkapselmechanisme aan de handshake toe te voegen. Dit artikel behandelt hoe u het implementeert op echte defensie-API's: de hybride ML-KEM handshake, de certificaatvraag, het prestatie- en bandbreedteimpact, en een gefaseerde uitrol die geen enkele bestaande client verstoort.

Het threat model van harvest-now-decrypt-later

De reden dat post-quantum TLS urgent is, heeft niets te maken met of er vandaag een cryptografisch relevante kwantumcomputer bestaat. Het gaat om de asymmetrie tussen wanneer data wordt vastgelegd en wanneer het wordt ontsleuteld. Een tegenstander met de middelen om verkeer af te tappen en op te slaan kan de versleutelde sessies van een defensie-API voor onbepaalde tijd archiveren. Op het moment dat een kwantumcomputer die in staat is Shor's algoritme op de vereiste schaal uit te voeren beschikbaar wordt, is elke opgeslagen sessie waarvan de sleuteluitwisseling een klassiek algoritme gebruikte retroactief blootgelegd. We behandelen deze kwantumbedreigingstijdlijn elders in detail; de operationele conclusie voor een API-team is eenvoudig. Als uw data geheim moet blijven na de komst van praktische kwantumcomputing, kan de migratie niet wachten op die komst — tegen dan is het vastgelegde verkeer al gecompromitteerd.

Dit is waarom authenticatie en vertrouwelijkheid een verschillende urgentie hebben. Een vervalste handtekening telt alleen op het moment van de verbinding — een kwantumcomputer die in 2035 handtekeningen kraakt, kan een handshake uit 2026 die al voltooid is niet retroactief vervalsen. Vertrouwelijkheid is het tegenovergestelde: die moet standhouden gedurende de gehele bewaartijd van de data. Post-quantum TLS geeft dan ook prioriteit aan de sleuteluitwisseling en stelt de migratie van handtekeningen uit, wat precies de volgorde is die CNSA 2.0 en de bredere normorganisaties aanbevelen.

Hybride handshakes: dubbele beveiliging

Het gestandaardiseerde post-quantum sleutelinkapselmechanisme is ML-KEM (FIPS 203, afgeleid van CRYSTALS-Kyber). In principe zou een TLS 1.3 handshake alleen ML-KEM kunnen gebruiken. In de praktijk gebruiken defensie-implementaties een hybride handshake die ML-KEM en een klassiek algoritme samen uitvoert en hun outputs combineert.

Het mechanisme is eenvoudig. Tijdens de TLS 1.3 sleuteluitwisseling leiden de client en server elk twee gedeelde geheimen af — één van het klassieke algoritme (X25519) en één van ML-KEM-768. De twee geheimen worden samengevoegd en als één gecombineerd geheim in het TLS-sleutelschema ingevoerd. De sessiesleutel wordt daardoor van beide afgeleid. Een aanvaller moet beide algoritmen kraken om de sessie te herstellen: het klassieke weerstaat huidige tegenstanders, en ML-KEM weerstaat een toekomstige kwantumtegenstander.

De hybride aanpak is bewust conservatief. ML-KEM is nieuw, en het vertrouwen van de cryptografische gemeenschap in een algoritme groeit met jaren van scrutiny. Door het te combineren met de beproefde X25519 betekent dat zelfs als later een implementatiefout of onverwachte zwakte in de post-quantum component wordt gevonden, de sessie niet zwakker is dan het huidige klassieke TLS. De kosten van het dragen van beide zijn bescheiden, en voor defensiewerklasten is de conservativiteit het waard.

De named group: X25519MLKEM768

In TLS 1.3 wordt de hybride constructie blootgesteld als één named group in de supported_groups extensie. De wijdverspreide vorm is X25519MLKEM768, die X25519 koppelt aan ML-KEM-768 (de beveiligingsniveau-3 parameterset, geschikt voor de meeste CNSA 2.0-doelen). De server kondigt de groep aan, de client biedt er een sleutelshare voor aan, en de onderhandeling verloopt precies zoals bij elke andere groep. Cruciaal is dat dit betekent dat hybride TLS naadloos in de bestaande TLS 1.3 onderhandelingsmachinerie past — er is geen nieuwe protocollaag, alleen een nieuwe groepsidentificator en een grotere sleutelshare.

Prestatie en bandbreedte: waar de kosten werkelijk liggen

Een veelgemaakte aanname is dat post-quantum cryptografie traag is. Voor ML-KEM klopt dat niet. De roosterbewerkingen achter ML-KEM-768 sleutelgeneratie, inkapseling en ontkapseling zijn snel — vaak sneller dan de elliptische-curve scalaire vermenigvuldiging van het klassieke algoritme waarmee ze gepaard gaan. Op een moderne servercore voegen de ML-KEM bewerkingen in een hybride handshake ruim minder dan een milliseconde toe. CPU is niet de beperkende factor.

De werkelijke kosten zijn bytes op de lijn. Een ML-KEM-768 publieke sleutel is ongeveer 1184 bytes en de cijfertekst ongeveer 1088 bytes. Opgeteld bij de klassieke X25519-share draagt de hybride sleuteluitwisseling samen in de ClientHello en ServerHello ongeveer 2,3 KB bij. De operationeel relevante consequentie: de ClientHello, die met klassieke groepen comfortabel onder 1400 bytes ligt, overschrijdt nu één enkel netwerkpakket. Op een schoon netwerk is dit onzichtbaar. Op een verliesgevende of beperkte verbinding — een satelliet backhaul, een overbelaste tactische radiodrager — introduceert het extra pakket een nieuwe kans op verlies en hertransmissie, en de staart van handshake-failures kan groeien.

Dit herkadert het uitrolrisico. Wat u moet meten is niet de handshake-CPU-tijd maar het fragmentatiegedrag van de ClientHello en de middlebox-tolerantie over de specifieke netwerkpaden die een defensie-API werkelijk bedient. Een API die alleen bereikt wordt via een gezond datacenternetwerk ziet vrijwel geen impact; één die bereikt wordt via kansarme tactische verbindingen vereist zorgvuldige validatie voordat de hybride groep wordt ingeschakeld.

De certificaatvraag: eerst vertrouwelijkheid, later authenticatie

Een veelvoorkomend punt van verwarring is of het implementeren van post-quantum TLS vereist dat elk certificaat opnieuw wordt uitgegeven. Voor de eerste fase is dat niet het geval. De hybride handshake beschermt de sleuteluitwisseling — het deel van TLS dat de vertrouwelijkheid van de sessie tot stand brengt — en dat is het enige deel dat blootgesteld is aan de harvest-now-decrypt-later aanval. Serverauthenticatie blijft de bestaande RSA- of ECDSA-certificaatketen gebruiken.

Er is een praktische reden om handtekeningmigratie uit te stellen naast het argument van het threat model. De gestandaardiseerde post-quantum handtekeningalgoritmen, ML-DSA (FIPS 204) en SLH-DSA (FIPS 205), produceren veel grotere handtekeningen en publieke sleutels dan ECDSA. Een certificaatketen gebouwd op ML-DSA kan een orde van grootte groter zijn, wat elke handshake vergroot en beperkte clients belast. Het certificaatautoriteitsecosysteem, de browser- en OS-vertrouwensopslag, en de meeste client-TLS-stacks zijn nog niet klaar om post-quantum handtekeningketens op schaal te valideren. Het vandaag dwingen van post-quantum authenticatie zou veel meer kapotmaken dan het beschermt.

De juiste volgorde, in overeenstemming met de CNSA 2.0-richtlijn voor defensie, is dan ook: implementeer nu hybride sleuteluitwisseling om harvest-now-decrypt-later te verslaan, behoud klassieke authenticatie, en migreer handtekeningen naar ML-DSA in een afzonderlijke, latere fase zodra de CA-keten en uw clientpopulatie dit kunnen ondersteunen. Het behandelen van deze als twee onafhankelijke migraties is wat elk ervan beheersbaar houdt.

Gefaseerde uitrol zonder clients te verstoren

Het meest belangrijke principe voor een niet-verstorende uitrol is dat de hybride named group additief moet zijn. U schakelt X25519MLKEM768 in naast de klassieke groepen, niet in de plaats ervan. TLS 1.3 groepsonderhandeling is door ontwerp achterwaarts compatibel: een moderne client die de hybride groep aanbiedt krijgt het; een oudere client die alleen X25519 aanbiedt valt terug naar de klassieke groep op hetzelfde eindpunt. Geen enkele client wordt verstoord doordat de server simpelweg een nieuwe groep kent.

Daarna is de uitrol een oefening in meting. Inventariseer eerst elk TLS-beëindigingspunt — edge load balancers, API-gateways, service-mesh sidecars, origin servers — en de cryptobibliotheek op elk punt, omdat het upgradeverhaal slechts zo goed is als de minst capabele terminator. Een hardwareapparaat met bevroren firmware dat niet ML-KEM kan spreken wordt de beperkende factor en moet worden geïdentificeerd voordat beloften worden gedaan.

Schakel ten tweede de hybride groep in additieve modus in achter een feature flag en instrumenteer de onderhandelde sleuteluitwisselingsgroep voor elke voltooide handshake. Die telemetrie vertelt u het werkelijke deel van het verkeer dat al beschermd is en toont de clients en netwerken die nooit upgraden. Ten derde — en pas zodra telemetrie bijna universele hybride onderhandeling op een route aantoont — kunt u optioneel de hybride groep afdwingen op de meest gevoelige endpoints door klassieke fallback daar te verwijderen, terwijl de rest van de API additief blijft. Handhaving is de laatste stap, smal toegepast, met een geteste terugval naar additieve modus altijd beschikbaar.

Deze volgorde telt om dezelfde reden als in elk cryptografisch migratieprogramma — de migratie is een langdurige, omkeerbare toestandsovergang, geen schakelaar. Voor organisaties die de bredere cryptografische overgang rondom hun API's plannen, plaatst de CNSA 2.0 migratie-roadmap TLS sleuteluitwisseling in de context van de volledige algoritme-inventaris en tijdlijn.

Operationele veiligheidsmaatregelen voor defensie-API's

Naast onderhandeling scheiden een paar veiligheidsmaatregelen een geharde implementatie van een kwetsbare. Stel het minimumprotocol vast op TLS 1.3 op post-quantum-capabele routes; de hybride constructie bestaat alleen in 1.3, en het toestaan van een downgrade naar 1.2 herintroduceert een klassieke-enige sleuteluitwisseling. Schakel sessie-hervattingspaden uit die een verbinding zouden laten overslaan van een verse hybride sleuteluitwisseling tenzij de hervatting zelf post-quantum bescherming voortzet. En zorg ervoor dat uw observeerbaarheidsstack zowel de TLS-versie als de onderhandelde groep registreert, zodat een regressie — een bibliotheekdowngrade, een verkeerd geconfigureerde gateway — verschijnt als een daling in het hybride aandeel in plaats van uw API's stilzwijgend terug te zetten naar klassieke-enige vertrouwelijkheid.

Crypto-behendigheid is de eigenschap die dit alles onderhoudbaar maakt over de meerjarige horizon die de migratie werkelijk omspant. ML-KEM-768 is vandaag de juiste parameterset voor de meeste defensie-API's, maar de standaarden zullen evolueren, named groups worden toegevoegd, en uw hoogst geclassificeerde routes kunnen uiteindelijk ML-KEM-1024 vereisen. Configuratie, niet code, moet beslissen welke groepen een eindpunt aanbiedt, zodat het verhogen van het post-quantum beveiligingsniveau of het buiten gebruik stellen van een verouderde groep een operationele wijziging is in plaats van een heruitrol. Dezelfde behendigheid geldt omgekeerd: als er een fout wordt gevonden in een ingezette groep, wilt u die binnen minuten over de hele vloot kunnen uitschakelen. Behandel de lijst met ondersteunde groepen als een beheerd, geversioneerd beleid, en uw API's blijven kwantumveilig gedurende de gehele overgang in plaats van op één enkel tijdstip.

De uitrol testen voordat deze productie bereikt

Valideer de hybride handshake tegen de volledige diversiteit van uw clientpopulatie voordat u deze breed inschakelt. Zet een staging-eindpunt op dat X25519MLKEM768 additief aanbiedt en drijf het aan met elk clienttype dat de API in het veld aanraakt — huidige SDK's, embedded clients op beperkte hardware, en eventuele externe integrators. Registreer de onderhandelde groep voor elk zodat u weet welke clients upgraden en welke stilzwijgend klassiek blijven. Let in het bijzonder op clients achter inspectieproxy's of overheids-gateways, want daar is de vergrote ClientHello het meest waarschijnlijk te worden laten vallen. Een stagingdoorgang die de werkelijke netwerktopologie oefent, niet alleen een schoon laboratoriumpad, is wat u later in staat stelt hybride met vertrouwen in plaats van hoop op een gevoelige route af te dwingen.