Рекомендации по обеспечению безопасности для изготовителей устройств Интернета вещей Azure

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

  • Выбор способа проверки подлинности устройства
  • Установка сертификатов на устройствах Интернета вещей
  • Интеграция доверенного платформенного модуля (TPM) в процесс производства

Выбор способа проверки подлинности устройства

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

Существуют три широко используемых типа проверки подлинности: сертификаты X.509, доверенные платформенные модули (TPM) и симметричные ключи. Хотя есть и другие типы проверки подлинности, большинство клиентов, которые создают решения в Интернете вещей Azure, используют один из этих трех. В остальной части этой статьи рассматриваются преимущества и недостатки использования каждого типа проверки подлинности.

Сертификат X.509

Сертификаты X.509 — это тип цифрового удостоверения, который можно использовать для проверки подлинности. Стандарт сертификата X.509 описан в документе IETF RFC 5280. Интернет вещей Azure предоставляет два способа проверки подлинности сертификатов.

  • Отпечаток. Алгоритм отпечатка выполняется на сертификате для создания шестнадцатеричной строки. Созданная строка — это уникальный идентификатор сертификата.
  • Проверка подлинности центра сертификации на основе полной цепочки. Цепочка сертификатов — это иерархический список всех сертификатов, необходимых для проверки подлинности сертификата конечного субъекта (EE). Чтобы проверить подлинность сертификата EE, необходимо выполнить проверку подлинности для каждого сертификата в цепочке, включая доверенный корневой центр сертификации.

Преимущества X.509:

  • X.509 — это наиболее безопасный тип проверки подлинности, поддерживаемый Интернетом вещей Azure;
  • X.509 обеспечивает высокий уровень контроля для управления сертификатами;
  • многие поставщики предлагают решения для проверки подлинности на основе X.509.

Недостатки X.509:

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

Доверенный платформенный модуль (TPM)

TPM, также известный как ISO/IEC 11889, является стандартом для безопасного создания и хранения криптографических ключей. TPM также относится к виртуальному или физическому устройству ввода-вывода, которое взаимодействует с модулями, реализующими этот стандарт. Устройство доверенного платформенного модуля может быть выполнено в виде дискретного аппаратного средства, интегрированного аппаратного средства, модуля на основе встроенного ПО или модуля на основе программного обеспечения.

Между TPM и симметричными ключами существует два ключевых различия:

  • Модули TPM также могут хранить сертификаты X.509.
  • Аттестация доверенного платформенного модуля в DPS использует ключ аутентификации доверенного платформенного модуля, который является формой асимметричной проверки подлинности. При использовании асимметричной проверки подлинности для шифрования применяется открытый ключ, а для расшифровки используется отдельный закрытый ключ. Симметричные ключи, напротив, используют симметричную проверку подлинности, где закрытый ключ применяется как для шифрования, так и для расшифровки.

Преимущества доверенного платформенного модуля:

  • TPM входят в стандартную комплектацию многих устройств с Windows и имеют встроенную поддержку операционной системы.
  • Аттестация TPM (доверенного платформенного модуля) проще в защите, чем аттестация на основе токена симметричного ключа (маркер общей подписи доступа, SAS).
  • Вы можете легко аннулировать, обновить или продлить учетные данные устройства. Служба DPS автоматически обновляет учетные данные IoT Hub, когда необходимо переподготовить TPM-устройство.

Недостатки TPM: доверенного платформенного модуля

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

Симметричный ключ

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

Преимущества симметричного ключа:

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

Недостатки симметричного ключа:

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

Общий симметричный ключ

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

Преимущество общего симметричного ключа:

  • Легко реализовать и недорого производить в больших объемах.

Недостатки общего симметричного ключа:

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

Выбор правильного решения для устройств

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

Установка сертификатов на устройствах Интернета вещей

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

Если вы привыкли использовать пароли, вы можете задаться вопросом, почему вы не можете использовать один и тот же сертификат на всех устройствах, аналогично тому, как можно использовать один и тот же пароль. Во-первых, использование одного и того же пароля везде рискованно и привело к значительным атакам DDoS, таким как тот, который нарушил DNS на восточном побережье США несколько лет назад. Никогда не используйте пароли повторно, даже для личных учетных записей. Во-вторых, сертификат не является паролем; это уникальное удостоверение. Пароль похож на секретный код, который любой пользователь может использовать для разблокировки двери в безопасном здании- это то, что вы знаете и можете поделиться. В отличие от этого, сертификат похож на водительскую лицензию с фотографией и подробностями, которые вы показываете охраннику, чтобы получить доступ. Это связано с вашей личностью. Если охранник правильно сопоставляет людей с их лицензиями, только вы можете использовать свою лицензию (удостоверение) для входа.

Переменные, используемые в процессе принятия решений о сертификатах

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

Откуда берется корень доверия сертификата

Управление инфраструктурой открытых ключей (PKI) может быть дорогостоящим и сложным. Особенно если у вашей компании отсутствует опыт управления инфраструктурой открытых ключей. Можно выполнить следующие действия:

  • Используйте стороннюю PKI. Промежуточные сертификаты для подписи можно приобрести у стороннего поставщика сертификатов. Можно также использовать частный центр сертификации.
  • Используйте самоуправляемую инфраструктуру открытых ключей. Можно поддерживать собственную систему инфраструктуры открытых ключей и создавать собственные сертификаты.

