Entenda como o Azure IoT Edge usa certificados

Aplica-se a: IoT Edge 1.5

O IoT Edge usa diferentes tipos de certificados para diferentes finalidades. Este artigo explica como o IoT Edge usa certificados com o Hub IoT do Azure e cenários de gateway do IoT Edge.

Resumo

O IoT Edge usa certificados nesses cenários principais. Use os links para saber mais sobre cada cenário.

Pré-requisitos

• Você precisa de uma compreensão básica da criptografia de chave pública, dos pares de chaves e de como uma chave pública e uma chave privada podem criptografar ou descriptografar dados. Para obter mais informações sobre como o IoT Edge usa a criptografia por chave pública, confira Noções básicas sobre a criptografia por chave pública e a infraestrutura de chave pública X.509.
• Você precisa de uma compreensão básica de como o IoT Edge se relaciona com o Hub IoT. Para obter mais informações, confira Noções básicas sobre o runtime e a arquitetura do Azure IoT Edge.

Cenário de dispositivo individual

Para ajudá-lo a aprender os conceitos de certificado do IoT Edge, imagine um cenário em que um dispositivo IoT Edge chamado EdgeGateway se conecta a um Hub IoT do Azure chamado ContosoIotHub. Neste exemplo, toda autenticação usa autenticação de certificado X.509 em vez de chaves simétricas. Para estabelecer a relação de confiança nesse cenário, precisamos garantir que o Hub IoT e o dispositivo IoT Edge sejam autênticos: "Este dispositivo é genuíno e válido?" e "A identidade do Hub IoT está correta?". Aqui está uma ilustração do cenário:

Este artigo explica as respostas para cada pergunta e, em seguida, expande o exemplo em seções posteriores.

O dispositivo verifica a identidade do Hub IoT

Como o EdgeGateway verifica se está falando com o ContosoIotHub real? Quando EdgeGateway fala com a nuvem, ele se conecta ao endpoint ContosoIoTHub.Azure-devices.NET. Para verificar se o ponto de extremidade é autêntico, o IoT Edge precisa do ContosoIoTHub para mostrar a ID (identificação). A ID precisa ser emitida por uma autoridade em que o EdgeGateway confia. Para verificar a identidade do Hub IoT, o IoT Edge e o Hub IoT usam o protocolo de handshake TLS para verificar a identidade do servidor do Hub IoT. O diagrama a seguir mostra um handshake do TLS. Alguns detalhes são deixados de fora para mantê-lo simples. Para obter mais informações sobre o protocolo de handshake TLS , consulte handshake TLS na Wikipédia.

Nesse contexto, você não precisa saber os detalhes exatos do algoritmo de criptografia. O importante é que o algoritmo verifica se o servidor possui a chave privada emparelhada com sua chave pública. Essa verificação prova que o apresentador do certificado não o copiou ou roubou. Pense em um documento de identidade com foto em que seu rosto combina com a foto. Se alguém roubar sua ID, não poderá usá-la porque seu rosto é exclusivo. Para as chaves criptográficas, o par de chaves é relacionado e exclusivo. Em vez de corresponder um rosto a uma ID de foto, o algoritmo criptográfico usa o par de chaves para verificar a identidade.

Em nosso cenário, o ContosoIotHub mostra a seguinte cadeia de certificados:

A AC (autoridade de certificação) raiz é o certificado Baltimore CyberTrust Root. O DigiCert assina esse certificado raiz e é amplamente confiável e armazenado em muitos sistemas operacionais. Por exemplo, o Ubuntu e o Windows o incluem no repositório de certificados padrão.

Repositório de certificados do Windows:

Repositório de certificados do Ubuntu:

Quando um dispositivo verifica o certificado Baltimore CyberTrust Root , ele já está no sistema operacional. Do ponto de vista do EdgeGateway, como a cadeia de certificados da ContosoIotHub é assinada por uma AC raiz em que o sistema operacional confia, o certificado é confiável. Esse certificado é chamado de certificado de servidor do Hub IoT. Para obter mais informações sobre o certificado do servidor do Hub IoT, consulte o suporte ao TLS (Transport Layer Security) no Hub IoT.

