Re: WebCrypto Security Analysis

On Wed, Mar 19, 2014 at 7:40 AM, Kelsey Cairns <kelsey.cairns@inria.fr>wrote:

> Dear W3C Crypto API WG,
>
> Here at INRIA we're starting a security analysis on the current draft
> of the Crypto API, co-funded by INRIA and W3C. The idea is to try to
> get some results in before the end of the last call period.
>

Could you define what your actual goal is with this security analysis?

Typically, one does a security analysis of a protocol - does it live to the
expected goals, and provide the expected assurances. WebCrypto itself
provides many algorithmic building blocks, and (with the exception,
arguably, of Wrap/Unwrap), doesn't really implement a protocol itself (as
opposed something like JOSE JWS or XML DSig, which are arguably both
formats *and* protocols)


>
> Doing analysis of an API spec is a slightly unusual activity, it can
> often lead to conclusions like "if the API is implemented this way.."
> or "if the application program uses the API like this.." which can
> seem a bit superficial, but we will aim to produce something concrete
> output in terms of implementation advice, test cases for
> implementations, etc.
>

> As an example of the kind of things we find, one of the things we were
> looking at in the spec this morning was padding oracles on key unwrap
> operations. These are common in implementations of PKCS#11, for
> example.. Following the current WebCrypto spec, if you were to unwrap a
> key using
> AES-CBC or RSA PKCS1v1.5, incorrect padding would lead to "DataError"
> or " OperationError" respectively. Meanwhile, the error if the
> ciphertext is correctly padded but the key is too long or too short,
> the error is "SyntaxError". The fact that these are different *could*
> be enough to allow a network attacker to obtain the encrypted key by
> chosen ciphertext attack, which would be relevant say for use case 2.2
> (Protected Document Exchange).
>

Correct. This is a point of extreme tension within the working group -
whether or not Key Wrapping / Unwrapping can provide security guarantees
against the host code executing. This was the key of the debate as to
whether or not to provide these primitives to begin with - or whether a web
application can polyfill them.

Individually, I remainly highly suspicious about this. As a security-minded
individual, I can tell you there are dozens of ways to botch this, beyond
just algorithm choice. As an editor, I can simply say "Please show more
about how this is completely broken", so that the WG can take a closer look
about the security guarantees it's attempting to make, and properly
evaluate whether or not these APIs belong. I suspect that some members will
insist they do, unfortunately, so guidance is welcome.


>
> As a first step we were planning to look in more detail at the key
> management subset of the API, but if there are any areas that are of
> specific concern where you'd like us to take a closer look and you
> haven't had time please let us know. All feedback welcome.
>
> Best,
>
> Graham Steel & Kelsey Cairns
>

I think a clear point of use/misuse to examine would be be the issues
previously discussed in ISSUE-21 (
https://www.w3.org/2012/webcrypto/track/issues/21 ) . The WG had, in the
past, discussed requiring SSL/TLS for this API, as well as requiring more
active mitigations for scripting issues via CSP (
http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0230.html ).
There were and are some strong objections to this.

Since part of your sponsorship includes "implementation advice", and
conclusions like "if the application program uses the API like this", it
would be interesting to see if INRIA can come up with any proofs of
security where the code is delivered over unauthenticated connections (eg:
HTTP)

My continued assertion is that this is impossible - messages cannot be
authenticated as coming from a user/UA, rather than a MITM. Likewise, under
HTTP, a UA/user cannot authenticate messages as coming from the server,
rather than a MITM. Encryption/Decryption results cannot be protected from
being shared with Mallory, and that there can be no authenticated key
exchange without an OOB means. Especially because Mallory can modify the JS
operating environment, any proofs of correctness of a protocol go out the
window, because the operating environment for those proofs is malleable. In
a PKCS#11 world, this would be similar to a "hostile token" that has no
pre-provisioned aspects.