Démarrage sécurisé + TPM : Ce qu’ils protègent (et ce qu’ils ne protègent pas)

Commencez par le modèle de menace, pas par la case à cocher

Secure Boot et le TPM sont souvent vendus comme de la « sécurité au démarrage ». C’est comme vendre des « ceintures de sécurité ». Les ceintures sont excellentes — contre des problèmes spécifiques. Elles ne servent à rien contre d’autres. Votre travail consiste à choisir les bonnes protections pour le crash que vous êtes réellement susceptible d’avoir.

À quoi sert Secure Boot (en une phrase)

Secure Boot concerne l’application : seuls les composants de démarrage de confiance (firmware → bootloader → noyau) sont autorisés à s’exécuter, sur la base de la vérification des signatures.

À quoi sert le TPM (en une phrase)

Le TPM concerne les secrets et les preuves : il peut protéger des clés et enregistrer des mesures du processus de démarrage (PCR) afin que vous puissiez lier l’accès à des états « connus bons » ou prouver ce qui s’est passé.

Menaces réalistes au démarrage que vous pouvez effectivement atténuer

• Attaques de type « evil maid » : quelqu’un a un accès physique à un laptop ou serveur éteint et manipule la chaîne de démarrage ou s’empare des clés de disque.
• Persistance par bootkit : un malware s’installe sous le système (bootloader, noyau précoce, initramfs) de sorte qu’une réimagerie « depuis l’OS » ne le nettoiera pas.
• Dérive de la chaîne d’approvisionnement / image maîtresse : un nœud démarre autre chose que ce que vous avez construit, et vous voulez un moyen cryptographique de le détecter.
• Vol de justificatifs via accès disque hors ligne : l’attaquant vole un disque ou une machine entière et tente de le lire ailleurs.

Menaces que ces fonctionnalités ne résoudront pas seules

• RCE distante dans votre appli une fois que l’OS est en marche.
• Exploit du noyau après le démarrage qui ne nécessite pas de remplacer la chaîne de démarrage.
• Mauvais initiés avec accès admin qui peuvent signer leur propre malware si vous leur donnez les clés de signature.
• Firmware vulnérable qui ment volontiers sur ce qu’il a vérifié.

Une citation à afficher sur votre mur, car elle évite les projets absurdes :

Idée paraphrasée (Gene Kim) : « Améliorer la fiabilité, c’est améliorer le système de travail, pas faire du héroïsme pendant les incidents. »

Secure Boot et le TPM améliorent le système de travail quand vous les opérationnalisez : gestion des clés, flux de mise à jour, vérifications d’attestation, et procédures de bris-glace. Si votre plan est « l’activer et espérer », ce n’est pas un plan. C’est un futur rapport d’incident.

Secure Boot : ce qu’il applique

UEFI Secure Boot est une application de signatures au niveau du firmware. Le firmware n’exécutera que des binaires EFI signés par une clé qu’il estime fiable. C’est le cœur. Tout le reste — shim, MOK, outils de distribution — est de la plomberie pour que cela fonctionne en pratique.

La chaîne de confiance, concrètement

Une chaîne Linux typique sur du matériel grand public ressemble à ceci :

• Firmware UEFI contient des clés de confiance et la logique de vérification.
• shim est un petit bootloader signé généralement par une clé largement reconnue et peut charger des clés supplémentaires.
• GRUB/systemd-boot est chargé par shim et peut lui-même vérifier le noyau et l’initramfs.
• Noyau charge des modules ; l’application de signatures de modules est un contrôle séparé.
• initramfs initialise le stockage et monte la racine ; si cela n’est pas fiable, vous pouvez tout perdre avant que votre « vrai » OS démarre.

La valeur de Secure Boot est simple : il empêche un composant EFI non signé (ou mal signé) de s’exécuter. Cela bloque une classe de bootkits et de tentatives de manipulation. Mais ça peut aussi vous bloquer à 2h du matin si votre flux de signature est négligent.

Clés que vous rencontrerez (et que vous devriez respecter)

• PK (Platform Key) : clé de plus haut niveau contrôlant la configuration de Secure Boot.
• KEK (Key Exchange Key) : autorise les mises à jour des bases de signatures.
• db : signatures/hashes autorisés.
• dbx : signatures/hashes révoqués (la « liste non »).
• MOK (Machine Owner Key) : liste gérée par shim couramment utilisée pour autoriser des noyaux/modules personnalisés sans remplacer les clés de plateforme.

Si vous ne retenez qu’une règle opérationnelle : traitez les clés de signature comme des identifiants de base de données de production. Si votre clé de signature fuit, « Secure Boot activé » devient « Secure Boot permet la persistance des attaquants. »

Blague #1 : Secure Boot, c’est comme un videur avec un cahier — très efficace jusqu’à ce que vous distribuiez des bracelets photocopiés sur le parking.

