Si vous expediez un module Bluetooth avec un firmware non signe, vous avez implicitement fait confiance a quiconque peut le flasher. Un concurrent clone votre produit, un attaquant installe une porte derriere, ou une OTA defectueuse brique le parc — et vous ne pouvez pas distinguer votre image de la sienne au demarrage. Le secure boot comble cette breche : le materiel verifie cryptographiquement une signature avant d’autoriser l’execution de tout code. Cet article traite du cote ingenierie — racine de confiance, chaine de signatures, provisioning des cles, anti-rollback, OTA securise, verrouillage du debug et les compromis accepts.
Pourquoi le secure boot existe
Les menaces sont concretes :
- Clonage. Une image non signee se lit sur une unite et se flash sur mille contrefacons.
- OTA malveillante. Si le canal de mise a jour n’est pas authentifie, celui qui l’atteint possede l’appareil.
- Sabotage de la chaine d’approvisionnement. Un serveur de compilation ou un sous-traitant compromis livre du code que vous n’avez jamais ecrit.
- Implant persistant. Un implant au niveau bootloader survit aux mises a jour applicatives car le verificateur d’app tourne *sous* lui.
Sans secure boot, la seule limite est “l’attaquant peut-il flasher physiquement ou atteindre le port ?”. Avec lui, la limite devient “l’attaquant detient-il la cle privee de signature ?”.
Racine de confiance
Tout repose sur un bootloader ROM immuable grave dans le silicium a l’usine. Il contient la logique de verification du fabricant et un emplacement a usage unique (OTP / eFuse) conservant le *hash de votre cle publique* — jamais la cle privee.
- La cle privee vit uniquement sur un serveur de signature offline et ne touche jamais l’appareil.
- La chaine de confiance va ROM -> bootloader -> application. Chaque etape verifie la signature de la suivante avant de ceder le controle.
Une disposition standard :
ROM (fixe) --verifie--> Bootloader (signe) --verifie--> Application (signee)Le schema de signature
Le mecanisme est la signature asymetrique :
1. L’image est hashee (SHA-256) et le hash est signe offline avec votre cle privee ECDSA P-256 (ou Ed25519).
2. Le bootloader, a l’allumage, recalcule le hash et verifie la signature contre la cle publique de confiance.
3. Il ne saute vers l’image que si la verification reussit.
Stocker la cle publique complete dans l’eFuse gaspille des bits rares, la plupart des designs stockent donc un SHA-256 de la cle publique. Le bootloader verifie d’abord que la cle de l’image correspond au digest eFuse, puis verifie la signature avec cette cle.
Une verification minimale :
def verify_image(img, pk_digest, sig):
if sha256(img.public_key) != pk_digest:
return FAIL # mauvaise cle
if not ecdsa_verify(img.public_key, sig, sha256(img.code)):
return FAIL # signature invalide
return OKAnti-rollback
Une image signee ne suffit pas si un attaquant peut flasher une image signee *ancienne et vulnérable* que vous avez livree l’an dernier. La solution est un compteur de version monothone dans l’eFuse :
- L’image porte un numero de version ; l’appareil memorise la version la plus haute executee.
- Le demarrage refuse une image dont la version est inferieure au compteur stocke.
- Les bits eFuse sont a sens unique, donc le plan de compteur doit etre fige avant production — on ne peut pas “en ajouter” plus tard.
OTA securisee
La meme signature qui protege l’image d’usine doit proteger les mises a jour. Le flux :
1. La CI signe la nouvelle image avec la cle offline ; l’appareil la verifie au telechargement.
2. Utilisez une disposition double banque : ecrivez la mise a jour dans le slot B, verifiez puis basculez. Si la verification echoue, le slot A tourne toujours — pas de brick.
3. La cle de signature OTA doit correspondre a la cle eFuse, donc le canal de mise a jour est authentifie de bout en bout.
Verrouillage de l’interface de debug
Un module Bluetooth avec SWD/JTAG ouvert est un livre ouvert : lecture et re-flash complet du code. Le secure boot n’est aussi fort que le port de debug :
- Verrouillez l’interface de debug apres le provisioning.
- Prevoyez une reouverture controlee — typiquement “tout effacer pour debloquer” ou un defi-reponse — pour que les retours/RMA puissent etre effaces mais jamais lus.
- Comparaison d’implementations courantes :
| Controle | nRF Secure Boot (NSIB) | ESP32 Secure Boot v2 | SoC eFuse generique |
|---|---|---|---|
| Stockage cle | hash pubkey en eFuse | digest pubkey en eFuse | hash OTP |
| Signature | ECDSA P-256 | RSA-3072 / ECDSA | ECDSA |
| Anti-rollback | Compteur monothone | Version en eFuse | Manuel |
| Debug lock | verrou CTRL-AP | JTAG disable eFuse | SWD lock |
| OTA securisee | MCUBoot / SUIT | Native | Custom |
Materiel cryptographique sur le module
Les SoC BLE modernes embarquent les primitives necessaires : un TRNG, AES et accelerateurs ECDSA (nRF52/53, ESP32, DA1459x). Verifier une signature sur un Cortex-M4 prend des dizaines de millisecondes et tire des mA dans cette rafale — trivial face a un demarrage unique. Utilisez les bibliotheques bootloader du fabricant ; ne roulez pas votre propre crypto.
Compromis et modes de defaillance
Le secure boot n’est pas gratuit :
- Risque de brick. Perdez la cle privee et vous ne pouvez plus jamais signer — plus de mises a jour terrain. La custodie de la cle est le bien le plus important.
- Pas de retroceder. Une mauvaise nouvelle version ne s’evade pas en flashant l’ancienne (le compteur bloque). Vous devez pousser un build corrige *plus recent*.
- Rendement de provisioning. Les gravures eFuse sont a sens unique ; une erreur bricke l’unite sur la ligne. Validez l’unite dorée avant le burn de masse.
- Recuperation. Planifiez des le depart un chemin d’image de “recuperation” signee ; le retroadapter ensuite est dur.
Ce qu’un OEM doit faire
Si vous construisez un module Bluetooth qui sort de votre usine, le minimum :
1. Generez la paire de cles sur un HSM / serveur de signature offline. La cle privee ne va jamais sur un portable de dev ni sur un runner CI.
2. Gravez le hash de la cle publique dans l’eFuse dans une etape de provisioning protegee ; verifiez sur une unite dorée avant la production de masse.
3. Signez chaque artefact — bootloader, application, OTA — en CI avec la cle offline.
4. Activez l’anti-rollback et verrouillez le port de debug.
5. Conservez un chemin de recuperation (image de recuperation signee) et un plan de rotation / revocation des cles.
En conclusion
Le secure boot deplace la confiance de “qui peut flasher” vers “qui detient la cle”. Il est peu couteux a ajouter en conception et quasi impossible a retroadapter. Integrez-le, verrouillez le debugger et gardez la cle privee comme un joyau de la couronne — car pour un attaquant, votre signature de firmware est la seule chose entre lui et votre produit.
