Re: WebCrypto Security Analysis

On Mar 21, 2014 9:18 AM, "Mark Watson" <watsonm@netflix.com> wrote:
>
>
>
>
> 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.
>

No, they really aren't.

Regardless of how the key got there (and there are plenty of ways to screw
that up), the fundamental analysis has to look at whether any of the
assertions can be trusted if they are being processed by untrusted code:

Sign: Did this message come from Alice or Mallory-injecting-script?

Verify: Did this message come from Bob, or Mallory with Mallory-injected
script saying Bob

Encrypt: Is the Ciphertext sent to Bob the ciphertext that Alice intended,
or modified by Mallory?

Decrypt: Is the Plaintext processed by Alice what Bob sent in his
Ciphertext, or is this Mallory?

Wrap: Is this key the actually Alice's key, or is it a key of Mallory?

Unwrap: Is the unwrapped key actually what Bob intended, or is it
Mallorie's injected?

Mallory can also force an unprovisioned state at any time, so you need a
way to authenticate that. WebCrypto cannot provide that, such you must rely
on side-channels - such as Named Key Discovery or TLS.

Fundamentally, the question is: Is it possible to design a secure protocol,
where Mallory not only controls the messages being processed, but also the
instruction set to process the messages?

You can also take into consideration technologies like Service Workers,
cache policies, and persistent XSS to explore how an attacker can poison an
origin indefinitely, independent of maintaining a persistent MITM.

Since it is clear some members of the WG unfortunately feel this is
possible - which will no doubt promulgate more insecure code, and prove
many detractors of Web Crypto absolutely correct - you will find this to be
a very useful and topical avenue of exploration.

Again, to map to PKCS#11 terms - can a PKCS#11 token prevent malware?

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

Not r