{"id":3161,"date":"2018-09-08T20:00:24","date_gmt":"2018-09-08T18:00:24","guid":{"rendered":"http:\/\/www.unicoda.com\/?p=3161"},"modified":"2021-02-17T20:55:35","modified_gmt":"2021-02-17T19:55:35","slug":"chiffrer-un-support","status":"publish","type":"post","link":"https:\/\/www.unicoda.com\/?p=3161","title":{"rendered":"Chiffrer un support"},"content":{"rendered":"\n

Je r\u00e9fl\u00e9chis ces derniers temps \u00e0 ma r\u00e9silience num\u00e9rique. C’est un th\u00e8me qui me tient \u00e0 c\u0153ur, mais que je n’ai pas ou peu d\u00e9velopp\u00e9 pour l’instant. Je me suis cantonn\u00e9 \u00e0 y penser de temps \u00e0 autre, sans faire beaucoup plus que m’assurer d’avoir un double de mes fichiers importants. J’ai n\u00e9anmoins am\u00e9lior\u00e9 la partie service au premier semestre 2018, en automatisant le d\u00e9ploiement de mon nuage de service \u00e0 partir de la derni\u00e8re sauvegarde disponible. La solution fonctionne et a le m\u00e9rite d’\u00eatre une premi\u00e8re \u00e9tape pouvant servir de base pour des am\u00e9liorations ult\u00e9rieures. Plus r\u00e9cemment, je me suis donc int\u00e9ress\u00e9 \u00e0 mes donn\u00e9es locales, \u00e0 commencer par ce que l’on pourra nommer les \u00ab\u00a0fichiers critiques\u00a0\u00bb: base de donn\u00e9es de mot de passe, copie de documents administratifs, … Pour ces donn\u00e9es, il convient de les sauvegarder sur de multiples supports qui pourront ensuite \u00eatre stock\u00e9s en des lieux diff\u00e9rents. Ces supports ne doivent bien s\u00fbr pas \u00eatre lisible, c’est pourquoi je fais le choix de les chiffrer. C’est cette op\u00e9ration que je vais documenter ci-dessous. <\/p>\n\n\n\n

Cr\u00e9ation<\/h4>\n\n\n\n

Le support sera chiffr\u00e9 avec la combinaison LUKS\/dm-crypt. Une fois l’emplacement du support identifi\u00e9 (\/dev\/sdx), on pourra effectuer l’op\u00e9ration de chiffrement avec cryptsetup<\/em> : <\/p>\n\n\n\n

sudo cryptsetup --cipher aes-xts-plain64 --key-size 512<\/span> --hash sha512 luksFormat \/dev\/sdx<\/pre>\n\n\n\n
Attention, cette commande effacera toutes les donn\u00e9es sur le support concern\u00e9 !<\/strong> Par ailleurs, en ce qui concerne le choix de la phrase secr\u00e8te, la documentation de cryptsetup<\/em> conseille de se limiter aux 95 caract\u00e8res imprimables des premiers 128 caract\u00e8res de la table ASCII; pour des raisons d’encodage. Au revoir donc caract\u00e8res accentu\u00e9s et autres caract\u00e8res particuliers propres \u00e0 la langue fran\u00e7aise. <\/p>\n\n\n\n
Ouverture<\/h4>\n\n\n\n
 Une fois le support chiffr\u00e9, nous allons pouvoir l’ouvrir. <\/p>\n\n\n\n
sudo cryptsetup luksOpen \/dev\/sdx nomDuDisque_crypt<\/pre>\n\n\n\n
S\u00e9curit\u00e9 suppl\u00e9mentaire (optionnel)<\/h4>\n\n\n\n
 Avant de formater, certaines sources pr\u00e9conisent de remplir le support de z\u00e9ro. Avec le programme dd<\/em> et une indication de la progression : <\/p>\n\n\n\n
dd if=\/dev\/zero of=\/dev\/mapper\/nomDuDisque_crypt status=progress<\/p>\n\n\n\n
Attention, cette op\u00e9ration n’est pas des plus rapides et peut durer plusieurs heures. <\/p>\n\n\n\n
Formatage<\/h4>\n\n\n\n
 Et enfin formater le support. <\/p>\n\n\n\n
sudo mkfs.ext4 -L nomDuDisque \/dev\/mapper\/nomDuDisque_crypt<\/pre>\n\n\n\n
Statut<\/h4>\n\n\n\n
 On peut v\u00e9rifier le statut du support : <\/p>\n\n\n\n
sudo cryptsetup -v status nomDuDisque<\/pre>\n\n\n\n
Qui nous donnera : <\/p>\n\n\n\n
\/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\u00e9ration r\u00e9ussie.<\/pre>\n\n\n\n
Fermeture<\/h4>\n\n\n\n
 Pour fermer le support chiffr\u00e9 : <\/p>\n\n\n\n
sudo cryptsetup luksClose \/dev\/mapper\/nomDuDisque_crypt<\/pre>\n\n\n\n
Sauvegarde du header<\/h4>\n\n\n\n
 \u00c9tant donn\u00e9 que toute corruption, alt\u00e9ration ou destruction du header LUKS entra\u00eene l’impossibilit\u00e9 d’acc\u00e9der \u00e0 l’ensemble du support chiffr\u00e9, il convient d’en effectuer une sauvegarde : <\/p>\n\n\n\n
cryptsetup luksHeaderBackup --header-backup-file \/chemin\/vers\/header \/dev\/sdx<\/pre>\n\n\n\n
Il faut renouveler la sauvegarde du header en cas de changement des phrases secr\u00e8tes (un support chiffr\u00e9 peut avoir jusqu’\u00e0 8 phrases secr\u00e8tes diff\u00e9rentes). <\/p>\n\n\n\n
Test d’un header<\/h4>\n\n\n\n
 En cas de tentative de restauration d’un header, il est possible de v\u00e9rifier que le header que l’on souhaite restaurer est le bon : <\/p>\n\n\n\n
sudo cryptsetup -v --header \/chemin\/vers\/header open \/dev\/sdx test<\/pre>\n\n\n\n
Qui doit renvoyer : <\/p>\n\n\n\n
Key slot 0 unlocked. Command successful.<\/pre>\n\n\n\n
Restauration d’un header<\/h4>\n\n\n\n
 Avec le support ferm\u00e9, on peut effectuer la restauration du header \u00e0 partir de son fichier de sauvegarde : <\/p>\n\n\n\n
sudo cryptsetup luksHeaderRestore \/dev\/sdx --header-backup-file \/chemin\/vers\/header<\/pre>\n\n\n\n
Gestion des phrases secr\u00e8tes<\/h4>\n\n\n\n
 Pour ajouter un mot de passe au support ou en supprimer un existant, on utilisera l’une des commandes : <\/p>\n\n\n\n
$ sudo cryptsetup luksAddKey \/dev\/sdx\n$ sudo cryptsetup luksRemoveKey \/dev\/sdx<\/pre>\n\n\n\n
Note : Permissions ext4<\/h4>\n\n\n\n
 Petit point technique relatif au syst\u00e8me de fichier avant de conclure. Il faut noter que par d\u00e9faut, suite au formatage, le propri\u00e9taire de la racine du support chiffr\u00e9 est root. En l’\u00e9tat, impossible sur mon syst\u00e8me de d\u00e9placer un fichier vers le support chiffr\u00e9 sans passer par un sudo cp<\/code>. Pour y rem\u00e9dier, on peut au besoin changer le propri\u00e9taire : <\/p>\n\n\n\n
sudo chown -R user \/run\/media\/user\/nomDuDisque<\/pre>\n\n\n\n
Il est \u00e9galement possible de donner les droits \u00e0 l’utilisateur ex\u00e9cutant la commande de formatage via sudo avec : <\/p>\n\n\n\n
sudo mkfs.ext4 -E root_owner=$UID:$GID \/dev\/sdx<\/pre>\n\n\n\n
Ou encore : <\/p>\n\n\n\n
sudo mkfs.ext4 -E root_owner=$UID:$GID -L nomDisque \/dev\/mapper\/nomDuDisque<\/pre>\n\n\n\n
Source: Format ext4 filesystem to be owned by regular user<\/a> <\/p>\n\n\n\n
Conclusion<\/h4>\n\n\n\n
 \u00c0 la suite de cet article, je dispose d\u00e9sormais d’un lot de cl\u00e9s USB chiffr\u00e9es sur lesquelles je vais pouvoir stocker mes fichiers importants \u00e0 sauvegarder. Afin de boucler la boucle, chaque header fera \u00e9videmment partie de la sauvegarde. Il me reste \u00e0 d\u00e9finir la fr\u00e9quence de rotation de ces sauvegardes froides, celle-ci sera certainement semestrielle, \u00e9ventuellement trimestrielle. Chaque lieu de sauvegarde pr\u00e9vu disposant de deux cl\u00e9s d\u00e9di\u00e9s, il suffira de g\u00e9n\u00e9rer la \u00ab\u00a0nouvelle\u00a0\u00bb cl\u00e9, puis de l’\u00e9changer avec \u00ab\u00a0l’ancienne\u00a0\u00bb. Pour la suite, je souhaite conduire une r\u00e9flexion sur mes donn\u00e9es locales: d\u00e9finir clairement les fichiers critiques, d\u00e9finir une arborescence g\u00e9n\u00e9rale pour l’organisation de mes donn\u00e9es. Il sera \u00e9galement n\u00e9cessaire de s’interroger sur la pertinence des donn\u00e9es (donn\u00e9es \u00e0 garder ?) et de d\u00e9finir quelles donn\u00e9es constituent \u00e9ventuellement une perte acceptable, afin de choisir le disque externe \u00e0 privil\u00e9gier (en fonction de son \u00e2ge principalement).<\/p>\n\n\n\n
Source : <\/p>\n\n\n\n