Secure BOOT

Sul blog di Elettronica Open Source puoi leggere non solo tutti gli articoli Premium riservati agli abbonati Platinum 2.0 e inseriti nella rivista Firmware 2.0 (insieme ad articoli tecnici, progetti, approfondimenti sulle tecnologie emergenti, news, tutorial a puntate, e molto altro) ma anche gli articoli della Rubrica Firmware Reload. In questa Rubrica del blog abbiamo raccolto gli articoli tecnici della vecchia rivista cartacea Firmware, che contengono argomenti e temi evergreen per Professionisti, Makers, Hobbisti e Appassionati di elettronica. Secure boot è uno dei componenti appartenenti all’architettura QorIQ trust, che include, tra gli altri, anche un controllore di debug secure, e un controllore di integrità in tempo reale. L’infrastruttura secure boot impedisce che la CPU esegua un codice arbitrario diverso da quello di produzione originale, evita che vengano modificati i parametri di configurazione relativi alla sicurezza, utilizza una chiave master one-time programmable per garantire il corretto funzionamento del dispositivo, ed evita che vengano sottratti dati sensibili dal dispositivo.

Il tema della sicurezza sta diventando un fattore sempre più importante nella progettazione dei sistemi elettronici moderni. Le minacce a cui sono sottoposte le reti e i dispositivi collegati in rete rappresentano una preoccupazione reale e crescente. Si stima che la perdita di dati legati alla sicurezza sia pari ad almeno 40 miliardi di dollari statunitensi (USD) all’anno. Conseguentemente, sia le società fornitrici di servizi che gli utenti finali, stanno diventando sempre più consapevoli delle conseguenze derivanti da reti e banche dati non protette. Freescale, in qualità di leader di mercato nel settore dei microprocessori e dei microcontrollori per applicazioni embedded, conosce bene il ruolo fondamentale che i propri processori possono svolgere per aumentare la sicurezza dei dati che scorrono all’interno delle reti, fornendo una protezione efficace dei nodi della rete dagli attacchi e dalle minacce provenienti dall’esterno. Un sistema viene considerato sicuro quando svolge le attività che il suo fabbricante (OEM) e i suoi utenti si aspettano che esegua, e soprattutto quando non esegue altre attività che l’OEM e/o gli utenti potrebbero considerare come degli attacchi, o comunque delle attività che potenzialmente potrebbero procurare dei danni. Il punto di partenza per ottenere un sistema sicuro è far sì che esso carichi ed esegua sempre e soltanto del codice originale. Di conseguenza, il “secure boot” (avvio sicuro) è una pietra miliare della piattaforma QorIQ, che comprende anche il run-time sicuro, il debug sicuro, l’individuazione della manomissione, e l’utilizzo di una chiave segreta per ogni specifico dispositivo. Il processore QorIQ P1010, insieme ai modelli P2040, P2041, P3041, P4080, P4040, P5020, e P5010, implementa l’architettura trust, mettendo a disposizione degli sviluppatori tutti quegli elementi hardware sulla base dei quali è possibile realizzare un sistema ad elevato grado di sicurezza. Le informazioni relative al secure boot, anche se riferite in particolare al dispositivo Freescale QorlQ P1010, si applicano comunque anche a tutti gli altri dispositivi precedentemente elencati.

IL TEMA DELLA SICUREZZA

Gli OEM e i fornitori di servizi vogliono evitare che i loro sistemi eseguano delle funzionalità per le quali il cliente non ha pagato. Non soltanto, essi vogliono anche proteggere i loro clienti finali da una eventuale perdita di funzionalità che potrebbe derivare da azioni o attacchi eseguiti da malintenzionati. Il furto di funzionalità, l’accesso non autorizzato, o il crash del sistema sono in genere attribuibili all’esecuzione di codice non autorizzato, il quale può includere delle modifiche più o meno importanti al codice originale. Attacchi di questo tipo includono: ingannare il sistema in modo tale che esso esegua non l’immagine originale, ma una alternativa con funzionalità dannose o non autorizzate. Attacchi tipici di questo tipo prevedono la modifica o la sostituzione della memoria flash, oppure la modifica dell’indirizzo di boot. Se chi conduce gli attacchi non dispone della chiave con la quale è stata firmata digitalmente l’immagine del codice, la funzionalità secure boot di QorlQ sarà in grado di rilevare la presenza di un’immagine fraudolenta, evitando di mandare in esecuzione la modifica del codice di sistema dopo il boot. Questo tipo di attacchi prevede l’utilizzo di buffer overflow, interfacce di debug, e chip modificati.

