Étude — Démarrage vérifié sur Raspberry Pi : ce qui existe, ce que ça coûte, ce que ça ne protège pas

Statut : note de travail. Les §1 à §6 relèvent l’état de l’art et ne font autorité sur rien. Le §7 consigne des décisions BDFL prises le 2026-08-02 sur la base de cette étude ; elles ont vocation à être reprises dans un ADR (ADR-014, « Catalogue de matériel Air long-term »), qui seul fera autorité.

Pourquoi. Le modèle de mise à jour système envisagé pour Air — image A/B montée en lecture seule et protégée par dm-verity, chargeur de démarrage qui vérifie la signature d’un emplacement avant de le démarrer — repose entièrement sur l’existence d’une racine de confiance. Sur x86_64, UEFI Secure Boot la fournit. Sur Raspberry Pi 4, qui est une plateforme de validation continue du projet (ADR-014, « Catalogue de matériel Air long-term »), la question était ouverte. Cette note l’instruit.

Fraîcheur des sources. Les faits ci-dessous proviennent de la documentation officielle Raspberry Pi (dépôt raspberrypi/usbboot), consultée le 2026-08-02. Ce domaine a évolué entre Pi 4, CM4 et Pi 5 ; toute décision d’architecture doit être re-vérifiée à sa date contre la documentation courante. Les sources sont listées en fin de note.

1. Le principe : une racine de confiance doit être immuable

Du logiciel qui vérifie du logiciel ne fait que déplacer la question. La chaîne doit se terminer dans quelque chose qu’un attaquant ne peut pas remplacer — typiquement une ROM de masque et des fusibles à écriture unique.

Corollaire pratique, et il compte. Il existe un portage UEFI (EDK2) pour Raspberry Pi 4, qui offre un environnement UEFI complet, Secure Boot compris. Il ne résout rien par lui-même : ce firmware est chargé depuis la carte SD par la chaîne de démarrage native du Pi. Si cette chaîne ne vérifie rien, on remplace le firmware UEFI, et son Secure Boot avec. Le même raisonnement vaut pour un GRUB aarch64, un U-Boot signé, ou tout autre chargeur : sans ancrage matériel du premier maillon, l’ensemble est décoratif.

2. La chaîne de démarrage réelle du Pi

Elle diffère profondément de celle d’un PC :

1. ROM de démarrage gravée dans le SoC (BCM2711 sur Pi 4, BCM2712 sur Pi 5) — immuable. C’est la seule racine de confiance possible.
2. Elle charge le bootloader de second étage depuis une EEPROM SPI, et non depuis la carte SD. C’est un changement majeur par rapport aux Pi 3 et antérieurs, et c’est ce qui rend un démarrage vérifié envisageable : le premier étage programmable n’est plus sur le support amovible.
3. Le bootloader charge ensuite le firmware et le noyau depuis le support de démarrage.

3. Ce que le mécanisme officiel fait

Raspberry Pi fournit un démarrage vérifié, documenté dans raspberrypi/usbboot, pour Pi 4 (BCM2711) et Pi 5 (BCM2712).

• Cryptographie : RSA 2048 bits. Une paire de clés asymétrique fournie par l’intégrateur. Pas de choix d’algorithme, pas de courbe elliptique.
• L’unité vérifiée est boot.img — « une image FAT autonome en ramdisk contenant le firmware GPU, le noyau et toutes ses dépendances ». Elle doit contenir au minimum config.txt, le noyau et l’arbre de périphériques, plus éventuellement un initramfs et des overlays. Le bootloader vérifie ainsi que tout ce qui est chargé en mémoire correspond à la signature.
• La configuration de l’EEPROM est elle aussi signée.
• L’ancrage : l’empreinte de la clé publique de l’intégrateur est programmée dans les fusibles OTP du SoC. Le bootloader charge la clé publique depuis l’EEPROM et la compare à cette empreinte.
• Verrouillage optionnel du JTAG : program_jtag_lock=1 désactive définitivement le JTAG VideoCore. Sans effet si le démarrage vérifié n’est pas déjà actif.
• Anti-retour-arrière du chargeur : une fois activé, il devient impossible de revenir à un bootloader antérieur ne gérant pas le démarrage vérifié.

4. Les limites documentées — le cœur de la note

Cinq limites, toutes explicitement énoncées par la documentation officielle. Trois d’entre elles sont structurantes pour Air.

4.1 L’activation est irréversible, et la clé n’est ni rotative ni révocable

« Once secure-boot has been enabled by programming the one-time programmable (OTP) fuses, it cannot be disabled and a different key cannot be programmed. »

