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
