El uso de pantallas de papel electrónico para indicar errores fatales y seguridad comprometida en los nodos críticos de IoT.

Los nodos de la Internet de las Cosas (IoT) y de la IoT Industrial (IoTT) se están utilizando en sistemas cada vez más seguros en los que la seguridad y la protección de la red en su conjunto es más importante que la funcionalidad de los dispositivos individuales de esa red. Esto significa que si un nodo de IoT detecta que ha sido comprometido, o si se produce un error de firmware irrecuperable, la acción más segura puede ser que el nodo se apague tan pronto como sea prácticamente posible para proteger al nodo y a la red de consecuencias potencialmente peligrosas.

Sin embargo, una vez que el nodo se apaga, todo el contenido de la memoria volátil se pierde. El almacenamiento de datos de depuración en una memoria no volátil como la EEPROM o el flash consume tiempo y energía, lo que aumenta el riesgo de posibles daños. Además, el sistema puede haber estado comprometido hasta un punto en el que la lectura de los datos del encendido puede no proporcionar datos fiables si la secuencia de encendido también se ha visto comprometida.

Este artículo explica cómo las pantallas de papel electrónico (EPD) se pueden conectar fácilmente a un nodo de IoT o IIoT para mostrar el último error conocido, proporcionando una indicación visual de la razón del evento de apagado para que los técnicos puedan tomar la acción apropiada. A continuación, proporciona ejemplos de pantallas de papel electrónico de Pervasive Displays y Display Visions y analiza cómo estas pantallas se pueden interconectar con un microcontrolador y configurar para proporcionar información de diagnóstico mientras se consume poca o ninguna energía.

Nodos de alta seguridad de IoT y IIoT

Cada vez más, los diseñadores de los nodos de IoT y IIoT tienen la responsabilidad de disponer de métodos de seguridad cada vez más sofisticados para garantizar el correcto funcionamiento del microcontrolador anfitrión. En general, hay tres tipos de amenazas a la seguridad de las que hay que cuidarse:

1. Un mal funcionamiento del firmware del microcontrolador
2. Datos de entrada no válidos de sensores, teclados, periféricos en serie u otros dispositivos externos
3. Acción de un actor malintencionado

El mal funcionamiento del firmware de un microcontrolador puede ocurrir por varias razones: errores de codificación en el firmware instalado; cálculos inválidos que resultan en un mal funcionamiento; o, en casos extremadamente raros, un mal funcionamiento del hardware del microcontrolador. El firmware bien escrito suele detectar esto al restregar las entradas de las subrutinas y las funciones. En casos extremos en los que el firmware está bloqueado o en bucle, un tiempo de espera del vigilante recuperará el firmware mediante la vectorización a una subrutina de control de errores o la realización de un reinicio completo del microcontrolador.

En el caso de datos de entrada no válidos, por ejemplo si un sensor externo funciona mal o es manipulado, pueden resultar datos fuera de rango que pueden no haber sido contabilizados adecuadamente en el código de aplicación. Por ejemplo, si el sensor de temperatura ambiente de una sala de control habitada por humanos registra incorrectamente una temperatura de 250 °F, puede tratarse de un mal funcionamiento del sensor o de una manipulación maliciosa. Un programador de firmware descuidado puede no haber codificado para esa lectura de alta temperatura que podría conducir a algo tan trivial como el registro incorrecto de datos, o algo tan grave como permitir el acceso de un intruso a un área segura, o tan crítico como un error en el cómputo de un algoritmo de control que podría conducir a un fallo del equipo o a graves lesiones personales. Los posibles resultados negativos son muchos.

Los actores maliciosos son diferentes en el sentido de que pueden tener la intención deliberada de causar el mal funcionamiento del nodo IoT. El mal funcionamiento debido al intento de piratería podría ser detectado por las rutinas de seguridad como una intrusión; sin embargo, también podría disfrazarse de un mal funcionamiento del firmware o de datos de entrada externos no válidos. El ejemplo de una lectura de temperatura ambiente de 250 °F podría ser causado por un actor malintencionado que prueba el comportamiento del firmware en una lectura tan alta con la intención de probar un método de intrusión; por ejemplo, las puertas pueden ser abiertas automáticamente si la lectura de temperatura ambiente de 250 °F se evalúa erróneamente como un incendio.

Reacción a los fallos del firmware

