Catégorie : Crypto

Ayant fait l’acquisition début d’année, d’un nouveau disque vierge d’une capacité de stockage de 1To, je me suis enfin occupé de sa configuration, afin de pouvoir y déposer les données numériques dont je souhaite absolument éviter la perte.

Mon choix s’est porté sur un disque de marque Seagate au format 2.5″, et j’ai choisi un boîtier « Mobility Disk S8 » de la marque Advance, pour protéger le disque et simplifier sa connexion comme disque externe. Esthétiquement parlant, le boîtier est très bien, sobre, en aluminium et simple dans l’installation du disque. Ce sera désormais mon choix par défaut pour les prochains disques externes dont je pourrais avoir besoin. En cas de problème sur le disque ou l’interface de connexion, il est en effet bien plus simple de changer l’un ou l’autre. Chose qui est impossible sur les disques externes tout assemblés comme ceux de Western Digital, où toute l’électronique est solidaire du disque.

Place ensuite à l’étape d’initialisation du disque chiffré et direction mon article « Chiffrer un support » de 2018, pour suivre la procédure et vérifier que celle-ci est toujours valable; ce qui est le cas.

Au passage, après avoir généré aléatoirement et stocké le mot de passe de la partition chiffrée dans pass, sous une arborescence spécifique crypt/usb/ et sauvegarder dans une entrée nommée suivant l’UUID du disque, j’en profite pour mettre à jour ma configuration de udiskie. udiskie, programme qui s’occupe de la gestion des médias amovibles sur mon système.

Je modifie donc le fichier .config/udiskie/config.yml pour y ajouter le contenu suivant:

program_options:
  tray: auto
  automount: false
  notify: true
  password_prompt: ["pass", "crypt/usb/{id_uuid}"]

Avec ces quelques lignes, j’indique au programme d’exécuter la commande pass pour accèder au mot de passe stocké dans crypt/usb et identifié par son UUID, d’où le choix du nommage au paragraphe précédent. UUID du disque qu’il est possible de connaître de plusieurs manières (décrites dans le wiki ArchLinux, partie Persistent block device naming – by-uuid), dont celle-ci:

$ ls -l /dev/disk/by-uuid/

On effectue ensuite un petit test pour vérifier le bon fonctionnement de la configuration via la commande:

$ udiskie-mount -r /dev/sdX

Cela fonctionne correctement. Après un redémarrage, je constate néanmoins que c’est la fenêtre de demande de mot de passe par défaut qui s’affiche lorsque j’utilise PCmanFM comme explorateur de fichier. Il me semble avoir résolu le problème en désactivant le montage automatique configuré dans PCmanFM. C’est alors bien udiskie qui prend la main.

Enfin, dernière étape incontournable pour conclure, la sauvegarde des entêtes du disque chiffré, afin de pouvoir restaurer un accès aux données chiffrées en cas de corruption des entêtes présentes sur le support. Une corruption des entêtes d’un disque chiffré entraîne en effet une impossibilité totale d’accéder à l’ensemble du contenu, et cela, même si cette partie du disque est parfaitement saine. C’est donc une opération à faire absolument, lorsqu’on décide de chiffrer un disque et on s’évitera ainsi des sueurs froides en cas de problème sur les entêtes.

Après avoir réalisé quelques tests du jeton cryptographique fraîchement créé à partir d’un ST-Linkv2 et de Gnuk, j’ai cherché à nettoyer les clefs stockées sur ce jeton de test. Mes recherches m’ont guidé vers le dossier tool du dépôt gnuk, qui contient plusieurs scripts permettant de réaliser divers opérations sur le jeton. L’instruction factory-reset ne fonctionnant pas sur les jetons Gnuk, je me suis tourné vers le script gnuk_remove_keys_libusb.py. Script qui nécessite d’arrêter gpg-connect-agent avant d’être exécuté. Je n’ai au final pas pu valider son fonctionnement, pour la raison que vous découvrirez au paragraphe suivant.

gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye
./tool/gnuk_remove_keys_libusb.py -p 

Lors de mes premières tentatives, je n’avais pas utilisé le paramètre p de la commande et celle-ci utilisait donc le PIN par défaut à savoir 12345678 pour le PIN admin. Ayant changé ce dernier, j’ai très vite atteint la limite d’essai autorisé et ai rendu mon jeton inopérant. Il a donc fallu s’intéresser à la façon de réinstaller Gnuk sur un jeton bloqué.

Pour effectuer la reprogrammation, il faut connecter le jeton à notre ST-Link comme dans l’article précédent. Afin de déverrouiller le jeton, il est également nécessaire de connecter les pins 7 (NRST) et 8 (VSSA) du micro-contrôleur STM8F103. Une fois les deux pins connectés, avec la pointe de mesure d’un multimètre par exemple, il faut lancer openocd comme précédemment. Une fois le programme en cours de fonctionnement, sans erreur ni tentative permanente de reconnexion, on peut arrêter de maintenir la connexion entre les deux pins.

Pour repérer les deux pins concernés, voir le schéma ci-dessous.

L’opération n’étant pas des plus évidentes, j’ai dû effectuer plusieurs tentatives avant de pouvoir reprendre la main pour reprogrammer le micro-contrôleur. Par ailleurs, impossible de me reconnecter correctement aux pins du ST-Link, j’ai donc été obligé de sortir le fer à souder, d’autant plus que le STM32 est positionné de l’autre côté de la carte et donc impossible d’y accéder pour connecter les deux pins en utilisant le précédent système de connexion.

Pas de changement dans les instructions de programmation à part l’ajout du mass_erase pour supprimer tout le contenu de la mémoire.

halt
stm32f1x unlock 0
reset halt
stm32f1x mass_erase 0
flash write_bank 0 ./src/build/gnuk-vidpid.bin 0
stm32f1x lock 0
reset halt

Après reprogrammation, le jeton est à nouveau vierge de toutes informations et prêt à recevoir de nouvelles clés!