Проблемы безопасности сетей настолько остры, что даже правительства разных стран принимают законы, цель которых – защитить компьютеры и другие устройства пользователей от взлома. К сожалению, с проблемой киберпреступности не справиться только законодательными мерами. Атаки хакеров становятся все более изощренными и часто нацелены одновременно на несколько устройств, что, в конечном итоге, приводит к распределенному отказу в обслуживании (DDoS).

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

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

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

Если хакеры имеют доступ к шлюзам, они могут перехватывать информацию с помощью т.н. «атаки через посредника» (man-in-the-middle attack). После подключения своих устройств к серверу злоумышленники могут атаковать другие области системы или нарушить работу основных служб.

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

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

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

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

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

Еще одна проблема возникает после приобретения изделия конечным пользователем. Хакер, имеющий физический доступ к изделию или доступ к изделию через сеть, может извлечь ключи или повредить устройство, если энергонезависимая память не защищена. Исправить ситуацию можно с помощью аппаратного корня доверия, который гарантирует защиту от несанкционированного доступа и защиту от атак через другие каналы, а также проверяет аутентичность загружаемого ПО.

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

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

 

Рис. 1. Упрощенная схема подключения элемента безопасности к МК

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

Когда МК загружает ПО из загрузчика bootROM, он запрашивает ключ, хранящийся в элементе безопасности ATECC608a. Связь с удаленным сервером может осуществляться с помощью протоколов PKI, которые получают эфемерные ключи (создаваемые, как правило, для однократного использования), необходимые для сеансов TLS. Если закрытый ключ формируется непосредственно при производстве на фабах Microchip, он никуда не передается. Его сохранность обеспечивают аппаратные модули защиты.

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

Кроме того, предусмотрены меры защиты от атак через побочные каналы: сбои, анализ мощности потребления, использование инструментов тестирования и др. Microchip поставляет элемент безопасности с уже сгенерированным ключом, что исключает влияние третьих лиц, вовлеченных в цепочку поставок и программирования компонентов. Элемент безопасности делает практически невозможной атаку через посредника и гарантирует, что устройство коммутируется с авторизованным сервером с помощью PKI.

Компания Microchip посылает клиенту сертификаты или открытые ключи, которые формируются перед отправкой с помощью модулей HSM. Эти сертификаты или ключи можно использовать непосредственно на локальном сервере или у поставщика облачных услуг, например Amazon WebServices(AWS) и Google Cloud Platform. После соединения устройство IoT становится членом сети с надежной защищенной идентификацией и может передавать данные с использованием безопасных протоколов, например TLS.

Однако для простейших узлов сети такая защита может оказаться избыточной, и ее аппаратное обеспечение увеличит стоимость узла. Для таких случаев провайдеры облачных услуг разработали упрощенные механизмы безопасности соединения. Они используют все преимущества PKI, но не требуют полных сертификатовX.509 на каждом конечном устройстве. Например, GoogleCloud в партнерстве с Microchip обеспечивает безопасную инициализацию и работу даже самых простых устройств IoT. Структурная схема описанного упрощенного механизма приведена на рисунке 2.

 

Рис. 2. Структурная схема описанного упрощенного механизма безопасного соединения

Основная авторизация Google Cloud IoT не требует полных цифровых сертификатов. Вместо них используются более простые «веб-токены JSON» (JWT), которые формируются на основе закрытого ключа, хранящегося в элементе безопасности ATECC608a. Google Cloud принимает вместо пароля веб-токен и использует его для авторизации нового устройства в сети и привязки его к цифровому двойнику в облаке. Такой упрощенный протокол можно реализовать на самых простых 8-бит МК. Описанный механизм обеспечивает сквозную безопасную обработку учетных данных устройства, позволяя получить безопасный доступ к облачным сервисам практически из любой точки мира, даже если у пользователей нет своего сервера.

Шифр статьи: МСА772

Статьи, реклама, подписка на журнале Электронные Компоненты: anton.denisov@ecomp.ru