Proteggere l’IP in un sistema embedded

PSoC1_Cypress Semiconductor_WEB

Il futuro di un’azienda dipende dallo sviluppo e dalla protezione delle proprie proprietà intellettuali, frutto di innovazione e di impegno. Per una società che produce sistemi embedded, una proprietà intellettuale può garantire un vantaggio competitivo rispetto alla concorrenza. Una Intellectual Property può presentarsi sotto varie forme: un metodo innovativo per risolvere un particolare problema; l’implementazione firmware di un sistema; l’implementazione hardware, cioè catene di segnale o controllo dell’uscita mediante tecniche innovative in grado di differenziare il prodotto. La sicurezza della proprietà intellettuale rappresenta un problema, in quanto i nuovi prodotti introdotti sul mercato sono esposti al rischio che su di essi vengano effettuate operazioni di “reverse engineering” che possono avere un impatto sulle vendite del prodotto nel caso di copiatura del progetto da parte di un concorrente. Quando si parla di sicurezza della IP integrata nei sistemi embedded, la prima cosa che viene in mente è il firmware associato al microcontrollore. Alcuni progettisti di sistemi non vanno al di là del firmware, tralasciando quindi di prendere in considerazione l’hardware che è anch’esso soggetto a fenomeni di copiatura. Questo hardware è utilizzato per interagire con le periferiche esterne, per rilevare gli ingressi, per generare le uscite e per eseguire operazioni di condizionamento del segnale. Si prenda ad esempio il sistema di controllo di una bicicletta elettrica. Il firmware scritto per la Mcu acquisisce segnali in ingresso come la tensione del bus, i comandi di velocità e così via, esegue il condizionamento dei segnali e li converte in formato digitale. Quindi effettua vari calcoli e formula decisioni in base al firmware scritto per la Mcu, come ad esempio controllare un motore e le uscite del Led. Nel caso della sicurezza della IP di un sistema embedded, si possono distinguere due aspetti: protezione contro accessi non autorizzati al firmware; occultamento delle risorse analogiche e digitali e delle relative interconnessioni.


Protezione contro accessi non autorizzati al firmware

