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

On 09/18/2012 07:51 PM, Ryan Sleevi wrote:
>
>
> On Tue, Sep 18, 2012 at 10:42 AM, Mark Watson <watsonm@netflix.com 
> <mailto:watsonm@netflix.com>> wrote:
>
>
>     On Sep 18, 2012, at 10:29 AM, Ryan Sleevi wrote:
>
>>
>>     On Tue, Sep 18, 2012 at 8:53 AM, Mark Watson <watsonm@netflix.com
>>     <mailto: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.
>
>     That's a bold statement which requires only an existence proof to
>     refute.
>
>     If at the server I receive a message signed by a pre-provisioned
>     key that I know was placed into a specific hardware module. I
>     know, up to the security of that hardware module, that the message
>     came from code (malware or otherwise) that is able to communicate
>     with that hardware.
>
>     This is a security property. And it is useful.
>
>     …Mark
>
>
> In the context of the referred to document, which specifically was 
> discussing the malleability of the content runtime and client script, 
> my position remains the same. A smart card, secure element, or 
> otherwise pre-provisioned key is not a defense against or an added 
> security property for such a set of attacks.
>
> Further, this is no different than native code, which equally has the 
> "malware or otherwise" problem.
>
> Apologies for seeming that I was making an overbroad statement here - 
> certainly, I agree that hardware modules can provide some set of 
> additional properties. But in the context of malware and malleability, 
> I do not believe they're part of the equation.

There are obviously different roots of trust. In fact, what I'm hearing 
a lot now is that due to the "vetting" of the Apple Store etc., many 
folks are rooting trust in native apps. However, I would agree with Ryan 
that with CSP and the Crypto API we can mitigate the content runtime and 
the client script malleability issue. So, on that level I'm not sure if 
there's a big difference between a Crypto API for Javascript and a 
Crypto API for Java or any other programming language, as *every client 
app* has the ability to be compromised or insecure at the level of code 
and upgrade paths. So, the deliverable is not doomed, any more so than 
any other "app", non-Web or Web.

And I would not personally but my trust in the CA system until something 
like Key Transparency is widely deployed, so again, just use TLS will 
not work without pinning in the general case and would not work in 
general for many of our use-cases regardless.

And yes, I'd agree that pre-provisioned keys, smart-cards, etc. can add 
some element of trust *if* that's where you want to root trust. Rooting 
trust in the user is actually I think quite dangerous, as every study I 
have ever looked at shows that users often do not have the right 
intutitions regarding security aspects of the Web like TLS and reading 
URIs, much less key management.  I think for most apps we should aim for 
*key invisibility*, making the use of keys as invisible to the user as 
possible. Of course, we need to keep the ability for an educated user to 
check to see what's going on and have ideally the WebApp or browser 
appear to do "the right thing." Where to draw that line is tricky, but 
it seems the WG is more willing to have apps draw that line.

    cheers,
      harry