Secure Boot y flash encryption son controles potentes, pero no convierten por sí solos un producto IoT en seguro. Secure Boot responde “¿qué código puede ejecutarse?”; el cifrado reduce el valor de leer físicamente la flash. NVS encryption puede proteger datos almacenados seleccionados. eFuses, custodia de claves, fabricación, recuperación y soporte determinan si todo sigue funcionando fuera del laboratorio.
Secure Boot verifica firmas en la cadena de bootloader y aplicación. No cifra firmware ni protege automáticamente todas las particiones. Flash encryption cifra contenidos compatibles en la memoria externa, pero no garantiza por sí sola que solo ejecute código confiable. NVS encryption protege datos elegidos; siguen siendo necesarios transporte autenticado y autorización en backend.
Las claves de firma autorizan código para toda una familia de productos. Genéralas con buena entropía, limita el acceso, mantenlas fuera del repositorio y de logs corrientes, y planifica copias, rotación y respuesta a compromisos. Una clave filtrada es un incidente del producto.
En producción, usa una clave de cifrado flash única por dispositivo. Los eFuses almacenan opciones que pueden grabarse una sola vez; una configuración incorrecta puede desactivar depuración o complicar recuperación. Desarrollo y release difieren en ESP-IDF. Prueba el chip, revisión, SDK, tabla de particiones y proceso de fábrica en unidades de ensayo antes de aplicar cambios irreversibles.
Diseña la estación: identificar placa, provisionar material único, grabar imagen firmada, activar los controles, verificar arranque y registrar resultado por número de serie. Restringe las fixtures y evita secretos en logs. Define el tratamiento de unidades retrabajadas, devueltas o descartadas para impedir que vuelvan al inventario con identidad duplicada.
La seguridad de producción puede limitar JTAG o comandos ROM download, lo que cambia el diagnóstico y reparación. Define antes un modo de servicio autorizado, autenticado, acotado y auditado. Un reset de fábrica no restaura la confianza original: puede borrar datos de aplicación sin revertir eFuses ni cambiar identidad.
| Control | Protección principal | Riesgo residual |
|---|---|---|
| Secure Boot | Rechaza imágenes ejecutables no autorizadas. | Clave comprometida o fallo en código firmado. |
| Flash encryption | Reduce el valor de leer la flash físicamente. | No autentica el firmware por sí sola ni protege secretos en ejecución. |
| NVS encryption | Protege configuración almacenada seleccionada. | La aplicación aún puede exponer datos por logs y API. |
| Anti-rollback | Rechaza firmware inferior al nivel de seguridad. | Limita recuperación; hay que planificar versiones. |
| Restricciones de debug | Reduce rutas de acceso alternativas. | Dificulta reparación legítima sin servicio definido. |
Ensaya OTA firmada, firma inválida, corte de energía, partición incorrecta, pérdida de claves, revocación de firmware y devolución de campo. Revisa la consola serial sin revelar secretos. Conserva una recuperación firmada y verifica que rollback funcione con anti-rollback. Documenta qué se puede revertir, qué graba eFuses y quién lo autoriza.
Usa Secure Boot para autenticidad de código, flash encryption para confidencialidad en reposo y NVS encryption para secretos seleccionados. Son capas de un modelo más amplio. Claves únicas, eFuses planificados, fabricación controlada y reparación autorizada importan tanto como menuconfig. Valida el ciclo completo en el chip de producción.