![\"20131108](\"\/wp-content\/uploads\/stephane\/2013\/11\/20131108-cryptsetup-sur-2-cles-usb1.png\")
<\/a><\/p>\nL’exemple est r\u00e9alis\u00e9 \u00e0 partir de Debian Linux 7.0<\/a>, mais \u00e7a n’a pas de raison de ne pas fonctionner avec d’autres distributions. \u00c7a marche aussi avec Ubuntu Linux<\/a> par exemple. Il faut obligatoirement que cryptsetup<\/em> soit disponible sur la distri. Il faut de pr\u00e9f\u00e9rence que l’on puisse mettre en place le chiffrement d\u00e8s l’installation du syst\u00e8me. Il faut aussi de pr\u00e9f\u00e9rence que le syst\u00e8me soit installable directement sur cl\u00e9 USB et sur une partition chiffr\u00e9e. Si ces deux derni\u00e8res conditions ne sont pas remplies, l’exercice est r\u00e9alisable mais il est beaucoup plus complexe \u00e0 mettre en place.<\/p>\n <\/p>\n Les partitions en rouge sont en clair. Tout ce qui est enregistr\u00e9 dessus est lisible et\/ou modifiable par autrui. Les partitions en bleu sont int\u00e9gralement chiffr\u00e9es. Tout ce qui est \u00e0 l’int\u00e9rieur n’est ni lisible, ni modifiable. On ne peut pas non plus savoir ce qu’il y a dedans ou m\u00eame estimer la quantit\u00e9 de donn\u00e9es. Le but est ici de montrer que l’on peut combiner les disques chiffr\u00e9s de diff\u00e9rentes mani\u00e8res. Dans cet exemple, les donn\u00e9es sont sur une cl\u00e9 USB, le syst\u00e8me d’exploitation est sur l’autre cl\u00e9 USB, le tout d\u00e9marre sans demander de mot de passe. La cl\u00e9 USB contenant le syst\u00e8me d’exploitation est physiquement (switch) verrouill\u00e9e en lecteur seule pour le prot\u00e9ger de toute modification logique. Et bien s\u00fcr, le syst\u00e8me peut tout \u00e0 fait \u00eatre ‘user-friendly’ avec une belle interface graphique!<\/p>\n La s\u00e9paration du Si cette protection ne vous int\u00e9resse pas, il n’est dans ce cas pas n\u00e9cessaire de s\u00e9parer la partition Chaque partition chiffr\u00e9e a sa cl\u00e9 de d\u00e9chiffrement qui se trouve stock\u00e9e sur l’autre cl\u00e9 USB. Ainsi, bien que l’une des cl\u00e9s de d\u00e9chiffrement soit en clair, la perte ou le vol d’une des cl\u00e9s USB ne permet d’acc\u00e9der ni au syst\u00e8me d’exploitation ni aux donn\u00e9es.<\/p>\n Sur la station qui sert \u00e0 l’installation, d\u00e9brancher physiquement le disque dur interne le temps de l’installation. Brancher les deux cl\u00e9s USB et ins\u00e9rer le CD-ROM d’installation de Debian Linux<\/a>. Faire une installation en mode texte (par d\u00e9faut).<\/p>\n L’installation se passe normalement \u00e0 l’exception de la partie concernant le partitionnement. Il faut cr\u00e9er d’abord :<\/p>\n Pour la partition sda2<\/em>, lui donner comme label ‘ Chaque partition chiffr\u00e9e n\u00e9cessite son mot de passe propre, mais ce peut \u00eatre le m\u00eame. Choisir un mot de passe assez solide le temps de terminer l’installation et le param\u00e9trage des mots de passes d\u00e9finitifs dans des fichiers. L’installation peut continuer normalement…<\/p>\n ATTENTION!!!<\/strong><\/span> Il est important, parce que nous travaillons sur des supports de stockage USB, de mettre des mots de passes forts<\/span> sur les partitions chiffr\u00e9es. Et ceci m\u00eame 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’\u00e9criture sur la cl\u00e9, on n’est pas en mesure de savoir si l’\u00e9lectronique de la cl\u00e9 USB ne va pas permuter le ‘secteur<\/em>‘ contenant le mot de passe pour \u00e9crire la modification sur un autre secteur. Ce m\u00e9canisme est \u00e0 l’origine destin\u00e9 \u00e0 \u00e9conomiser le nombre d’\u00e9critures sur un secteur en particulier et de r\u00e9partir les \u00e9critures sur l’ensemble des secteurs. Tout ceci \u00e0 l’origine non pas pour voler des cl\u00e9s de chiffrement mais pour allonger la dur\u00e9e de vie des supports amovibles \u00e0 m\u00e9moires en technologie FLASH<\/em>. Le probl\u00e8me est le m\u00eame avec un SSD<\/em>.<\/p>\n Une fois le tout install\u00e9 et la machine red\u00e9marr\u00e9e, se reconnecter en root<\/em>. Toutes les partitions doivent avoir \u00e9t\u00e9 mont\u00e9es normalement, chacune ayant n\u00e9cessit\u00e9 la saisie d’un mot de passe au d\u00e9marrage.<\/p>\n G\u00e9n\u00e9rer deux cl\u00e9s de chiffrement de 128 caract\u00e8res en hexad\u00e9cimal (ou plus), une pour chaque partition chiffr\u00e9e : Ajouter les nouvelles cl\u00e9s de chiffrement \u00e0 leurs partitions chiffr\u00e9es respectives : A chaque fois, un mot de passe est demand\u00e9. C’est le mot de passe cr\u00e9\u00e9 \u00e0 l’installation pour la partition concern\u00e9e.<\/p>\n Il faut maintenant dire au syst\u00e8me, au d\u00e9marrage, d’utiliser ces deux cl\u00e9s. Pour cela on modifie le fichier Si il manque, c’est que le label a \u00e9t\u00e9 oubli\u00e9 lors de l’installation. Le seul vraiment utile c’est boot<\/em>, on ne se servira pas des autres ici. On doit dans ce cas utiliser Le fichier\u00c2\u00a0 Les valeurs des UUID<\/em> sont ceux de mes essais, ils sont donc diff\u00e9rents \u00e0 chaque installation, \u00e0 adapter donc. Modifier le fichier comme cela (2 lignes) : Pour que les fichiers mots de passes soient pris en compte au d\u00e9marrage, il faut r\u00e9g\u00e9n\u00e9rer le fichier Red\u00e9marrer le syst\u00e8me pour voir si tout se passe bien…<\/p>\n Si tout s’est bien pass\u00e9, aucun mot de passe ne devrait \u00eatre demand\u00e9 cette fois-ci. Si tout se passe bien au d\u00e9marrage et que les deux partitions chiffr\u00e9es sont bien mont\u00e9es, on peut retirer les mots de passes d’installation. Ce n’est pas une obligation. lancer (2 lignes) : Pour v\u00e9rifier le nombre de cl\u00e9s, utiliser la commande : Par d\u00e9faut, le bootloader<\/em> devrait d\u00e9j\u00e0 \u00eatre sur la cl\u00e9 USB contenant la partition Le bon positionnement de GRUB<\/em> peut \u00eatre v\u00e9rifi\u00e9 : Si on ne s\u00e9pare pas \/home mais plut\u00f4t \/data par exemple sur la deuxi\u00e8me partition chiffr\u00e9e, l’environnement utilisateur peut ainsi \u00eatre verrouill\u00e9 au m\u00eame titre que le syst\u00e8me d’exploitation.<\/p>\n On peut essayer de demander un mot de passe en plus au d\u00e9marrage. Plut\u00f4t que de simplement laisser le mot de passe de d\u00e9verrouillage de la racine, il est pr\u00e9f\u00e9rable d’essayer de passer par une partition interm\u00e9diaire afin de conserver aussi le mot de passe dans un fichier. Juste garder \u00e0 l’esprit qu’un mot de passe peut se voler avec un simple keylogger<\/em> ou \u00e0 distance si la machine n’est pas TEMPEST<\/em>.<\/p>\n Si l’on fait abstraction de l’utilisation d’une cl\u00e9 USB avec protection physique en lecture seule, il est possible de ne pas s\u00e9parer la partition On peut, suite \u00e0 la r\u00e9flexion pr\u00e9c\u00e9dente, par exemple avoir trois cl\u00e9s USB et non deux. Une est en lecture seule pour le syst\u00e8me, le bootloader<\/em> et le noyau. Une autre contient la partition chiffr\u00e9e des donn\u00e9es. Et la derni\u00e8re plus classique contient le fichier de mot de passe de d\u00e9verrouillage du syst\u00e8me. Le sch\u00e9ma de principe devient plus compliqu\u00e9 \u00e0 repr\u00e9senter.<\/p>\n Nous pourrions mettre le bootloader<\/em> (grub), qui est g\u00e9n\u00e9ralement associ\u00e9 au disque avec la partition On peut am\u00e9liorer la furtivit\u00e9 de l’ensemble. Pr\u00e9senter une partition ‘normale<\/em>‘ pour M$ Windows<\/em> n’est qu’une premi\u00e8re \u00e9tape. Mais elle ne trompera pas un Linux<\/em> qui demandera de saisir la cl\u00e9 de d\u00e9chiffrement. Si vous souhaitez vous rendre dans un pays totalitaire comme les USA, la Chine ou la Russie, il faudra faire mieux que \u00e7a. Liens : Voici une base de syst\u00e8me qui n\u00e9cessite deux cl\u00e9s USB pour pouvoir fonctionner. Si l’une manque, le syst\u00e8me ne peut d\u00e9marrer et, plus important encore, les donn\u00e9es sont ind\u00e9chiffrables. Le sch\u00e9ma de principe : L’exemple est r\u00e9alis\u00e9 \u00e0 partir de Debian Linux 7.0, mais \u00e7a n’a pas de raison de ne pas fonctionner avec d’autres … Continuer la lecture de Syst\u00e8me bootable chiffr\u00e9 sur deux cl\u00e9s USB interd\u00e9pendantes<\/span> Les partitions<\/h2>\n
\nLa seule partition rouge vraiment utile est celle qui contient le \/boot<\/code> avec notamment le noyau Linux (kernel) \u00e0 l’int\u00e9rieur, en clair. Les deux partitions en fat32<\/em> permettent de stocker des donn\u00e9es en clair, et elles sont surtout lisible par beaucoup de syst\u00e8mes d’exploitations. Elles sont surtout l\u00e0 comme mesure de d\u00e9ception, donner \u00e0 un intrus l’impression qu’il a acc\u00e8s au contenu de la cl\u00e9 sans lui montrer que l’on cache le reste. C’est le premier niveau de d\u00e9ception, et aussi le plus facile \u00e0 d\u00e9tecter.<\/p>\n
\nIl est important qu’elles soient au moins deux et que la racine \/<\/code> ne soit pas sur la cl\u00e9 qui contient le \/boot<\/code>. Ainsi plusieurs combinaisons sont possibles comme laisser le \/home<\/code> avec la racine et cr\u00e9er un \/data<\/code> par exemple. On peut aussi mettre les deux partitions chiffr\u00e9es sur la m\u00eame cl\u00e9 USB et laisser le \/boot<\/code> sur une cl\u00e9 ind\u00e9pendante. On peut enfin juste garder la racine \/<\/code> comme seule partition chiffr\u00e9e, on verra cela plus bas.<\/p>\nLe principe<\/h2>\n
<\/a> <\/a><\/p>\n\/home<\/code>, et donc des donn\u00e9es qu’il contient par rapport au syst\u00e8me, permet au syst\u00e8me d’exploitation d’\u00eatre dispos\u00e9 sur une cl\u00e9 USB verrouill\u00e9e physiquement en lecture seule. Le syst\u00e8me est plus r\u00e9sistant \u00e0 une attaque virale qui essayerait de modifier le syst\u00e8me pour le contaminer ou pour s’installer. Cette protection n’est pas infaillible puisqu’il faut pouvoir aussi maintenir \u00e0 jour le syst\u00e8me d’exploitation et ses nombreux programmes pour qu’il r\u00e9siste aux nouvelles attaques.
\nDans ce cas, \u00e9videment, la partition en fat32<\/em> n’a pas vraiment d’int\u00e9r\u00eat.<\/p>\n\/home<\/code> de la partition racine \/<\/code>.<\/p>\nMise en pratique<\/h2>\n
1\/ Installation du syst\u00e8me d’exploitation<\/h3>\n
\n
sda1<\/strong> fat32<\/code> none<\/em><\/li>\nsda2<\/strong> ext4 \/boot<\/code><\/li>\nsda3<\/strong> <\/code>chiffrement<\/li>\nsdb1<\/strong> fat32 <\/code>none<\/em><\/li>\nsdb2<\/strong> <\/code>chiffrement<\/li>\n<\/ul>\nboot<\/code>‘, c’est plus simple pour la suite.
\nPuis aller dans la partie gestion des disques chiffr\u00e9s. Cr\u00e9er les partitions chiffr\u00e9es sur sda3 et sdb2, et le configurer comme cela :<\/p>\n\n
sda3_crypt<\/strong> ext4 \/home<\/code><\/li>\nsdb2_crypt<\/strong> volume lvm<\/code><\/li>\n<\/ul>\n
\nPuis aller dans la partie gestion des volumes lvm. Cr\u00e9er un volume et des volumes logiques la racine et le swap (et plus encore si besoin) :<\/p>\n\n
vlroot<\/strong> ext4 \/<\/code><\/li>\nvlswap<\/strong> swap<\/code><\/li>\n<\/ul>\n2\/ Premier d\u00e9marrage<\/h3>\n
3\/ G\u00e9n\u00e9ration des mots de passes<\/h3>\n
\n# openssl rand -hex 64 > \/boot\/boot.pwd
\n# openssl rand -hex 64 > \/boot.pwd
\n# chmod 400 \/boot\/boot.pwd \/boot.pwd<\/code>
\nL’avantage des caract\u00e8res en hexad\u00e9cimal, c’est qu’ils peuvent \u00eatres recopi\u00e9s \u00e0 la main facilement. L’inconv\u00e9nient, c’est aussi qu’ils peuvent \u00eatres recopi\u00e9s \u00e0 la main facilement (arrggg…<\/em>). On peut tout aussi bien g\u00e9n\u00e9rer des cl\u00e9s non-ASCII<\/em> (binaires), \u00e7a marche aussi. A noter que d’un point de vue solidit\u00e9 du mot de passe, c’est \u00e0 dire son entropie dans son espace de caract\u00e8res, c’est exactement pareil d’avoir 128 caract\u00e8res hexad\u00e9cimaux ou 64 caract\u00e8res binaires.<\/p>\n4\/ Ajout des mots de passes aux partitions chiffr\u00e9es<\/h3>\n
\n# cryptsetup luksAddKey \/dev\/sdb2 \/boot\/boot.pwd
\n# cryptsetup luksAddKey \/dev\/sda3 \/boot.pwd<\/code><\/p>\n5\/ Ajout des fichiers mots de passes \u00e0 la configuration<\/h3>\n
\/etc\/crypttab<\/code>. On v\u00e9rifie que le label de la partition \/boot<\/code> est bien pris en compte :
\n# ls -l \/dev\/disk\/by-label\/<\/code><\/p>\nlrwxrwxrwx 1 root root 10 nov.\u00c2\u00a0\u00c2\u00a0 9 10:50 boot -> ..\/..\/sda2
\n<\/code><\/p>\n\/dev\/disk\/by-uuid\/78a4832d-a421-4dbd-8503-66106ef27129<\/code> au lieu de \/dev\/disk\/by-label\/boot<\/code> (l’UUID<\/em> correspond \u00e0 mon disque \u00e0 moi). C’est moins facile.<\/p>\n\/etc\/crypttab<\/code> ressemble \u00e0 ceci (2 lignes) :<\/p>\nsdb2_crypt UUID=d3c7791c-1989-47fe-bf31-e8996207dadf none luks
\nsda3_crypt UUID=598cf9d7-a9f3-4728-87e2-a0c90369d542 none luks<\/code><\/p>\n
\n<\/code><\/p>\nsdb2_crypt UUID=d3c7791c-1989-47fe-bf31-e8996207dadf \/dev\/disk\/by-label\/boot:boot.pwd luks,keyscript=\/lib\/cryptsetup\/scripts\/passdev
\nsda3_crypt UUID=598cf9d7-a9f3-4728-87e2-a0c90369d542 \/boot.pwd luks<\/code><\/p>\n6\/ Modification du d\u00e9marrage<\/h3>\n
\/boot\/initrd.img-3.2.0-4-686-pae<\/code> (ou \u00e9quivalent) :
\n# update-initramfs -u
\n<\/code>\u00c9videment, si le fichier\u00c2\u00a0\/etc\/crypttab<\/code> est pr\u00e9sent dans l’image initrd<\/em>, ce n’est pas le cas des fichiers de cl\u00e9s de d\u00e9chiffrement!<\/p>\n
\nSi \u00e7a se passe mal, il y a toujours le mode rescue<\/em> du CD-ROM d’installation de Debian<\/em>…<\/p>\n7\/ Suppression des mots de passes d’installation<\/h3>\n
\n# cryptsetup luksKillSlot \/dev\/sdb3 0 --keyfile \/boot.pwd
\n# cryptsetup luksKillSlot \/dev\/sda2 0 --keyfile \/boot\/boot.pwd<\/code>
\n<\/code><\/p>\n
\n# cryptsetup luksDump \/dev\/sdb3
\n<\/code>Le Key Slot 0<\/code> doit maintenant \u00eatre marqu\u00e9 d\u00e9sactiv\u00e9.<\/p>\n8\/ D\u00e9placement du bootloader<\/em><\/h3>\n
\/boot<\/code>. Si ce n’est pas le cas, il faut le d\u00e9placer puis l’effacer de l’ancienne cl\u00e9 (3 lignes) :
\n# grub-install \/dev\/sda
\n# update-grub
\n# dd if=\/dev\/zero of=\/dev\/sdb bs=446 count=1<\/code>
\nCette derni\u00e8re ligne efface le chargeur de la deuxi\u00e8me cl\u00e9 USB.<\/p>\n
\n# debconf-show grub-pc<\/code><\/p>\nAm\u00e9liorations<\/h2>\n
\/home<\/code> de la partition racine \/<\/code>. On ne peut plus profiter de la protection en lecture seule du syst\u00e8me. Ce qu’il reste sur la cl\u00e9 USB contenant la partition \/boot<\/code> est minime. C’est \u00e0 dire qu’il ne reste que la partition \/boot<\/code> avec son noyau Linux et la cl\u00e9 de d\u00e9chiffrement de la partition racine sur l’autre cl\u00e9 USB.
\nOn peut m\u00eame imaginer dans ce cas laisser le bootloader<\/em> et le noyau Linux sur la m\u00eame cl\u00e9 que la partition racine et de ne laisser que le fichier contenant le mot de passe de la partition racine seul sur une cl\u00e9 USB.
\nCela am\u00e8ne une r\u00e9flexion int\u00e9ressante, il n’est nul besoin de garder avec soi la cl\u00e9 USB des donn\u00e9es. Le fichier avec le mot de passe du syst\u00e8me est le plus important et ‘cache<\/em>‘ le syst\u00e8me et les donn\u00e9es. On a instinctivement tendance \u00e0 vouloir garder les donn\u00e9es avec soi par d\u00e9faut, mais sans la cl\u00e9 USB contenant le syst\u00e8me, c’est compl\u00e8tement inutilisable. Autant finalement ne transporter que la cl\u00e9, garder le reste est superflu et sentimental…<\/p>\n\/boot<\/code>, sur la m\u00eame cl\u00e9 que le syst\u00e8me d’exploitation. Il profiterais ainsi de la protection physique en lecture seule.
\nCependant, on est plus dans un probl\u00e8me d’usage qu’un probl\u00e8me technique. Qu’est ce qui vous garanti que la cl\u00e9 ne va pas \u00eatre d\u00e9verrouill\u00e9e par un intrus, le noyau Linux modifi\u00e9 par une version corrompue, et re-verrouill\u00e9e. En effet, le noyau Linux est stock\u00e9 en clair dans la partition \/boot<\/code>. Il n’y a aucun moyen facile de v\u00e9rifier l’int\u00e9grit\u00e9 du noyau ou du bootloader<\/em> avant le chargement de ceux-ci. On peut penser \u00e0 TPM<\/em> et SecureBoot<\/em> mais il faut que le bootloader<\/em> soit reconnu sur toutes les machines qui sont susceptibles de devoir d\u00e9marrer avec celui-ci. Graver le tout sur un CD-ROM ne prot\u00e8ge pas plus des modifications parce que celui-ci peut \u00eatre re-grav\u00e9 modifi\u00e9. Une solution serait de v\u00e9rifier l’empreinte du bootloader<\/em> ainsi que du noyau, mais il faut le faire sur une machine qui est potentiellement corrompue.
\nLa solution retenue est simplement organisationnelle, laisser le bootloader<\/em> et le noyau sur la cl\u00e9 avec les donn\u00e9es et non avec le syst\u00e8me. Et garder la cl\u00e9 USB des donn\u00e9es avec soi en permanence. La cl\u00e9 du syst\u00e8me peut rester sans risque \u00e0 c\u00f4t\u00e9 de l’ordinateur sur lequel elle sera utilis\u00e9e. Si la cl\u00e9 des donn\u00e9es est perdu ou vol\u00e9e, elle sera inutilisable. Si elle ‘r\u00e9appara\u00eet<\/em>‘ apr\u00e8s une disparition non \u00e9lucid\u00e9e, elle ne doit plus \u00eatre utilis\u00e9e.<\/p>\n
\nIl est possible d’am\u00e9liorer un peu \u00e7a en utilisant sur la partition des donn\u00e9es la m\u00e9thode plain dm-crypt<\/em> \u00e0 la place de la m\u00e9thode LUKS<\/em> qui est rep\u00e9rable \u00e0 son ent\u00eate. Mais cela laisse la trace de la partition inconnue avec son contenu \u00e0 tr\u00e8s forte entropie.
\nIl est aussi possible de bidouiller les partitions tout en trouvant un moyen de rendre la partition chiffr\u00e9e accessible au moment de d\u00e9marrer sur la cl\u00e9. on entre en plein dans la st\u00e9ganographie…<\/p>\nR\u00e9f\u00e9rences<\/h2>\n
\n– http:\/\/code.google.com\/p\/cryptsetup\/wiki\/FrequentlyAskedQuestions<\/a>
\n– http:\/\/www.debian.org\/<\/a>
\n– http:\/\/www.ubuntu.com\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"