Utilisation d'une phrase de passe unique pour déverrouiller plusieurs disques chiffrés au démarrage
Ma machine a un SSD, où j'ai installé le système et un disque dur, que j'utilise comme stockage pour les fichiers volumineux et/ou rarement utilisés. Les deux sont cryptés, mais j'ai choisi d'utiliser la même phrase secrète pour eux. Le SSD est monté à / et disque dur à /usr/hdd (les utilisateurs individuels ont chacun un répertoire et peuvent créer des liens symboliques comme ils le souhaitent depuis le répertoire personnel).
Lorsque le système est démarré, il demande immédiatement une phrase secrète pour le SSD, et quelques secondes plus tard pour celle pour le disque dur (il est monté automatiquement). Étant donné que les deux mots de passe sont identiques, existe-t-il un moyen de configurer le système pour qu'il ne demande qu'une seule fois?
Distributions basées sur Debian:
Debian et Ubuntu livrent un script de mise en cache des mots de passe decrypt_keyctl avec cryptsetup package.
decrypt_keyctl le script fournit le même mot de passe à plusieurs cibles LUKS chiffrées, vous évitant de le taper plusieurs fois. Il peut être activé dans crypttab avec l'option keyscript=decrypt_keyctl. Le même mot de passe est utilisé pour les cibles qui ont le même identifiant dans champ du fichier clé. Au démarrage, un mot de passe pour chaque identifiant est demandé une fois.
Un exemple crypttab:
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
part2_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
Le script decrypt_keyctl Dépend du package keyutils (qui est uniquement suggéré, et donc pas nécessairement installé).
Après avoir mis à jour votre cryptab, vous devrez également mettre à jour initramfs pour appliquer les modifications. Utilisez update-initramfs -u .
Le fichier Lisez-moi complet pour decrypt_keyctl se trouve dans /usr/share/doc/cryptsetup/README.keyctl
Malheureusement, cela ne fonctionne actuellement pas sur les systèmes Debian utilisant systemd init à cause de un bug (les autres systèmes d'initialisation ne devraient pas être affectés). Debian page de manuel de crypttab suggère comme solution de contournement d'utiliser l'option initramfs pour forcer le traitement à l'étape initramfs du démarrage.
Distributions qui ne fournissent pas de script decrypt_keyctl:
Si decrypt_keyctrl n'est pas fourni par votre distribution, l'appareil peut être déverrouillé à l'aide d'un fichier de clés dans le système de fichiers racine chiffré. Cela lorsque le système de fichiers racine peut être déverrouillé et monté avant de tout autre appareil crypté.
LUKS prend en charge plusieurs emplacements de clé. Cela vous permet également de déverrouiller l'appareil à l'aide d'un mot de passe si le fichier de clé n'est pas disponible/perdu.
Générez la clé avec des données aléatoires et définissez ses autorisations en lecture seule par le propriétaire pour éviter de la divulguer. Notez que le fichier de clé doit être sur la partition racine qui est déverrouillée en premier.
dd if=/dev/urandom of=<path to key file> bs=1024 count=1 chmod u=rw,g=,o= <path to key file>Ajoutez la clé à votre appareil LUKS
cryptsetup luksAddKey <path to encrypted device> <path to key file>Configurez crypttab pour utiliser le fichier de clé. La première ligne doit être le périphérique racine, car les périphériques sont déverrouillés dans le même ordre que celui indiqué dans crypttab. Utilisez des chemins absolus pour les fichiers clés.
<target> <source> <keyfile> <options> root_crypt /dev/disk/... none luks part1_crypt /dev/disk/... <path to key file> luks
Une autre option consiste à utiliser le /lib/cryptsetup/scripts/decrypt_derived script, qui fait également partie de cryptsetup dans Debian/Ubuntu.
Au lieu de mettre la clé en cache, vous utilisez la clé de volume d'un disque comme mot de passe supplémentaire pour le deuxième disque. Cela nécessite l'ajout d'un deuxième mot de passe au deuxième (et troisième, etc.) disque crypté, mais LUKS le prend en charge. Cette solution fonctionne donc également si vos multiples disques chiffrés n'utilisent pas le même mot de passe.
Exemple pour ajouter la clé de sda6crypt à sda5:
Ajoutez la clé de volume de sda6crypt comme mot de passe supplémentaire pour sda5:
mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo
Configurez sda5crypt pour qu'il soit déverrouillé automatiquement dans /etc/crypttab
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
Cela utilise un canal nommé (fifo) pour passer la clé afin d'éviter d'avoir à stocker la clé de volume dans un fichier temporaire sur le disque.
L'option keyscript ne fonctionne que si crypttab est traité par les outils cryptsetup d'origine de Debian, la réimplémentation systemd ne la prend pas actuellement en charge. Si votre système utilise systemd (qui est la plupart des systèmes), vous avez besoin de l'option initramfs pour forcer le traitement à se produire dans initrd par les outils cryptsetup, avant le démarrage de systemd.
Voici ma solution de contournement sur Debian, étant donné le bogue référencé ci-dessus par @sebasth.
Ma configuration est légèrement différente. J'ai une partition racine chiffrée et un tas de disques de raid. Pour moi, j'ai dû ajouter une option initramfs à la crypttab:
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
Cela indique à update-initramfs que je veux que ces entrées crypttab soient montées dans les initramfs. J'ai vérifié mon crypttab en exécutant
cryptdisks_start part1_crypt
cryptdisks_start part2_crypt
Notez que mes disques de raid sont des dm-crypt simples. Cela signifiait que je ne pouvais pas utiliser la méthode luks keyfile qui contourne le bogue keycript de systemd. Pour dm-crypt simple, je devrais stocker la phrase secrète en texte clair.
Les disques chiffrés doivent être montés avant update-initramfs est exécuté; sinon, cela générera des erreurs. J'ai dû chercher les lignes suivantes lors de la construction de mes initramfs:
update-initramfs -k -u -v | grep 'keyctl'
qui montrait les deux fichiers suivants:
/bin/keyctl
cryptkeyctl
étant ajouté aux initramfs.
Enfin, j'ai dû désactiver systemd pour gérer mon crypttab, afin de gérer le bogue référencé ci-dessus: systemd ne prend pas en charge l'option keyscript dans crypttab. Pour cela, j'ai ajouté l'option noyau
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"
dans/etc/default/grub et a exécuté update-grub. systemd ignore maintenant crypttab, et toutes les partitions chiffrées sont chargées dans les initramfs.
Parce que j'ai une partition racine chiffrée, cryptroot ne semble pas mettre en cache ma clé. Cela signifie que je dois saisir mon mot de passe deux fois; un pour la partition racine et une fois pour ma baie de raid.