TPM : ce qu’il mesure, stocke et refuse d’oublier

Le TPM (Trusted Platform Module) est un composant résistant à la falsification (puce ou firmware sécurisé) conçu pour faire quelques choses extrêmement bien : protéger des clés, produire des preuves cryptographiques et enregistrer des mesures du démarrage précoce dans des PCR (Platform Configuration Registers).

Notions de base TPM 2.0 utiles en exploitation

• PCR : registres spéciaux qui enregistrent une chaîne de hachage de mesures. On ne « définit » pas les PCR ; on les étend, ce qui signifie PCR = HASH(PCR || nouvelle_mesure). Cela rend l’historique collant.
• Sealing : chiffrer (envelopper) un secret pour que le TPM ne le libère que si la machine est dans un état spécifique (souvent défini par les valeurs PCR).
• Attestation : produire une déclaration signée sur les valeurs PCR (et parfois le journal d’événements), afin qu’une partie distante puisse vérifier l’état du démarrage.
• Clés d’endossement et d’identité : clés qui permettent à un TPM de prouver qu’il est un vrai TPM, puis de s’exprimer comme une machine particulière.

Le piège du « déverrouillage automatique TPM »

Utiliser le TPM pour déverrouiller automatiquement LUKS/BitLocker est courant. C’est aussi la source de nombreuses déconvenues, car les gens confondent confort et sécurité.

Si vous scellez une clé de disque sur des PCR qui mesurent le bootloader et le noyau, vous forcez l’attaquant à conserver ces composants intacts pour obtenir la clé. Si vous la scellez sur un ensemble de PCR faible — ou pire, si vous n’utilisez pas d’association PCR du tout — vous stockez peut‑être simplement la clé dans une boîte chic qui s’ouvre quand elle en a envie.

Le TPM n’est pas une « enclave sécurisée pour tout »

Le TPM est efficace pour de petits secrets et des preuves. Ce n’est pas un accélérateur crypto haut-débit pour votre base de données. Ce n’est pas non plus un substitut au patchage du firmware, au contrôle des accès admins, ou à des processus d’intégrité dans la chaîne d’approvisionnement.

Blague #2 : Un TPM est un coffre‑fort, pas une nounou ; il ne vous empêchera pas d’oublier la porte de la salle serveurs ouverte.

Secure Boot vs Measured Boot : application vs preuve

Ces deux notions sont souvent confondues car elles parlent toutes deux d’intégrité de démarrage. Ce sont des outils différents avec des modes de défaillance différents.

Secure Boot (application)

• Question qu’il répond : « Ce binaire doit‑il être autorisé à s’exécuter ? »
• Mécanisme : vérification de signatures contre les clés autorisées (db) et les révocations (dbx).
• Mode de défaillance : vous ne démarrez pas.
• Douleur opérationnelle : flux de signature, rotation de clés, révocations, pilotes tiers.

Measured Boot (preuve)

• Question qu’il répond : « Qu’est‑ce qui s’est exécuté ? »
• Mécanisme : mesures étendues dans les PCR + journal d’événements ; attestées ensuite.
• Mode de défaillance : vous pouvez quand même démarrer, mais votre attestation échoue ou vos secrets scellés ne se libèrent pas.
• Douleur opérationnelle : dérive des PCR due aux mises à jour, changements de firmware ou modifications de configuration.

En pratique, de bonnes plateformes font les deux : Secure Boot empêche les manipulations évidentes ; le measured boot vous donne une auditabilité et une confiance conditionnelle pour la libération des clés.

Ce que Secure Boot + TPM ne protègent pas

Cette section évite le gaspillage de budget. Si vous dépensez du capital politique sur la sécurité au démarrage, assurez‑vous de ne pas prétendre qu’elle corrige des choses qu’elle ne corrige pas.

Ils n’arrêtent pas la compromission en exécution

Si un attaquant obtient l’exécution de code dans votre OS en fonctionnement et escalade en root, Secure Boot ne le jette pas. Le TPM n’appelle pas la police. Vous avez toujours besoin de durcissement du noyau, de patchs, du principe du moindre privilège et d’un vrai monitoring.

Ils ne garantissent pas que le firmware est honnête

Secure Boot et le measured boot dépendent du bon comportement du firmware. Si le firmware est compromis, il peut mentir sur ce qu’il a vérifié ou mesuré. C’est pourquoi l’hygiène des mises à jour de firmware n’est pas optionnelle, et pourquoi certains environnements exigent des racines matérielles de confiance plus des chemins de mise à jour de firmware vérifiés.

Ils ne protègent pas contre les malwares « autorisés »

