Dévérouiller automatiquement partition chiffrée

Anonyme-8 · 25-05-2014 16:07:16

Bonjour,

J'ai plusieurs partitions chiffrées, la partition Root, la partition Home et une autre partition. Du coup j'ai besoin d'accéder aux partitions Home et Documents et il me faudrait taper 3 mots de passe pour déverrouiller les partitions puis le mot de passe pour le login. Assez pénible, du coup j'avais trouvé ça:

Objectifs: dévérouiller automatiquement une partition chiffrée.

Préalable: La partition système doit être chiffrée et la partition qui doit être déverrouillée doit être crée et chiffrée et non montée.
S'il s'agit de votre /home , il est conseillé d'utiliser un Live CD après effectuée une sauvegarde préalable.

Avertissement a écrit :

Ce tuto ne permet pas d'améliorer le niveau de sécurité générale mais d'en simplifier l'utilisation. Dans le cadre d'une installation sécurisée, il fortement déconseillé de ne pas suivre ce tuto, il comporte plusieurs failles de sécurité pouvant compromettre votre système.

création d'une clé de déchiffrement
Pour commencer, il est nécessaire de générer fichier qui nous servira de clé de déchiffrement. Elle sera utilisé lors du démarrage de votre système.
dd if=/dev/random of=/root/keyfile bs=1024 count=4

en cas d'erreur, executer
dd if=/dev/urandom of=/root/keyfile bs=1024 count=4

La fichier sera nommée keyfile et sera stockée dans le répertoire /root. Il doit impérativement avoir comme propriétaire "root".
/!\ le fichier ne doit surtout pas être stocké sur /boot ou une partition non chiffrée
modification des droits du fichier keyfile
chmod 0400 /root/keyfile

on modifie les droits d'accès pour que le fichier soit en lecture seule pour le compte root. Le fichier n'est alors utilisable que pour le compte root.
Il est vivement conseillé d'effectuer une sauvegarde de ce fichier dans un endroit sûr.
ajouter le fichier comme clé
pour le moment, on a juste générée un fichier. Maintenant il est nécessaire de l'ajouter comme clé de déchiffrement à notre partition
cryptsetup luksAddKey /dev/disk/by-uuid/c4295a74-5c31-475b-aa57-b9fa4c2de36e /root/keyfile

/!\ l'uuid doit correspondre à la partition chiffrée. Pour identifier la partition, on peut utiliser blkid
modifier le fichier crypttab
Il est nécessaire de configurer le fichier crypttab qui fera le lien avec fstab qui permet de monter à chaque démarrage les partitions.
Il faut référencer la partition /dev/sdX en modifiant le fichier /etc/crypttab

sdX_crypt UUID=2a76a71e-dbe5-4419-9965-e3cd3 /root/keyfile luks

sdX_crypt correspond au label qui sera repris dans fstab, autant utilisé un libellé explicite.
UUID=2a76a71e-dbe5-4419-9965-e3cd3 correspond à l'UUID de la partition chiffrée /dev/sdX. on le retrouve avec blkid
/root/keyfile correspond à l'emplacement de la clé de déchiffrement
luks correspond aux options du fichier crypttab
modifier le fichier fstab
pour finaliser l'installation, il est nécessaire de monter tout ceci au démarrage. Pour ça, il faut éditer le fichier /etc/fstab

/dev/mapper/sdX_crypt /media/sdX ext4 defaults 0 2

/!\ à modifier en fonction de votre système
/dev/mapper/sdX_crypt reprend le nom du mapper mis dans /etc/crypttab. Si vous avez changer sdX_crypt par autre chose, il faut utiliser le nom présent dans /etc/crypttab
/media/sdX correspond au point de montage. Le dossier /media/sdX doit exister, sinon il faut le créer.
ext4 correspond au système de fichier utilisé à l'intérieur de la partition chiffrée et doit être modifié en conséquence. Les principaux systèmes de fichier sont: ext2, ext3, ext4

defaults correspond aux options de montage
0 2 correspond aux dump et fsck
tester le montage de la partition
Pour vérifier le bon fonctionnement, redémarrer le système si vous utilisé un Live CD ou taper la commande
mount -a

La partition devrait être montée.

