Importing P-521 EC private key fails with CKR_ATTRIBUTE_VALUE_INVALID when private key has leading zero byte

[ivaylo-yordanov]

Importing a P-521 EC private key fails with CKR_ATTRIBUTE_VALUE_INVALID (0x13)
when the private key value contains a leading 00 byte. This is valid for P-521 keys since
the private key is 521 bits stored in 66 bytes, meaning some keys will naturally have a leading zero.

Steps to Reproduce

1. Generate or obtain a P-521 private key whose value starts with a leading 00 byte
2. Import using pkcs11-tool:

pkcs11-tool --module libkryoptic_pkcs11.so \
  --token-label "My token 1" \
  --login --pin "test" \
  --write-object private_key_ec_secp521r1.der \
  --type privkey \
  --id 06 --label "ECDSA-P521"

Expected Behavior

Key is imported successfully, as leading zero bytes are valid for P-521 private keys.

Actual Behavior

error: PKCS11 function C_CreateObject failed: rv = CKR_ATTRIBUTE_VALUE_INVALID (0x13)

Environment

• Kryoptic version: built from main branch
• OS: Ubuntu 24.04
• OpenSSL: 3.2.0
• pkcs11-tool: from OpenSC

[simo5]

Hi @ivaylo-yordanov,
it seem you are trying to write a der encoded signed integer in CKA_VALUE.
A DER encoded value would permit a leading 00 byte even though exactly for P-521 that would still be a mis-coding given there is only 1 bit in the MSB and therefore the Msb can never be 1 and therefore the leading 0 byte is never needed.

However, the PKCS#11 spec clearly says that the private key for P-521 is encoded as a "Big Integer", which is defined as:

a string of CK_BYTEs representing an unsigned integer of arbitrary size, most-significant byte first (e.g., the integer 32768 is represented as the 2-byte string 0x80 0x00)

As you can see from the example there is explicitly no leading zero even for value that would be interpreted as negative if this was a signed integer.

[ivaylo-yordanov]

Hi @simo5,
Thank you for the explanation. I am aware that the leading 0 byte is technically non-compliant with the PKCS#11 spec's "Big Integer" definition.

I forgot to mention that the same key imports successfully when using SoftHSM2, which appears to silently accept the leading 0 byte.

The key was generated using a standard OpenSSL command (openssl genpkey)

I see that Kryoptic is stricter in its compliance with the PKCS#11 spec but would it be worth considering whether Kryoptic could strip the leading zero byte and import the key?

[Jakuje]

I was asked to look into that from pkcs11-tool point of view. The pkcs11-tool parses the provided DER with EVP_PKEY_get_bn_param and passes the content of private key part from OSSL_PKEY_PARAM_PRIV_KEY to underlying pkcs11 module:

https://github.com/OpenSC/OpenSC/blob/1df21be0fb8f3e23bee113f913046f9384ac5a7f/src/tools/pkcs11-tool.c#L4645

The OpenSSL documents the private key like an unsigned integer too, so I would say this might be considered OpenSSL bug. I think it might make sense for OpenSSL to normalize the bignum values before returning them to a user.

https://docs.openssl.org/3.5/man7/EVP_PKEY-EC/#common-ec-parameters

The pksc11-tool does not really do any checking nor pre-processing so if we get non-minimal values from openssl, we just pass it on (after converting it to binary value with BN_bn2bin()).

Though, kryoptic should likely be able to ignore the bogus leading null bytes. But we are trying to implement the PKCS#11 specification as close as possible in kryoptic so even if it will work for you with softhsm, it might be that it will not work with the next PKCS#11 implementation against real HSM.

Can you try it is still the issue with some more recent OpenSSL version like 3.5 or 4.0/master?