Jak zabezpieczyć komunikację między aplikacją a urządzeniem IoT?

18

Obecnie pracuję nad projektem, który obejmuje komunikację Bluetooth między aplikacją mobilną (obecnie korzystającą z platformy Ionic) a urządzeniem wbudowanym. Dla porównania nasz produkt jest podobny do inteligentnego zamka .

Bezpieczeństwo jest sprawą najwyższej wagi, a my szukamy sposobów, aby zapewnić, że nasz sprzęt i oprogramowanie nie będą zhakowane. Jakie kroki powinniśmy podjąć, aby zapewnić bezpieczeństwo naszego systemu?

Edycja: Tak, obecnie szyfrujemy komunikację i używamy HTTPS, gdy urządzenie komunikuje się z naszym serwerem.

Joel Brewer
źródło
Używać HTTPS? Czy kodujesz oba urządzenia? Szyfrowanie
Mawg mówi o przywróceniu Moniki
1
Consiedr pyta również na security.stackexchange.com
Mawg mówi o przywróceniu Moniki
2
@Mawg O ile mi wiadomo HTTPS nie ma zastosowania do bluetooth (a przynajmniej nie w sensie normatywnym / rozsądnym).
goldilocks,
1
Głosuję za zamknięciem tego pytania jako nie na temat, ponieważ nie pokazuje to, w jaki sposób jest to specyficzne dla Internetu Rzeczy. To tylko zabezpieczenie komunikacji między urządzeniami.
Helmar
4
@Helmar Komunikacja między urządzeniami jest dość ważną funkcją IoT, a nawet funkcją definiującą, więc nie rozumiem, dlaczego to pytanie jest nie na temat.
Gilles „SO- przestań być zły”

Odpowiedzi:

13

Aby upewnić się, że Twoje urządzenie jest wystarczająco bezpieczne, mam kilka wskazówek:

  1. Dodaj szyfrowanie do komunikacji Bluetooth. Zalecam trzymanie kluczy szyfrujących w powietrzu. Na przykład możesz poprosić użytkownika o zeskanowanie kodu QR znajdującego się na urządzeniu, wydrukowanego w pudełku itp. Przy początkowej konfiguracji aplikacji mobilnej, może za pomocą klucza AES? Zależy od Ciebie. Ma to na celu uniemożliwienie komuś zobaczenia hasła przesłanego bezprzewodowo zwykłym tekstem.
  2. Jeśli możesz, trzymaj się z dala od trybu EBC (użyj CBC) wybranego algorytmu szyfrowania, ponieważ może on dostarczyć pewnych informacji o przesyłanych danych. Więcej informacji na ten temat można znaleźć tutaj .
  3. Podczas transmisji danych Bluetooth pamiętaj o podaniu unikalnego identyfikatora, aby nie można było powtórzyć wiadomości (na przykład możesz dołączyć znacznik czasu). Możesz także wdrożyć system podobny do TOTP.
  4. Umieść w urządzeniu port, który pozwala łatwo go sflashować, aby na wypadek, gdybyś zdał sobie sprawę, że oprogramowanie zawiera błąd (i z jakiegoś powodu nie możesz go zaktualizować OTA), urządzenie nie jest drogim przyciskiem do papieru, tylko urządzeniem który należy podłączyć do komputera i sflashować do nowego oprogramowania.
  5. Dodatkowo: Aby upewnić się, że osoba z nieuczciwym certyfikatem root (prawdopodobnie wydanym samodzielnie i zainstalowanym na urządzeniu klienckim) nie może przechwycić komunikacji z serwerem, sprawdź certyfikat HTTPS. Oto SO z prośbą o to dla Androida, musisz być w stanie znaleźć podobne zasoby dla iOS .

Ponadto, jeśli chcesz dowiedzieć się więcej o kryptologii i szyfrowaniu, których będziesz używać do zabezpieczenia swojego urządzenia, sprawdź ten (bezpłatny) ebook . Mówi dużo o dobrych i złych implementacjach algorytmów szyfrowania i powinien pomóc w zabezpieczeniu produktu. (Uwaga 1: Proszę nie tworzyć własnego algorytmu. Uwaga 2: Nie jestem powiązany z crypto101 lub lvh.)

zdrowaśka
źródło
2
„Jeśli możesz, trzymaj się z dala od EBC”. Nie, zła rada. Dobrą radą byłoby „nigdy nie korzystaj z EBC”, ale nadal jest ona niepełna. Lepsza odpowiedź brzmiałaby, że jeśli wpisujesz litery CBC w swoim kodzie, robisz to źle . W szczególności AES-CBC nie zapewnia integralności ani autentyczności komunikacji.
Gilles „SO- przestań być zły”
@Gilles ECB jest z pewnością lepszy niż wszystkie obecnie dostępne urządzenia iot, które tylko przesyłają rzeczy w postaci zwykłego tekstu lub po prostu xor z ustaloną wartością, ale tak, EBC nie doprowadza twojego produktu do „niemożności włamania się” (technicznie nic nie robi, ale możesz spróbować zrobić coś, co zapewni jak najbezpieczniejsze zabezpieczenie przez jak najdłuższy czas, a to nie będzie wymagało EBC, ale właściwą implementację AES-CBC 256).
Ave
13

