Una solución segura que conecta dispositivos IoT a la nube

　　Aunque la gente es cada vez más consciente de la necesidad de seguridad, los desarrolladores a menudo se ven tomando atajos para conectar dispositivos IoT a la nube. En muchos casos, el conflicto entre la complejidad de los mecanismos de seguridad adecuados, la memoria limitada y los recursos de procesamiento disponibles en los dispositivos IoT alimentados por microbaterías, y la demanda de transportar productos parece insuperable.

　　Para abordar estos problemas y simplificar la implementación de funciones de seguridad en dispositivos IoT, Microchip Technology y Google han colaborado para crear un método que combina las características de hardware seguro de Microchip con una estructura de datos sencilla llamada JSON Web Token (JWT). El resultado es una forma sencilla de garantizar la autenticación mutua entre dispositivos IoT y los servicios núcleo IoT de Google Cloud.

　　Este artículo presentará las amenazas de seguridad para los dispositivos IoT y los dispositivos que actualmente se utilizan para hacer frente a estas amenazas. Identificará vulnerabilidades de seguridad y cómo los desarrolladores y diseñadores de sistemas embebidos utilizan JWT para desactivarlas.

　　Vulnerabilidades de seguridad en dispositivos IoT

　　Los ataques a dispositivos IoT pueden adoptar muchas formas y están lejos de limitarse a despliegues a gran escala de IoT. Para los hackers que buscan explotar recursos de muchos dispositivos individuales en botnets utilizadas para ataques de denegación de servicio distribuida (DDoS), incluso el IoT más pequeño es un objetivo atractivo. Por lo tanto, los diseñadores de todo tipo de dispositivo IoT inevitablemente necesitan proteger sus sistemas mediante mecanismos de seguridad robustos basados en hardware para prevenir ataques.

　　Por ejemplo, usar memoria del sistema o almacenamiento flash para almacenar claves privadas de cifrado y autenticación hace que los dispositivos IoT sean vulnerables a ataques. Peor aún, los hackers pueden robar estas claves y usarlas para acceder a redes IoT y recursos adicionales de la empresa.

　　IC de seguridad

　　Dispositivos de seguridad dedicados, como los CryptoMemory y CryptoAuthentication ICs de Microchip Technology, cuentan con funciones de hardware basadas en mecanismos para proteger claves privadas y otros datos secretos. Las matrices EEPROM están integradas en estos dispositivos, proporcionando almacenamiento seguro y mecanismos de seguridad de cifrado accesibles solo a través de la interfaz serial SPI o I2C del dispositivo (véase la Figura 1). Por lo tanto, estos dispositivos ofrecen una forma sencilla de añadir almacenamiento seguro y otras características de seguridad a cualquier diseño de dispositivo IoT.

　　Figura 1: Los dispositivos de seguridad de hardware de Microchip Technology (como AT88SC0204C CryptoMemory IC) proporcionan almacenamiento seguro y utilizan mecanismos de cifrado integrados para proteger el acceso a EEPROM integradas. (Imagen: Tecnología de Microchip)

　　Los miembros de la serie Microchip CryptoAuthentication (como ATECC608A) mejoran la base del almacenamiento seguro y soportan algoritmos de cifrado comúnmente usados en el diseño de seguridad. Entre sus características de hardware, el dispositivo cuenta con aceleración por hardware para varios algoritmos, entre ellos:

　　Algoritmo de cifrado asimétrico:

　　Algoritmo de Firma Digital de Curvas Elípticas FIPS186-3 (ECDSA)

　　FIPS SP800-56A Curva Elíptica Diffie-Hellman (ECDH)

　　Cifrado estándar de curvas elípticas P256 del NIST (ECC)

　　Algoritmo de cifrado simétrico:

　　Código hash SHA-256

　　Criptografía con Código de Autenticación de Mensajes basada en Hash (HMAC)

　　Criptografía AES-128

　　Criptografía AES-GCM (Multiplicación de Campos de Galois)

　　Función de derivación clave (KDF):

　　Función pseudoaleatoria (PRF) KDF

