Facilitar el aprovisionamiento de IoT a escala

Ya sea que esté buscando diseñar un nuevo dispositivo o modernizar un dispositivo existente para IoT, deberá considerar el aprovisionamiento de IoT que lleva los dispositivos de IoT en línea a los servicios en la nube. El diseño de aprovisionamiento de IoT requiere que se tomen decisiones que afecten la experiencia del usuario y la seguridad tanto para la puesta en marcha de la red como para los mecanismos de aprovisionamiento de credenciales que configuran identidades digitales, puntos finales de la nube y credenciales de red para que los dispositivos puedan conectarse de forma segura a la nube.

Para realizar el aprovisionamiento de IoT a escala, los clientes a menudo crean y mantienen herramientas y aplicaciones de software personalizadas que pueden impulsar las credenciales requeridas a través de protocolos compatibles con sus dispositivos que abarcan múltiples dominios de problemas. Los dominios de aprovisionamiento de IoT incluyen:

• Puesta en servicio de la red, que proporciona mecanismos para que los clientes definan parámetros específicos del contexto;
• Aprovisionamiento de credenciales, que asigna credenciales y configuración a dispositivos físicos; y
• Aprovisionamiento en la nube, que establece los datos de configuración del lado de la nube que permiten la autenticación, la autorización y la administración de dispositivos.

Los tres dominios de aprovisionamiento deben funcionar en armonía para brindar una experiencia de usuario espectacular para el cliente.

Por ejemplo, un operador de telefonía móvil proporciona datos de configuración y ajustes de políticas cuando un usuario de teléfono móvil se conecta por primera vez. Este es un proceso simple y bien entendido que no toma mucho tiempo para el usuario del dispositivo móvil donde la tarjeta SIM representa la identidad del dispositivo. La situación se vuelve muy diferente y desafiante para los clientes, especialmente los fabricantes de equipos originales (OEM), que intentan aprovisionar millones de dispositivos de IoT.

A lo largo de este artículo, podrá aprender cómo evitar o mitigar los riesgos asociados con su propia implementación de IoT y comprender, a través de breves ejemplos, cómo un servicio de IoT proporcionado a través de plataformas en la nube como Amazon Web Services (AWS) lo ayuda a lograr sus objetivos de aprovisionamiento de IoT.

Enfoques para la puesta en servicio de la red cuando surge la necesidad

Finalmente, su dispositivo de IoT se conecta y se comunica con un servicio central que es el centro de su solución de IoT. Para llegar a ese centro, su dispositivo IoT debe unirse a un medio en red. El medio puede ser un cable duro, como Ethernet, o una transmisión de radio, como Wi-Fi. Dependiendo del medio, necesita que un humano le diga al dispositivo a qué medio debe unirse para tener éxito en llegar al concentrador. Por ejemplo, con la red celular, no necesitará decirle al dispositivo que la red se una porque esto ha sido definido por la tarjeta SIM. Por otro lado, para unirse a una red Wi-Fi, deberá conocer el nombre y la contraseña del Punto de acceso Wi-Fi y poder decirle al dispositivo estos detalles. Nos centraremos en los dispositivos que requieren configuración para unirse a una red.

Hay varios mecanismos diferentes que los clientes han estado utilizando para unirse a las redes de IoT. Casi todo el mundo tiene un teléfono inteligente en la actualidad y la mayoría de los teléfonos inteligentes tienen Bluetooth, por lo que la configuración a través de Bluetooth se ha vuelto omnipresente. Sin embargo, ese no es el único medio para conectarse. Algunos módulos de Wi-Fi en dispositivos IoT son lo suficientemente inteligentes como para convertirse en puntos de acceso por derecho propio, donde puede desarrollar una página web simple que permite a los usuarios ingresar la configuración de la red más grande. En el caso de los dispositivos que no son de consumo, sigue siendo común configurarlo en serie o microSD. La configuración de Bluetooth con la ayuda de una aplicación de teléfono inteligente se ha convertido en la norma. Estas aplicaciones para teléfonos inteligentes también pueden ayudar al aprovisionamiento de dispositivos en la nube, lo que descubrirá más adelante en este artículo.

Enfoques para el aprovisionamiento de credenciales de dispositivos a gran escala

