Internet of Things. Applicazioni, sicurezza e riservatezza dei dati personali

L’esplosione del fenomeno Internet of Things (IoT) è una “coincidenza” di tre fattori: tecnologia accessibile a basso costo, moltitudine di scenari applicativi e, non meno importante, il ruolo dei media.

Da un lato il fenomeno IoT può potenzialmente rivoluzionare il concetto di computing, portando la raccolta di dati del mondo fisico ad essere quasi una commodity. Dall’altro, le implicazioni dell’IoT sulla sicurezza del mondo digitale e fisico danno senza dubbio ragione agli scettici. La prima discussione che propongo riguarda cosa può succedere quando si connette il mondo fisico a quello digitale, in un verso e nell’altro. Basandomi su una serie di ricerche effettuate e presentate durante il 2014 analizzerò alcuni errori tecnici—che purtroppo sono “sempre i soliti”—che contribuiscono al diffuso scetticismo degli esperti di sicurezza. Concludo con una serie di possibili direzioni di lavoro per ricerca accademica e tecnologia.

Un discorso simile riguarda la riservatezza dei dati personali. Da un lato preoccuparsi di privacy nell’era dell’Internet of Things sembra scontato. Dall’altro, senza rilassare il concetto di privacy, il rischio è quello di ostacolare le opportunità di ricerca e sviluppo industriale. A partire da ricerche e risultati emersi nell’ultimo anno, offrirò alcuni punti di discussione sul “costo” della riservatezza dei dati nell’ambito applicativo dell’IoT.

Il messaggio generale è che, come all’inizio di ogni “rivoluzione” nel mondo digitale, la sicurezza dovrebbe diventare un bene imprescindibile, un obiettivo strategico. Non una mera opzione.

TECNOLOGIE NOTE

NUOVE APPLICAZIONI

INFINITE OPPORTUNITÀ

Il 2014 è stato definito “l’anno dell’Internet of Things”. Per gli appassionati degli acronimi, IoT. L’origine della buzzword la dobbiamo, probabilmente, a Kevin Ashton, il primo a pronunciare il termine nel 1999.

Il fenomeno IoT sta cambiando—e ha le potenzialità di rivoluzionare—il modo in cui siamo abituati a creare, elaborare e fruire l’informazione. Un po’ come accadde quando esplose il cloud computing, forse anche un po’ di più. Già nel 2008, nel rapporto del National Intelligence Council (una divisione dell’intelligence statunitense che comprende accademici ed esperti), il concetto di Internet of Things era elencata tra le “Disruptive Civil Technology”). Citando dal rapporto:

Individuals, businesses, and governments are unprepared for a possible future when Internet nodes reside in such everyday things as food packages, furniture, paper documents, and more.

In sintesi, nel 2008 il mondo non era pronto per l’Internet of Things. C’è da chiedersi se oggi lo sia. D’altra parte, il rapporto continua offrendo un altro punto di vista:

But to the extent that everyday objects become information security
risks, the IoT could distribute those risks far more widely than the Internet has to date

Comunque, prima di analizzare vantaggi e svantaggi in termini di sicurezza e riservatezza dei dati, vorrei focalizzarmi su tre fattori chiave che, a mio avviso, hanno contribuito all’esplosione del fenomeno IoT.

Primo fattore: tecnologia accessibile

Un abbassamento dei costi e delle barriere di accesso alle tecnologie alla base dell’IoT. Si tratta di tecnologie che sono “sempre” (passatemi l’iperbole) state lì, ma che lentamente sono diventate la nuova normalità. Sono cambiati i costi, le modalità e la facilità di accesso, le dimensioni, ma sostanzialmente le tecnologie sono le stesse.

Ad esempio, le reti WiFi hanno oggi raggiunto livelli di accessibilità, diffusione e qualità decisamente più alti rispetto a una decina di anni fa. Ve n’eravate accorti? Io quasi no. Ci siamo lentamente abituati. Il risultato è che è relativamente semplice collegare un dispositivo ad Internet.

Crediti: gunes t

Un altro esempio, forse meno ovvio, è il famoso “contapassi”. Chi non se lo ricorda? Una scatoletta nera con la cinghietta di velcro da fissare sulla caviglia. Cosa c’era dentro? Un accelerometro, la circuiteria necessaria per implementare un contatore, e un display a cristalli liquidi. Ricordo che vidi il primo circa 25 anni fa, in vetrina da un orologiaio. L’anno scorso ho ricevuto in regalo il Jawbone UP, azzurro perché il nero era finito. Cosa c’è dentro? Un accelerometro, la circuiteria necessaria per implementare un contatore, e un jack da 3.5mm per collegarlo allo smartphone. Cos’è cambiato? Poco. Giusto giusto la miniaturizzazione e la precisione dell’accelerometro—che permette di misurare quanto bene o male dormo, in base ai micro movimenti durante il sonno. Colleghiamo un aggeggio del genere ad una cloud bramosa di raccogliere dati, un ecosistema di applicazioni fitness, ed ecco un mix di tecnologie più che noti, solo con il vestito nuovo.

Crediti: limpfish.

Stesso discorso per i sistemi embedded: non è difficile trovare una guida che spieghi come collegare un sensore di temperatura, un relè o un emettitore a infrarossi per regolare, dal proprio cellulare o dal computer dell’ufficio, il condizionatore di casa in base alla temperatura ambiente. Realizzare un progetto del genere costa meno di una cena. Per chi ama ristoranti un po’ più costosi, invece del fai da te, può optare per un termostato intelligente pronto all’uso. App compresa.

La progettazione e la realizzazione di un prototipo hardware sta gradualmente assumendo le caratteristiche che normalmente associamo alla progettazione software, sia grazie a prodotti come Arduino e derivati, sia grazie a movimenti come l’Open Source Hardware. Non è passato molto tempo e già si vedono progetti come l’USB armory (giusto per menzionare uno dei più recenti) lasciano il “codice sorgente” sia hardware che software su Github.

Secondo fattore: infinite opportunità

Legato a doppio filo con il primo, le opportunità applicative sono probabilmente il fattore che più sta alimentando il fenomeno IoT.

Crediti: Maxime Raphael

