Oracle sta estendendo il supporto alla crittografia post-quantum all’interno della piattaforma Java, con l’obiettivo di permettere alle applicazioni esistenti di adottare algoritmi resistenti ai futuri attacchi basati su computer quantistici senza richiedere una completa riscrittura dell’infrastruttura crittografica. Il passaggio più recente è arrivato con Java 27, disponibile dal 15 settembre 2026, che introduce uno scambio di chiavi ibrido post-quantum per TLS 1.3 e completa una prima serie di componenti necessarie per integrare la PQC nello stack standard del JDK. Oracle sta parallelamente lavorando per portare queste capacità anche sulle versioni Long-Term Support già diffuse negli ambienti enterprise, comprese JDK 25, 21, 17, 11 e 8.
La novità principale di Java 27 è JEP 527, Post-Quantum Hybrid Key Exchange for TLS 1.3. Il meccanismo combina un algoritmo crittografico tradizionale con un algoritmo progettato per resistere agli attacchi quantistici, in modo che la sicurezza della sessione non dipenda esclusivamente da una delle due tecniche. L’approccio ibrido permette quindi di conservare la protezione offerta dagli algoritmi classici già ampiamente utilizzati e, contemporaneamente, aggiungere una componente post-quantum. In questo modo le applicazioni Java che utilizzano TLS 1.3 possono iniziare la transizione verso una protezione resistente ai computer quantistici senza abbandonare immediatamente gli algoritmi attuali.
Il problema affrontato riguarda soprattutto il cosiddetto modello “harvest now, decrypt later”. Un attaccante può intercettare oggi traffico cifrato e conservarlo con l’obiettivo di decifrarlo in futuro, nel momento in cui sistemi quantistici sufficientemente potenti dovessero rendere vulnerabili alcuni algoritmi a chiave pubblica attualmente utilizzati. Per questo motivo la migrazione verso la crittografia post-quantum viene considerata rilevante anche prima della disponibilità di computer quantistici capaci di eseguire concretamente questi attacchi: dati con una lunga vita utile o informazioni sensibili trasmesse oggi potrebbero infatti rimanere interessanti anche tra molti anni.
Java aveva già iniziato questa transizione nelle release precedenti. JDK 24 ha introdotto implementazioni degli algoritmi ML-KEM e ML-DSA, standardizzati rispettivamente dal NIST attraverso FIPS 203 e FIPS 204. ML-KEM è un meccanismo di incapsulamento delle chiavi destinato alla creazione sicura di segreti condivisi, mentre ML-DSA è un algoritmo di firma digitale post-quantum. La Java Cryptography Architecture riconosce inoltre i diversi set di parametri previsti dagli standard, compresi ML-KEM-512, ML-KEM-768 e ML-KEM-1024, insieme a ML-DSA-44, ML-DSA-65 e ML-DSA-87.
L’integrazione attraverso la Java Cryptography Architecture è un elemento importante della strategia Oracle. Gli sviluppatori possono utilizzare i nuovi algoritmi attraverso le API crittografiche standard di Java invece di dover introdurre necessariamente librerie esterne o interfacce specifiche per ogni implementazione. Lo stesso principio viene applicato a TLS: le applicazioni che già utilizzano lo stack TLS del JDK possono beneficiare progressivamente delle nuove capacità attraverso aggiornamenti della piattaforma e modifiche di configurazione, limitando gli interventi sul codice applicativo. Oracle indica proprio la riduzione dell’impatto sulle applicazioni esistenti come uno degli obiettivi principali della propria roadmap PQC.
La transizione non riguarda soltanto le nuove versioni di Java. Oracle ha avviato un piano di backport per rendere le funzioni post-quantum disponibili anche sulle release LTS utilizzate da molte infrastrutture aziendali. La roadmap comprende JDK 25, 21, 17, 11 e 8. Alcuni prerequisiti sono già stati portati indietro: l’API KEM, Key Encapsulation Mechanism, introdotta originariamente in JDK 21, è stata successivamente incorporata anche nella specifica Java SE 17 attraverso una Maintenance Release. Questo lavoro permette di introdurre algoritmi come ML-KEM anche in versioni precedenti senza richiedere la migrazione immediata verso il JDK più recente.
Secondo la roadmap comunicata da Oracle, JDK 25 dovrebbe raggiungere la parità funzionale con le capacità post-quantum di JDK 27 attraverso il Critical Patch Update previsto per ottobre 2026. Per le release ancora precedenti l’estensione richiede interventi più complessi, perché alcune delle API necessarie non erano originariamente presenti nelle rispettive specifiche Java SE. Il progetto deve quindi coordinare sia il backport delle implementazioni crittografiche sia l’evoluzione delle API standard richieste per utilizzarle.
Oracle sta intervenendo anche sul proprio provider crittografico Jipher. La versione Jipher 20, annunciata il 15 settembre 2026, aggiunge il supporto agli algoritmi post-quantum e amplia la compatibilità a Java 17, 21, 25 e 27. Jipher è un Java Cryptographic Service Provider destinato agli ambienti che richiedono servizi crittografici conformi agli standard FIPS e rende queste funzioni disponibili attraverso le normali interfacce della Java Cryptography Architecture. Con la nuova versione Oracle sta quindi portando le primitive post-quantum anche negli ambienti Java soggetti a requisiti di conformità crittografica più stringenti.
L’adozione di uno scambio di chiavi ibrido in TLS 1.3 permette inoltre una migrazione graduale. Invece di sostituire in un solo passaggio tutti i meccanismi esistenti, la sessione utilizza contemporaneamente una componente classica e una componente post-quantum. L’obiettivo è mantenere compatibilità e affidabilità durante una fase nella quale algoritmi, implementazioni e infrastrutture PQC continueranno ancora a evolvere. Per un’applicazione Java che utilizza le API TLS standard, gran parte di questa complessità rimane all’interno del runtime e del provider crittografico anziché essere gestita direttamente dal codice applicativo.
La scelta di intervenire anche sulle vecchie versioni LTS è legata alla struttura del parco applicativo Java. Molte applicazioni enterprise rimangono infatti per anni sulla stessa major release e non possono essere migrate immediatamente ogni volta che viene pubblicata una nuova versione del JDK. Limitare la protezione post-quantum a Java 27 avrebbe quindi lasciato fuori una parte significativa dei sistemi in produzione. La strategia Oracle punta invece a rendere disponibili gli stessi elementi crittografici attraverso gli aggiornamenti delle release supportate, consentendo alle aziende di separare la migrazione crittografica dalla più ampia modernizzazione delle applicazioni.
Java 27 non è una release LTS: l’attuale versione Long-Term Support è Java 25, mentre la prossima LTS è prevista con Java 29 nel settembre 2027 secondo la roadmap Oracle attuale. Per questo motivo il backport verso Java 25 assume particolare importanza per gli ambienti enterprise che preferiscono restare sulle versioni con supporto a lungo termine. Oracle prevede inoltre di continuare ad aggiornare la propria roadmap crittografica man mano che gli standard post-quantum e il relativo supporto nei protocolli di rete evolvono.
L’introduzione della PQC in Java viene quindi sviluppata su più livelli: algoritmi standardizzati come ML-KEM e ML-DSA nella Java Cryptography Architecture, scambio di chiavi ibrido nel TLS 1.3 di Java 27, supporto nei provider crittografici come Jipher e backport progressivo verso le release LTS precedenti. La scelta consente di affrontare la transizione post-quantum all’interno dello stack Java stesso, mantenendo per quanto possibile le API e i meccanismi di deployment già utilizzati dalle applicazioni esistenti.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)