C’est la limite la plus lourde. Programmer les fusibles est définitif : on ne peut ni désactiver le mécanisme, ni changer de clé. La documentation ne décrit aucun mécanisme de rotation ni de révocation. Une clé compromise signifie donc un parc de machines définitivement liées à une clé compromise, sans chemin de retour.

Pour un projet qui promet dix ans de stabilité contractuelle, c’est un point à peser gravement : la durée de vie d’une clé RSA 2048 utilisée en production, sur dix ans, avec zéro possibilité de rotation, n’est pas une hypothèse confortable.

4.2 L’OTP est lisible par le système d’exploitation

« Within the secure-boot OS image this key is accessible to any process with access to /dev/vcio (vcmailbox). »

« It is not possible to prevent code running in ARM supervisor mode (e.g. kernel code) from accessing OTP hardware directly. »

Autrement dit : l’OTP n’est pas un coffre. Pour l’empreinte de clé publique, ce n’est pas un problème — elle est publique par nature. Mais cela signifie qu’on ne peut pas utiliser l’OTP du Pi comme dépôt de secret : tout ce qui y est stocké est lisible par le noyau, donc par n’importe quel code s’exécutant en mode superviseur. Ça exclut d’y ancrer une clé de déchiffrement.

4.3 Aucun chiffrement de disque, et la partition de démarrage reste en clair

« There is no support in the ROM or firmware for full-disk encryption. »

« Secure-boot is responsible for loading the Kernel + initramfs and loads all of the data from a single boot.img file stored on an unencrypted FAT/EFI partition. »

La documentation renvoie vers des conteneurs LUKS montés par des scripts d’initramfs. Le démarrage vérifié garantit donc l’intégrité de ce qui démarre, jamais la confidentialité de ce qui est sur le disque. Ce sont deux propriétés distinctes, et seule la première est offerte.

4.4 Pi 5 : plus contraignant que Pi 4 — et c’est décisif en pratique

Différence majeure, et elle porte sur la phase de développement, pas sur le produit fini :

• sur Pi 4B et CM4, il est possible de tester la chaîne de démarrage vérifié sans programmer l’OTP — donc de tout mettre au point, de se tromper, de recommencer ;
• sur Pi 5, ce n’est pas possible. Le BCM2712 exige que la clé publique soit dans l’OTP avant de pouvoir démarrer une image signée. Sans cette étape, « the EEPROM firmware will not run and there will be no output on the debug header. The device will not boot. »

De plus, le Pi 5 impose un modèle de contre-signature : le firmware de second étage (recovery.bin / bootcode5.bin) doit être contre-signé par la clé de l’intégrateur, en plus de la signature Raspberry Pi.

Conséquence directe pour Air : le développement de la chaîne doit se faire sur Pi 4 ou CM4. Sur Pi 5, la première tentative est aussi la dernière.

4.5 La clé privée ne doit pas se trouver dans l’image

La documentation insiste : la clé privée « should not be installed in the target OS image » et doit être « stored securely and backed up ». Cela impose une infrastructure de signature hors machine — ce qui rejoint ce qu’Air construit déjà avec air-keystore et ses magasins typés par rôle.

5. TPM et élément sécurisé : une distinction à ne pas manquer

Il existe des modules TPM 2.0 se raccordant au connecteur SPI du Pi. Utiles, mais pas pour ce problème :

Un TPM n’empêche donc pas de démarrer une image corrompue. Ce qu’il apporte réellement est le scellement de secrets sur les mesures : une clé de déchiffrement scellée aux valeurs attendues ne peut pas être descellée sur une machine dont la chaîne a été altérée. La machine démarre, mais ne déchiffre rien.

C’est précisément le complément de la limite 4.3 — le démarrage vérifié n’offre pas la confidentialité, un TPM peut la fournir. Sur un Pi dont l’OTP n’est pas programmé, c’est probablement le meilleur rapport bénéfice sur complexité.

6. Ce que ça implique pour Air

6.1 Une hiérarchie de confiance matérielle explicite

Plutôt que de prétendre à une garantie uniforme, nommer les niveaux — l’endroit naturel étant ADR-014 (« Catalogue de matériel Air long-term ») :

Un utilisateur installant Air sur un Pi non provisionné doit savoir que sa machine ne résiste pas à un accès physique. Le dire vaut mieux que de le laisser supposer.

6.2 dm-verity garde une valeur réelle même sans ancrage matériel

C’est le point à ne pas perdre de vue. Sans démarrage vérifié, on perd la protection contre un attaquant qui remplace tout le support de démarrage. On conserve la protection contre la modification du système de fichiers racine par tout ce qui ne remplace pas aussi le noyau et sa ligne de commande — donc contre un gestionnaire de paquets compromis, contre une application ayant obtenu l’écriture, contre une altération en ligne.

