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

["Fenwick, Valerie" <valerie.fenwick@intel.com>]

FYI, New comment to list

-----Original Message-----
From: pkcs11-comment@lists.oasis-open.org [mailto:pkcs11-comment@lists.oasis-open.org] On Behalf Of Robert Künnemann
Sent: Wednesday, June 27, 2018 3:05 AM
To: pkcs11-comment@lists.oasis-open.org
Subject: [pkcs11-comment] GCM/CCM mode in PKCS#11

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.

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 a pity: it is very powerful to be able to authenticate data about the permission that a wrapped key should posses when being unwrapped at a possibly different device. Without this feature, secure policies are somewhat limited [2].

To back up this proposal --- leaving the IV generation to the device --- a student of mine, Sven Tangermann, created a formal model that demonstrates how GCM/CCM and similar modes of operations can achieve security guarantees while retaining much more functionality than previous secure policies [3]. A slightly modified variant gives also guarantees for SIV mode.

The key point is that IVs need to be guaranteed to be network-wide unique.  This can be achieved with random number generators, but also without them, by equipping devices with a unique identifier (e.g., a serial number) and combining this identifier with a running counter.
The current specification prohibits this way of securely making use of AES-GCM or AES-CCM. In fact, any compliant device should be vulnerable to Steel's attack.

Thus I would propose the following modifications, so that a device can securely use these new features, while remaining compliant to the standard.

(1) introduce a separate interface for the use of AES-GCM or AES-CCM for authenticated key-wrapping, much like 2.14. The rationale is that applications like IPSec and ZFS might need an interface that allows supply their own IVs, while authenticated key-wrapping requires the IV to be set by the device, and consequently needs to output the encryption
*and* the IV that was chosen, as opposed to the existing interface. 

(2) prohibit the use of existing mechanism for key-wrap (2.11)

(3) For the new interface, provide modified variants of 2.12, 2.12.1, 2.12.3, 2.12.4, 2.12.5. so that

(3a) the interface does not allow for supplying the IV (because this
     cannot be guaranteed to be secure if a host is compromised) i.e.,
     remove plv and ulIvLen from CK_GCM-PARAMS and CK_GCM_PARAMS. 

(3b) Implementations chose the IV themselves.  Recommend or require that
     the IV is unique among all IVs generated for that key on any device
     in the future or past.

(3c) Implementations output the IV they have generated.

I am looking forward to comments and hope that this proposal is helpful, or at least informative. I am happy to give additional information on the model (see also below). As to what concerns the use of SIV, the requirements are very similar: the attribute ought to be network-wide unique, which can be achieved in a very similar manner. But this is a topic on its own.

With kind regards, Robert Künnemann

[1] https://cryptosense.com/blog/attacks-on-key-wrapping-in-pkcs11-v2-40/.
[2] https://robertkunnemann.weebly.com/uploads/2/9/4/5/29452463/templatepolicy-short.pdf
[3] https://robertkunnemann.weebly.com/uploads/2/9/4/5/29452463/main.pdf

PS: As for the technical details: the formal model applies to modes of operation that take an IV (like GCM or CCM), as well as modes that synthesise the IV (SIV)). The basic idea is that every token needs to be equipped with some unique id, and that a running counter on each device is incorporated, along with said id, whenever an encryption is produced, either within the IV (GCM/CCM) or within the header (SIV). Now a key-hierarchy can be achieved by including the level as the header in each wrapping. The result is shown using tamarin-prover, and can even be automated.
--
Robert Künnemann, Ph.D.
Information Security & Cryptography Group, Saarland University E 9.1, Room 2.12, 66123 Saarbrücken
Phone:  +49 681 302 70962 

-- 

This publicly archived list offers a means to provide input to the

OASIS PKCS 11 TC.



In order to verify user consent to the Feedback License terms and

to minimize spam in the list archive, subscription is required

before posting.



Subscribe: pkcs11-comment-subscribe@lists.oasis-open.org

Unsubscribe: pkcs11-comment-unsubscribe@lists.oasis-open.org

List help: pkcs11-comment-help@lists.oasis-open.org

List archive: http://lists.oasis-open.org/archives/pkcs11-comment/

Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf

List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Committee: http://www.oasis-open.org/committees/pkcs11

Join OASIS: http://www.oasis-open.org/join/