Czy można pobrać programy załadowane na płytkę NodeMCU?

13

Korzystam z karty NodeMCU z funkcją WiFi, aby zbudować prosty moduł do śledzenia zasobów. Udało mi się znaleźć kilka szkiców Arduino, które umożliwiają łączność z Centrum IoT Azure i wysyłanie wiadomości.

Jednym z kluczy, które muszę „załadować” na płytę, jest ciąg połączenia urządzenia Azure i oczywiście identyfikator SSID i hasło WiFi.

Obawiam się, że ktoś może po prostu wziąć zarząd i „pobrać” pliki, aby uzyskać dostęp do poświadczeń bezpieczeństwa.

Czy mój strach jest nieuzasadniony, czy utrata danych uwierzytelniających jest realnym zagrożeniem, które muszę złagodzić?

security barany
źródło
3
Myślę, że odpowiedzi @Mike Ounsworth i Bence Kaulics razem dają mi przyzwoitą opcję. Niestety nie mogę zaznaczyć obu jako zaakceptowanych odpowiedzi.
baranów

Odpowiedzi:

12

[zrzeczenie się: Jestem specjalistą od bezpieczeństwa / kryptografii i codziennie zajmuję się takimi pytaniami dotyczącymi architektury bezpieczeństwa.]

Natknąłeś się na problem przechowywania poświadczeń w taki sposób, że dostęp do nich może uzyskać nienadzorowany proces, ale osoba atakująca nie może. Jest to dobrze znany i bardzo trudny problem do rozwiązania.

Jeśli twoje urządzenie IoT ma wbudowany w płytę główną sprzętowy magazyn kluczy, taki jak niektóre moduły TPM, lub odpowiednik magazynu kluczy wspieranego przez system Android lub Apple Secure Enclave, możesz go użyć.

Z tradycyjnymi serwerami można korzystać z HSM lub kart inteligentnych, ale jedynym pełnym oprogramowaniem, o którym wiem, jest uzyskanie klucza AES z pewnego rodzaju „sprzętowego odcisku palca” zbudowanego przez połączenie numerów seryjnych wszystkich urządzeń. Następnie użyj tego klucza AES do zaszyfrowania poświadczeń. Proces działający na tym samym serwerze może zrekonstruować klucz AES i odszyfrować poświadczenia, ale po wyodrębnieniu pliku z serwera nie można go odszyfrować.

IoT wrzuca do tego klucz z dwóch powodów:

  1. Założenie, że numery seryjne sprzętu są unikalne, prawdopodobnie nie ma zastosowania, i

  2. W przeciwieństwie do serwerów, osoby atakujące mają fizyczny dostęp do urządzenia, dlatego prawdopodobnie mogą uzyskać powłokę na urządzeniu, aby uruchomić program deszyfrujący.

Zarówno szyfrowanie sprzętowe (TPM), jak i szyfrowanie „sprzętowego odcisku palca” są co najwyżej zaciemniające, ponieważ zasadniczo, jeśli proces lokalny może odszyfrować dane, osoba atakująca, która może uruchomić ten proces lokalny, może go również odszyfrować.

Wygląda więc na to, że standardowa sztuczka tutaj nie działa. Pierwsze pytanie, które musisz sobie zadać, to:

  • Jaki jest mój model zagrożenia / gdzie ten projekt znajduje się na Secure <--> Convenientskali?

Ostatecznie myślę, że musisz albo zdecydować o tym security > conveniencei poprosić człowieka o wprowadzenie poświadczeń po każdym uruchomieniu (używając czegoś takiego jak odpowiedź @ BenceKaulics ), lub zdecydujesz o tym security < conveniencei po prostu umieścisz poświadczenia na urządzeniu, być może używając jakiegoś zaciemnienia, jeśli czuję, że to robi różnicę.

Jest to trudny problem, utrudniony przez naturę urządzeń IoT.

Dla kompletności pełne rozwiązanie przemysłowe tego problemu to:

  • Daj każdemu urządzeniu IoT unikalny klucz publiczny RSA w czasie produkcji. Zapisz ten klucz publiczny w db względem numeru seryjnego urządzenia.
  • Przechowuj poufne dane uwierzytelniające na odpowiednim serwerze, nazwijmy to „bramą”.
  • Gdy urządzenie IoT uwierzytelnia się w bramie (przy użyciu klucza RSA), brama otwiera dla niego sesję przy użyciu przechowywanych poświadczeń i przekazuje token sesji z powrotem do urządzenia.
  • Dla najlepszego bezpieczeństwa brama jest bramą fizyczną (lub VPN), dzięki czemu cały ruch z urządzenia IoT przechodzi przez bramę i masz większą kontrolę nad regułami zapory i tym podobne - idealnie zapobiegając bezpośredniemu urządzeniu (tunelowanemu bez VPN) dostęp do Internetu.

W ten sposób atakujący, który naruszy urządzenie, może otworzyć sesję, ale nigdy nie ma bezpośredniego dostępu do poświadczeń.

