Una solución más sencilla para conectar de forma segura los dispositivos de IoT a la nube

Por Stephen Evanczuk

Colaboración de Editores de Digi-Key de América del Norte

A pesar de ser cada vez más conscientes de cuán necesaria es la seguridad, los desarrolladores a menudo toman atajos en seguridad para conectar dispositivos de IoT a la nube. En muchos casos, los conflictos entre la complejidad de los mecanismos de seguridad adecuados, la memoria y los recursos limitados de procesamiento disponibles en pequeños dispositivos de IoT alimentados por batería, y la necesidad de enviar resultados parecen imposibles de superar.

Para solucionar estos problemas y simplificar la implementación de las características de seguridad en dispositivos IoT, Microchip Technology y Google colaboraron para crear un enfoque que combina las capacidades de hardware seguro de Microchip con una estructura de datos simple llamada JSON Web Token (JWT). El resultado es un método fácil para garantizar la autenticación mutua entre los dispositivos IoT y los servicios de Google Cloud IoT Core.

Este artículo describirá la amenaza a la seguridad de los dispositivos de IoT y presentará los dispositivos que se utilizan actualmente para contrarrestar esa amenaza. Identificará las brechas de seguridad y cómo los desarrolladores y diseñadores de sistemas integrados pueden usar JWT para cerrarlas.

La vulnerabilidad en seguridad de los dispositivos de IoT

Los ataques a dispositivos de IoT pueden tomar muchas formas y de ninguna manera se limitan a implementaciones de IoT a gran escala. Incluso la red IoT más pequeña es un objetivo atractivo para los hackers que buscan aprovechar los recursos de muchos dispositivos individuales en botnets (redes de equipos infectados por malware) diseñados para ataques de denegación de servicio distribuido (DDoS) y otros. Como resultado, los diseñadores de cada clase de dispositivos de IoT inevitablemente enfrentan la necesidad de proteger sus sistemas con mecanismos de seguridad robustos basados en hardware y capaces de frustrar ataques.

Por ejemplo, el uso de la memoria del sistema o la memoria flash para almacenar las claves privadas utilizadas para el cifrado y la autenticación hace que el dispositivo de IoT sea vulnerable. Peor aún, los hackers pueden robar esas claves y usarlas para obtener acceso a la red de IoT y los recursos corporativos adjuntos.

Los IC de seguridad

Dispositivos de seguridad especializados, como los IC CryptoMemory y CryptoAuthentication de Microchip Technology, cuentan con mecanismos basados en hardware para proteger las claves privadas y otros datos secretos. Una matriz de EEPROM (Memoria programable y borrable de sólo lectura) integrada en estos dispositivos proporciona almacenamiento seguro al que solo se puede acceder a través de mecanismos criptográficos seguros, a los que a su vez se accede a través de la SPI (interfaz periférica serial) o de la interfaz I2C del dispositivo (Figura 1). Como resultado, estos dispositivos proporcionan un método simple para agregar almacenamiento seguro y otras características de seguridad a cualquier diseño de dispositivo de IoT.

Diagrama de la tecnología de microchip del IC CryptoMemory AT88SC0204C

Figura 1: Los dispositivos de seguridad de hardware de Microchip Technology como el IC CryptoMemory AT88SC0204C proporcionan almacenamiento seguro, utilizando mecanismos criptográficos integrados para proteger el acceso a la EEPROM en el chip. (Fuente de la imagen: Microchip Technology)

Los miembros de la familia CryptoAuthentication de Microchip, como el ATECC608A, mejoran esa base de almacenamiento seguro con soporte para algoritmos de criptografía comúnmente utilizados en diseños seguros. Entre sus características de hardware, el dispositivo cuenta con aceleración de hardware para múltiples algoritmos, incluidos los siguientes:

  • Algoritmos de criptografía asimétrica:
    • Algoritmo de firma digital de curva elíptica (ECDSA) FIPS186-3
    • Diffie-Hellman de curva elíptica (ECDH) FIPS SP800-56A
    • Criptografía de curva elíptica (ECC) P256 estándar NIST
  • Algoritmos de criptografía simétrica:
    • Criptografía hash SHA-256
    • Criptografía de código de autenticación de mensajes basada en funciones hash (HMAC)
    • Criptografía AES-128
    • Criptografía AES-GCM (multiplicación de campos de Galois)
  • Funciones de derivación de claves (KDF):
    • KDF de función pseudoaleatoria (PRF)
    • KDF de extracción y expansión basado en HMAC (HKDF)

