Système de fichier chiffré

Après avoir utilisé pendant près d’un an cryptoloop, il nous faut passer à dm-crypt. L’occasion de disposer d’un nouveau PC est trop belle. Nous allons donc voir comment on peut procéder avec dm-crypt pour crypter tout ou partie d’un système de fichiers.

Pour commencer: des explications et un exemple simple

Principes

dm-crypt utilise un système de Device Manager (DM) pour crypter les données. Le DM agit comme une sorte de filtre entre un périphérique de bloc virtuel et un périphérique de bloc physique. Lorsqu’un bloc de données va de l’un à l’autre, il est crypté par le module. Pour de bonnes performances, nous allons utiliser l’algo aes avec une clef de 256 octets.

Installation

Première étape: un noyau ayant le module dm-mod. C’est en standard partout. Un simple modprobe dm-mod doit suffir à charger le module. Ensuite, il faut que /dev/mapper/control existe. Sinon, il faut installer la libdevmapper. Normalement, on doit utiliser le programme dmsetup pour gérer les opérations de device (création, dimensionnement, etc…) mais son interface n’est pas triviale. C’est pourquoi, un petit apt-get install cryptsetup est recommendé: cette commande est plus facile à utiliser.

Préparation du système

Pour éviter de charger les modules à la main avec modprobe, il convient d’ajouter les modules dans /etc/modules.

echo aes >> /etc/modules
echo dm_mod >> /etc/modules
echo dm_crypt >> /etc/modules

En avant avec cryptsetup

Création du device crypté: sudo cryptsetup create crypt /dev/hda7

Cette commande va créer un “Crypted Device Mapper” (CDM) nommé crypt (visible dans /dev/mapper tel que) pointant sur /dev/hda7. A noter que la création du CDM n’intervient pas sur la partition cible. A ce niveau, il n’y a rien de touché ! On pourrait même imaginer créer deux CDM pointant vers la même partition.

Si on a fait une erreur, on peut revenir en arrière en supprimant le device toujours avec cryptsetup:cryptsetup remove crypt

Pour aller plus loin, on peut jouer avec les options de cryptsetup pour disposer d’un système adapté à nos besoins: sudo cryptsetup --verify-passphrase --cipher aes --key-size 256 create crypt /dev/hda7 Dans ce cas, cryptsetup va créer un CDM avec l’algorithme AES avec une clef de 256 octets et va chiffrer cette clef avec un password qu’il demandera de confirmer (option –verify-passphrase).

Vérification de la création du CDM

sudo cryptsetup status crypt

Cette commande retourne chez moi les références suivantes:

/dev/mapper/crypt is active:
cipher: aes-cbc-plain
keysize: 256 bits
device: /dev/.static/dev/hda7
offset: 0 sectors
size: 58588992 sectors
mode: read/write

Ne reste qu’à remplir

En effet, maintenant, /dev/mapper/crypt est périphérique de blocs comme un autre. Dans ces conditions, il est possible de le formatter comme une partition et de l’intégrer dans le montage des systèmes de fichier au démarrage de la machine.

Formattage du CDM

C’est très simple: on procède comme tout autre périphérique de bloc (ici, j’ai choisi d’utiliser du reiserfs comme système de fichiers): sudo mkfs.reiserfs /dev/mapper/crypt

Modifications des fichiers pour montage

Il faut amender notre /etc/fstab pour indiquer qu’on souhaite monter /dev/mapper/crypt au bon endroit: sudo echo "/dev/mapper/crypt /private_life reiserfs defaults 0 1" >> /etc/fstab

Maintenant, un simple: mount /private_life suffit pour monter le système de fichiers chiffré.

Montage au démarrage

Là, un problème supplémentaire vient se greffer: si on désire monter notre partition chiffrée automatiquement au démarrage, il faut impérativement demander le mot de passe qui protège la clef de chiffrement du CDM crypt. Pour cela, il suffit de renseigner le fichier /etc/crypttab, sorte de fstab pour dm_crypt: sudo echo "crypt /dev/hda7" >> /etc/crypttab

Ainsi, au démarrage, il faudra entrer la “passphrase” pour activer le CDM. Ensuite, suivant la configuration de fstab, la partition sera montée directement.

