Do czego jest układ kryptograficzny w Arduino?

[Elvis]

I to brzmi jak sensowne wytłumaczenie zastosowania ECC. Tylko ciekawe jak zareaguja użytkownicy na takie podejście.

[Treker (Damian Szymański)]

Pytanie (równie ważne) czy Chińczycy mają zamiar kopiować te płytki, bo jakoś do tej pory nie widziałem klonów MKR.

[Elvis]

Podobno skopiowanie ECC jak na razie jest niemożliwe. Te same układy sa używane przez Apple i innych dużych graczy. Więc nawet jeśli skopiuja to nie w 100% jak obecnie

[Treker (Damian Szymański)]

Zgadza się, ale na razie ewidentnie nie widać jeszcze przewagi tego, że Arduino programuje(?) jakoś swoje ECC. Więc aktualnie wyprodukowane klony działałyby tak samo, płytki są dostępne już dość długo, a klonów brak 😉

[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

[Harnas]

Jeszcze może chodzić o możliwość jednoznacznej identyfikacji płytki. Niby można identyfikować po adresie MAC albo jakimś UID (STM32 maja wbudowany taki) ale jeśli ktoś zdobędzie protokół komunikacji to będzie mógł podszyć się pod dowolne urządzenie. A tak za 0.5$ każde urządzenie ma swój unikalny numer seryjny zabezpieczony kryptografią asymetryczną.

[Treker (Damian Szymański)]

Tylko pytanie do czego taka jednoznaczna identyfikacja jest potrzebna, a właściwie "dla kogo"? Czy dla Arduino, które chce walczyć z klonami lub dopuszczać do swojej infrastruktury tylko oryginalne płytki, czy dla użytkowników, którzy mają wykorzystywać to w swoich projektach. Oczywiście obie wersje mogą być prawdziwe, ale z drugiej strony odsetek użytkowników, który z tego skorzysta jest pewnie mały. Szczególnie, że oficjalna biblioteka wiele nie wspiera, bo tylko generowanie liczb losowych.

14 godzin temu, Elvis napisał:

Ten układ ma własną pamięć (nieulotną), która może być zapisana przez producenta. Układ może nawet zliczać liczbę uruchomień i odmówić np. autoryzacji po przekroczeniu limitu. Poza tym jeśli raz został zapisany, nie daje już użytkownikowi pełnej kontroli - ma ją producent / Arduino

To może najlepszym testem byłoby teraz sprawdzenie czy ten układ jest zapisany i "zablokowany" przez producenta?

[sebas86]

Dla mnie to naturalny krok i wręcz niezbędny element dla rozwiązań IoT. Nawet zwykły czujnik temperatury czy ruchu powinien szyfrować komunikację z centralką żeby nie dawać fajnego narzędzia choćby dla włamywaczy... Samo szyfrowanie wbudowane w protokół to trochę mało, niestety nie jestem eskeprtem od bezpieczeństwa więc nie będę rzucał przykładami ale... na popularnych portalach zajmujących się tą tematyką można było poczytać o podatnościach w implementacji WiFi.

Druga sprawa to taki silnik szyfrujący i miejsce do przechowywania kluczy przydałby się już dawno dla bardziej wymagających użytkowników projektujących urządzenia odporne na piractwo. Procesory AVR miały co prawda opcję zabezpieczenia fuse bitami ale to jest mechanizm chroniący tylko przed odczytem, problematyczna staje się implementacja bezpiecznego mechanizmu aktualizacji.

No i trzecia sprawa, teoretycznie są biblioteki pełniące tą samą rolę ale zabierają one cenną przestrzeń mikrokontrolera i znacznie obciążają go obliczeniowo, tym bardziej, że spory odsetek mikrokontrolerów nie ma instrukcji sprzętowych przyspieszających tego typu obliczenia.

Edytowano Styczeń 27, 2019 przez sebas86

[deshipu]

2 godziny temu, sebas86 napisał:

Nawet zwykły czujnik temperatury czy ruchu powinien szyfrować komunikację z centralką żeby nie dawać fajnego narzędzia choćby dla włamywaczy...

A to jest bardzo ciekawe. Znasz jakieś czujniki, które to robią?

Mógłbyś podać jakiś scenariusz w którym włamywacz uzyskuje dostęp do czegokolwiek (poza temperaturą) rozszyfrowując sygnał z czujnika temperatury?

[piotrva]

Hmm, choćby włamywacz podszywa się za czujnik i wysyła że mamy cały czas temperaturę 0 - przez to ogrzewanie grzeje na maska i cóż...

Co do samego chipu - można na razie tylko spekulować, czy to nowy feature i udogodnienia dla użytkownika wraz z możliwością dodatkowego zabezpieczenia się, czy tez rzeczywiście krok w stronę ukrócenia rynku klonów.

Szczerze nie dziwiłbym się, gdyby tak było jeśli chodziłoby o rozwiązania chmurowe - kupujesz nasz produkt - korzystaj. Kupujesz klona - radź sobie sam.

Przykładem na to, że zapomniano o tym może być sprawa analizatorów stanów logicznych: Saleae i USBee - są one obecnie klonowane na potęgę, firmy, które zrobiły dobry soft (w szczególności Saleae) nie mają z tego dochodu (a ruch na ich stronach w związku np. z pobieraniem softu jest generowany => ponoszą koszty). Nie mają tez jak zablokować klonów, bo są nie od odróżnienia od oryginałów... 

[Elvis]

Jak chodzi o układ ECC, to jego funkcjonalność odpowiada karcie SIM w telefonie. Więc może formuując nieco inaczej pytanie z tego tematu - czy gdyby Arduino w nowych modelach zacząło montować gniazda dla kart SIM oraz wydawać same karty to byloby to fajne, czy niepokojące?

Natomiast w kwestii szyfrowania i bezpieczeństwa to nie jest tak, że moduł ECC (lub karta SIM) jest niezbędny. Zacznijmy od początku - obecnie większość (czyli pewnie wszystkie) projekty tworzone na Arduino nie ma żadnych zabezpieczeń. Dane są przesyłane otwartym tekstem, a sam kod w mikrokontrolerze możliwy do odczytu i nie zabezpieczony w żaden sposób. Wbrew pozorom takie podejście znajdziemy też w wielu komercyjnych urządzeniach.

Jednak w przypadku urządzeń produkcyjnych, taka pełna niefrasobliwość zdarza się już coraz rzadzej. Pierwsze co producenci starają się ochraniać, to kod programu. Aby uniemożliwić odczyt kodu z pamięci Flash używane są fusebity lub podobne metody. Dzięki nim po wgraniu programu można zablokować jego (prostą) modyfikację. 

Kolejną rzeczą są protokoły używane do komunikacji między urządzeniami. Tutaj o ile wiem jest znacznie gorzej i dobrych rozwiązań wcale łatwo nie znajdziemy. Niektóre protokoły radiowe jak np. BLE, czy ZigBee mają, albo chociaż starają się mieć wbudowane mechanizmy uwierzytelniania i ochrony danych. Jednak często projektanci urządzeń chronią jedynie kod, a dane traktują jako nieistotne.

Warto dodać, że do szyfrowania komunikacji wystarczy założenie o tajności kodu w pamięci flash. Jeśli tego kodu nie można odczytać, możemy klucze kryptograficzne zapisać w kodzie programu i mamy ochronę komunikacji - to można zrobić nawet na AVR i Arduino. Może warto kiedyś będzie taki artykuł napisać?

 

Problem pojawia się jeśli zastanowimy się, czy na pewno wypalenie fusebitów daje 100% zabezpieczenia. W domowym warsztacie takiego kodu nie odczytamy, ale jeśli mamy pod ręką mikroskop (elektronowy) oraz odpowiednie sondy, okazuje się że pamięć flash można nadal odczytać. Brzmi to jak powieść science-fiction? Może i tak, ale jeśli odczytamy jeden układ, to mamy dostęp do wszystkich danego producenta. Co więcej nie musimy kupować sprzętu - są firmy, które taką "usługę" wykonują...

Jeśli chcemy się zabezpieczyć i przed takim atakiem, musimy mocno przemyśleć projekt naszego urządzenia - zarówno programowy, jak i sprzętowy. Pod względem sprzętowym znajdziemy specjalne modele mikrokontrolerów, Atmel jest (albo raczej był) mocnym graczem w tym segmencie. Nowe mikrokontrolery serii L10 oraz L11 są warte uwagi jeśli interesuje nas wyższy poziom bezpieczeństwa. Nieco większe układy z rodziny SAMA5D2 mają specjalne modele zaprojektowane właśnie do takich zastosowań.

Natomiast jeśli nie chcemy i nie potrzebujemy specjalnych procesorów, możemy użyć układu kryptograficznego, tzw. secure-element, jak wspomniany ECC, albo karta SIM. Jednak samo wyjęcie bezpiecznego układu i dodanie do płytki nie daje bezpieczeństwa. To ciekawe, chociaż czasem skomplikowane i raczej nie przeznaczone dla tego samego segmentu rynku co Arduino.

Podsumowując - nie istnieje 100% bezpieczeństwo, ale jego poziom musimy dobrać do ważności ochranianych danych. ECC daje możliwość zabezpieczenia układu na znacznie wyższym poziomie niż typowe, spotykane na rynku rozwiązania. To jednak może wskazywać, że nie jest to narzędzie dla nas, czyli użytkowników Arduino, ale jego producenta...

I jeszcze dwa słowa o "nieistotnych" danych przesyłanych przez nasz termometr. Podejście "to nieważne" jest typowe i bardzo ułatwia życie hackerowi. Załóżmy więc że BadElvis chce włamać się do Waszego systemu i domu zarazem, a na początek ma dostęp do niezaszyfrowanego protokołu danych z termometru.

Pierwsze co może zrobić to podłączyć sniffer i zbierać dane. Niby nic ciekawego - głupia temperatura. Ale jeśli to temperatura w domu, to można na jej podstawie dużo dowiedzieć się o aktywności domowników. Kiedy chodzą spać, kiedy wstają, na jak długo wychodzą z domu. W dłuższym czasie danych jest jeszcze więcej - czy w weekendy siedzicie w domu, a cały tydzień dom stoi pusty w środku dnia itd...

To pierwszy etap, dalej BadElvis może przejść do kolejnej fazy ataku i zacząć zmieniać dane. To znowu głupia temperatura, ale skoro już wie że np. w środku dnia jesteście w pracy, może zrobić ciekawy test - co się stanie jeśli wywoła wówczas alarm. Przyjedziecie natychmiast? A może pojawi się ochrona? itd. To już dużo więcej ciekawych danych niż tylko temperatura.

Skoro raz udało się wywołać alarm, można to zrobić ponownie - sprawdzić kiedy i jak szybko reagujecie. Co więcej po kilku fałszywych alarmach i sprawdzeniu instalacji pewnie przestaniecie na alarmy reagować.

Przy okazji zły hacker może próbować zaatakować Wasze oprogramowanie. Bo co się stanie jeśli np. wyślemy pakiet z temperaturą 0xffffffff. Może programista Arduino nie sprawdził takiej wartości i np. cały system się zawiesi - wtedy mamy już nie tylko kontrolę nad temperaturą. Co będzie jeśli zasypiemy odbiornik pakietami - poprawnymi, a może złymi. Czy nie przepełni się żaden bufor?

Innymi słowy - nawet mając tylko termometr BadElvis, może sporo namieszać. Jeśli poczytacie opisy łamania zabezpieczeń zobaczycie podobny schemat - często zaczyna się od zupełnie nieistotnej podatności, której istnienie projektanci zignorowali. A odpowiednio zawzięty hacker wykorzystuje i rozszerza swoje uprawnienia stopniowo.

Na koniec drobna uwaga - pisałem o zwykłym termomentrze, a o ile więcej można zrobić jeśli macie niezabezpieczoną centralkę z Domoticzem na pokładzie, albo wszystkie swoje dane przesyłacie na serwer w Chinach... To tak do przemyślenia, chociaż może i dyskusji 🙂

 

Edytowano Styczeń 28, 2019 przez Elvis

[Treker (Damian Szymański)]

12 godzin temu, deshipu napisał:

Mógłbyś podać jakiś scenariusz w którym włamywacz uzyskuje dostęp do czegokolwiek (poza temperaturą) rozszyfrowując sygnał z czujnika temperatury?

Ktoś już to testował. Tutaj przez termometr w akwarium włamano się do bazy danych kasyna: https://www.businessinsider.de/hackers-stole-a-casinos-database-through-a-thermometer-in-the-lobby-fish-tank-2018-4?r=UK&IR=T 😉

[deshipu]

13 godzin temu, piotrva napisał:

Hmm, choćby włamywacz podszywa się za czujnik i wysyła że mamy cały czas temperaturę 0 - przez to ogrzewanie grzeje na maska i cóż...

I co "cóż"? Możesz dokończyć? Bo nadal nie rozumiem co z tego ma włamywacz.

[Treker (Damian Szymański)]

3 minuty temu, deshipu napisał:

I co "cóż"? Możesz dokończyć? Bo nadal nie rozumiem co z tego ma włamywacz.

Mocne grzanie i ruchy ciepłego powietrza mogą powodować fałszywe alarmy czujników PIR. Po serii XX fałszywych alarmów (przez kilka dni) pewnie tymczasowo nikt nie reagowałby błyskawicznie na kolejne alarmy - kilka minut dla złodzieja zaoszczędzone 😉

[ethanak]

Z ciągu wartości temperatura/czas możesz baaardzo dużo się dowiedzieć, włącznie z tym ile osób i o której wchodziło do danego pomieszczenia. Włamywaczowi takie informacje mogą byc potrzebne, aby wybrać optymalną porę dokonania włamania.

A z włączenia ogrzewania na maksa też można pewne korzyści wyciągnąć - np. jeśli pięć razy włączy się alarm mimo że nic się nie stało, to za szóstym razem strażnik najpierw dokończy kanapkę a dopiero później spojrzy w monitor.

(Treker był szybszy)

Edytowano Styczeń 28, 2019 przez ethanak

[deshipu]

3 minuty temu, Treker napisał:

Mocne grzanie i ruchy ciepłego powietrza mogą powodować fałszywe alarmy czujników PIR. Po serii XX fałszywych alarmów (przez kilka dni) pewnie tymczasowo nikt nie reagowałby błyskawicznie na kolejne alarmy - kilka minut dla złodzieja zaoszczędzone 😉

Nie no, jak ci się włączy alarm z powodu rozgrzania pomieszczenia, które miało być utrzymywane w stałej temperaturze, to chyba od razu się zorientujesz, że coś tu jest nie tak. Trudno jest nie zauważyć takiego drobnego detalu.

3 minuty temu, ethanak napisał:

Z ciągu wartości temperatura/czas możesz baaardzo dużo się dowiedzieć, włącznie z tym ile osób i o której wchodziło do danego pomieszczenia. Włamywaczowi takie informacje mogą byc potrzebne, aby wybrać optymalną porę dokonania włamania.

 

To jeszcze by ten włamywacz musiał przesyłać te dane jakoś do siebie, żeby móc z nich skorzystać. Czyli musi zainstalować własne urządzenie. Równie dobrze to jego urządzenie może mieć własne czujniki.