Atestado do certificado X.509
Este artigo descreve os conceitos envolvidos ao provisionar dispositivos usando o atestado de certificado X.509 no DPS (Serviço de Provisionamento de Dispositivos). Este artigo é relevante para todas as personas envolvidas na preparação de um dispositivo para implantação.
Os certificados X. 509 podem ser armazenados em um HSM de módulo de segurança de hardware.
Dica
É altamente recomendável usar um HSM com dispositivos para armazenar com segurança segredos, como o certificado X. 509, em seus dispositivos em produção.
Noções básicas sobre a cadeia de certificados X.509
Usar certificados X.509 como um mecanismo de atestado é uma maneira excelente de escalar a produção e simplificar o provisionamento do dispositivo. Os certificados X.509 normalmente são organizados em uma cadeia de certificados de confiança na qual cada certificado na cadeia é assinado pela chave privada do próximo certificado mais alto e assim por diante, terminando em um certificado raiz autoassinado. Essa estruturação estabelece uma cadeia de confiança delegada do certificado raiz gerado por uma AC (autoridade de certificação) confiável através de cada certificado intermediário para o certificado final instalado em um dispositivo. Para saber mais, consulte Autenticação de dispositivo usando certificados de AC X.509.
Geralmente, a cadeia de certificados representa uma hierarquia lógica ou física associada aos dispositivos. Por exemplo, um fabricante pode criar a seguinte hierarquia de certificados:
- Um certificado de AC raiz autoassinado inicia a cadeia de certificados.
- O certificado raiz gera um certificado de AC intermediário exclusivo para cada fábrica.
- O certificado de cada fábrica gera um certificado de AC intermediário exclusivo para cada linha de produção na fábrica.
- O certificado de linha de produção gera um dispositivo exclusivo (entidade final) para cada dispositivo fabricado na linha.
Para saber mais, consulte Entendimento conceitual de certificados de AC X.509 no setor de IoT.
Certificado raiz
Um certificado raiz é um certificado X.509 autoassinado que representa uma AC (autoridade de certificação). É o terminal, ou âncora de confiança, da cadeia de certificados. Certificados raiz podem ser autoemitidos por uma organização ou adquiridos de uma autoridade de certificação raiz. O certificado raiz também pode ser chamado de certificado de AC raiz.
Certificado intermediário
Um certificado intermediário é um certificado X.509 que foi assinado pelo certificado raiz (ou por outro certificado intermediário com o certificado raiz em sua cadeia) e também pode assinar novos certificados. O último certificado intermediário em uma cadeia assina o certificado folha. Um certificado intermediário também pode ser chamado de certificado de AC intermediário.
Os certificados intermediários são usados de várias maneiras. Por exemplo, certificados intermediários podem ser usados para agrupar dispositivos por linhas de produtos, dispositivos de compra para clientes, divisões de empresa ou fábricas.
Imagine que a Contoso é uma grande empresa com sua própria PKI (infraestrutura de chave pública) usando o certificado raiz chamado ContosoRootCert
. Cada subsidiária da Contoso tem seu próprio certificado intermediário assinado por ContosoRootCert
. Cada subsidiária usa seu certificado intermediário para assinar seus certificados folha para cada dispositivo. Nesse cenário, a Contoso pode usar uma única instância do DPS em que ContosoRootCert
é um certificado verificado. Eles podem ter um grupo de registro para cada subsidiária. Dessa forma, cada subsidiária individual não precisa se preocupar com a verificação de certificados.
Certificado "secundário" de entidade final
Um certificado folha ou certificado de entidade final, identifica o proprietário do certificado. Ele tem o certificado raiz em sua cadeia confiável e zero ou mais certificados intermediários. Um certificado folha não é usado para assinar outros certificados. Ele identifica exclusivamente um dispositivo para o serviço de provisionamento e, às vezes, é chamado de certificado de dispositivo. Durante a autenticação, um dispositivo usa a chave privada associada ao certificado para responder a um desafio de prova de posse do serviço.
Preparar certificados
Os dispositivos usam dois tipos diferentes de certificados quando se conectam ao Hub IoT por meio do DPS. Ao preparar seu dispositivo, verifique se você criou e adicionou todos os certificados corretos ao dispositivo antes de se conectar.
- Certificados raiz públicos: todos os dispositivos precisam ter uma cópia dos certificados raiz públicos que o Hub IoT, o IoT Central e o Serviço de Provisionamento de Dispositivos usam para autorizar as conexões.
- Certificados de autenticação: os certificados X.509 são o método recomendado para autenticar uma identidade do dispositivo.
Certificados raiz públicos necessários
Os dispositivos da Internet das Coisas do Azure usam o TLS para verificar a autenticidade do hub IoT ou do ponto de extremidade do DPS ao qual estão se conectando. Cada dispositivo precisa ter uma cópia do certificado raiz usado pelo Hub IoT e pelo DPS. Recomendamos que todos os dispositivos incluam as seguintes ACs raiz no repositório de certificados confiáveis:
- AC raiz do DigiCert Global G2
- AC raiz do Microsoft RSA 2017
Para obter mais informações sobre as práticas de certificado recomendadas, consulte o suporte do TLS.
Autenticação usando certificados X.509
O serviço de provisionamento expõe dois tipos de entrada de registro que você pode usar para controlar o acesso de dispositivos que usam o mecanismo de atestado X.509:
- As entradas de registro individual são configuradas com o certificado do dispositivo associado a um dispositivo específico. Essas entradas controlam os registros de dispositivos específicos.
- As entradas de grupo de registros são associadas a um certificado de AC intermediário ou raiz. Essas entradas controlam os registros de todos os dispositivos que têm esse certificado raiz ou intermediário em sua cadeia de certificados.
Um certificado pode ser especificado em apenas uma entrada de registro na instância do DPS.
Suporte mútuo ao TLS
Quando os registros DPS são configurados para atestado X.509, o mTLS (TLS mútuo) tem suporte do DPS.
Requisitos do algoritmo de criptografia DPS
O Serviço de Provisionamento de Dispositivos aceita apenas certificados X.509 que utilizem o algoritmo RSA (Rivest-Shamir-Adleman) ou o algoritmo de ECC (Criptografia de Curva Elíptica) para criptografia. O ECC e o RSA fornecem níveis equivalentes de força de criptografia, mas o ECC usa um comprimento de chave mais curto.
Se você usar métodos ECC para gerar certificados X.509 para atestado de dispositivo, recomendamos as seguintes curvas elípticas:
- nistP256
- nistP384
- nistP521
Requisitos de nomenclatura para certificado DPS
Certificados folha usados com entradas de registro individual devem ter o CN (nome comum da entidade) definido como a ID de registro. A ID de registro identifica o registro do dispositivo com o DPS e deve ser exclusiva para a instância do DPS (escopo da ID) em que o dispositivo é registrado.
Para grupos de registro, o CN (nome comum da entidade) também define a ID do dispositivo que está registrada no Hub IoT. A ID do dispositivo será mostrada nos Registros do dispositivo autenticado no grupo de registro. Para registros individuais, a ID do dispositivo pode ser definida na entrada do registro. Se ela não for definida na entrada do registro, será usado o CN (nome comum do certificado).
Para saber mais, confira Autenticar dispositivos assinados com certificados de AC X.509.
Requisitos da cadeia de dispositivos do DPS
Quando um dispositivo está tentando fazer o registro por meio do DPS usando um grupo de registro, o dispositivo deve enviar a cadeia de certificados do certificado folha para um certificado verificado. Caso contrário, a autenticação falhará.
Por exemplo, se apenas o certificado raiz for verificado e um certificado intermediário for carregado no grupo de registro, o dispositivo deverá apresentar a cadeia de certificados do certificado de folha até o certificado raiz verificado. Essa cadeia de certificados incluiria qualquer certificado intermediário entre eles. A autenticação falhará se o DPS não puder atravessar a cadeia de certificados para um certificado verificado.
Por exemplo, considere uma empresa que usa a seguinte cadeia de dispositivos para um dispositivo.
Neste exemplo, o certificado raiz é verificado com DPS e o certificado intermediate2
é carregado no grupo de registro.
Se o dispositivo enviar apenas a seguinte cadeia de dispositivos durante o provisionamento, a autenticação falhará. Porque o DPS não pode tentar a autenticação supondo a validade do certificado intermediate1
.
Se o dispositivo enviar a cadeia de dispositivos completa da seguinte maneira durante o provisionamento, o DPS poderá tentar a autenticação do dispositivo.
Ordem de DPS de operações com certificados
Quando um dispositivo conecta o serviço de provisionamento, o serviço percorre a cadeia de certificados começando com o certificado do dispositivo (folha) e procura uma entrada de registro correspondente. Ele usará a primeira entrada encontrada na cadeia para determinar se deverá provisionar o dispositivo. Ou seja, se houver um registro individual para o certificado de dispositivo, o serviço de provisionamento aplicará essa entrada. Se não houver um registro individual para o dispositivo, o serviço procurará um grupo de registro que corresponda ao primeiro certificado intermediário. Se encontrar um, o serviço aplicará essa entrada, caso contrário, procurará um grupo de registro para o próximo certificado intermediário, e assim por diante, passando pela cadeia até a raiz.
O serviço aplicará a primeira entrada encontrada, de modo que:
- Se a primeira entrada de registro encontrada estiver habilitada, o serviço provisionará o dispositivo.
- Se a primeira entrada de registro encontrada estiver desabilitada, o serviço não provisionará o dispositivo.
- Se nenhuma entrada de registro for encontrada para nenhum certificado na cadeia de certificados do dispositivo, o serviço não provisionará o dispositivo.
Cada certificado na cadeia de certificados de um dispositivo pode ser especificado em uma entrada de registro, mas poderá ser especificado em apenas uma entrada na instância do DPS.
Esse mecanismo e a estrutura hierárquica de cadeias de certificados oferece flexibilidade eficiente em como você pode controlar o acesso a dispositivos individuais e a grupos de dispositivos. Por exemplo, imagine cinco dispositivos com as seguintes cadeias de certificados:
- Dispositivo 1: certificado raiz -> certificado A -> certificado do dispositivo 1
- Dispositivo 2: certificado raiz -> certificado A -> certificado do dispositivo 2
- Dispositivo 3: certificado raiz -> certificado A -> certificado do dispositivo 3
- Dispositivo 4: certificado raiz -> certificado B -> certificado do dispositivo 4
- Dispositivo 5: certificado raiz -> certificado B -> certificado do dispositivo 5
Inicialmente, você pode criar uma única entrada de registro de grupo habilitado para o certificado raiz para habilitar o acesso para todos os cinco dispositivos. Se o certificado B posteriormente for comprometido, você poderá criar uma entrada de grupo de registros desabilitada para o certificado B para impedir que o Dispositivo 4 e o Dispositivo 5 se registrem. Se depois ainda o Dispositivo 3 for comprometido, você poderá criar uma entrada de registro individual desabilitada para este certificado. Isso revoga o acesso para o Dispositivo 3, mas ainda permite que o Dispositivo 1 e o Dispositivo 2 se registrem.