Outils pour utilisateurs

Outils du site


expert:systeme_chiffre_luks_pam_cryptsetup

Chiffrer son disque avec cryptsetup, luks, pam-mount

Logo de LUKS :

Cette page traite de deux différentes méthodes pour mettre en place un chiffrement de partitions basé sur luks ("Linux Unified Key Setup") et cryptsetup, avec ou sans pam-mount qui permet de coupler le déchiffrement de partitions avec le login d'un utilisateur. Vous verrez comment créer des conteneurs chiffrés LUKS, utilisez un mot de passe ou une clé pour les déchiffrer, utiliser le module “pam” pour déchiffrer votre /home au login, ou encore comment chiffrer la swap avec “decrypt_derived” de manière à pouvoir utiliser la veille sur disque et limiter la multiplication des mots de passe.
Les méthodes présentées ici ont été testées et sont utilisées sur Debian et (K)Ubuntu, “cryptsetup”, “luks” et “pam” sont des outils présents sur quasiment toutes les distributions et les commandes présentées ici devraient être facilement transposables. L'emplacement de certains fichiers de configuration peut en revanche être différent.

Un signe $ précède les commandes qui ne nécessitent pas de droits administrateur ; un signe # précède celles qui nécessitent des droits administrateur, ces signes ne font PAS partie des commandes. Les lignes qui ne commencent pas par un signe $ ou # correspondent au résultat de la commande précédente. Voyez cette page si vous ne savez pas comment obtenir des droits administrateur.
Les manipulations présentées ici ont le potentiel de rendre votre système inopérant (“inbootable”), de détruire des données si des erreurs sont faites dans l'exécution des commandes. Vous devez faire une sauvegarde de l'ensemble de vos données, de préférences sur un disque amovible qui ne sera pas connecté pendant les manipulations (évite le risque de confusion de partitions).
Les opérations d'écriture de données aléatoires sur une partition, de création d'un conteneur chiffré, de formatage provoquent la destruction de toutes les données contenues sur la partition visée, utilisez ce tutoriel en connaissance de cause.

Généralités sur le chiffrement

Pourquoi chiffrer ?

Nos ordinateurs sont des cibles de choix pour les voleurs, dans le cadre d'un cambriolage ou plus souvent d'un vol d'ordinateur portable dans les transports, au bureau, en voyage, …etc. Si le vol de la machine est déjà un coup dur financier, le fait de savoir nos données personnelles entre des mains malveillantes est bien plus pesant encore. Qu'il s'agisse de photos personnelles, de courriels ou de documents professionnels retrouver ses donnés éparpillées sur le net n'est pas une expérience agréable. Voici la première motivation pour protéger ses données par chiffrement.
Se protéger de collègues trop curieux, d'un petit frère aux talents de cracker, chacun aura ses propres motivations pour prendre cette mesure de protection de sa vie privée numérique.
Chiffrer ses partitions est le moyen le plus sûr d'en rendre l'accès impossible à un voleur, mais également à un curieux qui tenterait de démarrer la machine sur un live-cd afin d'examiner le contenu de vos disques. Une fois le chiffrement en place plus rien ne sera accessible sans la clé ou le mot de passe.

Bien chiffrer

Pour que le chiffrement soit efficace il ne faut pas faire d'erreur lors de la mise en place, et bien réfléchir aux implications. Chiffrer uniquement une partition de données peut sembler suffisant, mais cela laissera exposées de nombreuses informations contenues dans les répertoires “cachés” dans votre dossier personnel. Les cookies, caches et profils des navigateurs Internet, de nombreux clients de messagerie y stockent les répertoires des courriels, l'historique de vos sessions de “chat”. Il faut donc au minimum chiffrer son répertoire personnel, et pour que cela soit vraiment efficace il faut également toujours chiffrer la partition d'échanges “swap”. Tout ce qui est mis en swap est écrit sur le disque, et sera donc accessible à des techniques de récupération de données. Si vous possédez peu de mémoire vive, ou laissez des applications ouvertes inactives pour de longues périodes, vous risquez de voir “swappé” des données sensibles. Si vous utilisez la mise en veille sur disque l'ensemble de votre session sera écrite sur la swap, cela peut totalement annihiler vos efforts de protection, c'est d'autant plus lourd de conséquences que dans certaines circonstances la clé de chiffrement des conteneurs “luks” peut se trouver écrite en swap…
Le cas de la partition système est plus nuancé, si vous voulez juste vous prémunir contre le vol de votre ordinateur il n'est pas indispensable de chiffrer la partition système. Si en revanche vous avez des impératifs de sécurité stricts, ou êtes (à tord ou à raison ;-) ) paranoïaques vous chiffrerez également le système pour éviter la mise en place d'un cheval de Troie ou autre espiogiciel destiné à enregistrer votre mot de passe ou clé de chiffrement (attaque dite “Evil maid”). Vous devrez au minimum conserver une partition /boot non chiffrée, et si vous êtes jusqu'au-boutiste vous placerez celle-ci sur un média amovible (clé usb) afin qu'elle ne puisse pas être manipulée à votre insu. Même si vous décidez de ne pas chiffrer la partition système il vaudrait mieux chiffrer /tmp (données temporaires), /var/ (en particulier pour /var/mail et /var/log), plus /www ou autres en fonction de l'usage du système.
Bien entendu vous devez utiliser un mot de passe de bonne qualité ou une clé générée de manière aléatoire et stockée sur un média amovible lui-même chiffré (par mot de passe). Il ne sert à rien d'utiliser un robuste chiffrement si le conteneur est protégé par un mot de passe faible.
Les partitions destinées à être chiffrées devront également être préparées par l'écriture de données (pseudo) aléatoires auparavant, sinon la cryptanalyse en sera facilitée, surtout sur un disque neuf où les blocs ont été “mis à zéro” en usine. La préparation peut-être faite avec une commande comme (pour la partition sda1) :