Afin de garantir un niveau de sécurité optimal, il est nécessaire actualiser régulièrement votre clé. Pour ce faire il est nécessaire de révoquer la clé pour en ajouter une nouvelle.
/!\ lors du changement de clé et si une erreur survient, la partition pourrait être définitivement inaccessible. Pensez à faire une sauvegarde de la partition.

cryptsetup luksChangeKey /dev/sdX /root/keyfile2

source:
http://www.howtoforge.com/automatically … -a-keyfile

On peut discuter du caractère border line concernant la sécurité mais c'est un compromis.

Dernière modification par Anonyme-8 (03-06-2014 19:52:46)

captnfab · 26-05-2014 10:14:57

Salut,
Merci pour ce tuto.
J'ai juste quelques commentaires rapides

D'abord, si tu écris dans le fichier via « echo 'mdp' > fichier », alors la commande reste dans l'historique, et donc ton mdp aussi.
Certes, à ce stade c'est l'historique root, mais tout de même.
Tu peux plutôt utiliser

cat > fichier

mdp

Ctrl-d

Mais bon, en réalité, il ne faut pas faire cette étape de génération de mot de passe. En effet, le «mot de passe» ici c'est /dev/urandom qui le génère via la commande dd. Il n'est pas affichable, pas tapable via un clavier, mais c'est pas grave.

Ensuite, le fichier de destination est /root/clé
Bon, si /root est lui-même sur une partition chiffrée, alors c'est raisonnable. En revanche, sinon, non. En effet, qqn peut emprunter ton disque dur, le monter depuis un autre ordi, et alors accéder à tous les fichiers non chiffrés, quels que soient leurs droits.

Donc, l'idée est que ta clé ne doit jamais être stockée en clair dans une mémoire persistante qu'on pourrait de piquer.
Tu peux par exemple la stocker dans /tmp/root si /tmp est un tmpfs monté en ram, mais bien évidemment elle sera alors effacée au prochain reboot.
Tu peux également la stocker sur une clé USB et t'arranger pour que le boot monte la clé usb et aille chercher la clé dessus.
Attention cependant, si ta clé meurt, il te faudra te souvenir de ta passphrase de chiffrement

Pour ma part, voici la configuration que j'ai sur mon EEEPC

Un « /boot » en clair, pour le grub et pour amorcer le noyal.
Un « / » chiffré, déchiffrable via une passphrase mémorisable
Un « /home » (et d'autres partoches créées pour faire plus propre) qui vont chercher directement leur clés dans « / » une fois celle-ci déchiffrée.
La swap chiffrée via la même clé que « / » lors de l'hibernation.

À cette configuration on peut ajouter le déchiffrement via clé USB, mais je ne l'ai pas fait (je perds mes clés USB quotidiennement, donc ça n'est pas très raisonnable)

De plus, cette configuration est loin d'être parfaite, parce que la partie s'occupant du déchiffrement est en clair dans /boot. Une personne mal intentionnée pourrait la modifier de manière à stocker la passphrase en clair quelque part, puis venir la récupérer ensuite.
Bon, ça reste (très) peu probable, mais voilà, c'est juste pour dire que ce schéma ne me semble pas encore au point.

Enfin bon, avec les UEFI, ça va être tout différent, puisque l'UEFI gèrera les entrées clavier et donc il n'y aura vraiment plus aucun moyen de taper une passphrase/un mdp sans être sûr qu'un blob propriétaire y aura mis ses yeux dessus. Oh, joie

Anonyme-8 · 26-05-2014 11:06:02

je n'aime pas trop l'idée d'utilisée /dev/urandom parce que la sortie n'est pour moi pas interprétable. C'est certainement mieux en terme de sécurité mais en cas de pb, c'est plus facile d'avoir un passphrase avec chiffre , lettre et symbole.

Je suis complètement d'accord avec toi concernant l'emplacement de keyfile. Il doit être sur un emplacement chiffré, logiquement c'est sur / ou un sous dossier parce que les autres partitions ne doivent pas être montées à ce stade.
L'autre solution, comme tu la propose est d'utilisé un support externe de type clé USB. Mais dans ce cas le fichier est en clair, et devra faire l'objet d'une attention toute particulière. De mémoire, je crois que c'est pas facile de récupérer le fichier sur une clé USB.

Après, si quelqu'un a accès physiquement à ton ordinateur, il est très difficile de se protéger.

