Re: Comments on wrap/unwrap

On Wed, Jun 12, 2013 at 12:24 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> On Wed, Jun 12, 2013 at 12:00 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>> 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.
>
>
> You could also say that about the extractable attribute, or potentially
> anything in the spec. The spec defines what a compliant implementation must
> do and there is some value in that even when you don't have 100% proof that
> the UA is compliant.
>
> To support the use-case, this needs to be specified as proposed.
>
>>
>>
>> >
>> > 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.
>
>
> We can't, because this is an issue also without named keys.
>
> Regarding the security model, we previously established that this is an
> issue and that it affects the extractable attribute as much as these other
> things. We should keep the specification consistent - if we are going to
> have the extractable attribute at all then we need to be able to deliver
> non-extractable wrapped keys, which has the implications I described above.
>
> If the group decides that the model is invalid, then the extractable
> attribute can be removed and my points above become moot.

I disagree with your conclusion that supporting extractable requires,
by definition supporting non-extractable wrapped keys - if anything,
this highlights the general issue with key wrapping.

Your proposed solution suggests that the JWE/CEK should be modified to
support attributes - which helps for the JWE/CEK case, but does
nothing for other formats, which would conceivably share the same
issue.

CryptoAPI/CNG, for example (and +cc Vijay for the possibility of me
misstating here) lacks the functionality you're requesting, and has
worked out quite fine for applications.

PKCS#11 somewhat supports the notion you're trying for, by virtue of
the CKA_WRAP_TEMPLATE and CKA_UNWRAP_TEMPLATE attribute that applies
to the wrap/unwrapping key. In the wrap case, the CKA_WRAP_TEMPLATE
specifies a list of attributes that the *key to be wrapped* must
match. In the unwrap case, the CKA_UNWRAP_TEMPLATE specifies a list of
attributes that must not conflict with the caller-supplied list of
attributes.

My statement about the unwrapping key rejecting extractable=false is a
failure mode consistent with this latter part. The issue you have
seems to be whether or not the ability to mutate those attributes
necessarily needs to be exposed to application authors, or whether it
can be kept behind the notion of 'implementation dependent' - for
example, coupled to named keys.

I don't think it's absolutely necessary for non-extractable unwrapped
keys to be supported in V1. I've provided a proposal that would allow
implementations that view it as necessary to do so in a manner
consistent with the generic algorithm, and would prefer to leave it
'unspecified' / 'not supported' for the generic case. We can then
revisit different approaches of how to do so - and exactly what the
security model of such applications are.

>
>>
>>
>> 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.
>
>
> The intention of the named origin-specific keys is that there are no special
> implementation requirements other than the existence of the keys themselves
> and compliance to the WebCrypto specifications.
>
> Again, though, this is an issue without named origin-specific keys.
>
> ...Mark
>
>>
>>
>> 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:41:46 UTC