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

[Robert Relyea <rrelyea@REDHAT.COM>]

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.

bob