002 · El prototipo se encuentra con el reglamento: auditamos nuestro propio firmware

En la entrada 001 escribimos que no recomendamos a los clientes lo que no hacemos con nosotros mismos. Esta entrada lo pone a prueba. Hicimos a nuestro propio prototipo el análisis que hacemos a los productos de los demás, y publicamos el resultado entero, incluida la parte que no nos deja bien en la fotografía.

El producto, ahora con nombre

Lo que veníamos llamando solo “nuestro producto agro-IoT” se llama Aeromate. Es un ecosistema de control ambiental para secado y maduración: vino, hierbas aromáticas, queso, charcutería, puros. El módulo más maduro se llama Aerodry y hace una sola cosa, pero la hace bien: lee temperatura y humedad, calcula el punto de rocío y el déficit de presión de vapor, y gobierna un deshumidificador dentro de una cámara con temperatura controlada, sea una bodega, un frigorífico adaptado o una cámara de curado.

El Aerodry lleva dos años de funcionamiento continuo en un entorno real. Detecta los ciclos del compresor del frigorífico, para no confundir los picos de humedad que estos provocan con eventos reales. Avisa cuando la toalla de curado se seca. Corta el deshumidificador si la temperatura sube demasiado. Es un prototipo del que estamos orgullosos, y precisamente por eso sirve para este ejercicio. La distancia entre “funciona desde hace dos años” y “puede venderse en Europa en 2027” es casi exactamente la lista de requisitos del anexo I del CRA, y merece la pena medir esa distancia en un caso en el que podemos contarla entera.

Cómo hicimos el análisis

Tomamos el firmware tal como está en el repositorio, sin arreglarlo primero para la fotografía, y recorrimos los requisitos esenciales de ciberseguridad de las dos partes del anexo I: las propiedades de seguridad del producto y el tratamiento de vulnerabilidades. Para cada requisito registramos una de tres respuestas: cumple, no cumple, o no se aplica. Sin redondear a nuestro favor.

Lo que el prototipo ya hace bien

Empezamos por el lado positivo, que también existe.

La capacidad de actualización está ahí. El Aerodry actualiza el firmware por OTA desde el primer día. El CRA exige que un producto pueda recibir actualizaciones de seguridad durante todo el período de soporte, y muchos prototipos ni siquiera tienen el mecanismo. Nosotros lo tenemos. El problema, como se verá enseguida, es la seguridad de ese mecanismo, pero el mecanismo existe.

Las credenciales de Wi-Fi no están en el código. El primer arranque crea un punto de acceso temporal donde el usuario configura la red de casa, y esas credenciales nunca pasan por el repositorio. Fue una buena decisión en 2024 y sigue siéndolo hoy.

Hay lógica de seguridad operativa funcionando: el corte por temperatura máxima, la detección de los ciclos del compresor, las alertas de mantenimiento. No es ciberseguridad, pero revela la actitud correcta, porque el sistema ya fue escrito contando con que las cosas salen mal.

Y la superficie de ataque es pequeña. Dos servicios de red, un sensor, un relé. El CRA pide que se minimice la superficie de ataque, y aquí la simplicidad del prototipo trabaja a favor sin esfuerzo alguno.

Lo que falla, y por qué iba a fallar siempre

Describimos aquí los nueve fallos con consecuencia directa para quien usa el producto. Estos son los cuatro más graves.

La actualización OTA acepta firmware de cualquier origen. La dirección de actualización va por HTTP simple, en el puerto 80, sin autenticación y sin verificación de firma. Cualquier aparato en la misma red puede sustituir el firmware entero. En una red nuestra, de laboratorio, esto es una comodidad. En casa de un cliente pasa a ser la vulnerabilidad más seria del producto, porque el mecanismo que debía servir para corregir problemas se convierte en la puerta de entrada. Es el primer punto del plan de trabajo, por la razón simple de que un canal de actualización inseguro es más peligroso que no tener canal alguno.

