EO_503

ELETTRONICA OGGI 503 - GIUGNO/LUGLIO 2022 48 DIGITAL SECURITY terruzione non sicura mentre la CPU è in modalità protet- ta, i registri vengono salvati, per impostazione predefinita, nello stack protetto e il loro contenuto viene cancellato au- tomaticamente. Ciò serve a prevenire la fuga involontaria di informazioni dall’area protetta. Il partizionamento delle eccezioni (interrupt periferici) da assegnare all’ambiente protetto o non protetto, è supportato tramite una tabella vettoriale di interrupt dedicata e separata, all’interno di ciascun dominio. Allo stesso modo, esiste un’implemen- tazione separata dei puntatori dello stack, dei timer e così via. Interrogazioni in parallelo Fin qui tutto bene, ma come vengono definite sicure quelle aree di memoria e come i loro confini? Ci sono due unità che vengono interrogate in parallelo: la SAU (security at- tribution unit - unità di attribuzione di sicurezza) e l’IDAU (implementation-defined attribution unit - unità di attri- buzione definita dall’implementazione). Ad ogni accesso alla CPU, entrambe le unità eseguono una ricerca dell’in- dirizzo e rispondono con l’attributo di sicurezza associato a quell’indirizzo. La risposta delle due unità viene combi- nata, per definire l’attributo indirizzo; il principio generale è che la più rigida delle due vince (il che significa che non è possibile “sovrascrivere” un’impostazione di regione sicura con un attributo meno sicuro). Infine, l’attributo di sicurezza combinato per quell’indirizzo viene valutato ri- spetto alla politica definita come nella figura 1. Se l’accesso è legittimo, può procedere, altrimenti viene bloccato e viene sollevata un’eccezione (interrupt sicuro) a livello di CPU. In particolare, la configurazione della SAU (quante regioni sono supportate, le impostazioni predefinite, e così via) può esseredefinita in fasedi progettazione,mentre l’implemen- tazione dell’IDAU è lasciata al produttore del dispositivo. Per proteggere i singoli thread l’uno dall’altro e migliorare la robustezza complessiva del software contro gli errori, si possono utilizzare, all’interno di ciascun dominio, le uni- tà di protezione della memoria (MPU). La figura 3 mostra come partizionare l’applicazione software su un micro- controllore che supporta TrustZone: Finora abbiamo raggiunto qualche obiettivo relativo alla sicurezza? In realtà, non ancora. TrustZone fornisce un isolamento tra i thread dell’applicazione in esecuzione nell’ambiente protetto e quelli in esecuzione nell’ambiente non protetto, ma non fornisce alcuna “sicurezza” di per sé e non può controllare quali thread accedono all’ambiente sicuro, ovvero non può imporre la legittimità, ma piutto- sto prevenire l’uso non intenzionale o l’accesso diretto alle risorse. In sostanza, è lo sviluppatore che decide quale parte dell’applicazione deve essere isolata e questo dipende for- temente dall’applicazione. L’isolamento tramite la Trust- Zone può essere utilizzato per proteggere qualsiasi risorsa e migliorare l’affidabilità di un’applicazione, rispetto a un approccio classico basato su MPU che si basa solo su un li- vello privilegiato (ma è abbastanza facile da modificare ed aggirare nel software). D’altra parte, inserire all’interno dell’area TrustZone l’operazione relativa alla crittografia sembra una buona idea per la maggior parte delle appli- cazioni che richiedono crittografia. È importante che il sistema applichi tali impostazioni fin dall’inizio dell’ese- cuzione (al reset) e che la configurazione di tali limiti non possa esseremanomessa. Tale configurazione potrebbe, ad esempio, essere archiviata in un’apposita area di memoria che non sia direttamente modificabile dalla CPU stessa. La crittografia Per i requisiti tipici relativi alla sicurezza (crittografica), la buona pratica suggerirebbe di mantenere la quantità di funzionalità implementata all’interno dell’ambiente pro- tetto, il più essenziale e minima possibile. Ciò per ridur- re la possibilità di comportamenti scorretti dovuti a bug nell’implementazione del software, errori di runtime e sfruttamento dannoso di eventuali difetti del software da parte di un utente malintenzionato che tenta di ottenere l’accesso non autorizzato alle risorse dell’MCU. Come ef- fetto collaterale, seguire questo principio rende anche la convalida della funzionali- tà molto più semplice durante il debug e il test, poiché c’è meno da testare. Quali risorse deve fornire un microcon- trollore in grado di gestire gli algoritmi di crittografia? Dipende dalla complessità dell’applicazione; se è vero che per una so- luzione “ entry level ” potrebbe essere uti- lizzata anche una pura routine software, è anche vero che avere il supporto per algo- ritmi crittografici nell’hardware, ha molti vantaggi in termini di consumo energeti- Fig. 3 – Partizionamento tramite TrustZone e MPU