Checking key server response against the request parameters

[Stefan Tomanek]

Dies schrieb Stefan Tomanek (tomanek at internet-sicherheit.de):

> And it looks like you are working under the assumption that a) the keyserver is
> playing nice with you and b) you are actually talking to the keyserver you
> specified. Both assumptions are completely bogus, considering that is trivial
> to mount an man-in-the-middle attack against keyserver traffic.

After investigating the issue further, even more attack scenarios come to mind.

Consider this:

John H. Newuser installs gnupg and enigmail.

He fetches the public keys from his coworkers (to verify their signatures),
using the keyserver.

He then generates a key pair for himself and transmits confidential material
to someone, of course checking the fingerprint of the recipient's key first.

Well, at this point, he might have already run into trouble without even
noticing. At every key server action, it is possible for the server (or anyone
in the middle) to poison his keyring.

In this scenario, the malign keyserver sent an additional key with its replies,
matching the User ID of our victim. GnuPG will in fact add this key to the
keyring, disregarding the fact that the user has never asked for it.

The fun fact: The secret key remains in control of the attacker, while enigmail
(and many other MUAs as well) encrypts every mail using the injected public key
(encrypt-to-self), since gnupg will search in a linear fashion through the
pubring for matching keys.

I guess that this scenario can be mitigated in many ways, but in my opinion
gnupg should never add keys to my secring/pubring without me explicitly asking
for it.

-- 
if(is) - Institut für Internet-Sicherheit
Westfälische Hochschule, Gelsenkirchen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: </pipermail/attachments/20130918/d1542791/attachment.sig>