Mike Ounsworth
źródło
2
Tak. Dużą część problemu stanowi to, że próbuje się tutaj chronić wspólny sekret, którym jest hasło do Wi-Fi. Wspólne sekrety to zły pomysł, kiedy urządzenie można fizycznie rozdzielić na części. Lepszy projekt podzieliłby każde wystąpienie urządzenia (lub innego komputera) na własne środowisko bezpieczeństwa z wyjątkowo bezpiecznym kanałem między poszczególnymi gadżetami a systemami, z którymi muszą się komunikować. W tym przypadku Wi-Fi może i tak nie pasować do aplikacji w porównaniu z jakimś schematem 2,4 GHz punkt-punkt lub nawet protokołem „Esp Now”.
Chris Stratton,
1
Słuszna uwaga. Możesz rozwiązać wspólny tajny problem, używając certyfikatów klienta korporacyjnego WPA2 zamiast hasła SSID (jeśli urządzenie IoT jest wystarczająco duże, aby mieć stos TLS, wiele z nich nie jest). Nic nie wiem o Azure IoT Hub, ale zakładam, że te parametry połączenia urządzenia Azure są już unikatowe dla każdego urządzenia. Niestety wydaje się, że jest to dość czysty czarno-biały między „Zrób to sam bez zabezpieczeń” i „Bezpieczeństwo na skalę przemysłową”, a niewiele między nimi.
Mike Ounsworth,
2
Zastanawiam się, czy jeśli mogę otworzyć sesję do woli, dlaczego potrzebuję poświadczeń?
Andrew Savinykh,
1
@AndrewSavinykh Zależy od poświadczeń. Może wszystko, co robią, to otwarta sesja, w którym to przypadku nie ma żadnego powodu. Ale może są to poświadczenia AD domeny Windows lub dają dostęp do dodatkowych interfejsów API, które zwykle nie są używane / dostępne z urządzenia IoT. Być może nie masz nic przeciwko sesjom pochodzącym z zainfekowanych urządzeń, ale nie jesteś zadowolony z sesji pochodzących z laptopów atakujących. Tak, dość szybko staje się specyficzny dla konkretnego przypadku.
Mike Ounsworth,
3
Numer seryjny??? Znalezienie unikalnego numeru seryjnego nie powinno stanowić problemu, ale numery seryjne nie są tajne. Są bezużyteczne, aby utworzyć klucz. Gdzie, u licha, numery seryjne tworzą kluczową „sztuczkę”?
Gilles „SO- przestań być zły”
6

Zagrożenie jest realne, ale na szczęście to nie ty jesteś pierwszy, czy tylko ten, który ma obawy związane z bezpieczeństwem.

Potrzebny jest tutaj ESP WiFi Manager .

Dzięki tej bibliotece ESP, który nie ma zapisanej sesji, przełączy się w tryb AP i będzie hostował portal internetowy. Jeśli połączysz się z tym AP za pomocą komputera lub smartfona, będziesz mógł skonfigurować dane uwierzytelniające WiFi za pośrednictwem strony internetowej.

Nie musisz kodować krytycznych informacji i możesz korzystać z urządzenia w dowolnej sieci Wi-Fi, którą chcesz, bez konieczności ponownego flashowania.

Jak to działa

  • po uruchomieniu ESP ustawia go w trybie stacji i próbuje połączyć się z wcześniej zapisanym punktem dostępu

  • jeśli to się nie powiedzie (lub żadna poprzednia sieć nie została zapisana), przenosi ESP do trybu Access Point i obraca DNS i WebServer (domyślnie ip 192.168.4.1)

  • za pomocą dowolnego urządzenia Wi-Fi z przeglądarką (komputer, telefon, tablet) połącz się z nowo utworzonym punktem dostępu

  • z powodu Captive Portal i serwera DNS pojawi się wyskakujące okienko typu „Dołącz do sieci” lub dowolna domena, do której próbujesz uzyskać dostęp, zostanie przekierowana do portalu konfiguracji

  • wybierz jeden z zeskanowanych punktów dostępu, wprowadź hasło, kliknij zapisz

  • ESP spróbuje się połączyć. Jeśli się powiedzie, rezygnuje z kontroli nad aplikacją. Jeśli nie, podłącz ponownie do AP i ponownie skonfiguruj.

(Dokumentacja ESP WiFi Manager)

Bence Kaulics
źródło
1
Lub po prostu pobierz rekordy lub cokolwiek, gdy jest w trybie AP. Mam nadzieję, że plakat nie próbuje użyć samego Wi-Fi do śledzenia zasobów.
Chris Stratton
1
@ChrisStratton :-) Właściwie próbuję użyć Wi-Fi do śledzenia zasobów. Na szczęście sieć WiFI, z której korzystam, jest publiczna i otwarta, ale martwię się konsekwencjami, gdy muszę użyć innej, która potrzebuje hasła. Również fakt, że parametry połączenia usługi AzureIoT Hub znajdują się na urządzeniu.
taranuje
2
@rams Z pewnością odczyt EEPROM urządzenia nie byłby dużym zadaniem.
Bence Kaulics,
3
@rams Na twoim sprzęcie tak EPROM można odczytać. Nowsze urządzenia mogą mieć pewne bezpieczne regiony pamięci flash, które są lepiej chronione. Z pewnością jest to znany problem, który wymaga wsparcia na chipie, aby spróbować zrobić to poprawnie.
Sean Houlihane,
2
@SeanHoulihane - ESP8266 nie ma pamięci EEPROM. Flash SPI, którego używa do wszystkiego (w tym do emulacji funkcji Arduino), jest zewnętrzny w stosunku do ESP8266. Nawet w module wieloukładowym jest to wyraźna kostka, którą można sondować w przyzwoitym laboratorium.
Chris Stratton,
3

