
Secure Boot i.MX8 semplificato - firma del codice usando Yocto
La maggior parte degli ingegneri ha ormai sentito parlare di Secure Boot e dei vantaggi derivanti dal suo utilizzo. Tuttavia, dopo aver esaminato brevemente la documentazione, Secure Boot sembra troppo complicato e dispendioso (in termini di tempo) e, pertanto, viene messo da parte come “utile in futuro”. Vi suona familiare questo?
Con l’integrazione di Variscite di Secure Boot e Yocto, non è mai stato così facile abilitare Secure Boot sul vostro prodotto basato su i.MX8 di Variscite. Sebbene la creazione e la firma manuale delle immagini al di fuori del sistema di compilazione Yocto richieda numerosi step e renda possibili eventuali errori umani, l’utilizzo di Yocto per automatizzare la firma delle immagini consente di risparmiare tempo, è facilmente replicabile, può essere condiviso con molti developer e richiede solo una breve configurazione in local.conf.
Cos’è Secure Boot e perché dovreste usarlo?
Secure Boot è il processo di autenticazione delle immagini di avvio e del sistema operativo nel vostro prodotto. Vi consente di accertarvi che il software in esecuzione nel vostro prodotto sia autentico e non sia stato modificato o sostituito da terzi. Tra le altre cose, impedisce che il vostro prodotto venga riproposto o infettato da software di avvio o da sistemi operativi dannosi.
Come funziona?
Per abilitare Secure Boot, le famiglie di SoC i.MX8 (i.MX8Q e iMX8X) e i.MX8M (i.MX8M, i.MX8M Mini, i.MX8M Nano e iMX8M Plus) sono dotate di una funzione hardware opzionale. La famiglia i.MX8M è dotata di High Assurance Boot (HAB), mentre la famiglia i.MX8 è dotata di Advanced High Assurance Boot (AHAB). Sebbene l’architettura di ciascuna famiglia sia leggermente diversa dall’altra, entrambe conseguono il medesimo risultato finale.
L’autenticazione HAB/AHAB si basa sulla crittografia a chiave pubblica. L’autenticazione si ottiene utilizzando una Super Root Key (SRK), la quale consiste in una coppia di chiavi RSA. Le immagini di avvio vengono firmate offline utilizzando la chiave privata. Le immagini firmate risultanti vengono quindi verificate sul processore i.MX utilizzando la chiave pubblica corrispondente. La chiave pubblica è inclusa nel binario finale e un hash della chiave pubblica viene programmato nel SoC, in e-fuse programmabili una tantum, per stabilire la root of trust.
La prima immagine di avvio viene autenticata dal bootloader ROM i.MX. Ogni immagine chiama quindi l’API HAB/AHAB per l’autenticazione dell’immagine successiva, al fine di stabilire una chain of trust.

Come si inizia?
Il layer Yocto di Variscite, meta-variscite-hab, semplifica l’utilizzo di Secure Boot sul vostro prodotto. La procedura generale è la seguente:
- seguire la wiki guide di Variscite “Build Yocto from Source Code” per configurare il proprio ambiente Yocto Build;
- scaricare lo strumento di firma del codice (CST) di NXP;
- utilizzare CST per generare un albero PKI (Public Key Infrastructure). Questo deve essere effettuato solo una volta;
- configurare meta-variscite-hab in conf/local.conf inserendo i dati specifici del cliente;
- usare bitbake per creare l’immagine della scheda SD firmata;
- U-Boot: programmare gli e-fuse di SoC i.MX con l’hash della chiave pubblica SRK;
- U-Boot: verificare l’immagine firmata eseguendo hab_status o ahab_status;
- U-Boot: chiudere il dispositivo scrivendo a un e-fuse SoC dedicato.
Per visualizzare una procedura dettagliata e completa, visitare la sezione wiki del software Variscite relativa al vostro SoM Variscite:
Con l’accelerazione della domanda trainata dall’intelligenza artificiale nel corso del 2025 si è verificata una carenza di chip di memoria, perché i fornitori di semiconduttori hanno riorientato la propria capacità produttiva verso gli acquirenti di grandi volumi, lasciando invece scoperti molti settori, tra cui quello medico, industriale, edge/IoT e della robotica. L’aumento dei prezzi e l’allungamento dei tempi di consegna, aggravati dalle ripercussioni su altri componenti dei SoM, hanno creato due colli di bottiglia ben visibili. Da una parte, i fornitori di SoM che hanno appaltato la produzione all’esterno hanno una flessibilità limitata quando l’offerta diminuisce e i loro ritardi si ripercuotono sui clienti. Dall’altra, gli sviluppatori di prodotti che hanno preferito architetture chip-down rispetto a quelle SoM devono procurarsi i componenti autonomamente. Chi acquista in quantità minori viene sistematicamente relegato in fondo alle liste di priorità dei fornitori o, in molti casi, addirittura depennato.



