Gestione delle chiavi crittografiche: ciclo di vita, rotazione e scadenze

La gestione delle chiavi crittografiche stabilisce se la cifratura protegge davvero dati e comunicazioni o li protegge soltanto sulla carta. Un algoritmo solido serve a poco se la chiave è copiata in dieci posti, se la può usare chiunque o se nessuno ricorda quando scade. Questa guida segue la vita di una chiave dalla generazione alla distruzione e la confronta con le regole del NIST, del CA/B Forum, della direttiva NIS2 e del regolamento DORA.

Il tema è attuale per tre ragioni. Dal 15 marzo 2026 i certificati TLS pubblicamente attendibili non possono durare più di 200 giorni, come prevede il ballot SC-081v3 del CA/B Forum. Dopo il 21 settembre 2026 i certificati FIPS 140-2 passano nell’elenco storico del programma di validazione dei moduli crittografici del NIST. E la norma di riferimento sul ciclo di vita delle chiavi, la SP 800-57, ha una bozza di revisione che entra nell’era post-quantistica.

Perché la gestione delle chiavi crittografiche pesa più dell’algoritmo

Chi cifra un archivio, firma un software o apre un tunnel TLS affida la sicurezza a un segreto breve: la chiave. Se la chiave esce, l’algoritmo non può più difendere nulla. Per questo il NIST dedica alla gestione delle chiavi un’intera serie di raccomandazioni, la SP 800-57 parte 1, revisione 5, pubblicata nel maggio 2020.

Questo pezzo si colloca a valle di altri tre già pubblicati dalla testata. L’inventario delle primitive e delle chiavi in uso è l’oggetto della Cryptographic Bill of Materials. La capacità di sostituire un algoritmo senza fermare i sistemi è la crypto-agility. Il passaggio agli algoritmi resistenti ai computer quantistici è la migrazione alla crittografia post-quantum. Secondo la lettura della redazione, nessuno dei tre funziona se manca lo strato operativo descritto qui: sapere chi custodisce ogni chiave, per quanto tempo e con quali regole.

Il ciclo di vita di una chiave secondo il NIST

Quattro fasi e sei stati

Nella gestione delle chiavi crittografiche ogni chiave ha una vita, e ogni momento di quella vita ha regole proprie. La SP 800-57 la divide in quattro fasi: pre-operativa, operativa, post-operativa e di distruzione. Dentro queste fasi il documento definisce sei stati: pre-attivazione, attiva, sospesa, disattivata, compromessa e distrutta.

La distinzione ha un risvolto pratico. Una chiave disattivata non cifra più nuovi dati, ma può ancora servire a leggere quelli già protetti. Una chiave compromessa richiede invece un percorso diverso, perché va ritirata subito e può imporre di ricostruire ciò che ha protetto. La norma prevede per questo un piano di recupero dalla compromissione, da preparare prima che serva.

Il crittoperiodo: quanto può durare una chiave

Il NIST chiama crittoperiodo l’intervallo in cui una chiave è autorizzata all’uso. La Tabella 1 della revisione 5 propone valori orientativi per ogni tipo di chiave.

Le chiavi private di firma restano in uso da uno a tre anni. Le chiavi simmetriche di cifratura dei dati hanno un periodo di utilizzo per cifrare inferiore a due anni, mentre per decifrare si può arrivare al periodo di cifratura più tre anni. Le chiavi master e di derivazione durano circa un anno. Le chiavi effimere di accordo valgono una sola transazione.

Il documento precisa che periodi più lunghi o più brevi possono essere giustificati dal contesto, ma chi allunga il crittoperiodo deve valutare con attenzione i rischi. Ogni chiave, inoltre, dovrebbe servire a un solo scopo: usare la stessa chiave per cifrare e per firmare allarga i danni di una compromissione.

La revisione 6 in consultazione

Il 5 dicembre 2025 il NIST ha pubblicato la bozza iniziale della revisione 6; i commenti si sono chiusi il 5 febbraio 2026. Il testo aggiunge gli algoritmi post-quantistici e Ascon, inserisce una sezione separata sulla conservazione delle chiavi e rimanda i periodi di approvazione degli algoritmi alla SP 800-131A. Al 4 novembre 2026 sul sito del NIST non risulta una versione definitiva, quindi la revisione 5 resta il riferimento in vigore.

