Cómo conectar de forma rápida y segura las aplicaciones de IoT a Google Cloud

Los servicios en la nube a nivel de empresa, como Google Cloud, ofrecen a los desarrolladores de IoT una amplia gama de capacidades, que van desde servicios ampliables de máquina virtual hasta aplicaciones llave en mano de inteligencia artificial (AI). Un requisito fundamental para estos servicios es el uso de métodos de seguridad específicos para establecer y mantener conexiones seguras entre los dispositivos de IoT y la nube. Sin embargo, para los desarrolladores, implementar mecanismos de seguridad apropiados puede llevar a retrasos y añadir complejidad al diseño de proyectos que tienen plazos cortos.

El tablero de desarrollo PIC-IoT WG de Microchip Technology, construido con una CI de seguridad dedicada, ofrece una solución llave en mano a la conectividad de Google Cloud. Junto con una IC de seguridad dedicada, el kit proporciona una plataforma amplia diseñada para acelerar el desarrollo de los diseños de IoT capaces de conectarse de forma segura a los servicios de Google Cloud. Este artículo describe los requisitos clave para una conectividad segura y muestra cómo los desarrolladores pueden cumplirlos al utilizar el PIC-IoT WG en un diseño típico de IoT.

Complejidad de la seguridad

La capacidad de asegurar las conexiones entre los dispositivos de IoT y los servidores host remotos es fundamental para la protección general de las aplicaciones de IoT y de los recursos empresariales en red relacionados. Estos servidores y otros sistemas a nivel empresarial pueden proporcionar capacidades y rendimiento que simplemente no están disponibles en dispositivos de IoT construidos con microcontroladores de recursos limitados y memoria mínima. En el caso de los dispositivos simples de IoT que se espera que proporcionen datos de sensores u operen actuadores de manera oportuna, los requisitos de procesamiento por sí solos para aplicar incluso los algoritmos de seguridad más fundamentales pueden ser prohibitivos debido a su naturaleza.

Los métodos de seguridad se basan en el principio básico de que la penetración de una barrera de seguridad debe ser más costosa que los bienes que la barrera está destinada a proteger. Para los métodos algorítmicos de seguridad, esto significa que descifrar un mensaje cifrado o romper un protocolo de autenticación debería ser prohibitivo desde el punto de vista informático. Como mínimo, romper la seguridad algorítmica debería exigir un nivel de recursos computacionales y de tiempo requerido que exceda el valor o la puntualidad del canal de datos o de comunicaciones protegido. En consecuencia, los algoritmos criptográficos tratan de enterrar datos valiosos bajo una serie de pasos de procesamiento complejos e intensivos desde el punto de vista computacional que involucran una clave secreta. Por ejemplo, el ampliamente utilizado algoritmo de estándar de cifrado avanzado (AES) somete los datos a múltiples rondas de procesamiento, cada una de las cuales comprende una serie de pasos que comienzan con una clave secreta y continúan con sustituciones de bytes, desplazamientos y cálculos de matrices (Figura 1).

Figura 1: Con la intención de hacer el descifrado impráctico y efectivamente imposible, los algoritmos criptográficos emplean deliberadamente una serie de manipulaciones complejas, como este paso en el algoritmo AES que combina datos con bits derivados de una clave privada. (Fuente de la imagen: Wikimedia Commons)

Con los algoritmos criptográficos simétricos, como el AES, los receptores de un mensaje cifrado utilizan la misma clave secreta para descifrar los datos. Por el contrario, los algoritmos asimétricos utilizan un par de claves, una privada y otra pública, eliminando los riesgos asociados al uso de una clave compartida a costa de una mayor complejidad computacional. En este enfoque, el emisor y el receptor intercambian las claves públicas al tiempo que mantienen en secreto sus propias claves privadas. A su vez, una parte puede utilizar la clave pública de la otra parte para cifrar un mensaje que solamente puede descifrarse con la clave privada de la otra parte.

