Le démarrage sécurisé : la chaîne de confiance du calculateur
Un calculateur moderne ne se contente plus de vérifier que son logiciel est intact. Avant de le lancer, il vérifie qu'il est le bon. Ce mécanisme s'appelle le démarrage sécurisé — secure boot — et c'est lui qui explique qu'un fichier parfaitement cohérent puisse être refusé sans le moindre message.
La notion a été introduite dans signature RSA et calculateurs verrouillés. Cette fiche en détaille le déroulement, les variantes et les conséquences.
Le principe : une chaîne, pas un contrôle
L'idée centrale est celle de chaîne de confiance. Au lieu d'un contrôle unique, on enchaîne des vérifications où chaque maillon valide le suivant avant de lui passer la main.
Le premier maillon pose un problème logique : qui vérifie le vérificateur ? La réponse est la racine de confiance — root of trust. C'est un élément que l'on ne peut pas modifier :
- du code gravé dans le silicium à la fabrication, ou du code résidant dans le module de sécurité matériel ;
- des clés ou des empreintes de clés inscrites dans une mémoire à programmation unique, non effaçable, décrite dans les protections du microcontrôleur.
Cette racine est le postulat du système : on la considère fiable parce qu'elle est physiquement immuable.
Le déroulement typique
Sur une architecture à module de sécurité matériel, la séquence à la mise sous tension ressemble à ceci :
1. Le composant démarre le module de sécurité en premier, avant les cœurs applicatifs.
2. Le module calcule une empreinte cryptographique des zones mémoire à protéger : chargeur d'amorçage, logiciel applicatif, parfois une partie des données de calibration.
3. Il compare cette empreinte à une référence, ou vérifie une signature avec une clé publique qu'il détient.
4. Si tout concorde, il libère les cœurs principaux, qui exécutent le chargeur d'amorçage.
5. Le chargeur d'amorçage vérifie à son tour l'élément suivant avant de lui transférer le contrôle.
Chaque étape ne fait confiance qu'à ce qu'elle a elle-même vérifié. Un maillon qui ne passe pas arrête la chaîne à cet endroit précis.
Deux familles de démarrage sécurisé
Il faut distinguer deux comportements, car ils n'ont pas les mêmes conséquences en atelier.
- Le démarrage vérifié bloquant. La vérification est faite avant l'exécution. Si elle échoue, le logiciel concerné n'est pas lancé, point final.
- Le démarrage mesuré ou différé. Le système démarre, mais l'empreinte est calculée et enregistrée. Le résultat conditionne alors des fonctions ultérieures : accès à des services, à un réseau, à des fonctions de confort. Le véhicule fonctionne, en apparence normalement, mais un indicateur interne a changé.
Certaines architectures combinent les deux : blocage sur le noyau critique, mesure sur le reste.
Ce qui se passe quand la vérification échoue
Le comportement dépend du constructeur et de la fonction concernée. Les cas observés couvrent un spectre large :
- le calculateur ne quitte pas son mode de programmation : il reste en attente d'un logiciel valide, ce qui est précisément la conception voulue par un chargeur d'amorçage de production ;
- le moteur ne démarre pas, sans code défaut exploitable côté client ;
- le calculateur démarre en fonctionnement réduit, avec un couple limité ;
- une fonction annexe est refusée : mise à jour, connectivité, appairage.
Un bon chargeur d'amorçage de production ne s'efface jamais lui-même et valide l'application à chaque démarrage : c'est ce qui fait qu'un échec de vérification ne détruit pas le calculateur. Voir bootloader et BSL.
Pourquoi ce n'est pas un checksum
C'est la confusion la plus fréquente, et elle coûte cher en temps.
| Somme de contrôle | Démarrage sécurisé | |
|---|---|---|
| Question posée | le contenu est-il intact ? | ce contenu vient-il bien du constructeur ? |
| Calcul | public, reproductible par n'importe qui | exige un secret détenu par le constructeur |
| Moment | à l'écriture, puis en fonctionnement | avant l'exécution du programme |
| Élément qui vérifie | le programme lui-même | un composant indépendant du programme |
| En cas d'échec | défaut, mode dégradé, refus de démarrage | le programme n'est pas lancé du tout |
Une somme de contrôle se recalcule. Une signature se possède ou ne se possède pas. Ce n'est pas une différence de difficulté, c'est une différence de nature. Voir qu'est-ce qu'un checksum.
Ce qu'un reprogrammateur en retient
- Un fichier cohérent n'est pas un fichier autorisé. Sur une plateforme à démarrage sécurisé, la cohérence interne ne suffit pas.
- Le diagnostic d'un refus change. Chercher une erreur de somme de contrôle sur un calculateur qui refuse par authentification est une perte de temps.
- La vérification est répétée à chaque mise sous tension. Il n'existe pas d'état « validé une fois pour toutes ».
- La chaîne s'étend au véhicule. Sur les architectures récentes, le calculateur moteur n'est qu'un maillon : la passerelle, le calculateur de domaine et l'unité télématique participent au même contrôle. Voir la passerelle et le filtrage des trames.
- On ne cherche pas à faire échouer une vérification. Un mécanisme de démarrage sécurisé est un dispositif de sécurité ; il se respecte. L'accès légitime passe par le constructeur ou par un prestataire habilité.
Voir aussi le HSM, signature RSA et secure boot et bootloader et BSL.
Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.