Em resumo, o EdgeGateway pode verificar a identidade do ContosoIotHub e confiar nela porque:

• O ContosoIotHub apresenta o certificado do servidor do Hub IoT
• O certificado do servidor é confiável no repositório de certificados do sistema operacional
• Os dados criptografados com a chave pública do ContosoIotHub podem ser descriptografados pelo ContosoIotHub, provando a posse da chave privada

O Hub IoT verifica a identidade do dispositivo IoT Edge

Como o ContosoIotHub verifica se está se comunicando com o EdgeGateway? Como o Hub IoT dá suporte ao TLS mútuo (mTLS), ele verifica o certificado do EdgeGateway durante um handshake TLS autenticado pelo cliente. Para simplificar, ignoramos algumas etapas no diagrama a seguir.

Nesse caso, o EdgeGateway fornece o certificado de identidade do dispositivo IoT Edge. Da perspectiva da ContosoIotHub, verifica-se se a impressão digital do certificado fornecido corresponde ao registro e se o EdgeGateway tem a chave privada emparelhada com o certificado que apresenta. Ao provisionar um dispositivo IoT Edge no Hub IoT, você fornece uma impressão digital. O Hub IoT usa a impressão digital para verificar o certificado.

Por exemplo, use o seguinte comando para obter a impressão digital do certificado de identidade no EdgeGateway:

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

O comando gera a impressão digital do certificado 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

Se você exibir o valor da impressão digital SHA256 para o dispositivo EdgeGateway registrado no Hub IoT, verá que ele corresponde à impressão digital no EdgeGateway:

Em resumo, a ContosoIotHub confia no EdgeGateway porque o EdgeGateway apresenta um certificado de identidade de dispositivo do IoT Edge válido com uma impressão digital que corresponde à registrada no Hub IoT.

Para obter mais informações sobre o processo de compilação de certificados, consulte Criar e provisionar um dispositivo IoT Edge no Linux usando certificados X.509.

Uso de certificado para operações de identidade do módulo

Nos diagramas de verificação de certificado, pode parecer que o IoT Edge usa o certificado apenas para falar com o Hub IoT. O IoT Edge tem vários módulos. O IoT Edge usa o certificado para gerenciar identidades de módulo para módulos que enviam mensagens. Os módulos não usam o certificado para autenticar no Hub IoT, mas usam chaves SAS derivadas da chave privada gerada pelo runtime do módulo do IoT Edge. Essas chaves SAS não serão alteradas mesmo que o certificado de identidade do dispositivo vencer. Se o certificado expirar, o edgeHub ainda será executado, mas apenas as operações de identidade do módulo falharão.

A interação entre módulos e Hub IoT é segura porque a chave SAS é derivada de um segredo e o IoT Edge gerencia a chave sem o risco de intervenção humana.

Cenário de hierarquia de dispositivo aninhado com o IoT Edge como o gateway

Agora você entende uma interação simples entre o IoT Edge e o Hub IoT. Mas o IoT Edge também pode atuar como um gateway para dispositivos downstream ou outros dispositivos IoT Edge. Esses canais de comunicação devem ser criptografados e confiáveis. Devido à complexidade adicionada, vamos expandir o cenário de exemplo para incluir um dispositivo downstream.

Adicionamos um dispositivo IoT comum chamado TempSensor, que se conecta ao dispositivo IoT Edge pai EdgeGateway que se conecta ao Hub IoT ContosoIotHub. Como antes, toda autenticação usa a autenticação de certificado X.509. Esse cenário levanta duas questões: "O dispositivo TempSensor é legítimo?" e "A identidade do EdgeGateway está correta?". O cenário é ilustrado aqui:

O dispositivo verifica a identidade do gateway

Como o TempSensor verifica se ele está se comunicando com o EdgeGateway original? Quando o TempSensor quer se comunicar com o EdgeGateway, o TempSensor precisa do EdgeGateway para mostrar uma ID. A ID precisa ser emitida por uma autoridade em que o TempSensor confia.

