Re: WebCrypto Security Analysis

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





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