On Thu, Aug 09, 2018 at 11:01:35AM +0800, Yu Chen wrote: > Hi Pavel, Joey, Oliver > Please let me describe the original requirement and my > understanding about hibernation encryption here, thus > help us sync on the same thread: > On Wed, Aug 08, 2018 at 07:50:36PM +0200, Pavel Machek wrote: > > Hi! > > > > > > > > User space doesn't need to involve. The EFI root key is generated by > > > > > > EFI boot stub and be transfer to kernel. It's stored in EFI boot service > > > > > > variable that it can only be accessed by trusted EFI binary when > > > > > > secure boot is enabled. > > > > > > > > > > > Okay, this apply to the 'suspend' phase, right? > > > > > I'm still a little confused about the 'resume' phase. > > > > > Taking encryption as example(not signature), > > > > > the purpose of doing hibernation encryption is to prevent other users > > > > > from stealing ram content. Say, user A uses a passphrase to generate the > > > > > > > > No, I don't think that's purpose here. > > > > > > > > Purpose here is to prevent user from reading/modifying kernel memory > > > > content on machine he owns. > > > > > > > Say, A puts his laptop into hibernation and walks away, > > > and B walks by, and opens A's laptop and wakes up the system and he > > > can do what he wants. Although EFI key/TPM trusted key is enabled, > > > currently there's no certification during resume, which sounds > > > unsafe to me. Afterall, the original requirement is to probe > > > > Define unsafe. > > > > If you want security against bad people resuming your machines, please > Yes, this is one of the requirements. > > take a look at existing uswsusp solutions. It defends against that. > > > > If you want security against bad people tampering with your machines > > physically, sorry, there's no way to defend against that. > No, this is not the requirement. > > > > But I thought you were trying to do something for secure boot, and "bad > > person resumes your machine" is out of scope there. > > > Not exactly, secure boot is one solution to meet the requirement. > > So please always explain security against _what kind of attack_ you > > are trying to improve; intelligent communication is not possible > > without that. > > > User requirement: > A is the user, B is the attacker, user A launches a STD and > encrypts A's ram data, then writes these encrypted data onto > the disk, so that: Even if user B has access to the disk, > B could not know the content of A. Which implies: > 1. If B unplugs the disk from A's machine, and plugs the disk onto > another machine, B could not decode the content without A's > 'permission'. > 2. If B is using the same machine as A, even A has walked away leaving > the system suspend, B could not resume to A's context without > A's 'permission'. > > Previously, there are three proposal for this: > a. Enhance the uswsusp(Pavel) > b. Using user provided password to generate the key, for encryption(Yu) Base on your A/B users case. Your requirement is a" resume password", it doesn't really neeed encryption. Of course we can use the password to encrypt image, but it's not the key point for your requirement. > c. Using security boot(TPM or EFI key) for encryption(Joey) > No! The EFI key that relies on secure boot is failed. The only solution is TPM trusted key. I agreed with Ard's comment on my EFI secure key patches: https://lkml.org/lkml/2018/8/5/31 "'Secure boot' is a misnomer, since it is too vague: it should be called 'authenticated boot', and the catch is that authentication using public-key crypto does not involve secrets at all." So the EFI key can not be accepted because the secure boot is not designed for confidentiality. So, please forget EFI key. The only solution to me (or secure boot) is TPM trusted key. My purpose for developing the hibernation encryption/authentication is to prevent that the snapshot image be malicious modified. This will cause that the kernel space is not safe for secure boot (or we call it authenticated boot). In kernel space, we want to use locked-down mode to keep kernel space safe. That's also why I said that user space helper must be authenticated by kernel. It also prevents malicious key can be enroll to kernel space. > Since I was proposing solution b, I'll say a little more about it. > The original idea was that, the user provides a password, then this > password is used to generate the key, which means, if user B has provided > an incorrect password, the kernel will fail to decrypt the data and is > likely to fail the resume process. That is to say, no matter > which physical machine B is using, only if he has provided the > password, he would be able to resume. In the first version, the key > deviration was firstly done in kernel space, which satisfies the > requirement and both saftey. Unfortunately it was rejected and > people would like to see the key generated in user space instead. > However, using user provided key directly is not safe, according > to the discussion in the thread. I don't have good idea on > how to improve this, but only have some workarounds, say, ask the > kernel to use TPM key to protects the user provided 'key', etc. Do not need to combind two purposes to one solution. Your requirement is a "resume password", not snapshot encryption. So we can just encrypt snapshot by TPM encrypted key but still use your tool (or uswsusp) to provide "resume password" to user. It's not conflict. If we still want to use the "resume password" to encrypt snapashot image. That's fine, but hibernation function must be locked-down when kernel runs in lock-down mode. Because "resume password" doesn't help anything in lockdown mode. Unless we found a way to authenticate the user space helper by kernel. Regards Joey Lee