Tak, mogą uzyskać dostęp do Twojego hasła, jeśli pozostawisz go jako zwykły tekst.

Zaletą jest to, że wiele interfejsów połączeń Wi-Fi akceptuje zaszyfrowane hasła. Chociaż te, których użyłem, zaakceptowały skróty md5, a md5 nie jest super bezpieczne, wciąż jest to bardzo trudne wyzwanie dla przeciętnego Joe. W zależności od pliku konfiguracyjnego albo podajesz nazwę algorytmu haszującego, a następnie piszesz hasło lub używasz domyślnego interfejsu Wi-Fi.

atakanyenel
źródło
3
Czy mogą wyodrębnić hashowane hasło, które działa, a co uniemożliwia im korzystanie z niego bez cofania go?
Chris Stratton,
1
@ChrisStratton masz rację. W jaki sposób można temu zapobiec w przypadku Information Security SE, pytanie to dotyczy zapobiegania utracie poświadczeń. Niemniej jednak hashowane hasła nadal nie mogą być używane przez telefony komórkowe do łączenia się z siecią bez dodatkowego oprogramowania.
atakanyenel
1
Tak, w rzeczywistości zapewniłoby to pewną ochronę w przypadku ponownego użycia hasła Wi-Fi w innym systemie, ale niewiele przed nieautoryzowanym połączeniem z tym punktem dostępu Wi-Fi.
Chris Stratton,
1
@ChrisStratton tak, na przykład biała lista adresów MAC jest znacznie bezpieczniejsza niż samo posiadanie hasła i mieszanie go, ale te kroki są ogólnie dla bezpieczeństwa Wi-Fi, a nie dla prywatności poświadczeń na urządzeniach publicznych.
atakanyenel
2
Nie, biała lista MAC to żart - nie ma w tym żadnej tajemnicy . I oczywiście MAC można łatwo wyodrębnić ze skradzionego ESP8266 lub jego pamięci flash SPI. Jedyne miejsce, w którym biała lista adresów MAC pomogłoby, to przeciwko osobom, które używają GUI do łączenia się z sieciami Wi-Fi lub jeśli punkt dostępu tam czekał na połączenie od klienta, który może się kiedyś pojawić, ale nigdy się z nim nie łączył - tj. , miecz w kamieniu.
Chris Stratton,
1

Prosta odpowiedź - TAK. To może być zrobione. Musisz przynajmniej wykonać jakiś rodzaj zaciemnienia, aby zapewnić minimalną ochronę.

Amit Vujic
źródło
1
Zaciemnianie utrudnia ustalenie sposobu działania urządzenia, ale ochrona przed klonowaniem urządzenia jest bezużyteczna . Nie ma sensu chronić przed wyodrębnieniem poświadczeń: wystarczy uruchomić oprogramowanie układowe w emulatorze.
Gilles „SO- przestań być zły”
Kompletnie się zgadzam. Moją motywacją było udzielenie takiej odpowiedzi, aby zauważyć, że <bezpieczeństwo sieci IoT należy wziąć pod uwagę>. @Mike Ounsworth udzielił szczegółowej odpowiedzi sugerującej rozwiązania wykorzystujące infrastrukturę AES i / lub RSA. Zastanawiam się nad udzieleniem jeszcze jednej odpowiedzi, ale nie jestem pewien, jak pójść do kryptografii (jestem również od wielu lat w rozwiązaniach płatniczych i bankowych). Myślę, że musimy udzielić praktycznych / zrównoważonych porad, ponieważ zwykle ludzie unikają zagłębiania się w kryptografię, aby chronić urządzenia IoT na swoim podwórku.
Amit Vujic
1
Jeśli ludzie chcą tworzyć niezabezpieczone urządzenia, ponieważ nie mogą zadać sobie trudu, aby dowiedzieć się, jak zrobić bezpieczne urządzenie, nie widzę powodu, aby je włączyć.
Gilles „SO- przestań być zły”
Z mojego doświadczenia wynika, że ​​ludzie chcą się uczyć, ale znowu musi istnieć równowaga między poziomem bezpieczeństwa a złożonością. W branży płatniczej istnieje znana historia dotycząca SET ( en.wikipedia.org/wiki/Secure_Electronic_Transaction ), która jest / była bardzo bezpieczna, ale złożona do wdrożenia i z tego powodu zawiodła w praktyce.
Amit Vujic
2
Zaciemnianie dodaje złożoności bez poprawy bezpieczeństwa. To nie jest równowaga.
Gilles „SO- przestań być zły”