Zabezpieczenia w IoT. Czy każda komunikacja powinna być szyfrowana?

[piotrva]

Poniższy post został wydzielony jako początek nowej dyskusji z poniższego tematu:

-----------

Mówicie dużo, że szyfrowanie nieistotne itp. itd. Moim zdaniem lepiej wprowadzać szyfrowanie od najmniejszych układów. Bo potem dojdziemy: a po co szyfrować, to tylko żarówka. I jakiś domorosły idiota zrobi nam dyskotekę oświetleniem dla żartów.

Plus nie wiem czy widzieliście jak goście hakowali... sterowanie zdalne dźwigów i suwnic itp. Wyobraźcie sobie ile szkody (w tym na życiu ludzkim) może spowodować przejęcie kontroli nad czymś w hucie stali na przykład... A projektanci systemów też myśleli - po co szyfrowanie, przecież kto by się do tego włamywał - ma działać pewnie i tyle...

[deshipu]

1 godzinę temu, piotrva napisał:

Mówicie dużo, że szyfrowanie nieistotne itp. itd. Moim zdaniem lepiej wprowadzać szyfrowanie od najmniejszych układów. Bo potem dojdziemy: a po co szyfrować, to tylko żarówka. I jakiś domorosły idiota zrobi nam dyskotekę oświetleniem dla żartów.

Plus nie wiem czy widzieliście jak goście hakowali... sterowanie zdalne dźwigów i suwnic itp. Wyobraźcie sobie ile szkody (w tym na życiu ludzkim) może spowodować przejęcie kontroli nad czymś w hucie stali na przykład... A projektanci systemów też myśleli - po co szyfrowanie, przecież kto by się do tego włamywał - ma działać pewnie i tyle...

Wydaje mi się, że przedstawiasz tutaj fałszywy dylemat, zakładając że szyfrowanie to coś co tylko jest albo nie ma.

Chcesz robić szyfrowanie już przy najmniejszych układach? No to albo robisz to porządnie, i twój czujnik temperatury za 30 centów kosztuje teraz 30 dolarów i wymaga wykwalifikowanej obsługi z dostępem do kluczy prywatnych do instalacji, albo robisz to na odwal się i czujnik jest tylko 4 razy droższy i "drop in", ale za to każdy domorosły haker z 20 minutami wolnego czasu rozwala to szyfrowanie na swoim telefonie. No ale jest szyfrowanie, możesz wpisać w dokumentacji i odhaczyć.

No i teraz kupujesz tą żarówkę, czytasz że nie zrobili szyfrowania ani uwierzytelniania na poziomie protokołu i aplikacji, bo przecież każda jedna część już ma szyfrowanie, więc jest bezpiecznie. Dwa dni później masz dyskotekę.

Co gorsza, firma robiąca te suwnice ogłosiła przetarg i oczywiście wygrały czujniki tańsze. Zgadnij jakie mają szyfrowanie...

[Elvis]

Nie uważam żeby dodanie szyfrowania do kodu programu zwiększało koszt projektu stukrotnie. Ale zostawmy czujniki z wbudowanym szyfrowaniem, zajmijmy się protokołami komunikacji, najlepiej radiowej. Wiele projektów wygląda tak: mamy czujnik, Arduino i moduł radiowy np 433MHz. Pytanie, czy w takiej sytuacji szyfrowanie ma znaczenie, czy to tylko ekstrawagancja?

[deshipu]

Rozróżnijmy też szyfrowanie (mające uniemożliwić słuchającym odbiór nadawanych danych) od podpisu cyfrowego (mającego uniemożliwić sfałszowanie tych danych).

Edytowano Styczeń 28, 2019 przez deshipu

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Elvis]

Dobrze, więc przyjmujemy rozróżnienie między szyfrowaniem oraz podpisywaniem wiadomości. Przy okazji pamiętamy, że szyfrowanie wcale nie unimożliwia odbioru danych, jedynie sprawia, że bez znajomości klucza odczytanie informacji przekazywanej w odebranej wiadomości nie jest możliwe (albo jest wystarczająco trudne).

Edytowano Styczeń 28, 2019 przez Elvis

[piotrva]

