[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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!
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Graham Steel 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 - and withdrawn from the final proposal here 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. 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. 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, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]