Catégorie : Crypto

Utilisation du jeton cryptographique Gnuk de secours

Dans un précédent article, j’avais décrit la manière de reprogrammer un STLinkv2 pour en faire un jeton cryptographique Gnuk. J’aurais pu m’arrêter là dans mes tests, mais alors, je n’aurais pas eu la garantie que ma solution de secours est valable. J’ai donc vérifié ma procédure, pas à pas, en reprenant si besoin les différents articles faisant offices de documentation. Voici quelques éléments à considérer.

Pour mener à bien la création d’un nouveau jeton cryptographique contenant les mêmes clés que mon jeton source, je commence par réinitialiser l’environnement sur le poste sécurisé ayant servi à la création des clés, après avoir pris soin de déchiffrer le dossier de sauvegarde contenant un exemplaire des clés :

export GNUPGHOME=/path/to/working/directory
cp dir-backup-mastersubkeys/* $GNUPGHOME/*

Pour la suite, l’export des clés sur le jeton s’effectue comme décrit dans les parties « Configuration de la cible » et « Export des sous-clefs vers la Yubikey » de mon article intitulé « GnuPG, clefs, YubiKey : c’est parti« . Par ailleurs, avant de commencer l’export des clés et pour compléter la configuration du jeton, on exécutera la commande kdf-setup dans l’éditeur de cartes GnuPG en mode admin, le but étant de renforcer la sécurité des clefs (Pour plus de détails à ce sujet, lire la partie « Protection des clefs » de l’article « Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre« ). Après import des clefs, on dispose alors d’un nouveau jeton cryptographique prêt à être utilisé.

Afin de faire fonctionner ma clé Gnuk avec gpg –card-status sans utiliser sudo, ajout d’une règle udev dans le fichier /lib/udev/rules.d/60-gnuk.rules.

ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0000", ENV{ID_MODEL_ID}=="0000", MODE="660", GROUP="users"

Puis application des changements.

# rechargement des règles
sudo udevadm control --reload-rules
# Éventuellement redémarrage du système
sudo reboot

Sur le poste cible, sauvegarde du dossier .gnupg/private-keys-v1.d. Puis suppression de son contenu.

cp -r .gnupg/private-keys-v1.d .gnupg/private-keys-v1.d-save
rm .gnupg/private-keys-v1.d/*
gpg --card-status

La commande gpg –card-status a pour effet de réimporter les informations des clefs présentes sur la carte. Ainsi, si j’effectue une commande pass pour déchiffrer l’un de mes mots de passe, c’est bien la nouvelle clé Gnuk qui est attendue et non ma Yubikey. Pour repasser à la Yubikey, il suffit de supprimer à nouveau le contenu du dossier private-keys-v1.d et le tour est joué (et d’inverser jeton Gnuk et YubiKey).

Je note qu’il n’est pas possible en l’état d’utiliser deux supports différents pour les mêmes clefs, sans une intervention de l’utilisateur ou une automatisation des changements à effectuer en fonction du support branché. Pour utiliser indifféremment deux supports différents, un internaute proposait de créer trois sous-clefs supplémentaires, soit six en tout et de répartir les trois nouvelles sous-clefs sur le support supplémentaire.

Effectuer ce que je peux qualifier de « test grandeur nature » était ici indispensable, afin de s’assurer de la robustesse de la solution retenue pour la sécurisation de mon environnement informatique. En effet, s’appuyer sur une solution sans jamais avoir vérifié les procédures de restauration, le retour à un fonctionnement normal, me semble bien périlleux. C’est donc un pas de plus sur le chemin de ma résilience informatique !

Source:
GnuPG mailing list – GnuPG card && using the backup secret key

Jeton cryptographique de dépannage avec Gnuk

Après avoir commencé à étendre l’usage de mes clefs gpg via Yubikey à différents aspects de mon informatique, se pose la question de la résilience du système. Que faire en cas de perte, détérioration ou malfonction de l’outil qui sert à accéder à mon répertoire de mot de passe et à me connecter à mes serveurs. L’idéal reste de posséder une seconde Yubikey NFC vierge en réserve, pour pouvoir redéployer rapidement ses clefs de sécurité à partir de l’une des sauvegardes que l’on aura pris soin d’effectuer. Une autre solution consiste à détourner un matériel de son usage premier pour en faire une clé de sécurité prête à accueillir mes clés le temps d’effectuer la transition vers une nouvelle Yubikey, ou un autre support du même type.

Pour répondre à ce besoin, j’ai découvert un programme nommé Gnuk, qui permet de transformer un microcontrôleur de type STM32F103 en une clé de sécurité supportant le protocole OpenPGP card version 2. Il se trouve que ce type de processeur équipe les cartes de programmation ST-Linkv2 et qu’on trouve ces dernières pour moins de 2 euros sur Aliexpress. Afin de réaliser quelques tests, j’en ai donc commandé trois chez deux vendeurs différents et j’ai reçu l’ensemble des cartes après environ deux dizaines de jours. Il faut un minimum de deux ST-Linkv2, car l’un sera utilisé pour programmer l’autre.

Une fois en possession des ST-Linkv2, je commence donc par retirer leur boîtier métallique afin d’avoir accès à la carte. Je vérifie la version du microcontrôleur équipant les cartes: STM32F103C8T6, ça ne devrait pas poser de problème. En examinant les cartes, je constate que j’ai reçu deux modèles différents, l’un avec des pastilles métalliques, l’autre avec des trous pour l’accès au processeur. Autre point gênant que je constaterai lors de mes premiers essais de reprogrammation du processeur, l’alternance des « pins » de connexion au bout du ST-Link au boîtier rouge ne correspond pas à ce qui est inscrit sur le boîtier, attention donc en branchant les câbles, de bien vérifier directement sur le PCB à quoi correspond chaque pin.

Continuer la lecture de « Jeton cryptographique de dépannage avec Gnuk »

Signer un commit Git

Je continue de tester les différentes possibilités offertes par l’utilisation d’un jeu de clés gpg, cette fois dans le domaine de la gestion de code avec git. L’idée consiste à signer ses commits git afin de garantir l’identité de la personne ayant réalisée les modifications.

Première étape, récupérer l’identifiant de sa clé PGP:

gpg --list-secret-keys --keyid-format LONG

Une fois en possession de l’identifiant, on met à jour la configuration git.

git config --global user.signingkey <ID-cle>

Ce qui se traduit par l’ajout suivant dans le fichier de configuration.

[user]
signingkey = 069DXXXXXX4A5F7A

Il est ensuite nécessaire d’ajouter le résultat de la commande suivante au niveau de son serveur git. Dans le cas de Github, la configuration s’effectue sur la même page que la page de configuration des clés SSH.

gpg --armor --export <ID-cle>

Passons à la signature à proprement parler. Pour signer un tag, on utilisera l’option -s.

git tag -s v1.5 -m 'my signed 1.5 tag'

Pour signer un commit, on utilisera cette fois l’option -S.

git commit -S -m 'signed commit'

Enfin, pour éviter d’avoir à ajouter en permanence l’option -s ou -S, on pourra configurer git pour toujours signer les tags et les commits.

git config --global commit.gpgsign true
git config --global tag.gpgsign true

Étant donné qu’il est possible pour n’importe quel utilisateur de réécrire l’historique d’un dépôt git et de modifier au passage les informations de l’auteur du commit, ou plus simplement, de modifier l’auteur le temps du commit, la signature des opérations git permet de s’assurer de l’identité de la personne ayant effectué l’opération et de se prémunir contre une éventuelle tentative d’usurpation d’identité (à condition que la clé ne soit pas compromise).

pass comme gestionnaire de mot de passe

Cela fait maintenant plusieurs années que j’utilise un gestionnaire de mot de passe pour retenir à ma place les informations d’accès aux différents services que j’utilise. J’avais jusqu’à présent choisi d’utiliser Keepass, en particulier pour ces fonctions de synchroniser via WebDAV et l’existence de ses nombreuses variantes qui permettent une utilisation sur GNU/Linux, Windows, Mac et Android sans trop de difficultés. Très récemment, j’ai décidé de changer de gestionnaire et de tester pass.

Quelques mots sur pass. Le programme de base prend la forme d’une simple ligne de commande. Chaque entrée consiste en un fichier dont la première ligne contient le mot de passe. On peut ensuite stocker diverses informations sur les lignes suivantes, comme url, username, clés d’API, etc. Tous les fichiers sont chiffrés par clé gpg. Lorsqu’on accède à l’un des fichiers de mot de passe, seul ce fichier sera déchiffré et non l’ensemble de la base comme c’est en général le cas avec les autres gestionnaires. La synchronisation est assurée par git, ce qui permet de bénéficier de l’historique du dépôt qui constituera notre base de référence de mot de passe.

Continuer la lecture de « pass comme gestionnaire de mot de passe »

gpg et pinentry

J’ai réalisé une modification du paramètre pinentry-program du côté de mon fichier de configuration de l’agent gpg à savoir ~/.gnupg/pgp-agent.conf :

# Ancienne valeur :
# pinentry-program /usr/bin/pinentry-curses
# Nouvelle valeur :
pinentry-program /usr/bin/pinentry

Ceci a pour effet d’utiliser le pinentry par défaut, soit pinentry-gtk-2 dans mon cas. J’effectue ce changement, car pinentry-curses n’arrive pas à s’afficher correctement si le déclencheur n’est pas une application lancée dans un terminal. J’ai notamment rencontré des problèmes au démarrage de Webstorm, lorsque celui-ci lance des commandes git en arrière plan pour rechercher d’éventuelles nouveautés. Si un terminal était déjà ouvert, l’interface curses y apparaissait, mais impossible d’y saisir correctement le PIN. Problème similaire en testant passmenu: pas d’affichage de l’interface.

Une fois la modification de configuration effectuée, on redémarre notre agent :

gpg-connect-agent reloadagent /bye