Accept the raw CKA_EC_POINT for Edwards/Montgomery public keys (PKCS#11 v3.1+), not only the v3.0 DER form

Aperta
  • Qualcosa non va?
#909 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
54/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
backend, cryptography, security

Direzione di ricerca

Read OSSLEDPublicKey::createOSSLKey and BotanEDPublicKey where each converts stored CKA_EC_POINT, then compare their handling with SoftHSM::getECDHPubData and DERUTIL::octet2Raw. Check existing Edwards and Montgomery key import and verification tests; done means raw v3.1+ points import and verify successfully while DER-form points continue to work.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

SoftHSM accepts an Edwards public key's CKA_EC_POINT only as a DER OCTET STRING (04 20 ‖ point for Ed25519). That's how PKCS#11 v3.0 described it. PKCS#11 v3.1 and v3.2 changed the attribute to the raw key bytes: "Public key bytes in little endian order as defined in [RFC 8032]" (and [RFC 7748] for Montgomery keys).

With a raw point, C_CreateObject succeeds, but the key never works afterwards. C_Verify reports even a valid signature as CKR_SIGNATURE_INVALID, so the failure looks like a bad signature rather than an error. Applications and libraries that follow v3.1+ therefore can't import an Ed25519 public key into SoftHSM.

Could SoftHSM also accept the raw form on input? Keeping the DER form it writes would leave v3.0 applications unaffected.

Environment

  • SoftHSMv2 master at 884cb38 (2026-09-03), OpenSSL backend (the Botan backend uses the same DERUTIL conversion)

Steps to reproduce

  1. C_CreateObject a CKO_PUBLIC_KEY with CKK_EC_EDWARDS, CKA_EC_PARAMS = Ed25519 (OID 06 03 2B 65 70 or PrintableString edwards25519), CKA_VERIFY = CK_TRUE, and CKA_EC_POINT = the raw 32-byte RFC 8032 test 3 public key (fc51cd8e…48908025).
  2. C_VerifyInit + C_Verify with CKM_EDDSA over the RFC 8032 test 3 message and signature.

Observed (built from the commit above against OpenSSL 3.0.13, Linux x64):

CKA_EC_PARAMS CKA_EC_POINT C_CreateObject C_Verify of the valid RFC 8032 test 3 signature
OID 06 03 2B 65 70 raw (32 bytes) CKR_OK CKR_SIGNATURE_INVALID
OID 04 20 ‖ point CKR_OK valid
PrintableString edwards25519 raw (32 bytes) CKR_OK CKR_SIGNATURE_INVALID
PrintableString 04 20 ‖ point CKR_OK valid

For the raw rows, syslog shows:

src/lib/crypto/DerUtil.cpp(91): ByteString is not an octet string
src/lib/crypto/OSSLEDDSA.cpp(150): Could not get the OpenSSL public key

A generated Ed25519 key pair's CKA_EC_POINT is 34 bytes, 04 20 ‖ point.

Where

SoftHSM already tolerates both forms in one place: SoftHSM::getECDHPubData treats a 32/56-byte peer key as raw and wraps it.

What other tokens do

From their sources and our test runs:

  • BouncyHsm, NSS 3.131 and opencryptoki accept only the raw form, and write raw for generated keys.
  • Kryoptic accepts both: it unwraps a DER value of the expected size+2 and stores raw. It uses a config option (ec_point_encoding) to pick which form C_GetAttributeValue returns, "because of the different expected encoding in applications following the 3.0 spec vs applications following 3.1".

So a portable application has to special-case SoftHSM to import Edwards public keys.

Suggested fix

Where SoftHSM converts a stored Edwards/Montgomery CKA_EC_POINT to raw (OSSLEDPublicKey::createOSSLKey, BotanEDPublicKey), use the value as is when its length is exactly the key size (32, 56 or 57 bytes) and it isn't a valid 04 len ‖ point encoding of that size. This is the same length-based test getECDHPubData already uses. Validating the length in C_CreateObject would also report a malformed point there, instead of at first use.

For output, SoftHSM could keep writing the DER form. Alternatively, it could offer a configuration switch for the v3.1+ raw form, like Kryoptic does.

Lingua principale
C++
Stelle
1.1k
Fork
434
Merge medio
12g 14h
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di softhsm/SoftHSMv2

Tutte le issue di softhsm/SoftHSMv2

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.