Аттестация на основе сертификата X.509

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

Сертификаты X.509 могут храниться в аппаратном модуле безопасности HSM.

Совет

Мы настоятельно рекомендуем использовать HSM с устройствами для безопасного хранения секретов, таких как сертификат X.509, на устройствах в рабочей среде.

Общие сведения о цепочке сертификатов X.509

Применение сертификатов X.509 в качестве механизма аттестации позволяет легко масштабировать производство и упростить подготовку устройств к работе. Сертификаты X.509 обычно организуются в цепочки доверия, в которых каждый сертификат подписан закрытым ключом от сертификата следующего уровня. На самом верху цепочки расположен самозаверяющий корневой сертификат. Это соглашение устанавливает делегированную цепочку доверия от корневого сертификата, созданного доверенным центром сертификации (ЦС), через каждый промежуточный сертификат до окончательного сертификата, установленного на устройстве. Дополнительные сведения см. в статье Device Authentication using X.509 CA Certificates (Аутентификация устройств с помощью сертификатов ЦС X.509).

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

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

Дополнительные сведения см. в статье Концептуальное представление о сертификатах ЦС X.509 в отрасли Интернета вещей.

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

Корневой сертификат — это самозаверяющий сертификат X.509, представляющий центр сертификации (ЦС). Он выполняет роль конечной точки (якоря доверия) в цепочке сертификатов. Организация может самостоятельно выдавать корневые сертификаты или приобретать их в корневом центре сертификации. Корневой сертификат можно также назвать корневым сертификатом ЦС.

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

Промежуточный сертификат — это сертификат X.509, подписанный корневым сертификатом (или другим промежуточным сертификатом с корневым сертификатом в своей цепочке), а также может подписывать новые сертификаты. Последний промежуточный сертификат в цепочке подписывает конечный сертификат. Промежуточный сертификат можно также назвать промежуточным сертификатом ЦС.

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

Представьте, что Contoso является крупной корпорацией с собственной инфраструктурой открытых ключей (PKI) с использованием корневого сертификата с именем ContosoRootCert. У каждой дочерней компании Contoso есть собственный промежуточный сертификат, подписанный ContosoRootCert. Каждая дочерняя компания использует промежуточный сертификат для подписывания конечных сертификатов для каждого устройства. В этом сценарии Contoso может использовать один экземпляр DPS, где ContosoRootCert является проверенным сертификатом. У них может быть группа регистрации для каждого подразделения. Таким образом, каждому отдельному дочернему подразделению не нужно беспокоиться о проверке сертификатов.

Сертификат конечного объекта

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

Использование сертификатов X.509 с DPS

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

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

Сертификат можно указать только в одной записи регистрации в экземпляре DPS.

Взаимная поддержка TLS

При настройке регистраций DPS для аттестации X.509 взаимная поддержка TLS (mTLS) поддерживается DPS.

Требования к алгоритму шифрования DPS

Служба подготовки устройств принимает только сертификаты X.509, использующие алгоритм Rivest-Shamir-Adleman (RSA) или алгоритм шифрования эллиптических кривых (ECC). ECC и RSA предоставляют эквивалентные уровни надежности шифрования, но ECC использует более короткую длину ключа.

Если вы используете методы ECC для создания сертификатов X.509 для аттестации устройств, рекомендуется использовать следующие эллиптические кривые:

• nistP256
• nistP384
• nistP521

Требования к именованию сертификатов DPS

Конечные сертификаты, используемые с отдельными записями регистрации , должны иметь общее имя субъекта (CN) для идентификатора регистрации. Идентификатор регистрации определяет регистрацию устройства в DPS и должен быть уникальным для экземпляра DPS (области идентификатора), в котором регистрируется устройство.

Для групп регистрации общий имя субъекта (CN) задает идентификатор устройства, зарегистрированный в Центр Интернета вещей. Идентификатор устройства будет отображаться в записях регистрации для прошедшего проверку подлинности устройства в группе регистрации. Для отдельных регистраций идентификатор устройства можно задать в записи регистрации. Если он не задан в записи регистрации, используется общее имя субъекта (CN).

Дополнительные сведения см. в статье "Проверка подлинности устройств, подписанных с помощью сертификатов ЦС X.509".

Требования к цепочке устройств DPS

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

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

Например, рассмотрим корпорацию, которая использует следующую цепочку устройств для устройства.

В этом примере корневой сертификат проверяется с помощью DPS, а intermediate2 сертификат передается в группу регистрации.

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

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

Порядок операций с сертификатами в службе DPS

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

Служба применяет первую запись, которую она находит, например:

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

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

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

• Устройство 1: корневой сертификат —> сертификат A —> сертификат устройства 1
• Устройство 2: корневой сертификат —> сертификат A —> сертификат устройства 2
• Устройство 3: корневой сертификат —> сертификат A —> сертификат устройства 3
• Устройство 4: корневой сертификат —> сертификат B —> сертификат устройства 4
• Устройство 5: корневой сертификат —> сертификат B —> сертификат устройства 5

Изначально вы создаете запись групповой регистрации для корневого сертификата, чтобы включить доступ для всех пяти устройств. Если в определенный момент сертификат B окажется скомпрометирован, вы можете создать дополнительную групповую запись для сертификата B и отключить ее, чтобы запретить регистрацию устройства 4 и устройства 5. Если позднее будет скомпрометировано еще и устройство 3, вы можете создать запись отдельной регистрации для сертификата этого устройства и отключить ее. Таким образом, доступ будет закрыт для устройства 3, но устройство 1 и устройство 2 смогут пройти регистрацию.