Si votre organisation signe un bootloader malveillant avec une clé de confiance, Secure Boot le démarrera volontiers. Si un attaquant vole votre clé de signature, votre couche d’application devient son canal de distribution. Mettez les clés de signature dans des processus HSM‑backed, encadrez leur usage, et journalisez chaque signature comme s’il s’agissait d’un déploiement de production.

Ils ne résolvent pas les problèmes de session volée

Secure Boot et le TPM peuvent aider à protéger les clés de disque au repos. Ils ne protègent pas une machine déjà déverrouillée d’un attaquant connecté, d’un agent SSH volé ou d’une session SSO compromise. Menace différente. Contrôles différents.

Ils ne rendent pas la récupération « plus facile »

Ils rendent souvent la récupération plus difficile. C’est le but : vous appliquez l’intégrité. Prévoyez des procédures de bris‑glace avec des clés de récupération, un accès console hors bande et des procédures documentées pour l’enrôlement des clés.

Faits intéressants et contexte historique (les parties que l’on oublie)

1. Secure Boot est arrivé avec les PC UEFI grand public au début des années 2010, et il s’est immédiatement heurté à la réalité que des gens installent des OS qui ne sont pas ceux d’usine.
2. TPM 1.2 précède TPM 2.0 de plusieurs années ; TPM 2.0 a étendu les algorithmes et la flexibilité, ce qui est bien jusqu’à ce que vous essayiez de standardiser sur une flotte hétérogène.
3. Le measured boot est plus ancien que la plupart des carrières cloud‑native : le concept d’une chaîne de mesures remonte aux premières recherches sur l’informatique de confiance, pas au branding DevSecOps moderne.
4. La liste de révocation UEFI (dbx) est un levier opérationnel réel : elle peut briquer d’anciens bootloaders après une mise à jour si vous dépendez de composants révoqués.
5. shim existe parce que la réalité existe : c’est un compromis pratique pour permettre aux distributions de participer aux écosystèmes Secure Boot sans que chaque utilisateur gère des clés de plateforme dès le premier jour.
6. La signature de modules n’est pas la même chose que Secure Boot : même avec Secure Boot activé, des modules noyau non signés peuvent rester une voie de compromission du noyau à moins que l’application de signatures de modules ne soit configurée.
7. Les valeurs PCR changent pour des raisons ennuyeuses, comme une mise à jour de firmware, un changement d’ordre de démarrage, ou le basculement de certains réglages UEFI. Ce n’est pas que le TPM soit instable, c’est la mesure qui fait son travail.
8. Des TPM virtuels (vTPM) existent et sont largement utilisés dans les piles de virtualisation ; ils sont utiles, mais votre confiance se déplace vers l’hyperviseur et sa gestion des clés.

Tâches pratiques : commandes, signification des sorties et décision que vous prenez

Voici les vérifications que j’exécute quand quelqu’un dit « Secure Boot est activé » ou « le TPM est configuré ». Je ne m’intéresse pas aux impressions. Je veux des preuves.

Task 1: Verify Secure Boot state from Linux

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Ce que cela signifie : UEFI Secure Boot est activé et le noyau le voit comme tel.

Décision : S’il est désactivé sur des machines qui doivent appliquer l’intégrité de démarrage, corrigez la politique du firmware ; s’il est activé sur une station de dev qui a besoin de noyaux non signés, prévoyez MOK ou des profils séparés.

Task 2: Confirm UEFI boot mode (UEFI vs legacy BIOS)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

Ce que cela signifie : Secure Boot requiert le mode UEFI ; le mode legacy rend toute cette conversation pour l’essentiel académique.

Décision : Si vous voyez « Legacy » sur du matériel qui doit être sécurisé, vous avez un problème de base d’images/firmware.

Task 3: Inspect enrolled MOK keys (common in Linux fleets)

cr0x@server:~$ mokutil --list-enrolled | head
MokListRT:
  SHA1 Fingerprint: 12:34:56:78:90:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88
  Subject: CN=Corp Kernel Signing CA

Ce que cela signifie : shim fera confiance aux binaires signés par ces clés (selon la configuration).

Décision : Si vous ne reconnaissez pas le sujet, considérez‑le comme une possible violation de politique. Si vous le reconnaissez, assurez‑vous que la clé privée est contrôlée comme un secret de production.

Task 4: Check whether the bootloader and kernel are signed (Debian/Ubuntu style)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Windows UEFI Driver Publisher
image signature certificates:
 - subject: /CN=Canonical Ltd. Secure Boot Signing

Ce que cela signifie : Le binaire EFI contient une chaîne de signatures. L’application de Secure Boot n’est efficace que pour ce que vous exécutez réellement.

Décision : Si l’émetteur de la signature est inattendu pour votre environnement, vous pourriez faire confiance à des clés plus larges que prévu. Pour des environnements stricts, utilisez votre propre stratégie PK/KEK/db.

