Re: Scope of key discovery draft

On Dec 10, 2012, at 3:58 PM, Ryan Sleevi wrote:

> On Mon, Dec 10, 2012 at 3:50 PM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>> On Dec 10, 2012, at 3:35 PM, Ryan Sleevi wrote:
>> 
>>> On Mon, Dec 10, 2012 at 3:28 PM, Mark Watson <watsonm@netflix.com> wrote:
>>>> 
>>>> On Dec 10, 2012, at 3:23 PM, Acar, Tolga wrote:
>>>> 
>>>>> One aspect: exposure of raw key material in IndexedDB instead of a Key object that may not be extractable.
>>>> 
>>>> A Key object with "extractable=false" can be stored in IndexedDB without exposing the raw key material. What is stored in IndexedDB is effectively a *reference* to the key material, not the raw key material itself.
>>>> 
>>>> Perhaps some clarification of this is required ? Whatever kind of Key object you have, storing and retrieving it to/from IndexedDB should not pose any additional security risks, in terms of exposing the key.
>>>> 
>>>> …Mark
>>>> 
>>> 
>>> Thanks Mark for beating me to this.
>>> 
>>> I'm torn on the clarifying text, because for 'implementors' it should
>>> be 'obvious' (in the same way that Blob/File/ArrayBuffer structured
>>> cloning does not require copying the actual data into IndexedDB), but
>>> for potential users of the API, this may be ambiguous.
>>> 
>>> I'll see about how this can be made clearer, but I'm generally
>>> antagonistic towards over-clarification, since 'guidance' is often
>>> mis-interpreted as normative 'requirements', leading to all sorts of
>>> bad behaviour.
>>> 
>>> For example, a user agent *could* decide to store the cryptographic
>>> material in the same representation of IndexedDB, if it so wanted -
>>> but by virtue of structured clone, it MUST always return a Key object
>>> when that key/value pair is retrieved, and the returned Key must
>>> preserve the same exportability semantics as what was put in. Meaning
>>> there's no way for client JS to get the data 'out', even if it's
>>> "right there"
>> 
>> Where this gets slightly tricky is that implementing "exportable=false" should mean slightly more than just "you can't use the WebCrypto export API to get the raw keying material". It should mean that reasonable care has been taken to make it impossible for the Javascript code to get the raw keying material. Put another way, there's no point in the exportable attribute if it can be trivially defeated with some (pure JS) workaround.
>> 
>> This is the converse of clarifying for users that storing in IndexedDB doesn't change the accessibility of the key material: it needs to be clear to implementers that if they support "exportable=false" they're making some kind of promise about what they do with the key, and their implementation of IndexedDB and structured clone needs to consider this.
>> 
>> [I know that didn't help in terms of finding actual words for the spec … sorry]
> 
> The spec says an implementor is totally within their rights to do that.
> 
> An implementor can (and many will, and that's Just Dandy) do exactly
> that - store the raw key material into IDB, even when
> exportable=false.

Sure, but my point is just that if "exportable = false" is to mean anything it has to mean that the implementor has taken *some* care to make it non-trivial to for scripts to get the key.

For example, if an implementation also provided a method like this:

ArrayBufferView Window.secretGetWebCryptoNonExportableKey( Key theKey )

then I think we would say that the "exportable=false" setting is a little meaningless on that platform.

Now, there is (hopefully) no need to provide any guidance that says implementations should not implement a method like the above one. 

However, leaving gaping security holes in an IndexedDB implementation, such that retrieving keying material for non-exportable keys is trivial, is essentially the same thing as proving the above method. Some guidance on this might be in order: users of the API expect that storing keys in IndexedDB won't make access to non-exportable keying material any easier than it was before. 

> 
> There is no sort of promise being made here. Intentional. By design.

I think a modest form of promise of the above kind is essential for exportable=false to be meaningful.

> There's no way any API can make such a promise, especially not given
> the hostility towards Key Tainting.
> 
> Consider, for example:
> - Timing attacks
> - Chosen Ciphertext attacks
> - Chosen plaintext attacks
> - Padding attacks
> - Algorithm confusion
> 
> These are all part of the broader problem, regardless of whether you
> talk about IndexedDB. They're essential threats that are "not
> addressed" because no API can address them while also maintaining
> utility and while avoiding becoming 400 pages long detailing every
> cryptographic attack and requiring logging of every operation.
> 
> To put it differently, there is no reason to expect that somehow
> setting exportable=false gets you FIPS 140-2 Level 4 assurances
> regarding exportability (which can, if the implementation is faulty,
> be trivially defeated by using a null wrap key. Go figure)
> 
> "exportable=false" means exactly what you say it shouldn't: "You
> cannot use the WebCrypto export API to get the raw key material."
> Naught more.

I do think it should mean a little more than that. Specifically, we can write a requirement that the User Agent MUST NOT expose the raw keying material to scripts.

The MUST NOT means both that you cannot implement Window.secretGetWebCryptoNonExportableKey and that reasonable care should be taken not to create security holes that expose the raw key material (even if it is stored as a serialized raw key in IndexedDB).

…Mark



>

Received on Tuesday, 11 December 2012 00:37:37 UTC