systemd-cryptenroll et TPM2 : déchiffrement automatique LUKS

Le chiffrement LUKS protège les disques au repos. Mais comment déchiffrer au boot d'un serveur sans frappe humaine ? La passphrase tapée par sysadmin SSH après chaque reboot ne tient pas pour un parc edge ou un serveur en colocation. Les clés stockées en clair dans /etc/crypttab annulent l'intérêt du chiffrement. Les solutions tierces (Tang/Clevis, Mandos) ajoutent une infrastructure complète.

systemd 248+ propose systemd-cryptenroll qui scelle la clé LUKS dans le TPM2 de la machine. Le déchiffrement est automatique au boot, à condition que l'état de la machine (Secure Boot, mesures kernel, initramfs) corresponde à ce qui était attendu. Si quelqu'un sort le disque ou modifie le boot, le TPM refuse, le déchiffrement échoue.

Pour les serveurs avec TPM2, c'est l'option simple et propre.

• Le problème : déchiffrer LUKS sans intervention humaine
• TPM2 et sealing : ce que la puce garantit
• systemd-cryptenroll en pratique
• Mesures PCR et politiques de sealing
• Cas d'usage : edge, colocation, root encryption
• Récupération et perte du TPM
• Comparaison avec Tang/Clevis et Mandos
• Limites et signaux d'alerte

LUKS chiffre une partition. Au boot, la clé est demandée. Plusieurs options pour fournir cette clé sans humain au clavier.

Passphrase fixe stockée. Inutile : si la clé est sur le même disque, autant ne pas chiffrer. Si c'est sur un autre disque, on déplace le problème.

Demande SSH au boot via dropbear. Demande qu'un admin se connecte SSH après reboot pour saisir la passphrase. Ne tient pas pour un parc.

Tang/Clevis. Service réseau distant qui sert un fragment de clé. Marche bien mais demande infrastructure dédiée et lien réseau opérationnel.

TPM2 sealing. La clé est scellée dans le TPM2 de la machine, libérée seulement si l'état système correspond à un état attendu. Pas de réseau, pas d'humain, pas de stockage externe.

Cette dernière option est la plus simple opérationnellement. C'est ce que systemd-cryptenroll --tpm2-device automatise.

Un TPM2 (Trusted Platform Module v2.0) est une puce dédiée présente sur la majorité des cartes mère serveurs depuis 2016. Elle expose :

• Stockage cryptographique non-extractible.
• Génération de clés (RSA, ECC).
• Mesures cryptographiques de l'état du système (PCR, Platform Configuration Registers).
• Sealing : on confie un secret au TPM, le TPM le restituera seulement si certaines mesures sont conformes.

Le sealing TPM2 fonctionne ainsi :

1. La machine boot. Chaque étape (UEFI firmware, bootloader, kernel, initramfs) génère une mesure cryptographique enregistrée dans des PCR du TPM.
2. Ces mesures sont déterministes : si le kernel n'est pas modifié, la mesure reste la même.
3. systemd-cryptenroll demande au TPM de sceller une clé LUKS avec une politique : "libère cette clé seulement si PCR 0,2,7 ont les valeurs X, Y, Z".
4. Au boot suivant, si rien n'a changé, le TPM libère la clé. systemd l'utilise pour déchiffrer LUKS. Si quelque chose a changé, le TPM refuse.

Une attestation locale, sans tiers.

Prérequis : kernel récent avec tpm2-tss activé, paquet systemd-tpm2 ou équivalent installé, TPM2 présent dans le firmware.

Vérifier le TPM :

sudo tpm2_getcap properties-fixed | head
# Doit retourner les caractéristiques de la puce

Enroll d'une clé TPM2 sur une partition LUKS existante :

sudo systemd-cryptenroll --tpm2-device=auto \
                         --tpm2-pcrs=0+2+7 \
                         /dev/nvme0n1p3

/dev/nvme0n1p3 est la partition LUKS, déjà chiffrée et accessible (passphrase humaine demandée pour autoriser l'enroll).

Les PCR 0+2+7 mesurent :

• PCR 0 : firmware UEFI (BIOS).
• PCR 2 : OptionROM, drivers PCIe.
• PCR 7 : Secure Boot policy et certificats.

Combinaison classique pour vérifier que le firmware et la chaîne de boot restent intacts.

Configurer crypttab pour utiliser le TPM2 :

# /etc/crypttab
nvme0n1p3 UUID=... none tpm2-device=auto

Régénérer l'initramfs :

sudo update-initramfs -u
# ou sur Fedora/RHEL:
sudo dracut -f

Reboot. Si tout est correct, plus de prompt de passphrase, le déchiffrement est automatique.

Le choix des PCR conditionne la rigueur de la politique.

Combinaisons recommandées :

• PCR 7 seul : minimaliste, valide la policy Secure Boot. Survit aux upgrades kernel.
• PCR 0+2+7 : durci, valide aussi le firmware. Casse à un BIOS update.
• PCR 0+2+7+11 : très durci avec UKI signé. Casse à toute modif kernel/initramfs (donc à chaque package update qui régénère l'initramfs).

Plus on cible large, plus la politique casse souvent. Plus on cible étroit, plus un attaquant peut modifier l'environnement sans alerter le TPM. Compromis pratique : PCR 7 sur des serveurs prod où on veut survivre aux updates, PCR 0+2+7 sur des appliances très sensibles.

Serveurs en colocation. On loue de la baie chez un opérateur tiers. Le risque : un employé malveillant ou un voleur sort le disque, accède aux données. Avec LUKS + TPM, le disque sorti est une brique chiffrée illisible.

Sites edge sans présence humaine. Un boitier dans une agence ou un site industriel. Reboot après coupure électrique sans intervention. TPM2 permet le déchiffrement automatique sans humain.

Root encryption sur portables admin. Plus simple que TPM + PIN, mais variant. La passphrase humaine reste préférable sur portable (vol). TPM combiné à un PIN court via --tpm2-with-pin=yes est un bon compromis.

Serveurs cloud confidentiels. Combinaison TPM2 + Confidential Computing (TDX, SEV-SNP). Voir aussi KubeVirt v1.8 HAL qui supporte ces backends.

Perte du TPM. Si la carte mère meurt et qu'on remplace, le TPM neuf a des PCR différentes. Le sealing échoue. La passphrase humaine de secours reste valable : systemd-cryptenroll n'efface pas les keyslots existants par défaut. On peut booter avec passphrase, ré-enroller le nouveau TPM.

Recovery key. Toujours générer une recovery key longue, stockée hors site (coffre, gestionnaire de mots de passe enterprise). En cas de perte TPM + oubli passphrase, c'est le dernier recours.

sudo systemd-cryptenroll --recovery-key /dev/nvme0n1p3
# Affiche une clé longue à stocker

Migration. Si on change le serveur de site ou de matériel, la nouvelle config TPM (PCR différents) ne déchiffre plus. Re-enroll après migration. Documenter le runbook.

Audit logs. Le TPM génère des événements à chaque mesure. journalctl -u systemd-cryptsetup@* montre ce qui s'est passé au boot. Garder ces logs pour les forensics.

Tang/Clevis a l'avantage de ne pas dépendre du TPM, mais nécessite un service réseau Tang opérationnel. Si le serveur Tang tombe, le boot échoue. Pour un cluster avec Tang en HA, marche bien. Pour un boitier edge isolé, TPM tient mieux la coupure réseau.

Mandos est plus rare en prod française.

TPM compromis. Très rare en pratique, mais des CVE TPM ont existé (TPM-Fail en 2019). Garder firmware TPM à jour. Surveiller les avis sécurité du fabricant (Intel, Infineon, ST Micro).

Boot non Secure Boot. Si Secure Boot est désactivé dans le BIOS, PCR 7 est différent, l'attestation peut casser ou être permissive. Toujours activer Secure Boot pour un sealing significatif.

Updates kernel cassent PCR 11. Si on inclut PCR 9 ou 11 dans la politique, chaque update kernel demande un re-enroll. Automatiser dans le pipeline de mise à jour, ou éviter ces PCR.

Doc opérateur. Documenter clairement la procédure de re-enroll après update firmware ou kernel. Sans runbook, le sysadmin de garde panique au prochain reboot.

Pas un substitut à la sécurité périmètre. Un attaquant qui a un accès root sur la machine en marche peut copier les données accessibles. TPM protège uniquement le disque au repos.

Compatibilité Boot UEFI uniquement. Pas de support TPM2 sur du legacy BIOS. Les serveurs doivent être en UEFI.

TPM saturé. Le TPM a un nombre limité de slots. En général jamais un problème, mais documenté pour les très gros déploiements multi-disques chiffrés.

systemd-cryptenroll TPM2 convient aux boitiers en colocation, aux serveurs edge et aux workloads à conformité forte. Le déploiement initial prend quelques minutes par hôte : reboots automatiques sans intervention humaine, disque inutilisable s'il quitte le serveur. Pour du parc isolé où on veut éviter Tang/Clevis, c'est l'option la plus simple, à condition de documenter le runbook de re-enroll. Tenir ce runbook à jour et rejouer les re-enroll après chaque update kernel ou firmware pèse vite ; cette charge se sort de l'équipe si besoin.

• systemd-cryptenroll man page : référence officielle des options.
• TPM 2.0 Library Specification - TCG : spec TPM 2.0.
• systemd documentation - TPM2 PCR Registry : référence des PCR mesurées par systemd.
• LUKS2 reference : format LUKS2 utilisé.
• Red Hat - Disk encryption with TPM2 : guide pratique RHEL.
• Lennart Poettering - "TPM2 in Linux" : vision systemd sur le boot vérifié.