Comprender cómo Azure IoT Edge usa certificados

Se aplica a: IoT Edge 1.5

IoT Edge usa diferentes tipos de certificados para distintos propósitos. En este artículo se explica cómo IoT Edge usa certificados con escenarios de puerta de enlace de Azure IoT Hub y IoT Edge.

Resumen

IoT Edge usa certificados en estos escenarios principales. Use los vínculos para obtener más información sobre cada escenario.

Requisitos previos

• Necesita un conocimiento básico de la criptografía de clave pública, los pares de claves y cómo una clave pública y una clave privada pueden cifrar o descifrar datos. Para obtener más información sobre cómo IoT Edge usa la criptografía de clave pública, consulte Introducción de criptografía de clave pública y infraestructura de clave pública X.509.
• Necesita una comprensión básica de cómo IoT Edge se relaciona con IoT Hub. Para obtener más información, consulte Understand the Azure IoT Edge runtime and its architecture.

Escenario de dispositivo único

Para ayudarle a aprender los conceptos de certificados de IoT Edge, imagine un escenario en el que un dispositivo IoT Edge denominado EdgeGateway se conecta a un Azure IoT Hub denominado ContosoIotHub. En este ejemplo, toda la autenticación usa la autenticación de certificados X.509 en lugar de claves simétricas. Para establecer la confianza en este escenario, debe garantizar que el IoT Hub y el dispositivo IoT Edge son auténticos: "¿Es este dispositivo auténtico y válido?" y "¿Es la identidad del IoT Hub correcta?" A continuación, se muestra un ejemplo del escenario:

Diagrama de estado del escenario de confianza que muestra la conexión entre el dispositivo IoT Edge y el IoT Hub.

En este artículo se explican las respuestas a cada pregunta y, a continuación, se expande el ejemplo en secciones posteriores.

El dispositivo verifica la identidad del IoT Hub

¿Cómo comprueba EdgeGateway que está hablando con el verdadero ContosoIotHub? Cuando EdgeGateway se comunica con la nube, se conecta al punto de conexión ContosoIoTHub.Azure-devices.NET. Para asegurarse de que el punto de conexión es auténtico, IoT Edge necesita ContosoIoTHub para mostrar la identificación (ID). El identificador debe ser emitido por una autoridad en la que EdgeGateway confíe. Para comprobar la identidad de IoT Hub, IoT Edge y IoT Hub utilizan el protocolo de enlace TLS para verificar la identidad del servidor de IoT Hub. En el diagrama siguiente se muestra un protocolo de enlace TLS. Algunos detalles se dejan fuera para mantenerlo sencillo. Para obtener más información sobre el protocolo de protocolo de enlace TLS, consulte Protocolo de enlace TLS en Wikipedia.

En este contexto, no es necesario conocer los detalles exactos del algoritmo criptográfico. El concepto de clave es que el algoritmo comprueba que el servidor posee la clave privada que se empareja con su clave pública. Esta comprobación demuestra que el presentador del certificado no lo ha copiado ni robado. Piense en un documento de identidad con foto en el que su cara coincide con la foto. Si alguien roba su identificador, no puede usarlo porque su cara es única. Para las claves criptográficas, el par de claves está relacionado y es único. En lugar de hacer coincidir una cara con un identificador de foto, el algoritmo criptográfico usa el par de claves para comprobar la identidad.

En este escenario, ContosoIotHub muestra la siguiente cadena de certificados:

La entidad de certificación raíz (CA) es el certificado DigiCert Global Root G2 . DigiCert firma este certificado raíz y es ampliamente de confianza y se almacena en muchos sistemas operativos. Por ejemplo, Ubuntu lo incluye en el almacén de certificados predeterminado:

Cuando un dispositivo comprueba el certificado DigiCert Global Root G2 , ya está en el sistema operativo. Desde la perspectiva de EdgeGateway , ya que la cadena de certificados de ContosoIotHub está firmada por una entidad de certificación raíz en la que confía el sistema operativo, el certificado es de confianza. Este certificado se denomina certificado de servidor IoT Hub. Para obtener más información sobre el certificado de servidor de IoT Hub, consulte Compatibilidad de seguridad de la capa de transporte (TLS) en IoT Hub.