Microcontrollori differenti prevedono diversi meccanismi per proteggere il codice memorizzato nella Flash contro tentativi di accesso non autorizzati. Alcuni, ad esempio, potrebbero non avere alcuna opzione di protezione. Al livello più alto, tutte le soluzioni ricorrono alla disabilitazione della lettura nell’area della memoria Flash. Alcuni dispositivi disabilitano l’accesso in lettura e scrittura relativamente all’intero sistema di memoria Flash. Tale soluzione rende impossibile l’aggiunta del supporto per un bootloader nel sistema finale. Se è necessario implementare un bootloader nel sistema e la sicurezza della IP riveste un ruolo importante, il progettista di sistema deve quindi scegliere un microcontrollore appropriato. In alcuni Mcu la memoria Flash è divisa in più blocchi e ciascun blocco è protetto con un livello di sicurezza differenziato. In dispositivi di questo tipo è possibile implementare un bootloader e ottenere nel contempo un livello di protezione adeguato. I dispositivi della linea PSoC1 di Cypress Semiconductor, ad esempio, supportano le seguenti modalità di protezione della Flash: modalità non protetta; modalità di aggiornamento in fabbrica; modalità di aggiornamento sul campo; modalità di protezione completa. La modalità di protezione selezionata viene caricata nei bit non volatili nel corso della programmazione e non possono essere modificati durante il funzionamento. Ciò evita la possibilità di modifiche accidentali al livello di protezione e non permette a un potenziale intrusore di modificare il firmware mediante la scrittura di codice specifico in un’area non protetta della Flash.

  • La modalità non protetta consente tutte le operazioni di lettura e scrittura esterne e interne. Questa modalità di protezione può essere usata in fase di sviluppo, quando il dispositivo non viene ceduto a terzi ma non dovrebbe essere utilizzato in produzione.
  • La modalità di aggiornamento in fabbrica è utile per tutti quei sistemi che richiedono l’aggiornamento di singoli blocchi della Flash da parte di un programmatore esterno. Questa modalità di protezione non consente letture dall’esterno, mentre è possibile effettuare scritture dall’esterno, nonché letture e scritture interne. Questo è il metodo da utilizzare nel caso un programmatore esterno debba aggiornare un particolare blocco senza cancellare l’intero contenuto della memoria. Questa modalità è utile ad esempio in un sistema che deve essere calibrato da un cliente o dal team che si occupa dell’installazione ed è richiesta la memorizzazione di questi dati di calibrazione nella Flash. Sebbene molto utile in un sistema come quello appena descritto, questa modalità deve essere evitata se è possibile implementarne una che garantisce una maggiore sicurezza. Ciò è dovuto alla mancanza di protezione contro scritture esterne. Nel caso qualcuno inserisca del codice nell’area aggiornabile per leggere il contento della Flash, la IP risulterebbe non protetta. In dispositivi di questo tipo, comunque, questo livello di sicurezza può essere assegnato solamente a blocchi specifici, mentre ad altri blocchi viene assegnato un livello di sicurezza più elevato. Di conseguenza è necessario accertarsi che in questi blocchi sia salvato solamente codice di tipo non critico.
  • La modalità di aggiornamento sul campo disabilita letture e scritture esterne mentre sono consentite le operazioni di lettura e scrittura interne. Quindi risulta impossibile effettuare letture/scritture mediante l’interfaccia di un programmatore. Questa modalità è dunque più adatta nel caso di sistemi che richiedano il supporto per il bootloading. Nel caso di sistemi embedded basati su bootloader, quest’ultimo riceve i dati che devono essere scritti nella Flash per mezzo di un protocollo di comunicazione e quindi effettua la scrittura nella Flash utilizzando un programma interno. In modo analogo, un’operazione di lettura viene effettuata utilizzando comandi interni. Quindi la Flash viene letta solamente nel caso in cui il bootloader decida di effettuare tale operazione. Il bootloader può essere memorizzato nei blocchi caratterizzati dal più elevato livello di sicurezza (modalità di protezione completa) in modo tale che non possa essere modificato. L’aggiunta di funzioni di cifratura alla comunicazione con il bootloader può contribuire a ridurre le probabilità di eventuali letture della Flash.
  • La modalità di protezione completa è ideale in fase di produzione nel caso i blocchi della Flash non debbano essere aggiornati sul campo o mediante programmi interni. Questa modalità impedisce qualsiasi accesso alla Flash in quanto sono disabilitate operazioni di lettura/scrittura sia interne sia esterne. Un livello di protezione adeguato deve essere impostato dal progettista di sistema mentre vengono generate gli hex file che devono essere programmati nei sistemi pronti per la produzione. Il compito del progettista deve prendere in considerazione tutte le possibili modalità atte a garantire la massima sicurezza della proprietà intellettuale.

Celare risorse analogiche, digitali e interconnessioni

