Depuis Linux version 2.4.22, le noyau stable intègre un ensemble d'algorithmes de cryptographie regroupés sous le nom de 'Scatterlist Cryptographic API'. Cette API est un 'backport' en provenance du kernel 2.5/2.6.
Grâce à cette API et à une extension du device loop, il est possible de crypter un système de fichiers. Nous allons apprendre ici à l'installer et à la configurer.
Il faut savoir qu'il existe deux versions d'API cryptographiques :
À noter qu'il existe aussi la solution loop-AES développée par AT pp.inet.fi Jari Ruusu. Voir plus loin.
Le loop device permet de simuler un périphérique en mode bloc à partir d'un fichier. C'est grâce à ce driver que l'on peut monter les images de CD-ROM au format ISO9660 :
La cryptoloop insère les fonctions de cryptage dans les fonctions de lecture et d'écriture du loop device. Le loop device est donc utilisé pour convertir un fichier crypté en block device que l'on peut ensuite monter comme un disque normal. Tout ce qui est écrit sur ce système de fichier est crypté, autant les données que les méta-données (arborescence, noms de fichiers, droits d'accès, ...). L'accès aux fichiers est entièrement transparent, à part un temps d'accès plus important que l'accès direct.
La cryptoloop utilise l'API de cryptographie afin d'avoir accès aux différents algorithmes de cryptage ('cypher') enregistrés. Parmi les cyphers disponibles dans la 'scatterlist cryptoapi', on citera : AES(Rijndael), Blowfish, Twofish, Serpent et l'antique DES.
Bien que les algorithmes de cryptage soient présents dans le kernel 2.4.22, il n'y a pour l'instant aucun driver permettant de crypter un fichier, un système de fichiers, un disque ou le swap. Il faut toujours un patch pour étendre les fonctionnalités du périphérique loop, ceci afin d'y insérer les fonctions de cryptage à la volée. Pour la version 2.4, sont donc nécessaires :
Le premier patch apporte un nombre conséquent de changements au driver loop mais permet en contrepartie de crypter le swap. Le deuxième patch applique le minimum de changements pour permettre le cryptage/décryptage. L'auteur recommande l'usage du premier car il calcule correctement les tailles des volumes si l'on fait usage des offsets (voir plus loin).
Quant à la prochaine version stable du kernel, la 2.6, tout y est présent : API cryptographique, crypto loop device et IPSec, donc pas de patch à appliquer.
Ensuite, il est nécessaire de disposer des outils en adéquation avec la version de la cryptoloop/cryptoapi : vérifiez si vous votre système ne dispose pas des util-linux 2.12 : mount -V Si ce n'est pas le cas, il vous faut alors :
Ou bien :
À noter que Debian (3.0 Woody) fournit une version d'util-linux intégrant les patchs pour la cryptoapi de kerneli.org et est inutilisable pour notre usage.
Remarque : Attention, lors de la mise à jour de vos outils, il est possible que d'une version (patch) d'util-linux à l'autre, la méthode pour étendre et/ou hasher le mot de passe peut être différente. Ce changement produisant alors un mot de passe incapable de décrypter vos données. L'auteur vous conseille d'utiliser les util-linux 2.12, nouvelle version qui va fixer la norme assurant la compatibilité future.
Pour les gens déjà au kernel 2.6, allez directement en 2.
Pour manipuler le loop device patché, il faut une version adéquate de lomount. Cet outil, que l'on trouve généralement dans le répertoire /sbin, fait partie des util-linux. Comme précisé précédemment, la version 2.12 intègre un support de la cryptoloop, mais ne fournit pas tous les services que la version 2.11z avec le patch Jari.
Si actuellement vous n'avez pas les util-linux 2.12 :
Nous allons préparer un système de fichiers crypté pour un utilisateur en particulier. Le système de fichier sera monté dans le répertoire home de cet utilisateur.
On pourra aussi utiliser une autre arborescence reprenant la même structure que /home mais dédiée aux données cryptées : /crypt/user/ contenant le container crypté et le système de fichiers crypté pour chaque utilisateur. Ce choix est laissé au soin du lecteur.
Voici la liste des commandes à utiliser lors la création de votre container crypté :
$ signifie que la commande est lancée en tant qu'utilisateur lambda, # signifie que la commande requiert les droits du super utilisateur (root).
Définition des variables d'environnement :
On définit les chemins et les paramètres de cryptage. On spécifie le nom du fichier qui va contenir le système de fichiers crypté. Ce fichier est appelé par la suite container.
Création du container :
Activation :
C'est à ce moment que le système va vous demander de choisir un mot de passe.
Note : Avec les util-linux 2.12, il est impossible de choisir la taille de la clé, fixée à 256 bits (32 octets). De plus le mot de passe n'est pas étendu/hashé, donc utilisez un mot de passe d'une taille avoisinant les 32 caractères.
Initialisation :
Création du système de fichier, on utilise ici ext3fs, la version journalisée du système de fichiers ext2fs. Cela a pour avantage de limiter les risques de corruption des méta données dans le container, mais c'est coûteux en ressources si le système de fichiers où se trouve le container est lui aussi journalisé.
Si la création du système de fichiers échoue à cause d'une écriture en dehors du périphérique, c'est que vous faites usage de l'offset avec une version de la loop device qui ne le gère pas correctement. Dans ce cas vous pouvez changer de patch ou alors calculer le nombre de blocs disponibles pour le système de fichiers et passer cette valeur à mkfs.ext3 : (taille du container / 512) - offset .
Au final :
Maintenant que tout est prêt, on peut monter le container de façon intégré en une seule opération :
Malheureusement, seul root a la possibilité de monter le container crypté. Dans /etc/fstab, une option user=xxx ou group=xxx autorisant seulement un utilisateur ou un groupe d'utilisateur à monter/démonter un système de fichier serait intéressante ici : une idée à creuser.
Pour l'instant, l'administrateur peut créer un script contenant toutes les commandes nécessaires, et autoriser l'utilisateur à exécuter ce script grâce à 'sudo'.
NOTE : attention, ici on monte le container crypté par dessus le répertoire le contenant. Quand il est monté, cela rend son accès impossible pour l'utilisateur lambda. Cela évite que l'on puisse effectuer une recherche de clé de cryptage par force brute en comparant le système de fichier décrypté et le container crypté. Mais cette astuce permet surtout d'éviter de modifier le container pendant qu'il est monté.
Vous serez probablement amenés à changer de mot de passe ou d'algorithme de cryptage. L'opération n'est pas transparente : elle nécessite la création d'un nouveau container et la recopie des informations contenues dans l'ancien.
Deux solutions sont disponibles : la copie brute du container ou la copie des fichiers.
Ici on effectue une copie bloc pour bloc des loop devices :
Il est possible de spécifier une taille plus grande, de copier les données avec dd, et ensuite d'utiliser un outil comme resize2fs pour agrandir le système de fichiers. Cet exercice est laissé au soin des lecteurs aventureux.
Cette fois, nous allons copier les fichiers présents dans le container :
Ensuite il faut créer un nouveau container en suivant la même marche à suivre qu'au début. Ce nouveau container doit être suffisament grand pour contenir un système de fichiers contenant les fichiers de l'ancien container. De plus, la remarque précédente au sujet des offsets s'applique ici aussi.
Avant de monter le nouveau container, activez l'ancien :
Montez ensuite le nouveau container et l'ancien :
Recopiez ensuite les fichiers :
Supprimez ensuite l'ancien container :
La deuxième solution permet un changement de type de système de fichiers et un redimensionnement simple du système de fichiers, mais nécessite de monter deux fois le container, exposant deux fois les données non cryptées.
Loop-AES développée par .ruusu@pp.inet.fi Jari Ruusu, n'est pas une API de cryptographie générique, ce patch ne fournit que les services de cryptage de volumes. Loop-AES offre plus d'algorithmes que son nom ne le laisse croire : twofish, blowfish, mars et rc6 sont supportés en plus d'AES. Cette solution de cryptage est moins générique mais plus performante que les autres de par sa spécialisation.
Quelques rappels sur la sécurité...
Nous avons vu comment crypter un système de fichiers contenu dans un fichier. Pour allez plus loin, on peut utiliser une partition en lieu et place du fichier container.
Il est maintenant 'facile' de crypter ses données avec le noyau Linux, même s'il faut toujours un patch pour la version 2.4. À terme, la version 2.6 de linux plus les util-linux 2.12 offriront à tout un chacun la possibilité de crypter des systèmes de fichiers.
Ensuite à chacun de voir s'il a besoin de crypter ses données et s'il a confiance dans les algorithmes du kernel.
Copyright
Copyright (C) 2003 @meuh.eu.org Yann Droneaud Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
@ Retour à la rubrique Réseau et sécurité
Copyright © 09/09/2002, Meuh
![]() ![]() ![]() ![]() |
Ce document est publié sous licence Creative Commons Attribution, Partage à l'identique, Contexte non commercial 2.0 : http://creativecommons.org/licenses/by-nc-sa/2.0/fr/ |