Expose EC_NewKeyFromSeed() to PKCS#11

NEW
Unassigned

Status

NSS
Libraries
P3
normal
2 years ago
a month ago

People

(Reporter: ttaubert, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(firefox47 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
To properly support WebCrypto PKCS#8 imports we need a method to compute the point on the curve for a given secret value. It would also be nice to use that same method for PKCS#8/JWK imports to check whether (x,y) = G*d for a given curve.
(Reporter)

Comment 1

2 years ago
Created attachment 8715714 [details] [diff] [review]
0001-Bug-1245777-Expose-EC_NewKeyFromSeed-to-PKCS-11.patch
Attachment #8715714 - Flags: review?(rrelyea)

Comment 2

2 years ago
Comment on attachment 8715714 [details] [diff] [review]
0001-Bug-1245777-Expose-EC_NewKeyFromSeed-to-PKCS-11.patch

Review of attachment 8715714 [details] [diff] [review]:
-----------------------------------------------------------------

So we can't just add new functions to PKCS #11. Also, you are using a pretty low level value when I think the high level primitive is you have an ECC private key and you want the public key falue.

In that case I think we can define a CKM_NSS_PUBLIC_FROM_PRIVATE as a derive mechanism. We'd call C_Derive() with the handle from the private key. It will return a handle to the public key. For ECC it would use EC_NewKeyFromSeed() to get the private key, DH, DSA would use DSA_NewKeyFromSeed(), and RSA would use build_rsa_from_primes() [you'd have to export a function from freebl to softokn to handle this.

Ideally your protocol will generate an ECC private key, though you could build it using C_CreateObject() and setting all the right attributes. It's better if you don't need to do that. Usually if you are doing that it means your protocol code is carrying to many secrets in the code itself and not leaving them in the token.

bob

::: lib/softoken/fipstokn.c
@@ +1566,5 @@
> +
> +    return NSC_CurvePointFromSecret(pParams, ulParamsLen,
> +                                    pSecret, ulSecretLen,
> +                                    pData, ulDataLen);
> +}

We can't just add functions through the PKCS #11 interface without working through the PKCS #11 oasis group. PKCS #11 is a standard, and new functions are a no-no.

We could create a private mechanism, and use once of the existing functions on the mechanism.
Attachment #8715714 - Flags: review?(rrelyea) → review-
(Reporter)

Updated

8 months ago
Assignee: ttaubert → nobody
Status: ASSIGNED → NEW
(Reporter)

Updated

a month ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.