Para los expertos en criptografía, este conjunto de características de criptografía representa una lista completa de los mecanismos necesarios para admitir protocolos de seguridad de nivel superior para la autenticación y el intercambio seguro de datos. Por ejemplo, la capacidad KDF proporciona mecanismos esenciales requeridos por el protocolo de seguridad de la capa de transporte (TLS) para autenticar a los participantes en una sesión de intercambio de datos antes de que comience el intercambio.

En este protocolo, una sesión TLS comienza con un cliente que envía al servidor una solicitud para iniciar una sesión segura. El servidor responde con su certificado digital, que el cliente utiliza para confirmar la identidad del servidor. Una vez que el cliente autentica el servidor de esta manera, la configuración de la sesión continúa cuando el cliente genera una clave de sesión utilizando la clave pública del servidor para cifrar algún valor aleatorio creado mediante un KDF PRF o un HDKF más robusto.

El protocolo de autenticación TLS es fundamental para la seguridad de Internet. Una industria completa de proveedores de certificados, denominados autoridades de certificación (CA), ha evolucionado para admitir este componente crítico de las comunicaciones seguras. Las empresas adquieren certificados confiables de las CA para instalarlos en sus propios servidores y admitir el protocolo de autenticación de servidor TLS estándar descrito anteriormente.

Para las aplicaciones de IoT, donde las redes se conectan amplia y profundamente con fuentes corporativas, este tipo de autenticación unidireccional no es suficiente para garantizar la protección. Por ejemplo, los piratas informáticos con certificados fraudulentos podrían representarse a sí mismos como servidores legítimos para dispositivos de IoT como parte de un ataque más amplio.

A pesar del riesgo, los desarrolladores de IoT a menudo encuentran dificultades al implementar el protocolo de autenticación mutua TLS porque los certificados, las claves y el software necesarios para implementar la autenticación del cliente con TLS pueden exceder las capacidades de muchos dispositivos de IoT. Trabajando en colaboración, Microchip Technology y Google han creado un enfoque alternativo que combina las capacidades ATECC608A con una estructura de datos simple llamada JSON Web Token (JWT). El resultado es un método fácil para garantizar la autenticación mutua entre los dispositivos de IoT y los servicios de Google Cloud IoT Core.

Autenticación basada en JWT

