Créer un gros conteneur chiffré rapidement, avec des zéros...

Il est écrit partout, et c'est bien normal, que la première étape incontournable pour créer un conteneur chiffré est de passer par un remplissage du volume par des données aléatoires. Cela se fait sans soucis pour un petit conteneur de quelques mégas, mais cela peut vite devenir très très lent si l'on tape sur plusieurs centaines de giga, voir un disque d'un tera.

Heureusement il y a un contournement assez simple, en passant par des zéros...

/dev/urandom vs /dev/zero

Commençons par faire les choses en bon élève, en suivant tous les tutos de la terre sur la création de conteneur chiffrés. Perso j'ai besoin de 300G, je vais donc lancer la commande dd qui tue :

gastondd if=/dev/urandom of=mon_conteneur bs=10M count=30000

Et là ça dure, ça dure des plombes. Et l'on a envie de savoir ce qui se passe évidemment mais dd est un sale vicieux qui se garde bien de dire ce qu'il fabrique. Heureusement, petite astuce cachée au fin fond du man de cette commande, il est possible de l'obliger à parler de temps en temps. Pour cela, dans une autre console tapez la commande suivante

killall dd -USR1

Rassurez-vous, cela ne va pas tuer dd, mais simplement lui demander gentiment où il en est. Il va alors imprimer dans la sortie standard l'état d'avancement et surtout son débit. Et là on pleure, dans mon cas, 10.3MB/S. C'est loin, très loin même de ce que permet un vieux disque tout pourris en écriture. Et à ce rythme là, mes 300Go seront créés dans 8h, intolérable. D'un jeu de doigts vengeurs CTRL-C, on arrête le tout.

Essayons maintenant avec cette fois un remplissage à base de zéros.

gastondd if=/dev/zero of=mon_conteneur bs=10M count=30000

Cette fois on passe de 10.3 à 402MB/S. Cela fait tout de même une belle différence, car de 8h de désespoir on tombe 12 minutes...

Alors utilisons des zéros !!

Même d'ici j'en vois déjà certains qui bondissent sur leur chaise. Un conteneur remplis de zéros est une hérésie rendant un cassage beaucoup plus facile (tout est relatif cependant) puisque l'attaquant pourrait détecter quelles portions du volume sont concrètement remplies de fichiers. Réfrénez vos hurlement quelques instants, nous allons nous amuser un peu...

Étape suivant, le formatage du conteneur plein de zéros (oui, j'insiste ;-) :

$ sudo cryptsetup --verbose luksFormat test2

WARNING!
========
Cette action écrasera définitivement les données sur test2.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète LUKS :
Verify passphrase:
Opération réussie.

$ sudo cryptsetup --verbose luksOpen test2 mon_conteneur
Saisissez la phrase secrête pour /home/yoran/test2 :
Emplacement de clé 0 débloqué.
Opération réussie.

Là, deuxième bond sur la chaise, en effet, c'est malheureux, mais je n'ai mis aucun mot de passe à mon conteneur, juste deux fois Entrée.

Ici commence vraiment le "truc". Nous allons maintenant remplir le conteneur chiffré encore une fois de zéros :

$ sudo dd if=/dev/zero of=/dev/mapper/mon_conteneur bs=1M
dd: écriture de /dev/mapper/mon_conteneur : Aucun espace disponible sur le périphérique
499+0 enregistrements lus
498+0 enregistrements crits
522190848 octets (522 MB) copis, 2,93756 s, 178 MB/s

Plouf, plouf, c'est gagné, voilà mon conteneur remplis de données aléatoires. Dérouté ? Reprenons alors un peu plus haut.

Use the force LUKS

Lorsque nous avons ouvert notre conteneur formaté sans mot de passe avec LUKS, ce dernier nous a dit quelque chose d'intéressant : "Emplacement de clé 0 débloqué". En fait LUKS n'utilise pas la clef que vous lui donnez pour chiffrer les données, mais génère sa propre clef bien longue et solide. La votre ne sert qu'à débloquer celle de LUKS.

Lorsque nous avons lancé notre commande dd, nous avons donc demandé à LUKS de chiffrer avec sa clef une série de zéro jusqu'à ce que le conteneur soit plein, ce qui a eu pour conséquence de remplir le fichier sous-jacent de données... aléatoires.

L'opération est pour le moins rentable car même si le débit est moindre que lorsque l'on a créé le fichier initial, cela reste tout de même 18 fois plus rapide qu'en passant par urandom, soit environ 28 minutes pour 300Go.

En résumé, là ou le remplissage avec urandom aurait pris 8h, nous n'avons pour l'instant utilisé que 30 minutes.

Il nous suffit maintenant de démonter le conteneur, et d'écraser le header de LUKS avec des données cette fois aléatoire.

gastonsudo dmsetup remove /dev/mapper/mon_conteneur
gastondd if=/dev/urandom of=test2 bs=1M count=1 conv=notrunc
1+0 enregistrements lus
1+0 enregistrements écrits
1048576 octets (1,0 MB) copiés, 0,100975 s, 10,4 MB/s

On retrouve la lenteur de urandom (10.4MB/S) mais on s'en moque, ce n'est qu'1mo qu'il nous faut écraser, cela reste instantané sur une machine moderne. Notez le paramètre conv=notrunc qui permet d'écraser notre premier mega sans pour autant faire disparaître les gigas suivants, utile... :)

Il ne reste maintenant plus qu'à reprendre la création du volume LUKS depuis le début, en prenant bien soin cette fois de mettre un mot de passe ;-)

Conclusion

À noter qu'ici on travaille sur un fichier conteneur. Cette approche est encore plus rapide s'agissant de chiffrer une partition puisqu'il n'y a pas de disque initial à créer.