Agilità crittografica: definizione e come integrarla nei sistemi

L’agilità crittografica (crypto agility) è la capacità di un sistema di cambiare i propri algoritmi, parametri e chiavi crittografici senza riscrivere il codice applicativo e senza attendere una nuova release del prodotto. Non è una funzionalità che si acquista: è un insieme di proprietà ingegneristiche, principalmente la configurazione al posto di scelte codificate nel codice, la negoziazione a livello di protocollo, un inventario aggiornato, confini di astrazione puliti e cicli di vita automatizzati di chiavi e certificati. Le autorità di regolamentazione descrivono ormai la stessa capacità con parole proprie: ad esempio, le norme tecniche DORA richiedono una politica di cifratura che preveda disposizioni per cambiare la tecnologia crittografica in funzione degli sviluppi della crittoanalisi.

Che cosa significa agilità crittografica

Una definizione operativa utile: un sistema è crittograficamente agile quando un operatore competente può sostituire un algoritmo, una dimensione di chiave o una versione di protocollo in una finestra di modifica controllata, usando configurazione e automazione già esistenti, e può dimostrare in seguito che cosa è ora in uso. La verifica è operativa, non teorica. Se cambiare un gruppo di scambio di chiavi significa modificare il codice sorgente, ricostruire un’immagine container, rinegoziare con un fornitore o scoprire dipendenze non documentate, il sistema non è agile, qualunque cosa affermi la sua documentazione.

Vale la pena tenere presenti tre distinzioni:

• L’agilità non equivale alla preparazione post-quantistica. La crittografia post-quantistica (PQC) è una destinazione. L’agilità è il veicolo. Un server che oggi offre uno scambio di chiavi ibrido post-quantistico ma non può cambiarlo l’anno prossimo ha risolto una migrazione e non si è preparato a nessuna delle successive.
• L’agilità non è solo negoziazione. Transport Layer Security (TLS) negozia. I formati dei dati archiviati, il firmware firmato, i moduli di sicurezza hardware (HSM), i terminali di pagamento e i dispositivi embedded spesso no. È lì che l’agilità va progettata anziché configurata.
• L’agilità ha un ordine di priorità. Harvest now, decrypt later (HNDL, «raccogli ora, decifra dopo») descrive il traffico registrato che un avversario conserva finché la decifratura non diventa possibile. Le sessioni registrate sono protette solo dallo scambio di chiavi, ed è per questo che la definizione delle chiavi migra per prima e le firme possono seguire. Il nostro articolo su harvest now, decrypt later spiega questo ordine in dettaglio.

Configurazione anziché codice, negoziazione anziché valori fissi

La prima proprietà è che la selezione degli algoritmi risiede in una configurazione di cui è responsabile un operatore, in un unico punto per host o per servizio, e viene riesaminata come qualsiasi altro controllo. Una politica crittografica centralizzata è preferibile a flag specifici per applicazione, perché sono proprio i flag per applicazione a essere dimenticati.

TLS: gruppi denominati e un elenco di preferenze ordinato

In TLS 1.3 lo scambio di chiavi è un gruppo denominato (named group), negoziato per ogni connessione. Il registro della Internet Assigned Numbers Authority (IANA) elenca i gruppi ibridi X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) e SecP384r1MLKEM1024 (0x11ED), accanto ai gruppi ML-KEM puri (parametri TLS IANA). ML-KEM è il meccanismo di incapsulamento delle chiavi (KEM) standardizzato dal NIST nel FIPS 203 il 13 agosto 2024. L’RFC 10024 (agosto 2026) specifica l’accordo di chiavi ibrido post-quantistico e tradizionale per TLS 1.3.

Una configurazione agile indica una preferenza ordinata e mantiene un fallback classico, in modo che un client che non supporta il gruppo ibrido riesca comunque a connettersi. Per i gruppi ML-KEM è necessario OpenSSL 3.5 o successivo:

# /etc/ssl/openssl.cnf (OpenSSL 3.5 or later)
openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Groups = X25519MLKEM768:X25519:P-256
MinProtocol = TLSv1.2

Verificate dall’esterno prima e dopo ogni modifica, con un test in sola lettura:

# read-only test: does the server accept the hybrid group?
openssl s_client -groups X25519MLKEM768 -connect example.com:443 < /dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

A livello di server web la stessa preferenza è una sola direttiva, ad esempio ssl_ecdh_curve X25519MLKEM768:X25519; in nginx compilato con un OpenSSL adeguato. La nostra guida per abilitare ML-KEM su nginx, Apache, HAProxy e Caddy riporta la sintassi per ciascun prodotto e le versioni minime. Testate prima in staging e mantenete il gruppo di fallback.

SSH: lo stesso schema, già distribuito

OpenSSH è un buon modello di agilità nella pratica. La versione 9.0 (8 aprile 2022) ha reso predefinito uno scambio di chiavi ibrido. La versione 9.9 (19 settembre 2024) ha aggiunto mlkem768x25519-sha256. La versione 10.0 (9 aprile 2025) lo ha reso l’accordo di chiavi predefinito, e la 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiavi non post-quantistico, tramite WarnWeakCrypto, abilitato per impostazione predefinita (note di rilascio di OpenSSH). Gli operatori che avevano espresso le preferenze nella configurazione hanno ereditato la modifica; quelli che avevano fissato un singolo algoritmo negli script no.

# list what this client supports, then set an ordered preference
ssh -Q kex

# /etc/ssh/sshd_config (OpenSSH 9.9 or later), classical fallback last
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Inventario, astrazione e automazione

Un inventario interrogabile, non un foglio di calcolo da riscrivere

Non si può cambiare ciò che non si sa elencare. Un inventario giustifica la propria esistenza quando risponde a una domanda in pochi minuti: quali servizi negoziano ancora uno scambio di chiavi solo classico, quali certificati usano quale algoritmo di firma, quali librerie forniscono le primitive e chi è responsabile di ciascuno. Registrate almeno l’asset, il protocollo e la versione, gli algoritmi e le dimensioni delle chiavi, la finalità, il responsabile, la versione della libreria o del modulo e il meccanismo di rinnovo. Una distinta base crittografica (CBOM) è un modo leggibile dalle macchine per conservare queste informazioni; consultate che cos’è una CBOM. Considerate la CBOM come una pratica da noi suggerita e non come un obbligo di legge.

Livelli di astrazione che nascondono l’algoritmo

Il codice applicativo dovrebbe richiedere una capacità, non un nome. Quattro schemi offrono la maggior parte del beneficio:

• Passare attraverso un provider o una libreria interna leggera. Un unico modulo traduce la politica in primitive, così una sola modifica si propaga ovunque.
• Versionare ogni formato archiviato. Anteponete a testi cifrati, token e buste firmate un identificativo di algoritmo e una versione del formato, così i dati vecchi restano leggibili mentre quelli nuovi usano il nuovo algoritmo.
• Non dare mai per scontate le dimensioni. Le chiavi pubbliche e i testi cifrati ML-KEM, così come le firme ML-DSA, sono considerevolmente più grandi dei loro equivalenti a curve ellittiche. Colonne di database a lunghezza fissa, buffer fissi, limiti di dimensione dei messaggi e campi di protocollo dimensionati per chiavi da 32 byte sono l’ostacolo bloccante più comune. Preferite campi con prefisso di lunghezza.
• Mantenere un doppio percorso di verifica. Accettate e verificate sia il vecchio sia il nuovo algoritmo durante la transizione, quindi rimuovete il vecchio secondo un calendario con date definite.

Chiavi e certificati che ruotano senza intervento umano

Una rotazione eseguita a mano una volta l’anno non è un controllo, è una prova generale destinata a fallire. Emissione e rinnovo automatizzati, durate brevi dei certificati e un allarme su ogni certificato non rinnovato sono ciò che rende ordinaria la modifica di un algoritmo: quando cambia l’algoritmo di firma, la pipeline emette semplicemente certificati diversi. Le esercitazioni di rotazione vanno inserite nel calendario delle modifiche. Le firme basate su hash con stato (LMS e XMSS, standardizzate nel NIST SP 800-208) sono un’eccezione che conferma la regola: la gestione dello stato rende insicura la duplicazione ingenua di una chiave di firma, per cui richiedono una gestione delle chiavi deliberata anziché un’automazione generica.

Dove la normativa richiede agilità, e quali evidenze sono adeguate

Diversi testi richiedono questa capacità senza usarne il nome. La tabella distingue ciò che ciascun testo dice letteralmente dal modo in cui suggeriamo di documentarlo. Si tratta di informazioni, non di consulenza legale: verificate i vostri obblighi con il vostro consulente legale o la vostra autorità di vigilanza.

Leggete il testo esatto nel Regolamento (EU) 2024/1774 e consultate le nostre pagine su DORA e PCI DSS v4.0.1 per le scadenze datate. Mantenete le giuste cautele: la EU Coordinated Implementation Roadmap v1.1 è una guida coordinata per gli Stati membri e non un regolamento vincolante per le imprese, il BSI TR-02102-1 è una linea guida tecnica, l’ANSSI dichiara che le sue raccomandazioni post-quantistiche non sono ancora obblighi normativi al di fuori del proprio ambito regolamentato, e il NIST IR 8547 resta una bozza pubblica iniziale.

Insidie che vanificano silenziosamente l’agilità

• Fissare un singolo algoritmo nel codice o negli script invece di esprimere una preferenza ordinata nella configurazione.
• Rimuovere troppo presto il fallback classico. Mantenete X25519 dopo X25519MLKEM768 finché la vostra popolazione di client non è stata misurata.
• Conservare gruppi pre-standard obsoleti. I gruppi TLS Kyber in bozza sono obsoleti: passate a X25519MLKEM768 e agli altri ibridi registrati.
• Un inventario senza responsabili. Un elenco di cui nessuno risponde non produce cambiamento.
• Dimenticare gli artefatti di lunga durata: firmware firmato, firme di documenti, backup e dati archiviati sopravvivono ai sistemi che li hanno creati.

Misurate ciò che i vostri sistemi negoziano oggi

L’agilità parte da una baseline onesta, e la sua parte visibile dall’esterno si ottiene rapidamente: analizzate il vostro dominio con PQC Status per vedere quali versioni TLS, suite di cifratura, gruppi di scambio di chiavi e algoritmi dei certificati il vostro server negozia effettivamente. Una scansione descrive solo la configurazione TLS visibile dall’esterno: non è una certificazione né un’attestazione di conformità, come spiega la nostra pagina sulla metodologia. Il passo successivo concreto è prendere quel risultato, registrare ogni servizio nel vostro inventario crittografico con un responsabile, quindi spostare la selezione degli algoritmi di un servizio in una configurazione centralizzata ed esercitarvi a cambiarla in staging.