La scène se passe prés du centre boursier de la capitale où l'ami d'un ami
prenait un café dans un de ces endroits modernes qui vous offre le WIFI pour faire passer
le goût de la consommation. A côté de lui, un monsieur sérieux avec
costard, cravate et bonnes manières, pianotait fébrilement sur son portable
jusqu'à ce que la nature lui rappelle son existence. Il se tourne alors vers l'ami de
l'ami en lui demandant s'il aurait la gentillesse de garder son bébé le temps d'une
courte pause. L'ami de l'ami a une allure rassurante et lorsqu'il accepte, le monsieur s'en va
l'esprit tranquille. Il revient une dizaines de minutes plus tard, visiblement content de
retrouver son matériel à sa place.
Une histoire tellement banale, et c'est bien là le problème. Dans la tête de
ce monsieur si moderne, tourne encore une logique qui date de bien avant l'âge de pierre.
Il a beau manipuler des symboles à longueur de journée, sa seule inquiétude
est de se faire dérober sa machine. Il ne lui est même pas venu à
l'idée une seconde que cet amas de puces n'avait aucune valeur en comparaison des
données qu'il contenait. Il n'avait d'ailleurs même pas verrouillé sa
session. L'ami de l'ami aurait put en un rien de temps brancher sa clef USB, recopier les
documents récents, le profile firefox, etc. Le monsieur aurait eu le même sourire en
revenant car sa machine, elle, était encore là...
Que crypter ?
Dans une première approche, la "sécurité" consiste simplement à
déterminer le niveau de risque associé à une menace. Dans le cas qui nous
intéresse, la menace s'appelle "rupture de la confidentialité sur une ressource" et
le niveau de risque associé sera proportionné à l'éventuel
intérêt qu'un tiers peut porter à cette ressource. Et
généralement, si un tiers est intéressé, c'est que la rupture vous
sera sûrement dommageable 
L'idée n'est donc pas de tomber dans la totale paranoïa mais de cerner avec soin ce
qui doit être protégé et ce qui n'a aucun intérêt à
l'être. Dans mon cas, ce que je protège avant tout ce sont mes clients et les
données qu'ils me confient. Une approche qui n'a rien d'altruiste dans la mesure où
généralement j'ai du signer un contrat de confidentialité et qu'en cas de
problème, ce serait entièrement pour ma pomme. Après, de manière plus
générale, je dirais que le chiffrage de la zone de stockage des courriels, carnet
d'adresses, des logs de messagerie instantanée et du profile FireFox, est une bonne
pratique.
Après, que quelqu'un qui manipule des données hautement sensibles puisse opter pour
la solution radicale du chiffrement total, swap compris, est parfaitement compréhensible.
Tout est une question d'évaluation de votre niveau de risque qui débouchera
généralement sur les choix suivant :
- Le cryptage total de tous les systèmes de fichiers, swap compris et
ce dés le démarrage du système.
- Le chiffrage d'un partition.
- Le chiffrage d'une clef USB.
- Le chiffrage d'un dossier "coffre-fort".
Pour répondre à ses différents besoins il y a deux options techniques qui
ont chacune leurs avantages et leurs inconvénients : LUKS et EncFS.
Chiffrement d'un conteneur Le principe
Il s'agit ici d'utiliser un conteneur qui peut être une partition (ex. /dev/hda1) ou un
fichier (ex. /mon_conteneur). Ce conteneur ne sera pas utilisé directement mais à
travers une fausse périphérique qui sera montée comme la partition ou le
fichier d'origine sur un dossier de l'arbrescence. Ceci fait, l'outil s'occupe de chiffrer tout
ce qui est écrit dans le dossier vers le conteneur, et déchiffrer à partir
du conteneur tout ce qui est lu du dossier.
L'avantage de cette approche est qu'elle rend possible un chiffrement total du système et
ce avec un coût supplémentaire relativement faible. Les conteneurs agissant comme
une partition classique peuvent être formatés avec le système de fichier de
votre choix. L'inconvénient est que le conteneur est "rigide", fixé dans sa taille
à la création. Cela ne pose pas de problèmes lorsque l'on chiffre une
partition physique car le conteneur est alors la partition elle-même. En revanche c'est
plus problématique lorsque l'on cherche seulement à disposer d'un dossier
protégé en utilisant un simple fichier comme conteneur. En effet, dans ce cas de
figure, que le dossier soit plein ou vide, le fichier-conteneur sera lui exactement de la
même taille, occupant ainsi un espace sans doute inutile.
Autre inconvénient, la sécurité des données. En effet, sans juger de
la qualité des outils, le seul fait de rajouter une couche logicielle entre le conteneur
et le système de fichier implique qu'en cas de corruption grave des données du
conteneur, le système de fichier puisse devenir définitivement illisible.
Ces deux inconvénient rendent à mon sens peu pertinent l'usage de
conteneurs-fichiers. Ainsi, dans le cas où vous chercheriez à simplement
protéger un seul dossier, il me semble plus rentable d'utiliser un système comme
encfs comme expliqué au chapitre suivant.
LUKS, truecrypt, realcrypt et cryptoloop
L'outil utilisé ici est LUKS, mais ce n'est pas le seul qui existe. LUKS est le
remplaçant à peu prés officiel de l'ancien cryptoloop. Ce dernier semble
poser des problèmes de sécurité que je ne détaillerais pas ici car je
ne les connais pas 
. Toujours est-il qu'Andrew Morton
lui-même appel au retrait de cryptoloop, je lui fait totale confiance
A noter qu'l existe aussi truecrypt (ou
realcrypt pour la version forkée par Mandriva pour des problèmes de licence).
L'argument de la portabilité a longtemps joué en faveur de cet outil car disponible
sur Linux, MacOS et Windows. Cependant des portages de LUKS sous windows fonctionnent aujourd'hui
avec FreeOTFE. Reste donc la plate-forme
d'Apple où LUKS n'a, à ma connaissance, pas encore été porté.
Ceci mis à part, et au delà de tout débat de trolls, le seul point
différenciant que j'ai constaté est la capacité de truecrypt à rendre
difficilement prouvable
l'existence du volume chiffré. Maintenant je laisse chacun juge de l'usage possible de
cette caractéristique...
Pour revenir à LUKS (Linux Unified Key Setup), il s'agit est en réalité plus
d'une infrastructure permettant diverses implémentation du cryptage. En l'occurrence, le
chiffrement à proprement parler est prise en charge par dm-crypt.
Chiffrement d'une partition avec LUKS
Pour voir comme LUKS fonctionne, prenons l'exemple du chiffrement d'une partition /dev/hda1
ressemblerait à cela :
- # Remplissage de la partition avec des nombre aléatoires pour rendre encore plus
- # délicate le cassage du volume.
- dd if=/dev/urandom of=/dev/hda1
- Â
- # Initialisation de la partition en utilisant l'algorithme aes
- # et une clef de 256 bits. C'est ici que le mot de passe est demandé
- cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase
luksFormat /dev/hda1
- Â
- # création du "faux" device associé à la "vraie" partition.
- # Ainsi, écrire sur le faux device, encryptera sur le vrai..
- cryptsetup luksOpen /dev/hda1 ma_clef_crypte
- Â
- # formatage de notre loop device, ici en EXT2
- mkfs -t ext2 /dev/mapper/ma_clef_crypte
- Â
- # montage du volume crypté
- mkdir /media/ma_clef_crypte
- mount -t ext2 -o rw /dev/mapper/ma_clef_crypteloop  /media/ma_clef_crypte
- Â
- # écriture sur la partition cryptée
- echo coucou > /media/ma_clef_crypte/un_fichier_caché
- Â
- # démontage de la partition
- umount /media/ma_clef_crypte
- Â
- # suppression du mapping LUKS
- cryptsetup luksClose ma_clef_crypte
Comme vous le voyez, tout ceci est très proche de ce que nous pouvions faire avec
cryptoloop. La grosse différence étant le remplacement du système loop par
un mapping de "faux" device.
Maintenant pour monter tout cela au démarrage il faut commencer par ajouter une
entrée dans /etc/crypttab ma_clef_crypte /dev/sdc1 none luks
Cela va donc créer notre "faux" device au boot, reste plus qu'à le monter en
ajoutant dans /etc/fstab /dev/mapper/ma_clef_crypte /media/ma_clef_crypte ext3 defaults 1 2
Cas d'une clef USB
Le chiffrement d'une partition pour une clef USB se fait aussi simplement que pour n'importe
quelle partition de disque dur mais pour ce qui est du montage, l'utilisation de fstab n'est pas
des plus pratique, obligeant généralement un montage "à la main".
Fort heureusement, les bureaux modernes (en tout cas Gnome 2.24) gèrent enfin cela
automatiquement en s'appuyant sur couple udev (détection des périphériques
ajoutées) et dbus pour transmettre cette information aux bureaux KDE ou Gnome. Le volume
sera donc détecté à l'insertion de la clef et un mot de passe de
déverrouillage sera demandé dans la session graphique de l'utilisateur courant. Si
tout se passe bien de ce côté là, une fenêtre Nautilus (sous Gnome)
s'affiche avec le contenu de clef qui a été montée automatiquement.
j'imagine que la même chose existe pour KDE ou Xfce.
Chiffrement d'un conteneur-fichier avec LUKS
Utiliser LUKS pour chiffrer une partition est finalement beaucoup plus simple que tout le bazar
des loop devices que l'on avait à gérer avec cryptoloop. Maintenant l'utilisation
des loop device reste d'actualité lorsqu'il s'agit de créer un dossier
chiffré par l'intermédiaire d'un fichier conteneur. Je ne suis pas un grand fan de
cette méthode mais chacun est seul maître à bord .
La procédure est strictement la même que pour une partition à la
différence que nous allons plutôt envoyer nos données aléatoires sur
un fichier, par exemple mon_conteneur, associer ce fichier à un loop device par un losetup
/dev/loop0 mon_conteneur (pour connaître les devices libres, faire un losetup -f) et
ensuite utiliser /dev/loop0 de la même manière que notre précédent
/dev/sdc1.
La libération du loop device, lorsque le conteneur est démonté par losetup
-d /dev/loop1.
Chiffrement d'un dossier simple Principe
Le chiffrement de conteneur est indispensable pour protéger une partition dans sa
globalité, spécialement si l'on souhaite mettre un système d'exploitation
complet dans cet espace, swap compris. Maintenant, comme nous l'avons vu en introduction du
précédent chapitre, lorsqu'il s'agit de chiffrer un simple dossier cette approche
se révèle assez peu souple concernant l'espace de stockage occupé et les
risques de corruptions.
Une autre approche consiste se placer au dessus du système de fichier en
chiffrant/déchiffrant les fichier à l'unité. Ainsi à chaque fichier
"copié" dans le montage correspondra un fichier, chiffrée cette fois, dans un
dossier protégé, source du montage. De même lorsqu'un dossier est
créé dans le montage, un dossier avec un nom chiffré est créé
dans le dossier protégé. Ainsi lorsque vous démontez le dossier
protégé, ne reste plus qu'une structure de fichiers illisible sans la clef.
Cette approche utilisant le même système de fichier que tout le monde, il n'y a pas
d'espace à réserver comme pour un système par conteneur. L'espace
occupé par les fichiers chiffrés est donc à peu prés le même
que s'ils ne l'étaient pas. De plus, en cas de corruption du système de fichier
sous-jacent, l'impact est lui aussi le même que pour les autres fichiers.
Maintenant cette technique n'est pas, elle non plus, sans inconvénients. Son principal
"problème" est l'impact sur les performances globales de lecture/écriture. Ce point
est la conséquence logique du fait que ces mécanisme se placent justement au dessus
du système de fichier bas niveau utilisant un mécanique fonctionnant dans l'espace
utilisateur, typiquement FUSE.
Tout ceci fait qu'à mon sens l'usage du chiffrement par fichier est réservé
à de simples dossiers contenant par exemple des documents confidentiels. A titre personnel
j'ai tout de même testé son utilisation pour un dossier utilisateur complet
(/home/gaston) et rien que le temps de lancement de Gnome est clairement affecté par la
manoeuvre alors qu'avec LUKS aucune différence n'est réellement ressentie. Pour
ceux que cela intéresse, une étude très serieuse sur les performances comparées native/LUKS/encFS
Maintenant avantage de l'inconvénient si j'ose dire, est que fonctionnant dans l'espace
utilisateur, ces mécanismes ne nécessitent aucunement les droits root pour
fonctionner.
Mise en oeuvre
Deux système s'opposent sur ce domaine : cryptofs ou encfs. Je ne vais pas partir sur un argumentaire de l'un en
faveur de l'autre. Tout deux fonctionnent sur le même principe et sont utilisable avec
FUSE. Pour ma part, j'ai opté un peu arbitrairement je l'avoue pour encfs.
Avec une distribution correctement dotée, tous les paquets sont déjà
prêts à l'emploi. Nous auront besoin de fuse, fuse-utils et bien évidement
encfs.
Sous Mandriva 2009.0, avec l'apparition de GVFS, FUSE est devenu un standard et le module fuse
est automatiquement chargé avec le service /etc/init.d/fuse. Si ce n'est pas le cas dans
votre distribution, faite, en tant que root, un echo fuse >> /etc/modules. Cela permettra
le chargement du module au prochain redémarrage. En attendant vous pouvez le charger
à la main par modprobe fuse.
La seconde chose à faire est d'ajouter les utilisateurs qui vont accéder à
encfs au groupe autorisé à utiliser fuse. Chacun sa méthode, personnellement
j'édite simplement /etc/group, je recherche fuse et j'ajouter l'utilisateur après
le dernier : (mettre des virgules si vous avez plusieurs utilisateurs). Dans tous les cas, ne me
demandez pas pourquoi, sous Mandriva, il va falloir redémarrer la session de cet
utilisateur pour poursuivre avec la prise en compte de son nouveau groupe.
Création d'un dossier protégé
A partir de là, créer un dossier chiffré se fait comme suit :
- # Initialisation du dossier par encfs qui a besoin de chemins ABSOLUS
- gaston$encfs $PWD/.dossier_chiffré $PWD/dossier_protégé
- Création du nouveau volume encrypté.
- Veuillez choisir l'une des options suivantes :
- entrez "x" pour le mode de configuration expert,
- entrez "p" pour le mode paranoïaque préconfiguré,
- toute autre entrée ou une ligne vide sélectionnera le mode normal.
- ?> p
- Configuration paranoïaque sélectionnée.
- Â
- Configuration terminée. Le système de fichier à créer a les
propriétés suivantes :
- Cryptage du système de fichiers : "ssl/aes" version 2:1:1
- Encodage de fichier "nameio/block", version 3:0:1
- Taille de clé : 256 bits
- Taille de bloc : 1024 octets, y compris 8 octets d'en-tête MAC.
- Chaque fichier contient un en-tête de 8 octets avec des données IV uniques.
- Noms de fichier encodés à l'aide du mode de chaînage IV.
- Les données IV du fichier sont chaînées à celles du nom de fichier
- Nouveau mot de passe :
- Vérifier le mot de passe :
- Â
- # copie d'un fichier dans le dossier protégé
- gaston$echo "coucou" > dossier_protégé
- Â
- # démontage du dossier
- gaston$fusermount -u dossier_protégé
En pressant p à la question, nous avons utilisé un pré-paramétrage
dit "paranoïaque". En gros il s'agit d'un chiffrage AES avec une clef 256 bits. En pressant
x vous pourriez changer toutes ces options.
Ensuite vous est demandé le mot de passe qui va être utilisé pour
déverrouiller le coffre-fort. Alors là le choix a de l'importance car il faut
quelque chose de long, genre 12 caractères c'est pas mal, contenant des symboles, des
chiffres, des caractères de case différentes. Évitez absolument tout mot du
dictionnaire, même modifiés. Les attaques par dictionnaires sur les mots de passes
idiots sont celles qui fonctionnent le mieux. Bref, un mot de passe quoi...
Options avancées
Un aspect étonnant d'encfs est que le dossier protégé est illisible par
n'importe quel autre utilisateur, y compris le root !! Cependant cette approche n'est pas
toujours pratiques, notamment si l'on cherche à chiffrer un dossier utilisateur
(/home/gaston) contenant un environnement gnome ou kde. Là il vaut mieux que le dossier
soit visible par root, ce qui se fait facilement en montant comme cela : sudo encfs /home/.gaston
/home/gaston -o nonempty --public
Notez que seul root a le droit d'utiliser l'option --public ce qui en réduit
considérablement l'interêt.
Une autre option intéressante utilisée ici est -o nonempty. Elle indique à
encfs de ne pas vérifier que le dossier cible soit vide avant montage. Sans elle, le
montage échouera dans ce cas de figure. Avec elle, il est possible de mettre un script
/home/gaston/.bashrc dans ce dossier pour justement faire le montage au login de M. gaston. Mais
il existe d'autres méthodes pour monter un dossier utilisateur crypté, comme nous
le verrons plus loin.
Il est aussi possible de changer changer à tout moment de mot de passe du dossier encfsctl
passwd /home/.gaston
Enfin, dans le cas d'un dossier que l'on n'utilise pas tout le temps, il est aussi possible de
demander à encfs un démontage automatique après une période
d'inactivité exprimée en minutes avec l'option -i.
Montage
Comme toujours, les montages FUSE et donc encfs peuvent être ajoutés à
/etc/fstab comme cela :
- # un dossier chiffré par encfs
- encfs#/home/gaston/.dossier_chiffré/ /home/gaston/dossier_protégé fuse
rw,user 0 0
Mais là où les choses se corsent un peu, c'est lorsque l'on cherche à
utiliser les montages via l'interface graphique. En effet, dans les précédentes
version de gnome (avant gvfs et spécifiquement gvfsd-computer), les montages FUSE
présents dans /etc/fstab étaient automatiquement visible dans nautilus via
computer:///. Il était donc possible de les monter en toute simplicité par un
click-droit. Aujourd'hui, en tout cas avec ma configuration (Mandriva 2009.0/Gnome 2.24) cela ne
fonctionne plus.
Plus embêtant, l'autre solution consistant à utiliser cryptkeeper, qui se placer dans
la zone de miniatures pour permettre le montage dynamique des dossiers chiffrés, ne marche
pas non plus. Cela commence par une erreur de compilation facile à régler (ajouter
#include &tl;cstring> à lsof.c) et cela se termine par l'outil qui n'arrive pas
à importer le moindre dossier. Si vous voulez tenter votre chance, je vous conseille ce
très bon tutoriel pour savoir comment l'utiliser.
Reste donc fusible, un
équivalent de cryptkeepr mais utilisant malheureusement Qt, et les montages en ligne de
commande...
Conclusion
Voilà, fin du petit panorama du chiffrage de système de fichiers sous GNU/Linux, en
espérant qu'il y en aura pour tous les goûts. Et sur ce, bonne paranoïa.
Billet original de Artisan
Numérique.Votez pour cet article sur le Planet Libre.
)
and reject those that you are not interested in
(
)
Billet original de 
