Subject: [openpgp] Intended Recipient observation

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 16 Apr 2021 16:24:34 +0200

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

---

From: [email-masked]
Date: Fri, 16 Apr 2021 12:31:01 -0400

On 4/16/2021 at 10:24 AM, "Neal H. Walfield"  wrote: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.  T
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. 

=====

Why would Alice want to import M's key?

Unless M was once a friend of Alice, and unsuspected by her, now bears
her ill will,
and is familiar with her encryption subkey S, and now created a new
certificate M'
with her encryption subkey S, and sends it to the server.

Still, in order for her to Import M' as a new key by M, she would
check first if M' was also signed by M.
If she then sees a decryption problem, she would (thanks to your
pointing this out), 
check for duplicate subkey S in her keyring, and then find out that M
does bear her ill will.

As most users are familiar with their encryption subkey's fingerprint,
it would be a good idea to check any prospective public key for an
encryption subkey fingerprint, before importing it.

Thanks for pointing this out.
(Doesn't affect me though, as am from old school that doesn't use
subkeys,
where the primary certificate signs, decrypts and authenticates).

vedaal

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 16 Apr 2021 18:41:58 +0200

On Fri, 16 Apr 2021 18:31:01 +0200,
[email-masked] wrote:
> On 4/16/2021 at 10:24 AM, "Neal H. Walfield" <[email-masked]> wrote:

In the software that I'm working on the "keyring" is simply a cache.
We aggresively harvest all keys that we encounter (storage is cheap),
and rely on our trust model to separate the wheat from the chaff.

>  Still, in order for her to Import M' as a new key by M, she would check first if M' was also signed by M.
>  If she then sees a decryption problem, she would (thanks to your pointing this out), 
>  check for duplicate subkey S in her keyring, and then find out that M does bear her ill will.

In my opinion, we should shift as little complexity as possible to the
user.  In our case, this means that Sequoia has to worry about a lot
more corner cases, such as this one, but I think it is worth it.

>  As most users are familiar with their encryption subkey's
>  fingerprint, it would be a good idea to check any prospective
>  public key for an encryption subkey fingerprint, before importing
>  it.

The user population that I'm targetting doesn't understand how to do
this nor do they want to learn about these nuances.

>  (Doesn't affect me though, as am from old school that doesn't use subkeys,

Thanks for the feedback!

:) Neal