RE: Scope of key discovery draft

> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Monday, December 10, 2012 4:18 PM
> To: Acar, Tolga
> Cc: Mark Watson; public-webcrypto@w3.org Group
> Subject: 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.
OK, thanks. You and I seem to be on the same page here.

> >
> >>
> >> 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.
Agreed. This is another way of saying what I wrote above, just reversed. 

> 
> The assurances cannot come from the spec itself.
Surely not.

> 
> 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.
This is not a complaint; but a confirmation request that an implementation choosing not to expose any of the plaintext keys can still be compliant with this API; and it appears that it can be. As for your CAPI/CNG reference, having worked on it in the past, one can also register a provider (e.g., HSM or TPM provider) under CNG that does not expose plaintext key values. My confirmation request does not only consider traditional software-only implementations.

Received on Tuesday, 11 December 2012 00:32:21 UTC