Názory k článku BigClown: bezpečnostní koncepce v IoT
-
JardaH (neregistrovaný)
Tohle by mělo být vytesáno do HTML nad každým formulářem diskuzního příspěvku, protože podobnými rozumbrady se root jen hemží...
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.
-
Neplac (neregistrovaný)
Ale no neplac. Oni trosku podrazdene reaguju na komentare v diskusiach kde im par ludi pekne vysvetlilo a teraz sa to potvrdzuje ze ta bezpecnost stoji s ich strany za h.vno.(energeticky narocna a viac menej prekonane sifrovanie s xyz slepymi ( ved to nie je nas problem ale problem napr. linuxovej distribucie wtf ?) miestamy... proklamacia) Cele je to take viac ako kostrbate. Ale na druhej strane sa im aj cudujem
-
ebik (neregistrovaný)
Resi se nejak moznost utoku na zjisteni obsahu zpravy tim, ze zmenim cast, nad kterou mam jako utocnik kontrolu? Priklad realneho problemu je komprese hlavicek spolu s telem v https - pokud jako utocnik vlozim cookie a pak hlidam delku zpravy (treba POSTu s heslem uzivatele), tak pokud jsem heslo uhodnul, tak bude delka kratsi, nez kdyz heslo neuhodnu, protoze dve stejna slova se zkomprimuji vice nez dve ruzna. (S heslem je ten priklad pritazeny za vlasy, ale pokud mam treba hadat nejake sessionid pevne delky, tak uz je to o trochu realnejsi.) Zajimalo by mne, zda ten protokol se podobnym utokum brani (protoze zjevne komprimuje a pak sifruje), nebo zda jsou prenasene zpravy tak dobre popsane, ze lze vyloucit to, ze takovy utok zpusobi realnou skodu.
-
Komprimaci uplatňujeme jen na payload a komprimujeme na základě znalosti struktury a obsahu JSON zpráv - tedy na aplikační vrstvě, nekomprimujeme servisní data nižších vrstev (protože tam komprimace obecným kompersním algoritmem není efektivní).
Autentizaci máme jednu jednu na úrovni zprávy v transportní vrstvě (netaháme ji do aplikační vrstvy jako např. HTTP/S s hesly).
Paket je autentizován AUTH, autentizace zahrnuje relevantní část link+network vrstvy, kde je i délka paketu. I když link+network hlavičky nejsou šifrované (aby je mohl zpracovat čip rádia), jsou autentizované a tedy pokud někdo změní změní, rozpoznáme a adekvátně zpracujeme. Využíváme výhodu designu OCB-AES, který umí autentizovat dohromady s šifrovanými daty i část nešifrovaných dat.
Zároveň s nešifrovanou částí, časováním vysílání a dalšími vlastnostmi vznikají postranní kanály, kterých jsme si vědomi, ale jejich odstraňování je energeticky náročné - např. doplňování všech paketů na stejnou délku (útočník pak není schopen hádat typ zprávy podle délky) nebo náhodné posílání paketů (útočník má obtížnější najít "non-fake" pakety - problém hledání jehly v kupce sena). Předpokládáme doplnění a volitelnou aktivaci obranných mechanismů v budoucích verzích protokolu. -
abc (neregistrovaný)
Mam dve (hloupe) otazky:
1) Proc jste zvolili zrovna pasmo 868MHZ a ne 433MHz? Nizsi frekvecne by se mela prece mnohem lepe sirit skrz prekazky. Je to kvuli zaruseni na 433MHz?
2) Proc Nody periodicky vymenuji AES klice? Bylo by mozne, podobne jako u WEP na WiFi rekonstruovat heslo, pokud se klic pouzival treba rok beze zmeny?
-
1) Je několik důvodů. Přechod z 433 na 868 je v EU doporučen. Na 868 MHz lze vysílat vyšším výkonem, 868 má i větší dosah, v tomto pásmu je menší zarušení, a v neposlední řadě jsou antény pro 868 MHz menší. (K tématu např. https://www.tssgroup.cz/item/jaky-je-rozdil-mezi-pouzitim-frekvence-433mhz-a-868-mhz-/)
2) Ony je, přesněji řečeno, "obměňují". Jejich obměna by měla probíhat co nejčastěji. Pokud by se delší dobu komunikovalo s jedním klíčem, otevírá se tak prostor k různým útokům, včetně brute force.
-
Varel (neregistrovaný)
Je skutečně tak náročné porozumět psanému textu ? V úvodu celého seriálu a i v pokračováních je zmíněno že projekt je ve stádiu vývoje, já docela chápu že nechtějí uvolňovat různé alfaverze. Uvolnění komunitě má být někdy na podzim pokud se nepletu (někde už to bylo zmíněno) ...
-
Microsoft taky bude open ... (neregistrovaný)
Nu, takze nejse o prazdny hype od _JABLOTRONU_ ?
Udajne _pry_ bude mit tato historii potvrzena svine "otevrenou divizi".
Vse je predstavovano na urovni spekulaci (nic nevime jiste, takhle si to predstavujeme).
Nez prejdou od slibu k cinum, jde jen o reklamni sliby (je nam lito, nepujde to, koho zaujal koncept ...).
-
Uhrovity mladik (neregistrovaný)
Ale on ma pravdu ! Ak sa teda chcu hrat na to ze aha sme open-source a nieco predstavovat tak nech to teda zverejnia. Toto je cele take aha tu mate serial o IoT o genialnej veci ktora je uplne lacna (nikto este nevie cenu lebo vlastne nic nevyrobilz) je open source ( aj ked ziadne kody ani navrhy PCB ani nic vlastne nie je verejne lebo je to este velmy Alfa) ale na druhej strane su si isty ze je to dobre, prinosne, efektne a neviem co a to cele pod hlavickou Jablotronu o firme o ktorej vie kazdy svoje...
Nemaly poton pisat radsej vobec nic a pockat do jesene - zimy do doby nez maju aspon nieco co sa da naozaj ochytat (nie prototyp u vas v labaku ktory mozete chytit do ruky tak vy a vas kolega je zatial naozaj este nic) a nie len kecy a este sa tu idete rozculovat co si to ty hlupi ludia len dovolia kritizovat nieco o com nemaju ani len potuchy - ale aby som im nieco na "osahanie" dal tak na to je skoro..... To uz ten clanok minule o tej carovnej Microsoft IOT hracke mal aspon to + ze sa jednalo o produkt ktory sa da naozaj kupit.
Kakaju si do ust..
-
MarSik (neregistrovaný)
U velkého množství open source projektů se dodržuje "Release early, release often". Chápu, že třeba Turris nebo BigClown se tím neřídí (číňané jsou rychlí), nicméně pokud z toho neplánují moc velký zisk (a při těch naznačených cenách asi neplánují..), tak by s tím nemuseli mít problém. Naopak by mohli přilákat lidi s věcnými a korektními poznámkami. Těžko se ale dá o něčem diskutovat, když nezveřejnili žádná detailní fakta (známe ideu a některé použité komponenty.. ale to nestačí).
ČLÁNKY DO MAILU