Secure Boot et UKI : une chaîne de démarrage signée

Un serveur chiffré au repos, ça rassure jusqu'au jour où on regarde ce qui s'exécute avant l'OS. Un attaquant avec un accès physique, ou un employé d'un site de colocation, remplace l'initramfs par une version modifiée qui capture la passphrase LUKS ou injecte un implant. Au boot suivant, le disque se déchiffre, l'implant tourne, et le chiffrement n'a servi à rien. C'est le scénario bootkit, et il exploite le code de démarrage que personne ne vérifie.

Secure Boot impose une signature sur chaque binaire de démarrage. UKI étend cette signature à l'initramfs et à la ligne de commande noyau, longtemps laissés sans contrôle. Ensemble, ils donnent une chaîne de démarrage vérifiée de bout en bout, et c'est la base sur laquelle le scellement TPM2 prend tout son sens.

Le chiffrement de disque protège les données quand la machine est éteinte. Il ne protège rien de ce qui tourne au démarrage, avant que LUKS soit déverrouillé. Or cette phase exécute du code : firmware, bootloader, noyau, initramfs.

L'initramfs est le maillon faible historique. Il contient le code qui demande la passphrase et déverrouille le disque chiffré. S'il n'est pas signé ni vérifié, un attaquant le remplace par une version qui exfiltre la clé. La cible n'est pas le disque chiffré, c'est le code qui le déchiffre. Voler la clé en amont vaut mieux que casser l'AES.

Côté ops, ce risque concerne tout serveur où on ne maîtrise pas l'accès physique : colocation, site distant, baie partagée. Le chiffrement seul ne suffit pas, il faut garantir l'intégrité de la chaîne qui mène au déchiffrement.

Secure Boot impose que chaque binaire exécuté au démarrage soit signé par une clé reconnue. Le firmware vérifie le bootloader, qui vérifie le noyau. La hiérarchie de clés est stockée dans le firmware UEFI :

• PK (Platform Key) : la clé racine, auto-signée. Le propriétaire de la plateforme.
• KEK (Key Exchange Key) : signée par la PK, sert à signer db et dbx.
• db : la liste des clés et hashes autorisés à s'exécuter au boot.
• dbx : la liste des révocations, parsée en premier. Tout binaire dont le hash ou la signature matche dbx est refusé, même s'il est dans db.

Aucune clé ne se remplace sans être signée par la précédente. Le propriétaire de la plateforme est la racine de confiance.

Le problème pratique : la plupart des distributions Linux ne sont pas signées par une clé présente d'origine dans db. La solution est shim, un petit bootloader signé par la CA UEFI tierce de Microsoft, donc accepté par le firmware de la quasi-totalité des machines. shim vérifie ensuite l'étage suivant (systemd-boot, GRUB, ou directement un UKI) contre db ou contre une base de clés propre à l'utilisateur, la MOK.

La MOK (Machine Owner Key) est l'équivalent des clés db, mais gérée par le propriétaire de la machine sans toucher au firmware d'origine. On enregistre sa propre clé via mokutil, et shim accepte alors les binaires signés avec. C'est le mécanisme propre pour signer ses propres noyaux et UKI sans dépendre de Microsoft ni reconfigurer la PK.

Signer le noyau, c'est bien. Mais le noyau seul ne suffit pas : l'initramfs et la ligne de commande noyau (cmdline) influencent ce qui s'exécute, et les signer séparément est fragile. Un attaquant qui ne peut pas toucher au noyau peut encore modifier l'initramfs ou injecter un paramètre dans la cmdline.

UKI (Unified Kernel Image) règle ça. C'est un fichier unique au format PE/COFF, le même format d'exécutable que celui des binaires UEFI, qui embarque dans ses sections :

• .linux : le noyau (seule section obligatoire).
• .initrd : l'initramfs.
• .cmdline : la ligne de commande noyau.
• .osrel : l'identification de l'OS (/etc/os-release).
• .sbat : les métadonnées de révocation SBAT.
• .pcrsig et .pcrpkey : signatures et clé pour les mesures PCR du TPM.

Tout ce bloc se signe d'un coup, comme un binaire UEFI standard. La signature protège le noyau, l'initramfs et la cmdline ensemble, en une fois. Plus de maillon non signé. À l'exécution, le stub UEFI extrait les composants et démarre le noyau embarqué.

Ce stub, c'est systemd-stub. Il sert d'amorce : intégré au début de l'UKI, il lit les sections et passe la main au noyau. La construction de l'image passe par ukify, l'outil systemd qui assemble les composants, gère l'alignement PE et signe le résultat pour Secure Boot si on lui fournit une clé. À noter, ukify n'engendre pas l'initramfs lui-même : on le construit avec dracut (qui sait aussi produire un UKI directement), puis on l'assemble.

En pratique, l'assemblage et la signature ressemblent à ça :

ukify build \
  --linux=/boot/vmlinuz-$(uname -r) \
  --initrd=/boot/initramfs-$(uname -r).img \
  --cmdline="root=/dev/mapper/cryptroot rw quiet" \
  --secureboot-private-key=/etc/secureboot/db.key \
  --secureboot-certificate=/etc/secureboot/db.crt \
  --output=/boot/efi/EFI/Linux/uki.efi

