Crittografia post-quantistica sui dispositivi embedded: cosa cambiano FIPS 203, 204 e 205

Ad agosto 2024 il NIST ha pubblicato i primi tre standard di crittografia post-quantistica. Per i servizi cloud adottarli è soprattutto questione di aggiornare librerie e protocolli. Per i dispositivi embedded è un problema di progettazione.

Questa nota è una panoramica per chi guida prodotto e ingegneria, non una lezione di crittografia. Non sono un crittografo; in Shorium abbiamo persone che lo sono. Il mio lavoro è aiutare a rendere queste scelte comprensibili per i team che dovranno conviverci.

I tre standard, un paragrafo ciascuno

FIPS 203, ML-KEM (derivato da CRYSTALS-Kyber). Un meccanismo di incapsulamento delle chiavi: prende il ruolo di RSA o di Diffie-Hellman su curve ellittiche nello stabilire un segreto condiviso. È veloce, ma chiavi pubbliche e testi cifrati si misurano in kilobyte invece che in decine di byte.

FIPS 204, ML-DSA (derivato da CRYSTALS-Dilithium). Uno schema di firma digitale di uso generale, il sostituto più probabile delle firme ECDSA e RSA nella maggior parte dei casi. Le firme pesano alcuni kilobyte.

FIPS 205, SLH-DSA (derivato da SPHINCS+). Uno schema di firma basato su hash, senza stato. La sua sicurezza poggia su funzioni hash ben conosciute, il che lo rende una scelta prudente, al prezzo di firme grandi e di una firma più lenta.

C’è anche una quarta famiglia utile da conoscere per il firmware: le firme basate su hash con stato, LMS e XMSS, specificate nel NIST SP 800-208. La suite CNSA 2.0 della NSA statunitense le indica per la firma di software e firmware.

Cosa cambia su un dispositivo con poche risorse

Gli algoritmi funzionano. La domanda è se il tuo dispositivo, i tuoi protocolli e la tua filiera riescono a portarli.

Dimensioni. Chiavi e firme sono molto più grandi dei valori ECC attorno a cui è stata progettata la maggior parte dei sistemi embedded. Questo pesa su flash e RAM, sulle catene di certificati e su qualsiasi protocollo con limiti stretti sui messaggi.

Banda e tempo radio. Sulle reti a basso consumo, inviare qualche kilobyte in più a ogni handshake non è gratis. Costa energia, latenza e a volte limiti regolamentari sul tempo di trasmissione.

Prestazioni e picchi di memoria. Alcune operazioni sono veloci sulla carta ma richiedono memoria di lavoro che i microcontrollori piccoli non hanno.

Accelerazione hardware. Molti dispositivi si affidano ad acceleratori crittografici o elementi sicuri pensati per RSA ed ECC. Se i nuovi algoritmi girano in software, la protezione da attacchi temporali e side-channel va riconsiderata.

Stato. LMS e XMSS sono efficienti e prudenti, ma ogni chiave privata può firmare un numero limitato di messaggi e chi firma non deve mai riutilizzare uno stato. È gestibile in un’infrastruttura di firma ben organizzata. È un rischio serio ovunque lo stato possa essere copiato o riportato indietro.

L’ibrido è uno strumento di transizione, non una destinazione

Durante la transizione molti protocolli combinano un algoritmo classico con uno post-quantistico, così la connessione resta sicura finché ne regge almeno uno. Lo scambio di chiavi ibrido è già comune in TLS.

Per i dispositivi le modalità ibride fanno guadagnare tempo e riducono il rischio. Aggiungono anche dimensioni e complessità. Trattale come un ponte da attraversare, con una data sull’altra sponda.

Domande da fare prima di scegliere

Prima che qualcuno scelga un algoritmo, vorrei risposte chiare a queste domande:

• Cosa fa davvero il dispositivo con la crittografia a chiave pubblica? Avvio sicuro, aggiornamenti firmware, identità del dispositivo, chiavi di sessione? Ognuno ha una soluzione più adatta.
• Per quanto tempo sarà supportato il dispositivo, e la sua radice di fiducia si potrà aggiornare in quel periodo?
• Quali sono i margini reali di memoria, flash, energia e banda sulla revisione hardware attuale, e sulla prossima?
• Quali parti della catena controlliamo, e quali appartengono ai fornitori: produttore del chip, del modulo, piattaforma cloud, autorità di certificazione?
• Se scegliamo male, come lo cambieremmo?

L’ultima domanda è la più importante. Gli standard sono nuovi, le implementazioni miglioreranno e le indicazioni cambieranno. Il dispositivo che supererà questo decennio non è quello che nel 2026 ha scelto l’algoritmo perfetto. È quello progettato per cambiare.

Da dove cominciare

Comincia da un inventario di dove si usa la crittografia a chiave pubblica nei tuoi prodotti, e da una valutazione franca dei margini hardware dei dispositivi che venderai ancora nel 2030. Tutto il resto, scelta dell’algoritmo compresa, dipende da queste due risposte.