Расширенная аутентификация

MQTT v5 содержит множество новых функций, и мы постараемся представить эти функции в простой для понимания форме и обсудить влияние этих функций на разработчиков. До сих пор мы обсуждали эти новые возможности MQTT v5. Сегодня мы продолжим обсуждение: усиленная аутентификация.

В сценарии IoT безопасный дизайн является очень важной частью процесса. Утечка конфиденциальных данных или несанкционированный контроль периферийных устройств недопустимы, но по сравнению с другими сценариями проект IoT по-прежнему имеет следующие ограничения:

Не удается сбалансировать безопасность и высокую производительность;
Алгоритмы шифрования требуют большей вычислительной мощности, но производительность устройств IoT часто очень ограничена;
Сетевые условия IoT часто намного хуже, чем дома или в офисе.

Для решения поставленных выше вопросов необходимо протокол MQTT обеспечивает простую аутентификацию и расширенную аутентификацию, которые легко проверяют устройства на прикладном уровне.

Простая аутентификация

Пакет MQTT CONNECT использует имя пользователя и пароль для поддержки базовой аутентификации сетевого подключения, которая называется простой аутентификацией. Этот метод также можно использовать для размещения других форм аутентификации, например, доставки пароля в виде токена.

После получения пакета CONNECT брокер может проверить легитимность клиента с помощью имени пользователя и пароля, содержащихся для обеспечения безопасности бизнеса.

По сравнению с расширенной проверкой подлинности простая проверка подлинности требует меньше вычислительных ресурсов как для клиента, так и для сервера и может использоваться для служб, где требования безопасности не столь высоки, а вычислительные ресурсы ограничены.

Однако в протоколе, основанном на простой модели аутентификации имени пользователя и пароля, клиент и брокер знают, что имя пользователя соответствует паролю. Без шифрования канала либо прямое использование открытого текста для передачи имени пользователя и пароля, либо метод хеширования пароля уязвим для атаки.

В целях повышения безопасности в MQTT v5 добавлена новая функция. усиленная аутентификация. Расширенная проверка подлинности включает в себя проверку подлинности в стиле запрос/ответ, которая может реализовать двунаправленную проверку подлинности клиента и брокера. MQTT-брокер может проверить, является ли подключенный клиент реальным клиентом, и клиент также может проверить, является ли подключенный брокер реальным брокером, что обеспечивает более высокий уровень безопасности.

Расширенная проверка подлинности зависит от метода проверки подлинности и данных проверки подлинности для завершения всего процесса проверки подлинности. В расширенной аутентификации метод аутентификации обычно SASL (простая аутентификация и уровень безопасности) механизм, который использует зарегистрированное имя для легкого обмена информацией. Однако метод аутентификации не ограничивается использованием зарегистрированного механизма SASL, и брокер и клиент могут договориться об использовании любого стиля аутентификации типа запрос/ответ.

Методы аутентификации

Метод аутентификации — это строка UTF-8 для указания метода аутентификации, и клиент и брокер должны одновременно поддерживать указанный метод аутентификации. Клиент инициирует расширенную аутентификацию, добавляя поле метода аутентификации в пакет CONNECT. В процессе расширенной аутентификации пакет, которым обмениваются клиент и брокер, должен включать поле метода аутентификации, а метод аутентификации должен соответствовать пакету CONNECT.

Данные аутентификации

Данные аутентификации — это двоичная информация, используемая для передачи нескольких итераций криптографических секретов шагов протокола. Содержание данных аутентификации сильно зависит от конкретной реализации метода аутентификации.

Расширенный процесс аутентификации

По сравнению с простой аутентификацией, основанной на взаимодействии между пакетами CONNECT и CONNACK, расширенная аутентификация требует многократного обмена данными аутентификации между клиентом и посредником. Поэтому MQTT v5 добавляет пакет AUTH для реализации этого. Реализация расширенной аутентификации основана на трех типах пакетов MQTT: CONNECT, CONNACK и AUTH. Пакеты этих трех типов должны содержать метод аутентификации и данные аутентификации для двунаправленной аутентификации.

Чтобы запустить расширенный процесс аутентификации, клиент должен отправить посреднику пакет CONNECT, содержащий поле метода аутентификации. После получения пакета CONNECT брокер может продолжить обмен данными аутентификации с клиентом через пакет AUTH и отправить пакет CONNACK клиенту после завершения аутентификации.

Нестандартный пример аутентификации SCRAM

Клиент-сервер: метод аутентификации CONNECT = «SCRAM-SHA-1», данные аутентификации = client-first-data
Сервер-клиент: код причины AUTH = 0x18, метод аутентификации = «SCRAM-SHA-1», данные аутентификации = server-first-data
Клиент-сервер: код причины AUTH = 0x18, метод аутентификации = «SCRAM-SHA-1», данные аутентификации = client-final-data
Сервер-клиент: код причины CONNACK = 0, метод аутентификации = «SCRAM-SHA-1», данные аутентификации = server-final-data

Нестандартный пример аутентификации Kerberos

Клиент-сервер: метод аутентификации CONNECT = «GS2-KRB5»
Сервер-клиент: код причины AUTH = 0x18, метод аутентификации = «GS2-KRB5»
Клиент-сервер: код причины AUTH = 0x18, метод аутентификации = «GS2-KRB5», данные аутентификации = токен начального контекста
Сервер-клиент: код причины AUTH = 0x18, метод аутентификации = «GS2-KRB5», данные аутентификации = токен контекста ответа
Клиент-сервер: код причины AUTH = 0x18, метод аутентификации = «GS2-KRB5»
Сервер-клиент: код причины CONNACK = 0, метод аутентификации = «GS2-KRB5», данные аутентификации = результат аутентификации

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

Повторная аутентификация

После завершения расширенной аутентификации клиент может инициировать повторную аутентификацию в любое время, отправив пакет AUTH. После запуска повторной аутентификации клиент и брокер обмениваются данными аутентификации путем обмена пакетом AUTH, как и в случае расширенной аутентификации, до тех пор, пока брокер не отправит клиенту пакет AUTH с кодом причины 0x00 (успешно), чтобы указать, что повторная аутентификация прошла успешно. Следует отметить, что метод аутентификации для повторной аутентификации должен быть таким же, как и при расширенной аутентификации.

В процессе повторной аутентификации другие пакеты клиента и брокера могут продолжать использовать предыдущую аутентификацию.

Первоначально опубликовано на

Расширенная аутентификация — новые функции MQTT 5.0

Простая аутентификация