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

On Jul 22, 2013 7:36 AM, "Mark Watson" <watsonm@netflix.com> wrote:
>
>
>
> Sent from my iPhone
>
> On Jul 22, 2013, at 2:42 PM, GALINDO Virginie <
Virginie.GALINDO@gemalto.com> wrote:
>
>> Hi all,
>>
>>
>>
>> Let me share with you my understanding of the situation about the
non-extractability attribute consistency in case of
wrap/unwrap/import/export :
>>
>> -          We have a request to maintain non-extractability consistency
over the API, including in the wrap/unwrap/import/export, with a clear
balance on not having the javascript seeing the key material
>>
>> -          We have a possible technical solution which addresses the JWK
case http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Notes_July
>>
>> -          We have in our scope other formats (aka raw and pkcs8/spki
format) which may require a global mechanism – several principles discussed
in the thread below but no technical description at the moment
>>
>> -          We had a request from Microsoft and Netflix to progress on
that matter as soon as possible (see previous minutes meeting)
>>
>> -          We do not have any description of the import/export methods
at the moment in our specification
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#SubtleCrypto-method-importKey
>>
>>
>>
>> As a WG we need to decide next path to progress. I see several options :
>>
>> -          Option 1 : integrate something that we have on the table now
(JWK only solution), and build a solution for the other formats based on
contributions of participants
>
>
> One thing to consider is that the requirement for maintaining
non-extractability is probably relevant only for new applications, since
the extractability concept itself - as it appears in WebCrypto - is new.
>
> As such, if maintaining extractability is possible only with JWK then I
don't see this as a big restriction since applications which need that can
be designed to use JWK.

Mark,

This is not at all accurate. Every existing cryptographic API has this
concept.

This is extremely important to support the members and use cases that may
make use of named, origin specific pre-provisioned keys. I do not see it at
all appropriate to suggest these other formats (which are broadly supported
and actually mature, secure standards) are somehow second class.

Further, Netflix's concerns have so far been expressed in terms of named,
pre-provisioned origin specific keys, so it seems like some awareness of
'existing' keys and apps are needed.

>
>>
>> -          Option 2 : decide we want to go for a broader scope
addressing all our formats in a single solution
>
>
> The two are not mutually exclusive. We can require the WebCrypto
application to respect JWK attributes *and* work on
extractability-maintaining wrap/unwrap for other formats.

Mark,

Is your view that the counter proposal for wrap/unwrap (eg: the editors
draft) would be sufficient if JWK attributes were respected?

That is, unwrapKey with raw to get the CEK, which would be non-extractable
via [named pre-provisioned internal attributes, explicit key attributes
from generation ala CKA_UNWRAP_TEMPLATE, viral propagation of
non-extractability]. You would then unwrap the JWK, whose attributes say
non-extractable.

This avoids needing to handle JWE in an implementation, only JWK, as
already required by importKey.

Is that sufficient for your uses? Or do you still feel its a MUST to
support the full JWE profile to meet your needs?

