Les clés GPG#

Je me suis enfin motivé à regarder comment se générer ses propres clés GPG. Je n’expliquerais pas ce qu’est GPG, il y a des gens beaucoup plus capable et à mème d’expliquer ce que c’est sur le net. Vous trouverez des articles tres poussé sur le sujet qui vous expliqueront en détail comment ça fonctionne.

Si t’es développeur ou admin et que tu mets ta clé SSH dans ~/.ssh/ en clair sur ton disque, ou que tu n’as jamais signé un mail de ta vie, cet article te concerne.

Dans mon cas je voulais _ètre à mème de pouvoir chiffrer mes mails, chiffrer des fichiers, m’authentifier en ssh via GPG bref plein de truc super cool, le tout en utilisant une Yubikey.

Les Yubikey’s#

Une Yubikey c’est une petite clé usb, j’ai fait le choix d’en avoir de deux types une en USB-C et une en USB-A. Les deux ont le NFC pour aussi ètre utiliser depuis mon smartphone.

La procédure#

Génération de sa clé maitre#

Il est fortement conseillé d’effectuer ces opérations depuis une machine déconnecter d’internet et depuis un live usb. Bien sur il faut une distribution avec tout le nécessaire pour générer tout ce dont nous avons besoin. Dans mon cas j’ai fait le choix de me faire un clé usb Tails comme préconisé dans un blog indiqué dans les sources plus bas. J’ai donc téléchargé la dernière image de Tails et j’en ai fais une clé usb bootable depuis mon pc portable. Je branche ma clé usb, un petit lsblk qui me permet de m’afficher le device correspondant et de ne pas faire de bétises. sudo dd bs=4M conv=fsync oflag=direct status=progress if=Téléchargements/tails-amd64-6.17.img of=/dev/sda

J’attend que ce soit fini puis je redémarre ma machine en bootant sur la clé USB. Par défaut tails me propose le language que je veux utiliser, le clavier et la localization. J’ouvre ensuite un terminal et on vas pouvoir commencer à travailler.

On va donc d’abord générer notre clé maitre :

gpg --expert --full-generate-key

On va vouloir ajouter le flag --expert, ce dernier va nous permettre de générer plus que juste des clés pour signer ou chiffrer. (Nécessaire pour l’authentification SSH notamment.) Le flag --full-generate-key va nous ouvrir un petit menu interactif.

Voici ce qui nous est retourné :

➜  ~ gpg --expert --full-gen-key
gpg (GnuPG) 2.4.7; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card

Ici ce qui vas nous intéresser, c’est la 11ème options, en effet il est possible de générer des clés RSA ou encore DSA mais les plus costaude en matiere de cryptographie sont de ce que j’ai entendu dire les clés ECC a base de courbe éliptique. Me demander pas pourquoi comment les maths c’est pas mon domaine. Mais normalement vous devrier ètre tranquille.

Et surtout nous allons pouvoir indiquer les capabalities de chaque clé, nous allons pouvoir ètre beaucoup plus granulaires.

En l’occurence, nous allons vouloir générer une clé maitre qui ne pourra faire que de la certifications, c’est à dire certifier d’autre clés.1

Your selection? 11

Possible actions for this ECC key: Sign Certify Authenticate
Current allowed actions: Sign Certify

   (S) Toggle the sign capability
   (A) Toggle the authenticate capability
   (Q) Finished

On peut voir les actions authorisé déja sélectionné par défaut Sign et Certify, vous me direz pourquoi si ce n’est pas une bonne pratiques est-ce proposé comme cela par défaut ? Réferer vous à ce lien2 Et on va donc pouvoir interactivement changer les capacité pour notre clé, c’est notre clé maitre donc elle ne vas pouvoir que Certifier. On peut donc Toggle la capacité signature en tapant S. Le menu nous ai de nouveau affiché mais cette fois juste avec la possibilité de Certifié ce que l’on désire. Nous pouvons donc quitter avec Q. On peut séléctionner quel courbe eliptique nous désirons. Si vous ne savez pas quoi choisir, ed25519 est le choix standard aujourd’hui — rapide, sécurisé, largement supporté. Puis nous allons pouvoir mettre une expiration sur notre clé master:

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years

Il est conseillé de mettre une expiration au cas ou cette dernière fuiterais, nous sommes censé la rangé dans un coffre fort, caché dans notre Bunker mais on ne sait jamais un acteur malveillant pourrait mettre la main dessus et compromettre toutes les sous clés que vous avez généré. A noté qu’il serait possible de reporter la date d’expiration d’une clé, enfin de rallonger sa date d’expiration mème. Pas encore tester mais je pointe le liens correspondant.3 Le prompt vas vous indiquer à quel date la clé est censé expirer et vous demandant si cela vous convient. Puis vous allez devoir rentrer votre Nom, personnelement j’y ai mis mon pseudo, je ne compte pas trop exposer ma vrai identité sur internet. Car mon nom apparaitrait dans ma clé publique que je veux partager partout. Pour certains cas d’usage bien évidemment il faut montrer pate blanche notemment chez les contributeurs de gros projets opensource, il est nécessaire d’avoir sa vrai identité d’indiquer, ces derniers se retrouve lors d’évenement opensource pour s’entre certifier leur clés en présentant une pièce d’identité.4 Vous pouvez ensuite fournir votre email. Toutes ces informations sont liés à une identité d’utilisateur uid, il est possible d’en ajouter d’autre a posteriori. Petit récapitulatif vous demandant de vérifier si toutes les informations entrés sont correct, si oui vous pouvez continuer. Il vas vous demander d’entrer une passphrase afin de rajouter une sécurité au cas ou quelqu’un mettrait la main sur votre clé maitre. Chose assez marrante, pendant la génération d’une clé, gpg va vous demander de taper au clavier ou bouger la souris afin de générer des octets aléatoires et ainsi augmenter l’entropy.(Des fois vous avez a peine le temps de faire quoi que ce soit). Bref notre clé maitre à été généré. On peut voir un petit récapitulatif comme celui ci :

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: directory '/home/b0dian/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/b0dian/.gnupg/openpgp-revocs.d/3FF5BE6BA84EDEDD21C4AE0DC1DDF61ADDB0003F.rev'
public and secret key created and signed.

pub   ed25519 2025-07-18 [C] [expires: 2035-07-16]
      3FF5BE6BA84EDEDD21C4AE0DC1DDF61ADDB0003F
uid                      test <test@ŧest.com>

On peut voir beaucoup d’informations, pub nous indique le type de clé publique ici ed25519, la date de création de cette clé, les capactié de cette dernière, c’est une clé master donc uniquement de la certification et enfin a quel date cette dernière expire. On à a la ligne l’identifiant de la clé, c’est un long identifiant unique permettant d’identifié la clé. Et enfin l’identifiant utilisateur, nom et mail.

Fiou c’était du boulot quand mème. Passons à la suite.

Generer nos sous clés à partir de notre clé maitre#

Grace à notre clé maitre, nous allons pouvoir générer(enfin plus exactement certifier des sous clé que nous allons générer). On est donc reparti avec les commandes gpg !

gpg --expert --edit-key test@test.com

Alors la on peut utiliser l’identifiant unique de notre clé maitre généré plus tôt mais j’ai également vu que l’on pouvait utiliser le mail correspondant. Je pense uniquement si ce mail n’est pas lié à d’autre clé afin de ne pas se mélanger les pinceaux. Dans le cas présent je n’ai qu’une clé avec ce mail ça m’a l’air de fonctionner. (Il doit bien y avoir des puristes qui crie au scandale je m’en tape).

Voici ce que la commande nous retourne :

gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (12) ECC (encrypt only)
  (13) Existing key
  (14) Existing key from card

On va créer 3 sous-clés distinctes, une pour chaque usage : signer, chiffrer, s’authentifier. On répète donc addkey trois fois, en sélectionnant l’option 11 (ECC avec capabilities custom) à chaque fois, sauf pour la clé de chiffrement où on prend le 12 (ECC encrypt only) car OpenPGP impose un algorithme différent pour le chiffrement (Curve25519/ECDH).

Sous-clé de signature (Sign only) On toggle tout pour ne garder que S.

Sous-clé de chiffrement (Encrypt only) Option 12 directement, pas besoin de toggler.

Sous-clé d’authentification (Authenticate only) Option 11, on toggle pour ne garder que A.

À la fin un petit gpg --list-secret-keys nous confirme le résultat :

sec   ed25519 2025-07-18 [C] [expires: 2035-07-16]
      3FF5BE6BA84EDEDD21C4AE0DC1DDF61ADDB0003F
uid           [ultimate] Dimitri <monmail@example.com>
ssb   ed25519 2025-07-18 [S] [expires: 2026-07-18]
ssb   cv25519 2025-07-18 [E] [expires: 2026-07-18]
ssb   ed25519 2025-07-18 [A] [expires: 2026-07-18]

Parfait, on a bien notre clé maître [C] et nos 3 sous-clés chacune avec son rôle bien défini.

Sauvegarder ses clés avant tout#

Étape CRITIQUE. Une fois les sous-clés transférées sur la Yubikey, elles n’en sortent plus jamais. Si tu perds ta Yubikey sans backup, tu perds tes clés. Point.

On va donc exporter tout ce qu’on a avant de toucher quoi que ce soit.

