VPN-migratie na Quantum: IPsec, TLS VPN's en toegang op afstand

Kort antwoord: De migratie naar post-quantum VPN's kent twee verschillende uitgangspunten, afhankelijk van wat uw apparaat momenteel ondersteunt. RFC 8784 maakt het mogelijk om een ​​post-quantum pre-shared key te integreren in IKEv2-sleutelafleiding zonder een nieuw sleuteluitwisselingsalgoritme. Dit is een eenvoudige eerste stap die al beschikbaar is op veel firewalls van de huidige generatie. RFC 9370, voortbouwend op de Intermediate Exchange van RFC 9242, voegt echte hybride post-quantum sleuteluitwisseling toe aan IKEv2 zelf. TLS-gebaseerde VPN's voor toegang op afstand erven dezelfde hybride sleuteluitwisseling (X25519MLKEM768) die al wordt gebruikt in browsers en CDN's. De belangrijkste beperking voor beide trajecten is de firmware: beschouw de specifieke productversie van uw apparaat als een harde afhankelijkheid en valideer de interoperabiliteit op de exacte peercombinatie die u gebruikt, niet alleen op basis van de algemene roadmap van de leverancier.

VPN-migratie krijgt in de meeste PQC-planningen minder aandacht dan TLS-migratie, wat een vergissing is gezien de hoeveelheid langdurig, gevoelig verkeer dat over IPsec- en TLS-VPN-tunnels loopt. In tegenstelling tot een webserver is een VPN-apparaat meestal niet iets dat je kunt patchen door een nieuwe build uit te rollen; het is een harde firmware-afhankelijkheid, vaak bepaald door een releaseplanning van de leverancier waar je geen controle over hebt, en bevindt zich aan beide uiteinden van een tunnel die ook nog eens moet samenwerken. Deze handleiding behandelt de protocollen, de gereedheid van het apparaat en een gefaseerde uitrolaanpak.

Key Takeaways

• RFC 8784 (post-quantum pre-shared keys) is de meest eenvoudige eerste stap voor IKEv2 VPN's, waarbij geen nieuw sleuteluitwisselingsalgoritme nodig is, maar slechts een vooraf gedeelde sleutel die in de bestaande afleiding wordt gemengd.
• RFC 9370, gebaseerd op de Intermediate Exchange van RFC 9242, voegt een echte hybride post-kwantum sleuteluitwisseling toe aan IKEv2, waarbij een klassieke uitwisseling wordt gecombineerd met een of meer post-kwantum KEM's.
• Op TLS gebaseerde VPN's voor toegang op afstand erven de ondersteuning voor hybride sleuteluitwisseling van de onderliggende TLS-stack, volgens hetzelfde X25519MLKEM768-implementatiepatroon als browser- en CDN-verkeer.
• Firmware en productversie zijn essentiële vereisten voor VPN-apparaten en geen instelbare optie; aankondigingen van leveranciers over ondersteuning en de daadwerkelijke gereedheid voor implementatie zijn twee verschillende zaken.
• De richtlijnen van CISA voor kwantumgereedheid beschouwen de betrokkenheid van leveranciers en de validatie van interoperabiliteit als kernonderdelen van het migratieplan, en niet als een bijzaak.

IPsec-sleuteluitwisseling: twee paden, verschillende inspanning

IKEv2 kent twee verschillende standaardiseringsroutes naar post-kwantumresistentie, en deze sluiten elkaar niet uit.

RFC 8784, post-quantum pre-shared keys, voegt een symmetrische, vooraf gedeelde sleutel, die buiten de bandbreedte wordt gedistribueerd, toe aan de IKEv2-sleutelafleiding naast de bestaande klassieke uitwisseling. Het vereist geen nieuw asymmetrisch algoritme en geen significante wijziging aan de IKEv2-onderhandeling zelf, waardoor het vaak de eerste functionaliteit is die apparaten implementeren en de snelste weg naar enige vorm van kwantumweerstand op infrastructuur die dit al ondersteunt.

RFC 9370, Multiple Key Exchanges in IKEv2, is het completere antwoord: het breidt het protocol uit om een ​​of meer extra sleuteluitwisselingen, doorgaans een post-quantum KEM zoals ML-KEM, naast de klassieke uitwisseling mogelijk te maken, met behulp van een trapsgewijze sleutelafleidingsmethode. Omdat de oorspronkelijke IKE_SA_INIT-uitwisseling geen grote sleutelmaterialen kon fragmenteren, introduceerde RFC 9242 een "Intermediate Exchange" specifiek zodat RFC 9370 de grotere post-quantum sleutelmaterialen na de initiële handshake kon verwerken, waar fragmentatie wel mogelijk is. Dit is de weg die een echte hybride sleuteluitwisseling oplevert, en niet slechts een extra vooraf gedeeld geheim.

TLS VPN's: Dezelfde hybride sleuteluitwisseling