Riprendendo i tre esempi di cui sopra, mi invento di sana pianta un servizio per l’utente finale. In base a quanto ho corso, regola la temperatura di casa al mio rientro per creare un ambiente gradevole e adatto al mio livello di sudorazione. Il Jawbone UP misura quanto ho corso, quindi stima quanto potrei essere accaldato e, quando lo collego al cellulare—meglio ancora se la versione Bluetooth, comunica al termostato di impostare una temperatura idonea in base alle mie condizioni fisiche.

Chiaramente è solo un esempio banale, e forse un po’ futile, ma spero di aver passato il messaggio. Discorsi attorno ad idee come queste sono all’ordine del giorno di una pausa pranzo tra colleghi nerd. Il fatto è che è cambiato il modo in cui pensiamo alla raccolta dati dal mondo fisico. Invece di pensare all’aspetto tecnologico di come raccogliere un dato, oggi è diventato quasi scontato che un modo per farlo ci sia, e che tutto stia nel cosa farci con quel dato.

Sta iniziando un nuovo cambio nel paradigma di computazione, in cui la raccolta dati è diventata una commodity. Diamo uno sguardo al passato:

1. Fase “mainframe”: ogni realtà (azienda, università, banca) era dotata di un certo numero di terminali a minima capacità computazionale, detti “thin client”, o “dumb terminal”. Di fatto erano terminali con tastiera e video usati al massimo per fare data entry. I dati risiedevano in un unico mainframe centralizzato che si occupava anche della loro elaborazione. I dati erano prodotti dagli esseri umani.
2. Fase “Internet”: con l’era della connettività globale il concetto di mainframe venne adattato su scala globale. Server al posto dei mainframe e client non più “thin”. Rispetto alla fase precedente anche i client conservano ed elaborano dati e la computazione è distribuita tra server e client. La stragrande maggioranza dei dati era, ancora, prodotta da esseri umani.
3. Fase “cloud”: l’aumentata quantità di dati e l’accresciuta capacità computazionale necessaria per elaborarli portò a sbilanciare nuovamente la differenza client-server. I client, sebbene più potenti dei “rich client” della fase precedente, tornarono ad essere considerati “thin”. La computazione tornò a centralizzarsi nelle cloud, il cui modello di fruizione ricorda sempre di più i vecchi mainframe, in cui si pagava per il tempo di utilizzo o per lo spazio di memorizzazione. La grande quantità di dati derivava, in sostanza, dalla facilità con cui si potevano elaborare e, quindi, trasformare in nuovi dati. Ancora, però, senza umani i dati non si producono da soli.
4. Fase “IoT”: in aggiunta alle caratteristiche della fase precedente, che restano valide, una quantità potenzialmente infinita di sensori “thin” affiancano i rich client nella produzione di dati. La computazione rimane centralizzata nelle cloud, sempre più potenti e sempre meno costose, ma sostanzialmente invariate rispetto al passato. Una differenza fondamentale è che, per la prima volta, l’origine di un dato è squisitamente automatica. Non fraintendetemi: i sensori, le reti di sensori e la raccolta dati sul campo è sono sempre esistite. Ciò che cambia qui è l’estensione e l’interconnessione dell’ecosistema dei “produttori di dati”. Oggi molti di questi iniziano ad avere un indirizzo IP, come minimo. E, soprattutto, costano dannatamente poco e sono entrati nel mercato consumer. Qualsiasi essere umano è un potenziale produttore di dati, ma non in quanto tale (e.g., data entry), ma come entità del mondo fisico. La produzione di dati diventa una commodity ed è indipendente dall’esistenza dell’essere umano che ha creato il sensore o il dispositivo IoT.
5. Fase “IoE”: era qui che volevo arrivare. Scusate se ci ho messo molto e non ho usato molta fantasia nella scelta dell’acronimo, ma state con me. I dispositivi IoT stanno iniziando ad essere parecchi e di pari passo va la quantità di dati che stanno producendo. Un po’ come avvenne tra la fase 2 (Internet) e 3 (cloud), il modo in cui sono elaborati i dati deve evolvere. Non si può più pensare di dover “aspettare” che il flusso di dati arrivi alla cloud di turno per poter essere elaborato. Come avvenne tra la fase 1 (thin client) e 2 (rich client), è necessario che sensori e dispositivi intermedi tra sensori e cloud diventino “rich”. In altre parole, è necessario distribuire e decentralizzare nuovamente l’elaborazione dei flussi di dati ai bordi di Internet.

[…] IOx will equip Cisco edge devices such as routers and IP cameras with applications that let them manage and process data themselves, instead of having to push that data back over the network and into a data center or cloud.

Quindi, per concludere, infinite opportunità applicative e inizio di un nuovo cambio di paradigma di computazione. Prima di mettere nero su bianco l’elenco di cui sopra non avevo pensato alla fase 5, ma mentre scrivevo mi sono reso conto che siamo in pieno nella fase 4.

Terzo fattore: il ruolo dei media

Non è difficile da credere che la diretta conseguenza dei due precedenti fattori è stato un crescente ed esplosivo fermento mediatico. Aggiungiamo al mix i cospicui investimenti (o le previsioni di investimento) delle principali multinazionali come IBM, Amazon, GE, Cisco, Apple, Samsung—tanto per nominarne alcune—ed ecco che il 2014 è l’anno dell’Internet of Things! Gartner ha stimato che entro il 2020 il valore totale di prodotti e servizi legati alle tecnologie IoT oltrepasserà i 300 miliardi di dollari americani. Per tornare ai termostati di cui sopra, si stima un’adozione del 43% entro i prossimi 5 anni. Okay, sono solo stime, ma i media vanno matti per i numeri, specie se sono alti.

Crediti: mkhmarketing

Anche se l’ho elencato per ultimo, concordo con Robert Metcalfe, co-inventore di Ethernet intervistato da Gil Press per Forbes, il quale dice che il ruolo dei media è stato determinante, più di quello tecnologico, per l’esplosione del fenomeno IoT. In effetti le tecnologie necessarie per realizzare le IoT sono ben note: sono solo rimaste “in incubazione” per diversi anni.

Ma adesso arriva il bello. Parliamo di sicurezza e riservatezza dei dati personali :-)

SICUREZZA

NUOVO OBIETTIVO STRATEGICO

