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, JarkkoHi 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