O fluxo é o mesmo de quando o EdgeGateway se comunica com o ContosoIotHub. O TempSensor e o EdgeGateway usam o protocolo de handshake TLS para verificar a identidade do EdgeGateway. Há dois detalhes importantes:

• Especificidade do nome do host: o certificado apresentado pelo EdgeGateway precisa ser emitido para o mesmo nome do host (domínio ou endereço IP) usado pelo TempSensor para se conectar ao EdgeGateway.
• Especificidade da AC raiz autoassinada: a cadeia de certificados apresentada pelo EdgeGateway provavelmente não está no repositório raiz confiável padrão do sistema operacional.

Para entender os detalhes, primeiro, vamos examinar a cadeia de certificados apresentada pelo EdgeGateway.

Especificidade do nome do host

O nome comum do certificado CN = edgegateway.local está listado no início da cadeia. edgegateway.local é o nome comum do certificado do servidor do edgeHub. edgegateway.local também é o nome do host do EdgeGateway na rede local (LAN ou VNet), em que o TempSensor e o EdgeGateway estão conectados. Esse pode ser um endereço IP privado, como 192.168.1.23, ou um FQDN (nome de domínio totalmente qualificado) como no diagrama. O certificado do servidor edgeHub é gerado usando o parâmetro nome do host definido no arquivo config.toml do IoT Edge. Não confunda o certificado do servidor edgeHub com o certificado de AC do Edge. Para obter mais informações sobre como gerenciar o certificado de AC do Edge, consulte Gerenciar certificados do IoT Edge.

Quando o TempSensor se conecta ao EdgeGateway, o TempSensor usa o nome do host edgegateway.local, para se conectar ao EdgeGateway. O TempSensor verifica o certificado apresentado pelo EdgeGateway e verifica se o nome comum do certificado é edgegateway.local. Se o nome comum do certificado for diferente, o TempSensor rejeitará a conexão.

Por que o EdgeGateway precisa ser informado sobre o respectivo nome do host?

O EdgeGateway não tem uma forma confiável de saber como outros clientes na rede podem se conectar a ele. Por exemplo, em uma rede privada, pode haver servidores DHCP ou serviços mDNS que listam o EdgeGateway como 10.0.0.2 ou example-mdns-hostname.local. No entanto, algumas redes podem ter servidores DNS que mapeiam edgegateway.local para o endereço IP do 10.0.0.2.

Para resolver o problema, o IoT Edge usa o valor de nome do host configurado em config.toml e cria um certificado do servidor para ele. Quando uma solicitação chega ao módulo edgeHub, ela apresenta o certificado com o CN (nome comum) do certificado correto.

Por que o IoT Edge cria certificados?

No exemplo, observe que há um iotedged workload ca edgegateway na cadeia de certificados. É a AC (autoridade de certificação) que existe no dispositivo IoT Edge conhecida como AC do Edge (antiga AC do Dispositivo na versão 1.1). Assim como a AC raiz do Baltimore CyberTrust no exemplo anterior, a AC do Edge pode emitir outros certificados. E o mais importante: também neste exemplo, ela emite o certificado do servidor para o módulo edgeHub. No entanto, ela também pode emitir certificados para outros módulos em execução no dispositivo IoT Edge.

Não é perigoso ter um certificado do emissor no dispositivo?

A AC do Edge foi projetada para habilitar soluções com conectividade limitada, não confiável, cara ou ausente, mas ao mesmo tempo que tem regulamentações ou políticas estritas sobre as renovações do certificado. Sem a AC do Edge, o IoT Edge (e em particular, o edgeHub) não podem funcionar.

Para proteger a AC do Edge em produção:

• Coloque a chave privada do EdgeCA em um TPM (Trusted Platform Module), preferencialmente, de uma forma em que a chave privada seja gerada de modo efêmero e nunca saia do TPM.
• Use uma PKI (infraestrutura de chave pública) para a qual a AC do Edge é acumulada. Isso fornece a capacidade de desabilitar ou recusar a renovação dos certificados comprometidos. A PKI poderá ser gerenciada pela TI do cliente se ela tiver o conhecimento sobre como fazer isso (menor custo) ou por meio de um provedor de PKI comercial.