Dove vivono le chiavi: custodia delle chiavi, HSM e KMS cloud

L’HSM e lo standard FIPS 140-3

La custodia delle chiavi parte da una scelta di fondo: tenerle in un file, in un archivio software o in un dispositivo dedicato. L’HSM, hardware security module, è il dispositivo fisico pensato per generare e usare le chiavi senza esporle in chiaro al resto del sistema. Il livello di robustezza di questi moduli si misura con la FIPS 140-3, pubblicata il 22 marzo 2019, che prevede quattro livelli di sicurezza crescenti.

Il caso Storm-0558 mostra perché la scelta conta. Nel suo rapporto del marzo 2024, il Cyber Safety Review Board statunitense ricostruisce come gli aggressori abbiano usato una chiave di firma dell’account consumer Microsoft risalente al 2016. Il Board rileva che per quella chiave non esisteva una rotazione automatica, che la rotazione era stata interrotta nel 2021 e che nessun allarme segnalava l’età della chiave. Tra le raccomandazioni figurano l’uso di HSM e la rotazione automatica.

I KMS cloud: che cosa fa davvero la rotazione

Un key management system, o KMS, è il servizio che governa le chiavi: le crea, ne decide gli usi, le ruota e registra ogni operazione. I principali fornitori cloud ne offrono uno, e le loro documentazioni mostrano una differenza che si trascura spesso. La rotazione delle chiavi crea nuovo materiale crittografico, ma non ricifra i dati già protetti.

Nella documentazione di AWS KMS la rotazione automatica è attiva a 365 giorni per impostazione predefinita e si può configurare tra 90 e 2.560 giorni. Esiste anche la rotazione su richiesta. Per le chiavi asimmetriche, per quelle HMAC e per quelle dei key store personalizzati la rotazione è manuale, e il materiale importato può avere una data di scadenza. Le istruzioni di AWS per attivare la rotazione chiariscono i passaggi.

Google descrive nella guida alla rotazione di Cloud KMS un modello a versioni. Ruotare crea una nuova versione primaria, le versioni precedenti restano disponibili per decifrare e i dati esistenti non vengono ricifrati. Le chiavi asimmetriche non hanno una rotazione automatica. La distruzione di una versione è programmata, con un intervallo predefinito di 30 giorni in cui si può ancora tornare indietro.

La conseguenza è che ruotare la chiave del KMS non basta a ridurre l’esposizione dei dati già cifrati. Per quelli serve una ricifratura, che è un’operazione distinta e va pianificata. Secondo la redazione, è il motivo per cui conviene registrare per ogni chiave sia la data di rotazione sia i dati che dipendono dalle versioni precedenti.

Bring your own key: chi tiene davvero la chiave

Il modello bring your own key consente al cliente di generare la chiave in proprio e di importarla nel servizio del fornitore. Il servizio Azure Managed HSM di Microsoft, per esempio, è descritto come un servizio a singolo cliente basato su HSM validati FIPS 140-3 livello 3, con importazione di chiavi generate altrove.

Il vantaggio è il controllo sull’origine della chiave. Il limite, nella lettura della redazione, è che una chiave importata nel cloud viene comunque usata nell’infrastruttura del fornitore: la proprietà del materiale non coincide con la sua custodia. Per questo vanno decise per iscritto anche le regole di revoca, di esportazione e di cancellazione.

Chi può usare le chiavi: segregazione dei segreti e dei ruoli

Chi controlla le chiavi decide di fatto chi può leggere i dati. La SP 800-57 tratta la separazione delle responsabilità con due strumenti. Il primo è la conoscenza ripartita (split knowledge), in cui nessuna persona conosce una chiave per intero. Il secondo sono le quote di chiave (key shares), che richiedono più custodi per ricostruirla. È il nucleo della segregazione dei segreti: nessuno deve poter generare, approvare e usare da solo una chiave critica.

In pratica la redazione ricava da qui tre regole operative. Chi amministra il KMS non dovrebbe coincidere con chi usa le chiavi per i dati. Le chiavi che servono scopi diversi vanno separate, anche per limitare il raggio di un furto. E ogni accesso va registrato, perché senza traccia non si può dire a chi sia attribuibile un uso anomalo. La segregazione dei segreti applicativi, come password e token delle applicazioni, è un tema affine ma distinto, che appartiene al secrets management.

