Re: CKA_VALUE_LEN and C

- CKA_VALUE_LEN must not be given when the mechanism does allow the size of the plaintext to be deduced (e.g. *_CBC_PAD or RSA_OAEP).

There isn’t a simple footnote for that, but we could add this wording underneath table 47. How does that strike people?

Note that unfortunately I can’t attend tonight’s phone meeting, but if it’s discussed tonight I’d be keen to hear the outcome.

Best,

Graham Steel

+33 (0)9 72 42 35 31

http://cryptosense.com

On 10 Jun 2015, at 13:15, Graham Steel <graham@cryptosense.com> wrote:

Dear TC,

A couple of things on key wrapping:

- I checked the spec and the latest version already allows GCM and CCM mode for C_WrapKey and C_UnwrapKey (se table 60). That’s good.

- However, while examine the minutiae for an implementation we came across the following issue:

For AES keys, the superscripts in table 47 (sec 2.8.2) specify that CKA_VALUE_LEN must *not* be given when unwrapping an AES key.

However, sections 2.8.4 and 2.8.5 (ECB and CBC unwrapping using AES) both say that:

For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the CKA_KEY_TYPE attribute of the template and, if it has one, and the key type supports it, the CKA_VALUE_LEN attribute of the template.

Since a 192-bit AES key and a 256 bit AES key would both require two CBC or ECB blocks, I think the CKA_VALUE_LEN *must* be specified in order to be sure that the right object is created. So I propose that (in v2.41) we delete the superscript 6 from CKA_VALUE_LEN in table 48 and replace it with superscript 5.

Note that in testing implementations we found a variety of behaviours here, and one case where ambiguity around this allowed us to execute a padding oracle attack on unwrapping that a manufacturer thought they had prevented.

Best,

Graham Steel
+33 (0)9 72 42 35 31
http://cryptosense.com

pkcs11 message