In un periodo come quello in cui stiamo vivendo, mettere “sicurezza” e “Internet of Things” nella stessa frase fa un po’ sorridere—o rabbrividire. Riguardo all’IoT in sé ho parlato abbastanza e spero di avervi convinto di due cose: estremo fermento, ma anche estremo caos all’orizzonte.

Riguardo alla sicurezza, non mi metterò certo ad elencare i numerosi incidenti di abbiamo assistito negli ultimi due anni, perché li abbiamo tutti bene in mente. Se però siete curiosi, vi suggerisco il tag “data breaches” sul blog di Brian Krebs, un breve post su Computer Weekly, o la Parte Prima del Red Book.

Sicurezza come gestione del rischio

Per chi è del mestiere, fare sicurezza significa gestire un rischio. Nel più semplice dei modelli il rischio per una persona o un’azienda di possedere informatico si può quantificare attraverso alcune variabili. Tra queste, la cosiddetta superficie di attacco rappresenta le parti di un sistema raggiungibili da un aggressore, ed è ovviamente direttamente proporzionale al rischio. Più è ampia la superficie di attacco, più cresce il rischio a parità di aggressori e vulnerabilità.

Ecco perché in molti rabbrividiscono!

In effetti, quello che sta succedendo è che dispositivi come la macchinetta del caffè, la porta di casa, l’antifurto, l’automobile, che fino a ieri erano al tutt’al più collegati alla rete elettrica, ora si ritrovano proiettati su una rete pubblica, Internet, alla mercé di buoni e cattivi. Se il mio termostato non è collegato ad Internet, poco me ne faccio: quindi è un requisito, non un “di più.” In termini di rischio, ciò si traduce in una superficie di attacco decisamente ampia.

Per fare un’analogia, quando iniziarono a diffondersi le applicazioni Web, il principale problema non fu tanto la quantità di vulnerabilità in esse presenti, ma la superficie attaccabile. Una singola vulnerabilità, ad esempio nel meccanismo di autenticazione, ha un forte impatto negativo sul rischio. Se poi l’applicazione Web in questione è quella che controlla il termostato, l’apertura di un cancello o di una porta, allora ci ritroviamo con un vecchio problema, per di più amplificato.

Nel 2010 Ang Cui, ricercatore di Columbia University, effettuò una prima scansione dell’intero spazio di indirizzamento Internet alla ricerca di router domestici. Lo scopo era quantificare quanti di questi fossero vulnerabili e potenzialmente attaccabili. Allora il fenomeno IoT non era ancora esploso e alcuni colleghi ricercatori giudicarono la ricerca sicuramente interessante ma non molto utile: chi ha interesse ad attaccare un router domestico? Era vero. Negli ultimi 4–5 anni, però, alcuni aspetti sono cambiati:

• primo, i router domestici sono diventati più potenti,
• secondo, le connessioni hanno velocità maggiore,
• ultimo, ma più importante, ciò che è collegato dietro ai router domestici può dare accesso al frigorifero, lavatrice o, peggio, alle telecamere di sorveglianza, all’apertura automatica della porta di casa.

In realtà il caso del frigorifero usato per creare una botnet per inviare spam fu contestato, perché non c‘erano elementi certi per concludere che furono veramente i frigoriferi a inviare spam—e non semplicemente i computer collegati alla stessa rete interna, che ovviamente avevano lo stesso IP in uscita. Tuttavia con l’aumento della diffusione di dispositivi a basso costo collegati alla rete anche un noioso router diventa molto, molto interessante. Connessione veloce significa, per un aggressore, possibilità di trarre profitto da una botnet di router. Ci hanno provato già nel 2010, infettando i router DSL sfruttando una vulnerabilità di tipo buffer overflow. Il risultato fu una botnet, nome in codice “Chuck Norris”, composta da soli router, usata per attacchi di tipo denial of service. Pochi anni dopo, storia simile: questa volta è stato sfruttato il fatto che raramente gli utenti consumer cambiano le credenziali predefinite. La differenza, questa volta, è che ci sono informazioni certe sul fatto che il gruppo criminale responsabile ha monetizzato la botnet così creata. Per chi vuole approfondire, consiglio questo articolo di Brian Krebs.

Riproviamoci: la mappa delle IoT nel 2014

Quattro anni dopo la prima scansione fatta da Ang Cui, Shahar Tal e Lior Oppenheim di Check Point, alla 31-esima edizione del Chaos Computing Congress (31c3), hanno ricapitolato i risultati del censimento dello spazio IP pubblico—presentati qualche mese prima a DEF CON 22. 45 milioni di dispositivi tra quelli che hanno risposo ai pacchetti di probing avevano un servizio di gestione remota basato sul protocollo TR-069 (porta 7547) attivo: la totalità di questi era un dispositivo al quale possiamo tranquillamente appiccicare l’etichetta “IoT.” 45 milioni corrisponde a circa l’1.18% dell’intero spazio IPv4. Dov’è il problema, direte voi? È una percentuale minuscola!

Invece, ci sono due aspetti interessanti: primo, un +0.06% rispetto al 2013; secondo, il 52% dei 45 milioni di dispositivi sono basati, tutti, su RomPager, un server HTTP per sistemi embedded creato da Allegro Software. Perché questo secondo dettaglio è interessante? L’uniformità dei bersagli è sempre un punto a favore dell’aggressore. Se i sistemi da attaccare sono tutti identici (a livello di hardware, sistema operativo e livello applicativo), i potenziali aggressori dovrebbero preparare solo un exploit e potranno utilizzarlo per tutti i dispositivi. Al contrario, diversificare è un modo per rendere gli attacchi di massa molto sconvenienti dal punto di vista economico. Se, per assurdo, tutti avessimo un computer con un instruction set distinto, sarebbe molto più difficile creare un attacco per ognuno di essi.

Tornando ai dispositivi IoT basati su RomPager che rispondono sulla 7547, vi starete chiedendo quale mix di versioni di RomPager sono state trovate dai dai due ricercatori di Check Point: sul 98.04% girava RomPager 4.07. A seguire, in ordine: 4.51, 4.03 e 4.34. Un momento: la maggior parte dei dispositivi non è all’ultima versione? Non solo! La versione 4.07 è del 2002: in 12 anni vuoi non trovare almeno una vulnerabilità? RomPager è basato su ZynOS, un sistema operativo real time diventato famoso nel maggio del 2014 per uno 0-day che valeva 1,219,985 dispositivi (CVE-2014–4019).

