di Federico Fuga
Negli ultimi anni la diffusione dell’IoT, o internet delle cose, ossia l’insieme di tutti quei dispositivi elettronici connessi tra loro e alla rete internet, ha subito un’accelerazione impressionante. Diverse statistiche mostrano che il numero assoluto di dispositivi IoT in funzione ha raggiunto quello dei dispositivi non IoT ormai qualche anno fa, con un trend di crescita impressionante. Se i dispositivi non-IoT hanno raggiunto un sostanziale plateau già quasi dieci anni fa, i dispositivi IoT dovrebbero raggiungere i 30 miliardi di dispositivi entro il 2025, triplicando in 6 anni1.
Per capire il passo enorme, possiamo andare a ricostruire come si immaginava il futuro quarant’anni fa. Correva l’anno 1985 e nel “Grande libro dell’Informatica” di Mariagiovanna Sami veniva raccontata questa ipotetica scenetta:
La padrona di casa ordina: “Menu!” e la voce educata – con un tono appena un poco snob – replica obbediente “Menu”. Sullo schermo compare un elenco: “arrosti”, “torte” e via di questo passo. La signora decide “Torte” e sullo schermo appare un altro elenco. … Poi, quando la signora ordina al forno”Apriti!” ecco che lo sportello si spalanca e il forno si predispone caldo alla temperatura giusta … e poi continua a lavorare secondo le istruzioni, mostrando sullo schermo come procede la cottura, finché tutto non è finito! E intanto la vocina ricorda “Mancano solo tre minuti prima che la torta sia pronta”, e poi “Manca solo un minuto”… Può darsi che questo forno non sia ancora in vendita in tutti i negozi, ma di sicuro esiste: è stato presentato ad alcune fiere di elettrodomestici e ha dimostrato la propria abilità cucinando degli ottimi pranzetti2.
Meno di quattro decenni dopo, il forno non solo è in vendita nei supermercati per una frazione irrisoria del costo del 1985, ma nello scaffale accanto abbiamo televisori, lavatrici, valvole termostatiche, telecamere di sicurezza, termometri, e mille altre “commodities”. Quello che, con l’ingenuità di quei tempi, la Signora del libro faceva con la voce, noi lo facciamo con lo smartphone, non perché parlare con gli assistenti virtuali non sia possibile, ma semplicemente perché si è scoperto che è molto più comodo e pratico usare un oggettino sempre nella tasca.
L’IoT è questo, milioni di dispositivi più o meno intelligenti, a volte più o meno utili, collegati in rete, pronti a riversare fiumi di informazioni verso altri sistemi che li utilizzeranno. Questo scriveva l’inventore del termine, Kevin Ashton, per RFID Journal nel 2009: Siamo esseri fisici, e fisico è l’ambiente. […] Idee e informazioni sono importanti, ma le cose lo sono molto di più. […] Se avessimo computer in grado di conoscere tutto ciò che c’è da sapere sulle cose – utilizzando dati raccolti senza alcun aiuto da parte nostra – saremmo in grado di tracciare e contare tutto, e di ridurre consumi, perdite e costi. […] L’internet delle cose ha il potenziale per cambiare il mondo, come ha fatto l’Internet. Anche di più.3
Ma quello che nel testo del libro sembrava semplice ed immediato, nella realtà nasconde insidie e sfide affatto banali, che richiedono un’attenta progettazione in ogni singolo passo, dalla scelta del prodotto alla sua dismissione.
Una sommatoria di problemi
Come per la scelta del sistema operativo di un pc, la scelta tra diverse alternative di un prodotto IoT si porta dietro variabilità quanto a funzionalità, capacità di interoperabilità e disponibilità di servizi.
Nell’IoT anzi questi problemi sono potenzialmente moltiplicati per il numero di produttori esistenti sul mercato e il numero di tecnologie diverse coinvolte. Ma non solo: se ci soffermiamo un attimo ad analizzare il flusso dei dati dalla sorgente, cioè dal dispositivo dove i dati nascono o vengono raccolti, fino alla destinazione, ossia al sistema in cui essi vengono utilizzati, si può avere una vaga idea di quella che è potenzialmente la complessità del problema.
Poiché lo scopo dei dispositivi è comunicare e scambiare dati con altri dispositivi attraverso Internet, occorre considerare l’aspetto del “come” tali dati vengono trasferiti, ossia il problema dei protocolli e degli standard di comunicazione, nonché l’aspetto del cosa, ossia dei servizi offerti dal dispositivo e dalle piattaforme.
Ciascun produttore ha una sua visione del prodotto, di quali sono gli standard da adottare, di quali servizi fornire e di quanto “aprire” il sistema all’utente, considerazioni dettate per lo più dal modello di business, dalla disponibilità di standard e di software, nonché dal marketing.
Infine, e non di minore importanza, tali dispositivi sono calati all’interno di una realtà, o “dominio digitale” esistente, che spesso è una rete domestica o aziendale più o meno complessa, nel quale devono convivere con altri dispositivi rispettando tutte le regole stabilite dai responsabili per garantire livelli di sicurezza adeguati al rischio informatico.
Tutti questi aspetti devono essere tenuti debitamente in conto nella scelta dei dispositivi e delle tecnologie.
La scelta delle tecnologie
Di seguito daremo alcuni cenni alle varie alternative tecnologiche disponibili, trattando l’aspetto della connettività, dell’interoperabilità e quello applicativo.
Questa non può e non vuole essere una trattazione esaustiva, ma solo uno spunto di approfondimento per i vari aspetti, in quanto, come vedremo, il panorama è in continua evoluzione. Il mercato dell’IoT è considerato uno dei più floridi e promettenti a livello globale e standard, protocolli e applicativi nascono ed evolvono con notevole frequenza.
Connettività
La maggior parte dei dispositivi IoT dispongono di collegamento wireless; essendo piuttosto variegato il contesto di installazione di dispositivi IoT, si sono affermati standard diversi in grado di far fronte alle necessità specifiche, come area di copertura e distanza fisica tra i dispositivi, livello di immunità ai disturbi elettromagnetici, compatibilità con standard esistenti. Tuttavia i dispositivi più sofisticati offrono spesso anche connessione wired che è, senza alcun dubbio, in assenza di ostacoli specifici, senz’altro da preferire.
In quest’ambito tratteremo soltanto le tecnologie wireless, in quanto per quelle wired accanto allo standard ethernet, praticamente onnipresente, si registrano i bus di campo d’uso prettamente industriale; in generale, non essendo di per sé tecnologie abilitate ai protocolli di rete Internet, richiedono l’installazione di router o hub specifici, per i quali valgono le considerazioni analoghe a quelle di alcune tecnologie wireless.
La connettività wireless in generale usufruisce di canali di comunicazione allocati nelle cosiddette bande ISM4, acronimo per Industrial, Scientific, Medical. Tali frequenze sono comunemente utilizzate per esempio dai dispositivi Wifi e Bluetooth, ma anche da dispositivi radio come ripetitori per cuffie e transponder di cancelli automatici e chiavi di automobili.
La banda dei 2.4Ghz è utilizzata dalle tecnologie Wifi e Bluetooth; per il Wifi è disponibile anche la banda 5Ghz e presto quella dei 6Ghz con lo standard 6E. Queste e altre tecnologie convivono grazie ad accorgimenti specifici che permettono ai dispositivi di cambiare frequenza quando quella in uso è particolarmente affollata o rumorosa. È una banda utilizzata in ambiente domestico e commerciale per via delle sue caratteristiche fisiche.
Oltre a queste frequenze esistono bande libere dette “sub Gigaherz”. La banda dei 433Mhz è utilizzata spesso per segnali digitali che richiedono maggiore distanza ma minore velocità; è utilizzata, tra l’altro, da telecomandi wireless, da stazioni meteorologiche e termometri. La banda degli 868Mhz invece è frequentemente utilizzata da ricetrasmittenti radio e ultimamente da dispositivi di misura remota. Queste due frequenze sono preferite in ambiente aperto e sono raramente utilizzate dai dispositivi informatici in generale, essendo riservate invece per gli usi industriali e di misurazione.
Accanto a queste tecnologie che utilizzano le bande libere, occorre menzionare anche quelle tecnologie che utilizzano la rete cellulare mobile (4G, 5G, GPRS), per quanto, nell’economia di questa trattazione, all’aspetto della connessione siano da riservare delle considerazioni a parte.
Tanti protocolli diversi
Il canale di comunicazione tra i dispositivi è costituito dal protocollo che lo utilizza, ossia l’insieme di regole che stabiliscono sia la modalità di comunicazione (“l’alfabeto” per così dire) che le regole di accesso (che potremmo definire “la sintassi” e “la buona educazione”).
Wifi
Il protocollo wireless per eccellenza degli ultimi anni è il protocollo Wifi5, che lavora su frequenze di 2.4Ghz, 5Ghz e a breve 6Ghz. Basato sullo standard IEEE-802.11, è stato progettato per applicazioni WLAN (Wireless Lan) in cui molteplici dispositivi si connettono in rete attraverso un singolo punto di accesso (Access Point). Per questo motivo tutti i dispositivi devono essere “coperti” dalla rete wireless, la quale diventa meno performante man mano che la distanza aumenta o per la presenza di ostacoli, abbassando il livello di segnale. Le performance della rete in copertura ottimale sono assai elevate, ma il protocollo richiede un continuo collegamento tra il dispositivo che lo utilizza e il punto di accesso, che comporta un aumento molto sensibile del consumo di energia6. Questo aspetto è assai rilevante in quelle applicazioni in cui sensori e dispositivi sono alimentati da batteria. In particolare spesso dispositivi a batteria non hanno un collegamento costante con l’access point, e di conseguenza comandi e dati non sono inviati e ricevuti “in tempo reale”.
Bluetooth (BT)
Il protocollo Bluetooth non è stato originariamente pensato per applicazioni di tipo IoT, ma con l’introduzione della sua evoluzione detta “Low Energy” è diventata una opzione pratica. Operante sulla frequenza 2.4Ghz, in grado pertanto di “convivere” con il Wifi, nella prima versione detta “Classica” ha un consumo energetico e una portata che lo rende meno appetibile rispetto al Wifi; viceversa la versione Low Energy permette un consumo energetico sensibilmente inferiore al Wifi, ma con una portata sensibilmente inferiore. Come il wifi, per via della sua disponibilità in praticamente tutti i dispositivi personali (Personal Computer e smartphone) è sovente utilizzata per sensori sia ambientali (temperatura, umitidità, eccetera) sia personali (smartband, contapassi, dispositivi medici), tuttavia proprio per via della portata molto limitata non è considerato il protocollo ideale per applicazioni IoT, ma piuttosto per applicazioni di misura personale.
Zigbee e Z-Wave
Zigbee e Zwave, sono protocolli basati sullo standard IEEE-802.15.47, ossia per applicazioni Wireless Personal Area Network (WPAN), tuttavia a differenza di Bluetooth, è stato progettato specificatamente per il mondo IoT, e quindi con lo scopo di essere più semplice (richiedendo minore potenza di calcolo), più robusto e meno esoso in termini di energia.
La rete Zigbee ha una topologia di tipo Mesh, ciò significa che a differenza di Wifi e BT, che sono reti centralizzate, non richiede che vi sia copertura completa da parte di un access point, ma è sufficiente che ciascun nodo sia in grado di raggiungerne un altro con capacità “router”. Questo semplifica notevolmente l’installazione di una rete, in quanto è sufficiente che i nodi più distanti tra loro riescano a raggiungere almeno un altro nodo router, il quale si occuperà di ritrasmettere i dati verso il nodo di destinazione.
Tuttavia è necessario prevedere un nodo, sovente che fa anche da “coordinatore” della rete, che la colleghi alla rete locale e da questa ad Internet. Tali nodi sono spesso identificati col termine “Hub”. Zigbee può lavorare sia su frequenza di 2.4Ghz che su frequenza 866Mhz (o 915Mhz in USA).
Z-Wave è un protocollo per molti versi simile a ZigBee, tuttavia a differenza di quest’ultimo, esso è un protocollo chiuso utilizzato da un singolo produttore di chip (Silicon Labs).
Entrambi i protocolli sono stati adottati da diversi produttori di dispositivi, tra cui ad esempio, Siemens, Schneider Electric, Philips, Osram, Bosch, Busch-Jaeger, Samsung, Sony8.
LoRa e LoRaWan
LoRa9 è anch’esso un protocollo di rete sub-Gigaherz ed è ottimizzato per lavorare su lunghe distanze (fino a 10km). Su di esso è stato definito un protocollo ulteriore, chiamato LoRaWan10, che definisce non solo la metodologia di connessione tra i nodi LoRa, ma anche l’inoltro e il trasporto dei dati attraverso la rete stessa, fino al dispositivo finale nella rete internet, è cioè predisposto nativamente per l’interconnessione con la rete internet.
Date le caratteristiche del protocollo, esso è specificatamente orientato all’uso in ambiente aperto per coprire notevoli distanze. È utilizzato per esempio nelle smart cities11 o nelle applicazioni di supervisione del territorio12 e della fauna13.
6lowpan, Thread e Matter
Thread è ancora un altro protocollo IoT, nato nel 2014 da un consorzio di diversi produttori, la Thread Group Alliance14. Esso è nato con lo scopo di superare le complessità inerenti l’IoT, in particolare sotto gli aspetti dell’interoperabilità, la portata del segnale radio, l’energia necessaria per alimentare i dispositivi, la sicurezza e l’affidabilità. Si tratta di protocollo aperto che si basa su altri due protocolli aperti, IEEE-802.15.415 e 6LowPan16.
Anche Thread implementa una rete Mesh, ed è progettato per non fornire un “Single Point of Failure”, ovvero un “singolo punto vulnerabile” il cui guasto possa compromettere il funzionamento dell’intera rete. Anzi, la rete è capace di riorganizzarsi e aggirare i nodi non disponibili.
Su di esso è stato costruito il nuovo protocollo chiamato Matter17, pubblicato nella versione 1.0 lo scorso ottobre 202218. Matter è un protocollo IoT che può funzionare sia su thread che su altri protocolli radio esistenti, in particolare Wifi. Matter, il cui nome originario era CHIP, acronimo per Connected Home over IP (Casa connessa su protocollo IP), è stato pensato per superare la frammentazione delle tecnologie IoT tra i vari produttori, infatti tra i finanziatori del progetto troviamo Google, Apple, Amazon e Samsung; inoltre è stato da subito adottato da produttori di prodotti “Smart”, quali Ikea, Huawei, Schneider.
L’obiettivo di Matter è, tra le altre cose, quello di superare i limiti dati dai diversi protocolli e di permettere ai prodotti di interfacciarsi sia al Cloud sia ai server locali superando la necessità di appoggiarsi ad un servizio esterno che, come vedremo, è una delle fonti principali dei problemi di interoperabilità del mondo IoT.
Router e gateway
Com’è facile intuire, non tutte le tecnologie sopra menzionate sono in grado di connettersi direttamente, tramite Router o l’equivalente di un Access Point Wifi, alla rete LAN, internet e ai server che raccolgono e trattano le informazioni; se si scelgono tecnologie di rete diverse, sarà necessario prevedere un sistema di connessione alla rete esistente. Si parla di Router quando i protocolli permettono di per sé la trasmissione sulle reti TCP/IP, ad esempio, quelli basati su 6LoWPan (thread) o LoRaWan; si parla di Gateway, o a volte Hub, quando il punto di accesso effettua una sorta di traduzione degli indirizzi dei dispositivi sulla rete perché incompatibili tra loro; è il caso del Bluetooth per esempio, che richiede un PC di raccolta dei dati, ma anche di molte tecnologie di rete cablata, ad esempio i bus di campo.
È importante notare che essendo le tecnologie diverse incompatibili tra loro, occorre prevedere la presenza di un opportuno Router o Gateway per ciascuna di esse. Questo aspetto è importante nella scelta, in quanto l’uso di una lega in qualche modo alla futura scelta di altre.
Server cloud di serie
Assai spesso con i dispositivi IoT i produttori forniscono anche un server Cloud a cui appoggiarli, per fornire un servizio completo e “Plug and play”. Questo approccio, di solito indirizzato ad una utenza di tipo SOHO (“small office home office”), ha appunto il vantaggio di richiedere una configurazione assai semplice, sovente limitata alle credenziali di accesso alla rete wireless. Tuttavia, come vedremo meglio nelle conclusioni, talvolta questo rende complicata l’integrazione con le reti e i servizi esistenti, in quanto non di rado, poco o nulla offrono come alternativa.
Protocolli di trasporto e applicativi
Una volta connessi alla rete, i dispositivi devono supportare almeno un protocollo di comunicazione, ossia una “lingua” che i server che raccolgono e trattano i dati siano in grado di capire.
A questo livello le cose col tempo si stanno facendo più chiare, in quanto da una parte i produttori stanno convergendo verso alcuni protocolli comuni, dall’altra è molto più facile per gli stessi adattare il firmware dei propri dispositivi adottando uno o più di questi standard.
Tra tali standard si stanno affermando MQTT e COAP, con HTTP a fare da “ultima spiaggia” in quanto non specificatamente dedicato allo scopo. Tramite essi i dispositivi possono periodicamente inviare le telemetrie ed essere notificati di “cambi di stato”, ossia eventi e comandi cui possono seguire azioni. Pertanto è necessario predisporre un server per quel protocollo sulla rete locale; su tale server (talvolta detto “Broker”) si appoggiano anche eventuali server applicativi come pannelli, dashboard e app mobili.
HTTP viceversa è un protocollo non specifico per l’IoT ma frequentemente usato al fine di fornire le telemetrie tramite un pannello direttamente implementato dal dispositivo, e non da un server locale. Questo genere di servizio è in generale fornito da quei dispositivi in grado di parlare direttamente con la rete locale, ad esempio quelli su Wifi.
Per quei dispositivi che invece hanno bisogno di un gateway, ad esempio Bluetooth, Zigbee o un qualche protocollo RF non standard, solitamente l’accesso ai dati avviene grazie al gateway stesso il quale fornirà i dati attraverso i propri protocolli e applicativi, secondo le scelte del produttore stesso. In tal caso tuttavia i gateway mettono a disposizione molteplici opzioni incluse MQTT o CoAP.
Applicativi
Una volta connessi i dispositivi e raccolti i dati, essi vanno utilizzati e presentati all’utente o comunque gestiti.
Con i dati a disposizione è possibile fare presentazioni ed elaborazioni per i fini più diversi, dalla monitorizzazione delle risorse alla loro ottimizzazione, anche attraverso l’automazione. Ad esempio, si può procedere all’automazione dell’accensione delle luci e dell’attivazione di serrande e tende, o del riscaldamento, a seconda del contesto – per esempio, la presenza o meno di persone negli uffici, la temperatura esterna ed interna in determinate stanze – ottenendo un vantaggio concreto. In ambito industriale, la raccolta di statistiche riguardo produzione e consumi permette interessanti ottimizzazioni, soprattutto grazie alla possibilità di integrare i dati raccolti con algoritmi statistici in grado di fare inferenze e predizioni.
Ciò è possibile con l’opportuno software, il quale, però, dovrebbe essere quanto più integrato e flessibile da supportare la maggior parte dei dispositivi disponibili.
Esistono tantissime possibilità in questo senso. I produttori di dispositivi in generale offrono la possibilità di utilizzare il proprio cloud, il quale però solitamente è accessibile soltanto nelle modalità definite, cosa che potrebbe limitare la disponibilità di dati e servizi. Tuttavia quando i dispositivi mettono a disposizione protocolli e specifiche esistono possibilità di utilizzare applicativi terzi sia open che closed source, ospitati sui propri server.
Tra le piattaforme open source dedicate alla gestione dei dispositivi IoT, vale la pena menzionare Home Assistant19, che nonostante il nome richiami il contesto domestico, è una opzione assai valida anche per gestire situazioni più complesse.
Con esso per esempio è possibile raccogliere i dati dei sensori e collezionarli in set di dati al fine di presentare statistiche ed elaborazioni; inoltre è possibile definire scenari sulla base di eventi ed effetti, come ad esempio attivare in automatico la programmazione del riscaldamento quando il sistema rileva presenze all’interno dell’appartamento.
La grafica è di un certo impatto visivo e la piattaforma è compatibile con un enorme numero di dispositivi, inclusi diversi che si appoggiano esclusivamente a Cloud proprietari. Tra le categorie di dispositivi supportati non ci sono solo dispositivi prettamente IoT (sensori, elettrodomestici, telecamere di sicurezza), ma anche dispositivi come stampanti, assistenti vocali (Alexa, Google Assistant e Siri), dispositivi mobili e multimediali. In questo modo le possibilità di automazione sono davvero enormi.
Un’altra alternativa Open Source è costituito da Open Remote20, che si propone come una piattaforma orientata non solo all’home management, ma anche al building automation e alle smart cities. Nel curriculum di applicazioni troviamo il controllo passaporti dell’aeroporto Schypol e la Smartcity di Rotterdam, di cui è disponibile anche una demo funzionante21.
In ogni caso occorre sempre tener conto che per quanto “User friendly”, queste piattaforme hanno una certa complessità intrinseca che richiede, specie negli strumenti più sofisticati, una dimestichezza sia con la tecnologia IoT che, a volte, con le basi della programmazione, pertanto la scelta della piat taforma non deve essere troppo ambiziosa senza avere la possibilità di mettere in campo risorse in termini economici e di know-how.
Sicurezza e sopravvivenza a lungo termine
Ultimo, ma tutt’altro che ultimo dal punto di vista dell’importanza, è l’aspetto della sicurezza informatica.
Integrare un sistema IoT in una rete informatica estente richiede una particolare attenzione non solo nella scelta di dispositivi e protocolli, che devono essere sicuri di per sé, ma anche nel processo di integrazione stessa per via delle peculiarità uniche di tali dispositivi.
Se nel gestire sistemi informatici gli amministratori hanno più o meno il controllo di buona parte del sistema e hanno gli strumenti per verificare e controllare il funzionamento a seconda del modello di rischio e delle esigenze contingenti, nei sistemi IoT ciò è spesso precluso. Questo è anche uno dei motivi dietro i dubbi di molte intelligence che nei mesi scorsi hanno indotto alcuni governi occidentali a bandire alcuni brand di dispositivi IoT. Il motivo sta nell’impossibilità di verificare il codice all’interno del dispo sitivo, e dunque l’assenza di vulnerabilità o di vere e proprie backdoor in grado di attivarsi con il verificarsi di alcune condizioni e che permettano l’accesso al sistema e alla rete cui è collegato.
In questo senso i dispositivi IoT sono dei piccoli incubi. Per questo motivo è indispensabile che a partire dalla fase di progettazione del sistema IoT da integrare, durante la loro vita operativa e finanche alla fase di dismissione, la security prenda parte a tutte le decisioni progettuali ed operative. Esistono notevoli risorse in rete a cui attingere per avere un’idea del processo22.
Innanzitutto, si dovranno privilegiare dispositivi che integrano protocolli con livelli di sicurezza adeguati e possibilmente che abbiano già passato un processo di verifica (auditing). Andranno privilegiati produttori dalla buona reputazione, tenendo conto tuttavia che una lunga esperienza nel campo industriale potrebbe non riflettersi su un’analoga competenza nel campo della Information Security.
È importante tenere una lista dei dispositivi IoT collegati alla rete locale. Non è difficile “dimenticare” una macchina da caffè “smart”, e come descritto in un altro articolo proprio in questo numero della rivista, tale dispositivo può essere un facile bersaglio23 e una ottima testa di ponte per violare l’intera rete.
Per questo motivo è sempre consigliato, sia che si usino protocolli su Wifi, Ethernet o appositi HUB, di prevedere reti separate per i dispositivi IoT e per la rete locale, prevedendo opportuni firewall e DMZ sulla base delle necessità di accesso dei vari servizi. Tali reti segregate dovranno essere monitorate al fine di identificare le anomalie che possono indicare un tentativo di compromissione o una violazione vera e propria. Anche a livello di gateway e router, ove cioè il traffico della rete IoT viene instradato verso i sistemi che usufruiscono dei dati, esso andrà monitorato notificando ogni anomalia di direttrice.
In ogni caso a tali reti dedicate vanno applicati gli stessi principi di sicurezza che si applicano alle reti informatiche “ordinarie”, tenendo conto inoltre che il controllo degli endpoint (ossia dei singoli dispositivi) è di fatto assai complesso. In particolare, è sempre opportuno evitare di esporre direttamente i dispositivi alla rete internet, tramite porta sul router o tramite servizi di Remote Desktop. Grazie ai motori di ricerca specializzati (Shodan24 o analoghi) la presenza di questo accesso ai dispositivi non sarebbe nascosta per molto tempo. Reti remote andrebbero sempre collegate tramite opportuno tunnel VPN.
Un problema in particolare è quello dell’aggiornamento dei firmware. Se con i sistemi operativi moderni è relativamente facile applicare gli aggiornamenti del sistema, con i dispositivi IoT occorre prevedere un controllo più proattivo. Raramente infatti essi si integrano con gli esistenti sistemi di Update Management, e i produttori mettono a disposizione aggiornamenti con frequenza meno assidua; pertanto è importante seguire gli advisory di sicurezza dei produttori e le liste di distribuzione dedicate alla sicurezza al fine di avere immediata notizia di aggiornamenti del firmware disponibili, di eventuali vulnerabilità scoperte cui magari applicare opportuni workaround.
A tal fine, si dovranno prediligere quei produttori che più velocemente intervengono sulle vulnerabilità e che più di frequente provvedono a mettere a disposizione aggiornamenti del firmware.
Dal punto di vista della disponibilità dei servizi, in contesti in cui essa è particolarmente rilevante si dovranno prediligere dispositivi quanto più indipendenti possibile dalle risorse dei produttori. Iniziano a fioccare le storie di dispositivi “Smart” la cui vita termina con la fine del supporto da parte del produttore, o con il fallimento dello stesso. Belkin ad esempio ha chiuso i server necessari al funzionamento delle proprie telecamere Wemo nel 2020, dopo 7 anni di vita del prodotto25. Ma anche senza paventare il fallimento del produttore, anche un semplice guasto a km di distanza può distruggere un sistema IoT provocando notevoli danni e disagi. Appoggiarsi ad un fornitore di servizi esterno espone ad un “Single point of Failure”, che nel caso dell’IoT provoca disagi tangibili quanto gli oggetti smart di cui è composta: è successo con Amazon e migliaia di case intelligenti26.
Infine, il decommissioning dei dispositivi non è teoricamente così semplice come portarli in discarica: ognuno di essi ha almeno un piccolo chip di memoria EPROM o FLASH in grado di mantenere il contenuto per lungo tempo, ad esempio password e configurazioni. Il dispositivo prima di essere rimosso dalla rete andrà resettato alle impostazioni di fabbrica, sperando, non avendo altra possibilità di verifica, che il produttore abbia previsto una cancellazione sufficientemente sicura. Se essi prevedono anche una memoria esterna di tipo SD, essa andrà rimossa e opportunamente cancellata o riposta in un luogo sicuro. Ideale sarebbe attivare la crittografia nativa del supporto, se il dispositivo lo permette. In casi estremi si dovrebbe considerare anche la distruzione fisica dei chip di memoria.
Conclusioni
Come detto in questa lunga carrellata abbiamo voluto fornire degli spunti di riflessione per valutare la complessità del mondo IoT. Il settore è in crescita enorme e negli anni a venire è ragionevole pensare che nascano tantissime nuove tecnologie ed applicazioni, che porteranno ad un ulteriore livello di complessità. Pertanto è opportuno che fin da ora si approcci il problema con la giusta consapevolezza.
Se da una parte infatti la quantità di dati messa a disposizione da sensori e smart devices, provenienti da edifici, quartieri, e in generale da servizi pubblici quali parcheggi, veicoli ed apparati intelligenti, insieme alle capacità di identificare pattern da parte di tecnologie di Data Mining e di “Intelligenza artificiale” porteranno ad applicazioni sempre più sofisticate, dall’altra tutto ciò costituisce un rischio per ciò che essi raccontano di noi. Inoltre la facilità di controllare dispositivi fisici come illuminazione e utility espongono ad un rischio di manipolazione e sabotaggio nelle mani di entità ostili.
Né l’autrice del racconto in introduzione né la protagonista probabilmente sospettavano che quarant’anni dopo, installare il forno sarebbe stato così complesso. Ma è il costo della tecnologia: una più alta complessità richiede personale in grado di gestirla.
- Fonte: IoT Analytics https://iot-analytics.com/state-of-the-iot-2020-12-billion-iot-connections-surpassing-non-iot-for-the-first-time/ ↩︎
- Tratto da: Il Grande Libro dell’Informatica, Mariagiovanna Sami, Arnoldo Mondadori Editore, 1985, pag.146 ↩︎
- https://www.rfidjournal.com/that-internet-of-things-thing ↩︎
- https://www.radiomakers.it/news/bande-libereguide ↩︎
- https://it.wikipedia.org/wiki/Wi-Fi ↩︎
- Per rendersi conto degli ordini di grandezza, alla pagina https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/ è illustrato il profilo di consumo del SoC ESP32, un chip assai diffuso per la realizzazione di dispositivi IoT, nelle varie modalità di lavoro. Spegnendo il modem Wifi e Bt il consumo passa da 160-260mA a 3-20mA. ↩︎
- https://areeweb.polito.it/didattica/corsiddc/ETLCE2TO/Tesine/ZigBeePres06.pdf ↩︎
- la CSA-IOT (Connectivity Standard Alliance, in origine Zigbee Alliance) incorpora tutti i produttori di semiconduttori e tecnologie che supportano lo sviluppo di questo standard. Si veda: https://csa-iot.org/ ↩︎
- LoRa, acronimo per”Long Range”. https://it.wikipedia.org/wiki/LoRa ↩︎
- https://lora-alliance.org/ ↩︎
- https://www.semtech.com/company/press/semtechs-lora-technology-is-leveraged-by-kiwi-technology-to-develop-smart-cities-in-thailand ↩︎
- https://www.zdnet.com/article/sk-telecom-launches-lora-based-fire-detection-solution/ ↩︎
- https://www.irnas.eu/animal-conservation-with-lorawan-turtles-fish-and-more/ ↩︎
- https://www.threadgroup.org/ ↩︎
- https://it.wikipedia.org/wiki/IEEE_802.15.4 ↩︎
- https://en.wikipedia.org/wiki/6LoWPAN ↩︎
- https://en.wikipedia.org/wiki/Matter_(standard) ↩︎
- https://csa-iot.org/newsroom/matter-arrives/ ↩︎
- https://www.home-assistant.io/ ↩︎
- http://www.openremote.com/ ↩︎
- https://demo.openremote.app/manager/?realm=smartcity ↩︎
- https://www.iotsecurityfoundation.org/best-practice-guidelines/ ↩︎
- https://blog.avast.com/avast-hacked-a-smart-coffee-maker ↩︎
- https://www.shodan.io/ ↩︎
- https://www.belkin.com/it/support-article/?articleNum=316642 ↩︎
- https://futurism.com/amazon-outage-iot ↩︎