# dd if=/dev/urandom of=/dev/sda1

ou alternativement :

# badblocks -wt random /dev/sda1

Vous pouvez également utiliser une programme spécialisé écrivant de manière répétée sur les disques, mais dans tous les cas le processus sera long, très long même pour de grandes partitions, prévoyez du temps pour cette opération. Pour utiliser au mieux /dev/random, un générateur matériel de nombres aléatoires peut être installé, sinon une solution logiciel est tout à fait adaptée aussi (voir plus bas).

Précisions quand au temps utilisé.

Il varie qu'on veuille utiliser le réservoir d'entropie de /dev/random, ou le réservoir d'entropie de /dev/urandom. Sur un ordinateur relativement récent (aujourd'hui nous sommes le 12 août 2013), et qui a quatre cœurs, modèle Intel Q9650 @ 3Ghz, + 4 gigas de ram, Linux Ubuntu 12.04 LTS, écriture sur un SSD récent, ce SSD est un SSD Samsung séries 840 120GO et précision aussi, SSD branché sur une carte mère Intel modèle DG33BU et SSD branché en SATA 3Gbits/sec (vitesse par port sur cette carte mère). Voilà pour le côté technique et matériel. En utilisant le réservoir d'entropie /dev/random, la vitesse d'écriture maxi pour cette configuration est de 0,6 kb/sec (elle varie pendant l'opération entre 0,4 kb/sec et 0,6 kb/sec), ce qui fait qu'en 10 heures on écrit 20 mégas environ de données aléatoires. Sur ce SSD qui fait 120 000 méga-octets, il faut quasiment 7 années pour le remplir. En utilisant le réservoir d'entropie de /dev/urandom, les 120 000 méga-octets de ce SSD sur la même configuration matériel à quelques minutes près d’intervalle entre l'utilisation du réservoir d'entropie /dev/random et /dev/urandom, les 120 000 méga-octets se sont remplis en environ six heures et trente minutes. Si vous avez des fichiers légers (quelques kilo-octets, jusqu'à plusieurs dizaines de méga-octets) et qui sont ultra-sensibles et à protéger de la meilleure façon, alors il faudra utiliser le réservoir d'entropie de /dev/random.

Si vous voulez par contre écrire sur une partition de 2 téra-octets, ce sera /dev/urandom qui s'imposera, sachant que la sécurité qu'il procure est quand même excellente.

Seuls sont maîtres du temps ceux qui le choisissent, alors vous êtes libres d'utiliser /dev/random ou /dev/urandom comme vous le souhaitez.

Exemple d'une partition de 150 méga-octets s'appelant “sdb1”. Je conseille de faire ainsi:

_vous ouvrez un terminal, vous vous loggez en utilisateur “root”, sous Ubuntu 12.04 LTS, je dois faire un :

$ sudo -i

Et la commande pour une sécurité maximale en utilisant donc /dev/random sera :

# dd if=/dev/random of=/dev/sdb1

Le signe # au début de la ligne de commande sera déjà dans le terminal une fois que vous vous serez loggé en utilisateur “root”. (Relisez tout au début de cet article, la partie dans l'encadré vert).

Pour utiliser /dev/urandom, beaucoup plus rapide, la commande sera :

# dd if=/dev/urandom of=/dev/sdb1

Pour plus d'options avec la commande “dd”, rendez-vous ici.

Pour aller plus loin au niveau du matériel, voyez par exemple ici, les différents générateurs matériel de nombres aléatoires.

Ici un exemple de logiciel gratuit qui génère des nombres aléatoires (et non pas des nombres pseudo-aléatoires) se basant sur le “bruit” de la carte son de votre ordinateur. Pour Linux audio entropy daemon a fonctionné avec transparence sur Ubuntu 12.04 LTS, il écrit donc les nombres créés dans /dev/random.

/dev/urandom ou badblocks ne fournissent pas des données réellement aléatoires mais “pseudo-aléatoires”. Pour obtenir le niveau maximum de sécurité il faudrait utiliser /dev/random à la place de /dev/urandom, mais pour fonctionner /dev/random nécessite un réservoir d'entropie confortable. Les données aléatoires sont dérivées du “bruit” ou entropie générée par l'activité de certains matériels dont les disques durs et leurs pilotes, si le “réservoir” est à zéro la commande “dd” se mettra en pause, augmentant d'autant la durée de l'opération. Vous pouvez avoir une idée de la taille de votre “réservoir” d'entropie en regardant les valeurs sous /proc/sys/kernel/random/. Il existe des générateurs d'entropie matériels qui se présentent sous la forme d'un périphérique usb, leur qualité varie autant que leur prix, mais ce type d'appareils est la meilleur façon d'obtenir des données aléatoires en quantité suffisante. Des générateurs de données aléatoires logiciels existent également, ils utilisent souvent le trafic réseau ou communiquent avec un générateur d'entropie distant. Pour un usage courant /dev/urandom fera très bien l'affaire. Si vous générez des clés de chiffrement (petite quantité de données nécessaire) pour vos conteneurs LUKS préférez /dev/random.

Les limites du chiffrement

Quelque soit la méthode employée le chiffrage a ses limites, il est très efficace dans le cas d'un vol d'une machine éteinte, en revanche le chiffrement est contournable si l'attaquant a un accès physique à la machine (remplacement du bios, espiogiciels installés dans le secteur d'amorçage du disque ou le firmware d'un périphérique, et bien d'autres). De plus le moyen le plus simple d'accéder aux données sera de voler l'ordinateur une fois la session ouverte, ou de “convaincre” le propriétaire de divulguer le mot de passe… Bref, si vous êtes le cousin de James Bond il vous faudra réfléchir à des mesures supplémentaires, si vous êtes juste soucieux de la protection de votre vie privée numérique ça devrait suffire.
Bien entendu ne perdez jamais de vu que vous devez conserver des sauvegardes de vos données (chiffrées elles aussi), car en cas de problème sur les conteneurs luks (en-têtes du conteneur endommagées, mot de passe ou clé perdus, …etc) vos données sont irrécupérables, il n'y a aucun espoir si le chiffrement a été correctement mis en place. Il ne vous reste qu'à attendre et espérer que dans un futur pas trop lointain une faille de sécurité, une avancée spectaculaire en mathématique ou un bond de la puissance de calcul des ordinateurs permettra de casser le chiffrement.

En voyage le chiffrement pourra éveiller la suspicion des douaniers et autres polices des frontières. Dans certains pays comme les EUA ou Singapour les autorités pourront exiger que vous leur donniez vos mots de passe et clés d'accès, la loi les autorisant à confisquer n'importe quel matériel pour examen ou à imager un disque dur pour analyse. En cas de refus de votre part l'entrée sur le territoire vous sera refusée, plus éventuellement quelques “joyeusetés” (amende, intimidation, séjour en prison, confiscation du matériel, …etc).


:!: Les en-têtes de conteneurs chiffrés luks sont extrêmement sensibles à la corruption, il suffit d'un seul octet endommagé à cet endroit pour rendre le conteneur indéchiffrable (pensez perte d'un secteur du disque dur). Il est impératif de conserver une copie de sauvegarde de ces en-têtes sur un ou plusieurs média séparés (clé usb, cdrom) afin de pouvoir les restaurer. Vous pouvez utiliser :

# cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file /ma/clé/usb/testcrypt_lukshead

où votre conteneur chiffré a été créé sur “/dev/sda2” et votre média de sauvegarde est monté sur /ma/clé/usb/.

La résistance à la cryptoanalyse de ces sauvegardes est plus faible que pour les en-têtes originales, gardez les en lieu sûr. Si vos mots de passe ou clés de déchiffrement sont compromis, et que vous les changiez, refaites ces sauvegardes et détruisez totalement les anciennes. En restaurant les anciennes en-têtes un attaquant pourrait sinon déchiffrer le conteneur à l'aide des anciens mots de passe ou clé de déchiffrement.

Chiffrer /home

De nombreuses distributions proposent le chiffrement de votre répertoire personnel à l'installation, on supposera ici que vous partez d'une système standard “en clair”. La façon la plus simple de chiffrer serait de sauvegarder vos données et de réinstaller, Ubuntu permet de chiffrer votre dossier personnel (avec “ecryptfs”, moins sûr que luks car les métadonnées du système de fichiers sont accessibles), les cd “alternatifs” d'Ubuntu et dérivés permettent de chiffrer des partitions (y compris système) avec “luks” et des volumes logiques (lvm). Debian offre la même approche en utilisant un seul conteneur luks renfermant des volumes logiques “lvm” pour le système et l'espace d'échange “swap”, l'installeur Debian ne vous laissera pas chiffrer une partition sans chiffrer également la swap. Mais pour conserver votre liberté de partitionnement, ne pas utiliser les lvm, ou simplement pour comprendre et maîtriser l'installation rien ne vaut une mise en place “manuelle”. Cette approche vous évitera d'être laissé dans le flou si un jour “l'automagie” mise en place par la distribution connaît des ratés.

Pour commencer vous devrez avoir de la place pour une nouvelle partition destinée au chiffrement, en effet la procédure détruit totalement les données déjà présentes. Avant toute chose faite une sauvegarde de vos données !. On suppose que vous disposez au moins d'une partition système, de partitions “swap” et /home séparées.

Voici l'hypothèse de départ concernant le partitionnement de votre disque :

=========================================================================
|  B  |    R	|						|   S	|
|  O  |    O	|	                /HOME			|   W	|
|  O  |    O	|						|   A	|
|  T  |    T	|						|   P	|
=========================================================================
  sda1	  sda2				sda3			   sda4

Les partitions peuvent être primaires ou logiques, simples ou être des volumes RAID, cela n'a pas d'importance. Si vous utilisez les volumes logiques (lvm) il est recommandé les mettre en place après création des conteneurs chiffrés, et non l'inverse.
Si vous ne souhaitez chiffrer que votre répertoire personnel sur “/home” et la partition d'échange “swap” vous n'avez pas besoin d'une partition “/boot” séparée, en revanche celle-ci est indispensable si vous chiffrez la partition système.

Pas de partition “/home” séparée ? Dans ce cas il vous suffit de chiffrer la partition racine “/” et votre répertoire personnel sera protégé en même temps. Voyez “Chiffrer la partition système” plus bas.

Vous pouvez travailler depuis votre système en mode “single user” (mode de récupération ou “init 1”, ligne de commande exclusivement), ou depuis un live-cd (environnement graphique disponible, connexion Internet, …etc). Dans tous les cas vous devrez avoir installé cryptsetup, libpam-mount, accessoirement mdadm si vos partitions sont situées sur des volumes raid, lvm2 si vous souhaitez utiliser des volumes logiques. Ces paquets doivent être présents sur votre système d'origine, ils seront nécessaires au redémarrage, et fournissent des fichiers de configuration que nous allons éditer. Seul “cryptsetup” doit également être présent sur le système de travail (live-cd) sinon vous n'aurez tout simplement pas accès aux commandes nécessaires. Si votre système repose sur du raid ou des lvm ajoutez les paquets correspondant (mdadm et lvm2).

Préparation du système

Sur votre système installez les paquets nécessaires : cryptsetup, libpam-mount. Nous allons mettre en place un déchiffrement et montage automatique au login de votre partition /home par pam-mount, pour que cela fonctionne il faut que votre mot de passe d'utilisateur et le mot de passe de chiffrement du conteneur qui supporte /home soient les mêmes. Un mot de passe utilisateur standard est rarement assez complexe pour faire un bon mot de passe luks, c'est un bon moment pour en changer si c'est votre cas. Le minimum raisonnable serait 18 à 20 caractères, pas de mots existant dans un dictionnaire (quelque soit la langue), pas de date de naissance, des lettres minuscules et majuscules, des chiffres et des caractères spéciaux (ponctuation, symboles). Un bon mot de passe doit être le plus complexe que vous puissiez raisonnablement retenir sans avoir à l'écrire quelque part (Ha! le fameux “post-it”…). Retenez également que vous devrez le taper sans retour visuel.

