Thread (5 messages) 5 messages, 3 authors, 2022-02-04

Re: [PATCH v4] KEYS: encrypted: Instantiate key with user-provided decrypted data

flat view

From: Jarkko Sakkinen <jarkko@kernel.org>
Date: 2022-02-04 06:28:33
Also in: keyrings, linux-doc, linux-integrity, lkml

On Wed, Jan 26, 2022 at 03:56:44PM -0500, Yael Tiomkin wrote:
On Wed, Jan 26, 2022 at 9:51 AM Jarkko Sakkinen [off-list ref] wrote:
quoted
On Wed, Jan 26, 2022 at 04:47:22PM +0200, Jarkko Sakkinen wrote:
quoted
On Tue, Jan 18, 2022 at 01:26:05PM -0500, Martin Ross wrote:
quoted
Hi Jarkko,

I have been working with Yael on this project so I thought I might add
a bit of background here around the use case that this series of
patches is trying to address.

At a high level we are trying to provide users of encryption that have
key management hierarchies a better tradeoff between security and
availability.  For available and performance reasons master keys often
need to be released (or derived/wrapped keys created) outside of a KMS
to clients (which may in turn further wrap those keys in a series of
levels).  What we are trying to do is provide a mechanism where the
wrapping/unwrapping of these keys is not dependent on a remote call at
runtime.  e.g.  To unwrap a key if you are using AWS KMS or Google
Service you need to make an RPC.  In practice to defend against
availability or performance issues, designers end up building their
own kms and effectively encrypting everything with a DEK.  The DEK
encrypts same set as the master key thereby eliminating the security
benefit of keeping the master key segregated in the first place.
Mainly this part (would be enough to explain why it is there).

BR, Jarkko
Hi Jarkko,

As for the commit message, WDYT about the following:

KEYS: encrypted: Instantiate key with user-provided decrypted data

For availability and performance reasons master keys often need to be
released outside of a KMS to clients. It would be beneficial to provide a
mechanism where the wrapping/unwrapping of DEKs is not dependent
on a remote call at runtime yet security is not (or only minimally) compromised.
Master keys could be securely stored in the Kernel and be used to wrap/unwrap
keys from userspace.

The encrypted.c class supports instantiation of encrypted keys with
either an already-encrypted key material, or by generating new key
material based on random numbers. This patch defines a new datablob
format: [<format>] <master-key name> <decrypted data length>
<decrypted data> that allows to inject and encrypt user-provided
decrypted data.


I want to make sure we're on the same page before publishing a new version.

Thanks,
Yael
It looks really good.

/Jarkko
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help