← Prev in month
← Prev in thread
Next in thread →
Next in month →
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 →