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
>
>
>
>