Morpheus
Sécurité / Chaîne de confiance boot

Boot Trust Morpheus

Chaîne de confiance au boot: systemd-boot, UKI, Secure Boot, LUKS, TPM, FIDO2 et contrôles après restauration PRA.

systemd-boot UKI Secure Boot LUKS TPM/FIDO2
Chaîne Boot Trust Morpheus expurgée
Vue publique: systemd-boot, UKI signé, Secure Boot, LUKS, TPM, FIDO2 et contrôles PRA.
01

Sélectionner

systemd-boot doit lancer l'entrée attendue, pas un ancien artefact oublié.

02

Vérifier

L'UKI regroupe noyau, initramfs et cmdline dans une image signée et contrôlable.

03

Déverrouiller

LUKS reste la protection principale, complétée par TPM et FIDO2 comme voies matérielles.

04

Valider

bootctl, sbctl, findmnt et lsblk confirment l'état réel après boot ou restauration.

Contexte

Le problème réel.

Un système peut sembler démarrer correctement tout en ayant une chaîne de confiance incohérente: mauvaise entrée bootloader, UKI stale, cmdline incomplète, signature absente ou slot FIDO2 jamais tenté.

Objectifs

Ce que la solution devait garantir.

  • Garantir que le bootloader charge l'entrée voulue.
  • Vérifier que l'image démarrée est l'UKI signé attendu.
  • Conserver LUKS, TPM et FIDO2 comme mécanismes cohérents et testables.
  • Rendre la chaîne de confiance restaurable dans le flux PRA.
Architecture publique

Structure documentée, détails exploitables retirés.

Exemples anonymisés

Ce qui peut être montré sans exposer le système réel.

Checklist post-update

Exemple dérivé du runbook UKI stale: vérifier la cohérence après mise à jour noyau ou initramfs.

entrée de boot courante      entrée durcie attendue
état UKI mesuré             oui / non
version noyau artefact      correspond au noyau installé
vérification signature      valide
racine chiffrée             toujours active
chemin de boot fallback     documenté et testé

Diagnostic d'artefact stale

Le cas documenté: un emergency shell peut faire croire à un compte root verrouillé alors que le problème vient souvent de la chaîne UKI/LUKS/TPM.

symptôme                        piste probable
Measured UKI: no                 mauvais chemin de boot ou fallback non UKI
écran boot d'urgence             chaîne de déverrouillage ou artefact stale
noyau plus ancien dans l'artefact UKI non reconstruit après mise à jour
signature incohérente            artefact modifié après signature
entrée fallback qui démarre      problème de chaîne de confiance, pas panne disque complète

Chaîne de confiance anonymisée

Le modèle mental est publiable sans empreintes, UUID ni slots matériels.

firmware
  -> bootloader entry
  -> signed unified kernel image
  -> encrypted root unlock
  -> integrity and service checks after boot
Runbook public

Commandes et états attendus issus de la documentation privée.

Les commandes ci-dessous sont volontairement anonymisées: chemins, noms de machines, interfaces, dépôts, périphériques et actions destructrices sont remplacés par des placeholders.

Documentation privée: uki-stale-after-update

Diagnostic UKI stale

Commandes anonymisées

bootctl status
bootctl list
uname -r
ukify inspect <signed-uki>
sbctl verify
journalctl -b -0 -p err..alert --no-pager
journalctl -b -0 --no-pager | rg -n 'emergency|cryptsetup|TPM|luks|unlock|failed|timeout'

État attendu

Current Entry correspond à l'entrée durcie
Measured UKI vaut yes sur le chemin attendu
le .uname de l'UKI correspond à la famille noyau en cours
la vérification sbctl est propre
l'emergency shell est traité comme une dérive de chaîne de confiance jusqu'à preuve du contraire
Documentation privée: boot-trust

Contrôles Boot Trust

Commandes anonymisées

bootctl status
sbctl status
findmnt <root-mount>
findmnt <boot-mount>
lsblk -f

État attendu

l'entrée bootloader est cohérente
l'UKI signée est bien l'artefact démarré
la racine chiffrée reste en place
les points de montage root et boot correspondent aux disques restaurés
le PRA garde Secure Boot, UKI, TPM/FIDO et LUKS visibles
Documentation privée: uki-stale-after-update

Prévention après update

Commandes anonymisées

mkinitcpio -P
ukify inspect <signed-uki>
sbctl verify
bootctl status

État attendu

la mise à jour noyau reconstruit initramfs et chemin UKI
la cmdline embarquée est explicite
la signature reste valide après reconstruction
l'entrée fallback reste documentée mais n'est pas le chemin nominal
Travail réalisé

Décisions techniques publiables.

Règle UKI

La cmdline embarquée doit inclure les options FIDO2/TPM attendues si ces voies doivent être tentées.

Matrice FIDO2

La page explique les rôles de la phrase de passe, de la clé de récupération, de TPM2 + PIN et des clés FIDO2 sans publier les slots réels.

PRA

La restauration doit reconstruire et signer les artefacts puis vérifier /, /boot, bootctl et sbctl.

Validation

Preuves et contrôles retenus.

Preuves visuelles

Contrôles observables et portée de la preuve.

Secure Boot et noyau courant
Secure Boot et noyau courant. sbctl confirme Secure Boot actif tandis que uname identifie le noyau LTS courant; les identifiants sensibles sont masqués.
Bootloader et UKI mesurée
Bootloader et UKI mesurée. bootctl expose le firmware UEFI, Secure Boot, TPM2, systemd-boot et le chemin UKI mesuré.
Contenu de l'UKI
Contenu de l'UKI. ukify inspect relie l'artefact signé à son noyau, sa cmdline, son initrd et ses sections mesurables.
Réutilisation PRA — signature après restauration
Réutilisation PRA — signature après restauration. Cette preuve complémentaire montre la vérification des signatures et l'inspection UKI dans la VM restaurée.
Réutilisation PRA — cmdline restaurée
Réutilisation PRA — cmdline restaurée. Cette preuve complémentaire montre que l'UKI restaurée embarque la cmdline LUKS/TPM attendue.
Résultats publics

Ce que le chantier démontre.

Anonymisation

Ce qui reste privé.

  • Pas d'empreintes de clés, UUID LUKS, slots matériels ou cmdline réelle complète.
  • Pas de chemins vers artefacts de boot privés.
  • Pas d'identifiants de clés FIDO2 ou TPM.
  • Les exemples utilisent des placeholders et une matrice de rôles.
Sources privées

Documentation d'origine.

  • Documentation Boot Trust.
  • Runbook UKI stale après update.
  • Documentation FIDO2 + LUKS.
  • Runbook restauration PRA.

Supplément de documentation privée anonymisé

Boot Trust Morpheus

Cette page centralise la chaîne de confiance au boot. Elle rassemble systemd-boot, UKI, Secure Boot, LUKS, TPM et FIDO2, avec les contrôles attendus après boot, mise à jour ou restauration PRA.

Objectif

  • Le bootloader attendu charge l'entrée voulue.
  • L'image démarrée est l'UKI signé attendu.
  • Le disque système reste chiffré.
  • Le TPM déverrouille seulement dans le contexte matériel prévu.
  • FIDO2 reste une voie de secours valide et lisible.
  • La restauration PRA conserve ces propriétés après réinstallation.

Chaîne de confiance

La chaîne ne repose pas sur une seule brique. Chaque étape doit être cohérente avec la précédente et vérifiable indépendamment.

1. systemd-boot

Point d'entrée du démarrage. Il sélectionne l'entrée utilisée au boot et reste le point de contrôle de la configuration de démarrage.

2. UKI

L'UKI regroupe noyau, initramfs et ligne de commande dans une seule image. Cela réduit les écarts entre configuration voulue et contenu réellement exécuté.

3. Secure Boot

Les binaires de boot sont signés avec les clés attendues. Secure Boot aide à détecter une image de boot remplacée ou altérée.

4. LUKS

Le disque système est chiffré avec LUKS pour protéger les données au repos. TPM et FIDO2 complètent LUKS, ils ne le remplacent pas.

5. TPM

Le TPM peut associer le déverrouillage à l'état matériel attendu. Une divergence firmware ou boot peut invalider ce chemin.

6. FIDO2

Une clé FIDO2 ajoute une voie matérielle supplémentaire pour déverrouiller LUKS. La matrice cible publique décrit les rôles, pas les numéros réels de slots:

RôleFonction
PassphraseDéverrouillage manuel de base.
Clé de récupérationSecours hors ligne.
TPM2 + PINDéverrouillage lié au matériel attendu.
FIDO2 principaleVoie matérielle principale.
FIDO2 secoursVoie matérielle de repli.

Un prompt FIDO2 lisible demande le PIN puis la présence utilisateur. Une erreur PIN_AUTH_BLOCKED indique souvent un mauvais PIN ou une injection clavier parasite, pas forcément un problème LUKS.

Règle de validation UKI

Quand FIDO2 doit être tenté au boot, la cmdline embarquée par l'UKI doit contenir explicitement fido2-device=auto dans les options LUKS, en plus du TPM si le mode hybride est voulu.

rd.luks.options=<LUKS_UUID>=fido2-device=auto,tpm2-device=auto,token-timeout=10s,discard
Slot dormant

Un slot FIDO2 peut exister dans LUKS sans être tenté au démarrage si l'UKI ne porte pas l'option attendue.

Flux logique

  1. La restauration PRA remet / et /boot dans un état cohérent.
  2. mkinitcpio et ukify reconstruisent les artefacts de boot.
  3. sbctl signe les artefacts nécessaires.
  4. systemd-boot lance l'entrée validée.
  5. bootctl et sbctl confirment la cohérence de l'état.
  6. findmnt confirme les points de montage réels.

Vérifications recommandées

bootctl status
sbctl status
findmnt /
findmnt /boot
lsblk -f

Restauration et PRA

Le PRA doit restaurer le système et préserver la chaîne de confiance: montages corrects, artefacts reconstruits, signatures cohérentes et options UKI attendues.

  • Restauration automatisée.
  • Hardening Kernel.
  • FIDO2 + LUKS.

Intégration avec le reste du site

  • SecOps expose l'état Secure Boot dans le dashboard local.
  • La vue d'ensemble hardening renvoie vers Boot Trust pour le démarrage.
  • Le PRA utilise cette chaîne comme condition de restauration complète.

Politique de validation

  • Une machine saine démarre sur l'entrée attendue.
  • L'état Secure Boot reste cohérent avec la cible signée.
  • Le chiffrement LUKS reste en place après restauration.
  • Toute divergence entre bootloader, UKI et artefacts signés est traitée comme un écart de confiance.