El JWT, especificado en RFC (llamado de función remota) 7519, es un contenedor estándar de la industria para información, llamada reclamos, sobre la entidad que prepara y transmite el JWT. La propia estructura JWT consta de tres secciones:

  • Cabecera, que incluye los pares nombre:valor de JSON para el nombre ("alg") del algoritmo de criptografía (p. ej. "EC256" para ECDSA usando la curva NIST P-256) que se usa para firmar el token y para el tipo ("typ") del token ("JWT” para estos tokens).
  • Carga útil, que incluye los pares nombre:valor de JSON para cada reclamo.
  • Firma, que utiliza el algoritmo especificado en la cabecera para codificar una clave secreta junto con la cabecera y el conjunto de reclamos, cada uno se convierte por separado a la representación base64 codificada en URL antes del cifrado.

RFC 7519 proporciona una gran flexibilidad para especificar reclamos en la carga útil u otras secciones. El estándar incluso permite JWT no protegidos, creados sin firma o cifrado, en cuyo caso, la cabecera incluiría el par nombre:valor para el algoritmo, como {"alg":"ninguno"}. Para los JWT utilizados con los servicios de Google Cloud IoT Core, Google requiere la sección de firmas y una carga útil con tres reclamos obligatorios, incluidos los siguientes:

  • “iat": el momento de “emisión”, en que se creó el token en formato de marca de hora UTC ISO 8601 como segundos desde 1970-01-01T00:00:00Z (por ejemplo, 1561896000 para el 30 de junio de 2019 12:00:00 p. m. GMT)
  • "exp": la marca de tiempo UTC que especifica la caducidad del token, con un máximo de 24 horas después del valor "iat" más un período de gracia de diez minutos para tener en cuenta el sesgo del reloj del sistema entre diferentes clientes y servidores (por ejemplo, 1561982400 para el 1 de julio de 2019 12:00:00 p. m. GMT)
  • "aud": una cadena que contiene la identificación del proyecto Google Cloud del desarrollador

El esquema de Google para la autenticación del dispositivo de IoT combina la autenticación normal del servidor basada en TLS con la autenticación del dispositivo de IoT usando un JWT creado con estos reclamos relativamente simples. Para iniciar una nueva sesión, un dispositivo de IoT abre un socket (“enchufe”) seguro al servidor y autentica el servidor utilizando el mismo protocolo TLS descrito anteriormente.

El siguiente paso en este proceso se basa en el uso en la nube de Google IoT del protocolo de transporte de telemetría de mensajes ligeros (MQTT) para las transacciones de la red IoT. Al usar el socket seguro para el servidor autenticado, el dispositivo de IoT "inicia sesión" en los servicios de host MQTT de ese servidor, utilizando su JWT único como la contraseña de inicio de sesión (Listado 1).

Copy /* Complete el búfer con la contraseña del usuario */ int config_get_client_username(char* buf, size_t buflen) {     if(buf && buflen)     {         int rv = snprintf(buf, buflen, "unused");           if(0 < rv && rv < buflen)         {             buf[rv] = 0;             return 0;         }     }     return -1; }   /* Complete el búfer con la contraseña del usuario */ int config_get_client_password(char* buf, size_t buflen) {     int rv = -1;       if(buf && buflen)     {         atca_jwt_t jwt;                 uint32_t ts = time_utils_get_utc();           rv = atcab_init(&cfg_ateccx08a_i2c_default);         if(ATCA_SUCCESS != rv)         {             return rv;         }           /* Build the JWT */         rv = atca_jwt_init(&jwt, buf, buflen);         if(ATCA_SUCCESS != rv)         {             return rv;         }           if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts)))         {             return rv;         }           if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400)))         {             return rv;         }           if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id)))         {             return rv;         }           rv = atca_jwt_finalize(&jwt, 0);           atcab_release();     }     return rv; } 

Listado 1: Incluido en el repositorio de muestra del software de Microchip Technology para Google Cloud Platform IoT Core, un módulo proporciona rutinas para generar un nombre de usuario ficticio y un objeto JWT para usar como contraseña para la autenticación del cliente con un host (o anfitrión) MQTT. (Fuente del código: Microchip Technology)

Aunque el dispositivo de IoT envía un nombre de usuario como parte de esta secuencia de inicio de sesión, el nombre de usuario no se usa para la autenticación. En consecuencia, se transmite un nombre de usuario ficticio (Listado 2). En cambio, la autenticación del dispositivo de IoT se basa en el JWT enviado como contraseña de inicio de sesión. Debido a que la firma JWT es una combinación de la cabecera, la carga útil y la clave privada del dispositivo, los servicios de Google Cloud IoT Core pueden verificar que el JWT realmente se origine en un dispositivo autorizado. Para esta verificación, los servicios de Google Cloud IoT utilizan la clave pública del dispositivo que previamente fue almacenada en la nube de Google por el desarrollador del dispositivo de IoT mediante un proceso de administración de claves descrito a continuación. En contraste con el uso de TLS solo, este enfoque proporciona autenticación mutua a través de un enfoque híbrido que acelera el proceso, al tiempo que reduce los requisitos de recursos del dispositivo de IoT.

