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_crypt

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_crypt 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_crypt

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_crypt

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 :

[ArchLinux] dunst: gestionnaire de notifications

Lors de l’installation et du test de udiskie, j’ai constaté l’apparition de l’erreur suivante dans mon terminal:

Failed to show notification: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files

Après une recherche rapide, il semble que je ne possède pas de gestionnaire de notification installé sur mon système. Je me suis donc tourné vers dunst :

sudo pacman -S dunst

Il ne reste plus qu’à copier le fichier de configuration par défaut vers mon .config :

mkdir -p ~/.config/dunst
sudo cp /usr/share/dunst/dunstrc ~/.config/dunst
sudo chown <user>:<group> .config/dunst/dunstrc

Puis à s’assurer du démarrage automatique de dunst au lancement de mon gestionnaire de fenêtre i3 en modifiant le fichier ~/.config/i3/config et en y ajoutant:

exec --no-startup-id dunst -config ~/.config/dunst/dunstrc

Et voilà !

[ArchLinux] Montage auto des supports amovibles

Jusqu’à présent, mon système Arch était en mesure de monter les supports amovibles, ces derniers s’affichant correctement dans PCManFM. Néanmoins, le démontage par simple clic ne fonctionnait pas: en cause un problème de manque de droit.

À la lecture récente d’un article de blog, je suis tombé sur un court passage vantant les mérites de l’utilitaire udiskie (avec mention de la possibilité de l’intégrer avec pass pour l’ouverture des supports chiffrés LUKS). Je me suis donc lancé dans l’intégration du programme à mon système.

Dans un premier temps, installation via pacman:

sudo pacman -S udiskie

Une fois installé, lancement automatique à l’ouverture de session en ajoutant la ligne suivante dans mon .xinitrc :

udiskie -2 -s &

Les supports amovibles tels que les clés USB, ou les disques durs externes sont désormais démontés sans erreur !

Devoxx France 2018 – Petite sélection

À la mi-avril avait lieu le Devoxx France à Paris, cycle de conférence sur 3 jours, à destination des développeurs. Voici quelques interventions qui ont retenu mon attention.

Laissez tomber Express, passez à son successeur
Présentation de Koa. Plus léger qu’Express, avec juste le minimum et surtout le support des fonctions async par défaut.

Gagner des super pouvoirs avec le terminal
Petit tour d’horizon sur tout ce qu’il est possible de faire directement dans son terminal (avec les « bons » logiciels).

Attention ! Ne mets pas cette clé tu risques de te faire hacker très fort !
Sur le danger de tout ce qui ressemble à une clé USB et ce qu’il est possible de faire avec un micro-controleur très simple.

T’es plutôt merge ou rebase ?
Petit point sur Git.

Les Tests End to End avec des raspberry pi chez leboncoin
Un impressionnant système de test auto sur mobile, construit de zéro.

Quand une documentation devient un problème et que faire alors
Bonnes pratiques et retour d’expérience sur la gestion d’une documentation.

NodeJS 5 bonnes raisons pour lesquelles vous devriez y jeter un oeil
Introduction à NodeJS et l’environnement JS en 2018.

RxJS Les clefs pour comprendre les observables
Quelques explications sur les observables. Quelques exemples intéressants.

Angular et performances
Optimiser Angular. Nouveautés.

RetourAuxSources Les cookies HTTP
Tous savoir sur les cookies !

Ajout du champ Certification Authority Authorization (CAA) à la zone DNS

Je m’étais intéressé il y a de cela plusieurs semaines aux entêtes de sécurité du protocole http et j’en avais également profité pour regarder du côté de la zone DNS. Je m’étais donc occupé d’ajouter un champ CAA, pour Certification Authority Authorisation à la zone DNS de mon domaine.

Quelques mots sur le champ en question. Le but est d’indiquer publiquement quelles autorités de certification sont aptes à générer un certificat pour le domaine concerné (zéro, une ou plusieurs). Si une tentative de génération d’un certificat devait être tenté par une autre autorité, celle-ci devrait échouer car ne figurant pas comme autorité autorisée. A condition bien sûr que l’autorité de certification prenne en compte le champ CAA et le respecte. L’objectif étant de réduire le risque que quelqu’un demande et obtienne un certificat pour votre domaine sans y être autorisé.

Pour la mise en place sur unicoda.com, cela nous donne la configuration suivante :

Trois paramètres possibles: issue, issuewild et iodef. Dans l’ordre, issue restreint la génération des certificats pour le domaine, issuewild restreint la génération de certificat « wildcard » (et ignore tout autre champ comportant issue). Enfin, iodef permet de spécifier un moyen de communication (mailto, http ou https) pour signaler une violation du champ CAA.

Pour davantage d’informations, rien de mieux que d’aller lire directement la RFC : RFC 6844. On peut également consulter les explications de Let’s Encrypt.