Envias un módulo Bluetooth con firmware sin firmar y, implicitamente, has confiado en cualquiera que pueda grabarlo. Un competidor clona tu producto, un atacante inserta una puerta trasera, o una OTA defectuosa deja el parque inutilizable — y no puedes distinguir tu imagen de la de ellos en el arranque. Secure boot cierra esa brecha: el hardware verifica criptograficamente una firma antes de permitir que cualquier codigo se ejecute. Este articulo aborda el lado ingenieril — raiz de confianza, cadena de firmas, aprovisionamiento de claves, anti-rollback, OTA segura, bloqueo de depuracion y las concesiones que aceptas.
Por que existe secure boot
Las amenazas son concretas:
- Clonado. Una imagen sin firmar se lee de una unidad y se graba en mil falsificaciones.
- OTA maliciosa. Si el canal de actualizacion no esta autenticado, quien lo alcance controla el dispositivo.
- Manipulacion en la cadena de suministro. Un servidor de compilacion o contratista comprometido envia codigo que nunca escribiste.
- Implantes persistentes. Un implante a nivel de bootloader sobrevive a las actualizaciones de la app porque el verificador de la app corre *debajo* de el.
Sin secure boot, el unico limite es “¿puede el atacante grabar fisicamente o alcanzar el puerto?”. Con el, el limite pasa a ser “¿tiene el atacante la clave privada de firma?”.
Raiz de confianza
Todo descansa en un bootloader ROM inmutable grabado en el silicio en fabrica. Contiene la logica de verificacion del fabricante y un espacio de un solo uso (OTP / eFuse) que guarda el *hash de tu clave publica* — nunca la clave privada.
- La clave privada vive solo en un servidor de firma offline y nunca toca el dispositivo.
- La cadena de confianza va ROM -> bootloader -> aplicacion. Cada etapa verifica la firma de la siguiente antes de ceder el control.
Un esquema tipico:
ROM (fija) --verifica--> Bootloader (firmado) --verifica--> Aplicacion (firmada)El esquema de firma
El mecanismo es la firma asimetrica:
1. La imagen se hashea (SHA-256) y el hash se firma offline con tu clave ECDSA P-256 (o Ed25519) privada.
2. El bootloader, al encender, recalcula el hash y verifica la firma contra la clave publica en la que confia.
3. Solo si la verificacion pasa salta a la imagen.
Guardar la clave publica completa en eFuse desperdicia bits escasos, asi que la mayoria de los disenos almacenan un SHA-256 de la clave publica. El bootloader primero comprueba que la clave de la imagen coincida con el digest de eFuse y luego verifica la firma con esa clave.
Una verificacion minima:
def verify_image(img, pk_digest, sig):
if sha256(img.public_key) != pk_digest:
return FAIL # clave incorrecta
if not ecdsa_verify(img.public_key, sig, sha256(img.code)):
return FAIL # firma invalida
return OKAnti-rollback
Una imagen firmada no basta si un atacante puede grabar una imagen firmada *antigua y vulnerable* que enviaste el ano pasado. La solucion es un contador monotico de version en eFuse:
- La imagen lleva un numero de version; el dispositivo guarda la version mas alta que ha ejecutado.
- El arranque rechaza una imagen cuya version es inferior al contador guardado.
- Los bits de eFuse son de un solo uso, asi que el plan del contador debe fijarse antes de produccion — no puedes “anadir mas” despues.
OTA segura
La misma firma que protege la imagen de fabrica debe proteger las actualizaciones. El flujo:
1. CI firma la nueva imagen con la clave offline; el dispositivo la verifica al descargar.
2. Usa un esquema de doble banco: escribe la actualizacion en el slot B, verifica y luego intercambia. Si la verificacion falla, el slot A sigue corriendo — sin bloqueo.
3. La clave de firma OTA debe coincidir con la clave eFuse, asi el canal de actualizacion queda autenticado de extremo a extremo.
Bloqueo de la interfaz de depuracion
Un módulo Bluetooth con SWD/JTAG abierto es un libro abierto: lectura y regrabado total del codigo. Secure boot es tan fuerte como el puerto de depuracion:
- Bloquea la interfaz de depuracion tras el aprovisionamiento.
- Proporciona una reapertura controlada — tipicamente “borrar todo para desbloquear” o un desafio-respuesta — para que las devoluciones/RMA se puedan borrar pero nunca leer.
- Una comparacion de implementaciones comunes:
| Control | nRF Secure Boot (NSIB) | ESP32 Secure Boot v2 | SoC eFuse generico |
|---|---|---|---|
| Almacen clave | hash de pubkey en eFuse | digest de pubkey en eFuse | hash OTP |
| Firma | ECDSA P-256 | RSA-3072 / ECDSA | ECDSA |
| Anti-rollback | Contador monotico | Version en eFuse | Manual |
| Bloqueo debug | bloqueo CTRL-AP | JTAG disable eFuse | SWD lock |
| OTA segura | MCUBoot / SUIT | Nativa | Custom |
Hardware criptografico en el módulo
Los SoC BLE modernos traen los primitivos que necesitas: un TRNG, AES y aceleradores ECDSA (nRF52/53, ESP32, DA1459x). Verificar una firma en un Cortex-M4 tarda decenas de milisegundos y consume mA en esa rafaga — trivial frente a un arranque que ocurre una vez. Usa las librerias de bootloader del fabricante; no implementes la cripto a mano.
Concesiones y modos de fallo
Secure boot no es gratis:
- Riesgo de bloqueo. Pierdes la clave privada y nunca mas puedes firmar — sin actualizaciones en campo. La custodia de la clave es el activo mas importante.
- Sin retroceso. Una version nueva mala no se evade grabando la vieja (el contador lo impide). Debes empujar una version arreglada *mas nueva*.
- Rendimiento de aprovisionamiento. Los grabados eFuse son de un solo uso; un error bloquea la unidad en linea. Valida la unidad dorada antes de grabar en masa.
- Recuperacion. Planea una via de imagen de “recuperacion” firmada desde el principio; retroadaptarla luego es dificil.
Lo que un OEM debe hacer
Si construyes un módulo Bluetooth que sale de tu fabrica, lo minimo:
1. Genera el par de claves en un HSM / servidor de firma offline. La clave privada nunca esta en un portatil de desarrollo ni en el runner de CI.
2. Graba el hash de la clave publica en eFuse en un paso de aprovisionamiento protegido; verifica en una unidad dorada antes de produccion en masa.
3. Firma cada artefacto — bootloader, aplicacion, OTA — en CI con la clave offline.
4. Habilita anti-rollback y bloquea el puerto de depuracion.
5. Mantén una via de recuperacion (imagen de recuperacion firmada) y un plan de rotacion / revocacion de claves.
Conclusion
Secure boot mueve la confianza de “quien puede grabar” a “quien tiene la clave”. Es barato de anadir en diseno y casi imposible de retroadaptar. Integrarlo, bloquea el depurador y guarda la clave privada como joya de la corona — porque para un atacante, tu firma de firmware es lo unico que hay entre el y tu producto.
