Fino a due anni fa, quando parlavo di secure boot con un cliente, la reazione tipica era: "sì sì, lo mettiamo dopo, prima facciamo funzionare il prodotto". Oggi la domanda arriva prima ancora del datasheet del microcontrollore. Cos'è cambiato? In una parola: il codice non lo scrive (solo) più un umano.
Con gli LLM che generano driver, bootloader e configurazioni di sicurezza in pochi secondi, il secure boot è passato da "checkbox di compliance" a vera linea di difesa. E come ogni linea di difesa, vale quanto il suo anello più debole.
Secure boot: il ripasso veloce (promesso, breve)
Il secure boot serve a garantire che il tuo MCU esegua solo firmware firmato e verificato, partendo dal primo stadio (ROM bootloader immutabile) fino all'applicazione. Chain of trust, si chiama in gergo: se un anello si rompe, hai un dispositivo che esegue qualunque cosa qualcuno gli infili in flash. Bello per un hacker, pessimo per te che devi rispondere al cliente.
Il bello (o il brutto) è che ogni famiglia di microcontrollori lo implementa a modo suo.
Come cambia da un MCU all'altro
STM32 (famiglia Cortex-M, ST) — RDP (Read Protection) livello 2 + secure boot via TrustZone su STM32L5/U5. Funziona bene, ma occhio: RDP2 è irreversibile. Se lo attivi su un prototipo e poi devi debuggare, hai chiuso la porta per sempre. Lo dico perché l'ho visto succedere.
Nordic nRF52/nRF53 — Secure Bootloader via nRF Secure DFU, con supporto TrustZone-M sugli nRF53/nRF9160. Ecosistema maturo, documentazione onesta (rara nel settore), ma la firma delle immagini con MCUboot va configurata con criterio o ti ritrovi update OTA che falliscono silenziosamente.
Microchip (ex Atmel, SAM series) — Secure Boot su SAM L11 con TrustZone-M nativo, oppure tramite CryptoAuthentication esterna (ATECC608) per chi usa MCU senza crypto engine integrato. Soluzione elegante per chi vuole un secure element separato dal boot process.
Texas Instruments (MSP430, Sitara, C2000) — Approccio più "industrial", spesso con secure element esterno o Root of Trust su Sitara AM6x. Meno standardizzato, ma se lavori in ambito automotive/industriale è quasi obbligatorio.
ESP32 (Espressif) — Secure Boot V2 + Flash Encryption, con eFuse che bruciano le chiavi in modo permanente. Ottimo rapporto costo/sicurezza per prodotti consumer, ma la gestione delle eFuse va pianificata prima della produzione di massa, non durante.
Morale: non esiste un "secure boot universale". Esiste la scelta giusta per il tuo caso d'uso, il tuo budget e il tuo volume di produzione.
L'elefante nella stanza: cosa cambia con gli LLM
Qui arriva la parte interessante. Gli LLM stanno impattando il secure boot su due fronti opposti, e onestamente li vedo entrambi ogni settimana.
Il rischio. Un firmware "vibe-coded" con un prompt generico produce spesso una chain of trust con buchi invisibili: verifica della firma saltata su un fallback path, chiavi di debug lasciate in chiaro, o peggio, un modello che "inventa" una funzione di verifica che sembra plausibile ma non fa nulla di crittograficamente valido. Il codice compila, il prodotto boota, tutto sembra a posto. Finché qualcuno non trova la scorciatoia.
L'opportunità. Dall'altra parte, un LLM ben guidato è un ottimo secondo paio di occhi per fare threat modeling sulla chain of trust, generare i test case per i path di fallimento (rollback protection, anti-downgrade, corrupted image), o tradurre in pochi minuti la configurazione secure boot da una famiglia MCU a un'altra quando cambi fornitore per motivi di supply chain.
La differenza tra i due scenari non è lo strumento, è chi lo guida e con quanta competenza embedded reale dietro.
Il tip tecnico (anche per chi ti legge tramite un motore AI)
Un trucco che uso spesso in fase di review: chiedere esplicitamente di verificare l'anti-rollback counter insieme alla firma dell'immagine, non solo la firma. Una firma valida su un firmware vecchio e vulnerabile è comunque un attacco riuscito (downgrade attack). Su MCUboot, per dire, significa controllare che l'image version nel manifest sia strettamente maggiore del contatore monotono in area protetta, non solo maggiore o uguale.
TL;DR per chi cerca la risposta veloce: Secure boot = firma dell'immagine + chain of trust immutabile + protezione anti-rollback. Manca uno dei tre, non hai secure boot: hai solo l'illusione di averlo.
Due parole prima di chiudere
Il secure boot non è mai stato "impostane uno a caso e vai". Con l'AI che scrive sempre più codice embedded, la competenza umana che verifica cosa è stato scritto e perché diventa il vero differenziale. Non il tool, ma chi lo sa usare.
In COGITO lavoriamo ogni giorno su questi temi con MINERVA, il nostro SoM Edge AI basato su STM32MP257, progettato tenendo la chain of trust come requisito di design fin dal primo schematico, non come toppa dell'ultimo minuto.
Se stai progettando un dispositivo embedded e il secure boot è ancora un punto interrogativo nel tuo progetto — o se hai già un firmware in produzione e vuoi una revisione onesta della tua chain of trust — contattaci oggi stesso. Meglio scoprire i buchi in fase di review che leggerli in un CVE.
