Voici une base de système qui nécessite deux clés USB pour pouvoir fonctionner. Si l’une manque, le système ne peut démarrer et, plus important encore, les données sont indéchiffrables.

Le schéma de principe :

L’exemple est réalisé à partir de Debian Linux 7.0, mais ça n’a pas de raison de ne pas fonctionner avec d’autres distributions. Ça marche aussi avec Ubuntu Linux par exemple. Il faut obligatoirement que cryptsetup soit disponible sur la distri. Il faut de préférence que l’on puisse mettre en place le chiffrement dès l’installation du système. Il faut aussi de préférence que le système soit installable directement sur clé USB et sur une partition chiffrée. Si ces deux dernières conditions ne sont pas remplies, l’exercice est réalisable mais il est beaucoup plus complexe à mettre en place.

Les partitions

Les partitions en rouge sont en clair. Tout ce qui est enregistré dessus est lisible et/ou modifiable par autrui.
La seule partition rouge vraiment utile est celle qui contient le /boot avec notamment le noyau Linux (kernel) à l’intérieur, en clair. Les deux partitions en fat32 permettent de stocker des données en clair, et elles sont surtout lisible par beaucoup de systèmes d’exploitations. Elles sont surtout là comme mesure de déception, donner à un intrus l’impression qu’il a accès au contenu de la clé sans lui montrer que l’on cache le reste. C’est le premier niveau de déception, et aussi le plus facile à détecter.

Les partitions en bleu sont intégralement chiffrées. Tout ce qui est à l’intérieur n’est ni lisible, ni modifiable. On ne peut pas non plus savoir ce qu’il y a dedans ou même estimer la quantité de données.
Il est important qu’elles soient au moins deux et que la racine / ne soit pas sur la clé qui contient le /boot. Ainsi plusieurs combinaisons sont possibles comme laisser le /home avec la racine et créer un /data par exemple. On peut aussi mettre les deux partitions chiffrées sur la même clé USB et laisser le /boot sur une clé indépendante. On peut enfin juste garder la racine / comme seule partition chiffrée, on verra cela plus bas.

Le principe

Le but est ici de montrer que l’on peut combiner les disques chiffrés de différentes manières. Dans cet exemple, les données sont sur une clé USB, le système d’exploitation est sur l’autre clé USB, le tout démarre sans demander de mot de passe. La clé USB contenant le système d’exploitation est physiquement (switch) verrouillée en lecteur seule pour le protéger de toute modification logique. Et bien sûr, le système peut tout à fait être ‘user-friendly’ avec une belle interface graphique!

La séparation du /home, et donc des données qu’il contient par rapport au système, permet au système d’exploitation d’être disposé sur une clé USB verrouillée physiquement en lecture seule. Le système est plus résistant à une attaque virale qui essayerait de modifier le système pour le contaminer ou pour s’installer. Cette protection n’est pas infaillible puisqu’il faut pouvoir aussi maintenir à jour le système d’exploitation et ses nombreux programmes pour qu’il résiste aux nouvelles attaques.
Dans ce cas, évidement, la partition en fat32 n’a pas vraiment d’intérêt.

Si cette protection ne vous intéresse pas, il n’est dans ce cas pas nécessaire de séparer la partition /home de la partition racine /.

Chaque partition chiffrée a sa clé de déchiffrement qui se trouve stockée sur l’autre clé USB. Ainsi, bien que l’une des clés de déchiffrement soit en clair, la perte ou le vol d’une des clés USB ne permet d’accéder ni au système d’exploitation ni aux données.

Mise en pratique

1/ Installation du système d’exploitation

Sur la station qui sert à l’installation, débrancher physiquement le disque dur interne le temps de l’installation. Brancher les deux clés USB et insérer le CD-ROM d’installation de Debian Linux. Faire une installation en mode texte (par défaut).

L’installation se passe normalement à l’exception de la partie concernant le partitionnement. Il faut créer d’abord :

• sda1 fat32 none
• sda2 ext4 /boot
• sda3 chiffrement
• sdb1 fat32 none
• sdb2 chiffrement

Pour la partition sda2, lui donner comme label ‘boot‘, c’est plus simple pour la suite.
Puis aller dans la partie gestion des disques chiffrés. Créer les partitions chiffrées sur sda3 et sdb2, et le configurer comme cela :

• sda3_crypt ext4 /home
• sdb2_crypt volume lvm

Chaque partition chiffrée nécessite son mot de passe propre, mais ce peut être le même. Choisir un mot de passe assez solide le temps de terminer l’installation et le paramétrage des mots de passes définitifs dans des fichiers.
Puis aller dans la partie gestion des volumes lvm. Créer un volume et des volumes logiques la racine et le swap (et plus encore si besoin) :

• vlroot ext4 /
• vlswap swap

L’installation peut continuer normalement…

