Presentación de EnigmaIOT

El pasado 14 de septiembre tuve el placer de participar junto a otros miembros de The Things Network Madrid en el evento Tech.Party 2019, organizado por la comunidad HackMadrid%27. En él hice mi presentación sobre Redes de Sensores con EnigmaIOT.

Se celebró en La Nave. La que en su día fue una fábrica de ascensores en el barrio madrileño de Villaverde hoy es un centro de innovación en el que cualquiera puede participar.

Mi presentación trata sobre las redes de sensores utilizadas en hogares y cómo implantarlas utilizando software libre.

Cómo puedo montar una red de sensores en mi casa

Hoy en día podemos encontrar todo tipo de dispositivos muy fáciles de instalar para gestionar nuestra casa. Enchufes, bombillas, sensores de todo tipo. Gracias a las redes WiFi nos podemos olvidar de los cables.

Esto está bien si vamos a conectar unos pocos de estos aparatos, pero es muy posible que tu sistema crezca poco a poco, cada vez con más dispositivos.

Puede no ser una buena idea utilizar nuestro router WiFi como medio para interconectarlos. Los routers domésticos pueden tener problemas a la hora de gestionar tantos dispositivos conectados a su red inalámbrica. No están pensados para eso.

Los dispositivos domóticos de los que estamos hablando suelen conectarse a un servicio en la nube, por lo que si nos quedamos sin conexión en algún momento tendremos un bonito pisapapeles hasta que vuelva a funcionar el servicio de Internet.

Además, si estos dispositivos son de marcas diferentes es muy posible que tengamos que utilizar aplicaciones diversas para gestionarlos.

Seguro que estarás de acuerdo en que tener una aplicación para encender la luz del salón, otra para encender el aire acondicionado y otra para ver la temperatura de la calefacción no es lo más apetecible.

Mantén tus datos en privado

Otro punto que hay que considerar es la privacidad de todos estos datos. Puede parecer que no es importante que un tercero maneje datos como la temperatura de nuestra casa o las veces que encendemos o apagamos las luces.

De estos datos se pueden deducir nuestras costumbres. Por ejemplo, del estado de las luces se puede saber si estamos o no en casa. La temperatura del frigorífico puede variar de forma detectable si acabamos de meter la compra en él.

Me gusta que todos mis datos sean privados, por muy inocentes que puedan parecer. Además, ¿qué sentido tiene que para encender una luz con un interruptor conectado tenga que hacer una petición a un servidor que está en la otra parte del mundo? No parece eficiente, ¿verdad?

Sistemas más avanzados utilizan comunicación ZigBee o Z-Wave. Esto implica un precio más alto pero utiliza un protocolo más adecuado para el transporte de datos de elementos domóticos. Pero si quieres construir tus propios sensores utilizar módulos con estos protocolos significa un coste alto, sobre todo si te planteas instalar un número considerable de ellos.

Qué alternativas tengo

Si quieres montar tus propios sensores para construir un sistema domótico tienes numerosas alternativas, cada una con sus ventajas e inconvenientes. No hay una que sea la ideal, depende de cada necesidad.

En mi caso, yo quiero instalar una red de sensores de temperatura en toda mi casa para estudiar los flujos de calor. Mi casa es muy fría y la verdad es que ya no sé por dónde se me escapa el calor, pero eso es otro tema.

Mi idea es poner al menos un sensor o dos en cada habitación. Ya de paso puedo añadir alguno más para monitorizar la temperatura en el interior del frigorífico. Esto hace un total de unos 20 sensores.

Quiero un sistema lo más económico posible ya que el número de sensores puede ser considerable. No quiero gastarme más de 10€ por cada sensor terminado.

EnigmaIOT. Una plataforma de sensores para entornos domésticos

He trabajado durante mucho tiempo con el microcontrolador ESP8266 en mis proyectos. Lo conozco bien y me manejo con comodidad programándolo y, además, es muy económico. Por eso, mi primera decisión fue utilizarlo para montar redes de sensores con EnigmaIOT.

El sistema está basado en una topología en estrella, en la que todos los nodos (sensores y/o actuadores) están conectados con un gateway o concentrador. Este gateway es el único que sí está conectado a mi red WiFi. Los datos pueden enviarse mediante el protocolo MQTT a un broker instalado en una RaspberryPi dentro de mi propia red. Puede ser también interesante poder hacer una conexión segura a un broker MQTT instalado fuera de mi casa, en un VPS por ejemplo.