Op TLS gebaseerde VPN's voor toegang op afstand maken gebruik van dezelfde TLS 1.3-stack als elke andere TLS-terminerende service. Dit betekent dat ze hybride post-quantum sleuteluitwisseling erven op dezelfde manier als een webserver: via de ondersteuning van de onderliggende TLS-bibliotheek voor de X25519MLKEM768-groep, die uitgebreid wordt behandeld in onze implementatiehandleiding voor X25519MLKEM768 . De onderhandelingsmechanismen, compatibiliteitsrisico's en testaanpak in die handleiding zijn direct van toepassing op een TLS VPN-gateway, met één toevoeging: VPN-clientsoftware, en niet alleen browsers, moet de hybride groep ondersteunen, en de updatecycli voor VPN-software zijn vaak trager dan de automatische updatecycli van browsers.

Apparaatgereedheid: Leveranciersondersteuning is niet hetzelfde als implementatiegereedheid.

Een leverancier die in een roadmap of persbericht ondersteuning na de quantumfase aankondigt, betekent niet dat die ondersteuning ook daadwerkelijk beschikbaar, getest en stabiel is voor de specifieke productversie die in uw omgeving draait. Beschouw firmware en productversie als een harde, expliciete afhankelijkheid in uw migratieplan: identificeer de exacte minimale versie die de door u te gebruiken sleuteluitwisselingsmethode ondersteunt, vergelijk deze met uw huidige versie en plan de upgradecyclus in als onderdeel van de migratietijdlijn in plaats van ervan uit te gaan dat deze automatisch plaatsvindt.

Validatie van interoperabiliteit is net zo belangrijk als versieondersteuning. Ondersteuning van IKEv2 na de kwantumfase door twee verschillende leveranciers, of zelfs twee verschillende productlijnen van dezelfde leverancier, biedt geen garantie voor een probleemloze communicatie vanaf dag één. Valideer de exacte peercombinatie die u daadwerkelijk gebruikt, van client naar concentrator, van site naar site, in plaats van ervan uit te gaan dat naleving van algemene standaarden interoperabiliteit garandeert.

Clientcompatibiliteit

Clientsoftware voor VPN-toegang op afstand brengt een eigen compatibiliteitsvraagstuk met zich mee, los van de gateway of concentrator. Een VPN-gateway die hybride sleuteluitwisseling ondersteunt, is niet nuttig als de clienttoepassing die ermee verbinding maakt, of het nu een dedicated VPN-client of een browsergebaseerde TLS VPN-portal is, dit niet ondersteunt. Inventariseer de clientsoftwareversies van uw medewerkers die op afstand werken met dezelfde nauwkeurigheid als de gatewayfirmware, aangezien een mix van bijgewerkte en verouderde clients de realistische beginsituatie is voor de meeste bedrijfsimplementaties, en geen schone overstap.

Een gefaseerde uitrolaanpak

1. Basislijn en inventarisatie: Controleer voor elke VPN-gateway, concentrator en client de actuele firmware- of softwareversie en de gedocumenteerde post-quantum-functionaliteit voordat u configuratiewijzigingen aanbrengt.
2. Moderniseer eerst de klassieke basislijn: Zorg ervoor dat sterke klassieke cryptografie en actuele protocolversies al aanwezig zijn; post-kwantummogelijkheden bouwen voort op een moderne basis, niet op een verouderde.
3. Begin met RFC 8784, indien beschikbaar: Post-quantum pre-shared keys bieden zinvolle bescherming tegen 'harvest-now-decrypt-later' met minimaal protocolrisico, een redelijke eerste stap totdat bredere ondersteuning voor hybride sleuteluitwisseling zich verder ontwikkelt.
4. Test RFC 9370 hybride sleuteluitwisseling op een niet-kritieke tunnel: Valideer de interoperabiliteit op de exacte peercombinatie voordat u het productieverkeer gebruikt.
5. Bepaal expliciet het klassieke terugvalgedrag: Bepaal of een peer die geen post-kwantum sleuteluitwisseling kan uitvoeren, verbinding mag maken met uitsluitend klassieke cryptografie of direct moet worden geweigerd, en documenteer die beslissing in plaats van deze als een impliciete standaardwaarde te laten gelden.
6. Onderhandelde algoritmen registreren en bewaken: Houd bij welke sleuteluitwisselingsmethode elke tunnel daadwerkelijk gebruikt in de productieomgeving, zodat een stille terugval naar alleen de klassieke methode als meetwaarde wordt weergegeven en geen verrassing vormt tijdens een audit.

Wat we daadwerkelijk zouden aanbevelen

Begin met RFC 8784 pre-shared keys op infrastructuur die dit al ondersteunt, aangezien dit daadwerkelijke bescherming biedt tegen het 'harvest-now-decrypt-later'-principe met het laagste implementatierisico van alle huidige opties. Stel uw inventaris van firmware- en clientversies samen voordat u zich vastlegt op een tijdlijn voor de uitrol van hybride sleuteluitwisseling en beschouw aankondigingen van leveranciers in hun roadmap als input voor de planning, niet als een implementatiedatum. Test eerst de hybride sleuteluitwisseling volgens RFC 9370 op een enkele, niet-kritieke tunnel en valideer de exacte peercombinatie in plaats van te vertrouwen op naleving van algemene standaarden.

