BigClown: bezpečnostní koncepce v IoT

Zabezpečení

V diskusi zazněl komentář k zabezpečení BigClown: “uniká mi výhoda, protože svůj vlastní lehce zabezpečený protokol si můžu pro Arduino napsat taky a nestojí mě to nic navíc”. Pojďme si tedy představit zabezpečení, jak jej navrhujeme my.

Jsme otevřeni všem řešením, která splňují základní předpoklady: 

• Bateriové napájení s výdrží alespoň 2 roky na komoditní alkalické baterie 
• Veřejná specifikace a implementace neohrožují bezpečnost 
• Svobodná licence 

Pokud kdokoli máte konkrétní nápady, specifikace či funkční prototyp, neváhejte se prosím podělit.
Neumíme pracovat s proklamacemi “mohl bych” či “nic to nestojí” u věcí, které neexistují v jakékoli podobě, nad kterou lze vést technickou diskuzi.

V první řadě připomeňme designový záměr celého BigClown: low power Nody, komunikující přes low bandwidth rádio, které jsou tak jednoduché, jak jen mohou být, ale ne jednodušší, s dostatečným výkonem i kapacitou, a s možností účelně zabezpečeného připojení do internetu.

Zabezpečení našeho systému rozdělujeme na několik zón, které zhruba odpovídá jeho logickému členění, jak jsme si jej popisovali minule (viz obrázek). Řešíme tedy:

• Zónu A, což jsou nody a vlastní lokální rádiová síť po koncentrátor 
• Zónu B, což je koncentrátor (Gateway) a lokální server s funkcionalitou Hubu 
• Zónu C, což jsou cloudové služby (obecněji internetové) 
• Propojení A-B 
• Propojení B-C

Každá z těchto oblastí má jiná rizika, jiné vektory útoku a jinou obranu proti nim. V zóně A jsou nody (tedy koncová zařízení). Zónu B tvoří gateway a lokální server, zóna C je pak “okolní svět”.

Kupříkladu u zóny B (linuxový server a rádiová gateway) potřebujeme nejen zabezpečení vůči případnému útoku zvenčí, ale i dobré fyzické zabezpečení. Jakmile se jich zmocní útočník fyzicky (popřípadě exploitem zvenčí), má pod kontrolou všechno v místních zónách A a v připojených cloudových službách (autentizace k nim je právě starost linuxového serveru). Pokud se někdo zmocní fyzicky Node (zóna A), má pod kontrolou pouze ten který Node. Může podvrhnout veškerou vnější Nodu (třeba falšovat naměřené údaje), ale nemůže jej duplikovat (tedy nevytvoří druhé zařízení, které se za Node vydává).

Zóna A: Koncová zařízení (Node)

Do této zóny patří koncová zařízení – nody – které komunikují se zónou B rádiem (použité pásmo 868 MHz).

V této zóně je použita topologie “hvězda”, tedy každý Node komunikuje pouze s Gateway, nekomunikují spolu navzájem. Tento přístup velmi zjednodušil návrh – nemusíme se starat o předávání informací mezi nody jako u topologie “mesh” a odpadá řešení problémů s nestabilitou routování, zabezpečení routovacích protokolů a dalších servisních protokolů.

Komunikační protokol je otevřený a popsaný (zde se opět odvolám na úvod tohoto dílu: vše vzniká, takže si zde ukážeme, jak protokol vypadá, ale na webu bude až úvodní revize použitá v produkční sérii). Je tedy do jisté míry proprietární. K tomuto řešení jsme nakonec sáhli proto, že jsme nenašli žádnou rozumně jednoduchou a použitelnou, obecně dostupnou a svobodnou alternativu. Díky tomu jsme jej mohli navrhnout tak, aby splňoval naše představy o zabezpečení a nízké spotřebě.

