Déverrouiller automatiquement LUKS au démarrage avec le TPM2 et Clevis (Ubuntu 24.04)¶

Contexte¶

Le besoin¶

Le disque de mon ThinkPad est chiffré avec LUKS2 + LVM. À chaque démarrage, je dois saisir manuellement la phrase de passe LUKS. Objectif : ne plus avoir à taper le mot de passe au boot, en laissant le TPM2 libérer la clé automatiquement — tout en conservant des méthodes de secours.

Le lecteur d'empreintes ne peut pas déverrouiller LUKS au boot (il n'intervient qu'après le démarrage, au niveau de PAM). La seule vraie solution de déverrouillage du disque au démarrage est donc le TPM2.

L'environnement matériel (référence)¶

Organisation du disque nvme0n1 :

Prérequis¶

• Ubuntu 24.04 sur UEFI, avec Secure Boot activé et une puce TPM 2.0 détectée.
• Une racine chiffrée en LUKS2 (indispensable : les tokens TPM2 n'existent pas en LUKS1).
• Un accès sudo.
• Connaître sa phrase de passe LUKS (elle reste le filet de sécurité).
• Une clé USB pour stocker la sauvegarde de l'en-tête LUKS hors du disque chiffré.
• Idéalement, une clé USB Live Ubuntu 24.04 prête en cas de dépannage.

Vérifications matérielles rapides :

[ -d /sys/firmware/efi ] && echo "UEFI: oui" || echo "UEFI: non"
mokutil --sb-state                       # -> SecureBoot enabled
ls /dev/tpm*                             # -> /dev/tpm0 et /dev/tpmrm0
sudo dmesg | grep -i -e tpm -e iommu     # -> "2.0 TPM", DMAR/iommu
sudo cryptsetup luksDump /dev/nvme0n1p3 | head -5   # -> LUKS Version: 2

Comprendre le piège : pourquoi systemd-cryptenroll seul échoue sur Ubuntu¶

C'est le point clé de toute cette procédure, et l'erreur classique.

La documentation générale (et beaucoup de tutoriels orientés Arch/Fedora) recommande :

# Enrôlement TPM2 "à la systemd" — fonctionne pour l'enrôlement,
# mais NE déverrouille PAS la racine au boot sur Ubuntu 24.04 !
sudo systemd-cryptenroll /dev/nvme0n1p3 --tpm2-device=auto

puis d'ajouter dans /etc/crypttab :

dm_crypt-0 UUID=... none luks,tpm2-device=auto

Problème : au update-initramfs, Ubuntu affiche :

cryptsetup: WARNING: dm_crypt-0: ignoring unknown option 'tpm2-device'

Cause racine¶

L'option tpm2-device= de /etc/crypttab n'est comprise que par systemd-cryptsetup. Or, sur Ubuntu 24.04, l'initramfs par défaut (initramfs-tools + cryptsetup-initramfs) n'utilise pas systemd pour déverrouiller la racine : il utilise le déverrouillage historique en scripts shell (/scripts/local-top/cryptroot), qui ne connaît pas cette option.

Conséquence : le token systemd-tpm2 est bien inscrit dans l'en-tête LUKS, mais rien ne le consulte au boot. Le keyslot correspondant est donc mort au démarrage.

Alternatives et pourquoi Clevis¶

On retient donc Clevis, qui lie un keyslot LUKS au TPM2 et se branche dans l'initramfs Ubuntu via un hook dédié, avec repli automatique sur le mot de passe.

Procédure¶

Étape 0 : Filet de sécurité (obligatoire)¶

Sauvegarde de l'en-tête LUKS (le parachute ultime), puis copie sur une clé USB externe :

sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 \
  --header-backup-file ~/luks-header-nvme0n1p3-$(date +%F).img

Assurez-vous aussi d'avoir noté votre recovery key et de connaître votre mot de passe LUKS.

Étape 1 : Vérifier / ajouter les filets logiciels (optionnel mais conseillé)¶

Une recovery key (phrase de passe de secours facile à archiver) :

sudo systemd-cryptenroll /dev/nvme0n1p3 --recovery-key

Étape 2 : Nettoyer /etc/crypttab¶

Retirez toute option tpm2-device=auto (ignorée et source de warning). L'objectif est de revenir à une ligne propre — Clevis n'a besoin d'aucune option dans crypttab, son hook détecte le binding automatiquement.

sudo cp -a /etc/crypttab /etc/crypttab.bak-$(date +%F)
sudo sed -i 's/,tpm2-device=auto//' /etc/crypttab
cat /etc/crypttab

Résultat attendu :

dm_crypt-0 UUID=3e75e9a9-8816-4ae4-a2b8-56cb94555125 none luks

Étape 3 : Installer Clevis¶

sudo apt update
sudo apt install clevis clevis-luks clevis-initramfs clevis-tpm2 tpm2-tools

Vérifier la présence du support TPM2 :

# Test rapide : le TPM2 chiffre-t-il / déchiffre-t-il ?
echo "test-tpm" | sudo clevis encrypt tpm2 '{"pcr_bank":"sha256","pcr_ids":"7"}' \
  | sudo clevis decrypt && echo "[TPM2 OK]"

Étape 4 : Lier LUKS au TPM2 avec Clevis (le cœur de la procédure)¶

sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_bank":"sha256","pcr_ids":"7"}'

• Au prompt Enter existing LUKS password:, saisissez votre mot de passe LUKS (ou votre recovery key — les deux fonctionnent).
• Clevis ajoute un nouveau keyslot (par ex. le n°3) et crée un token clevis qui pointe dessus. Les keyslots existants ne sont pas modifiés.
• Succès = la commande rend la main sans afficher d'erreur.

Étape 5 : Régénérer l'initramfs¶

sudo update-initramfs -u -k all

Vérification¶

1. Le binding Clevis existe¶

sudo clevis luks list -d /dev/nvme0n1p3

3: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"7"}'

2. Les keyslots et tokens sont cohérents¶

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -E '^[[:space:]]+[0-9]+: (luks2|systemd|clevis|pbkdf2)'

On doit retrouver le keyslot mot de passe (slot 0), la recovery (slot 1), éventuellement l'ancien systemd-tpm2 (slot 2), et le nouveau keyslot Clevis (slot 3) associé à un token clevis.

3. Le hook Clevis est bien embarqué dans l'initramfs¶

sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep -iE 'clevis'

scripts/local-top/clevis
scripts/local-bottom/clevis
usr/bin/clevis-luks-unlock
usr/bin/clevis-decrypt-tpm2

4. Test décisif : le TPM libère-t-il réellement la clé ?¶

On ne peut pas tester en ré-ouvrant dm_crypt-0 (le disque racine est déjà monté → « périphérique déjà utilisé »). On rejoue donc exactement l'opération du boot : demander au TPM de déchiffrer le JWE stocké dans le token Clevis, selon la politique PCR 7.

# Remplacez --token-id 2 par l'ID du token clevis vu à l'étape "luksDump"
sudo cryptsetup token export --token-id 2 /dev/nvme0n1p3 \
  | python3 -c 'import sys,json; d=json.load(sys.stdin)["jwe"]; sys.stdout.write(".".join([d["protected"],d.get("encrypted_key",""),d["iv"],d["ciphertext"],d["tag"]]))' \
  | sudo clevis decrypt >/dev/null && echo ">>> SUCCÈS : le TPM libère la clé, l'auto-déverrouillage fonctionnera."

5. Le vrai test : redémarrer¶

sudo reboot

• Cas normal : le disque se déverrouille tout seul, sans mot de passe. 🎯
• Si le TPM refuse : l'initramfs redemande la phrase de passe — aucune casse. C'est le filet de sécurité intégré.

Précautions prises (récapitulatif)¶

• Sauvegarde de l'en-tête LUKS avant toute modification (étape 0), stockée hors du disque.
• Sauvegarde de /etc/crypttab avant édition.
• Keyslots existants intacts : slot 0 (mot de passe) et slot 1 (recovery) jamais touchés — on n'a fait qu'ajouter le keyslot Clevis.
• Fallback automatique sur le mot de passe si le TPM échoue (comportement natif de clevis-initramfs).
• Test à froid du déverrouillage TPM (déchiffrement du JWE) avant de dépendre du reboot.
• Aucune suppression de keyslot ou token tant que la nouvelle méthode n'est pas validée par un redémarrage réussi.

Problèmes futurs possibles et comment les surmonter¶

Le disque redemande le mot de passe après une mise à jour¶

C'est le scénario le plus courant et il est normal. Le PCR 7 change si l'état Secure Boot évolue : mise à jour du firmware/UEFI, mise à jour des clés Secure Boot ou de la dbx (souvent via fwupd), activation/désactivation de Secure Boot.

Solution : déverrouillez au boot avec votre mot de passe (ou recovery key), puis re-liez le TPM à la nouvelle valeur de PCR 7 :

# Réenrôle le binding sur l'état de boot courant
sudo clevis luks regen -d /dev/nvme0n1p3 -s <slot_clevis>
sudo update-initramfs -u -k all

Après une mise à jour de noyau¶

Rien de spécial : update-initramfs est relancé automatiquement par le paquet noyau, et le hook Clevis est ré-embarqué. Comme on est lié au PCR 7 (et pas aux PCR liés au noyau/bootloader), le déverrouillage reste valide.

Je veux revenir en arrière (désactiver l'auto-déverrouillage)¶

Totalement réversible, sans impact sur le mot de passe :

# Lister pour retrouver le slot Clevis
sudo clevis luks list -d /dev/nvme0n1p3
# Retirer le binding (remplacez 3 par le bon slot)
sudo clevis luks unbind -d /dev/nvme0n1p3 -s 3
sudo update-initramfs -u -k all

Le TPM a été réinitialisé / la carte mère a changé¶

Les secrets scellés dans le TPM sont liés à cette puce. Un TPM clear (dans l'UEFI) ou un changement de carte mère invalide le binding. Le disque redemandera alors le mot de passe : déverrouillez avec la phrase de passe, puis refaites un clevis luks bind.

Plan de secours si le boot échoue¶

1. Au prompt de mot de passe (TPM en échec) → tapez votre mot de passe LUKS ou votre recovery key. Vous bootez normalement, puis vous re-liez le TPM.

2. Initramfs cassé / boucle → démarrez sur la clé USB Live Ubuntu, puis chroot :

   sudo cryptsetup open /dev/nvme0n1p3 dm_crypt-0        # mot de passe LUKS
   sudo vgchange -ay
   sudo mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt
   sudo mount /dev/nvme0n1p2 /mnt/boot
   sudo mount /dev/nvme0n1p1 /mnt/boot/efi
   for d in dev proc sys run; do sudo mount --bind /$d /mnt/$d; done
   sudo chroot /mnt
   # --- dans le chroot : revenir à l'état d'avant ---
   sed -i 's/,tpm2-device=auto//' /etc/crypttab
   clevis luks unbind -d /dev/nvme0n1p3 -s 3   # slot Clevis
   update-initramfs -u -k all
   exit
   

   Puis reboot : vous retrouvez le déverrouillage classique par mot de passe.

3. En-tête LUKS corrompu (catastrophe) → restaurez la sauvegarde de l'étape 0 :

   sudo cryptsetup luksHeaderRestore /dev/nvme0n1p3 \
     --header-backup-file /chemin/vers/luks-header-....img
   

Étape 8 (optionnelle) : nettoyage après validation¶

Uniquement après au moins un redémarrage réussi avec Clevis, on peut retirer le token systemd-tpm2 redondant (inutilisé sur Ubuntu). On conserve évidemment le mot de passe (slot 0) et la recovery (slot 1).

# Vérifier d'abord de quel slot/token il s'agit
sudo cryptsetup luksDump /dev/nvme0n1p3
# Retirer le token + keyslot systemd-tpm2
sudo systemd-cryptenroll /dev/nvme0n1p3 --wipe-slot=tpm2

Changer sa phrase de passe LUKS sans casser l'auto-unlock¶

Un jour ou l'autre, il faut faire tourner (ou renforcer) la phrase de passe. Bonne nouvelle : changer le mot de passe n'impacte aucune des configurations ci-dessus.

Méthode sûre : « ajouter puis supprimer »¶

Plutôt que de modifier le slot du mot de passe sur place, on ajoute le nouveau dans un slot libre, on le teste, puis on supprime l'ancien. Ainsi on n'est jamais sans accès valide (on garde en permanence l'ancien mot de passe + la recovery + le TPM).

# 0. Sauvegarde fraîche du header AVANT (parachute)
sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 \
  --header-backup-file ~/luks-header-avant-chgt-$(date +%F).img

# 1. Ajouter le NOUVEAU mot de passe dans un slot libre
#    (invite: ancienne passphrase, puis nouvelle x2)
sudo cryptsetup luksAddKey /dev/nvme0n1p3

# 2. Repérer le nouveau slot (ex. 4) et VÉRIFIER qu'il fonctionne (non destructif)
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -E '^[[:space:]]+[0-9]+: luks2'
sudo cryptsetup open --test-passphrase --key-slot 4 /dev/nvme0n1p3 -v   # tape le NOUVEAU

# 3. Seulement ensuite : supprimer l'ANCIEN slot (ex. slot 0)
#    (invite: "any remaining passphrase" -> tape le NOUVEAU mot de passe)
sudo cryptsetup luksKillSlot /dev/nvme0n1p3 0

Vérifiez ensuite que Clevis fonctionne toujours (test à froid du JWE, cf. section Vérification), puis que le nouveau mot de passe déverrouille au reboot.

⚠️ Le piège des sauvegardes de header (à ne pas manquer)¶

Changer un mot de passe ne change PAS la clé maîtresse du disque. Conséquence critique :

# Nouvelle sauvegarde propre
sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 \
  --header-backup-file ~/luks-header-APRES-chgt-$(date +%F).img
# Contrôle : l'ancien slot ne doit plus apparaître
sudo cryptsetup luksDump ~/luks-header-APRES-chgt-$(date +%F).img | grep -E '^[[:space:]]+[0-9]+: luks2'
# Destruction sécurisée des anciennes
shred -u ~/ancienne-sauvegarde-header.img

Rappel de sécurité lié à l'auto-unlock¶

Avec l'auto-déverrouillage TPM, le disque se déchiffre seul au boot : la phrase de passe LUKS n'est plus une barrière au démarrage pour un voleur qui allume la machine. La protection physique repose alors sur :

• un mot de passe de session fort + verrouillage d'écran (barrière principale à l'allumage) ;
• le scellement PCR 7 + Secure Boot (empêche de booter un autre OS) — renforcé par un mot de passe UEFI (supervisor) ;
• en option, un PIN TPM au binding Clevis (défense en profondeur, mais réintroduit une saisie au boot).

Aide-mémoire¶

Glossaire¶

LUKS2

Linux Unified Key Setup, format standard de chiffrement de disque sous Linux (au-dessus de dm-crypt). La version 2 introduit les tokens, métadonnées qui associent un mécanisme de déverrouillage à un keyslot.

TPM2

Trusted Platform Module 2.0 : puce sécurisée qui peut sceller un secret et ne le libérer que si l'état de démarrage (mesuré dans les PCR) correspond à celui enregistré.

PCR

Platform Configuration Register : registre du TPM mesurant un aspect du démarrage. Le PCR 7 mesure l'état Secure Boot.

Clevis

Cadre de déverrouillage automatique qui « lie » (bind) un keyslot LUKS à une politique (ici le TPM2). Sur Ubuntu, clevis-initramfs ajoute un hook qui tente le déverrouillage au boot, avec repli sur le mot de passe.

initramfs

Système de fichiers minimal chargé avant la racine, chargé de déverrouiller et monter /. Sur Ubuntu, il repose sur initramfs-tools (scripts shell), pas sur systemd — d'où l'incompatibilité avec l'option tpm2-device de crypttab.

JWE

JSON Web Encryption : format dans lequel Clevis stocke le secret scellé au TPM, à l'intérieur du token LUKS.

Ressources¶

• Clevis — dépôt officiel — bind LUKS, pins tpm2/tang/sss.
• Manuel cryptsetup / LUKS2 — référence des commandes et des tokens.
• systemd-cryptenroll — documentation — pour comprendre les tokens TPM2 (et leurs limites hors initramfs systemd).
• Recommandations ANSSI sur le chiffrement — bonnes pratiques de cryptographie.
• Article connexe du wiki : Sécuriser un volume de données avec le chiffrement LUKS sous Linux