Suport technique et veille technologique

LinuxFr.org : les journaux  -  LUKS, TPM et boulette

 -  Avril 2023 - 

Sommaire

• Contexte
• Utilisation
• Au secours, j'ai perdu ma passphrase…

Contexte

À mon taf actuel, on nous demande que les disques durs de données de nos serveurs soient chiffrés. L'objectif est avant tout de se protéger d'un vol d'un disque par un technicien de l'opérateur qui nous héberge, ou d'un mauvais effaçage après recyclage du disque en cas d'incident.
Mais du coup, comment conjuguer ça avec la volonté d'avoir un serveur capable de redémarrer "seul" en cas d'incident ?
Afin d'avoir une solution où la passphrase ne se retrouve pas dans un fichier en clair sur le serveur ou dans l'initramfs, le plus simple reste d'utiliser un élément qui reste quelque peu honni par ses origines : le TPM.

Le TPM est une puce de chiffrement, similaire à une carte à puce, intégrée sur la carte mère des machines (et requis pour Windows), qui permettra de déchiffrer des secrets si l'état d'intégrité de la machine n'est pas altéré. Concrètement, si la signature du firmware, du bootloader ou du noyau n'est pas bonne, les secrets sont inaccessibles. C'est le principe de Secure Boot.
Dans notre cas, l'intérêt est surtout de lier les disques à une machine. La probabilité du vol d'un serveur complet est considérée négligeable face au risque du vol d'un disque.

Utilisation

Du coup, étape 1 : activer Secure Boot. Bonne chance, ça dépend du firmware de chaque machine, et si, en prime, vous avez installé en mode "legacy" au lieu d'UEFI, vous allez avoir une ou deux étapes de souffrance additionnelle (ajouter une partition ESP, changer de grub…)
Par contre, une fois Secure Boot activé, vous avez normalement au boot ceci :

# dmesg | grep secureboot
[    0.000000] secureboot: Secure boot enabled

Ce qui veut dire que le TPM est normalement accessible, en avant pour la suite !

Étape 2 : créer un volume avec LUKS et une passphrase. Cette opération est classique, je ne vais pas tout détailler. Grosso modo: crypsetup luksFormat /dev/mapper/mon-volume
Et notez bien la passphrase, elle vous servira de clé de secours en cas de perte du TPM (imaginez un instant que votre hébergeur ait une fuite sur son refroidissement et que votre carte mère soit sous l'eau…)

Étape 3 : installer les éléments requis pour avoir le TPM fonctionnel. Dans mon cas, il s'agit d'un serveur en bullseye, or il est bien plus simple d'utiliser le systemd de bookworm pour ce qui suit (il faut beaucoup plus bidouiller cryptsetup pour qu'il utilise le TPM), du coup, activons les backports et apt install -t bullseye-backports systemd. En complément, pour le TPM : apt install libtss2-esys-3.0.2-0 libtss2-rc0
Désormais, la commande systemd-cryptenroll --tpm2-device=list devrait lister un TPM disponible pour ce qui suit

Étape 4 : enroller le TPM dans le luks. C'est facile, systemd-cryptenroll s'en charge: systemd-cryptenroll --tpm2-device=/dev/tpmrm0 --tpm2-pcrs=7 /dev/mapper/mon-volume
Bien sûr, la passphrase sera demandée pour pouvoir ajouter le TPM.

Étape 5 : enjoy and profit.
Pour vérifier que ça fonctionne, il suffit de faire /usr/lib/systemd/systemd-cryptsetup attach volume-clear /dev/mapper/mon-volume - tpm2-device=/dev/tpmrm0
Normalement, le volume sera accessible en clair sur /dev/mapper/volume-clear.
Pour le monter au boot, il suffit alors d'ajouter dans /etc/crypttab quasiment ce que l'on vient de saisir, à savoir:
volume-clear /dev/mon/volume - tpm2-device=/dev/tpmrm0

Facile, n'est-ce-pas ?

Au secours, j'ai perdu ma passphrase…

Ça peut arriver à tout le monde, donc pour votre sécurité, j'ai décidé de supprimer ma passphrase et pourtant de réussir à en rajouter une nouvelle grâce à la clé du TPM… (Oui bon ça arrive à tout le monde une fausse manip, ça va, puis j'ai fait ça en recette, pas en prod)

Tout d'abord, un rappel : comment marche LUKS. C'est très simple, un en-tête est ajouté sur le volume, qui contient un ensemble de données en JSON (sigh). Dans ces données se trouvent surtout des slots. Chaque slot permet de déchiffrer une clé de volume, qui elle permet de déchiffrer les données du reste du disque. Dans la procédure qui précède, nous avons donc deux slots : le slot 0 avec notre passphrase, le slot 1 pour le TPM.
On peut donc avoir une dizaine de passphrases différentes, les révoquer… sans pour autant rechiffrer tout le disque, heureusement.
Par contre si on fuite la clé du volume, là effectivement il va falloir travailler un peu plus, mais c'est pas le sujet ici.
Historiquement, il était d'ailleurs assez simple de récupérer la clé du volume sur un volume déjà monté, mais depuis un certain temps elle est stockée dans un keyring noyau interdit d'accès à l'espace utilisateur, il va donc falloir faire autrement.

systemd-cryptenroll permet d'ajouter une passphrase, un TPM, un FIDO ou autre, mais il faut systématiquement lui donner une passphrase existante pour accéder au volume. Il refuse d'utiliser un TPM pour ajouter une passphrase, limite d'implémentation je suppose.
MAIS… rien ne nous interdit d'aller avec gdb voir la clé utilisée pour déverrouiller le volume avec le TPM, non ?

C'est parti, apt install gdb systemd-dbgsym…

sudo gdb /usr/lib/systemd/systemd-cryptsetup

Quand on regarde le code source de systemd et le code de la libcryptsetup, on voit une fonction au nom fort tentant qui est utilisée pour ouvrir le volume : crypt_activate_by_passphrase.
Cf. https://github.com/systemd/systemd/blob/v252/src/cryptsetup/cryptsetup.c#L1177-L1186

Un breakpoint bien placé devrait nous aider…
b crypt_activate_by_passphrase
r attach volume-test /dev/mapper/mon-volume - tpm2-device=/dev/tpmrm0

Et hop, notre breakpoint s'active ! Par contre j'ai pas les symboles de debug de libcryptsetup moi…
up
Et je suis dans le code de systemd…
p base64_encoded
Et voilà la passphrase. Je n'ai plus qu'à l'utiliser pour ajouter une nouvelle passphrase, et le tour est joué.

Commentaires : voir le flux Atom ouvrir dans le navigateur

par Pinaraf