GLI OBIETTIVI DEL SECURE BOOT

Il secure boot è un processo attraverso il quale il processore P1010 è in grado di determinare se l’immagine caricata nel sistema è attendibile o meno. Il processore P1010 non è di per sè in grado di conoscere quali intenzioni abbia il codice caricato sul sistema, e non ha alcuna possibilità oggettiva di sapere se il codice stesso cercherà di eseguire delle azioni dannose. Pertanto, nell’ambito del discorso secure boot, deve valere l’equazione affidabile = originale (autentico). Con ciò si intende affermare che un elevato grado di affidabilità (o anche sicurezza) di un sistema si ottiene accertandosi e garantendo che esso esegua sempre e solamente del codice autentico. A livello pratico, questo concetto si realizza nel modo seguente. Gli sviluppatori del sistema “firmano” in modo digitale il loro codice, in modo tale da permettere al processore P1010 di distinguere tra un codice autentico (attendibile) e un codice non autentico (non attendibile). La capacità di distinguere tra codice attendibile e codice non attendibile permette di attuare le seguenti funzionalità: evitare che la CPU esegua codice non attendibile, ma soltanto codice OEM autentico, individuazione e non accettazione dei parametri di configurazione della sicurezza non ammessi, permettere al codice attendibile di utilizzare una chiave master specifica per ogni dispositivo e programmabile una sola volta (chiamata anche OTPMK, acronimo di One Time Programmable Master Key) quando l’architettura trust determina che il P1010 si trova in uno stato sicuro, prevenire l’estrazione/acquisizione di dati sensibili dal dispositivo perpretata con qualsiasi mezzo. Si noti che mentre alcuni sviluppatori hanno una necessità critica di sapere se i loro sistemi sono protetti da eventuali attacchi, questo non rappresenta un requisito universale. Molto, se non tutto, dipende dalla particolare applicazione a cui il sistema è destinato. Ne consegue che il secure boot e l’architettura trust, come impostazione predefinita (default) sono disattivati. Gli sviluppatori non interessati a questa funzionalità possono pertanto ignorarne l’esistenza senza compromettere il funzionamento del sistema (rinunciando, ovviamente, a un maggiore grado di sicurezza dello stesso). Si noti inoltre che gli sviluppatori che scelgono di sfruttare l’architettura trust non dipendono da Freescale per impostare i dispositivi o il codice trust. I processori P1010 sono infatti venduti pronti per la fornitura ai clienti con un impatto minimo sulla progettazione delle schede e sul flusso di produzione dello sviluppatore, e la firma del codice viene eseguita tramite l’utilizzo di strumenti appartenenti al software development kit (SDK) del P1010.

LA FIRMA DIGITALE DEL CODICE

Il punto di partenza per arrivare ad ottenere una piattaforma affidabile è la creazione (da parte dello sviluppatore) di un codice esente da bachi e da malware. Una volta che lo sviluppatore è “confidente” in merito al corretto funzionamento del proprio codice, appone ad esso una firma digitale in modo tale che delle modifiche accidentali o intenzionali apportate al codice possano essere rilevate dal processo secure boot. Come mostrato nella Figura 1, il produttore del sistema (d’ora in avanti riferito con il termine OEM) calcola una chiave (hash) sull’intero codice del sistema (istruzioni eseguibili e informazioni di configurazione). E’ anche possibile (oltrechè vantaggioso) proteggere delle specifiche porzioni di codice tramite criptatura. Ciò evita che dei malintenzionati possano appropriarsi indebitamente del codice contenuto all’interno della flash. L’OEM deve generare una coppia di chiavi, una pubblica e l’altra privata, ed è responsabilità dell’OEM stesso tenere sotto stretto controllo l’accesso alla chiave privata, sulla base della quale viene eseguita la firma del codice. Se infatti questa chiave dovesse essere divulgata, dei malintenzionati potrebbero essere in grado di generare delle immagini alternative in grado di superare i controlli eseguiti dal secure boot. Se inoltre questa chiave dovesse andare perduta, l’OEM non sarebbe più in grado di aggiornare l’immagine. L’hash viene “firmato” utilizzando una chiave RSA privata. L’hash crittografato che si ottiene di conseguenza viene anche chiamata firma digitale, e una sua copia viene appesa in coda al codice, scrivendo entrambi all’interno della memoria flash (o di qualunque altro sistema di memoria non volatile). Un altro hash viene poi calcolato con la chiave pubblica, utilizzata dal P1010 per validare il codice del sistema. Questo valore di hash (la chiave di hash super root) viene programmato all’interno di un blocco fuse del P1010.