Task 5: Verify kernel module signature enforcement status

cr0x@server:~$ cat /sys/module/module/parameters/sig_enforce
Y

Ce que cela signifie : Le noyau exige des modules signés (tel que configuré).

Décision : Si « N » sur des systèmes exposés à du code non fiable, envisagez de l’activer ; si « Y » casse des pilotes fournisseurs, vous avez besoin d’un flux de signature de modules propre, pas d’une exception nocturne.

Task 6: Confirm TPM device presence

cr0x@server:~$ ls -l /dev/tpm* 2>/dev/null
crw------- 1 root root  10, 224 Feb  5 10:12 /dev/tpm0
crw------- 1 root root 253,   0 Feb  5 10:12 /dev/tpmrm0

Ce que cela signifie : Le TPM est exposé à l’OS. /dev/tpmrm0 est l’interface du gestionnaire de ressources (préférée par beaucoup d’outils).

Décision : Si absent, vérifiez les paramètres BIOS/UEFI (TPM désactivé), pilotes manquants, ou configuration VM (vTPM non attaché).

Task 7: Read TPM capabilities to confirm TPM 2.0

cr0x@server:~$ tpm2_getcap properties-fixed | grep -E 'TPM2_PT_FAMILY_INDICATOR|TPM2_PT_MANUFACTURER'
  TPM2_PT_FAMILY_INDICATOR: "2.0"
  TPM2_PT_MANUFACTURER: "INTC"

Ce que cela signifie : Confirme la famille TPM et le fabricant. Utile quand vous dépannez des comportements incohérents entre révisions matérielles.

Décision : Si vous attendiez 2.0 et voyez autre chose (ou erreurs d’outil), arrêtez et standardisez le matériel/firmware ou ajustez les outils.

Task 8: Dump current PCR values (snapshot)

cr0x@server:~$ tpm2_pcrread sha256:0,2,4,7
sha256:
  0 : 2F4A...9C11
  2 : A1B2...C3D4
  4 : 88EE...1020
  7 : 0D0C...BEEF

Ce que cela signifie : Les PCR sont des hachages représentant l’état mesuré du démarrage (selon le firmware et la configuration). Le PCR 7 est souvent associé à l’état de politique Secure Boot sur de nombreuses plateformes.

Décision : Utilisez ces valeurs pour détecter une dérive ou lier des secrets. Si le PCR 7 change de façon inattendue après des mises à jour, attendez‑vous à ce que les secrets scellés cessent de se désemballer jusqu’à ce que vous re‑sceleiez ou ajustiez la politique.

Task 9: Check IMA/EVM measurement logs (if enabled)

cr0x@server:~$ test -r /sys/kernel/security/ima/ascii_runtime_measurements && head -n 3 /sys/kernel/security/ima/ascii_runtime_measurements
10 8b6c2f0c8d9e1e... ima-ng sha256:... boot_aggregate
10 1a2b3c4d5e6f... ima-ng sha256:... /usr/lib/systemd/systemd
10 9f8e7d6c5b4a... ima-ng sha256:... /usr/bin/sudo

Ce que cela signifie : IMA étend la mesure au‑delà du démarrage précoce vers des mesures de fichiers en runtime (si configuré). Contrôle distinct, mais souvent couplé à l’attestation TPM.

Décision : Si vous construisez de l’attestation, décidez si vous avez besoin seulement de l’intégrité du démarrage ou d’une preuve d’intégrité de fichiers en continu. N’activez pas IMA en production sans plan de déploiement ; ça peut être bruyant.

Task 10: Confirm LUKS is using TPM-based unlocking (systemd-cryptenroll example)

cr0x@server:~$ sudo systemd-cryptenroll --dump /dev/nvme0n1p3 | sed -n '1,25p'
CRYPTTAB ENROLLMENT:
  Entry Token 0:
        Token Type: systemd-tpm2
        PCRs: 7
        SRK Handle: 0x81000001

Ce que cela signifie : Le volume a un token TPM2 enrôlé, lié au PCR 7 dans cet exemple.

Décision : Un lien uniquement sur PCR 7 est courant et parfois acceptable, mais souvent insuffisant pour une forte assurance. Envisagez de lier des PCR supplémentaires (par ex. liés au bootloader/noyau) selon votre plateforme et votre tolérance aux pannes lors des mises à jour.

Task 11: Test unsealing behavior by simulating a policy mismatch (safe read-only check)

cr0x@server:~$ sudo systemd-cryptenroll --tpm2-pcrs=0+7 --dry-run /dev/nvme0n1p3
Failed to enroll TPM2 token: PCR 0+7 policy would change (existing token uses PCRs: 7)

Ce que cela signifie : Changer la politique PCR modifie le moment où le TPM libérera la clé. C’est pourquoi « simplement lier à plus de PCR » n’est pas gratuit.

