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

Message

Franck Lenormand March 1, 2019, 4:09 p.m. UTC

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

Comments

Jan Lübbe March 6, 2019, 4:47 p.m. UTC | #1

Hi Franck,

thanks for working on this!

On Fri, 2019-03-01 at 17:09 +0100, Franck LENORMAND wrote:
> 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

On 2018-07-23, Udit Agarwal <[e-mail]> sent a series which
seems related to this:
[PATCH v2 1/2] security/keys/secure_key: Adds the secure key support
based on CAAM.
[PATCH v2 2/2] encrypted_keys: Adds support for secure key-type as
master key.

Is this series intended to continue that work and cover the same uses-
cases? 

If I remember correctly, the CAAM also supports marking blobs to allow
or disallow exporting the encapsulated key from the hardware. Or is
this unneeded and we could encrypt/decrypt other (less critical) key
material against the tk(cbc(aes)) CAAM key via the keyring mechanisms?

Best regards,
Jan

David Howells March 6, 2019, 5:29 p.m. UTC | #2

Franck LENORMAND <[e-mail]> wrote:

> 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

Is it possible that this could be done through an existing key type, such as
the asymmetric, trusted or encrypted key typed?

David

Franck Lenormand March 7, 2019, 1:02 p.m. UTC | #3

> -----Original Message-----
> From: Jan Lübbe <[e-mail]>
> Sent: Wednesday, March 6, 2019 5:48 PM
> To: Franck Lenormand <[e-mail]>; linux-
> [e-mail]; [e-mail];
> [e-mail]
> Cc: Horia Geanta <[e-mail]>; Silvano Di Ninno
> <[e-mail]>; [e-mail]; [e-mail]; dm-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; David Gstir <[e-mail]>
> Subject: Re: [RFC PATCH 0/2] Create CAAM HW key in linux keyring and use in
> dmcrypt
> 
> Hi Franck,
> 
> thanks for working on this!
> 
> On Fri, 2019-03-01 at 17:09 +0100, Franck LENORMAND wrote:
> > 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
> 
> On 2018-07-23, Udit Agarwal <[e-mail]> sent a series which
> seems related to this:
> [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based
> on CAAM.
> [PATCH v2 2/2] encrypted_keys: Adds support for secure key-type as master
> key.
> 
> Is this series intended to continue that work and cover the same uses- cases?
> 
> If I remember correctly, the CAAM also supports marking blobs to allow or
> disallow exporting the encapsulated key from the hardware. Or is this
> unneeded and we could encrypt/decrypt other (less critical) key material
> against the tk(cbc(aes)) CAAM key via the keyring mechanisms?
> 
> Best regards,
> Jan
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.pengutronix.de%2F&amp;data=02%7C01%7Cfranck.lenormand%40nxp.co
> m%7C29ab89e99f9040e30aa908d6a2537967%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C636874876732153093&amp;sdata=byKD4SmYfzMTs
> FK6cX5L81%2B9hxxqTbnOLf7%2BAJgXylU%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: [phone]    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   [phone]-5555 |

Hello Jan,

The current series is aimed to change which key type is acceptable in dm-crypt. Without
this change, the key type cannot be integrated properly.

About the key type implementation:
The implementation of the key type is an improvement related to the work of Udit Agarwal.

The transform tk(cbc(aes)) is intended to receive key material whose format can change
hence the "tagging" to handle it properly. It could, for example, handle plain keys, black keys or blobs as key material and this material would be stored in keyring.

Regards,
Franck

Franck Lenormand March 7, 2019, 1:17 p.m. UTC | #4

> -----Original Message-----
> From: David Howells <[e-mail]>
> Sent: Wednesday, March 6, 2019 6:30 PM
> To: Franck Lenormand <[e-mail]>
> Cc: [e-mail]; [e-mail]; linux-security-
> [e-mail]; [e-mail]; Horia Geanta
> <[e-mail]>; Silvano Di Ninno <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [RFC PATCH 0/2] Create CAAM HW key in linux keyring and use in
> dmcrypt
> 
> Franck LENORMAND <[e-mail]> wrote:
> 
> > 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
> 
> Is it possible that this could be done through an existing key type, such as the
> asymmetric, trusted or encrypted key typed?
> 
> David

Hello David,

I didn't know about asymmetric key type so I looked it up, from my
observation, it would not be possible to use it for the caam_tk as
we must perform operations on the data provided.
The name " asymmetric " is also misleading for the use we would have.

The trusted and encrypted does not provides the necessary
callbacks to do what we would need or require huge modifications.

I would like, for this series to focus on the change related to
dm-crypt. In effect, it is currently not possible to pass a key
from the asymmetric key type to it.

Franck

James Bottomley Jan. 18, 2020, 5:51 p.m. UTC | #5

On Thu, 2019-03-07 at 13:17 +0000, Franck Lenormand wrote:
> > -----Original Message-----
> > From: David Howells <[e-mail]>
> > Sent: Wednesday, March 6, 2019 6:30 PM
> > To: Franck Lenormand <[e-mail]>
> > Cc: [e-mail]; [e-mail]; linux-
> > security-
> > [e-mail]; [e-mail]; Horia Geanta
> > <[e-mail]>; Silvano Di Ninno <[e-mail]>;
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: [RFC PATCH 0/2] Create CAAM HW key in linux keyring
> > and use in
> > dmcrypt
> > 
> > Franck LENORMAND <[e-mail]> wrote:
> > 
> > > 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
> > 
> > Is it possible that this could be done through an existing key
> > type, such as the
> > asymmetric, trusted or encrypted key typed?
> > 
> > David
> 
> Hello David,
> 
> I didn't know about asymmetric key type so I looked it up, from my
> observation, it would not be possible to use it for the caam_tk as
> we must perform operations on the data provided.
> The name " asymmetric " is also misleading for the use we would have.
> 
> The trusted and encrypted does not provides the necessary
> callbacks to do what we would need or require huge modifications.
> 
> I would like, for this series to focus on the change related to
> dm-crypt. In effect, it is currently not possible to pass a key
> from the asymmetric key type to it.

What you're performing are all bog standard key wrapping operations
which is why we're asking the question: do we have to expose any of
this to the user?  Can this whole thing not be encapsulated in such a
way that the kernel automatically selects the best key
escrow/accelerator technology on boot and uses it (if there are > 1
there would have to be an interface for the user to choose).  We make
all the accelerator device key formats distinguishable so the kernel
can figure out on load what is supposed to be handling them.  That way
the user never need worry about naming the actual key handler at all,
it would all be taken care of under the covers.

The one key type per escrow/accelerator has us all going ... "aren't
there hundreds of these on the market?"  which would seem to be a huge
usability explosion because a user will likely only have one, but they
have to figure out the type instructions for that one.  I really think
a better way is to have a more generic key type that's capable of
interfacing to the wrap/unwrap and crypto functions in such a way that
the end user doesn't have to know which they're using: most platforms
only have one thing installed, so you use that thing.

James