Contexte: La NSA publie des orientations sur la gestion de Secure Boot pour Linux (information reprise dans l’article de Brittany Day, 31 déc. 2025 sur Linuxsecurity), soulignant le déplacement des attaques vers les phases les plus précoces du démarrage. Des incidents comme BootHole, BlackLotus et PKFail illustrent comment des configurations permissives, des clés réutilisées et des bootloaders vulnérables transforment Secure Boot en surface d’attaque. L’enjeu: imposer la confiance avant que l’OS et ses contrôles n’existent, sous peine de persistance profonde et d’invisibilité des bootkits.

Fonctionnement de Secure Boot: UEFI Secure Boot vérifie que chaque composant de la chaîne de démarrage est signé par une clé de confiance, sinon l’exécution s’arrête (en mode appliqué). La confiance repose sur les magasins cryptographiques firmware: PK (Platform Key) pour la gouvernance du policy, KEK pour autoriser les mises à jour des listes, DB (signatures/empreintes autorisées) et DBX (signatures/empreintes révoquées). Les modes enforcement vs audit conditionnent la rigueur: l’audit loggue mais laisse s’exécuter, pouvant créer une fausse impression de sécurité.

Chaîne de démarrage Linux: La plupart des distributions utilisent un shim signé (souvent par la CA UEFI Microsoft) comme premier binaire EFI, qui vérifie et lance GRUB2, lequel charge un noyau Linux signé (p. ex. /boot/vmlinuz-). Des éléments clés nommés: shimx64.efi, grubx64.efi sur la partition EFI. L’ajout de noyaux personnalisés ou de modules tiers passe souvent par l’enrôlement d’une MOK (Machine Owner Key), qui élargit la frontière de confiance et doit être gérée au même titre que les clés éditeur. Toute pièce non signée, non approuvée ou révoquée via DBX stoppe le boot.

Vérification et outillage 🔧: La gestion efficace vise à maintenir un état « connu-bon » et à éviter la dérive de configuration. Contrôles à effectuer autant dans l’OS que dans le firmware (désactivation du CSM/Legacy BIOS qui contourne Secure Boot). Outils cités:

  • mokutil (état Secure Boot, MOK, DB/DBX)
  • efivar (variables UEFI)
  • sbverify / pesign (vérifier signatures des binaires EFI)
  • lsblk -f (identifier la partition EFI)
  • UI firmware (mode Secure Boot, CSM)
  • Outils d’orchestration (Ansible, etc.) pour auditer à l’échelle Des bases de référence doivent définir l’état d’application, les clés approuvées et le niveau de révocation, avec collecte d’empreintes/certificats et tests pré-déploiement.

Défis de configuration et impacts: Des contournements fréquents proviennent de modes BIOS/CSM, de défauts OEM permissifs, de clés manquantes/test laissant la politique sans propriétaire. Les rotations de clés éditeurs et mises à jour DBX peuvent casser silencieusement la confiance ou, si retardées, laisser des bootloaders vulnérables actifs. Spécificités Linux: MOK pour noyaux/modules tiers, modes audit non bloquants, variations UEFI selon matériels. L’article souligne aussi l’impact « quotidien » (posture domestique contre la persistance silencieuse) et l’importance accrue en serveurs/datacenters où l’hétérogénéité matérielle et la dérive d’état compliquent l’uniformité. Conclusion: il s’agit d’une recommandation de sécurité structurée visant à cadrer la gestion continue de Secure Boot pour réduire les attaques de bootchain.

TTPs observés (exemples, d’après les cas évoqués):

  • Abus de bootloaders signés mais vulnérables (ex.: BlackLotus)
  • Persistance via bootkits avant l’initialisation de l’OS
  • Bypass par configuration permissive (mode audit, CSM/Legacy BIOS)
  • Exploitation de listes de révocation (DBX) non mises à jour

🔗 Source originale : https://linuxsecurity.com/root/features/nsa-secure-boot-management-guidance