From: joeyli <jlee@suse.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: David Howells <dhowells@redhat.com>, Pavel Machek <pavel@ucw.cz>,
"Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
LKML <linux-kernel@vger.kernel.org>,
linux-pm@vger.kernel.org, keyrings@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Chen Yu <yu.c.chen@intel.com>, Oliver Neukum <oneukum@suse.com>,
Ryan Chen <yu.chen.surf@gmail.com>,
Giovanni Gherdovich <ggherdovich@suse.cz>,
Randy Dunlap <rdunlap@infradead.org>,
Jann Horn <jannh@google.com>
Subject: Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image
Date: Fri, 11 Jan 2019 22:59:58 +0800 [thread overview]
Message-ID: <20190111145958.GA3599@linux-l9pv.suse> (raw)
In-Reply-To: <CALCETrU5qWzMSLxa28XHXBsg-gZwkxfzrqztTbBO+qcCYQbTMA@mail.gmail.com>
On Thu, Jan 10, 2019 at 05:09:46PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 10, 2019 at 7:13 AM joeyli <jlee@suse.com> wrote:
> >
> > On Wed, Jan 09, 2019 at 10:47:42AM -0800, Andy Lutomirski wrote:
> > > On Wed, Jan 9, 2019 at 8:40 AM joeyli <jlee@suse.com> wrote:
> > > >
> > > > Hi Andy,
> > > >
> > > > Thanks for your review!
> > > >
> > > > On Tue, Jan 08, 2019 at 01:41:48PM -0800, Andy Lutomirski wrote:
> > > > > > On Jan 7, 2019, at 9:37 AM, joeyli <jlee@suse.com> wrote:
> > > > > >
> > > > > > Hi Pavel,
> > > > > >
> > > > > > Thanks for your review!
> > > > > >
> > > > > >> On Sun, Jan 06, 2019 at 07:10:27PM +0100, Pavel Machek wrote:
> > > > > >> Hi!
> > > > > >>
> > > > > >>> This patchset is the implementation of encryption and authentication
> > > > > >>> for hibernate snapshot image. The image will be encrypted by AES and
> > > > > >>> authenticated by HMAC.
> > > > > >>
> > > > > >> Ok, so you encrypt.
> > > > > >
> > > > > > Yes, encryption and authentication.
> > > > > >
> > > > > >>> The hibernate function can be used to snapshot memory pages to an image,
> > > > > >>> then kernel restores the image to memory space in a appropriate time.
> > > > > >>> There have secrets in snapshot image and cracker may modifies it for
> > > > > >>> hacking system. Encryption and authentication of snapshot image can protect
> > > > > >>> the system.
> > > > > >>>
> > > > > >>> Hibernate function requests the master key through key retention service.
> > > > > >>> The snapshot master key can be a trusted key or a user defined key. The
> > > > > >>> name of snapshot master key is fixed to "swsusp-kmk". User should loads
> > > > > >>> swsusp-kmk to kernel by keyctl tool before the hibernation resume.
> > > > > >>> e.g. The swsusp-kmk must be loaded before systemd-hibernate-resume
> > > > > >>
> > > > > >> But if userspace has a key, encryption is useless against root.
> > > > > >
> > > > > > Yes, but this concern is not only for hibernation encryption. This patch
> > > > > > set does not provide solution against this concern.
> > > > > >
> > > > > > The purpose of this patch set is to encrypt and authenticate hibernate
> > > > > > snapshot image in kernel space. It also requests key through keyring
> > > > > > mechanism. Which means that we can easy to adapt to new key type from
> > > > > > keyring in the future.
> > > > > >
> > > > > > Currently TPM trusted key or user defined key types are not against
> > > > > > root. Even using the TPM trusted key, it still can be unsealed by root
> > > > > > before the PCRs be capped (unless we capped PCRs in kernel).
> > > > > >
> > > > > > My solution for keeping the secret by kernel is the EFI secure key type:
> > > > > > https://lkml.org/lkml/2018/8/5/31
> > > > > >
> > > > > > But the EFI boot variable doesn't design for keeping secret, so Windows
> > > > > > and OEM/ODM do not use boot variable to keep secret. So this idea can
> > > > > > not be accepted. We must think other key type against root.
> > > > > >
> > > > > >>> The TPM trusted key type is preferred to be the master key. But user
> > > > > >>> defined key can also be used for testing or when the platform doesn't
> > > > > >>> have TPM. User must be aware that the security of user key relies on
> > > > > >>> user space. If the root account be compromised, then the user key will
> > > > > >>> easy to be grabbed.
> > > > > >>
> > > > > >> In the TPM case, does userland have access to the key?
> > > > > >
> > > > > > In the TPM case, userland can only touch the sealed key blob. So userland
> > > > > > doesn't know the real secret. But it has risk that root unseals the key
> > > > > > before PCRs be capped.
> > > > > >
> > > > > >> Please explain your security goals.
> > > > > >
> > > > > > My security goals:
> > > > > >
> > > > > > - Encrypt and authicate hibernate snapshot image in kernel space. Userspace
> > > > > > can only touch an encrypted and signed snapshot image.
> > > > >
> > > > > Signed?
> > > > >
> > > > > I’m not entirely convinced that the keyring mechanism is what you
> > > > > want. ISTM that there are two goals here:
> > > > >
> > > > > a) Encryption: it should be as hard as can reasonably be arranged to
> > > > > extract secrets from a hibernation image.
> > > > >
> > > > > b) Authentication part 1: it should not be possible for someone in
> > > > > possession of a turned-off machine to tamper with the hibernation
> > > > > image such that the image, when booted, will leak its secrets. This
> > > > > should protect against attackers who don’t know the encryption key.
> > > > >
> > > > > c) Authentication part 2: it should be to verify, to the extent
> > > > > practical, that the image came from the same machine and was really
> > > > > created using hibernation. Or maybe by the same user.
> > > > >
> > > > > For (a) and (b), using an AE mode where the key is protected in some
> > > > > reasonable way. Joey, why are you using HMAC? Please tell me you’re
> > > > > at least doing encrypt-then-MAC. But why not use a real AE mode like
> > > > > AES-GCM?
> > > >
> > > > The reason for using HMAC is the history for development. My first patch
> > > > set is only for hibernate authentication. Then I added encryption code on
> > > > top of my authentication patches in last version.
> > > >
> > > > I am doing encrypt-then-MAC. My code ecrypts each page by AES then HMAC
> > > > whole snapshot image. I feed encrypted data pages one by one to
> > > > crypto_shash_update() API for calculating the hash for whole image.
> > >
> > > ...
> > >
> > > I think you should write down a clear description of the data format.
> >
> > Hibernation allocates free pages for building snapshot image. Those free
> > pages are scattered in memory. So kernel marks those page numbers on a
> > bitmap to locate them. Because this image buffer is discontinuous, so I
> > use update mode hashing whole image.
> >
> > > A general problem with crypto is that the fact that it appears to work
> > > doesn't mean it's secure at all, and it's very hard to follow the
> > > code. Especially in Linux using the crypto API -- code using the
> > > crypto API tends to be mostly boilerplate.
> > >
> >
> > hm... Do you mean that the implementation of HMAC in crypto cannot be
> > trusted? I hope at least that I can trust the update mode for normal
> > hash like SHA256 or SHA512?
>
> No, I fully expect the crypto code to do what it says. What I mean is
> that you can easily create utterly broken things that involve crypto,
> but they still work fine when you use then non-maliciously.
>
OK, I see! I will review my code with crypto to make sure that I didn't
create broken things.
> > > >
> > > > Sorry for I didn't capture the meaning of "acceptable usage". The trusted
> > > > key already be unsealed by TPM when the key be enrolled by keyctl tool.
> > > > So my code just extract the unsealed key data (the random number) for
> > > > encryption.
> > >
> > > If someone creates a trusted key that is used for asymmetric crypto or
> > > perhaps a trusted key that is intended to be used for, say, an HMAC
> > > key, you should not also use it to derive hibernation keys. This is
> > > what I mean by "acceptable usage".
> > >
> >
> > When keyring is producing encrypted key, the trusted key be used to
> > derive the encrypt key and authenticate key to encrypt and hmac sign
> > a encrypted key. So trusted key can be used in symmetric crypto.
>
> Can it?
>
> David, you actually understand the overall kernel keyring design. Do
> keys in the keyring have usage constraints?
>
> But I think you need to take a big step back here. We already have
> kernel/power/user.c. It seems to me that you can do a better job of
> what you're trying to do with less code by using it. Why do you need
> new kernel code *at all* to accomplish your goals?
I still very think for you, Stephan, Pavel and all kernel experts'
review to my code. I will follow your suggestions to rewrite my
solution.
I thought that the userland hibernation is not enough against a
compromised root. My original target of hibernation encryption and
authentication is for kernel lockdown mode. I hope that kernel can
produce encrypted/signed snapshot image. So I developed EFI secure
key and hibernation encryption.
Becasue my original solution relates two areas, EFI and hibernation.
So I separated them and sent them to kernel upsteam for review. The
EFI seucre key is not accepted so I moved to use TPM trusted key.
I thought that the final problem is still how to deal with TPM against
a compromised root.
Thanks a lot!
Joey Lee
prev parent reply other threads:[~2019-01-11 15:00 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 14:32 [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image Lee, Chun-Yi
2019-01-03 14:32 ` [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Lee, Chun-Yi
2019-01-06 8:01 ` Stephan Mueller
2019-01-06 8:25 ` Stephan Mueller
2019-01-07 15:33 ` joeyli
2019-01-07 15:52 ` Stephan Mueller
2019-01-08 5:03 ` Herbert Xu
2019-01-08 7:09 ` Stephan Mueller
2019-01-08 23:54 ` Andy Lutomirski
2019-01-09 0:44 ` James Bottomley
2019-01-09 1:43 ` Andy Lutomirski
2019-01-09 6:49 ` James Bottomley
2019-01-09 18:11 ` joeyli
2019-01-11 15:53 ` Jarkko Sakkinen
2019-01-09 18:34 ` Andy Lutomirski
2019-01-09 19:46 ` James Bottomley
2019-01-09 20:12 ` Andy Lutomirski
2019-01-09 21:43 ` James Bottomley
2019-01-09 22:19 ` Pavel Machek
2019-01-11 16:04 ` Jarkko Sakkinen
2019-01-11 14:02 ` Jarkko Sakkinen
2019-01-11 15:28 ` James Bottomley
2019-01-18 14:33 ` Jarkko Sakkinen
2019-01-18 20:59 ` James Bottomley
2019-01-20 16:02 ` Jarkko Sakkinen
2019-01-09 6:45 ` Stephan Mueller
2019-01-09 6:58 ` James Bottomley
2019-01-09 7:05 ` Stephan Mueller
2019-01-09 8:21 ` Eric Biggers
2019-01-09 10:17 ` Stephan Mueller
2019-01-09 17:34 ` Eric Biggers
2019-01-09 18:18 ` Stephan Mueller
2019-01-11 19:08 ` [PATCH 0/6] General Key Derivation Function Support Stephan Müller
2019-01-11 19:09 ` [PATCH 1/6] crypto: add template handling for RNGs Stephan Müller
2019-01-11 19:10 ` [PATCH 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller
2019-01-12 5:27 ` Eric Biggers
2019-01-14 9:31 ` Stephan Müller
2019-01-11 19:10 ` [PATCH 3/6] crypto: kdf - add known answer tests Stephan Müller
2019-01-12 5:26 ` Eric Biggers
2019-01-14 9:26 ` Stephan Müller
2019-01-11 19:10 ` [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function Stephan Müller
2019-01-12 5:12 ` Eric Biggers
2019-01-12 9:55 ` Herbert Xu
2019-01-13 7:56 ` Stephan Müller
2019-01-13 16:52 ` James Bottomley
2019-01-14 9:30 ` Stephan Müller
2019-01-14 17:53 ` Eric Biggers
2019-01-14 18:44 ` Stephan Mueller
2019-01-11 19:10 ` [PATCH 5/6] crypto: hkdf - add known answer tests Stephan Müller
2019-01-12 5:19 ` Eric Biggers
2019-01-14 9:25 ` Stephan Müller
2019-01-14 17:44 ` Eric Biggers
2019-01-11 19:11 ` [PATCH 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller
2019-01-16 11:06 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Müller
2019-01-16 11:07 ` [PATCH v2 1/6] crypto: add template handling for RNGs Stephan Müller
2019-01-16 11:08 ` [PATCH v2 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller
2019-01-16 11:08 ` [PATCH v2 3/6] crypto: kdf - add known answer tests Stephan Müller
2019-01-16 11:08 ` [PATCH v2 4/6] crypto: hkdf - HMAC-based Extract-and-Expand KDF Stephan Müller
2019-01-16 11:09 ` [PATCH v2 5/6] crypto: hkdf - add known answer tests Stephan Müller
2019-01-16 11:09 ` [PATCH v2 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller
2019-01-28 10:07 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Mueller
2019-01-30 10:08 ` Herbert Xu
2019-01-30 14:39 ` Stephan Mueller
2019-02-08 7:45 ` Herbert Xu
2019-02-08 8:00 ` Stephan Mueller
2019-02-08 8:05 ` Herbert Xu
2019-02-08 8:17 ` Stephan Mueller
2019-02-19 5:44 ` Herbert Xu
2019-01-09 15:34 ` [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler James Bottomley
2019-01-09 6:27 ` Stephan Mueller
2019-01-03 14:32 ` [PATCH 2/5] PM / hibernate: Generate and verify signature for snapshot image Lee, Chun-Yi
2019-01-06 8:09 ` Stephan Mueller
2019-01-07 18:58 ` Dan Carpenter
2019-01-03 14:32 ` [PATCH 3/5] PM / hibernate: Encrypt " Lee, Chun-Yi
2019-01-06 8:23 ` Stephan Mueller
2019-01-03 14:32 ` [PATCH 4/5 v2] PM / hibernate: Erase the snapshot master key in snapshot pages Lee, Chun-Yi
2019-01-03 14:32 ` [PATCH 5/5 v2] PM / hibernate: An option to request that snapshot image must be authenticated Lee, Chun-Yi
2019-01-06 18:10 ` [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image Pavel Machek
2019-01-07 17:37 ` joeyli
2019-01-07 18:07 ` Pavel Machek
2019-01-08 21:41 ` Andy Lutomirski
2019-01-08 23:42 ` Pavel Machek
2019-01-09 16:39 ` joeyli
2019-01-09 16:47 ` Stephan Mueller
2019-01-11 14:29 ` joeyli
2019-01-09 16:51 ` joeyli
2019-01-09 18:47 ` Andy Lutomirski
2019-01-10 15:12 ` joeyli
2019-01-11 1:09 ` Andy Lutomirski
2019-01-11 14:59 ` joeyli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190111145958.GA3599@linux-l9pv.suse \
--to=jlee@suse.com \
--cc=dhowells@redhat.com \
--cc=ggherdovich@suse.cz \
--cc=jannh@google.com \
--cc=joeyli.kernel@gmail.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luto@kernel.org \
--cc=oneukum@suse.com \
--cc=pavel@ucw.cz \
--cc=rafael.j.wysocki@intel.com \
--cc=rdunlap@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).