Independientemente de la fuente del error, el firmware del microcontrolador para los nodos de alta seguridad de IoT y IIoT tiene que ser intolerante a las fallas. Todas las fallas deben ser codificadas y captadas. Las entradas de las subrutinas y funciones deben ser lavadas y todos los datos de entrada del sensor deben ser validados. Los temporizadores de vigilancia deben ser programados con la intención de detectar código bloqueado o en bucle que esté tardando demasiado en base a un tiempo de ejecución conocido.

Cuando se detecta un mal funcionamiento del firmware en un nodo de IoT o IIoT de alta seguridad, independientemente de si el mal funcionamiento es accidental o deliberado, el firmware debe atrapar el evento lo antes posible. Las acciones comunes incluyen el intento de compensar el mal funcionamiento. En el caso de un sensor que funcione mal y que esté constantemente fuera de rango, el firmware puede tener un "modo de funcionamiento limitado" para que ese sensor compense los malos datos hasta que pueda ser reemplazado. Se puede reiniciar una rutina de firmware que devuelva resultados incorrectos. A menudo se envía un código de error a través de la red para notificar al anfitrión de la red del problema.

Sin embargo, en algunos nodos de IoT o IIoT de alta seguridad existe una categoría especial de disfunciones para las que no puede o no debe haber compensación o contramedidas. Esto puede incluir la detección de alteraciones físicas, fallos en la suma de comprobación interna, algunos fallos en la autocomprobación incorporada (BIST) y cualquier fallo que pueda ser causado por un firmware comprometido o un sistema pirateado. Para estas situaciones de alta seguridad, la única opción puede ser apagar el nodo de forma inmediata y segura. El anfitrión de la red determinará que el nodo se ha apagado cuando no responde a las peticiones de la red. Si el nodo se apaga sin enviar un informe de error al anfitrión, y si el nodo ignora los comandos de red para reiniciarse, es una indicación de que se ha producido un fallo fatal y que debe enviarse un técnico para examinar físicamente el nodo en busca de la causa.

Sin embargo, una vez que el nodo se ha apagado, toda la memoria volátil y los datos de estado se borran inmediatamente. Esto hace que el diagnóstico de la causa del apagado sea muy difícil, si no imposible. Opcionalmente, antes de apagar el nodo, los datos de diagnóstico podrían almacenarse en una memoria no volátil, como la EEPROM o la memoria flash. El problema es que escribir en estos tipos de memoria lleva tiempo, durante el cual el nodo debe permanecer activo y posiblemente provocar un daño adicional.

Diagnosticar errores fatales con el papel electrónico

Las EPD consumen muy poca energía y pueden usarse para almacenar y mostrar información de error y diagnóstico justo antes de apagar el nodo. Una vez que el nodo se apaga, la EPD puede mantener su imagen de pantalla sin ninguna energía durante días o semanas. La información en la pantalla da a los técnicos una indicación visual de la razón del apagado, permitiéndoles decidir si es seguro encender el nodo de IoT, o si debe ser sacado de la red para un análisis detallado.

Un ejemplo de una EPD adecuada para mostrar información de diagnóstico es el módulo EPD E2271CS091 de Pervasive Displays. Se conecta a cualquier microcontrolador compatible con una interfaz serial SPI y tiene una pantalla de alto contraste de 2.71 pulgadas (pulgadas) (Figura 1).

Figura 1: El módulo EPD E2271CS091 tiene una pantalla de alto contraste de 2.71 pulgadas con una resolución de 264 x 176 píxeles. Tiene un amplio ángulo de visión y se conecta a cualquier microcontrolador compatible con una interfaz SPI. (Fuente de la imagen: Pervasive Displays)

El módulo EPD E2271CS091 utiliza una pantalla de matriz activa de transistores de película fina (TFT) con una resolución nativa de 264 x 176 píxeles a 117 puntos por pulgada (dpi). Esto permite que la pantalla contenga mucha información para ayudar a los técnicos en el diagnóstico. La pantalla antirreflejos tiene un amplio ángulo de visión de casi 180˚, lo que permite una fácil visualización de la pantalla cuando se encuentra en lugares de montaje inusuales. El EPD requiere una fuente de alimentación de 3.0 voltios.

