Ashram de Swâmi Petaramesh - cryptographie

Une clé de contact pour votre portable chiffré : Version 1.6

Petaramesh — Mon, 21 Jul 2008 23:12:00 +0200

Ce billet est là uniquement pour signaler une mise à jour du script bootkeyscript proposé dans mon précédent billet "Une clé de contact pour votre portable chiffré".

Avec la version 1.6, il est désormais possible de spécifier la partition où se trouve le fichier-clé déverrouillant le système, non seulement par son device (i.e. sdb1) mais également par son label de filesystem ou son UUID,^[1] ce qui permet d'utiliser une fichier-clé sur un périphérique dont le nom est susceptible de changer d'une fois sur l'autre.

Notes

[1] Si le filesystem contenant le fichier-clé est chiffré LUKS, il est seulement possible d'utiliser l'UUID du conteneur LUKS, mais pas le label ou l'UUID du filesystem qui est à l'intérieur.

Retailler à la volée une LVM chiffrée LUKS

Petaramesh — Tue, 27 May 2008 11:58:00 +0200

(English abstract at end.)

Et encore un article en bas moldave qui s'annonce ;-)

J'explique ci-dessous comment il est possible d'agrandir à la volée une LVM chiffrée LUKS sur laquelle est installé tout un système GNU/Linux chiffré (ici une Ubuntu 8.04 Hardy).

Si cela vous parle autant que l'élevage du Yaka-Faucon en Patagonie septentrionale, passez votre chemin ;-)

Ma problématique pour cette manip' était la suivante : un ordinateur portable entièrement chiffré (sauf /boot) dont le disque dur était partitionné de la manière suivante :

sda1: /boot (non chiffré)
sda2: LVM chiffrée contenant le root filesystem et la quasi-totalité des volumes logiques usuels (/var, /home...)
sda3: un /tmp chiffré utilisant une clé aléatoire générée au boot.
sda4: un swap chiffré utilisant une clé aléatoire générée au boot.

L'objectif de la manip était d'"incorporer" le /tmp et le swap à l'intérieur de la LVM chiffrée principale et non plus à l'extérieur de celle-ci, de manière à pouvoir utiliser la fonction "hibernation sur disque" de la machine, qui nécessite en pratique que le déchiffrement du root filesystem au boot permette également l'accès au swap sur lequel est stocké le fichier de reprise, le plus simple étant alors de mettre le swap dans la même LVM chiffrée que le reste des partitions.

La même manip pourrait être utilisée à d'autres fins, par exemple augmenter l'espace disque utilisable après avoir recopié l'ensemble d'un système chiffré sur un disque neuf plus gros.

Pour que ça soit plus drôle, nous allons faire ça en live, sur le système tournant et bien chaud, et sans recourir au boot sur un CD-Rom.

Cet article est en partie inspiré de l'article de Bodhi.Zazen : How to Resize a LUKS Encrypted File System.

Avertissement : Ce type de manipulation est susceptible de provoquer la perte irréparable de l'ensemble des données présentes sur votre disque, si vous faites la moindre erreur durant les opérations, ou si j'ai fait la moindre erreur en les décrivant ! Faites une copie de sauvegarde de l'ensemble de votre système, vous êtes seul(e) responsable des dégâts que vous vous apprêtez à causer, même si une erreur s'est glissée dans mon article et si c'est moi qui vous ai foutu dedans. À vos risques et périls ! ;-)

Dans mon cas particulier, je vais donc commencer par supprimer les partitions sda3 et sda4, dont le contenu sera perdu durant l'opération, mais cela est sans importance s'agissant d'un /tmp et d'un swap, puis je vais étendre la partition sda2 sur laquelle réside la LVM chiffrée afin de récupérer dedans l'espace laissé libre par les partitions supprimées, puis j'agrandirai le container chiffré qui occupe cette partition, puis j'agrandirai le volume physique de LVM qui est dedans, ce qui ajoutera à la LVM chiffrée l'espace ainsi récupéré, permettant alors d'y créer de nouveaux volumes logiques, ou d'étendre les volumes logiques existants.

Dans le cas général, on considèrera que nous disposerons d'une manière ou d'une autre d'espace disque libre immédiatement après la partition contenant la LVM chiffrée à étendre.

Dans mon cas particulier, il me faut commencer par désactiver le swap (swapoff -a) dont je vais supprimer la partition, démonter le /tmp, et le démontage du /tmp nécessite de fermer toute session graphique X (KDE ou Gnome) et d'arrêter le gestionnaire de session graphique (invoke-rc.d kdm stop ou invoke-rc.d gdm stop selon le cas), ce qui me fera donc travailler en mode console texte. Il me faudra ensuite désactiver les volumes chiffrés correspondants avant de pouvoir en supprimer les partitions.
Dans le cas général, si vous n'avez pas besoin de démonter une partition nécessaire, vous pouvez travailler dans un terminal depuis une session graphique.

Retaillage des partitions

Commençons donc par décrire l'étape de suppression des partitions inutiles, et de redimensionnement de la partition à agrandir.

Nous allons pour cela utiliser le bon vieux fdisk en console, et non pas un outil graphique, car seul fdisk nous permettra de supprimer notre partition essentielle (celle de la LVM chiffrée) et de la recréer exactement au même endroit, mais plus grande.

Lançons donc: fdisk /dev/sda

La première chose à faire est d'afficher la table de partitions actuelle en utilisant la commande "p", et de noter absolument tous les jolis chiffres qui apparaîssent alors, de manière à pouvoir remettre manuellement les choses en l'état en cas de problème.

Puis nous utiliserons la commande "d" de fdisk afin de détruire sans regret les partitions "4" et "3" dont nous n'avons plus besoin.

Puis nous arrivons à l'étape vraiment terrifiante de la manoeuvre, qui consiste à supprimer la partition sda2, c'est-à-dire celle de notre LVM chiffrée, ce qui revient très exactement à scier la branche sur laquelle notre système est assis. Supprimons donc courageusement la partition "2" à l'aide de la commande "d".

Pas de panique toutefois, les modifications ne seront réellement apportées sur le disque qu'au moment où nous exécuterons la commande "w" finale, et nous aurons recréé la partition vitale d'ici-là, mais en plus grand. D'autre part, la modification de la table de partitions sera alors écrite sur le disque dur lui-même, mais le noyau Linux n'en tiendra aucun compte puisqu'il est incapable de relire la table de partitions d'un disque ayant des partitions montées. Il faudra donc rebooter le système pour que le changement de taille de la partition concernée soit pris en compte.

Après avoir supprimé la partition "2", nous la recréons maintenant aussitôt, comme partition primaire, en utilisant la commande "n". Nous veillerons alors à ce que la "nouvelle partition 2" commence à l'endroit exact du disque (numéro de cylindre) où elle commençait précédemment, et nous la laisserons s'étendre jusqu'à la fin du disque, utilisant ainsi tout l'espace disponible.

Après avoir recréé la partition, utilisons la commande "p" pour afficher la nouvelle table de partitions, et vérifions soigneusement à l'aide de nos notes qu'elle commence effectivement exactement au même endroit que précédemment.

Si c'est bien le cas, nous pouvons alors écrire nos modifications de manière définitive avec la commande "w", qui nous fera également quitter fdisk.

Nous allons maintenant devoir rebooter le système pour que la nouvelle table de partitions soit prise en compte. Toutefois, si nous avons (dans mon cas particulier) supprimé des partitions qui servaient antérieurement, nous devons en faire disparaître toute trace dans /etc/fstab et /etc/crypttab, puis régénérer notre initramfs (update-initramfs -u) pour éviter de cruelles erreurs lors du reboot.

Rebootons donc bien proprement le système. Ceci devrait se dérouler sans erreur.

Extension du volume LUKS chiffré

Après avoir rebooté, il nous faut théoriquement agrandir le volume chiffré supportant notre LVM. Je dis théoriquement car mes observations semblent démontrer que le volume chiffré utilise automatiquement la nouvelle taille entière de la partition, mais comme je n'en suis pas absolument certain, le redimensionner quand même ne fera pas de mal.

