Re: Use Cases | ACTION-13 Revisited

On Thu, Aug 16, 2012 at 3:55 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> While working through the use cases (per [ACTION-13]) with Wan-Teh (wtc), we
> came up with the following:
>
> 1. The use cases rsleevi added to the draft [spec] are pretty solid;  they
> are only missing a "local storage" scenario, first mentioned on the Wiki
> [cf. local].
>
> 2. I think our use cases should account for cross-origin keys.  This should
> make its way into our security considerations section as well, but by
> mentioning them in the use cases, we mention an important scenario that we
> are building this API for.  Either wtc or I will update the spec to account
> for this (probably in Use Case 2.1).
>
> "Strawperson text" can be simple and terse.  For instance, from Use Case
> 2.1:
>
> "A web application may wish to extend or replace existing username/password
> based authentication schemes with authentication methods based on proving
> that the user has access to some secret keying material, possibly available
> across multiple origins."
>
> For ordered grouping of use cases, we may wish to move Cloud Storage next to
> Protected Document Exchange, simply because of how similar these use cases
> are (Cloud Storage may be seen as a special case of document storage,
> covered in the other scenario).
>
> 3. Both of us wrestled with the fact that currently, the number of ways to
> protect decrypted content from a web application are limited.  This isn't
> quite a fully-fledged use case, but is a caveat first raised by Emily Stark
> when discussing use cases [Stark Caveat].  One way to do this might be to
> use the "File | Save As" or "File Upload (file picker)" UI provenances in
> web browsers today, obliging users to treat decrypted content as files, thus
> allowing for them to at least be treated differently as readable variables
> in web application space.  But this is clearly overkill for OTR messaging, a
> use case covered in the specification (and in general, seems problematic).
>
> Keeping decrypted content from web applications, and ONLY making them
> available to the user, may be something that we don't account for, leaving
> web applications vulnerable to getting at decrypted content via fairly well
> understood ways (negligence, getting pwnt, etc.).  In order to prevent this
> kind of access, we'd need to make some changes that include both UI (which
> we've discussed as important, but not a WG activity) as well as creating a
> class of content that's not generally readable by web content.
>
> We may wish to just state this as a caveat for developers to consider.
>
> -- A*
> [spec] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#use-cases
> [cf. local]
> http://www.w3.org/community/webcryptoapi/wiki/Use_Cases#Storing_local_storage
> [Stark Caveat]
> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0065.html
> [ACTION-13] https://www.w3.org/2012/webcrypto/track/actions/13

Arun,

I'm a little concerned about the "local storage" case, and wondering
whether it's something that would necessarily be in scope for this
group.

Consider the example of IndexedDB, which uses "Keys" (IDB keys -
http://www.w3.org/TR/IndexedDB/#key-construct ) and returns "Values" (
http://www.w3.org/TR/IndexedDB/#value-construct ), and can
alternatively be accessed via indices (
http://www.w3.org/TR/IndexedDB/#index-concept ).

A naieve assumption would be that this API would only protect the
Values - not the keys, nor the indices. However, as practically
deployed today, that wouldn't offer much protection, since both Keys
and Indices often reveal quite a bit of information.

Further, by ciphering contents, it's a tradeoff between efficiency and
privacy. Perfect privacy (storing no relationships about keys/indices,
everything randomly distributed) is the worst efficiency, while
perfect efficiency (which is what is afforded by today's IndexedDB)
has no privacy/cryptography.

A refinement might be to have the IndexedDB actually take a Key
(Crypto API key), that it can use to protect however the IndexedDB is
stored - keys, indices, everything. Call it an "EncryptedIndexedDB".
This is better, in that it allows the user agent to decrypt on the fly
(see caveat), and allows applications to use existing indices/keys.
The caveat, however, is that encryption requires defining an
encryption algorithm, and the choice of encryption algorithm directly
affects the efficiency of the API. For example, under today's
IndexedDB, a user agent can load data on the fly (eg: from disk), but
under EncryptedIndexedDB with say, a block cipher alg like AES, it
might have to read the entire DB into memory, then decrypt, in order
to be able to offer this functionality.

Even more fundamentally though, is the question about what attack this
is trying to defend against. The arguments I've heard for encrypted
local storage seem to be about a remote server, serving a web
application, distrusting the client platform. If that's the case, it
doesn't seem like any level of cryptography will save them. As I noted
in the existing security considerations, it SHOULD be perfectly valid
for a user agent to store a key in plaintext on disk, so what actual
protections are afforded by this?

If something like EncryptedIndexedDB is what is meant here, then this
seems like something that would likely live in the Web Apps WG (since
it's about extending IndexedDB).

I just want to make sure that we're carefully considering the use case
and the security implications before committing to them, as well as to
figure out what parts of the spec may need to change in order to
meaningfully implement them.

Cheers

Received on Thursday, 16 August 2012 23:17:03 UTC