Du fonctionnement des sous-clés avec GPG

Pour commencer mon explication, créons une nouvelle identitée pour monsieur Prout, par défaut, sur gpg : gpg --gen-key

On remplis le nom, le mail, on entre une phrase secrète (attention gpg ne vous prévient pas que votre mot de passe n'est pas assez complexe et plante silencieusement). Et la si on liste les clés disponibles :

$ gpg -K
sec   rsa3072 2020-12-15 [SC] [expire : 2022-12-15]
      6EEFD1BAF2205BB81B746999022229C692ABDD61
uid          [  ultime ] Prout prout <prout@prout.prout>
ssb   rsa3072 2020-12-15 [E] [expire : 2022-12-15]

On voit deux lignes avec des informations de clés (algorithme, taille, date d'expiration):

sec   rsa3072 2020-12-15 [SC] [expire : 2022-12-15]
ssb   rsa3072 2020-12-15 [E] [expire : 2022-12-15]

La première est, selon le vocabulaire de gpg, la clé maître. La seconde est une "sous clé de chiffrement". En realité, les deux lignes correspondent chacune a une paire de clé publique/privée qui sont indépendantes l'une d'entre elles. Notez bien, à chaque fois qu'on parle de clé, c'est en réalité un abus de langage pour parler d'un couple de clé privée/publique. Sous le capot, GPG à simplement des métadonnées qui associent aux clés ces "statuts" particulier.

D'autre part, on voit aussi une information entre crochet : SC ou E. Ces lettres correspondent aux 3 rôles qu'une clé peut avoir :

• S: signature, la clé privée du couple sert à signer un message et toutes les personnes ayant la clé publique peuvent le déchiffrer, et s'assurer que le message provient bien le personne qui possède la clé.
• C: certify, la clé privée sert à signer des clés publiques, pour établir des relations de confiance. C'est avec cette clé là que vous pouver certifier les clés d'autres personnes, ou vos propre sous clés, pour apporter votre preuve de confiance à des identités.
• E: encrypt, la clé publique sert à chiffre un message que seule la personne possédant la clé privée (nous) pourra déchiffrer.

Il existe un dernier rôle, plus récent, noté 'A', servant a décrire le rôle d'authentification d'une clé, dans le cas par exemple de l'utilisation de clé gpg pour l'authentification dans le protocole SSH.

En réalité, tout couple de clé privée / clé publique peut réaliser ses 4 rôles. Il s'agit simplement d'une séparation arbitraire des pouvoirs que GPG (soit par défaut, soit par vos choix) applique.

Par défaut donc, gpg vous crée une clé SC, qui à le double pouvoir de signer des messages et de certifier des identités; puis une clé E qui est celle qui va être utilisée pour déchiffrer des messages qu'on vous envoie. A noter qu'il est tout à fait possible de faire en sorte que sa clé maître n'ai pas le rôle S, uniquement le C, et avoir une autre sous-clé qui ai le rôle S.

Une question naturelle qui se pose est alors, pourquoi se compliquer la vie et ne pas avoir une seule paire de clé qui a les 3 rôles, au lieu de ségreger le rôle de chiffrement à une autre clé ? Une partie de l'explication vient du fait que certains algorithmes de chiffrement (RSA par exemple) ont besoin d'avoir des clés différentes pour fonctionner de façon sécuritaire.

Par exemple, il y a un faille assez basique si vous utilisez la même clé privée de votre paire de clé pour signer et déchiffrer vos messages, imaginons qu'Eve récupère un message chiffré à votre destination, si elle parvient par social ingeneering à vous demander de signer ce dit message, en réalité vous le déchifrerez et lui enverrez puisque d'un point de vue mathémique il s'agit de la même chose.

Donc, gpg pour contrer va par défaut nous créer deux paire de clés, l'une est utilisée pour signer et certifier, l'autre pour déchiffrer.

Lorsque l'on envoie nos clés sur les serveurs de partage de clés publiques, avec gpg --send-keys, gpg va envoyer les clés publiques de tout nos couples de clés présents, donc la SC et la E, mais aussi toutes celles d'autres sous-clés que l'on aurait pu créer.

Pass est un outil KISS de gestion des mots de passes, les mots de passes sont simplement stockées sous l'arborescence que vous voulez, et chiffré avec votre clé gpg.

Si vous avez suivi, par défaut ils sont chiffrés donc avec la plus récente sous-clé E que vous possédez.

$ pass init 6EEFD1BAF2205BB81B746999022229C692ABDD61
$ pass insert --generate test
$ gpg .password-store/test.gpg
gpg: chiffré avec une clef RSA de 4096 bits, identifiant A3AFEC937A66A529, créée le 2020-12-15

Si vous avez plusieurs sous-clé de chiffrement, vous pouvez forcer pass à chiffre tous vos mots de passes avec toutes les clés publiques des sous-clés de chiffrement que vous avez, en utilisant l'astuce du point d'exclamation :

$ pass init A3AFEC937A66A529! C5E21A31259E52EF!
$ pass insert --generate test
$ gpg .password-store/test.gpg
gpg: chiffré avec une clef RSA de 4096 bits, identifiant A3AFEC937A66A529, créée le 2020-12-15

Liens pour aller plus loin :

• https://wiki.debian.org/fr/Subkeys
• https://serverfault.com/questions/397973/gpg-why-am-i-encrypting-with-subkey-instead-of-primary-key/399366
• https://security.stackexchange.com/questions/186649/gpg-masterkey-and-subkey-for-encryption-and-signature-and-default-keys
• https://lists.zx2c4.com/pipermail/password-store/2018-January/003178.html