ietf-openpgp
[Top] [All Lists]

[openpgp] Intended Recipient observation

2021-04-16 09:25:06
Hi,

I just encountered a complication when respecting the Intended
Recipient subpacket.  Others might find this useful.  Consider.

Alice has a certificate A with an encryption subkey S.  The encryption
key is stored externally on something like an HSM (in my case, gpg
agent).  The key is addressable by its grip (basically a hash of its
public MPI).

  
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/Notes;h=d420ff0aca38732cc1c867f317529f3e34e92207;hb=refs/heads/master#l87

Mallory creates certificate M and adopts S.  This is possible, because
unlike signing subkeys, encryption subkeys do not need a backsig.

Alice imports the certificate M into her local keystore.  She now has
two certificates with the subkey S.

Alice receives a signed and encrypted message.  The message is
encrypted to S (the PKESK's recipient field has the keyid of S, S'),
and A is listed as an intended recipient in the signature.

Alice's OpenPGP implementation looks in her keystore for a certificate
with S' and finds M.  She sees that S is in her HSM, so she decrypts
the message using the HSM.  It works.  Alice's OpenPGP implementation
now checks whether M is in the set of intended recipients.  Since it
isn't, her OpenPGP implementation marks the signature as invalid.

Ouch.

Marking the key in a special way (e.g., A is a personal key, and only
personal keys should be used for decryption) is not sufficient.  I'm
aware of people who use the same key material on multiple
certificates:

  $ gpg --with-keygrip -k XXX
  pub   dsa1024/0xE0BB1C42B6A8C559 2002-03-01 [SCA]
        Key fingerprint = 8C88 F05D EE7E 7A36 075F  609B E0BB 1C42 B6A8 C559
        Keygrip = 08E03C5C2B608ABBE643F4CCDC15AB1266E6F847
        ...
  sub   rsa2048/0x6374E7B91E8D8306 2016-01-27 [A]
        Keygrip = FAF3D6010613E9D1E3D66C4F81DA6914052C6DE3
  sub   rsa2048/0xCB3A5ACDBA0C288F 2016-01-27 [E]
        Keygrip = F270EF185112798820DB4AC669BC0CB1DC5523BE
  sub   rsa2048/0x44C4193E2D42869B 2016-01-27 [S]
        Keygrip = 6931F49B045414D50AFE18240BB96C4610AA018E

  pub   dsa3072/0xDCF666F298FA0DCF 2021-01-06 [SC]
        Key fingerprint = 3361 C438 401F C9C9 D52C  DDC7 DCF6 66F2 98FA 0DCF
        Keygrip = DA44D0AD8506E6CB0ECDE60DF9925D5A6AD05F3C
        ...
  sub   rsa2048/0x46E8EF0E42FE802B 2021-01-06 [A]
        Keygrip = FAF3D6010613E9D1E3D66C4F81DA6914052C6DE3
  sub   rsa2048/0x940C2C3BDB9A2EF6 2021-01-06 [E]
        Keygrip = F270EF185112798820DB4AC669BC0CB1DC5523BE
  sub   rsa2048/0xB86888BABA9CD070 2021-01-06 [S]
        Keygrip = 6931F49B045414D50AFE18240BB96C4610AA018E

(In this person's case, the subkeys happily have different
fingerprints, but this need not be the case.)


So it seems that when checking the intended recipients, it is
necessary to check whether any of the certificates with S is listed,
not just the first one that happens to have that subkey, which is my
case was sufficient to decrypt the message.

:) Neal

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>