Jeśli możesz mieć kompleksowy protokół TCP, użyj kompleksowego protokołu TLS (np. Z HTTPS).

Nie wymyślaj na nowo koła, szczególnie jeśli chodzi o kryptografię - większość ludzi myli się. Jeśli urządzenie nie jest zbyt ograniczone pod względem zasobów, aby obsługiwać TLS, jeśli przejdziesz do poziomu AES, robisz to źle . # 1 błędem jest szyfrowanie i zapominanie o uwierzytelnianiu - jeśli masz zaszyfrowany kanał między serwerem a człowiekiem w środku, zamiast zaszyfrowanego kanału między serwerem a urządzeniem, szyfrowanie nie przyniosło żadnych korzyści . Jeśli nie możesz korzystać z TLS, upewnij się, że każdy używany protokół uwierzytelnia wszystko i szyfruje to, co musi być poufne.

Aby bezpiecznie korzystać z TLS, zastanów się, jakie gwarancje musisz mieć z punktu widzenia każdego uczestnika. Zasadniczo urządzenie musi wiedzieć, że komunikuje się z legalnym serwerem. Oznacza to, że musi sprawdzić certyfikat serwera. Na urządzeniu musi być zarejestrowany certyfikat X.509 urzędu certyfikacji jako zaufany; wymaga to pamięci, której atakujący nie może modyfikować, ale nie wymaga żadnej poufności pamięci. Pamiętaj, że nie powinieneś bezpośrednio kodować certyfikatu serwera, ponieważ nie pozwoli to łatwo zastąpić tego certyfikatu, jeśli zostanie naruszony. Zamiast tego urządzenie przechowuje oczekiwaną tożsamość(nazwa hosta) serwera oraz certyfikat urzędu certyfikacji, który gwarantuje, że określony klucz publiczny należy do oczekiwanej nazwy hosta. Ponownie nie wymyślaj koła ponownie, polegaj na sprawdzaniu certyfikatów dostarczonym przez Twoją bibliotekę TLS lub aplikację.

Jeśli serwer musi wiedzieć, że rozmawia z legalnym klientem, każdy klient musi mieć własny certyfikat klienta. Wymaga to poufnego przechowywania na kliencie. Przekaż certyfikat klienta do funkcji otwierania sesji TLS z biblioteki TLS lub ustaw go w konfiguracji aplikacji.

To zapewnia bezpieczeństwo komunikacji między serwerem a urządzeniem. Jeśli aplikacja mobilna może bezpośrednio komunikować się z urządzeniem (np. Aby umożliwić rozłączenie działania, gdy jest w lokalnej sieci Wi-Fi), musisz najpierw wykonać parowanie między inteligentnym przełącznikiem a telefonem komórkowym. Parowanie oznacza wymianę kluczy, najlepiej wymianę kluczy publicznych, jeśli pozwalają na to zasoby, w przeciwnym razie uzgodnienie tajnych kluczy. Celem tego parowania jest upewnienie się, że każde urządzenie wie, z kim rozmawia.

Musisz także zabezpieczyć kanał kontrolny, niezależnie od tego, czy przechodzi on bezpośrednio z urządzenia mobilnego na inteligentny przełącznik, czy przez serwer. Pomyśl o autoryzacji: czy istnieją różne poziomy dostępu do przełącznika, np. Poziom kontroli, który umożliwia przeprowadzenie rekonfiguracji i podstawowy kanał, który pozwala tylko na włączanie / wyłączanie? Jest to zazwyczaj obsługiwane przez etap uwierzytelnienia po ustanowieniu bezpiecznego kanału (TLS, jeśli to możliwe).

Innym zagadnieniem są aktualizacje oprogramowania układowego. To trudne: z jednej strony nie ma czegoś takiego jak absolutne bezpieczeństwo, więc od czasu do czasu będziesz mieć łatki bezpieczeństwa. Z drugiej strony mechanizm aktualizacji oprogramowania układowego jest złożoną rzeczą i może sam zawierać błędy. Przynajmniej upewnij się, że aktualizacje oprogramowania układowego są podpisane. Poleganie wyłącznie na bezpieczeństwie kanału komunikacyjnego w przypadku aktualizacji jest niejasne, ponieważ zaufany oparty na bezpiecznym kanale jest większy niż w przypadku statycznej weryfikacji bezpieczeństwa, a czasami możesz chcieć zastosować aktualizacje oprogramowania układowego bez połączenia sieciowego. Oprócz weryfikacji podpisu najlepiej byłoby mieć pewną ochronę przed wycofaniem, aby przeciwnik mógł „

Gilles „SO- przestań być zły”
źródło