GCM/CCM mode in PKCS#11

[Robert Künnemann <robert.kuennemann@uni-saarland.de>]

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