Décision : Décidez selon votre modèle de menace : plus de PCR augmente généralement l’intégrité mais renforce l’accouplement opérationnel aux mises à jour et aux changements de configuration.

Task 12: Inspect boot entries and confirm you’re booting what you think you’re booting

cr0x@server:~$ sudo efibootmgr -v | head -n 15
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,2c9d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Ce que cela signifie : Affiche le chemin vers le binaire EFI réellement utilisé. Les attaquants et les accidents aiment tous deux les entrées de démarrage alternatives.

Décision : Si BootCurrent n’est pas le chemin attendu, corrigez l’ordre de démarrage et supprimez les entrées obsolètes. Sur des serveurs, verrouillez l’accès au firmware et journalisez les changements.

Task 13: Check for Secure Boot-related boot failures in the journal

cr0x@server:~$ sudo journalctl -b -0 | grep -iE 'secure boot|shim|mok|verification|lockdown' | head
kernel: secureboot: Secure boot enabled
kernel: Lockdown: integrity: Kernel is locked down from EFI Secure Boot mode
shim: MokManager: Processing MOK enrollment request

Ce que cela signifie : Confirme le mode lockdown et montre les événements d’enrôlement de clés.

Décision : Si vous voyez des erreurs de vérification après des mises à jour, vous avez probablement un décalage de signature ou un événement de révocation. Arrêtez de deviner et validez les signatures et l’état dbx.

Task 14: Determine kernel lockdown mode (common with Secure Boot on)

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity [confidentiality]

Ce que cela signifie : Le noyau est en mode lockdown, restreignant certaines actions qui pourraient contourner les garanties d’intégrité.

Décision : Si vos outils dépendent d’interfaces restreintes (comme certains débogueurs), prévoyez des workflows alternatifs. Ne désactivez pas Secure Boot juste pour satisfaire votre débogueur ; utilisez des noyaux signés ou des builds de débogage contrôlés.

Task 15: Inspect dbx updates (revocations) that can break boot

cr0x@server:~$ sudo mokutil --dbx | head
dbx:
  0: sha256 3f2a...d91c
  1: sha256 7a9b...0011

Ce que cela signifie : Liste les hashes/certs révoqués dans dbx tels que vus via mokutil.

Décision : Si un bootloader dont vous dépendez apparaît dans dbx (directement ou via une chaîne de certificats), vous devez mettre à jour les composants de démarrage sur la flotte avant que l’application de la révocation n’isole des nœuds.

Task 16: Confirm TPM is not in a weird “needs attention” state

cr0x@server:~$ dmesg | grep -iE 'tpm|crb|tis' | head -n 10
tpm_tis 00:05: 2.0 TPM (device-id 0x1B, rev-id 16)
tpm tpm0: TPM2.0 device found (CRB interface)

Ce que cela signifie : Le noyau reconnaît le TPM et l’interface. Les erreurs ici sont souvent corrélées à des mauvais réglages de firmware ou des révisions BIOS boguées.

Décision : Si vous voyez des timeouts ou des erreurs de localité, priorisez les mises à jour de firmware ou les correctifs de plateforme avant de construire des systèmes « dépendants du TPM » dessus.

Playbook de diagnostic rapide : trouvez le goulot d’étranglement vite

Quand la sécurité au démarrage casse, les gens ont tendance à gesticuler. Ne le faites pas. Utilisez un playbook court et vous trouverez généralement le coupable en minutes.

Première étape : est‑ce l’application qui échoue ou la libération de la clé ?

• La machine ne démarre pas du tout, tombe sur le firmware ou l’invite du bootloader : probablement une application Secure Boot ou un composant de démarrage révoqué.
• La machine démarre mais le disque ne se déverrouille pas automatiquement / demande une clé de récupération : probablement un échec d’unseal TPM dû à une dérive PCR ou un changement d’état du TPM.
• La machine démarre et le disque se déverrouille, mais l’attestation dit « non fiable » : probablement un décalage du measured boot, un parsing du journal d’événements ou une dérive de baseline.

Deuxième étape : vérifiez les trois « sources de vérité »

1. Paramètres du firmware : Secure Boot activé ? CSM/legacy désactivé ? TPM activé/activé ? Mise à jour firmware récente ?
2. Composants de démarrage : quel binaire EFI a été exécuté (efibootmgr), les signatures sont‑elles valides (sbverify), dbx a‑t‑il changé (mokutil –dbx) ?
3. Mesures/cles : valeurs PCR (tpm2_pcrread), politique d’enrôlement (systemd-cryptenroll –dump), et logs (journalctl, dmesg).

Troisième étape : décidez quel type de correction vous êtes autorisé à faire

