# Author: Thibaud "thican" CANALE
# thican [at] thican [dot] net
# Date: 2014-08-17
# Update: 2020-09-29
# CC by-sa

Vous avez vu un peu toutes les déclarations sur l’espionnage de masse avec les méchants chinois du FBI, toussa toussa ? Aujourd'hui, nous allons apprendre à chiffrer vos partitions, pour y stocker votre système d'exploitation et vos données.

Euh, mais attends, « pourquoi ? » d'abord s’il te plaît

Petit rappel : le chiffrement de vos données permet de « protéger » vos données sur deux types d'action :

Remarque ÜBER importante : tel que démontré par de nombreux papiers, l'intégrité (“malleability” en anglais) n'est pas assurée avec certains méthodes d'enchaînements, comme CBC (Cipher-Block Chaining). N'utilisez plus CBC, utilisez à la place XTS (ciphertext stealing), tel que disponible avec cryptsetup (méthode qui est devenue par défaut), car même sans être infaillible, il permet de “mitiger” le problème (une véritable solution serait de signer les données, mais ceci est beaucoup plus gourmand en ressources mémoire et calculs).

Enfin, comme vous l’avez peut-être remarqué, j’ai mis entre guillemets le mot « protéger », car il faut être conscient qu’avec les moyens à disposition de nos jours (puissance de calcul, failles et erreurs humaines), aucun chiffrement n’est inviolable. Et souvent, la faille, c’est vous.

… Mais avant toute chose …!

Je ne suis pas responsable de ce qui peut arriver

Le titre est on ne peut plus clair, je ne pourrai pas être tenu responsable si le système de chiffrement que vous tentez de mettre en place à travers ce tutoriel est déjoué, ou si vous perdez des données.
Avant même de continuez de lire ce tutoriel, vous devriez vous renseigner sur quelques bases en cryptographie, et avoir des connaissances assez correctes pour être à l’aise dans l’utilisation d’un terminal.
Et même durant la lecture de ce tutoriel, vous devriez rechercher des informations sur le choix de certaines options ; ce que je précise ici concerne des choix par défaut qui offrent une bonne sécurité, sans trop de compromis.

Il est à souligner que perdre la clef de chiffrement revient à perdre vos données. Sinon, la remarque est plutôt simple, si vous pouvez récupérer vos données sans connaitre la clef de déchiffrement, alors il en sera de même pour ceux qui tenterons d’y accéder. On appelle ça « décrypter », ce qui veut dire « déchiffrer sans connaître la clef », c’est le seul cas où ce mot existe (et donc, « crypter » est un non sens car ça voudrait dire « chiffrer sans clef », or il est nécessaire d’utiliser une clef pour chiffrer).

Et enfin, je ne suis aussi par responsable si vous perdez d’autres données car vous auriez par exemple écrasé la mauvaise partition. Faire des sauvegardes est essentiel (plus facile à dire qu’à faire correctement, malheureusement), car il est possible de faire de mauvaises manipulations. De plus, je donne dans ce tutoriel des exemples pour les supports de stockage, qui ainsi ont grande chose de ne pas correspondre à votre système. Que je le précise ou pas, vous ne devriez nullement copier/coller les commandes sans adapter à votre système.
Votre inattention vous coûtera l’intégrité de vos données, et sans sauvegarde correcte, vous allez devoir en faire une croix dessus.

Bien, maintenant que nous savons pourquoi et que nous allons faire attention, entrons dans les détails.

Let’s go!

Dans ce tutoriel, le but est de pouvoir chiffrer le contenu de notre support mémoire (i.e disque dur, SSD, carte mémoire, etc) ; le plus simple est d’utiliser un conteneur LVM pour les données et de chiffrer le tout avec un conteneur LUKS.
Par conséquent, il n'y a qu’un seul chiffrement/déchiffrement, ce qui est bien plus simple.
En extra, si vous le souhaitez et que vous en avez les moyens, nous allons aussi profiter de tutoriel pour mettre en place un système RAID1 (“Redundant Array of Inexpensive Disks” en mode “mirroring”) en sous couche du chiffrement, ce qui va permettre de créer un support de données qui peut résiter à un défaut matériel jusqu’à un support restant (exemple, si vous avez trois disques en RAID1, deux peuvent tomber en panne). Pour celà, il vous faudra vous munir de deux supports mémoire ou plus, de préférence de taille identique. Si leur taille ne sont pas identique, il faudra bien veiller lors de la création des partitions d’avoir deux partitions de taille identique.

Au cours de ce tutoriel, nous allons voir plusieurs cas de figures concernant le déchiffrement de notre système, lors du démarrage :

  1. soit vous avez un accès physique à la machine avec clavier et vous pouvez y brancher un support externe, comme une clef USB (recommandé) ;
  2. ou soit vous n’avez qu'un accès distant (comme un serveur par exemple), et là la clef devra se trouver sur le même support mémoire que votre partition.
    note : il existe des alternatives comme utiliser un service SSH lors de l’initramfs (système qui sert à démarrer le vrai système) pour ainsi fournir la passphrase de déchiffrement plutôt que de la stocker sur le support, mais nous n’aborderons pas ce point car plus complexe.

Tout de suite, on peut remarquer que le cas de figure 2 est beaucoup moins sécurisé que le cas de figure 1. Vu que nous n'avons pas d’accès physique, pour y brancher tout autre support mémoire et apporter notre clef secrète ainsi que notre noyau, il faut donc malheureusement créer une partition qui contiendra donc notre clef et notre noyau, et surtout qui ne sera pas chiffrée. Le seul avantage de ce cas de figure est de pouvoir démarrer le système automatiquement, et de garder en sécurité le système (relativement) en supprimant (de façon efficace) la clef.

Remarque : soyez-en bien conscient, la faille est béante ; ce système n'est pas là pour protéger vous et vos données, vu que mettre sur le même support les données chiffrées et la clef n’est pas sécurisé, mais il est pour unique but de faire perdre du temps, mais très peu.

Maintenant que nous avons compris quelques détails, commençons par préparer le support.

Préparation du ou des supports de stockage

Si vous êtes dans le cas où vous souhaitez un support RAID1, nous allons créer autant de partitions que de supports, toutes de taille identique pour rappel, sur les supports en question. Sinon, un seule partition sera nécessaire pour LUKS.

Avec votre outil préféré (je conseille gptfdisk), il faut « découper en partitions » vos supports (le mot « partitionner » n’existe pas). Si vous êtes dans le cas de figure 1, seule la seconde partition sera nécessaire (ou faites selon vos souhaits).

Dans le cas de figure 2, il estnécessaire de créer une (petite) partition d’amorçage – /boot – en plus de la partition pour les données chiffrées ; pour /boot, et au cas où vous souhaiteriez être conforme avec UEFI, je vous recommande une taille de 512 Mio.
Si vous faites une partition trop petite et venez à manquer de place dedans, vous devrez refaire un partitionnement, et donc déplacer vos fichiers temporairement, ce qui est long et fastidieux, alors évitez de vous faire perdre votre propre temps, par expérience ces 512 Mio seront plus que suffisant.
Pour être conforme UEFI, le code de ce support devra être "EF00", nommé "EFI System", et être formatté avec le système de fichier FAT32. Ces deux derniers points ne sont nécessaires que si vous souhaitez utiliser le système de démarrage UEFI de votre carte mère, le remplaçant du système BIOS. À terme (Intel parle de 2023), ce dernier ne sera plus du tout supporté. À l’heure où j’ai rédigé initialement ce tutoriel, en 2014, j’avais continué d’utiliser BIOS, avec l’utilisation de LILO (voir la partie "Bootloader"). Ceci fonctionne encore, mais le fait de réserver cette partition de 512 Mio vous permettra de pouvoir reprendre cette partie sans devoir retoucher à votre partition principale. Ainsi, nous éviterons de perdre énormément de temps, et de se créer des soucis. J’ai personnellement adopté le système UEFI, je mettrai de nouveau à jour ce tutoriel une prochaine fois.

Pour créer des partitions sur un support donné (prenons exemple /dev/sda), appelez l’utilitaire avec la commande suivante :
gdisk /dev/sda
Note : tant que vous n’utilisez pas la commande "w" dans l’utilitaire, aucune donnée ne sera modifiée (sauf exceptions), et vous pourriez ainsi reprendre votre schéma de partitionnement autant de fois que nécessaire.


Dans le cas où vous utilisez un système RAID1, il n’est pas nécessaire de recréer la première partition sur l’ensemble de vos autres supports, par contre, pour vous faciliter la maintenance, entrez le même numéro pour cette partition ("2" en temps normal).

Remarque : évitez au maximum de donner des infos sur le contenu de votre disque, donc, pas de label comme « cypher h4ck3r », et concernant le type, “Linux filesystem” par défaut fonctionne très bien.

Vérifions en lançant ls -l /dev/sd* pour voir si le système a bien mis à jour les partitions, et voir ainsi si le nombre de partitions correspond (de la forme /dev/sdXY, avec X une lettre, et Y un chiffre). Si oui, continuons. Si non, tentez un redémarrage, ou reprenez cette étape.

Avant de continuer, prenez bien soin de noter le chemin vers la partition qui contiendra le support LUKS ; par défaut, si vous avez créé deux partitions sur le support /dev/sda, il doit exister /dev/sda2, et doit être pratiquement autant volumineux que votre support entier. Pour simplifier la rédaction de ce tutoriel, j’y ferai référence avec le mot "$SUPPORT_LUKS". J’insiste toutefois en faisant bien attention à ne pas vous trompez de partition, si vous avez d’autres supports, pour éviter d’écraser d’autres données.

Si vous n’êtes pas concerné par l’utilisation du RAID1, vous pouvez directement vous rendre ai vif du sujet, à l’étape « le conteneur LUKS ».

Du stockage redondant avec RAID1

Si vous avez bien suivi les précédentes instructions, vous devriez avoir plusieurs supports ayant une partition de taille identique sur chacun de ces supports ; ceci est requis. Sinon, reprenez l’étape précédente.

Encore pour simplification de ce tutoriel, je vais considérer que les supports pour ce RAID1 sont /dev/sda, /dev/sdb, /dev/sdc, etc, et que les partitions en question sont donc respectivement /dev/sda2, /dev/sdb2, /dev/sdc2, etc.
Demandez de l’aide à quelqu’un si vous avez un doute. Je rappelle que je ne peux être nul doute tenu responsable de la perte de vos données (encore un rappel, l’utilisation d’un support RAID1 ne vous dispense pas de faire des sauvegardes).
Encore un autre point, je n’entre guère dans les détails concernant le support par votre système et votre noyau d’un système RAID1 ; en résumé, vous allez avoir besoin du paquet mdadm dans votre système, et de l’option CONIG_MD_RAID1 en dur dans votre noyau. Sans celà, vous ne pourrez guère démarrer votre nouveau système.

Maintenant que nous avons notre liste de partitions, prenons le simple exemple où vous en avez trois : sda2, sdb2 et sdc2.
Petite mise en garde, la synchronisation prend du temps, il semble que l’outil mdadm va synchroniser l’ensemble des supports même pour la création d’une nouvelle grappe (“array” en anglais).
À partir de votre liste, nous pouvons donc utiliser le « sucre syntaxique » /dev/sd[abc]2 comme dans la commande ci-dessous, tel que l’exemple fourni par le manuel de mdadm(8). Il existe d’autres options, comme l’utilisation de l’option --name, je vous invite donc à lire le dit manuel (si vous utilisez cette option --name, vous pourrez retrouver un lien vers votre support dans le répertoire "/dev/md/", ce qui est plus parlant que le nombre /dev/mdX qui en fonction du nombre d’autres grappes dans le système peut ne pas avoir le même numéro entre chaque redémarrage).
mdadm --create /dev/md0 --level=1 --raid-devices=3 /dev/sd[abc]2

Enfin vous voici avec un support RAID1, pratiquement prêt à l’emploi, car il va se synchroniser.
Vous pouvez suivre l’avancement de cette synchronisation des supports de votre grappe en lisant le fichier "/proc/mdstat". Je vous conseille de patienter jusqu’à la fin de la synchronisation avant de continuer. Profitez-en pour vous renseigner sur comment monter, maintenir et restaurer votre grappe, car ceci sera nécessaire avant de pouvoir déchiffrer son contenu. Encore une fois, il vous suffit de lire mdadm(8).
Le chemin que vous allez donc utiliser pour le reste de ce tutoriel est celui indiqué dans la commande, il s’agit dans cet exemple de "/dev/md0" ; ceci est votre nouvelle valeur pour "$SUPPORT_LUKS".

Voilà pour le support RAID1, continuons après ce détour avec le vif du sujet !

Ze vif ofe ze sujet : le conteneur LUKS

Pour avoir un conteneur LUKS (Linux Unified Key Setup), il faut une passphrase ; c'est comme un mot de passe, mais en plus long … Cette passphrase, nous allons la stocker dans un fichier chiffré pour la « protéger » (concernant le cas de figure n°2, je détaillerai plus bas le changement).
Avant de continuer, la question suivante pourrait se détacher : « pourquoi utiliser une clef chiffrée pour déchiffrer le conteneur LUKS, plutôt que d'utiliser la passphrase directement ? »
Voici quelques arguments :

Cette commande peut paraître assez longue lors de son exécution, car il faut avoir généré de l'entropie pour permet au « générateur de nombres pseudo-aléatoires » (PRNG) d'avoir les données les plus « aléatoires » possible (à ne pas confondre avec un « générateur de probabilités infinies », qui lui requiert des coordonnées).
Prenons en une quantité de 255 octets.
head -c 255 /dev/random | base64 -w 0 - | tr -d '\n' | gpg --symmetric --armor - > clef_luks.gpg
Remarque : pour éviter des soucis avec les pipes |, la commande tr -d '\n' permet de supprimer les éventuels retours à la ligne qui pourraient nous poser problème.
Autre remarque : le choix entre /dev/random et son homologue /dev/urandom n'a ici que peu d'importance, suivant l'importance que vous lui accordez.

Créons maintenant notre conteneur LUKS, avec "luksFormat"
gpg --decrypt clef_luks.gpg | cryptsetup --key-file - luksFormat $SUPPORT_LUKS

Note : Si quelque chose n'a pas fonctionné, vous pouvez rajouter l'option --verbose, juste après cryptsetup.
Remarques : Je vous conseille de laisser les valeurs de --cyper et --hash par défaut. Toutefois, je vous conseille, si votre version le permet, d’utiliser LUKS2, avec --type luks2.
Dans les anciennes versions de cryptsetup, comme la version 1.4.3, le mode de chaînage "CBC" est utilisé par défaut. Par défaut avec la version 2.X, le mode par défaut est "XTS".
Pour toutes ces remarques, vous pouvez vérifier quelles sont les valeurs par défaut avec la commande cryptsetup --help, et voir les algos de chiffrement et de hash en lisant le fichier "/proc/crypto".

Félicitations, vous venez de créer votre conteneur LUKS. :-)

Nous pouvons toutefois vérifier le résultat, avec cryptsetup luksDump $SUPPORT_LUKS et ainsi vérifier des informations, comme le chiffrement utilisé (“Cipher name”), le mode (“Cipher mode”), la méthode utilisée pour le hash (“Hash spec”), et enfin regarder quels sont les compartiments (“slot”) occupés.
De même, il peut être judicieux de faire une sauvegarde de l'en-tête LUKS pour la mettre dans un endroit sûr, grâce à l'action “luksHeaderBackup” (lisez cryptsetup(8) pour plus d'infos) ; ceci n'a pour but que de pouvoir récupérer le contenu d'un conteneur LUKS, si l'en-tête de se dernier s'est retrouvé écrasé ou supprimé (la clef que nous stockons ne permet uniquement que de déchiffrement l'un des compartiments de l'en-tête LUKS, qui ces derniers permettent de déchiffrer les données).

Montons le tout de suite dans le système, comme ceci :
gpg --decrypt clef_luks.gpg | cryptsetup --key-file - open $SUPPORT_LUKS vador

Nous voilà donc avec le périphérique LUKS monté dans /dev/mapper/vador
Note : le nom "vador" importe peu, vous pouvez lui donner le nom que vous souhaitez, par contre le chemin sera donc différent, tout en restant dans le répertoire "/dev/mapper/".
Note : je suis sûr que vous avez compris la référence "Luks/Vador", non ? … Pas du tout ? Tant pis …
Considérez le comme une partition vide (un “block device”), donc actuellement nous ne pouvons pas y stocker de fichiers directement (comme dans un point de montage dans votre système de fichiers) ; et puis nous sommes limité à une seule partition, donc un seul système de fichiers, or nous en voulons plusieurs, comme par exemple séparer /home et /var de /, la racine.

Voilà donc qu'entre en jeu le conteneur LVM (Logical Volume Manager).

Les volumes virtuels avec LVM

Nous allons donc créer des "groupes de volumes" (VG), avec les différentes commandes que voici (adaptez bien sûr à vos besoins)

Initialiser et créer le groupe de volume (on peut se permettre de ne pas exécuter pvcreate, comme l'indique la documentation) :
Note : oui, le nom "lvm-vador" est spécifique pour notre exemple, vous pouvez utiliser un autre nom, surtout que celui restera, donc choisissez quelque chose de plus parlant pour vous.
vgcreate lvm-vador /dev/mapper/vador

créer les "partitions" à l'intérieur du volume :
lvcreate --name root --size 20G lvm-vador
lvcreate --name swap --size 2G lvm-vador
lvcreate --name var --size 20G lvm-vador
lvcreate --name home --extents 100%FREE lvm-vador

Oui, pour la dernière, nous n'utilisons pas "--size", mais "--extents 100%FREE" pour prendre toute la place restante.

Encore une fois, félicitations ! Pour faire un parallèle avec une installation sans chiffrement, c'est comme si vous venez à peine de créer les partitions. Mais vous voilà avec un système chiffré, ce n'est pas rien.

Admirez le résultat (ainsi que la taille concrètement allouée à home) avec la commande lvdisplay lvm-vador cette commande nous permet ainsi de savoir où nos volumes LVM sont situés, en suivant pour chacun des volumes la ligne “LV Path”, ce qui revient à /dev/<VG name>/<LV Name> (soit /dev/lvm-vador/home pour notre volume home).

À cette étape, vous pouvez très bien reprendre le processus d'installation sans devoir refaire vos partitions (ce ne serait vraiment pas pratique autrement), après avoir déchiffré le conteneur LUKS, en exécutant vgchange --available y lvm-vador ou si vous ne vous connaissez pas le nom vgscan && vgchange --available y ce qui vous permet de reprendre à cette étape et de poursuivre avec la création des systèmes de fichiers.

Les systèmes de fichiers

Après avoir créer nos “partitions” avec LVM, il est temps d'y mettre un système de fichiers, pour pouvoir y stocker les données ; par contre, ne vous trompez, comme déjà fait remarqué précédemment, nos “partitions” sont dans /dev/lvm-vador/, et non pas /dev/sda comme l'indique de base le handbook Gentoo.

Commençons par créer la swap – car ça s'oublie facilement – et de l'activer si nous sommes sur un liveUSB/CD :
mkswap --label swap /dev/lvm-vador/swap
# Si nous sommes dans un liveUSB/CD et que nous souhaitons entrer dans un “chroot”
swapon /dev/lvm-vador/swap

Et puis, les systèmes de fichiers ; me concernant, je vais utiliser le système de fichiers XFS :
mkfs.xfs -L root /dev/lvm-vador/root
mkfs.xfs -L var /dev/lvm-vador/var
mkfs.xfs -L home /dev/lvm-vador/home

On oublie pas de monter les systèmes de fichiers (oui, car dans la RAM, ça ne sert à rien …)
mkdir /mnt/gentoo/
mount /dev/lvm-vador/root /mnt/gentoo
mkdir /mnt/gentoo/{boot,home,var}
touch /mnt/gentoo/{boot,home,var}/.keep
mount /dev/lvm-vador/var /mnt/gentoo/var
mount /dev/lvm-vador/home /mnt/gentoo/home

Remarque : la commande touch est facultative, mais nous a permit de créer des fichiers vides dans les dossiers boot, home et var, tous nommés .keep (donc cachés) ; ces fichiers ont pour unique rôle d'éviter de voir les dossiers concernés supprimés de / et d'empêcher le montage des partitions à leur emplacement. Une petite sécurité pour valider le démarrage, surtout quand on ne peut pas voir la séquence de démarrage.
Note : nous nous occuperons de notre support de démarrage plus tard.

Nous y voilà, notre hiérarchie de fichiers est en place.

Et maintenant ?

Et maintenant, c'est “très simple”, vous pouvez reprendre normalement l'installation de votre système d'exploitation GNU/Linux préféré. Maintenant, suivez le handbook ou tout autre document et reprenez un peu plus tard.

Une fois le système de base installé et le noyau presque prêt, reprenons ensemble.
Nous allons nous créer un système de base, qui va pouvoir permettre de déchiffrer le conteneur LUKS et monter le système de fichiers, avec l'aide de genkernel.

J'ai deux amours, le noyau et Genkernel

Commencez par configurer votre kernel, avec make menuconfig. Importante chose, mettez en dur au moins les systèmes de fichiers de "/boot" et de "/" (respectivement fat32, ext2 et xfs dans nos exemples).
Maintenant, faisons appel à genkernel et voyons sa magie agir avec la commande suivante :
Remarque : faites attention à certaines options, comme --no-mrproper, qui empêche de supprimer les fichiers temporaires, et donc de perdre votre fichier .config.
genkernel --clean --no-mrproper --no-install --no-symlink --kernel-config=/usr/src/linux/.config --disklabel --lvm --luks --gpg --all-ramdisk-modules all

Comme vous pouvez le voir, nous rajoutons le support LVM, LUKS et optionnellement GPG, si votre clef est chiffré symétrique. Si vous utilisez du RAID, rajoutez "--mdadm" (voir genkernel(8)).

Une fois la compilation terminée, trois fichiers ont été créés dans /var/tmp/genkernel/, nommés "kernel-genkernel-x86_64-<version>-<name>", "initramfs-<version>-<name>" et "System.map-genkernel-x86_64-<version>-<name>". Mais avant de les copier dans /boot, reprenons ce dernier.

Nous avions mis de côté notre support de stockage, il est temps de le reprendre. Pour être démarrable, il faut par contre une simple partition et un simple système de fichiers. C'est là aussi que les deux cas de figure cités en début de tutoriel diffèrent :

  1. Dans le cas de figure n°1, il vous faut donc un support externe, telle qu'une clef USB, ou équivalent (les cartes SD fonctionnent aussi) :
    • déterminez après l'avoir branchée (*hmmhmm*) sa "position" dans /dev. Dans notre cas de figure, prenons /dev/sdb,
    • comme pour notre support mémoire système, utilisez fdisk /dev/sdb pour créer une partition dédiée à cette tâche ; dans notre exemple, ce sera /dev/sdb1,
    • ensuite, créons un système de fichiers de type ext2, avec la commande mkfs.ext2 -m0 -c /dev/sdb1 (Conseil, avec un FS en ext2, ça prendra du temps, du coup, prévoyez pas trop grand, comme indiqué en début d'article),
    • pour finir, montez ce nouveau système dans /boot comme ceci mount /dev/sdb1 /boot et voilà.
  2. Dans le cas de figure n°2, nous devons stocker la clef sur le même support ; or rappelez-vous, nous l'avons déjà fait (trop génial ce thican). On va donc simplement :
    • créer un système de fichiers mkfs.ext2 -m0 -c /dev/sda1
    • puis monter le nouveau système dans son emplacement mount /dev/sda1 /boot et c'est tout.

Remarque : ne copiez pas bêtement les commandes non plus, car si vous formattez avec un FS la partition qui sert de conteneur LUKS, « bravo », vous gagnez le droit de tout recommencer … ou pire, de perdre des données !

Ensuite, copiez les fichiers créés par genkernel ainsi que votre fichier clef_luks.gpg dans la partition de démarrage (/boot), et maintenant, occupons nous du bootloader.

Le bootloader, pour un démarrage tout en douce(u)r

Le bootloader est un logiciel, de petite taille, qui se charge d'exécuter les scripts et programmes de base permettant au système de démarrer. D'expérience, je vous aurais conseillé extlinux, mais je n'ai pas réussi à le faire fonctionner à distance, donc nous allons prendre LILO, qui fonctionne.
Note : Si vous avez une idée du soucis, n'hésitez pas à m'écrire pour me donner quelques détails. ;-)

Créez donc votre fichier /etc/lilo.conf avec ces informations, sans toutefois oublier d'adapter les noms de fichiers, bien sûr, mais aussi la variable "boot=" avec /dev/sdb (selon notre exemple) pour un support externe, ou /dev/sda pour un système distant :
# /etc/lilo.conf

# Should work for most systems, and do not have the sector limit:
lba32
# If lba32 do not work, use linear:
#linear

# MBR to install LILO to: (BE CAREFUL)
boot=/dev/sdb
map=/boot/.map
timeout=0
default=gentoo

image=/boot/kernel-genkernel-x86_64-<version>-<name>
label=gentoo
read-only # read-only for checking
initrd=/boot/initramfs-<version>-<name>
append="doluks crypt_root=/dev/sda1 root_keydev=/dev/sdb1 root_key=/boot/clef_luks.gpg dolvm lvmraid=lvm-vador real_root=/dev/lvm-vador/root rootfstype=xfs"

Remarque : Si vous êtes sur une machine distante, tel un serveur, il sera tout aussi difficile d'y taper un mot de passe au moment du démarrage comme le fait d'y brancher un support externe. Pour cela, et comme je l'avais mentionné, on va donc déchiffrer la clef, pour la stocker en clair avec le kernel et l'initramfs. Reprenons en premier notre clef, pour la déchiffrer et stocker ses données en clair dans un autre fichier :
# Plaçons-nous dans le dossier /boot du système de fichier, en dehors du chroot
cd /mnt/gentoo/boot
# Déchiffrons la clef et stockons les données dans un autre fichier. Le mot de passe vous sera demandé.
gpg --decrypt clef_luks.gpg > clef_luks.txt

Une fois ceci de fait, il faut remodifier le fichier /etc/lilo.conf pour indiquer d'utiliser ce nouveau fichier plutôt que la clef chiffrée. Pour celà, modifiez le contenu de la variable root_key=/boot/clef_luks.gpg en root_key=/boot/clef_luks.txt.

Comme vous pouvez le voir, rien de bien compliqué. Une fois le fichier /etc/lilo.conf correct et écrit, exécutez simplement la commande lilo et ... et c'est tout !

Si si, pour de vrai, vous avez fini ! Redémarrez simplement, ou fermez vous-même les systèmes de fichiers (pour apprendre, par exemple) :
umount -l /mnt/gentoo/{home,boot,var,}
swapoff /dev/lvm-vador/swap
vgchange -a n lvm-vador
crytpsetup luksClose vador
reboot

Je vous souhaite bonne continuation pour le reste, et merci à vous d'avoir suivi ce tutoriel.