Hoe encryptieconsultancy kan helpen

De bovenstaande gefaseerde uitrol is volledig afhankelijk van een nauwkeurige inventarisatie van de VPN-gatewayfirmware, clientsoftwareversies en tunnelconfiguraties in uw omgeving. Dit is precies het soort hiaat in de inventarisatie dat de meeste migratieplannen al in een vroeg stadium laat vastlopen. CBOM Secure bouwt en onderhoudt deze inventarisatie, waarbij elk VPN-eindpunt wordt gekoppeld aan de huidige versie en de mogelijkheden na de Quantum-update. Zo begint het migratieplan met de juiste gegevens.

Omdat de belangrijkste ML-KEM-bewerkingen zelf op FIPS-gecertificeerde hardware moeten draaien, ondersteunt HSM-as-a-Service de hybride uitwisseling volgens RFC 9370 zonder dat er per gateway een aparte hardware-aankoopcyclus nodig is. Onze PQC Advisory Services stemmen de hierboven beschreven firmware-upgradecyclus, interoperabiliteitsvalidatie en gefaseerde uitrol af op uw specifieke combinatie van apparaten en tunneltopologie. Zo wordt de planning van de leverancier vertaald naar een daadwerkelijk, getest migratieplan in plaats van een aanname.

Firmware is de werkelijke tijdlijn voor migratie.

De migratie naar een VPN na het kwantumtijdperk is minder een kwestie van algoritmes dan van firmware en interoperabiliteit. RFC 8784 biedt een eerste stap die weinig moeite kost, RFC 9370 biedt de complete hybride oplossing en TLS VPN's profiteren van dezelfde beveiliging als webverkeer. Wat de migratie daadwerkelijk versnelt, is of uw specifieke apparaatversie, aan beide uiteinden van elke tunnel, de gekozen methode ondersteunt en er correct mee samenwerkt. Daarom zijn de inventarisatie- en interoperabiliteitsvalidatiestappen belangrijker dan de protocolkeuze zelf.

Veelgestelde Vragen / FAQ

Wat is de snelste manier om post-quantumbeveiliging toe te voegen aan een bestaande IKEv2 VPN?

RFC 8784, post-quantum pre-shared keys. Het vereist geen nieuw sleuteluitwisselingsalgoritme, alleen een pre-shared key die is geïntegreerd in de bestaande IKEv2-afleiding, en is al beschikbaar op veel apparaten van de huidige generatie.

Wat is het verschil tussen RFC 8784 en RFC 9370?

RFC 8784 voegt een symmetrische, vooraf gedeelde sleutel toe aan de bestaande sleutelafleiding van IKEv2 zonder een nieuw algoritme. RFC 9370 voegt een echte hybride post-kwantum sleuteluitwisseling toe, waarbij de klassieke uitwisseling wordt gecombineerd met een of meer post-kwantum KEM's zoals ML-KEM, en vereist dat de tussenliggende uitwisseling van RFC 9242 het grotere sleutelmateriaal transporteert.

Vereisen op TLS gebaseerde VPN's voor toegang op afstand aparte nabewerking na de kwantumverwerking, in tegenstelling tot IPsec VPN's?

Ze erven hybride sleuteluitwisseling van de onderliggende TLS 1.3-stack, volgens hetzelfde X25519MLKEM768-patroon als elke TLS-service, maar VPN-clientsoftware moet specifiek de hybride groep ondersteunen, en clientupdates verlopen vaak trager dan browserupdates, dus dit vereist een aparte compatibiliteitscontrole.

Is leveranciersondersteuning voor VPN-functies na de quantum-update hetzelfde als direct inzetbaar zijn?

Nee. Een aankondiging van een leveranciersroadmap is input voor de planning, geen implementatiedatum. Controleer of de specifieke firmware- of productversie die in uw omgeving draait daadwerkelijk de door u gewenste sleuteluitwisselingsmethode ondersteunt en hiervoor gevalideerd is, voordat u een implementatietijdlijn opstelt.

Zou het toegestaan ​​moeten zijn voor peers die alleen klassieke sleutels gebruiken om verbinding te maken zodra post-kwantum sleuteluitwisseling is geïmplementeerd?

Dat moet een expliciete, gedocumenteerde beslissing zijn in plaats van een standaardinstelling. Bepaal en documenteer of een peer die geen post-kwantum sleuteluitwisseling kan uitvoeren, nog steeds verbinding mag maken met uitsluitend klassieke cryptografie of dat deze moet worden geweigerd. Registreer de onderhandelde algoritmen in de productieomgeving, zodat het daadwerkelijke gedrag zichtbaar is.