🛠 Sécurité industrielle : bootloader MCUboot, secure boot, SE050 et OTA signé

Objetivos

Es por eso que compramos una Portenta en el taller: toda la cadena de confianza está integrada. El bootloader MCUboot verifica la firma del firmware antes de la ejecución (secure boot), un chip dedicado NXP SE050C2 almacena claves y certificados fuera del alcance del firmware, el SoC añade TrustZone-M, MPU y RNG de hardware, y las actualizaciones OTA están firmadas. Este tutorial cartografía la cadena y establece la base: actualización del bootloader, seguida de una estrategia de despliegue firmada. Fuentes: tutoriales oficiales updating-the-bootloader, secure-boot y over-the-air-update en docs.arduino.cc.

Material

• 1 × Arduino Portenta H7 + cable USB-C de datos
• Núcleo « Arduino Mbed OS Portenta Boards » reciente (la biblioteca MCUboot se incluye en él)
• Clave privada de firma fuera de la tarjeta (estación de compilación, nunca en el repositorio Git)
• Consola serie a 115200 baudios

Código completo

// secure_boot_check.ino — squelette de principe
// > 
// interroger l'etat de la verification — suis pas a pas le tuto officiel
// docs.arduino.cc/tutorials/portenta-h7/secure-boot pour la procedure
// complete (generation de cles, signature, activation).
#include "Arduino.h"

void setup {
  Serial.begin(115200);
  while (!Serial) {}
  // Le firmware ne tourne ICI que si le bootloader MCUboot a valide
  // sa signature : ce code est deja la preuve d'un boot de confiance.
  Serial.println("Boot valide par MCUboot (secure boot actif)");

  // L'element sur NXP SE050C2 (cles/certificats inaccessibles au
  // firmware) sert notamment a verifier la signature des mises a
  // jour OTA recues par le Wi-Fi (tuto over-the-air-update).
  // > 
}

void loop { }
// Chaine de confiance complete :
// 1. MCUboot (updatable) verifie la signature du firmware au boot
// 2. TrustZone-M + MPU isolent les zones critiques
// 3. SE050C2 garde les cles hors de la flash attaquable
// 4. L'OTA telecharge un firmware signe ; refuse sinon

Verificación esperada

Tras el procedimiento del tutorial updating-the-bootloader, el bootloader está actualizado y es actualizable; con el secure boot activado, un firmware no firmado se niega a arrancar — prueba flasheando intencionadamente un binario no firmado para ver cómo la tarjeta lo rechaza (y luego vuelve a flashear un binario firmado). La OTA firmada (tutorial over-the-air-update) aplica el mismo control de forma remota: una imagen falsificada en tránsito nunca se instala.

Errores frecuentes

• Perder la clave privada de firma: sin ella, ningún firmware firmado arranca en las tarjetas desplegadas — guarda una copia cifrada fuera del repositorio y documenta el ritual de generación.
• Activar el secure boot en producción sin un banco de pruebas: si el procedimiento de activación falla a mitad de camino, la tarjeta puede rechazar cualquier firmware; realiza la secuencia completa primero en una tarjeta de demostración.
• Confundir «bootloader presente» con «secure boot activo»: MCUboot está presente por defecto (doble pulsación de RESET para acceder, «Burn bootloader» para restaurarlo), pero la verificación de firma se activa mediante el procedimiento dedicado del tutorial oficial.
• Almacenar secretos de API en el código o en la flash: es exactamente lo que el SE050C2 evita — las claves deben estar en el elemento seguro, no en el binario.
• Creer que la OTA es mágica: el canal (Wi-Fi/Ethernet) puede ser lento o cortarse durante la transferencia — mantén un slot de fallback (MCUboot conserva la imagen anterior) y nunca cortes la alimentación durante el intercambio de imágenes.
• >