Durante il corso di Computer Security al Politecnico di Milano (e non siamo certo gli unici a farlo), insegnamo agli studenti di evitare l’uso della funzione di libreria C “strcpy()” senza aver prima controllato che la dimensione dell’area di memoria destinazione sia almeno grande quanto il dato che ci si vuole scrivere. Beh, la CVE-2014–4019 sembrerebbe essere proprio un buffer overflow causato da una “strcpy()” non protetta. Purtroppo questa è solo una delle tre vulnerabilità dimostrate dagli autori della ricerca. La seconda è simile alla prima, anche se è tecnicamente più difficile da sfruttare, mentre la terza ha preso il nome di Misfortune Cookie, perché riguarda un errore nella gestione dei cookie HTTP.

Mettiamoci una pezza. Eh, fosse facile!

La brutta notizia è che mentre nel caso dei normali computer ci sono minacce e vulnerabilità, ma ci sono anche contromisure — OK, blande, ma ci sono — nel caso dei dispositivi IoT ci sono le minacce ma non ci sono molte contromisure. Non esiste “l’antivirus” per il termostato, per intenderci. Al massimo ci sono le raccomandazioni trite e ri-trite sulla scelta di una buona password…bla bla bla: richieste a mio avviso vergognose nel 2015.

Ma torniamo alle vulnerabilità, perché possono esserci tutte le minacce che vogliamo, ma senza vulnerabilità…poco si fa. Tristemente non c’è da meravigliarsi che router domestici, termostati smart (come il famoso Google Nest), dispositivi indossabili (come il Samsung Gear) contengano vulnerabilità come quelle illustrate poco fa…nonostante tutte le lezioni che abbiamo imparato negli ultimi 20 anni di sicurezza informatica.

Peggio ancora, è difficile eliminare le suddette vulnerabilità. Normalmente in un computer classico ciò avviene aggiornando ad una versione successiva del software vulnerabile, nella quale il produttore — si spera — avrà risolto quel baco. Purtroppo nel contesto IoT questo non è così facile.

Il costo di un sistema embedded destinato al mercato consumer non può che essere strizzato al limite. Chiaramente i sistemi embedded destinati alle applicazioni IoT sono molto diversi rispetto a quelli destinati alle applicazioni critiche (e.g., controllo di flussi di produzione, SCADA): sono diversi i chip e, soprattutto, è diverso il firmware ed il supporto offerto dal produttore. Il mercato consumer è dinamico, effimero e orientato a rincorrere costi bassi, diffusione capillare, semplicità d’uso e l’ultima novità. Quindi è raro trovare un prodotto IoT che offra aggiornamenti di sicurezza del firmware—magari automatici, senza richiedere che l’utente sia un esperto. Molte volte non è facile o per niente fattibile aggiornare o modificare il firmware di un dispositivo: potrebbero non esserci porte di diagnostica accessibili, potrebbe non avere un display, o più semplicemente l’utente non è interessato o tecnicamente in grado. In altre parole, non è prioritario: il mercato e gli utenti spingono in altre direzioni.

Crediti: Natasha Wheatland

In un ecosistema relativamente chiuso (dal punto di vista software) e al tempo stesso pervasivo, è cruciale avere procedure di aggiornamento automatico e risposte veloci da parte dei produttori in termini di risoluzione di vulnerabilità. Già un anno fa Bruce Schneier richiamava l’attenzione dei produttori e sottolineava il ruolo chiave degli Internet service provider come attuatori di tali procedure di aggiornamento, per arrivare ad ottenere un ecosistema gestito, per lo meno per i dispositivi direttamente affacciati ad Internet come i router. Purtroppo non ci sono segnali che facciano intendere che si stia andando in nella giusta direzione. D’altra parte non è banale progettare e implementare una procedura sicura di aggiornamento firmware, che assicuri almeno autenticità ed integrità del codice, e che sia adatta e applicabile al mercato consumer. Nel 2013 lo stesso Ang Cui proseguì la sua ricerca dimostrando la fattibilità di sfruttare le procedure di aggiornamento del firmware di stampanti, o in generale di sistemi embedded, come vettore di attacco.

Un circolo vizioso

Finora ho descritto problemi classici di sicurezza dei sistemi, derivanti tipicamente da vulnerabilità applicative, amplificate dall’ampia superficie di attacco offerta dai presupposti di uno scenario IoT. Concludo con un’osservazione che risale a 3–4 anni fa ma è tutt’ora valida.

Nel momento in cui rendo raggiungibile e gestibile, informaticamente parlando, un oggetto che fino a ieri non lo era mai stato, abbiamo visto che si creano una serie di criticità. Nel caso di un sensore, ad esempio, lettura o modifica dei dati in modo non autorizzato, rottura del dispositivo, e quant’altro.

C’è dell’altro però.

Ammettiamo pure che il sensore in questione sia immune da qualsiasi tentativo di manomissione, sia fisica che digitale, che sia privo di vulnerabilità e che funzioni alla perfezione. Quindi, fintanto che questo sensore legge dati, nessun problema. In altre parole, il sensore offre al programmatore una primitiva di “lettura” dal mondo fisico (cat /dev/stdworld > file).

Ora immaginiamo, senza neanche troppo sforzo, che i dati letti da questo sensore servano ad un sistema di controllo per, ad esempio, regolare temperatura, pressione o chissà cos’altro di un ambiente fisico. Ci sarà dunque un attuatore, ossia la nostra primitiva di “scrittura” sul mondo fisico (cat temp > /dev/stdworld :-P). Possiamo tranquilamente assumere che anche l’attuatore sia perfetto, sicuro, fidato e tutto ciò che volete.

Fin qui, tutto OK.

Ora, esiste una categoria di errori software detti “errori logici” che sono senza dubbio tra i più difficili da individuare. Il motivo è che non riguardano il modo in cui un generico programma esegue, ma sono specifici per ogni programma. Ad esempio, errori tipo i buffer overflow o format string sono relativamente facili da individuare—a livello di codice, assemblatore o di sistema operativo—perché riguardano, tutti, il modo in cui viene gestita la memoria. Un esempio di errore logico è un errato controllo su una variabile che, per alcuni valori, fa finire il programma in uno stato non previsto dal programmatore. È facile capire perché individuare errori logici è difficile e, soprattutto, è un problema che richiede soluzioni specifiche caso per caso.

