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