>
> ...Mark
>>
>>
>>
>> I’d be interested to have the views from WG participants on their
preferred choice, or any other option you would like to submit to the WG.
>>
>> Thanks for helping the discussion to progress.
>>
>>
>>
>> Regards,
>>
>> Virginie
>>
>> chair of web crypto wg
>>
>>
>>
>>
>>
>>
>>
>> From: Mark Watson [mailto:watsonm@netflix.com]
>> Sent: vendredi 19 juillet 2013 04:30
>> To: Ryan Sleevi
>> Cc: Harry Halpin; GALINDO Virginie; public-webcrypto@w3.org
>> Subject: Re: Key wrap/unwrap/import/export open issue
>>
>>
>>
>>
>>
>> On Thu, Jul 18, 2013 at 7:09 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>> On Mon, Jul 8, 2013 at 5:12 PM, Mark Watson <watsonm@netflix.com> wrote:
>> > Returning to the subject of the original post, and to start off the
>> > discussion.
>> >
>> > Ryan has mentioned two other possibilities for solving this problem,
so I'd
>> > like to take a moment to describe my understanding of those.
>> >
>> > (1) Implicit unwrap semantics in pre-provisioned keys
>> >
>> > A pre-provisioned key with usage unwrap could be imbued with behaviors
that
>> > dictate the extractable and usage attributes of keys that it unwraps
or even
>> > that imbue the unwrapped keys with other such properties. The former
would
>> > be sufficient for "single step" key wrapping, where the final key to
be used
>> > for encryption, decryption, signature or signature verification is
wrapped
>> > directly with the pre-provisioned key. The special property of the
>> > pre-provisioned key ensures that the final key has extractable = false.
>> >
>> > If you want to have two steps, for example the key you are
transferring is
>> > encrypted using a temporary Content Encryption Key (as in JWE) and
then this
>> > CEK is wrapped using the pre-provisioned key, then you not only need
the
>> > pre-provisioned key to force extractable = false and usage = unwrap on
the
>> > CEK, but it must also transfer a special property to the CEK, so that
when
>> > this in turn is used for unwrapping the resultant key always has
extractable
>> > = false.
>>
>> Correct. The "Named Pre-provisioned keys" is already imbued with
>> special properties by definition, so this is consistent.
>>
>> JWK is not unique in this 'two step' form - consider multi-party
>> RSA-KEM - you have the RSA key, the derived per-party KEK, and the
>> shared, protected key.
>>
>>
>> >
>> > (2) Explicit attributes on wrapping keys
>> >
>> > A key with usage "unwrap" also has properties which dictate the
attributes
>> > of keys that it unwraps. Let's call these properties
"unwrap-extractable"
>> > and "unwrap-usages". Whenever a key, W, is used to perform an unwrap
>> > operation, the unwrapped key, K, gets it's attributes set as follows:
>> >
>> > K.extractable = W.unwrap-extractable
>> > K.usages = W.unwrap-usages
>> >
>> > Again, this is sufficient for single-step unwrapping. When the
wrapping key
>> > W is generated, the unwrap-extractable and unwrap-usages properties
are set
>> > to 'false' and the intended usages of the expected wrapped key,
>> > respectively, When it comes to unwrapping the unwrapped key, K, gets
the
>> > appropriate properties.
>>
>> Correct.
>>
>> This matches PKCS#11's CKA_WRAP_TEMPLATE and CKA_UNWRAP_TEMPLATE
>> properties, for which the smart card and secure element industry have
>> long since embraced as sufficient for a variety of high-security needs
>> (eg: eID cards, as a number of members have pointed out)
>>
>>
>> >
>> > However, if the intended usage of the key K is also for unwrapping (as
in
>> > the two-step key wrapping described above), we need a way to set
>> > K.unwrap-extractable and K.unwrap-usages.
>> >
>> > Theoretically, we could go down the path of having unwrap-extractable
and
>> > unwrap-usages each be an array, popping the first value on each unwrap
>> > operation, i.e.
>> >
>> > K.extractable = W.unwrap-extractable[ 0 ]
>> > K.usages = W.unwrap-usages[ 0 ]
>> > K.unwrap-extractable = W.unwrap-extractable[ 1 : ]
>> > K.unwrap-usages = W.unwrap-usages[ 1 : ]
>> >
>> > (using python-like slice notation)
>> >
>> > It may not be necessary to explicitly expose these attributes on the
Key
>> > object: it may be sufficient to have them settable at key creation
time.
>> >
>> > The other option is to have the extractable and usage attributes
carried
>> > securely with the wrapped key, as I have proposed.
>>
>> Note: This solution ONLY works with JWE-protected-JWK keys - it does
>> not and cannot work with 'raw' or 'pkcs8'/spki. The smart card / HSM /
>> SE industry certainly seems to recognize that mixing/matching as you
>> propose only really works in an implementation-specific manner - see
>> the CKM_SEAL_KEY proposal in the OASIS TC to see how the very nature
>> of 'opaque' key blobs is left up to implementations because of this.
>>
>> You missed the third option though - which is that the (JavaScript)
>> caller specifies the policy.
>>
>>
>>
>> As you explain below, that's not an option that maintains the
extractability functionality. In this mail, I was exploring options which
do that.
>>
>>
>>>
>>>
>>> If I can sum up the discussion so far, the two objections against this
>>> last point (eg: what is currently specified) are:
>>> 1) It allows end-users to manipulate variables (eg: in the Javascript
>>> console) to circumvent this
>>> 2) In the event of an XSS, an attacker can unwrap a key and set
>>> extractable to false.
>>>   2.1) The first attack requires the attacker has previously observed
>>> a wrapped key in transit (eg: MITM) before an XSS, then later XSSes
>>> and replays the original key with 'extractable' as true.
>>>   2.2) The second attack requires the attacker have XSSed the site,
>>> the server send a wrapped key, and the XSS change 'extractable' to
>>> true.
>>>
>>> I see #1 as an explicit non-goal for a general web spec - it's a
>>> feature, not a bug.
>>
>>
>>
>> I don't see it as consistent with the existing extractable attribute
though. We should be consistent. Following your approach, we should remove
the extractable attribute (not that I am proposing this).
>>
>>
>>>
>>> #2.1 can (and should) be mitigated via HTTPS and related.
>>> #2.2 can (and should) be mitigated via CSP and related.
>>
>>
>>
>> There are many ways in which the Javascript running on the users machine
may not be the Javascript that either the user or the service provider
expects. The extractability attribute provides some protection against such
scripts obtaining the raw keying material once it has been installed,
provided the browser itself is not compromised. We're not in a position to
do security engineering for every possible application here, we're
providing tools and extractability is a useful one.
>>
>>
>>
>> Given the above, it's completely reasonable to want to maintain this
property with wrapped keys.
>>
>>
>>>
>>>
>>> Finally, the Structured Clonability of Key objects permits other
>>> creative uses that have strong parallels to existing software such as
>>> middleware, for example, by having a 'trusted' origin perform the
>>> unwrapping, and then postMessaging() to the untrusted origin (which,
>>> for example, may not be able to support strict CSP policies), while
>>> still preserving attributes.
>>
>>
>>
>> Sure, but you are making a bunch of assumptions or imposing a bunch of
constraints on how applications are designed. What I can say is that for
our application, this wouldn't work. Our security analysis suggests that we
should in all cases attach a different level of trust to the Javascript
code than we do to the browser code. Both can be compromised, of course,
but the ways in which the Javascript can be attacked are more numerous and
varied.
>>
>>
>>
>> ...Mark
>>
>>