Vlákno názorů k článku BigClown: bezpečnostní koncepce v IoT od ebik - Resi se nejak moznost utoku na zjisteni obsahu...
-
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.
