Chiffrer un support

Je réfléchis ces derniers temps à ma résilience numérique. C’est un thème qui me tient à cœur, mais que je n’ai pas ou peu développé pour l’instant. Je me suis cantonné à y penser de temps à autre, sans faire beaucoup plus que m’assurer d’avoir un double de mes fichiers importants. J’ai néanmoins amélioré la partie service au premier semestre 2018, en automatisant le déploiement de mon nuage de service à partir de la dernière sauvegarde disponible. La solution fonctionne et a le mérite d’être une première étape pouvant servir de base pour des améliorations ultérieures. Plus récemment, je me suis donc intéressé à mes données locales, à commencer par ce que l’on pourra nommer les « fichiers critiques »: base de données de mot de passe, copie de documents administratifs, … Pour ces données, il convient de les sauvegarder sur de multiples supports qui pourront ensuite être stockés en des lieux différents. Ces supports ne doivent bien sûr pas être lisible, c’est pourquoi je fais le choix de les chiffrer. C’est cette opération que je vais documenter ci-dessous.
Création
Le support sera chiffré avec la combinaison LUKS/dm-crypt. Une fois l’emplacement du support identifié (/dev/sdx), on pourra effectuer l’opération de chiffrement avec cryptsetup :
sudo cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 luksFormat /dev/sdx
Attention, cette commande effacera toutes les données sur le support concerné ! Par ailleurs, en ce qui concerne le choix de la phrase secrète, la documentation de cryptsetup conseille de se limiter aux 95 caractères imprimables des premiers 128 caractères de la table ASCII; pour des raisons d’encodage. Au revoir donc caractères accentués et autres caractères particuliers propres à la langue française.
Ouverture
Une fois le support chiffré, nous allons pouvoir l’ouvrir.
sudo cryptsetup luksOpen /dev/sdx nomDuDisque
Sécurité supplémentaire (optionnel)
Avant de formater, certaines sources préconisent de remplir le support de zéro. Avec le programme dd et une indication de la progression :
dd if=/dev/zero of=/dev/mapper/nomDuDisque status=progress
Attention, cette opération n’est pas des plus rapides et peut durer plusieurs heures.
Formatage
Et enfin formater le support.
sudo mkfs.ext4 -L nomDuDisque /dev/mapper/nomDuDisque
Statut
On peut vérifier le statut du support :
sudo cryptsetup -v status nomDuDisque
Qui nous donnera :
/dev/mapper/nomDuDisque is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sdx
  sector size:  512
  offset:  4096 sectors
  size:    30229492 sectors
  mode:    read/write
Opération réussie.
Fermeture
Pour fermer le support chiffré :
sudo cryptsetup luksClose /dev/mapper/nomDuDisque
Sauvegarde du header
Étant donné que toute corruption, altération ou destruction du header LUKS entraîne l’impossibilité d’accéder à l’ensemble du support chiffré, il convient d’en effectuer une sauvegarde :
cryptsetup luksHeaderBackup --header-backup-file /chemin/vers/header /dev/sdx
Il faut renouveler la sauvegarde du header en cas de changement des phrases secrètes (un support chiffré peut avoir jusqu’à 8 phrases secrètes différentes).
Test d’un header
En cas de tentative de restauration d’un header, il est possible de vérifier que le header que l’on souhaite restaurer est le bon :
sudo cryptsetup -v --header /chemin/vers/header open /dev/sdx test
Qui doit renvoyer :
Key slot 0 unlocked.
Command successful.
Restauration d’un header
Avec le support fermé, on peut effectuer la restauration du header à partir de son fichier de sauvegarde :
sudo cryptsetup luksHeaderRestore /dev/sdx --header-backup-file /chemin/vers/header
Gestion des phrases secrètes
Pour ajouter un mot de passe au support ou en supprimer un existant, on utilisera l’une des commandes :
sudo cryptsetup luksAddKey /dev/sdx
sudo cryptsetup luksRemoveKey /dev/sdx
Note : Permissions ext4
Petit point technique relatif au système de fichier avant de conclure. Il faut noter que par défaut, suite au formatage, le propriétaire de la racine du support chiffré est root. En l’état, impossible sur mon système de déplacer un fichier vers le support chiffré sans passer par un sudo cp. Pour y remédier, on peut au besoin changer le propriétaire :
sudo chown -R user /run/media/user/nomDuDisque
Il est également possible de donner les droits à l’utilisateur exécutant la commande de formatage via sudo avec :
sudo mkfs.ext4 -E root_owner=$UID:$GID /dev/sdx
Ou encore :
sudo mkfs.ext4 -E root_owner=$UID:$GID -L nomDisque /dev/mapper/nomDuDisque
Source: Format ext4 filesystem to be owned by regular user
Conclusion
À la suite de cet article, je dispose désormais d’un lot de clés USB chiffrées sur lesquelles je vais pouvoir stocker mes fichiers importants à sauvegarder. Afin de boucler la boucle, chaque header fera évidemment partie de la sauvegarde. Il me reste à définir la fréquence de rotation de ces sauvegardes froides, celle-ci sera certainement semestrielle, éventuellement trimestrielle. Chaque lieu de sauvegarde prévu disposant de deux clés dédiés, il suffira de générer la « nouvelle » clé, puis de l’échanger avec « l’ancienne ». Pour la suite, je souhaite conduire une réflexion sur mes données locales: définir clairement les fichiers critiques, définir une arborescence générale pour l’organisation de mes données. Il sera également nécessaire de s’interroger sur la pertinence des données (données à garder ?) et de définir quelles données constituent éventuellement une perte acceptable, afin de choisir le disque externe à privilégier (en fonction de son âge principalement). Source : Cold Storage et LUKS Header Backup de Peter Hogg. cryptsetup Wiki Cryptsetup Wikibook dm-crypt/Device encryption sur le Wiki ArchLinux.
Victor

Auteur : Victor

Libriste convaincu, j’administre ce serveur et son domaine et privilégie l'utilisation de logiciels libres au quotidien. Je construis progressivement mon "cloud" personnel service après service pour conserver un certain contrôle sur mes données numériques.

Une réflexion sur « Chiffrer un support »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *