OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[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.com

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