Un bon mot de passe est pénible à taper à longueur de journée, et de plus à chaque fois que vous le tapez vous augmentez les risques qu'il soit visuellement intercepté (espionnage “par dessus l'épaule” directe ou par l'intermédiaire de caméras). pam-mount impose d'utiliser le même mot de passe pour votre utilisateur et le conteneur luks, si vous utilisez “sudo” pour administrer votre système ça peut vite devenir pesant, voir aller à l'encontre de l'objectif de sécurité initial. Imaginez que vous devrez taper le mot de passe au login, pour chaque commande “sudo”, si l'économiseur d'écran se lance (le verrouillage par mot de passe de l'économiseur d'écran est une mesure basique de sécurité). Pour toutes ces raisons il peut être préférable de ne pas utiliser pam-mount, vous devrez taper le mot de passe de déchiffrement de votre conteneur luks, puis votre login utilisateur qui pourra être différent. L'autre possibilité étant d'activer le compte root avec un mot de passe indépendant (et oui, même sur les *Ubuntu c'est possible) et de l'utiliser pour l'administration, ou de configurer sudo pour demander le mot de passe root (option “Defaults rootpw” dans /etc/sudoers).
Sinon vous pouvez utiliser une clé dérivée pour chiffrer la partition “/home”, voyez “Chiffrer la partition d'échange “SWAP”” plus bas pour la méthode générale. Cela implique que la partition système soit chiffrée également.

Détruire et recréer une partition vide pour /home

Une fois les données sauvegardées détruisez la partition /home, écrivez des données aléatoires pour effacer le contenu précédant (facultatif, voir plus haut “Bien chiffrer”), puis recréez une partition sans système de fichiers. Si vous utilisez un programme comme GParted ou PartitionManager choisissez “aucun système de fichier” ou “non formaté”. Si vous utilisez “(s-c-g)fdisk” vous afficherez la table de partition avec “p”, puis vous choisirez “d” (détruire, ne vous trompez pas de partition !), puis “n” (nouvelle, laissez les choix par défaut ou redimensionnez la partition selon vos besoins), avant d'écrire les modifications sur le table de partition avec “w” (write). À tout moment “q” (quit) permet de quitter sans écrire les modifications sur le disque.
Un exemple de destruction et création de partition dans fdisk :

# gfdisk /dev/sda

GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

Using /dev/sda
Command (m for help): m                                                   
Command action
   a   toggle bootable flag
   b   edit bsd disklabel
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Command (m for help): p

Disk /dev/sda: 10 GB, 10733990400 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

 Device    Boot      Start        End      Blocks   Id  System
/dev/sda1               1         666     5349613   83  Linux
/dev/sda3             667        1047     3052350   83  Linux
/dev/sda2            1048        1305     2064352   83  Linux

Command (m for help): d                                                                                                                      
Partition number (1-3): 3                                                                                                                    

Command (m for help): n                                                                                                                      
Partition type                                                                                                                               
   e   extended                                                                                                                              
   p   primary partition (1-4)                                                 
p                                                                                                                                            First cylinder  (default 666cyl):                                         
Last cylinder or +size or +sizeMB or +sizeKB  (default 1046cyl):
Command (m for help): w                                                   
Information: Don't forget to update /etc/fstab, if necessary.             

Writing all changes to /dev/sda.
Si votre /home est inclus dans la partition racine (une seule partition pour le système et le répertoire personnel), vous pouvez facilement réduire la partition unique, en créer une nouvelle qui servira de /home séparé et dans laquelle vous déplacerez votre répertoire personnel.

Créer un conteur chiffré "luks" pour /home

Maintenant lancez une console et en ligne de commande utilisez “cryptsetup” pour créer le conteneur chiffré sur votre nouveau /home (/dev/sda3 ici) :

# cryptsetup --hash=sha256 luksFormat /dev/sda3

WARNING!
========
Cela écrasera de façon définitive les données sur /dev/sda3.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: 
Verify passphrase: 

Il vous sera demandé de confirmer en écrivant “YES” en majuscules, puis vous devrez choisir un mot de passe et le saisir deux fois pour vérification. C'est fait, le conteneur est créé.

Vous pouvez utiliser de nombreuses options avec cryptsetup pour choisir un algorithme de chiffrement, utiliser un fichier clé au lieu d'un mot de passe pour déverrouiller le conteneur luks, et bien plus. Pour le moment je vous conseil de conserver les options par défaut qui sont sûres et éprouvées. Pour connaître les paramètres utilisés par défaut tapez :

$ cryptsetup --help

L'option par défaut pour luks est en général “aes-cbc-essiv:sha256 (Rinjdael 256 bits), Key: 256 bits, LUKS header hashing: sha1”. D'autres options existent pour utiliser des algorithmes comme “twofish” ou “serpent”, différentes longueurs de clé ou encore sha256, sha512 ou whirlpool pour le hachage. C'est ici la seule différence avec le réglage par défaut que je suggère, car le hachage sha1 ne peut plus vraiment être considéré comme sûr, ses faiblesses sont aujourd'hui démontrées. La seule raison pour laquelle sha1 est conservé par défaut est le soucis de préserver la compatibilité avec des versions anciennes de cryptsetup (les conteneurs luks n'utilisant pas sha1 ne seront pas déchiffrables avec ces anciennes versions de cryptsetup). Cette considération est justifiée dans l'informatique embarquée et les appareils où une mise à niveau est impossible, en revanche sur un ordinateur l'installation d'une version plus récente de cryptsetup n'est jamais impossible. Même si vous utilisez sha1 la sécurité reste pour le moment satisfaisante, les attaques connues nécessitant une puissance de calcul à la limite du matériel actuel.

Pour illustrer les options principales voici une exemple de chiffrage “alternatif” avec l'algorithme “twofish”, utilisation d'un fichier-clé au lieu d'un mot de passe :

# cryptsetup --cipher=twofish-cbc-essiv:sha256 --key-file=/media/macleusb/home.key --hash=sha256 luksFormat /dev/sda3

L'option “--key-file=” permet d'indiquer le chemin d'un fichier qui sera la clé de déchiffrement du conteneur luks. Au lieu de taper un mot de passe vous devrez toujours fournir un chemin vers ce fichier-clé pour ouvrir le conteneur chiffré.

Pour pouvoir utiliser un algorithme de chiffrage avec cryptsetup il faut que le module noyau correspondant soit chargé. Pour voir ce qui actuellement chargé sur votre système faites :

$ cat /proc/crypto

Pour voir ce qui est disponible avec votre noyau faites, au choix :

# modprobe -l | grep crypto

$ ls -l /lib/modules/$(uname -r)/kernel/crypto/

Pour charger un module particulier utilisez “modprobe”.

Formater /home

Maintenant nous allons ouvrir le conteneur chiffré nouvellement créé, l'inspecter et le formater en ext4. Remarquez le point de montage sous /dev/mapper/ :

# cryptsetup luksOpen /dev/sda3 testcrypt

Enter passphrase for /dev/sda3: 


$ ls -l /dev/mapper

total 0
crw------- 1 root root 10, 59 2011-03-10 10:53 control
lrwxrwxrwx 1 root root      7 2011-03-10 11:55 testcrypt -> ../dm-0

# cryptsetup status testcrypt
/dev/mapper/testcrypt is active:
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/sda3
  offset:  2056 sectors
  size:    4142714 sectors
  mode:    read/write

# mkfs.ext4 -L testcrypt /dev/mapper/testcrypt

La syntaxe de la commande luksOpen est [partition source] [mapping] où “partition source” est l'adresse de votre partition chiffrée (ici /dev/sda2) et “mapping” est un nom (arbitraire) que vous choisissez pour identifier le conteneur ouvert sous /dev/mapper/.

Maintenant vous pouvez monter votre système de fichier tout frais et y copier votre sauvegarde de /home. Au passage notez l'identifiant UUID de la partition, vous en aurez besoin bientôt :

# blkid /dev/sda3

/dev/sda3: UUID="1e1688df-72bc-45d1-824a-59d5f35g20v" TYPE="crypto_LUKS"

Vous pouvez également consulter /dev/disk/by-uuid pour connaître l'UUID.

Utiliser pam-mount pour coupler le login et le déchiffrement de /home

Pour éviter d'avoir à fournir un mot de passe pour déchiffrer le conteneur de /home pendant le démarrage, puis un second lors du login, nous allons coupler les deux avec pam-mount.

Pour laisser pam-mount gérer le déchiffrage et montage de votre /home vous devez retirez ou commenter la ligne du fichier /etc/fstab qui y fait référence, ainsi que la ligne du fichier /etc/crypttab si vous en aviez déjà ajouté une. Concrètement ça donne pour le /etc/fstab :

#/dev/mapper/testcrypt   /home    ext4    defaults,relatime        0       2

Vous voyez la ligne qui devrait figurer pour une utilisation de luks traditionnelle, et le signe dièse # en début de ligne qui la désactive.
Idem pour /etc/crypttab :

#testcrypt     UUID=1e1688df-72bc-45d1-824a-59d5f35g20v     none     luks,tries=2,timeout=10

La ligne du fichier crypttab est commentée, cryptsetup ne prendra pas en charge ce conteneur au démarrage.

Maintenant créons la configuration “pam” en éditant /etc/security/pam_mount.conf.xml, Ajoutez en bas de fichier, juste avant le </pam_mount> final :

<volume user="MONUSER" fstype="crypt" path="/dev/disk/by-uuid/1e1688df-72bc-45d1-824a-59d5f35g20v" mountpoint="/home" options="fsck,relatime" />

Évidement vous replacerez MONUSER par votre nom de connexion, et le chemin /dev/disk/by-uuid/ devra comporter l'UUID correcte de VOTRE partition chiffrée /home. L'option de montage “relatime” est totalement facultative.

Redémarrez maintenant, si tout est bien en place vous ne devriez rien constater de particulier, le déchiffrement à la connexion est totalement transparent. Si vous rencontrez des problèmes vérifier soigneusement l'adresse de votre partition chiffrée (utiliser les UUID) dans les fichiers de configuration.

Chiffrer la partition d'échange "SWAP"

Ici plusieurs solutions sont possibles, celle que vous adopterez dépendra de votre usage de la veille sur disque (hibernation). La mise en veille en mémoire vive est toujours possible, mais elle peut compromettre la sécurité de votre système si un attaquant a accès à l'ordinateur alors qu'il est en veille.

Génération d'une clé de chiffrement aléatoire à chaque démarrage, mise en veille sur disque impossible

La première solution est la plus sûre, mais elle peut allonger le temps de démarrage et interdit l'hibernation (la mise en veille en mémoire vive est elle possible). Pour l'utiliser il suffit d'ajouter une ligne à votre fichier /etc/crypttab :

#swap cryptée
cryptswap        /dev/disk/by-uuid/xxxx-xxx-xxxx-xxxx       /dev/urandom   swap

Vous remplacerez les “xxxx” par l'UUID de la partition qui reçoit l'espace d'échange swap. “cryptswap” est le nom du “mapping” qui sera fait pour la partition de swap, choisissez ce que vous voulez, ici la partition de swap sera disponible sur /dev/mapper/cryptswap.

Maintenant préparez votre fichier /etc/fstab :

#swap cryptée
/dev/mapper/cryptswap	none    swap     sw          0       0

Vous ajusterez l'adresse de la partition en fonction du nom choisit pour le mapping dans /etc/crypttab. Une alternative est d'utiliser l'UUID de la partition swap, attention à bien utiliser l'identifiant de la partition swap une fois le conteneur ouvert et nom celle de la partition physique qui supporte le conteneur.

UUID=xxxxx-xxxxxx-xxxxxx-xxxxx-xxxxx  none    swap     sw          0       0

Pour vérifier que tout fonctionne :

# invoke-rc.d cryptdisks restart

# swapon -s

Filename		 	Type	     Size	Used	Priority
/dev/mapper/cryptswap         partition	    1800296	 84	  -1

Tout va bien, la swap est activée.

Utilisation d'une clé standard luks, obligation de taper le mot de passe ou de fournir un fichier-clé à chaque démarrage, mise en veille sur disque possible

Dans ce cas vous utiliserez la même procédure que pour la partition /home, je résume rapidement les étapes ici (on considère que la partition cible est /dev/sda4) :

# dd if=/dev/urandom of=/dev/sda4

# cryptsetup -h sha256 luksFormat /dev/sda4

# cryptsetup luksOpen /dev/sda4 cryptswap

# mkswap /dev/mapper/cryptswap

# swapon /dev/mapper/cryptswap

Ensuite ajoutez les lignes nécessaires dans vos fichiers crypttab et fstab :

/etc/crypttab

#<target name>       <source device>                 <key file>   <options>

cryptswap      /dev/disk/by-uuid/xxxx-xxx-xxxx-xxxx     none    luks,swap

La valeur “none” dans le champs “<key file>” correspond à l'utilisation d'un mot de passe, si vous utilisez un fichier clé vous en indiquerez le chemin ici.

/etc/fstab

#swap cryptée
/dev/mapper/cryptswap	none    swap     sw          0       0

Utilisation d'une clé dérivée depuis une autre partition, hibernation possible, pas de mot de passe supplémentaire à taper

Cette solution est la plus souple, elle demande un peu plus de travail de mise en place. Le script nécessaire est /lib/cryptsetup/scripts/decrypt_derived, il est normalement installé en même temps que le paquets cryptsetup. Assurerez vous qu'il soit bien présent :

$ ls -l /lib/cryptsetup/scripts/
total 36

-rwxr-xr-x 1 root root  730 19 mai   20:55 decrypt_derived

-rwxr-xr-x 1 root root  576 19 mai   20:55 decrypt_gnupg
-rwxr-xr-x 1 root root 2683 19 mai   20:55 decrypt_keyctl
-rwxr-xr-x 1 root root 1724 19 mai   20:55 decrypt_openct
-rwxr-xr-x 1 root root 1415 19 mai   20:55 decrypt_opensc
-rwxr-xr-x 1 root root  349 19 mai   20:55 decrypt_ssl
-rwxr-xr-x 1 root root 9512 19 mai   20:55 passdev

Préparez la partition (non formatée) destinée à recevoir le conteneur LUKS et la swap (ici /dev/sda4).
Il ne reste plus qu'à modifier la ligne du fichier /etc/crypttab pour utiliser le script de clé de chiffrement dérivé, ici nous supposons que la partition système /dev/sda2 est elle-même chiffrée (“mappée” sur /dev/mapper/cryptroot), c'est elle qui va servir de “source” pour le déchiffrement dérivé de la swap :

cryptswap /dev/sda4 cryptroot cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap

Décomposons la ligne pour plus de clarté :

  • cryptswap est le nom que prendra le “mapping” sous /dev/mapper, c'est cette adresse qui devra figurer dans le fichier fstab.
  • /dev/sda4 est la partition cible, celle qui deviendra effectivement la partition swap chiffrée.
  • cryptroot est la partition source pour dériver la clé de chiffrement de cryptswap, ici on suppose qu'il s'agit de la partition système /dev/sda2 chiffrée et “mappée” sur /dev/mapper/cryptroot.
  • les options sont séparées par une virgule, elles peuvent spécifier la méthode de chiffrement (algorithme, taille de la clé, hash), voyez “cryptsetup –help” et “man cryptsetup” pour les options valident. Voyez “/usr/share/doc/cryptsetup/README.initramfs.gz” section 9 pour un exemple type. Les options keyscript=/lib/cryptsetup/scripts/decrypt_derived et swap sont nécessaires pour le chiffrement par clé dérivée de la partition “swap”.

Votre fichier /etc/fstab devrait contenir une ligne comme celle-ci :

/dev/mapper/cryptswap	none    swap     sw          0       0

Vous pouvez utiliser l'UUID de la partition à la place de son “mapping”, mais attention à bien utiliser l'UUID du conteneur chiffré et non celle de la partition. Un exemple concret :

ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236  1 juin  09:14 control
lrwxrwxrwx 1 root root       7  1 juin  09:14 cryptroot -> ../dm-0

lrwxrwxrwx 1 root root       7  1 juin  16:35 cryptswap -> ../dm-1

lrwxrwxrwx 1 root root       7  1 juin  09:15 _dev_md3 -> ../dm-2

Ici “cryptswap” est une partition swap chiffrée. On voit qu'elle possède un alias dans le répertoire de niveau supérieur, soit “/dev/dm-1”. Maintenant voyons l'UUID :

ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10  1 juin  09:15 02eee349-7406-46d3-b2f3-5dd86bad4250 -> ../../dm-2
lrwxrwxrwx 1 root root  9  1 juin  09:14 171f3f45-b101-4423-adc3-cc94a0dbc2b7 -> ../../md2
lrwxrwxrwx 1 root root 10  1 juin  09:14 1f5677df-7aac-44d0-955a-59bd5a35f05c -> ../../sde1
lrwxrwxrwx 1 root root 10  1 juin  09:14 45b120bd-c7a5-4d00-9c5b-a72c48a663fc -> ../../dm-0
lrwxrwxrwx 1 root root  9  1 juin  09:14 58fc4506-7de8-41c9-86bf-39de880d94a0 -> ../../md0

lrwxrwxrwx 1 root root 10  1 juin  16:35 613c44a1-3b4a-4149-9300-b31136dc6268 -> ../../dm-1

lrwxrwxrwx 1 root root  9  1 juin  09:14 6e23b1fc-1039-48ed-91aa-be7b50d037fb -> ../../md4
lrwxrwxrwx 1 root root  9  1 juin  09:14 a21700c9-4c5e-45a2-818f-2fc56ba332ad -> ../../md3

Dans le fstab c'est donc UUID=613c44a1-3b4a-4149-9300-b31136dc6268 (/dev/dm-1) qu'il faudra utiliser, et non l'UUID de la partition physique sur laquelle le conteneur chiffré repose (/dev/md2 dans cet exemple).

Vérifiez que tout fonctionne avec :

# invoke-rc.d cryptdisks restart

Stopping remaining crypto disks...cryptroot (busy)..._dev_md3 (busy)...done.
Starting remaining crypto disks...cryptroot (running)..._dev_md3 (running)...cryptswap (starting)...
cryptswap (started)...done.

# swapon -a
# swapon -s

Filename		 	Type	     Size	Used	Priority
/dev/mapper/cryptswap         partition	    1800296	 84	  -1

Tout va bien, c'est presque fini. Si vous voulez que tout se passe bien lors de la mise en veille ouvrez /etc/initramfs-tools/conf.d/resume et indiquez la partition swap, par exemple ici :

$ cat /etc/initramfs-tools/conf.d/resume

RESUME=/dev/mapper/cryptswap

Et mettez à jour votre initramfs :

# update-initramfs -u -k all

Chiffrer la partition système

Pour chiffrer la partition système vous devez avoir une partition /boot séparée (et non chiffrée), et utiliser un disque initial de démarrage (initrd ou initramfs).

La procédure implique que vous sauvegardiez tous les fichiers de la partition système, vous pouvez envisager de réduire la partition système et d'utiliser la place libérée pour mettre en place le conteneur LUKS, mais de toute façon avant de manipuler vos partitions il faut s'assurer d'avoir une sauvegarde à jour.

Si vous estimez que votre partition système ne contient rien de primordial, vous pouvez faire le choix de réinstaller en prenant bien garde de ne pas formater vos autres partitions (/home). L'installateur de Debian, ou le cd alternatif d'Ubuntu (et dérivées) permettent par exemple d'effectuer une installation chiffrée facilement.

Avant de faire la sauvegarde, vous devez installer au minimum cryptsetup sur votre système, sans ça il sera impossible de démarrer sur la partition Luks.
Ensuite démarrez sur un live-cd comme grml, System Rescue CD ou Parted Magic. Un live-cd d'Ubuntu ou dérivée fera également l'affaire à condition de disposer d'une connexion Internet pour installer cryptsetup. Choisissez un live-cd de même architecture que votre système (x86 ou x86-64), comme nous allons utiliser le “chroot” ça vous évitera des problèmes.

Création du conteneur LUKS et du système de fichiers

Vous devez détruire la partition système actuelle, éventuellement réécrire des données aléatoires pour augmenter la robustesse du chiffrement, et recréer une nouvelle partition sans système de fichiers.

Maintenant vous allez créer le conteneur LUKS qui va recevoir votre système :

# cryptsetup -h sha256 luksFormat /dev/sda2

Pendant le processus de création vous attribuerez un mot de passe à ce conteneur, c'est celui-ci qui vous sera demandé tôt dans le processus de démarrage de votre système pour déchiffrer la partition système.
Maintenant nous ouvrons le conteneur LUKS et nous créons un système de fichiers ext4 :

# cryptsetup luksOpen /dev/sda2 cryptroot

# mkfs.ext4 -L cryptroot /dev/mapper/cryptroot

L'option “-L” de “mkfs.ext4” permet d'attribuer un label au système de fichiers, ici “cryptroot”.

Restauration des fichiers système

Maintenant, toujours depuis notre live-cd, nous créons des points de montage sous /mnt, et montons la partition chiffrée “cryptroot” ainsi que la partition où est stockée la sauvegarde du système (ici backup-sys). Enfin nous copions la sauvegarde sur “cryptroot” :

# mkdir /mnt/cryptroot /mnt/backup-sys
# mount /dev/mapper/cryptroot /mnt/cryptroot
# mount LABEL=backup-sys /mnt/backup-sys
# rsync -aHAXP /mnt/backup-sys/ /mnt/cryptroot/

Ajuster en fonction de l'outil de sauvegarde utilisé (tar, rsync, …etc).

Mettre en place la partition /boot séparée

Si vous avez bien suivi, vous devez avoir une partition /boot séparée, dans notre exemple il s'agit de /dev/sda1 que l'on imagine prête et formatée. Nous créons un point de montage temporaire sous /mnt/newboot, et copions le contenu de /mnt/cryptroot/boot/ dans /mnt/newboot/ :

# mkdir /mnt/newboot
# mount /dev/sda1 /mnt/newboot
# rsync -aHAXP /mnt/cryptroot/boot/ /mnt/newboot/

Contrôlez que les contenus des deux répertoires sont bien identiques, puis supprimez tout le contenu de /mnt/cryptroot/boot/. Enfin démontez/remontez la nouvelle partition (ici /dev/sda1) à sa place définitive, soit /mnt/cryptroot/boot.

N'oubliez pas de mettre le “drapeau” (“flag”) “boot” sur votre partition /boot, certaines configurations refuseront de démarrer sans cette précaution.

Configuration du système

Modifier /etc/crypttab

La syntaxe du fichier crypttab est toujours la même, ici “/dev/sda2” est la partition qui supporte le conteneur LUKS, “cryptroot” sera le nom du “mapping” sous /dev/mapper. Comme les en-têtes des conteneurs LUKS contiennent toutes les informations nécessaires il n'y a pas besoin d'options supplémentaires :

# <target name>         <source device>         <key file>      <options>

cryptroot                 /dev/sda2              none              luks
Modifier /etc/fstab

Il est fortement recommandé d'utiliser l'UUID de la partition système plutôt que le nom du mapping. Ne vous trompez pas d'UUID, c'est celui du système de fichiers porté par le conteneur LUKS, pas celui de la partition physique qui supporte le conteneur. C'est donc l'UUID de /dev/mapper/cryptroot qu'il vous faut et non celle de /dev/sda2 :

# blkid /dev/mapper/cryptroot
/dev/mapper/cryptroot: LABEL="cryptroot" UUID="45b120bd-c7a5-4d00-9c5b-a72c48a663fc" TYPE="ext4"
# /etc/fstab: static file system information.
#
# <file system>                        <mount point>   <type>          <options>            <dump>  <pass>

UUID=45b120bd-c7a5-4d00-9c5b-a72c48a663fc    /          ext4     errors=remount-ro,relatime   0       1

Vous avez maintenant une partition /boot séparée (ici /dev/sda1), vous devez l'indiquer dans le fichier etc/fstab :

/dev/sda1  /boot   ext4   errors=remount-ro,relatime  0       1

Il est préférable d'utiliser l'UUID de la partition plutôt que son adresse relative /dev/sda1, cette dernière pouvant changer.

Mettre à jour l'initramfs

Le disque de démarrage initial (“initrd” ou “initramfs”) doit-être configuré pour prendre en charge le conteneur LUKS qui supporte la partition système. Heureusement pour nous l'“automagie” fonctionne à merveille et les modules nécessaires seront ajoutés automatiquement.

Les paquets “busybox” et “initramfs-tools” doivent être installés, vérifiez leur état :

$ aptitude search '(busybox|initramfs-tools)'

Si vous n'utilisez pas aptitude (vous manquez quelque chose) faites :

$ dpkg -l | egrep '(busybox|initramfs-tools)'

Vérifiez la configuration de initramfs-tools, si vous avez “MODULES=most” et “BUSYBOX=y” (yes) c'est bon :

egrep '(MODULES|BUSYBOX)' /etc/initramfs-tools/initramfs.conf
# MODULES: [ most | netboot | dep | list ]
MODULES=most
# BUSYBOX: [ y | n ]
BUSYBOX=y

Si pour une raison quelconque le démarrage se passe mal et l'initramfs est incapable de déchiffrer la partition LUKS, vous pouvez forcer les modules et scripts qui seront embarqués dans l'initramfs. Commencez par copier le scripts “cryptroot” fourni par initramfs-tools :

# cp /usr/share/initramfs-tools/hooks/cryptroot /etc/initramfs-tools/hooks/

Ensuite vous pouvez ajouter les modules nécessaires et adaptés à votre cas (type d'encryption, …etc) dans /etc/initramfs-tools/modules. Un exemple pour un système avec des conteneurs chiffrés avec les options par défaut de cryptsetup (aes) et un hashage en “sha:256” :

# List of modules that you want to include in your initramfs.
# Syntax:  module_name [args ...]
# You must run update-initramfs(8) to effect this change.

aes_generic
sha256_generic

Pour que l'initramfs prenne en compte votre nouvelle configuration vous devez le mettre à jour, cela se fait à l'intérieur d'un “chroot”. Voyez le paragraphe suivant “Le chargeur d'amorçage (Grub2)” pour la marche à suivre.

Mettre à jour le chargeur d'amorçage (Grub2) avec un chroot

L'adresse et l'UUID de la partition système ayant changés, et d'autant plus si vous avez ajouté une partition “/boot” séparée qui n'existait pas auparavant, vous devez mettre à jour la configuration de grub2. Le plus simple une fois le fichier /etc/fstab renseigné est d'utiliser un “chroot” sur le nouveau système, et d'exécuter grub-mkconfig.

“chrooter” signifie obtenir un shell sur le système cible, à partir du live-cd, pour exécuter des commandes comme si on se trouvait sur le système cible.
Notre nouveau système est monté sur /mnt/cryptroot, il reste à monter quelques arborescences de fichiers systèmes et /boot (facultatif si vous l'avez déjà fait à une étape antérieure) avant d'effectuer le “chroot” :

# mount -o bind /dev /mnt/cryptroot/dev
# mount -o bind /sys /mnt/cryptroot/sys
# mount -o bind /proc /mnt/cryptroot/proc
# mount /dev/sda1 /mnt/cryptroot/boot

Ensuite placez-vous à la racine de votre nouveau système, et effectuez le chroot :

$ cd /mnt/cryptroot
# chroot . /bin/bash

À partir de maintenant toutes les commandes seront exécutées sur le système cible “chrooté”, c'est à dire votre nouveau système sur partition chiffrée.

Mettez à jour l'initramfs et grub :

# update-initramfs -u -k all

# grub-mkconfig -o /boot/grub/grub.cfg

# grub-install "(hd0)"
Au lieu d'un mot de passe vous pouvez utiliser un fichier-clé (“key-file”) sur un support externe (clé usb) pour déchiffrez la partition système. Lisez /usr/share/doc/cryptsetup/README.initramfs.gz (Chapitre 10 “The “passdev” keyscript”) avant toute chose. LUKS supporte plusieurs clés pour un même conteneur, vous pouvez donc combiner un mot de passe et un fichier-clé, voyez dans le manuel de “cryptsetup” l'option “luksAddKey”.

Liens

expert/systeme_chiffre_luks_pam_cryptsetup.txt · Dernière modification: 2014/05/09 18:56 (modification externe)