Checking key server response against the request parameters

[Stefan Tomanek]

While working with the gnupg source code, I noticed that gnupg does not take
the query itself into consideration when retrieving key data from a server
(--search-key, --recv-key); regardless of the query issued, gnupg will happily
import anything returned.

This poses a few problems:

A malicious keyserver (or man in the middle) can "pollute" the keyring with
additional keys, making it hard to identify the correct ones. Creating keys
with identical (short) key ids has become easy over the years, so it might be
possible for an attacker to introduce bogus key material into the keyring of a
targeted victim (who might not pay attention to the real fingerprint after
importing).

It also violates the principle of least surprise:
Issuing a very specific command like receiving a key identified by its
fingerprint (gpg --recv-keys 0x15F900BFBA9B685D15D0266C2788CD17B78FEAFA)
should not bear the possibility of importing completely unrelated key material;
neither should 'gpg --refresh-key'.

I've created a set of patches to tackle this issue:

1. display the key fingerprint when searching for keys

When using vague arguments to search for matching keys on the servers, current
releases of e.g. SKS (1.1.4+) return the entire fingerprint in the result set
instead of a shorter key id. When displaying the result, GnuPG cuts this down
to the setting of --keyformat, possibly hiding vital information for key
identification. Checking the fingerprint after importing the key (and removing
it on mismatch) is prone to user neglect and error.

With my patches applied, the fingerprint (if available) is shown to the user
_before_ the key is added to the keyring.

2. filter the retrieved key data by applying the constraints of the query

Instead of blindly importing anything returned by the keyserver, the changeset
introduces a filtering mechanism that takes the initial request into
consideration. If, for example, the get request was issued using a complete
fingerprint (like when using --refresh-keys or --search-keys), the filter
function will look at each key to be imported and match its calculated
fingerprint against the initial query value.

This prevents malicious attackers from "slipping" additional keys into the
result set.

I've already sent the patches to this list (however, they might be stuck in
moderation). The changeset is also available on my github account - although
based on 1.4, they should also be applicable to the 2.0 branch.

https://github.com/wertarbyte/gnupg/compare/stable-1-4...keyserver_fpr

I'd really like to see those changes integrated into the official tree;
of course, any feedback is welcome as well.

Stefan Tomanek
-- 
if(is) - Institut für Internet-Sicherheit
Westfälische Hochschule, Gelsenkirchen