Wyobraźcie sobie, że kroicie w kuchni szczypiorek, nawlekacie igłę, schodzicie po schodach, niosąc ciążki wazon, i nagle gaśnie światło… nic fajnego. Może być gorzej. Wracacie do domu, a w nim 8°C lub 28°C i cieknie woda z zamrażarki. To też „pół biedy”, ale jak zastaniecie otwartą bramę, a w garażu fstwierdzicie brak drogiej kosiarki? A co z „inteligentnym zamkiem” do drzwi domostwa?
Bezpieczeństwo rozwiązań automatyki domowej (i przemysłowej oczywiście też) oraz urządzeń IoT jest niestety bardzo złożonym zagadnieniem. Złożonym, ponieważ w użyciu jest wielka liczba różnych technologii, świadomość problemu nie jest pełna nawet wśród projektantów i wykonawców, a całość jest obarczona „grzechami dzieciństwa”.
Zacznijmy od końca
Używaliście bądź używacie włączników sterowanych pilotem radiowym? Takie popularne „RF 433”? Ja tak i sąsiad też. Zdarzało się, że zanim „uzgodniliśmy kanały”, to potrafiliśmy sobie wzajemnie wyłączać światło, a mój termometr często podłączał się do czujnika u sąsiada. Działo się tak, bo jedynym zabezpieczeniem tej technologii jest wybór kanału (adresu). I jakoś nikt z tego nie robił tragedii. Niestety projektanci pierwszych urządzeń automatyki domowej również uważali, że „jakoś to będzie”.
Dużym problemem jest wspomniana mnogość używanych technologii łączności. Wymienię kilka najpopularniejszych: Wi-Fi, Bluetooth, ZigBee, Z-Wave, LoRa, nRF24, rf433, rf868 i oczywiście wszystkie „komórkowe”. Każdą z tych technologii można (nie)zabezpieczyć na kilku poziomach. Weźmy dla przykładu WiFi. Podłączenie do punktu dostępowego routera może być szyfrowane (WEP, WAP, WAP2) lub nie. Nad tym aspektem może zapanować użytkownik, jednak to tylko wierzchołek góry lodowej. Urządzenia IoT transmitują dane pomiędzy sobą i do różnych „central i centralek”.
Te dane również mogą być lub nie być szyfrowane, tak jak nasze połączenie w przeglądarce może być w nieszyfrowanym protokole http lub szyfrowanym https (z kłódeczką). Na to jako użytkownicy nie mamy wpływu. Z Bluetooth jest zarazem lepiej i gorzej. Szyfrowanie transmisji i autentykację ma „w standardzie”, ale po ostatniej aferze z podatnością na przejęcie transmisji należy podchodzić do tego ostrożnie. Co gorsza, projektanci przyzwyczajeni do „szyfrowania w standardzie” i niewielkiego zasięgu technologii najczęściej zaniedbali własne dodatkowe metody zabezpieczeń.
Bardziej egzotyczne protokoły jak ZigBee stosowany przez Ikea Trådfri oraz Philips Hue, czy Z-Wave używany w wielu urządzeniach Fibaro, również mają wbudowane systemy szyfrowania i autentykacji, jednak wiele zależy od ich implementacji przez danego producenta. Najgorzej jest z nRF24, rf433, rf868, które sprzętowo nie mają żadnych systemów szyfrowania i autentykacji, więc wszystko zależy od twórców implementacji. Zobaczcie oferty „pilotów RF” do bram garażowych, które „same się uczą” kodów sterujących. Straszne, prawda?
Co się z czym łączy i jakie dane gdzie wysyła?
Po krótkim omówieniu problemów wynikających z tego, jak sprzęty IoT łączą się ze sobą, czas na kolejną porcję złych wiadomości. Urządzenia automatyki domowej zazwyczaj komunikują się z „centralą” lub „hubem”. Tak działa Ikea Trådfri, Philips Hue, Fibaro, BleBox i wiele innych, w tym (jednak nieobowiązkowo) HomeKit Apple. Najtańsze urządzenia WiFi, od jakich rozpoczął się mój cykl na blogu „Inteligentny dom…”, dla obniżenia kosztów łączą się z serwerami gdzieś w świecie i są sterowane za ich pomocą. Działa to tak, że aplikacja na naszym iPhonie wysyła polecenie do serwera gdzieś daleko, a on przesyła je do naszego urządzenia podpiętego przez WiFi w domowej sieci. Podobnie w drugą stronę. Nasze urządzenie wysyła np. odczyt temperatury na odległy serwer, a on przesyła dane do nas lub używa ich do automatyki i wysyłania poleceń. Najmniejszym problemem w tej sytuacji jest ewentualna utrata dostępu do internetu. Większym zaś zaufanie do producenta urządzeń i firmy odpowiadającej za serwery. Nie wiemy, czego się można spodziewać po „chińskim” przełączniku WiFi za 6 dolarów, współpracującym z serwerem producenta.
W bardzo wielu przypadkach proste urządzenia podłączone do sieci domowej (lokalnej) przez WiFi komunikują się z lokalnym serwerem uruchomionym na dysku NAS (QNAP, jak w moim przypadku), nanokomputerze Rospbery Pi lub jakimś jego klonie. Jednym z najpopularniejszych protokołów wymiany danych w „małym” IoT jest MQTT. Ma on wiele zalet (do działania wymaga naprawdę niewielu linijek kodu i jest bardzo elastyczny), ale jedną wadę: brak szyfrowania w standardzie. Jest wiele rozwiązań, które dodają szyfrowanie, jednak nie są zbyt często w lokalnych sieciach używane.
Wszędzie czyha zło… Co robić?
Myśleć… myśleć przy planowaniu rozwiązań, przed planowaniem zakupów, podczas instalacji, konfiguracji, uruchomieniu i wdrożeniu. Ponadto co jakiś czas kontrolować.
Jeżeli nie mamy sporej wiedzy, lepiej ograniczyć się do sprawdzonych rozwiązań znanych firm. Bardzo dobrym wskaźnikiem jest zgodność z HomeKit Apple, który nie dość, że jest wbudowany w nasze iUrządzenia, to był stworzony z myślą o maksymalnym bezpieczeństwie, a urządzenia opatrzone znakiem „HomeKit” przechodzą rygorystyczne testy, co też pierwotnie powodowało ograniczone zainteresowanie producentów. Więcej o HomeKit przeczytacie w osobnym artykule.
Pamiętajmy, że nawet bardzo znanym firmom przytrafiły się wpadki. Tak się stało z popularnymi termostatami Nest, tuż po przejęciu firmy przez Google. Po aktualizacji oprogramowania wielu użytkowników obudziło się w zimnych mieszkaniach.
Jeżeli chcemy używać tanich i prostych urządzeń, to postarajmy się, aby działały one w sieci lokalnej i nie komunikowały się z Internetem ani nie miały do niego dostępu. Sieć WiFi, w której będą pracować, powinna być dobrze zabezpieczona, najlepiej wydzielona od reszty. W poważniejszych zastosowaniach, jak sterowanie zamkami i otwieranie bram, zdecydowanie lepiej unikać rozwiązań eksperymentalnych i chałupniczych.
Cytując kolegę redakcyjnego Kubę Barana: „Myśl, a nic Ci nie grozi”.
Artykuł oryginalnie pojawił się w numerze 9/2017 Mój Mac Magazynu. | Zdjęcia Fotolia
Trzeba dodać, że Tradfri i Philips Hue, a przynajmniej ich nowe wersje współpracują z Apple HomeKit (Tradfri wymaga aktualizacji firmware centralki). Stało się to możliwe, bo od niedawna do komunikacji urządzeń HomeKit z kontrolerem (zwykle Apple TV 4 lub 4K) nie jest wymagany specjalny chip szyfrujący. Wystarczy, że szyfrowanie realizuje oprogramowanie, a to jest możliwe po aktualizacji firmware