Los procesos de aprovisionamiento de credenciales de dispositivos continúan estando muy fragmentados en toda la industria sin una línea de visión para la convergencia en el corto plazo. La mayoría de los sistemas centralizados de IoT sugieren, o requieren, una conexión Transport Layer Security (TLS) 1.2 para el transporte cifrado, que más recientemente, y quizás elocuentemente, se conoce como cifrado en tránsito. En la actualidad, la mayoría de las implementaciones de IoT utilizan Infraestructura de clave pública (PKI), por lo que el resto de este artículo asume el uso de PKI. En cualquier caso, es imperativo que cada dispositivo posea su propia clave privada y certificado de identificación únicos.

Para crear una sesión con una nube (o un punto final de servicio), TLS 1.2 requiere una clave privada y un certificado (o credencial) x.509. Nota:Algunas técnicas, como Java Web Tokens o JWT, presentan desafíos similares, pero no se discutirán aquí. La clave privada, que es como su ADN, solo debe ser conocida por un dispositivo individual, lo que significa que no debe compartirse con otros dispositivos. El certificado x.509, que es como una licencia de conducir, es emitido por una Autoridad de Certificación (CA) verificable al proporcionar una Solicitud de firma de certificado (CSR). Entregar un CSR no es muy diferente de entregarle a la entidad emisora ​​de pasaportes de su país su certificado de nacimiento con una huella digital y prueba de otras pruebas aprobadas como prueba para recibir un pasaporte. A lo largo de este artículo, nos referimos al certificado x.509 como una credencial, asumiendo que el dispositivo tiene una clave privada única.

Los detalles de TLS 1.2 están más allá del alcance de este artículo, pero solo le brindaremos suficiente información para que esté un poco informado para que pueda comprender por qué es imperativo que el dispositivo proteja la clave privada. Durante el proceso de conexión de TLS 1.2, se producen una serie de intercambios para demostrar que el dispositivo es el propietario de la clave privada que es su identidad. Su dispositivo debe demostrar que es el propietario real del certificado x.509 que está intentando utilizar para la autenticación. Para que el servicio de IoT confíe en una credencial de dispositivo cuando su dispositivo se conecta, debe tener esa clave privada a mano. Ahora puede darse cuenta de que si un mal actor se apodera de esa clave, el modelo de seguridad se desmorona. ¡Proteja a toda costa las llaves de su castillo de IoT!

Como la mayoría de los que están implementando IoT, debe tomar decisiones sobre cómo aprovisionar estas credenciales a escala. Para revisar brevemente, cada dispositivo debe tener:

• Una clave privada única e inmutable que representa el dispositivo. Idealmente, para protegerse contra ataques simultáneos y otros ataques avanzados, la clave privada debe estar protegida físicamente y no debe cargarse en la memoria principal del programa.
• Una credencial relacionada con su aplicación o servicio de IoT.

La logística difiere entre las opciones para el aprovisionamiento de credenciales y claves privadas, algunas de las cuales son independientes del aprovisionamiento en la nube y otras que dependen del aprovisionamiento en la nube.

• Módulos de seguridad de circuito integrado (que generalmente tienen capacidades criptográficas), ya sea de forma independiente o participando en un diseño de System-In-Package (SiP), System-On-Module (SoM) o System-On-Chip (SoC), tener uno de los siguientes comportamientos:

• • Un módulo de seguridad que tiene una clave privada o raíz de confianza aprovisionada manualmente o autogenerada.
  • Además del elemento anterior, el módulo de seguridad proporciona credenciales en forma de certificados x.509 aprovisionados previamente.

• Las tecnologías Subscriber Identity Module (SIM), embedded-SIM (eSIM) y SIM integrada (iSIM) proporcionan hardware que los diseñadores utilizan como identidad celular para comunicarse con redes celulares. El aprovisionamiento de credenciales generalmente depende del proveedor del operador de red móvil (MNO), del proveedor de red virtual móvil (MVNO) o de un tercero. Si está utilizando módulos celulares para la comunicación, esta es su elección.
• Aprovisionamiento de credenciales de dispositivo automatizado y personalizado a un segmento de dispositivo flash, que podría tener un flash seguro especial, junto con un módulo de seguridad de hardware (HSM) durante la fabricación.
• Aprovisionamiento manual de claves privadas y credenciales para flash seguro seguro especial (o flash no seguro, generalmente durante la creación de prototipos, pero no se recomienda para el aprovisionamiento de flotas).