Requerimientos

Hardware

Para que el montaje sea económico, el hardware tiene que ser lo más sencillo posible. Sería deseable que pudiera implementarse con un microcontrolador más el sensor correspondiente a cada uso.

El sistema no necesita de ningún router WiFi para poder comunicar los nodos con el gateway. La comunicación se establece punto a punto entre ellos.

Seguridad

Quiero que sea seguro y privado. Si pretendo garantizar que nadie pueda husmear en mis datos el sistema tiene que utilizar algún tipo de cifrado con algoritmos suficientemente probados.

Utilizar una clave estática para el cifrado puede ser un inconveniente, ya que cambiarla en más de 3 ó 4 dispositivos sería algo muy pesado. La clave debe negociarse automáticamente entre el gateway y cada sensor de manera independiente y renovarse cada cierto tiempo. Sería un mecanismo similar al que utiliza un navegador al hacer peticiones a un servidor web.

Comunicación

Los nodos pueden ser completamente inalámbricos, utilizando alimentación con baterías. Mi deseo es que un par de baterías alcalinas duren más de un año, al menos. Para ello utilizaré las posibilidades de bajo consumo que ofrezca el hardware elegido.

El rango de la comunicación inalámbrica debe ser suficiente para funcionar en una vivienda de tamaño medio, comparable al que tiene un router WiFi.

Necesito que el número de nodos permitidos sea relativamente grande. A los 20 sensores de temperatura se le podrían añadir más nodos si este diseño resulta útil. Interruptores, sensores de humedad, de apertura de puertas. Podría sumar fácilmente unos 50 nodos sin mucho esfuerzo. Lo deseable es que el sistema no tenga un límite definido nada más que por la capacidad del hardware y que no sea menor a unos 50 nodos.

Para soportar nodos que sean actuadores, la comunicación entre el gateway y los nodos puede ser bidireccional. Además esto puede ser útil para que se puedan configurar parámetros en sensores.

Durante el desarrollo de este proyecto surgió otro requerimiento que se hace imprescindible cuando el número de nodos crece. Los nodos deben poder gestionarse, configurarse y actualizarse de forma inalámbrica.

Elección del protocolo de radio

Para la comunicación inalámbrica existen también muchas posibilidades. NRF24, LoRa, interfaces de RF a 443 MHz, basados en diferentes librerías muy flexibles y que podrían cumplir con los requerimientos.

Pero todas ellas, en mayor o menor medida, requieren añadir un módulo de radio al microcontrolador o comprar placas dedicadas con estos interfaces ya incorporados. Esto implica un coste más alto y una complejidad adicional.

En la mayoría de mis proyectos he utilizado ESP8266 para realizar dispositivos conectados a Internet.

Pero aparte de poder comunicarse utilizando señal WiFi, el ESP8266 implementa un protocolo desarrollado por sus creadores conocido como ESP-NOW.

Comunicación con ESP-NOW

ESP-NOW es utiliza una señal que sigue el estándar WiFi pero que funciona de manera parecida a los módulos de RF que he nombrado anteriormente. Permite hacer una comunicación punto a punto sin necesidad de establecer una conexión ni validación previa y sin que tenga que mediar ningún router.

Es por tanto una comunicación muy rápida que permite mensajes cortos, de unos pocos milisegundos. Esto ayuda a reducir considerablemente el consumo de energía.

Los puntos fuertes que aporta ESP-NOW para el proyecto EnigmaIOT son los siguientes:

• Comunicación sin conexión. No hay límite establecido de dispositivos.
• Bitrate alrededor de 1 MBps. Rápido, permite reducir el consumo.
• Mensajes de hasta 250 bytes. Perfectamente válido para transportar datos de sensores o actuadores sencillos.
• Integrado en el ESP8266. No necesita módulos adicionales.
• El alcance de la comunicación es comparable o un poco mayor que el de una señal WiFi convencional.
• Permite comunicación cifrada… ¿o no?

Parece que ESP-NOW es el candidato ideal, pero al comenzar la implementación me encontré un problema importante.

¿Y cómo añado cifrado?