@deshipu Mówię o stosownym szyfrowaniu, takim przy którym złamanie dla potencjalnego włamywacza będzie nieopłacalne.

Rozróżnijmy 2 produkty: a) czujnik temperatury bezprzewodowy do stacyjki pogodowej na biurko b) czujnik temperatury bezprzewodowy do sterowania ogrzewaniem CO
ten pierwszy mogę kupić za 2 dolary, może być bez szyfrowania, nie obchodzi mnie to bo co najwyżej zobaczę, że mi wyświetla milion stopni na zewnątrz (+ lub -) i stwierdzę, że do kitu. Ten drugi - mogę dać i 40$ - chcę coś niezawodnego.

i czy od razu muszę mieć skomplikowaną obsługę, etc? Można na prawdę wymianę takich kluczy zrobić transparentną dla użytkownika, albo jakieś jednoczesne wciśnięcie przycisku na centralce i czujniku (niby może ktoś wtedy podsłuchać radio), albo podpięcie jakiegoś kabelka na chwilę czy zrobienie tego samego ze specjalnie zmniejszoną mocą (pt. przyłóż antenkę jednego do drugiego i wciśnij guziki). Dla mnie żaden problem ze strony użytkownika, ze strony producenta - kwestia przemyślenia sprawy.

@Elvis moduły 433 MHz - tego nie powinni dopuścić do sprzedaży, widziałeś tego widmo? Ja dziś wyjąłem jeden i chcę zobaczyć jego widmo na nowym SDR, bo na RTL-SDR, którym kiedyś to chciałem zobaczyć widmo wyszło poza jego zakres 😜 I tu nie chcę nawet tego widzieć w jakimkolwiek urządzeniu, nie mówiąc o rozmyślaniu czy szyfrować dane czy nie. Aczkolwiek - szyfrować można 😉

Tak czy siak dyskusje można podsumować - szyfrować w aplikacjach krytycznych, w innych olać sprawę 😉

A wracając do dyskusji o tym chipie w Arduino - mi się wydaje, że czy to będzie do szyfrowania użyte, czy podpisywania wiadomości celem odmowy dostępu do chmury ludziom nie będącymi klientami - mają prawo tak zrobić, bo oni będą tę chmurę utrzymywać. Są takie moduły Particle: https://www.particle.io/cellular i tam u nich kupujesz abonament na transmisję danych i masz wtedy dostęp do ich chmury. Chcesz co innego? Wkładasz inna kartę SIM i bawisz się sam - są schematy dostępne i kody.

Tu mogłoby być podobnie - kupujesz naszą płytkę - korzystaj dożywotnio z chmury. Kupujesz klona? zobacz na źródła naszych serwerów chmurowych, postaw sobie na swoim serwerze i baw się dalej - ja bym przynajmniej tak zrobił 😉

[deshipu]

1 godzinę temu, piotrva napisał:

Rozróżnijmy 2 produkty: a) czujnik temperatury bezprzewodowy do stacyjki pogodowej na biurko b) czujnik temperatury bezprzewodowy do sterowania ogrzewaniem CO
ten pierwszy mogę kupić za 2 dolary, może być bez szyfrowania, nie obchodzi mnie to bo co najwyżej zobaczę, że mi wyświetla milion stopni na zewnątrz (+ lub -) i stwierdzę, że do kitu. Ten drugi - mogę dać i 40$ - chcę coś niezawodnego.

I dokładnie taką sytuację masz teraz. Tylko nie jest to $40 a $400, ale tak to już jest.

Ja generalnie myślałem jeszcze o c) czujnik temperatury przewodowy do sterowania czymkolwiek. Wiadomo, że jak masz już ten moduł radiowy, to masz i protokół i jakiś procesor do jego przetwarzania, więc tutaj rzeczywiście koszt dodania jakiegoś prymitywnego szyfrowania jest znikomy, jeśli nie obchodzą cię opóźnienia. (Inna sprawa, że każdy szyfr jaki taki kulawy procesorek jest w stanie w rozsądnym czasie policzyć jest do rozwalenia brute forcem w godzinę na komputerze z kartą graficzną.)

1 godzinę temu, piotrva napisał:

