Защищённое решение, которое подключает IoT-устройства к облаку

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

　　Для решения этих проблем и упрощения внедрения функций безопасности в устройствах IoT компания Microchip Technology и Google совместно создали метод, объединяющий защищённые аппаратные функции Microchip с простой структурой данных под названием JSON Web Token (JWT). В результате появился простой способ обеспечить взаимную аутентификацию между устройствами IoT и основными сервисами Google Cloud IoT.

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

　　Уязвимости безопасности в устройствах IoT

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

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

　　Safety IC

　　Специализированные устройства безопасности, такие как CryptoMemory и IC CryptoAuthentication от Microchip Technology, оснащены аппаратными функциями, основанными на механизмах защиты приватных ключей и других секретных данных. Массивы EEPROM интегрированы в эти устройства, обеспечивая защищённые механизмы хранения и шифрования, доступные только через последовательный интерфейс SPI или I2C устройства (см. рисунок 1). Таким образом, эти устройства предлагают простой способ добавить защищённое хранилище и другие функции безопасности в любой дизайн IoT-устройства.

　　Рисунок 1: Аппаратные устройства безопасности Microchip Technology (такие как AT88SC0204C CryptoMemory IC) обеспечивают безопасное хранение и используют интегрированные механизмы шифрования для защиты доступа к встроенным EEPROM. (Изображение: Microchip Technology)

　　Участники серии Microchip CryptoAuthentication (например, ATECC608A) укрепляют основы защищённого хранения и поддерживают алгоритмы шифрования, широко используемые в проектировании безопасности. Среди аппаратных особенностей устройства — аппаратное ускорение различных алгоритмов, включая:

　　Алгоритм асимметричного шифрования:

　　FIPS186-3 Алгоритм цифровой подписи эллиптической кривой (ECDSA)

　　FIPS SP800-56A Эллиптическая кривая Диффи-Хеллмана (ECDH)

　　Стандарт NIST P256 Эллиптическое шифрование кривой (ECC)

　　Алгоритм симметричного шифрования:

　　Хеш-код SHA-256

　　Криптография с кодом аутентификации сообщений на основе хэша (HMAC)

　　AES-128 Криптография

　　Криптография AES-GCM (умножение поля Галуа)

　　Функция вывода ключей (KDF):

　　Псевдослучайная функция (PRF) KDF

　　Экстракция на основе HMAC и расширение KDF (HKDF)

　　Для криптоэкспертов этот набор возможностей шифрования представляет собой полный список механизмов, необходимых для поддержки более высокоуровневых протоколов безопасности. Аутентификация и безопасный обмен данными. Например, функция KDF предоставляет базовые механизмы, необходимые для протоколов безопасности транспортного уровня (TLS) для проверки участников сессий обмена данными до их или даже их начала.

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

　　Протокол аутентификации TLS является основой интернет-безопасности. Вся индустрия поставщиков сертификатов, известная как Сертификационный центр (CA), превратилась в ключевой компонент, поддерживающий безопасные коммуникации. Компания получает доверенный сертификат от CA для установки на собственных серверах, поддерживающий вышеупомянутый стандартный протокол аутентификации сервера TLS.

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

　　Несмотря на риски, разработчики IoT часто испытывают трудности с внедрением протоколов взаимной аутентификации TLS, поскольку сертификаты, ключи и программное обеспечение, необходимые для аутентификации клиентов с помощью TLS, могут превышать возможности многих IoT-устройств. Благодаря сотрудничеству Microchip Technology и Google создали альтернативный подход, сочетающий ATECC608A функциональность с простой структурой данных под названием JSON Web Token (JWT). В результате появился простой способ обеспечить взаимную аутентификацию между устройствами IoT и основными сервисами Google Cloud IoT.

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

　　RFC 7519 определяет, что JWT является отраслевым стандартом для информации о организации, готовящей и передающей JWT, известный как претензия. Сама структура JWT состоит из трёх частей:

　　Названия, включая имя JSON: название криптографического алгоритма («alg») (например, ECDSA «EC256» использует кривую NIST P-256) для подписания токенов и типов токена («тип») («JWT» этих токенов)

　　Полезная нагрузка, включая имя JSON: пару значений для каждой претензии