Toda la comunicación viaja en claro. Las lecturas, el estado del relé y los registros salen por HTTP sin cifrar, con los propios datos metidos en la dirección, hacia un servidor que no pide autenticación. El CRA exige que los datos en tránsito estén protegidos en su confidencialidad y en su integridad. La corrección técnica es bien conocida, con TLS y autenticación mutua en el MQTT. El coste real no está en saber qué hacer, está en hacerlo caber en un microcontrolador y en gestionar los certificados a lo largo de cinco años de soporte. Será el tema de una entrada técnica propia.

La contraseña de fábrica es la misma en todos los aparatos. El punto de acceso de configuración usa una contraseña fija, débil e igual en todas las unidades, y encima está publicada en el README. Este es de los pocos puntos en los que el CRA señala con el dedo una mala práctica concreta por su nombre: nada de contraseñas universales de fábrica. La corrección pasa por generar una contraseña distinta por unidad, en producción, impresa en la etiqueta del aparato. Obsérvese adónde nos lleva esto: deja de ser un problema de firmware y pasa a ser un problema de la línea de montaje. Fue el descubrimiento más útil de toda la auditoría, y volvemos a él al final.

Había un secreto de integración en el repositorio público. El identificador de un aparato en una integración con una plataforma en la nube estaba escrito en el código, en un repositorio abierto. Ya ha sido revocado. Queda registrado aquí porque es el error más común que encontramos en el firmware de los demás, y con nosotros no fue diferente.

Los otros cinco, en resumen. No hay SBOM, el inventario de componentes: las dependencias están copiadas dentro del repositorio con versiones congeladas en fechas distintas, lo que es más arqueología que inventario. No hay verificación de integridad en el arranque. No hay registro de eventos de seguridad ni detección de accesos indebidos. No hay forma de borrar los datos al final de la vida útil, y este punto es menos abstracto de lo que parece, porque el aparato guarda la contraseña de la Wi-Fi de la casa en memoria sin cifrar: un Aerodry revendido de segunda mano se lleva consigo la red del dueño anterior. Y falta además extender al producto la política de divulgación de vulnerabilidades, que en el sitio web ya tiene un embrión pero aún no tiene clave PGP ni canal propio.

La conclusión que importa

Nueve fallos con consecuencia directa, en un cuadro de veintiún requisitos aplicables, no es un mal resultado. Es el resultado normal de cualquier prototipo, incluidos los buenos, incluidos los que ya llevan dos años funcionando. Ninguno de estos fallos vino del descuido. Vinieron de prioridades que eran correctas para la fase de prototipo y dejan de serlo cuando el objetivo pasa a ser entregar el aparato a desconocidos. Un prototipo sirve para demostrar que el control de humedad funciona. Un producto tiene que aguantar estar en casa de alguien que no lo construyó.

El CRA es, en el fondo, la lista de trabajo entre una cosa y la otra. Y el ejercicio reveló algo que solo se ve haciéndolo: cerca de la mitad de las correcciones no es software. Es proceso de fabricación, como la contraseña por unidad. Es infraestructura, como la autoridad de claves que firma el firmware y tiene que mantenerse en pie cinco años. Es documentación, como la SBOM y el expediente técnico. Y es organización, como el canal de divulgación y el equipo que responde. Por eso dejar la conformidad para la víspera del marcado CE sale caro: a esas alturas el coste ya está dibujado por completo dentro del producto, y tocarlo implica reabrirlo todo.

La entrada 003 toma esta auditoría y la transforma en un plan, con la secuencia del prototipo al producto y una idea de lo que cuesta cada fase. Si alguna decisión del plan se revela errada por el camino, quedará registrada aquí, como acordamos.

---

El análisis completo, requisito a requisito, está en el anexo a esta entrada. Es el mismo formato de informe que entregamos a los fabricantes.