Sommaire
La branche 2.3 qui démarre officiellement avec cette version marque le début d’un nouveau cycle de développement qui aboutira à la prochaine version « stable » 2.4. L’actuelle branche stable 2.2, renommée LTS pour Long Term Support, est toujours prise en charge en attendant et devrait l’être au moins jusqu’en décembre 2024.
Un nouveau démon d’accès aux clefs publiques : keyboxd
Pour comprendre cette nouveauté, revenons sur les différentes méthodes que GnuPG a utilisées au fil des versions pour stocker les clefs publiques.
GnuPG ≤ 2.0 : pubring.gpg
Les premières versions de GnuPG stockaient les clefs publiques dans un fichier appelé $GNUPGHOME/pubring.gpg, dans le même format que celui utilisé pour l’échange des clefs — le format décrit par le standard OpenPGP. C’est-à-dire que ce fichier contenait simplement les différents paquets OpenPGP constituant une clef publique.
C’était aussi l’approche retenue, à l’époque, par PGP. Un des avantages de cette approche est qu’elle dispense d’avoir à gérer un format spécifique pour le stockage des clefs — on ré-utilise simplement le parser de paquets OpenPGP que toute implémentation du standard se doit naturellement d’avoir.
En revanche, un gros inconvénient est que les clefs ne sont pas indexées et qu’accéder à une clef précise suppose de parcourir tout le fichier jusqu’à trouver la clef voulue, ce qui est rapidement inefficace sur les trousseaux un peu gros.
GnuPG 2.1, 2.2 : pubring.kbx
La branche 2.1 de GnuPG a introduit le format keybox (fichier $GNUPGHOME/pubring.kbx). Désormais, les clefs publiques sont stockées dans un format spécialisé propre à GnuPG.
L’objectif de ce format était de résoudre le problème d’inefficacité de la recherche de clefs dans un trousseau ; cet objectif n’a été que partiellement atteint, et le format a suscité quelques critiques acerbes, notamment lorsque les clefs publiques de plusieurs membres proéminents de la communauté ont été victimes d’attaques par empoisonnement (exploitant certaines failles dans l’implémentation du format keybox au sein de GnuPG) au printemps 2019.
La principale critique adressée aux développeurs de GnuPG concernait le fait même d’avoir développé à partir de zéro un format ad hoc, au lieu de ré-utiliser des solutions existantes et éprouvées — SQLite étant notamment fréquemment citée.
GnuPG 2.3 : keyboxd
En réponse à ces critiques, GnuPG 2.3 introduit deux changements majeurs pour le stockage des clefs publiques.
D’abord, les clefs sont désormais stockées dans une base SQLite. GnuPG utilisait déjà SQLite pour la base de données du modèle de confiance TOFU de toute manière, donc ce n’est pas une nouvelle dépendance. La base est dans un fichier appelé $GNUPGHOME/public-keys.d/pubring.db.
Ensuite et surtout, un démon spécifique, keyboxd (sans lien avec le format keybox utilisé précédemment, en dépit du nom), est désormais seul à accéder au fichier contenant les clefs publiques. Les programmes gpg et gpgsm doivent maintenant obtenir les clefs publiques dont ils ont besoin en les demandant à ce démon via le protocole Assuan.1 L’intérêt est de rendre la recherche d’une clef beaucoup plus rapide, la base de données des clefs n’étant lue qu’une fois pour toutes par le démon keyboxd et non lors de chaque invocation de gpg ou gpgsm.
L’utilisation de keyboxd est désactivée par défaut pour l’instant. Les personnes motivées pour l’essayer (et rapporter les bogues — on est sur une branche de développement, souvenez-vous…) doivent simplement ajouter l’option use-keyboxd dans leurs fichiers $GNUPGHOME/gpg.conf et $GNUPGHOME/gpgsm.conf. À défaut, GnuPG 2.3 continuera d’utiliser le fichier pubring.kbx des versions 2.1/2.2.
Un nouveau démon d’accès aux puces TPM : tpm2d
Gros changement, d’ailleurs resté en incubation pendant longtemps, la prise en charge des puces TPM 2.0 présentes dans la plupart des ordinateurs portables modernes. Cela passe par un nouveau démon, tpm2d, qui est aux TPM ce que scdaemon est aux cartes à puces et jetons assimilés.
La prise en charge des TPM nécessite qu’une « pile logicielle TPM 2.0 » (TSS, TPM Software Stack) soit présente sur le système lors de la compilation de GnuPG. Deux telles piles sont disponibles dans le monde libre : une développée par IBM (ibmtss20), l’autre par une communauté de développeurs menée par Intel (tpm2-tss). GnuPG prend en charge les deux et le script configure devrait automatiquement autoriser la compilation de tpm2d si au moins l’une de ces bibliothèques est détectée.
Votre compte utilisateur doit avoir accès en lecture et écriture au TPM (/dev/tpm0 ou /dev/tpmrm0 si vous passez par le gestionnaire de ressources intégré au noyau). Typiquement, cela se fait en assignant le groupe tss au périphérique /dev/tpm0 (ou /dev/tpmrm0) et en assignant votre compte utilisateur à ce même groupe. (Il est possible que votre distribution se charge déjà de faire ça lors de l’installation de la pile logicielle TPM.)
L’utilisation est similaire à celle d’une carte à puce. Pour « charger » une clef privée sur un TPM, lancez l’éditeur de clefs de GnuPG :
$ gpg --edit-key alice@example.org
Secret key is available.
sec rsa2048/FA6E81E09F636D5F
created: 2021-04-07 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/66EBA79F4D48C3B5
created: 2021-04-07 expires: never usage: E
[ultimate] (1). Alice
gpg>
Sélectionnez la sous-clef à envoyer au TPM (ou ne sélectionnez rien, si vous voulez envoyer la clef principale) :
gpg> key 1
sec rsa2048/FA6E81E09F636D5F
created: 2021-04-07 expires: never usage: SC
trust: ultimate validity: ultimate
ssb* rsa2048/66EBA79F4D48C3B5
created: 2021-04-07 expires: never usage: E
[ultimate] (1). Alice
Puis utilisez la commande keytotpm :
gpg> keytotpm
Il vous est alors demandé votre phrase de mot-de-passe actuel pour déchiffrer la clef privée (si l’agent GnuPG ne l’avait pas déjà en cache), puis le PIN qui la protégera désormais (similairement à ce qui se passerait avec une carte à puce).
sec rsa2048/FA6E81E09F636D5F
created: 2021-04-07 expires: never usage: SC
trust: ultimate validity: ultimate
ssb* rsa2048/66EBA79F4D48C3B5
created: 2021-04-07 expires: never usage: E
card-no: TPM-Protected
[ultimate] (1). Alice
Notez la mention TPM-Protected, indiquant que la sous-clef est désormais chiffrée par le TPM (au passage, le card-no trahit le fait que la prise en charge des TPM par GnuPG ré-utilise largement l’infrastructure déjà en place pour la gestion des cartes à puces).
Attention, contrairement à ce qui se passerait avec une carte à puce, ici à aucun moment la clef privée n’est physiquement stockée dans le TPM. Elle est chiffrée par le TPM de telle sorte que seul le TPM peut la déchiffrer et l’utiliser (sous réserve de fournir le bon PIN), mais elle est toujours stockée (sous sa forme chiffrée) dans $GNUPGHOME/private-keys-v1.d.
Par ailleurs, la clef étant désormais irrémédiablement liée à ce TPM, il est évidemment fortement conseillé de sauvegarder la clef privée sur un support externe avant toute utilisation de la commande keytotpm… Mais vous n’avez pas attendu cette dépêche pour avoir des sauvegardes hors-ligne de vos clefs, n’est-ce pas ? N’EST-CE PAS ?
Les clefs n’étant pas stockées par le TPM lui-même, il n’y a aucune limitation au nombre de clefs qu’il est possible de protéger ainsi et vous pouvez utiliser keytotpm pour autant de clefs que vous voulez.
Un nouvel outil : gpg-card
Jusqu’à présent, la manipulation des cartes à puce passait principalement par l’éditeur de cartes intégré au programme gpg (appelable par gpg --card-edit).
Désormais, un programme spécifique, gpg-card, est dédié à la manipulation des cartes à puce. Il reprend toutes les fonctionnalités de gpg --card-edit et en ajoute quelques nouvelles. Notamment, il fournit une commande yubikey permettant spécifiquement de manipuler les jetons de type Yubikey (par exemple pour activer/désactiver l’application OpenPGP sur ces jetons).
Le chargement d’une clef sur une carte à puce passe toujours par l’éditeur de clefs de GnuPG (gpg --edit-key) et sa commande keytocard.
De nouveaux algorithmes par défaut
Bien que la prise en charge de la cryptographie elliptique (ECC — dont l’utilisation dans OpenPGP est spécifiée dans le RFC 6637) ait été introduite dès GnuPG 2.1 en 2014, GnuPG a continué depuis de générer par défaut des clefs RSA. Non seulement ça, mais la possibilité de choisir des clefs ECC était « cachée » derrière l’option --expert. Peu d’implémentations prenaient en charge la cryptographie elliptique à l’époque, donc il convenait d’éviter que les utilisateurs ne génèrent par inadvertance des clefs que leurs correspondants ne pourraient peut-être pas utiliser.
De nos jours en revanche, toutes les implémentations majeures d’OpenPGP (GnuPG, OpenPGP.js, Sequoia-PGP, RNP, et même PGP Symantec™ BroadcomⓇ Encryption Solutions) gèrent la cryptographie elliptique, donc il n’y a plus lieu de réserver les clefs ECC aux utilisateurs avertis.
GnuPG génère donc désormais par défaut une clef principale de signature ed25519 (EdDSA sur la courbe 25519), et une sous-clef de chiffrement cv25519 (ECDH sur la même courbe).
Prise en charge de la prochaine version du standard OpenPGP (RFC 4880bis)
Depuis quelques années, le standard OpenPGP (dont la dernière version, le RFC 4880, remonte à 2007) est en cours de refonte. C’est le projet 4880bis, qui a connu un développement laborieux (lors de la reformation du groupe de travail OpenPGP à l’IETF en 2015, l’objectif était de publier le nouveau RFC fin 2016, début 2017 au plus tard…) mais qui semble désormais en bonne voie.
Les nouveautés qu’apportera la nouvelle version du standard incluent :
- la formalisation des clefs ECC utilisant la courbe 25519 (qui ne figurait pas dans le RFC 6637 évoqué ci-dessus) ;
- un nouveau format de clef publique, v5, qui remplacera l’actuel format v4 et qui utilisera SHA-256 (et non plus SHA-1) pour les empreintes de clefs ;
- la prise en charge des modes de chiffrement symétrique authentifié (AEAD, Authenticated Encryption with Associated Data), qui remplaceront l’actuel système de vérification d’intégrité (MDC, Modification Detection Code) ;
- une mise à jour des algorithmes qui DOIVENT (au sens du RFC 2119) être pris en charge par toutes les implémentations (MTI, mandatory to implement) et qui servent donc de socle de compatibilité.
Les nouveaux algorithmes MTI seront désormais RSA et ECDSA pour les signatures (en remplacement de DSA), RSA et ECDH pour le chiffrement asymétrique (en remplacement de ElGamal), AES-128 pour le chiffrement symétrique (en remplacement du vénérable 3DES) et SHA-256 pour la condensation (en remplacement de SHA-1). La prise en charge d’au moins un mode AEAD parmi les deux spécifiés (OCB et EAX) sera également requis — pour l’instant, il s’agit de EAX, mais cela pourrait changer maintenant qu’OCB n’est plus encombré de brevets.
Toutes ces nouveautés sont présentes dans GnuPG 2.3.0 et sont d’ores et déjà utilisables. Dans les faits, les nouveaux algorithmes par défaut étaient déjà utilisés par toutes les implémentations majeures depuis plusieurs années déjà, de ce côté le standard ne fait qu’entériner l’usage.
Concernant le chiffrement authentifié (AEAD), il sera automatiquement utilisé lors du chiffrement d’un message si la clef du destinataire indique, via les préférences exprimées dans les auto-signatures, que l’implémentation du destinataire prend en charge cette fonctionnalité. Sinon, c’est le traditionnel mode MDC qui s’appliquera.
Toutes les clefs nouvellement générées par GnuPG 2.3.0 se voient automatiquement attribuer des préférences AEAD et vous n’avez donc rien à faire pour activer cette fonctionnalité si vous générez une nouvelle clef avec cette version. En revanche, si vous avez déjà une clef émise par une version antérieure, il vous faut manuellement mettre à jour la liste des algorithmes préférés pour y inclure les algorithmes AEAD. Cela se fait simplement avec la commande setpref (sans argument, pour utiliser les nouvelles préférences par défaut) :
$ gpg --edit-key alice
Secret key is available.
sec rsa2048/FA6E81E09F636D5F
created: 2021-04-07 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/66EBA79F4D48C3B5
created: 2021-04-07 expires: never usage: E
[ultimate] (1). Alice
gpg> setpref
Set preference list to:
Cipher: AES256, AES192, AES, 3DES
AEAD: OCB, EAX
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, AEAD, Keyserver no-modify
Really update the preferences? (y/N) y
gpg> save
Concernant le nouveau format de clef v5, il n’est par défaut pas utilisé pour l’instant et GnuPG continue de générer des clefs au format v4. Passez l’option --rfc4880bis pour forcer GnuPG à générer une clef v5.
Je vous conseille de ne faire ceci qu’à des fins de test. D’une part, toutes les implémentations ne gèrent pas encore les clefs v5 — Sequoia-PGP par exemple a prévu d’attendre la finalisation du RFC 4880bis pour les prendre en charge —, et d’autre part il est toujours possible, quoique peu probable à ce stade, que certains détails du format ne changent d’ici la version finale du RFC 4880bis — c’est d’ailleurs pour ça que les développeurs de Sequoia-PGP préfèrent attendre. Le seul avantage du format v5 est qu’il utilise SHA-256 au lieu de SHA-1 pour le calcul de l’empreinte de clef, et c’est donc une étape nécessaire pour éliminer totalement SHA-1, mais les récentes collisions démontrées sur SHA-1 ne menacent pas son utilisation pour le calcul d’empreinte ; il n’y a pas d’urgence à basculer vers le format v5, surtout avant sa finalisation officielle.
Autres changements
Voici les principaux autres changements. Pour une liste complète, y compris les changements moins significatifs, référez-vous à l’annonce officielle sur gnupg-announce.
Une nouvelle courbe elliptique, X448 (aussi appelée Ed448-Goldilocks), est désormais utilisable avec EdDSA (clef de type ed448), ECDH (clef de type cv448) et pour l’authentification SSH.
GpgSM, le volet X509/SMIME de GnuPG, prend désormais en charge à son tour les clefs ECC (y compris EdDSA).
La gestion des cartes à puce voit plusieurs améliorations significatives :
- Scdaemon gère désormais mieux le cas où plusieurs lecteurs de carte ou jetons sont disponibles ;
- Plusieurs nouveaux types de cartes sont gérées, dont les cartes PIV ;
- Une nouvelle option
--pcsc-shared permet à d’autres applications d’accéder au lecteur de carte en même temps que Scdaemon. Ce n’est pas recommandé, mais cela avait été réclamé de longue date par certains utilisateurs.
