lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1551456599-10603-1-git-send-email-franck.lenormand@nxp.com>
Date:   Fri,  1 Mar 2019 17:09:57 +0100
From:   Franck LENORMAND <franck.lenormand@....com>
To:     linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, keyrings@...r.kernel.org
Cc:     franck.lenormand@....com, horia.geanta@....com,
        silvano.dininno@....com, agk@...hat.com, snitzer@...hat.com,
        dm-devel@...hat.com, dhowells@...hat.com, jmorris@...ei.org,
        serge@...lyn.com
Subject: [RFC PATCH 0/2] Create CAAM HW key in linux keyring and use in dmcrypt

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