Сведения об использовании сертификатов в Azure IoT Edge

Область применения: IoT Edge 1.5

IoT Edge использует разные типы сертификатов для разных целей. В этой статье объясняется, как IoT Edge использует сертификаты с помощью Центра Интернета вещей Azure и сценариев шлюза IoT Edge.

Итоги

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

Необходимые компоненты

• Вам потребуется базовое понимание шифрования, пар ключей и способ шифрования или расшифровки данных с открытым ключом и закрытым ключом. Дополнительные сведения о том, как IoT Edge использует криптографию открытого ключа, см. в статье "Общие сведения о шифровании открытых ключей" и инфраструктуре открытых ключей X.509.
• Вам нужно базовое представление о том, как IoT Edge связан с Центром Интернета вещей. Дополнительные сведения см. в статье "Общие сведения о среде выполнения Azure IoT Edge" и его архитектуре.

Сценарий одного устройства

Чтобы узнать о понятиях сертификатов IoT Edge, представьте сценарий, в котором устройство IoT Edge с именем EdgeGateway подключается к Центру Интернета вещей Azure с именем ContosoIotHub. В этом примере вся аутентификация выполняется с использованием сертификата X.509 вместо симметричных ключей. Чтобы установить доверие в этом сценарии, необходимо гарантировать подлинность устройства Центр Интернета вещей и IoT Edge: "Является ли это устройство подлинным и допустимым?" и "Правильно ли удостоверение Центр Интернета вещей?". Вот иллюстрация сценария:

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

Устройство проверяет удостоверение Центр Интернета вещей

Как EdgeGateway проверяет, что он разговаривает с реальным ContosoIotHub? Когда EdgeGateway взаимодействует с облаком, он подключается к конечной точке ContosoIoTHub.Azure-devices.NET. Чтобы убедиться, что конечная точка является аутентичной, IoT Edge требует ContosoIoTHub для отображения идентификации (идентификатора). Идентификатор должен быть выдан центром, которому доверяет EdgeGateway . Чтобы проверить идентичность IoT Hub, IoT Edge и IoT Hub используют протокол рукопожатия TLS для проверки удостоверения сервера IoT Hub. Следующая схема показывает рукопожатие TLS. Некоторые детали опускаются, чтобы упростить. Дополнительные сведения о протоколе подтверждения TLS см. в разделе "Подтверждение TLS" в Википедии.

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

В нашем сценарии ContosoIotHub отображает следующую цепочку сертификатов:

Корневой центр сертификации (ЦС) — это корневой сертификат Baltimore CyberTrust. DigiCert подписывает этот корневой сертификат, и он широко доверяется и хранится во многих операционных системах. Например, Ubuntu и Windows включают его в хранилище сертификатов по умолчанию.

Хранилище сертификатов Windows:

Хранилище сертификатов Ubuntu:

Когда устройство проверяет корневой сертификат Балтимора CyberTrust , он уже находится в ОС. С точки зрения EdgeGateway так как цепочка сертификатов из ContosoIotHub подписана корневым ЦС, которому доверяет ОС, сертификат является надежным. Этот сертификат называется сертификатом сервера Центра Интернета вещей. Дополнительные сведения о серверном сертификате Центра Интернета вещей см. в статье Поддержка Transport Layer Security (TLS) в Центре Интернета вещей.

В итоге EdgeGateway может проверить и доверять удостоверению ContosoIotHub, так как:

• ContosoIotHub представляет свой сертификат сервера Центр Интернета вещей
• Сертификат сервера является доверенным в хранилище сертификатов ОС
• Данные, зашифрованные с помощью открытого ключа ContosoIotHub, можно расшифровывать с помощью ContosoIotHub, доказывая его владение закрытым ключом.

Центр Интернета вещей проверяет удостоверение устройства IoT Edge

Как ContosoIotHub проверяет, что он взаимодействует с EdgeGateway? Так как Центр Интернета вещей поддерживает взаимную TLS (mTLS), он проверяет сертификат EdgeGateway во время TLS рукопожатия, аутентифицированного клиентом. Для простоты мы пропустим некоторые шаги на следующей схеме.

