J’ai décidé de renouveller ma clé pgp, qui commence à être un peu ancienne. En effet, ma toute première clé PGP date de 2007, et je l’ai remplacée en 2008. Ma clé PGP actuelle a donc 6 ans, et les algorithmes qu’elle utilise sont vieillissants (avec par exemple l’utilisation de clés 1024 bits alors qu’aujourd’hui on conseille l’utilisation de 4096 bits).
Je me suis un peu documenté, et j’écris désormais ce billet pour me souvenir de mes recherches. Je me suis basé sur un tutoriel de Stéphane Bortzmeyer, qui se base lui-même sur un article de référence d’Alex Cabal (en) et le guide du projet Debian (en), ainsi qu’une section sur les sous-clés.
Je vais essayer de faire un guide complet. Voici les différentes étapes que je vais détailler :
- Création d’une clé PGP
- Remplacement des anciennes clés par la nouvelle
- Bonnes pratiques de sécurité et de sauvegarde
- Usage et exemples particuliers
Création d’une clé PGP
Configuration des options par défaut de gnupg
Dans un premier temps, on va lancer gpg une première fois, afin d’initialiser les fichiers de configuration :
gpg --list-key
Ensuite, on modifie le fichier ~/.gnupg/gpg.conf et on rajoute ceci à la fin :
### Modifications personnelles ###
# Crypto preferences
personal-digest-preferences SHA256
# For the keys we create
cert-digest-algo SHA256
# For the signatures and other things we generate
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed
Création d’une nouvelle clé PGP
On peut désormais passer à la génération de la nouvelle clé PGP, qui aura les bonnes options par défaut :
$ gpg --gen-key
[…]
Sélectionnez le type de clef désiré :
(1) RSA et RSA (par défaut)
(2) DSA et Elgamal
(3) DSA (signature seule)
(4) RSA (signature seule)
Quel est votre choix ? 1
les clefs RSA peuvent faire entre 1024 et 4096 bits de longueur.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
0 = la clef n'expire pas
<n> = la clef expire dans n jours
<n>w = la clef expire dans n semaines
<n>m = la clef expire dans n mois
<n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 2y
La clef expire le sam. 09 septembre 2016 21:36:51 CEST
Est-ce correct ? (o/N) o
Une identité est nécessaire à la clef ; le programme la construit à partir
du nom réel, d'un commentaire et d'une adresse électronique de cette façon :
« Heinrich Heine (le poète) <heinrichh@duesseldorf.de> »
Nom réel : Jean Dupont
Adresse électronique : thomas@exemple.net
Commentaire : Main ID
Vous avez sélectionné cette identité :
« Jean Dupont (Main ID) <thomas@exemple.net> »
Faut-il modifier le (N)om, le (C)ommentaire, l'(A)dresse électronique
ou (O)ui/(Q)uitter ? O
Une phrase de passe est nécessaire pour protéger votre clef secrète.
[…]
gpg: clef 4EA58FE3 marquée de confiance ultime.
les clefs publique et secrète ont été créées et signées.
gpg: vérification de la base de confiance
gpg: 3 marginale(s) nécessaire(s), 1 complète(s) nécessaire(s),
modèle de confiance PGP
gpg: profondeur : 0 valables : 1 signées : 0
confiance : 0 i., 0 n.d., 0 j., 0 m., 0 t., 1 u.
gpg: la prochaine vérification de la base de confiance aura lieu le 2016-09-09
pub 4096R/4EA58FE3 2014-09-10 [expire : 2016-09-09]
Empreinte de la clef = AE08 AB5C D9E8 4C9D 1D8C E78D 4FE7 0F12 4EA5 8FE3
uid Jean Dupont (Main ID) <thomas@exemple.net>
sub 4096R/87EAB420 2014-09-10 [expire : 2016-09-09]
Notre clé PGP est désormais utilisable, mais on va paufiner quelques détails qui n’en sont pas.
Création d’une sous-clé de signature supplémentaire
On va créer une sous-clé de signature, qui sera utilisée au quotidien, sur l’ordinateur portable, voire sur le téléphone portable, pendant que la clé de signature initiale sera bien en sécurité.
$ gpg --edit-key 4EA58FE3
gpg (GnuPG) 1.4.16; Copyright (C) 2013 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.
La clef secrète est disponible.
pub 4096R/4EA58FE3 créé : 2014-09-10 expire : 2016-09-09 utilisation : SC
confiance : ultime validité : ultime
sub 4096R/87EAB420 créé : 2014-09-10 expire : 2016-09-09 utilisation : E
[ ultime ] (1). Jean Dupont (Main ID) <thomas@exemple.net>
gpg> addkey
La clef est protégée.
Une phrase de passe est nécessaire pour déverrouiller la clef secrète de
l'utilisateur : « Jean Dupont (Main ID) <thomas@exemple.net> »
clef RSA de 4096 bits, identifiant 4EA58FE3, créée le 2014-09-10
Sélectionnez le type de clef désiré :
(3) DSA (signature seule)
(4) RSA (signature seule)
(5) Elgamal (chiffrement seul)
(6) RSA (chiffrement seul)
Quel est votre choix ? 4
les clefs RSA peuvent faire entre 1024 et 4096 bits de longueur.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
0 = la clef n'expire pas
<n> = la clef expire dans n jours
<n>w = la clef expire dans n semaines
<n>m = la clef expire dans n mois
<n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 2y
La clef expire le dim. 07 août 2016 13:44:34 CEST
Est-ce correct ? (o/N) o
Faut-il vraiment la créer ? (o/N) o
[…]
pub 4096R/4EA58FE3 créé : 2014-09-10 expire : 2016-09-09 utilisation : SC
confiance : ultime validité : ultime
sub 4096R/87EAB420 créé : 2014-09-10 expire : 2016-09-09 utilisation : E
sub 4096R/E8DC29F1 créé : 2014-09-11 expire : 2016-09-10 utilisation : S
[ ultime ] (1). Jean Dupont (Main ID) <thomas@exemple.net>
Ajout d’autres UID (adresses courriel et identité)
On peut désormais ajouter d’autres uid (User ID), correspondant à d’autres adresses email, xmpp ou autres. Toujours dans la même “session” gpg :
gpg> adduid
Nom réel : Jean Dupont
Adresse électronique : vetetix@domaine.fr
Commentaire :
Vous avez sélectionné cette identité :
« Jean Dupont <vetetix@domaine.fr> »
Faut-il modifier le (N)om, le (C)ommentaire, l'(A)dresse électronique
ou (O)ui/(Q)uitter ? o
Une phrase de passe est nécessaire pour déverrouiller la clef secrète de
l'utilisateur : « Jean Dupont (Main ID) <thomas@exemple.net> »
clef RSA de 4096 bits, identifiant 4EA58FE3, créée le 2014-09-10
pub 4096R/4EA58FE3 créé : 2014-09-10 expire : 2016-09-09 utilisation : SC
confiance : ultime validité : ultime
sub 4096R/87EAB420 créé : 2014-09-10 expire : 2016-09-09 utilisation : E
sub 4096R/E8DC29F1 créé : 2014-09-11 expire : 2016-09-10 utilisation : S
[ ultime ] (1) Jean Dupont (Main ID) <thomas@exemple.net>
[ inconnue] (2). Jean Dupont <vetetix@domaine.fr>
Et n’oublions pas, pour quitter la “session” gpg, de sauvegarder proprement nos changements :
gpg> save
Remplacement des anciennes clés par la nouvelle
Maintenant qu’on a une clé PGP définitivement fonctionnelle, occupons-nous de remplacer l’ancienne clé par cette dernière.
Signature de la nouvelle clé par l’ancienne clé
Si comme moi vous avez déjà une clé PGP, la première étape est d’officialiser la nouvelle clé en la signant avec l’ancienne (mon ancienne clé a pour empreinte 078AF6AD, et la nouvelle 4EA58FE3) :
$ gpg --default-key 078AF6AD --sign-key 4EA58FE3
pub 4096R/4EA58FE3 créé : 2014-09-10 expire : 2016-09-09 utilisation : SC
confiance : ultime validité : ultime
sub 4096R/87EAB420 créé : 2014-09-10 expire : 2016-09-09 utilisation : E
sub 4096R/E8DC29F1 créé : 2014-09-11 expire : 2016-09-10 utilisation : S
[ ultime ] (1). Jean Dupont <vetetix@domaine.fr>
[ ultime ] (2) Jean Dupont (Main ID) <thomas@exemple.net>
Voulez-vous vraiment signer toutes les identités ? (o/N) o
pub 4096R/4EA58FE3 créé : 2014-09-10 expire : 2016-09-09 utilisation : SC
confiance : ultime validité : ultime
Empreinte clef princip. : AE08 AB5C D9E8 4C9D 1D8C E78D 4FE7 0F12 4EA5 8FE3
Jean Dupont <vetetix@domaine.fr>
Jean Dupont (Main ID) <thomas@exemple.net>
Cette clef va expirer le 2016-09-09.
Voulez-vous vraiment signer cette clef avec votre
clef « Jean Dupont <thomas@exemple.net> » (078AF6AD)
Voulez-vous vraiment signer ? (o/N) o
[…]
Publication de la nouvelle clé
Votre nouvelle clé est désormais prête à être publiée sur un serveur de clés :
$ gpg --send-keys 4EA58FE3
gpg: envoi de la clef 4EA58FE3 au serveur hkp keys.gnupg.net
Les différents serveurs de clés se synchronisent entre eux automatiquement et assez rapidement, donc il n’est pas nécessaire d’envoyer votre clé sur d’autres serveurs (pgp.mit.edu, keyserver.ubuntu.com, etc.)
Révocation de l’ancienne clé
On n’a désormais plus besoin de l’ancienne clé, qui est devenue obsolète. On va donc la révoquer, en choisissant l’option 2 (clé remplacée), et en indiquant dans le commentaire l’ID de la nouvelle clé :
$ gpg --gen-revoke 078AF6AD > revcert.txt
sec 1024D/078AF6AD 2008-11-20 Jean Dupont <thomas@exemple.net>
Faut-il créer un certificat de révocation pour cette clef ? (o/N) o
choisissez la cause de la révocation :
0 = Aucune raison indiquée
1 = La clef a été compromise
2 = La clef a été remplacée
3 = La clef n'est plus utilisée
Q = Annuler
(Vous devriez sûrement sélectionner 1 ici)
Quelle est votre décision ? 2
Entrez une description facultative, en terminant par une ligne vide :
> New key ID 4EA58FE3 thomas@exemple.net
>
Cause de révocation : La clef a été remplacée
New key ID 4EA58FE3 thomas@exemple.net
Est-ce d'accord ? (o/N) o
[…]
$ gpg --import revcert.txt
[…]
$ gpg --send-keys 078AF6AD
[…]
Bonnes pratiques de sécurité et de sauvegarde
On a créé une nouvelle clé PGP, et on a révoqué l’ancienne clé, mais il reste quelques petites choses à faire.
Création du certificat de révocation de la nouvelle clé
Dans un premier temps, on va créer un certificat de révocation pour la nouvelle clé, que l’on stockera par la suite sur un support sécurisé. Il sera utile si on se fait voler la clé privée, ou si on la perd.
Ce certificat, publié sur un serveur de clés, permettra à lui-seul d’annoncer à tous nos contacts que la clé ne doit plus être utilisée.
En premier lieu, on modifie le umask pour éviter que les fichiers générés soient lisibles par un autre utilisateur :
$ umask 177
$ gpg --gen-revoke 4EA58FE3 > 4EA58FE3.revocation.asc
Export, stockage et sauvegarde de la clé complète (avec une version papier)
On va désormais “archiver” notre clé complète, et la stocker en un lieu sûr.
Sauvegarde sur une clé USB
Dans un premier temps, on va sauvegarder la clé complète, en exportant d’abord sa partie privée, puis sa partie publique :
$ umask 177
$ gpg --export-secret-keys --armor 4EA58FE3 > 4EA58FE3.private.asc
$ gpg --export --armor 4EA58FE3 > 4EA58FE3.public.asc
La clé “privée” ainsi créée est la plus importante. Elle contient la totalité de votre clé GPG. Elle peut être ré-importée dans un système vierge si vous avez perdu l’originale.
La clé “publique” est celle que vous donnez à vos correspondants. Elle peut être recréée à partir de la clé “privée”.
Le certificat de révocation peut aussi être recréé à partir de la clé “privée”. Il ne doit absolument pas être publié. Toute personne mettant la main dessus peut révoquer définitivement votre clé GPG sans votre consentement.
Il ne vous reste plus qu’à stocker ces trois fichiers, sur une clé USB ou un disque dur chiffré (je conseille l’utilisation de cryptsetup/LUKS, le plus simplement du monde en utilisant l’outil graphique “Disques” sous Ubuntu)
Sauvegarde sur un support papier
Il est possible de créer une sauvegarde de dernier recours, en version papier, de votre clé PGP. Le détail des opérations se trouve sur ce billet de Schnouki.
Le principe est simple :
- Vous utilisez un utilitaire pour réduire la taille de la clé en en supprimant les informations inutiles ;
- Le fichier résultant étant toujours trop volumineux, vous le découpez en plusieurs fichiers plus petits ;
- Vous encodez ces fichiers pour créer des codes barre 2D imprimables ;
- Vous imprimez ces codes 2D, chacun sur une feuille A4.
Et voilà, vous avez une copie de sauvegarde sur papier de votre clé. Pour la récupérer en cas de besoin :
- Vous scannez chacun des codes 2D à partir de la version imprimée ;
- Vous décodez ces codes scannés, ce qui vous donne les bouts de fichiers initiaux ;
- Vous recollez les bouts ensemble, pour recréer la clé PGP complète.
Ce n’est pas plus compliqué que cela.
Installation du dossier de travail .gnupg
Sous Linux l’ensemble des données se trouvent par défaut dans le dossier .gnupg qui se trouve à la racine de votre répertoire personnel.
Sur clé USB (différente de la clé de sauvegarde mentionnée précédemment), dont on se servira à chaque fois qu’on aura besoin de la clé PGP complète (avec sa partie privée), on va placer une copie de ce répertoire .gnupg. Vous pouvez suivre ce tutoriel un peu complexe utilisant cryptsetup et dm-crypt (en), mais personnellement je ne m’embarrasse pas de cela. Je copie juste mon dossier .gnupg à la racine de la clé USB, que j’ai préalablement chiffrée avec LUKS :
$ cp -r $HOME/.gnupg/ /media/vetetix/cle-usb/gnupg
Ce dossier gnupg contient donc votre clé PGP complète.
Un dernier rappel avant de passer à la suite :
- Vous ne devez pas perdre votre clé privée (toujours en avoir une copie quelque part) ;
- Même si elle n’est utilisable qu’avec un mot de passe, personne d’autre que vous ne doit y avoir accès ;
- Absolument personne ne doit avoir accès à votre certificat de révocation.
Création d’une version partielle de la nouvelle clé
Souvenez-vous, on a ajouté une sous-clé de signature supplémentaire. On va maintenant garder une clé amputée de sa principale sous-clé privée de signature pour notre usage quotidien, en supprimant cette dernière (dont on a fait une sauvegarde sur une clé USB).
-
Dans un premier temps, exportez les sous-clés privées :
$ umask 177 $ gpg --export-secret-subkeys 4EA58FE3 > subkeys -
Ensuite, on supprime la clé privée principale (répondez par l’affirmative aux questions et avertissements) :
$ gpg --delete-secret-key 4EA58FE3 […] sec 4096R/4EA58FE3 2014-09-10 Jean Dupont (Main ID) <thomas@exemple.net> Faut-il supprimer cette clef du porte-clefs ? (o/N) o C'est une clef secrète — faut-il vraiment la supprimer ? (o/N) o -
Réimportez maintenant les sous-clés, et supprimez le fichier temporaire :
$ gpg --import subkeys $ shred --remove subkeys -
Vérifiez que tout s’est bien passé (votre clé est listée avec un # devant sa clé secrète, indiquant qu’elle est absente) :
$ gpg -K /home/vetetix/.gnupg/secring.gpg sec# 4096R/4EA58FE3 2014-09-10 [expire : 2016-09-09] uid Jean Dupont (Main ID) <thomas@exemple.net> uid Jean Dupont <vetetix@domaine.fr> ssb 4096R/87EAB420 2014-09-10 ssb 4096R/E8DC29F1 2014-09-11
Précisons que l’option “-K” est un raccourcis pour “—list-secret-keys”.
« Et voilà ! », comme diraient nos amis anglophones. La clé que vous utilisez au quotidien, sur votre ordinateur portable, ne dispose plus de votre clé privée, celle-ci étant en sécurité sur une clé USB.
Usage et exemples particuliers
Maintenant qu’on a placé la partie privée de la clé PGP sur une clé USB, il faut savoir comment l’utiliser concrètement.
Montage de la clé
Commençons par monter la clé USB contenant notre clé GPG complète. Dans notre exemple elle se monte dans /media/vetetix/usb-key.
On peut alors travailler avec en utilisant l’option --home de gnupg, que l’on pointe sur le répertoire de travail contenu sur la clé :
$ gpg --home=/media/vetetix/usb-key/gnupg -K
/media/vetetix/usb-key/gnupg/secring.gpg
---------------------------------------
sec 4096R/4EA58FE3 2014-09-10 [expire : 2016-09-09]
uid Jean Dupont (Main ID) <thomas@exemple.net>
uid Jean Dupont <vetetix@domaine.fr>
ssb 4096R/87EAB420 2014-09-10
ssb 4096R/E8DC29F1 2014-09-11
On constate que la clé secrète n’est pas suivie d’un #. Elle est donc présente.
Prolongation de la validité de la clé
En créant ma clé, j’ai mis une durée de validité de deux ans. Pour prolonger cette validité, il suffit d’utiliser la commande expire de gpg, et à nouveau de choisir “2y”, ou toute autre durée :
$ gpg --home=/media/vetetix/usb-key/gnupg --edit-key 4EA58FE3
[…]
gpg> expire
[…]
gpg> save
$ gpg --home=/media/vetetix/usb-key/gnupg --send-keys 4EA58FE3
Signatures d’autres clés
Pour signer une autre clé, on va récupérer la clé en question (à partir de son ID dans notre exemple) :
$ gpg --home=/media/vetetix/usb-key/gnupg --recv-keys ABCD1234
Ensuite on la signe, et on exporte la signature dans un format lisible (option --armor) :
$ gpg --home=/media/vetetix/usb-key/gnupg --sign-key ABCD1234
$ gpg --home=/media/vetetix/usb-key/gnupg --armor --output ABCD1234.signed-by.4EA58FE3.asc --export ABCD1234
Maintenant qu’on a signé la clé publique de la personne, on n’uploade pas la signature soi-même. La personne dont on a vérifié l’identité peut très bien avoir menti sur l’adresse email ou xmpp qu’il a montrée. Pour éviter tout problème, on envoie la signature par email ou xmpp au titulaire de l’adresse, en chiffrant le message avec la clé publique qu’on vient de signer.
Le récipiendaire du message sera ainsi le titulaire de l’adresse email, et de la clé qu’on vient de signer. Il déchiffrera le message, importera la signature dans son trousseau GnuPG, et l’uploadera lui-même sur un serveur de clé.
Révocation d’une sous-clé
En cas de souci (vol de la clé, ou autre désastre), on peut avoir besoin de révoquer la sous-clé de signature de notre clé. Avantage de notre système de sous-clé additionnelle : la clé principale n’a pas à être révoquée, elle reste donc en service et on ne perd pas le bénéfice du Web of Trust existant.
Pour générer le certificat de révocation de la sous-clé, il faut avoir accès à la clé de signature principale, donc il faut utiliser la clé USB :
$ gpg --home=/media/vetetix/usb-key/gnupg --edit-key 4EA58FE3
gpg> list # Pour voir le détail des sous-clés et identités
[…]
gpg> key 2 # Pour sélectionner la deuxième sous-clé, compromise
[…]
gpg> revkey # Pour générer le certificat de révocation de la sous-clé sélectionnée
gpg> save
Il faut désormais recréer une sous-clé de signature, tel qu’expliqué précédemment, et republier notre clé modifiée avec la commande gpg --send-keys ID (puis recréer une version amputée de la clé en vue de son utilisation quotidienne).
Il ne reste plus qu’à vos correspondants de mettre à jour leur version de votre clé publique via gpg --recv-keys ID
Note : Il semble déconseillé de supprimer les sous-clés et identités corrompues, car de toute façon, elles ne disparaitraient pas sur les serveurs de clé, ou dans notre clé publique chez nos correspondants.
Révocation définitive de la clé
Si la clé a été définitivement compromise, ou qu’après plusieurs années de bons et loyaux service on la remplace pour utiliser des algorithmes plus robustes, on peut la révoquer.
Cela peut se faire à partir du certificat de révocation créé préalablement :
$ gpg --import 4EA58FE3.revocation.asc
$ gpg --send-keys 4EA58FE3
La clé est désormais inutilisable :-( Paix à son âme.
Si on n’a pas prévu de certificat de révocation, on peut en créez un à partir de la clé privée complète. Si en plus on a perdu la clé privée complète, on ne pourra jamais la révoquer.