lkml.org 
[lkml]   [2018]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption
    On Fri, Aug 3, 2018 at 10:06 PM joeyli <jlee@suse.com> 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@suse.com> 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

    \
     
     \ /
      Last update: 2018-08-03 18:10    [W:3.734 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site