← Prev in month ← Prev in thread
Next in thread → Next in month →

GCM/CCM mode in PKCS#11

From
Robert Künnemann <>
Date
2018-06-27T10:04:37+00:00
ID
Thread
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
← Prev in month ← Prev in thread
Next in thread → Next in month →