Alcuni Oem utilizzano resina epossidica sui Pcb per rendere più difficile la lettura dei codici identificativi dei componenti da parte dei concorrenti. Nel caso di sistemi prodotti in elevati volumi, è possibile ottenere part number personalizzati stampati sui circuiti integrati, per rendere più complicata l’individuazione del part number effettivo. In ogni caso, nessuno di questi approcci è infallibile. Individuare le modalità di connessione dei vari blocchi sul Pcb non è un’operazione poi così complessa. La sola soluzione efficace per nascondere le diverse periferiche e le relative interconnessioni è procedere a un occultamento di tipo fisico. Nel caso fosse possibile celare tutte le connessioni all’interno di un unico chip, diventerebbe molto più difficile comprendere le catene del segnale e determinare il tipo di periferiche utilizzate nel sistema. Tenuto conto del fatto che l’integrazione delle periferiche all’interno di un unico chip contribuisce a occultare le informazioni relative all’hardware, i dispositivi System-on-Chip rappresentano la soluzione ideale quando si tratta di implementare misure di protezione contro tentativi di “reverse engineering”. Alcuni SoC, comunque, prevedono pin dedicati che rappresentano un vero e proprio varco da utilizzare per le operazioni di “reverse engineering”. Quando su un dispositivo vi sono pin dedicati riservati alle periferiche, risulta semplice determinare le periferiche utilizzate. Per questo motivo un dispositivo SoC che prevede funzionalità di istradamento flessibili e consente il collegamento di qualsiasi periferica con qualunque pin dà maggiori garanzie di sicurezza contro tentativi di “reverse engineering”. Nel caso fosse chiesto a un progettista quale delle tre implementazioni della scheda Pcb richiederebbe meno tempo per condurre a termine un’operazione di reverse engineering, la risposta più ovvia sarà l’implementazione riportata nella Fig 2a, in quando tutti i componenti sono chiaramente esposti sul Pcb. Nel caso dell’implementazione di Fig. 2b l’operazione di reverse engineering richiederà più tempo, anche se sarà possibile avere un’idea abbastanza chiare della realizzazione effettiva. Determinare l’implementazione riportata nella Fig. 2c è invece un’operazione alquanto complessa se non addirittura impossibile: si tratta infatti di una sorta di “black box” che acquisisce alcuni ingressi e fornisce alcune uscite. Non esiste alcuna possibilità di individuare la catena del segnale analogico implementata nel sistema perché in questo SoC è prevista la possibilità per tutte le periferiche di essere collegate a qualsiasi pin mentre internamente le periferiche possono essere connesse le une con le altre senza utilizzare nessun pin fisico. Inoltre non è possibile determinare la logica di protezione poiché non esiste un pin dedicato utilizzato per la logica programmabile. La sola possibilità per effettuare l’operazione di reverse engineering su questa soluzione è rappresentata dalla lettura dei registri che decidono le connessioni tra le periferiche e i pin, un’operazione questa che richiede l’espletamento di un compito molto impegnativo come la lettura della Flash. Nel caso si riuscisse a infrangere la sicurezza della Flash o se un progettista si dimenticasse di implementare la protezione richiesta per la Flash, sarebbe possibile determinare la catena del segnale nel caso in cui le periferiche hanno indirizzi fissi come accade per un gran numero di Mcu.

PSoc1, un esempio concreto

Un esempio di dispositivi che garantiscono il maggior livello di protezione possibile in un ambiente come quello appena descritto sono i componenti della serie PSoC1 di Cypress. Questi ultimi utilizzano blocchi analogici e digitali generici unitamente a un istradamento di tipo programmabile. Qualsiasi periferica può essere implementata nel medesimo blocco generico. Un blocco analogico programmabile, ad esempio, può essere impiegata per realizzare un amplificatore a guadagno programmabile, un convertitore A/D, un comparatore, un filtro o persino un blocco di rilevamento capacitivo. Un blocco digitale programmabile, invece, può essere configurato come un timer, un contatore, un Uart, un generatore Prs o persino un’interfaccia Spi. Ognuno di questi blocchi può essere collegato a qualsiasi pin. Tutto è deciso da alcuni bit del registro che vengono memorizzati nella Flash e quindi caricati durante il processo di boot. La posizione dove questi valori sono memorizzati nella Flash non è fissa e dipende dal programma. La posizione inoltre può essere variata dal progettista di sistema durante la compilazione. Senza dimenticare che questi valori possono essere cambiati durante l’esecuzione per riconfigurare questi blocchi in modo che si comportino come una periferica differente. Ad esempio, un blocco configurato come amplificatore a guadagno programmabile in fase di avviamento può essere riconfigurato per operare come un comparatore o un convertitore A/D. Questo significa che è praticamente impossibile eseguire il reverse engineering delle risorse hardware utilizzate nel progetto che sono implementate utilizzando questi dispositivi.

Pubblica i tuoi commenti