GPG : comment créer une paire de clefs presque parfaite

Aujourd'hui, c'est la journée européenne de la protection des données. Nous avons donc décidé de vous occuper avec un nouveau guide qui prend place au sein de notre dossier dédié au chiffrement. Celui-ci vous permettra de créer une paire de clefs GnuPG plus robuste et utilisable au quotidien.

Récemment, nous avons débuté un dossier sur le chiffrement. Tout d'abord en vous permettant d'expliquer au mieux cette notion à vos proches, mais aussi en revenant plus en détail sur l'histoire de GnuPG (GPG) et sur la façon de créer votre première paire de clefs afin de chiffrer des fichiers.

En cette journée européenne de la protection des données, nous avons décidé de passer à l'étape suivante : vous permettre de créer une paire de clefs presque parfaite. Pourquoi presque ? Parce que tout est toujours perfectible, surtout lorsqu'il est question de sécurité. Nous n'hésiterons d'ailleurs pas à mettre à jour ce guide avec de nouvelles astuces si cela est nécessaire ou si certaines sont partagées au sein de nos commentaires.

La seconde question à se poser est « Pourquoi un tel guide est nécessaire ? ». La raison est simple : tout pratique et simple à installer que soit GPG, ses paramètres par défaut sont loin d'être optimaux, comme nous avons déjà eu l'occasion de l'évoquer. Certes, cela a tendance à évoluer dans le bon sens, mais il y a encore du chemin à parcourir.

Nous avons donc décidé de vous détailler quelques étapes à suivre pour mieux comprendre et générer une paire de clefs plus robuste de manière simple. Cela devrait aussi vous permettre de vous simplifier un peu la vie au quotidien.

Renforcer l'environnement depuis lequel la clef est générée

La première chose à savoir est qu'il est toujours préférable de générer votre paire de clefs sur une machine de confiance. Dans l'idéal, cela doit donc être fait sur une machine disposant d'un système d'exploitation open source, qui n'est pas reliée à Internet (Tails fait en général très bien l'affaire).

Ensuite, il faut commencer par renforcer les paramètres par défaut de GnuPG. Plusieurs méthodes existent pour cela, mais le plus simple est d'éditer le fichier de configuration. Celui-ci se trouve à l'endroit suivant :

