Re: I want to have unsafe key exchange.

On Mon, Jul 16, 2012 at 4:43 PM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
> Given the web assumption of an untrustworthy execution environment, "make the key secure" isn't possible. Any flag that says "make the key secure" is implicitly adding "... if you can and deign to".
>
> Why not go the other direction - say that key storage is up to the environment/browser, unless the app says specifically that it wants an exportable key, in which case the browser must either generate an exportable key or fail. That would also allow for browsers to implement the maximum security possible under the app's constraints.
>
> (I thought I saw someone else also express this same idea recently, but I can't find the email right now.)

>From reading the replies, it seems like most everyone on this thread
is in agreement, but we may be talking past eachother.

In working out the state machine for how key generation works, my thought is:

Handling for generate() method [as part of the KeyGenerator interface]
- If "privateKeyMaterial" is not supplied, then it will be initialized
to the default value of "false"
- If "privateKeyMaterial" is equal to "false", then whether or not the
key material will be accessible is IMPLEMENTATION-DEFINED. Future
calls to ("raw key" method) MAY return the raw keying material, or MAY
return NULL.
- If "privateKeyMaterial" is equal to "true", then the implementation
MUST allow access to the keying material for as long as the key handle
remains available/discoverable by the application. If the
implementation cannot do so, it MUST fail the key generation
operation.

For key discovery:
- If the application provisioned the key via generateKey(), and
specified "true" for "privateMaterialAccess", then the ("raw key"
method) MUST be implemented and MUST return the raw keying material
that was previously generated via generateKey().
- For all other cases, then the ("raw key" method) MAY be implemented.
If the raw keying material is not available, it MUST return null.


I'm 100% in favour of implementation-defined storage. For example, the
browser may decide to store the key in a plaintext file on disk, for a
pure software implementation. It may decide (likely based on some form
of user input) to store the key in protected storage - whether the OS
store or a secure element/TPM.

The only requirement/guarantee is that if an application says it
requires raw key material, then that raw key material will be
accessible to that application for the lifetime of that key, or the
operation should fail.

>
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Monday, July 16, 2012 12:39 PM
> To: Mark Watson
> Cc: GALINDO Virginie; Ryan Sleevi; Vijay Bharadwaj; Wan-Teh Chang; David Dahl; Zooko Wilcox-OHearn; public-webcrypto@w3.org
> Subject: Re: I want to have unsafe key exchange.
>
> On Mon, Jul 16, 2012 at 11:37 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>> On Jul 14, 2012, at 7:13 AM, Eric Rescorla wrote:
>>
>>> On Sat, Jul 14, 2012 at 6:50 AM, GALINDO Virginie
>>> <Virginie.GALINDO@gemalto.com> wrote:
>>>> Vijay, Ryan, and all,
>>>>
>>>>
>>>>
>>>> Just to make sure we are on line on this topic :
>>>>
>>>> About a key to be extractable, Ryan wrote" it is up to the
>>>> implementation and how it handles key", my understanding of our
>>>> conversations was that this 'extractable capability' should be
>>>> defined at key creation. If it is really up to the implementation
>>>> and will vary from one browser to another, then I think we do not
>>>> help the developer to build consistent security : he will not be able to choose if the key could or not be viewed by the JS.
>>>>
>>>> Did I miss something ?
>>>
>>> It's important to remember that WebCrypto is likely to be initially
>>> deployed via a polyfill. I.e., there will be pure JS implementations
>>> which sites import to allow operation with browsers which don't
>>> currently support WebCrypto. Under those circumstances, it is
>>> obviously not possible to build an implementation which secures the key from the JS.
>>>
>>> Such an implementation has two choices:
>>>
>>> 1. Refuse to make keys which are tagged as protected.
>>> 2. Make keys which are tagged as protected but actually aren't
>>> protected.
>>
>> Surely a site which needed 'protected' keys for some function would not use this "import a JS implementation of WebCrypto" approach and would instead tell the user that their browser didn't support the capabilities needed for that site function ?
>
> You're assuming that they aren't just pulling in a library which wraps the crypto functions as jQuery/underscore, etc. do for so many other pieces of web functionality.
>
> -Ekr
>

Received on Tuesday, 17 July 2012 00:21:59 UTC