Key usage of ECC keys on PKCS#15 smartcards doesn't allow decryption?

[Mario Haustein]

Dear developers,

while implementing the D-Trust ECC smartcards I encountered an issue I 
couldn't make sense of and would like to request assistance from you. I also 
couldn't find an issue in the bug tracker looking similar to it.

My test cards provides two certificates: one for qualified signatures and one 
for (non-qualified) signatures and decryption. While the signature creation 
works out of the box for both keys, I am unable to decrypt an encrypted 
message with the latter key.

This is the secret key:

           ID: 0x2F5CD959
          S/N: 71440EE33409F4256085AFE32C15B5A6
        (dec): 150556141664708457568253825304782812582
       Issuer: /CN=D-TRUST Limited Basic Test CA 1-4 2020/O=D-Trust GmbH/C=DE
      Subject: /CN=XXX/C=DE/SerialNumber=DTR230045177P0004/SN=XXX/GN=XXX
          aka: XXX at d-trust.net
     validity: 2024-01-10 22:03:55 through 2026-01-20 22:03:55
     key type: nistp256
    key usage: digitalSignature keyAgreement
ext key usage: emailProtection (suggested), clientAuth (suggested)
     policies: 1.3.6.1.4.1.4788.2.2.2:N:
  fingerprint: DF:30:3A:2E:C7:6E:60:FD:77:41:BA:03:86:F6:46:18:2F:5C:D9:59
     sha2 fpr: 53:F5:22:23:CD:AD:52:7F:8A:B6:81:FD:C3:9D:04:0A:
7D:B8:48:7C:DF:B1:4D:84:84:D2:AA:C9:BE:19:BC:94
     card s/n: 9276003211760004942F

It supports the usage flags `sign` and `derive` reported as `digitalSignature` 
and `keyAgreement` in the frontend.

I could narrow down the issue to `do_decipher()` in scd/app-p15.c. The 
function bails out at the following check.

```
  if (!(prkdf->usageflags.decrypt
        || prkdf->usageflags.unwrap
        || prkdf->gpgusage.encr     ))
    {
      log_error ("p15: key %s may not be used for decryption\n", keyidstr);
      return gpg_error (GPG_ERR_WRONG_KEY_USAGE);
    }
```

AFAIK decryption with ECDH keys is done by negotiating a common secret between 
Alice and Bob from which the symmetric encryption key is derived. So the 
`derive` key usage flag makes sense as the key is not capable of decrypting 
directly.

When skipping this check, the smartcard works fine for decryption, too.

Is it likely that the `derive` check was just forgotten at this place? I 
cannot judge the consequences of this change, which is the reason for asking 
here in advance.

Many thanks in advance for reviewing my thoughts.

Kind regards
-- 
Mario Haustein
Facharbeitsgruppe Anwendungen
Universitätsrechenzentrum

Technische Universität Chemnitz
Straße der Nationen 62 | R. 1/B303 (neu: A11.303)
09111 Chemnitz
Germany

Tel:    +49 371 531-36606
Fax:    +49 371 531-836606

mario.haustein at hrz.tu-chemnitz.de
www.tu-chemnitz.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240216/d2b6d1fe/attachment.sig>