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] RSA Key Import proposal

On 4/2/2013 11:27 AM, Cohen, Doron wrote:

Proposal :

We propose that the PKCS#11 specification explicitly state that a CKA_UNWRAP_TEMPLATE attribute can contain a CKA_UNWRAP_TEMPLATE to be applied to whatever key is unwrapped by the key in question. Currently this is ambiguous.  In addition, we recommend that CCM and GCM be enabled for wrap and unwrap. This is crucial for prevent oracle padding attacks.

If you're worried about misuse of the AES key, then instead, how about defining a mechanism - CKM_RSA_AES_KEYWRAP? This defines a mechanism which first unwraps the AES key using RSA, and then uses the AES key wrap mechanism to unwrap the actual data? The AES key gets implicit attributes (and actually never gets a public handle) when unwrapped, and goes away once the other key is unwrapped. The template on the original RSA private key applies to the finally unwrapped new RSA private key.

On the wrapping side, the AES key is generated internally, wraps the data, is encrypted under the RSA public key, and then zeroized.

For an elliptic curve equivalent you probably need something like CKM_ECIES_AES_KEYWRAP.

Also, RFC5649 is probably a much better choice for key wrapping than CCM or GCM. That's CKM_AES_KEY_WRAP_PAD in the 2.30 draft.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]