Conteneurs chiffrés pour documents envoyés à des clouds douteux

Contexte

Le titre parle de cloud douteux, mais il peut s'agir de son propre cloud auto-hébergé sur lequel on aurait des doutes quant à la sécurité : temps ou compétences limités, faille potentielles (probables?) dans le logiciel utilisé,...

Le caractère pratique de disposer de ses données dans un cloud partout, tout le temps, peut conduire à y stocker des données sensibles: historique bancaire, copie de pièces d'identité, bulletins de salaires, factures,... Des données que l'on ne souhaite pas voir exposées aux yeux d'un tiers inconnu. Si le logiciel utilisé en auto-hébergement ne permet pas le chiffrement de bout en bout (ou si on utilise un cloud propriétaire), il semble ainsi pertinent de conserver ces données dans un conteneur chiffré, de sorte qu'un attaquant ayant pénétré le serveur (ou le tiers propriétaire du cloud) ne trouve pas ces données en open bar. En outre, si les clients (ordinateur, téléphone) ne sont pas chiffrés, cela permet également de gagner en sécurité vis-à-vis de ces appareils: quelqu'un qui les trouverait n'aurait pas plus accès à ces données.

La première idée était de chiffrer avec un conteneur LUKS (crédit au guide d'autodéfense numérique: voir qu'ils recommandent LUKS permet de savoir assez vite vers qui se tourner). Néanmoins le débroussaillage me laissait entrevoir quelque chose d'assez peu pratique, j'ai donc commencer par explorer une autre voie basée sur GPG.

Précision en terme de contexte : ordinateur sous Debian stable (Stretch à date), utilisant Thunar comme gestionnaire de fichier et XFCE comme environnement de bureau, et smartphone sous Android 6. L'optique est d'avoir une utilisation quotidienne facile, ce qui se traduit sur l'ordinateur par une semi-automatisation (actions personnalisées Thunar, appariement du conteneur à l'ouverture de session).

À la mode GPG

Principe

Encapsuler le dossier dans un fichier (.zip par exemple) puis chiffrer ce fichier avec une clé GPG, avec pour destinataire la même clé GPG.

Principal inconvénient

Si on perd la clé alors le contenu est perdu.

Mise en oeuvre

1. créer une clé GPG avec son ordinateur: gen-key

2. la transférer à son téléphone. Sous Android et avec OpenKeychain voir ici la procédure :

   gpg --armor --gen-random 1 20; gpg --armor --export-secret-keys YOUREMAILADDRESS | gpg --armor --symmetric --output mykey.sec.asc

   avec à la place de YOUREMAILADDRESS l'adresse mail ou l'identité IDENTITE associée à la clé créée plus tôt ; transférer le fichier produit au téléphone et l'ouvrir avec OpenKeychain en suivant les indications ; il faut notamment renseigner le mot de passe généré avec la première commande, permettant la sécurisation du transfert de la clé privée au téléphone) ;

3. l'action personnalisée pour Thunar pour transformer un dossier en .zip chiffré (qui rend compte des étapes successives pour passer d'un dossier à une archive chiffrée):

   cd %d; zip -r %f.zip $(realpath --relative-to=%d %f); xfce4-terminal -x gpg --encrypt --recipient IDENTITE %f.zip; rm %f.zip

   (%f : chemin absolu du fichier pointé, soit ici un dossier ; %d le chemin absolu du dossier parent ; la bidouille sur le realpath permet d'avoir effectivement les chemins relatifs dans le fichier zippé) ;

   • pour l'action personnalisée Thunar, bien penser à aller cocher que celle-ci doit apparaître pour les dossiers (dans l'onglet "Conditions d'apparition").

4. pour déchiffrer, l'action personnalisée Thunar (idem, rend compte des commandes successives pour lire le conteneur):

   xfce4-terminal -x gpg --decrypt --output %f_dechiffre --recipient IDENTITE %f

