J’ai récemment démarré une mission chez un client. Les équipes SRE utilisent des clefs GPG (GNU Privacy Guard). C’est un outil libre, venant de PGP, qui permet de chiffrer, déchiffrer et signer tout un tas de choses. 😅
Dans mon cas, il est utilisé pour le keyring partagé avec un password store afin de communiquer les mots de passe. Au même titre que l’on utiliserait KeePass. Dans notre cas, c’est gopass qui fait office de gestionnaire de secrets.
GPG est également utilisé pour s’échanger des fichiers chiffrés.
Vous trouvez que c’est un peu flou ? Et bien, c’est aussi ce que j’ai ressenti lorsque l’on m’a parlé de GPG pour la gestion des mots de passe et du partage de fichiers au sein de l’équipe.
Mais ne vous inquiétez pas ! On va reprendre les bases ensemble et comprendre comment cela fonctionne.
Le sujet va être découpé en deux articles. Ici, nous allons parler uniquement du fonctionnement de GPG, du certificat de rénovation et de la génération de clefs.
Un second article viendra en complément pour détailler son utilisation.
GPG, comment ça marche ?
Avant de se lancer à toute vitesse dans le fonctionnement de GPG, je vous propose d’aller faire un tour sur cette page, si vous n’êtes pas à l’aise avec le principe de clefs publique et privée.
Brièvement, la clef publique va servir à chiffrer un message qui va être déchiffré uniquement à l’aide de la clef privée associée. Il faudra partager votre clef publique ET SEULEMENT VOTRE CLEF PUBLIQUE à vos correspondants.
Ces personnes vont chiffrer le message avec votre clef publique. De ce fait, vous serez le seul à être en mesure de déchiffrer le message. Vous êtes l’unique détenteur de la clef privée associée, permettant de déchiffrer le message.
Si ce n’est toujours pas clair, vous trouverez pas mal d’informations sur Internet. 😁
Il est important de bien saisir ce mécanisme. GPG repose en grande partie sur ce système.
Il paraît qu’une image vaut 1000 mots, voici une représentation graphique du paragraphe précédent :
Maintenant, que le fonctionnement s’est éclairci (enfin, j’espère 😅), on va faire un point sur les composants d’une clef GPG.
Commençons par l’uid (User Identifiant), comme son nom l’indique, il correspond à l’identifiant d’une clef. Jusque-là, ça va ? Coooool, on continue !
Il est composé comme suit :
Prénom NOM (commentaire) <adresse mail>
Chaque clef GPG comporte 3 éléments majeurs :
- “pub” qui est la partie publique
- “sub” qui indique une sous-clef
- “uid” qui est la partie identifiant, avec une adresse mail et un nom/prénom
Voici un exemple d’une clef GPG :
pub rsa3072 2022-06-29 [SC] [expires: 2024-06-28]
92796670396483E86DAF97FC8600C597C7D0B8F8
uid [ultimate] Antoine <antoine@learngpg.com>
sub rsa3072 2022-06-29 [E] [expires: 2024-06-28]
On retrouve bien nos 3 éléments pub, uid et sub. 🙂
Générer une paire de clefs
Maintenant, rentrons dans le vif du sujet !
Nous allons créer notre clef GPG qui va nous identifier “numériquement” et certifier notre identité.
Avant la création, nous pouvons regarder si nous avons déjà des clefs présentes sur notre machine :
# Pour lister les clefs secrètes :
$ gpg -K
# Pour lister les clefs publiques :
$ gpg -k
S’il n’y a pas d’ouput, c’est que vous n’avez pas de clef. 🙂
Pour procéder à la génération, nous allons utiliser la commande gpg --full-gen-key
La première question à laquelle il falloir répondre, est quel type de clef que nous désirons :
$ gpg --full-gen-key
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
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 (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(14) Existing key from card
Par défaut, c’est le type RSA asymétrique, c’est très bien, choisissons l’option 1.
Ensuite, on nous propose de créer une clef de 3072 bits. Je vous conseille de toujours les créer avec au moins 4096 bits :
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Ici, il va falloir indiquer la durée de validité de notre clef. Il est recommandé d’avoir une durée de 2 ans. Pour ça, il faut renseigner 2y :
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
Key is valid for? (0) 2y
Key expires at Sat Jun 29 16:53:10 2024 UTC
Is this correct? (y/N) y
À partir de cette date, plus personne ne pourra l’utiliser pour le chiffrement de données. Pas d’inquiétude, il sera possible d’éditer la clef pour spécifier une nouvelle durée de validité.
On nous demande à présent votre nom. Pour rappel, le but d’une clef n’est pas de vous rendre anonyme mais bel est bien de vous identifier de manière certaine. Je vous encourage à utiliser votre véritable nom. Il nous est demandé également de renseigner une adresse email. Au même titre que votre identité, utilisez une véritable adresse, que vous possédez. Pour le commentaire, libre à vous d’en ajouter un ou non :
GnuPG needs to construct a user ID to identify your key.
Real name: Antoine Mayer
Email address: demo@antoinemayer.fr
Comment: Clef demo article de blog
You selected this USER-ID:
"Antoine Mayer (Clef demo article de blog) <demo@antoinemayer.fr>"
Un récapitulatif des informations renseignées est affiché. Si tout est bon, nous pouvons valider.
La dernière étape consiste à mettre une passphrase qui va protéger votre clef privée. Ici, il s’agit de mettre un mot de passe vraiment, vraiment, vraiment balèze !
Etttt TADAAAAM GPG a réussi à générer nos clefs :
public and secret key created and signed.
pub rsa4096 2022-07-03 [SC] [expires: 2024-07-02]
CFD6DA6900A81BF044DFF18C8CE5FBBD2E9BD4EC
uid Antoine Mayer (Clef demo article de blog) <demo@antoinemayer.fr>
sub rsa4096 2022-06-30 [E] [expires: 2024-06-29]
Analyse des clefs créées
Voici le résultat de la commandegpg -K
pour obtenir la liste de nos clefs secrètes :
$ gpg -K
/root/.gnupg/pubring.kbx
------------------------
sec rsa4096 2022-07-03 [SC] [expires: 2024-07-02]
CFD6DA6900A81BF044DFF18C8CE5FBBD2E9BD4EC
uid [ultimate] Antoine Mayer (Clef demo article de blog) <demo@antoinemayer.fr>
ssb rsa4096 2022-07-03 [E] [expires: 2024-07-02]
La ligne sec indique que c’est notre clef secrète, avec son ID juste en dessous, dans mon cas : CFD6DA6900A81BF044DFF18C8CE5FBBD2E9BD4EC.
On l’a vu précédemment, la ligne uid correspond à l’identifiant en, renseigné à l’étape précédente.
ssb nous informe de la création d’une sous-clef secrète.
La commande gpg -k
me permet de lister les clés publiques.
/root/.gnupg/pubring.kbx
------------------------
pub rsa4096 2022-06-03 [SC] [expires: 2024-07-02]
CFD6DA6900A81BF044DFF18C8CE5FBBD2E9BD4EC
uid [ultimate] Antoine Mayer (Clef demo article de blog) <demo@antoinemayer.fr>
sub rsa4096 2022-07-03 [E] [expires: 2024-07-02]
pub indique la clef publique liée à notre clef secrète. Nous avons également une sous-clef publique sub qui est également liée à notre sous-clef privée (ssb).
Création d’un certificat de révocation
Maintenant, que nous avons notre paire de clefs, il va falloir envisager qu’un jour (peut-être) votre clef soit compromise. Ce que nous allons faire, c’est créer un certificat de révocation. Il vous permettra de la révoquer et de la rendre inutilisable.
Voici la commande :
$ gpg --output /root/revocation.asc --gen-revoke CFD6DA6900A81BF044DFF18C8CE5FBBD2E9BD4EC
--output
: chemin où sera stocké votre fichier de révocation
--gen-revoke
: ID de votre clef maître
Il va vous être demandé ensuite, pour quelle raison nous souhaitons créer un certificat de révocation. Dans notre cas, ce sera le choix 1 “la clef a été compromise”.
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Il vous faudra renseigner la passphrase de votre clef secrète pour confirmation.
A noter, que le message suivant est très important :
Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others!
Toute personne accédant à ce certificat peut l’utiliser pour rendre votre clef inutilisable.
Conclusion
Nous arrivons au terme de cette première partie, qui nous aura permis de découvrir ce qu’est GPG et comment générer sa paire de clefs et la révocation de celle-ci.
Dans une seconde partie (qui arrivera le mois prochain) nous allons voir comment utiliser ces clefs.
N’hésitez pas me suivre sur LinkedIn ou Twitter pour être informé de la sortie des prochains articles ! 😁
Comments are closed.