Para obtener una mayor protección, los algoritmos avanzados se basan en métodos de criptografía de clave pública asimétrica para permitir el intercambio seguro de una clave privada de corta duración compartida que se utiliza para encriptar datos durante una sesión determinada de intercambio de mensajes. Debido a la naturaleza crítica de estos intercambios de claves, los algoritmos más avanzados, como la curva elíptica Diffie-Hellman (ECDH), entierran aún más profundamente los secretos bajo los cálculos complejos de la curva elíptica. Los protocolos de autenticación como seguridad de la capa de transporte (TLS) combinan mecanismos, como el intercambio de claves Diffie-Hellman, con métodos formales de identificación, utilizando certificados digitales que incorporan una clave pública con una firma digital verificable de una autoridad de certificación (CA) que certifique la autenticidad del certificado.

Como sugiere esta breve descripción, los métodos de seguridad se basan en capas de algoritmos y protocolos criptográficos que, en última instancia, dependen de claves privadas. Aunque estas capas están sujetas a constantes ataques de hackers, toda la estructura de seguridad colapsará rápidamente si se pueden descubrir las claves privadas.

Por esta razón, el almacenamiento seguro de claves basado en hardware es un requisito fundamental para la seguridad de los dispositivos de IoT. Además, la complejidad computacional de estos algoritmos y protocolos dicta la necesidad de motores de criptografía dedicados que puedan descargar cálculos complejos de microcontroladores con recursos limitados.

Seguridad basada en hardware

Los dispositivos de hardware de elementos seguros especializados, como la CI de CryptoAuthentication ATECC608A de Microchip Technology, proporcionan las características necesarias para proteger los secretos y acelerar la ejecución de los algoritmos criptográficos. Entre sus características, el ATECC608A proporciona una EEPROM en el chip para el almacenamiento seguro de hasta 16 claves, certificados y otros datos, así como otras capacidades necesarias, incluido un generador de números aleatorios compatible con NIST SP 800-90A/B/C.