Figura 1: firma del codice e validazione della firma

Figura 1: Firma del codice e validazione della firma

SECURE BOOT: IL PROCESSO

Ad alto livello, il secure boot implica che il processore P1010 utilizzi la chiave pubblica RSA (la chiave “super root”) per decifrare il contenuto della hash, ricalcolando simultaneamente l’hash di tipo SHA-256 sull’intero codice del sistema. Il processore P1010 confronta poi l’hash originale decifrata con l’hash appena calcolata e, se il confronto fornisce un esito positivo, il codice viene considerato come autentico (originale). In realtà, però, questo processo si articola su altri step che ora analizzeremo.

LA FASE DI PRE-BOOT

Non appena il dispositivo viene alimentato, la logica di controllo del reset blocca tutte le attività del dispositivo (incluse le attività di scansione e di debug) fino a quando i valori dei fuse possono essere rilevati in modo stabile e con accuratezza. Il parametro di fuse più importante in questo stadio di funzionamento del processo secure boot è il bit ITS (Intent To Secure), il quale, quando impostato, manifesta appunto l’intenzione di applicare il secure boot. Quando il fabbricante (OEM) setta il bit ITS all’interno dei fuse del processore relativi alla funzionalità della sicurezza, vuole quindi che il sistema operi solo e soltanto in una modalità sicura e affidabile. L’impostazione del bit ITS comporta poi, come conseguenza, l’impostazione di default di una serie di registri di configurazione all’interno del dispositivo. Riassumendo, queste impostazioni comportano il blocco delle interfacce e dei permessi di accesso alla memoria e alle configurazioni MMU sino a quando il codice attendibile è in esecuzione. Quando il bit ITS è impostato, il sistema esegue un salto a una ROM di boot interna (IBR, Internal Boot ROM), a partire dalla quale esegue il boot. Il contenuto di questa ROM include il codice interno di secure boot (ISBC, Internal Secure Boot Code), il quale controlla il valore di cfg_rom_loc per determinare l’indirizzo del codice che lo sviluppatore vuole eseguire, assumendo che il secure boot superi la fase di controllo.

LA FASE DI BOOT ISBC

Il codice interno di secure boot (ISBC) è un codice sviluppato direttamente da Freescale che esegue sia dei controlli di validità del dispositivo sotto il punto di vista della sicurezza, che una verifica della firma digitale condotta su tutto il codice dell’applicazione presente in memoria RAM non volatile (NVRAM). Il codice applicativo prodotto dallo sviluppatore potrebbe essere un’immagine monolitica che comprende bootloader, sistema operativo, e programmi applicativi, oppure il secure boot potrebbe coinvolgere una sequenza di validazioni concatenate, in cui l’ISBC valida il bootloader, il bootloader valida il sistema operativo, e il sistema operativo valida l’applicativo. L’SDK di Freescale per i dispositivi appartenenti all’architettura trust include un esempio di catena di validazioni, partendo dall’ISBC che valida una versione modificata di u-boot denominata trusted u-boot. In alcuni documenti, il trusted u-boot viene anche indicato come codice di boot sicuro esterno (SEBC, Secure External Boot Code). La funzione principale dell’ISBC è quella di verificare l’autenticità dell’ESBC, il quale esegue una configurazione più estesa dei dispositivi e una verifica di autenticità del codice simile a quella eseguita dall’ISBC. L’ISBC accede alla memoria principale per ottenere il codice ESBC a partire da un indirizzo predefinito. L’ISBC si basa su un file header chiamato file di sequenza dei comandi (CSF, Command Sequence File) per determinare quando ha trovato un’immagine potenzialmente valida, e per conoscere la dimensione e altre caratteristiche dell’immagine da convalidare. L’header CSF viene aggiunto all’immagine prodotta dallo sviluppatore dal tool Freescale per la firma del codice. Se l’ISBC valida correttamente l’immagine (ESBC in questo esempio), il processore P1010 viene portato nello stato SECURE, e si esegue un salto a un entry point all’interno dell’ESBC. Se invece la validazione della firma digitale fallisce, il processore P1010 si porta nello stato FAIL, uno stato nel quale esso si rifiuta di eseguire il boot.

LA FASE ESBC

