В последнее время постоянно растет количество умных вещей, таких как камеры, различные датчики, умные лампочки, выключатели и многое другое. Эти вещи имеют постоянный доступ в интернет и активно обмениваются данными для аналитики с приложениями. На самом деле существуют более стратегически важные данные, такие как показание датчиков о здоровье пациентов. Встает очень закономерный вопрос, как защищать данные такого рода, которые в реальном времени(без усмотрения пользователя) отпарвляются на сторонние устройства. Дело в том, что очень непросто спроектировать и построить уникальную и на сто процентов безопасную систему IoT(Internet of things), из-за того что устройства имеют различные операционные системы, цели и масштабы - некоторые работают в пределах вашей комнаты, а некоторые, например, должны охватить систему видеонаблюдения района города.
В этой статье мы рассмотрим, различные механизмы аутентификации - по имени пользователя и паролю, по токену, с помощью OTP(one-time password) и, наконец, сертификатов. Например, на бытовом уровне это позволяет защитить счётчики электроэнергии от неавторизованного доступа, и защитить данные от подмены.
Вернее всего будет начать с весьма фундаментальной вещи для IoT - платформы. Платформа IoT - это инструмент, который объединяет «вещи» и «интернет» и по сути является основой построений новых решений в IoT. Рынок платформ очень стремительно растет и рассматривать их все не имеет смысла и к тому же не является целью этой статьи. Поскольку общности это не нарушит, в качестве примера рассмотрим платформу от компании IBM(International Business Machines) .
Чтобы понять, в какие моменты должны срабатывать механизмы аутентификации давайте рассмотрим структуру стандартного IoT-приложения на основе IBM Watson IoT Platform и облачной платформы IBM Bluemix.
Мы не будем вдаваться в подробности структуры, но если вкратце: устройства публикуют данные датчиков в IBM Watson IoT Platform, которая обменивается с IoT-приложением (на Bluemix) с помощью протокола MQTT - Message Queueing Telemetry Transport Protocol. Далее устройства получают от приложений инструкции по выполнению функций управления.
Очевидно, что устройство должно получать инструкции на выполнение от довереннных устройств, в то же время устройство(например датчик) должно быть идентифицировано приложением. И таким образом мы получаем некое условие корректной работы системы - клиент должен быть аутентифицирован на сервере, а сервер, в свою очередь, на клиенте.
Перед тем, как перейти к аутентификации необходимо ввести понятие брокера - мы встречали его раньше на картинке 1. Если простыми словами брокер - помошник, который работает с потоками данных от устройств, умеет ими управлять и манипулировать, добиваясь максимальной эффективности от использования IoT - устройств. Расширенные возможности обмена сообщениями являются ключевыми для всех экосистем Интернета вещей.
Аутентификация по имени пользователя и паролю
Суть в том, что при подключении устройства к брокеру(напрямую устройства никогда не соединяются), оно отосылает броекру имя пользователя и пароль, используя команду CONNECT. Пароль отправляется в виде открытого текста, если он не зашифрован.
После этого брокер отвечает сообщением CONNACK, в которм есть поле Return Code, которое по сути является ответом от сервера об успешной или неуспешной аутентификации. Далее клиент отправляет сообщение SUBSCRIBE брокеру и подписывается на получение сообщений для него.
Чтобы подтвердить подписку Брокер MQTT отправляет сообщение SUBACK обратно клиенту.
Теперь можно считать, что клиент подключен к брокеру и может отправлять сообщения с полезной нагрузкой.
Аутентификация по токену доступа
В этом варианте также используется команда CONNECT. Клиент извлекает токен доступа и отправляет его брокеру через поле password. С этим токеном брокер может проверить были ли изменены данные, и не истек ли срок действия токена.
Аутентификация на основе одноразового пароля (OTP)
Такой подход позволяет уберечь устройство от неавторизованного пользователя и от ненадлежащего использования. Когда включен этот механизм, устройство после включения отсылает в IOT-приложение, через брокера OTP-request. Приложение генерирует одноразовый пароль и отсылает его на доверенное устройство владельца, также приложение шлет уведомление на устройство, которое мы хотим авторизовать. Далее пароль вводится в устройство и отсылается приложению, где пароль проверяется. В конфигурации можно задать количество попыток для OTP-аутентификации и если не удалось пройти аутентификацию после повторных попыток, приложение завершает работу.
Аутентификация на основе сертификатов
Не все брокеры поддерживают сертификаты устройств. Этот механизм используется в системах, где требования к безопасности высоки. Вообще говоря MQTT может использовать протокол транпортного уровня модели TCP/IP - TLS(Transport Layer Sequrity), и чтобы лучше понять как происходит установление соединения с помощью протокола TLS, рассмотрим этот процесс.
Перед тем, как начать передачу данных по протоколу TLS необходимо установить соединение между сервером и клиентом. В этот процесс входит установление некоторого согласия о том, какие криптографические технологии будут использоваться для защиты данных, какой алгоритм будет использоваться для шифрования, для подписи. Обратите внимание - клиентку необходимо убедиться в подлиности сервера. Так же в процессе соединения клиент и сервер обмениваются ключами, которые используются для шифрования.
Как происходит соединение? Клиент высылает сообщение Client Hello, в которое вставляется набор шифров TLS, которые он поддерживает и Clent Random - число, которое используется для генерации ключей симметричного шифрования. Затем сервер шлёт сообщение Server Hello, где выбирает шифр TLS, из ранее ему предоставленных от клиента, а также Server Random(аналогично клиенту). Кроме этого сервер создает Идентификатор сесси, по которму позже можно восстановить ссесию не меняя ключи и алгоритмы шифрования, что само по себе хорошо, так как не нужно повторно проводить установку соединения. Далее сервер шлет клиенту сертификат - файл, содержащий ключ сервера. Получив сертификат, клиент его проверяет. Через некоторе время сервер шлет сообщение Server Key Exchange, для обмена ключами(это не обязательное сообщение, зависит от алгоритмов шифрования, которые были выбраны). Затем сервер отсылает Server Hello Done, после которого должен действовать клиент.
Далее идет процедура обмена ключами - клиент шлет Client Key Exchange, где передаёт информацию необходимую для получения разделяемого ключа(эта информация, опять же, зависит от алгоритма обмена ключами). Например в RSA используется открытый ключ сервера, который находился в сертификате, полученном от сервера и клиент генерирует pre-master secret(это предварительный ключ, на основе которого будут получены ключи симметричного шифрования). Используя открытый ключ из сертификата, клиент зашифровывает pre-master secret и отправляет на сервер в сообщении Client Key Exchange. Далее сервер получает этот ключ и с помощью своего закрытого ключа расшифровывает ранее полученное сообщение, таки образом он получает pre-master secret. Таким образом клиент и сервер имеют одинаковые ключи(pre-master secret), на основе которых они рассчитывают ключи для шифрования, используя Client Random и Server Random. Теперб всё готово чтобы переключиться на безопасное соединение и клиент отсылает Change Ciper Spec и Finished(это сообщение уже зашифровано), а сервер отвечает аналогичной парой сообщений.
Теперь все готово для передачи сообщений! А мы возвращаемся к IOT. В нашем слушае необходимо верифицировать еще и клиента! А поэтому перед Server Hello Done сервер запрашивает сертификат клиента. Сервер проверяет сертификат клиента, и если все успешно, то подлинность клиента также подтверждена. Это позволяет аутентифицировать клиента до установления безопасного соединения, что позволяет аутентифицировать клиента на транспортном уровне, а не на уровне приложений, а, следовательно, и до сообщения CONNECT в котором передаётся пароль и имя.
Стоит добавить, что при утечке данных, или каких-либо проблем с устройством, сервер должен сбросить такой сертификат и перестать подключать клиентов с этим сертификатом.
Итоги
В этой статье мы указали на важность защиты и безопасности данных в IoT. Также мы достаточно подробно рассмотрели методы аутентификации на уровне приложений - по имени пользователя и паролю и на транспортном уровне - аутентификация на основе сертификатов, которая выполняется до установления соединения. Эти методы не являются универсальными для IoT, так как с каждым днем к нам приходят всё новые и новые устройства, которые обрабатывают наши данные, поэтому эта область остается крайне важной для безопасности людей.
Источники
1. http://blog.catchpoint.com/2017/05/30/protocol-for-internet-of-things/
2. https://developer.ibm.com/articles/iot-trs-secure-iot-solutions1/
3. https://iot-analytics.com/5-things-know-about-iot-platform/