Jak mogę korzystać z 2FA w sieci MQTT?

12

Jak mogę korzystać z 2FA (uwierzytelnianie dwuskładnikowe) po podłączeniu nowego urządzenia do brokera, jeśli jest to w ogóle możliwe?

Ponieważ wydaje się to łatwiejsze, drugim czynnikiem może być najpierw rozwiązanie programowe, ale chętnie przyjmę pomysły na wprowadzenie twardych tokenów (może RFID).

Sensowne byłoby, gdyby urządzenia uwierzytelniały się tylko przy pierwszym połączeniu, a serwer zapamiętywałby „starych” klientów.

Pomysł może być nietypowy lub nieodpowiedni - jeśli jest to zły pomysł, proszę podać przyczyny.

Bence Kaulics
źródło
Czy możesz nam powiedzieć, w jaki sposób urządzenie może zrobić 2FA, ponieważ jest to jedno urządzenie?
Goufalite,
@Goufalite Na przykład, gdy instaluję nowe urządzenie, muszę podać klucz ręcznie (na przykład za pomocą znacznika RFID), który będzie używany podczas uwierzytelniania. Jeśli chodzi o oprogramowanie 2FA, nie wiem, czy w moim domu można by skonfigurować usługę, z której nowe urządzenia mogłyby żądać tokenów miękkich, coś w rodzaju serwera kluczy prywatnych.
Bence Kaulics

Odpowiedzi:

8

Potrzebujesz brokera proxy lub serwera WWW ...

Przede wszystkim absolutnie potrzebujesz usługi uwierzytelniania gdzieś podłączonej do twojego brokera, aby wykonać 2FA przy użyciu określonych tematów ( /auth/RFID, ...). Umożliwiłoby to klientowi opublikowanie informacji (patrz poniżej).

Pierwszym problemem, jaki widzę tutaj, jest to, że każdy, kto subskrybuje ten temat, może przeczytać informacje na ten temat, ale możesz zablokować tematy !

Następnie możesz powiedzieć (wymusić) na wszystkich swoich urządzeniach, aby opublikowały informacje /proxy/mytopic. Dzięki funkcji clientId mqtt usługa uwierzytelniania może sprawdzić, czy wiadomości wysyłane z tego tematu pochodzą z uwierzytelnionego urządzenia, które poprzednio korzystało z 2FA, a następnie opublikować własną wiadomość w imieniu urządzenia, /proxyout/mytopicpodając identyfikator urządzenia w ładunku.

Problem polega teraz na sprawdzeniu urządzeń, które mogą odbierać wiadomości, jeśli są uwierzytelnione, ponieważ Cóż, MQTT polega na masowej publikacji. Usługa uwierzytelniania musi mieć listę uwierzytelnionych urządzeń i sprawdzić, czy kwalifikują się do odbioru. Ponownie szyfrowanie i deszyfrowanie ładunku po stronie urządzenia ...

Myślę, że moje rozwiązanie jest bardzo przesadne w stosunku do możliwości MQTT. Dlatego powinieneś użyć gniazda lub serwera WWW ...

Goufalite
źródło
@ tim3in przepraszamy za spóźnioną odpowiedź. W końcu była to odpowiedź udzielona 2,5 roku temu ... może wszystko się zmieniło i to była tylko ogólna propozycja architektury. Czy zrobiłeś POC ze swoim rozwiązaniem?
Goufalite,
Zaplanowałem to. Czy będziesz w stanie to sprawdzić?
tim3in
7

Nadchodząca specyfikacja MQTT v5 dodaje obsługę AUTHpakietu kontrolnego, co umożliwia uwierzytelnianie typu wyzwanie / odpowiedź. Ponieważ MQTT v5 nie jest jeszcze sfinalizowany, wsparcie może się jeszcze zmienić, ale uzasadnione wydaje się założenie, że AUTH pozostanie w takiej lub innej formie i że można przy jego użyciu dodać 2FA.

