Un prototipo con un ESP32 en la mesa de pruebas y una flota de 300 nodos operando a la intemperie durante tres años tienen un problema en común —ambos corren firmware y se conectan a una red—, pero uno solo de los dos necesita resolver seguridad de verdad. En un despliegue real la pregunta no es “¿está cifrado el enlace?”, sino tres preguntas independientes que rara vez se responden todas juntas: ¿cada dispositivo tiene una clave propia o comparte una de fábrica?, ¿qué evita que alguien instale un firmware falso o degrade uno legítimo a una versión vulnerable?, y ¿quién puede llegar a ese dispositivo, a la red que lo conecta y a la nube que recibe sus datos? Ya cubrimos cómo el protocolo LoRaWAN cifra cada trama con AES-128 y cómo administrar permisos de accionamiento en el dashboard; este artículo va una capa más abajo, a las decisiones de fábrica y de operación que determinan si esas dos protecciones descansan sobre una base sólida o sobre un dispositivo que cualquiera puede clonar, reflashear o suplantar.
Claves únicas por dispositivo: la primera falla que nadie ve hasta que es tarde
El error más común y más barato de cometer en un lote de producción es grabar la misma clave raíz en los primeros cien dispositivos porque es “más simple de gestionar”. El problema no es teórico: si esa clave se filtra —por acceso físico a una sola unidad, por un archivo de fábrica mal resguardado o por un empleado que se lleva el firmware de referencia— compromete a todo el lote de una sola vez, no a un dispositivo aislado. La práctica correcta, y la que exige activar OTAA en vez de ABP como ya explicamos en la nota sobre activación de dispositivos LoRaWAN, es que cada unidad reciba su propia AppKey (o NwkKey en LoRaWAN 1.1) inyectada durante el aprovisionamiento de fábrica, nunca copiada de una plantilla compartida.
En el silicio mismo hay un mecanismo equivalente y complementario para la clave de cifrado de flash: en el ESP32-S3, esa clave se genera dentro del propio chip la primera vez que se activa el cifrado y se graba en un banco de eFuse —memoria de una sola escritura, físicamente imposible de regrabar—, de modo que cada unidad termina con una clave de cifrado distinta e ilegible incluso para el propio fabricante, según documenta Espressif en su guía de seguridad del ESP32-S3. Ya mencionamos de pasada, al hablar de placas base modulares, que las tarjetas Yubox activan esta función de fábrica; lo que falta detallar es la disciplina que debe acompañarla en producción: los espacios de clave de Secure Boot que no se usan (el chip admite hasta tres claves RSA-3072 para verificar firmware) deben quemarse como revocados —el eFuse KEY_REVOKE correspondiente— antes de que la unidad salga de fábrica, para que un atacante no pueda aprovechar una ranura de clave vacía para firmar su propio bootloader malicioso.
Firmware firmado y con anti-rollback: que no corra cualquier cosa, ni una versión vieja
Un bootloader que no verifica nada ejecuta cualquier imagen que encuentre en flash, lo que en la práctica significa que un atacante con acceso físico (o un firmware de actualización mal protegido) puede instalar código propio con las credenciales de red ya embebidas listas para exfiltrar. Secure Boot rompe esa cadena de confianza ciega: el bootloader de ROM verifica la firma del segundo bootloader, y ese segundo bootloader verifica a su vez la firma de la aplicación antes de saltar a ejecutarla —cada eslabón solo corre si el anterior lo autorizó criptográficamente—.
Eso resuelve “¿es firmware legítimo?”, pero no “¿es la versión correcta?”. Ahí entra el anti-rollback: el dispositivo guarda una versión de seguridad en eFuse y la compara contra la cabecera de la imagen tanto al arrancar como durante cada actualización OTA, así que un firmware antiguo y ya parcheado —por ejemplo, una versión con una vulnerabilidad de por medio conocida— queda rechazado aunque su firma sea válida. Sin este control, un atacante que capture un paquete OTA firmado pero desactualizado podría “downgradear” un dispositivo a una versión con un bug ya corregido y explotarlo deliberadamente. Como explicamos al detallar la tabla de particiones ota_0/ota_1/otadata del ESP32, la actualización OTA ya escribe en la partición inactiva mientras la activa sigue corriendo; el anti-rollback es la verificación que decide si esa imagen nueva merece siquiera intentarse. En una flota de campo, además, conviene desplegar la actualización primero a un pequeño porcentaje de nodos —un lote piloto, no toda la red a la vez— y confirmar telemetría estable antes de empujarla al resto: el anti-rollback protege contra un ataque deliberado, pero un despliegue escalonado protege contra un error propio en el firmware nuevo.
Control de acceso: tres capas distintas, no una sola
“Control de acceso” en IoT no es un único candado, son al menos tres, y confundirlas es lo que deja huecos:
- Acceso físico al dispositivo: con Secure Boot y cifrado de flash activos, el ESP32-S3 restringe automáticamente el modo de descarga UART a un subconjunto de comandos seguros (Secure Download Mode), y desactiva el puerto JTAG de depuración salvo que se habilite explícitamente con una clave —sin esto, cualquiera con un cable y acceso a la caja del nodo podría volcar la memoria o reflashear el chip directamente por hardware.
- Acceso a la red y al join server: aquí es donde vive el aprovisionamiento por tenants que ya describimos en la nota sobre ChirpStack y TTN —cada organización o integrador con su propia clave de API, sin compartir credenciales de administrador solo para registrar un dispositivo o enviar un downlink de prueba—, y las claves de las integraciones vía API con sistemas internos, que deben rotarse periódicamente y nunca quedar embebidas en un script que alguien sube por error a un repositorio público.
- Acceso a la aplicación y al accionamiento: los roles de lectura, operación y administración sobre un dashboard, que ya tratamos en detalle en la nota sobre permisos para controlar bombas y aireadores y que no repetimos aquí porque merece su propio artículo completo.
Tratar estas tres capas como si fueran una sola —“ya activé 2FA en el dashboard, entonces estoy protegido”— es exactamente el tipo de falso sentido de seguridad que deja expuesta la capa física o la de red mientras la atención se concentra en la más visible.
Un marco de referencia: qué exige un estándar internacional de seguridad IoT
No hace falta inventar esta lista de prioridades desde cero. La norma ETSI EN 303 645, el estándar europeo de referencia para seguridad de IoT de consumo, formaliza trece provisiones de línea base entre las que destacan tres que resumen exactamente lo cubierto arriba: prohibir contraseñas o claves universales por defecto (cada unidad debe tener credenciales únicas), garantizar que el software sea actualizable de forma segura durante la vida útil declarada del producto, y mantener un canal claro para reportar vulnerabilidades encontradas en el dispositivo. Que un fabricante de hardware IoT ecuatoriano cumpla espontáneamente con un estándar europeo no es un ejercicio de certificación formal, pero sí una señal de que las prácticas de aprovisionamiento de claves y firmware firmado no son una preferencia de ingeniería aislada, sino el consenso de la industria sobre qué evita los incidentes más comunes y más costosos.
Cómo se ve esto en un despliegue de campo real
Una red de 150 nodos en una camaronera del Golfo de Guayaquil ilustra las tres capas trabajando juntas: cada tarjeta Yubox Industrial sale de fábrica con su propia AppKey para unirse por OTAA, Secure Boot activo y las ranuras de clave no usadas ya revocadas; el Gateway LoRaWAN que las conecta opera bajo una cuenta de tenant separada en el network server, sin compartir credenciales de administrador con el integrador que instaló los nodos; y una actualización de firmware que corrige un bug de reporte de oxígeno disuelto se despliega primero a diez nodos de una piscina, se confirma que el telemetría sigue estable durante 48 horas, y solo entonces se empuja a las 140 unidades restantes. Ningún paso de estos depende de que el operador de turno recuerde hacerlo bien: la clave única, el anti-rollback y la separación de tenants ya vienen resueltos por el diseño, no por la disciplina de alguien en el día a día.
Conclusión
La seguridad de un despliegue IoT real no se resume en “cifrar los datos”: depende de que cada dispositivo tenga una clave propia e irrepetible desde fábrica, de que su firmware solo acepte código firmado y nunca pueda degradarse a una versión vulnerable, y de que el acceso físico, de red y de aplicación se traten como tres candados distintos en vez de uno solo. Ninguna de estas tres capas es opcional en un despliegue de más de un puñado de dispositivos —es precisamente ahí, a escala, donde una clave compartida o un puerto de depuración abierto deja de ser un riesgo teórico. ¿Necesita revisar el aprovisionamiento de claves o la estrategia de actualización de firmware de su flota IoT? Conversemos sobre cómo cerrar esas tres capas antes de escalar su despliegue.