EO_503

ELETTRONICA OGGI 503 - GIUGNO/LUGLIO 2022 49 DIGITAL SECURITY co, dimensione del codice e reattività del sistema, grazie alla maggiore velocità di esecuzione. Detto questo, il primo elemento costitutivo della maggior parte dei protocolli crittografici è un TRNG (True Random Number Generator – generatore di numeri casuali reali), che deve essere convalidato e testato per le sue proprietà di entropia e la qualità della casualità (poiché un RNG mal costruito può rovinare, usandolo, la sicurezza di qualsiasi algoritmo). Per l’archiviazione locale, il supporto di algoritmi sim- metrici come AES con modalità operative multiple è quasi obbligatorio per crittografare e decrittografare la maggior parte dei dati. In combinazione con algoritmi di hashing (una sorta di checksum crittograficamente sicuro) come SHA-2 o SHA-3 è possibile eseguire semplici controlli di autenticazione e verificare che il contenuto dei dati non sia stato modificato. Per una connettività più avanzata, il dispositivo deve sup- portare algoritmi di crittografia asimmetrica come RSA o ECC (crittografia a curva ellittica), in modo da supporta- re, ad esempio, la verifica dell’identità nelle connessioni client/server, ricavare segreti per generare chiavi di ses- sione effimere o verificare l’origine e la legittimità di un aggiornamento del firmware. Tutti questi acceleratori de- vono anche essere in grado di generare chiavi utente su chip, per l’utilizzo locale. La gestione delle chiavi In ogni caso, il problema difficile dietro il loro utilizzo è la gestione delle chiavi. Il bene più prezioso rappresentato dalla chiave dell’utente deve essere tutelato mantenendo- ne la riservatezza (non esponendone il valore), l’integrità (non permettendo che la chiave venga modificata in modo impercettibile) e garantendone la disponibilità. Questo apre molti scenari da considerare; da quando la chiave vie- ne iniettata (memorizzata) nel sistema, come viene tra- sportata lì, come viene caricata nell’hardware crittografico e protetta da perdite durante il funzionamento. Idealmente, il materiale della chiave non deve essere ge- stito dal software applicativo in testo normale, ovvero in formato chiaro, poiché sarà esposto in modo pericoloso. Un modo semplice per impedirlo potrebbe essere quello di gestire la chiave all’interno dell’area protetta definita dalla TrustZone, ma la cosa migliore sarebbe utilizzare le chia- vi solo all’interno di un sottosistema dedicato isolato dal resto. Un problema simile si pone una volta che le chiavi sono (tipicamente) memorizzate nella memoria non vola- tile; per evitare una violazione della riservatezza, tecniche come il “wrapping” delle chiavi (essenzialmente, la critto- grafia delle chiavi) possono aiutare a proteggere la privacy della chiave dell’utente. Rendere unici i dati incapsulati su ogni MCU aiuta ulteriormente contro la perdita di chiavi condivise ed elimina il rischio di copia delle chiavi (clona- zione), da un sistema esistente a un altro. Ovviamente per implementare tale meccanismo è obbligatoria una “root of trust” per lo storage; quindi, il sottosistema crittografico deve avere accesso esclusivo a una “chiave di crittografia della chiave” unica per ogni microcontrollore. La “root of trust”, essendo unica per ogni MCU, evita che la compro- missione di un dispositivo specifico consenta un attacco di “classe” a tutte le apparecchiature che montano la stessa unità. Un altro aspetto importante è valutare la robustezza del sottosistema crittografico contro gli attacchi DPA e SPA, che registrano e analizzano le tracce del consumo ener- getico e possono decodificare il valore della chiave. Que- sto tipo di attacchi sta diventando sempre più economico e veloce da implementare, anche per chi non è altamente qualificato e dispone di risorse limitate. Se l’accesso fisico al dispositivo è fonte di preoccupazione e non ci sono al- tri mezzi di controllo dell’accesso nel sistema, dovrebbero essere disponibili e utilizzate contromisure contro tali mi- nacce. Inoltre, sarà auspicabile anche qualsiasi funzione di rilevamento precoce, in grado di monitorare gli IO collegati all’alloggiamento dell’apparecchiatura, generare una no- tifica al sistema e, eventualmente, acquisire un timestamp quando viene rilevata una manomissione. Per semplificare la vita dell’utente, il sottosistema deve consentire un modo per effettuare il provisioning, ovvero la possibilità di “iniettare” le chiavi scelte dall’utente nel dispositivo e trattarle per poi essere conservate in modo sicuro e pronte per un successivo utilizzo dell’applicazione. Il microcontrollore dovrebbe supportare un’interfaccia per il provisioning delle chiavi sia sul campo sia in fabbrica, rendendo semplice sia la produzione sia, successivamen- te, il provisioning e l’aggiornamento sul campo. Anche tale fase di provisioning deve essere protetta, ovvero non dovrà esporre alcun contenuto importante, mentre è in transito nell’MCU. Oltre la CPU Considerando ora l’implementazione del software, gli ap- procci citati finora si sono concentrati sulla CPU principale che esegue il software applicativo, tuttavia, nei moderni microcontrollori, altre entità funzionali sono in grado di trasferire autonomamente dati da e verso memoria o pe- riferiche, per migliorare le prestazioni, in modo più effi- ciente utilizzando la larghezza di banda disponibile. Alcuni esempi includono motori DMA, controller grafici, control- ler Ethernet e simili. Tutte le funzionalità di isolamento relative a TrustZone sono prive di significato per queste periferiche, poiché questi possono effettuare transazioni