Crypto-agility nel firmware: progettare dispositivi che possono cambiare la propria crittografia

Ogni algoritmo crittografico prima o poi va in pensione. È successo a MD5. È successo a SHA-1. RSA e la crittografia a curve ellittiche ora hanno un percorso di deprecazione pubblicato.

Per un’applicazione web, ritirare un algoritmo è un progetto di migrazione. Per un dispositivo sul campo, può significare un richiamo.

La crypto-agility è la capacità di cambiare la crittografia usata da un sistema senza riprogettare il sistema. Sembra una funzione di libreria. Nei prodotti embedded è una decisione di architettura, e si prende molto presto.

Dove l’agilità di solito si rompe

Per la mia esperienza, i dispositivi raramente non riescono a cambiare crittografia per colpa dell’algoritmo. Non ci riescono per un’ipotesi fatta da un’altra parte.

• Il bootloader verifica il firmware con un solo algoritmo e una sola chiave pubblica, scritti in una memoria non modificabile.
• Lo schema delle partizioni riserva esattamente lo spazio per la firma di oggi, e non un byte in più.
• Il protocollo di aggiornamento ha un formato dei messaggi che non può contenere una firma più grande o una seconda firma.
• L’identità del dispositivo è un certificato emesso da una catena che non si può rifirmare.
• Le chiavi stanno in un elemento sicuro che supporta solo gli algoritmi della sua generazione.

Ognuna di queste scelte era ragionevole quando è stata fatta. Insieme, trasformano un aggiornamento crittografico in un cambio di hardware.

Principi di progettazione

Sono i principi che vorrei seguisse ogni nuovo prodotto connesso. Nessuno richiede di scegliere oggi un algoritmo post-quantistico.

1. Separare la radice di fiducia dall’algoritmo. La parte immutabile della catena di avvio deve essere il più piccola possibile, e capace di verificare lo stadio successivo con più di uno schema, oppure di passare il controllo a uno stadio aggiornabile.

2. Lasciare spazio. Prevedi flash, RAM e dimensioni dei messaggi per firme e chiavi parecchie volte più grandi di oggi. Le firme post-quantistiche pesano kilobyte, non byte.

3. Mettere una versione su tutto ciò che contiene crittografia. Immagini firmware, manifest, certificati e messaggi di protocollo devono dichiarare quali algoritmi usano, così vecchio e nuovo possono convivere durante una transizione.

4. Prevedere la doppia firma. Durante una migrazione un aggiornamento può dover essere firmato sia con il vecchio sia con il nuovo schema, perché ogni dispositivo sul campo possa verificarlo. Progetta il manifest perché sia possibile.

5. Rendere le chiavi sostituibili. Tieni una procedura documentata e provata per ruotare chiavi di firma e radici di fiducia, compreso cosa succede ai dispositivi rimasti scollegati per mesi.

6. Conoscere le dipendenze. L’agilità è impossibile se non sai quale componente, di quale fornitore, implementa quale funzione crittografica. Una SBOM aiuta; una mappa delle relazioni crittografiche aiuta di più.

Il lato organizzativo

Un dispositivo può essere tecnicamente agile e restare comunque bloccato, perché nessuno sa chi decide.

Cambiare un algoritmo di firma tocca hardware, firmware, backend degli aggiornamenti, produzione, gestione dei certificati, assistenza clienti e a volte certificazione. Ogni team ha una parte delle informazioni. Se le dipendenze tra quelle parti non sono visibili, ogni migrazione comincia con settimane di archeologia.

È il problema su cui lavoriamo in Shorium: modellare le dipendenze crittografiche dentro i prodotti connessi, così che i team possano vedere cosa toccherà un cambiamento prima di farlo. Ho spiegato l’idea del Trust Twin in Perché sto costruendo Shorium.

Un test semplice

Ecco un test che trovo utile. Chiedi al tuo team:

«Se dovessimo sostituire l’algoritmo con cui firmiamo il firmware del prodotto più vecchio che supportiamo ancora, cosa cambieremmo, chi lo farebbe e quanto ci vorrebbe?»

Se la risposta è un piano, hai un po’ di agilità. Se la risposta è il silenzio, sai da dove cominciare.

Le norme vanno nella stessa direzione. Il Cyber Resilience Act si aspetta che i prodotti restino sicuri per tutto il periodo di supporto, e il NIST prevede di deprecare gli algoritmi a chiave pubblica di oggi dopo il 2030. I dispositivi progettati adesso vivranno quel cambiamento. Dovrebbero essere costruiti per affrontarlo.