On Fri, Aug 3, 2018 at 10:06 PM joeyli <jlee@xxxxxxxx> wrote: > > On Fri, Aug 03, 2018 at 09:14:22PM +0800, Ryan Chen wrote: > > On Fri, Aug 3, 2018 at 1:35 PM joeyli <jlee@xxxxxxxx> wrote: > > > > > > On Fri, Aug 03, 2018 at 11:37:02AM +0800, Yu Chen wrote: > > > > Hi Joey, > > > > On Tue, Jul 31, 2018 at 01:04:15AM +0800, joeyli wrote: > > > > > Hi all, > > > > > > > > > > On Thu, Jul 26, 2018 at 04:14:04PM +0800, joeyli wrote: > > > > > > On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote: > > > > > > > On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote: > > > > > > > > > > > > > > > > Good point, we once tried to generate key in kernel, but people > > > > > > > > suggest to generate key in userspace and provide it to the > > > > > > > > kernel, which is what ecryptfs do currently, so it seems this > > > > > > > > should also be safe for encryption in kernel. > > > > > > > > https://www.spinics.net/lists/linux-crypto/msg33145.html > > > > > > > > Thus Chun-Yi's signature can use EFI key and both the key from > > > > > > > > user space. > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > ecryptfs can trust user space. It is supposed to keep data > > > > > > > safe while the system is inoperative. The whole point of Secure > > > > > > > Boot is a cryptographic system of trust that does not include > > > > > > > user space. > > > > > > > > > > > > > > I seriously doubt we want to use trusted computing here. So the > > > > > > > key needs to be generated in kernel space and stored in a safe > > > > > > > manner. As we have a saolution doing that, can we come to ausable > > > > > > > synthesis? > > > > > > > > > > > > > > Regards > > > > > > > Oliver > > > > > > > > > > > > Crurently there have two solutions, they are trusted key and EFI key. > > > > > > Both of them are generated in kernel and are not visible in user space. > > > > > > > > > > > > The trusted key is generated by kernel then sealed by the TPM's > > > > > > SRK. So the trusted key can be stored in anywhere then be enrolled > > > > > > to kernel when we need it. EVM already uses it. > > > > > > > > > > > > The EFI key is Jiri Kosina's idea. It is stored in boot services > > > > > > variable, which means that it can only be access by signed EFI binary > > > > > > (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied > > > > > > this solution a couple of years. > > > > > > > > > > > > I am working on put the EFI key to key retention service. Then > > > > > > EFI key can be a master key of encrypted key. EVM can also use > > > > > > it: > > > > > > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f > > > > > > https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec > > > > > > > > > > > > That's why I want to use key retention service in hibernation > > > > > > encryption/authentication. Which means that we can use key > > > > > > API to access trusted key and EFI key. > > > > > > > > > > > > > > > > Here is a proof of concept for using the key retention service > > > > > to encrypt/sign snapshot image. It's using EFI key now, I will > > > > > add encrypted key support in the key handler later: > > > > > https://github.com/joeyli/linux-s4sign/commit/6311e97038974bc5de8121769fb4d34470009566 > > > > > > > > > Thanks for the work, I have two questions here: > > > > > > My EFI key patch set is almost done. I will send it soon. > > > > > Okay, please send them out then we can have further discussion > > on that. > > > > 1. Could you please describe a little more about the scenario on > > > > how the user could use the secret key for hibernation encryption? > > > > A requirement is that, the user should provide a passphrase(for key derivation, i.e.) > > > > during resume. I was thinking how user could interact with > > > > the security key mechanism here. > > > > > > > > > > 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 > > key and encrypted the hibernation snapshot and stores it on the disk . > > Then if user > > B wants to do a hibernation resume to A's previous environment, B has > > to provide the same passphrase. > > If I understand correctly, the secret key is saved in header and stored > > on the disk. Which means, any one can read the header from the disk > > to get the secret key in trampoline thus decrypt the image, which is not > > safe. > > The secret key that it's saved in snapshot header is a session key which > is encrypted by ERK (EFI root key). The ERK only lives in kernel space. > So the session key is still secure. > > When resume, the session key will be decrypted/verified by ERK. Then > kernel uses the session key to decrypted/verified snapshot image. > OK, I see. > Of course that we can direct use ERK to encrypt/authenticate snapshot > image. Actually the first version of hibernation verification in SLE > direct uses ERK. So the snapshot header only keeps signature but no > encrypted session key. > > I add session key in new version because I want to align with > the use case of TPM trusted key + encrypted key. Then hibernation > can use key retention service API to access EFI key or encrypted key. > > Compare the trusted key with EFI secure key: > > TPM SRK ----seal-----> Trusted key ---encrypt---> Encrypted key > ERK ---encrypt---> EFI secure key ---encrypt---> Encrypted key > > Both of them can be the master key of encrypted key. > So either Trusted key or EFI secure key(session key) could be used for snapshot encryption, right? > If EFI key can not be accepted by kernel community, then the TPM > trusted key + encrypted key will be the only solution. We can very > easy to switch to encrypted key by using key retention service > API. > Back to question raised previously, how could TPM or EFI key be used to prevent user B from resuming to the environment of A? It appears to me that, although A is the user who launches the hibernation, B could resume to the context of A because there's no certification during resume. Is there any way to introduce the password based verification? Best, Yu > Thanks a lot! > Joey Lee
