W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

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

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 18 Sep 2012 10:51:39 -0700
Message-ID: <CACvaWvZgS1BOG2G7oE-KBG_j9CHzCsw_Qqh+wCyik2SbYmrt_w@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Harry Halpin <hhalpin@w3.org>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Wendy Seltzer <wseltzer@w3.org>
On Tue, Sep 18, 2012 at 10:42 AM, Mark Watson <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> 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.
Received on Tuesday, 18 September 2012 17:52:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:13 UTC