On Tue, Jan 18, 2022 at 01:26:05PM -0500, Martin Ross wrote: > 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. > > We are building a mechanism to create a security boundary in the > kernel that allows these master keys to be stored in the kernel and > used to wrap/unwrap keys via less trusted user processes. The other > goal here is to eliminate the complexity and statefulness required to > do this today which would be to create a trusted daemon or process on > the machine. Concretely this means that since the user process will > not have the master key the system designer has better options. One > obvious advantage is that any core dumps or code injection attacks > won't be able to trivially grab the master key from the process or the > linux keyring. Once in the kernel this functionality can be > transparently integrated into user space crypto libraries that have > existing key management functionality. > > Hope this helps and happy to answer any further questions! > > M Thank you. It indeed does. I think it is a good explanation. Maybe the way to move forward would be bring this context at leat a bit to the documentation update? /Jarkko