Especificidade de AC raiz autoassinada

O módulo edgeHub é um componente importante que compõe o IoT Edge processando todo o tráfego de entrada. Neste exemplo, ele usa um certificado emitido pela AC do Edge, que, por sua vez, é emitido por uma AC raiz autoassinada. Como a AC raiz não é confiável para o sistema operacional, a única maneira de o TempSensor confiar nela é instalar o Certificado de Autoridade de Certificação no dispositivo. Isso também é conhecido como o cenário de pacote de relação de confiança, em que você precisa distribuir a raiz para os clientes que precisam confiar na cadeia. O cenário de pacote de relação de confiança pode ser problemático porque você precisa acessar o dispositivo e instalar o certificado. A instalação do certificado exige planejamento. Isso pode ser feito com scripts, adicionados durante a fabricação ou pré-instalados na imagem do sistema operacional.

Aplicando todos esses conceitos, o TempSensor pode verificar se ele está se comunicando com o EdgeGateway original, porque ele apresentou um certificado que correspondia ao endereço e o certificado é assinado por uma raiz confiável.

Para verificar a cadeia de certificados, você pode usar o openssl no dispositivo do TempSensor. Neste exemplo, observe que o nome do host para conexão corresponde à CN do certificado de profundidade 0 e que a AC raiz é correspondente.

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

Para saber mais sobre o comando openssl, confira a documentação do OpenSSL.

Inspecione também os certificados em que eles são armazenados por padrão em /var/lib/aziot/certd/certs. Encontre os certificados da AC do Edge, os certificados de identidade do dispositivo e os certificados do módulo no diretório. Use os comandos openssl x509 para inspecionar os certificados. Por exemplo:

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

Em resumo, o TempSensor pode confiar no EdgeGateway porque:

• O módulo edgeHub mostrou um certificado do servidor do módulo do IoT Edge válido para edgegateway.local
• O certificado é emitido pela AC do Edge, que é emitida por my_private_root_CA
• Essa AC raiz privada também é armazenada no TempSensor como a AC raiz confiável anteriormente
• Os algoritmos de criptografia verificam se a cadeia de propriedade e de emissão pode ser confiável

Certificados para outros módulos

Outros módulos podem obter os certificados do servidor emitidos pela AC do Edge. Por exemplo, um módulo do Grafana que tem uma interface da Web. Ele também pode obter um certificado da AC do Edge. Os módulos são tratados como dispositivos downstream hospedados no contêiner. No entanto, a capacidade de obter um certificado do runtime do módulo do IoT Edge é um privilégio especial. Os módulos chamam a API de carga de trabalho para receber o certificado do servidor encadeado para a AC do Edge configurada.

O gateway verifica a identidade do dispositivo

Como o EdgeGateway verifica se está se comunicando com o TempSensor? O EdgeGateway usa a autenticação de cliente TLS para autenticar o TempSensor.

A sequência é semelhante ao ContosoIotHub verificando um dispositivo. Mas, em um cenário de gateway, o EdgeGateway depende do ContosoIotHub como a fonte da verdade para o registro de certificado. O EdgeGateway também mantém uma cópia ou cache offline se não houver nenhuma conexão com a nuvem.

Em resumo, o EdgeGateway pode confiar no TempSensor porque:

• TempSensor apresenta um certificado de identidade de dispositivo IoT válido para seu nome
• A impressão digital do certificado de identidade corresponde àquela carregada no ContosoIotHub
• Os algoritmos de criptografia verificam se a cadeia de propriedade e de emissão pode ser confiável

Local de obtenção dos certificados e do gerenciamento

Na maioria dos casos, você fornece seus próprios certificados ou usa certificados gerados automaticamente. Por exemplo, a AC do Edge e o certificado edgeHub são gerados automaticamente.

