Requisiti di cifratura del CRA per i produttori

Il Cyber Resilience Act (CRA, Regulation (EU) 2024/2847, regolamento sulla ciberresilienza) fissa il proprio requisito di cifratura nell'Annex I, Part I (2)(e): proteggere la riservatezza dei dati conservati, trasmessi o altrimenti trattati, ad esempio cifrando i dati pertinenti a riposo o in transito mediante meccanismi allo stato dell'arte. Non nomina algoritmi post-quantum. Gli obblighi di segnalazione previsti dall'articolo 14 si applicano dall'11 settembre 2026 e il regolamento si applica integralmente dall'11 dicembre 2027: i team di prodotto stanno quindi scegliendo oggi la crittografia per dispositivi che saranno ancora supportati ben oltre tali date.

Cosa dice il requisito, e cosa non dice

L'Annex I si compone di due parti. La Part I elenca i requisiti essenziali di cibersicurezza relativi al prodotto stesso, tra cui l'immissione sul mercato senza vulnerabilità sfruttabili note, una configurazione sicura per impostazione predefinita e il requisito di riservatezza al punto (2)(e). La Part II elenca i requisiti di gestione delle vulnerabilità, che si applicano per tutto il periodo di supporto dichiarato dal fabbricante. Il testo è disponibile su EUR-Lex (Regulation (EU) 2024/2847) e la nostra sintesi datata si trova nella pagina dedicata al regolamento CRA.

Per un team di prodotto ne derivano tre conseguenze:

• Il requisito è orientato al risultato. Nomina la riservatezza e i meccanismi allo stato dell'arte, non RSA, non ECDH, non ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, standardizzato in NIST FIPS 203).
• Il riferimento è in movimento. Un meccanismo difendibile al momento della valutazione della conformità può smettere di esserlo mentre il prodotto è ancora supportato.
• Nulla nel testo vi obbliga a distribuire oggi crittografia post-quantum. Allo stesso modo, nulla salva un progetto la cui crittografia non può essere modificata quando lo stato dell'arte evolve.

Norme armonizzate potranno in seguito precisare come soddisfare l'Annex I, e la conformità a una norma armonizzata citata nella Gazzetta ufficiale conferisce una presunzione di conformità. Finché tale norma non esiste e non è citata, il suo contenuto è sconosciuto: non pianificate sulla base di ipotesi su ciò che dirà in materia di crittografia. Il contenuto giuridico qui riportato ha carattere informativo e non costituisce consulenza legale.

Le date del calendario CRA

Per un dispositivo con un periodo di supporto pluriennale, l'orizzonte di pianificazione non è il 2027. È l'ultima data in cui dovete ancora fornire aggiornamenti di sicurezza per le unità vendute poco prima della fine del supporto.

Cosa può ragionevolmente significare stato dell'arte lungo un periodo di supporto

Il CRA non pubblica un elenco di algoritmi: il modo corretto di ragionare sullo stato dell'arte è quindi esaminare ciò che autorità pubbliche e organismi di normazione hanno effettivamente pubblicato, mantenendone lo status.

Fonti primarie: la roadmap UE, BSI TR-02102-1, le FAQ PQC di ANSSI, NIST IR 8547 ipd e le tempistiche di migrazione dell'NCSC.

La nostra interpretazione, chiaramente indicata come tale: nessuno di questi testi rende la crittografia post-quantum un obbligo del CRA, e nessuna autorità ha affermato che la crittografia classica non soddisfi oggi l'Annex I. Tuttavia, un prodotto il cui periodo di supporto si estende oltre il 2030 viene venduto in un periodo per il quale diverse autorità hanno già pubblicato date di dismissione dello scambio di chiavi classico. La posizione ingegneristica difendibile è quindi l'agilità: la capacità di cambiare algoritmi tramite un normale aggiornamento, documentata nel fascicolo di progetto.

Crypto agility nel firmware

L'agilità è una proprietà dell'implementazione, non una frase in una policy. Quattro domande stabiliscono se un dispositivo già distribuito può seguire lo stato dell'arte, ed è più facile rispondervi prima del tape-out che dopo. Un approfondimento è disponibile nell'articolo sulla crypto agility.

