Як я можу використовувати 2FA в мережі MQTT?


12

Як я можу використовувати 2FA (двофакторну автентифікацію), коли підключаю новий пристрій до брокера, якщо це навіть можливо?

Оскільки це здається легшим, другий фактор може бути першим програмним рішенням, але я б вітав ідеї щодо впровадження жорстких жетонів (можливо, RFID).

Було б сенс, якщо пристрої повинні мати автентифікацію лише при першому підключенні, а сервер запам'ятає "старих" клієнтів.

Ідея може бути незвичною або непридатною - якщо це погана ідея, будь ласка, дайте мені причини.


Чи можете ви сказати нам, як ви думаєте, що пристрій міг би робити 2FA, оскільки це один пристрій?
Гуфаліт

@Goufalite Наприклад, коли я встановлюю новий пристрій, я повинен надати ключ вручну (наприклад, тегом RFID), який буде використовуватися під час автентифікації. Що стосується програмного забезпечення 2FA, я не знаю, чи можна було б налаштувати якийсь вид сервісу в моєму будинку, з якого нові пристрої могли б запитувати м'які жетони, щось на зразок сервера приватних ключів.
Бенс Каулікс

Відповіді:


8

Вам потрібен проксі-посередник або веб-сервер ...

Перш за все, вам абсолютно потрібна послуга аутентифікації десь підключена до вашого брокера, щоб виконати 2FA з використанням конкретних тем ( /auth/RFID, ...). Потім це дозволить клієнту публікувати інформацію (див. Нижче).

Перша проблема, яку я бачу тут, - це те, що кожен, хто підписався на цю тему, може прочитати інформацію з цієї теми, але ви можете заблокувати теми !

Потім ви можете сказати (змусити) всі свої пристрої публікувати інформацію /proxy/mytopic. Завдяки функції clientId mqtt служба аутентифікації може перевірити, чи є повідомлення, надіслані з цієї теми, з аутентифікованого пристрою, який раніше використовував 2FA, а потім публікувати своє власне повідомлення від імені пристрою /proxyout/mytopicз ідентифікатором пристрою в корисному навантаженні.

Проблема зараз полягає в тому, щоб перевірити наявність пристроїв, які можуть отримувати повідомлення, якщо вони перевірені автентичністю, адже, MQTT, все стосується масової публікації. Службі аутентифікації потрібно мати список автентифікованих пристроїв і перевірити, чи вони мають право на прийом. Знову шифрування корисного навантаження та дешифрування на стороні пристрою ...

Я думаю, що моє рішення дуже непосильне над можливостями MQTT. Тому ви повинні використовувати сокет або веб-сервер ...


@ tim3in вибачте за пізню відповідь. Зрештою, це була відповідь, отримана 2,5 роки тому ... можливо, все змінилося, і це була просто загальна архітектурна пропозиція. Ви робили POC зі своїм рішенням?
Гуфаліт

Я це запланував. Чи зможете ви переглянути його?
tim3in

7

Майбутня специфікація MQTT v5 додає підтримку AUTHпакету управління, що дозволяє аутентифікувати виклик / відповідь. Оскільки MQTT v5 ще не доопрацьована, підтримка може все-таки змінитися, але здається розумним припустити, що AUTH залишиться в тій чи іншій формі і що 2FA можна буде додати за допомогою неї.

Ви можете ознайомитись з поточними робочими проектами специфікації на сторінці документів комітету OASIS MQTT .


5

Відповідно до специфікації, з'єднання з'єднання може додатково містити ім'я користувача та пароль. Це підтверджено проти ACL, збереженого десь у брокера. Отже, це ваш перший фактор аутентифікації, який ви можете використати. Повідомлення CONNACK від брокера відповість, якщо аутентифікація пройшла.

Для реалізації другого фактора, якщо аутентифікація, найкращим способом має бути надіслати спеціальне повідомлення про з'єднання з іншим фактором. Повідомлення CONNACK у цьому випадку має стосуватися успіху чи відмови другого фактора аутентифікації. Тому брокер і клієнт повинні реалізовувати власні повідомлення над специфікацією та вище.


4

Для досягнення 2FA в мережі MQTT я створив такі сервіси для аутентифікації, які підключені до Broker.

  1. Ідентифікатор підтвердження
  2. Генератор токенів
  3. Перевірка токенів

Коли клієнт MQTT підключається до брокера через SSL / TLS, він спочатку публікує свій власний ідентифікатор у темі device_id , ідентифікатор перевірки ідентифікує, що він є справжнім клієнтом, а потім викликається генератор Token, який генерує маркер і публікує маркер на заблокованій темі device_token .

Клієнтський пристрій отримує цей маркер і надалі публікує його в темі verify_token . Як тільки тема опублікована на verify_token, верифікатор токенів порівнює значення на тему device_token та verify_token, якщо вона відповідає, додайте ідентифікатор пристрою до перевіреного пулу пристроїв та дозволить пристрою публікувати дані. Це покращує безпеку, оскільки єдині перевірені пристрої підключаються до тем для публікації даних.

Я також використовував параметр конфігурації MQTT_KEEPALIVE для того, щоб клієнт був активним, коли дані не надсилаються та не надходять, щоб підтримувати клієнтський пристрій живим у пулі пристроїв і не допускати його повторної перевірки після його додавання до пулу пристроїв. однак з метою безпеки я заморожую пристрій на 2FA кожні 24 години.


3
Як гарантується, що маркер отримує лише правильний клієнт?
Гельмар

@Helmar, використовуючи унікальний clientID та окрему тему, щоб зберігати маркер для кожного клієнта, який заздалегідь визначений при реєстрації пристрою. Клієнт фактично підписався на цю тему. Коли він повторно публікує маркер для перевірки, він додає свій ідентифікатор з даними маркера, щоб перевіряючий фактор знав, який клієнт опублікував цей маркер. клієнт може бути захищений за допомогою Secure Element на стороні пристрою після реєстрації того ж ідентифікатора на сервері в базі даних.
tim3in

@Helmar, чи хотіли б ви додати свій коментар до цього? Я би вдячний думкам усіх щодо мого рішення.
tim3in

2
так, але що не може мені підписатись на "#", щоб побачити всі відповіді на маркер
hardillb

Теми @hardillb, на які є відповіді лексеми, заблоковані, як згадував Goufalite. Тож бачать лише попередні пристрої. На етапі реєстрації пристрої прив’язуються до певних тем, і кожному пристрою призначено окремі теми для відповідей на лексеми.
tim3in
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.