'Function::GenerateKeyPair': FunctionFailed with Nitrokey NetHSM v2.0.0 PKCS#11 lib

[and0x000]

I'm tinkering with the nitrokey/nethsm docker container and their .so PKCS#11 lib (v2.0.0) in combination with cascade using the cascade Debian packages from the NLNetLabs mirror.
Package versions are

• kmip2pkcs11 -> 0.1.0~alpha-1bookworm
• cascade -> 0.1.0~alpha4-1bookworm

I added the hsm to the cascad policy (cascade hsm add) and verified connectivity of the .so with pkcs11-tool.

However, when trying to add a zone (cascade zone add), I get these error messages:

2025-11-20T14:28:04.848016Z ERROR cascade: Error: Failed to add zone: Zone registration failed: Keyset command '/usr/libexec/cascade/cascade-dnst keyset -c /var/lib/cascade/keys/test.zone.cfg init' returned non-zero exit code: exit status: 1 [
  stdout=,
  stderr=
    [/usr/libexec/cascade/cascade-dnst] ERROR: KMIP request failed: Internal error: Missing response payload: Server error: Operation CreateKeyPair failed: Failed to create key pair: Relay failed to invoke PKCS#11 function 'Function::GenerateKeyPair': FunctionFailed
    [/usr/libexec/cascade/cascade-dnst] ERROR: KMIP key generation failed: a problem occurred while communicating with the KMIP server: Internal error: Missing response payload: Server error: Operation CreateKeyPair failed: Failed to create key pair: Relay failed to invoke PKCS#11 function 'Function::GenerateKeyPair': FunctionFailed
]

Logs from the relevant section (log level trace):

[...]
Nov 20 14:28:04 cascade-test /usr/bin/kmip2pkcs11[2806231]: C_FindObjectsInit() template: Some(CkRawAttrTemplate { ptr: 0x7f48500060c0, count: 1 })
Nov 20 14:28:04 cascade-test /usr/bin/kmip2pkcs11[2806231]: attr 258: Some([165, 181, 252, 142, 21, 207, 56, 246, 45, 144, 11, 229, 94, 108, 87, 179, 56, 90, 128, 188])
Nov 20 14:28:04 cascade-test /usr/bin/kmip2pkcs11[2806231]: ID [165, 181, 252, 142, 21, 207, 56, 246, 45, 144, 11, 229, 94, 108, 87, 179, 56, 90, 128, 188] is invalid: not a UTF-8 string
Nov 20 14:28:04 cascade-test /usr/bin/kmip2pkcs11[2806231]: Invalid ID in key requirements
[...]
Nov 20 14:28:04 cascade-test /usr/bin/kmip2pkcs11[2806231]: ID [165, 181, 252, 142, 21, 207, 56, 246, 45, 144, 11, 229, 94, 108, 87, 179, 56, 90, 128, 188] is invalid: not a UTF-8 string
Nov 20 14:28:04 cascade-test /usr/bin/kmip2pkcs11[2806231]: C_GenerateKeyPair() failed to generate key: InvalidAttribute(258)
Nov 20 14:28:04 cascade-test /usr/bin/kmip2pkcs11[2806231]: C_GenerateKeyPair failed with error FunctionFailed
[...]

The passed array translates to various non-printable characters in most all the encodings I tried.

Best correlation in documentation for the error message that I found was NetHSM limitting the key IDs to A-Z, a-z and 0-9. But I have no clue if this is the root cause, a too strict limitation of NetHSM, a incorrect use of PKCS#11 by cascade/kmip2pkcs11 or if that's the right correlation at all.

Please let me know if this is the wrong spot for this error report ...

[ximon18]

Hi @and0x000,

Thanks for the report, and for taking the time to try out Cascade.

I'm surprised as I see on https://cascade.docs.nlnetlabs.nl/en/latest/hsms.html that I tested earlier with a NitroKey Docker container.

I'll have a close look at what you wrote and re-test myself and get back to you as soon as I can.

Ximon

[and0x000]

best guess would be, that you tried out a prior PKCS#11 lib of theirs.

I took a closer look at the release notes and it seems that they addressed this specifically in the v2.0.0. That version was released pretty recently on October 15th.

Fix ID validation. The new requirements are:
The ID must not be empty and not be longer than 128 characters.
The first character must be in the range a-z, A-Z or 0-9.
The remaining characters must be in the range a-z, A-Z or 0-9 or one of the characters ., -, _.
The characters ., - and _ can only be used with NetHSM v3.0 or later.

Edit: Yes, that likely seems to be the cause. Running kmip2pkcs11 with version 1.7.2 (latest prior to 2.0.0) of their PKCS#11 lib works.

[ximon18]

@and0x000,

I'll sort this out.

Thanks for the EXCELLENT bug reporting.

Ximon

[ximon18]

Regarding this:

But I have no clue if this is the root cause, a too strict limitation of NetHSM, a incorrect use of PKCS#11 by cascade/kmip2pkcs11 or if that's the right correlation at all.

It's too strict in my opinion. The PKCS#11 specification defines CKA_ID as a byte array, not text, of unspecified length, and which is permitted to be empty, and further says:

The CKA_ID field is intended to distinguish among multiple keys. In the case of public and private keys, this field assists in handling multiple keys held by the same subject; the key identifier for a public key and its corresponding private key should be the same. The key identifier should also be the same as for the corresponding certificate, if one exists. Cryptoki does not enforce these associations, however. (See Section 4.6 for further commentary.)

In the case of secret keys, the meaning of the CKA_ID attribute is up to the application.

And in section 4.6 it says:

The CKA_ID attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject (whether stored in the same token or not). (Since the keys are distinguished by subject name as well as identifier, it is possible that keys for different subjects may have the same CKA_ID value without introducing any ambiguity.)

It is intended in the interests of interoperability that the subject name and key identifier for a certificate will be the same as those for the corresponding public and private keys (though it is not required that all be stored in the same token). However, Cryptoki does not enforce this association, or even the uniqueness of the key identifier for a given subject; in particular, an application may leave the key identifier empty.

And further, a certificate subject key identifier is defined here and explicitly mentions values which are not strings, e.g. _"One common method for generating unique values is a monotonically increasing sequence of integers".

To my mind these definitions conflict with the length and byte value limitations imposed by NitroKey.

[ximon18]

I note that OpenDNSSEC limits generated IDs to 16 bytes, while kmip2pkcs11 limits them to 20 bytes, the latter being based on observed subject key identifier values of 160 bits which is also noted by RFC 3280 and 5280:

The keyIdentifier is composed of the 160-bit SHA-1 hash of the
           value of the BIT STRING subjectPublicKey (excluding the tag,
           length, and number of unused bits).

[robin-nitrokey]

We are currently working on a solution that would encode the problematic IDs before sending them to the NetHSM, see Nitrokey/nethsm-pkcs11#303. There will be a release candidate with this feature in the next days.

[ximon18]

Wow, nice to hear, and thanks @robin-nitrokey for the timely update!

[ximon18]

@and0x000: Given the update by @robin-nitrokey can I close this as not planned?

[and0x000]

@and0x000: Given the update by @robin-nitrokey can I close this as not planned?

sure, go ahead as you like.