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

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.

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.
#2.1 can (and should) be mitigated via HTTPS and related.
#2.2 can (and should) be mitigated via CSP and related.

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.

Received on Friday, 19 July 2013 02:10:06 UTC