i czy od razu muszę mieć skomplikowaną obsługę, etc? Można na prawdę wymianę takich kluczy zrobić transparentną dla użytkownika, albo jakieś jednoczesne wciśnięcie przycisku na centralce i czujniku (niby może ktoś wtedy podsłuchać radio), albo podpięcie jakiegoś kabelka na chwilę czy zrobienie tego samego ze specjalnie zmniejszoną mocą (pt. przyłóż antenkę jednego do drugiego i wciśnij guziki). Dla mnie żaden problem ze strony użytkownika, ze strony producenta - kwestia przemyślenia sprawy.

Tak, niestety musisz. Możesz sobie poczytać o tym jakie są znane ataki na WPS przez to właśnie, że używa twojego pomysłu z guzikiem. Chcesz to mieć zrobione dobrze i niezawodnie, to użytkownik musi wiedzieć co robi i rozumieć jak to działa. Inaczej masz cargo cult i druidyzm, które kończą się zerowym bezpieczeństwem, niezależnie od zastosowanych środków technicznych.

Edytowano Styczeń 28, 2019 przez deshipu

[Elvis]

Jak chodzi o szyfrowanie, to nie piszmy bzdur. Jako mały mikrokontroler chyba nadaje się arduino. Tutaj sa wyniki prędkości użycia AES: https://forum.arduino.cc/index.php?topic=88890.0

skoro jest 20-30kB/s to krótki komunikat z np. wynikami pomiarów będzie szyfrowany w kilka ms. Są również dostępne mikrokontrolery ze sprzętowym aes-em i to za rozsądną cenę.

[deshipu]

Skoro możesz taki krótki komunikat zaszyfrować na Arduino w kilka ms, to na swoim komputerze zrobisz to znacznie szybciej. To znaczy, że możesz przelecieć wszystkie możliwości (komunikat jest krótki, więc nie będzie ich tak dużo) i zobaczyć która się szyfruje do tego samego.

[piotrva]

@deshipu o jakich 400$ mówisz? Przy masowej produkcji koszty porządnego protokołu szyfrowania będą znikome.

@Elvis Zapomnijmy o Arduino i AVR - one są woooooolne - taki np. STM32 bez problemu policzy sobie nawet RSA:

https://www.st.com/content/ccc/resource/technical/document/user_manual/34/1a/20/75/7f/84/45/cb/CD00208802.pdf/files/CD00208802.pdf/jcr:content/translations/en.CD00208802.pdf

I jakie 20-30kB na sekundę? Pomiar temperatury to jest... 4 bajty na pomiar, zakładając nawet jakiś overhead, adres, etc, powiedzmy 16 bajtów. Temperaturę musisz czytać co sekundę? wątpię - wystarczy raz na minutę 😉
Wiadomo są inne pomiary, ale raczej jak mamy wysoki update rate to i ni wymagamy życia na baterii przez lata -> można dać mocniejszy procesorek.

@deshipu to że komunikat krótki, nie oznacza, ze klucz jest krótki - wystarczy AES512 czy 1024 i KONIEC.

 

[deshipu]

Przed chwilą, piotrva napisał:

@deshipu o jakich 400$ mówisz? Przy masowej produkcji koszty porządnego protokołu szyfrowania będą znikome.

Ale rynek jest znacznie mniejszy, do tego dochodzi konieczność zatrudnienia ekspertów do zrobienia i do utrzymywania tego, no i do tego kłaniają się prawa rynku, które przy braku alternatyw mogą być bezlitosne.

[piotrva]

@deshipu Ale jakich ekspertów? Dajesz ludziom choćby podlinkowaną bibliotekę od ST do szyfrowania i po problemie. Ewentualnie każesz dołożyć scalaka szyfrującego, bierzesz do niego przykładowe kody i po problemie - na prawdę nie widzę powodu, aby średnio rozgarnięty inżynier nie poradził sobie ze zrobieniem czegoś takiego - ja parę lat temu, gdy moja wiedza była znikoma w tych dziedzinach postawiłem pełne szyfrowanie TLS na ESP8266 (TLS, czyli to samo na czym bazuje SSL/HTTPS). A był to bzdetny projekt nadajnika podczerwieni do zdalnego sterowania urządzeniami z dowolnymi protokołami IR.