Affichons tout d'abord la taille actuelle de notre container de LVM chiffrée, supposant qu'il s'appelle "encVG" par exemple :

# cryptsetup status encVG
/dev/mapper/encVG is active:
 cipher:  aes-cbc-essiv:sha256
 keysize: 192 bits
 device:  /dev/sda2
 offset:  1032 sectors
 size:    312061593 sectors
 mode:    read/write

"Agrandissons" (en théorie) maintenant le container :

cryptsetup resize encVG

Affichons de nouveau sa taille (cryptsetup status encVG) : Surprise : il semble que rien n'a changé, et que notre manip n'a donc servi à rien ? Ce n'est pas grave : nous utilisons désormais bel et bien la totalité de l'espace attribué à la partition sda2.

Agrandissement du volume physique de la LVM

C'est là que nous allons nous apercevoir que la manip' a marché !

# pvs
 PV                       VG   Fmt  Attr PSize   PFree
 /dev/mapper/encVG VG1 lvm2 a-   144.80G    0

pvresize /dev/mapper/encVG

# pvs
 PV                       VG   Fmt  Attr PSize   PFree
 /dev/mapper/encVG VG1 lvm2 a-   148.80G    4.0G

Eh oui ! le "pvresize" nous a bien fait gagner 4 Go d'espace libre dans la LVM chiffrée !

Création des nouveaux volumes logiques

Nous pouvons maintenant créer (lvcreate) un ou plusieurs nouveaux volumes logiques dans l'espace désormais disponible sur la LVM. Dans mon cas, j'en recréerai deux, pour le /tmp et pour le swap bien sûr.

Si vous souhaitez utiliser ce nouvel espace non pas pour créer de nouveaux volumes logiques, mais pour agrandir un volume déjà existant (lvextend), je vous conseille toutefois de commencer par créer un nouveau volume logique, que vous supprimerez ensuite, mais entre-temps vous l'aurez rempli de données aléatoires, ce qui est toujours conseillé avant de commencer à utiliser un volume chiffré.

Remplissage des nouveaux volumes logiques avec des données aléatoires

Par exemple :

dd if=/dev/urandom of=/dev/mapper/VG1-newvolume bs=1M

(Si vous voulez accélérer cette étape, vous pouvez utiliser /dev/zero à la place de /dev/urandom, puisque, s'agissant d'un volume chiffré, le chiffrement donnera de toute manière un aspect parfaitement aléatoire aux données qui seront physiquement écrites sur le disque (les zéros seront transformés en random apparent).

Formatage des nouveaux volumes logiques

Nous n'avons plus désormais qu'à formater les nouveaux volumes logiques en fonction de leur utilisation projetée : mke2fs, mkswap, etc... ou, pour l'extension d'un volume existant, lvextend puis resize2fs^[1] par exemple.

Mise à jour de fstab

Enfin, nous pouvons monter nos nouveaux volumes, sans oublier bien sûr de les mentionner dans /etc/fstab - il n'y a rien à ajouter dans /etc/crypttab puisque l'entrée servant à déverrouiller globalement la LVM chiffrée y figure déjà.

That's all, folks !

English abstract : This article explains how to expand a LUKS-encryped LVM on which resides a fully encrypted GNU/Linux System, including its root filesystem. This can be done on the "live" system without needing to boot from a live CD or the like. Use an online translator such as Google translate or babelfish to obtain a truly bad, automated translation of this document ;-)

Help Google : resize enlarge expand LUKS encrypted partition LVM container on the fly

Notes

[1] À effectuer sur un volume préalablement démonté

Une clé de contact pour votre portable chiffré : Mise à jour

Petaramesh — Sun, 11 May 2008 09:46:00 +0200

Ce billet est là uniquement pour signaler une importante mise à jour de mon précédent billet Une clé de contact pour votre portable chiffré et du script bootkeyscript^[1] qu'il propose.

En effet, ce script s'est avéré dans sa version précédente pouvoir très mal fonctionner avec une clé non chiffrée sur une clé USB formatée en FAT. Le voici maintenant bien débuggé, partiellement réécrit et enrichi, ainsi que les explications qui vont avec.

Que demande le peuple ? ;-)

Instructions de mise-à-jour :

Si vous utilisiez la précédente version de mon script bootkeyscript, il vous suffit d'installer la nouvelle à la place de la précédente (typiquement dans /usr/local/sbin) et de régénérer votre initramfs avec "update-initramfs -u". C'est tout.

Bon c'est pas tout ça, faut qu'on va aller pique-niquer ;-))