Copy/* Conectar el MQTT al host */static int client_connect(void* pCtx){ MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer; struct _g_client_context* ctx = (struct _g_client_context*)pCtx; size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;  mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S; mqtt_options.cleansession = 1;  /* Cadena de identificación del cliente */ mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0]; if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining)) { return MQTTCLIENT_FAILURE; }  /* Cadena de nombre de usuario */ mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1; buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring); if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining)) { return MQTTCLIENT_FAILURE; }  /* Cadena de contraseña */ mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1; buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring); if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining)) { return MQTTCLIENT_FAILURE; }  return MQTTConnect(&ctx->mqtt_client, &mqtt_options);}

Listado 2: Esta función, proporcionada en el repositorio de muestra del software de Microchip, demuestra el uso de un objeto JWT como contraseña que autentica el dispositivo de IoT en el servidor MQTT durante la fase de conexión inicial. (Fuente del código: Microchip Technology)

Habilitadores críticos

Las capacidades del ATECC608A y su cadena de suministro son los habilitadores críticos para este enfoque. Aunque cualquier MCU (microcontrolador) podría generar una firma cifrada criptográficamente desde la cabecera y la carga útil de JWT, cualquier enfoque realizado únicamente con software seguiría siendo vulnerable sin el almacenamiento seguro de claves basado en hardware. Además, la carga del procesador y el retardo de ejecución requeridos para una implementación de "solo software" podrían ser prohibitivos para muchos dispositivos de IoT con recursos limitados o aplicaciones con requisitos de tiempo de respuesta ajustados. Finalmente, los desarrolladores sin una amplia experiencia en algoritmos de seguridad y protocolos de nivel superior se verían obligados a implementar la funcionalidad de software requerida. Microchip aborda estas inquietudes con su biblioteca CryptoAuthLib (Figura 2).

Diagrama de la capa de abstracción de hardware (HAL) CryptoAuthLib

Figura 2: Debido a que CryptoAuthLib utiliza una capa de abstracción de hardware (HAL) para separar las funciones de la API (interfaz de programación de aplicaciones) y los núcleos primitivos del hardware subyacente, los desarrolladores pueden dirigir su software a una amplia gama de dispositivos de soporte. (Fuente de la imagen: Microchip Technology)

El Microchip CryptoAuthLib simplifica la implementación de características de IoT seguras, como el protocolo de autenticación JWT de Google, reduciendo las operaciones de seguridad complejas a un conjunto de llamadas de función proporcionadas a través de la interfaz de programación de aplicaciones (API) CryptoAuthLib. Tal vez lo más importante para los desarrolladores de IoT sea que las funciones centrales de Microchip CryptoAuthLib aprovechan al máximo los circuitos integrados de criptografía de Microchip, como el ATECC608A, para acelerar la ejecución de las características de seguridad en un diseño. Por ejemplo, la llamada a atca_jwt_finalize() en el Listado 1 usa un dispositivo criptográfico disponible como el ATECC608A para crear el JWT utilizado como la contraseña en el Listado 2. En este caso, el ATECC608A acelera el cifrado de la firma JWT, leyendo la clave privada del diseño desde su almacenamiento seguro integrado para completar el proceso de creación de la firma descrito anteriormente.

Sin embargo, incluso con el uso de software sofisticado y dispositivos de seguridad, los dispositivos de IoT pueden seguir siendo vulnerables debido a los métodos que tradicionalmente se necesitan para administrar claves y certificados. En el pasado, las claves privadas debían generarse externamente y cargarse en dispositivos de almacenamiento seguro durante la fabricación, distribución o incluso la implementación. Incluso con el uso de módulos de seguridad de hardware e instalaciones seguras, la existencia efímera de estos secretos fuera del único dispositivo que "necesita conocerlos" representa una debilidad de seguridad que puede provocar su exposición por accidente o intención. Al aprovechar las capacidades del ATECC608A, Microchip y Google han eliminado en gran medida esta debilidad tradicional en la seguridad.