　　Extracción basada en HMAC – y expansión del KDF (HKDF)

　　Para los expertos en criptografía, este conjunto de funciones de cifrado representa una lista completa de mecanismos necesarios para soportar protocolos de seguridad de mayor nivel. Autenticación e intercambio seguro de datos. Por ejemplo, la característica KDF proporciona los mecanismos básicos necesarios para que los protocolos de Seguridad de la Capa de Transporte (TLS) verifiquen a los participantes en las sesiones de intercambio de datos antes de los intercambios o incluso de comenzar.

　　En este protocolo, las sesiones TLS envían solicitudes de los clientes al servidor para iniciar una sesión segura. El servidor responde utilizando su certificado digital, que el cliente utiliza para confirmar la identidad del servidor. Después de que el cliente verifica el servidor de esta manera, la configuración de sesión continúa generando claves de sesión usando la clave pública del servidor para cifrar algunos valores aleatorios creados con PRF KDF o el más potente HDKF.

　　El protocolo de autenticación TLS es la base de la seguridad en Internet. Toda la industria de proveedores de certificados, conocida como Autoridad Certificadora (CA), ha evolucionado hasta convertirse en un componente clave que apoya las comunicaciones seguras. La empresa obtiene un certificado de confianza de la CA para instalarlo en sus propios servidores, soportando el mencionado protocolo estándar de autenticación TLS para servidores.

　　Para aplicaciones IoT, las redes están ampliamente y profundamente conectadas a las empresas, y esta autenticación unidireccional es insuficiente para garantizar protección. Por ejemplo, hackers con certificados fraudulentos podrían presentarse como servidores legítimos para dispositivos IoT como parte de un ataque más amplio.

　　A pesar de los riesgos, los desarrolladores de IoT a menudo tienen dificultades para implementar protocolos de autenticación mutua TLS porque los certificados, claves y software necesarios para la autenticación de clientes usando TLS pueden superar las capacidades de muchos dispositivos IoT. A través de la colaboración, Microchip Technology y Google han creado un enfoque alternativo que combina ATECC608A funcionalidad con una estructura de datos sencilla llamada JSON Web Token (JWT). El resultado es una forma sencilla de garantizar la autenticación mutua entre dispositivos IoT y los servicios núcleo IoT de Google Cloud.

　　Autenticación basada en JWT

　　La RFC 7519 especifica que JWT es un contenedor estándar de la industria para la información sobre la entidad que prepara y transmite JWT, conocido como reclamación. La estructura JWT en sí consta de tres partes:

　　Títulos, incluido el nombre JSON: el nombre del algoritmo criptográfico ("alg") (por ejemplo, el "EC256" de ECDSA utiliza la curva P-256 del NIST) para firmar tokens y tipos de token ("typ") (el "JWT" de estos tokens)

　　Payload, incluyendo el par de valores JSON name: para cada afirmación

　　Firma: Utiliza el algoritmo especificado en el encabezado para codificar la clave, el encabezado y el conjunto de declaraciones, cada uno convertido individualmente a la codificación de la URL base64 antes del cifrado

