EMB_89

EMBEDDED 89 • SETTEMBRE • 2023 44 HARDWARE | CRYPTOGRAPHIC CONTROLLERS ficare il firmware e mantenere il processore host in reset, assi- curandosi che non possa svolgere alcuna azione fino a quando l’intero processo di avvio non sia stato verificato. Il secondo assioma è l’autenticazione del codice basata su har- dware, che utilizza coppie di chiavi pubbliche-private per fir- mare e autenticare le immagini del codice. In terzo luogo, sono disponibili aggiornamenti del firmware si- curi, che consentono di installare in modo sicuro le versioni fu- ture del firmware e di offrire la stessa protezione. La soluzione Root of trust Microchip è NIST 800-193 compliant, dove NIST sta per National Institute of Standards and Tech- nology. Questo standard indica la capacità di una piattaforma di proteggere, rilevare e recuperare. Le soluzioni di Microchip proteggono dagli attacchi malware e rilevano qualsiasi attacco in corso. Ad esempio, se un’immagine di dati fosse compromes- sa o danneggiata, sarebbe recuperabile da una immagine prece- dente valida e l’avvio potrebbe ancora avere successo. C’è anche una vasta gamma di algoritmi di crittografia tra cui scegliere, certificati dal programma di convalida dell’algoritmo crittografico. Infine, il processo è molto veloce, fluido e appena percettibile. Una verifica dell’immagine del codice, in generale, comporterà un ritardo dell’ordine di poche centinaia di millisecondi del tem- po di avvio. Il processo di secure boot Il diagramma di figura 1 mostra come un processore di appli- cazioni utilizzi il CEC1712 per verificare il suo codice di avvio. Il codice che si vuole eseguire è memorizzato in una memoria flash con interfaccia SPI esterna al processore dell’applicazione. Due immagini di codice identiche che saranno etichettate come “immagine 0” e “immagine 1” possono essere utilizzate per l’au- tenticazione. Nel caso in cui l’immagine primaria, l’immagine 0, sia danneggiata, è possibile tornare all’immagine 1. Al momento dell’avvio, il processore host viene tenuto in reset e non può operare. CEC1712 è il primo dispositivo del sistema che si avvia. Carica l’immagine CEC 0 nella SRAM interna del CEC1712 e verifica la presenza di una firma digitale utilizzando coppie di chiavi pubbliche private memorizzate all’interno del blocco OTP. Se la firma viene verificata, fa uscire il processore host dallo sta- to di reset, consentendo a quest’ultimo di iniziare l’esecuzione. Il codice di avvio verrà caricato in blocchi dallo SPI flash nel processore host. Se l’autenticazione non ha successo, l’immagi- ne 1 CEC completamente ridondante, o “golden image”, verrà caricata nella SRAM di CEC1712. Se l’autenticazione ha esito positivo, rilascerà il processore host dal reset e leggerà il codice dallo SPI flash direttamente nel processore host, abilitandone l’esecuzione. Le soluzioni Root of trust di Microchip sono ampiamente adot- tate nei server e nei sistemi di elaborazione client e utilizzate anche nel mercato delle telecomunicazioni e nelle applicazioni per veicoli a guida autonoma (sistemi ADAS). Tutto ciò che è ne- cessario per garantire la compatibilità con queste soluzioni è la possibilità che il processore host si avvii da un flash SPI esterna. Una configurazione di questo tipo è spesso indicata come exter- nal root of trust (E-ROT). Aggiornamenti sicuri Il diagramma di figura 2 descrive il modo in cui la Rom di avvio di CEC1712 esegue gli aggiornamenti sicuri. Il meccanismo è identico a quello dell’avvio protetto, ma il funzio- namento è leggermente diverso. Nella flash SPI sono presenti una golden image CEC e un’immagine di aggiornamento CEC, anziché due immagini identiche. All’ac- censione, l’immagine di aggiorna- mento viene caricata nella SRAM del CEC1712 se autentica, e verrà eseguita sul processore host. Un riavvio del sistema attiverà e sovrascriverà la precedente golden image . Questo riporta allo Fig. 1 – Esempio di utilizzo di CEC1712 da parte del processore host per verificare il suo codice di avvio