Non-extratability Tainting of Keys

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.

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

Received on Friday, 6 September 2013 22:42:50 UTC