0
$\begingroup$

I have a problem with EC public key reading from smartcard using pkcs11 library.

With the secp256r1 EC algorithm, I always get 65 or 67-byte length public key with different smartcards. But with the ePass2003 token, the length of the public key is 61 bytes. Using the pkcs11 library all sign and verify methods work fine with these pair keys(so it seems key pairs are OK), but when I read public key I get 61 bytes.

I tried opensc for double testing. There is also EC_POINT is 232 bits with ePass2003, whether 256 bits with Safenet 5110.

You can see opensc keygeneration command and result below:

"C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --modul C:\Windows\System32\eps2003csp11.dll --login --login-type user --keypairgen --id 1 --key-type EC:secp256r1
Using slot 0 with a present token (0x1)
Logging in to "ePass2003".
WARNING: user PIN to be changed
Please enter User PIN: Key pair generated:
Private Key Object; EC
  label:
  ID:         01
  Usage:      sign, derive
  Access:     sensitive, always sensitive, never extractable, local
Public Key Object; EC  EC_POINT 232 bits
  EC_POINT:   a6ea6b9ce6bd0e086f029b082e1a4096062b79293b782bb0d255363994fd846e93ef0950a1338fa2106769a46f692da9a1607cd98a68b42b85a1ab47c9
  EC_PARAMS:  06082a8648ce3d030107
  label:
  ID:         01
  Usage:      encrypt, verify, wrap, derive
  Access:     local

And it is the same code for Safenet 5110 token below:

"C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --modul C:\Windows\System32\etpkcs11.dll --login --login-type user --keypairgen --id 1 --key-type EC:secp256r1
Using slot 2 with a present token (0x2)
Logging in to "GlobalSign SafeNet Token".
Please enter User PIN: Key pair generated:
Private Key Object; EC
  label:
  ID:         01
  Usage:      decrypt, sign, unwrap, derive
  Access:     sensitive, always sensitive, never extractable, local
Public Key Object; EC  EC_POINT 256 bits
  EC_POINT:   0441044de0b0df2e13f532240a9c3dd8123c86963ee7e456e62c4be767ff76a74ee935ba431a4d6159db031377d0a1e9cf2fc0b4e818912e9cfc124bc90c13f5b055c7
  EC_PARAMS:  06082a8648ce3d030107
  label:
  ID:         01
  Usage:      encrypt, verify, wrap, derive
  Access:     local
Improve this question
$\endgroup$
3
  • $\begingroup$ @kelalaka yes 65 is fine and there is no problem if public key length is 65. But problem is that my public key is 61 byte length). I will add opensc keygeneration commend result, you can see length of ec_point. $\endgroup$
    – Uzeyir
    Feb 18, 2021 at 9:57
  • $\begingroup$ @MaartenBodewes i tried to generate some keys and all of them are 61 byte length with this token $\endgroup$
    – Uzeyir
    Feb 18, 2021 at 10:56
  • $\begingroup$ It's possible that the specific public key you have has a particularly small $X$ coordinate, less than $2^{223}$ - this is unlikely, but can occur on occasion. This would DER encode to an unusually small value, such as you see - might this be the case? $\endgroup$
    – poncho
    Feb 18, 2021 at 14:53

2 Answers 2

Reset to default
2
$\begingroup$

The EC_POINT must be a ASN.1-encoded octet string, and the ePass2003 result does not seem to be valid ASN.1 (compare the Safenet 5110 value and the ePass2003 value)

(Due to a fun coincidence, the octet string ASN.1 prefix is also 04, so the byte that identifies that it's an uncompressed point is actually the second 04 in the third byte, in the Safenet 5110 output)

I don't know exactly what it's returning, but it's certainly wrong. It doesn't matter for the signing/verification process because they happen inside the token and don't rely on the EC_POINT value returned by the token.

My guess is that internally it has the correct value, but the ePass2003 code that returns the EC_POINT value has a bug.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Hmm, interesting. There is something else too, that the 232 bits are 61 bytes in size. So 3 bytes are missing and they are also missing from the reported key size. $\endgroup$
    – Maarten Bodewes ♦
    Feb 18, 2021 at 21:45
  • $\begingroup$ I also think that it is a bug of pkcs11 library of token. So the keys inside the token are OK, the problem with exporting public key. I wrote to vendor, hope they will catch the problem. $\endgroup$
    – Uzeyir
    Feb 19, 2021 at 7:05
1
$\begingroup$

Yes, it was a bug in PKCS11 library of token. Vendor resolved the problem and after getting a new library I can read 67 byte EC_POINT from token. So it is impossible to get 61 byte for EC256 bit public keys:) Thanks to you guys!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.