PQC StatusIn una VPN, la parte esposta a un futuro attaccante quantistico è lo scambio di chiavi, non la cifratura del traffico. Per IPsec esistono oggi due meccanismi IETF pubblicati che è possibile utilizzare: RFC 9370, che consente a IKEv2 di negoziare scambi di chiavi aggiuntivi in modo che un KEM (key encapsulation mechanism, meccanismo di incapsulamento della chiave) post-quantum operi accanto a un gruppo classico, e RFC 8784, che integra una chiave pre-condivisa post-quantum nella derivazione delle chiavi di IKEv2. WireGuard non prevede uno scambio di chiavi post-quantum nel protocollo stesso, quindi la sua chiave simmetrica pre-condivisa opzionale da 32 byte è l'unica leva disponibile all'interno del protocollo.
Perché lo scambio di chiavi viene prima
Un tunnel IPsec ha due livelli. ESP (Encapsulating Security Payload) protegge i dati con un algoritmo simmetrico, tipicamente AES-256-GCM. Gli algoritmi simmetrici e le funzioni di hash non vengono violati dall'algoritmo di Shor, e l'algoritmo di Grover è il motivo per cui AES-256 è preferito per la protezione a lungo termine. Il livello IKE (Internet Key Exchange) è diverso: IKEv2, come pubblicato nella RFC 7296, deriva le proprie chiavi da uno scambio Diffie-Hellman, e il Diffie-Hellman su curve ellittiche e il Diffie-Hellman su campi finiti vengono violati dall'algoritmo di Shor su un computer quantistico sufficientemente potente, qualunque sia la dimensione del gruppo.
Questo conta già oggi a causa dello scenario harvest now, decrypt later (HNDL): un attaccante che registra oggi il traffico cifrato del tunnel ha bisogno soltanto che lo scambio di chiavi ceda in futuro per poterlo leggere. I tunnel site-to-site che trasportano dati con una lunga durata di riservatezza (cartelle cliniche, documenti legali, progetti industriali, dati di pagamento) sono il caso più evidente. L'autenticazione è una questione distinta. L'autenticazione dei peer IKEv2 con certificati RSA o ECDSA deve resistere soltanto a un attaccante presente al momento dell'handshake, quindi le firme possono migrare dopo lo scambio di chiavi, ma devono comunque migrare.
I tre meccanismi disponibili oggi
| Meccanismo | Specifica | Che cosa cambia | Che cosa richiede |
|---|---|---|---|
| Scambi di chiavi aggiuntivi IKEv2 | RFC 9370, tramite lo scambio IKE_INTERMEDIATE della RFC 9242 | Un KEM post-quantum viene negoziato in banda, in aggiunta al gruppo classico | Supporto da parte di entrambi i peer, un metodo di scambio di chiavi registrato per il KEM, frammentazione IKEv2 |
| Integrazione di una chiave pre-condivisa post-quantum (PPK) | RFC 8784 | Un segreto ad alta entropia viene integrato nella derivazione delle chiavi IKEv2, per cui uno scambio registrato non è sufficiente | Distribuzione fuori banda, conservazione e rotazione di una PPK per ciascuna coppia di peer |
| Chiave pre-condivisa WireGuard | Documentazione del protocollo WireGuard (opzione PresharedKey) | Una chiave simmetrica da 32 byte viene integrata nella chaining key dell'handshake | Distribuzione fuori banda per ciascuna coppia di peer, nessuna negoziazione in banda |
| Protezione del payload ESP | AES-256-GCM | Nulla: già fuori dalla portata di Shor | Preferire AES-256 per la protezione a lungo termine |
RFC 9370: scambi di chiavi aggiuntivi in IKEv2
IKEv2 di base negozia esattamente un metodo di scambio di chiavi, nello scambio IKE_SA_INIT. La RFC 9370 aggiunge fino a sette ulteriori tipi di trasformazione per lo scambio di chiavi (comunemente indicati come ADDKE1 fino ad ADDKE7), che vengono negoziati nella stessa proposta e poi eseguiti in uno o più scambi IKE_INTERMEDIATE, il tipo di scambio definito nella RFC 9242. I segreti condivisi risultanti vengono combinati nel materiale di chiave della IKE SA, quindi mantenere un gruppo classico come primo scambio di chiavi e aggiungere un KEM come ADDKE1 produce uno schema ibrido: un attaccante deve violarli entrambi. L'approccio ibrido è quello raccomandato da ANSSI e BSI, ed è la scelta prudente finché le implementazioni post-quantum sono ancora giovani.
Il KEM da richiedere è ML-KEM, standardizzato dal NIST nel FIPS 203 il 13 agosto 2024. ML-KEM-768 è il set di parametri intermedio più diffuso; CNSA 2.0 richiede ML-KEM-1024. L'elenco di riferimento degli identificativi dei metodi di scambio di chiavi IKEv2 è il registro IANA dei parametri IKEv2, e il lavoro di specifica di ML-KEM per IKEv2 è in corso nel gruppo di lavoro IETF IPSECME: consultate quindi il registro e la documentazione della vostra implementazione, invece di fidarvi di un numero di trasformazione citato in un articolo.
Due conseguenze operative. In primo luogo, le chiavi pubbliche e i ciphertext di ML-KEM sono molto più grandi di un punto su curva ellittica, quindi è opportuno abilitare la frammentazione dei messaggi IKEv2 (RFC 7383). Uno dei motivi per cui la RFC 9370 utilizza IKE_INTERMEDIATE è che questi scambi possono essere frammentati, a differenza di IKE_SA_INIT. In secondo luogo, la sintassi delle proposte varia tra implementazioni e versioni, e la parola chiave per uno scambio di chiavi aggiuntivo post-quantum non è portabile. Verificatela nella documentazione della vostra versione esatta:
# Illustrative shape only, not a portable configuration line.
# Order: encryption - integrity/PRF - classical group - additional key exchange 1
# aes256gcm16 - prfsha384 - <classical group> - <ML-KEM as ADDKE1>
# The keyword for the additional key exchange depends on the implementation
# and its version. Take it from that version's documentation.Alcune verifiche in sola lettura su un gateway Linux, prima e dopo una modifica, mostrano che cosa il kernel ha effettivamente installato:
# List the IPsec security associations and the ESP algorithms in use
ip -s xfrm state
# Show the installed IPsec policies
ip xfrm policyEseguite prima i test in un ambiente di staging, con i peer che utilizzate realmente, e mantenete una proposta solo classica come fallback documentato finché tutti i peer non saranno migrati.
RFC 8784: integrare una chiave pre-condivisa post-quantum
La RFC 8784 segue un percorso diverso. L'initiator segnala il supporto con una notifica USE_PPK, e una chiave pre-condivisa post-quantum, identificata da un PPK_ID, viene integrata nella derivazione delle chiavi della IKE SA. Un attaccante che registra lo scambio e in seguito viola la parte Diffie-Hellman non può comunque derivare le chiavi di sessione senza la PPK. È utile proprio perché non richiede alcun nuovo algoritmo asimmetrico: molti stack IKEv2 già in produzione sono in grado di gestirla.
I limiti sono operativi più che crittografici. La PPK deve avere un'entropia reale e deve essere generata da una sorgente casuale adeguata, non digitata da una persona. Deve essere distribuita, conservata e ruotata fuori banda, per ciascuna coppia di peer, ed è questa la parte difficile su larga scala. Non rende post-quantum l'autenticazione dei peer. Inoltre la RFC 8784 consente che la PPK sia obbligatoria oppure opzionale: se è opzionale, un peer che non invia USE_PPK ottiene semplicemente una SA classica. Dove entrambe le estremità la supportano, configuratela come obbligatoria e registrate nei log quali peer hanno negoziato una PPK, così da poter dimostrare la copertura invece di presumerla.
WireGuard oggi
L'handshake di WireGuard si basa su Curve25519, quindi lo scambio di chiavi è vulnerabile ai computer quantistici allo stesso modo di IKEv2 con un gruppo classico. Per scelta progettuale, il protocollo non ha un livello di negoziazione né agilità algoritmica, quindi non esiste uno scambio di chiavi post-quantum da attivare. Ciò che esiste è la chiave simmetrica pre-condivisa opzionale, integrata nell'handshake, che la documentazione del protocollo WireGuard presenta come mitigazione contro un attaccante che registra il traffico oggi e attacca le chiavi pubbliche in seguito.
# Generate one 32 byte pre-shared key per peer pair
wg genpsk
# In a wg-quick configuration file, add it to the peer section
# [Peer]
# PublicKey = <peer public key>
# PresharedKey = <output of wg genpsk>
# AllowedIPs = 10.0.0.2/32Trattate il risultato come un segreto con un proprio ciclo di vita: unico per ciascuna coppia, consegnato tramite un canale di cui vi fidate, ruotato e registrato nel vostro inventario delle chiavi. Alcuni progetti utilizzano un demone esterno che esegue separatamente uno scambio di chiavi post-quantum e aggiorna periodicamente il valore di PresharedKey (Rosenpass è un esempio open source di questo approccio). In questo modo WireGuard resta invariato, al costo di un componente in più da distribuire, monitorare e sottoporre ad audit. Se avete bisogno della negoziazione in banda di un KEM standardizzato, IPsec con la RFC 9370 è la strada che esiste oggi.
Che cosa chiedere ai fornitori di VPN
| Domanda | Perché è importante |
|---|---|
| Quali metodi di scambio di chiavi post-quantum supporta l'implementazione IKE, in quale versione del firmware e con quali identificativi IANA dei metodi di scambio di chiavi? | Trasforma un'affermazione di marketing in qualcosa che potete testare e documentare |
| Implementate la RFC 9370 con la RFC 9242, la RFC 8784 o entrambe? | Il KEM ibrido in banda e l'integrazione manuale della PPK risolvono il problema in modo diverso |
| Lo scambio di chiavi è ibrido, e con quale set di parametri ML-KEM? | L'approccio ibrido è la postura raccomandata; CNSA 2.0 richiede ML-KEM-1024 |
| L'implementazione è validata rispetto al FIPS 203, oppure utilizza un modulo validato? | Richiesto da alcuni regimi di procurement e di audit |
| La frammentazione IKEv2 è abilitata, e qual è l'effetto misurato su frequenza di rekey, CPU e tempo di instaurazione del tunnel? | Payload KEM più grandi modificano le dimensioni dei pacchetti IKE e il carico del gateway |
| Che cosa succede quando un peer non supporta lo scambio post-quantum, ed è possibile registrarlo nei log o generare un alert? | Serve visibilità su un fallback silenzioso verso una SA solo classica |
| Quali test di interoperabilità sono stati eseguiti con i peer specifici che utilizziamo (gateway cloud, dispositivi dei partner, client di accesso remoto)? | L'interoperabilità di IKEv2 ibrido è il punto in cui i progetti si bloccano |
| Qual è la roadmap per l'autenticazione post-quantum dei peer (certificati ML-DSA)? | Prima lo scambio di chiavi, poi le firme, ma servono entrambi |
| L'hardware attuale riceverà questa funzionalità, oppure solo la prossima generazione? | Gli acceleratori crittografici dimensionati per le curve ellittiche potrebbero non supportare ML-KEM |
| Quale documentazione scritta fornirete: note di rilascio, report di test, configurazione supportata? | È ciò che confluisce nel vostro inventario crittografico |
Le scadenze che riguardano gli apparati di rete
I gateway VPN sono citati esplicitamente in una sola timeline. CNSA 2.0 della NSA, che si applica ai National Security Systems statunitensi, fissa l'uso esclusivo del proprio insieme di algoritmi (tra cui ML-KEM-1024) entro la fine del 2030 per la firma di software e firmware e per gli apparati di rete tradizionali, ed entro la fine del 2033 per browser e server web, servizi cloud, sistemi operativi e apparati di nicchia. Gli apparati di rete rientrano nel gruppo con la scadenza anticipata.
Altrove, BSI TR-02102-1 (versione 2026-01, pubblicata il 23 gennaio 2026) raccomanda un accordo di chiave ibrido post-quantum e considera accettabile l'accordo di chiave classico usato da solo soltanto fino alla fine del 2031, oppure fino alla fine del 2030 per esigenze di protezione molto elevate; si tratta di una linea guida tecnica, non di un regolamento. ANSSI rende obbligatoria l'ibridazione all'interno del proprio perimetro regolamentato (qualificazione dei prodotti, Diffusion Restreinte, SAIV e SIIV) e precisa che le sue raccomandazioni post-quantum non sono ancora obblighi normativi negli altri ambiti (FAQ PQC di ANSSI). La EU Coordinated Implementation Roadmap v1.1 (23 giugno 2025) chiede inventari crittografici e roadmap nazionali entro la fine del 2026 e la migrazione dei casi d'uso ad alto rischio entro la fine del 2030; si tratta di indicazioni coordinate per gli Stati membri, non di un regolamento vincolante per le imprese. L'NCSC britannico (20 marzo 2025) prevede la fase di discovery e un piano iniziale entro il 2028, le migrazioni a priorità più alta entro il 2031 e il completamento entro il 2035. NIST IR 8547 resta una bozza pubblica iniziale: propone di deprecare gli algoritmi con sicurezza a 112 bit, come RSA-2048, dopo il 2030 e di vietare tutti gli algoritmi a chiave pubblica vulnerabili ai computer quantistici dopo il 2035.
La nostra lettura, proposta come interpretazione e non come consulenza legale: un tunnel site-to-site di lunga durata che trasporta dati regolamentati è il tipo di caso d'uso ad alto rischio a cui queste timeline puntano per primo, il che colloca il parco VPN tra le prime priorità anche quando il testo è una raccomandazione e non un obbligo.
Prossimo passo
Iniziate dall'inventario, perché è ciò che tutti questi testi richiedono: elencate ogni tunnel, la versione di IKE, il gruppo di scambio di chiavi negoziato, gli algoritmi ESP, il metodo di autenticazione e la durata di riservatezza dei dati trasportati. Poi scegliete un tunnel a basso rischio tra due peer che controllate e testate una proposta ibrida in staging, lasciando attivo un fallback classico.
PQC Status testa TLS, non IKEv2, quindi non vi dirà che cosa negozia il vostro gateway sulle porte UDP 500 e 4500. Resta comunque la verifica più rapida su tutto ciò che un parco VPN espone tramite HTTPS: portali web degli appliance, front end SSL-VPN, interfacce di gestione e di enrollment. Eseguite una scansione gratuita di questi hostname con PQC Status per verificare se offrono già uno scambio di chiavi ibrido ML-KEM, poi inviate le domande per i fornitori riportate sopra al vendor di ciascun gateway.