Ogni quanto si ruotano le chiavi

Nella gestione delle chiavi crittografiche la rotazione risponde a due esigenze diverse. La prima è programmata: limitare la quantità di dati protetti da una sola chiave e il tempo in cui un furto passato resta utile. La seconda è d’emergenza: sostituire subito una chiave compromessa.

Per la prima, il crittoperiodo del NIST dà un punto di partenza e i fornitori cloud propongono impostazioni predefinite, come i 365 giorni di AWS. Per la seconda non c’è calendario. Il CSRB, nel caso Storm-0558, individua proprio nella rotazione trascurata una delle cause che hanno prolungato il rischio.

Una buona politica, secondo la lettura della redazione, indica per ogni classe di chiavi la durata massima e il responsabile della rotazione. Prevede anche come si ricifrano i dati e quale procedura vale in emergenza. La rotazione automatica è preferibile, ma va provata: una chiave che cambia senza che le applicazioni sappiano riaprire i dati vecchi è un’interruzione di servizio pianificata.

La scadenza dei certificati: l’incidente più banale e più frequente

Un certificato è una chiave pubblica con una data di scadenza, e la scadenza dei certificati è la parte che viene dimenticata più spesso. Il caso più noto è quello di Equifax. Nel suo rapporto sulla violazione del 2017, la commissione Supervisione della Camera statunitense documenta che il certificato di un dispositivo per l’ispezione del traffico era scaduto da 19 mesi. Il dispositivo non poteva quindi esaminare il traffico cifrato.

Un secondo caso viene dal Regno Unito. Il 6 dicembre 2018, alle 4:30, la rete dell’operatore O2 ha perso i servizi dati 2G, 3G e 4G per quasi 23 ore. Il disservizio ha toccato i 25 milioni di clienti diretti e anche gli operatori virtuali che usano la rete. Nella decisione del 1° novembre 2019 l’autorità britannica Ofcom attribuisce il guasto al software SGSN-MME fornito da Ericsson. La scadenza di un certificato di sicurezza incorporato nel codice (hardcoded) ha mandato in errore il programma.

Ofcom non ha riscontrato violazioni da parte di O2: l’operatore aveva controlli contrattuali e test, e nessuno gli aveva segnalato il difetto prima dell’incidente. L’autorità ha però indicato una lezione. In futuro si aspetta che i fornitori di reti dimostrino di aver chiesto ai produttori garanzie su politiche di gestione dei certificati e sul loro rispetto durante lo sviluppo del software. Secondo la lettura della redazione, il caso mostra che la scadenza dei certificati riguarda anche quelli che l’azienda non vede, perché stanno dentro il software dei fornitori.

Il problema si aggrava perché le scadenze si accorciano. Le Baseline Requirements del CA/B Forum, nella versione 2.3.1, fissano la durata massima dei certificati TLS pubblici. Il limite è 200 giorni dal 15 marzo 2026, 100 giorni dal 15 marzo 2027 e 47 giorni dal 15 marzo 2029. Il riuso della convalida del dominio scende in parallelo a 200, 100 e 10 giorni. Le stesse regole richiedono la revoca entro 24 ore quando la chiave privata di un certificato è compromessa.

Con 47 giorni di validità il rinnovo manuale diventa impraticabile. La risposta è l’automazione con il protocollo ACME, definito dall’IETF nella RFC 8555. Le regole del Forum riguardano i certificati pubblici, non le infrastrutture a chiave pubblica interne. La redazione ritiene tuttavia prudente allineare anche queste, perché una scadenza dimenticata non distingue tra certificati interni ed esterni.

Che cosa chiedono le norme europee e italiane

La direttiva NIS2 impone ai soggetti essenziali e importanti, all’articolo 21, paragrafo 2, lettera h), politiche e procedure sull’uso della crittografia e, se del caso, della cifratura. In Italia la stessa lettera è riportata nell’articolo 24, comma 2, del d.lgs. 138/2024. La norma di principio non dice però come si gestiscono le chiavi.