Le binaire produit est déposé dans la partition EFI, et un bootloader comme systemd-boot le détecte automatiquement dans EFI/Linux/. Plus besoin d'entrées de boot bricolées : un UKI par version de noyau, le bootloader les liste.

C'est là que la chaîne signée devient un atout opérationnel. Le TPM2 mesure chaque étape du boot dans ses registres PCR. La section .pcrsig de l'UKI permet de signer ces mesures attendues. Le scellement TPM2 de la clé LUKS s'appuie dessus : le TPM ne descelle la clé que si les mesures correspondent à un boot intègre.

Concrètement, on combine deux choses. D'abord Secure Boot plus UKI signé garantissent que seul un noyau et un initramfs légitimes peuvent démarrer. Ensuite le TPM, via les PCR, vérifie que c'est bien cet état-là qui a booté, et libère la clé de déchiffrement seulement dans ce cas. Si un attaquant remplace l'UKI, la signature casse côté Secure Boot, et même s'il contournait ça, la mesure PCR changerait et le TPM refuserait de desceller la clé.

Le détail des PCR, des combinaisons et de l'enrôlement est traité dans le guide systemd-cryptenroll et TPM2. Le point à retenir ici : UKI signé et scellement TPM2 se renforcent. L'un garantit ce qui démarre, l'autre vérifie que c'est bien ce qui a démarré avant de livrer la clé. La section .pcrsig de l'UKI permet de garder une politique de scellement qui survit aux upgrades de noyau, en signant les mesures prévues plutôt qu'en figeant un hash unique.

Le workflow sur un serveur qu'on opère :

1. Générer une paire de clés (db perso, ou MOK).
2. Enregistrer la clé publique : dans db si on contrôle le firmware, sinon via mokutil --import pour passer par shim.
3. Construire l'UKI avec ukify ou dracut, signé avec la clé privée.
4. Déposer l'UKI dans la partition EFI, configurer systemd-boot.
5. Activer Secure Boot dans le firmware UEFI.
6. Sceller la clé LUKS au TPM avec une politique PCR qui inclut la mesure de l'UKI.

Le piège classique : automatiser la régénération de l'UKI à chaque update de noyau. Un kernel update qui reconstruit l'initramfs sans re-signer l'UKI casse le boot, ou pire, désactive la vérification. Le pipeline de mise à jour doit reconstruire et re-signer l'UKI, puis rejouer le scellement TPM si la politique PCR l'exige. Sans ce runbook, le serveur ne reboote plus après une mise à jour, et le sysadmin de garde découvre le problème au pire moment.

Autre garde-fou : toujours garder une passphrase LUKS de secours et une clé de récupération hors site. Secure Boot plus TPM, c'est de l'automatisation du déverrouillage, pas un remplacement du dernier recours humain. Le jour où la carte mère meurt, le TPM change, et seule la passphrase de secours rouvre le disque.

Secure Boot et UKI verrouillent le démarrage. Ils ne protègent rien une fois le système en marche. Un attaquant qui obtient root sur la machine vivante lit les données déverrouillées, modifie les fichiers, installe ce qu'il veut. La chaîne de boot signée est une couche, pas la sécurité complète.

Au-dessus, il faut le contrôle d'accès obligatoire avec SELinux, la surveillance d'intégrité des fichiers avec AIDE, et le durcissement habituel du système en marche. Secure Boot garantit qu'on démarre sur du code vérifié ; ce qui se passe ensuite relève d'autres mécanismes.

Le verdict ops : sur un serveur sensible, surtout en colocation ou sur site distant, la cible est Secure Boot activé, UKI signés avec ses propres clés, et clé LUKS scellée au TPM. Le chiffrement de disque sans chaîne de boot vérifiée laisse le maillon initramfs ouvert ; UKI le ferme. Le coût, c'est la rigueur du pipeline de mise à jour. Sans automatisation propre de la reconstruction et de la signature, on transforme une mesure de sécurité en panne de boot programmée.

Mettre en place une chaîne de démarrage signée sur un parc, écrire le pipeline qui reconstruit et signe les UKI à chaque update, documenter le runbook de récupération, c'est un chantier qui se cadre et se teste avant la prod. C'est le genre de durcissement qu'on déploie et qu'on opère sur les serveurs sensibles qu'on gère. Si vos serveurs chiffrés laissent encore l'initramfs en clair, on peut auditer et fermer la chaîne de boot.

• UAPI Group - Unified Kernel Image specification : format PE/COFF, sections embarquées, signature d'un bloc pour Secure Boot.
• ukify(1) - man page : assemblage des composants, signature Secure Boot, options de clés.
• systemd-stub(7) et Secure Boot - ArchWiki : construction d'un UKI, intégration systemd-stub, dépôt dans la partition EFI.
• UEFI Secure Boot - ArchWiki : clés PK/KEK/db/dbx, shim, MOK, enregistrement via mokutil.
• Red Hat - Signing a kernel for Secure Boot : signature de noyau et modules, gestion des clés MOK en pratique.