Re: Extractable Keys

Just cycling through older feedback


On Tue, Feb 4, 2014 at 5:30 PM, Matthew Tamayo <matthew@kryptnostic.com>
wrote:

> So this is just my thought process, so I could be completely off base.
>
> 1) This scenario is not specifically called out in the use cases.  For
> example, adding a clarifying phrase to section 2.3 such as, "The Web
> Cryptography API allows an application to have a user use a private or
> secret key whose raw key material is inaccessible to the web application,
> to either derive encryption keys from the selected key or to directly
> encrypt documents using this key, and then to upload the
> transformed/encrypted data to the service provider using existing APIs."
>

This should be clarified in new security considerations


>
> 2) In sections 4.2 and 5.1, there are mentions of key handles but I don't
> see the notion of key handles not allowing you access to the underlying
> keys elsewhere in the document.  The first section where protection against
> future access by web applications is mentioned is 5.2.  It also use
> verbiage that indicates that in certain cases it might be accessible.  The
> fact the both possibilities seem to exist might lead developers reading the
> specification to expect when they can or can't retrieve key material to be
> called out explicitly.
>

https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#concepts-underlying-implementation
should have clarified this


>
> 3) There is only one mention of opaque reference (section 11). The other
> locations where opaqueness is mentioned it is referring to the actual
> keying material (11.2 , issue 36). It might be a poor assumption on my
> part, but in my past experience when people refer to opaque buffers or
> bytes, it has meant binary blobs you have access to ship around but should
> make no assumptions about what you are shipping about. This also led to my
> original interpretation of opaque reference as a reference you can pass
> around, but who format can be anything that the browser wants.
>
>
Clarified by
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#concepts-underlying-implementation
(and related)


> 4) The exportKey method in section 14.2.9 has no text.
>
> 5) Extractable defined in 11.2 is the most precise specification of
> behavior, which is what led to my question as a result of #4 and the change
> in how a property it is talked about.
>
> 6) Exportable and accessible, have slightly different meanings for the
> most part this is a minor detail except in the face a user might want to
> allow exporting of key that encrypted with the public key of a device they
> recently established a trust relationship with. I would say the keys are
> exportable, but not accessible.
>

The spec doesn't make a distinction between "exportable while wrapped" vs
"exportable unwrapped". This was a topic of great length when discussing
how to handle extractability, as well as key formats.

As it stands, we took the more conservative approach; in part, because of
the intentional absent of key storage definitions.


>
> Thank you for taking the time to read my feedback and answer my question!
>
> Matthew
>
> On Tue, Feb 4, 2014 at 7:42 AM, Richard Barnes <rlb@ipv.sx> wrote:
>
>> Hey Matthew,
>>
>> You're exactly right.  The idea of the extractable attribute is that the
>> key is safe from bad scripts after it's generated.
>>
>> If you think the spec is unclear, it would be really helpful if you could
>> suggest some ways to clarify.
>>
>> Thanks,
>> --Richard
>>
>>
>>
>> On Monday, February 3, 2014, Matthew Tamayo <matthew@kryptnostic.com>
>> wrote:
>>
>>> A fellow developer point me at the Web Crypto API draft, when I was
>>> looking into whether it would be possible to have the browser execute some
>>> key generation process that would allow use of a secret key for encryption
>>> / decryption, but would not allow that key to be extracted and sent
>>> elsewhere with a Javascript call. I was wondering if the "Key.extractable"
>>> property in section 11 was intended for that purpose.
>>>
>>> The specific scenario I am interested in is if a bad actor is able to
>>> compromise a website to deliver bad JS that attempts to extract they keys
>>> and send them to their own server, whenever a user visits what is otherwise
>>> a functional and previously safe site.
>>>
>>> It would be very useful for a site to be able to generate a key, which
>>> is could use via a handle like interface, but the site is unable to read
>>> the contents of the keys.
>>>
>>> Matthew
>>>
>>
>