(Rectificatif : Ah non, tiens, le programme de la journée a l'air plutôt réglé sur "Monstre engueulade familiale et hurlements uxoriens"... Soyons zen...)

Notes

[1] (Signature GnuPG, licence GPL)

Another brick in the wall

Petaramesh — Wed, 27 Feb 2008 08:31:00 +0100

L'étau libéral-fasciste se resserre encore un peu plus sur nos moyens d'expression et de communication. C'est à lire ici et là.

Désolé, je ne fais que mettre ici en évidence le lien fourni hier par Patrick, n'ayant pas le temps matériel de pondre un "véritable billet"...

Mais je ne peux que constater avec un immense dégoût que rien n'arrête le train successif des mesures liberticides adoptées les unes après les autres malgré les vives protestations de ceux qui comprennent de quoi il s'agit vraiment, et dans la totale indifférence du plus grand nombre. LSI, LSQ, série sans fin de "lois antiterroristes", DADVSI, "conservation des données de connexion", biométrie à tous les étages, STIC, FNAEG, "Rétention" arbitraire sine die après la "détention"... Toutes mesures votées au prétexte de bien grands crimes qui finissent rapidement appliquées aux plus petites vétilles, comme les prélèvements génétiques effectués sur un manifestant ou un d'jeunz qui a tagué un mur... ou un prof qui a giflé un élève. Étonnant que Bayrou n'ait pas eu droit à son petit prélèvement lors de sa fameuse baffe, ou pourquoi pas Sarkozy fiché au STIC pour insulte publique ?

En l'espace de quelques années, les gouvernements successifs de ce pays se sont dotés d'un arsenal sans précédent de mesures de surveillance et de contrôle de la population au motif que nous sommes tous des "terroristes" ou des "pirates" en puissance.

Et ne nous y trompons pas, nous le sommes tous. L'ennemi, c'est le peuple. Et le gouvernement a acquis un arsenal lui permettant de réprimer n'importe lequel d'entre-nous à tel ou tel prétexte de manière arbitraire le jour où ça lui pètera.
Surveillé au microscope, tout le monde est délinquant...

En profiterai-je pour rappeler la nécessité brûlante pour chacun de prendre lui-même les contre-mesures nécessaires pour protéger sa vie privée autant que faire se peut, à commencer bien sûr par le chiffrement de son courrier électronique...

LFD: Mise à jour

Petaramesh — Fri, 18 Jan 2008 14:19:00 +0100

Voici une mise-à-jour de mon script "LUKSfile for dummies".

Cette nouvelle version permet désormais (optionnellement) la création et le montage de containers chiffrés LUKS intérieurement formatés en FAT16 ou FAT32, les rendant ainsi utilisables sous Windows grâce au logiciel FreeOTFE pour Windows.

On peut ainsi créer des containers chiffrés sur support amovible (clé USB, etc.) qui pourront être utilisés dans les deux environnement GNU/Linux ou Windows.

N.B.: Créer des containers chiffrés formatés en FAT est déconseillé si ce n'est pas pour les partager entre les deux environnements. En effet :

Il est impossible d'effectuer un fsck sur un container formaté en FAT, rendant toute réparation délicate en cas d'endommagement du filesystem.
FAT est intrinsèquement beaucoup plus fragile qu'ext3 employé par défaut.
Un filesystem en FAT ne gère pas les droits Un*x.

Une clé de contact pour votre portable chiffré

Petaramesh — Thu, 29 Nov 2007 16:44:00 +0100

Article mis à jour le 22 juillet 2008

Dans mon précédent article, je vous ai expliqué comment chiffrer intégralement le disque dur de votre portable sous Linux, rendant l'ensemble des données et programmes qu'il contient absolument indéchiffrables et inaccessibles pour qui ne connaît pas la phrase secrète nécessaire à son déchiffrement.

Nous allons aujourd'hui nous intéresser à une autre méthode de démarrage d'un tel portable : Celle qui consiste à utiliser une clé de déchiffrement stockée sur un support externe, qui jouera alors le rôle de "clé de contact" de la machine : Si ce support externe est inséré, le portable pourra démarrer ; s'il est absent, le portable sera inutilisable.

Nous verrons qu'il est également possible d'utiliser ce qu'on appelle "dual form authentication", une authentification forte basée à la fois sur quelque chose que vous avez, et quelque chose que vous savez : Un support externe, que vous avez, plus un mot de passe nécessaire à son utilisation. Si l'un des deux manque, point d'accès. C'est d'ailleurs ce que vous faites, comme monsieur Jourdain, à chaque fois que vous payez avec une carte bancaire.

(Short english summary at end)

L'un des avantages à avoir chiffré tout son disque avec LUKS, c'est que ce système permet de modifier après coup la ou les phrases secrètes ou clés qui le verrouillent. On peut donc assez aisément : ^[1]

Installer plusieurs phrases secrètes différentes permettant de déverrouiller la machine, ce qui est utile si la machine a plusieurs utilisateurs légitimes : ainsi, aucun n'a besoin de connaître la phrase secrète de l'autre. Chacun la sienne !
Ajouter une clé de déchiffrement qui ne sera pas une phrase secrète, mais un fichier hébergé sur un stockage externe (qui peut lui-même être chiffré, ce qui permet d'obtenir la "dual form authentication", ou authentification à double critère).
Supprimer une phrase ou clé existante si l'on ne souhaite plus utiliser l'une des méthodes, si l'un des utilisateurs ne doit plus avoir accès à la machine ou si une phrase ou clé a été compromise, etc.

La méthode hybride permet également de verrouiller le système avec une phrase secrète longue et complexe - donc fastidieuse à taper - et alternativement avec un support externe contenant une clé qui peut être protégée par un mot de passe plus simple, voire pas de mot de passe du tout, en fonction des besoins de sécurité que l'on aura.

En terme de support externe, nous pourrons envisager l'usage d'une clé "flash drive" USB,^[2] ou d'une carte mémoire type SD, etc, pour peu que la machine considérée soit équipée d'un lecteur adéquat.

En partant du principe que nous avons déjà un système entièrement chiffré sur la base de mon précédent article, la mise en oeuvre d'une clé sur support externe - avec ou sans double authentification - va être relativement simple : Je fournis ici un "bootkeyscript"^[3] qui fait tout le boulot.

En premier lieu, procurons-nous évidemment un support externe utilisable sur notre machine, et que nous utiliserons. Nous pouvons le partitionner et le formater de la manière de notre choix, le script "bootkeyscript" détectera automatiquement le système de fichiers utilisé.

Si nous voulons utiliser une clé "simple" sur support externe, non protégée elle-même par mot de passe, nous pouvons nous contenter de mettre celle-ci dans une partition FAT existante de n'importe quel support externe, que nous pourrons également utiliser "comme d'habitude" pour y stocker tous documents et fichiers de notre choix, en prenant simplement grand soin de ne jamais effacer par mégarde la clé de notre système !

Si nous voulons chiffrer la clé elle-même, nous créerons sur le support externe une petite partition que nous chiffrerons avec LUKS avant d'y créer un filesystem ext2 sur lequel nous stockerons enfin la clé.
Ceux qui ne désirent pas cette "double protection" peuvent sauter l'étape de création d'une partition chiffrée sur le support externe.

Création d'une partition chiffrée sur le support externe

Nous utiliserons donc un outil de partitionnement (fdisk, gparted, etc...) pour créer sur le support amovible une petite partition (typiquement 10 Mo) de type "Linux" (83), non formatée. Pour la suite de cet article, nous considérerons la partition créée, et située sur /dev/sdb2. Adaptez bien évidemment les instructions qui suivent à l'emplacement de votre propre partition, sur votre propre périphérique, au risque de détruire irrémédiablement des données sur votre système.

Commençons par remplir notre partition de clés de données aléatoires, selon la méthode habituelle :

dd if=/dev/urandom of=/dev/sdb2 bs=1M

Compte tenu de sa taille modeste, ça ne devrait prendre que quelques secondes.

Faisons ensuite de cette partition un volume chiffré LUKS :

cryptsetup luksFormat /dev/sdb2

Après un avertissement auquel il nous faut répondre "YES", il nous sera demandé de taper deux fois la phrase secrète ou mot de passe que nous utiliserons pour protéger nos clés. Rappelons-nous que nous devrons le taper à chaque boot, et que cela vient en supplément de la possession matérielle du support. À moins d'être paranoïaque, nous pouvons donc nous contenter d'un mot de passe relativement court et facile à taper - mais de préférence, pas à deviner ;-)
Une fois le volume chiffré créé, nous devons l'activer :

cryptsetup luksOpen /dev/sdb2 ext_keys

Après avoir tapé le mot de passe, si nous tapons "ls -l /dev/mapper", nous devrions voir y apparaître un périphérique nommé "ext_keys", qui correspond au volume chiffré "/dev/sdb2" actuellement ouvert.

Il nous faut maintenant "formater" cette partition pour y créer un filesystem ext2 :

mke2fs -m 0 -L ext_keys /dev/mapper/ext_keys

Génération d'un fichier-clé de 256 octets aléatoires

Nous allons maintenant monter le volume externe de manière à pouvoir y créer un fichier-clé. Commençons par créer le répertoire qui servira de point de montage :

mkdir /mnt/ext_keys

Puis :

Si nous n'avons pas chiffré le volume, nous utilisons directement la partition de l'unité externe :
- mount -t vfat -o defaults /dev/sdb2 /mnt/ext_keys
Si nous avons chiffré le volume, nous montons sa version ouverte depuis /dev/mapper :
- mount -t ext2 -o noatime /dev/mapper/ext_keys /mnt/ext_keys

Nous n'avons plus qu'à générer un fichier de 256 octets aléatoires que nous nommerons .bootkey (par exemple).

N.B.: Veillez bien à utiliser ici /dev/random et non pas /dev/urandom :

dd if=/dev/random of=/mnt/ext_keys/.bootkey

...à la suite de quoi un "ls -la /mnt/ext_keys/" devrait bien nous montrer la présence de notre fichier-clé aléatoire de 256 octets.

=> Un support externe peut être endommagé ou perdu ! Une mémoire flash n'est pas infaillible ! A ce stade, je vous conseille vivement de faire une copie de votre fichier-clé sur un ou plusieurs autres supports !

Maintenant que notre fichier est généré (et sauvegardé), nous pouvons démonter l'unité externe :

umount /mnt/ext_keys
sync

et, si nous avions utilisé un volume chiffré, nous pouvons le désactiver :

cryptsetup luksClose ext_keys

Première regénération de l'initramfs

Pour pouvoir accéder à notre unité externe lors du boot, nous devrons nous assurer que les modules nécessaires (USB ou SD/MMC) sont bien présents sur l'initramfs que nous utilisons.

Les modules à charger dépendent fortement du matériel que vous possédez. Utilisez la commande "lsmod" pour lister les modules actuellement chargés sur votre système, et déterminer ceux qu'il vous faudra inclure dans l'initramfs.

On aura typiquement pour de l'USB :

usbcore
ohci_hcd (ou uhci_hcd selon le matériel)
ehci_hcd
usb_storage
sd_mod

Pour un lecteur SD/MMC :

mmc_core
sdhci
mmc_block

Si vous voulez mettre votre clé sur une partition FAT (sur une clé USB par exemple, il faudra également ajouter :

fat
vfat
nls_cp437
nls_iso8859_1

Mettez alors cette liste de modules, un par ligne, dans le fichier /etc/initramfs-tools/modules. Le mien, pour une utilisation de cartes SD, contient les lignes suivantes :

mmc_core
sdhci
mmc_block
aes_i586
sha256
dm_mod
dm_crypt

Une fois ceci fait, récréons notre initramfs :

update-initramfs -v -u

Insertion de la nouvelle clé dans le container LUKS principal du système

Nous allons maintenant rebooter notre système (antérieurement chiffré), et, quand celui-ci nous demandera notre phrase secrète, nous allons volontairement taper 3 fois de suite un mot de passe invalide, puis attendre. Au bout d'une trentaine de secondes, nous devrions obtenir un message d'erreur indiquant que le root filesystem est indisponible, puis nous retrouver dans un shell minimal (busybox) à l'intérieur de notre initramfs.

(initramfs)

À partir de là, nous ne pouvons pas faire grand-chose, mais nous pouvons en faire assez pour ajouter notre clé au container :

Créons un point de montage "/ext_keys" : mkdir /ext_keys
Montons notre unité externe sous ce point : mount -t vfat -o ro /dev/sdb2 /ext_keys (si nous avions chiffré la partition, nous devons d'abord l'ouvrir avec "cryptsetup luksOpen'' avant de la monter à partir de /dev/mapper exactement comme expliqué plus haut)

Ajoutons maintenant la clé au container chiffré du disque dur (en supposant qu'il s'appelle /dev/sda2) :

cryptsetup luksAddKey /dev/sda2  /ext_keys/.bootkey

Le système nous demandera alors la phrase secrète actuelle du container, avant d'ajouter la clé qui se trouve sur le périphérique externe.

Une fois ceci fait, nous pouvons démonter le volume externe (umount /ext_keys), et si nécessaire refermer le volume chiffré correspondant (cryptsetup luksClose ext_keys).
Puis, nous pouvons rebooter "normalement" :

sync
reboot

=> Lors de ce reboot, nous devons toujours taper la phrase secrète habituelle de notre système, car son initramfs ne sait pas encore utiliser la clé résidant sur le support externe.

Génération d'un initramfs compatible avec la clé sur support externe.

Pour que notre système puisse utiliser la clé que nous avons fabriquée puis installée, il nous faut ajouter dans l'initramfs le script "bootkeyscript" que j'ai écrit et que vous trouverez en attachement.
Ce script est très souple, car il détecte automatiquement si la partition contenant la clé est chiffrée ou non, et en demande le mot de passe le cas échéant. De plus, si l'unité externe n'est pas présente, il vous sera possible de taper une phrase secrète à la main - si toutefois votre système en reconnaît encore une comme valide.

Installation du script "bootkeyscript"

Installez ce script dans un répertoire approprié de votre système (je vous suggère /usr/local/sbin), et rendez-le exécutable avec "chmod 755 /usr/local/sbin/bootkeyscript".

Inclusion de l'utilitaire "stty" dans l'initramfs

Créez un script que vous appellerez "include_stty" dans le répertoire /etc/initramfs-tools/hooks, avec le contenu suivant :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /bin/stty /bin

Rendez ce script exécutable : chmod 744 /etc/initramfs-tools/hooks/include_stty

Inclusion de l'utilitaire "udevsettle" dans l'initramfs

Créez un script que vous appellerez "include_udevsettle" dans le répertoire /etc/initramfs-tools/hooks, avec le contenu suivant :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/udevsettle /sbin

Rendez ce script exécutable : chmod 744 /etc/initramfs-tools/hooks/include_udevsettle

Edition de /etc/crypttab

Editez votre fichier /etc/crypttab : C'est lui qui indiquera au système qu'il faut utiliser le script, et où se trouve la clé. En fonction du périphérique externe que vous utilisez et du nom que vous avez choisi pour votre fichier-clé, la ligne concernant votre LVM chiffrée devra désormais prendre l'aspect suivant :

# <target name> <source device> <key file> <options>
crypt_VG1 /dev/sda2 sdb2:.bootkey   luks,tries=3,lvm=crypt_VG1-LV_ROOTFS,keyscript=/usr/local/sbin/bootkeyscript

À noter : l'emplacement du "key file" se note ici sous la forme partition/fichier (avec des sous-répertoires si vous le souhaitez, mais sans "/" de début), sans indiquer "/dev/..." ni le point de montage, qui sont automatiques.
La partition peut être définie sous l'une des syntaxes suivantes :

sdb1:nom_du_fichier_clé
LABEL=label_du_filesystem:nom_du_fichier_clé
UUID=UUID_du_filesystem:nom_du_fichier_clé

Les deux dernières formes permettant de définir le filesystem par son label ou son UUID, indépendamment du périphérique amovible dans lequel ce système de fichiers pourra être trouvé.
Si le filesystem est chiffré LUKS, on pourra le définir par l'UUID du container LUKS, mais pas par le LABEL du filesystem (invisible tant que le container chiffré n'a pas été ouvert).

Ne vous trompez pas en modifiant ce fichier ! Par rapport à votre installation antérieure, il vous faut seulement :

Modifier "key file" de "none" à l'emplacement de votre fichier-clé ;
Ajouter à la fin des options "keyscript=/usr/local/sbin/bootkeyscript"

Le reste ne change pas par rapport à précédemment.

Nous avons presque terminé.

Génération de l'initramfs final :

update-initramfs -v -u

...Et il ne nous reste plus qu'à rebooter proprement.

- Si le périphérique contenant la clé est présent, la machine bootera automatiquement (elle demandera le mot de passe du périphérique-clé automatiquement, uniquement ci celui-ci a été créé ainsi).

- Si le périphérique contenant la clé est absent, vous obtiendrez (et c'est intentionnel) uniquement le message d'erreur :

Missing boot device /dev/sdb2!

...mais en réponse à ce messages d'erreur, vous pouvez taper une phrase secrète, s'il en existe une valide pour le container chiffré du disque dur, et le démarage se poursuivra alors normalement.

Vous avez désormais un système chiffré capable d'être "trimodal" : Il peut démarrer soit avec une phrase secrète, soit avec une clé externe non protégée, soit avec une clé externe protégée, vous offrant ainsi une sécurité extrême.

Si les choses ne fonctionnent pas comme désiré, vous pouvez passer le script en mode "debug" en ajoutant "cryptdebug" à la ligne de paramètres de démarrage de votre noyau. Le script affichera alors des messages indiquant sa progression et d'éventuels problèmes.

Une fois que vous serez certain que votre clé externe permet effectivement le démarrage du système, et que vous en avez fait une copie de secours (ailleurs que sur le portable qu'elle protège ;-) vous pourrez, si vous le souhaitez, supprimer complètement la phrase secrète antérieure de votre disque dur chiffré, en utilisant "cryptsetup luksDelKey (voir man cryptsetup), après avoir booté dans l'initrd'' comme expliqué plus haut.

Il ne vous reste plus qu'à penser à ne pas laisser votre clé de contact en permanence sur votre machine : Aussitôt que la machine a démarré, vous pouvez la retirer - et donc utiliser votre lecteur de carte ou prise USB pour y connecter, comme d'habitude, tout autre périphérique de votre choix.

Vous pouvez également vous référer avec fruit au Two Form Factor Authentication and LUKS Whole Disk Encryption with Feisty Fawn HowTo, notez cependant que le script "maison" que je vous fournis ici n'en provient pas : J'ai la faiblesse de penser que mon script est beaucoup plus puissant, et il a l'avantage de ne nécessiter aucune modification des scripts standard du système.

Short english summary :

In this article, I propose a "bootkeyscript" that allows easy use of dual form factor authentication on a fully encrypted LVM Ubuntu (7.10 Gutsy Gibbon) Linux installation. (See one of these excellent HowTos for installing Ubuntu on a fully-encrypted LVM base : "EncryptedFilesystemLVMHowto", "FeistyLUKSTwoFormFactor")

The script that I propose here has some advantages over existing scripts :

Doesn't need any change or patch to Ubuntu Gutsy existing scripts, with which it integrates well, making future packages upgrads easy ;
Automatically allows in a smart way any combination of the following authentication methods :
- Single form-factor authentication, using an unencrypted keyfile on an external removable device ;
- Dual-form factor authentication, using a keyfile residing on a LUKS-encrypted partition on an external device ;
- Possible automatic fallback to typing a passphrase if keyfile external device is missing (with a purposely obscure Missing boot device! error message).

Short installation instructions :

Create a fully (passphrase-controlled) LVM encrypted system as usual, possibly following one of the existing HowTos. Do not change anything in the existing Ubuntu encryption scripts.
Create a random keyfile. Install it on an external device partition, either itself LUKS-encrypted with a passphrase (for 2 form-factor auth) or unencrypted (1 form-factor, with key device, without passphrase).
Install the key to the main system LUKS container (following usual instructions).
List all the modules you will need to access your key device and its filesystem, in the /etc/initramfs-tools/modules file
Put such an executable script (mode 744) into /etc/initramfs-tools/hooks, let's call it "include_stty" :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /bin/stty /bin

(This will include "stty" into the initramfs, to avoid echoing typed passphrase if not using bootsplash. Using bootsplash wouldn't actually need this)

Create an include_udevsettle script the same way :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/udevsettle /sbin

Install my "bootkeyscript" script wherever you like on your system (I suggest /usr/local/sbin), mode 755.
Update /etc/crypttab with the columns :
- Key : device/keyfilename i.e.:
  - sdb1:mysystemkey
  - or mmcblk0p2:somedir/somekeyfile
  - or LABEL=fs_label:somekeyfile
  - or UUID=fs_or_LUKS_container_uuid:somekeyfile
  - (Syntax is devicepartition:filepath without leading "/")
- Options : Add "keyscript=/usr/local/sbin/bootkeyscript"
Regenerate initramfs (update-initrafms -u)
Reboot, enjoy.

Example /etc/crypttab entry for encrypted root filesystem :

# <target name> <source device> <key file> <options>
enc_VG1 /dev/sda2 UUID=12345678-90ab-cdef-0123-4567890abc:rootkey.bin luks,tries=1,lvm=VG1-ROOTFS,keyscript=/usr/local/sbin/bootkeyscript

Changelog

2008/07/21: bootkeyscript V. 1.6:

Now the key partition can be defined in /etc/crypttab in any of the forms :
- sdb1/filename
- sdb1:filename
- LABEL=filesystem_label:filename
- UUID=filesystem_UUID:filename

2008/05/10: bootkeyscript V. 1.5:

Much debugged and rewritten version of the script.
Works much better than previously for keys on USB flash disks.
Includes a "debug" mode that you can set by adding "cryptdebug" to the kernel command line.
This article completed with some missing infomation.
Compatible with Ubuntu 8.04 Hardy or 7.10 Gutsy

Help Google : Ubuntu Linux 7.10 Gutsy Gibbon LUKS whole disk encryption external device keys, two form factor authentication, how to howto

Notes

[1] Les possibilités de ce système sont immenses. On peut par exemple imaginer, pour un serveur - qui doit être capable de booter sans intervention humaine - de stocker une clé sur une machine distante, et de l'obtenir via Internet, la machine distante étant configurée pour ne fournir cette clé qu'à une adresse IP précise. Le serveur sera ainsi capable de booter tout seul dans son "environnement habituel", mais si jamais il est volé, il deviendra inutilisable en dehors de son adresse IP habituelle, et il sera possible de supprimer la clé de la machine distante sur laquelle elle est stockée. Un tel setup est toutefois extrêmement complexe et va bien au-delà des objectifs de cet article.

[2] L'avantage d'une clé USB est qu'elle peut être bootable, alors qu'une SD-card ne le sera pas - parce que le BIOS du système ne le prévoit généralement pas. Si on utilise une clé USB, on peut même envisager de mettre dessus le "/boot" non chiffré du système (moins de 100 Mo), ainsi que le bootloader grub, ne laissant sur le disque dur qu'un container totalement chiffré et non bootable contenant tout le reste du système. Ce n'est pas particulièrement compliqué à faire, mais c'est là encore en dehors du sujet de cet article.

[3] Évidemment sous licence GNU GPL.

Ubuntu : Chiffrement intégral du disque dur d'un portable

Petaramesh — Wed, 21 Nov 2007 00:43:00 +0100

Je continue à faire mumuse avec le chiffrement sous Ubuntu, et je viens de parvenir au chiffrement intégral du disque dur de mon portable (à /boot près).

Eh oui, un portable, ça se perd, ça se vole... Si on veut à la fois que nos données personnelles ne risquent jamais de traîner toutes nues dans la nature, et cerise sur le gâtal, que la machine soit parfaitement inutilisable pour l'éventuel voleur, le chiffrement intégral du disque dur est le must. Mais ce n'est pas forcément simple !

Quelques explications pour montrer le chemin à qui n'a pas peur de s'y risquer. Attention, la manip n'est pas sans danger pas plus qu'elle n'est pour les débutants ! Il y a mille manières de se retrouver avec une machine non-bootable et toutes ses données perdues !

J'en décris ici seulement l'idée, les grandes lignes. Des points de détail peuvent manquer, alors encore une fois, attention à vos données ! You've been warned !

Je pars d'un portable comportant une installation quasi-standard d'Ubuntu 7.10 Gutsy Gibbon, avec cependant un swap chiffré selon la méthode expliquée dans mon précédent article, et également un /tmp + /var/tmp chiffré selon la méthode décrite dans un article que je n'ai pas encore écrit.

Le jeu consiste à chiffrer l'ensemble des filesystems sur la base d'une LVM, sans bien sûr rien perdre de mon installation, ni devoir réinstaller à blanc. Simplement en déplaçant l'installation sur un disque externe avant de la remettre sur le portable dont le filesystem aura été préalablement chiffré.

J'ai commencé par prendre un disque dur externe USB que j'ai entièrement effacé et gavé de données aléatoires avec un beau

nice dd if=/dev/urandom of=/dev/sdb bs=1M
(ça dure des heures...)

À la suite de quoi, j'ai partitionné le disque externe en 3 bouts :

Un petit /boot de 100 Mo en ext3
Une grosse partition non formatée de type 83 (Linux) de "tout le disque moins 2 Go"
Une partition non formatée de type 82 (Linux swap)

Ceci fait, j'ai monté la première partition et y ai copié mon /boot d'un coup de rsync -ax

Ensuite de quoi, j'ai utilisé cryptsetup luksFormat puis mke2fs pour faire de la deuxième partition du disque externe une partition chiffrée LUKS, que j'ai montée (sous un point de montage temporaire /mnt/ext2).

Après quoi, j'ai recopié l'ensemble du système du portable sur cette partition chiffrée du disque externe d'un nouveau coup de rsync (les différentes partitions séparées du disque interne rassemblées en une seule dans le disque externe).

J'obtiens donc une copie de sauvegade complète et chiffrée (sauf /boot) de mon portable sur le disque USB externe.

Vient le plus délicat : Rendre l'installation chiffrée bootable et utilisable directement depuis le disque externe,

Monter le /boot du disque externe sous la structure chiffrée : mount -t ext3 -o noatime /dev/sdb1 /mnt/ext2/boot
Créer un /dev/null bidon sous la nouvelle installation : mknod /mnt/ext2/dev/null c 1 3
Monter le /dev sous l'installation externe, de manière "fantôme" : mount --bind /dev /mnt/ext2/dev
Se chrooter dans l'installation : chroot /mnt/ext2
Une fois là, monter /proc : mount -t proc proc /proc
...et /sys : mount -t sysfs sysfs /sys
Adapter /etc/crypttab à la structure du disque externe : Créer une entrée pour le swap chiffré sur le disque externe, et une autre pour la "racine" chiffrée :
- cswap /dev/sdb3 /dev/urandom size=128,swap
- crootfs /dev/sdb2 none luks, check
Adapter /etc/fstab de même à la structure des points de montage : un /boot non chiffré, une racine (/dev/mapper/crootfs), un swap chiffré comme dans mon précédent article
Se rendre ensuite dans /boot/grub et modifier menu.lst : Y modifier le "root=" pour pointer sur le root filesystem chiffré.
Installer grub sur le MBR du disque externe de manière à le rendre bootable.

A ce stade, il suffit normalement de régénérer l'initramfs avec

update-initramfs -v -u

...pour avoir fini le boulot.

Je me suis cependant aperçu qu'un des scripts de démarrage d'Ubuntu était incorrect et n'autorisait pas le boot sur un disque externe USB chiffré, trop lent à être "vu" par le noyau au démarrage. J'ai donc écrit un patch pour ce script (/usr/share/initramfs-tools/scripts/local-top/cryptroot), patch que je joint en annexe et que je vous conseille d'installer (il ne peut pas faire de mal ;-) avant de lancer "@@update-initramfs -v -u"

Ceci fait, il ne reste plus qu'à...

cd /
umount /proc
umount /sys
exit (nous sort du chroot)
umount /mnt/ext2/dev
umount /mnt/ext2/boot
sync
umount /mnt/ext2
sync
Fermer le volume chiffré LUKS (cryptsetup luksClose, etc...) du disque externe

...Et on peut rebooter proprement.

Sélectionner par le BIOS le démarrage depuis le disque USB, on doit alors avoir un beau grub qui propose le démarrage sur le disque externe chiffré.

Le mot de passe de montage de la partition LUKS sera demandé automatiquement grâce aux scripts prévus à cet effet. Elle est pas belle, la vie ?

À ce stade, on a créé une installation de Linux entièrement chiffrée sur un disque externe bootable, que l'on devrait pouvoir d'ailleurs utiliser pour booter un peu n'importe quelle machine et y retrouver son environnement Ubuntu complet ! (modulo les possibles problèmes causés par des hardwares différents, notamment carte graphique...)

Une fois que l'on a vérifié que notre installation externe est complète et marche parfaitement, et qu'on peut donc utiliser le portable sans son disque interne, on va pouvoir totalement effacer celui-ci, y préparer notre installation chiffrée un peu de la même manière que pour le disque externe, et redéménager dans l'autre sens.

Commençons par effacer totalement le disque dur du portable avec :

nice dd if=/dev/urandom of=/dev/sda bs=1M
(Comme précédemment, ça durera des heures...)

Pour l'organisation du disque proprement dit, chiffré là encore à l'exception de /boot, je me suis cette fois largement inspiré de l'excellent EncryptedFilesystemLVMHowto, dont je n'ai cependant lu que les points essentiels et que j'ai largement adapté à ma sauce, notamment :

Répartition en plusieurs volumes logiques (root filesystem, /var, /home, etc...)
J'ai conservé un swap et un /tmp chiffrés "selon mon ancienne méthode" sur des partitions séparées en dehors de la LVM, afin de pouvoir les chiffrer avec des clés aléatoires changées automatiquement à chaque boot.

Une fois le filesystem chiffré installé et monté, il reste à recopier tout le système comme précédemment, mais dans l'autre sens, à grands coups de rsync.

Puis de nouveau la partie délicate : Chroot, adaptation de /etc/crypttab, /etc/fstab, /boot/grub/menu.lst, installation de grub dans le MBR du disque, régénération de l'initramfs.

Ceci fait, démonter tous les volumes du disque interne, arrêter la LVM, désactiver sa partition chiffrée, et il n'y a plus qu'à rebooter !

On obtient enfin un portable au filesystem entièrement chiffré, qui demande gentiment la phrase secrète durant le boot, et est totalement inexploitable sans elle. Et ça marche du Feu de Dieu !

Prochaine étape : Comme mon portable comporte un lecteur de carte SD (comme les appareils photos numériques), j'envisage, plutôt que de devoir me peler la phrase secrète à chaque boot, de mettre un fichier-clé sur une telle carte et d'utiliser celle-ci comme "clé de contact" de mon portable : Carte SD insérée, il bootera tout seul, carte SD absente, il ne bootera pas, point. La carte SD tient dans la poche et dans le portefeuille :-)

Des icônes pour LFD

Petaramesh — Sun, 18 Nov 2007 10:45:00 +0100

Si vous utilisez mon script de gestion de container chiffré LUKSfile for dummies avec un bureau KDE, vous aimeriez peut-être bien avoir quelques jolies icônes sur votre bureau pour monter ou démonter votre volume chiffré en un clic, sans avoir besoin d'ouvrir une fenêtre de terminal et d'y taper des commandes à la main...

Rien de plus facile !

Il vous suffit pour cela de créer dans le sous-répertoire Desktop de votre répertoire personnel les fichiers texte suivants, qui créeront chacun une icône. Vous pouvez les nommer différemment si vous le souhaitez, par exemple pour gérer plusieurs containers chiffrés, ou, par la suite, en changer l'icône ou les propriétés avec un clic-droit sus l'icône qui sera créée...

Aux lignes "Exec=", remplacez simplement "mysecrets" par le nom de votre container chiffré.

Pour ouvrir et monter un container chiffré : fichier LFD_Open.Desktop :

[Desktop Entry]
Comment=
Comment[fr]=
Encoding=UTF-8
Exec=/usr/local/bin/lfd mysecrets on
GenericName=Ouvre le dossier LUKS
GenericName[fr]=Ouvre le dossier LUKS
Icon=folder_man
MimeType=
Name=Ouvrir LFD
Name[fr]=Ouvrir LFD
Path=
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
X-DCOP-ServiceType=
X-KDE-SubstituteUID=false
X-KDE-Username=

Pour démonter et fermer un container chiffré : fichier LFD_Close.Desktop

[Desktop Entry]
Comment=
Comment[fr]=
Encoding=UTF-8
Exec=/usr/local/bin/lfd mysecrets off
GenericName=Ferme le dossier LUKS
GenericName[fr]=Ferme le dossier LUKS
Icon=folder_locked
MimeType=
Name=Fermer LFD
Name[fr]=Fermer LFD
Path=
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
X-DCOP-ServiceType=
X-KDE-SubstituteUID=false
X-KDE-Username=

Pour visualiser l'état d'un container chiffré : Fichier LFD_Status.Desktop :

[Desktop Entry]
Comment=
Comment[fr]=
Encoding=UTF-8
Exec=/usr/local/bin/lfd mysecrets status
GenericName=Ferme le dossier LUKS
GenericName[fr]=Ferme le dossier LUKS
Icon=folder_yellow_open
MimeType=
Name=Etat LFD
Name[fr]=Etat LFD
Path=
StartupNotify=true
Terminal=true
TerminalOptions=\s--noclose
Type=Application
X-DCOP-ServiceType=none
X-KDE-SubstituteUID=false
X-KDE-Username=

Elle est pas belle, la vie ?

LUKSfile for dummies

Petaramesh — Tue, 13 Nov 2007 08:31:00 +0100

(English summary at end)

Ou le Container chiffré pour les Nuls.

Nous avons tous sur nos disques durs quelques petits ou gros secrets : Listes de mots de passe, informations de connexion à notre site bancaire, écrits personnels, photos de nos (innombrables) maîtresses en lingerie fine ou sans... ;-)

Toutes sortes de choses que nous n'aimerions pas voir tomber sous des yeux indiscrets si jamais quelqu'un fourre son nez dans nos petites affaires, si notre machine est perdue ou volée, ou si tout bêtement son disque dur est renvoyé un jour en atelier sous garantie.

Le seul véritable moyen de protéger ces données contre toute indiscrétion est de les chiffrer (le terme "crypter" est incorrect).

GNU/Linux possède pour cela une trousse à outil très puissante, dont l'usage est hélas fort complexe et donc le plus souvent réservé aux initiés.
Voici un moyen de chiffrer vos données avec une facilité déconcertante en utilisant un container LUKS.

Un container LUKS est un fichier "ordinaire" (mais chiffré à l'aide d'un algorithme très puissant et très sûr: AES) qui se trouvera dans votre répertoire personnel ou sur un support amovible (clé USB, etc.).

Le contenu de ce fichier sera totalement inexploitable pour qui ne connaît pas la phrase secrète qui en permet le déverrouillage.

Une fois déverrouillé, le container sera monté et apparaîtra sous vos yeux ébahis en tant que sous-répertoire de votre répertoire personnel (ou du support amovible). Ce répertoire pourra contenir toutes sortes de fichiers et de sous-répertoires, limités seulement par la taille que vous aurez choisi d'affecter à votre container lors de sa création. Vous pourrez utiliser n'importe quel logiciel de votre choix pour accéder aux fichiers chiffrés, qui seront automatiquement chiffrés et déchiffrés à la volée tant que le container sera monté.

Une fois démonté, le sous-répertoire (point de montage) apparaîtra vide, et le fichier-container seulement plein de données indéchiffrables d'apparence aléatoire. Il ne sera possible de déterminer ni la taille des données qu'il contient réellement, ni le nombre ou le nom des fichiers ou répertoires qu'il contient, ni aucune information à leur propos.
Si vous avez créé un container de 256 Mo, on verra juste un fichier de 256 Mo de données aléatoires, point.

Pour obtenir ce résultat, j'ai écrit le script bash "lfd" joint à ce billet.^[1] ^[2]

Ce script vous permet d'utiliser trois commandes simples et à la portée du profane : Une pour créer un volume chiffré, une pour le monter, une pour le démonter, et c'est tout.

Pour installer et utiliser ce script, c'est extrêmement simple :

Copiez (comme "root") le fichier "lfd" joint (Annexe "LUKSfile for dummies" ci-dessous) dans votre répertoire /usr/local/bin
Rendez ce script exécutable avec la commande (comme "root") : chmod 755 /usr/local/bin/lfd
Vous pouvez ensuite exécuter le script sous votre profil utilisateur ordinaire (non-root)

Lancez simplement le script avec la commande "lfd", et vous obtiendrez une aide succinte.
"lfd --help" vous apportera une aide détaillée.

Et voilà !

N'hésitez pas à me faire part de vos remarques, suggestions, problèmes ou bugs dans l'utilisation de ce script.

En espérant qu'il vous sera utile :-)

N.B.:

Avant d'écrire des fichiers confidentiels, assurez-vous que votre volume chiffré est monté ! S'il ne l'est pas, vos fichiers seront écrits en clair dans le répertoire vide ordinaire qui sert de point de montage, et ne seront pas protégés !
Quand vous n'avez plus besoin d'accéder à vos fichiers, pensez à fermer les applications qui les utilisent, et à démonter le volume chiffré, sinon les données qu'il contient resteront accessibles (elles deviennent automatiquement inaccessibles si la machine est arrêtée ou rebootée, même violemment).
Pensez que si un fichier a été écrit une seule fois en clair sur votre disque, il en demeure toujours des traces. Rapportez-vous à mon billet sur l'effacement des fichiers rémanents.
Pensez que votre système peut utiliser du swap à tout moment, et que certaines applications peuvent générer des fichiers temporaires qui peuvent, en fonction de l'application, être créés ailleurs que dans votre répertoire chiffré (par exemple dans "/tmp"). Référez-vous à mon article sur le chiffrement du swap, je rédigerai dans quelque temps un billet sur le chiffrement des fichiers temporaires reposant sur le même principe général.

Changelog :

2008/02/05: v. 0.97: Small buxfix for use with 2.6.24 kernel and "sha256_generic" module.
2008/01/18: v. 0.96: Now supports optionally creating and mounting containers with internal FAT16 or FAT32 filesystem, making them usable under MS Windows with FreeOTFE.
2007/11/15: v. 0.94: BUGFIX: Change in 0.93 introduced a possible security issue. Fixed.
2007/11/15: v. 0.93: Compatibility FIX: made compatible with older versions of "losetup" that do not understand the "-a" option.
2007/11/13: v. 0.92: BUGFIX: Added a couple tests to catch inconsistencies created by some user mistakes.
2007/11/13: v. 0.91: COSMETIC: Typo fix in included helptext.
2007/11/13: v. 0.90: First public release.

English summary : "LUKSfile for dummies" (lfd): A shell script that allows creating / mounting / unmounting LUKS encrypted filesystems the easy way from container files, with a simple command and takes care of all the loopback and mounting technicalia. Get the script below, put it into /usr/local/bin, chmod it 755 and run it as a normal non-root user. Designed for Ubuntu (but usable on any other distro), makes extensive use of sudo for performing its operations. Run the script to get help (Script help text in english).

Notes

[1] Je joins également à ce billet la signature GnuPG détachée qui permet de vérifier (optionnellement) l'authenticité de ce script, ainsi que sa licence GPL.

[2] L'identifiant de ma clé GnuPG est 9076E32E et son empreinte : CC1F E3A0 6D39 FAB2 B91C 982E 2FC2 5C1D 9076 E32E. Elle est disponible sur tous les bons serveurs de clés ;-)

Sécurisation d'une Ubuntu: Chiffrement du swap

Petaramesh — Sat, 27 Oct 2007 12:21:00 +0200

Un billet technique, un !

Il existe une palanquée de HowTos expliquant diverses méthodes de chiffrement d'un système de fichiers sous Ubuntu, mais ceux-ci sont généralement complexes et s'adressent à des utilisateurs plutôt expérimentés.

Celui-ci, dont je me suis inspiré pour ce billet, donne à son début de très intéressantes et abordables informations de base sur le principe du chiffrement, je vous y renvoie donc pour de plus amples informations.

Je vais vous indiquer ici une méthode très simple permettant de chiffrer uniquement l'espace de swap, pour commencer...

Un disque dur peut se révéler très indiscret, et un examen "forensic" de celui-ci peut le plus souvent exhumer des fichiers temporaires effacés depuis longtemps, des morceaux de documents dont on penserait "qu'ils n'ont jamais été sauvegardés", des mots de passe...

Protéger un système contre la présence de tels "restes mortels" constitue un projet long et complexe, mais on peut commencer par le plus simple et le plus nécessaire : le swap et les répertoires de fichiers temporaires.

Nous nous intéresserons aujourd'hui au seul swap.

Le swap est une partition spéciale qui est toujours créée automatiquement et séparément des autres lors de l'installation d'une distribution GNU/Linux. Le swap peut être vu comme une extension sur le disque dur de la mémoire vive (RAM) du système, c'est-à-dire que dès que le système manque de mémoire, il copie automatiquement sur le disque dur, dans l'espace de swap, non pas des fichiers, mais des blocs de sa mémoire vive dont "il n'a pas besoin pour l'instant", de manière à libérer de la place en mémoire centrale. Ces éléments copiés sur le swap y demeurent jusqu'à ce qu'ils soient écrasés par d'autres, et on peut y trouver absolument n'importe quoi : Bouts de documents ouverts ou en cours de rédaction, pages web en cours de visite, morceaux de programmes, mots de passe... Leur exploitation est difficile, mais accessible à un spécialiste doté d'outils ad hoc.

Comme Linux optimise en permanence son utilisation de la mémoire, en pratique, dès qu'une machine a été allumée quelques dizaines de minutes, des données inutilisées sont swappées même si le système ne manque pas de mémoire.

Pour éviter la présence rémanente sur son disque dur de telles indiscrétions rémanentes, la plus sûre solution est de chiffrer le swap en utilisant un mot de passe aléatoire généré automatiquement au boot de la machine, et définitivement perdu dès que la machine est éteinte ou rebootée. Ainsi, tout ce qui demeure sur le swap est définitivement inexploitable dès la machine éteinte.

Or, ceci est extrêmement facile à mettre en oeuvre. Voici comment procéder sur une Ubuntu 7.04 Feisty ou 7.10 Gutsy.

=> Dans la suite de ce document, je parle de "console root". Une "console root" est un terminal dans lequel on est passé en mode root (administrateur) en tapant la commande "sudo -s". On peut aussi exécuter chaque commande root à partir d'une console "ordinaire", mais il faut à ce moment-là précéder chaque commande de "sudo" pour l'exécuter en tant que root.

Si l'on a fait "sudo -s", on peut ensuite ressortir en mode "utilisateur ordinaire" en tapant "exit" ou [Ctrl]-D (fin du fichier d'entrée).

Pour chiffrer le swap, donc, la première chose à faire est d'installer le paquetage cryptsetup, soit au moyen de l'outil graphique adéquat, soit en console root par la simple commande :

aptitude install cryptsetup

Une fois ceci fait, il faut s'assurer de la partition de disque sur laquelle se trouve le swap.

ATTENTION : Dans la suite de ce processus, toute erreur ou faute de frappe dans le nom de la partition sur laquelle on travaille provoquera irrémédiablement la destruction des données du disque dur ! Il faut donc vérifier à chaque commande qu'on travaille bien sur la bonne partition, exclusivement celle du swap !

Tapons la commande :

root@totor:/etc# swapon -s
Filename                                Type            Size    Used    Priority
/dev/sda4                               partition       4200884 34072   -1

...Notre partition de swap active est /dev/sda4 (4ème partition principale de notre premier disque dur SATA ou SCSI).

Dans la suite de ce document, à chaque fois que vous verrez /dev/sda4, pensez à le remplacer par votre partition de swap telle que cette commande vous l'aura montrée !

Si vous avez un processeur de classe i586 ou supérieur (c'est-à-dire tout le monde, sauf les possesseurs de très vieilles machines), nous utiliserons le module de chiffrement "aes_i586" (les plus vieux utiliseront "aes" tout court.

Chargeons les modules de noyau dont nous avons besoin pour le chiffrement :

modprobe aes_i586
modprobe dm_mod
modprobe dm_crypt

Désactivons notre partition de swap (fermez auparavant les applications dont vous n'avez pas besoin, de manière à vous assurer que vous ne consommez pas plus de mémoire vive que la mémoire RAM réelle de votre système)

swapoff /dev/sda4

Assurons-nous que le swap n'est plus utilisé :

root@totor:/etc# swapon -s
Filename                                Type            Size    Used    Priority

(On ne doit plus rien voir dans la liste)

Maintenant, nous allons effacer "écraser" complètement le contenu de la partition de swap (si vous écrasez la mauvaise partition, vous êtes mal !)

Si nous avons du temps devant nous (ça peut prendre plusieurs dizaines de minutes), nous remplirons cette partition de données pseudo-aléatoires, pour rendre son contenu présent et futur complètement indiscernable de données aléatoires :

dd if=/dev/urandom of=/dev/sda4 bs=1M

...L'opération se poursuivra jusqu'à donner une "erreur d'entrée-sortie" quand la partition sera pleine.

(Si nous sommes pressés et voulons aller beaucoup plus vite, nous pouvons utiliser "/dev/zero" à la place de "/dev/urandom" pour écraser toute la partition avec des zéros, mais cela donnera une protection d'un peu moins bonne qualité.)

La partition une fois effacée, créons un volume chiffré à partir de celle-ci :

cryptsetup -s 128 -d /dev/urandom create cswap /dev/sda4

(N'utilisez en aucun cas "/dev/zero" ici !)

Si cela a fonctionné, nous devons maintenant voir un péripérique bloc appelé /dev/mapper/cswap :

root@totor:/etc# ls -l /dev/mapper
total 0
crw-rw 1 root root  10, 63 2007-10-27 10:37 control
brw-rw 1 root disk 254, 41 2007-10-27 10:37 cswap

...Et nous pouvons vérifier que cswap est bien une partition chiffrée :

root@totor:/etc# cryptsetup status cswap
/dev/.static/dev/mapper/cswap is active:
cipher:  aes-cbc-plain
keysize: 128 bits
device:  /dev/sda4
offset:  0 sectors
size:    8401790 sectors
mode:    read/write

Créons maintenant un espace de swap sur cette nouvelle partition chiffrée :

mkswap /dev/mapper/cswap

Activons maintenant cet espace de swap :

swapon /dev/mapper/cswap

Vérifions qu'il est bien actif :

root@totor:/etc# swapon -s
Filename                                Type            Size    Used    Priority
/dev/mapper/cswap                       partition       4200884 34272   -1

Et voilà ! Notre swap est désormais chiffré !

Il nous faut maintenant nous assurer que ceci sera fait automatiquement à chaque boot. Nous avons pour cela quelques fichiers de configuration à éditer (toujours en mode root) :

Editons le fichier /etc/modprobe.d/aliases, et ajoutons à la fin de celui-ci une ligne :

alias aes aes_i586

Editons le fichier /etc/modules, et ajoutons vers le début de celui-ci les lignes :

aes_i586
dm_mod
dm_crypt

Editons le fichier /etc/crypttab, comme suit :

# <target name> <source device>         <key file>      <options>
cswap                  /dev/sda4                   /dev/urandom  size=128,swap

Editions le fichier /etc/fstab, cherchons la ligne concernant le swap et qui doit probablement commencer par un long "UUID=blablabla" suivi quelque part de "swap", et être précédé d'une ligne de commentaire indiquant "# /dev/sda4". Modifions cette ligne en supprimant "UUID=blablabla" et en le remplaçant pour donner à la ligne l'aspect suivant :

/dev/mapper/cswap none           swap    sw              0       0

Voilà, nous avons terminé !

Il ne reste plus qu'à redémarrer le système pour s'assurer que ceci a "survécu au reboot" et que le système sait désormais configurer tout seul son swap chiffré à chaque boot. Après le reboot, on vérifiera simplement que...:

root@totor:/etc# swapon -s
Filename                                Type            Size    Used    Priority
/dev/mapper/cswap                       partition       4200884 34272   -1

root@totor:/etc# cryptsetup status cswap
/dev/.static/dev/mapper/cswap is active:
 cipher:  aes-cbc-plain
 keysize: 128 bits
 device:  /dev/.static/dev/mapper/swap
 offset:  0 sectors
 size:    8401790 sectors
 mode:    read/write

Voilà, notre "swap" est désormais définitivement chiffré. Dans un prochain article, nous verrons comment faire la même chose, sur le même principe, pour la partition de fichiers temporaires "/tmp".

L'art de faire chier le monde

Petaramesh — Tue, 09 Jan 2007 08:16:00 +0100

Plus de 1200 spams de commentaires reçus en 8 heures sur ce blog, entre cette nuit minuit et ce matin 8 heures environ... Presque tous bloqués par l'antispam Akismet, seuls 7 ou 8 sur 1200+ sont passés à travers.

Mais la seule vidange de ma file de spams bloqués devient une véritable corvée. Vraiment, je n'arriverai jamais à comprendre que certains puissent déployer autant d'efforts pour faire chier le monde...

Je dois prévenir mes amis lecteurs : Si jamais l'un de vos commentaires atterrit en "file de modération" (c'est malheureusement le cas quasi-systématique pour deux d'entre-vous dont les adresses IP figurent sur des listes noires utilisées par l'anti-spam) prévenez-moi par mail via la page contact, parce que quand j'ai 1200 spams dans la file de modération, je vide tout, hein, je ne lis pas... Donc s'il y a des commentaires légitimes noyés dans la masse de merdes, ils passent hélas à la trappe avec... Je ne peux pas lire 1200 spams 4 fois par jour :-(

7000 commentaires légitimes sur ce blog en un peu moins d'un an. Mais 1200 merdes en 8 heures...

Vraiment, je suis contre la peine de mort. Sauf pour les spammeurs.