Re: WebCrypto Security Analysis

On Fri, Mar 21, 2014 at 11:34 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Fri, Mar 21, 2014 at 9:51 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>> 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.
>>
> Yep, as I said, the nature of the assertions which *can* be made with http
> content delivery are of the kind "This message came from the same entity
> (Alice|Mallory) as I agreed keys with at some previous time X."
>
> Are you disputing this assertion itself, or whether it is useful ?
>
> ...Mark
>

I'm disputing the assertion.

"I agreed keys with (Alice|Mallory) at some previous time X" - that
statement is self-containable
"This message came from (Alice|Mallory)"

You can't assert at Time Y that the message came from the same party at
Time X, if the *code* used to create that message is delivered insecurely.

The point being you may have agreed upon keys with Alice, but then the
message came from Mallory - because Mallory injected her code to create a
custom message using Alice's credentials.

Likewise, when you agree upon keys (at Time X), you can't be sure whether
you're agreeing with Alice or Mallory, unless you're using a secure
transport.

So without a secure transport at both Time X and Time Y, you can't be sure
that the party you agreed upon keys with is the same party that authored
the message using those keys. Which is the point.


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