Migrare la firma del codice a ML-DSA: un piano pratico

La firma del codice segue tempi diversi rispetto a TLS. Il traffico registrato è protetto solo dallo scambio di chiavi, ed è per questo che lì si parte dall'ML-KEM ibrido (Module-Lattice-Based Key-Encapsulation Mechanism). Una firma deve resistere alla contraffazione solo finché la sua trust anchor è attiva, ma il verificatore che la controlla può restare in un bootloader per un decennio, e non è possibile correggere un verificatore con un aggiornamento che quel verificatore non è in grado di verificare. Sono questi tempi di preparazione, non l'urgenza della minaccia, il motivo per cui le tempistiche ufficiali collocano presto la firma di software e firmware: la CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) della NSA richiede l'uso esclusivo di ML-DSA-87 o LMS/XMSS per la firma di software e firmware entro la fine del 2030 per i National Security Systems statunitensi, tre anni prima di browser, server, servizi cloud e sistemi operativi.

Perché le scadenze per la firma arrivano prima di quelle per lo scambio di chiavi

Lo scenario harvest now, decrypt later (raccogliere ora, decifrare dopo) non si applica alle firme. Nessuno può registrare una firma oggi e ricavarne in seguito una nuova contraffatta. L'esposizione è diversa: un attaccante dotato di capacità quantistiche, in grado di recuperare una chiave privata di firma a partire dalla sua chiave pubblica, potrebbe firmare firmware di cui la vostra base installata si fida ancora. La mitigazione consiste nel portare un verificatore post-quantistico in quella base installata molto prima che la chiave diventi contraffabile, e le basi installate si muovono lentamente.

Tre caratteristiche fanno della firma l'elemento più lungo da migrare. Primo, i verificatori sono ovunque e spesso immutabili: stadi di boot in ROM, secure element, strumenti di provisioning air-gapped, appliance presso i clienti, installer offline. Secondo, le trust anchor sono incorporate, quindi cambiare algoritmo significa distribuire nuove chiavi pubbliche attraverso un canale che è a sua volta firmato. Terzo, l'ultimo aggiornamento che un dispositivo accetta con il vecchio algoritmo è quello che deve insegnargli il nuovo, per cui un dispositivo ritirato dalla vostra pipeline di aggiornamento prima di quel momento resterà classico per sempre. Pianificate esplicitamente questa decisione di fine vita invece di scoprirla nel 2030.

Nulla di tutto ciò richiede una previsione su quando esisterà un computer quantistico crittograficamente rilevante. Le date riportate di seguito provengono da politiche e linee guida pubblicate, ed è a queste che la roadmap del vostro release engineering deve conformarsi.

ML-DSA, SLH-DSA, LMS e XMSS: la scelta per caso d'uso

Il NIST ha pubblicato FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Algorithm) e FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Algorithm) come standard definitivi il 13 agosto 2024 (FIPS 204, FIPS 205). Gli schemi hash-based con stato LMS e XMSS sono approvati dalla NIST SP 800-208. La CNSA 2.0 indica ML-DSA-87 e LMS/XMSS per la firma di software e firmware, con SHA-384 o SHA-512 per l'hashing.

Per la maggior parte delle pipeline di rilascio ML-DSA è la scelta predefinita, perché è senza stato e quindi può essere utilizzato in sicurezza in un sistema CI distribuito con più firmatari. Gli schemi con stato sono interessanti per bootloader con risorse limitate, ma la regola operativa non ammette errori: lo stato del firmatario non deve mai essere duplicato, il che esclude i normali snapshot di macchine virtuali, i cloni in warm standby e il ripristino da backup di un host di firma. Se non potete garantirlo nel vostro ambiente, scegliete uno schema senza stato.