Autentizace komunikační session mezi Node a Gateway je zabezpečena SHA256 a sdíleným tajemstvím, které je pro každý Node unikátní. Integrita a privátnost zpráv je zabezpečena pomocí OCB-AES-128 s klíčem unikátním pro každý Node a obměňovaným zhruba jednou denně. Zjednodušením oproti jiným řešením je to, že AES-128 využíváme jak pro zajištění integrity, tak i pro šifrování a dešifrování zpráv.

Volitelně lze zajištění integrity přenosu posílit pomocí SHA256 na bezpečnostním čipu (třeba pro akce typu otvírání vstupních dveří), ovšem za cenu větší spotřeby energie.
V Node a Gateway používáme specializovaný hardware pro ukládání sdíleného tajemství pro SHA256 (čip ATSHA204A), který brání duplikaci Node či Gateway. V obou zařízeních používáme procesor s hardwarovou akcelerací algoritmu AES-128 (což není podstatné pro bezpečnost, ale pro úsporu napájení) a TRNG (True Random Number Generator).

Zóna B: lokální server a gateway

Server (počítáme obecně s použitím Linuxu, konkrétní distribuce bude záležet na hardwaru – kupř. Raspbian či OpenWrt u Turrisu) je zabezpečen tak, jak jej zabezpečí jeho správce. Komunikace mezi komponentami, které na tomto serveru běží, není zabezpečena a je ohraničena právě jen tímto prostředím. Díky použití linuxové distribuce fungují automatické aktualizace a bezpečnostní záplaty elektronicky podepsanými balíčky.

V této oblasti záleží zcela na správci, jaký software na svůj server pustí, jakému bude důvěřovat. My budeme mít doporučenou konfiguraci a doporučení pro deployment, pro kterou budeme poskytovat podporu.

V této zóně je i rádiová Gateway. Gateway se serverem jsou propojeny fyzicky USB spojením (typicky konektor, nebo krátký kabel). Komunikace probíhá v plain textu. Zde jsme toho názoru, že není bezpečnostně účelné propojení důkladně zabezpečovat na straně použitého protokolu, protože pokud se útočník dostane bezprostředně k USB spojení, už narušil fyzickou bezpečnost linuxového serveru a má snazší vektory útoků, než napadat komunikaci po USB.

Propojení zón B a C

Komunikace mezi komponentou Hub (která běží v lokálním linuxovém serveru) a vnějším světem (internetem) probíhá zabezpečeně s pomocí TLS, DNSSEC, zabezpečené synchronizace času. Používáme protokoly HTTPS a MQTT over TLS. V rámci HTTPS někdy používáme i WebSockets (wss).

V zóně C kooperujeme na zabezpečení komunikace klient-server, zabezpečení cloudů necháváme na providerech. Primárně se orientujeme na cloudové služby od Amazonu a Google, ale nevyhýbáme se ani integraci s Azure a dalšími službami, primárně založenými na REST či MQTT.

Připojení Node do sítě

Už několikrát tu zaznělo, že Node sdílí s Gateway tajemství. Prvotní výměna sdílených tajemství probíhá při fyzickém “párování” Node s Gateway. Pomocí NFC (alternativně přes USB) se přenesou sdílená tajemství z Gateway do Node, jedno (to pro SHA) je uloženo do bezpečného úložiště ATSHA204A, druhé (použité pro AES) se ukládá do paměti mikrokontroléru.

Tajemství v bezpečném úložišti slouží k počítání SHA-256 HMAC jednotlivých zpráv. Používá se nejen k ověřování zpráv, ale i pro výměnu AES klíče. AES klíč je uložen, jak jsme si už řekli, v procesoru a slouží k šifrování (OCB-AES128) přenášené zprávy algoritmem AE (Authenticated Encryption), který zajistí i autentizaci zprávy.

Rádiový přenos

Pro přenos dat rádiem jsme si vytvořili dvojici přenosového protokolu a kompresního algoritmu. Při hledání možných technologií jsme nenašli žádnou rozumně použitelnou, proto jsme zvolili vlastní cestu (a otevření protokolů pod svobodnými licencemi). Vycházíme z MQTT, ale rozšiřujeme jej pro rádiovou komunikaci a podporu autentizace a šifrování.

