Re: Key wrap/unwrap/import/export open issue

On Jul 8, 2013, at 2:40 PM, Harry Halpin <hhalpin@w3.org> wrote:

> On 07/08/2013 08:18 PM, Ryan Sleevi wrote:
>> On Mon, Jul 8, 2013 at 11:16 AM, Harry Halpin <hhalpin@w3.org>
>>  wrote:
>> 
>>> On 07/08/2013 06:31 PM, GALINDO Virginie wrote:
>>> 
>>> Thanks Mark for this proposal, which makes your request crystal clear.
>>> 
>>> We will allocate some time during the next call in 2 weeks, to collect
>>> feedbacks from editors and have your proposal integrated in the next public
>>> working draft, as it was supposed to.
>>> 
>>> 
>>> I missed the last call and it appears there were lots of discussion over the
>>> security boundary actually being offered by
>>> 
>>> I can imagine a case where no real security boundary that JS code makes
>>> sense (i.e. private key material stored in say, localStorage, and can be
>>> easily exported in some fashion), but if a real security boundary is offered
>>> to non-extractable keys, then it seems doing wrap/unwrap in JS doesn't seem
>>> to make sense.
>>> 
>>> This seems like, as many people will try to store private key material as
>>> non-extractable, something we should clarify with an informative note
>>> somewhere in the spec.
>>> 
>>> Are the various browser vendors planning on doing anything around security
>>> boundary for keys of structured clone (while maintaining
>>> persistence/lifespan/etc.) at all to enforce non-extractable properties for
>>> keys?
>>> 
>> I'm sorry Harry, I do not understand your question.
>> 
> Will the browser vendors, in their initial implementation, store non-extractable keys in LocalStorage or IndexedDB? 
> 
> Do they plan to offer some better "security boundary" around extractability? 
> 
> I am assuming a "trust the JS" approach, but I'd like to clarify what non-extractable means in terms of current browser storage. I.e. obviously it means we shouldn't let exportKey() work, but also I imagine that it's intuitive that a developer would expect there should be no other way via localStorage/IndexedDB to get at the underlying key material. 
> 
> Otherwise, we need to clarify that setting extractable=false may have not offer what we appear it to be offered in this note. 
> 
> Implementation Note: When performing the structured clone algorithm for a Key object, it is important that the underlying cryptographic key material not be exposed to a JavaScript implementation. Such a situation may arise if an implementation fails to implement the structured clone algorithm correctly, such as by allowing a Key object to be serialized as part of a structured clone implementation, but then deserializing it as a DOMString, rather than as a Key object. 
> 
> 
> If developers can't tell what "extractable" means, then we should warn them :)
> 
>    cheers,
>    harry
> 


Harry,

In case it helps, here's how PolyCrypt implements key extractability:

-- The API implementation generates a key encryption key (KEK) for itself
-- When a key is generated/imported, the resulting Key object contains the octets of the key, encrypted under the KEK (as a "key" attribute)
-- When something is to be done with the key, the API implementation decrypts the key using the KEK

For example, on <http://demo.polycrypt.net/hello-enc.html>
> JSON.stringify(KEY)
"{"type":"secret","key":"265ba4cd37fb94fbb97f9293009ff6b56caeff562e1b8be2","algorithm":null,"extractable":false,"keyUsage":[]}"

That means that Key objects can be stored in LocalStorage or IndexedDB without exposing the actual key material, in the following sense: If an attacker wants to export the key, it has to get both the encrypted key (in the application origin) and the KEK (in the PolyCrypt origin).  In a browser implementation, you could do the same thing using a KEK stored inside the browser (invisible to JS) or in a secure element.

--Richard

Received on Monday, 8 July 2013 19:03:59 UTC