Re: Scope of key discovery draft

On Mon, Dec 10, 2012 at 4:11 PM, Acar, Tolga <tolga.acar@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Monday, December 10, 2012 3:59 PM
>> To: Mark Watson
>> Cc: Acar, Tolga; public-webcrypto@w3.org Group
>> Subject: Re: Scope of key discovery draft
>>
>> 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.
>>
>> There is no sort of promise being made here. Intentional. By design.
>> 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
> An API making a promise that extractable=false keys are not available in plaintext does not follow the existence of timings attacks, CPA, CCA, or IND properties of a particular cipher and its implementation.
> To make sure that we are on the same page here: An implementation, such as your example above, may choose to expose the key values in cleartext and still be compliant with the API, and much as another implementation not choosing to store its keys in cleartext is compliant.

Expose to whom though?

Expose to JS? No, it may not.
Expose to the "host implementation", for whatever value of "host
implementation" there may exist? It's up to the UA!

"Extractable" only gives you assurances between the UA and the JS. It
does not give you any assurances about the UA and below, and that's by
design. You can't spec that.

>
>>
>> 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)
> Fair enough.
> There may not be a reason to expect that if an implementation chooses not to pursue a particular crypto module validation program. Nonetheless, this is not a reason for a different crypto implementation to surrender any chance of having a certified implementation.
>
> This standard, as it does not put any restriction on storage of cleartext key values, should not require the availability of plaintext keys, either.

I do not follow this argument.

There is nothing in the spec that prevents a UA from wholly holding on
to its key material in a FIPS 140-2 Level 4 cryptomodule, never
revealing it. Such a UA can fully implement the spec. Just as a UA
that wholly implements the crypto in a naieve software implementation
in the browser can fully implement the spec.

The assurances cannot come from the spec itself.

Mark's/Netflix's way of dealing with this is to use a pre-provisioned
key to assert that the Keys being handled can *only* come from a
particular implementation, and that particular implementation always
behaves in a particular way (protecting the keys from both JS and
from, presumably, motivated attackers with physical access through the
use of a TPM). That's certainly one way to address the desire for
assurance.

What is not clear is where your concern/complaint/counter-proposal is.
This is behaving exactly like 'every other' cryptographic API.
Consider, for example, CryptoAPI, which even though secrets are stored
in the LSA/LocalService process, a user with privileged local access
can always read that memory and extract the secrets. Physical access
always means "game over" for software solutions.

Received on Tuesday, 11 December 2012 00:23:49 UTC