RE: [pkcs11] Secure key wrap proposal

Hi Graham,

 

Could you post this to the PKCS 11 TC documents folder? Here’s the URL:

 

https://www.oasis-open.org/apps/org/workgroup/pkcs11/documents.php?folder_id=2732

 

thanks!

Bob

 

From:  [mailto:]
On Behalf Of Graham Steel

Sent: Mittwoch, 1. April 2015 11:32

To: 

Subject: [pkcs11] Secure key wrap proposal

 

Hi,

 

Here’s an update on my secure key wrap proposal ahead of tonight’s call (which I’ll be on).

 

For context, I want to propose mechanisms for key wrap that allow you to encode attributes along with the encrypted keys in a secure way. I give some use cases for this in a document posted here http://markmail.org/message/zgccpro3pivwrrb2

 

There are several sub proposals to this:

 

1. Add the possibility to encode PKCS#11 key attributes into the PKCS#8 private key structure that is already included in the new (in 2.40) RSA_AES_KEY_WRAP mechanism 

 

- this was included in the 1.3 version of the proposal posted here

 

http://markmail.org/message/dhapvqxcbymhsbht

 

- and withdrawn from the final proposal here

 

http://markmail.org/message/5rjpvk6iy2qqv64n

 

In the withdrawal, Doron emphasised that SafeNet’s motivation was just to define a wrapping mechanism that was CCA secure and could be used to wrap private key objects, not to fix the attributes problem. Discussion in that thread about
 whether adding in these attributes would break existing implementations was resolved by the fact that this was a proposal for new mechanism, not an addition to e.g. unwrap using CKM_RSA_OAEP, nothing would be broken. 

 

I would like to know if there are any other reasons why this part of the proposal had to be withdrawn that are not recorded on the list.

 

2. Allow the use of GCM and CCM for key wrap. 

 

On April 3 2013 - Darren J Moffat proposed adding wrap/unwrap flag for GCM and CCM. Mike StJohn said he would email CCM creators about it because there may be security concerns. The thread then  goes dead.

 

http://markmail.org/thread/zymwg4kgefj2hjao

 

From a crypto point of view I see no security problems with using a conventional AE more to encrypt keys. For an expert’s view, check out this Phil Rogaway paper ("WHY THIS GOAL?" section) which explains the motivation for specific wrapping
 mode (data is already randomised, less bandwidth required if there is no nonce/IV) and notes that in many circumstances a conventional AE mode is just fine. 

 

http://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf

 

3. Define an encoding of PKCS#11 attributes to allow CCM/GCM key wrap to specify PKCS#11 attributes as associated data

 

I looked for a standard format for symmetric keys (a sort of equivalent of PKCS#8) but I can’t find one. There are specific financial formats like TR-31 but nothing general purpose that I could find.

 

I would like to know if anyone knows of such a format. If not, is it reasonable to just encode a template in the same format as is used to pass it in a buffer to a PKCS#11 command (TLV)? Even if restricted to Boolean attributes this would
 be very useful.

 

 

I look forward to your comments either on the list or on the call tonight.

 

Best,

 

Graham Steel

+33 (0)9 72 42 35 31

http://cryptosense.com