Actualizaciones inalámbricas de firmware para dispositivos IoT

Una actualización inalámbrica (OTA) instala nuevo firmware en un dispositivo a través de su red de radio. Un contador o sensor puede permanecer en servicio diez años o más; en ese tiempo es probable que se descubran fallos en su pila de radio o en el código de aplicación. En un parque de 400 dispositivos repartidos entre 20 sitios, corregir un fallo manualmente supone 20 visitas. La misma corrección por radio se convierte en una campaña planificada desde el Gateway.

Esta guía forma parte del itinerario sobre redes y arquitectura.

Por qué necesitan actualizaciones los dispositivos de campo

El caso Zigbee mejor documentado es el ataque publicado en 2016 por Ronen, O'Flynn, Shamir y Weingarten contra lámparas Philips Hue. Las lámparas autenticaban el firmware con una clave AES-CCM compartida por todas las del mismo tipo. Los investigadores extrajeron la clave mediante análisis de consumo eléctrico con equipos que costaban unos cientos de dólares. Con ella podían crear firmware que todas las lámparas de ese tipo aceptaran como auténtico, y un fallo en el código Zigbee Light Link permitía que la imagen maliciosa pasara de una lámpara a otra. Philips corrigió el fallo de toma de control y distribuyó la corrección mediante OTA. La extracción de la clave demostró por qué una imagen debe llevar una firma que el dispositivo compruebe con una clave pública.

Los fallos no maliciosos también importan. Un defecto que corrompe un contador de impulsos o hace que un dispositivo abandone la red después de reiniciarse su router padre debe corregirse en todas las unidades afectadas. NIST SP 800-82 Rev. 3, sección 6.2.11, pide a los operadores de tecnología operativa un proceso documentado de gestión de parches: cómo conocer los parches, probarlos, decidir cuándo aplicarlos y qué controles compensatorios usar mientras se aplaza uno. También indica que los parches se instalen durante paradas planificadas. Los pasos de campaña siguientes siguen ese criterio.

Cómo funciona en Zigbee

Los dispositivos Zigbee utilizan el clúster OTA Upgrade, ID 0x0019, definido en el capítulo 11 de la Zigbee Cluster Library (ZCL). El Gateway actúa como servidor OTA y almacena los archivos de imagen. El dispositivo es el cliente OTA y dirige la descarga.

Cada archivo OTA comienza con el identificador 0x0BEEF11E y una cabecera que indica el código de fabricante, el tipo de imagen, la versión del archivo y el tamaño total. También puede indicar versiones mínima y máxima de hardware. El servidor usa el código de fabricante y el tipo de imagen para seleccionar una imagen candidata. Confirme el modelo exacto, la revisión de hardware y el archivo aprobado por el fabricante; la coincidencia de identificadores de cabecera no demuestra por sí sola que sea adecuado.

El intercambio sigue este orden:

1. El servidor puede enviar Image Notify para anunciar una imagen disponible. No puede avisar inmediatamente y de forma fiable a un terminal dormido; estos clientes envían periódicamente Query Next Image Request, con código de fabricante, tipo de imagen y versión actual.
2. El servidor responde con Query Next Image Response: la versión de archivo ofrecida y el tamaño de la imagen.
3. El cliente envía Image Block Request con el desplazamiento de archivo que necesita y el bloque máximo que acepta. El servidor devuelve esos datos en Image Block Response. El cliente repite hasta recibir el archivo completo. El cliente, no el servidor, sigue el progreso, de modo que el servidor mantiene poco estado por dispositivo.
4. El cliente comprueba la imagen y envía Upgrade End Request con estado SUCCESS o INVALID_IMAGE.
5. El servidor responde con Upgrade End Response, que incluye una hora de actualización. En ese momento, el cliente pasa a la nueva imagen. El valor 0xFFFFFFFF le indica que espere una orden posterior, lo que permite cambiar un grupo de dispositivos a la vez.

ZCL exige un cargador de arranque de aplicación y memoria adicional para la imagen nueva completa antes de activarla. Esto permite descargar mientras funciona la imagen anterior, pero no garantiza la continuidad de la aplicación ni de los informes. Compruebe la implementación del dispositivo y la carga de red; el reinicio con la nueva imagen interrumpe el servicio.

Duración de una actualización Zigbee

