J’explique comment préparer un répertoire de fichiers pour le transfert sécuritaire par envoi postal d’une clef USB, ainsi que comment restaurer ces données sur réception. La discussion passe par l’assemblage d’outils UNIX communément répandus.
Pour une poignée de gigas
J’ai eu récemment à envoyer une machine virtuelle VMware à des collaborateurs européens. Cette VM tient dans un répertoire de quelques dizaines de gigaoctets: même en éliminant tous les snapshots, son transfert allait coûter une grande part de mon allocation mensuelle de bande passante. J’ai alors décidé d’envoyer ces données via une vieille clef USB de 32 GB que j’avais sous la main, par la poste. Vieille école.
En définitive, c’était probablement une idée saugrenue: la clef valait au moins 20$ et l’envoi postal m’a coûté 15$. Il m’aurait assurément coûté moins cher de bande passante de télécharger les fichiers en utilisant un outil adéquat au transfert de gros fichiers, comme BitTorrent. Ceci dit, il m’aurait fallu préparer les fichiers de manière similaire pour que ce transfert soit sécuritaire.
Préparation des données pour l’envoi
Donc, je dois stocker un répertoire volumineux sur une clef USB envoyée par la poste, ou je dois le transférer via BitTorrent. Dans le premier cas, l’envoi postal peut être simplement volé par un employé d’un des quelques services postaux qui achemineront mon paquet. Dans le deuxième cas, tous les usagers de BitTorrent pourront accéder aux données. Je veux que ma VM demeure privée à mon cercle de collaborateurs, aussi me faut-il encrypter les fichiers qui la composent. Il est plus simple d’encrypter un fichier unique, ce qui permettrait par ailleurs de comprimer les données. Donc, voici le plan pour préparer les données:
- Rassembler les fichiers dans un unique fichier archive.
- Comprimer l’archive.
- Encrypter l’archive comprimée à l’aide d’un algorithme symétrique, idéalement AES-256.
- Séparer l’archive comprimée et encryptée en fragments n’excédant pas 2 GB.
Les trois premières étapes génèrent un fichier encrypté de quelques dizaines de gigaoctets. Cependant, ma clef USB est formattée au système de fichiers FAT32, qui n’accepte pas les fichiers de plus de 2 GB, d’où la quatrième étape. Je ne crois pas qu’elle soit nécessaire pour le transfert par BitTorrent.
La chaîne de commandes UNIX suivante exécute ces 4 étapes sans stockage temporaire d’une archive volumineuse. Cette chaîne fonctionne également sur Mac OS X et Linux (j’ai vérifié sur Ubuntu 12.04). On branche donc la clef USB. On ouvre ensuite un terminal et on se place dans le répertoire qui contient la VM (supposons qu’elle réside dans le sous-répertoire VM), puis:
tar cfz - VM | openssl aes-256-cbc | split -a 3 -b 1024m - /chemin/vers/clef/usb/vm.tar.gz.aes.split.
L’option z de tar s’occupe implicitement de la compression de l’archive via gzip. La commande split, bien que standardisée POSIX, est un peu moins usitée: ainsi invoquée, elle fragmente son entrée standard en une séquence de fichiers nommés selon son dernier argument, suffixés d’un code alphabétique unique (aaa, aab, aac… aba, abb… zzz). L’option -a exige que ce code unique comporte trois lettres et l’option -b détermine la taille de chaque fragment (1024m = 1024 MB = 1 GB).
L’invocation de la commande openssl sous cette forme exige la saisie d’un mot de passe pour générer la clef cryptographique. Évidemment, toute la sécurité de l’ensemble de données repose sur la force de ce mot de passe. Je propose la génération aléatoire d’un mot de passe d’au moins 20 caractères incluant des lettres minuscules et majuscules, des chiffres et des symboles faciles à taper sur tous les claviers (!, @, #, $, etc.).
La transmission du mot de passe suppose que je suis déjà en mesure d’échanger des informations de manière sécuritaire avec les gens à qui j’envoie les données sous considération. En particulier, je suppose que j’ai échangé avec ces gens des clefs publiques PGP/GPG, de sorte que je peux leur écrire du courrier encrypté, ou communiquer avec eux via Silent Circle ou Safety Jabber. Après la découverte que Microsoft espionne les communications qui transitent par ses serveurs Skype, tous les systèmes de messagerie instantanée centralisés ont perdu ma confiance.
Récupération des données sur réception
Voici comment mes collaborateurs ont pu récupérer la VM à partir de la clef lorsqu’ils l’ont reçue par la poste:
cat /chemin/vers/clef/usb/vm.tar.gz.aes.split.* | openssl aes-256-cbc -d | tar xvfz -
L’usage de l’option v à la commande tar permet d’observer le résultat du désarchivage en cours, je suis toujours curieux de ce genre de choses.
Contrôle de la qualité des fichiers transférés
Avant d’envoyer la clef USB ainsi préparée, il est de bon augure de tenter l’opération de récupération. On s’assure ainsi que les blocs sur lesquels les données sont stockées ne sont pas mauvais, ce qui pourrait corrompre ce coûteux transfert. Si on n’a pas l’espace pour stocker une seconde copie du volume de données, on peut interrompre la récupération en tapant CTRL+C dès qu’on commence à voir un listing des fichiers désarchivés. En effet, si les fragments du fichier sont corrompus, la décompression échouera en prétextant que les données sont illisibles.
Peu importe le mode de transfert, c’est aussi une bonne idée de générer et de stocker les signatures cryptographiques des fragments du fichier comprimé et encrypté. Ces signatures cryptographiques peuvent être regénérées sur réception de la clef USB ou des fragments via BitTorrent, et comparées à celles calculées par l’émetteur. Sur Mac OS X, on génère les signatures MD5 par la simple commande
md5 /Volume/Clef\ USB/vm.tar.gz.aes.split.* > vm.md5
Sur Linux (Ubuntu 12.04), on utilise plutôt
md5sum /media/Clef\ USB/vm.tar.gz.aes.split.* > vm.md5
J’ai envoyé ce petit fichier de signatures aux récepteurs par courrier électronique encrypté. Si ces derniers emploient le même outil que moi pour générer ces signatures, les fichiers vm.md5 peuvent être comparés par la commande diff:
diff ben.md5 moi.md5
Si la commande ne génère aucune sortie, les signatures sont identiques. Si le récepteur n’utilise pas exactement le même outil pour générer les signatures que moi (e.g. j’ai utilisé md5 et le récepteur utilise md5sum), les sorties exactes ne correspondent pas, bien que les signatures elles-mêmes peuvent correspondre. Il faut donc comparer les signatures “à l’oeil.”
Le silence est une délicieuse tape dans le dos
En définitive, grâce à un peu de chance, mes collaborateurs ont bien reçu ma clef USB et ont récupéré la VM sans le moindre souci – à tel point que je n’ai eu des nouvelles de la réception que plusieurs jours après, en passant. Tout a si bien été qu’ils n’ont même pas pensé m’avertir de la chose. Succès.