[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: CKA_VALUE_LEN and C_UnwrapKey
Hi Graham - We discussed this in today's meeting. One small suggested change: On 7/8/2015 3:01 AM, Graham Steel wrote:
Following on from the brief discussion of this at the phone meeting on 10th June it seems to me that the right behaviour is: - *CKA_VALUE_LEN is **required* when unwrapping using a mechanism that doesn’t allow the size of the plaintext to be deduced (e.g. *_CBC or *_ECB) - *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).
Others would prefer s/CKA_VALUE_LEN must not/CKA_VALUE_LEN should not (as it will just be ignored if sent). There was a request as well to add an explanation for this change, such as you describe in the last two paragraphs below in your original email. Would you be willing to write that up as a draft proposal to send to the TC? There was also some discussion about whether this would be better suited for the Usage Guide, rather than the Base Spec. Please consider that as you write up a draft. Thanks! Valerie
* * 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.comOn 10 Jun 2015, at 13:15, Graham Steel <graham@cryptosense.com <mailto: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
-- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]