Qui viene il bello.

Cosa può succedere, dunque, se il valore letto da un sensore—diciamo prodotto dall’azienda X—viene usato dal programma di controllo—diciamo prodotto dall’azienda Y—che usa l’attuatore prodotto dall’azienda Z? L’attuatore, per definizione, agisce sull’ambiente fisico. Ma il sensore legge valori dall’ambiente fisico, li comunica al controllore che, a sua volta, modificherà l’ambiente fisico…e via così! Per i tecnici questo equivale, con un po’ di fantasia, a fare cat /dev/stdworld_X > /dev/stdworld_Y.

Attenzione che i due sistemi, presi singolarmente, sono perfettamente sicuri. L’eventuale esistenza di vulnerabilità—e a questo punto abbiamo capito che si tratta di vulnerabilità di tipo logico—deriva dal fatto di averli collegati tra loro, attraverso il mondo fisico. Perché è difficile verificare la presenza di vulnerabilità di questo tipo? Beh, perché non basta verificare che il sensore X continui a funzionare bene per tutti i valori possibili e che l’attuatore Y funzioni bene per tutti i valori prodotti dal programa che lo utilizza. Per fare verifiche di sicurezza serve anche un modello—o, meglio, un simulatore—del mondo fisico.

Crediti: Susanne Nilsson

In conclusione, in un ipotetico contesto IoT futuro c’è un potenziale circolo vizioso tra dispositivi e mondo fisico. OK, sono d’accordo con voi che è uno scenario piuttosto avveniristico, ma neanche troppo, soprattutto considerando l’economicità dei dispositivi verso cui spinge il mercato e l’eterogeneità dei dispositivi stessi.

Tirando le somme, la quantità di dispositivi collegati ad Internet è in aumento, e continueranno ad aumentare visto che il fenomeno IoT è solo all’inizio. Le vulnerabilità a livello di sistema non mancano e, punto interessante, non sono specifiche delle tecnologie impiegate nelle IoT. Tutt’altro, oserei definirle scolastiche.

La sicurezza non è ancora uno degli obiettivi e purtroppo, sul lungo periodo, questa strategia non paga, ma rischia di diventare controproducente. Sono d’accordo con le parole, forse un po’ di parte, di John Chambers, CEO di Cisco, che nel suo discorso al World Economic Forum Annual Meeting lo scorso 21–24 gennaio, propone di cambiare approccio alla sicurezza nel campo IoT, mettendola tra gli obiettivi strategici e come motore di crescita:

Every company is a security company […] customers, partners and employees in this environment, businesses must think of themselves as security companies. […] Security is no longer just a technology issue — it applies to everyone.

Non sono certo concetti o idee nuove quelle di John Chambers, intendiamoci: il fatto che la sicurezza debba essere un processo—e non una mera operazione tecnica—lo si insegna da sempre sui banchi dell’università. Tuttavia l’occasione offerta dal trovarsi sulla cresta dell’onda di un nuovo fenomeno come l’IoT è perfetta per ricordare ancora una volta a produttori, ricercatori e tecnici del settore l’importanza dare priorità alla sicurezza dei sistemi del futuro.

RISERVATEZZA DEI DATI PERSONALI

Premetto che qui mi sto muovendo in un campo su cui sono personalmente poco sensibile e “normativamente” poco esperto. Però non si può non parlare di riservatezza di dati personali quando all’orizzonte vediamo migliaia di sensori che leggono tutto il leggibile dalla personalissima sfera di ognuno di noi.

La tariffa nascosta

Il punto critico è che, mai come in questo momento, i servizi offerti in cambio dei dati personali sono maledettamente utili per l’utente. Migliorano davvero la qualità della nostra vita. E non sto parlando dell’app che mi ricorda di comprare il latte. Mi riferisco all’app davvero intelligente che mi consiglia un certo tipo di alimentazione basandosi su dati raccolti quali la qualità del sonno, il movimento fatto durante il giorno, temperatura, umidità, fattori personali quali pressione arteriosa, depressione, ansia, e chi più ne ha più ne metta. Basta guardare quante nuove aziende stanno spuntando intorno alla gestione della propria salute. Ha senso, no? Il mondo intorno a noi è più frenetico, il lavoro è più imprevedibile è dinamico, le relazioni sono migrate dalla telefonata alla social network, eccetera (non voglio dilungarmi, perché potrei continuare per ore). Risultato, abbiamo meno tempo per noi stessi e trascuriamo la nostra salute. Nel mio piccolo sono più propenso a obbedire al cellulare che mi ricorda di bere un bicchier d’acqua ogni ora, piuttosto che ascoltare se il mio corpo ha sete o meno. Se l’app sa anche quanto ho dormito mi saprebbe anche dire se sostituire l’acqua con un ricostituente o con un té o bevanda vitaminica.

Un discorso simile si potrebbe fare sull’utilità per l’utente finale in termini di risparmio. Un servizio che raccoglie dati ed apprende il profilo di utilizzo della corrente elettrica domestica può suggerire—o addirittura dialogare direttamente con lavatrice, frigorifero e quant’altro—come minimizzare il consumo. Il prezzo che però pensiamo di pagare per questo genere di servizi nasconde, ovviamente, il valore che ognuno di noi attribuisce ai dati personali. Condividere dati dettagliati circa l’assorbimento elettrico con l’azienda che fornisce un servizio come quello appena descritto può sembrare innocuo. Tuttavia le nostre abitudini “elettriche” possono celare le nostre abitudini televisive, ad esempio, o in generale le nostre abitudini domestiche: basta saperle leggere. Due anni fa, alla 28-esima edizione del CCC, Dario Carluccio e Stephan Brinkhaus hanno dimostrato che ogni trasmissione televisiva, a seconda di marca e modello del televisore, lascia un’impronta distintiva sul profilo di assorbimento di corrente.

Crediti: Kevin Simpson

La tendenza mostra che, anche senza un contatore intelligente, i dispositivi che ci stiamo portando in casa sono fin troppo “smart”. Vi ricordate il caso di LG dello scorso maggio? I possessori di una smart TV di LG si sono visti aggiornare il software, ma non per eliminare una vulnerabilità di sicurezza. L’interfaccia chiedeva all’utente di esprimere o declinare consenso, pena il non funzionamento dei servizi a valore aggiunto. Consenso per cosa? Vediamo:

Our Privacy Policy explains and seeks your agreement for how we collect, use, and share information that we obtain as a result of your use of LG Smart TV Services, as well as how we use cookies. You do not have to agree to the Privacy Policy but if you do not, not all Smart TV Services will be available to you. In that case, we will still receive certain non-identifying information from your Smart TV that we need to provide the basic functions that will be available.

Aggiungo che il testo di cui sopra è stato trascritto manualmente leggendo dalla TV, perché non ne esiste una versione pubblicamente disponibile, nemmeno nel manuale cartaceo o sul sito di LG. Sì, è la stessa LG che pochi mesi prima era stata contestata perché ogni volta che si collegava un disco esterno o una chiavetta USB alla TV, l’elenco dei file ivi presenti veniva spedito ai server di LG. Tornando alla privacy policy, avete notato il passaggio in cui si dice che, indipendentemente dall’accettazione o meno delle condizioni, LG continuerà a raccogliere dati (non identificanti il possessore) per continuare a poter erogare le funzionalità essenziali? Se volete approfondire consiglio questo e questo articolo. Nel secondo si parla anche del fatto che LG raccoglie le parole che inserite nel box di ricerca, le pressioni di play, stop, pausa.

Niente di personale, sono solo affari

Sarete d’accordo con me sul fatto che le abitudini domestiche, o comunque personali, sono informazioni molto preziose. Prima di tutto per chi vuole convincerci a comprare o meno un prodotto o servizio, o ci consiglia di guardare un certo film “on demand”. Ma pensate un po’ cosa può succedere se questi dati finissero nelle mani sbagliate. Purtroppo, viste le premesse fatte poco fa riguardo alla sicurezza di dispositivi e applicazioni IoT, le conclusioni non possono che portarci a fare un passo indietro e a chiederci:

• com’è regolata la generazione, raccolta e conservazione dei dati provenienti dalla sfera personale di ognuno di noi?
• com’è regolata la condivisione di tali dati tra aziende che offrono servizi a valore aggiunto? Mi viene in mente l’azienda del Contatore Intelligente (nome di fantasia) che condivide i dati all’azienda Guarda TV Intelligente (nome di fantasia) o Compra Medicina che Ti Passa (nome di fantasia).
• l’utente finale ha controllo sul dato e può, in qualsiasi momento, decidere di cancellarlo “ovunque”?

Attenzione perché qui stiamo parlando di dati molto più personali di un conto in banca, della posta elettronica o del nostro cellulare—sui quali, tra l’altro, abbiamo un certo controllo. Come vi sentireste se dopo aver fatto l’elettrocardiogramma il medico uscisse dallo stanzino sventolando copie del vostro tracciato a chiunque fosse disposto a pagarlo? Come vi sentireste se la vicina tenesse un foglio con date e orari di quando uscite o entrate in casa, che percorso fate per andare a correre, e lo condividesse con i migliori offerenti?

Quindi, da un lato questi dati sono utilissimi per noi, dall’altro sono ancora più utili per chi li gestisce. Per non parlare di un potenziale aggressore, cyber o fisico che sia, o di un datore di lavoro che può decidere o meno di assumermi perché ha visto su Facebook che il mio fitness tracker ha concluso che ho la pressione alta. Vorremmo poter condividere questi dati solo con parti fidate e vorremmo poter decidere sul loro destino. Dire “no, non li condivido” sarà sempre meno un’opzione. Sia per l’utente finale, sia, se guardiamo in grande, per lo sviluppo economico.

I punti difficili, a mio avviso, riguardano la regolamentazione dei dati collezionati da servizi valore aggiunto. Dal punto di vista tecnico è necessario pensare a procedure semplici quali “come chiedere all’utente il permesso di condividere?”. Se i dispositivi sono piccoli potrebbero non avere interfaccia grafica o bottoni. Ciò che avviene solitamente è che c’è un’app che permette all’utente di gestire la raccolta dati: oltre ad assicurare “privacy by default”, queste app dovrebbero essere progettate secondo opportune linee guida affinché l’utente possa avvalersi di controlli semplici ed intuitivi per capire che fine fanno i propri dati, e decidere cosa farne. Faccio un paragone: il modo, a mio avviso eccellente, in cui è stato progettato il sistema dei certificati medici per le assenze dal lavoro per malattia è da prendere d’esempio. Chi deve sapere, sa solo il minimo indispensabile e in nessun modo l’informazione riservata e personale raggiunge il datore di lavoro.

È necessario quindi che l’ecosistema IoT implementi, per sua natura, il concetto di privacy gestita, dal dispositivo di raccolta fino alla sua elaborazione ed eventuale ri-condivisione. Oltre a questo, ovviamente valgono le consuete raccomandazioni riguardo alla minimizzazione dei dati raccolti (un po’ controcorrente rispetto alla tendenza “big data”, seconda keyword del 2014) e all’anonimizzazione. Questo è il nocciolo del discorso fatto da Edith Ramirez della Federal Trade Commission durante il Consumer Electronic Show poche settimane fa. Se siete interessati al discorso completo, lo trovate su questo documento.

SOLUZIONI & DIREZIONI

Possiamo dunque concludere che il fenomeno IoT ha le potenzialità di dare una svolta al concetto di “computing” cui siamo abituati, fornendo agli sviluppatori infinite opportunità applicative. Un piatto d’argento per industria, sviluppo economico e ricerca scientifica. Viste le problematiche di sicurezza e riservatezza dei dati personali, la conclusione è che dovremmo cogliere l’opportunità di essere “sulla cresta dell’onda” per rivedere sicurezza e privacy come beni imprescindibili e come fattori di sviluppo.

Concludo dando la mia visione sulle possibili soluzioni e direzioni future nella ricerca scientifica nella tecnologia.

Ricerca scientifica

