EMB_82

EMBEDDED 82 • NOVEMBRE • 2021 41 SECURE ELEMENT | HARDWARE Implementazione di una soluzione Dato che anche per volumi medio-bassi ora si ha ac- cesso ad un modo conveniente per inserire la gestione sicura dell’identità nei propri dispositivi, il passaggio successivo consiste nel configurare l’elemento di sicu- rezza nel modo più appropriato per i loro casi d’uso. Questo perché il dispositivo deve essere sottoposto a provisioning con le credenziali e altre risorse crit- tografiche utilizzate per il modello di autenticazione specificato. Oltre all’identità del dispositivo principale, potrebbero essere presenti chiavi private ed elementi segreti aggiuntivi che devono essere inseriti nell’ele- mento hardware. Ad esempio, quelli non derivati dalla root key potrebbero essere necessari per autenticare accessori, periferiche, contenuti di terze parti e host remoti in modo che le loro credenziali possano essere gestite separatamente. Il principio che sta alla base dell’elemento sicuro è che controlla l’accesso alle risorse vitali e agisce come un controllo contro attività non autorizzate, per esempio i tentativi di sostituire il firmware approvato dal pro- duttore con codice dannoso, e che potrebbero tentare di utilizzare le informazioni segrete che il dispositivo detiene per eseguire ulteriori attacchi. Un requisito fondamentale per garantire che gli ag- gressori non possano penetrare e riprogrammare un dispositivo è l’utilizzo di una strategia di secure-boot che, a sua volta, sia protetta da un elemento sicuro. Il secure-boot garantisce che il dispositivo IoT possa eseguire solo codice autorizzato. In condizioni di secu- re-boot, il dispositivo può caricare solo blocchi di codi- ce con hash e firma da una chiave privata di proprietà del produttore. Quando il microcontroller deve caricare il codice dalla boot-ROM, il microcontroller richiede la verifica dal- la truly immutable public key detenuta dall’elemento protetto. Solo se quella verifica viene superata, l’MCU tenta di caricare il codice. Se il dispositivo incontra un blocco di codice firmato in modo errato, interrompe il caricamento del software compromesso e tenta di ripri- stinare uno stato programmato in fabbrica o, se non è possibile, di disattivarlo. Finché il codice del MCU bo- otloader non può essere modificato, poiché inserito nel- la ROM o nella flash protetta, la funzione di controllo stessa non può essere aggirata. Con le procedure di core security in atto, è possibile aggiungere facilmente altri casi d’uso, come il suppor- to per l’autenticazione basata su certificati sui server remoti, un ingrediente chiave questo per i dispositivi IoT. Questa autenticazione remota utilizza protocolli standard come Transport Layer Security (TLS) per la comunicazione crittografata e X.509, utilizzato per ge- stire i certificati digitali che dimostrano che un disposi- tivo o un servizio è autentico. Con lo standard X.509, tutti i certificati digitali fanno ri- ferimento a uno principale OEM tramite una gerarchia di certificati figlio. Le informazioni trasportate dai cer- tificati forniscono i mezzi per identificare il legittimo proprietario di ciascun certificato e da questo ottenere la chiave pubblica del certificato più in alto nella ge- rarchia in modo che la firma del certificato dipendente possa essere convalidata. Quando un dispositivo IoT adeguatamente protetto co- munica con un server remoto, utilizza le informazioni nei certificati in suo possesso per dimostrare di essere un utente valido del servizio. Al contrario, il server uti- lizza il proprio set di certificati per confermare al dispo- sitivo che anch’esso è autentico. Finché il dispositivo contiene i certificati richiesti, l’autenticazione bidire- zionale può essere garantita. Nel contesto dell’IoT, i certificati digitali possono esse- re utilizzati per semplificare il processo di onboarding dei dispositivi quando vengono alimentati per la prima volta e tentano di connettersi al loro fornitore di servi- zi su Internet. Ciò si ottiene inoltrando i certificati ne- cessari ai server quando l’elemento protetto viene pro- grammato per la prima volta e archiviando i certificati che il dispositivo utilizzerà per autenticare quei server nell’elemento insieme alla chiave privata principale del dispositivo. Come esempio di questo approccio, Micro- chip ha lavorato con le funzionalità di Amazon Web Services (AWS) per consentire a qualsiasi prodotto creato utilizzando la Trust Platform di essere integra- to in questo modo nei servizi AWS IoT. Il supporto per protocolli standard e sistemi di certificazione si traduce nel fatto che le stesse tecniche possono essere utilizzate facilmente con altri servizi cloud, come Microsoft Azu- re, nonché infrastrutture cloud private e ibride. Un altro caso d’uso chiave per l’IoT è quello degli ag- giornamenti over-the-air (OTA) del firmware per i di- spositivi IoT. Questi aggiornamenti offrono la possibili- tà di correggere le vulnerabilità della sicurezza, senza rischiare che i dispositivi vengano compromessi dal processo stesso di aggiornamento. Gli aggiornamenti firmati digitalmente inviati OTA possono essere con- trollati in modo simile al codice verificato durante il boot protetto per verificarne l’autenticità prima che l’aggiornamento possa essere applicato. Una volta po-