　　La RFC 7519 ofrece gran flexibilidad para especificar reclamaciones en cargas útiles u otras partes. El estándar incluso permite JWTs inseguros creados sin firma ni cifrado, en cuyo caso el encabezado incluirá el nombre del algoritmo: par de valores {{alg":"none"}. Para los JWT utilizados con los servicios núcleos IoT de Google Cloud, Google necesita una sección de firma y una carga útil que contenga tres declaraciones obligatorias, que incluyen:

　　"iat" - La "hora de emisión" al crear el token en formato de marca de tiempo ISO 8601 UTC, el número de segundos desde 1970-01-01T00:00:00Z (por ejemplo, 1561896000 12:00 GMT del 30 de junio de 2019)

　　"exp" - La marca de tiempo UTC que especifica la hora de caducidad del token, hasta 24 horas que supere el valor "IAT" más un periodo de gracia de 10 minutos, para abordar diferentes sesgos de reloj del sistema entre cliente y servidor (por ejemplo, 1 de julio de 2019 1561982400, GMT 00:00 00:00)

　　"aud" - una cadena que contiene el ID del proyecto Google Cloud del desarrollador

　　< p> la solución de autenticación de dispositivos IoT de Google combina la autenticación convencional basada en TLS con JWT, creada con estas declaraciones relativamente simples para la autenticación de dispositivos IoT. Para iniciar una nueva sesión, el dispositivo IoT abre un socket seguro hacia el servidor y autentica el servidor usando el mismo protocolo TLS descrito anteriormente.

　　El siguiente paso en este proceso se basa en el protocolo ligero de transmisión de telemetría de cola de mensajes (MQTT) de Google IoT Cloud para transacciones en redes IoT. Utilizando un socket seguro a un servidor autenticado, el dispositivo IoT utiliza su JWT único como contraseña de inicio de sesión para "iniciar sesión" en el servicio anfitrión MQTT en ese servidor (Inventario 1).

　　Aunque los dispositivos IoT envían nombres de usuario como parte de esta secuencia de inicio de sesión, los nombres de usuario no se utilizan para la autenticación. Por lo tanto, se transfirió un nombre de usuario virtual (Listado 2). En su lugar, la autenticación de dispositivos IoT se basa en JWT enviado como contraseña de acceso. Dado que las firmas JWT son una combinación de encabezados, cargas útiles y claves privadas de dispositivos, los servicios principales de IoT de Google Cloud pueden verificar si JWT realmente proviene de dispositivos autorizados. Para esta verificación, los Servicios IoT de Google Cloud utilizan claves públicas de dispositivos previamente almacenadas en Google Cloud por desarrolladores de dispositivos IoT utilizando el proceso de gestión de claves descrito a continuación. En comparación con el uso solo de TLS, este enfoque proporciona autenticación mutua mediante un enfoque híbrido, acelerando los procesos y reduciendo los requisitos de recursos para los dispositivos IoT.

　　Facilitadores clave

　　ATECC608A y la funcionalidad de su cadena de suministro son los principales motores de este enfoque. Aunque cualquier MCU puede eventualmente generar firmas de cifrado cifradas a partir de cabeceras y cargas útiles JWT, cualquier método solo de software sigue siendo vulnerable a ataques sin almacenamiento de claves de seguridad basado en hardware. Además, para muchos dispositivos o aplicaciones IoT con recursos limitados y requisitos estrictos de tiempo de respuesta, puede prohibirse la carga y ejecución del procesador para la implementación "solo por software". Por último, sin algoritmos de seguridad extensos y una experiencia más avanzada en protocolos, es difícil para los desarrolladores implementar las funciones de software necesarias. Microchip aborda estos problemas a través de su biblioteca CryptoAuthLib (Figura 2).

　　Figura 2: Debido a que CryptoAuthLib utiliza la capa de abstracción de hardware (HAL) para separar funciones API y primitivas centrales del hardware subyacente, los desarrolladores pueden posicionar su software para varios dispositivos de soporte. (Imagen: Tecnología de Microchip)

　　Microchip CryptoAuthLib simplifica la implementación de funciones seguras de IoT, como el protocolo de autenticación Google JWT, reduciendo las complejas operaciones de seguridad a un conjunto de llamadas a funciones proporcionadas a través de la interfaz de programación de aplicaciones (API) CryptoAuthLib. Para los desarrolladores de IoT, quizás la más importante sea la función central Microchip CryptoAuthLib, que aprovecha al máximo los circuitos integrados de cifrado Microchip como ATECC608A para acelerar la ejecución de las funciones de seguridad en el diseño. Por ejemplo, en el Anuncio 1, una llamada a atca_jwt_finalize() utiliza dispositivos de cifrado disponibles (como ATECC608A) para crear un JWT para la contraseña en el Anuncio 2. En este caso, ATECC608A acelerar el cifrado de las firmas JWT, lee el diseño desde su clave integrada de almacenamiento seguro hasta completar el proceso de creación de firmas descrito anteriormente.

　　Sin embargo, incluso con software complejo y dispositivos de seguridad, los dispositivos IoT siguen siendo vulnerables a ataques debido a los métodos tradicionales para gestionar claves y certificados. En el pasado, las claves privadas debían generarse externamente y cargarse en dispositivos de almacenamiento seguros durante la fabricación, distribución o incluso despliegue. Incluso al utilizar módulos de seguridad hardware y facilidades de seguridad, secretos brevemente existentes más allá del único dispositivo "necesario saberlo" representan vulnerabilidades de seguridad que podrían exponerse accidental o intencionadamente. Aprovechando las capacidades ATECC608A, Microchip y Google han eliminado en gran medida las vulnerabilidades tradicionales de seguridad.

　　En este nuevo enfoque, Microchip utiliza la capacidad del ATECC608A para generar pares de claves sin dejar el dispositivo con una clave privada (Figura 3). Microchip utiliza entonces un certificado intermedio para firmar la clave pública generada por el dispositivo, que es proporcionada por el cliente y almacenada en un servidor seguro dentro de las instalaciones de seguridad de Microchip. Por último, Microchip transmite de forma segura la clave pública a la cuenta del cliente en el Google Cloud IoT Device Manager, que puede almacenar hasta tres claves públicas por dispositivo para soportar políticas de rotación de claves. Tras el despliegue, los dispositivos IoT pueden utilizar ATECC608A características de seguridad para crear JWTs que se usan en el proceso de autenticación mutua descrito anteriormente.

　　Figura 3: La combinación de Microchip Technology y los servicios IoT de Google Cloud simplifica la configuración de claves y certificados, proporcionando un mecanismo protegido orientado a reforzar la seguridad de las aplicaciones IoT. (Imagen: Google)

　　Esta colaboración entre Microchip y Google permite a los desarrolladores deshacerse completamente de este proceso crítico de gestión de claves. Para requisitos personalizados, los desarrolladores pueden utilizar la función de la API de CryptoAuthLib atcab_genkey() para implementar su propio proceso de gestión de claves, lo que permite ATECC608A generar pares de claves, almacenar claves privadas en su almacenamiento seguro y devolver la clave pública asociada. /p>

　　Para explorar la generación de claves y otras características de seguridad ATECC608A, los desarrolladores pueden construir rápidamente un entorno de desarrollo integral basado en el kit de evaluación Microchip SAM D21 Xplained Pro. Basado en Microchip ATSAMD21J18A Arm ® Cortex-M0 ® + MCU de 32 bits, el kit SAM D21 Xplained Pro proporciona un controlador y módulo de código completo de plataforma de hardware soportado por el Advanced Software Framework (ASF) de Microchip.

　　Para evaluar dispositivos de CryptoAutenticación, incluyendo ATECC608A, los desarrolladores pueden simplemente insertar la placa adicional XPRO-B de CryptoAuth en una de las dos cabezas de extensión de la placa Xplained Pro. Microchip ofrece software de ejemplo para evaluar las características de seguridad de CryptoAuthLib y ATECC608A. Además, los desarrolladores pueden insertar la placa adicional Wi-Fi Microchip ATWINC1500-XPRO en otro encabezado para ejecutar el software de muestra Microchip, que demuestra el proceso de autenticación mutua descrito en este artículo, incluyendo la autenticación de servidor TLS y la autenticación de dispositivos JWT.

　　Conclusión

　　Aunque la seguridad de las aplicaciones IoT conlleva múltiples requisitos, el principal desafío suele residir en implementar la autenticación mutua para dispositivos IoT y recursos en la nube. En sistemas IoT con recursos limitados, los protocolos tradicionales pueden superar la memoria y los recursos de procesamiento disponibles. Utilizando la biblioteca CryptoAuthLib de Microchip Technology y ATECC608A CryptoAuthentication IC, los desarrolladores pueden implementar un enfoque más eficiente basado en tokens web JSON para conectar de forma segura dispositivos IoT a los servicios IoT de Google Cloud.