• Negoziazione, non costanti. Identificatori di algoritmo, named group e dimensioni delle chiavi provengono dalla configurazione o dall'handshake del protocollo, mai da una costante compilata o da un buffer di dimensione fissa. Le chiavi e i ciphertext ML-KEM sono molto più grandi dei valori su curve ellittiche: una struct dimensionata per chiavi da 32 byte è un blocco a livello hardware.
• Margine. Prevedete flash, RAM e tempo di handshake per materiale crittografico più voluminoso. Misuratelo sul dispositivo di destinazione, non su una workstation.
• Confine della libreria. Richiamate la crittografia tramite una sottile interfaccia interna, in modo che il provider possa essere sostituito. Fissate la versione minima nella build: i gruppi TLS ML-KEM richiedono OpenSSL 3.5 o successivo.
• Fallback classico. Preferite lo scambio di chiavi ibrido e mantenete un gruppo classico come alternativa, in modo che il dispositivo si connetta anche quando l'altra estremità è meno recente.

Su una build di test, verificate cosa lo stack può effettivamente offrire e cosa negozia un endpoint del dispositivo:

openssl version
# ML-KEM TLS groups require OpenSSL 3.5 or later
openssl list -tls-groups

# read-only test against a device endpoint, hybrid first, classical fallback
openssl s_client -connect device.example.com:443 -tls1_3 \
  -groups X25519MLKEM768:X25519 </dev/null

Il gruppo ibrido da preferire oggi è X25519MLKEM768 (codepoint IANA 0x11EC), con SecP256r1MLKEM768 o SecP384r1MLKEM1024 dove è richiesta una curva NIST; il profilo IETF per l'accordo di chiave ibrido post-quantum e tradizionale in TLS 1.3 è RFC 10024 (agosto 2026). I gruppi pre-standard basati sulle bozze Kyber, come X25519Kyber768Draft00, sono obsoleti e dovrebbero essere rimossi dal firmware dei dispositivi. Testate in staging prima della produzione e mantenete il gruppo classico nell'elenco.

I piani di gestione dei dispositivi meritano la stessa verifica. OpenSSH 9.9 ha aggiunto mlkem768x25519-sha256, OpenSSH 10.0 lo ha reso l'accordo di chiave predefinito e OpenSSH 10.1 emette un avviso quando una connessione negozia un accordo di chiave non post-quantum, secondo le note di rilascio di OpenSSH.

Firma degli aggiornamenti: la parte che non potrete correggere in seguito

Le chiavi di trasporto cambiano a ogni sessione. Una root of trust impressa nel silicio no. Il traffico registrato è protetto solo dallo scambio di chiavi, ed è per questo che lo scambio di chiavi ibrido viene per primo, mentre le firme possono migrare in seguito; ma la firma degli aggiornamenti è l'unico percorso di firma in cui una migrazione tardiva può risultare impossibile, perché il verificatore risiede in codice di avvio immutabile.

Misure pratiche, in ordine di valore:

1. Prevedete più di uno slot di verifica o più di una gerarchia di chiavi, in modo che un nuovo algoritmo di firma possa essere introdotto con un aggiornamento anziché con un richiamo del prodotto.
2. Decidete ora quale famiglia di firme post-quantum il prodotto potrebbe accettare: ML-DSA (FIPS 204), SLH-DSA (FIPS 205) oppure gli schemi hash-based con stato LMS e XMSS di NIST SP 800-208, che richiedono una gestione rigorosa dello stato per evitare il riutilizzo di una chiave monouso.
3. Mantenete il codice e i parametri di verifica delle firme in uno stadio aggiornabile, ove il modello di sicurezza lo consenta, limitando lo stadio immutabile alla verifica di tale stadio aggiornabile.
4. Documentate il rollover delle chiavi: chi detiene le chiavi, come viene ritirata una chiave compromessa o deprecata e come un dispositivo sul campo apprende la nuova chiave.

CNSA 2.0 fissa già alla fine del 2030 l'uso esclusivo dei propri algoritmi per la firma di software e firmware nei National Security Systems statunitensi. Non è un obbligo UE, ma è una data pubblicata per lo stesso problema ingegneristico, ed è un elemento ragionevole da considerare quando argomentate cosa significhi stato dell'arte per un prodotto supportato oltre il 2030.

Collegare il requisito alle evidenze

Prossimo passo: misurate cosa mostra il vostro prodotto in rete

Prima di scrivere una sola riga di documentazione CRA, verificate cosa negoziano effettivamente oggi i vostri endpoint e i vostri server di aggiornamento. Potete analizzare gratuitamente il vostro dominio con PQC Status per vedere le versioni TLS, i gruppi ibridi ML-KEM, le cipher suite e la catena di certificati osservati da un client esterno. Una scansione descrive solo la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità. Usate il risultato come prima riga del vostro inventario, quindi procedete verso l'interno fino al firmware: dimensioni delle chiavi nelle struct, versioni delle librerie nella build e numero di slot di verifica nella catena di avvio.