Or c’est exactement la menace visée par la séparation « gestionnaire de paquets contre mise à jour système » : un attaquant corrompt des applications, jamais le système. Cette propriété tient même sur un Pi non provisionné. L’ancrage OTP ajoute la résistance à l’accès physique, qui est une menace différente et à qualifier séparément.

6.3 Le format boot.img contraint la conception A/B

Le mécanisme Pi vérifie une image de démarrage FAT autonome contenant firmware, noyau, arbre de périphériques et initramfs. Le schéma A/B doit donc s’articuler ainsi : deux boot.img signés, chacun portant en ligne de commande la racine dm-verity de son emplacement système. La bascule A/B se joue sur le choix du boot.img. C’est cohérent avec le modèle, mais ça impose que la racine verity soit à l’intérieur de la zone signée — sinon on signe un noyau qui montera n’importe quelle racine.

7. Questions tranchées (BDFL, 2026-08-02)

1. Le Pi est-il plateforme de développement ou cible de production ? Les deux, sans garantie de sécurité. C’est d’abord la cible de validation aarch64 du projet. C’est aussi une cible sur laquelle un utilisateur final peut choisir d’installer Air pour essayer — mais le projet ne lui garantit alors aucune protection contre du code malveillant ayant un accès physique au support. L’utilisateur est informé deux fois : au téléchargement de l’image, et à l’installation. Après quoi c’est son choix.
2. Clé RSA 2048 non rotative sur dix ans ? Non.
3. L’accès physique est-il dans le modèle de menace du Pi ? Non.
4. Chiffrement de disque sur Pi ? Non.
5. Développement de la chaîne sur Pi 4 / CM4 ? Oui.

Conséquence directe : le démarrage vérifié du Pi sort du périmètre

Les réponses 2, 3 et 4 étant négatives, Air ne programmera jamais les fusibles OTP. Tout ce que décrivent les §3 et §4 de cette note devient documentaire : pas d’outillage OTP, pas de provisionnement par carte, pas d’infrastructure de signature d’images de démarrage Pi, pas de contre-signature Pi 5. C’est un chantier entier retiré du plan, et c’est la principale valeur pratique de cette étude.

Le §4.4 (impossibilité de tester sans OTP sur Pi 5) devient sans objet pour Air, puisque nous ne provisionnons pas. La réponse 5 garde cependant son sens si le projet devait revenir sur ce choix.

Ce que l’avertissement doit dire — et ne pas dire

« Aucune garantie de sécurité » serait à la fois inexact et contre-productif : un avertissement imprécis est ignoré, ou surinterprété. Sur un Pi non provisionné, l’essentiel du modèle de sécurité d’Air continue de fonctionner, parce qu’il repose sur le noyau et non sur la chaîne de démarrage :

La formulation juste est donc étroite et actionnable : Air protège votre machine contre les logiciels malveillants qui s’y exécutent. Sur Raspberry Pi, il ne peut pas vous protéger contre quelqu’un qui a un accès physique à la carte SD, ni chiffrer vos données.

Le point dur qui en découle : la partition de démarrage

Sur Pi, la partition de démarrage est une FAT en clair, non vérifiée (§4.3). Or c’est elle qui porte le noyau et sa ligne de commande — donc la racine dm-verity. Quiconque peut y écrire choisit la racine, et défait dm-verity sans avoir à toucher au système.

Ça a une conséquence directe sur la séparation « gestionnaire de paquets contre mise à jour système » : le gestionnaire de paquets ne doit en aucun cas pouvoir écrire dans la partition de démarrage. Elle n’est pas un système de fichiers ordinaire, elle fait partie du système. Non montée en fonctionnement normal, ou montée en lecture seule, ou interdite par Landlock au gestionnaire de paquets — le mécanisme reste à choisir, mais l’exigence est ferme, sans quoi la propriété « un attaquant corrompt des applications, jamais le système » tombe sur cette plateforme.

Sources

Documentation officielle Raspberry Pi, dépôt raspberrypi/usbboot, consultée le 2026-08-02 :

• docs/secure-boot.md — vue d’ensemble, limites, accès OTP, absence de chiffrement de disque
• secure-boot-recovery/README.md — procédure Pi 4 / CM4, irréversibilité, program_pubkey, program_jtag_lock
• secure-boot-recovery5/README.md — spécificités Pi 5 (BCM2712), contre-signature, impossibilité de tester sans OTP

Licence du document : MPL 2.0 Statut : note de travail, sans autorité.