ATTENTION!!! Il est important, parce que nous travaillons sur des supports de stockage USB, de mettre des mots de passes forts sur les partitions chiffrées. Et ceci même si nous allons les supprimer dans quelques minutes. Pourquoi? Tout simplement parce que lors de la suppression du mot de passe, et donc de l’écriture sur la clé, on n’est pas en mesure de savoir si l’électronique de la clé USB ne va pas permuter le ‘secteur‘ contenant le mot de passe pour écrire la modification sur un autre secteur. Ce mécanisme est à l’origine destiné à économiser le nombre d’écritures sur un secteur en particulier et de répartir les écritures sur l’ensemble des secteurs. Tout ceci à l’origine non pas pour voler des clés de chiffrement mais pour allonger la durée de vie des supports amovibles à mémoires en technologie FLASH. Le problème est le même avec un SSD.

2/ Premier démarrage

Une fois le tout installé et la machine redémarrée, se reconnecter en root. Toutes les partitions doivent avoir été montées normalement, chacune ayant nécessité la saisie d’un mot de passe au démarrage.

3/ Génération des mots de passes

Générer deux clés de chiffrement de 128 caractères en hexadécimal (ou plus), une pour chaque partition chiffrée :
# openssl rand -hex 64 > /boot/boot.pwd
# openssl rand -hex 64 > /boot.pwd
# chmod 400 /boot/boot.pwd /boot.pwd
L’avantage des caractères en hexadécimal, c’est qu’ils peuvent êtres recopiés à la main facilement. L’inconvénient, c’est aussi qu’ils peuvent êtres recopiés à la main facilement (arrggg…). On peut tout aussi bien générer des clés non-ASCII (binaires), ça marche aussi. A noter que d’un point de vue solidité du mot de passe, c’est à dire son entropie dans son espace de caractères, c’est exactement pareil d’avoir 128 caractères hexadécimaux ou 64 caractères binaires.

4/ Ajout des mots de passes aux partitions chiffrées

Ajouter les nouvelles clés de chiffrement à leurs partitions chiffrées respectives :
# cryptsetup luksAddKey /dev/sdb2 /boot/boot.pwd
# cryptsetup luksAddKey /dev/sda3 /boot.pwd

A chaque fois, un mot de passe est demandé. C’est le mot de passe créé à l’installation pour la partition concernée.

5/ Ajout des fichiers mots de passes à la configuration

Il faut maintenant dire au système, au démarrage, d’utiliser ces deux clés. Pour cela on modifie le fichier /etc/crypttab. On vérifie que le label de la partition /boot est bien pris en compte :
# ls -l /dev/disk/by-label/

lrwxrwxrwx 1 root root 10 nov.   9 10:50 boot -> ../../sda2


Si il manque, c’est que le label a été oublié lors de l’installation. Le seul vraiment utile c’est boot, on ne se servira pas des autres ici. On doit dans ce cas utiliser /dev/disk/by-uuid/78a4832d-a421-4dbd-8503-66106ef27129 au lieu de /dev/disk/by-label/boot (l’UUID correspond à mon disque à moi). C’est moins facile.

Le fichier /etc/crypttab ressemble à ceci (2 lignes) :

sdb2_crypt UUID=d3c7791c-1989-47fe-bf31-e8996207dadf none luks
sda3_crypt UUID=598cf9d7-a9f3-4728-87e2-a0c90369d542 none luks

Les valeurs des UUID sont ceux de mes essais, ils sont donc différents à chaque installation, à adapter donc. Modifier le fichier comme cela (2 lignes) :

sdb2_crypt UUID=d3c7791c-1989-47fe-bf31-e8996207dadf /dev/disk/by-label/boot:boot.pwd luks,keyscript=/lib/cryptsetup/scripts/passdev
sda3_crypt UUID=598cf9d7-a9f3-4728-87e2-a0c90369d542 /boot.pwd luks

6/ Modification du démarrage

Pour que les fichiers mots de passes soient pris en compte au démarrage, il faut régénérer le fichier /boot/initrd.img-3.2.0-4-686-pae (ou équivalent) :
# update-initramfs -u
Évidement, si le fichier /etc/crypttab est présent dans l’image initrd, ce n’est pas le cas des fichiers de clés de déchiffrement!

Redémarrer le système pour voir si tout se passe bien…

Si tout s’est bien passé, aucun mot de passe ne devrait être demandé cette fois-ci.
Si ça se passe mal, il y a toujours le mode rescue du CD-ROM d’installation de Debian…

7/ Suppression des mots de passes d’installation

Si tout se passe bien au démarrage et que les deux partitions chiffrées sont bien montées, on peut retirer les mots de passes d’installation. Ce n’est pas une obligation. lancer (2 lignes) :
# cryptsetup luksKillSlot /dev/sdb3 0 --keyfile /boot.pwd
# cryptsetup luksKillSlot /dev/sda2 0 --keyfile /boot/boot.pwd


Pour vérifier le nombre de clés, utiliser la commande :
# cryptsetup luksDump /dev/sdb3
Le Key Slot 0 doit maintenant être marqué désactivé.