Si le fait de taper une passphrase au démarrage vous ennuie, le mieux est de supprimer les liens vers le script de démarrage /etc/init.d/cryptdisks par la commande suivante: sudo update-rc.d -f cryptdisks remove Une fois que l’on désire lancer le système de chiffrement, il suffit de lancer la commande sudo /etc/init.d/cryptdisks

dm_crypt sur un fichier loopback

Le problème

Je n’ai pas envie d’utiliser une partition complète pour crypter un système de fichiers. Une solution existe: elle consiste à créer un périphérique loopback à partir d’un fichier. Ensuite, on dispose d’un périphérique de bloc qui va bien et on peut donc appliquer dm_crypt.

La manip en détails: Création du fichier support:

On commence par créer un fichier rempli de bordel (random) qui va contenir notre futur système de fichiers chiffré: dd if=/dev/urandom of=./carchive1 bs=1M count=60000

Attention: c’est très (trop) long. Les moins paranos d’entre nous remplirons le fichier avec des zéros: dd if=/dev/zero of=./carchive1 bs=1M count=60000

Initialisation du périphérique de boucle (loopback device)

Une interface de boucle (loopback) permet d’utiliser un fichier comme périphérique de bloc. Pour initialiser le périphérique de boucle, on utilise losetup: sudo losetup -f ./carchive1

Cette commande affecte le premier périphérique de boucle disponible au fichier ./carchive1. Ensuite, c’est la même chose avec dm_crypt qu’avant:

Au lieu de travailler avec /dev/hda7, on va travailler sur le loopback choisi (suivant les cas /dev/loop0 ou /dev/loop1), etc…

sudo cryptsetup -y --cipher aes --key-size 256 create crypt_loop /dev/loop1 sudo mkfs.reiserfs /dev/mapper/crypt_loop

Les problèmes: le démarrage

Pour l’instant, cryptsetup ne supporte pas directement les périphériques de boucle. Donc en attendant, il faudra, à chaque démarrage lancer un script qui associera le loopback device au fichier puis qui activera le CDM correspondant au loopback-device.

sauvegardes et récupération

Introduction

On va présenter le problème simplement: le disque système de ta machine vient de cramer. En revanche, le disque de data est encore OK ! Tu remontes un système qui va bien mais comment on fait pour récupérer ce qui est sur le data ? Bonne question…

Petite expérience:

Si on tente de recréer un CDM qui pointe vers un périphérique de blocs déjà passé à la moulinette, voilà ce que ça donne (on passe les configs de fstab): cryptsetup --verify-passphrase --cipher aes --key-size 256 create crypt /dev/hda7 (on met le même passphrase). mount /dev/mapper/crypt

Ben, ça marche… mais je ne l’ai fait que sur une machine précise avec une seule distribution (Ubuntu).

Conclusion

Lors d’un crash machine, si vous voulez récupérer vos données cryptées, il suffit de recréer le bon CDM avec la même passphrase (et les mêmes paramètres genre les offsets).

Crypter le swap

Introduction

Question:Pourquoi crypter le swap ? Réponse: Parce qu’on est parano et qu’on aime ça…

Plus sérieusement, une bonne analyse du swap qui, par défaut, est le reflet d’un moment donné de la RAM de votre système peut réveler des informations sensibles sur votre vie privée.

Principes

Le swap n’est pas comme un système de fichiers simple: son contenu est amené à changer souvent et il ne sert pas de stockage à long terme d’informations. C’est pourquoi on peut utiliser une clef jetable pour le chiffrer. Cette notion de clef jettable est particulièrement intéressante:

  • l’utilisateur même ne sait pas comment elle est.
  • elle change à chaque démarrage augmentant ainsi le niveau de sécurité
  • elle est générable directement par la machine: le processus de montage du swap est donc facile: on ne demande pas de “passphrase”.

Nous allons donc utiliser /dev/random pour générer la clef !

En avant

Opérations de création:

Chez moi, le swap est en /dev/hda9. On va donc l’arrêter puis créer un CDM avec les bonnes commandes en choisissant /dev/random pour générer la clef. Ensuite, on montera tout ça.

Ca donne ça:

sudo swapoff /dev/hda9
sudo cryptsetup -d /dev/urandom create cryptoswap /dev/hda9
sudo mkswap /dev/mapper/cryptoswap -L le_swap_chiffre -v1

