Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20180718235851.GA22170@sandybridge-desktop> <20180719110149.GA4679@amd>
 <20180719132003.GA30981@sandybridge-desktop> <20180720102532.GA20284@amd>
 <1532346156.3057.11.camel@suse.com> <20180723162302.GA4503@sandybridge-desktop>
 <1532590246.7411.3.camel@suse.com> <20180726081404.GG4244@linux-l9pv.suse>
 <20180730170415.GQ4244@linux-l9pv.suse> <20180803033702.GB416@sandybridge-desktop>
 <20180803053445.GC4244@linux-l9pv.suse>
In-Reply-To: <20180803053445.GC4244@linux-l9pv.suse>
From:   Ryan Chen <yu.chen.surf@gmail.com>
Date:   Fri, 3 Aug 2018 21:14:22 +0800
Message-ID: <CADjb_WSURQz86+E8kakNf7UBDM+aho+uaz3QdDkuGsEgan=szw@mail.gmail.com>
Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption
To:     jlee@suse.com
Cc:     Chen Yu <yu.c.chen@intel.com>, oneukum@suse.com,
        Pavel Machek <pavel@ucw.cz>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        ebiggers@google.com, "Theodore Ts'o" <tytso@mit.edu>,
        smueller@chronox.de, denkenz@gmail.com,
        Linux PM list <linux-pm@vger.kernel.org>,
        linux-crypto@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        kookoo.gu@intel.com, Zhang Rui <rui.zhang@intel.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.
Best,
Yu
> > 2. The generation of secret key in EFI boot environment is
> >    using a non standard derivation method in generate_secret_key(),
> >    I'm not sure if this is safe enough. This is why we tried to put
> >    PBKDF2 into kernel at first and leave it to the user space then.
> >
>
> Thank you for point out.
>
> The generate_secret_key() reuse the logic in kaslr_get_random_long()
> that it produces random seed by RDRAND, RDTSC and i8254. It doesn't
> standard like PBKDF2, but we do not have too many choices in the
> early boot stage. At least KASLR is using the same logic.
>
> We can relay on user space helper. But the helper must be authenticated
> by kernel. Currently we do not have kernel mechanism to verity user
> space process.
>
> Regards
> Joey Lee


-- 
Thanks,
Ryan