El tamaño de bloque hace lentas las actualizaciones Zigbee. El cliente fija un tamaño máximo de datos en cada petición. ZCL permite que el servidor envíe menos para dejar espacio al encaminamiento cuando el cliente está a varios saltos; las implementaciones habituales envían 50 bytes de imagen por bloque. Una imagen de 200 kB requiere entonces 4.000 bloques, cada uno con una petición y una respuesta que atraviesan todos los saltos. Si un viaje de ida y vuelta a través de dos saltos tarda un cuarto de segundo, la transferencia lleva unos 17 minutos. Coincide con los 10 a 20 minutos que Edge muestra antes de una actualización.

Dos factores la alargan. El servidor puede limitar la cadencia de un cliente mediante el atributo MinimumBlockPeriod, un retraso mínimo en milisegundos entre peticiones de bloques. ZCL da el ejemplo de limitar cada cliente a un bloque cada 500 ms cuando varios descargan a la vez, lo que duplica los 17 minutos. Además, un dispositivo terminal dormido solo recibe datos cuando consulta a su router padre. ZCL le permite pedir bloques más despacio de lo autorizado por el servidor para ahorrar batería; un sensor alimentado por batería puede tardar horas.

Firma de imágenes

ZCL recomienda firmar la imagen con la clave privada del fabricante y que el dispositivo compruebe la firma con la clave pública correspondiente al terminar la descarga (apartado 11.3.3.1). No lo exige. Cada estándar de aplicación fija sus propios mínimos. Smart Energy puede usar firmas de imágenes junto con cifrado de red y APS; otros estándares pueden usar solo cifrado de red (apartado 11.3.2). Sin firma, un hash de la imagen (apartado 11.3.3.2) indica que el archivo llegó intacto, pero no quién lo creó. Algunos fabricantes añaden su propia comprobación en el cargador de arranque. Pregunte al fabricante qué método utiliza el dispositivo. Una clave simétrica es tan segura como el dispositivo menos protegido que la almacena, como demostró el ataque a las lámparas.

Cómo funciona en LoRaWAN

Los mensajes descendentes LoRaWAN son pequeños y escasos, por lo que la LoRa Alliance desarrolló las actualizaciones inalámbricas de firmware (FUOTA) como varios paquetes de la capa de aplicación. El resumen del proceso FUOTA, TR002, los reúne:

• TS003, sincronización de reloj en la capa de aplicación, proporciona a cada dispositivo la hora de la red para iniciar una sesión multidifusión en el momento acordado.
• TS005, configuración remota de multidifusión, proporciona una dirección y claves compartidas y programa una sesión de clase C o B. Un dispositivo que solo opera en clase A no puede participar en una sesión multidifusión. Solo recibe fragmentos por transmisión individual en las ventanas de recepción posteriores a sus propios mensajes ascendentes.
• TS004, transporte de bloques de datos fragmentados, divide la imagen en fragmentos y añade corrección anticipada de errores. Con un 10 % de redundancia, un dispositivo puede perder aproximadamente el 10 % de las tramas y aun así reconstruir el archivo sin solicitar las perdidas. Una sesión admite como máximo 16.383 fragmentos.
• TS006, protocolo de gestión de firmware, informa de la versión instalada en el dispositivo y permite controlarla.

Cuando el dispositivo reúne suficientes fragmentos, reconstruye la imagen, comprueba su firma digital con la clave pública del servidor de actualizaciones y verifica que la cabecera corresponda a su hardware y firmware actual. Marca la imagen como preparada y reinicia. El cargador de arranque la instala en una segunda zona de imagen o página por página guardando su progreso, para que un corte eléctrico durante la escritura no deje al dispositivo sin firmware. Este es el proceso recomendado por TR002; admitir el transporte de fragmentos no demuestra por sí solo la verificación de firmas ni la recuperación tras una pérdida de alimentación. Verifique esas funciones en el dispositivo y el cargador de arranque exactos.

Duración de una actualización LoRaWAN

Suponga una imagen de 100 kB enviada por multidifusión de clase C en EU868, por la frecuencia RX2 predeterminada de 869,525 MHz a DR0 (SF12, 125 kHz):

• RP002 limita la carga útil de aplicación en DR0 a 51 bytes. El comando DataFragment de TS004 utiliza 3, dejando 48 bytes de imagen por trama.
• 100 kB son 2.084 fragmentos. Con un 10 % de redundancia, el servidor envía unas 2.300 tramas.
• Cada trama ocupa unos 2,8 s de radio a SF12.
• La Recomendación ERC 70-03 limita la banda de 869,40 a 869,65 MHz a un ciclo de trabajo del 10 %. El Gateway puede transmitir 360 s por hora, unas 129 tramas por hora.

