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

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.

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.

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.