Содержание


Проектирование и построение защищенных IoT-решений, часть 1

Защита IoT-устройств и шлюзов

В данной статье описываются такие защитные механизмы, как аутентификация (в том числе аутентификация на основе сертификатов), авторизация и проверка идентификатора приложения

Comments

Серия контента:

Этот контент является частью # из серии 3 статей: Проектирование и построение защищенных IoT-решений, часть 1

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Проектирование и построение защищенных IoT-решений, часть 1

Следите за выходом новых статей этой серии.

Интернет вещей (Internet of Things, IoT) представляет огромные возможности организациям и потребителям, особенно в таких областях, как здравоохранение, складское хранение, транспортировка и логистика. В условиях широкого распространения Интернет вещей перед разработчиками встают новые задачи - им необходимо гарантировать достаточную безопасность IoT-приложений, поскольку эти приложения манипулируют большим количеством конфиденциальных данных. В IoT-решениях уже было выявлено множество брешей безопасности, поэтому разработчикам необходимо уделять большое внимание встраиванию защиты в IoT-приложения в процессе проектирования и реализации таких решений.

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

В первой части цикла описываются различные подходы к защите устройств или шлюзов. Вторая часть посвящена вопросам защиты сетевого/транспортного уровня, включая сервис IBM Watson IoT Platform. В третьей части излагаются требования к защите уровня приложений, а также подход к реализации этих требований для аналитического IoT-приложения, созданного на платформе IBM Bluemix.

IoT-приложения собирают все больше ранее закрытых—а нередко и частных—данных и предоставляют через Интернет доступ к различным функциям управления, поэтому безопасность становится важнейшей задачей

Основы безопасности IoT-решений

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

  • Предотвращение взломов и компрометации системы.
    На каждом уровне IoT-приложения должны быть реализованы эффективные превентивные меры для противодействия злоумышленникам. Например, чтобы гарантировать безопасное взаимодействие устройства с облаком, это устройство необходимо сделать защищенным.
  • Поддержка непрерывного мониторинга.
    Даже в защищенных наилучшим образом системах остается множество уязвимостей. Кроме того, решение (как аппаратное, так и программное), защищенное наилучшим образом на сегодняшний день, в будущем может оказаться недостаточно хорошо защищенным для предотвращения атак. Поэтому разработчик должен дополнительно реализовать средства безопасности с непрерывным мониторингом и постоянным обновлением системы, чтобы защитить ее от новейших видов атак.
  • Обеспечение устойчивости.
    Наконец, если нарушение действительно произошло, необходимо минимизировать ущерб и обеспечить скорейшее восстановление системы.

Уязвимости IoT-решений

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

Однако подключение к сети таких объектов, как автомобили, дома и машины, раскрывает массу конфиденциальных данных, например, о расположении людей в здании или о здоровье пациентов. Эти данные должны быть защищены в соответствии с триадой ключевых принципов безопасности информации: конфиденциальность, целостность и доступность.

Любое устройство с сетевым подключением является уязвимым. Персональные данные, собираемые IoT-устройствами, всегда имеют ценность для хакеров и похитителей идентификационной информации. Кроме того, кибератака на IoT-решения потенциально способна нанести вред физическим сервисам и физической инфраструктуре. Например, хакеры успешно атаковали автомобиль Jeep Cherokee в то время, когда он двигался по шоссе под управлением водителя. По указанным причинам защита IoT-приложений критически важна не только для репутации предприятия, но и для физического здоровья и благосостояния клиентов и пользователей соответствующих решений.

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

Задачи проектирования защиты IoT-решений

Хотя все понимают и признают важность защиты IoT-решений, фактическая разработка и реализация IoT-безопасности порождает новые трудности и создает новые возможности для реализации творческого потенциала. При проектировании большей части приложений разработчики всегда идут на компромисс между безопасностью и удобством использования. Для IoT-решений эта задача становится еще более сложной. Нередко IoT-устройства имеют ограниченную вычислительную мощность и небольшой объем памяти, что затрудняет применение сложных криптографических алгоритмов, которым требуется больше ресурсов, чем предоставляют эти устройства.

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

Кроме того, может потребоваться разработка новых или совершенствование существующих механизмов безопасности для новых протоколов, специально созданных для Интернета вещей - например, Message Queuing Telemetry Transport (MQTT) и Constrained Application Protocol (CoAP). Поэтому при проектировании IoT-приложения особенно важно с самого начала учитывать вопросы безопасности.