D’abord on liste nos clés pour récupérer l’identifiant :

gpg --list-secret-keys

Puis on exporte la clé maître et les sous-clés :

gpg --export-secret-keys --armor <ID> > master-key.asc
gpg --export-secret-subkeys --armor <ID> > subkeys.asc
gpg --export --armor <ID> > public-key.asc

Et le certificat de révocation qui a été généré automatiquement lors de la création :

cp ~/.gnupg/openpgp-revocs.d/<ID>.rev revocation-cert.asc

On copie tout ça sur un support chiffré, déconnecté d’internet — une clé USB chiffrée avec LUKS par exemple, rangée dans un endroit sûr. Perso j’en ai fait plusieurs copies.

À noter qu’on est toujours sur Tails à ce stade, donc tout est en RAM. Rien n’est écrit sur le disque de la machine hôte. C’est pour ça qu’il faut vraiment prendre le temps de bien copier ces fichiers avant d’éteindre.

Transférer les sous-clés sur les Yubikeys#

Une fois le backup bien au chaud, on peut se lancer. On branche la première Yubikey et on entre dans le mode édition de la carte :

gpg --edit-key <ID>

Puis on tape key 1 pour sélectionner la première sous-clé (la [S]), une étoile apparaît à côté pour indiquer qu’elle est sélectionnée. On tape ensuite keytocard et GPG nous demande sur quel slot la mettre :

Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1

On répète l’opération pour les deux autres sous-clés :

  • key 2 puis keytocard → slot 2 (Encryption key)
  • key 3 puis keytocard → slot 3 (Authentication key)

Puis save pour valider.

Important : GPG remplace les sous-clés locales par un pointeur vers la carte (ssb>). C’est pour ça qu’il fallait avoir fait le backup avant — les clés privées ne sont plus sur la machine, elles sont sur la Yubikey.

Pour la deuxième Yubikey c’est exactement la même procédure, mais il faut d’abord réimporter les sous-clés depuis le backup avant de refaire le transfert. Sinon GPG voit déjà les pointeurs carte et ne peut plus rien transférer.

gpg --import subkeys.asc

On branche la deuxième Yubikey et on répète le keytocard pour chaque sous-clé.

Vérifier que tout est en ordre#

On peut vérifier l’état de nos clés avec :

gpg --list-secret-keys

Les sous-clés affichées avec ssb> (avec le chevron) indiquent qu’elles sont sur une carte. Si tu vois ssb# ça veut dire que la clé privée n’est plus disponible localement (normal après le transfert sans réimport).

Pour vérifier ce qui est sur la Yubikey :

gpg --card-status

Ça affiche les infos de la carte, les clés présentes sur chaque slot, et leur fingerprint.

Cas d’usage concret : l’authentification SSH#

C’est probablement le cas d’usage le plus utile au quotidien pour un profil DevOps. L’idée : utiliser la sous-clé d’authentification sur la Yubikey à la place d’une clé SSH classique. Avantage : ta clé privée ne quitte jamais la carte. Jamais.

Configurer gpg-agent pour SSH#

Il faut indiquer à gpg-agent qu’il doit aussi gérer le socket SSH. Dans ~/.gnupg/gpg-agent.conf :

enable-ssh-support

Puis dans ton .bashrc ou .zshrc :

export GPG_TTY=$(tty)
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent

On recharge le shell et on vérifie que l’agent voit bien la clé :

ssh-add -L

Ça doit retourner ta clé publique SSH dérivée de ta sous-clé GPG [A]. C’est cette clé publique à coller dans ~/.ssh/authorized_keys sur tes serveurs.

Utilisation#

Rien de particulier ensuite, on se connecte comme d’habitude :

ssh user@monserveur.bzh

GPG-agent intercepte la demande d’authentification, la transmet à la Yubikey, et selon ta configuration la Yubikey peut demander un PIN ou un simple touch physique. Si quelqu’un vole ta machine, sans la Yubikey il ne peut pas s’authentifier. Beau non ?

Bonus : signer ses commits Git#

Tant qu’on est là, autant aussi signer ses commits avec la sous-clé [S] :

git config --global user.signingkey <ID>
git config --global commit.gpgsign true

Chaque git commit demandera un touch sur la Yubikey. Tes commits apparaîtront avec un joli badge “Verified” sur GitHub/GitLab.

Sources#

Notes#

  1. Un article intéressant sur les bonnes pratiques GPG ↩︎

  2. Un petit thread intéressant qui parle d’historique et d’avis personnel ↩︎

  3. Un article détaillant comment rallonger la date d’expiration d’une clé GPG ↩︎

  4. Article Wikipedia détaillant le principe d’une Key Signing Party ↩︎