Sauver un GnuPG corrompu

Note de service : still alive, blog mis à jour et on va essayer d’y poster un peu plus en 2020…

Ces derniers jours, j’ai remarqué qu’un processus GnuPG prenait inhabituellement beaucoup de temps et CPU.

htop-gpg

Une commande gpg --list-keys semblait tourner en boucle pendant de longues minutes.

Avec un peu de recherche, je comprends que j’avais importé une clef victime de l’attaque de spam de signature GnuPG annoncée il y a quelques mois.

$ ls -lh ~/.gnupg/pubring.gpg

... 33M ...

Une (ou plusieurs) clef a été signée des centaines de milliers de fois, rendant le système inutilisable. Une attaque simple mais pourtant assez difficile à régler pour des raisons peu rassurantes:

Why Hasn’t It Been Fixed?

There are powerful technical and social factors inhibiting further keyserver development.

The software is Byzantine. The standard keyserver software is called SKS, for « Synchronizing Key Server ». A bright fellow named Yaron Minsky devised a brilliant algorithm that could do reconciliations very quickly. It became the keystone of his Ph.D thesis, and he wrote SKS originally as a proof of concept of his idea. It’s written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that’s deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that’s literally someone’s Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.
[…]

On utilise donc un proof-of-concept comme serveur de clef GPG et personne ne sait exactement comment il fonctionne. Joie.

gpg –list-keys

Solution

La solution la plus simple serait évidemment de supprimer l’ensemble du répertoire ~/.gnupg et de recommencer. Si, pour de bonnes raisons, cette solution ne vous plaît pas, il nous faudra identifier la ou les clefs problématiques et les supprimer.

Attention, toutes les commandes ci-dessous sont très lentes (une quinzaine de minute chez moi) ! Pensez à prendre un café…

D’abord, identifier la clef problématique :

$ gpg --export | gpg --list-packets | awk -F= -v oldoff=-1 -v keyid=unset '
/^# off=/{ off = $2 + 0 }
/^:public key/{ if (oldoff>-1) { print (off - oldoff) " " keyid }; oldoff = off; keyid = "unset"; }
/keyid:/ {if (keyid == "unset") { keyid = $1; } }
END { print (off - oldoff) " " keyid ; };' | sort -n
...
18420  keyid: D9C4D26D0E604491
19724  keyid: 4A95E75A1354AAF0
15874931  keyid: DB1187B9DD5F693B
15923848  keyid: 4E2C6E8793298290

La (grande) commande bash ci-dessous vous listera vos clefs avec la taille de celles-ci. Les deux dernières avec une taille à 8 chiffres sont les clefs problématiques.

Si l’on veut les garder (au cas où), vous pouvez les exporter en plaintext (ce qui donne un fichier de 21MB pour la clef ci-dessous)

$ gpg -a --export 'DB1187B9DD5F693B' > badkey.asc

Mais, il y a de bonnes chances que vous désiriez plutôt les supprimer.

$ gpg --delete-key 'DB1187B9DD5F693B'
gpg (GnuPG) 2.2.17; Copyright (C) 2019 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.


pub  rsa4096/DB1187B9DD5F693B 2015-01-17 Patrick Brunschwig 

Delete this key from the keyring? (y/N) y
gpg: removing stale lockfile (created by 598252)

Après la suppression des clefs problématiques, tout devrait rentrer dans l’ordre !

Source des commandes : Mitigating Poisoned PGP Certificates (CVE-2019-13050)

Vus : 352
Publié par mart-e : 65