Re: [WebCrypto.Next] "Plan B" - Chrome Native Messaging

On 02/05/2015 01:30 AM, Ryan Sleevi wrote:
> On Wed, Feb 4, 2015 at 4:11 PM, David Leon Gil <coruus@gmail.com> wrote:
>> So, a nit I have with WebCrypto/whatever at the moment, related to this issue.
>>
>> If I want to make a webapp that stores unextractable keys, I can store
>> them in IndexedDB. A browser can implement IndexedDB by providing a
>> store that is, e.g., a Sqlite3 database on disk. With all of these
>> "unextractable" keys stored in plaintext.
> 
> The spec is explicitly clear that this is a valid implementation
> strategy, although not required of implementors.
> 
>> Every browser, however, does have an internal keystore
> 
> False. No specification requires this of Web Browsers. What some
> browsers do (and again, not all of them do this) is not the same as
> all browsers.
> 
>> (e.g., for
>> passwords). And (some of them) use the best available protection their
>> platform provides to protect entries in it.
> 
> And that protection varies by platform to considerable extent, thus
> providing zero effective guarantees to a Web developer, short of
> coding platform-specific logic in the Web - which is, of course,
> exactly what the Web shouldn't do - or by requiring all platforms
> accessing the Web have some degree of restricted control capabilities
> that quickly borderlines on Trusted Computing.

While Ryan is right as regards the current lack of any kind of
consistent security properties of browser storage of keys, that seems
like a suitable topic for future exploration for possible
standardization. It's definitely a bug, not a feature, in my book
insofar as storing user's private material in plaintext on the client
side (and under server) control does likely violate the assumptions most
people I know have about cryptographic protocols.

> 
>> I'd be happy if I could just store one entry in that keystore: A KEK
>> to wrap all of the keys when they're at rest.
>>
>> But right now, as far as I know, I can't.
>>
>> - dlg
> 
> Correct. That is by design.
> 

Received on Thursday, 5 February 2015 11:39:34 UTC