В этом случае EdgeGateway предоставляет свой сертификат удостоверения устройства IoT Edge. С точки зрения ContosoIotHub он проверяет, соответствует ли отпечаток предоставленного сертификата его записи, и что EdgeGateway имеет закрытый ключ, связанный с сертификатом, который он представляет. При подготовке устройства IoT Edge в Центр Интернета вещей вы предоставляете отпечаток. Центр Интернета вещей использует отпечаток для проверки сертификата.

Например, используйте следующую команду, чтобы получить отпечаток сертификата удостоверения на EdgeGateway:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

Команда выводит отпечаток сертификата SHA256:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Если вы просматриваете значение отпечатка SHA256 для устройства EdgeGateway , зарегистрированного в Центре Интернета вещей, вы увидите, что он соответствует отпечатку на EdgeGateway:

В итоге ContosoIotHub доверяет EdgeGateway , так как EdgeGateway представляет действительный сертификат удостоверения устройства IoT Edge с отпечатком, который соответствует одному, зарегистрированном в Центре Интернета вещей.

Дополнительные сведения о процессе создания сертификатов см. в статье "Создание и подготовка устройства IoT Edge в Linux с помощью сертификатов X.509".

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

На схемах проверки сертификата может показаться, что IoT Edge использует сертификат исключительно для общения с IoT Hub. IoT Edge имеет несколько модулей. IoT Edge использует сертификат для управления удостоверениями модулей для модулей, отправляющих сообщения. Модули не используют сертификат для проверки подлинности в Центре Интернета вещей, но используют ключи SAS, производные от закрытого ключа, который создает среда выполнения модуля IoT Edge. Эти ключи SAS не изменяются, даже если срок действия сертификата удостоверения устройства истекает. Если срок действия сертификата истекает, edgeHub всё равно работает, но только операции идентификации модуля завершаются ошибкой.

Взаимодействие между модулями и Центром Интернета вещей безопасно, так как ключ SAS является производным от секрета, и IoT Edge управляет ключом без риска вмешательства человека.

Сценарий иерархии вложенных устройств с IoT Edge в качестве шлюза

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

Мы добавим обычное устройство IoT с именем TempSensor, которое подключается к родительскому устройству IoT Edge EdgeGateway, которое подключается к Центр Интернета вещей ContosoIotHub. Как и раньше, все проверки подлинности используют проверку подлинности сертификата X.509. В этом сценарии возникают два вопроса: "Является ли устройство TempSensor легитимным?" и "Корректна ли идентичность EdgeGateway?". Сценарий показан здесь:

Устройство проверяет удостоверение шлюза

Как TempSensor проверяет, что он взаимодействует с подлинным EdgeGateway? Когда TempSensor хочет поговорить с EdgeGateway, TempSensor должен EdgeGateway показать идентификатор. Идентификатор должен быть выдан центром, которому доверяет TempSensor .

Поток совпадает с тем, что при подключении EdgeGateway к ContosoIotHub. TempSensor и EdgeGateway используют протокол подтверждения TLS для проверки удостоверения EdgeGateway. Существует две важные детали:

• Специфика имени узла: сертификат, представленный EdgeGateway, должен быть выдан одному имени узла (домену или IP-адресу), который TempSensor использует для подключения к EdgeGateway.
• Специфика самозаверяющего корневого ЦС: цепочка сертификатов, представленная EdgeGateway , скорее всего, не находится в доверенном корневом хранилище ОС по умолчанию.

Чтобы понять детали, давайте сначала рассмотрим цепочку сертификатов, представленную EdgeGateway.

Специфика имени узла

Общее имя сертификата CN = edgegateway.local отображается в верхней части цепочки. edgegateway.local — это общее имя сертификата сервера edgeHub. edgegateway.local также является именем узла для EdgeGateway в локальной сети (локальной сети или виртуальной сети), где подключены TempSensor и EdgeGateway . Это может быть частный IP-адрес, например 192.168.1.23 или полное доменное имя (FQDN), как схема. Сертификат сервера edgeHub создается с помощью параметра имени узла, определенного в файле config.toml IoT Edge. Не путайте сертификат сервера EdgeHub с сертификатом ЦС Edge. Дополнительные сведения об управлении сертификатом ЦС Edge см. в статье "Управление сертификатами IoT Edge".