Разработка защищенных IoT-приложений

Большинство IoT-решений состоит из трех основных уровней. Компоненты IoT-решения, функционирующие на каждом из этих уровней, должны иметь надлежащие средства безопасности для защиты от разнообразных уязвимостей.

  • Уровень устройств/шлюзов: Защита от "мошеннического" сервера, который отсылает злонамеренные команды, или от хакера, который пытается прослушивать приватные данные датчиков, отправляемые устройствами. Соображения относительно защиты этого уровня излагаются в первой части этого цикла (данная статья).
  • Уровень сети/транспорта: Защита от "мошеннического" устройства, отсылающего ложные результаты измерений, которые могли бы повредить данные, сохраняемые в приложении. Соображения относительно защиты этого уровня излагаются во второй части этого цикла.
  • Уровень приложений: Защита от некорректного использования данных или от манипулирования аналитическими процессами, которые исполняются на уровне приложений. Соображения относительно защиты этого уровня излагаются в третьей части этого цикла.

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

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

На следующей схеме показаны три уровня типичного IoT-приложения, которое использует сервис IBM Watson IoT Platform на уровне сети/транспорта и облачную платформу IBM Bluemix на уровне приложений.



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

Уровень Описание Вопросы безопасности
Приложения IoT-приложения, развернутые на платформе Bluemix.
  • Защита приложений
  • Вызов защищенного API-интерфейса сервиса IBM Watson IoT Platform
  • Защита Node-RED
  • Дешифрование сообщений
  • Верификация контрольной суммы сообщения
Сеть/транспорт IBM Watson IoT Platform предоставляет для IoT-приложений платформу обмена сообщениями на основе MQTT.
  • Аутентификация устройств (отсылать данные могут только доверенные устройства)
  • Авторизация
  • Защита API-интерфейса
  • Конфигурация защиты
  • Защищенный транспорт
Устройства/шлюзы Устройства (непосредственно или через шлюзы) публикуют данные датчиков в IBM Watson IoT Platform и получают инструкции по выполнению функций управления.
  • Аутентификация
  • Шифрование полезной нагрузки сообщения
  • Инициализация и верификация сертификата
  • Защищенный MQTT-транспорт
  • Защищенная начальная загрузка
  • Брандмауэры
  • Обновления и патчи микропрограммного обеспечения

Защита устройств

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

Кроме того, мы разработали (на JavaFX) программу-имитатор устройства, которая демонстрирует следующие механизмы безопасности:

  • Аутентификация по идентификатору пользователя / паролю
  • Аутентификация по одноразовому паролю (OTP)
  • Аутентификация по уникальному идентификатору сервера
  • Аутентификация полезной нагрузки сообщения

Имитатор устройства показан на следующем снимке экрана.

 

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

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

Сам протокол MQTT специфицирует лишь небольшое количество механизмов защиты, однако все его распространенные реализации поддерживают современные стандарты безопасности (например, SSL/TLS для защиты транспорта). Протокол MQTT не требует использовать определенный подход для защиты приложений на его основе, оставляя эту задачу на усмотрение проектировщика приложения. Это позволяет строить IoT-решения в зависимости контексте приложения и конкретных требований к защите.

В большинстве MQTT-развертываний используется TLS (transport layer security), поэтому данные подвергаются шифрованию, а и их целостность - валидации. Аналогично, в большинстве реализаций MQTT (в том числе в среде IBM Watson IoT Platform) для контроля доступа также используются средства авторизации на MQTT-сервере.

В дополнение к программе-имитатору устройства мы создали клиентское приложение брокера, который отображает MQTT-сообщения, полученные от устройства, и отсылает устройству примеры команд. Этот пример клиента приложения-брокера генерирует OTP-ключ для аутентификации устройства и отсылает уникальный идентификатор для верификации приложения устройствами. Чтобы протестировать различные сценарии, этот клиент генерирует сообщения команд (как действительные, так и недействительные).

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

Аутентификация устройств

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

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

В следующих разделах описываются некоторые из этих подходов. В качестве библиотеки MQTT-клиента в примерах программного кода используется Eclipse Paho.

Аутентификация по имени пользователя и паролю

