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

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


On Sep 18, 2012, at 5:10 AM, Harry Halpin wrote:

On 09/18/2012 11:20 AM, GALINDO Virginie wrote:
Dear all,

Highlighting a link that Harry shared with us during the conf call yesterday. I think we should read that and try to see where we have been ‘better than expected’ for providing security for webapp. This would definitely help to better describe our value proposition, I think – and clearly know our limits ;-)
http://www.matasano.com/articles/javascript-cryptography/

I think requiring CSP plus having the API work natively on the client addresses rather than be downloaded his issues re hijacking and malleability of the Javascript runtime, although the latter point requires serious deliberation on our part. In particular, we will clearly address "the lack of systems programming primitives needed to implement crypto" and issues he brings up like "random number generation." Also, he assumes TLS is working just fine and should just be used rather than any JS crypto, which it may be if you are using pinning+cert transparency, but that is not always the case - and many of the things that we need this API for, like signatures, cannot be easily done within WebApps as TLS does not let these functions be accessed in an API.

It seems to me the rest of the arguments here can be repurposed against using cryptography any programming language, not just a Javascript run-time environment. Which basically would mean cryptography is in general doomed because its hard, yet given its usage and utility, this is self-evidently not the case. I'd like to hear the opinion of others

  cheers,
      harry



Regards,
Virginie