　　Signature: использует алгоритм, указанный в заголовке, для кодирования ключа, заголовка и набора объявлений, каждый из которых индивидуально конвертируется в кодировку URL base64 до шифрования

　　RFC 7519 обеспечивает большую гибкость для указания заявлений на полезные нагрузки или другие детали. Стандарт даже допускает небезопасные JWT, созданные без подписи или шифрования, в этом случае заголовок будет содержать имя алгоритма: пару значений {{alg":"none"}. Для JWT, используемых с основными сервисами Google Cloud IoT, Google требуется раздел подписей и полезная нагрузка с тремя обязательными объявлениями, включая:

　　«iat» — «время выпуска» при создании токена в формате временной метки ISO 8601 UTC, количество секунд с 1970-01-01T00:00:00Z (например, 1561896000 12:00 GMT 30 июня 2019 года)

　　"exp" — временная метка UTC, указывающая время истечения токена, до 24 часов, превышающих значение "IAT" плюс 10-минутный льготный период, чтобы устранить различные системные тактовые смещения между клиентом и сервером (например, 1 июля 2019 1561982400, GMT 00:00 00:00)

　　«aud» — строка, содержащая идентификатор проекта Google Cloud разработчика

　　< p> решение Google для аутентификации устройств IoT сочетает традиционную серверную аутентификацию на основе TLS с JWT, созданной с помощью относительно простых объявлений для аутентификации устройств IoT. Для начала новой сессии IoT-устройство открывает защищённый сокет, входящий в сервер и аутентифицирует сервер с помощью того же протокола TLS, описанного ранее.

　　Следующий шаг в этом процессе — это протокол передачи телеметрии в очереди сообщений (MQTT) от Google IoT Cloud для транзакций в сети IoT. Используя защищённый сокет для аутентифицированного сервера, IoT-устройство использует свой уникальный JWT в качестве пароля для входа в сервис MQTT на этом сервере (Инвентарь 1).

　　Хотя IoT-устройства отправляют имена пользователей в рамках этой последовательности входа, имена пользователей не используются для аутентификации. Поэтому было передано виртуальное имя пользователя (Listing 2). Вместо этого аутентификация IoT-устройства основана на JWT, отправленном в качестве пароля для входа. Поскольку подписи JWT представляют собой комбинацию заголовков, полезных нагрузок и приватных ключей устройств, сервисы Google Cloud IoT могут проверять, действительно ли JWT исходит от авторизованных устройств. Для этой проверки Google Cloud IoT Services использует публичные ключи устройств, ранее хранящиеся в Google Cloud разработчиками IoT-устройств, используя описанный ниже процесс управления ключами. По сравнению с использованием только TLS, этот подход обеспечивает взаимную аутентификацию через гибридный подход, ускоряя процессы и снижая потребности в ресурсах для IoT-устройств.

　　Ключевые факторы

　　ATECC608A и функциональность её цепочки поставок являются ключевыми факторами такого подхода. Хотя любой микроконтроллерный процессор может в конечном итоге генерировать зашифрованные сигнатуры шифрования из заголовков и полезных нагрузок JWT, любой программный метод всё равно уязвим для атак без аппаратного хранения ключей безопасности. Кроме того, для многих ограниченных ресурсами IoT-устройств или приложений с строгими требованиями к времени отклика может быть запрещена задержка нагрузки процессора и выполнения, необходимая для «только программной» реализации. Наконец, без обширных алгоритмов безопасности и более продвинутогося опыта работы с протоколами разработчикам сложно реализовать необходимые программные функции. Microchip решает эти проблемы через свою библиотеку CryptoAuthLib (рисунок 2).

　　Рисунок 2: Поскольку CryptoAuthLib использует аппаратный уровень абстракции (HAL) для разделения функций API и основных примитивов от базового оборудования, разработчики могут позиционировать своё программное обеспечение для различных поддерживающих устройств. (Изображение: Microchip Technology)

　　Microchip CryptoAuthLib упрощает реализацию защищённых функций IoT, таких как протокол аутентификации Google JWT, сводя сложные операции безопасности до набора вызовов функций, предоставляемых через интерфейс прикладного программирования CryptoAuthLib (API). Для разработчиков IoT, возможно, самой важной является основная функция Microchip CryptoAuthLib, которая полностью использует микрочиповые шифровательные ИС, такие как ATECC608A, для ускорения выполнения функций безопасности при проектировании. Например, в Листинге 1 вызов atca_jwt_finalize() использует доступные устройства шифрования (такие как ATECC608A) для создания JWT для пароля в Листинге 2. В этом случае, ATECC608A ускорить шифрование подписей JWT, считывайте дизайн от интегрированного защищённого ключа хранения до завершения процесса создания подписи, описанного ранее.

　　Однако даже при использовании сложного программного обеспечения и устройств безопасности устройства IoT остаются уязвимыми к атакам благодаря традиционным методам управления ключами и сертификатами. Ранее приватные ключи приходилось генерировать снаружи и загружать на защищённые хранилища во время производства, распространения или даже развертывания. Даже при использовании аппаратных модулей безопасности и средств безопасности, кратковременные существующие секреты, выходящие за рамки единственного устройства, которое их «нужно знать», представляют собой уязвимости, которые могут быть случайно или намеренно раскрыты. Используя ATECC608A возможности, Microchip и Google в значительной степени устранили традиционные уязвимости безопасности.

　　В этом новом подходе Microchip использует возможность ATECC608A генерировать пары ключей без сохранения приватного ключа (рисунок 3). Microchip затем использует промежуточный сертификат для подписания публичного ключа, сгенерированного устройством, который предоставляется клиентом и хранится на защищённом сервере в рамках защитных систем Microchip. Наконец, Microchip безопасно передаёт публичный ключ в аккаунт клиента в Google Cloud IoT Device Manager, который может хранить до трёх публичных ключей на устройство для поддержки политики ротации ключей. После развертывания IoT-устройства могут использовать ATECC608A функции безопасности для создания JWT, используемых в процессе взаимной аутентификации, описанном выше.

　　Рисунок 3: Сочетание технологии микрочипов и сервисов Google Cloud IoT упрощает конфигурацию ключей и сертификатов, обеспечивая защищённый механизм, направленный на укрепление безопасности приложений IoT. (Изображение: Google)

　　Это сотрудничество между Microchip и Google позволяет разработчикам полностью избавиться от этого критически важного процесса управления ключами. Для пользовательских требований разработчики могут использовать функцию CryptoAuthLib API atcab_genkey() для реализации собственного процесса управления ключами, что позволяет ATECC608A генерировать пары ключей, хранить приватные ключи в их защищённом хранилище и возвращать соответствующий публичный ключ. /p>

　　Для изучения ключевой генерации и других ATECC608A функций безопасности разработчики могут быстро создать комплексную среду разработки, основанную на оценочном наборе Microchip SAM D21 Xplained Pro. Основанный на Microchip ATSAMD21J18A 32-битном Arm ® Cortex-M0 ® + MCU, комплект SAM D21 Xplained Pro предоставляет полный аппаратный драйвер платформы и модуль кода, поддерживаемый Advanced Software Framework (ASF) от Microchip.

　　Для оценки устройств CryptoAuthentication, включая ATECC608A, разработчики могут просто вставить дополнительную плату CryptoAuth XPRO-B в одну из двух головок расширения платы Xplained Pro. Microchip предоставляет примерное программное обеспечение для оценки функций безопасности CryptoAuthLib и ATECC608A. Кроме того, разработчики могут вставить Wi-Fi дополнительную плату Microchip ATWINC1500-XPRO в другой заголовок для запуска программного обеспечения Microchip sample, что демонстрирует процесс взаимной аутентификации, описанный в этой статье, включая аутентификацию сервера TLS-сервера и аутентификацию устройств JWT.

　　Заключение

　　Хотя безопасность приложений IoT предъявляет множество требований, ключевая задача часто заключается в реализации взаимной аутентификации для устройств IoT и облачных ресурсов. В системах IoT, ограниченных по ресурсам, традиционные протоколы могут превышать доступную память и вычислительные ресурсы. Используя библиотеку CryptoAuthLib от Microchip Technology и ATECC608A CryptoAuthentication IC, разработчики могут реализовать более эффективный подход на основе JSON Web Tokens для безопасного подключения IoT-устройств к сервисам Google Cloud IoT.