Komprese přenášených dat algoritmem Twirling

Twirling je kompresní algoritmus, který využívá toho, že Gateway zná strukturu zpráv Node. Druhá úroveň komprese v algoritmu Twirling spočívá v tom, že se některé často používané hodnoty posílají pomocí menšího počtu bitů (algoritmus tak připomíná trochu Huffmanovu kompresi). Podrobněji si tento protokol popíšeme příště.

Přenosový protokol Juggling

Data jsou zkompresována algoritmem Twirling, zašifrována, opatřena autentizační informací, je načase je přenést pomocí rádia. K tomu používáme protokol Juggling. Přenos obsahuje několik vrstev, od linkové přes síťovou a transportní po prezentační a aplikační. Tento protokol řeší i přenos servisních informací, synchronizaci vysílání nebo identifikaci přijímače a vysílače. Na úrovni protokolu Juggling se řeší připojení, vysílání dat i pravidelný update klíčů pro AES.

Na té nejnižší, “paketové”, se přenáší úvodní preambule, synchronizace a identifikace sítě, délka zprávy, identifikace zdroje a cíle, samotná data (21 – 58 bytů), 16 bytů autentizačních dat a dvoubytový CRC kód. Délka, zdroj, cíl a data jsou autentizována pomocí AE (algoritmus OCB-AES128).

Transportní vrstva obsahuje informaci o čase, počítadlo pokusů (retransmit counter), příkaz (connect, challenge, disconnect, pub, sub atd.) a takzvaný payload (až do 37 bytů). Větší objem dat je možné přenést pomocí tzv. Bulk přenosu ve více paketech.

Pomocí speciálních příkazů se řeší i aktualizace AES klíčů. Obě zařízení, jak Node, tak Gateway, v tomto případě využívají generátor náhodných čísel TRNG, a prostřednictvím série zpráv si aktualizují sdílené tajemství. Názorně popisuje celou výměnu následující obrázek.

Využití bezpečnostních mechanismů

Naším cílem je, aby popsané bezpečnostní mechanismy mohl využít každý uživatel zcela transparentně. Node i Gateway obsahují firmware (opět otevřený pod licencí MIT), který funguje “na první zapojení” tak, jak jsme si popsali výše – tedy využívá prvotního předání sdíleného tajemství při párování zařízení, transparentně data šifruje, autentizuje a doručuje.

Pokud z jakéhokoli důvodu uživatel nechce či nemůže použít generický firmware, může si napsat vlastní. K tomu nabízíme knihovnu v jazyce C, které stačí přes jednoduché API předat data, a ona se postará o jejich zabalení, zabezpečení, transport, opětovné rozbalení a ověření autentizace.

Třetí možností je samozřejmě použití jakéhokoli software, který si uživatel napíše.

Vycházíme tak vstříc i takovému přístupu, jako je ten citovaný na začátku článku: “udělám si vlastní zabezpečený protokol”. Můžete, a BigClown vám k tomu nabídne alespoň některé vhodné komponenty (ATSHA, TRNG). Ale to je až ta třetí cesta. Obdobné systémy nabízí hardware s knihovnami, a zabezpečení se řeší až volitelně jako nadstavba, na kterou musí vývojář myslet a věnovat jí pozornost a trochu úsilí. My jdeme cestou, kde zabezpečení je standardní součástí, ať už výchozího firmware, nebo knihoven ze SDK, a vývojář musí naopak věnovat úsilí tomu, pokud se chce zabezpečenému přenosu dat vyhnout.

Věříme, že tento přístup, tedy “šifrování a autentizace by default”, přispěje k tomu, že se vývojáři naučí tuto oblast nepodceňovat, nenechávat zabezpečení “na potom” nebo ho úplně vypouštět, protože jim chybí čas nebo potřebné znalosti.