Mas a melhor prática é configurar seus dispositivos para usar um servidor EST (Registro por Transporte Seguro) para gerenciar certificados x509. Um servidor EST permite evitar o tratamento manual e a instalação de certificados em dispositivos. Para obter mais informações sobre como usar um servidor EST, confira Configurar o Servidor de Registro por Transporte Seguro para o Azure IoT Edge.

Você também pode usar certificados para autenticar no servidor EST. Esses certificados são autenticados com servidores EST para emitir outros certificados. O serviço de certificado usa um certificado de inicialização para autenticação em um servidor EST. O certificado de inicialização é de longa duração. Quando ele se autentica pela primeira vez, o serviço de certificado solicita um certificado de identidade do servidor EST. O certificado de identidade é usado em solicitações EST futuras para o mesmo servidor.

Se você não puder usar um servidor EST, solicite certificados do seu provedor PKI. Gerencie os arquivos de certificado manualmente no Hub IoT e seus dispositivos IoT Edge. Para obter mais informações, consulte Gerenciar certificados em um dispositivo IoT Edge.

Para o desenvolvimento de prova de conceito, crie certificados de teste. Para obter mais informações, confira Criar certificados de demonstração para testar recursos do dispositivo IoT Edge.

Certificados na IoT

Autoridade de certificação

Uma AC (autoridade de certificação) emite certificados digitais. A AC atua como um terceiro confiável entre o proprietário do certificado e o receptor do certificado. Um certificado digital prova que o receptor possui uma chave pública. A cadeia de certificados de confiança começa com um certificado raiz, que é a base para a confiança em todos os certificados que a autoridade emite. O proprietário do certificado raiz pode emitir certificados intermediários adicionais (certificados de dispositivo downstream).

Certificado de AC raiz

Um certificado de AC raiz é a raiz da confiança para o processo. Em produção, você geralmente compra esse certificado de AC de uma autoridade de certificação comercial confiável, como Baltimore, Verisign ou DigiCert. Se você controlar todos os dispositivos que se conectam aos dispositivos do IoT Edge, poderá usar uma autoridade de certificação corporativa. Em ambos os casos, a cadeia de certificados do IoT Edge para o Hub IoT usa o certificado de AC raiz. Os dispositivos IoT downstream devem confiar no certificado raiz. Armazene o certificado de autoridade de certificação raiz no repositório de autoridade de certificação raiz confiável ou forneça os detalhes do certificado no código do aplicativo.

Certificados intermediários

Em um processo de fabricação típico para dispositivos seguros, os fabricantes raramente usam certificados de AC raiz diretamente devido ao risco de vazamento ou exposição. O Certificado de Autoridade de Certificação raiz cria e assina digitalmente um ou mais Certificados de Autoridade de Certificação intermediários. Pode haver um ou uma cadeia de certificados intermediários. Os cenários que exigem uma cadeia de certificados intermediários incluem:

• Uma hierarquia de departamentos em um fabricante
• Várias empresas envolvidas em série na produção de um dispositivo
• Um cliente que compra uma AC raiz e deriva um certificado de autenticação para o fabricante assinar dispositivos em nome do cliente

O fabricante usa um certificado de AC intermediário no final dessa cadeia para assinar o certificado de AC do Edge colocado no dispositivo final. A fábrica protege de perto esses certificados intermediários. Processos físicos e eletrônicos estritos controlam seu uso.

Próximas etapas

• Para obter mais informações sobre como instalar certificados em um dispositivo IoT Edge e referenciá-los no arquivo config, consulte Gerenciar certificado em um dispositivo IoT Edge.
• Entenda os módulos do Azure IoT Edge
• Configure um dispositivo IoT Edge para atuar como um gateway transparente
• Este artigo explica como os certificados são usados para proteger conexões entre os diferentes componentes em um dispositivo IoT Edge ou entre um dispositivo IoT Edge e qualquer dispositivo downstream. Você também pode usar certificados para autenticar o dispositivo IoT Edge no Hub IoT. Esses certificados de autenticação são diferentes e não são discutidos neste artigo. Para obter mais informações sobre como autenticar o dispositivo com certificados, confira Criar e provisionar um dispositivo IoT Edge usando certificados X.509.