Aktualne robocze wersje specyfikacji można zobaczyć na stronie z dokumentami komitetu OASIS MQTT .

ralight
źródło
5

Zgodnie ze specyfikacją komunikat połączenia może opcjonalnie podać nazwę użytkownika i hasło. Jest to sprawdzane na podstawie listy ACL zapisanej gdzieś w brokerze. Jest to więc pierwszy czynnik uwierzytelnienia, który możesz wykorzystać. Komunikat CONNACK od brokera odpowie, jeśli nastąpi uwierzytelnienie.

Aby wdrożyć drugi czynnik w przypadku uwierzytelnienia, najlepszym sposobem powinno być wysłanie niestandardowej wiadomości połączenia z drugim czynnikiem. Komunikat CONNACK w tym przypadku powinien odnosić się do powodzenia lub niepowodzenia drugiego czynnika uwierzytelnienia. Dlatego broker i klient powinni implementować niestandardowe komunikaty powyżej specyfikacji.

Myślę, więc jestem
źródło
4

Aby osiągnąć 2FA w sieci MQTT, stworzyłem następujące usługi uwierzytelniania, które są połączone z Brokerem.

  1. Weryfikator tożsamości
  2. Generator Tokenów
  3. Token Verifier

Kiedy łączy klienta MQTT do maklera przez SSL / TLS, najpierw publikuje swój własny identyfikator device_id temacie, że sprawdza identyfikator kontrolny że jest to autentyczny klient, a następnie Reklamowe Generator jest wywoływana który generuje token i publikuje token na Zamknięty temat device_token .

Urządzenie klienckie pobiera ten token i dalej publikuje go w temacie token_weryfikacyjny . Gdy tylko temat zostanie opublikowany na stronie Verit_token, weryfikator tokenów porównuje wartości w temacie device_token i Verit_token, jeśli jest zgodny, dodaj identyfikator urządzenia do zweryfikowanej puli urządzeń i pozwól urządzeniu publikować dane. Zwiększa to bezpieczeństwo, ponieważ tylko zweryfikowane urządzenia są łączone z tematami w celu publikowania danych.

Użyłem również opcji konfiguracji MQTT_KEEPALIVE, aby utrzymać aktywność klienta, gdy żadne dane nie są wysyłane ani odbierane, aby utrzymać urządzenie klienta przy życiu w puli urządzeń i zapobiec ponownej weryfikacji po dodaniu do puli urządzeń. jednak ze względów bezpieczeństwa przeniosłem urządzenie do 2FA co 24 godziny.

tim3in
źródło
3
W jaki sposób jest zabezpieczone, że tylko właściwy klient otrzymuje token?
Helmar
@Helmar używa unikalnego ID klienta i osobnego tematu do przechowywania tokena dla każdego klienta, który jest wstępnie zdefiniowany przy rejestracji urządzenia. Klient faktycznie zasubskrybował ten temat. Po ponownym opublikowaniu tokena do sprawdzenia dodaje swój identyfikator do danych tokena, aby weryfikator wiedział, który klient opublikował ten token. clientid może być chroniony przy użyciu Secure Element po stronie urządzenia po zarejestrowaniu tego samego identyfikatora na serwerze w bazie danych.
tim3in
@Helmar, czy chcesz dodać do tego swój komentarz? Byłbym wdzięczny za opinie wszystkich na temat mojego rozwiązania.
tim3in
2
tak, ale co mnie powstrzymuje od subskrybowania „#”, aby zobaczyć wszystkie odpowiedzi na tokeny
hardillb
Tematy @hardillb, które mają tokeny, są zablokowane, jak wspomniał Goufalite. Widzą tylko uprzednio zaprogramowane urządzenia. W fazie rejestracji urządzenia są powiązane z określonymi tematami, a każde urządzenie ma przypisane osobne tematy do odpowiedzi na tokeny.
tim3in