La ejecución de TLS 1.2 es una actividad de cómputo intensivo debido a los requisitos de criptografía, que a su vez influye en la elección de componentes de cómputo, especialmente si está utilizando un microcontrolador para su diseño. Los circuitos integrados especializados generalmente incluyen rutinas de criptografía, que evitan que el procesador host aplique ciclos en la operación de TLS 1.2 al tiempo que garantizan que la clave privada no se cargue en la memoria principal.

El enfoque que adopte para el hardware depende del diseño de su hardware. La elección de una solución elegante para el diseño de hardware ciertamente simplifica el aprovisionamiento a escala, pero requiere la selección de componentes al principio del ciclo de vida del diseño de hardware, ya que influye en otras opciones de diseño de componentes para cómputo, módulos de criptografía, coprocesamiento matemático y flash. Ciertamente, para los dispositivos a gran escala, no querrá aprovisionar manualmente, y las tendencias sugieren que los dispositivos aprovisionados previamente producen la menor fricción desde las perspectivas de fabricación, operaciones y experiencia del cliente.

El aprovisionamiento de dispositivos de IoT requiere la orquestación de dispositivos y la nube

El aprovisionamiento exitoso de dispositivos de IoT requiere una orquestación de aprovisionamiento de dispositivos y en la nube que influya en el diseño de hardware y software, así como en la forma en que administrará los dispositivos a lo largo del ciclo de vida del dispositivo.

Desde la perspectiva del servicio de IoT, necesitará un proceso que se alinee con su elección de aprovisionamiento de credenciales para crear objetos de configuración relacionados. Cuando el dispositivo se conecta a un servicio de IoT, el servicio de IoT debe poder reconocer el dispositivo (autenticación), habilitar acciones específicas del dispositivo (autorización) y operar y administrar el dispositivo en un contexto específico (administración de dispositivos).

Para la autenticación, el servicio de IoT debe tener una huella digital de la credencial para que cuando el dispositivo se conecte y envíe la credencial al servicio de IoT, el servicio de IoT pueda relacionar la conexión física con los objetos de configuración. Para AWS IoT, registra su credencial, lo que permite que el servicio de IoT reconozca la conexión entrante. El protocolo de enlace TLS, que requiere que el dispositivo tenga acceso a la clave privada (que el servicio de IoT no tiene) garantiza que la credencial se haya enviado desde el dispositivo con la clave privada. Por eso es tan esencial proteger la clave privada en el dispositivo.

Para la autorización, el servicio de IoT debe aplicar reglas a la conexión que otorgue el acceso mínimo al servicio de IoT. El acceso mínimo al servicio de IoT significa establecer límites para que el dispositivo utilice solo los recursos que necesita para cumplir con su obligación operativa. Por ejemplo, los clientes de AWS crean políticas de IoT que se relacionan con el objeto de configuración de la credencial.

Para la administración de dispositivos, querrá aplicar metadatos a sus objetos de configuración para especificar claramente grupos o agregaciones de dispositivos o flotas. Con IoT, necesitaremos administrar miles, decenas de miles y millones de dispositivos. No será práctico administrar cada dispositivo individualmente. Planifique con anticipación para aplicar metadatos a la configuración de su dispositivo porque la actualización o la refactorización pueden ser dolorosas. Para AWS IoT, crea objetos de configuración de Thing Type y Thing Group que impulsan las prácticas de administración de dispositivos de IoT.

Enfoques para el aprovisionamiento de dispositivos en la nube a escala

No se puede decir que todos La implementación de IoT es diferente en lo que respecta al aprovisionamiento de dispositivos, pero hay suficiente diferenciación entre los proveedores de hardware, las aplicaciones de IoT y los contextos operativos para impulsar un conjunto sólido de mecanismos que influirán en su decisión sobre el mecanismo adecuado para usted. En términos generales, hay tres enfoques:registro masivo, registro bajo demanda y registro diferido. Todos los métodos siguientes esperan que cada dispositivo de IoT tenga, o tendrá, su propia clave privada y un par de certificados únicos.

Registro masivo

Con el registro masivo, el conjunto de credenciales que desea registrar con un servicio de IoT se conoce antes de la implementación del dispositivo en el campo. Una vez que se haya obtenido la lista de credenciales, canalice las credenciales a un proceso de registro masivo. El proceso de registro masivo registra la credencial y luego también coordina la credencial con los objetos de administración relacionados en el servicio de IoT que utiliza para administrar su flota de IoT. El registro masivo puede requerir personalización, pero los proveedores de servicios de IoT generalmente brindan un proceso de registro masivo a los clientes. Por ejemplo, AWS proporciona el proceso de registro masivo de AWS IoT como parte del servicio AWS IoT Core y el procesamiento personalizado mediante AWS SDK. Un proyecto de código abierto llamado ThingPress maneja casos de uso de importación específicos.

