[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11-comment] GCM/CCM mode in PKCS#11
Hi! On 30/07, Robert Relyea wrote:
On 06/27/2018 03:04 AM, Robert Künnemann wrote: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.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.
I am glad to hear that you are working on it.
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.
If I read the draft correctly, instead of creating separate interfaces for internal IV generation, you use pParameter to either read externalIVs from, or write internally-generated IVs to, and leave the choice to permit one or the other to the token. Did I get this right?
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).
I was concerned with the former case, AES-GCM keys wrapping "other" keys. It would be useful to have wrap key semantics for them, since AES-GCM, and authenticated encryption in general, would allow the tokento store what permission the "other" key should have on unwrapping.
The current wrap key semantics for AES-GCM in v2.40 let the user supply the IV, hence any user with access to the HSM was able to mount a two-time pad attack and thus learn any key that was wrapable in that way. So I do not see much use in allowing external IVs at all, but I am obviously coming from a "security first, functionality second" perspective here. Would it be an actual loss to mandating that the IV is generated internally, in general? In any case, I think we agree that internal IV generation should at least be possible, in which case the generated IV needs to be output. Do you envision a similar parameter block to communicate the IV to the application? With kind regards, Robert Künnemann -- Robert Künnemann, Ph.D. Information Security & Cryptography Group, Saarland UniversityE 9.1, Room 2.12, 66123 Saarbrücken Phone: +49 681 302 70962
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]