Las tramas consumen unas 1,8 horas de tiempo de emisión del Gateway, repartidas en unas 18 horas al límite del ciclo de trabajo del 10 %. El Gateway comparte ese margen con todos los demás mensajes descendentes del canal. A DR5 (SF7) caben 239 bytes en cada trama y la misma imagen requiere unas 460 tramas de 0,39 s: unos 30 minutos bajo el mismo límite. Pero todos los dispositivos del grupo deben recibir SF7 con fiabilidad y los que están en el borde de cobertura a menudo no pueden. La transmisión individual a un dispositivo de clase A es aún más lenta. A razón de un fragmento por mensaje ascendente, un dispositivo que informa cada 15 minutos necesita más de 3 semanas para recibir las mismas 2.300 tramas.

La compatibilidad depende del modelo. Compruebe qué paquetes FUOTA implementa, si puede abrir una sesión de clase B o C y si dispone de memoria flash para alojar una segunda imagen.

Planifique una campaña de actualizaciones

1. Liste cada dispositivo con modelo, revisión de hardware, código de fabricante, tipo de imagen y versión de archivo actual.
2. Lea las notas de la versión. Compruebe si la actualización cambia un valor, unidad, factor de escala o registro que lee el sistema. Un cambio de escala produce lecturas aparentemente válidas pero erróneas.
3. Pregunte al fabricante si la imagen está firmada, si el dispositivo acepta una versión anterior y si su cargador de arranque conserva la imagen previa.
4. Actualice primero un grupo piloto. Incluya la revisión de hardware más antigua, un dispositivo en el extremo lejano de la red en malla y uno de batería si existe en el sitio.
5. Actualice el resto en grupos pequeños, por ejemplo cinco dispositivos a la vez en un Gateway, con una pausa entre grupos. Observe los dispositivos que no se están actualizando. Si sus informes llegan tarde o faltan, la red en malla está saturada: reduzca el tamaño del grupo.
6. Cuando termine cada dispositivo, vuelva a leer su versión. En Zigbee puede usar el atributo CurrentFileVersion del clúster OTA o la versión comunicada por el clúster Basic. Después compruebe que informa según lo previsto y compare sus lecturas con las anteriores a la actualización.

Cuando falla una actualización

ZCL no dispone de una orden de reversión. Permite que el servidor ofrezca una versión de archivo inferior a la instalada, pero el firmware del dispositivo decide si la acepta. El método de recuperación queda en manos del fabricante (apartado 11.18). Los ejemplos de la especificación son un cargador de arranque que intercambia la imagen nueva por la anterior y un botón pulsado al arrancar que devuelve la imagen anterior. Si el dispositivo no tiene ninguno, una imagen defectuosa exige una visita al sitio.

Puede haber huecos de datos durante la descarga y el reinicio. Un registro de energía acumulada solo conserva el total durante un hueco de transmisión si la medida continúa y el contador sobrevive a la actualización sin reinicios ni desbordamientos sin tratar. No recupera el historial perdido de potencia o temperatura instantáneas. La guía de datos obsoletos explica cómo mostrar el hueco.

El firmware del dispositivo y el software del Gateway son distintos

El Gateway es el servidor OTA. Guarda las imágenes y responde a cada petición de bloque, así que actualizar su software y reiniciarlo durante una campaña detiene todas las transferencias en curso. Termine o suspenda la campaña de dispositivos antes de actualizar el Gateway. Comience la siguiente solo cuando el Gateway actualizado esté estable y todos los dispositivos vuelvan a informar.

Actualizaciones de firmware con Edge

Edge, en el Gateway ZGW-20, mantiene un catálogo de imágenes de firmware en el Gateway. Acepta tres tipos de archivo, de hasta 5 MB cada uno: archivos Zigbee OTA (.ota) para dispositivos de terceros, imágenes EBL (.ebl) para dispositivos EpiSensor e imágenes binarias (.bin) para la IO Board. Edge valida cada archivo al subirlo y lo muestra con fabricante, modelo, versión, tamaño y estado de validez.

Una actualización puede iniciarse de inmediato o a la hora programada. Puede dirigirse a un dispositivo o a una selección. Para una selección, Edge envía la orden a cada dispositivo por turno con un retraso de hasta 60 s entre ellos, de forma que las transferencias no comiencen todas a la vez. Edge advierte de que una actualización puede tardar de 10 a 20 minutos por dispositivo y de que este puede reiniciarse; muestra cada actualización como en curso, completada o fallida. Edge se actualiza por su canal snap o desde la aplicación de escritorio, no desde este catálogo.