Le dimensioni contano in un modo che con ECDSA non accadeva. Le chiavi pubbliche e le firme post-quantistiche sono sensibilmente più grandi, e le firme SLH-DSA lo sono ancora di più. Consultate le tabelle dei parametri in FIPS 204 e FIPS 205 prima di dimensionare un campo firma in un header di firmware, una partizione flash, uno schema di manifest o un budget di aggiornamento over-the-air. Un campo firma a larghezza fissa in un formato di immagine esistente è un ostacolo frequente, e si tratta di una modifica di formato, non di una modifica crittografica.

Prima il verificatore: l'ordine di aggiornamento che non si può invertire

La sequenza seguente è l'intero piano. I passaggi 2 e 3 devono essere completati sull'intera flotta prima che inizi il passaggio 5.

1. Censite i verificatori, non solo i firmatari. Elencate ogni punto in cui viene controllata una firma: bootloader, secure element, gestori di pacchetti, framework di installazione, agenti di aggiornamento, admission controller, strumenti di provisioning, script di validazione dei partner. Annotate quali potete aggiornare, attraverso quale canale, e quali sono congelati.
2. Aggiungete la verifica post-quantistica continuando ad accettare l'algoritmo classico. Il nuovo verificatore deve essere tollerante: accettare le vecchie firme, accettare le nuove e registrare quale ha ricevuto.
3. Distribuite quel verificatore attraverso il canale esistente con firma classica, poi distribuite le nuove trust anchor. Misurate la copertura con telemetria reale, per dispositivo e per versione, non per supposizione.
4. Registrate le chiavi di firma in hardware ed eseguite end to end una pipeline di firma parallela, non di produzione, comprese revoca e marcatura temporale.
5. Avviate la doppia firma degli artefatti di produzione quando il verificatore tollerante rappresenta la stragrande maggioranza.
6. Richiedete le firme post-quantistiche solo quando la telemetria mostra che i vecchi verificatori sono scomparsi, con una decisione scritta per i ritardatari: supporto esteso, sostituzione sul campo o fine vita documentata.
7. Eliminate la firma classica per ultima, e mantenete la capacità di rifirmare gli artefatti archiviati, così che le vecchie release restino verificabili con il nuovo schema.

Doppia firma: le due modalità e la trappola

Doppia firma significa allegare due firme indipendenti (una classica, una post-quantistica) allo stesso artefatto, di solito in un formato contenitore che supporta più slot di firma. Verificate se il vostro lo supporta prima di progettare qualsiasi altra cosa: alcuni formati consentono nativamente più firmatari, altri richiedono una firma separata (detached) fuori banda o una revisione del formato.

La decisione progettuale che conta è la politica di verifica. In modalità permissiva un verificatore accetta l'artefatto se una qualsiasi delle due firme è valida, il che mantiene funzionanti i vecchi client ma significa che la sicurezza effettiva è quella del più debole dei due algoritmi. In modalità rigorosa il verificatore le richiede entrambe, il che aumenta la sicurezza ma crea un rischio di disponibilità: un singolo errore in una delle due pipeline blocca ogni rilascio. Il percorso abituale è la modalità permissiva durante il rollout, quella rigorosa quando la flotta è pronta, poi solo post-quantistica. Mettete per iscritto la politica per classe di verificatore e per tipo di artefatto, e rendete esplicite le date di transizione: è esattamente il tipo di cambio di algoritmo pianificato che la crypto-agility dovrebbe rendere ordinaria amministrazione.

Supporto di HSM, PKI e toolchain: cosa verificare, senza dare per scontato

Il supporto delle firme post-quantistiche sta evolvendo rapidamente tra moduli di sicurezza hardware, autorità di certificazione e strumenti di firma, e i requisiti di versione differiscono tra prodotti e persino tra rami firmware dello stesso prodotto. Non considerate un post sul blog di un fornitore come un impegno. Chiedete le note di rilascio e il documento di validazione, e testate in staging. I punti seguenti sono le domande da porre per iscritto:

