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@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@hrz.tu-chemnitz.de
www.tu-chemnitz.de
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@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@hrz.tu-chemnitz.de
www.tu-chemnitz.de
Attached Files:
-
signature.asc (0.81 KB)