A differenza dell’ISBC, che è una ROM interna e quindi non modificabile, l’ESBC (trusted u-boot) rappresenta un codice di riferimento fornito da Freescale, e può essere modificato dai produttori dei sistemi (gli OEM). Di conseguenza, la seguente descrizione è basata sull’implementazione di riferimento fornita da Freescale, anche se sono possibili altri tipi di situazioni. Il trusted u-boot esegue le tipiche funzioni di configurazione relative all’uboot, come ad esempio la mappatura della memoria fisica, l’inizializzare delle interfacce di rete e l’infrastruttura relativa al data path, ed esegue poi il caricamento in memoria del software di livello superiore, come ad esempio il sistema operativo (il client trusted u-boot). Il client trusted u-boot possiede un header CSF con lo stesso formato di quello associato al trusted boot, il che consente al trusted u-boot di eseguire la validazione della firma relativa al client trusted u-boot. La chiave pubblica utilizzata per questa validazione può essere la stessa utilizzata dall’ISBC, oppure può essere una nuova chiave pubblica derivata dall’header CSF del client trusted u-boot. Se la validazione della firma viene superata correttamente, il trusted u-boot salta all’entry point all’interno del client e inizia l’esecuzione. Arrivati a questo punto, le configurazioni originali del dispositivo richieste dallo sviluppatore, il sistema operativo, e le applicazioni, possono essere considerati in esecuzione. Se il trusted u-boot non riesce a eseguire la validazione del client trusted uboot, il processore P1010 si porta nello stato FAIL, nel quale la CPU gira fino a quando non viene eseguito il reset.

IL TOOL CST

Per assistere gli utenti nella creazione di un’immagine del codice attendibile (trusted), incluso l’header CSF, Freescale offre un tool specifico, denominato CST (Code Signing Tool), il quale può firmare un’immagine sia in-line (cioè direttamente sul dispositivo QorlQ), oppure, come avviene generalmente, off-line. Il CST inizia generando una coppia di chiavi RSA pubblica e privata, utilizzando le API di OpenSSL. La coppia di chiavi consiste di tre parti (si vedano sia la Figura 1 che la Figura 2): N (modulo), E (esponente di crittografia), e D (esponente di decrittografia). La chiave pubblica è una combinazione delle componenti E e N, mentre la chiave privata è una combinazione di D e N. CST supporta chiavi con dimensione di 1024, 2048, oppure 4096 bit. Come detto precedentemente, una volta generata la coppia di chiavi è responsabilità dell’OEM tenere sotto controllo la chiave privata evitando che venga diffusa indebitamente. Il CST genera anche l’header CSF, come indicato in Figura 3 (gli indirizzi dei segmenti ESBC devono essere forniti in input al CST).

Figura 2: generazione della firma con il tool CST

Figura 2: Generazione della firma con il tool CST

 

Figura 3: l’header CSF

Figura 3: L’header CSF

CONCLUSIONI

A seguito della crescita esponenziale dei sistemi che includono dei dispositivi connessi in rete, è aumentata notevolmente la necessità di assicurare un elevato grado di sicurezza dei sistemi embedded. I sistemi embedded per applicazioni nel campo del networking, dei sistemi di accesso, e in quello industriale, costituiscono un business quantificabile in milioni di dollari, e l’impatto economico della indisponibilità di questi sistemi embedded (o la loro inusabilità a livello pratico a causa della mancanza di affidabilità del loro funzionamento) è di gran lunga superiore. Il codice open source viene sempre più spesso considerato come una serie di moduli che possono essere scaricati e inseriti all’interno di appositi spazi predisposti nel codice sviluppato dagli OEM, senza preoccuparsi eccessivamente delle loro origini e senza condurre un’analisi approfondita relativa alla presenza di eventuali backdoor all’interno dello stesso. La famiglia di processori QorIQ di Freescale è stata progettata espressamente includendo all’interno dei dispositivi della serie dei sottosistemi trusted che permettono agli utenti di soddisfare gli obiettivi di sicurezza richiesti dalla particolare applicazione, senza compromettere le prestazioni complessive del sistema. L’architettura trust della piattaforma QorlQ, disponibile sui processori P1010, P2040, P2041, P3041, P4040, P4080, P5010, e P5020, mette a disposizione degli OEM i punti cardine a livello hardware sui quali poter sviluppare un sistema affidabile sul piano della sicurezza. Un ulteriore supporto hardware durante la fase di avvio assicura che il codice di boot e quello run-time siano attendibili prima di mandarli in esecuzione, e impedisce l’accesso non autorizzato in debug quando il dispositivo si trova nello stato SECURE. L’architettura trust e le funzionalità di secure boot offerte dai processori della serie QorIQ forniscono agli OEM gli strumenti necessari per raggiungere un grado di sicurezza e attendibilità del sistema in grado di soddisfare i vincoli imposti in termini di dimensioni, peso e potenza.

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend