Dm-crypt
dm-crypt est un système de chiffrement de disque utilisant le framework de l'API cryptographique du noyau et le sous-système de mapping des périphériques. Avec dm-crypt, les administrateurs peuvent chiffrer des disques entiers, des volumes logiques, des partitions mais aussi un fichier seul.
Le sous-système dm-crypt supporte la structure de LUKS (Linux Unified Key Setup), qui autorise différentes clés à accéder aux données chiffrées (comme changer de clés, ajouter des mots de passes, etc). Bien que dm-crypt supporte tout à fait les configurations sans LUKS, cet article se concentrera principalement sur les fonctionnalités avec LUKS pour sa flexibilité, sa maintenance tout comme son important support dans la communauté.
Configuration
Il y a deux pré-requis avant de commencer à utiliser dm-crypt :
- Configuration du noyau Linux
- Installation du paquet sys-fs/cryptsetup
Configuration du noyau
Pour utiliser dm-crypt il y a certains nombres d'entrée à ajouter dans la configuration qui sont nécessaires.
Avant toute chose, le support pour l'infrastructure du mappage des périphériques tout comme la cible à chiffrer doivent être inclus :
[*] Enable loadable module support
Device Drivers --->
[*] Multiple devices driver support (RAID and LVM) --->
<*> Device mapper support
<*> Crypt target support
Ensuite, le noyau Linux doit supporter une série d'API cryptographique que l'administrateur veut utiliser pour le chiffrement. Ceux-ci se trouvent sous la section API Cryptographique :
[*] Cryptographic API --->
<*> XTS support
<*> SHA224 and SHA256 digest algorithm
<*> AES cipher algorithms
<*> AES cipher algorithms (x86_64)
<*> User-space interface for hash algorithms
<*> User-space interface for symmetric key cipher algorithms
Si le système de fichier racine doit être chiffré, alors un fichier initial en mémoire RAM pour le système doit être crée dans lequel le système de fichier racine doit-être déchiffré avant d'être monté.
General setup --->
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
Si en utilisant l'option tcrypt (le mode de compatibilité pour TrueCrypt/tcplay/VeraCrypt), alors les objets suivants doivent aussi être ajouté dans le kernel. Auquel cas, cryptsetup retournera l'erreur suivante : "device-mapper: reload ioctl failed: Invalid argument" et "Kernel doesn't support TCRYPT compatible mapping".
Device Drivers --->
[*] Block Devices --->
<*> Loopback device support
File systems --->
<*> FUSE (Filesystem in Userspace) support
[*] Cryptographic API --->
<*> RIPEMD-160 digest algorithm
<*> SHA384 and SHA512 digest algorithms
<*> Whirlpool digest algorithms
<*> LRW support
<*> Serpent cipher algorithm
<*> Twofish cipher algorithm
Installation de Cryptsetup
Le paquet sys-fs/cryptsetup fournit la commande cryptsetup, qui est utilisée pour ouvrir ou fermer le stockage chiffré tout comme il gère les mots de passes et clés associés avec.
root #emerge --ask sys-fs/cryptsetupStockage chiffré
Benchmark
cryptsetup fournit un outil de benchmark qui aidera à déterminer quels paramètres choisir. La sortie dépend des paramètres du noyau tout comme les USE flags et le support (NdT: à chiffrer) (HDD, SSD, etc).
root #cryptsetup benchmark# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 1707778 iterations per second for 256-bit key
PBKDF2-sha256 2131252 iterations per second for 256-bit key
PBKDF2-sha512 1630755 iterations per second for 256-bit key
PBKDF2-ripemd160 882639 iterations per second for 256-bit key
PBKDF2-whirlpool 664496 iterations per second for 256-bit key
argon2i 9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1197.2 MiB/s 3788.1 MiB/s
serpent-cbc 128b N/A N/A
twofish-cbc 128b N/A N/A
aes-cbc 256b 888.2 MiB/s 3011.1 MiB/s
serpent-cbc 256b N/A N/A
twofish-cbc 256b N/A N/A
aes-xts 256b 3670.7 MiB/s 3708.4 MiB/s
serpent-xts 256b N/A N/A
twofish-xts 256b N/A N/A
aes-xts 512b 2929.2 MiB/s 2974.0 MiB/s
serpent-xts 512b N/A N/A
twofish-xts 512b N/A N/A
Fichier clé ou mot de passe
Pour commencer avec le chiffrement d'un espace de stockage, l'administrateur doit décider de la méthode à utiliser pour la clé de chiffrement. Avec cryptsetup le choix est soit celui du mot de passe ou d'un fichier clé. Dans le cas d'un fichier clé, cela peut être n'importe quel fichier mais il est recommandé d'utiliser un fichier avec des données aléatoires qui est correctement protégé (considérant que l'accès au fichier clé veut dire l'accès aux données chiffrées).
Pour créer un fichier clé, la commande dd peut être utilisée :
root #dd if=/dev/urandom of=/etc/keys/enc.key bs=1 count=4096Dans la proche section, nous verrons chaque commande dans les deux situations - mot de passe et fichier clé. Bien sûr, seule une méthode est nécessaire.
Créer une plate-forme de stockage chiffrée
Afin de créer une plate-forme de stockage chiffrée (qui peut être un disque, une partition, un fichier, …) utiliser la commande cryptsetup avec l'option luksFormat.
Par exemple, pour avoir en tant que média de stockage pour les données chiffrées /dev/vdb2 :
root #cryptsetup -c aes-xts-plain64 -s 512 -y luksFormat /dev/vdb2This will overwrite data on /dev/vdb2 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: ... Verify passphrase: ...
Pour utiliser un fichier clé au lieu d'un mot de passe :
root #cryptsetup -c aes-xts-plain64 -s 512 -y luksFormat /dev/vdb2 /etc/keys/enc.keyThis will overwrite data on /dev/vdb2 irrevocably. Are you sure? (Type uppercase yes): YES
L'option -c aes-xts-plain64 dit à cryptsetup quelle est la méthode de chiffrement à utiliser pour le disque (cat /proc/crypto montrera toutes les possibilités). L'option -s 512 indique à cryptsetup quelle longueur doit avoir la clé utilisée pour le chiffrement de celle-ci (à la différence des mots de passe ou des fichiers clés, qui peuvent être utilisée pour accéder à la vrai clé de chiffrement). Finalement -y force l'utilisateur à taper le mot de passe deux fois.
XTS (NdT: lien en anglais) sépare la clé en deux moitiés, seulement une seule sera utilisé véritablement pour le chiffrement qui sera mis en place. Cela signifie qu'"aes-xts" avec une clé de 512-bit utilise en réalité 256 bits pour la partie AES.
Si l'en-tête de LUKS est endommagé, les données chiffrées seront perdues à jamais, même si une sauvegarde de la clé GPG et du mot de passe sont présents. De par le fait, il serait bon de sauvegarder cette en-tête sur un périphérique distinct, tout en le conservant à l’abri. Voir LUKS FAQ pour de plus amples informations pour faire cela.
root #cryptsetup luksHeaderBackup /dev/sdXn --header-backup-file /tmp/efiboot/luks-header.imgDémarrage d'un disque entièrement chiffré
Pour démarrer depuis un périphérique entièrement chiffré (incluant un /boot lui-aussi chiffré) en utilisant GRUB, avec le chiffrement luks1, vu que luks2 n'est pas encore entièrement supporté. Un exemple de commande :
root #cryptsetup -c aes-xts-plain64 -s 512 -y luksFormat --type luks1 /dev/vdb2Ouvrir le périphérique chiffré
Afin de déverrouiller le périphérique chiffré (c-à-d rendre les données réelles accessibles à travers un déchiffrement transparent), utiliser l'option luksOpen.
root #cryptsetup luksOpen /dev/vdb2 mynameEnter passphrase for /dev/vdb2: ...
Si un fichier-clé est utilisé, alors la commande devra plus ou moins ressembler à cela :
root #cryptsetup luksOpen -d /etc/keys/enc.key /dev/vdb2 monnomQuand la commande a terminé avec succès, alors un nouveau fichier pour le périphérique /dev/mapper/monnom sera rendu accessible.
Si cela est la première fois que ce périphérique chiffré est utilisé, il nécessite d'être formaté. L'exemple suivant utilise le système de fichier Btrfs mais bien sûr tout autre système de fichiers fera l'affaire :
root #mkfs.btrfs /dev/mapper/mynameUne fois le système de fichier formaté, ou si le formatage a été réalisé au préalable, alors le fichier du périphérique peut être monté sur le système :
root #mount /dev/mapper/monnom /homeRefermer le stockage chiffré
Afin de refermer le stockage chiffré (c-à-d s'assurer que les données réelles ne sont plus accessibles à travers une méthode de déchiffrement transparente), utiliser l'option luksClose :
root #cryptsetup luksClose monnomBien sûr, s'assurer que le périphérique n'est pas encore en cours d'usage.
Manipuler les clés de LUKS
Les clés de LUKS sont utilisés pour accéder à la clé de chiffrement. Elles sont stockés dans le slot (NdT: l'emplacement dans ce contexte) contenu dans l'en-tête de la partition (chiffrée), du disque ou du fichier.
Lister les slots
Avec l'option luksDump, des informations à propos du chiffrement de la partition, du disque ou du fichier peuvent être affichées. Cela inclus les slots :
root #cryptsetup luksDump /dev/vdb2LUKS header information for /dev/vdb2
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 512
MK digest: 34 3b ec ac 10 af 19 e7 e2 d4 c8 90 eb a8 da 3c e4 4f 2e ce
MK salt: ff 7c 7f 53 db 53 48 02 a4 32 dc e0 22 fc a3 51
06 ba b3 48 b3 28 13 a8 7a 68 43 d6 46 79 14 fe
MK iterations: 59375
UUID: 2921a7c9-7ccb-4300-92f4-38160804e08c
Key Slot 0: ENABLED
Iterations: 241053
Salt: 90 0f 0f db cf 66 ea a9 6c 7c 0c 0d b0 28 05 2f
8a 5c 14 54 98 62 1a 29 f3 08 25 0c ec c2 b1 68
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 273211
Salt: 01 4c 26 ed ff 18 75 31 b9 89 5d a6 e0 b5 f4 14
48 d0 23 47 a9 85 78 fb 76 c4 a9 d0 cd 63 fb d7
Key material offset: 512
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Dans l'exemple ci-dessus, deux slots sont utilisés. Il est à noter que luksDump ne renvoie rien de sensible - il affiche à peine le contenu de l'en-tête de LUKS. Aucune clé de déchiffrement n'as besoins d'être fournit afin d'appeler luksDump.
Ajouter un fichier clé ou un mot de passe
Afin d'ajouter un fichier-clé ou un mot de passe additionnel pour accéder au stockage, utiliser l'option luksAddKey :
root #cryptsetup luksAddKey /dev/vdb2Enter any passphrase: (Enter a valid, previously used passphrase to unlock the key) Enter new passphrase for key slot: ... Verify passphrase: ...
Pour utiliser un fichier-clé pour déverrouiller la clé (mais on continuant à utiliser un mot de passe) :
root #cryptsetup luksAddKey -d /etc/keys/enc.key /dev/vdb2Enter new passphrase for key slot: ... Verify passphrase: ...
Si un fichier-clé à été ajouté (disons /etc/keys/backup.key) :
root #cryptsetup luksAddKey /dev/vdb2 /etc/keys/backup.keyOu, pour utiliser le premier fichier-clé pour déverrouiller la clé principale :
root #cryptsetup luksAddKey -d /etc/keys/enc.key /dev/vdb2 /etc/keys/backup.keySupprimer un fichier-clé ou un mot de passe
Avec l'option luksRemoveKey, un fichier-clé ou un mot de passe peut être supprimé (qui n'est plus de par le fait utilisable pour déchiffrer le stockage) :
root #cryptsetup luksRemoveKey /dev/vdb2Enter LUKS passphrase to be deleted: ...
Ou pour supprimer un fichier-clé :
root #cryptsetup luksRemoveKey -d /etc/keys/backup.key /dev/vdb2Il faut s'assurer qu'au moins une méthode pour accéder aux données est encore disponible. Une fois que le mot de passe ou le fichier-clé a été retiré, il ne peut être restaurer.
Vider un slot
Supposons que le mot de passe ou fichier-clé n'est plus connu, alors le slot peut être libéré. Bien sûr, cela requiert au préalable de connaître le slot dans lequel le mot de passe ou fichier-clé à été stocké.
Par exemple, pour vider le slot 2 (qui est le troisième car leur numérotation commence à partir de 0) :
root #cryptsetup luksKillSlot /dev/vdb2 2Cette commande demandera un mot de passe valide avant de continuer. Ou l'on peut passer (NdT: en argument) le fichier-clé pour son utilisation :
root #cryptsetup luksKillSlot -d /etc/keys/enc.key /dev/vdb2 2Montage automatique d'un système de fichier chiffré
Jusqu'à présent, cet article s'est concentré sur le montage/démontage manuel d'un système de fichier. Un service d'initialisation comme dmcrypt existe et automatise le déchiffrement et le montage du système de fichier chiffré.
Configurer dm-crypt
Éditer le fichier /etc/conf.d/dmcrypt et rajouter une entrée pour chaque système de fichier. Les entrées supportés sont bien documentés dans ce fichier, l'exemple ci-dessus est ce qu'il est - un exemple :
/etc/conf.d/dmcryptActiver automatiquement deux systèmes de fichiers chiffrés# Definition for /dev/mapper/home (for /home)
target=home
source=UUID="abcdef12-321a-a324-a88c-cac412befd98"
key=/etc/keys/home.key
# If trim is desired, it can be enabled like this.
# Keep in mind that trim is not enabled by default for a security reason.
options="--allow-discards"
# Definition for /dev/mapper/local (for /usr/local)
target=local
source=UUID="fedcba34-4823-b423-a94c-cadbefda2943"
key=/etc/keys/local.key
# Using an encrypted partition as key source.
target=other
source=UUID="ff24303e-49e1-4d13-b8ad-fc6b7e1d8174"
key=/keys/other.key # Relative to the root of the encrypted partition.
remdev=/dev/mapper/home # The recently decrypted partition.
# An empty line is important at the end of the file
If using passphrase instead of a keyfile, you'll be prompted for it on boot (given a simple target and source configuration).
Configurer fstab
L'étape suivante est de configurer /etc/fstab pour monter automatiquement les systèmes de fichier (déchiffrés) quand ils deviennent disponibles. Il est recommandé d'obtenir en premier lieu l'UUID des systèmes de fichier (montés) qui ont été déchiffrés :
root #blkid /dev/mapper/home/dev/mapper/home: UUID="4321421a-4321-a6c9-de52-ba6421efab76" TYPE="ext4"
Ensuite, mettre à jour le fichier /etc/fstab en concordance :
/etc/fstabMonter automatiquement les systèmes de fichier déchiffrésUUID="4321421a-4321-a6c9-de52-ba6421efab76" /home ext4 defaults 0 0
UUID="bdef2432-3bd1-4ab4-523d-badcf234a342" /usr/local ext4 defaults 0 0
Ajout d'un script d'initialisation au niveau de l'amorçage (NdT: du système)
Ne pas oublier d'avoir le service d'initialisation dmcrypt lancé au démarrage :
root #rc-update add dmcrypt boot
Rendre les périphériques de nodes (NdT: nœuds) déchiffrés visibles
Si un périphérique a été déchiffré/déverrouillé avant que les services aient démarrés comme par exemple la partition root avec un initramfs alors il est possible que le périphérique mappé ne soit pas visible. Dans ce cas il faut relancer ce qui suit pour le recréer.
root #dmsetup mknodesMonter un volume TrueCrypt/tcplay/VeraCrypt
root #cryptsetup --type tcrypt open conteneur-à-monter nom-du-conteneurRemplacer conteneur-à-monter avec le fichier de périphérique dans /dev ou vers le fichier qu'il est souhaité d'ouvrir. Après une ouverture réussi, le périphérique en texte brute apparaîtra en tant que /dev/mapper/nom-du-conteneur, qui peut être mount comme n'importe quel périphérique.
Si des fichiers-clés sont utilisés, les ajouter avec l'option --key-file, pour ouvrir un volume caché ajouter l'option --tcrypt-hidden et pour une partition ou un disque entier qui est chiffré on mode système alors c'est l'option --tcrypt-system qu'il faudra utiliser.
Une fois terminé, unmount le volume et le refermer en utilisant cette commande suivante :
root #cryptsetup close nom-du-conteneurVoir aussi
- Full Disk Encryption From Scratch Simplified — a guide which covers the process of configuring a drive to be encrypted using LUKS and btrfs.
- Dm-crypt full disk encryption — a guide which covers the process of configuring a drive to be encrypted using LUKS and btrfs.
- User:Sakaki/Sakaki's EFI Install Guide/Preparing the LUKS-LVM Filesystem and Boot USB Key
Ressources externes
- The cryptsetup FAQ hosted on GitLab covers a wide range of frequently asked questions.