Je pense aussi qu'il serait nécessaire d'ajouter une partie pour révoquer une clé.

Je vais prendre en compte tes remarques et compléter en ajoutant quelques avertissements et préconisation. J'essaierai de regarder comment ça se passe avec une clé USB.

Dernière modification par Anonyme-8 (26-05-2014 11:32:02)

captnfab · 26-05-2014 12:33:03

Bah, le mot de passe du keyfile, il n'est pas franchement interprétable non plus.
Une clé de 4Ko générée par /dev/urandom (ou encore mieux, /dev/random) a une complexité de 32768bits.
Pour avoir un truc similaire avec KeepassX, il te faut un pass de 4965 caractères

donc de 4965 octets. Difficilement interprétable…

Je plussoie pour les avertissement et pour la révocation

Anonyme-8 · 26-05-2014 12:59:02

Pas de pb avec KeepassX, 5000 caractères, je viens de tester.
Je vais laisser la partie création de la clé avec /dev/urandom.

J'esaie de compléter ça aujourd'hui.

captnfab · 26-05-2014 13:17:43

D'ac, c'est cool !

Anonyme-8 · 26-05-2014 18:58:45

J'ai effecuté quelques modifications. Plusieurs remarques:
J'ai testé /dev/random mais il ne m'a pas généré la clé correctement. A ce que j'ai cru comprendre, /dev/urandom génère un clé de moins bonne qualité (moins aléatoire).

j'ai le message suivant

dd if=/dev/random of=/tmp/keyfile3 bs=1024 count=4

dd: warning: partial read (81 bytes); suggest iflag=fullblock

0+4 enregistrements lus

0+4 enregistrements écrits

99 octets (99 B) copiés, 8,4863 s, 0,0 kB/s

j'ai créé le fichier keyfile3 avec /dev/random et keyfile4 avec /dev/urandom

-rw-r--r-- 1 Anonyme-8 Anonyme-8     99 mai   26 19:53 keyfile3

-rw-r--r-- 1 Anonyme-8 Anonyme-8   4096 mai   26 19:54 keyfile4

dans la partie 'Ajouter le fichier comme clé", je pense qu'il serait préférable d'utiliser l'UUID plutôt qu'un simple /dev/sdX. Une erreur de frapper est vite arrivée. Je n'ai pas eu de regarder si c'était possible ni comment.

le changement de clé n'a jamais été testé

man a écrit :

luksChangeKey <device> [<new key file>]

Changes an existing passphrase. The passphrase to be changed must be supplied interactively or via --key-file. The new
passphrase can be supplied interactively or in a file given as positional argument.

If a key-slot is specified (via --key-slot), the passphrase for that key-slot must be given and the new passphrase will
overwrite the specified key-slot. If no key-slot is specified and there is still a free key-slot, then the new
passphrase will be put into a free key-slot before the key-slot containing the old passphrase is purged. If there is no
free key-slot, then the key-slot with the old passphrase is overwritten directly.

WARNING: If a key-slot is overwritten, a media failure during this operation can cause the overwrite to fail after the
old passphrase has been wiped and make the LUKS container inaccessible.

<options> can be [--key-file, --keyfile-offset, --keyfile-size, --new-keyfile-offset, --new-keyfile-size, --key-slot,
--force-password].

Reste à voir comment on déchiffre la partition à partir d'une clé USB.

captnfab · 26-05-2014 19:20:42

Pour le /dev/random, c'est le soucis, l'aléatoire est de meilleure qualité, mais il est produit lentement. Là, tu n'avais que 81octets d'aléatoire

Pour le « Ajouter la clé via l'UUID », je te propose la méthode passe-partout suivante :

cryptsetup luksChangeKey /dev/disk/by-uuid/c4295a74-5c31-475b-aa57-b9fa4c2de36e /root/keyfile2

Anonyme-8 · 26-05-2014 20:11:57

j'ai modifier pour l'uuid. je fais confiance
J'ai ajouté la commande pour /dev/urandom en cas d'erreur.

manu0123456 · 30-05-2014 09:04:38

