EO526

DIGITAL INTELLECTUAL PROPERTIES creare il valore del contatore secondo il seguente schema: counter [127:0] = InitialValue [127:28] || (MemoryAddress [31:4] >> 4). Una soluzione semplice e flessibile L’implementazione presenta altre due interessanti carat- teristiche molto utili per renderla una soluzione flessibile e di facile utilizzo. In primo luogo, l’applicazione può defini- re un limite di indirizzo per la quale la DOTF sarà applicata, o altrimenti aggirata, come mostrato nella figura 3. Questa possibilità è molto comoda se per una determinata applicazione si vuole partizionare il contenuto della flash tra codice e altri dati, dove il codice viene decriptato “al volo” e i dati vengono semplicemente letti senza essere decriptati. Quest’ultima soluzione consente all’applicazio- ne di usare un’altra chiave o modalità di crittografia per i dati ed evita di condividere la chiave di criptografia/decrit- tografia per molteplici scopi. Per quanto riguarda l’allineamento dell’area DOTF, anche se lo standard di criptazione AES implica un allineamento minimo di 16 byte, data l’organizzazione tipica della me- moria flash, il confine deve essere posto su una dimen- sione pari ad un settore o blocco (la minima dimensione di flash che può essere cancellata durante la programmazio- ne). Nell’implementazione, il confine per la DOTF è confi- gurabile con un allineamento ad indirizzi di 4 KB; l’appli- cazione dovrebbe evitare di avere blocchi di memoria che hanno sia dati DOTF, sia dati non DOTF, in quanto questo renderebbe gli aggiornamenti sul campo e la programma- zione in fabbrica inutilmente complicati. La memoria flash esterna è mappata linearmente nello spazio di indirizzamento del MCU, e la periferica Octal SPI si occupa di inviare i comandi di lettura appropriati; que- stamodalità di funzionamento è tipicamente chiamata XiP (execute-in-place). Per l’area criptata, qualsiasi accesso ai blocchi di 16 byte può essere effettuato in modo efficien- te inviando una sola volta l’indirizzo richiesto e leggendo poi i dati in modo continuo, riducendo così al minimo l’o- verhead del protocollo OctaSPI. Un altro aspetto importante è il modo in cui viene gestita e caricata la chiave di decodifica. Nei dispositivi che sup- portano la funzionalità DOTF, all’interno dell’IP è imple- mentato un acceleratore AES dedicato. La chiave utilizzata per il processo di decriptazione è caricata attraverso un bus privato, riservato al solo sottosistema sicuro di Renesas, in questo modo si evita di mostrare il valore della chiave sul bus interno del MCU. Inoltre, la chiavi gestite della IP si- cura di Renesas sono a loro volta criptate, possono dunque essere salvate in modo sicuro all’interno della memoria senza problemi di riservatezza ed integrità. La periferica DOTF supporta chiavi di dimensioni 128, 192 e 256 bit per offrire massima flessibilità e adattarsi a spe- cifiche di progetto future. Non c’è un limite sul numero di chiavi che possono essere usate per decifrare una specifi- ca immagine. Quest’ultimo aspetto permette di utilizzare una differente chiave per ogni aggiornamento firmware se lo si desidera, e non è necessario condividere la stessa chiave tra differenti MCU. La preparazione di una nuova immagine può essere svolta comodamente offline attra- verso un host sicuro, prima di inviare l’immagine di ag- giornamento al dispositivo sul campo o di inviare l’imma- gine crittografata ad un fornitore per la programmazione. La chiave di decriptazione iniziale, o “chiave di aggiorna- mento” (per aggiornare la chiave di decriptazione sul cam- po), può essere salvata in modo sicuro nel MCU durante la produzione. Le chiavi salvate, sia sul campo sia in fase di produzione, sono sempre vincolate allo specifico MCU, in modo da evitare la clonazione. Inoltre, la IP fornisce contromisure per la protezione dagli attacchi side channel. Tutte le operazioni in fase di esecuzione sono svolte in modo trasparente dall’hardware, ed i driver software for- niti si preoccupano di inizializzare e caricare i parametri per eseguire le operazioni di DOTF (valori iniziali, confini) e la chiave, prima che l’operazione possa iniziare. Tutti i microcontrollori che richiedono l’espansione della memoria e requisiti applicativi complessi trarranno van- taggi da questo tipo di soluzione, che garantisce agli svilup- patori embedded una solida roadmap ed allo stesso tempo assicura una protezione per l’investimento software. Per maggiori informazioni sulla famiglia di MCU RA è pos- sibile visitare il sito all’indirizzo : www.renesas.com/ra . Figura 3 – Scelta dei confini per la DOTF ELETTRONICA OGGI 526 - MAGGIO 2025 48