Protezione dei sistemi embedded con PSoC 64

Di Jacob Beningo

Contributo di Editori nordamericani di DigiKey

Il numero di prodotti connessi a Internet continua a crescere in modo esponenziale. Il problema di molti team di prodotto è che gli sviluppatori di software embedded non hanno sufficiente esperienza in materia di sicurezza. La mancanza di esperienza può portare a trascurare i requisiti di sicurezza, a creare lacune nella sicurezza e a una scarsa implementazione. Il risultato è che i sistemi connessi sono scarsamente protetti e sono un facile bersaglio per il furto della proprietà intellettuale, oltre che dei dati dei dispositivi e degli utenti.

I progettisti di sistemi basati su microcontroller hanno a disposizione diverse soluzioni per semplificare le implementazioni di sicurezza e gli strumenti per farlo con successo. Ad esempio, i microcontroller single core possono utilizzare TrustZone di ARM, che fa parte dell'architettura Armv8-M (e oltre). Esistono anche soluzioni con microcontroller multicore.

Questo articolo mostra come gli sviluppatori possono utilizzare i processori multicore per proteggere le loro soluzioni embedded. In particolare, viene esaminato il microcontroller sicuro PSoC 64 di Cypress e gli strumenti per implementare una soluzione sicura.

Fondamenti di sicurezza embedded

Uno dei fondamenti della progettazione di un prodotto sicuro è quello di sfruttare l'isolamento basato sull'hardware. L'isolamento può assumere diverse forme, come un ambiente di esecuzione isolato o una memoria isolata basata su un'unità di protezione di memoria (MPU). Al livello più alto, un microcontroller deve essere in grado di separare il suo ambiente di esecuzione in un ambiente di elaborazione sicuro (SPE) e in un ambiente di elaborazione non sicuro (NSPE).

Un SPE è un ambiente di esecuzione isolato che mantiene la memoria, i componenti e il codice applicativo separati dall'NSPE. L'SPE può essere considerato un processore di sicurezza. L'SPE esegue codice e operazioni sicure, come un sistema operativo sicuro e/o una radice di attendibilità (RoT). L'SPE eseguirà anche servizi di attendibili come crittografia, archiviazione sicura, attestazione e registrazione sicura. Nell'SPE viene eseguito un numero limitato di applicazioni attendibili relative a operazioni sicure.

L'NSPE, invece, può essere considerato come un ambiente di esecuzione ricco di funzionalità che esegue tutto, tranne le operazioni sicure. In realtà, l'NSPE è il modello di programmazione familiare a cui è abituata la maggior parte degli sviluppatori embedded; ha un RTOS e la maggior parte dei componenti dell'applicazione.

L'isolamento basato sull'hardware è uno dei principi fondamentali, o best practice, forniti dalla Platform Security Architecture (PSA) di ARM® per costruire sistemi sicuri. I diversi livelli di isolamento di cui abbiamo appena parlato sono illustrati nella Figura 1, con il PSoC 64 come esempio. In questo esempio, l'SPE e l'NSPE (1) producono l'isolamento hardware avendo gli ambienti di esecuzione su processori separati. Oltre alla separazione del tempo di esecuzione, i servizi RoT e attendibili sono ulteriormente isolati (2). Infine, ogni applicazione attendibile nell'SPE viene isolata utilizzando strumenti come partizioni attendibile e MPU (3).

Schema di un'applicazione sicura che utilizza l'isolamento basato sull'hardwareFigura 1: Un'applicazione sicura utilizza l'isolamento basato sull'hardware per separare gli ambienti di esecuzione. 1) NSPE e SPE sono isolati 2) servizi RoT e attendibili sono isolati 3) le applicazioni attendibili sono isolate. (Immagine per gentile concessione di ARM/Cypress)

Il PSoC 64 è un microcontroller dual core in cui l'NSPE viene eseguito su un processore ARM Cortex®-M4 e l'SPE su un processore ARM Cortex-M0+. ARM Cortex-M0+ gestisce tutte le funzioni di sicurezza e può comunicare con Cortex-M4 attraverso un bus di comunicazione interprocessore (IPC). L'architettura limita l'accesso all'SPE, che è isolato a livello di hardware.