Протокол MQTT предоставляет в сообщении CONNECT поля username и password для аутентификации устройства. При подключении к MQTT-брокеру клиент должен отослать имя пользователя и пароль.

Имя пользователя представляет собой строку в кодировке UTF-8, а пароль представляет собой двоичные данные. Максимальная длина каждого из них составляет 65535 байтов. Протокол MQTT не шифрует имя пользователя или пароль; если шифрование транспорта не используется, то эти сведения отсылаются в форме открытого текста.

Листинг 1. Поля user name и password
 try { MqttClient securedClient = new MqttClient(broker, clientId, persistence); MqttConnectOptions connOpts = new MqttConnectOptions(); connOpts.setCleanSession(true); connOpts.setUserName(userName); connOpts.setPassword(password.toCharArray()); System.out.println("Connecting to broker: "+broker); securedClient.connect(connOpts); System.out.println("Connected"); } catch(MqttException me) { System.out.println("reason "+me.getReasonCode()); System.out.println("msg "+me.getMessage()); System.out.println("loc "+me.getLocalizedMessage()); System.out.println("cause "+me.getCause()); System.out.println("excep "+me); me.printStackTrace(); }

Аутентификация по токену доступа

Если клиент успешно извлек токен доступа, он может отправить его брокеру с помощью поля password в сообщении CONNECT. После этого имя пользователя может представлять собой специальную строку для распознавания токена доступа. Предельный размер пароля в MQTT составляет 65535 байтов, соответственно длина токена не может превышать этот предел.

Брокер может использовать этот токен для осуществления различных проверок, в том числе следующих:

  • Проверка сигнатуры токена
  • Проверка срока действия данного токена на предмет его истечения
  • Проверка сервера авторизации на предмет аннулирования данного токена

Валидации, выполняемые при подключении устройства к MQTT-брокеру, можно использовать при публикации или подписке приложений. Однако при публикации или подписке брокер также должен авторизовать соответствующее приложение. Эта авторизация может быть осуществлена следующими двумя способами:

  • Токен включает авторизацию для клиента в сферу требования.
  • У брокера имеется сторонний источник (база данных или LDAP-каталог), в котором он ищет авторизации для клиента.

Приложения IBM Watson IoT Platform можно аутентифицировать по идентификатору приложения, по ключу и по токену. Ключ и токен IoT-приложения можно сгенерировать в процессе регистрации приложения, после чего их можно использовать при подключении к IBM Watson IoT Platform, как показано в следующем примере.

Листинг 2. Ключи и токены приложения
 App properties # Уникальный идентификатор, который вы выбрали сами, например, abcdefg123456 appid=<Your_application_id> # Поле ключа из информации App Keys, которую вы скопировали ранее key=<Key> # Поле Auth Token из информации App Keys, которую вы скопировали ранее token=<Token> App code during connection: strAuthMethod = props.getProperty("key"); strAuthToken = props.getProperty("token"); handler = new AppMqttHandler(); handler.connect(serverHost, clientId, strAuthMethod, strAuthToken, isSSL);

Аутентификация на основе одноразового пароля (OTP)

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

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

 

Листинг 3 В листинге 3 показано, как с помощью свойства устройства можно включать и выключать OTP-аутентификацию. Если OTP-аутентификация включена, устройство после запуска отсылает OTP-запрос IoT-приложению-брокеру с помощью обычного обмена MQTT-сообщениями.

Листинг 3. OTP-запрос
 // Создание запроса OTP JSONObject idObj1 = new JSONObject(); try { idObj1.put("event", "server_otp_request"); idObj1.put("deviceId", deviceIdentifier); } catch (JSONException e1) { System.out.println("Exception occurred"); e1.printStackTrace(); } new SendMessageToServer("server_otp_request", idObj1).start(); System.out.println("otp request sent...."); }

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

Листинг 4. Генерация одноразового пароля
 otp = IOTSecurityUtil.generateOTP(); JSONObject jsonObj = new JSONObject(); try { jsonObj.put("cmd", "server_otp_response"); jsonObj.put("otp", otp); jsonObj.put("appid", strAppId); jsonObj.put("time", new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date())); // Server starts a timer of 5 mins during which the // OTP is valid. task = new TimeOutTask(); t = new Timer(); t.schedule(task, 30000000L); } catch (JSONException e) { e.printStackTrace(); } System.out.println("Sending otp - " + otp); // Publish command to one specific device // iot-2/type/<type-id>/id/<device-id>/cmd/<cmd-id>/fmt/<format-id> new SendMessageToDevice(strDeviceId, "server_otp_response", jsonObj) .start();

