1494152 - Add FreeBL API for raw elliptic curve operations for bug 1473468

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement)

Description

[Tooru Fujisawa [:arai]]

In bug 1473468, I'm going to add private WebCrypto API for elliptic curve, in order to implement tSOKE protocol which is used by WiFi authentication for Remote Debugging.
the API is more low-level than the existing WebCrypto API, and it requires some addition to NSS to expose those raw operations.

the required operation is the following:
  (a) generate elliptic curve private/public key pair from specified private key value (single integer represented by buffer/length)
  (b) return the order of the specified generator
  (c) calculate `x mod n` where x is a specified integer, and n is the order of the specified generator
  (d) calculate scalar-point multiplication on the specified elliptic curve,
  (e) calculate point-point addition/subtraction on the specified elliptic curve

(a) is used to generate a private key from a hash for the session.

(b) and (c) is preparation for (a), to generate private key value from hash
they may be unnecessary depending on the design of (a).
if the caller is supposed to provide the final private key, (b) and (c) is necessary.
if the `x mod n` operation is done inside (a), (b) and (c) are not necessarily exposed.

(d) is used to generate a public key (actually just a point on the curve), from the private key generated from the has with (a)
the public key is used as a mask.

(e) is used to mask a public key of ECDH key exchange, with the mask generated by (d)

I'll prepare some rough implementation to confirm the above APIs are sufficient to implement the private WebCrypto API.

Comment 1

[Tooru Fujisawa [:arai]]

(In reply to Tooru Fujisawa [:arai] from comment #0)
> (d) is used to generate a public key (actually just a point on the curve),
> from the private key generated from the has with (a)

the *hash

Comment 2

[Tooru Fujisawa [:arai]]

>   (b) return the order of the specified generator
>   (c) calculate `x mod n` where x is a specified integer, and n is the order of the specified generator

these parts are going to be inside freebl, and no need to expose as API

Comment 3

[Tooru Fujisawa [:arai]]

Attachment: Add raw elliptic curve operations API for FreeBL.

separated from bug 1473468.
this is for FreeBL part.

now order and mod operations are inside EC_NewKeyFromSeedWithMod.

Comment 4

[Tooru Fujisawa [:arai]]

Attachment: Part 2 (or move to other bug): Add raw elliptic curve operations API for PK11.

and PK11 part (I think this should be for new bug), but posting here for reference.

about pkcs11n.h vs pkcs11f.h part, I couldn't find a solution, so the definitions are still in pkcs11f.h.

Comment 5

[Franziskus Kiefer [:franziskus]]

Comment on attachment 9014692 [details] [diff] [review]
Add raw elliptic curve operations API for FreeBL.

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

Can you put this on phabricator?

Comment 6

[Tooru Fujisawa [:arai]]

Attachment: Bug 1494152 - Add raw elliptic curve operations API for FreeBL. r?franziskus

Add raw elliptic curve operations API for FreeBL.

Comment 7

[Tooru Fujisawa [:arai]]

can you review?
or am I supposed to apply some other change?

Comment 8

[Martin Thomson [:mt:]]

NSS policy has been to be very selective about the primitives we provide.  The cost of adding new primitives is something we bear for a long time, so we don't add them without strong reasons to that.

As for this specific change, the addition of generic EC operations at such a low level is very much outside of our usual practice.  If we consider cryptographic primitives to be footguns, the amount of damage that access at a lower-level could do is worse.  I'm also concerned about the implications of a PK11 API that allows this sort of access to keys that would otherwise have limitations on their use that prevent things like accidental or malicious disclosure of private information.

Before we get too far into this, I'd like to understand more about use cases so that I can understand why we would add these to NSS.  WiFi authentication doesn't seem like something we should be concerning ourselves with, but I clearly don't have enough context.

Comment 9

[Tooru Fujisawa [:arai]]

The context is that, we want to implement PIN based authentication for Remote Debugging over WiFi (bug 1470352).
that is the authentication between Desktop Firefox which is debugger, and remote devices (smartphone, tablet, or VR devices) which is debuggee.

And we choose a variant of tSOKE protocol [1], which is proven to be secure and fits here (bug 1473468).
the algorithm needs the following operation:

  Y* = Y + (h mod n) G'
  Y = Y* - (h mod n) G'

where Y is EC public key, h is a hash of session info, G' is a yet another generator than regular one, where the order of G' is same as the generator of P-256,
this operation masks the public key Y which is used for ECDH key exchange.

the primitives used there is, scalar-point multiplication on elliptic curve, and point-point add/subtract on elliptic curve.

and those operations are not possible with current WebCrypto API, and implementing private API still needs some primitive APIs provided by NSS, which already has them internally.

so, we're going to expose those APIs from NSS, to use from private WebCrypto API and implement the auth protocol.

let me know if there's something unclear, or something needs more detailed explanation.

[1] https://link.springer.com/article/10.1007/s10207-016-0348-7

Comment 10

[Martin Thomson [:mt:]]

The bar for inclusion of cryptographic primitives is much higher than this.

I'd much rather prefer to implement a PAKE in NSS if this were necessary.  However, it's not clear that tSOKE is the PAKE that we would want if that were the case.  We would want to ensure that whatever we implement has a broad enough market to justify its inclusion in NSS.  Right now I'd rather spend my money at a racetrack than try to pick a winner, given the vast array of PAKEs that are being proposed.

WebCrypto doesn't expose this level of primitive for a reason; I don't think that it's a good idea to overload that API with this sort of feature.

Given the context, do you really need something as complex as a PAKE?

Comment 11

[Brian Birtles (:birtles, Feb 26~ parental leave)]

We reached out to the crypto engineering team to get advice about how to design a proper authentication flow for wifi debugging (since their assessment was that the current scheme used by WebIDE is not secure) and this is the proposal that came back: https://docs.google.com/document/d/10B79mNuJajy-nIdEZrZlsnr677QO7BBW2i0maPncsww/edit

(I hope that link works for you. I'm not the owner of the doc so I can't change its visibility I'm afraid.)

It was also their advice that some of the primitives need to be implemented in NSS.

Comment 12

[J.C. Jones [:jcj] (he/him)]

I agree with Martin that, if implemented, the whole PAKE should be implemented as a primitive in NSS.

It's also important to note that Fx Accounts is in the same boat here, so we have at least two consumers of a PAKE in Gecko.

Comment 13

[Tooru Fujisawa [:arai]]

given we're moving to another protocol, closing.