Il dettaglio compare in due testi settoriali. Il regolamento di esecuzione (UE) 2024/2690 contiene nell’allegato, al punto 9, un elenco articolato di misure sulla gestione delle chiavi. Si applica però solo a categorie definite. Sono i fornitori di servizi DNS, i registri di nomi di dominio di primo livello, i fornitori di cloud computing e di data center e le reti di distribuzione dei contenuti. Rientrano anche i gestori di servizi gestiti e di sicurezza gestiti, i mercati online, i motori di ricerca, le piattaforme di social network e i prestatori di servizi fiduciari.

Per gli enti finanziari il regolamento delegato (UE) 2024/1774, norma tecnica del DORA, dedica l’articolo 6 alla cifratura e l’articolo 7 alla gestione delle chiavi. L’articolo 7 chiede una politica che copra l’intero ciclo di vita delle chiavi, un registro dei certificati e dei dispositivi che li conservano, e il rinnovo dei certificati prima della scadenza. Vale per il quadro ordinario di gestione del rischio ICT; il quadro semplificato non contiene disposizioni sulla crittografia.

La lettura della redazione è che esista un vuoto. La parte più dettagliata sulle chiavi è in testi settoriali o nel NIST, mentre la base italiana per la maggior parte dei soggetti non indica come gestirle. Chi non rientra nei settori coperti può comunque usare la SP 800-57 e l’articolo 7 del DORA come misura di confronto per la propria gestione delle chiavi crittografiche. La pagina del NIST sulla gestione delle chiavi indica anche la Parte 2 della serie, rivolta alle organizzazioni che devono scrivere politiche e dichiarazioni di prassi per le chiavi.

Come impostare la gestione delle chiavi crittografiche in cinque passi

Questi passi sono una proposta della redazione, costruita sulle fonti citate, non un obbligo di legge.

1. Censire. Elencare chiavi, certificati e dati che proteggono. L’inventario è la base della CBOM e senza di esso nessuna scadenza è sotto controllo.
2. Assegnare. Dare a ogni chiave un responsabile e un solo scopo, separando chi amministra il KMS da chi usa le chiavi.
3. Fissare il crittoperiodo. Partire dai valori del NIST, adattarli al rischio e scrivere chi ruota, quando e come si ricifrano i dati.
4. Automatizzare i certificati. Adottare ACME, tenere un registro con le scadenze e un allarme che scatti ben prima, con l’obiettivo dei 47 giorni del 2029.
5. Provare il recupero. Simulare una compromissione, la revoca e la distruzione di una chiave: è l’unico modo per sapere se la procedura regge.

Chi ha questi cinque passi in ordine ha anche il presupposto per la crypto-agility: sostituire un algoritmo diventa un’operazione di gestione delle chiavi crittografiche, non un’emergenza.

Domande frequenti

Che cos'è la gestione delle chiavi crittografiche?

È l'insieme di regole e strumenti che governano la vita delle chiavi: generazione, uso, conservazione, rotazione, sospensione, revoca e distruzione. La SP 800-57 del NIST la descrive in quattro fasi e sei stati.

Ogni quanto si ruotano le chiavi crittografiche?

Il NIST suggerisce da uno a tre anni per le chiavi private di firma e meno di due anni per le chiavi simmetriche di cifratura dei dati. AWS KMS ruota per impostazione predefinita ogni 365 giorni. Una chiave compromessa va sostituita subito.

Che differenza c'è tra KMS e HSM?

Il KMS è il servizio che governa le chiavi: crea, assegna gli usi, ruota e registra gli accessi. L'HSM è il dispositivo fisico che custodisce e usa le chiavi; il suo livello di sicurezza si misura con la FIPS 140-3.

Quanto durano i certificati TLS dopo il 2026?

Secondo le Baseline Requirements del CA/B Forum, 200 giorni dal 15 marzo 2026, 100 giorni dal 15 marzo 2027 e 47 giorni dal 15 marzo 2029. Valgono per i certificati pubblici, non per le infrastrutture a chiave pubblica interne.

La NIS2 obbliga a gestire le chiavi crittografiche in un modo preciso?

L'articolo 21 chiede politiche sull'uso della crittografia ma non entra nel dettaglio. Le misure sulle chiavi sono dettagliate nel regolamento 2024/2690 per alcune categorie di fornitori e nel regolamento delegato 2024/1774 per gli enti finanziari.