Как показано в листинге Листинг 5, одноразовый пароль вводится в устройство, а устройство отсылает его приложению-брокеру. Приложение-брокер проверяет одноразовый пароль, отправленный устройством, и отсылает устройству сообщение success/failure (неверный одноразовый пароль или тайм-аут). Устройство может повторять OTP-аутентификацию исходя из количества повторных попыток, заданных в конфигурации.

Если OTP-аутентификацию не удалось пройти даже после повторных попыток, приложение завершает работу. Если OTP-аутентификация не была включена, то устройство после запуска пропустит OTP-аутентификацию.

Листинг 5. Проверка OTP-аутентификации
 if (receivedOTP.equals(otp)) { if (task.isTimedOut) { // Пользователь не реагирует более 100 секунд, одноразовый пароль неверен System.out.println("Time out!"); otpValidated = false; otpTimeOut = true; } else { System.out.println("OTP validated.."); otpValidated = true; otpTimeOut = false } } else { System.out.println("Incorrect OTP.."); otpValidated = false; otpTimeOut = false; } JSONObject otpRespObj = new JSONObject(); try { otpRespObj.put("cmd", "server_otp_validate"); otpRespObj.put("isOTPValid", String.valueOf(otpValidated)); otpRespObj.put("isTimeOut", String.valueOf(otpTimeOut)); otpRespObj.put("appid", strAppId); otpRespObj.put("time", new SimpleDateFormat( "yyyy-MM-dd HH:mm:ss").format(new Date())); } catch (JSONException e) { e.printStackTrace(); } System.out.println("Result of OTP validation - " + otpValidated); // Publish command to one specific device new sendMessageToDevice(strDeviceId, "server_otp_validate", otpRespObj).start(); }

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

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

В этой статье HiveMQ используется для демонстрации двусторонней SSL-аутентификации на основе сертификатов. При этом в качестве протокола для взаимодействия устройств используются только стандартные средства MQTT. Включенные в статью примеры кода, демонстрирующие шифрование/Дешифрование полезной нагрузки, были протестированы и в среде IBM Watson IoT Platform, и в среде HiveMQ.

Если у вас еще нет брокера HiveMQ, установите его, если вы хотите продолжать работу с данной статьей. HiveMQ можно легко загрузить, установить и запустить, выполнив инструкции на сайте hivemq.com. Для извлечения сохраненных сообщений из HiveMQ можно использовать дополнительные плагин. MQTT-клиент работает с HiveMQ таким же образом, как и с IBM Watson IoT Platform.

Демонстрационное приложение с программой-имитатором устройства и клиентом приложения MQTT-брокера демонстрируют аутентификацию на основе сертификатов. И устройство, и приложение выполняют взаимную верификацию сертификата с помощью HiveMQ.

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

Генерация сертификата

Выполните описанные ниже шаги, чтобы сгенерировать сертификат для аутентификации. В процедуре используется инструментарий keytool, поставляемый в комплекте со средой Java Runtime Environment.

  1. Генерация ключа устройства и хранилища ключей (keystore)
    keytool -genkey -alias iotdevice1 -keyalg RSA -keypass devicepass -storepass devicepass -keystore iot_device_keystore.jks -storetype jks
  2. Экспорт сертификата устройства из хранилища ключей
    keytool -export -alias iotdevice1 -storepass devicepass -file iotdevice1.cer -keystore iot_device_keystore.jks
  3. Добавление сертификата устройства в хранилище truststore брокера
    keytool -import -v -trustcacerts -alias iotdevice1 -file iotdevice1.cer -keystore iot_broker_truststore.jks -keypass devicepass -storepass brokerpass -storetype jks
  4. Генерация ключа брокера и хранилища ключей
    keytool -genkey -alias broker -keyalg RSA -keypass brokerpass -storepass brokerpass -keystore iot_broker_keystore.jks -storetype jks
  5. Экспорт сертификата брокера
    keytool -export -alias broker -storepass brokerpass -file broker.cer -keystore iot_broker_keystore.jks
  6. Добавление сертификата в хранилище truststore устройства
    keytool -import -v -trustcacerts -alias broker -file broker.cer -keystore iot_device_truststore.jks -keypass brokerpass -storepass brokerpass -storetype jks

Этот подход можно расширить на несколько устройств. Сертификаты всех устройств необходимо добавить в хранилище truststore брокера, а сертификат брокера должен находиться в хранилище truststore всех устройств.

Конфигурирование HiveMQ для аутентификации на основе сертификата

Как показано в листинге Листинг 6, конфигурирование HiveMQ с хранилищем keystore брокера и с хранилищем truststore брокера осуществляется с помощью файла config.xml.

Листинг 6. Конфигурирование MQTT-обработчика с хранилищами keystore и truststore брокера
 <tls-tcp-listener> <port>8883</port> <bind-address>0.0.0.0</bind-address> <tls> <keystore> <path><Your path>\iot_broker_keystore.jks</path> <password>brokerpass</password> <private-key-password>brokerpass</private-key-password> </keystore> <truststore> <path>C:\certificates\iot_broker_truststore.jks</path> <password>brokerpass</password> </truststore> <client-authentication-mode>REQUIRED</client-authentication-mode> </tls> </tls-tcp-listener>

Затем для MQTT-обработчика конфигурируются хранилища keystore и truststore устройства, как показано в следующем листинге:

Листинг 7. Конфигурирование MQTT-обработчика для работы с хранилищами keystore и truststore устройства
 if (isSSL) { java.util.Properties sslClientProps = new java.util.Properties(); // Задать свойства SSL sslClientProps.setProperty("com.ibm.ssl.protocol", "TLSv1.2"); sslClientProps.setProperty("com.ibm.ssl.contextProvider", "SunJSSE"); // Задать свойства keystore sslClientProps.setProperty("com.ibm.ssl.keyStore", "<Your_path>/iot_device_keystore.jks"); sslClientProps.setProperty("com.ibm.ssl.keyStorePassword", "devicepass"); sslClientProps.setProperty("com.ibm.ssl.keyStoreType", "JKS"); sslClientProps.setProperty("com.ibm.ssl.keyManager", "SunX509"); // Задать свойства truststore sslClientProps.setProperty("com.ibm.ssl.trustStore", "<Your_path>/iot_device_truststore.jks"); sslClientProps.setProperty("com.ibm.ssl.trustStorePassword", "brokerpass"); sslClientProps.setProperty("com.ibm.ssl.trustStoreType", "JKS"); sslClientProps.setProperty("com.ibm.ssl.trustManager", "SunX509"); // 'options' - это экземпляр MqttConnectOptions options.setSSLProperties(sslClientProps); }

Аутентификация с помощью сертификатов клиента

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

Сервис IBM Watson IoT Platform не поддерживает аутентификацию на основе сертификата клиента. Однако такую аутентификацию можно реализовать с использованием других брокеров, например, HiveMQ.

MQTT может использовать TLS для шифрования транспорта. Чтобы использовать TLS, у сервера должна иметься пара "открытый ключ/секретный ключ". В ходе процедуры TLS handshake клиентам необходимо проверить X509-сертификат сервера (который также содержит закрытый ключ сервера), прежде чем устанавливать безопасное соединение.

В дополнение к сертификатам сервера клиенты также могут иметь уникальную пару "открытый ключ/закрытый ключ", чтобы реализовать протокол TLS handshake. После валидации сертификата сервера клиент отсылает свой сертификат (содержащий закрытый ключ клиента) в рамках процедуры TLS handshake. После этого сервер может верифицировать идентификационные данные клиента и отменить процедуру handshake, если проверка сертификата клиента завершилась неудачей. Такой подход позволяет аутентифицировать клиента до установления безопасного соединения.

Реализация сертификатов клиентов имеет следующие преимущества:

  • Верификация идентификационных данных MQTT-клиентов
  • Аутентификация MQTT-клиентов на уровне транспорта
  • Блокировка недействительных MQTT-клиентов до отсылки сообщения MQTT CONNECT

В случае использования сертификатов клиентов установить защищенное соединение могут только доверенные клиенты. Такая конфигурация позволяет сэкономить ресурсы на стороне брокера, особенно если на стороне брокера используются дорогостоящие механизмы MQTT-аутентификации (неоднократный поиск в базе данных или вызовы веб-сервиса). Поскольку в процедуре TLS handshake имеет место аутентификация, эта аутентификация выполняется до установления соединения.

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

  • Развертывание сертификатов клиентов: Чтобы использовать сертификаты клиентов, необходимо иметь процесс развертывания сертификатов. Этот процесс определен, если предприятие контролирует свои устройства и располагает хорошо проработанным процессом обновления микропрограммного обеспечения. Развертывание сертификатов клиентов можно осуществлять в процессе обновления микропрограммного обеспечения. Кроме того, необходимо управлять жизненным циклом сертификатов в устройствах (включая истечение их срока действия).
  • Аннулирование сертификатов: Если сертификату клиента больше нельзя доверять (например, из-за утечки информации), этот сертификат необходимо аннулировать. Если имела места утечка данных сертификата и его используют злонамеренные клиенты, серверу нужен способ выявления недействительного сертификата и запрета на подключение клиентов с этим сертификатом.

Авторизация устройств

Механизм авторизации гарантирует отсутствие утечки данных между двумя устройствами.

MQTT - это протокол публикации/подписки на основе "темы" (topic). Каждое сообщение публикуется с какой-либо именованной темой, а каждая подписка имеет фильтр тем, который может включать подстановочные символы. Таким образом, авторизация осуществляется по именам публикаций/подписок и тем. У большинства MQTT-серверов имеется тот или иной способ предоставления полномочий на публикацию и подписку по темам.

В IBM Watson IoT Platform эта авторизация осуществляется принудительно путем реализации шаблонов защищенного обмена сообщениями. После того, как устройства аутентифицированы, им предоставляются полномочия на публикацию и подписку только в ограниченном пространстве тем, например:

  • /iot-2/evt/+/fmt/+
  • /iot-2/cmd/+

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

Авторизация приложения с использованием протокола OAuth 2.0

Если предприятие желает задействовать для MQTT-устройств свой централизованный механизм авторизации, оно может воспользоваться средой на базе протокола OAuth. Протокол OAuth 2.0 позволяет отделить сервер авторизации (например, MQTT-сервер) от сервера ресурса. При использовании OAuth 2.0 клиент представляет свои учетные данные серверу авторизации, который после этого выполняет аутентификационную проверку и возвращает токен доступа, дающий разрешение на обращение к ресурсу.

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

Проверка идентификатора приложения

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

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

Подробный поток показан на следующей схеме:

 

На схеме показаны следующие аспекты потока:

  • Проверка идентификатора приложения может быть включена/выключена в зависимости от возможностей устройства.
  • В случае перезапуска, если активированы проверка идентификатора приложения активирована и хранилище уникальных идентификаторов, устройство пытается восстановить уникальный идентификатор IoT-приложение из зашифрованного файла.
  • Если устройство не может загрузить уникальный идентификатор приложения, оно инициирует запрос на получение уникального идентификатора приложения.
  • После получения этого запроса IoT-приложение отсылает уникальный идентификатор устройству.
  • Устройство хранит уникальный идентификатор в памяти и в файле (если оно имеет возможности хранения информации).
  • После этого устройство предполагает, что этот же идентификатор приложения будет присутствовать в каждой команде, поступающей из IoT-приложения.
  • В случае несоответствия устройство игнорирует такую команду.

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

Защита устройств от других опасностей

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

  • Защита начальной загрузки.
    Безопасная начальная загрузка очень важна для защиты стартового кода от атак. В ходе начальной загрузки необходимо проверять подлинность и целостность устройства. Для подтверждения подлинности устройства можно использовать цифровую подпись.
  • Обновление микропрограммного обеспечения устройства.
    Устройство должно быть защищено от всех известных и неизвестных злонамеренных атак. Необходимо создать механизм установки регулярных патчей безопасности, который гарантировал бы получение регулярных обновлений всеми устройствами.
  • Журналирование и мониторинг инцидентов.
    Все потенциально возможные инциденты в сфере безопасности должны регистрироваться и постоянно отслеживаться. Любое подозрительное действие в устройстве должно немедленно инициировать прекращение регистрации устройства в брокере.

Защищенный транспорт

Сервис IBM Watson IoT Platform поддерживает протокол TLS 1.2, который можно использовать для защиты сообщений в процессе их передачи между устройством и брокером. Риск "взламывания" канала и несанкционированного доступа к сообщениям можно устранить, если защитить обеспечивающий транспортный уровень с помощью технологии SSL. В среде IBM Watson IoT Platform для поддерживаемых SSL-соединений используется порт 8883, как показано в листинге ниже.

Листинг 8. Шифрованный обмен данными с клиентом
 //tcp://<org-id>.messaging.internetofthings.ibmcloud.com:1883 //ssl://<org-id>.messaging.internetofthings.ibmcloud.com:8883 if (isSSL) { connectionUri = "ssl://" + serverHost + ":" + DEFAULT_SSL_PORT; } else { connectionUri = "tcp://" + serverHost + ":" + DEFAULT_TCP_PORT; } //If SSL is used, do not forget to use TLSv1.2 if (isSSL) { java.util.Properties sslClientProps = new java.util.Properties(); sslClientProps.setProperty("com.ibm.ssl.protocol", "TLSv1.2"); options.setSSLProperties(sslClientProps); }

В библиотеке IBM IoT starter library for Android and iOS предусмотрена ошибка Reference source not found, которая упрощает использование MQTT и SSL в вашем приложении. Вы можете использовать предоставляемый класс оболочки IoTClient, как показано в следующем листинге:

Листинг 9. Класс оболочки IoTClient
 IoTClient iotClient = IoTClient.getInstance( context, orgId, deviceId, deviceType, authToken ); try { IMqttToken mqttToken = iotClient.connectDevice( new DemoIoTCallbackHandler(), new DemoIoTActionListenerHandler(), (usingSSL ? createSslSocketFactory(context) : null) ); mqttToken.waitForCompletion(DemoIoTApplication.DEFAULT_MQTT_CONNECT_TIMEOUT); } catch(MqttException e) { Log.e("Error connecting to IBM Watson IoT Platform: "+e); }

Метод createSslSocketFactory определяется следующим образом:

Листинг 10. Метод createSslSocketFactory
 private SocketFactory createSslSocketFactory(Context context) { SocketFactory factory = null; try { ProviderInstaller.installIfNeeded(context); KeyStore ks = KeyStore.getInstance("bks"); ks.load( context.getResources().openRawResource(R.raw.iot), "password".toCharArray()); TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509"); tmf.init(ks); TrustManager[] tm = tmf.getTrustManagers(); SSLContext sslContext = SSLContext.getInstance("TLSv1.2"); sslContext.init(null, tm, null); factory = sslContext.getSocketFactory(); } catch (Exception e) { Log.e(TAG, "Error creating SSL factory: "+e); } return factory; }

Специальные шифрованные сообщения

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

В этой схеме приложение шифрует сообщение перед отсылкой его MQTT-брокеру. При этом устройство и IoT-приложение обмениваются шифром, который используется для шифрования/дешифрования сообщений. На данный момент сервис IBM Watson IoT Platform не поддерживает специального шифрования, однако его поддерживают некоторые другие MQTT-брокеры, например, HiveMQ.

Подробности взаимодействия с использованием специального шифрования описаны во второй части этого цикла.

Заключение

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

  • Используйте защищенные соединения, если IoT-данные являются конфиденциальными. Очень важны и аутентификация, и защищенный (шифрованный) обмен данными очень важны.
  • Используйте одноразовые пароли, когда требуется дополнительный слой защиты и когда степень физической безопасность устройства невысока (например, если доступ к физическому устройству может получить любое лицо).
  • Опираясь на возможности брокера, используйте такие механизмы, как OAuth, для поддержки внешних провайдеров авторизации.
  • Строго контролируйте авторизацию на подписку (например, с помощью определенных строк с фиксированными темами), чтобы злонамеренный клиент не мог получить доступ к большому числу подписок.
  • Ограничьте размер сообщений, чтобы никакие клиенты и устройства не могли самостоятельно блокировать брокера.
  • Если управление сертификатами для вас не является проблемой, рассмотрите такие возможности, как выпуск сертификатов клиентов и установление соединений только с клиентами, имеющими сертификаты.

Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Security
ArticleID=1039879
ArticleTitle=Проектирование и построение защищенных IoT-решений, часть 1: Защита IoT-устройств и шлюзов
publish-date=11152016