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

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.