Linux et macOS : ~/.gnupg/gpg.conf
Windows : C:\Users\[nom de l'utilisateur]\AppData\Roaming\gnupg\gpg.conf

Si vous êtes sous Windows, nous avons créé un petit utilitaire vous permettant d'ouvrir ce fichier afin de le modifier sans avoir à fouiller dans des dossiers cachés. Il est disponible par ici.

Par défaut, la plupart des lignes seront commentées, de manière à être sans aucune action. Il faut donc le compléter afin de préciser certains paramètres utiles qui viendront renforcer différents éléments du fonctionnement de GPG et limiter l'utilisation de certains algorithmes.

Pour établir la liste définitive, nous nous sommes notamment fondés sur les conseils d'Aeris22 et les best practices de Riseup.net. Les détails sur les paramètres S2K peuvent être trouvés dans la RFC 4880 à la section 3.7.

Il suffit donc d'ajouter ces lignes à la fin de votre fichier ou de remplacer les valeurs, si jamais il avait déjà été modifié :

# Limite les informations diffusées
no-emit-version
no-comments
export-options export-minimal

# Permet d'afficher le format long de l'ID des clefs et leurs empreintes
keyid-format 0xlong
with-fingerprint

# Affiche la validité des clefs
list-options show-uid-validity
verify-options show-uid-validity

# Limite les algorithmes utilisés
personal-cipher-preferences AES256
personal-digest-preferences SHA512
default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed

cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512
compress-algo ZLIB

disable-cipher-algo 3DES
weak-digest SHA1

# Paramètres S2K (String-to-Key) de la phrase de passe des clefs
# Le paramètre s2k-count peut être réduit sur les machines peu puissantes
s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

Notez que la ligne weak-digest SHA1 peut poser problème avec d'anciennes versions de GPG. Si tel est le cas vous pouvez la commenter (en rajoutant un # en début de ligne).

Vous pouvez aussi ajouter le paramètre throw-keyids qui permet de cacher pour quel destinataire est chiffré un message, ce qui apporte une couche de sécurité complémentaire. Mais cela peut parfois complexifier le déchiffrement, puisque la machine du destinataire devra tester les différentes clefs privée dont elle dispose avant de trouver la bonne, comme l'avait expliqué Stéphane Bortzmeyer dans l'un de ses articles.

L'importance de disposer de sous-clefs

Une fois le fichier enregistré, passons à la création de notre paire de clefs. Nous utiliserons à nouveau la version 2.1 de GPG pour notre démonstration (gpg2 sous Linux, voir la procédure d'installation). Comme nous l'avions évoqué dans notre précédent guide, il est possible de disposer de sous-clefs en complément de la clef primaire. Chacune pouvant se voir attribuer des tâches spécifiques :

Signature (S)
Certification (C)
Chiffrement (E)
Authentification (A)

La différence, c'est que ces sous-clefs sont liées à la clef primaire mais peuvent être révoquées de manière indépendante (voir ici pour la méthode). Utile pour ceux qui veulent changer souvent de clef de chiffrement (pour reproduire une sorte de Perfect Forward Secrecy).

Mais surtout, si l'une d'entre elles venait à être découverte ou perdue, vous pouvez la révoquer et en générer une nouvelle depuis votre clef primaire. Cela n'empêchera pas celui qui l'a trouvé de l'utiliser et de chiffre/déchiffrer vos documents et emails antérieurs s'il dispose de la phrase de passe associée, mais cela vous permettra de repartir facilement sur des bases saines.

Alors que si vous perdez l'accès à votre clef primaire, tout est perdu puisque vous devrez alors générer une nouvelle clef complète. De plus, un attaquant pourrait éventuellement générer de nouvelles clefs secondaires et se faire passer pour vous s'il dispose de votre phrase de passe. Il faut donc la protéger à tout prix.

Mais il est nécessaire de disposer au quotidien de quoi chiffrer et signer des documents ou des emails, même sur des machines plus accessibles à des tiers telles que des ordinateurs portables. Nous allons donc attribuer ces fonctionnalités à des sous-clefs que l'on pourra utiliser simplement.

Nous garderons la certification pour la clef primaire que l'on gardera bien au chaud sur une machine de confiance (et pourquoi pas hors-ligne), ou un autre système de stockage (clef USB mise en sécurité, format papier, etc). Une stratégie notamment détaillée par l'équipe de Debian, mais aussi recommandée par Riseup ou le guide d'Alex Cabal.

Création de la clef de base

Comme nous l'avons déjà vu, chaque méthode de création d'une paire de clefs peut aboutir à un résultat différent. Nous allons donc utiliser la ligne de commande qui a l'avantage d'être identique quel que soit le système. Le plus souvent, il est conseillé de créer une clef avec la méthode de base, ce qui a pour effet de mettre en place une clef primaire gérant la signature et la certification, ainsi qu'une sous-clef pour le chiffrement. On viendra ensuite modifier sa composition.

Dans notre cas, nous allons opter pour une méthode plus directe en limitant dès le départ les capacités de la clef primaire à la fonction de certification (C). Pour rappel, c'est ce qui permet d'indiquer le niveau de confiance lors de la signature de la clef d'un tiers dans le cadre du Web of trust. Une fonctionnalité importante qu'il faut préserver, mais qu'il n'est pas nécessaire d'utiliser au quotidien.

Pour cela nous pouvons utiliser la création en mode expert via la commande gpg --full-gen-key --expert afin de pouvoir sélectionner dès le départ les actions possibles avec la clef, il existe aussi une méthode plus rapide depuis GPG 2.1 que nous détaillerons un peu plus bas.

Comme lors de nos démonstrations précédentes, nous allons opter pour du RSA de 4096 bits (choix 8) valable pour une durée d'un an (1y). Bien entendu, vous pouvez opter pour une clef utilisant la cryptographie sur les courbes elliptiques (ECC) si vous le préférez, ou même tester la création d'une clef RSA jusqu'à 8 192 bits avec l'option --enable-large-rsa. Attention, dans ce dernier cas, votre clef pourrait ne pas être supportée par certains systèmes et applications.

gpg --full-gen-key --expert

gpg (GnuPG) 2.1.15; Copyright (C) 2016 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.

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)
 (7) DSA (indiquez vous-même les capacités)
 (8) RSA (indiquez vous-même les capacités)
 (9) ECC et ECC
 (10) ECC (signature seule)
 (11) ECC (indiquez vous-même les capacités)
Quel est votre choix ? 8

Actions possibles pour une clef RSA : Signer Certifier Chiffrer Authentifier
Actions actuellement permises : Signer Certifier Chiffrer
(S) Inverser la capacité de signature
 (C) Inverser la capacité de chiffrement
 (A) Inverser la capacité d'authentification
 (Q) Terminé
Quel est votre choix ? s

Actions possibles pour une clef RSA : Signer Certifier Chiffrer Authentifier
Actions actuellement permises : Certifier Chiffrer
(S) Inverser la capacité de signature
 (C) Inverser la capacité de chiffrement
 (A) Inverser la capacité d'authentification
 (Q) Terminé
Quel est votre choix ? c

Actions possibles pour une clef RSA : Signer Certifier Chiffrer Authentifier
Actions actuellement permises : Certifier
(S) Inverser la capacité de signature
 (C) Inverser la capacité de chiffrement
 (A) Inverser la capacité d'authentification
 (Q) Terminé
Quel est votre choix ? q

les clefs RSA peuvent faire une taille comprise entre 1024 et 4096 bits.
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) 1y

La clef expire le 01/28/18 17:17:10 Paris, Madrid
Est-ce correct ? (o/N) o

GnuPG doit construire une identité pour identifier la clef.
Nom réel : Jean Deauh
Adresse électronique : me@jeandeauh.fr
Commentaire :

Vous avez sélectionné cette identité :
 « Jean Deauh <me@jeandeauh.fr> »
Changer le (N)om, le (C)ommentaire, l'(A)dresse électronique
ou (O)ui/(Q)uitter ? o

De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

gpg: clef 0x1C141B1DE773D6CA marquée de confiance ultime.
gpg: revocation certificate stored as ''
les clefs publique et secrète ont été créées et signées.
pub rsa4096/0x1C141B1DE773D6CA 2017-01-28 [C] [expire : 2018-01-28]
 Empreinte de la clef = E6D9 DD35 E023 3198 EFAF 68F5 1C14 1B1D E773 D6CA
uid Jean Deauh <me@jeandeauh.fr>

Notez que vous avez aussi la possibilité depuis les versions récentes de GPG d'utiliser une ligne de commandes rapide pour effectuer une telle action :

gpg --quick-gen-key 'Jean Deauh <me@jeandeauh.fr>' rsa4096 cert 1y

Ajout des sous-clefs de chiffrement et de signature

Nous avons donc obtenu ce que nous voulions, une paire de clef avec une clef primaire qui ne dispose que d'une fonction de certification. Il faut maintenant lui rajouter des sous-clefs afin de disposer de quoi chiffrer et signer des documents.

Pour cela il faut commencer à éditer la clef (en tapant l'ID/empreinte de celle-ci, ou l'adresse email associée par exemple) :

gpg --edit-key <me@jeandeauh.fr>

gpg (GnuPG) 2.1.15; Copyright (C) 2016 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.

sec rsa4096/0x1C141B1DE773D6CA
 créé : 2017-01-28 expire : 2018-01-28 utilisation : C
 confiance : ultime validité : ultime
[ ultime ] (1). Jean Deauh <me@jeandeauh.fr>

Ensuite, il faut demander l'ajout de sous clefs de signature, puis une autre pour le chiffrement avec la commande addkey. Celles-ci peuvent utiliser différents algorithmes mais aussi disposer de leur propre date d'expiration. Nous avons là encore opté pour du RSA 4096 bits avec une durée de vie d'un an.

gpg> addkey

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 une taille comprise entre 1024 et 4096 bits.
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) 1y
La clef expire le 01/28/18 17:36:16 Paris, Madrid
Est-ce correct ? (o/N) o
Faut-il vraiment la créer ? (o/N) o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

sec rsa4096/0x1C141B1DE773D6CA
 créé : 2017-01-28 expire : 2018-01-28 utilisation : C
 confiance : ultime validité : ultime
ssb rsa4096/0x7B0E97F0E71AF6AA
 créé : 2017-01-28 expire : 2018-01-28 utilisation : S
[ ultime ] (1). Jean Deauh <me@jeandeauh.fr>

gpg> addkey
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 ? 6
les clefs RSA peuvent faire une taille comprise entre 1024 et 4096 bits.
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) 1y
La clef expire le 01/28/18 17:37:42 Paris, Madrid
Est-ce correct ? (o/N) o
Faut-il vraiment la créer ? (o/N) o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

sec rsa4096/0x1C141B1DE773D6CA
 créé : 2017-01-28 expire : 2018-01-28 utilisation : C
 confiance : ultime validité : ultime
ssb rsa4096/0x7B0E97F0E71AF6AA
 créé : 2017-01-28 expire : 2018-01-28 utilisation : S
ssb rsa4096/0xA0F83AE2EE071150
 créé : 2017-01-28 expire : 2018-01-28 utilisation : E
[ ultime ] (1). Jean Deauh <me@jeandeauh.fr>

gpg> save

Là aussi il est possible d'utiliser pour ligne de commandes rapide introduite dans les versions récentes de GPG en utilisant l'empreinte de votre clef primaire :