Когда TempSensor подключается к EdgeGateway, TempSensor использует имя узла edgegateway.local для подключения к EdgeGateway. TempSensor проверяет сертификат, представленный EdgeGateway, и проверяет, что общее имя сертификата — edgegateway.local. Если общее имя сертификата отличается, TempSensor отклоняет подключение.

Почему EdgeGateway нужно рассказать о своем собственном имени узла?

EdgeGateway не имеет надежного способа узнать, как другие клиенты в сети могут подключаться к нему. Например, в частной сети могут быть DHCP-серверы или службы mDNS, которые перечисляют EdgeGateway как 10.0.0.2 или example-mdns-hostname.local. Но некоторые сети могут иметь DNS-серверы, сопоставленные edgegateway.local с .

Для решения этой проблемы IoT Edge использует настроенное значение config.toml имени узла и создает для него сертификат сервера. Когда запрос поступает в модуль edgeHub , он представляет сертификат с правильным именем сертификата (CN).

Почему IoT Edge создает сертификаты?

В примере обратите внимание, что в цепочке сертификатов есть iotedged workload ca edgegateway . Это центр сертификации (ЦС), который существует на устройстве IoT Edge, известном как Пограничный ЦС (ранее известный как ЦС устройства в версии 1.1). Как и корневой ЦС Балтимора CyberTrust в предыдущем примере, ЦС Edge может выдавать другие сертификаты. Самое главное, а также в этом примере он выдает сертификат сервера модулю EdgeHub . Но он также может выдавать сертификаты другим модулям, работающим на устройстве IoT Edge.

Не опасно ли иметь сертификат издателя на устройстве?

Пограничный ЦС предназначен для включения решений с ограниченными, ненадежными, дорогостоящими или отсутствующими подключениями, но в то же время имеют строгие правила или политики для продления сертификатов. Без пограничного ЦС, IoT Edge - и в частности edgeHub - не может функционировать.

Чтобы защитить пограничный ЦС в рабочей среде:

• Поместите закрытый ключ EdgeCA в доверенном модуле платформы (TPM), желательно таким образом, чтобы закрытый ключ был эфемерно создан и никогда не покидает TPM.
• Используйте инфраструктуру открытых ключей (PKI), к которой выполняется свертка ЦС Edge. Это обеспечивает возможность отключения или отказа от продления скомпрометированных сертификатов. PKI можно управлять ИТ-отделом клиента, если у них есть сведения о том, как (низкая стоимость) или через коммерческий поставщик PKI.

Специфика самозаверяющего корневого ЦС

Модуль EdgeHub является важным компонентом, который создает IoT Edge, обрабатывая весь входящий трафик. В этом примере используется сертификат, выданный центром сертификации Edge, который, в свою очередь, выдан самозаверяющий корневой ЦС. Так как корневой ЦС не является доверенным ос, единственным способом TempSensor будет доверять это установка сертификата ЦС на устройство. Это также называется сценарием пакета доверия, где необходимо распределить корневой каталог клиентам, которым необходимо доверять цепочке. Сценарий пакета доверия может быть проблемным, так как вам нужен доступ к устройству и установка сертификата. Установка сертификата требует планирования. Это можно сделать с помощью скриптов, добавленных во время производства или предварительно установленного в образе ОС.

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

Чтобы проверить цепочку сертификатов, можно использовать openssl на устройстве TempSensor . В этом примере обратите внимание, что имя узла для подключения соответствует CN сертификата глубины 0 и соответствует корневому ЦС.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

Дополнительные сведения о команде см. в openssl документации по OpenSSL.

Вы также можете проверить сертификаты, в которых они хранятся по умолчанию /var/lib/aziot/certd/certs. В каталоге можно найти сертификаты ЦС Edge, сертификаты удостоверения устройства и сертификаты модулей. Для проверки сертификатов можно использовать openssl x509 команды. Например:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

В итоге TempSensor может доверять EdgeGateway, так как:

• Модуль EdgeHub показал действительный сертификат сервера модуля IoT Edge для edgegateway.local
• Сертификат выдан центром сертификации Edge, выданным my_private_root_CA
• Этот закрытый корневой ЦС также хранится в TempSensor как доверенный корневой ЦС ранее
• Криптографические алгоритмы проверяют, можно ли доверять цепочке владения и выдачи.

Сертификаты для других модулей

Другие модули могут получать сертификаты сервера, выданные центром сертификации Edge. Например, модуль Grafana с веб-интерфейсом. Он также может получить сертификат из пограничного ЦС. Модули обрабатываются как подчиненные устройства, размещенные в контейнере. Однако возможность получения сертификата из среды выполнения модуля IoT Edge является особым привилегием. Модули вызывают API рабочей нагрузки для получения сертификата сервера, цепочки с настроенным центром сертификации Edge.

Шлюз проверяет удостоверение устройства

Как EdgeGateway проверяет, что он взаимодействует с TempSensor? EdgeGateway использует проверку подлинности клиента TLS для проверки подлинностиTempSensor.

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

В итоге EdgeGateway может доверять TempSensor, так как:

• TempSensor представляет действительный сертификат удостоверения устройства Интернета вещей для его имени.
• Отпечаток сертификата удостоверения соответствует отпечатку, отправленной в ContosoIotHub.
• Криптографические алгоритмы проверяют, можно ли доверять цепочке владения и выдачи.

Где получить сертификаты и управление

В большинстве случаев вы предоставляете собственные сертификаты или используете автоматически созданные сертификаты. Например, пограничный ЦС и сертификат edgeHub создаются автоматически.

Но рекомендуется настроить устройства для использования сервера регистрации по протоколу Secure Transport (EST) для управления сертификатами x509. Сервер EST позволяет избежать ручной обработки и установки сертификатов на устройствах. Дополнительные сведения об использовании сервера EST см. в статье "Настройка регистрации по протоколу Secure Transport Server для Azure IoT Edge".

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

Если вы не можете использовать сервер EST, запросите сертификаты от поставщика PKI. Управление файлами сертификатов вручную в Центре Интернета вещей и устройствах IoT Edge. Дополнительные сведения см. в статье Управление сертификатами на устройстве IoT Edge.

Чтобы подтвердить разработку концепции, создайте тестовые сертификаты. Дополнительные сведения см. в разделе "Создание демонстрационных сертификатов" для тестирования функций устройств IoT Edge.

Сертификаты в IoT

Центр сертификации

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

Корневой сертификат ЦС

Корневой сертификат ЦС является основой доверия для процесса. В рабочей среде вы обычно покупаете этот сертификат ЦС из доверенного коммерческого центра сертификации, такого как Балтимор, Verisign или DigiCert. Если вы управляете всеми устройствами, подключающимися к устройствам IoT Edge, вы можете использовать корпоративный центр сертификации. В обоих случаях цепочка сертификатов от IoT Edge до IoT Hub (Центр Интернета вещей) использует корневой сертификат УЦ. Подчиненные устройства Интернета вещей должны доверять корневому сертификату. Сохраните сертификат корневого ЦС в хранилище доверенных корневых сертификатов или укажите сведения о сертификате в коде приложения.

Промежуточные сертификаты

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

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

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

Следующие шаги

• Дополнительные сведения о том, как устанавливать сертификаты на устройстве IoT Edge и ссылаться на них из файла конфигурации см. в статье Управление сертификатами на устройстве IoT Edge.
• Общие сведения о модулях IoT Edge Azure
• Настройка устройства IoT Edge для использования в качестве прозрачного шлюза
• В этой статье объясняется, как сертификаты используются для защиты подключений между различными компонентами на устройстве IoT Edge или между устройством IoT Edge и любыми подчиненными устройствами. Вы также можете использовать сертификаты для проверки подлинности устройства IoT Edge в Центре Интернета вещей. Эти сертификаты проверки подлинности отличаются и не рассматриваются в этой статье. Дополнительные сведения о проверке подлинности устройства с помощью сертификатов см. в статье Создание и инициализация устройств IoT Edge с помощью сертификатов X.509.