Re: WebCrypto with ECMAScript 5.1?

On Wed, Aug 3, 2016 at 12:08 PM, Waitzman, David (Contractor) <
David_Waitzman@comcast.com> wrote:

> Eric,
>
> Thanks for the response and apologize it was not worded well enough.
>
> My security model does require unextractable keys.
>
> The requirements include a browser implementation that, inconsistently,
> only has ECMAScript 5.1 support, but also has native WebCrypto, MSE, EME
> and an associate CDM.  To function, the WebCrypto implementation,
> if up-to-spec, would need a polyfill for Promises.  Can a secure up-to-spec
> WebCrypto implementation use a polyfill for Promises?
> My concern here is that is there a security risk introduced when handling
> the asynchronous nature of Promises via a polyfill (since it is necessarily
> in Javascript, not native) when mixed with an otherwise native
> implementation of WebCrypto?
>
> *Alternatively*
> Perhaps this WebCrypto implementation could not be up to the current
> WebCrypto spec, but only to an older version of the spec before Promises
> were required.  Would such an implementation be so full of problems
> (because of the old WebCrypto spec, probably from June 2013) that it would
> not be secure?
>
> OR perhaps the answer is that the requirements that I was given don’t make
> sense, since (I theorize that) unextractable keys requires a native
> WebCrypto which requires a native implementation of Promises, which in turn
> requires ECMAScript 6?
>

Your hypothetical scenario still strikes me as odd.

But, OK, let's say you had a browser with a native non-Promise-based
implementation of Web Crypto (which would not be compliant with today's
version of the spec), and you wanted to adapt it to run with Promises....
sure, you can do that!

In fact I believe there is an example of doing just this at:
https://github.com/vibornoff/webcrypto-shim
It looks like this project will adapt Internet Explorer 11's event-based
Web Crypto implementation (which targeted an earlier version of the spec),
to use Promises (via a polyfill)

Simply wrapping an event-based API to be a Promise-based API (using a
Javascript level polyfill) will not be a security concern in of itself. The
security boundary for access to keying material and whatnot needs to be at
a lower level than the Promise polyfill, so you shouldn't be able to
violate those constraints by wrapping it with a Promise polyfill or mucking
with the CryptoKey objects on the JS side of things (if you could, then the
implementation was broken).

That said I would have other concerns if you are using some old spec
implementation, or rolling your own. How complete was the implementation?
Did it have bugs that were never addressed? And also is it actually
compatible with the latest version of the Web Crypto API?

For instance, older versions of the spec IIRC did not bind hashes during
RSA key import or generation. I believe that is the reality reflected in
Safari's implementation. So there are other behaviors that may be different
than just the Promise vs Event delivery of results.


> On Aug 3, 2016, at 12:55 PM, Eric Roman <ericroman@google.com> wrote:
>
> I am not sure that I parsed your question or motivation correctly; will
> try to answer it two different ways:
>
> (a) If your environment doesn't have Promises, then necessarily your
> environment does not provide a native implementation of Web Crypto either
> (certainly not the version in the latest draft).
>
> In that case you would need to provide Web Crypto as a polyfill too, and
> so the question really is:
> "are there security risks to using Web Crypto polyfill XXX rather than
> built in platform support?"
>
> Yes -- It depends on your polyfill, but assuming a Javascript-side
> implementation you should consider:
>
>   * Implementation quality of the polyfill (is it a mature library that
> properly implements cryptographic primitives)
>   * Does your security model require unextractable keys (a Javascript
> polyfill almost surely cannot provide this; there are also subtle
> challenges like not revealing keying material due to non-constant timing of
> operations, for which all bets are off in a JS runtime environment).
>
> (b) If on the other hand your question is specifically about whether
> ECMAScript 6 provides important security features needed for Web Crypto,
> then the answer is No. The use of Promises for instance does not provide
> any security benefits. In fact earlier versions of the spec did not use
> Promises.
>
> On Tue, Aug 2, 2016 at 6:50 PM, Waitzman, David (Contractor) <
> David_Waitzman@comcast.com> wrote:
>
>> I want to use WebCrypto, Encrypted Media Extensions, and Media Source
>> Extensions in a context where only ECMAScript 5.1 is required.  So I need
>> to at least use a polyfill for Promise, as it is an ECMAScript 6 feature.
>> Any other polyfills that I would need?  Would any of those polyfill(s)
>> somehow introduce a security risk that would not be present if ECMAScript 6
>> was instead used?
>>
>
> --
> David Waitzman
> Envieta Systems LLC
>
>