In primis è necessario continuare la ricerca nel campo della sicurezza dei sistemi, verso soluzioni efficaci per rimediare o eliminare i problemi classici, che continueranno ad esserci: mi riferisco a meccanismi per rendere inefficaci i tentativi di eseguire codice arbitrario da parte di un aggressore. Non dimentichiamoci infatti che, per quanto un dispositivo IoT possa sembrare “magico”, sotto sotto c’è sempre un microprocessore o un microcontrollore, con tutti i problemi noti da decenni a chi fa ricerca in questo settore. In questi scenari, l’assenza di una vulnerabilità nella gestione della memoria è difficile da garantire, specialmente perché molto del codice che gira su questi dispositivi è nativo e, spesso, è scritto direttamente in C se non addirittura in assembly. Quindi vedo molto più fattibile un meccanismo di anti exploitation a livello di sistema o di compilatore rispetto, ad esempio, ad un re-design ad ampio spettro che preveda misure più drastiche, ma anche più risolutive, come ad esempio l’impiego di processori che garantiscano l’isolamento tra processi e integrità di codice, dati e control flow. Lavorare nella prima direzione avrebbe un impatto positivo a breve termine sulla sicurezza dei dispositivi embedded usati in ambito IoT. L’aspetto interessante è che ci sono già molti risultati di ricerca da cui attingere. La sfida è, chiaramente, come implementarli nella maniera meno invasiva possibile rispetto ai dispositivi già esistenti.

Altra direzione interessante consiste nella creazione di un osservatorio scientifico che permetta di mantenere una mappa in tempo reale dei dispositivi IoT attivi. Shodan è quanto di più vicino mi viene in mente. Osservatori di questo tipo devono necessariamente integrare dati di contesto come la versione del firmware utilizzata dal dispositivo, eventuali vulnerabilità note, privacy policy, eccetera, e serviranno ad alimentare lavori di ricerca come firmware.re volti a creare meccanismi automatici per cercare nuove vulnerabilità in firmware esistenti e utilizzati realmente.

Quest’ultima direzione è propedeutica alla creazione di soluzioni al “patching problem”—ossia la difficoltà ad aggiornare i dispositivi una volta trovate le vulnerabilità—o quanto meno per creare un corpus di firmware per la comunità scientifica. È interessante infatti quantificare e individuare quanti e quali dispositivi risultano veramente non aggiornabili se non con una sostituzione. Se questi risultassero una minoranza, allora varrebbe la pena investire risorse per creare procedure automatiche per correggere (semi-)automaticamente le vulnerabilità trovate, direttamente nel binario. In alternativa, si dovrebbe esplorare la fattibilità di creare versioni equivalenti e “vendor agnostic” degli stessi firmware.

Infine, la ricerca dovrebbe muoversi nella direzione più drastica e risolutiva. Servono linguaggi di programmazione, metodologie e linee guida per lo sviluppo e la verifica di sicurezza per la nuova generazione di firmware. Non sto parlando di procedure automatiche per trovare vulnerabilità, ma di ambienti di sviluppo adatti a sviluppatori non esperti di sicurezza, che impediscano loro di inserire vulnerabilità nel codice. Anche se la quantità di vulnerabilità trovate nei vari componenti della piattaforma Android non ne è la testimonianza, l’approccio tecnico scelto da Google di creare una runtime (Dalvik VM) in grado di eseguire codice a livello di astrazione relativamente alto è secondo me vincente. Questa soluzione permetterebbe di creare un ambiente di sviluppo e di esecuzione uniforme, a beneficio di aggiornamenti e compatibilità hardware, e al tempo stesso mantenere un controllo sul codice in esecuzione.

Non tutte le novità vengono per nuocere. Se ci dimentichiamo per un attimo dei problemi visti sinora, notiamo una succosa opportunità offerta dalle tecnologie IoT per soluzioni innovative di sicurezza. Se devo trovare un lato positivo dal punto di vista della sicurezza è che esistono dispositivi che permettono di implementare sistemi di autenticazione forte a basso costo. In sensori biometrici come il lettore di impronte digitali o battito cardiaco sono miniaturizzati ed economici al pari di un orologio. Ad esempio il Nymi—che ho acquistato in anteprima—integra un accelerometro e un sensore per misurare il battito cardiaco. Non vedo l’ora di metterci le mani sopra e di vedere quanto è accurato, ma stando alle promesse sarebbe in grado di estrarre una “firma” dal tracciato ECG, unica per ogni proprietario. La chiave per decifrare il portafoglio delle mie password è il mio battito cardiaco: grandioso! Ci sono tutta una serie di dubbi, gli stessi che sicuramente vi staranno frullando nella testa mentre leggete, tipo cosa succede se per caso sono agitato e il mio battito cardiaco non è lo stesso di quando ho registrato il dispositivo. Dubbi senz’altro da verificare: le sorprese non mancheranno.

Indipendentemente dal dato che si misura, il paradigma IoT apre le porte a nuovi meccanismi di autenticazione multi fattore, basati sull’uso combinato di più sensori, magari in più momenti della giornata. Idee che un paio d’anni fa risultavano solo esperimenti di laboratorio, e mi sto riferendo all’autenticazione basata sul modo in cui ci si muove, si scrive alla tastiera, sembrano più vicini alla realtà. La liberazione dalle password è più vicina? Forse sì, e con essa, secondo Gartner, anche una gestione come si deve della mobilità dei soggetti in azienda e tra aziende diverse.

Durante il mio dottorato mi sono occupato di rilevazione di anomalie di rete e nel sistema operativo. Leggendo questo articolo di Tom Davenport (Deloitte Analytics) dal titolo “Analytics of Things”—dopo essermi ripreso dal sussulto per l’ennesima parola accostata ad “…of Things”—mi sono accorto del termine “anomaly detection”, che effettivamente non vedevo da tempo:

Anomaly detection — identifying situations that are outside of defined boundaries, such as a temperature that is too high or the presence of an individual in an area that should be uninhabited.

L’ubiquità dei sensori permetterebbe di rivedere l’approccio generale all’anomaly detection, realizzare nuovi algoritmi, magari da incorporare in un dispositivo da portare sempre con sé, al quale dare accesso alle nostre transazioni bancarie, ai contatti con le persone, alla nostra posta, ai nostri spostamenti e quant’altro…al fine di assistere gli utenti meno esperti di sicurezza e privacy, avvertendoli ad esempio di un potenziale problema. Mi viene in mente che se un sensore indossabile può seguire i miei spostamenti e può interrogare una base di dati riguardo agli spostamenti dei miei familiari può avvertirmi ad esempio se la mia abitazione rimane vuota. Ma questo sarebbe poco. Potrebbe accorgersi che le stesse persone con cui ho appena fatto una riunione in ufficio ora stanno cercando di contattarmi per email, stanno osservando il mio profilo Facebook e sono molto interessati al mio indirizzo o alla banca presso cui ho il mio conto. Ci sono una miriade di problematiche di riservatezza che la ricerca scientifica dovrà risolvere prima che una tale applicazione possa vedere la luce, ma converrete con me sulla sua utilità di un tale assistente personale di sicurezza.