Per iniziare a utilizzare il PSoC 64, gli sviluppatori possono affidarsi al kit PSoC 64 Secure Boot Pioneer.

Il kit PSoC 64 Secure Boot Pioneer

Il kit PSoC 64 Secure Boot Pioneer (Figura 2) ha tutto l'occorrente per gli sviluppatori per iniziare a proteggere le loro applicazioni. Innanzitutto, ha un modulo PSoC 64 che contiene il microcontroller PSoC 64, la memoria esterna e tutti i circuiti di supporto (indicati in rosso). La memoria esterna può essere utilizzata per archiviare il codice dell'applicazione o le nuove immagini del firmware per gli aggiornamenti sicuri del firmware via etere (OTA).

Immagine del kit PSoC 64 Secure Boot PioneerFigura 2: Il kit PSoC 64 Secure Boot Pioneer Kit ha tutto l'occorrente per gli sviluppatori per iniziare a sviluppare applicazioni IoT sicure. (Immagine per gentile concessione di Cypress)

Inoltre, è dotato di un modulo Wi-Fi che consente agli sviluppatori di collegare la scheda a una rete. Il modulo Wi-Fi è particolarmente utile per le applicazioni IoT in cui la scheda si connette a servizi cloud come AWS o Azure. La scheda di sviluppo supporta Amazon FreeRTOS, di cui parleremo nella prossima sezione.

Infine, il kit Pioneer supporta un'ampia gamma di espansioni, come le basette pin, le basette di Arduino e una serie di sensori. Gli sviluppatori possono sfruttare il cursore tattile e i pulsanti a sfioramento, vari altri pulsanti, il potenziometro e molto altro. La scheda è inoltre predisposta per consentire una facile personalizzazione per pressoché tutte le applicazioni.

La suite software sicura PSoC 64

La progettazione di un'applicazione embedded sicura può richiedere molto tempo ed essere impegnativa. Gli sviluppatori dovrebbero cercare soluzioni che aiutino a ridurre i costi e il time-to-market, garantendo al contempo la sicurezza delle loro applicazioni. A tal fine, il PSoC 64 offre un'ampia gamma di software che consente di creare rapidamente un'applicazione sicura.

Ad esempio, CySecureTools fornisce un set di strumenti per la creazione di chiavi e certificati, nonché strumenti per la firma delle applicazioni utente e il provisioning dei microcontroller Cypress. Lo strumento consente di trasferire la RoT di Cypress e quindi di iniettare le proprie risorse di sicurezza. Le informazioni su come configurare e utilizzare CySecureTools si trovano nel file README del repository github.

Uno strumento che gli sviluppatori IoT troveranno utile è il supporto per AWS con FreeRTOS. Il repository github contiene esempi pratici per l'utilizzo di FreeRTOS e AWS con il PSoC 64. Il primo esempio d'interesse è l'applicazione "Hello World" che trasmette messaggi MQTT dal PSoC 64 al cloud AWS. L'esempio consente di seguire il processo di provisioning, la generazione delle chiavi e le fasi di distribuzione. Alla fine dell'esempio, gli sviluppatori hanno un dispositivo embedded sicuro collegato ad AWS. I dettagli su come iniziare sono riportati nella guida Primi passi del kit CY8CKIT-064S0S204343.

Applicazioni sicure con Trusted Firmware-M (TF-M)

Il PSoC 64 offre agli sviluppatori un framework di sicurezza pronto all'uso facilmente personalizzabile per un'applicazione. Gli sviluppatori possono trovare utile capire cosa succede dietro le quinte dal punto di vista del software. In particolare, il firmware del PSoC 64 sfrutta un framework di sicurezza di base open-source noto come Trusted Firmware-M, o TF-M.