Registro bajo demanda

Con el registro de dispositivos a pedido, no conoce el conjunto de dispositivos físicos con credenciales emparejadas antes de la implementación del dispositivo en el campo. Una vez que el dispositivo se haya implementado en el campo, lo encenderá. Con bajo demanda, una subrutina de conectividad determina si se ha registrado una referencia al emisor de la credencial en el servicio de IoT. Siempre que el servicio de IoT tenga un mecanismo sólido para verificar que, de hecho, usted es el propietario del emisor, lo que significa que tiene a mano la identidad del emisor (en PKI, la clave privada del emisor), puede estar seguro de que el emisor proporcionó la credencial. Luego, la subrutina registra automáticamente la credencial y crea objetos de administración relacionados. Por ejemplo, AWS tiene dos mecanismos de registro de dispositivos bajo demanda llamados Just-In-Time-Provisioning (JITP) que utiliza una plantilla de aprovisionamiento y Just-In-Time-Registration (JITR) que proporciona mecanismos que se pueden personalizar por completo.

Registro diferido

Con el registro diferido, ni el conjunto de dispositivos físicos ni las credenciales emparejadas se conocen antes de la implementación en el campo. En este caso, los dispositivos tienen una identidad conocida e inmutable (normalmente, una clave privada protegida) que el servicio de IoT puede confirmar sin transferir la identidad privada más allá del dispositivo.

En la actualidad, existen tres mecanismos para el registro diferido:por reclamo, por dispositivo móvil autorizado y por lista autorizada de identidades. En el primer caso, el dispositivo envía la reclamación al emisor de la credencial, el emisor responde con un token y el dispositivo usa el token para realizar una llamada directa a la API del servicio web para emitir el certificado. En el segundo caso, el dispositivo funciona en conjunto con un teléfono móvil, donde el teléfono móvil usa credenciales móviles, como un nombre de usuario y contraseña, el emisor responde con un token, el teléfono móvil envía el token al dispositivo y el dispositivo usa el token para realizar una llamada directa a la API. En el tercer caso, una lista autorizada, que puede ser una lista de claves públicas, y el dispositivo realiza una llamada API directa al servicio de IoT con un CSR. La clave pública derivada de la CSR se compara con la lista autorizada y, a continuación, proporciona el certificado al dispositivo cuando existe una coincidencia. Por ejemplo, el aprovisionamiento de AWS Fleet proporciona mecanismos de aprovisionamiento basados ​​en notificaciones y teléfonos inteligentes, el proyecto de código abierto IoT Provisioning Secret-Free proporciona mecanismos de registro diferidos mediante notificaciones, y el socio de AWS 1nce brinda una experiencia de aprovisionamiento celular optimizada a través de AWS Marketplace.

Elegir el aprovisionamiento de dispositivos adecuado para usted

Elegir el aprovisionamiento de dispositivos adecuado para usted significa encontrar la credencial del dispositivo y la práctica de aprovisionamiento en la nube del dispositivo que se alinee con el diseño de hardware, el diseño de software, la fabricación y las operaciones del ciclo de vida del dispositivo. El diseño del hardware define cómo se definen y almacenan los archivos de credenciales e identidad de dispositivos individuales. El diseño del software influye en la autorización del dispositivo. La fabricación influye en las condiciones en las que los secretos se crearán y almacenarán, o se identificarán, influyen en la forma en que las huellas dactilares de autorización se reflejan en los servicios de IoT.

La forma en que decide realizar el aprovisionamiento de credenciales para el hardware físico, que refleja el diseño de hardware que generalmente se decide con mucha anticipación al diseñar el producto, crea un pivote fundamental para tipos específicos de procesos de aprovisionamiento en la nube. Además, si no está haciendo su propia fabricación, entonces utilizará fabricantes contratados para construir sus productos. La fabricación por contrato tiene muchos beneficios, pero muchos aspectos del proceso de fabricación no estarán bajo su control, lo que incluye la creación de secretos de dispositivos como claves privadas y certificados en la línea de fabricación. Los riesgos como la sobreproducción, la clonación y otros vectores de ataque pueden relacionarse directamente con el fabricante contratado contratado, lo que significa que debe tener mucha confianza para dormir tranquilo por la noche.