Lascio lettrici e lettori rispondere alla domanda (retorica) su quale sarà il bersaglio più interessante per gli attacchi informatici nei prossimi 20 anni: un Rolex forse varrà meno di un braccialetto pieno di sensori sotto i 100 dollari?

Tecnologia

Ho iniziato dicendo che la maggior parte delle tecnologie su cui sono basate le applicazioni IoT sono per la maggior parte ben note. Intendo dire che non vedo, al di là di IPv6, tecnologie specifiche senza le quali le applicazioni IoT sarebbero irrealizzabili.

Crediti: sabrina’s stash

Ciò che serve per fare un vero passo in avanti sono sistemi operativi e protocolli di rete specifici per applicazioni su scala IoT che offrano primitive per garantire sicurezza e riservatezza dei dati. A titolo di esempio porto Bluetooth 4.2, per ora ancora a livello di specifica, che introduce nuove funzionalità di sicurezza (Sezione 5.2.1 “Security Goals”) e riservatezza (Sezione 5.4.5 “Privacy Feature”) con le quali attacchi di brute forcing come quello dimostrato sul Samsung Gear sarebbero sostanzialmente impossibili.

Riguardo alla riservatezza, Bluetooth 4.2 prevede un meccanismo per ridurre la possibilità per un osservatore esterno di tenere traccia di un dispositivo. Ogni dispositivo potrà essere configurato per essere visibile solo da una lista di dispositivi configurabile, e invisibile agli altri, tutto ciò anche con radio sempre accesa. Di fatto, è una sorta di firewall molto semplice a livello MAC. Questo è sostanzialmente diverso dalla modalità operativa delle precedenti versioni, in cui l’unico modo per nascondere un dispositivo era quello di spegnere la radio o renderlo non visibile—da chiunque. La parte ancora più interessante è che questa nuova funzionalità sarà disponibile con un aggiornamento software!

Questo discorso può essere generalizzato ad altre tecnologie oltre a quelle di rete. Il messaggio è, tuttavia, il medesimo: la tecnologia deve garantire, indipendemente da come utilizzata, proprietà di sicurezza, out of the box. Non sono io a raccomandarlo e non sono nemmeno gli incidenti e gli scandali che abbiamo visto negli ultimi 2 anni a richiederlo. Dal maggio del 2014 è da considerarsi una best practice progettare un protocollo di rete che sia in grado di mitigare attacchi di sorveglianza. Per i curiosi, sto parlando dell’RFC 7258 dell’IETF che porta la firma di Trinity College Dublin e ARM Ltd.

Concludo con un personalissimo commento sulla responsabilità di crea software per applicazioni IoT. È una leggerezza far sviluppare software per sistemi embedded a ingegneri e sviluppatori che non siano paranoici esperti di sicurezza, perché i casi d’uso di queste tecnologie sono intrinsecamente critici. Attenzione però, perché c’è la trappola. La facilità e la rapidità con cui oggi è possibile programmare un dispositivo IoT non implica che sia sufficiente un programmatore qualsiasi. Serve un set di conoscenze multi disciplinari che va ben oltre quelle richieste sia ad un generico programmatore sia ad un generico esperto di sicurezza.

Purtroppo, ancora una volta, il mercato fortemente dinamico e la corsa al prezzo più basso non sono punti a favore per la sicurezza delle applicazioni IoT.

Crediti: Dave Barger

Riferimenti

• Kevin Ashton, That ‘Internet of Things’ Thing (Giugno 2009)
• National Intelligence Council, Disruptive Civil Technologies, Six Technologies With Potential Impacts on US Interests Out to 2025 (Aprile 2008)
• Open Source Hardware
• Inverse Path, USB armory (Gennaio 2015), codice sorgente
• Kristin Bent, Cisco Launches ‘Fog Computing’ Platform For Internet Of Things (Febbraio 2014)
• Warwick Ashford, Top 10 cyber security stories of 2014 (Dicembre 2014)
• SysSec Consortium, The RED BOOK: A Roadmap for Systems Security Research (2014)
• Ang Cui, Salvatore J. Stolfo, A Quantitative Analysis of the Insecurity of Embedded Network Devices: Results of a Wide-Area Scan (Dicembre 2010)
• Carolyn Guevarra, Botnet Rises in the Name of Chuck Norris (Marzo 2010)
• Brian Krebs, Lizard Stresser Runs on Hacked Home Routers (Gennaio 2015)
• Shahar Tal, I Hunt TR 069 Admins Pwning ISPs Like a Boss (Agosto 2014)
• Dean Takahashi, Hello, Dave. I control your thermostat. Google’s Nest gets hacked (Agosto 2014)
• Swati Khandelwal, Smartwatch Hacked… Data Exchange with Smartphone Not So Secure (Dicembre 2014)
• Bruce Schneier, The Internet of Things Is Wildly Insecure — And Often Unpatchable (Gennaio 2014)
• Ang Cui, Michael Costello, Salvatore J. Stolfo, When Firmware Modifications Attack: A Case Study of Embedded Exploitation (Febbraio 2013)
• Michael K. Daly, Raytheon, For the Internet of things, the cost of cheap will be steep (Gennaio 2015)
• John Chambers, What does the Internet of Everything mean for security? (Gennaio 2015)
• La Stampa.it, Case sicure e bollette leggere con l’impianto elettrico 2.0 (Gennaio 2015)
• Chester Wisniewski, Smart meter hacking can disclose which TV shows and movies you watch (Gennaio 2012)
• Dario Carluccio, Stephan Brinkhaus, Smart Hacking for Privacy (Dicembre 2011)
• Xipiter, The Insecurity of Things: Part One (Ottobre 2014)

“Hardware hacking is a sh*tload of fun!”

—Anonymous