Если устройство заперто и недоступно, доступ к нему мог получить только уполномоченный персонал. Как только устройства начали подключаться к интернету и стали доступными за пределами помещения или завода, их уязвимость многократно выросла. Печальные последствия использования одного и того же пароля для всех устройств одного продуктового семейства стали очевидны после таких атак как Mirai в 2016 г. Эта атака позволила «завербовать» миллионы встроенных устройств в ботнеты для запуска атак типа DoS («отказ в обслуживании») на другие системы.

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

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

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

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

Рис. 1. Пример цепочки сертификатов

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

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

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

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

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

 

Рис. 2. Процесс исполнения заказов Trust Platform компании Microchip

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

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

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

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

 

Рис. 3. Схема типового цикла взаимодействия с клиентом

Чтобы обеспечить более гибкий подход к управлению безопасностью и сертификатами, компания Microchip разработала Trust Platform – доверенную платформу, у которой в качестве аппаратного ядра используется элемент безопасности ATECC608a. Множество автоматизированных сервисов позволяют клиентам выбирать требуемую стратегию сертификации для каждого устройства, а также набор средств разработки и исходный код, реализующие обычные меры аутентификации и обеспечения безопасности.

Trust Platform предоставляет элементы безопасности трех уровней. Уровень Trust&GO, основанный на архитектуре только сертификатов устройств, позволяет создавать безопасную аутентификацию и отправлять эти сертификаты без секретного пользовательского обмена. Все операции по регистрации выполняются надежными облачными партнерами – AWS, Google и Microsoft Azure. Учитывая, что минимальный заказ (включающий предоставление ключей) составляет всего 10 ед., сервис подходит для прототипирования и тестирования на месте эксплуатации, а также для мелкосерийной продукции, которая используется в сетях LoRaWAN и в системах с шифрованием TLS.

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

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

Как известно, встраиваемые системы интернета вещей чувствительны к затратам. Упомянутые дополнительные расходы выходят за рамки стоимости перечня компонентов и влекут за собой увеличение производственных расходов. Платформа Trust Platform компании Microchip предоставляет разработчикам встраиваемых систем возможность экономически эффективно использовать преимущества уникальной идентификации и удаленной аутентификации в масштабируемой цепочке поставок.

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

Размещение информации в журнале