Qualche giorno fa siamo stati invitati al webinar su IoT Security offerto da Distrelec e Arduino.

Riportiamo di seguito una parte dei concetti appresi, estesa dalle nostre considerazioni personali in merito e da alcune delle slide prodotte dal CISO Arduino, Gianluca Varisco, che ringraziamo anche in questa sede per la competenza e la disponibilità mostrata.

La sicurezza informatica è sempre stato un argomento della computer science particolarmente caldo e controverso, a causa dell’elevatissimo numero di potenziali rischi nella gestione di sistemi complessi. Tanto per fare un esempio, oramai tutti sono perfettamente consapevoli che almeno quattro attacchi su cinque vengono lanciati a causa di uno scarso controllo sul fattore umano interno all’azienda, e tuttavia quattro security managers su cinque continuano imperterriti a rinforzare le difese perimetrali esterne.

Nel caso della Internet of Things, lo scenario  diviene ulteriormente complicato. Innanzi tutto occorre tener conto della presenza di numerose applicazioni IoT “on the wild” (i cosiddetti nodi), ciascuno di essi afferente ad un server centrale per la raccolta dei dati (il Gateway) ed il tutto fittamente tramato con un sistema di comunicazioni tanto wired che wireless. Lo stesso sistema wireless utilizzante numerose differenti tecnologie.

Se questo moltiplicarsi di possibili point of failure non fosse ancora sufficiente, ricordiamo che i metodi di accesso al Cloud sono spesso gestite attraverso API proprietarie: quando si aggiunge complessità a complessità, il rischio di inserimento involontario di un bug nel codice di gestione diviene ancor più probabile.

Il mercato delle periferiche risulta infine particolarmente variegato, e purtroppo non sempre incline a rispettare le specifiche industriali (basti ricordare a tal proposito la gaffe compiuta dagli ingegneri progettisti del Raspberry 4).

In caso di falle della sicurezza (ma anche solo di errori di gestione) della piattaforma, chi diviene responsabile? Chi produce l’hardware? Quale hardware, nello specifico, in caso di sistemi a più schede? O risulterà responsabile il progettista software? Ma anche in quersto caso, spesso chi sviluppa l’applicazione non cura la sezione di autenticazione, chi cura il segmento di trasmissione dati non si occupa di GUI… Anche la linea di trasmissione viene gestita da terze parti, che concorrono ad offuscare la catena di responsabilità ed a rendere ancora più difficile il riconsocimento di colpe.

La mission di Arduino

Sviluppare applicazioni sicure per la Internet of Things appare oggi problematico, a meno di dotarsi degli strumenti minimi necessari (fisici e strutturali) per assicurarsi una gestione razionale ed efficiente del progetto. Il gruppo di progettazione di Arduino si è voluto imporre un target altamente specifico:

Offrire a chiunque la possibilità di sviluppare applicazioni IoT sicure, rendendo semplice da usare anche la tecnologia complessa.

Ed anche per tale ragione in Arduino hanno sviluppato la tecnologia “a panino“.

L’immagine seguente mostra il concetto in modo grafico e oserei dire plastico: il nostro sistema si compone di un contenitore, una base di sviluppo, una scheda MKR, un ulteriore (eventuale) shield, un’antenna. Il tutto è gestito internamente da Arduino. È evidente l’operazione demandata di volta in volta a ciascuna scheda, il tutto controlalto da un protocollo unico sotto la supervisione di Arduino. Ma cos’è una scheda MKR?

La parola magica è ATECCx08

Come abbiamo visto, Arduino offre una serie di schede in grado di trasmettere informazioni con tutta una serie di protocolli di trasmissione wireless. Quello che invece non appare evidente è il chip crittografico presente in tali schede.

Ricordiamo i tre classici elementi cruciali su cui poggia la sicurezza nella trasmissione dati via rete:

• Cifratura dei dati in ricetrasmissione
• Supporto di canale cifrato via TLS (Transport Layer Security)
• Autenticazione X.509 basata su certificato digitale

Arduino ha rilasciato le schede MKR dotate di criptoprocessore ATECCx08 (ad esempio, l’ATECC608), in grado di gestire le tre operazioni viste in precedenza direttamente in hardware.

Ma non è tutto. Arduino dispone di schede dotate di un fattore di forma in grado di supportare Arduino Zero, rendendo portabili e sicuri anche progetti di una certa importanza.

Di tutti i colori, per chi non fa errori

E quando l’applicazione richiede risorse di calcolo agiuntive, che il criptoprocessore non è in grado di soddisfare, la famiglia Arduino aggiunge un Arduino core basato su Mbed, un microsistema oeprativo in grado di gestire il progertto in modo più articolato. In grado di lavorare in multitasking, Mbed supporta le librerie che forniscono accesso alle API di Arduino dalle applicazioni Mbed. Le schede Nano 33 BLE e Nano 33 BLE Sense sono le prime piattaforme ufficialmente supportate di Mbed.

Ricapitolando, quindi, le idee chiave per lo sviluppo di applicazioni IoT sicure sono:

• Device Identity
• Anti-tampering
• Key management
• Encrypted transport e data confidentiality

L’ultimo punto, in particolare, riguarda tra le altre cose il colloquio tra le periferiche ioT ed il sistema di storage management, spesso gestito attraverso Cloud.

Come spesso succede quando un servizio viene offerto in modalità proprietaria, cascun provider offre una serie di API di accesso al sistema in base alle proprie configurazioni interne, e nella maggior parte dei casi i metodi software utilizzati non sono standard.

Anche in questo caso, Arduino rende esplicita la propria mission:

Se infatti da un lato abbiamo un sistema ottimizzato per la crittografia, dall’altro possiamo contare su di una serie di templates generalizzati che consentono in sostanza l’unificazione delle chiamate necessarie per il data transport su Cloud, il tutto secondo lo stile Open classico di Arduino.

Considerazioni finali

Arduino, considerato come “scheda per il prototyping basata su microcontroller ATmega328P”, non rappresenta che la punta dell’iceberg. Anche se in molti continuano a vedere la scheda come un giocattolo intelligente per insegnare l’elettronica ai ragazzini, ci troviamo invece di fronte ad una infrastruttura completa di comando e controllo, in grado di soddisfare le richieste di sicurezza più sofisticate in un ambiente complesso e distribuito.

Ma il vero valore aggiunto fornito dall’infrastruttura è rappresentata dalla sua “openness” intrinseca, hardware e software. A tutti infatti è dato di accedere alle componenti hardware ed alle relative librerie di pilotaggio (driver) dei singoli componenti. Anche le schede crittografiche dispongono di funzioni pronte all’uso, che abbattono il tempo di progettazione e sviluppo dei progetti. Viene fornita una knowledge-base in grado di accompagnare e far crescere il principiante, e di consentire al professionista l’analisi di alternative tecnologicamente avanzate ed economicamente  vincenti.

Fonti e approfondimenti

• Arduino library for the ECC508 ed ECC608 crypto elements
• Arduino port of BearSSL, an implementation of the SSL/TLS protocol written in C
• ArduinoMqttClient library (send and receive MQTT messages using Arduino)
• Kit MKR IoT Bundle
• Arduino MKR1000: come gestire la wireless IoT

Un sentito ringraziamento a Gianluca Varisco, CISU Arduino, e a Distrelec, per la cura nell’organizzazione del webinar dal quale questo articolo prende spunto.

Link utili:

• Arduino UNO R3
• Arduino MKR Zero
• Arduino MKR Wifi 1010
• Arduino FOX 1200
• Arduino WAN 1300
• Arduino GSM 1400
• Arduino NB 1500