8/ Déplacement du bootloader

Par défaut, le bootloader devrait déjà être sur la clé USB contenant la partition /boot. Si ce n’est pas le cas, il faut le déplacer puis l’effacer de l’ancienne clé (3 lignes) :
# grub-install /dev/sda
# update-grub
# dd if=/dev/zero of=/dev/sdb bs=446 count=1
Cette dernière ligne efface le chargeur de la deuxième clé USB.

Le bon positionnement de GRUB peut être vérifié :
# debconf-show grub-pc

Améliorations

Si on ne sépare pas /home mais plutôt /data par exemple sur la deuxième partition chiffrée, l’environnement utilisateur peut ainsi être verrouillé au même titre que le système d’exploitation.

On peut essayer de demander un mot de passe en plus au démarrage. Plutôt que de simplement laisser le mot de passe de déverrouillage de la racine, il est préférable d’essayer de passer par une partition intermédiaire afin de conserver aussi le mot de passe dans un fichier. Juste garder à l’esprit qu’un mot de passe peut se voler avec un simple keylogger ou à distance si la machine n’est pas TEMPEST.

Si l’on fait abstraction de l’utilisation d’une clé USB avec protection physique en lecture seule, il est possible de ne pas séparer la partition /home de la partition racine /. On ne peut plus profiter de la protection en lecture seule du système. Ce qu’il reste sur la clé USB contenant la partition /boot est minime. C’est à dire qu’il ne reste que la partition /boot avec son noyau Linux et la clé de déchiffrement de la partition racine sur l’autre clé USB.
On peut même imaginer dans ce cas laisser le bootloader et le noyau Linux sur la même clé que la partition racine et de ne laisser que le fichier contenant le mot de passe de la partition racine seul sur une clé USB.
Cela amène une réflexion intéressante, il n’est nul besoin de garder avec soi la clé USB des données. Le fichier avec le mot de passe du système est le plus important et ‘cache‘ le système et les données. On a instinctivement tendance à vouloir garder les données avec soi par défaut, mais sans la clé USB contenant le système, c’est complètement inutilisable. Autant finalement ne transporter que la clé, garder le reste est superflu et sentimental…

On peut, suite à la réflexion précédente, par exemple avoir trois clés USB et non deux. Une est en lecture seule pour le système, le bootloader et le noyau. Une autre contient la partition chiffrée des données. Et la dernière plus classique contient le fichier de mot de passe de déverrouillage du système. Le schéma de principe devient plus compliqué à représenter.

Nous pourrions mettre le bootloader (grub), qui est généralement associé au disque avec la partition /boot, sur la même clé que le système d’exploitation. Il profiterais ainsi de la protection physique en lecture seule.
Cependant, on est plus dans un problème d’usage qu’un problème technique. Qu’est ce qui vous garanti que la clé ne va pas être déverrouillée par un intrus, le noyau Linux modifié par une version corrompue, et re-verrouillée. En effet, le noyau Linux est stocké en clair dans la partition /boot. Il n’y a aucun moyen facile de vérifier l’intégrité du noyau ou du bootloader avant le chargement de ceux-ci. On peut penser à TPM et SecureBoot mais il faut que le bootloader soit reconnu sur toutes les machines qui sont susceptibles de devoir démarrer avec celui-ci. Graver le tout sur un CD-ROM ne protège pas plus des modifications parce que celui-ci peut être re-gravé modifié. Une solution serait de vérifier l’empreinte du bootloader ainsi que du noyau, mais il faut le faire sur une machine qui est potentiellement corrompue.
La solution retenue est simplement organisationnelle, laisser le bootloader et le noyau sur la clé avec les données et non avec le système. Et garder la clé USB des données avec soi en permanence. La clé du système peut rester sans risque à côté de l’ordinateur sur lequel elle sera utilisée. Si la clé des données est perdu ou volée, elle sera inutilisable. Si elle ‘réapparaît‘ après une disparition non élucidée, elle ne doit plus être utilisée.

On peut améliorer la furtivité de l’ensemble. Présenter une partition ‘normale‘ pour M$ Windows n’est qu’une première étape. Mais elle ne trompera pas un Linux qui demandera de saisir la clé de déchiffrement. Si vous souhaitez vous rendre dans un pays totalitaire comme les USA, la Chine ou la Russie, il faudra faire mieux que ça.
Il est possible d’améliorer un peu ça en utilisant sur la partition des données la méthode plain dm-crypt à la place de la méthode LUKS qui est repérable à son entête. Mais cela laisse la trace de la partition inconnue avec son contenu à très forte entropie.
Il est aussi possible de bidouiller les partitions tout en trouvant un moyen de rendre la partition chiffrée accessible au moment de démarrer sur la clé. on entre en plein dans la stéganographie…

Références

Liens :
– http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
– http://www.debian.org/
– http://www.ubuntu.com/