5. sur le téléphone, déchiffrer le conteneur avec OpenKeychain et consulter le contenu de l'archive avec GhostCommander, par exemple.

À base de conteneur LUKS

Principe

Créer un disque virtuel chiffré de format LUKS et partager ce disque.

Principal inconvénient

La taille du fichier est statique; de sorte que si on n'a quelques mégaoctets de données à chiffrer mais qu'on sait qu'on sera amené à y mettre davantage, pour ne pas refaire un nouveau conteneur à l'avenir, on est contraint de prendre de la marge dès la création du conteneur. Ce qui signifie qu'en général on occupe plus d'espace que n'en requièrent les fichiers chiffrés.

Avantage sur la façon GPG précédente

Retenir la phrase de passe est suffisant pour retrouver l'accès au contenu.

Mise en oeuvre

• création du conteneur et formatage en fat (à exécuter en tant qu'admin : sudo ou compte root de rigueur):

  dd if=/dev/urandom of=conteneur.img bs=20M count=1 iflag=fullblock
  cryptsetup --align-payload=1 --key-size 512 --hash sha512 luksFormat conteneur.img
  cryptsetup open conteneur.img cont_
  mkfs.fat /dev/mapper/cont_
  cryptsetup close cont_
  

• appariement du conteneur à un point de montage, en tant qu'utilisateur non-root : udisksctl loop-setup -f conteneur.img ; ne reste alors qu'à cliquer le conteneur dans le navigateur de fichier, rentrer la phrase de passe et on est bon!

  • pour faciliter l'utilisation quotidienne, j'ai créé un service au démarrage de la session, contenant cette ligne de commande. Il faut toujours rentrer la phrase de passe mais on se débarrasse déjà d'une partie du travail.
• il y a ce qu'il faut sur F-Droid pour lire les conteneurs LUKS sur un téléphone Android : EDS Lite
• A noter que j'ai d'abord essayé le formatage en ext4 : on obligé de bidouiller pour pouvoir écrire dans le conteneur (cf point suivant), et l'appli Android EDS Lite ne parvient pas à l'ouvrir.
  • pour pouvoir écrire dans le conteneur formaté en ext4, je suis obligé de l'ouvrir une première fois, donner la possession de son contenu à l'utilisateur, de le démonter. Au montage suivant je peux écrire dedans. Je suppose que la différence est liée (a) au formatage avec le compte administrateur et (b) à la différence de gestion des droits des utilisateurs entre les deux formats.

Principales sources pour cette méthode

• wiki d'Archlinux, comme toujours très utile (complet, clair);
  • les pages liées sont utiles également : 1, 2
• le blog qui m'a donné la solution pour l'usage en tant qu'utilisateur non root : blog (j'ai eu l'embryon de solution, à savoir udisksctl, ici, où l'on comprend que l'utilisation en tant que non-root est non triviale).

En passant

A noter également le projet luckyLUKS qui propose de faciliter l'usage de ces conteneurs chiffrés ; mais pas dans les dépôts, je ne connais pas, donc pas de confiance a priori. Surtout sur un sujet comme le chiffrement des données.

Conclusion

La solution avec LUKS reste plus sûre, dans la mesure où il n'y a pas de fichiers (clé de chiffrement) que l'on puisse égarer, seulement une phrase de passe qu'on peut oublier (problématique qui se traite mieux, de mon point de vue, avec un gestionnaire de mots de passe comme Keepass). L'ouverture d'un conteneur de 500mo sur Android est loin d'être immédiate (2 min à 3 min sur un Nexus 4) mais le cas d'usage n'implique pas un accès nécessairement rapide aux données, l'accent étant mis sur l'accessibilité.

L'avantage de GPG serait une ouverture plus rapide (OpenKeychain + GhostCommander qui sait ouvrir les zip) et une taille de fichier dynamique (vs. statique avec LUKS).