• Restauration d’urgence du service : utilisez les clés de récupération, démarrez un media signé connu‑bon, annulez la mise à jour fautive.
• Correction de fond : mettez à jour/re‑signez le bootloader/noyau, ajustez la politique PCR via une procédure de reseal contrôlée, déployez les changements db/dbx dans le bon ordre.
• Correction long terme : standardisez les versions de firmware, la gestion des clés et le rythme des mises à jour ; implémentez un gating d’attestation pour les workloads sensibles.

Le goulot d’étranglement n’est généralement pas « le TPM est cassé ». C’est « nous avons changé quelque chose que nous n’avons pas mesuré et maintenant notre politique fait exactement ce que nous lui avons demandé. »

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: After a kernel update, servers boot but LUKS auto-unlock fails

Cause racine : la clé scellée dans le TPM était liée à des PCR affectés par la mise à jour (ou à l’état Secure Boot qui a changé à cause d’un update db/dbx).

Correction : Utilisez le chemin de récupération pour démarrer, puis resealez/enrôlez le token TPM contre le nouvel état mesuré. Envisagez de lier aux PCR qui correspondent à votre stratégie de mises à jour et testez les mises à jour sur un anneau canari.

2) Symptom: “SecureBoot enabled” but unsigned kernel modules still load

Cause racine : l’application des signatures de modules n’est pas activée (ou les modules sont signés par une clé que le noyau fait confiance via MOK/cert incorporé).

Correction : Activez l’application des signatures de modules là où c’est requis ; auditez les clés de confiance ; implémentez une chaîne de signature de modules. Ne comptez pas uniquement sur Secure Boot pour l’intégrité des modules.

3) Symptom: Suddenly can’t boot older rescue media

Cause racine : une mise à jour dbx a révoqué l’ancien bootloader/shim utilisé sur ce média.

Correction : Maintenez des médias de secours à jour signés avec des clés actuellement fiables ; testez les médias de démarrage après les mises à jour dbx ; gardez un chemin de bris‑glace documenté qui ne dépend pas de composants révoqués.

4) Symptom: Attestation fails on a subset of identical model servers

Cause racine : les versions de firmware diffèrent, ou les réglages BIOS diffèrent (CSM, mode Secure Boot, ordre de démarrage), causant une dérive PCR.

Correction : Standardisez le firmware, imposez des baselines de configuration, et collectez des baselines PCR par modèle/version de firmware. Une flotte « identique » est généralement aspirationnelle, pas factuelle.

5) Symptom: TPM tools error with “No TPM device found” in a VM

Cause racine : vTPM non attaché ou non exposé ; ou l’invité manque de pilotes.

Correction : Attachez un périphérique vTPM dans la configuration de l’hyperviseur ; vérifiez l’existence de /dev/tpmrm0 ; assurez‑vous que les modules noyau sont présents. Si vous ne pouvez pas faire confiance à l’hyperviseur, ne prétendez pas que le vTPM vous apporte des garanties matérielles.

6) Symptom: Secure Boot enabled, but bootchain tampering still possible via physical access

Cause racine : le setup du firmware n’est pas protégé (pas de mot de passe admin), l’attaquant peut désactiver Secure Boot ou enrôler ses propres clés.

Correction : Verrouillez le setup du firmware, restreignez l’accès physique, utilisez la détection d’intrusion de châssis si disponible, et inventoriez/journalisez la dérive de configuration du firmware.

7) Symptom: You can’t debug production because lockdown blocks access to kernel interfaces

Cause racine : Secure Boot déclenche la politique de lockdown du noyau qui restreint certaines opérations de debug.

Correction : Fournissez des noyaux de debug signés pour des environnements contrôlés, ou utilisez des outils d’observabilité supportés qui ne nécessitent pas de briser les garanties d’intégrité. Si votre plan de debug nécessite de désactiver des contrôles, ce n’est pas un plan.

Trois mini‑histoires d’entreprise (anonymisées, plausibles et douloureuses)

Mini‑histoire 1 : L’incident causé par une fausse hypothèse (« Secure Boot signifie que nos pilotes sont sûrs »)

Une entreprise SaaS de taille moyenne a déployé Secure Boot sur ses nœuds worker Kubernetes. C’était un mouvement de conformité. L’équipe sécurité a coché sa case, l’équipe infra a enchaîné les redémarrages de firmware, et tout le monde a déclaré victoire.

Des semaines plus tard, un pool de nœuds a commencé à se comporter bizarrement : pertes de paquets intermittentes, pics CPU en softirq, puis paniques noyau occasionnelles. Vibes classiques « matériel ou pilote ». Ils ont drainé des nœuds, remplacé quelques images, et le problème a suivi l’image, pas le châssis.

La cause n’était pas exotique : un module noyau tiers avait été installé dans le cadre d’un « pack de performance ». Il était signé — parce que l’organisation avait enrôlé une clé MOK large pour faciliter l’installation des fournisseurs. Un artefact de build compromis s’est glissé dans la chaîne d’approvisionnement, toujours signé par la clé en laquelle tout le monde avait confiance. Secure Boot a appliqué la politique fidèlement : « Si c’est signé par cette clé, exécutez‑le. »

La correction n’a pas été de désactiver Secure Boot. La correction a été d’arrêter de traiter l’enrôlement MOK comme une commodité. Ils ont renouvelé la clé MOK, restreint qui peut signer des modules, et exigé des preuves de build reproductibles pour les blobs fournisseurs. Ils ont appris à la dure que faire confiance à une clé est la vraie politique ; les signatures ne sont que le format.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux (« Lier la clé disque à plus de PCR pour plus de sécurité »)

Une équipe de services financiers a décidé de durcir le posture de chiffrement des disques sur des laptops Linux. Ils ont utilisé le déverrouillage basé TPM et ont pensé, raisonnablement, que lier la clé à plus de PCR rendrait la manipulation plus difficile. Ils l’ont donc liée à un ensemble large : firmware, bootloader, noyau, et quelques mesures liées à la configuration.

En laboratoire, ça semblait parfait. Puis le monde réel est arrivé. Des mises à jour firmware ont été déployées en vagues, parfois déclenchées par des outils OEM, parfois par l’IT. Un sous‑ensemble de machines a reçu une mise à jour BIOS qui a changé des composants mesurés et les valeurs PCR. Les laptops ont démarré, mais le TPM a refusé de désemballer. Les utilisateurs ont été renvoyés vers des flux de récupération, et les lignes de support ont fondu.

L’équipe sécurité a d’abord parlé d’« instabilité TPM ». Ce n’était pas ça. C’était la politique qui faisait son travail : ces machines n’étaient plus dans l’ancien état mesuré.

Ils ont récupéré en utilisant des clés de récupération et un processus de réenrôlement contrôlé après les mises à jour. Ils ont aussi appris à lier aux PCR qui correspondent à leur cadence opérationnelle et à orchestrer les mises à jour firmware avec la même discipline que les mises à jour OS. Plus de PCR peut être plus sûr. Ça peut aussi devenir un déni de service auto‑infligé.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (« Nous avons testé les changements dbx comme un déploiement de production »)

Une grande entreprise gérait une flotte Linux mixte : serveurs bare metal, quelques laptops, et un lot d’appliances qui étaient essentiellement des PC en boîte. Ils avaient une habitude apparemment terriblement conservatrice : toute mise à jour de firmware et tout changement db/dbx Secure Boot passaient par des anneaux canaris, avec des tests de démarrage incluant les médias de secours.

Un trimestre, une mise à jour dbx a été déployée qui révoquait un composant de démarrage vulnérable. C’était la bonne décision de sécurité. C’était aussi le type de changement qui peut isoler des machines si vous démarrez encore d’anciens shims ou si vous dépendez d’images de récupération obsolètes.

Parce qu’ils avaient des canaris, ils l’ont détecté tôt : leur ISO de secours legacy ne démarrera plus. La correction a été simple : actualiser les médias de secours avec un shim signé courant et mettre à jour l’image du fournisseur d’appliance avant que la révocation n’atteigne le reste de la flotte.

Pas de drame. Pas d’appel d’astreinte. Pas de cadre dirigeant apprenant ce que « dbx » signifie. Juste un ticket fermé calmement. C’est le genre d’hygiène opérationnelle ingrate qui vous maintient en poste.

Listes de contrôle / plan étape par étape (que faire dans une organisation réelle)

Checklist A: Rolling out Secure Boot without self-inflicted outages

1. Inventaire du mode firmware : confirmez le mode UEFI partout ; éliminez les installations BIOS legacy.
2. Décidez la stratégie de clés : valeurs par défaut du fournisseur vs PK/KEK/db personnalisés. Si vous avez besoin d’un contrôle fort, planifiez des clés custom et un escrow.
3. Établissez une chaîne de signature : qui signe noyaux/modules ? où la clé est‑elle stockée ? quelles approbations existent ? où sont les logs d’audit ?
4. Planifiez les changements dbx : suivez les révocations ; testez que vos composants de démarrage et médias de secours ne sont pas révoqués.
5. Canarisez tout : firmware, shim, bootloader, noyau, et mises à jour dbx. Les tests de démarrage ne sont pas optionnels.
6. Définissez le bris‑glace : console hors bande, médias de récupération, clés de récupération, et le processus humain pour les utiliser.

Checklist B: Using TPM for disk unlock without lying to yourself

1. Définissez ce que vous défendez : laptop volé, serveur volé, ou manipulation ?
2. Choisissez la politique PCR intentionnellement : PCR 7 uniquement est pratique ; des politiques plus larges sont plus fortes mais fragiles. Choisissez selon la réalité des mises à jour.
3. Stockez les clés de récupération en sécurité : escrow avec contrôle d’accès et logs d’audit. Testez la récupération trimestriellement.
4. Planifiez les mises à jour firmware : elles changeront les PCR. Construisez un workflow de réenrôlement.
5. Surveillez la dérive : collectez des baselines PCR ; alertez sur les changements inattendus pour les rôles sensibles.

Checklist C: Attestation that doesn’t become theatre

1. Décidez de l’usage des résultats d’attestation : bloquer le placement de workloads, restreindre les secrets, ou juste conserver une preuve.
2. Baseline par classe de plateforme : modèle matériel + version firmware + profil de configuration.
3. Gérez les mises à jour : traitez les nouvelles baselines comme une release ; propagez via des anneaux.
4. Conservez les logs : l’attestation sans rétention est un loisir, pas un contrôle.

FAQ

1) Does Secure Boot encrypt anything?

Non. Secure Boot vérifie des signatures pour décider ce qui peut s’exécuter. Le chiffrement au repos est un contrôle séparé (LUKS, BitLocker, etc.).

2) If Secure Boot is enabled, am I safe from bootkits?

Vous êtes plus protégé contre les bootkits non signés ou non fiables. Si des attaquants peuvent faire signer un composant malveillant par une clé de confiance (ou compromettre votre clé), Secure Boot le démarrera avec plaisir.

3) What does the TPM actually store?

Il peut stocker des clés (ou des matériaux de clé), des compteurs, et de petits blobs. Il enregistre aussi des valeurs PCR (mesures) et peut signer des déclarations d’attestation. Ce n’est pas un stockage généraliste.

4) What’s the difference between PCR binding and “TPM present” disk unlock?

Lier aux PCR signifie que le TPM ne libère la clé que si l’état mesuré correspond à la politique. « TPM présent » sans politique PCR significative est surtout du confort ; cela peut ne pas résister à la manipulation.

5) Why does a firmware update break TPM-based auto-unlock?

Parce que les composants mesurés ont changé, les valeurs PCR ont changé, et le TPM refuse de désemballer une clé liée aux anciennes mesures. C’est le comportement attendu.

6) Can I use a TPM in a VM and still claim hardware trust?

Vous pouvez utiliser un vTPM et bénéficier de fonctions comme le sealing et l’attestation dans la frontière de confiance de la virtualisation. Mais votre confiance se déplace vers l’hyperviseur, son stockage des secrets vTPM et son histoire d’attestation.

7) Should I use custom Secure Boot keys (own PK/KEK/db) everywhere?

Seulement si vous êtes prêt à l’opérer : génération de clés, stockage sécurisé, rotation, récupération et gestion du cycle de vie. Pour beaucoup d’organisations, shim + MOK est un compromis pragmatique. Pour une forte assurance, les clés personnalisées valent l’effort.

8) Is Secure Boot the same as kernel lockdown?

Non, mais ils sont liés sur beaucoup de distributions. Quand Secure Boot est activé, le noyau peut entrer en mode lockdown pour empêcher certaines actions qui pourraient contourner les garanties d’intégrité.

9) Can Secure Boot prevent someone from booting from a USB stick?

Il peut empêcher le démarrage de bootloaders USB non signés / non fiables. Mais si les options de boot du firmware ne sont pas verrouillées, un attaquant peut toujours changer les réglages. La sécurité physique et le contrôle d’accès firmware comptent.

10) What should I log and monitor?

Au minimum : état Secure Boot, clés enrôlées (MOK/db), changements dbx, versions de firmware, disponibilité du TPM, et résultats d’attestation pour les machines exécutant des workloads sensibles.

Prochaines étapes qui font vraiment la différence

Si vous voulez que Secure Boot + TPM soient plus qu’un autocollant de conformité, faites trois choses :

1. Rédigez votre modèle de menace en langage clair. « Evil maid sur laptops » et « persistance bootkit sur hyperviseurs » sont des mondes différents.
2. Opérationnalisez les clés et les mises à jour : traitez la signature comme des déploiements de production, testez les changements dbx comme vous testez des rollouts noyau, et standardisez le firmware.
3. Exercez la récupération : escrowez les clés de récupération, maintenez des médias de secours à jour, et faites un drill trimestriel « peut‑on récupérer un disque scellé après une mise à jour firmware ? ».

Secure Boot applique ce que vous faites confiance. Le TPM vous aide à lier des secrets et à prouver ce qui s’est passé. Aucun des deux ne remplace le patching, le contrôle d’accès, ou la procédure ennuyeuse. Et la « procédure ennuyeuse », de façon agaçante, c’est là que vit la vraie sécurité.