En resumen, EdgeGateway puede comprobar y confiar en la identidad de ContosoIotHub porque:

• ContosoIotHub presenta su certificado de servidor IoT Hub.
• El certificado de servidor es de confianza en el almacén de certificados del sistema operativo.
• ContosoIotHub puede descifrar los datos cifrados con la clave pública de ContosoIotHub, lo que demuestra su posesión de la clave privada.

IoT Hub verifica la identidad del dispositivo IoT Edge

¿Cómo comprueba ContosoIotHub que se está comunicando con EdgeGateway? Dado que IoT Hub admite mutual TLS (mTLS), comprueba el certificado de EdgeGateway durante un protocolo de enlace TLS autenticado por cliente. Para simplificar, el diagrama siguiente omite algunos pasos.

En este caso, EdgeGateway proporciona su certificado de identidad de dispositivo IoT Edge. Desde la perspectiva de ContosoIotHub, comprueba que la huella digital del certificado proporcionado coincide con su registro y que EdgeGateway tiene la clave privada emparejada con el certificado que presenta. Al aprovisionar un dispositivo IoT Edge en IoT Hub, proporcione una huella digital. IoT Hub usa la huella digital para comprobar el certificado.

Por ejemplo, use el siguiente comando para obtener la huella digital del certificado de identidad en EdgeGateway:

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

El comando genera la huella digital SHA256 del certificado:

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

Si ve el valor de huella digital SHA256 del dispositivo EdgeGateway registrado en IoT Hub, verá que coincide con la huella digital en EdgeGateway:

En resumen, ContosoIotHub confía en EdgeGateway porque EdgeGateway presenta un certificado de identidad de dispositivo IoT Edge válido con una huella digital que coincida con la registrada en IoT Hub.

Para obtener más información sobre el proceso de creación de certificados, consulte Crear y aprovisionar un dispositivo IoT Edge en Linux mediante certificados X.509.

Uso de certificados para las operaciones de identidad de módulo

En los diagramas de comprobación de certificados, puede parecer que IoT Edge solo usa el certificado para comunicarse con IoT Hub. IoT Edge tiene varios módulos. IoT Edge usa el certificado para administrar identidades de módulo para módulos que envían mensajes. Los módulos no usan el certificado para autenticarse frente a IoT Hub, sino que utilizan claves SAS derivadas de la clave privada que genera el tiempo de ejecución del módulo de IoT Edge. Estas claves SAS no cambian aunque expire el certificado de identidad del dispositivo. Si el certificado expira, edgeHub todavía se ejecuta, pero solo se produce un error en las operaciones de identidad del módulo.

La interacción entre módulos y IoT Hub es segura porque la clave SAS se deriva de un secreto y IoT Edge administra la clave sin el riesgo de intervención humana.

Escenario de jerarquía de dispositivos anidados con IoT Edge como puerta de enlace

Ahora comprende una interacción sencilla entre IoT Edge y IoT Hub. Pero IoT Edge también puede actuar como puerta de enlace para dispositivos de bajada u otros dispositivos IoT Edge. Estos canales de comunicación deben cifrarse y confiarse. Debido a la complejidad adicional, vamos a expandir el escenario de ejemplo para incluir un dispositivo aguas abajo.

Agregue un dispositivo IoT normal denominado TempSensor, que se conecta a su dispositivo IoT Edge primario EdgeGateway, que se conecta a la IoT Hub ContosoIotHub. Como antes, toda la autenticación usa la autenticación de certificados X.509. Este escenario plantea dos preguntas: "¿Es legítimo el dispositivo TempSensor?" y "¿Es correcta la identidad de EdgeGateway?" El escenario se muestra en el diagrama siguiente:

El dispositivo comprueba la identidad de la puerta de enlace

TempSensor ¿Cómo verifica que se comunica con el auténtico EdgeGateway? Cuando TempSensor quiere hablar con EdgeGateway, TempSensor debe EdgeGateway mostrar un identificador. El identificador debe provenir de una autoridad que TempSensor confíe.

