La crittografia attuale, basata su RSA ed ECC, è destinata a cedere il passo ai più moderni computer quantistici, la minaccia “Harvest Now, Decrypt Later” ormai è un rischio già presente che le aziende devono considerare. Oggi e in futuro, quindi, vi è la necessità di adottare la “Crypto Agility”: infrastrutture capaci di sostituire algoritmi e chiavi senza riscrivere il codice, abbracciando gli standard NIST post-quantistici attraverso inventario, disaccoppiamento, schemi ibridi e governance continua.
Indice degli argomenti
Crypto agility: perché le infrastrutture devono cambiare
Chi ha realizzato nel tempo un sistema di sicurezza informatico per la propria azienda ha sicuramente fondato il proprio modus operandi su un presupposto che oggi mostra evidenti limiti, ossia la longevità decennale dei meccanismi di cifratura. Infatti, metodi classici come RSA e le curve ellittiche sono stati implementati a fondo nei server, nei programmi gestionali, nei database e nei canali di autenticazione. Con i progressi costanti dei calcolatori quantistici e la diffusione teorica dell’algoritmo di Shor, queste formule matematiche rischiano di diventare inefficaci in tempi brevi, lasciando scoperte le comunicazioni aziendali.
Vi è però una soluzione molto interessante come la Crypto Agility, ovvero la capacità di un’infrastruttura di rinnovare, sostituire o potenziare i componenti crittografici riducendo al minimo l’impatto sul lavoro di tutti i giorni. Un ambiente agile non costringe i team tecnici a rimettere mano a migliaia di righe di codice ogni volta che una chiave mostra debolezze o viene dichiarata obsoleta. La gestione dei cifrari si sposta verso configurazioni dinamiche, centralizzate e facili da aggiornare attraverso semplici direttive applicate dall’esterno.
Che cos’è l’intercettazione preventiva
Un motivo di grande impatto per accelerare questo cambiamento è la minaccia conosciuta come intercettazione preventiva, spesso riassunta nella formula inglese che prevede di raccogliere dati cifrati oggi per decifrarli domani. Gli Organi preposti e servizi di spionaggio industriale stanno già accumulando volumi consistenti di traffico internet protetto. Anche se tali pacchetti restano illeggibili per le macchine attuali, basterà un computer quantistico operativo fra qualche anno per svelarne il contenuto. Chi custodisce brevetti industriali, cartelle cliniche o dati bancari con valore a lungo termine è potenzialmente vulnerabile anche con una buona infrastruttura IT.
A questa condizione negativa vi sono anche tutte quelle criticità legate alle scadenze normative molto stringenti, a partire da regolamenti come NIS2 e DORA in Europa, fino ai requisiti per i pagamenti elettronici e alle direttive governative internazionali. Così come non bisogna trascurare la durata temporale dei certificati digitali che si sta accorciando continuamente, passando da diversi anni a pochi mesi, con proiezioni che indicano scadenze nell’ordine di poche settimane. Gestire questi passaggi operativamente a mano è oggettivamente impensabile; serve quindi un’architettura elastica in grado di cambiare dinamicamente con un semplice intervento di configurazione.
Standard NIST e migrazione alla crittografia post-quantistica
Il National Institute of Standards and Technology ha pubblicato i primi schemi definitivi, identificati dalle denominazioni FIPS 203, FIPS 204 e FIPS 205. Questi protocolli derivano da un lavoro di selezione durato quasi dieci anni e forniscono gli strumenti pratici per proteggere sia lo scambio di chiavi segrete sia le firme digitali usate per autenticare utenti, server e dispositivi. Ma cosa identifica più nel dettaglio?
ML-KEM, ML-DSA e SLH-DSA: funzioni e impieghi
Il protocollo FIPS 203 deriva dal progetto CRYSTALS-Kyber e prende il nome tecnico di ML-KEM. Si occupa di incapsulare e scambiare chiavi segrete su canali aperti, prendendo il posto delle più comuni procedure Diffie-Hellman e dei meccanismi basati su RSA. Il suo punto di forza è la geometria dei reticoli multidimensionali, poiché trovare una combinazione esatta in mezzo a un disturbo casuale risulta un compito proibitivo perfino per un computer quantistico.
Esistono tre gradini di protezione, dal livello base indicato con il numero 512, fino al livello intermedio 768 e a quello massimo identificato da 1024, concepito per i sistemi di difesa e le infrastrutture critiche governative.
Il secondo protocollo, FIPS 204, nasce dal progetto CRYSTALS-Dilithium e prende la sigla ML-DSA. Questo algoritmo si fa carico delle firme digitali, sostituendo i vecchi certificati RSA ed ECDSA nei passaggi di autenticazione web, nella validazione dei documenti e nei token di sessione. Anche in questo caso specifico i calcoli sfruttano le proprietà geometriche dei reticoli, offrendo una risposta robusta ed equilibrata per la maggioranza delle connessioni aziendali ordinarie.
C’è poi il protocollo FIPS 205, questo si basa sull’algoritmo SPHINCS+ e viene classificato come SLH-DSA. A differenza dei primi due sistemi, non ricorre alla matematica dei reticoli ma si fonda esclusivamente sulle proprietà di dispersione delle funzioni di hash, le medesime formule matematiche unidirezionali usate da decenni per verificare l’integrità dei file. Questa impostazione serve da paracadute; infatti, se un giorno i reticoli dovessero mostrare criticità non previste sul piano teorico, questo schema rimarrebbe intatto, risultando ideale per firmare firmware industriali o certificati radice che richiedono la massima prudenza.
Chiavi più grandi: gli effetti su banda e latenza
I nuovi metodi matematici mostrano un comportamento molto diverso rispetto alle soluzioni del passato; se sul fronte dell’impegno del processore le operazioni risultano veloci e poco gravose, il vero collo di bottiglia risiede nello spazio fisico occupato dai dati crittografici. Le chiavi pubbliche e le firme post-quantistiche pesano decine o centinaia di volte più rispetto alle vecchie controparti a curve ellittiche.
Una chiave classica a curve ellittiche occupa appena qualche decina di byte, mentre una chiave per lo scambio post-quantistico supera agevolmente il migliaio di byte. Ciò si amplifica ancor di più nelle firme digitali, dove un singolo attestato può richiedere diversi kilobyte di memoria. Quando questi pacchetti viaggiano sulle reti aziendali o sulle connessioni mobili, rischiano di superare le dimensioni massime dei singoli segmenti di rete, costringendo i router a spezzettare le comunicazioni in più frammenti. Ovviamente anche una rete, locale o in cloud, di qualità non riesce a supportare tutto il carico richiesto.
Questa frammentazione genera ritardi nell’apertura delle connessioni protette e aumenta le probabilità che qualche pacchetto vada smarrito lungo il percorso, rendendo necessarie ritrasmissioni continue. Risulta particolarmente evidente sulle catene di certificati dei server web, dove la somma dei certificati intermedi e delle firme può quadruplicare il carico iniziale, mettendo sotto pressione i bilanciatori di carico e i sistemi per la gestione dei flussi applicativi.
Architetture flessibili per aggiornare la crittografia
Rendere un’infrastruttura elastica richiede una revisione strutturale dei programmi aziendali. Inserire chiamate rigide a librerie di sicurezza direttamente nelle pagine web o nelle logiche interne delle applicazioni blocca qualsiasi tentativo di rinnovamento e moltiplica i costi operativi nel medio termine.
Separare la sicurezza dal codice e censire gli algoritmi
Le applicazioni aziendali devono, prima di tutto, concentrarsi sui compiti operativi e delegare i dettagli della sicurezza a componenti esterni. Nelle architetture moderne basate su container e microservizi, questo obiettivo si raggiunge affidando la gestione delle connessioni a intermediari di rete, come i proxy dedicati, i service mesh e i varchi di accesso per i servizi web. In questo modo le regole di cifratura si aggiornano modificando un file di impostazioni centralizzato o una policy di deployment, senza toccare il programma sorgente.
Nei casi in cui invece il software debba cifrare i dati internamente, conviene sfruttare interfacce modulari che consentono di richiamare i servizi di protezione tramite nomi logici generici anziché tramite formule fisse. Cambiando il modulo sottostante nei componenti del sistema operativo o nelle librerie condivise, il software riceve i nuovi algoritmi in modo del tutto trasparente, senza obbligare a ricompilare l’intero applicativo.
Ovviamente, un tassello operativo di grande utilità è la creazione di un inventario crittografico dettagliato dei programmi in uso. Si tratta di un registro elettronico generato tramite strumenti automatici di scansione del codice e analisi del traffico di rete, che è capace di elencare chiavi, certificati, librerie e algoritmi attivi nell’azienda. Disporre di questa mappa aggiornata evita controlli manuali su fogli di calcolo e permette di capire subito quali componenti contengano ancora formule obsolete o vulnerabili.
KMS e rinnovo automatico dei certificati
Lasciare certificati e chiavi segrete sul proprio apparato informatico tra cartelle di sistema e file di testo elimina buona parte delle possibilità di intervenire. La soluzione, quindi, consiste nell’adottare sistemi centralizzati per la gestione delle chiavi, affiancati da moduli hardware protetti progettati per custodire i segreti aziendali. Questi strumenti mettono a disposizione canali di comunicazione unificati verso cui convergono tutte le richieste di firma e cifratura delle applicazioni.
Nel momento in cui bisogna rafforzare una chiave o sostituire un algoritmo, l’amministratore interviene unicamente sulle regole del sistema centrale; tutte le applicazioni collegate adottano la novità all’istante, senza fermi operativi o riconfigurazioni sui singoli server.
Allo stesso tempo si rende doveroso automatizzare il rinnovo dei certificati tramite protocolli standard di gestione remota. Con la progressiva riduzione della durata temporale dei certificati, affidarsi a scadenze annotate sui calendari espone al blocco dei siti e dei portali aziendali. Moltissime aziende stanno lavorando anche per verificare che i dispositivi hardware di protezione già installati nei centri elaborazione dati dispongano di memoria interna sufficiente e firmware aggiornati per archiviare chiavi voluminose come quelle post-quantistiche.
Algoritmi classici e PQC: il confronto per una transizione ibrida
Il divario tra vecchi e nuovi metodi emerge soprattutto dalle dimensioni dei parametri scambiati. Sistemi tradizionali come RSA-2048 o le curve ellittiche impiegano chiavi e firme minime, comprese tra 32 e 256 byte, garantendo flussi di rete leggeri. Gli algoritmi post-quantistici ribaltano questo equilibrio; infatti, ML-KEM richiede chiavi pubbliche superiori al kilobyte per lo scambio dati, mentre ML-DSA genera firme oltre i 3.300 byte, appesantendo sensibilmente le catene di certificati web.
La famiglia SLH-DSA produce payload ancora più ampi, arrivando a firme tra gli 8 e i 17 kilobyte a fronte di chiavi contenute. Poiché il sovraccarico si sposta dal processore alla banda di rete, conviene attivare modalità ibride durante la transizione. Affiancare una formula classica a una post-quantistica nello stesso handshake protegge sin da subito dalle registrazioni non previste senza rischiare incompatibilità improvvise.
Come portare la crypto agility in azienda: le priorità operative
Guidare la modernizzazione dei sistemi verso la Crypto Agility presuppone un cammino ordinato, diviso in traguardi progressivi e sostenibili.
Step 1 – Perlustrazione automatica delle risorse crittografiche
Il primo passo concreto consiste nell’avviare una perlustrazione automatica di tutte le risorse crittografiche presenti nei server, nei servizi cloud e nei programmi interni. Da questo lavoro deve scaturire una distinta base dei componenti di sicurezza, da aggiornare di continuo ogni volta che viene rilasciata una nuova versione dei software aziendali.
Step 2 – Suddivisione delle priorità
Il secondo fattore riguarda la suddivisione delle priorità in base al rischio effettivo. Non occorre cambiare tutto insieme dall’oggi al domani. La precedenza va accordata ai canali di collegamento esposti su internet e agli archivi contenenti informazioni che devono rimanere segrete per dieci o venti anni, come dati sanitari o brevetti di ricerca. I sistemi interni oppure i flussi con dati volatili possono essere aggiornati in un secondo momento con calma.
Step 3 – Disaccoppiamento architetturale
Il terzo step prevede di inserire il disaccoppiamento architetturale nei varchi di rete e di abilitare subito le connessioni ibride sui bilanciatori di carico e sui server web principali. Al contempo, le linee guida interne di sviluppo devono vietare l’inserimento di parametri crittografici rigidi nei nuovi programmi, orientando i progetti verso varchi e interfacce flessibili.
Step 4 – Adeguamento dei moduli hardware di sicurezza e dei servizi di certificazione
Come quarto elemento c’è poi il passaggio all’adeguamento dei moduli hardware di sicurezza e dei servizi di certificazione interni. Conviene verificare sul campo che i dispositivi fisici supportino i nuovi standard di calcolo e introdurre meccanismi automatizzati per il rilascio e la sostituzione dei certificati web, eliminando le incombenze manuali.
Step 5 – Un piano di dismissione degli algoritmi obsoleti
Nell’ultimo passaggio bisogna stabilire un piano formale di dismissione degli algoritmi obsoleti, definendo scadenze precise allineate con gli obblighi di legge. Trattare l’adeguamento crittografico come una normale abitudine di manutenzione infrastrutturale, anziché come un’emergenza isolata, consente all’azienda di proteggere i propri beni digitali contro qualsiasi salto generazionale della tecnologia.
Partecipa alla community