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] Review before next meeting

About my work item (Key Wrapping with encoded attributes)

- I have already noted (thanks to Tim Hudson) to change the tags in section 4.1 to become standard tags in KMIP as well. Previously they were in the « vendor defined » range which will cause problems.

- However there is a more subtle crypto/security point which I’ve come across while addressing another of Tim’s points:

The idea of this wrapping method is to offer a higher level of security than existing schemes where the template for the new key is supplied on unwrapping. This means protecting against attacks where an intruder with access to the PKCS#11 interface may make a second copy of the key with some of the attributes changed - SENSITIVE turned off for example - in order to get hold of the encrypted key value.

The method relies on the new «  authenticated encryption » methods added to v2.40: GCM and CCM. Both of these are counter modes, which means that they work by calculating a key stream from the IV + a counter, and then XOR this against the plaintext to obtain the ciphertext.

The problem is that if the attacker controls the IV, he can control the key stream. This means he can use the encrypt operation to decrypt, by giving the cipher text as the plaintext and reusing the same IV. In the context of PKCS11 wrap and unwrap, this mean he could decrypt a wrapped key if he can wrap a known key value. It may be possible to avoid the possibility of wrapping a known value by making heavy usage restrictions on the API, but if we introduce the new wrapping mechanism where attributes (known data for the most part) are included in the plaintext, this is no longer possible.

Options include: make the IVs for this wrap mechanism token-generated (probably a good idea anyway for NIST compliance), add a mode with automatic deterministic nonce calculation like SIV (designed for key-wrap), use an AEAD mode so that attributes are treated as public data.



Graham Steel
+33 (0)9 72 42 35 31

On 31 May 2016, at 23:45, Valerie Fenwick <valerie.fenwick@oracle.com> wrote:

Hi folks-

We want to really start moving forward on 3.0, and we have a few items that are approaching readiness for ballot. But, we really don't want to take things to ballot if they need changes before they can be approved :-) to that end, please take time before our next meeting to review and give feedback to the authors on.

I have provided the public links as well, if you find that useful:

* New function proposal draft 3(Bob R):
WG link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58225
PUblic Link: https://www.oasis-open.org/committees/document.php?document_id=58225

* Updated AEAD Proposal (Bob R.):
WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57976
Public Link: https://www.oasis-open.org/committees/document.php?document_id=57976

* AES GCM Changes form AEAD API (Bob R.):
WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57637
Public Link: https://www.oasis-open.org/committees/document.php?document_id=57637

* PKCS11 Wrapping with templates - v2 (Graham S):
WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58092
Public link: https://www.oasis-open.org/committees/document.php?document_id=58092

* Adding attributes to wrapped keys - (Graham S):
WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58091
Public Link: https://www.oasis-open.org/committees/document.php?document_id=58091

Please complete your review by Monday, June 6, to give the author time to incorporate your suggested changes and have a moment for you to we review that they got them right before our next meeting on June 8.

Thank you so much! There is a lot here, but once we start knocking some of these things off, there will be less :-)

If I missed one of the documents we're currently reviewing, please
let me know. I know documents like the DSA one are awaiting further updates.

I hope to have my proposal for constant identifier allocation out shortly.

Note: I am using voice recognition software. Forgive any strange words.
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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