Diagrama de secuencia que muestra el intercambio de certificados desde el dispositivo de puerta de enlace al dispositivo IoT Edge, con verificación de certificados mediante la autoridad certificadora raíz privada.

El flujo es el mismo que cuando EdgeGateway se comunica con ContosoIotHub. TempSensor y EdgeGateway usan el protocolo de enlace TLS para verificar la EdgeGateway identidad. Dos detalles importantes destacan:

• Especificidad del nombre de host: EdgeGateway debe presentar un certificado emitido al mismo nombre de host (dominio o dirección IP) que TempSensor usa para conectarse a EdgeGateway.
• Especificidad de la entidad de certificación raíz autofirmada: EdgeGateway es probable que presente una cadena de certificados que no esté en el almacén raíz de confianza predeterminado del sistema operativo.

Para comprender los detalles, examine primero la cadena de certificados que EdgeGateway presenta.

Diagrama de flujo que muestra la cadena de entidad de certificación para una puerta de enlace de IoT Edge.

Especificidad del nombre de host

El nombre CN = edgegateway.local común del certificado aparece en la parte superior de la cadena. edgegateway.local es el nombre común del certificado de edgeHub servidor. edgegateway.local también es el nombre de host de EdgeGateway en la red local (LAN o red virtual) donde TempSensor y EdgeGateway se conectan. Puede ser una dirección IP privada, como 192.168.1.23, o un nombre de dominio completo (FQDN), como el diagrama. Genere el certificado de servidor edgeHub utilizando el parámetro hostname definido en el archivo IoT Edge config.toml. No confunda el certificado de edgeHub servidor con el certificado de CA de Edge. Para obtener más información sobre la gestión del certificado CA de Edge, consulte Administrar certificados IoT Edge.

Cuando TempSensor se conecta a EdgeGateway, TempSensor usa el nombre edgegateway.local de host para conectarse a EdgeGateway. TempSensor comprueba el certificado que EdgeGateway presenta y comprueba que el nombre común del certificado es edgegateway.local. Si el nombre común del certificado es diferente, TempSensor rechaza la conexión.

¿Por qué EdgeGateway necesita conocer su propio nombre de host?

EdgeGateway no tiene una manera confiable de saber cómo otros clientes de la red pueden conectarse a él. Por ejemplo, en una red privada, podría haber servidores DHCP o servicios mDNS que enumere EdgeGateway como 10.0.0.2 o example-mdns-hostname.local. Sin embargo, algunas redes pueden tener servidores DNS que asocian edgegateway.local a la dirección IP EdgeGateway10.0.0.2.

Para solucionar el problema, IoT Edge usa el valor de nombre de host configurado en config.toml y crea un certificado de servidor para él. Cuando una solicitud llega al módulo edgeHub, presenta el certificado con el nombre común (CN) correcto del certificado.

¿Por qué IoT Edge crea certificados?

En el ejemplo, observe que hay una instancia de iotedged workload ca edgegateway en la cadena de certificados. Es la entidad de certificación (CA) que existe en el dispositivo IoT Edge conocido como Edge CA (anteriormente conocido como Device CA en la versión 1.1). Al igual que DigiCert Global Root G2 en el ejemplo anterior, la Edge CA puede emitir otros certificados. Lo más importante, y también en este ejemplo, emite el certificado de servidor al edgeHub módulo. Pero también puede emitir certificados a otros módulos que se ejecutan en el dispositivo IoT Edge.

¿No es peligroso tener un certificado de emisor en el dispositivo?

La CA Edge está diseñada para habilitar soluciones con una conectividad que sea limitada, poco confiable, costosa o incluso ausente, pero que al mismo tiempo cuenten con estrictas regulaciones o políticas en cuanto a las renovaciones de certificados. Sin la CA de Edge, IoT Edge , y en particular edgeHub, no puede funcionar.

Para proteger la CA perimetral en producción:

• Coloque la clave privada de CA de Edge en un módulo de plataforma segura (TPM), preferiblemente de modo que la clave privada se genere de manera efímera y nunca salga del TPM.
• Use una infraestructura de clave pública (PKI) en la que se acumule la CA perimetral. Esta configuración proporciona la capacidad de deshabilitar o rechazar la renovación de certificados en peligro. La PKI se puede administrar mediante TI del cliente si tiene el conocimiento (costo menor) o a través de un proveedor de PKI comercial.

Especificad de CA raíz autofirmado

El módulo edgeHub controla todo el tráfico entrante para IoT Edge. En este ejemplo, utiliza un certificado emitido por Edge CA, que a su vez es emitido por una entidad de certificación raíz autofirmada. Dado que el sistema operativo no confía en la entidad de certificación raíz, la única manera TempSensor de confiar es instalar el certificado de CA en el dispositivo. Este método de confianza también se conoce como el escenario de paquete de confianza, donde debe distribuir el certificado raíz a los clientes que necesitan confiar en la cadena. El escenario de agrupación de confianza puede ser problemático porque necesita acceder al dispositivo e instalar el certificado. La instalación del certificado requiere planificación. Se puede hacer mediante scripts, agregados durante la fabricación o preinstalados en la imagen del sistema operativo.

Al aplicar todos estos conceptos, TempSensor puede comprobar que se está comunicando con el original EdgeGateway porque presentó un certificado que coincide con la dirección y el certificado está firmado por una raíz de confianza.

Para comprobar la cadena de certificados, puede usar openssl en el TempSensor dispositivo. En este ejemplo, el nombre de host de la conexión coincide con el CN del certificado depth 0 y el CA raíz coincide.

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 obtener más información sobre el openssl comando, consulte la documentación de OpenSSL.

También puede inspeccionar los certificados donde se almacenan de forma predeterminada en /var/lib/aziot/certd/certs. Puede encontrar certificados de CA perimetral, certificados de identidad de dispositivo y certificados de módulo en el directorio. Puede usar comandos openssl x509 para inspeccionar los certificados. Por ejemplo:

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

En resumen, TempSensor puede confiar EdgeGateway porque:

• El módulo edgeHub muestra un certificado de servidor de módulo IoT Edge válido para edgegateway.local.
• El certificado lo emite Edge CA, el cual a su vez es emitido por my_private_root_CA.
• Esta entidad de certificación raíz privada también se almacena en el TempSensor como entidad de certificación raíz de confianza previamente.
• Los algoritmos criptográficos comprueban que la propiedad y la cadena de emisión pueden ser de confianza.

Certificados para otros módulos

Otros módulos pueden obtener certificados de servidor emitidos por Edge CA; por ejemplo, un módulo de Grafana que tenga una interfaz web. También puede obtener un certificado de Edge CA. Los módulos se tratan como dispositivos de bajada hospedados en el contenedor. Sin embargo, poder obtener un certificado del entorno de ejecución del módulo IoT Edge es un privilegio especial. Los módulos llaman a la API de cargas de trabajo para recibir el certificado de servidor encadenado a la CA perimetral configurada.

La puerta de enlace comprueba la identidad del dispositivo

EdgeGateway¿Cómo comprueba que se está comunicando con TempSensor? EdgeGateway usa TLS client authentication para autenticar TempSensor.

La secuencia es similar a ContosoIotHub que comprueba un dispositivo. Pero en un escenario de puerta de enlace, EdgeGateway se basa en ContosoIotHub como fuente de veracidad para el registro del certificado. EdgeGateway también mantiene una copia o caché sin conexión si no hay ninguna conexión a la nube.

En resumen, EdgeGateway puede confiar TempSensor porque:

• TempSensor presenta un certificado de identidad de dispositivo IoT válido a su nombre.
• La huella digital del certificado de identidad coincide con la que se cargó en ContosoIotHub.
• Los algoritmos criptográficos comprueban que la propiedad y la cadena de emisión pueden ser de confianza.

Dónde obtener los certificados y la administración

En la mayoría de los casos, debe proporcionar sus propios certificados o usar certificados generados automáticamente. Por ejemplo, Edge CA y el certificado de edgeHub se generan automáticamente.