Para implementar el cifrado, ESP-NOW mantiene una tabla con las claves de cada uno de los pares. Esta tabla está limitada a 6 posiciones, lo que elimina el cifrado de la lista anterior.

Salvo por la limitación anterior, ESP-NOW sigue siendo ideal para mi propósito. Me iba a tocar implementar una capa de cifrado sobre la comunicación ESP-NOW.

Yo no soy ni mucho menos un experto en criptografía, pero si quería seguir adelante con este proyecto me iba a tocar aprender. Y si a un maker le gusta una cosa después de desarrollar proyectos, eso es aprender cosas nuevas.

A pesar de que mi elección estaba clara a favor de ESP-NOW, no quería dejar cerrada la puerta a utilizar otros protocolos de radio, si fuese necesario.

He hecho el diseño de manera que sea modular en cuanto al interfaz de radio. Para implementar un driver para uno diferente solamente hay que desarrollar una librería con unos pocos métodos para inicializar y terminar la comunicación, enviar datos y recibirlos.

Características de EnigmaIOT

Después de un largo tiempo de aprendizaje y desarrollo, la implementación actual del sistema tiene las siguiente funcionalidades:

• Comunicación cifrada, mediante algoritmo ChaCha20+Poly1305. Éste es uno de los algoritmos de cifrado más recomendado actualmente para conectar dispositivos que no tienen funcionalidades de cifrado por software. Es muy eficiente y muy seguro siempre que se tenga cuidado al manejar sus parámetros.
• La clave de cifrado es dinámica, compartida entre el gateway y cada nodo. Cada nodo utiliza una clave diferente.
• La configuración inicial, tanto de los nodos como del gateway se realiza mediante un interfaz WEB en el propio dispositivo, que se deshabilita tras una configuración satisfactoria.
• El número de claves y, por tanto, el número de nodos solamente está limitado por la memoria en el gateway (unos 70 Bytes por cada nodo). Teniendo en cuenta que quedan unos 30 kBytes libres, hay lugar para muchos nodos.
• La clave compartida nunca se transmite, por lo que no hay riesgo de interceptación. El algoritmo que he elegido para la negociación de la clave es ECDH (Elliptic Curves Diffie Hellmann).
• Esta clave se guarda en RAM, tanto en los nodos como en el gateway. Si uno de ellos se desconecta de la alimentación sus claves que almacenadas se pierden y ya no serán válidas. En el próximo intento de comunicación se calcularán nuevas claves. Esto evita que un atacante con acceso físico a los nodos pueda capturar la clave de comunicación.
• La expiración y renegociación de la clave se produce de manera automática, con una periodicidad configurable.
• Se evita la posibilidad de repetición de secuencias añadiendo contenido aleatorio y un contador a cada uno de los mensajes.
• La asociación de un nodo a la red se realiza de manera automática y transparente con intervención mínima del usuario.
• Se evita que un nodo no autorizado pueda conectase a la red mediante una clave de red, compartida entre todos los nodos. Esta clave sí se almacena de manera permanente en la flash del dispositivo. Hay que tener en cuenta que ESP8266 no admite cifrado de la memoria flash, por lo que sería posible leerla si tenemos acceso físico a uno de los dispositivos. Este es el punto de ataque más claro que aún no tengo resuelto. Con ESP32 sería posible evitar esto. De momento no lo planteo por el coste extra que ello supondría.
• El protocolo de RF está descrito mediante un interfaz. Sería bastante sencillo cambiar ESP-NOW por otro protocolo implementando dicho interfaz.
• Si se utiliza ESP-NOW, un nodo solamente necesita un ESP8266, además del sensor y/o actuador correspondiente.
• El contador de cada mensaje, independiente en cada nodo, permite calcular los paquetes perdidos. El gateway proporciona estadísticas para cada nodo junto a cada mensaje.
• Diseñado en forma de librería de Arduino para que sea muy sencillo utilizarlo sin complicaciones. Solamente hay que añadir el código para manejar el sensor y componer los datos para enviarlos.
• Sería sencillo sustituir el algoritmo de cifrado.
• Es posible un modo de bajo consumo en el que el nodo queda dormido tras la transmisión. El tiempo de transmisión es configurable, incluso de forma remota.
• Tras un ciclo de bajo consumo no es necesario renegociar la clave. Ésta se almacena en la memoria del RTC, que se mantiene aunque el ESP8266 se reinicie. Si el nodo se desconecta de su alimentación esta memoria se borra y la clave ya no será válida. En la siguiente comunicación se generará una nueva clave.
• Disponible un canal de comunicación desde el gateway al nodo. En el caso de utilizar modo de bajo consumo, el nodo no está escuchando el canal mientras está dormido. El gateway lo tiene en cuenta y almacena el mensaje hasta que su destino provoca una comunicación. Justo antes de entrar en modo de bajo consumo, espera un instante en el que el gateway puede enviar el mensaje almacenado.
• Este canal puede utilizarse para enviar mensajes de control para configurar parámetros de los nodos o para interrogarle sobre el valor de los mismos.
• EnigmaIOT soporta actualización inalámbrica OTA, a través del mismo medio por el que se envían y reciben los mensajes. El envío del firmware se realiza mediante un programa escrito en Python. El script se configura mediante línea de comandos para que sea fácil de integrar en sistemas automatizados.

