Re: WebCrypto Security Analysis

On Thu, Mar 20, 2014 at 1:01 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> 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.
>

Ryan is right, of course, that security assertions that can be made if the
content is delivered over https cannot be made if he content is delivered
over http. However, this does not mean there are no useful security
assertions for the case where content is delivered over http. It would be
good to have the nature of the assertions which can be made properly
investigated and documented.

Specifically, most of the assertions that can be made for the http case are
in the "Trust on First Use" category: if an authentication key is agreed
between client and server at time X, then the client can be sure at time Y
that they are talking to the same entity they were talking to at time X
(which may be A MITM, or may be the intended server, you don't know).
Likewise the server can be sure they are talking to the same entity at time
Y as they were at time X (which, again, may be either a MITM or may be the
client). If you have other reasons to believe there was no MITM at time X,
such assertions can be useful.

Furthermore, the mixed mode case, in which https is used at time X and http
at time Y (with the key being communicated between origins using
postMessage) bears investigation too.

...Mark