MQTT v5 принес много новых функций, мы постараемся изо всех сил показать эти функции популярным и понятным способом и обсудить влияние этих функций на разработчиков. До сих пор мы обсуждали эти новые функции MQTT v5 , сегодня мы продолжим обсуждение: расширенная проверка подлинности
В сценариях приложений Интернета вещей проектирование безопасности является очень важным звеном. Утечка конфиденциальных данных или незаконный контроль над периферийными устройствами недопустимы. Однако по сравнению с другими сценариями приложений в проектах Интернета вещей по-прежнему есть следующее Ограничения:
- Нет компромисса между безопасностью и высокой производительностью;
- Алгоритмы шифрования требуют большей вычислительной мощности, а производительность устройств IoT часто очень ограничена;
- Сетевые условия Интернета вещей часто намного хуже, чем в доме или офисе.
Чтобы решить вышеупомянутые проблемы, протокол MQTT обеспечивает простую аутентификацию и расширенную аутентификацию для облегчения проверки устройств на уровне приложений.
Простая аутентификация
Сообщение MQTT CONNECT использует имя пользователя и пароль для поддержки базовой аутентификации сетевого подключения.Этот метод называется простой аутентификацией. Этот метод также можно использовать для выполнения других форм аутентификации, таких как передача пароля в виде токена.
После получения сообщения CONNECT сервер может проверить легитимность клиента с помощью имени пользователя и пароля, содержащихся в нем, для обеспечения безопасности бизнеса.
По сравнению с расширенной аутентификацией, простая аутентификация требует очень низкой вычислительной мощности для клиента и сервера, и бизнес с низкими требованиями к безопасности и ограниченными вычислительными ресурсами может использовать простую аутентификацию.
Однако в протоколе, основанном на простой модели аутентификации имени пользователя и пароля, и клиент, и сервер знают, что имя пользователя соответствует паролю. При условии отсутствия шифрования канала, либо прямая передача имени пользователя и пароля в виде обычного текста, либо добавление хеш-кода к паролю легко подвергнуться атаке.
Расширенная сертификация
Основываясь на более строгих соображениях безопасности, MQTT v5 добавляет новые функции для улучшения аутентификации , расширенная сертификация сертификации включает стиль запроса / ответа, вы можете достичь взаимной аутентификации клиента и сервера, сервер может проверить, что клиент подключен к реальному клиенту В конце клиент также может проверить, является ли подключенный сервер реальным сервером, тем самым обеспечивая более высокую безопасность.
Расширенная проверка подлинности полагается на методы проверки подлинности и данные проверки подлинности для завершения всего процесса проверки подлинности. При расширенной проверке подлинности метод проверки подлинности обычно представляет собой механизм SASL (Simple Authentication and Security Layer) , а зарегистрированное имя используется для облегчения обмена информацией. Однако метод аутентификации не ограничивается использованием зарегистрированного механизма SASL.Сервер и клиент могут согласиться использовать любой стиль аутентификации запрос / ответ.
Метод проверки подлинности
Метод аутентификации - это строка UTF-8, которая используется для указания метода аутентификации.Клиент и сервер должны поддерживать указанный метод аутентификации одновременно. Клиент инициирует усиленную аутентификацию, добавляя поле метода аутентификации к сообщению CONNECT. Во время процесса расширенной аутентификации сообщения, которыми обмениваются клиент и сервер, должны включать поле метода аутентификации, и метод аутентификации должен согласовываться с сообщением CONNECT.
Данные аутентификации
Данные аутентификации - это двоичная информация, используемая для передачи секретов шифрования или нескольких итераций шагов протокола. Содержание данных аутентификации сильно зависит от конкретной реализации метода аутентификации.
Расширенный процесс сертификации
По сравнению с простой аутентификацией, основанной на одном взаимодействии между пакетами CONNECT и CONNACK, расширенная аутентификация требует многократного обмена данными аутентификации между клиентом и сервером, поэтому MQTT v5 добавляет пакет AUTH для удовлетворения этого требования. Расширенная аутентификация реализована на основе трех типов сообщений MQTT: сообщение CONNECT, сообщение CONNACK и сообщение AUTH. Все три сообщения должны содержать методы аутентификации и данные аутентификации для достижения цели взаимной аутентификации.
Чтобы запустить процесс расширенной аутентификации, клиенту необходимо отправить на сервер сообщение CONNECT, содержащее поле метода аутентификации. После того, как сервер получит сообщение CONNECT, он может продолжить обмен данными аутентификации с клиентом через сообщение AUTH и отправить данные аутентификации клиенту после завершения аутентификации. Конец отправляет сообщение CONNACK.
Примеры нестандартной сертификации SCRAM
-
Клиент-сервер: метод аутентификации CONNECT = "SCRAM-SHA-1", данные аутентификации = данные-клиент-первые
-
От сервера к клиенту: код причины AUTH = 0x18, метод аутентификации = "SCRAM-SHA-1", данные аутентификации = server-first-data
-
От клиента к серверу: код причины AUTH = 0x18, метод проверки подлинности = "SCRAM-SHA-1", данные проверки подлинности = конечные данные клиента.
-
От сервера к клиенту: код причины CONNACK = 0, метод аутентификации = «SCRAM-SHA-1», данные аутентификации = конечные данные сервера
Нестандартный пример аутентификации 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 клиенту. Пакет AUTH с кодом причины 0x00 (успех) указывает, что повторная аутентификация прошла успешно. Следует отметить, что метод аутентификации для повторной аутентификации должен соответствовать расширенной аутентификации.
Во время процесса повторной аутентификации другие потоки сообщений клиента и сервера могут продолжать использовать предыдущую аутентификацию.
Заявление об авторских правах: Данная статья является оригинальной EMQ , пожалуйста, укажите источник для перепечатки.
Исходная ссылка: https://www.emqx.io/cn/blog/mqtt5-enhanced-authentication