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;
Date:   Fri, 3 Aug 2018 13:34:45 +0800
From:   joeyli <jlee@suse.com>
To:     Yu Chen <yu.c.chen@intel.com>
Cc:     Oliver Neukum <oneukum@suse.com>, Pavel Machek <pavel@ucw.cz>,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
        Eric Biggers <ebiggers@google.com>,
        Theodore Ts o <tytso@mit.edu>,
        Stephan Mueller <smueller@chronox.de>,
        Denis Kenzior <denkenz@gmail.com>, linux-pm@vger.kernel.org,
        linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
        "Gu, Kookoo" <kookoo.gu@intel.com>,
        "Zhang, Rui" <rui.zhang@intel.com>
Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation
 encryption
Message-ID: <20180803053445.GC4244@linux-l9pv.suse>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180803033702.GB416@sandybridge-desktop>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

> 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.

> 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