[Elvis]

Mam wrażenie, że to kolejna dyskusja w której chodzi tylko o to żeby mieć ostatnie słowo. Jest niby trochę lepiej niż wczoraj, gdzie nawet kalendarzyki małżeńskie były w ruchu, ale poziom argumentów chyba niedługo się wyrówna.

Nie chce mi się kłócić i udowadniać, kto ma rację. Powiem tylko to co wiem - na małych mikrokontrolerach można stosować szyfrowanie, algorytmy symetryczne, jak chociażby 3DES, czy wspomniany AES spokojnie dają radę nawet na 8-bitowcach. Nowsze układy mają często sprzętowe wsparcie, jak chociażby niektóre STM32. Są nawet układy, które potrafią AES wykonywać "w locie", czyli każdy zapis i odczyt pamięci jest automatycznie szyfrowany.

Edit: Jeszcze nawiązując do tematu tego wątku - algorytmy szyfrowania symetrycznego są wystarczające zarówno do zapewnienia poufności jak i integralności przekazywanych informacji. Problematyczna jest za to wymiana klucza. Natomiast używanie układu ECC wcale nie jest konieczne. Stąd moim zdaniem Arduino coś knuje stosując wspomniany moduł. Chociaż to co koledzy napisali odnośnie chmury ma dla mnie sens, to metoda na wyeliminowanie używania klonów.

Edytowano Styczeń 28, 2019 przez Elvis

[Treker (Damian Szymański)]

19 minut temu, Elvis napisał:

Chociaż to co koledzy napisali odnośnie chmury ma dla mnie sens, to metoda na wyeliminowanie używania klonów.

Z jednej strony na wyeliminowanie klonów, ale z drugiej strony mogą one służyć do jednoznacznej identyfikacji płytek wpiętych do chmury. Bo to by było chyba dość wygodne rozwiązanie. Wpinasz do chmury i działa, nie musisz podawać ręcznie żadnych unikalnych ID itd., masz pewność, że nikt "przypadkiem" nie będzie się podszywał pod Twój układ. Czy źle myślę o tym mechanizmie? 

[deshipu]

3 godziny temu, piotrva napisał:

@deshipu Ale jakich ekspertów? Dajesz ludziom choćby podlinkowaną bibliotekę od ST do szyfrowania i po problemie. Ewentualnie każesz dołożyć scalaka szyfrującego, bierzesz do niego przykładowe kody i po problemie - na prawdę nie widzę powodu, aby średnio rozgarnięty inżynier nie poradził sobie ze zrobieniem czegoś takiego - ja parę lat temu, gdy moja wiedza była znikoma w tych dziedzinach postawiłem pełne szyfrowanie TLS na ESP8266 (TLS, czyli to samo na czym bazuje SSL/HTTPS). A był to bzdetny projekt nadajnika podczerwieni do zdalnego sterowania urządzeniami z dowolnymi protokołami IR.

To równie dobrze możesz to wszystko puszczać otwartym tekstem, będzie równie bezpieczne. Potrzebujesz ekspertów choćby po to, żeby ci powiedzieli że ten genialny system który z @Elvis wymyśliliście jest podatny na mnóstwo ataków, od dekodowania brute-force (bo nadajecie bardzo krótkie komunikaty, których treść daje się zgadnąć) do replay (można zwyczajnie nagrać sygnał takiego czujnika i go powtarzać w kółko i nikt się nie zorientuje). W przypadku tego twojego nieszczęsnego TLS ktoś się zatroszczył o te wszystkie szczegóły, choć oczywiście nie wątpię, że nie wiedząc o nich można to równie koncertowo spartolić i wcale bym się nie zdziwił, gdyby ten twój bzdetny projekt był jeszcze bardziej bzdetny niż ci się wydaje.

Kryptografia jest dziedziną trudną i delikatną i naprawdę trzeba się mocno zastanowić zanim zacznie się wprowadzać własne wynalazki. Zdecydowanie nie uważam, żeby pchanie jej wszędzie na siłę z zerową wiedzą było dobrym pomysłem.