- SYNTAXE
- DESCRIPTION
- ACTIONS DE BASE
- MODE SIMPLE
- EXTENSION LUKS
- EXTENSION LOOP-AES
- EXTENSION TCRYPT (COMPATIBLE AVEC TRUECRYPT ET VERACRYPT)
- EXTENSION BITLK (COMPATIBLE WINDOWS BITLOCKER)
- EXTENSION FVAULT2 (COMPATIBLE AVEC APPLE MACOS FILEVAULT2)
- EXTENSION SED (DISQUE À CHIFFREMENT INTÉGRÉ) OPAL
- ACTIONS DIVERSES
- MODE STANDARD OU LUKS ?
- AVERTISSEMENTS
- EXEMPLES
- CODES DE RETOUR
- NOTES
- Traitement des phrases de passe pour le mode PLAIN
- Traitement des phrases de passe pour LUKS
- Comportement incohérent pour les phrases de passe/clés non valides
- Ciphers, modes, hachages et tailles de clé pris en charge
- Remarques sur les phrases de passe
- Remarques sur les générateurs de nombres aléatoires
- Chiffrement de disque authentifié (EXPÉRIMENTAL)
- Remarques sur l'utilisation du périphérique loopback
- Verrouillage de l'en-tête LUKS2
- Spécification du format LUKS sur disque
- AUTEURS
- SIGNALEMENT DES BUGS
- VOIR AUSSI
- CRYPTSETUP
cryptsetup - utilitaire pour configurer et gérer les périphériques de stockage chiffrés
SYNTAXE
cryptsetup <action> [<options>] <arguments_action>
DESCRIPTION
Cryptsetup est un utilitaire pour configurer et gérer le chiffrement complet du disque sur les périphériques de stockage. Il peut chiffrer des périphériques blocs (tels que des disques durs ou des partitions) et des conteneurs (images de disque stockées sous forme de fichiers).
Lorsque vous déverrouillez un volume chiffré, cryptsetup crée un nouveau mappage de périphérique auquel les applications peuvent accéder comme n’importe quel périphérique de stockage normal. Le travail réel de chiffrement et de déchiffrement est effectué de manière transparente par le pilote dm-crypt du gestionnaire de périphériques du noyau.
Cryptsetup fonctionne avec deux types de volumes principaux : les volumes chiffrés simples et les volumes LUKS (Linux Unified Key Setup). Les volumes simples offrent un chiffrement de base, tandis que les volumes LUKS incluent un en-tête de métadonnées qui permet des fonctionnalités avancées telles que plusieurs emplacements de clés et la gestion des clés. De plus, LUKS peut être utilisé pour gérer le chiffrement basé sur le matériel sur les disques de stockage compatibles OPAL.
Cryptsetup fournit également une prise en charge limitée pour les volumes créés par d’autres systèmes de chiffrement, notamment loop-AES, TrueCrypt, VeraCrypt, BitLocker et FileVault2.
Pour plus d’informations sur une action cryptsetup spécifique, consultez cryptsetup-
Les périphériques cryptsetup peuvent être activés au démarrage via crypttab(5), qui fait partie de systemd(1) ou d’autres scripts d’initialisation du système.
ACTIONS DE BASE
Les actions suivantes sont valides pour tous les types de périphériques pris en charge.
OPEN
open <périphérique> <nom> --type <type_périphérique>
Ouvre (crée un mappage avec)
CLOSE
close <nom>
Supprime le mappage existant
STATUS
status <nom>
Affiche l’état du mappage
RESIZE
resize <nom>
Redimensionne un mappage actif
REFRESH
refresh <nom>
Actualise les paramètres du mappage actif
REENCRYPT
reencrypt <périphérique> ou --active-name <nom> [<nouveau_nom>]
Exécute le rechiffrement du périphérique LUKS. Voir cryptsetup-reencrypt(8).
MODE SIMPLE
dm-crypt simple chiffre le périphérique secteur par secteur avec un seul hachage de mot de passe non salé. Aucune vérification n’est effectuée et aucune métadonnée n’est utilisée. Il n’y a pas d’opération de formatage. Lorsque le périphérique brut est mappé (ouvert), les opérations de périphérique habituelles peuvent être utilisées sur le périphérique mappé, y compris la création du système de fichiers. Les périphériques mappés résident généralement dans /dev/mapper/
Les actions suivantes sont valides pour les types d’appareils simples :
OUVRIR
open --type plain <device> <name>
create <name> <device> (syntaxe OBSOLÈTE)
Ouvre (crée un mappage avec)
EXTENSION LUKS
LUKS, le système unifié de configuration de clés Linux, est une norme pour le chiffrement de disque. Il ajoute un en-tête standardisé au début de l’appareil, une zone de clés juste derrière l’en-tête et la zone de données volumineuses derrière celle-ci. L’ensemble est appelé « conteneur LUKS ». L’appareil sur lequel réside un conteneur LUKS est appelé « appareil LUKS ». Pour la plupart des usages, les deux termes peuvent être utilisés de manière interchangeable.
LUKS peut gérer plusieurs phrases de passe qui peuvent être révoquées ou modifiées individuellement. Chaque phrase de passe utilise un emplacement de clé individuel contenant une clé de volume pour le chiffrement des données. Les emplacements de clé peuvent être effacés de manière sécurisée à partir des supports persistants grâce à l’utilisation de bandes anti-forensiques. Les phrases de passe sont protégées contre les attaques par force brute par la fonction de dérivation de clé basée sur un mot de passe (PBKDF). Une phrase de passe stockée dans un fichier est appelée fichier de clé. La seule différence entre une phrase de passe et un fichier de clé est qu’un fichier de clé peut contenir des données binaires. Les deux sont traités de la même manière.
LUKS version 1 (ou LUKS1) est le format de métadonnées d’origine, tandis que LUKS2 est une nouvelle version qui permet des extensions supplémentaires, telles que différents algorithmes PBKDF ou un chiffrement authentifié. Vous pouvez formater l’appareil avec une version LUKS spécifique à l’aide de l’option --type luks1 ou --type luks2 dans la commande luksFormat. Normalement, vous n’avez pas besoin de spécifier une version, car elle est reconnue automatiquement. Le format par défaut est LUKS2.
Le paramètre
L’en-tête LUKS peut être détaché des données (stocké séparément). Pour spécifier un en-tête détaché, le paramètre --header peut être utilisé dans toutes les commandes LUKS et a toujours la priorité sur le paramètre positionnel
Les actions LUKS suivantes sont valides :
FORMATER
luksFormat <device> [<fichier de clé>]
Initialise une partition LUKS et définit la phrase de passe initiale (pour l’emplacement de clé 0). Voir cryptsetup-luksFormat(8).
OUVRIR
open --type luks <device> <name>
luksOpen <device> <name> (ancienne syntaxe)
Ouvre l’appareil LUKS
SUSPENDRE
luksSuspend <name>
Suspend un appareil actif (toutes les opérations d’E/S seront bloquées et les accès à l’appareil attendront indéfiniment) et efface la clé de chiffrement de la mémoire du noyau. Voir cryptsetup-luksSuspend(8).
REPRENDRE
luksResume <name>
Reprend un appareil suspendu et rétablit la clé de chiffrement. Voir cryptsetup-luksResume(8).
AJOUTER UNE CLÉ
luksAddKey <device> [<fichier de clé avec une nouvelle clé>]
Ajoute une nouvelle phrase secrète en utilisant une phrase secrète existante. Voir cryptsetup-luksAddKey(8).
SUPPRIMER UNE CLÉ
luksRemoveKey <device> [<fichier de clé avec la phrase secrète à supprimer>]
Supprime la phrase secrète fournie du périphérique LUKS. Voir cryptsetup-luksRemoveKey(8).
MODIFIER UNE CLÉ
luksChangeKey <device> [<nouveau fichier de clé>]
Modifie une phrase secrète existante. Voir cryptsetup-luksChangeKey(8).
CONVERTIR UNE CLÉ
luksConvertKey <device>
Convertit un emplacement de clé LUKS2 existant vers de nouveaux paramètres PBKDF. Voir cryptsetup-luksConvertKey(8).
DÉTRUIRE UN EMPLACEMENT
luksKillSlot <device> <number>
Efface l’emplacement de clé
EFFACER
erase <device>
luksErase <device> (ancienne syntaxe)
Efface tous les emplacements de clé et rend le conteneur LUKS définitivement inaccessible. Voir cryptsetup-erase(8).
UUID
luksUUID <device>
Affiche ou définit l’UUID d’un périphérique LUKS. Voir cryptsetup-luksUUID(8).
EST LUKS
isLuks <device>
Retourne true si
VIDER
luksDump <device>
Vide les informations d’en-tête d’un périphérique LUKS. Voir cryptsetup-luksDump(8).
SAUVEGARDE DE L’EN-TÊTE
luksHeaderBackup <device> --header-backup-file <file>
Stocke une sauvegarde binaire de l’en-tête LUKS et de la zone d’emplacement des clés. Voir cryptsetup-luksHeaderBackup(8).
RESTAURER L’EN-TÊTE
luksHeaderRestore <device> --header-backup-file <file>
Restaure une sauvegarde binaire de l’en-tête LUKS et de la zone d’emplacement des clés à partir du fichier spécifié. Voir cryptsetup-luksHeaderRestore(8).
TOKEN
token <add|remove|import|export> <device>
Manipule les objets token utilisés pour obtenir des phrases secrètes. Voir cryptsetup-token(8).
CONVERTIR
convert <device> --type <format>
Convertit le périphérique entre les formats LUKS1 et LUKS2 (si possible). Voir cryptsetup-convert(8).
CONFIGURATION
config <device>
Définit des options de configuration permanentes (les stocke dans l’en-tête LUKS). Voir cryptsetup-config(8).
EXTENSION LOOP-AES
Cryptsetup prend en charge le mappage d’une partition loop-AES cryptée en utilisant un mode de compatibilité.
OUVRIR
open --type loopaes <device> <name> --key-file <keyfile>
loopaesOpen <device> <name> --key-file <keyfile> (ancienne syntaxe)
Ouvre le périphérique loop-AES
Voir également la section 7 de la FAQ et loop-AES [http://loop-aes.sourceforge.net] pour plus d’informations concernant loop-AES.
EXTENSION TCRYPT (COMPATIBLE AVEC TRUECRYPT ET VERACRYPT)
Cryptsetup prend en charge le mappage des partitions chiffrées TrueCrypt, tcplay ou VeraCrypt en utilisant une API crypto native du noyau Linux. Le formatage de l’en-tête et la modification de l’en-tête TCRYPT ne sont pas pris en charge ; cryptsetup ne modifie jamais l’en-tête TCRYPT sur le périphérique.
L’extension TCRYPT nécessite que l’API d’espace utilisateur crypto du noyau soit disponible. Si vous configurez le noyau vous-même, activez « Interface d’espace utilisateur pour les algorithmes de chiffrement par clé symétrique » dans la section « API cryptographique » (option .config CRYPTO_USER_API_SKCIPHER).
Étant donné que l’en-tête TCRYPT est chiffré, vous devez toujours fournir une phrase secrète et des fichiers de clés valides.
Cryptsetup devrait reconnaître toutes les variantes d’en-tête, à l’exception des chaînes de chiffrement héritées utilisant le mode de chiffrement LRW et une taille de bloc de chiffrement de 64 bits (en particulier, Blowfish en mode LRW n’est pas reconnu ; il s’agit d’une limitation de l’API crypto du noyau).
VeraCrypt est une extension de TrueCrypt avec un nombre d’itérations accru, donc le déverrouillage peut prendre pas mal de temps.
Pour ouvrir un périphérique VeraCrypt avec une valeur de multiplicateur d’itération personnelle (PIM) personnalisée, utilisez l’option --veracrypt-pim PIM pour spécifier directement le PIM sur la ligne de commande ou utilisez --veracrypt-query-pim pour que le PIM soit demandé.
La valeur PIM affecte le nombre d’itérations appliquées pendant la dérivation de clé. Veuillez vous référer à PIM [https://veracrypt.io/en/Personal%20Iterations%20Multiplier%20(PIM).html] pour plus d’informations détaillées.
Si vous devez désactiver la prise en charge des périphériques VeraCrypt, utilisez l’option --disable-veracrypt.
L’activation avec tcryptOpen est prise en charge uniquement pour les chaînes de chiffrement utilisant les modes de chiffrement LRW ou XTS.
La commande tcryptDump devrait fonctionner pour tous les périphériques TCRYPT reconnus et ne nécessite pas de privilèges d’administrateur.
Pour mapper le périphérique système (périphérique avec le chargeur d’amorçage où réside l’ensemble du système chiffré), utilisez l’option --tcrypt-system. Veuillez lire les informations spécifiques dans cryptsetup-tcryptOpen(8) – section de l’option --tcrypt-system, car le mappage d’un périphérique chiffré système est délicat.
Pour utiliser un en-tête caché (et mapper le périphérique caché, si disponible), utilisez l’option --tcrypt-hidden.
Pour utiliser explicitement l’en-tête de sauvegarde (secondaire), utilisez l’option --tcrypt-backup.
Il n’y a pas de protection pour un volume caché si le volume externe est monté. La raison en est que si une protection existait, elle nécessiterait des métadonnées décrivant ce qui doit être protégé dans le volume externe, et le volume caché deviendrait détectable.
OUVRIR
open --type tcrypt <périphérique> <nom>
tcryptOpen_ <périphérique> <nom> (ancienne syntaxe)
Ouvre le périphérique TCRYPT (compatible TrueCrypt)
DUMPER
tcryptDump <périphérique>
Déverse les informations d’en-tête d’un périphérique TCRYPT. Voir cryptsetup-tcryptDump(8).
Voir également les pages TrueCrypt [https://en.wikipedia.org/wiki/TrueCrypt] et VeraCrypt [https://en.wikipedia.org/wiki/VeraCrypt] pour plus d’informations.
Veuillez noter que cryptsetup n’utilise pas le code TrueCrypt ou VeraCrypt ; veuillez signaler tous les problèmes liés à cette extension de compatibilité au projet cryptsetup.
EXTENSION BITLK (COMPATIBLE WINDOWS BITLOCKER)
Cryptsetup prend en charge le mappage des partitions chiffrées BitLocker et BitLocker to Go à l’aide d’une API crypto native du noyau Linux. Le formatage de l’en-tête et les modifications de l’en-tête BITLK ne sont pas pris en charge ; cryptsetup ne modifie jamais l’en-tête BITLK sur le périphérique.
L’extension BITLK nécessite que l’API crypto d’espace utilisateur du noyau soit disponible (pour plus de détails, voir la section TCRYPT).
Cryptsetup devrait reconnaître toutes les variantes d’en-tête BITLK, à l’exception de l’en-tête hérité utilisé dans les systèmes Windows Vista et des périphériques BitLocker partiellement déchiffrés. L’activation des périphériques hérités chiffrés en mode CBC nécessite au moins une version du noyau Linux 5.3, et pour les périphériques utilisant le diffuseur Elephant, la version 5.6.
La commande bitlkDump doit fonctionner pour tous les périphériques BITLK reconnus et ne nécessite pas de privilèges d'administrateur.
Pour le déverrouillage avec la commande open, un mot de passe, une phrase de récupération ou une clé de démarrage doit être fourni.
De plus, le déverrouillage à l'aide de la touche de volume est pris en charge. Vous devez fournir la clé de chiffrement de volume complète de BitLocker (FVEK) à l'aide de l'option --volume-key-file. La clé doit être déchiffrée et ne doit pas contenir l'en-tête (seules les données de clé de 128/256/512 bits sont requises, en fonction du chiffrement et du mode utilisés).
Les autres méthodes de déverrouillage (TPM, SmartCard) ne sont pas prises en charge.
OPEN
open --type bitlk <périphérique> <nom>
bitlkOpen <périphérique> <nom> (ancienne syntaxe)
Ouvre le périphérique BITLK (compatible BitLocker)
DUMP
bitlkDump <périphérique>
Affiche les informations d'en-tête d'un périphérique BITLK. Voir cryptsetup-bitlkDump(8).
Veuillez noter que cryptsetup n'utilise aucun code Windows BitLocker ; veuillez signaler tous les problèmes liés à cette extension de compatibilité au projet cryptsetup.
EXTENSION FVAULT2 (COMPATIBLE AVEC APPLE MACOS FILEVAULT2)
Cryptsetup prend en charge le mappage de FileVault2 (chiffrement complet du disque FileVault2) pour le système d'exploitation macOS à l'aide d'une API crypto native du noyau Linux.
Cryptsetup prend en charge uniquement FileVault2 basé sur Core Storage et le système de fichiers HFS+ (introduit dans macOS X 10.7 Lion). Il NE prend PAS en charge la nouvelle version de FileVault basée sur le système de fichiers APFS utilisé dans les versions récentes de macOS.
Le formatage de l'en-tête et les modifications de l'en-tête FVAULT2 ne sont pas pris en charge ; cryptsetup ne modifie jamais l'en-tête FVAULT2 sur le périphérique.
L'extension FVAULT2 nécessite que l'API crypto de l'espace utilisateur du noyau soit disponible (pour plus de détails, voir la section TCRYPT) et un pilote de noyau pour le système de fichiers HFS+ (hfsplus).
Cryptsetup doit reconnaître la configuration de base pour les disques portables.
La commande fvault2Dump doit fonctionner pour tous les périphériques FVAULT2 reconnus et ne nécessite pas de privilèges d'administrateur.
Pour le déverrouillage avec la commande open, un mot de passe doit être fourni. Les autres méthodes de déverrouillage ne sont pas prises en charge.
OPEN
open --type fvault2 <périphérique> <nom>
fvault2Open <périphérique> <nom> (ancienne syntaxe)
Ouvre le périphérique FVAULT2 (compatible FileVault2)
EXTENSION SED (DISQUE À CHIFFREMENT INTÉGRÉ) OPAL
Cryptsetup prend en charge l'utilisation du chiffrement matériel natif sur les disques qui fournissent une interface OPAL, à la fois en mode imbriqué avec dm-crypt et en mode autonome. Les phrases de passe, les jetons et les métadonnées sont stockés à l'aide du format d'en-tête LUKS2, et sont donc compatibles avec tout logiciel ou système qui utilise LUKS2 (par exemple, les jetons).
Le support OPAL nécessite au moins la version du noyau v6.4. Le redimensionnement des périphériques n'est pas pris en charge.
L'option --hw-opal peut être spécifiée pour OPAL + dm-crypt, et l'option --hw-opal-only peut être spécifiée pour utiliser uniquement OPAL, sans couche dm-crypt.
L’ouverture, la fermeture et l’enregistrement des jetons fonctionnent de la même manière que pour LUKS2 et dm-crypt. Les nouveaux paramètres ne sont nécessaires que lors du formatage ; les métadonnées LUKS2 garantiront que la configuration appropriée est effectuée lors de l’ouverture ou de la fermeture.
Si aucun libellé de sous-système n’est spécifié, il sera automatiquement défini sur HW-OPAL afin qu’il soit immédiatement évident qu’un périphérique utilise OPAL.
FORMAT
luksFormat --type luks2 --hw-opal <périphérique> [<fichier de clé>]
Spécifiez également --hw-opal-only au lieu de --hw-opal pour éviter la couche dm-crypt. En plus du mot de passe habituel, un mot de passe administrateur devra être spécifié lors du formatage de la première partition du disque, et il devra être fourni à nouveau lors du formatage de toute autre partition jusqu’à ce qu’une réinitialisation d’usine soit effectuée.
EFFACER
erase <périphérique>
Efface de manière sécurisée une partition ou un périphérique. Nécessite un mot de passe administrateur. Spécifiez également --hw-opal-factory-reset pour une réinitialisation d’usine complète du disque, en utilisant le PSID du disque (généralement imprimé sur l’étiquette) au lieu du mot de passe administrateur.
Le PSID doit être saisi sans tirets, espaces ou soulignements.
AVERTISSEMENT : Une réinitialisation d’usine entraînera la perte de TOUTES les données du périphérique, quelle que soit la partition sur laquelle elle est exécutée, si elle existe, et quel que soit tout sauvegarde de l’en-tête LUKS2.
ACTIONS DIVERSES
RÉPARER
repair <périphérique>
Tente de réparer les métadonnées du périphérique si possible. Actuellement pris en charge uniquement pour le type de périphérique LUKS. Voir cryptsetup-repair(8).
ANALYSE comparative
benchmark <options>
Effectue une analyse comparative des chiffrements et de la fonction de dérivation de clé (KDF). Voir cryptsetup-benchmark(8).
MODE STANDARD OU LUKS ?
Sauf si vous comprenez bien les bases cryptographiques, utilisez LUKS. Avec le mode standard, il existe un certain nombre d’erreurs possibles de l’utilisateur qui diminuent considérablement la sécurité. Bien que LUKS ne puisse pas toutes les corriger, il peut en atténuer l’impact pour beaucoup d’entre elles.
AVERTISSEMENTS
De nombreuses informations utiles sur les risques liés à l’utilisation du stockage chiffré, sur la gestion des problèmes et sur les aspects de sécurité peuvent être trouvées dans les FAQ de Cryptsetup. Lisez-les. Néanmoins, certains risques méritent d’être mentionnés ici.
Sauvegarde : les supports de stockage tombent en panne. Le chiffrement n’y a aucune influence. La sauvegarde est obligatoire pour les données chiffrées, si les données ont une valeur. Voir les FAQ de Cryptsetup pour obtenir des conseils sur la manière de sauvegarder un volume chiffré.
Encodage des caractères : si vous entrez un mot de passe avec des symboles spéciaux, le mot de passe peut changer en fonction de l’encodage des caractères. Les paramètres du clavier peuvent également être modifiés, ce qui peut rendre la saisie à l’aveugle difficile, voire impossible. Par exemple, passer d’une variante ASCII 8 bits à UTF-8 peut entraîner un encodage binaire différent et, par conséquent, un mot de passe différent vu par cryptsetup, même si ce que vous voyez sur le terminal est exactement le même. Il est donc fortement recommandé de sélectionner des caractères de mot de passe uniquement à partir d’ASCII 7 bits, car l’encodage d’ASCII 7 bits reste le même pour toutes les variantes ASCII et UTF-8.
En-tête LUKS : si l’en-tête d’un volume LUKS est endommagé, toutes les données sont définitivement perdues, à moins que vous n’ayez une sauvegarde de l’en-tête. Si un emplacement de clé est endommagé, il ne peut être restauré qu’à partir d’une sauvegarde de l’en-tête ou si un autre emplacement de clé actif avec un mot de passe connu n’est pas endommagé. Ce risque est le résultat d’un compromis entre sécurité et sûreté, car LUKS est conçu pour un effacement rapide et sûr en écrasant simplement l’en-tête et la zone des emplacements de clé.
Partitions précédemment utilisées : S’il s’agit d’une partition précédemment utilisée, il est fortement conseillé de supprimer les signatures de système de fichiers, les données, etc., avant de créer un conteneur LUKS ou dm-crypt simple. Pour supprimer rapidement les signatures de système de fichiers, utilisez wipefs(8) avec l’option --all. Notez que cela ne supprime pas les données ; cela invalide uniquement les signatures de format connues. Pour une suppression complète, écrasez toute la partition avant de créer un conteneur. Si vous ne savez pas comment faire, la FAQ de cryptsetup décrit plusieurs options.
EXEMPLES
Exemple 1 : Créer un conteneur LUKS 2 sur le périphérique bloc /dev/sdX.
sudo cryptsetup --type luks2 luksFormat /dev/sdX
Exemple 2 : Ajouter une phrase de passe supplémentaire au créneau 5.
sudo cryptsetup luksAddKey --key-slot 5 /dev/sdX
Exemple 3 : Créer une sauvegarde de l’en-tête LUKS et l’enregistrer dans un fichier.
sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /var/tmp/NameOfBackupFile
Exemple 4 : Ouvrir le conteneur LUKS sur /dev/sdX et le mapper à sdX_crypt.
sudo cryptsetup open /dev/sdX sdX_crypt
ATTENTION : La commande de l’exemple 5 effacera tous les créneaux. Vous ne pourrez plus utiliser votre conteneur LUKS à moins que vous n’ayez une sauvegarde à restaurer.
Exemple 5 : Effacer tous les créneaux sur /dev/sdX.
sudo cryptsetup erase /dev/sdX
Exemple 6 : Restaurer l’en-tête LUKS à partir d’un fichier de sauvegarde.
sudo cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /var/tmp/NameOfBackupFile
CODES DE RETOUR
Cryptsetup renvoie 0 en cas de succès et une valeur non nulle en cas d’erreur.
Les codes d’erreur sont : 1 : paramètres incorrects, 2 : pas d’autorisation (mauvaise phrase de passe), 3 : manque de mémoire, 4 : périphérique incorrect spécifié, 5 : le périphérique existe déjà ou est occupé.
NOTES
Traitement des phrases de passe pour le mode PLAIN
Notez qu’il n’y a pas de hachage itératif ni de salage en mode simple. Si un hachage est effectué, il s’agit d’un hachage direct unique. Cela signifie que les phrases de passe de faible entropie sont faciles à attaquer en mode simple.
Depuis un terminal : La phrase de passe est lue jusqu’au premier retour à la ligne, c’est-à-dire « \n ». L’entrée sans le caractère de retour à la ligne est traitée avec le hachage par défaut ou le hachage spécifié avec --hash. Le résultat du hachage sera tronqué à la taille de clé du chiffrement utilisé, ou à la taille spécifiée avec -s.
Depuis stdin : La lecture se poursuivra jusqu’à un retour à la ligne (ou jusqu’à ce que la taille d’entrée maximale soit atteinte), le retour à la ligne final étant supprimé. La taille d’entrée maximale est définie par la même valeur par défaut intégrée que la taille maximale du fichier de clé et peut être remplacée à l’aide de l’option --keyfile-size.
Les données lues seront hachées avec le hachage par défaut ou le hachage spécifié avec --hash. Le résultat du hachage sera tronqué à la taille de clé du chiffrement utilisé, ou à la taille spécifiée avec -s.
Notez que si l’option --key-file=- est utilisée pour lire la clé depuis l’entrée standard, les nouvelles lignes à la fin de l’entrée ne sont pas supprimées.
Si « plain » est utilisé comme argument de l’option --hash, les données d’entrée ne seront pas hachées. Au lieu de cela, elles seront complétées avec des zéros (si elles sont plus courtes que la taille de la clé) ou tronquées (si elles sont plus longues que la taille de la clé) et utilisées directement comme clé binaire. Cela est utile pour spécifier directement une clé binaire. Aucun avertissement ne sera donné si la quantité de données lue depuis l’entrée standard est inférieure à la taille de la clé.
À partir d’un fichier de clés : il sera tronqué à la taille de la clé du chiffrement utilisé ou à la taille spécifiée par l’option -s, et utilisé directement comme clé binaire.
L’argument --hash est ignoré. L’option --hash n’est utilisable que pour l’entrée standard en mode « plain ».
Si le fichier de clés est plus court que la clé, cryptsetup se terminera avec une erreur. La taille d’entrée maximale est définie par la même valeur par défaut compilée que la taille maximale du fichier de clés et peut être modifiée à l’aide de l’option --keyfile-size.
Traitement des phrases de passe pour LUKS
Depuis un terminal : la phrase de passe est lue jusqu’à la première nouvelle ligne, puis traitée par PBKDF2 sans le caractère de nouvelle ligne.
Depuis l’entrée standard : LUKS lira les phrases de passe depuis l’entrée standard jusqu’à la première nouvelle ligne ou la longueur maximale du fichier de clés définie lors de la compilation. Si l’option --keyfile-size est spécifiée, elle est ignorée.
Depuis un fichier de clés : le fichier de clés complet est lu jusqu’à la taille maximale définie lors de la compilation. Les caractères de nouvelle ligne ne terminent pas l’entrée. L’option --keyfile-size peut être utilisée pour limiter ce qui est lu.
LUKS utilise la fonction de dérivation de clé basée sur un mot de passe (PBKDF) pour se protéger contre les attaques par force brute et pour offrir une certaine protection contre les phrases de passe à faible entropie (voir la FAQ de cryptsetup). LUKS1 prend en charge uniquement l’algorithme PBKDF2, tandis que LUKS2 prend également en charge Argon2, qui est gourmand en mémoire. Les PBKDF sont configurés avec des coûts : la durée pendant laquelle l’itération doit s’exécuter (coût CPU ou nombre d’itérations), la quantité de mémoire utilisée (coût mémoire) et le nombre de processus parallèles utilisés (coût parallèle). PBKDF2 ne prend en charge que le nombre d’itérations. Cryptsetup utilise le banc d’essai PBKDF pour calculer les coûts optimaux en fonction de l’ordinateur sur lequel la nouvelle phrase de passe est initialisée. Si nécessaire, ces coûts peuvent également être remplacés. Notez qu’il existe certaines limites codées en dur, pour plus de détails, consultez la section COÛTS MINIMAUX ET MAXIMAUX DE PBKDF dans la description de l’option --pbkdf.
Chaque fois qu’une phrase de passe est ajoutée à un en-tête LUKS (luksAddKey, luksFormat), l’utilisateur peut spécifier la durée pendant laquelle le traitement de la phrase de passe doit durer. La durée est utilisée pour déterminer le nombre d’itérations pour PBKDF2, et des durées plus longues offriront une meilleure protection pour les phrases de passe à faible entropie, mais la commande open prendra plus de temps à s’exécuter. Pour les phrases de passe dont l’entropie est supérieure à la longueur de clé utilisée, des durées d’itération plus longues n’augmenteront pas la sécurité.
Le paramètre par défaut de une ou deux secondes est suffisant pour la plupart des cas pratiques. La seule exception est une phrase de passe à faible entropie utilisée sur un appareil doté d’un CPU lent, car cela entraînera un faible nombre d’itérations. Sur un appareil lent, il peut être conseillé d’augmenter le temps d’itération à l’aide de l’option --iter-time afin d’obtenir un nombre d’itérations plus élevé. Cela ralentit toutes les opérations luksOpen ultérieures.
Comportement incohérent pour les phrases de passe/clés non valides
LUKS vérifie la validité de la phrase de passe lorsqu’un emplacement de clé est déchiffré.
Le comportement de dm-crypt simple est différent. Il déverrouille toujours le périphérique avec la phrase de passe fournie. Si la phrase de passe fournie est incorrecte, le périphérique mappé par dm-crypt simple utilisera la mauvaise clé de chiffrement et les données seront illisibles.
Ciphers, modes, hachages et tailles de clé pris en charge
Les combinaisons disponibles de ciphers, de modes, de hachages et de tailles de clé dépendent du support du noyau. Consultez /proc/crypto pour obtenir la liste des options disponibles. Vous devrez peut-être charger des modules crypto supplémentaires pour obtenir plus d’options.
Cryptsetup traite de nombreuses opérations en dehors du noyau, donc la bibliothèque cryptographique configurée doit également prendre en charge les algorithmes sélectionnés. Certains algorithmes peuvent être manquants car cryptsetup peut être compilé avec divers backends cryptographiques (bibliothèques).
Remarques sur les phrases de passe
Les mathématiques ne peuvent pas être corrompues. Assurez-vous de conserver vos phrases de passe en sécurité. Il existe quelques astuces pour construire une solution de secours lorsqu’il arrive, soudainement et de manière inattendue, que votre cerveau refuse de coopérer. Ces solutions de secours nécessitent LUKS, car c’est uniquement avec LUKS qu’il est possible d’avoir plusieurs phrases de passe. Toutefois, si votre modèle de menace ne l’empêche pas, stocker votre phrase de passe dans une enveloppe scellée quelque part peut être une bonne idée.
Remarques sur les générateurs de nombres aléatoires
Les générateurs de nombres aléatoires (GNA) utilisés dans cryptsetup sont toujours les GNA du noyau, sans aucune modification ni ajout au flux de données produit.
Il existe deux types d’aléatoire dont cryptsetup/LUKS a besoin. L’un est utilisé pour les sels, le diviseur AF et pour l’effacement des emplacements de clé supprimés. Le second est utilisé pour la clé de volume.
Avec les noyaux récents (noyau Linux 5.6), vous n’avez pas besoin de vous soucier du choix du GNA (/dev/random ou /dev/urandom). Dans une situation de faible entropie (système embarqué), l’initialisation du GNA du noyau peut prendre très longtemps, mais cela se produit avant que cryptsetup ne puisse même démarrer. Utilisez cryptsetup --help pour afficher le GNA par défaut compilé. Consultez urandom(4) pour plus d’informations.
Chiffrement de disque authentifié (EXPÉRIMENTAL)
Les modes de chiffrement de disque normaux sont de taille fixe (le secteur de texte clair a la même taille qu’un secteur de texte chiffré) et ne peuvent fournir que la protection de la confidentialité, et non une protection de l’intégrité des données cryptographiquement fiable.
Les modes authentifiés nécessitent un espace supplémentaire par secteur pour la balise d’authentification et utilisent des algorithmes de chiffrement authentifié avec des données supplémentaires (AEAD).
Si vous configurez un périphérique LUKS2 avec une protection de l’intégrité des données, il y aura un périphérique dm-integrity sous-jacent, qui fournit un espace de métadonnées supplémentaire par secteur et une protection du journal des données pour garantir l’atomicité des mises à jour des données et des métadonnées. Étant donné qu’il doit y avoir un espace supplémentaire pour les métadonnées et le journal, l’espace disponible pour le périphérique sera inférieur à celui des modes de taille fixe.
Le périphérique dm-crypt réside ensuite au-dessus d'un tel périphérique dm-integrity. L'activation et la désactivation de cette pile de périphériques sont effectuées par cryptsetup ; il n'y a aucune différence dans l'utilisation de luksOpen pour les périphériques protégés par l'intégrité. Si vous souhaitez formater un périphérique LUKS2 avec une protection de l'intégrité des données, utilisez l'option --integrity (voir cryptsetup-luksFormat(8)).
Bien que le noyau Linux 5.7 ait ajouté la prise en charge de TRIM pour les périphériques dm-integrity autonomes, cryptsetup(8) ne peut pas offrir de prise en charge des commandes de suppression (TRIM) en mode de chiffrement authentifié, car le module de noyau dm-crypt sous-jacent ne prend pas en charge cette fonctionnalité lorsque dm-integrity est utilisé comme espace d'allocation de balise d'authentification (voir --allow-discards dans cryptsetup-open(8)).
Certains modes d'intégrité nécessitent deux clés indépendantes (une clé pour le chiffrement et une clé pour l'authentification). Ces deux clés sont stockées dans un seul emplacement de clés LUKS.
La prise en charge des modes authentifiés est expérimentale, et seuls certains modes sont disponibles actuellement. Notez que très peu d'algorithmes de chiffrement authentifiés sont adaptés au chiffrement de disque. Vous ne pouvez pas non plus utiliser CRC32 ou d'autres sommes de contrôle non cryptographiques (à l'exception du mode d'intégrité spécial « none »). Si, pour une raison quelconque, vous souhaitez avoir un contrôle d'intégrité sans utiliser le mode d'authentification, vous devez configurer dm-integrity séparément, indépendamment de LUKS2.
Remarques sur l'utilisation du périphérique loopback
Cryptsetup est généralement utilisé directement sur un périphérique bloc (partition de disque ou volume LVM). Cependant, si l'argument de périphérique est un fichier, cryptsetup tente d'allouer un périphérique loopback et de le mapper dans ce fichier. Bien sûr, vous pouvez toujours mapper un fichier sur un périphérique loopback manuellement. Voir la FAQ de cryptsetup pour un exemple.
Lorsque le mappage de périphérique est actif, vous pouvez voir le fichier de mappage loopback dans la sortie de la commande status. Voir également losetup(8).
Verrouillage de l'en-tête LUKS2
Les métadonnées LUKS2 sur disque sont mises à jour en plusieurs étapes, et pour obtenir une mise à jour atomique correcte, il existe un mécanisme de verrouillage. Pour une image dans un fichier, le code utilise l'appel système flock(2). Pour un périphérique bloc, le verrouillage est effectué sur un fichier spécial stocké dans un répertoire de verrouillage (par défaut /run/cryptsetup). Le répertoire de verrouillage doit être créé avec le contexte de sécurité approprié par la distribution pendant la phase de démarrage. Seul LUKS2 utilise des verrous ; les autres formats n'utilisent pas ce mécanisme.
Spécification du format LUKS sur disque
Pour la spécification des métadonnées LUKS sur disque, voir LUKS1 [https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification] et LUKS2 [https://gitlab.com/cryptsetup/LUKS2-docs].
AUTEURS
Cryptsetup a été initialement écrit par Jana Saout <_>. Les extensions LUKS et la page de manuel originale ont été écrites par Clemens Fruhwirth <_>. Extensions de la page de manuel par Milan Broz <_>. Réécriture et extension de la page de manuel par Arno Wagner <_>.
SIGNALEMENT DES BUGS
Signalez les bugs sur la liste de diffusion cryptsetup <_> ou dans la section des problèmes du projet. [https://gitlab.com/cryptsetup/cryptsetup/-/issues/new].
Veuillez joindre la sortie de la commande ayant échoué avec l’option --debug ajoutée.
VOIR AUSSI
FAQ de Cryptsetup [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions]
cryptsetup(8), integritysetup(8) et veritysetup(8)
CRYPTSETUP
Fait partie du projet cryptsetup [https://gitlab.com/cryptsetup/cryptsetup/].