TF-M è un'implementazione di riferimento dell'ARM PSA IoT Security Framework. Fornisce agli sviluppatori utili strumenti di sicurezza come l'attestazione del dispositivo, la verifica del firmware, i servizi crittografici, la gestione dei segreti del dispositivo e il partizionamento sicuro, tanto per citarne alcuni. Cypress ha sfruttato TF-M per costruire il suo framework di sicurezza, in modo che gli sviluppatori possano utilizzarlo nelle loro applicazioni.

Gli sviluppatori possono modificare il loro framework di sicurezza aggiungendo il proprio codice, profili di sicurezza e molto altro. Tuttavia, è importante tenere presente che più il software SPE viene modificato, maggiore è la possibilità che si introducano vulnerabilità. Gli sviluppatori devono valutare attentamente i rischi associati a modifiche, aggiunte o sottrazioni al firmware di base.

Suggerimenti e accorgimenti per la sicurezza delle applicazioni embedded

Gli sviluppatori che cercano di rendere sicure le loro applicazioni embedded per la prima volta hanno molti aspetti da considerare. Ecco alcuni accorgimenti che possono semplificare e velocizzare lo sviluppo:

  • Eseguite un modello di minaccia e un'analisi di sicurezza (TMSA) nelle prime fasi del ciclo di sviluppo.
  • Utilizzate una scheda di sviluppo per testare la RoT del dispositivo, Secure Bootloader, il processo di provisioning del dispositivo e gli aggiornamenti del firmware.
  • Non implementate la sicurezza da soli! Sfruttate gli stack di firmware open source e sicuri esistenti per ridurre al minimo il dover ripetere il lavoro.
  • Assicuratevi di pensare al ciclo di vita del dispositivo, compreso il modo in cui deve essere smantellato in modo sicuro.
  • Esplorate strumenti come CySecureTools; tali strumenti sono dotati di modelli di sicurezza, software ed esempi.
  • Quando si clona il repository github di FreeRTOS, clonare l'ultima versione taggata. Clonando la mainline attiva spesso si scoprono incompatibilità di strumenti e bug ancora presenti.
  • Avviate un progetto seguendo le istruzioni per l'uso del kit CY8CKIT-064S0S2-4343W di Cypress. Fornisce tutte le informazioni necessarie per eseguire un'applicazione di base, che poi può essere modificata per gli scopi specifici del prodotto.

Seguendo questi consigli, gli sviluppatori risparmieranno parecchio tempo.

Conclusione

La sicurezza non deve per forza essere difficile. Gli sviluppatori embedded dovrebbero concentrarsi sui fattori di differenziazione del loro prodotto, la loro salsa segreta. Nella maggior parte dei casi, questa non è la sicurezza. Questo articolo ha analizzato come il PSoC 64 possa aiutare gli sviluppatori a rendere sicure le loro applicazioni fornendo non solo un ambiente di isolamento basato sull'hardware, ma anche un framework di strumenti software. Insieme, le soluzioni hardware e software offrono agli sviluppatori un accelerato ciclo di sviluppo della sicurezza.

DigiKey logo

Esonero della responsabilità: le opinioni, le convinzioni e i punti di vista espressi dai vari autori e/o dai partecipanti al forum su questo sito Web non riflettono necessariamente le opinioni, le convinzioni e i punti di vista di DigiKey o le sue politiche.

Informazioni su questo autore

Image of Jacob Beningo

Jacob Beningo

Jacob Beningo è un consulente software embedded e attualmente lavora con clienti in più di una decina di paesi per trasformare radicalmente le loro attività migliorando la qualità dei prodotti, i costi e il time-to-market. Ha pubblicato più di 200 articoli sulle tecniche di sviluppo di software embedded, è un relatore e un istruttore tecnico e ha conseguito tre lauree, tra cui un master in ingegneria presso University of Michigan. Risponde all'indirizzo jacob@beningo.com, ha un sito web personale www.beningo.com e produce una Newsletter mensile Embedded Bytes cui è possibile iscriversi.

Informazioni su questo editore

Editori nordamericani di DigiKey