Re: Key export and an opaque KeyFormat

This proposal would at least allow storage of keys in web storage - which is universally supported, unlike IndexedDB. (Please correct me if there is another storage mechanism with universal support).

I don't think there is any privacy issue: if the implementation uses an internal reference, then the internal store must be cleared when the user clears other storage. If it encrypts the key data with a local key, then so long as there is some kind of nonce in the plaintext, guessing a valid opaque blob is as difficult as guessing the internal key. Also, the plaintext could include a sequence number which is incremented each time storage is cleared. Anyway, we would simply state a requirement that keys exported this way should be able to be imported again after storage has been cleared.

...Mark

Sent from my iPhone

On Mar 20, 2013, at 3:55 AM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:


Exactly. And there is no requirement that raw key material be stored in the underlying storage - the only implementation requirement is that, given a store and later load (eg: clone) it yields a Key object that behaves the same.

A conforming browser using CNG could thus implement this by storing the opaque key. It could also implement this by storing a reference to the KSP and key name. Or it could store the raw material. From the web page side, all three possible implementations have the same behaviour, and are thus conforming.

On Mar 20, 2013 1:04 AM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
Ah, I think I see now. I seem to have missed a lot of the structured clone conversation earlier.

So with the structured cloning, something like transaction.objectStore(“storename”).put(key, “indexedDBkeyname”) ought to work?

From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>]
Sent: Wednesday, March 20, 2013 12:04 AM
To: Ryan Sleevi
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: RE: Key export and an opaque KeyFormat

Perhaps I am not understanding the draft then. How is a script supposed to save a key (created by generateKey) for later use (i.e. across a browser restart for example)? Is the idea that generateKey also creates a key in some underlying persisted store?

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Tuesday, March 19, 2013 11:49 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: Key export and an opaque KeyFormat


Vijay,

Keys support structured clone. Just use the existing web storage mechanisms. Until the user clears storage, it works.

This avoids any privacy concerns with accidental key resurrection through throwing opaque blobs at the user until one sticks (thus indicating they previously generated said blob, thus acting as a super cookie).

No exporting is required for object cloning. This was a key point that has been repeatedly explained and a well understood concept from the Storage APIs and from Workers, which both use Clonability.
On Mar 19, 2013 11:39 PM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
It seems to me that the current API has little support for an origin which wants to generate a key and then use it for multiple sessions. The only way I can see in the API of doing this is to use exportKey and store the key in the clear. This is not an appealing prospect. It also means that if an origin wants to persist a key in this way for its own later use then it has no choice but to make it exportable.

So I would like to propose adding a value “opaqueLocal” to enum KeyFormat. The behavior of this format would be as follows: the result of calling exportKey with this KeyFormat would be a durable key reference that would be bound to the particular machine (and possibly UA). The contents of this reference are opaque to the caller – it may be just a key name that refers to a local key store, or it could be the entire key object wrapped with a key held by the UA. Calling importKey on this result will work on the same machine and UA, but fail on all other machines. Also, the algorithm, extractable and keyUsages parameters will be ignored and the values from the original key object will be used.

The concept is similar to BCRYPT_OPAQUE_KEY_BLOB in CNG: http://msdn.microsoft.com/library/windows/desktop/aa375434.aspx

Thoughts?