Pero el procedimiento recomendado es configurar los dispositivos para usar un servidor de inscripción a través de transporte seguro (EST) para administrar certificados x509. Un servidor EST le ayuda a evitar controlar e instalar manualmente certificados en dispositivos. Para obtener más información sobre el uso de un servidor EST, consulte Configurar la inscripción a través de un servidor de transporte seguro para Azure IoT Edge.

También puede usar certificados para autenticarse en el servidor EST. Estos certificados se autentican con servidores EST para emitir otros certificados. El servicio de certificados usa un certificado de arranque para autenticarse con un servidor EST. El certificado de arranque es de larga duración. Cuando se autentica por primera vez, el servicio de certificados solicita un certificado de identidad desde el servidor EST. El certificado de identidad se usa en futuras solicitudes EST al mismo servidor.

Si no puede usar un servidor EST, solicite certificados del proveedor PKI. Administre los archivos de certificado manualmente en IoT Hub y los dispositivos de IoT Edge. Para obtener más información, consulte Administrar certificados en un dispositivo IoT Edge.

Para el desarrollo de prueba de concepto, cree certificados de prueba. Para obtener más información, consulte Crear certificados de demostración para probar las características del dispositivo IoT Edge.

Certificados en IoT

Entidad de certificación

Una entidad de certificación emite certificados digitales. La ENTIDAD de certificación actúa como un tercero de confianza entre el propietario del certificado y el receptor del certificado. Un certificado digital demuestra que el receptor posee una clave pública. La cadena de confianza del certificado comienza con un certificado raíz, que es la base para confiar en todos los certificados que emite la entidad. El propietario del certificado raíz puede emitir certificados intermedios adicionales (certificados de dispositivo de bajada).

Certificado de entidad de certificación raíz

Un certificado de entidad de certificación raíz es la raíz de confianza para el proceso. En producción, normalmente se compra este certificado CA de una Autoridad de Certificación comercial de confianza como DigiCert. Si controla todos los dispositivos que se conectan a los dispositivos de IoT Edge, puede usar una entidad de certificación corporativa. En ambos casos, la cadena de certificados de IoT Edge a IoT Hub usa el certificado de entidad de certificación raíz. Los dispositivos IoT descendentes deben confiar en el certificado raíz. Almacene el certificado de entidad de certificación raíz en el almacén de entidades de certificación raíz de confianza o proporcione los detalles del certificado en el código de la aplicación.

Certificados intermedios

En un proceso de fabricación típico para dispositivos seguros, los fabricantes rara vez usan certificados de autoridad certificadora (CA) raíz directamente debido al riesgo de filtración o exposición. El certificado de entidad de certificación raíz crea y firma digitalmente uno o varios certificados intermedios. Puede haber una o una cadena de certificados intermedios. Entre los escenarios que requieren una cadena de certificados intermedios se incluyen:

• Jerarquía de departamentos dentro de un fabricante.
• Varias empresas implicadas en serie en la producción de un dispositivo.
• Un cliente que compra una entidad de certificación raíz y obtiene un certificado de firma para permitir al fabricante firmar los dispositivos en nombre del cliente.

El fabricante utiliza un certificado de CA intermedia al final de esta cadena para firmar el certificado de CA perimetral colocado en el dispositivo final. La planta de fabricación protege estrechamente estos certificados intermedios. Los procesos físicos y electrónicos estrictos controlan su uso.

Pasos siguientes

• Para obtener más información sobre cómo instalar certificados en un dispositivo IoT Edge y hacer referencia a ellos desde el archivo de configuración, consulte Administrar certificado en un dispositivo IoT Edge.
• Entender los módulos de Azure IoT Edge
• Configurar un dispositivo IoT Edge para que actúe como puerta de enlace transparente
• En este artículo se explica cómo los certificados protegen las conexiones entre los distintos componentes de un dispositivo IoT Edge o entre un dispositivo IoT Edge y los dispositivos de bajada. También puede usar certificados para autenticar el dispositivo IoT Edge en IoT Hub. Esos certificados de autenticación son diferentes y no se describen en este artículo. Para obtener más información sobre cómo autenticar el dispositivo con certificados, consulte Crear y aprovisionar un dispositivo IoT Edge mediante certificados X.509.