[RFC PATCH 0/2] Create CAAM HW key in linux keyring and use in dmcrypt

[Franck LENORMAND]

This RFC aims to provide better security of users using CAAM block allowing
them to encrypt their disks with a hardware key. A hardware key is a
key only know by the hardware hence not known neither by the userspace nor
the kernelspace.

The use of hardware keys allows to mitigate attacks against systems using
such type of keys as the key is more complicated to obtain. In effect, even
a compromised kernel could not divulge the key used to encrypt the data.
The user or the kernel can only configure a device mapper using the target
crypt and provide the HW key to encrypt a disk.

The CAAM possesses a mechanism to generate HW keys called "black key".

The CAAM has the capacity to encrypt a plain key ("red key") with a key
only accessible by the hardware hence creating a "black key". The
encryption key used change at each reset of the CAAM: shutdown, reboot.

generate a black key: <plain key> -> CAAM -> <black key>

To keep a black key between reset, it must be stored in filesystem in a
structure called "black blob". This structure contains the "black key" but
also encryption information. It is also generated by the CAAM using a key
only accessible by the hardware but which doesn't change between reset of
the CAAM.

generate a black blob: <black key> -> CAAM -> <black blob> -> FS
obtain the black key: FS -> <black blob> -> CAAM -> <black key>

The creation of such structures and its use was not exposed to userspace so
it was complicated to use and required custom development. We would like to
ease this using interface which are known and used:
 - Linux key retention service : Allow to generate or load keys in a
	keyring	which can be used by applications.
 - dm-crypt : device mapper allowing to encrypt data.

The capacity to generate or load keys already available in the Linux key
retention service does not allows to exploit CAAM capabilities hence we
need to create a new key_type. The new key type "caam_tk" allows to:
 - Create a black key from random
 - Create a black key from a red key
 - Load a black blob to retrieve the black key

The patch 01 presents the implementation of the key type is available in
the RFC. This implementation is presented to give context but cannot be
compiled as it requires other components not presented in this RFC.

We target dm-crypt to perform the disk encryption. It can retrieve keys
from the Linux key retention service however it only supports the key
type "user" and "logon". In order to use keys from our new key type, we
need to either:
 - add support for our new key type : dm-crypt need a reference on the key
	type structure.
 - support any key type : the reference on the key type is retrieved from
	the key subsystem based on the name of the key type

The patch 02 present the implementation of the second solution. The main
advantage of this implementation are:
 - The reference on the key type is no more needed at compile time
 - All future key type will be supported
 - Only the key type registered can be obtained (key type as module)

We think that this modification of dm-crypt and the key subsystem will ease
the use of dm-crypt and the development of key type.

Franck LENORMAND (2):
  drivers: crypto: caam: key: Add caam_tk key type
  dm-crypt: Use any key type which is registered

 drivers/crypto/caam/caam_key.c | 623 +++++++++++++++++++++++++++++++++++++++++
 drivers/crypto/caam/caam_key.h |  58 ++++
 drivers/md/dm-crypt.c          |  11 +-
 include/linux/key-type.h       |   2 +
 security/keys/key.c            |  42 +++
 5 files changed, 731 insertions(+), 5 deletions(-)
 create mode 100644 drivers/crypto/caam/caam_key.c
 create mode 100644 drivers/crypto/caam/caam_key.h

-- 
2.7.4