Re: W3C Web Crypto WG - Is our deliverable doomed ?

On Tue, Sep 18, 2012 at 8:53 AM, Mark Watson <watsonm@netflix.com> wrote:

>  One of the points missing from the article, which we have considered a
> lot, is the fact that it is possible to build systems with useful security
> properties, whilst always accepting that we can't really trust the
> Javascript code at the client (for the reasons given in the article).
>

>  Specifically, we trust the browser code more than the Javascript code
> and we trust code in secure elements even more. We take care understand the
> security properties we have through the lens of exactly what operations are
> being performed by which code and with which data.
>
>  This is why the API becomes much more interesting when we introduce
> concepts like pre-provisioned keys. Without them, then I fear the API does
> indeed suffer from many of the issues identified in the article.
>
>  Pre-provisioned keys allow us to bind to something we trust, even if
> that is just the browser code, and from there we can infer something
> useful. Without that, then any Javascript could be using a malicious
> polyfill WebCrypto API and all your security bets are off.
>
>  Having said that, it is certainly possible to 'simulate' pre-provisioned
> keys (insecurely) in polyfill for test and API validation purposes. I
> wouldn't rule out some kind of obfuscation-based JS polyfill implementation
> with pre-provisioned keys, but that does sound like a "challenging" project
> that I am not about to embark on ;-)
>
>  …Mark
>
>
Respectfully, I have to disagree with Mark here. I do not think
pre-provisioned keys (smart card or deivce) do not, in themselves, buy any
additional security properties, just as they would not and do not within
native applications.

To take a step back, to see how I get there, let's take a step back and
look at the points raised in the article:

   - Secure delivery of Javascript to browsers is hard
      - If you have SSL, just use SSL
   - Browsers are hostile to cryptography
      - The prevalence of content-controlled code
      - The malleability of the Javascript runtime
      - The lack of systems programming primitives needed to implement
      crypto
         - The browser lacks secure random number generation
         - The browser lacks secure erase
         - The browser lacks functions with known-timing characteristics
         - A secure keystore
      - The crushing weight of the installed base of users
   - The view-source transparency is illusory
      - Unlike native applications, Javascript is delivered on demand and
      thus may be mutated in time
      - An exploit server side can compromise many tens or hundreds of
      thousands of users

To address these points, let's look at what we have at our disposal.


   - This work
      - Our API so far provides secure RNG and functions with known-timing
      characteristics, along with a secure keystore. Yes, we don't
offer a secure
      erase, nor do we offer a generic secure memory comparison, and perhaps
      those are things we can look at in the future. But I'd suggest
that, given
      the general framework of what is brought by the API, it's not as c
   - Content Security Policy
      - Can address the malleability problem and the prevalence of
      content-controlled code
   - Web Intents
      - Can address the malleability problem and the prevalence of
      content-controlled code
   - The view-source transparency is illusory
      - The W3C has, through various efforts, looked at offline [1][2] and
      system applications [3] that can provide stable source over time.
      - Several popular user agents implement support for forms of signing
      or organizational validity that is equivalent to native code.
      - Given many auto-updating systems today, the same argument can be
      made of native applications.
   - If you have SSL, just use SSL
      - As demonstrated by our use cases, SSL is not in and of itself
      suitable or equivalent to what is being requested.
   - An exploit server side can compromise tens or hundreds of thousands of
   users
      - As demonstrated by the Flame attacks, this is equally true for
      native applications.
      - As the mobile web continues to take off, it's not uncommon to see
      study after study looking at mobile permissions or implementation details
      that show mobile, "native" applications are just as susceptible
Yes, this
      is a valid attack class, but it's increasingly becoming no different than
      'native' code.

While I have great respect for the Matasano team, and agree with their
publication as capturing the state of the world at the time it was written,
I do not think it's a statement about what is at all possible. I think our
efforts in this WG are to show that we can, are, and have been addressing
those issues.

The crushing weight of the installed base is a problem that, as a WG, I
don't think we can solve, but that's not to say it's unsolvable. As
browsers such as Chrome and Firefox have shown, it's possible to adopt a
rapid release schedule that reasonably upgrades the vast majority of users.

However, I think it's important to keep the right perspective in these
discussions. My goal at least has been to ensure a robust enough
implementation that applications which were previously native-only can be
reasonably be implemented in the web platform. That said, this API cannot
in and of itself solve the trusted computing problem. This API is agnostic
about its operating environment. It may be executing on vendor hardware
that is restricted to specific origins and with in-built device keys, that
disallows any form of arbitrary web content except that vetted individually
line by line by the vendor. It may be executing on general purpose desktop
machines running popular operating systems, capable of running any number
of applications - and, for better or worse, capable of running any number
of *malware* applications.

That's why I don't think pre-provisioned keys get you anything - smart
card, device bound, or otherwise. Much like non-repudiation, trust requires
an end-to-end system security, and that is not something our API is
providing. To the extent possible, we're defining the interaction between
the user agent and the application - but nothing we've specified prevents
the user agent or operating system from being subverted, and we've yet to
require anything (such as CSP) that prevents subversion of the application.

[1] http://www.w3.org/TR/offline-webapps/
[2] http://dev.w3.org/html5/spec/offline.html
[3] http://www.w3.org/2012/05/sysapps-wg-charter.html