La première ligne arrête le swap présent en /dev/hda9. La seconde ligne créé un CDM (nommé cryptoswap) à la volée. La troisième ligne créé un swap sur le CDM cryptoswap en lui donnant un label (le_swap_chiffre), avec comme type nouveau (-v1).

Volatilité au démarrage

Les principes vus dans le point précédent peuvent être relancés à chaque démarrage de manière à disposer d’un swap complètement neuf aussi bien dans le contenu que dans la clef de chiffrement.

Pour cela, il suffit d’amender le contenu de /etc/crypttab: echo 'cryptoswap /dev/hda9 /dev/urandom swap' >> /etc/crypttab Ensuite, il faut indiquer dans /etc/fstab qu’on désire utiliser /dev/mapper/cryptoswap comme périphérique de swap. /dev/mapper/cryptoswap none swap sw 0 0

Une fois ces changements faits, un simple sudo swapon -a suffit pour remonter le swap. D’ailleurs cette commande est lancée au moment du démarrage de la machine.

Conclusion

Ca prend deux minutes pour crypter son swap, ce n’est pas dangereux (pas de perte de données vitales), c’est très sûr et les performances restent correctes. Conclusion: à faire absolument.

Les extensions LUKS

LUKS, c’est quoi ?

LUKS signifie Linux Unified Key Setup. En gros, c’est un effort de standardisation des systèmes de génération de clefs pour les protections de systèmes de fichiers cryptés. Si on se réfère au point sur les sauvegardes, on voit que c’est assez risqué. Je sais par expérience qu’entre une Ubuntu 32bits et une Ubuntu 64bits (la même Breezy), il est impossible de partager un FS crypté.

LUKS entre toutes les informations pour générer la clef directement dans la partition cryptée. Dans ces conditions, on a toujours assez d’informations pour regénérer la clef correctement. De plus, LUKS permet de changer le mot de passe de protection de la clef sans devoir tout réencoder.

En revanche, LUKS ne fonctionne que sur une partition…

Comment on utilise LUKS avec dm_crypt ?

Par bonheur, cryptsetup de Ubuntu contient les extensions LUKS. Il nous suffit donc de reprendre nos commandes habituelles et d’ajouter des options.

Pour vérifier si cryptsetup supporte LUKS, un simple cryptsetup –help suffit: si on voit des lignes genre: luksFormat / [] - formats a LUKS device luksOpen - open LUKS device as mapping

Faire du bruit

Avant de remplir la partition avec des données chiffrées, on va la remplir avec du bruit (des données aléatoires). Sur un disque neuf et non utilisé,on peut utiliser badblocks avec les options de random pour générer ce bruit. Dans mon cas, je veux juste m’occuper de la partition /dev/hdb5 de 30Go. On va donc utiliser dd: sudo dd if=/dev/urandom of=/dev/hdb5

Ca prend environ 5 minutes par Go soit dans mon cas, près de 2H30…Au fait, n’utilisez pas /dev/random: ça prendrait des années à remplir ! Présentation des opérations LUKS de cryptsetup

Les extensions LUKS de cryptsetup ne sont pas nombreuses. En voici une rapide présentation: - luksFormat: initialise une partition et initialise sa clef - luksOpen: active la partition et la lie à un CDM - luksClose: supprime le CDM lié à la partition - luksAddKey: Ajoute une clef d’accès à la partition - luksDelKey: efface une clef d’accès à la partition - luksUUID: retourne le UUID - luksDump: fait un dump de l’entête de partition - isLuks: vérifie si la partition est en mode LUKS.

Création de la partition LUKS

C’est la première étape: on va utiliser luksFormat avec quelques options pour convenir à notre besoin. luksFormat va nous permettre de mettre une première clef pour chiffrer notre partition. sudo cryptsetup --verbose --verify-passphrase --cipher aes -yptsetup luksClose archive_vol0

Note: soyez sûr de taper YES en MAJUSCULE lorsque cryptsetup vous demande si vous voulez effacer la partition.

Activation et formattage de la partition LUKS

Ensuite, il faut activer la partition et la formatter. Activer une partition, c’est en fait créer le CDM à la volée. sudo cryptsetup luksOpen /dev/hdb5 archive_vol0 Normalement, une passphrase est demandée.

Ensuite, /dev/mapper/archive_vol0 peut être utilisé comme n’importe quel périphérique de bloc. Nous allons formatter cette partition en reiserFS (3.6, pas assez moderne pour du reiserFS4), les options par défaut me suffisent: sudo mkfs.reiserfs /dev/mapper/archive_vol0

