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


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11-comment message

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

Subject: Re: [pkcs11-comment] GCM/CCM mode in PKCS#11

On 06/27/2018 03:04 AM, Robert KÃnnemann wrote:
Dear OASIS Members and other interested parties,

I would like to propose an amendment to the PKCS#11 interface, more
specifically, the "PKCS #11 Cryptographic Token Interface Current
Mechanisms Specification Version 2.40 Plus Errata 01". It concerns the
AES-GCM and AES-CCM authenticated modes of encryption/decryption (2.12
to 2.14), or the handling of authenticated encryption (GCM/CCM model,
but also SIV mode) in general.
Sorry for taking so long to get back to you. I wanted to have time to actually digest your comments to make sure you are in fact saying what I think you are saying.

So the issue you are bringing up is actually one we've been working on for PKCS #11 3.0. In fact it's probably the driving feature of PKCS #11 3.0. A number of our tokens need to generate the IV internally and present it during encryption (this is a basic FIPS requirement). The main impediment to this is our current interface didn't allow additional parameters on update calls. This means we could only implement AES-GCM using the one shot EncryptInit/Encrypt interface, meaning you loose state betwen each AES-GCM message.

PKCS #11 3.0 now has the EncryptMessage interface, which was made with AEAD style encryption algorithms in mind. Each message has it's own Parameter block, so IV, authentication data, and additional data can be supplied to each Message of an active stream. In addition we have a parameter to select the generation method. We still allow for external IV's, but tokens may refuse to accept them.

The current interface requires implementations to permit setting the
initialisation vector (IV), which, as Graham Steel pointed out, defeats
confidentiality of key-wrapping [1]

This is the one area I'm not clear on. Are you using AES-GCM to actually wrap keys, or are you talking about attacks on AES-GCM keys that have been wrapped. In that case we have not defined a wrap key semantic for AES-GCM in PKCS #11 3.0 (but such a mechanism would be relatively easy to define once we got PKCS #11 3.0 out the door).

The latest edit is available here: https://www.oasis-open.org/committees/document.php?document_id=63472&wg_abbrev=pkcs11

I'm reviewing it myself to make sure everything got in.


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