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

Objectifs

C'est pour ça qu'on achète une Portenta en atelier : toute la chaîne de confiance est embarquée. Le bootloader MCUboot vérifie la signature du firmware avant exécution (secure boot), une puce dédiée NXP SE050C2 stocke clés et certificats hors de portée du firmware, le SoC ajoute TrustZone-M, MPU et RNG matériel, et les mises à jour OTA sont signées. Ce tuto cartographie la chaîne et met en place le socle : mise à jour du bootloader, puis stratégie de déploiement signée. Sources : tutos officiels updating-the-bootloader, secure-boot et over-the-air-update sur docs.arduino.cc.

Matériel

• 1 × Arduino Portenta H7 + câble USB-C data
• Core « Arduino Mbed OS Portenta Boards » récent (la bibliothèque MCUboot y est fournie)
• Clé privée de signature hors de la carte (poste de build, jamais dans le dépôt Git)
• Console série 115200 bauds

Code complet

// secure_boot_check.ino — squelette de principe
// > 
// interroger l'état de la vérification — suis pas a pas le tuto officiel
// docs.arduino.cc/tutorials/portenta-h7/secure-boot pour la procédure
// 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 vérifier 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 télécharge un firmware signe ; refuse sinon

Vérification attendue

Après la procédure du tuto updating-the-bootloader, le bootloader est à jour et updatable ; avec le secure boot activé, un firmware non signé refuse de démarrer — teste en flashant volontairement un binaire non signé pour voir la carte le rejeter (puis reviens en flashant un binaire signé). L'OTA signé (tuto over-the-air-update) applique le même contrôle à distance : une image falsifiée en transit n'est jamais installée.

Erreurs fréquentes

• Perdre la clé privée de signature : sans elle, plus aucun firmware signé ne démarre sur les cartes déployées — sauvegarde chiffrée hors dépôt, rituel de génération documenté.
• Activer le secure boot en production sans banc de test : si la procédure d'activation échoue à mi-chemin, la carte peut refuser tout firmware ; fais la séquence complète sur une carte de démo d'abord.
• Confondre « bootloader présent » et « secure boot actif » : MCUboot est là par défaut (double-tap RESET pour y accéder, « Burn bootloader » pour le restaurer), mais la vérification de signature s'active par la procédure dédiée du tuto officiel.
• Stocker les secrets d'API dans le code ou la flash : c'est exactement ce que le SE050C2 évite — clés dans l'élément sécurisé, pas dans le binaire.
• Croire l'OTA magique : le canal (Wi-Fi/Ethernet) peut être lent ou coupé en plein transfert — garde un slot de fallback (MCUboot garde l'image précédente) et ne coupe jamais l'alimentation pendant le swap d'images.
• >