Además de ser un dispositivo de almacenamiento seguro, el ATECC608A puede acelerar la ejecución de una serie de algoritmos, incluyendo el AES para criptografía simétrica y el ECDH para criptografía asimétrica. El dispositivo también proporciona soporte para servicios de nivel superior, incluido el arranque seguro (véase “Usar un chip criptográfico para añadir un arranque seguro a los diseños de dispositivos de IoT").

Además de los beneficios de rendimiento directos que se obtienen al descargar la ejecución de estos algoritmos, la integración de estos motores de cifrado, el almacenamiento seguro y otras características del ATECC608A proporcionan otra capa de seguridad: las claves permanecen aisladas de las entidades no confiables. Estas entidades incluyen los microcontroladores que no están diseñados para la seguridad, el software que se ejecuta en el microcontrolador y las personas que utilizan el software. La capacidad del dispositivo para generar claves privadas proporciona mayor seguridad durante el aprovisionamiento en instalaciones de fabricación o distribución.

El resultado es una reducción del número de vectores de amenazas, en comparación con los métodos de seguridad convencionales basados en software. Esto apoya el tipo de defensa en profundidad que se encuentra en el núcleo de las políticas de seguridad eficaces.

Esta integración completa de la funcionalidad en el ATECC608A simplifica los requisitos de interfaz del hardware. El dispositivo funciona como otro periférico I²C que puede incluso compartir el bus I²C de un microcontrolador con otros dispositivos, como lo hacen los sensores digitales como el MCP9808 de Microchip Technology (Figura 2).

Figura 2:Debido a que la CI de CryptoMemory ATECC608A de Microchip Technology (izquierda) completa su proceso de seguridad completamente en el chip, puede proporcionar una interfaz de hardware I²C sencilla para su uso con otros dispositivos I²C, como el sensor de temperatura digital MCP9808 I²C de Microchip Technology (derecha). (Fuente de la imagen: Microchip Technology)

Sin embargo, a nivel de software, la amplia funcionalidad del ATECC608A resulta en una interfaz más compleja. La biblioteca CryptoAuthLib de Microchip Technology abstrae esta interfaz en un conjunto de llamadas de función intuitivas disponibles en la interfaz de programación de aplicaciones (API) de CryptoAuthLib. Esta biblioteca está incluida en los controladores y middleware relacionados en el entorno de desarrollo integrado (IDE) MPLAB X de Microchip Technology. Aunque la API y los controladores de CryptoAuthLib proporcionan los elementos básicos para los diseños personalizados con el ATECC608A, los desarrolladores se enfrentan a retos adicionales a la hora de implementar toda la cadena de seguridad necesaria para la conectividad segura con Google Cloud. La tarjeta de desarrollo PIC-IoT WG de Microchip Technology también elimina ese obstáculo.

Desarrollar una aplicación IoT de extremo a extremo

Basado en el ATECC608A y el microcontrolador de bajo costo PIC24FJ128GA705 de 16 bits de Microchip Technology, el tablero PIC-IoT es un diseño de IoT inalámbrico que incluye el módulo Wi-Fi ATWINC1510 de Microchip Technology, el sensor de luz ambiental TEMT6000X01 de Vishay Semiconductor y el sensor de temperatura MCP9808 I²C. Además, los desarrolladores pueden ampliar fácilmente la plataforma de base de hardware añadiendo sensores y actuadores provistos de los cientos de tableros click de MikroElektronika disponibles. Para el desarrollo de software, Microchip Technology proporciona su MPLAB X IDE y la herramienta de creación rápida de prototipos MPLAB Code Configurator (MCC) asociada.

El tablero y el software relacionado proporcionan una plataforma llave en mano para evaluar una aplicación básica de IoT de extremo a extremo, desde el dispositivo sensor de IoT hasta los servicios de Google Cloud a través de conexiones seguras. El kit implementa un enfoque único diseñado para permitir la autenticación mutua, incluso con dispositivos de IoT con recursos limitados. En este enfoque, el dispositivo de IoT puede utilizar los servicios TLS ligeros para autenticar el lado Google de la conexión y los Object Notation (JSON) Web Tokens (JWT) de JavaScript para autenticarse en los servidores de Google (véase “Una solución más sencilla para conectar de forma segura los dispositivos de IoT a la nube”). Junto con los controladores de dispositivos, los paquetes de soporte de tarjetas y los servicios de middleware, Microchip Technology demuestra este enfoque como parte de una aplicación de IoT de muestra completa disponible para el tablero PIC-IoT a través del paquete de desarrollo MPLAB.

Al trabajar en la aplicación de muestra, los desarrolladores pueden adquirir experiencia trabajando no solo con aplicaciones en la nube, sino también con servicios específicos de IoT proporcionados por los principales proveedores de servicios de nube para conectar dispositivos de IoT a su nube. Por ejemplo, los dispositivos de IoT acceden a los recursos de Google Cloud a través de Google Cloud IoT Core, que proporciona una serie de servicios necesarios para conectar esos dispositivos, gestionar sus metadatos relacionados y mucho más (Figura 3).

Figura 3: Al igual que otros proveedores de servicios en la nube para empresas, Google Cloud proporciona una oferta de servicio especializada, Google Cloud IoT Core, diseñada para satisfacer los requisitos exclusivos asociados a la integración de dispositivos de IoT con recursos en la nube. (Fuente de la imagen: Google)

Utilizar servicios en la nube

En el back end, Google Cloud IoT Core proporciona a los dispositivos acceso a los recursos de alto nivel de Google Cloud a través de un agente de datos que utiliza un modelo de publicación/suscripción (pub/sub). En el extremo frontal, el núcleo de IoT proporciona un puente que es compatible con la conectividad de dispositivos de IoT utilizando el Protocolo de Transferencia de Hipertexto (HTTP) o el Transporte de Telemetría de Cola de Mensajes (MQTT). MQTT es un estándar de transporte de mensajes de la Organización Internacional para la Estandarización (ISO) diseñado para funcionar con un mínimo de ancho de banda de comunicaciones y recursos de dispositivos de IoT. La aplicación de software de Microchip Technology para el tablero PIC-IoT demuestra el uso de MQTT que se ejecuta en una conexión de enchufe de Protocolo de Control de Transmisión/Protocolo de Internet (TCP/IP) que está asegurada con el método de autenticación mutua TLS/JWT descrito anteriormente.

Después de establecer la conexión segura, el software utiliza el MQTT para comunicarse con los servicios centrales de Google Cloud IoT a fin de establecer un canal, o "tema", utilizado para enviar datos de los sensores a Google Cloud y responder a los comandos de los servicios en la nube. Google pide que el software del dispositivo de IoT se suscriba y posteriormente envíe datos a un tema designado del formulario /devices/{deviceID}/events y ofrece la opción de subtemas bajo el tema de los eventos generales. Además de otros temas, como los relacionados con las funciones de administración de dispositivos, Google designa un tema /devices/{device-id}/commands para enviar comandos desde la nube al dispositivo de IoT. Google incluso proporciona un tema general (/devices/{device-id}/commands/#) que permite a los dispositivos de IoT recibir comandos enviados a través de cualquier subtema.

La aplicación PIC-IoT demuestra estos diversos procedimientos utilizando una arquitectura de software extensible basada en temporizadores y devoluciones de llamadas. Debido a esta arquitectura, el módulo principal (main.c) solo necesita proporcionar la rutina principal (main()) así como rutinas a nivel de aplicación para enviar (sendToCloud()) y recibir (receivedFromCloud()) mensajes. La rutina main() en sí misma solo llama a un par de rutinas de inicialización antes de entrar en un bucle interminable que ejecute el programador del temporizador y proporciona un marcador de posición para las rutinas del usuario (Listado 1).

Copyvoid receivedFromCloud(uint8_t *topic, uint8_t *payload){ char *toggleToken = "\"toggle\":"; char *subString;  if ((subString = strstr((char*)payload, toggleToken))) { LED_holdYellowOn( subString[strlen(toggleToken)] == '1' ); }   debug_printer(SEVERITY_NONE, LEVEL_NORMAL, "topic:%s", topic); debug_printer(SEVERITY_NONE, LEVEL_NORMAL, "payload:%s", payload);} // This will get called every 1 second only while we have a valid Cloud connectionvoid sendToCloud(void){ static char json[70];  // This part runs every CFG_SEND_INTERVAL seconds int rawTemperature = SENSORS_getTempValue(); int light = SENSORS_getLightValue(); int len = sprintf(json, "{\"Light\":%d,\"Temp\":\"%d.%02d\"}", light,rawTemperature/100,abs(rawTemperature)%100);  if (len >0) { CLOUD_publishData((uint8_t*)json, len); LED_flashYellow(); }} #include "mcc_generated_files/application_manager.h" /* Main application */int main(void){ // initialize the device SYSTEM_Initialize(); application_init();  while (1) { // Add your application code runScheduler(); }  return 1;

Listado 1: La aplicación de muestra del tablero PIC-IoT de Microchip Technology utiliza una serie de temporizadores y devoluciones de llamadas que simplifican el bucle principal y permiten a los desarrolladores añadir fácilmente sus propios servicios y rutinas de aplicación. (Fuente del código: Microchip Technology)

Llamada antes del bucle interminable, la rutina SYSTEM_Initialize() inicializa los componentes de hardware, incluido el reloj, el convertidor de analógico a digital (ADC), las interrupciones y otros. La rutina application_init() inicializa varios sistemas de software, incluida la biblioteca CryptoAuthentication, se conecta a Wi-Fi y a la propia nube. Como última tarea, application_init() establece un temporizador de 100 milisegundos (ms) para la ejecución de la MAIN_dataTask(). Cuando el temporizador expira y se invoca MAIN_dataTask(), comprueba la conexión con la nube y llama a sendToCloud() una vez por segundo, configurando los LED del tablero, según corresponda, para indicar el estado operativo actual de la aplicación (Listado 2). A su vez, los desarrolladores pueden ver una visualización de los valores de los sensores en una cuenta de entorno de pruebas gratuita proporcionada por Microchip Technology en Google Cloud.

Copy // This gets called by the scheduler approximately every 100ms uint32_t MAIN_dataTask(void *payload) {    static time_t previousTransmissionTime = 0;       // Get the current time. This uses the C standard library time functions    time_t timeNow = time(NULL);       // Example of how to send data when MQTT is connected every 1 second based on the system clock    if (CLOUD_isConnected())    {       // How many seconds since the last time this loop ran?
int32_t delta = difftime(timeNow,previousTransmissionTime);          if (delta >= CFG_SEND_INTERVAL)       {          previousTransmissionTime = timeNow;                   // Call the data task in main.c          sendToCloud();       }    }       if(shared_networking_params.haveAPConnection)     {         LED_BLUE_SetLow();     }     else     {         LED_BLUE_SetHigh();     }     if(shared_networking_params.haveERROR)     {         LED_RED_SetLow();     }     else     {         LED_RED_SetHigh();     }     if (LED_isBlinkingGreen() == false)     {         if(CLOUD_isConnected())         {             LED_GREEN_SetLow();         }         else         {             LED_GREEN_SetHigh();         }     }       // This is milliseconds managed by the RTC and the scheduler, this return makes the    //      timer run another time, returning 0 will make it stop    return MAIN_DATATASK_INTERVAL; } 

Listado 2: Utilizando un temporizador y un mecanismo de devolución de llamada, la aplicación de muestra PIC-IoT de Microchip Technology envía los datos del sensor a la nube una vez por segundo (CFG_SEND_INTERVAL=1) y actualiza los LED de la tarjeta para indicar el estado operativo actual. (Fuente del código: Microchip Technology)

Procesar comandos desde la nube es igual de fácil. La aplicación de muestra ilustra cómo asociar una rutina de devolución de llamada como receivedFromCloud() para manejar los mensajes recibidos. Como parte de la fase de inicialización, la rutina application_init() mencionada anteriormente llama a una rutina (CLOUD_subscribe()) que realiza el proceso de suscripción a Google Cloud. Como parte de este proceso, el software actualiza una tabla (imqtt_publishReceiveCallBackTable) con la devolución de llamada a receivedFromCloud() (Listado 3). En este caso, la aplicación de muestra utiliza el tema de config y codifica el índice en la tabla desde NUM_TOPICS_SUBSCRIBE=1, pero el tema de comandos más general y los subtemas derivados son otra opción.

Copyvoid CLOUD_subscribe(void){ mqttSubscribePacket cloudSubscribePacket; uint8_t topicCount = 0;  // Variable header cloudSubscribePacket.packetIdentifierLSB = 1; cloudSubscribePacket.packetIdentifierMSB = 0;  // Payload for(topicCount = 0; topicCount < NUM_TOPICS_SUBSCRIBE; topicCount++) { sprintf(mqttSubscribeTopic, "/devices/%s/config", deviceId); cloudSubscribePacket.subscribePayload[topicCount].topic = (uint8_t *)mqttSubscribeTopic; cloudSubscribePacket.subscribePayload[topicCount].topicLength = strlen(mqttSubscribeTopic); cloudSubscribePacket.subscribePayload[topicCount].requestedQoS = 0;  imqtt_publishReceiveCallBackTable[0].topic = mqttSubscribeTopic; imqtt_publishReceiveCallBackTable[0].mqttHandlePublishDataCallBack = receivedFromCloud; MQTT_SetPublishReceptionHandlerTable(imqtt_publishReceiveCallBackTable); }  if(MQTT_CreateSubscribePacket(&cloudSubscribePacket) == true) { debug_printInfo("CLOUD:SUBSCRIBE packet created"); sendSubscribe = false; }}

Listado 3: Las aplicaciones de muestra de Microchip Technology muestran cómo los desarrolladores pueden asociar fácilmente las rutinas de devolución de llamada con los mensajes MQTT recibidos, en este caso definiendo la función receivedFromCloud() como la devolución de llamada para los mensajes recibidos del tema por defecto. (Fuente del código: Microchip Technology)

Los desarrolladores pueden utilizar el paquete de hardware y software PIC-IoT tal y como se entrega para empezar a explorar inmediatamente los diferentes escenarios de envío y recepción de datos desde Google Cloud. El hardware PIC-IoT y el dispositivo ATECC608A CryptoAuthentication están preconfigurados para ser compatibles con Google Cloud IoT Core y este modelo de uso. Los desarrolladores pueden utilizar fácilmente el MPLAB X IDE y el MPLAB Code Configurator para modificar o crear una aplicación de IoT completamente nueva diseñada para conectarse de forma segura a Google Cloud.

Conclusión

Proporcionar conexiones seguras entre los dispositivos de IoT y los recursos de red es esencial para cualquier entorno de servicio en red y obligatorio para trabajar con servicios comerciales en la nube. La creación de los niveles de servicios de software necesarios para una conectividad segura puede añadir retrasos significativos a los proyectos de IoT, e incluso puede resultar poco práctica en los diseños de IoT con recursos limitados. Utilizando un tablero de desarrollo como el PIC-IoT de Microchip Technology, que incluye un CI de seguridad especializado, los desarrolladores pueden crear rápidamente una aplicación de IoT capaz de conectarse de forma segura a Google Cloud.