[whatwg] Proposal for secure key-value data stores

[Evan Ireland]

One of our key concerns is with Web SQL Database API (which we prefer) or
Indexed Database API.

I might wish to build an offline web application which will refuse to
operate if the browser cannot guarantee that the database is encrypted. Now
full-disk encryption would be fine (if the O/S has a power-on password), but
how can my web application author detect (using a JS API) if any data stored
in a browser's database is in fact encrypted (or not)?

Such uncertainty might force us (as a vendor) to have to develop
platform/browser-specific plugins to providew an alternative implemantation
of the database API so we can be confident that database storage is secure.

> -----Original Message-----
> From: Ian Hickson [mailto:ian at hixie.ch] 
> Sent: Tuesday, 17 August 2010 10:58 a.m.
> To: whatwg at lists.whatwg.org
> Subject: [whatwg] Proposal for secure key-value data stores
> 
> On Tue, 30 Mar 2010, Nicholas Zakas wrote:
> > 
> > In attempting to use localStorage at work, we ran into some major 
> > security issues. Primary among those are the guidelines we 
> have in place 
> > regarding personalized user data. The short story is that 
> personalized 
> > data cannot be stored on disk unless it's encrypted using a 
> > company-validated encryption mechanism and key. So if we 
> actually wanted 
> > to use localStorage, we'd be forced to encrypt each value as it was 
> > being written and then decrypt each value being read. 
> Because of this 
> > tediousness, we opted not to use it.
> 
> Doing that wouldn't actually help, either, since anyone 
> attacking the user 
> could simply intercept the key and then decrypt it all 
> offline. (In this 
> scenario, I'm assuming the attack being defeated is that of 
> an attacker 
> obtaining the data, and I'm assuming that the attacker has 
> physical access 
> to the computer, since otherwise the Web's security model would be 
> sufficient to block the attack, and that the computer is 
> logged in, since 
> otherwise whole-disk encryption would be sufficient to block 
> this attack.)
> 
> 
> > Another major issue also relates to the persistence of the data in 
> > localStorage. Whereas cookies allow you to specify a time 
> at which the 
> > data will be removed, localStorage is there more or less forever.
> 
> Right, it's there for as long as the data that would be saved 
> by the user 
> if the user viewed your page and chose "File > Save As" -- 
> that is, until 
> the user deletes it. (Or until he visits your page again and 
> your page 
> deletes it.)
> 
> 
> > It seems like any company that takes the security of its 
> data seriously 
> > would run into the same issues, and rather than forcing 
> every company to 
> > implement their own version of the same approach, a common native 
> > approach would be incredibly useful.
> 
> Why isn't whole-disk encryption sufficient? It seems like if 
> the user is 
> concerned about his disk being stolen, he'd be concerned 
> about all data on 
> the disk, including his HTTP cache, his cookies, his saved 
> usernames and 
> passwords, etc, not just the data in the Web page's localStorage area.
> 
> 
> On Tue, 30 Mar 2010, Dirk Pranke wrote:
> >
> > Nicholas is almost certainly discussing the case where the service 
> > provider requires any data stored on a customer's computer to be 
> > encrypted, not the provider's own computers. (e.g., this could be a 
> > Yahoo! policy that data stored on Yahoo! users' computers must be 
> > encrypted).
> > 
> > Hence they cannot enforce anything like "use FileVault".
> 
> If you can't enforce whole disk encryption, but you are 
> concerned that an 
> attacker could have access to your machine, it seems that there is no 
> solution, since an attacker could just install a rootkit and 
> then carry 
> out arbitrary attacks remotely, including simply replacing 
> the browser 
> with one that intercepts all the user's data as it is written.
> 
> 
> On Tue, 30 Mar 2010, Dirk Pranke wrote:
> > 
> > Perhaps we should instead focus on a set of JS Crypto APIs, 
> since that
> > is largely orthogonal to the storage APIs?
> 
> That would make more sense, I think. It would be useful in 
> other scenarios 
> too (such as replacing <keygen>). I would encourage people 
> interested in 
> such an approach to get vendors together and write a spec.
> 
> -- 
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   
> _\  ;`._ ,.
> Things that are impossible just take longer.   
> `._.-(,_..'--(,_..'`-.;.'
>