Re: Comments on wrap/unwrap

On Tue, Jun 11, 2013 at 8:31 AM, Mark Watson <watsonm@netflix.com> wrote:
> All,
>
> First, if you receive two versions of this email, they should be equivalent.
> I wrote one last night and now find no sign of it in my email system, so
> this is just a rewrite and retransmission :-(
>
> Second, sorry for the delay in responding on this topic. I was unexpectedly
> out of the office all last week.
>
> I have two comments on the wrap/unwrap implementation in the latest draft.
>
> 1) The procedures refer to the import/export procedures which are currently
> unspecified. For the mechanism to meet the original requirements, it's
> important that import and export respect the attributes of the Key (usage,
> exportable). We need to define mappings for these to/from JWK and in the
> import case the values in the JWK must override those in the import method
> parameters.

I'm of a mixed opinion as to whether or not this needs to be specified
to this level. The security model assumed here is already
implementation dependent - whether or an implementation respects these
fields, or provides any other guarantees, is already opaque to the web
application.

>
> 2) There is one important difference between our proposal and what Ryan has
> implemented. We proposed methods that would create/consume a JWE-encrypted
> JWK object in one step. Ryan's proposed methods are simpler, more flexible
> and agnostic as to the wrapping format. Implementing JWE-encrypted JWK takes
> two steps but the JS could also implement other formats.
>
> However, in order to obtain the same properties, in terms of key
> extractibility, as the original proposal it is necessary for any temporary
> keys (such as JWE Content Encryption Key) to be encoded in a way that
> carries attributes. To explain this, first note that Ryan's methods wrap and
> unwrap are effectively compound methods based on the existing encrypt,
> decrypt, import and export: wrap = export+encrypt and unwrap=decrypt+import
> where the intermediate result (at the '+') is not exposed to the script.
>
> To implement JWE-encrypted JWK with these methods we proceed as follows:
>
> Wrap a key X using wrapping key Y:
> (W1) Generate a Content Encryption Key with usage "wrap"
> (W2) Use the CEK with the wrap method to export+encrypt X (using JWK format)
> (W3) Use Y and with the wrap method to export+encrypt the CEK
> (W3) Construct the JWE object using the output of steps W2 and W3
>
> Unwrap a key X using wrapping key Y:
> (U1) Extract the wrapped CEK and the payload from the JWE structure
> (U2) Use Y and the unwrap method to decrypt+import the wrapped CEK,
> resulting in a Key object K[CEK] for the CEK
> (U3) Use K[CEK] and the unwrap method to decrypt+import the payload,
> resulting in a Key object for X
>
> Let's suppose the X has extractable=false. In order for this property to be
> maintained it's essential the K[CEK] is not extractible and does not have
> usage "decrypt". Otherwise, it would be possible for the Javascript to use
> K[CEK] to simply decrypt the payload, exposing the key X.
>
> Therefore, the wrapped encoding of the CEK must carry the extractible and
> usages attributes (for cases where the extractibility property of X must be
> maintained).

I don't really see this as the case.

Again, you're working from a threat model where you don't trust the
executing JS. Obviously, this is a threat model that I disagree with,
but you can mitigate this in an implementation-dependent way that
matches your implementation-dependent dependency on named keys.

For example, if unwrapKey() is called where unwrappingKey is a key
from some 'named key store', your implementation could choose to fail
the operation if the calling application ever set extractable=true or
set 'decrypt' in keyUsages. That is, your implementation checks these
while importing.

If you trust the JS executing at that particular time, then you just
set extractable=false and don't add a decrypt key usage.

>
> There are two issues with this:
>
> (A) This is incompatible with the current JWE specification, where the
> wrapped CEK must be encoded as raw octets (though there is a proposal to
> allow JWK here)
>
> (B) If the wrapping key is an RSA key, then the size of the encoded CEK is
> constrained by the size of object this RSA key can encrypt. The only
> attribute-supporting encoding, JWK, has arbitrary size, so it's not clear
> how this constraint works in practice
>
> These issues may both be acceptable. I haven't done the maths for (B) to see
> what the CEK size constraint is for a given RSA key size. If this constraint
> is an issue we would need a more compact key+attributes format than JWK.
>
> ...Mark

Received on Wednesday, 12 June 2013 19:00:55 UTC