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 prix 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'esprit une seule 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 pu en un rien de temps brancher sa clef USB, recopier les documents récents, le profile firefox, etc. Et 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 :

1. Le cryptage total de tous les systèmes de fichiers, swap compris et ce dés le démarrage du système.
2. Le chiffrage d'un partition.
3. Le chiffrage d'une clef USB.
4. 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. Il existe cependant un portage de LUKS sous windows, FreeOTFE, mais je n'ai jamais réussi à le faire fonctionner... 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é

gaston$ 

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.

L'autre solution consiste à utiliser cryptkeeper, un très bon outil qui se place dans la zone de miniatures et permet le montage dynamique des dossiers chiffrés. Malheureusement il n'est pas dans les dépôts mandriva et la version en source ne passe pas très bien 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.