Где хранить сертификаты

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

  • В аппаратном модуле безопасности (HSM). Настоятельно рекомендуется использовать аппаратные модули безопасности (HSM). Убедитесь, что на панели управления устройства уже установлен HSM. Если вы уверены, что у вас нет аппаратного модуля безопасности, обратитесь к производителю аппаратного обеспечения, чтобы найти аппаратный модуль безопасности, соответствующий вашим потребностям.
  • В безопасном месте на диске, например в доверенной среде выполнения (TEE).
  • В локальной файловой системе или хранилище сертификатов. Например, в хранилище сертификатов Windows.

Связь на производстве

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

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

Требования к аудиту

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

  • Не является конфиденциальной отраслью. Аудит не требуется.
  • Конфиденциальная отрасль. Сертификаты должны быть установлены в защищенном помещении в соответствии с требованиями сертификации соответствия. Если вам нужна безопасная комната для установки сертификатов, скорее всего, вы уже знаете, как сертификаты устанавливаются на ваших устройствах. Вероятно, у вас также уже есть система аудита.

Срок действия сертификата

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

Когда следует создавать сертификаты

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

  • Предварительно загруженные сертификаты. Некоторые поставщики HSM предлагают дополнительную услугу, при которой поставщик HSM устанавливает сертификаты для клиента. Сначала клиенты предоставляют поставщику HSM доступ к сертификату для подписи. Затем поставщик HSM устанавливает сертификаты, подписанные с помощью этого сертификата для подписи, на каждый HSM, который покупает клиент. Все, что требуется от клиента, — это установить HSM на устройство. Хотя эта услуга требует дополнительных затрат, она помогает упростить производственный процесс. Кроме того, она снимает вопрос о том, когда устанавливать сертификаты.
  • Сертификаты, созданные устройством. Если устройства создают сертификаты автоматически, необходимо извлечь общедоступный сертификат X.509 с устройства, чтобы зарегистрировать его в DPS.
  • Подключенное производство Если на предприятии есть возможность подключения, можно создавать сертификаты устройств тогда, когда они требуются.
  • Автономное производство с собственной инфраструктурой открытых ключей. Если у вашей фабрики нет подключения, и вы используете собственный PKI с автономной поддержкой, вы можете создать сертификаты, если они нужны.
  • Автономное производство со сторонней инфраструктурой открытых ключей. Если у вашей фабрики нет подключения, и вы используете сторонний PKI, необходимо заранее создать сертификаты. И необходимо генерировать сертификаты из места, имеющего подключение.

Когда устанавливать сертификаты

После создания сертификатов для устройств Интернета вещей их можно установить на устройства.

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

Если вы не используете предварительно загруженный сертификат, необходимо установить сертификат в рамках рабочего процесса. Самый простой подход — установить сертификат в HSM одновременно с установлением начального образа встроенного ПО. Этот процесс должен содержать шаг для установки образа на каждое устройство. После выполнения этого шага можно выполнить окончательные проверки качества и другие действия, прежде чем приступать к упаковке и поставке устройства.

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

После установки сертификатов на устройствах следует узнать, как зарегистрировать устройства с помощью DPS.

Интеграция доверенного платформенного модуля в производственный процесс

В этом разделе содержатся рекомендации по использованию доверенного платформенного модуля для проверки подлинности устройств Интернета вещей. В руководстве описаны широко используемые устройства TPM 2.0, которые имеют поддержку ключа кода проверки подлинности сообщений с помощью хэш-функций (HMAC). Спецификация TPM для чипов TPM — это стандарт ISO, поддерживаемый Группой доверительных вычислений. Дополнительные сведения о доверенном платформенном модуле см. в спецификациях для TPM 2.0 и ISO/IEC 11889.

Взятие на себя ответственности за TPM

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

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

Внимание

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

Общая временная шкала производства

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

Шаг 1: TPM производится

  • Если вы покупаете модули TPM у производителя для использования в ваших устройствах, уточните, извлекают ли они для вас ключи открытого утверждения (EK_pubs). Это полезно, если производитель предоставляет список EK_pubs с поставляемыми устройствами.

    Примечание.

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

  • Если вы производите ТПМ для продажи производителям устройств, рассмотрите предоставление вашим клиентам списка EK_pub вместе с их физическими ТПМ. Предоставление клиентам EK_pubs позволяет им сэкономить время в процессе.

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

Шаг 2. Устройство комплектуется доверенным платформенным модулем (TPM).

На этом этапе рабочего процесса следует знать, с каким экземпляром DPS используется устройство. В результате вы сможете добавить устройства в список для регистрации для автоматической настройки. Дополнительные сведения об автоматической подготовке устройств см. в документации DPS.

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

Шаг 3. На устройстве установлено встроенное ПО и программное обеспечение

На этом этапе процесса установите клиент DPS вместе с областью идентификатора и глобальным URL-адресом для предоставления.

  • Сейчас последняя возможность извлечь EK_pub. Если сторонняя сторона устанавливает программное обеспечение на своем устройстве, рекомендуется сначала извлечь EK_pub.
  • Этот этап производственного процесса идеально подходит для того, чтобы взять на себя ответственность за ТПМ.

    Примечание.

    Если вы используете программный TPM, вы можете установить его сейчас. Одновременно с этим извлеките EK_pub.

Шаг 4. Устройство упаковывается и отправляется на склад

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

Шаг 5. Устройство установлено на место

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

Дополнительные сведения см. в разделе Подготовка и Аттестация доверенного платформенного модуля.

Ресурсы

В дополнение к рекомендациям по обеспечению безопасности, приведенным в этой статье, Интернет вещей Azure предоставляет ресурсы, которые помогут выбрать безопасное аппаратное обеспечение и создать безопасные развертывания Интернета вещей:

  • Last updated on