URL: https://linuxfr.org/news/gnupg-2-3-0-est-sorti Title: GnuPG 2.3.0 est sorti Authors: gouttegd Yves Bourguignon, Xavier Teyssier, Maderios, palm123 et Xavier Claude Date: 2021-04-07T22:49:16+02:00 License: CC By-SA Tags: Score: 5 Le 7 avril 2021, le projet GnuPG a publié la première version officielle de sa nouvelle branche de développement, GnuPG 2.3.0. Les nouveautés de cette version sont nombreuses, cette dépêche va passer en revue les plus significatives. ---- [L’annonce officielle sur la liste gnupg-announce](https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000458.html) ---- 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](https://gnupg.org/download/index.html#end-of-life) 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](https://trustedcomputinggroup.org/work-groups/trusted-platform-module/) 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](https://sourceforge.net/projects/ibmtpm20tss/)), l’autre par une communauté de développeurs menée par Intel ([tpm2-tss](https://github.com/tpm2-software/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](https://fr.wikipedia.org/wiki/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](https://tools.ietf.org/html/rfc6637)) 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](https://openpgpjs.org/), [Sequoia-PGP](https://sequoia-pgp.org/), [RNP](https://www.rnpgp.org/software/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](https://tools.ietf.org/html/rfc4880), remonte à 2007) est en cours de refonte. C’est le projet [4880bis](https://gitlab.com/openpgp-wg/rfc4880bis), 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](https://tools.ietf.org/html/rfc2119)) ê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](https://linuxfr.org/users/gouttegd/journaux/ocb-serait-il-toujours-protege-par-des-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](https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000458.html). Une nouvelle courbe elliptique, X448 (aussi appelée [Ed448-Goldilocks](https://eprint.iacr.org/2015/625)), 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](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-2.pdf) ; * 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. [^1]: Le protocole Assuan est le protocole utilisé pour toutes les communications inter-processus au sein du projet GnuPG (entre *gpg* et *gpg-agent*, entre *gpg-agent* et *scdaemon*, entre *gpg-agent* et les différents *pinentries*… et maintenant entre *gpg* et *keyboxd*).