je suis sous wheezy, avec 4 partitions cryptées + swap
j'ai complètement réinstallé récemment.
depuis la réinstallation, j'arrive à manipuler les partitions en ligne de commande ainsi qu'avec palimpsest (gnome-disk-utility)
quand je veux automatiser avec l'utilisation d'u fichier contenant le mot de passe, j'obtiens systématiquement le message d'erreur "Aucune clé n'est disponible avec cette phrase secrète."
j'ai ce message d'erreur aussi bien au démarrage qu'avec "cryptsetup luksOpen" ou "cryptsetup luksAddKey"
Pourriez vous m'aider à résoudre ce problème ?
merci

smolski · 30-05-2014 09:10:01

Salut manu0123456 !

Ouvre une nouvelle discussion pour ta question.
Voir le tuto magique et chocolaté là :
Voir le tuto : On ne bernacle pas le post d'autrui. Plop !

manu0123456 · 09-06-2014 12:32:40

un article intéressant sur le sujet : http://2010.rmll.info/IMG/pdf/06_denis_article-2.pdf

Pour les disques avec mes données personnelles (/home, et /sauvegarde avec sauvegarde journalière des données), j'ai 2 key dans mon fichier : le fichier clé généré aléatoirement et qui me sert au montage automatique, ainsi qu'un mot de passe "en clair" pour pouvoir ouvrir en cas de problème sur le système.
Pour les disques sytème (/ n'est pas chiffré), je n'ai que la clé aléatoire.

Le premier élément de sécurité, c'est de ne pas avoir d'autoLogin.

Avec cryptage + pas d'autologin, le seul moyen d'accéder aux données est de démarrer avec une autre distrib et de chercher les clés.

Prochaine étape : mettre les fichiers clé sur une clé usb déportée (déportée de telle sorte que quelqu'un qui vole le PC n'emmène pas la clé USB) -> je n'ai pas erncore vraiment trouvé comment faire.

Anonyme-8 · 09-06-2014 13:52:06

La solution n'est pas sûr mais le minimum, c'est avoir /boot qui n'est pas chiffré, / chiffré + autres partitions chiffrées.
On ne peut rien faire si on modifie le code présent sur /boot. On pourra exécuter un code arbitraire. Je sais pas si RKHunter ou Chkrootkit permet de détecter une alération à posteriori
Un keylogger ou autres techniques alternatives permettront de trouver le mot de passe de déchiffrement sans trop de pb.

Concernant toute la partie matérielle, on ne sait jamais ce qui se passe.

En tout cas, ne pas chiffré / me parait bancale puisqu'elle contient les clés de déchiffrement. Dans ton cas, l'autologin est plus que déconseillé sinon idiot.

Si tu trouves une solution pour déchiffrer à partie d'une clé USB, je suis intéressé

manu0123456 · 17-06-2014 18:29:04

A priori, la solution pour avoir les codes sur une clé USB est de chiffre / et d'avoir /boot sur une clé reliée par un cable au PC et bien caché.
Comme cela, si quelqu'un par tavec la PC, il y a de très forte chance que la clé ne parte pas avec.

vv222 · 18-06-2014 01:59:08

manu0123456 a écrit :

A priori, la solution pour avoir les codes sur une clé USB est de chiffre / et d'avoir /boot sur une clé reliée par un cable au PC et bien caché.
Comme cela, si quelqu'un par tavec la PC, il y a de très forte chance que la clé ne parte pas avec.

Tu laisses la clé de ta voiture sur le contact (mais « bien cachée ») quand tu n'es pas dedans ?
Ou tu préfères la garder dans ta poche ?

captnfab · 18-06-2014 10:53:01

Sinon, tu peux souder ta clé sur ton bureau en fonte dont les pieds sont fondus dans l'armature en béton armé de ton sol. Sûr que le voleur sera désorienté là, il sera obligé de voler tout le bâtiment !
Mais bon, s'il vient bien préparé… tout est possible

Qui pour tourner un nanar dans lequel le héros fait crasher un satellite enrichi au plutonium pour envoyer le bâtiment-fonte-pc-cléusb dans l'espace et dévier la méchante météorite pleine d'aliens du fbi qui venaient piller les secrets planqués dans l'ordi… oh… ! wait…

paskal · 18-06-2014 11:21:07

Sinon, tu as ça : http://www.commentcamarche.net/news/586 … os-donnees
mais prends garde à planquer tes doigts.

Anonyme-8 · 18-06-2014 11:50:18

Utiliser un sherpa pour déplacer son pc où que l'on soit est selon moi la meilleure des solutions. Je pensais sceller le PC avec du béton mais il faut installer un PC dans un bain d'huile ici

Je pense que si le /boot est installé sur une clé usb, ça peut être un bon compromis. Il faut voir quelles sont les conséquences.

captnfab · 18-06-2014 12:02:44

Mhh… Effectivement, c'est pas idiot le coup du /boot sur la clé usb

A priori, c'est facile à remplacer en cas de dégât matériel. Et si l'on perd la clé, on peut toujours changé la passphrase/clé sur l'ordi maître pour la rendre inutile.
Je vote pour

Anonyme-8 · 18-06-2014 12:51:56

Je sais pas ce qui se passe si la clé est débranché accidentellement ou volontairement.

Après, j'ai pas trop d'idée comment déplacer le /boot.

Anonyme-8 · 18-06-2014 18:47:19

je suis tombé par hasard sur cette page expliquant comment utilisé une clé usb contenant keyfile
http://binblog.info/2008/12/04/using-a- … assphrase/

vv222 · 20-06-2014 16:18:57

Anonyme-8 a écrit :

Je sais pas ce qui se passe si la clé est débranché accidentellement ou volontairement.

Aucun problème, /boot n'a plus d'utilité une fois le système lancé.
J'ai eu l'exemple d'un système démontant automatiquement /boot une fois que celle-ci a rempli son office.

Anonyme-8 · 20-06-2014 16:46:31

vv222 a écrit :

Anonyme-8 a écrit :
Je sais pas ce qui se passe si la clé est débranché accidentellement ou volontairement.

Aucun problème, /boot n'a plus d'utilité une fois le système lancé.
J'ai eu l'exemple d'un système démontant automatiquement /boot une fois que celle-ci a rempli son office.

effectivement, j'ai testé et ça semble pas poser trop de soucis.
Si on doit faire des mises à jour, qu'est qui se passe ?

Si c'est possible, on peut envisager d'afficher un message pour retirer la clé au début de la session. Cela permettrait de ne pas oublier la clé et d'assurer un certains niveau de sécurité.

Debian-facile

#1 25-05-2014 16:07:16

Dévérouiller automatiquement partition chiffrée

#2 26-05-2014 10:14:57

Re : Dévérouiller automatiquement partition chiffrée

#3 26-05-2014 11:06:02

Re : Dévérouiller automatiquement partition chiffrée

#4 26-05-2014 12:33:03

Re : Dévérouiller automatiquement partition chiffrée

#5 26-05-2014 12:59:02

Re : Dévérouiller automatiquement partition chiffrée

#6 26-05-2014 13:17:43

Re : Dévérouiller automatiquement partition chiffrée

#7 26-05-2014 18:58:45

Re : Dévérouiller automatiquement partition chiffrée

#8 26-05-2014 19:20:42

Re : Dévérouiller automatiquement partition chiffrée

#9 26-05-2014 20:11:57

Re : Dévérouiller automatiquement partition chiffrée

#10 30-05-2014 09:04:38

Re : Dévérouiller automatiquement partition chiffrée

#11 30-05-2014 09:10:01

Re : Dévérouiller automatiquement partition chiffrée

#12 09-06-2014 12:32:40

Re : Dévérouiller automatiquement partition chiffrée

#13 09-06-2014 13:52:06

Re : Dévérouiller automatiquement partition chiffrée

#14 17-06-2014 18:29:04

Re : Dévérouiller automatiquement partition chiffrée

#15 18-06-2014 01:59:08

Re : Dévérouiller automatiquement partition chiffrée

#16 18-06-2014 10:53:01

Re : Dévérouiller automatiquement partition chiffrée

#17 18-06-2014 11:21:07

Re : Dévérouiller automatiquement partition chiffrée

#18 18-06-2014 11:50:18

Re : Dévérouiller automatiquement partition chiffrée

#19 18-06-2014 12:02:44

Re : Dévérouiller automatiquement partition chiffrée

#20 18-06-2014 12:51:56

Re : Dévérouiller automatiquement partition chiffrée

#21 18-06-2014 18:47:19

Re : Dévérouiller automatiquement partition chiffrée

#22 20-06-2014 16:18:57

Re : Dévérouiller automatiquement partition chiffrée

#23 20-06-2014 16:46:31

Re : Dévérouiller automatiquement partition chiffrée

Pied de page des forums