On peut maintenant désactiver la partition: sudo cryptsetup luksClose archive_vol0

Montage et démontage à la volée

Pour ma part, l’intérêt de LUKS avec cryptsetup est de pouvoir monter facilement la partition à un autre moment qu’au boot: sur ma machine, il existe plusieurs utilisateurs. Je ne désire pas que ces derniers partagent ma passphrase de chiffrement ni même qu’ils aient un dialogue qui demande cette passphrase. Dans ces conditions, un montage au boot est assez lourd.

Grâce à LUKS, on peut avec une combinaison de commande monter rapidement la partition chiffrée à la demande: sudo cryptsetup luksOpen /dev/hdb5 archive_vol0 && sudo mount /dev/mapper/archive_vol0 /mnt/archive_vol0

Il est facile de mettre cette commande dans un script.

Pour démonter à la volée, il suffit de lancer la commande: sudo umount /dev/mapper/archive_vol0 && sudo cryptsetup luksClose archive_vol0

Références:

[1] Site principal de dm-crypt [2] Wiki de dm-crypt [3] Wiki de dm-crypt sur LUKS [4] Wiki Ubuntu sur les systèmes de fichiers cryptés [5] Site de LUKS: Linux Unified Key Setup

December 6th, 2005 at 19:46

Posted mar. 06 d�c. 2005 18:46:00 Tags:

Installation de Widelands build9-half sur Ubuntu Breezy

Widelands est un port libre du jeu “The Settlers”. Il est assez bien fichu. Toutefois, la version officielle de Ubuntu est le build9 qui date de janvier 2005.

Le build9-half est sorti début décembre 2005 et il est bon de voir ce qu’il y a dedans. Nous sortons donc du paquet Ubuntu pour revenir à la bonne vieille compilation à la main que nous adorons et qui nous permet de profiter de toutes les dernières modifications…

Dépendances:

Widelands a besoin des librairies suivantes pour pouvoir être compilé: - SDL - SDL_mixer >= 1.2.6 - SDL_image - SDL_net - SDL_ttf >= 2.0.0 - gettext (look at FAQ if you have problems with -lintl) - libpng - zlib

En gros, pour être sûr d’avoir tout, la commande suivante peut être lancée: sudo apt-get install libsdl1.2-dev libsdl-image1.2 libsdl-image1.2-dev libsdl-mixer1.2 libsdl-mixer1.2-dev libsdl-net1.2 libsdl-net1.2-dev libsdl-ttf2.0 libsdl-ttf2.0-dev gettext zlib1g zlib1g-dev libpng12-0 libpng12-dev

Attention à bien préciser la version de libsdl-ttf: en version 1.2, la compilation plante.

Téléchargement:

Récupérer les sources à l’emplacement suivant: Sources de Widelands build9-half sur sourceforge

Compilation:

Après avoir déchargé l’archive dans un répertoire, on constate qu’il n’y a pas de ./configure et rien pour le générer. Conclusion, widelands n’utilise pas les outils GNU pour préparer la compilation. Ainsi, il va falloir se modifier le Makefile à la main pour le faire. A priori, ce travail est assez limité et on peut, du moins pour la compilation, lancer un simple make.

Sur Ubuntu, la compilation échoue avec le message suivant: /usr/bin/ld: ne peut trouver -lintl Comme indiqué dans la FAQ de widelands [2], cela vient du fait que sur Ubuntu, il n’existe pas de librairie intl. Il faut donc indiquer dans le Makefile ou dans le Makefile.local qu’on désire utiliser la libc pour intl. Pour cela, la commande suivante créé un fichier Makefile.local qui va bien: echo "IMPLICIT_LIBINTL:=yes" > ./Makefile.local

Ensuite, un simple: make suffira pour lancer la compilation (à priori pas trop longue sur une machine moderne).

Si la commande n’échoue pas, on peut lancer directement widelands sans l’installer.

Installation sur le système

Un coup d’oeil dans le Makefile nous indique qu’il n’y a pas de directive “install”. Il faut donc se débrouiller pour installer le jeu à la main.

Références:

[1]Le site officiel de Widelands [2]FAQ de widelands sur la lib intl December 10th, 2005

Posted sam. 10 d�c. 2005 13:00:00 Tags: