RE: Non-extratability Tainting of Keys

 

 

From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Tuesday, September 10, 2013 5:23 PM
To: Jim Schaad
Cc: Ryan Sleevi; public-webcrypto@w3.org
Subject: Re: Non-extratability Tainting of Keys

 



Sent from my iPhone


On Sep 10, 2013, at 4:16 PM, Jim Schaad <ietf@augustcellars.com> wrote:

 

 

From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Monday, September 09, 2013 4:06 PM
To: Jim Schaad
Cc: Ryan Sleevi; public-webcrypto@w3.org
Subject: Re: Non-extratability Tainting of Keys

 

 

 

On Mon, Sep 9, 2013 at 3:45 PM, Jim Schaad <ietf@augustcellars.com> wrote:

Ok - I remember that as being discussed, but I did not think it was on the
table as a solution and I believe that this is not a solution that solves
the Netflix problem.

 

The problem statement that I believe that Netflix has is:

 

It is required that one can chain from one non-extractable key (KeyA) to a
second non-extractable key (KeyB) in such a way as to prevent an active
script attacker from obtaining the value of KeyB while being able to use
KeyA for "normal" purposes.

 

The solution of having an attribute in a JWK fails for the following
reasons:

 

1.        You may not be able to wrap a JWK in an RSA key due to size
constraints.  This solution only works if you are assuming that KeyA is a
symmetric key and not if it is an asymmetric key (either RSA or ECDH).

If you use something like JWE-encapsulated-JWK, then the JWK is always
wrapped using a symmetric key and only the (symmetric) Content Master Key is
wrapped using the asymmetric key. I believe the numbers work out such that
the size constraints are not a problem.

 

Nevertheless, in this case you need the Content Master Key to also be a JWK
in order to carry its own attributes. (I'm assuming we use the existing
WebCrypto API where unwrap = decrypt + export and not the originally
proposed idea where JWE-encapsulated-JWK was natively supported as an
algorithm in its own right).

 

And you do need the usages in the JWK also to be respected, or for
encryption and wrap usages to be distinct algorithms (and I mean distinct in
that one cannot be performed using the other, like the difference between
AES-CBC and AES-KW, not just that they have different WebCrypto names but do
the same thing.)

 

This is also an example of an application where you unwrap a key which must
then only be usable for unwrapping.

 

Strictly, for our purposes, the constraint on JWK size that comes with an
asymmetric wrapping key is acceptable.

 

[JLS] So I unwrap the CEK (names have been changed in JOSE) with RSA.  The
CEK is not tagged as non-exportable so I can export it and then decrypt the
JWK on my own.  

 

This is why I said the CEK must also be a JWK containing extractable and
usage attributes, which need to be respected by the UA.

 

So, what you get is a WebCrypto Key for the CEK with extractable = false and
usages = [unwrap].

 

[JLS] but that implies that you need to wrap a JWK object inside of an RSA
key (potentially) or only use symmetric keys as the beginning point for this
exercise.  The first may be difficult and the second limits the general
applicability of the chaining operation.  It would also follow that there
needs to be a set of changes made to how ECDH works as well that you have
not covered.

 

 

Also there is nothing which is forcing the CEK to be tagged as a key wrap
algorithm, in fact one would expect it to be tagged as a content encryption
algorithm since you would then use a CEK algorithm not a KEK algorithm to
decrypt the content.

 

Ok. This works.

 

However, I'm open to other solutions. Yours looks like it would almost work,
but it involves quite heavy blanket restrictions on how things behave.

 

...Mark

 

 

Jim

 

 

2.       If the active script can capture the encrypted JWK which is being
passed from the server to the client, then it can call the decrypt function
on KeyA to decrypt the JWK and then parse the JWK to get KeyB independent of
the presence of an attribute in the JWK string.

Yes, the usage on KeyA would include unwrap but not decrypt.

 

Then, in the case that KeyB is actually the Content Master Key for a
JWE-encapsulated-JWK, the usage attribute of KeyB would also indicate only
unwrap.

 

...Mark 

 

 

 

 

Jim

 

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Monday, September 09, 2013 11:57 AM


To: Jim Schaad
Cc: public-webcrypto@w3.org
Subject: Re: Non-extratability Tainting of Keys

 

 

 

On Sat, Sep 7, 2013 at 7:17 PM, Jim Schaad <ietf@augustcellars.com> wrote:

If there is a solution to the non-extractability on the table, I have
completely missed it.

 

I was unable to come up with a good solution to the non-extractability
problem that was not as draconian as the one that I proposed except for some
very limited cases.  I would love to get a pointer to the Netflix solution
so that I can see if I think it really works or if it is just a very small
subset of what is needed.  Does the solution work just for the RSA key
transport problem or does it work for the ECDH problem as well?

 

Jim

 

 

The Netflix solution: Only applies to JWK, through the introduction of a new
attribute. Any JWKs unwrapped with this attribute supercede the attributes
specified by the caller.

 

My proposal: unextractability is specified by the caller.

 

It's extremely important that you elaborate on your threat model when
unwrapping keys as well as your expectations on what 'unextractable' means.
In the discussions so far, it's in the context of "key provisioning", which
is such a complex can of worms (see Anders' proposals to understand just
*some* of what is commonly requested) that I would much rather not try to
boil the ocean to solve that yet, and I'm convinced that the current Netflix
proposal is NOT something that is web-extendable in the future when we DO
try to solve those.

 

 

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, September 06, 2013 4:55 PM


To: Jim Schaad
Cc: public-webcrypto@w3.org
Subject: Re: Non-extratability Tainting of Keys

 

Jim,

 

Could you state then what problem you're trying to solve?

 

We have solutions for non-extractability on the table. You've proposed yet
another. The question is what set of problems you believe they solve that
the other solutions do not solve or solve inadequately that required yet
another proposal.

 

That is, you enumerated your proposal, highlighting a number of
disadvantages compared to any of the existing proposals, but unless I'm
mistaken, you failed to highlight what (new) problems were being solved.

 

Given that Netflix has proposed at least one solution that they feel meets
their needs in a much less restrictive manner, I'm curious what problem
space you feel needs an even more restrictive API space (eg: one that
prevents polyfills).

 

Cheers

 

On Fri, Sep 6, 2013 at 4:50 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I believe this is something that I desire.  I believe that this is probably
what Nexflix desires.

 

I believe that this is not going to make Ryan think that this is a problem
that needs to be solved.

 

Jim

 

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, September 06, 2013 4:20 PM
To: Jim Schaad
Cc: public-webcrypto@w3.org
Subject: Re: Non-extratability Tainting of Keys

 

 

 

On Fri, Sep 6, 2013 at 3:41 PM, Jim Schaad <ietf@augustcellars.com> wrote:

This is a proposal of how to do tainting of keys with non-extractability.
As part of this proposal, there is a set of things that are restricted when
you have a key marked as non-extractable.  I do not believe that these
restrictions are burdensome, but others might.  This message is intended to
provide a workable solution to the non-extractible problem.  There is still
a need to determine if this work is needed or not.

My assumption is that when one starts with a non-extractable secret, then
all secrets that are derived from that secret need to be non-extractable as
well.

 

That's not something I desire. Is that something you desire, or is this an
interpretation of what Netflix desires?

 

I guess I read your preamble as "I'm not sure what problem I'm trying to
solve, but here's a possible solution", which leaves me a bit... confused?

 


Changes to the current document:

1.  There is a new restriction placed on algorithm descriptions so that the
usages [KeyWrap,KeyUnwrap] and [Encryption,Decryption] are mutually
exclusive.   Most of the time this will not be an issue, but for some
encryption algorithms it will mean that there will need to be two algorithms
defined.  One of these will be for content encryption and one will be for
key encryption.  This would be an issue for example with AES-GCM where a new
AES-GCM-KeyWrap algorithm would need to be defined which allows for key
wrapping to occur.

2.  When a key agreement operation is done with a key marked as
non-extractable, the DeriveBits key usage is removed on the resulting secret
so that only keys can be derived.

3.  KeyUnwrap, KeyAgreement and DeriveKey all propagate the non-extractable
bit if it is on the key that was used in the operation.

4.  It is assumed that a key encryption algorithm which unwraps a key
produces a content encryption key (i.e. the usage on the resulting key is
decryption not key unwrap). If one wants to do a two level key unwrap then a
new algorithm would need to be defined that went from a key wrap key to a
key wrap key rather than a content encryption key.  I would be surprised if
this was ever needed in practice.

The resulting restrictions:

1.  Only the algorithms defined in the UA will be available to a
non-extractible key and any secrets that are derived from it.  This is an
issue if one looks at some of the composite AEAD algorithms such as the
AES-CBC/HMAC-SHA-256 algorithm that the JOSE documents use.  If such an
algorithm is to be used, it must be in the UA and not provided by the script
even if all of the components of the composite algorithm are provided by the
UA.

2.  DeriveBits cannot be used to generate both key data and non-key data
when using a non-extractable key.   This makes it impossible, for example,
to derive both a key and an iv from the shared secret in the same way as the
TLS extractor done.  It would be possible to document how an extractor could
be defined where the DeriveBits would still be permitted, but the data
stream and the key stream would be required to be distinct by having the
extractor mix in data that indicates the stream that the data is being
generated for as part of the data generation process.

3.  Only those key formats that are supported by the UA can be used with a
non-extractable key.  Thus if one wants to use a JWK key format, then that
format must be supported by the UA or it cannot be used.

4.  If one assumes that bad code can exist, then one can only be truly
assured that this works for named keys (i.e. those keys that are populated
by the UA itself).  However there are some tricks that one can play with
trying to extract and test non-extractable keys where one can potentially
later detect that the key was not generated with the non-extractable bit
set.

Jim