Accept the raw CKA_EC_POINT for Edwards/Montgomery public keys (PKCS#11 v3.1+), not only the v3.0 DER form
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 54/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- cpp
- 領域
- backend, cryptography, security
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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
masterat 884cb38 (2026-09-03), OpenSSL backend (the Botan backend uses the sameDERUTILconversion)
Steps to reproduce
C_CreateObjectaCKO_PUBLIC_KEYwithCKK_EC_EDWARDS,CKA_EC_PARAMS= Ed25519 (OID06 03 2B 65 70or PrintableStringedwards25519),CKA_VERIFY = CK_TRUE, andCKA_EC_POINT= the raw 32-byte RFC 8032 test 3 public key (fc51cd8e…48908025).C_VerifyInit+C_VerifywithCKM_EDDSAover 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
OSSLEDPublicKey::createOSSLKeypasses the stored value throughDERUTIL::octet2Raw.octet2Rawreturns an empty string unless the value starts with0x04, so no OpenSSL key is created.BotanEDPublicKeydoes the same.- Key generation writes the DER form (
setFromOSSL:setA(DERUTIL::raw2Octet(raw))).
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 formC_GetAttributeValuereturns, "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.
- 主要言語
- C++
- スター
- 1.1k
- フォーク
- 434
- 平均マージ
- 12日 14時間
- マージ済み PR（30日）
- 2
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
softhsm/SoftHSMv2 のほかの issue
-
C_DigestKey digests a sensitive EC private key's CKA_VALUE: no check that the object is a secret keyオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 56/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 57/100
softhsm/SoftHSMv2 の issue をすべて見る
似ている issue
-
mlir
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
llvm/llvm-project#241070 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
backlog documentation
難易度 1/5 1時間未満 初心者へのやさしさ 96/100
EchoTools/nevr-runtime#2354 ·
メンテナーはふだん 1 日以内に返信
-
help wanted new command
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
tldr-pages/tldr#25111 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
Ask the `ServerHelper` for fresh headers on every poll in `Future::get`, as is done for cookiesオープンenhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
NVIDIA/cuda-quantum#5886 ·
メンテナーはふだん 1 日以内に返信