L’elettrodomestico e la casa in rete è un ritornello più vecchio della diffusione di massa di Internet.
A questa promessa abbastanza inutile si sono aggiunte negli ultimi anni e nelle ultime settimane le promesse che tutti gli oggetti saranno online: termostati, orologi, frigoriferi, lampadine, calzini…
Bisogna riconoscere che adesso la tecnologia c’è quasi tutta per rendere veritiere queste promesse: ogni casa tecnologica ha una connessione a Internet con un access point. Il prossimo protocollo IPv6 permetterebbe, allo stato attuale, di assegnare non meno di 264 indirizzi univoci ad ogni abbonamento residenziale.
La tecnologia attuale rende disponibili microcomputer incorporabili in vari oggetti con costi ridicoli, si vedano a titolo di esempio i vari Arduino, Raspberry ed Edison.
Tutto online, tutto comodo, tutto bello, finché qualcuno decide, ad esempio, di fare uno scherzo al sistema di controllo dell’illuminazione.
Giusto per intenderci: non è che qualcuno crede che basti usare un indirizzo casuale, una porta non standard o dei protocolli non documentati per sentirsi sicuro, vero?
Già adesso con l’utente che viene tenuto all’oscuro di tutto chi sviluppa le APP commette degli errori madornali e mette a repentaglio la sicurezza dell’utente (qui e qui due dei tanti esempi che dovrebbero far riflettere sulla validità delle APP paragonate all’uso del browser). Twitter è uno di quelli che ha capito il problema e cerca di limitare i danni che programmatori incapaci potrebbero causare: dal 14 gennaio u.s. le chiamate alle API del sito di microblogging potranno essere fatte solo via HTTPS.
Tralasciando i vari aspetti di violazione della privacy, la pervasività di oggetti collegati in TCP/IP potrebbe costituire un pericolo se la tecnologia venisse implementata male dal punto di vista della sicurezza.
In questo momento l’unico sistema sicuro per garantire la riservatezza dei dati e l’identificazione con ragionevole certezza di chi ha diritto di accedere passa per l’adozione di TLS, magari con l’aggiunta della PFS. Anche nell’implementazione di OpenSSL, TLS non è immediato da integrare in un sistema perché richiede comunque la conoscenza dei vari aspetti del protocollo. Nulla di alieno, sia chiaro, ma è un campo in cui lo sviluppatore potrebbe decidere di prendere delle pericolose scorciatoie senza che nessuno se ne possa accorgere se non quando è troppo tardi.
Il secondo problema riguarda l’aggiornamento del software di questi oggetti. In primo luogo, non è detto che sia facile aggiornare il firmware di un frigorifero una volta che viene posseduto da un malware che (per esempio) riscrive l’host da cui il sistema scarica l’aggiornamento. In un PC o anche in un telefono si può usare il boot manager per intervenire sull’avvio, ma in un elettrodomestico o in un capo d’abbigliamento? Di solito l’accesso al boot manager (o equivalente) di questi oggetti avviene via seriale collegando opportunamente dei pin o delle piazzole ad una RS-232. Ce lo vedete l’utente medio (o anche il piccolo centro assistenza) a fare queste operazioni?
Ultima ma non ultima è l’attitudine delle ditte che producono questi oggetti, che, ovviamente, non vedono se stesse come ditte di software e, quindi, non hanno l’infrastruttura per gestire gli aggiornamenti e il ciclo di vita dei programmi; questo è un problema che sta venendo fuori, ad esempio, con le autovetture, che sono oramai piene di software. Ci potrebbe essere, inoltre, il rischio che il software non sia prodotto da un team interno alla casa stessa, ma sia commissionato all’esterno come progetto, che, una volta consegnato (e pagato), non viene più aggiornato. L’utente si potrebbe trovare, quindi, con un oggetto collegabile a Internet, ma che non può essere collegato e utilizzato appieno per ragioni di sicurezza.
Paranoia? Leggete qui. La storia si è rivelata poco attendibile. Per ora 😉
Lascia un commento