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

Objectives

This is why we buy a Portenta for the workshop: the entire chain of trust is embedded. The MCUboot bootloader verifies the firmware signature before execution (secure boot), a dedicated NXP SE050C2 chip stores keys and certificates out of reach of the firmware, the SoC adds TrustZone-M, MPU, and hardware RNG, and OTA updates are signed. This tutorial maps out the chain and sets up the foundation: updating the bootloader, then implementing a signed deployment strategy. Sources: official tutorials updating-the-bootloader, secure-boot, and over-the-air-update on docs.arduino.cc.

Hardware

• 1 × Arduino Portenta H7 + USB-C data cable
• Recent "Arduino Mbed OS Portenta Boards" core (the MCUboot library is included)
• Private signing key off the board (build machine, never in the Git repository)
• Serial console at 115200 baud

Complete Code

// 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

Expected Verification

After following the procedure in the updating-the-bootloader tutorial, the bootloader is up to date and updatable; with secure boot enabled, an unsigned firmware refuses to start — test this by intentionally flashing an unsigned binary to see the board reject it (then revert by flashing a signed binary). Signed OTA (tutorial over-the-air-update) applies the same check remotely: a tampered image in transit is never installed.

Common Errors

• Losing the private signing key: without it, no signed firmware will start on deployed boards — keep an encrypted backup outside the repository, with a documented key generation ritual.
• Enabling secure boot in production without a test bench: if the activation procedure fails midway, the board may reject all firmware; perform the full sequence on a demo board first.
• Confusing "bootloader present" with "secure boot active": MCUboot is present by default (double-tap RESET to access it, "Burn bootloader" to restore it), but signature verification is enabled via the dedicated procedure in the official tutorial.
• Storing API secrets in code or flash: this is exactly what the SE050C2 prevents — keys belong in the secure element, not in the binary.
• Believing OTA is magic: the channel (Wi-Fi/Ethernet) can be slow or cut off during transfer — keep a fallback slot (MCUboot retains the previous image) and never cut power during the image swap.
• >