gpg --quick-addkey E6D9DD35E0233198EFAF68F51C141B1DE773D6CA rsa4096 sign 1y
gpg --quick-addkey E6D9DD35E0233198EFAF68F51C141B1DE773D6CA rsa4096 encr 1y

Nous voilà donc avec une clef secrète composée d'une clef principale (sec) pour la certification (C) et de sous-clefs (ssb) pour la signature (S) et le chiffrement (E).

Notez que vous pouvez ajouter une ligne à votre fichier gpg.conf afin d'indiquer la clef à utiliser par défaut pour la signature. Cela passera par l'ajout suivant (à adapter selon l'ID de votre propre sous-clef de signature) :

default-key 0x7B0E97F0E71AF6AA

La sauvegarde de vos clefs

Passons maintenant à une étape importante : celle qui consiste à créer une sauvegarde de vos clefs. Ici, on passera par des fichiers qui sont à mettre en sécurité, mais il est possible de passer par des sauvegardes papier, sous forme de QR Code ou autre selon vos préférences. Des outils comme Kleopatra proposent même désormais directement une option d'impression :

Pour ces différentes étapes vous pouvez passer par des outils à interface graphique, mais là encore, la ligne de commandes nous permet une gestion unifiée et complète sur les différents systèmes d'exploitation. C'est donc vers elle que nous avons décidé de nous tourner.

Certificat de révocation

Celui-ci vous permettra de révoquer votre clef complète en cas de problème. Si jamais elle venait à être découverte ou perdue, il sera possible de l'utiliser pour indiquer qu'elle ne doit plus être utilisée.

Dans les versions récentes de GPG il est généré automatiquement, vous le retrouverez dans le répertoire openpgp-revocs.d situé dans celui contenant votre fichier gpg.conf (voir ci-dessus). Sinon vous pouvez toujours le générer avec la commande suivante (à utiliser avec le nom, l'ID, l'empreinte ou l'email) :

gpg --output revocation.asc --gen-revoke me@jeandeauh.fr

Notez que vous pouvez désigner une clef tierce afin de lui permettre de générer un certificat de révocation à travers la commande --desig-revok.

Clef primaire et sous-clefs

L'objectif est maintenant de garder une sauvegarde séparée de la clef primaire qu'il faut mettre en sécurité et les sous-clefs qui pourront être utilisées sur une machine du quotidien. Pour cela nous utiliserons deux commandes spécifiques (à utiliser avec le nom, l'ID, l'empreinte ou l'email) :

gpg -a --export-secret-keys me@jeandeauh.fr > secret_keys.gpg
gpg -a --export-secret-subkeys me@jeandeauh.fr > secret_subkeys.gpg

Clef publique et envoi sur un serveur de clefs

Vous pouvez aussi plus simplement créer une sauvegarde de votre clef publique qui sera à partager largement. Pour cela, vous pouvez la mettre en copie de vos emails, sur votre site ou même la publier sur un serveur de clefs (en utilisant l'ID/empreinte de celle-ci). Attention, il sera impossible de la supprimer une fois en ligne. Vous pourrez seulement diffuser votre certificat de révocation pour indiquer qu'elle ne doit plus être utilisée.

gpg -a --export me@jeandeauh.fr > public.gpg
gpg --keyserver eu.pool.sks-keyservers.net --send-key 0x1C141B1DE773D6CA

L'utilisation de vos clefs sur une machine du quotidien

Maintenant que vous avez créé une sauvegarde de vos clefs, il vous reste à les mettre en place sur vos différentes machines, et à faire éventuellement le ménage sur celle que vous venez d'utiliser.

Suppression de la clef privée

Si l'on veut éviter que la clef privée reste sur la machine actuelle, il est possible de le faire via une commande simple (à utiliser avec le nom, l'ID, l'empreinte ou l'email). Il vous sera proposé de supprimer la clef primaire mais aussi les sous-clefs, attention donc à ce que vous aller accepter ou refuser.

gpg --delete-secret-keys me@jeandeauh.fr

Import des sous-clefs

Si vous voulez importer les sous-clefs sur une machine afin de pouvoir signer ou chiffrer des documents et des emails, vous pouvez utiliser un outil avec une interface graphique, ou la commande suivante (à utiliser avec le nom, l'ID, l'empreinte ou l'email) :

gpg --import secret_subkeys.gpg

Vous pourrez ensuite verifier l'état de vos clefs privées et publiques respectivement, avec les commandes suivantes :

gpg -K
gpg -k

Si la clef primaire est bien absente, vous le saurez avec la présence de la mention sec# lorsque vous afficherez les informations sur vos clefs privées.

Retrouvez notre dossier Chiffrement, clefs de sécurité et cryptobidules :

GPG : création de votre première paire de clefs et chiffrement d'un fichier