El microcontrolador anfitrión envía datos a la EPD a través de una interfaz SPI en el conector de cinta de 24 pines de la pantalla. La comunicación de datos SPI es sólo una vía, desde el microcontrolador anfitrión hasta la EPD. La única comunicación de vuelta de la EPD al microcontrolador anfitrión es un pin de "dispositivo ocupado" en el conector de la cinta, lo que simplifica enormemente la interfaz y aumenta la confianza en los datos de diagnóstico mostrados.

Si se detecta un error o un intento de piratería, y si el error es lo suficientemente grave como para requerir el cierre del nodo, el error debe ser atrapado primero por el firmware, el perro guardián u otro método. El control debe ser transferido a la rutina de registro de errores que envía los datos a la EPD. Esta rutina de registro de errores debería ser la tarea de mayor prioridad para evitar la interrupción o la corrupción de los datos. Para una máxima fiabilidad, se recomienda que la rutina de registro de errores sea totalmente autónoma, sin llamadas a subrutinas o funciones externas. Lo ideal es que la rutina de registro de errores esté en un flash protegido contra escritura permanente para garantizar la integridad del código, incluso después de las actualizaciones del firmware.

Antes de que el EPD se actualice con los datos de error, el microcontrolador anfitrión debe enviar primero un comando de reinicio suave a través de la interfaz SPI al EPD para borrar la pantalla. Luego envía la información de la pantalla en blanco y negro en una serie de secuencias de bytes, donde cada bit de un byte representa un píxel en la EPD. Una vez que la secuencia se completa, la rutina de registro de errores puede apagar el microcontrolador. Los diferentes fabricantes de microcontroladores tienen diferentes maneras de apagar, ya que esto depende de la arquitectura y del fabricante. En algunas situaciones, y por razones de seguridad, el fabricante puede tener una forma no documentada de apagar el microcontrolador, que solo está disponible a petición. Opcionalmente, se puede utilizar un circuito externo para interrumpir la alimentación del microcontrolador; sin embargo, esto aumenta la complejidad del sistema, lo que reduce la fiabilidad. Por lo tanto, se prefiere el control de apagado del microcontrolador.

Para ayudar en el desarrollo utilizando la EPD, Pervasive Displays ofrece el kit de extensión de la EPD B3000MS034 (Figura 2). Tiene una tarjeta de extensión con un conector para la pantalla de EPD de 24 pines, así como conectores para otras EPD de pantalla penetrante que requieren conectores de 40 y 26 pines. La placa de extensión es compatible con los kits de desarrollo LaunchPad de Texas Instruments y evaluación, pero también puede utilizarse con otros kits de desarrollo. Se puede conectar un cable puente de 20 pines al conector de cabecera de 20 pines 90˚, que al ser soldado a la placa de extensión, permite monitorear las señales de control a la EPD durante el desarrollo.

Figura 2: El kit de extensión para el módulo EPD E2271CS091 de Pervasive Displays incluye un conector de 24 pines en la tarjeta de extensión para el cable de cinta de 24 pines de la pantalla. También incluye un cable puente y un conector de cabecera de 20 pines 90˚. (Fuente de la imagen: Pervasive Displays)

Otra opción de EPD es el EA EPA20-A de Display Visions (Figura 3).

Figura 3: la EPD EPA20-A EPD de Display Visions es una pantalla de 172 x 72 que puede mantener el estado de la pantalla sin energía conectada. (Fuente de la imagen: Display Visions)

Esta EPD tiene una pantalla en escala de grises de 172 x 72 y también utiliza una interfaz SPI para la comunicación con un microcontrolador anfitrión. La EPD es extremadamente baja en potencia, requiere una única fuente de 3.3 voltios y consume sólo 40 milivatios (mW) durante un cambio de pantalla. La EPD EA EPA20-A de Display Visions también puede mantener su pantalla cuando no se aplica energía.

Conclusión:

Los nodos de alta seguridad de IoT y IIoT a veces deben apagarse en respuesta a un error fatal de firmware o a una amenaza detectada. Esto puede resultar en la pérdida de todos los datos volátiles, incluyendo el estado interno del microcontrolador anfitrión. Sin embargo, los datos de estado y de diagnóstico pueden enviarse a una EPD conectada antes del cierre y mostrarse durante días o semanas. Esto proporciona a los técnicos la información que necesitan para determinar la causa del cierre y tomar futuras precauciones, si es necesario, para salvaguardar y asegurar el nodo y la red.