Czy jednokierunkowy protokół SSL może zabezpieczyć urządzenie IoT?

9

Rozważam urządzenie IoT podłączone do mojej sieci lokalnej (ustawienia domyślne, brak VPN, brak NAT, brak DMZ) z dostępem do Internetu lub bez niego. Moje urządzenie będzie działać jako serwer HTTP oferujący mechanizm RPC z uwierzytelnianiem i autoryzacją. Reklamuje się za pomocą mDNS i rozmawiam z nim za pomocą mojej aplikacji mobilnej lub RaspberryPi.

Wydaje się, że normą w rozwoju IoT jest wzajemne (dwukierunkowe) SSL. Czy to oznacza, że ​​jednokierunkowy protokół SSL nie może zabezpieczyć mojego ruchu? Dlaczego?

Uwagi:

  • Rozumiem techniczne różnice między jedno- i dwukierunkowym protokołem SSL, nie rozumiem, dlaczego jednokierunkowego (prawie) nigdy nie bierze się pod uwagę w produkcji IoT.
  • Rozumiem, że posiadanie wzajemnego SSL dla lokalnego urządzenia jest trudne: musisz udostępnić klucz publiczny serwera i certyfikat klientowi i odwrotnie. Z drugiej strony wydaje się łatwiejsze (nie wymaga działań użytkownika).
  • Niektóre masowo produkowane urządzenia, takie jak Philips Hue, wolą mieć lokalny punkt końcowy http otwarty i niezabezpieczony niż jednokierunkowe szyfrowanie SSL. Dlaczego miałby dokonywać tego wyboru?
  • Oczekuję, że to pytanie nie będzie oparte na opiniach. Przepraszamy, jeśli tak jest.
walentyna
źródło

Odpowiedzi:

8

SSL / TLS działa dobrze, gdy „serwer” znajduje się w znanej lokalizacji (stała nazwa hosta), która może być zgodna z CN prezentowanego certyfikatu.

Nie działa to dobrze dla urządzeń w sieciach domowych (np. Większość urządzeń IoT), ponieważ mają one tendencję do uzyskiwania adresów IP z bloków RFC1918 i nie mają wpisów DNS. Oznacza to, że nie można im wystawiać certyfikatów (cóż, mogą, ale większość przeglądarek je odrzuci). Właśnie dlatego urządzenia takie jak Philips Hue używają niezabezpieczonych punktów końcowych HTTP urządzenia, w zasadzie polegają na zabezpieczeniu dostępu do sieci.

Kiedy używane jest wzajemne TLS, ma to miejsce, gdy urządzenie łączy się z jakąś usługą centralną, klient ma swój własny certyfikat / klucz prywatny, aby uwierzytelnić, że może działać w imieniu właściciela z tym centralnym serwerem.

Aby wyjaśnić twoje pytanie, nie musisz rozpowszechniać certyfikatu / klucza serwera wśród wszystkich klientów, wystarczy certyfikat urzędu certyfikacji, który wystawił certyfikat, aby udowodnić, że certyfikat jest zaufany.

EDYTOWAĆ:

Dobrym przykładem bezpiecznego połączenia z urządzeniem lokalnym jest oświetlenie Tradfri IKEA, które korzysta z COAP przez DTLS z kluczem wstępnym (w kodzie QR) na urządzeniu, które jest używane do generowania klucza na klienta. Zapewnia to fizyczny dostęp do konfiguracji nowego klienta i chroni dane w locie w sieci lokalnej.

hardillb
źródło
Jeśli host nie ma stałej nazwy DNS lub adresu IP, wówczas normalna weryfikacja certyfikatu nie powiedzie się, ponieważ certyfikat stwierdza, że ​​urządzenie pod tym adresem jest tym, za kogo się podaje (normalny „jednostronny” SSL). W przypadku wzajemnie uwierzytelnionego protokołu SSL nie należy używać tego samego klucza / certyfikatu dla obu stron. Serwer i klient powinni osiągnąć swój certyfikat / klucz podpisany przez
wzajemnie
Dzięki za odpowiedź i przepraszam za długą ciszę @hardillb. „Oznacza to, że nie można im wystawiać certyfikatów (cóż, mogą, ale większość przeglądarek je odrzuci)”. Biorąc pod uwagę komunikację z moim urządzeniem IoT, nie widzę, kiedy skorzystam z przeglądarki, aby to zrobić ... „nie trzeba rozpowszechniać certyfikatu / klucza serwera wśród wszystkich klientów, tylko certyfikat urzędu certyfikacji” dla jednokierunkowego TLS, prawda? Ponieważ dla wzajemności uważam, że musisz dać certyfikat i klucz, co znacznie utrudnia sprawę. W przypadku Tradfri kluczem wstępnym jest uwierzytelnianie, a nie szyfrowanie.
valentin,
Nie, wspólnym kluczem tradrfi jest uścisk dłoni i utworzenie klucza dla urządzenia do szyfrowania
hardillb
1

Ogólnie rzecz biorąc, TLS jest dobry na więcej niż x.509, ale wiele implementacji ogranicza go tylko do x.509.

x.509 to technika bezpiecznego pośredniego zaufania. „A” ufa „B”, jeśli „B” ma certyfikat podpisany przez „C”, a „C” jest zaufany przez „A”. Działa to również w prawdziwym życiu; ufasz komuś, kogo nie znasz, jeśli list zostanie przedstawiony podpisany przez osobę, której ufasz. Może widzisz pułapkę: jeśli list mówi, proszę o filiżankę kawy, której nie podasz swojemu samochodowi. W związku z tym dodatkowe informacje w certyfikacie są również istotne dla rozszerzenia zakresu zaufania. Właśnie dlatego serwer zwykle ma w certyfikacie swoją nazwę dns lub adres IP. Zasadniczo możesz zawierać różne informacje (np. „Lampa do salonu”), ale wiele implementacji jest również przynajmniej wstępnie skonfigurowanych do używania / sprawdzania danych DNS / IP. A wszystko to działa tylko wtedy, gdy komuś zależy na zaufanym ”

Jeśli możesz spędzić w nim czas, sprawdź swoją implementację, jeśli oferuje ona także zestawy szyfrów PSK. Jeśli nie, być może możesz dostosować „sprawdzanie poprawności” certyfikatu serwera. Ale znalezienie odpowiedniego rozwiązania wymaga dużo czytania. A czasami używana implementacja TLS po prostu tego nie oferuje.

Achim Kraus
źródło