En este nuevo enfoque, Microchip utiliza la capacidad del ATECC608A para generar pares de claves sin que las claves privadas salgan del dispositivo (Figura 3). Microchip luego firma las claves públicas generadas por el dispositivo con un certificado intermedio que fue proporcionado por el cliente y almacenado en un servidor seguro dentro de las instalaciones seguras de Microchip. Finalmente, Microchip transmite de manera segura las claves públicas a la cuenta del cliente en el Administrador de dispositivos de Google Cloud IoT, que puede almacenar hasta tres claves públicas para cada dispositivo para admitir políticas de rotación clave. Una vez implementado, un dispositivo de IoT puede usar las características de seguridad ATECC608A para crear el JWT utilizado en el proceso de autenticación mutua descrito anteriormente.

Diagrama de los servicios de la tecnología Microchip y Google Cloud IoT (haga clic para ampliar)

Figura 3: Los servicios de Microchip Technology y Google Cloud IoT se combinan para simplificar el aprovisionamiento de claves y certificados, y proporcionan un mecanismo protegido diseñado para fortalecer la seguridad de las aplicaciones de IoT. (Fuente de la imagen: Google)

Esta colaboración entre Microchip y Google permite a los desarrolladores descargar completamente este proceso crítico de administración de claves. Sin embargo, para los requisitos personalizados, los desarrolladores pueden implementar su propio proceso de administración de claves, utilizando la función de API CryptoAuthLib atcab_genkey(), lo que hace que el ATECC608A genere un par de claves, almacene la clave privada en su almacenamiento seguro y devuelva la clave pública asociada.

Para explorar la generación de claves y otras capacidades de seguridad ATECC608A, los desarrolladores pueden configurar rápidamente un entorno de desarrollo integral creado en torno al kit de evaluación de Microchip SAM D21 Xplained Pro Sobre la base del MCUATSAMD21J18Ade 32 bit Arm® Cortex®-M0+ de Microchip, el kit SAM D21 Xplained Pro proporciona una plataforma de hardware completa compatible con marco de software avanzado (ASF) de Microchip para controladores y módulos de código.

Para evaluar los dispositivos CryptoAuthentication, incluido el ATECC608A, los desarrolladores pueden simplemente conectar una placa complementaria CryptoAuth XPRO-B en uno de las dos cabeceras de expansión de la placa Xplained Pro. Microchip proporciona un software de muestra para evaluar la funcionalidad de seguridad de CryptoAuthLib con el ATECC608A. Además, los desarrolladores pueden conectar una placa adicional con Wi-Fi ATWINC1500-XPRO en la otra cabecera para ejecutar el software de muestra Microchip que demuestra el flujo de autenticación mutua descrito en este artículo, incluida la autenticación del servidor TLS y la autenticación del dispositivo JWT.

Conclusión

Aunque la seguridad de la aplicación de IoT conlleva múltiples requisitos, un desafío crítico a menudo radica en la implementación de la autenticación mutua para dispositivos de IoT y recursos en la nube. En los sistemas de IoT con recursos limitados, los protocolos convencionales pueden exceder la memoria disponible y los recursos de procesamiento. Mediante el uso de la biblioteca CryptoAuthLib de tecnología Microchip y el IC CryptoAuthentication ATECC608A, los desarrolladores pueden implementar un enfoque más eficiente basado en los tokens web de JSON para conectar de forma segura los dispositivos de IoT a los servicios Google Cloud IoT.

Descargo de responsabilidad: Las opiniones, creencias y puntos de vista expresados por los autores o participantes del foro de este sitio web no reflejan necesariamente las opiniones, las creencias y los puntos de vista de Digi-Key Electronics o de las políticas oficiales de Digi-Key Electronics.

Acerca de este autor

Stephen Evanczuk

Stephen Evanczuk tiene más de 20 años de experiencia escribiendo para y sobre la industria de electrónica en un amplio rango de temas, entre ellos hardware, software, sistemas y aplicaciones, que incluyen IoT. Se doctoróen neurociencias (redes neuronales) y trabajó en la industria aeroespacial en sistemas seguros con distribución masiva y métodos de aceleración de algoritmos. Actualmente, cuando no escribe artículos sobre tecnología e ingeniería, trabaja en aplicaciones de aprendizaje profundo sobre sistemas de reconocimiento y recomendaciones.

Acerca de este editor

Editores de Digi-Key de América del Norte