Secure Boot & Root of Trust¶

Ancrer la confiance dans le silicium pour garantir qu'aucun code non autorisé ne s'exécute, même après un accès physique au device.

Le principe de la chaîne de confiance¶

Le secure boot repose sur une vérité fondamentale : chaque maillon d'une chaîne logicielle ne peut être vérifié que par quelque chose de plus fiable que lui. Cette hiérarchie doit commencer par un élément immuable — le Root of Trust (RoT) — qui ne peut pas être modifié même par un attaquant avec un accès physique.

Un système correctement conçu ne démarre que si chaque étape valide cryptographiquement la suivante. Un firmware modifié, même d'un seul octet, produit un hash différent et le boot est refusé.

Les composants matériels du Root of Trust¶

ROM de boot immutable¶

Le tout premier code exécuté au démarrage est stocké dans une ROM (Read-Only Memory) programmée lors de la fabrication du SoC. Elle ne peut pas être modifiée après production — c'est l'ancre immuable de la chaîne. Elle contient :

• Le vérificateur de signature du premier bootloader
• La clé publique OEM (ou son hash) fusée dans l'OTP
• La logique de démarrage d'urgence

OTP (One-Time Programmable) fuses¶

Les registres OTP permettent de stocker de façon permanente et irréversible des données critiques : hash de la clé publique OEM, configuration de sécurité (JTAG lock, debug disable, boot source). Une fois programmées, ces fuses ne peuvent plus être modifiées.

Secure Element (SE)¶

Un secure element est un microcontrôleur dédié à la cryptographie, physiquement séparé du MCU principal, conçu pour résister aux attaques physiques (tamper resistance certifiée CC EAL5+). Exemples industriels :

Le secure element stocke les clés privées dans une zone physiquement protégée. Même avec un accès JTAG complet au MCU principal, les clés ne peuvent pas être extraites — les opérations crypto se font à l'intérieur du SE.

TPM (Trusted Platform Module)¶

Le TPM 2.0 (norme ISO/IEC 11889) est le standard industriel pour les PC et serveurs, de plus en plus utilisé dans les gateways IoT et équipements edge. Il offre :

• Stockage de clés hiérarchique (SRK → AIK → clés applicatives)
• PCR (Platform Configuration Registers) pour mesurer l'état du système au boot
• Attestation d'intégrité à distance
• Générateur de nombres aléatoires certifié (DRBG)
• Scellement de secrets conditionnel à l'état du système (sealing/unsealing)

La chaîne de boot sécurisé¶

flowchart TD
    ROM["ROM Boot Code\n(immutable, OEM)"]
    OTP["OTP Fuses\nHash clé pub OEM\nJTAG locked\nBoot config"]
    SE["Secure Element\nATECC608 / OPTIGA\nClé privée device\nCertificat X.509"]

    BL0["Stage 0 Bootloader\ndans ROM\nVérifie BL1 signature"]
    BL1["Stage 1 Bootloader\n(ex: TF-A / SPL)\nVérifie BL2 signature\nInit sécurité hardware"]
    BL2["Stage 2 Bootloader\n(ex: U-Boot)\nVérifie kernel signature\nInit mémoire, stockage"]
    KERN["Kernel Linux / RTOS\nVérifie signature modules\nSecure storage mount"]
    APP["Application firmware\nVérifie intégrité config\nConnect broker mTLS via SE"]

    ROM -->|"lit clé pub depuis OTP"| OTP
    ROM -->|"valide signature"| BL0
    BL0 --> BL1
    BL1 -->|"ECDSA P-256 verify"| BL2
    BL2 -->|"ECDSA P-256 verify"| KERN
    KERN -->|"module signing"| APP
    APP -->|"clé privée"| SE

    style ROM fill:#1a237e,color:#fff
    style OTP fill:#283593,color:#fff
    style SE fill:#1565c0,color:#fff
    style BL0 fill:#e8eaf6
    style BL1 fill:#c5cae9
    style BL2 fill:#9fa8da
    style KERN fill:#7986cb
    style APP fill:#5c6bc0,color:#fff

Anti-tampering matériel¶

La détection d'ouverture physique (tamper detection) est un mécanisme de sécurité critique pour les devices déployés en environnements non contrôlés.

Mécanismes de détection¶

Contacteurs mécaniques. Interrupteurs qui détectent l'ouverture du boîtier. Simple et fiable, mais contournable par un attaquant préparé.

Enveloppes conductrices. Un réseau de pistes conductrices enveloppant le PCB (mesh actif) détecte toute tentative de perçage ou découpe. Toute rupture déclenche l'effacement des secrets.

Capteurs environnementaux. Température hors plage, pression anormale, tension d'alimentation anormale (indicateurs de glitching) déclenchent une réponse de sécurité.

Détection lumineuse. Capteur de lumière dans un boîtier opaque — l'ouverture déclenche l'effacement immédiat de la SRAM sécurisée.

Réponses à une détection de tampering¶

Hardware Security Module (HSM)¶

Le HSM est l'équivalent côté serveur du secure element côté device. Il protège les clés maîtresses de l'infrastructure PKI IoT — les clés qui signent les certificats de chaque device produit.

HSM en production IoT¶

En production industrielle, le HSM signe les firmwares, génère les certificats device, et protège la CA racine de la PKI IoT. Sa compromission serait catastrophique — il fait l'objet de procédures opérationnelles strictes (M-of-N, cérémonies de clé).

Lockdown des interfaces de débogage¶

Les interfaces JTAG/SWD doivent être désactivées sur les devices de production. Les mécanismes varient selon le SoC :

Sur STM32, le RDP Level 2 verrouille définitivement le debug et efface la flash si une tentative de debug est détectée — un device en RDP2 ne peut plus être débogué ni reprogrammé par JTAG.

Implémentations de référence¶

ARM TrustZone. Architecture matérielle divisant le SoC en monde sécurisé (Secure World) et monde non sécurisé (Normal World). Le monde sécurisé exécute le Trusted Execution Environment (TEE), les opérations crypto, la gestion des clés. Le monde normal exécute le système d'exploitation principal.

OP-TEE. Implémentation open source du TEE pour ARM TrustZone, utilisée sur Raspberry Pi, i.MX, STM32MP1. Fournit un environnement d'exécution isolé pour les applications de confiance (Trusted Applications — TA).

MCUboot. Bootloader sécurisé open source pour MCU Cortex-M (Zephyr, Apache Mynewt). Supporte la vérification ECDSA P-256/RSA-2048, le rollback, les mises à jour A/B.

Ce qu'il faut retenir¶

• Le Root of Trust doit être ancré dans du matériel immutable — ROM + OTP + secure element — pas dans du logiciel.
• La chaîne de confiance est aussi solide que son maillon le plus faible : un seul stage non vérifié compromet tout le reste.
• Les interfaces de debug (JTAG, SWD, UART) doivent être verrouillées de façon irréversible avant la mise en production.
• Le tamper detection physique est indispensable pour tout device déployé dans un environnement non contrôlé.

Chapitre suivant : Firmware signé & OTA sécurisé — comment signer les mises à jour et les vérifier à l'embarquement pour garantir l'intégrité du code en production.