Support for CKM_EC_EDWARDS_KEY_PAIR_GEN (EdDSA keypair generation through PKCS#11 interface) [feature-request] #98

New Issue

2025-05-28T05:35:49+08:00

N-Storm commented

2025-05-28 05:35:49 +08:00

(Migrated from https://github.com/polhenarejos/pico-hsm)

Hello,

Latest version of Pico-HSM can be built with EdDSA support, particularly ed25519, including on-card keypair generation. At least that's what I've learned from the code (EdDSA support aren't documented). From my understanding, the only user-facing tool available for this is the Python library, since attempting to generate Ed25519 keys with pkcs11-tool from the OpenSC project fails:

pkcs11-tool.exe -l - -k --key-type EC:ed25519 
Please enter User PIN:
error: Generate EC key mechanism 1055 not supported

PKCS#11 3.0 Interface added support for the EDDSA/Ed25519 key pairs as an additional mechanism. While it seems that the original SC-HSM interface never had it supported, Pico-HSM appears to rely on a non-standard approach to pass Ed25519/Ed448 curves as parameters within the same parent APDU data, as it does with ECDSA key pair generation. Because these are not supported by PKCS#11, no PKCS#11-compatible software can use them.

While the Pico-HSM doesn't interfaces with PKCS#11 directly, but parses raw APDU data, I wonder if that would be possible to add EDDSA support via PKCS#11 commands? It sounds possible to me, unless SC-HSM interface somehow restricts allowable mechanisms. If it's not, then I guess it would be possible by translating PKCS#11 method 1055 request to APDU commands and adding those in the cmd_keypair_gen.c. Which should be possible by enabling OpenSC debug output, it can log APDU frames when enabled. Or am I missing something else here?

I would be glad to help with that, if you don't have time to implement it. But my knowledge on the actual interfaces (PC/SC / APDU / SC-HSM) are pretty limited, so I'll be glad to hear some comments on my thoughts before.

Hello, Latest version of Pico-HSM can be built with EdDSA support, particularly ed25519, including on-card keypair generation. At least that's what I've learned from the code (EdDSA support aren't documented). From my understanding, the only user-facing tool available for this is the Python library, since attempting to generate Ed25519 keys with `pkcs11-tool` from the OpenSC project fails: ``` pkcs11-tool.exe -l - -k --key-type EC:ed25519 Please enter User PIN: error: Generate EC key mechanism 1055 not supported ``` [PKCS#11 3.0](https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/pkcs11-curr-v3.0.html) Interface added support for the EDDSA/Ed25519 key pairs as an additional mechanism. While it seems that the original SC-HSM interface never had it supported, [Pico-HSM appears to rely on a non-standard approach](https://github.com/polhenarejos/pico-hsm/blob/a0f6abf6a6f9073a357ed23b5ef0c7c11e20ea24/src/hsm/cmd_keypair_gen.c#L81) to pass Ed25519/Ed448 curves as parameters within the same parent APDU data, as it does with ECDSA key pair generation. Because these are not supported by PKCS#11, no PKCS#11-compatible software can use them. While the Pico-HSM doesn't interfaces with PKCS#11 directly, but parses raw APDU data, I wonder if that would be possible to add EDDSA support via PKCS#11 commands? It sounds possible to me, unless SC-HSM interface somehow restricts allowable mechanisms. If it's not, then I guess it would be possible by translating PKCS#11 method 1055 request to APDU commands and adding those in the cmd_keypair_gen.c. Which should be possible by enabling OpenSC debug output, it can log APDU frames when enabled. Or am I missing something else here? I would be glad to help with that, if you don't have time to implement it. But my knowledge on the actual interfaces (PC/SC / APDU / SC-HSM) are pretty limited, so I'll be glad to hear some comments on my thoughts before.

👍 1

polhenarejos commented

2025-05-28 16:08:16 +08:00

(Migrated from https://github.com/polhenarejos/pico-hsm)

OpenSC uses multiple drivers to communicate with the reader. In the Pico HSM case, we use the sc-hsm driver, as it offers some specific HSM functionalities that other drivers do not. However, as you guess, this driver only implements the procedures of supported features of the original sc-hsm. If this driver does not implement EdDSA support, it will not be possible to use pkcs11 with EdDSA.

The communication chain is as follows:

user --- opensc --- driver --- reader --- card

The communication between user and opensc is via terminal, commands. Between opensc and reader is via pkcs11, meaning that both endpoints (at opensc and reader) must support EdDSA. OpenSC supports it but not the driver. Between the driver and reader is CCID, usually via usb. However, this is not always true and some vendors use their propietary protocol. This is why OpenSC exists, since implements multiple vendor protocols and "wrap" them to pkcs11 interface. Finally, between the reader and the card is via ISO 7816 but, some vendors use propietary protocols.
PC/SC is the software to manage the pool of readers and smart cards. APDU is the ISO 7816 protocol unit.
For instance, there's the driver sc-hsm-embedded which brings support for AES in pkcs11 with sc-hsm but since EdDSA is not supported natively by the card, there will not be a driver able to support it.

As a summary, you cannot use EdDSA with Pico HSM and PKCS11. If you want to manipulate Edward curves and do EdDSA, you must use the pico-hsm-tool or program your own pkcs11 driver.

OpenSC uses multiple drivers to communicate with the reader. In the Pico HSM case, we use the `sc-hsm` driver, as it offers some specific HSM functionalities that other drivers do not. However, as you guess, this driver only implements the procedures of supported features of the original sc-hsm. If this driver does not implement EdDSA support, it will not be possible to use pkcs11 with EdDSA. The communication chain is as follows: user --- opensc --- driver --- reader --- card The communication between user and opensc is via terminal, commands. Between opensc and reader is via pkcs11, meaning that both endpoints (at opensc and reader) must support EdDSA. OpenSC supports it but not the driver. Between the driver and reader is CCID, usually via usb. However, this is not always true and some vendors use their propietary protocol. This is why OpenSC exists, since implements multiple vendor protocols and "wrap" them to pkcs11 interface. Finally, between the reader and the card is via ISO 7816 but, some vendors use propietary protocols. PC/SC is the software to manage the pool of readers and smart cards. APDU is the ISO 7816 protocol unit. For instance, there's the driver `sc-hsm-embedded` which brings support for AES in pkcs11 with `sc-hsm` but since EdDSA is not supported natively by the card, there will not be a driver able to support it. As a summary, you cannot use EdDSA with Pico HSM and PKCS11. If you want to manipulate Edward curves and do EdDSA, you must use the `pico-hsm-tool` or program your own pkcs11 driver.

👍 2

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dearsky/pico-hsm#98