I protocolli Thread e Wi-Fi assicurano una comunicazione wireless protetta e criptata tra i dispositivi. Tuttavia, le caratteristiche di sicurezza di questi protocolli proteggono solamente i canali di trasmissione e i dati in transito attraverso tali canali, ma non i dispositivi terminali contro le minacce di potenziali attacchi informatici. Per affrontare questa problematica, i produttori e dispositivi per la “casa intelligente” hanno collaborato allo sviluppo di Matter, un protocollo a livello applicativo espressamente ideato per proporsi come standard unificante capace di garantire l’interoperabilità tra gli ecosistemi della smart home come quelli di Amazon, Apple e Google. I dispositivi che supportano Matter possono comunicare gli uni con gli altri indipendentemente dall’ecosistema al quale partecipano. Un ulteriore vantaggio è derivato dal fatto che è implementato a livello applicativo, che può integrare funzionalità di sicurezza a livello del dispositivo.
In questo articolo verrà discusso in che modo la sicurezza a livello di dispositivo possa complementare la sicurezza del protocollo esistente, così da permettere ai produttori di dispositivi di garantire la conformità delle loro apparecchiature ai requisiti di sicurezza previsti dalla specifica Matter.
Identità del dispositivo
Matter definisce una struttura di certificazione gerarchica che deve essere seguita per autenticare il dispositivo come legittimo e ogni certificato deve essere firmato da un certificato che si trova al livello superiore della scala gerarchica. La specifica afferma che: “Tutti i nodi Matter che possono essere accoppiati devono includere un certificato DAC (Device Attestation Certificate – certificato per l’attestazione del dispositivo) e la corrispondente chiave privata, che è esclusiva per quel dispositivo”. L’utilizzo di un TRNG (True Random Number Generator) rappresenta un mezzo efficace per generare la chiave privata del DAC. Il componente in silicio alla base del dispositivo Matter (ad esempio, una lampadina intelligente) può generare un numero casuale utilizzando una fonte di entropia fisica (Fig. 1). Questo viene reso disponibile come ingresso per il TRNG che genera un numero casuale il quale, a sua volta, può essere usato dalla funzione di generazione della chiave per ricavare una chiave privata unica del DAC per il dispositivo Matter. L’utilizzo di un TRNG a elevata entropia è di fondamentale importanza perché fornisce al dispositivo un’identità unica e rende difficoltosa la realizzazione di dispositivi contraffatti mediante il “reverse engineering” della chiave privata a partire dalla corrispondente chiave pubblica da parte di eventuali criminali informatici.
Fig. 1 – Un TRNG genera una chiave privata del DAC unica per un dispositivo Matter
Archiviazione protetta delle chiavi
La specifica Matter stabilisce che “I dispositivi devono proteggere la riservatezza delle chiavi private di attestazione (DAC)” e “i nodi devono proteggere la riservatezza delle chiavi private operative dei nodi”. Esistono parecchie opzioni per l’archiviazione sicura delle chiavi, come, ad esempio, la creazione di celle di memoria integrate in un sottosistema di sicurezza. Un approccio di questo tipo comporta l’utilizzo di un maggiore spazio su silicio, con tutti gli oneri che ciò comporta. In alternativa, è possibile utilizzare una funzione PUF (Physically Unclonable Function – funzione non clonabile fisicamente) basata su un circuito integrato per generare una chiave per la PUF specifica di un dispositivo (Fig. 2). In questo modo è possibile crittografare tutti i contenuti chiave (inclusa la chiave privata del DAC) utilizzando una memoria standard senza dubbio più economica. Una funzione PUF è una struttura fisica celata all’interno di un circuito integrato che si basa sulle proprietà uniche a livello nano/micrometrico di un dispositivo ascrivibili alle inevitabili variazioni del processo di produzione, rendendo quindi molto difficile la clonazione. La soluzione più utilizzata è rappresentata dalla funzione PUF basata su SRAM (Static Random Access Memory). Una cella di memoria SRAM contiene sei transistor, due inverter a coppia incrociata e due transistor aggiuntivi per l’accesso. Nel momento in cui viene applicata una tensione alla cella di memoria, questa viene inizializzata nello stato “1” oppure “0” in funzione delle tensioni di soglia dei transistori che formano gli inverter a coppia incrociata. In presenza di una matrice di celle di memoria della SRAM di dimensioni sufficienti (da 1000 a 2000), il pattern casuale di “1” e “0” che si appare in fase di accensione può agire alla stregua di “impronta digitale” unica per quel particolare circuito integrato. Questa può essere utilizzata per generare una chiave della radice simmetrica denominata chiave della PUF, che a sua volta può essere sfruttata per criptare le chiavi che richiedono livelli più elevati di sicurezza in fase di archiviazione (come, ad esempio, la chiave privata del DAC). Poiché ciascuna porzione di silicio ricrea la propria chiave della PUF unica ogni volta che viene alimentata, è quasi impossibile per un potenziale intrusore scoprire la chiave della PUF. Una caratteristica essenziale della PUF è rappresentata dal fatto che questa impronta digitale unica viene archiviata in memoria solo nel momento in cui il dispositivo è alimentato, eliminando così il problema di come memorizzare la chiave di crittografia. In questo modo, i dispositivi sono protetti contro tutti gli attacchi logici e fisici finalizzati alla lettura delle chiavi. Un ulteriore vantaggio di questo approccio è la possibilità di memorizzare la chiave in modo sicuro e con la massima flessibilità, in quanto la chiave crittografata può essere memorizzata su dispositivi di archiviazione esterni senza il pericolo di compromettere la chiave privata.
Fig. 2 – Utilizzo della funzione PUF per archiviare le chiavi in modo sicuro
Una modalità alternativa per proteggere le chiavi private su un dipositvo Matter prevede il ricorso a un TEE (Trusted Execution Environment). Un TEE può essere usato per eseguire il partizionamento degli elementi hardware e software di un SoC (System-on-Chip) in ambienti di esecuzione sicuri e non, con barriere hardware che impediscono all’ambiente non sicuro l’accesso all’ambiente sicuro. Tali barriere non consentono l’accesso fisico alla memoria e ai controlli del sistema, oltre a limitare il numero delle commutazioni di stato. Solitamente, nell’ambiente di esecuzione non sicuro vengono eseguiti processi e applicazioni caratterizzate da superfici di attacco più ampie: esso, inoltre, è più soggetto ad attacchi remoti. Un TEE eseguito correttamente assicura una robusta protezione contro gli attacchi logici che hanno per obiettivo le chiavi private memorizzate nel software nell’area sicura, anche se non protegge dagli attacchi di natura fisica.
Fig. 3 – Un TEE può archiviare le chiavi private di un’applicazione
Crittografia dell’immagine e aggiornamenti in modalità OTA (Over-the-Air)
Si tratta di requisiti critici della specifica Matter, finalizzati a garantire che i dispositivi finali eseguano solamente codice autentico e il software possa essere caricato da remoto su di essi in modo sicuro. I produttori di dispositivi Matter devono essere in grado di assicurare l’autenticità del software che gira su di essi. Inoltre, devono garantire che tutti gli aggiornamenti software provengano da una fonte autorizzata, il che comporta la verifica dell’autenticità e dell’integrità del codice ricevuto. Per quanto concerne il primo problema, un approccio efficace prevede la validazione della firma su ciascuna porzione del software prima della sua esecuzione sul dispositivo (Fig. 4). Si consideri, ad esempio, la suddivisione della memoria di un dispositivo in tre sezioni: il codice nella ROM, il bootloader e il codice dell’applicazione. In questo caso, il codice nella ROM può essere usato per verificare la firma del codice del bootloader prima che venga eseguito, mentre il codice del bootloader, a sua volta, può verificare la firma del codice dell’applicazione. Tuttavia, sorge il problema di come autenticare il codice nella ROM. La soluzione consiste nell’utilizzare una RoT (Root of Trust), una memoria immutabile che fa girare una piccola porzione di software “fuzz-tested” (ovvero soggetto a fuzzing, una tecnica di test che prevede la fornitura di input casuali e non validi a un programma per scoprire vulnerabilità ed errori) che, almeno in teoria, non dovrebbe essere mai riscritto. Questo agisce come una “singola fonte di fiducia” al vertice della gerarchia di autenticazione. Il secondo problema può essere risolto utilizzando una chiave di crittografia OTA (Over The Air) per criptare l’aggiornamento software prima che venga inviato al dispositivo e per decriptarlo successivamente sul dispositivo, prima di consentirne l’installazione. In questo modo è possibile proteggere il canale di comunicazione e garantire che gli aggiornamenti provengano da una fonte autorizzata.
Fig. 4 – Autenticazione del firmware mediante una RoT (Root of Trust)
Protezione dei dispositivi in fase di produzione
La specifica Matter consiglia di equipaggiare con fusibili i dispositivi durante la produzione per impedire a eventuali intrusori di estrarre informazioni sui dispositivi stessi che potrebbero essere utilizzate per creare prodotti contraffatti. Essa suggerisce anche ai produttori di dispositivi di bloccare la porta di debug o di implementare “ancore” fidate per l’avvio sicuro. Tuttavia, il blocco non è auspicabile perché può rappresentare un limite per il debug. Un approccio alternativo consiste nel bloccare la porta di debug direttamente in fabbrica e offrire un accesso limitato a un gruppo selezionato di persone. Il primo passo per limitare l’accesso alle porte di debug prevede la creazione di una coppia di chiavi privata-pubblica e memorizzare la chiave pubblica nel dispositivo. Quando uno sviluppatore richiede l’accesso alla porta di debug per effettuare tale operazione, può firmare il comando di debug utilizzando la chiave privata corrispondente prima di inviarlo al dispositivo (Fig. 5). La firma sul comando viene verificata con la chiave pubblica prima di consentire l’avvio del debug. Tuttavia, se da un lato questo approccio richiede di limitare l’accesso al dispositivo hardware durante la produzione, dall’altro non attenua le conseguenze nei casi in cui un dispositivo sia stato precedentemente compromesso in un’altra fase del processo produttivo. Per creare chiavi sicure, i produttori di dispositivi Matter che vogliono ridurre le minacce nella fase di produzione in outsourcing dovrebbero programmare il dispositivo, oltre a fornire i certificati del dispositivo e le chiavi di sicurezza a una fonte di produzione fidata. Una prassi raccomandata è far eseguire ciò al produttore di circuiti integrati, in modo che gli asset che devono essere realizzati non vengano mai esposti (anche nel sito di produzione del silicio). Questo approccio riduce al minimo la possibilità che eventuali intrusori possano effettuare contraffazioni e clonazioni dei dispositivi.
Fig. 5 – La programmazione alla sorgente permette di incrementare la sicurezza
Considerazioni conclusive
I dispositivi per la “casa intelligente” devono essere il più sicuri possibile per proteggere i consumatori finali dagli eventuali violazioni della privacy. Garantire la sicurezza dei prodotti connessi di largo consumo è un compito complesso, in quanto essi vengono utilizzati in una pluralità di ecosistemi. Tuttavia, grazie alla rapida diffusione del protocollo Matter nel settore della casa intelligente, i produttori possono sfruttare le sue caratteristiche di sicurezza aggiuntive per proteggere i loro dispositivi intelligenti e i dati in transito tra di essi. Essi possono seguire le raccomandazioni della specifica Matter utilizzando alcune delle soluzioni discusse in questo articolo, in modo da alleviare le preoccupazioni dei loro clienti in materia di sicurezza e proteggere la reputazione del proprio marchio.
di Rohit Ravichandran – Product Manager – Security (Silicon Labs)