Descripción del gateway

La función del gateway de EnigmaIOT es comunicar los nodos con la red local, haciendo la conversión de los datos a mensajes MQTT.

Además gestiona la comunicación con los nodos y es el encargado de comprobar la validez de las claves dinámicas.

Igual que en el nodo, las claves no se guardan de manera permanente. Éstas se almacenan en RAM para garantizar la privacidad. Si el gateway se reinicia, todos los nodos deberán volver a registrarse.

El protocolo ESP-NOW no funciona bien si se utiliza a la vez que el WiFi en el mismo microcontrolador. Por ello la funcionalidad del gateway se ha dividido en dos ESP8266.

El primero gestiona la comunicación ESP-NOW y envía los mensajes a través del puerto serie.

El segundo toma estos datos por su interfaz serie y los reenvía por MQTT.

Como se permite la comunicación bidireccional, este segundo ESP8266 puede suscribirse a ciertos tipos de mensajes MQTT para enviarlos en sentido hacia los nodos por la misma vía.

Esta solución no sería necesaria si, en vez de ESP-NOW, se utilizase otro medio para comunicar los nodos y el gateway.

** Hace poco he descubierto que estaba cometiendo un error al asignar los canales WiFi en el sistema y ESP-NOW estaba intentando enviar los mensajes por un canal diferente al que estaba sintonizado el gateway. Después de hacer bastantes pruebas, he visto que sí es posible que la comunicación WiFi conviva sin problemas con el protocolo ESP-NOW dentro del mismo ESP8266. Por ello, de aquí en adelante, me voy a centrar en unir la funcionalidad de ambos módulos, Gateway y el Bridge MQTT.

Futuros pasos

El sistema ya tiene implementado todo lo anterior. Tengo algunas ideas para seguir trabajando en el proyecto.

La primera es diseñar una PCB a medida para sensores de bajo consumo. De esta manera podré añadir un regulador que me permita que funcione con baterías alcalinas tipo AA y eliminar todos los otros componentes que suelen llevar las placas de desarrollo. A este diseño hay que añadirle una caja que pueda imprimirse en 3D.

De momento estoy satisfecho con el montaje del gateway, aunque una placa PCB a medida tampoco le vendría mal para darle mayor fiabilidad.

En cuanto al software, estoy pensando en añadir la posibilidad de crear grupos de nodos para poder enviar mensajes a varios a la vez y que sea el gateway el que gestione dichos grupos. Esto me permitiría también cargar el firmware a en grupo, en vez de tener que hacerlo nodo a nodo.

Es deseable también poder actualizar el gateway de la misma forma que se hacen los nodos. Y si es con el mismo script mucho mejor.

Cómo puedes colaborar

De momento, el sistema está en una fase de desarrollo que podríamos valorar como pre-beta. Ya tiene la funcionalidad básica que quería implementar, por lo que ya está preparado para que montes varios nodos y los pruebes en un entorno real.

Como he comentado al principio no soy un experto en temas de cifrado y seguridad. Es muy probable tenga algún fallo en ese aspecto. Agradezco por tanto todos los comentarios y sugerencias que me puedas aportar en este aspecto.

Seguro que cuando tenga el sistema en operación en mi casa me surgirán más necesidades que podré ir implementando. Si se te ocurre alguna funcionalidad que creas interesante para implementar en el futuro no dudes en comentármela.