Si no administra una CA privada para su flota de IoT, las credenciales aprovisionadas previamente pueden ser las adecuadas para usted. Las credenciales aprovisionadas previamente pueden costar un poco más por adelantado, pero hemos visto que reducen significativamente los costos operativos. Si necesita administrar su propia CA privada, algunas empresas de hardware proporcionan credenciales aprovisionadas previamente cuando la configuración se realiza al final del proceso, lo que significa que el fabricante contratado no tendrá ningún conocimiento de los secretos del dispositivo. De lo contrario, es posible que desee inclinarse hacia el aprovisionamiento de estilo perezoso donde el dispositivo tiene la clave privada inmutable o la clave privada autogenerada reproducible en el dispositivo y puede participar con un servicio de IoT para implementar las credenciales después de cierto nivel de certificación. Si se queda en la desafortunada situación de no tener una clave privada inmutable en el dispositivo, aún puede proporcionar una clave privada y una credencial directamente para flashear, pero esto no es muy recomendable.

A diferencia del diseño de hardware, el diseño de software es más flexible y puede cambiar durante el desarrollo del dispositivo e incluso durante el ciclo de vida (piense en las actualizaciones de firmware por aire). Siempre que envíe un nuevo lote de dispositivos a los clientes, deberá apoyarse en el proceso de aprovisionamiento de dispositivos en la nube. Al igual que el diseño de software, el diseño de aprovisionamiento puede requerir flexibilidad en función de los requisitos de software en evolución. La configuración requerida y la amplitud de personalización impulsan el proceso de aprovisionamiento de dispositivos en la nube que utilizará al implementar flotas de dispositivos nuevos o adicionales.

Los requisitos de las operaciones del ciclo de vida del dispositivo impulsarán el nivel de flexibilidad que se requerirá para el aprovisionamiento de dispositivos en la nube. Más específicamente, si bien la mayoría de los procesos para el aprovisionamiento en la nube de dispositivos de AWS IoT permiten la creación automática de objetos de administración como tipos de cosas y grupos de cosas, si su proceso también requiere interoperabilidad personalizada durante el tiempo de registro, es posible que desee considerar Just-In-Time- Aprovisionamiento que permite una personalización más profunda.

Finalmente, al observar el ciclo de vida del dispositivo, considere la oportunidad de que el dispositivo cambie de propietario humano a lo largo de su utilidad. Si bien es posible que la identidad del dispositivo en términos de la clave privada no cambie, existe la oportunidad de desaprobar el Certificado del propietario anterior para mover el dispositivo a un "estado de fábrica". Cuando el nuevo propietario humano encarga el dispositivo a una nueva red y lo aprovisiona usando quizás una aplicación móvil, es posible que deba aprovisionarse un Certificado nuevo en ese momento. La mecánica del ciclo de vida tendría que acompañar a esos requisitos.

Conclusión

A lo largo de este artículo, analizamos situaciones de aprovisionamiento de IoT que probablemente esté presenciando hoy. Del mismo modo, ha sido testigo de que hay muchas opciones según lo que esté tratando de lograr y los resultados que desea que disfruten sus clientes. Como todo, la seguridad sustenta el aprovisionamiento, que comienza con cada dispositivo que tiene su propia clave privada y un par de certificados únicos e identificables. El enfoque de aprovisionamiento de credenciales que elija crea ese punto de pivote para las opciones de aprovisionamiento en la nube de su dispositivo. Si está haciendo un nuevo diseño, querrá analizar detenidamente las soluciones de seguridad de hardware reforzadas, como elementos seguros y enclaves seguros, que a su vez simplifican el aprovisionamiento de dispositivos en la nube. Si está evolucionando o reelaborando un diseño existente, sus opciones pueden parecer mucho más limitadas, pero todavía hay opciones para que conecte su dispositivo en una capacidad de IoT. Finalmente, a través de los ejemplos y anécdotas, pudo presenciar que AWS IoT ha brindado soluciones de aprovisionamiento de dispositivos en la nube que combinan bien con nuestras soluciones de socios de silicio. ¡Ahora es el momento de empezar a construir dispositivos de IoT encargados y aprovisionados de forma segura!