Secure boot et signature de firmware: la chaîne de confiance, maillon par maillon
« Notre firmware est signé. » La phrase rassure, et elle ne dit presque rien. Signé par quoi? Vérifié quand? Par quel code, avec quelle clé, stockée où? Et que se passe-t-il si la vérification échoue?
Un firmware signé que personne ne vérifie au démarrage n’apporte aucune garantie. C’est l’une des failles que nous faisons manipuler dans nos trainings, parce qu’elle est fréquente et qu’elle se comprend bien mieux en la contournant soi-même.
Trois mécanismes à ne pas confondre
La signature de mise à jour vérifie qu’un firmware reçu vient bien du fabricant avant de l’installer.
Le secure boot vérifie, à chaque démarrage, que le code sur le point de s’exécuter est authentique.
Le chiffrement de la mémoire empêche de lire le firmware stocké dans l’équipement.
Les deux premiers apportent l’authenticité. Le troisième apporte la confidentialité. Un produit peut avoir l’un sans les autres, et c’est souvent là que se trouve la faille. Un firmware chiffré mais non signé peut être remplacé. Un firmware signé mais non chiffré peut être lu.
La chaîne de confiance
Le principe du secure boot tient en une phrase: chaque étape du démarrage vérifie la suivante avant de lui passer la main.
- La racine de confiance. Un code de démarrage non modifiable, inscrit en usine dans le microcontrôleur, et une clé publique (ou son empreinte) gravée dans une zone programmable une seule fois.
- Le chargeur de démarrage. La racine vérifie sa signature avec cette clé. S’il est valide, il s’exécute.
- L’application. Le chargeur vérifie à son tour la signature du firmware applicatif.
- Le refus. Si une vérification échoue, le démarrage s’arrête ou bascule sur une image de secours valide.
La solidité de l’ensemble repose sur le premier maillon. Si la clé de référence peut être modifiée, ou si le premier code exécuté peut être remplacé, tout le reste est décoratif.
La signature repose sur de la cryptographie asymétrique. La clé privée signe chez le fabricant et ne quitte jamais son environnement de production. La clé publique, embarquée dans le produit, ne permet que de vérifier.
Les sept erreurs qui cassent la chaîne
1. Vérifier à la mise à jour, pas au démarrage
Le firmware est contrôlé quand il arrive par le réseau. Mais un attaquant qui a l’objet en main écrit directement dans la mémoire, par un port de debug ou avec un programmateur. Sans vérification au démarrage, sa version s’exécute.
2. Confondre somme de contrôle et signature
Un CRC ou une empreinte SHA-256 placés en fin d’image détectent une corruption accidentelle. Ils n’apportent aucune authenticité: celui qui modifie le firmware recalcule la valeur.
3. Utiliser un secret partagé
Authentifier le firmware par un code calculé avec une clé symétrique suppose que cette clé se trouve dans chaque équipement. Elle sera extraite, et permettra alors de produire des firmwares valides pour tout le parc. Voir Secrets dans le firmware: trois failles, une même cause.
4. Mal protéger la clé privée
Clé de signature dans le dépôt de code, sur le poste d’un développeur, dans une variable d’intégration continue lisible par toute l’équipe. Ou clé de test du fabricant du microcontrôleur laissée en production. La cryptographie est intacte, la confiance ne l’est plus.
5. Oublier le retour en arrière
Un ancien firmware est correctement signé, puisqu’il a été publié par le fabricant. S’il contient une vulnérabilité connue, l’attaquant le réinstalle puis l’exploite. La parade est un compteur de version qui ne peut qu’augmenter, stocké hors de portée du firmware.
6. Ne signer qu’une partie
L’application est vérifiée, mais pas le chargeur de démarrage, la table de partitions ou la zone de configuration. Modifier un paramètre non couvert (une adresse de serveur, un indicateur de mode debug) suffit souvent à obtenir le résultat recherché.
7. Laisser une porte à côté
Un port de debug resté ouvert, un mode de récupération sans authentification, une console série qui propose de charger une image. Le secure boot est respecté à la lettre, et contourné par le chemin d’à côté.
Et quand tout est bien fait?
Par honnêteté, il faut le dire: un secure boot correctement mis en œuvre n’est pas inviolable. Des travaux de recherche publics ont montré qu’une perturbation brève de l’alimentation, appliquée au bon instant, peut faire sauter l’instruction de vérification sur certains microcontrôleurs. Ces attaques par injection de fautes demandent du matériel, du temps et un accès physique prolongé.
La conclusion n’est pas que le secure boot est inutile. Il fait passer l’attaque de quelques minutes avec un adaptateur à quelques jours de laboratoire. Pour la plupart des produits, c’est exactement l’objectif. Pour les plus sensibles, il faut le compléter par des contre-mesures matérielles et par des clés uniques par équipement, de sorte qu’une unité compromise ne livre rien sur les autres.
Ce que proposent les plateformes
La mise en œuvre dépend du composant. Sur ESP32, le fabricant fournit un secure boot dont l’empreinte de clé est inscrite dans des eFuses, associé à un chiffrement de la flash. Sur STM32, selon les familles, on s’appuie sur la protection en lecture, sur un chargeur de démarrage protégé en écriture et sur les solutions de démarrage sécurisé fournies par le fabricant. Des projets libres comme MCUboot offrent un chargeur vérifiant la signature et gérant le retour en arrière sur de nombreuses architectures.
Dans tous les cas, ces mécanismes s’activent par des opérations irréversibles. Ils doivent être intégrés au processus de fabrication et testés sur chaque unité, pas ajoutés en fin de projet.
La liste de contrôle
- La signature est-elle vérifiée à chaque démarrage, et pas seulement à l’installation?
- La clé de référence est-elle stockée dans une zone non modifiable?
- Toutes les zones exécutables et de configuration sensible sont-elles couvertes?
- Un mécanisme empêche-t-il le retour à une version antérieure?
- La clé privée est-elle dans un module matériel dédié, avec un accès tracé?
- Que fait le produit si la vérification échoue?
- Les interfaces de debug et les modes de récupération sont-ils verrouillés?
- Existe-t-il une procédure de renouvellement de la clé en cas de compromission?
Le lien avec la réglementation
L’Annexe I du Cyber Resilience Act demande de protéger l’intégrité des programmes et de distribuer les mises à jour de façon sécurisée. La norme ETSI EN 303 645 consacre une exigence entière à l’intégrité du logiciel, et les normes EN 18031 évaluent le mécanisme de mise à jour sécurisée. L’IEC 62443-4-2 traite le sujet dans ses exigences d’intégrité du système.
Le pratiquer sur la carte DVID
Le parcours Sécurité IoT de DVID comprend un module de contournement de signature firmware. Les participants y découvrent un produit qui semble vérifier ses mises à jour, identifient ce qui manque dans la vérification, et font accepter un firmware modifié. Ils reconstruisent ensuite la chaîne correcte.
L’exercice change durablement la façon de lire la phrase « notre firmware est signé ».
Pour qui?
- développeurs firmware et architectes embarqués
- responsables d’industrialisation, pour la gestion des clés en production
- pentesters et auditeurs matériels
- responsables sécurité produit qui préparent la conformité CRA ou IEC 62443-4-2
Aller plus loin
Pour valider ces compétences, découvrir le parcours de certification DVID.
En savoir plus: https://dvid.eu/fr
Nous contacter: https://dvid.eu/fr#contact
Suivre notre actualité: https://www.linkedin.com/company/dvid/