• Il firmware dell'HSM implementa ML-DSA, con quali set di parametri, ed esiste una versione validata FIPS 140-3 o una roadmap datata per ottenerla? Se la CNSA 2.0 vi riguarda, il set di parametri pertinente è ML-DSA-87.
• È accessibile tramite l'interfaccia utilizzata dalla vostra pipeline (meccanismo PKCS#11, tipi di oggetto KMIP, API di un KMS cloud, SDK del fornitore), e le chiavi possono essere generate in hardware senza mai essere esportate?
• Per LMS o XMSS: la generazione delle chiavi e l'avanzamento dello stato avvengono all'interno del modulo crittografico, senza alcun meccanismo che possa duplicare lo stato, come richiede la SP 800-208?
• La vostra autorità di certificazione può emettere certificati con chiavi del soggetto post-quantistiche, e può firmare dati di revoca che i vostri verificatori accetteranno? Le gerarchie potrebbero richiedere una catena post-quantistica parallela anziché una modifica in loco.
• La vostra autorità di marcatura temporale supporta il nuovo algoritmo, così che le firme restino verificabili dopo la scadenza del certificato?
• I vostri strumenti di firma degli artefatti e di trasparenza, i sistemi di build dei pacchetti e le librerie di verifica lo supportano nelle versioni esatte che distribuite? OpenSSL, ad esempio, richiede la versione 3.5 o successiva per i gruppi TLS ML-KEM; per il supporto delle firme, consultate le note di rilascio della versione specifica che distribuite, sia nell'ambiente di firma sia in quello di verifica.
• Throughput e latenza: firme più grandi e nuovi percorsi di codice modificano il tempo di firma per artefatto e la dimensione dei download. Effettuate benchmark con il vostro volume di rilascio reale.

Le date su cui pianificare

Quanto segue è a titolo informativo e non costituisce consulenza legale. Lo stato conta quanto la data: una bozza non è uno standard, e una linea guida rivolta agli Stati membri non è un obbligo per le imprese.

Fonti primarie: OMB M-26-15, la EU Coordinated Implementation Roadmap, le FAQ PQC dell'ANSSI, le tempistiche di migrazione dell'NCSC britannico e NIST IR 8547 ipd. Per la CNSA 2.0 le fonti pubblicate sono le CNSA 2.0 FAQ v2.1 (dicembre 2024) e l'advisory CNSA 2.0 Algorithms (30 maggio 2025).

I produttori dovrebbero inoltre tenere presente che il Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e), richiede di proteggere la riservatezza mediante meccanismi allo stato dell'arte e non nomina algoritmi post-quantistici; i suoi obblighi di segnalazione si applicano dall'11 settembre 2026 e il regolamento si applica integralmente dall'11 dicembre 2027 (EUR-Lex). Considerate l'aggiornamento sicuro e la verifica delle firme come parte di questa argomentazione sullo stato dell'arte, e mantenete l'inventario delle chiavi di firma nello stesso registro del resto della vostra crittografia.

Iniziate da ciò che potete misurare oggi

La migrazione della firma è un programma pluriennale che riguarda l'intera flotta, quindi iniziate dalle due attività economiche: un elenco di ogni verificatore di cui siete responsabili con il relativo canale di aggiornamento, e una pipeline di firma in staging che produca end to end un artefatto con doppia firma. In parallelo, verificate che il lato trasporto utilizzi già lo scambio di chiavi ibrido, poiché è lì che è in gioco il traffico registrato e lì la correzione è una modifica di configurazione anziché un rollout sulla flotta. Potete analizzare il vostro dominio con PQC Status per verificare se i vostri host di rilascio, di aggiornamento e degli artefatti negoziano X25519MLKEM768, quali versioni TLS e cipher suite offrono e com'è composta la loro catena di certificati. L'analisi descrive solo la configurazione TLS visibile dall'esterno: non è una certificazione e non esamina la vostra pipeline di firma del codice, quindi abbinatela all'inventario dei verificatori descritto sopra.