EO_503

DIGITAL SECURITY ELETTRONICA OGGI 503 - GIUGNO/LUGLIO 2022 50 sul bus di interconnessione principale in modo autonomo e indipendentemente dalle unità di attribuzione di sicu- rezza della CPU, senza ulteriori contromisure. Pertanto, è di vitale importanza che il microcontrollore implementi opzioni per definire l’attributo di sicurezza di ciascuno di quei canali periferici master e disponga di “filtri” specifici situati sul lato slave della comunicazione (davanti alle me- morie e alle periferichemappate inmemoria). Le violazioni delle politiche di accesso a livello di sistema devono anche essere in grado di attivare eccezioni (ovvero notifiche di interruzione) alla CPU principale, al fine di intraprendere azioni correttive. Qualsiasi sistema a microcontrollore sarebbe quasi inu- tile senza la capacità di eseguire operazioni di input e output su segnali digitali e analogici esterni. Anche la protezione di tali interfacce dall’uso improprio è un re- quisito fondamentale per prevenire le manomissioni, poiché questo è ovviamente il modo predefinito per in- teragire con l’MCU. Il progettista prudente dovrebbe as- sicurarsi che il microcontrollore possa limitare i livelli di accesso per le porte I/O e le periferiche, per impedi- re al software la possibilità di “prendere il controllo” di un’interfaccia in modo fraudolento, interferire con essa o spiare la comunicazione (in tal modo violando la politica di sicurezza). La funzionalità implementata consentirà di isolare le periferiche e le relative porte l’una dall’altra in modo sicuro. Tenendo presente i vincoli di spazio, spe- cialmente nei microcontrollori di piccole dimensioni, la quantità di interfacce funzionali può essere molto supe- riore al numero di pin fisici disponibili sul package; molti di questi sono condivisi insieme per consentire all’utente di scegliere. Durante la fase di sviluppo, per testare il software e ve- rificare che si comporti come previsto, è quasi obbligato- rio un dispositivo di debug basato su Jtag. Per sua stessa definizione, tale interfaccia può accedere a quasi tutte le risorse sul chip e quindi costituisce una backdoor si- gnificativa per qualsiasi applicazione che viene succes- sivamente implementata sul campo. I casi d’uso per la protezione di Jtag potrebbero essere molto diversi: alcuni vorrebbero bloccarlo in modo permanente, altri potreb- bero voler mantenere la capacità di debug sul campo e semplicemente proteggere l’accesso. Qualunque sia la strategia scelta, non sarà possibile aggirare una prote- zione permanente o accedervi senza un’adeguata auto- rizzazione; un codice di autenticazione o una chiave di proprietà dello sviluppatore deve essere richiesto in un meccanismo di “ challenge-response ”, e quest’ultimo deve essere completato con successo per consentire qualsia- si comunicazione successiva. Infine, il dispositivo deve supportare un meccanismo sicuro per rispedire il dispo- sitivo alla fabbrica per ulteriori analisi, nel caso si so- spetti un difetto del prodotto; ciò potrebbe comportare la cancellazione di eventuali risorse segrete archiviate, mantenendo comunque protetta l’interfaccia. Dopo lo sviluppo, l’immagine finale dell’applicazione è pronta per essere distribuita sul campo. Parte di esso po- trebbe essere soggetta ad aggiornamenti successivi, ma parte di esso deve essere immutabile per garantire che l’applicazione o il codice del boot-loader si trovi in uno stato noto in qualsiasi momento. Per supportare questo requisito, il microcontrollore deve avere la capacità di proteggere, in modo permanente dalle modifiche, parti della memoria non volatile definite dall’utente. Infine, ma non meno importante, ogni microcontrollo- re è sottoposto, in produzione, ad un lungo processo di test per verificarne il corretto funzionamento secondo le specifiche predefinite. Allo stesso tempo, molti risultati di tali test (come valori di calibrazione, dati specifici di produzione, e così via) e altre impostazioni relative all’MCU vengono memorizza- ti sul dispositivo. Questa modalità di test speciale non è significativa per un utente finale, ma essendo molto potente può accedere, controllare e potenzialmente manomettere tutte le ri- sorse del chip. Dal punto di vista della sicurezza, questa è un’altra potenziale backdoor e il produttore dovrebbe ga- rantire che una modalità di test non possa essere inserita in modo dannoso o per errore, una volta che il dispositivo è fuori dalla fabbrica e nelle mani del cliente. Fig. 4 – Secure Crypto Engine