Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp766768imm; Fri, 3 Aug 2018 11:07:59 -0700 (PDT) X-Google-Smtp-Source: AAOMgpctM9RU7m/5DykmVOhtKEKQQvWSV71LQ0Zuabrs8nMNE+EYI7LboXezR/AbgiJNODaHqhTb X-Received: by 2002:a63:1a20:: with SMTP id a32-v6mr4799066pga.446.1533319679531; Fri, 03 Aug 2018 11:07:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533319679; cv=none; d=google.com; s=arc-20160816; b=xWCIonvHIlZP4jJZfV8q8yf6osDXU/1YZtZV/1dUOKnZJNHMgJaP5VDL65ZSt+fvDF KpHctIi4BirWWeJZWvyHT+yrHzOelXedsmJxvXssaWLzlV6Tx0h3mpOTkwMCpJDFIjxJ vTL+pp6IemQ4XvYm3p8H97zDm92RcHb+KuFzRzGMYRS+qYiM1q3CQ6Lb6QqRtnHf2z5R taoDK7KtBLh5Y8HX05qv3EjMqPU3kT5loQmxTAhflqRhn+S+mGk9sThdGe7Si4SLlmdc tko9z+fUhooJtz67sHPPUfhfh1BfmgUHP+1FoqlRPz0lorbsYd0VNgVx8JG4aTXZGDgD OPlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=owVSYHojxPA5h7PgOboTtZO12NgoYDSMorZ9sktlYuA=; b=Kv3YkWLHjX4s4rLotzAI0+of63NcB6RdQxezTy5Ft3I2ryfYzX8ba8Fsk4W9IeKD19 kB15BrxmTm692bZz3NYicVoslcx0a6XP/zjrzav5qJv+QX+0wMjPeJrQ1hVJb3k8e0Ox zdhDMiuzfPAJIaww/m29rFpYVhfwKHVypAPr5ssHgo3RfzoG9nDPB/KBniHyNZTvgOc/ mDMZqjNRNQvomMPSJx+XXfTSiP4CUW9VeNZIASEXHu8yuDRvckO6D8QHQBwMmb/bq0Rc YvPm/XTjxvKNA6YYwQU4rNBsfvgDL/2dwXeB+IcDuStEyeyx8oBpjC2/Sqd1H2oEiHnG daGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l30-v6si4341290plg.12.2018.08.03.11.07.41; Fri, 03 Aug 2018 11:07:59 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728457AbeHCUEM (ORCPT + 99 others); Fri, 3 Aug 2018 16:04:12 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:57327 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727356AbeHCUEM (ORCPT ); Fri, 3 Aug 2018 16:04:12 -0400 Received: from linux-l9pv.suse (124-11-22-254.static.tfn.net.tw [124.11.22.254]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Fri, 03 Aug 2018 20:06:39 +0200 Date: Sat, 4 Aug 2018 02:06:24 +0800 From: joeyli To: Ryan Chen Cc: Chen Yu , oneukum@suse.com, Pavel Machek , "Rafael J. Wysocki" , ebiggers@google.com, Theodore Ts'o , smueller@chronox.de, denkenz@gmail.com, Linux PM list , linux-crypto@vger.kernel.org, Linux Kernel Mailing List , kookoo.gu@intel.com, Zhang Rui Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption Message-ID: <20180803180624.GE4244@linux-l9pv.suse> References: <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> <20180803140443.GD4244@linux-l9pv.suse> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 04, 2018 at 12:09:08AM +0800, Ryan Chen wrote: > On Fri, Aug 3, 2018 at 10:06 PM joeyli wrote: > > > > On Fri, Aug 03, 2018 at 09:14:22PM +0800, Ryan Chen wrote: > > > On Fri, Aug 3, 2018 at 1:35 PM joeyli 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? Yes. Or we can use encrypted key. It depends on different use case. If the trusted key is sealed with PCRs, then we can not generate new trusted key after PCRs be capped. Then we can only use the encrypted key as the session key. > > 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? I see you point. Yes, TPM or EFI key can only be used to prevent that the content in snapshot image be detected on other machine. It can not be used to prevent the snapshot image be resumed on _the same_ machine by different user. Sounds like B can physical accessing the machine. Could you please explain more detail for the case? As you said, password is useful in this case. But I have no idea for how to introduce password without user space helper. And user space helper must be authenticate by kernel. Which means that we need to add mechanism to verify user space binary. Thanks Joey Lee