From: Andy Lutomirski <luto@kernel.org> To: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: Andy Lutomirski <luto@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, Stephan Mueller <smueller@chronox.de>, Herbert Xu <herbert@gondor.apana.org.au>, "Lee, Chun-Yi" <joeyli.kernel@gmail.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, 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>, David Howells <dhowells@redhat.com>, Giovanni Gherdovich <ggherdovich@suse.cz>, Randy Dunlap <rdunlap@infradead.org>, Jann Horn <jannh@google.com> Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Date: Wed, 09 Jan 2019 18:34:42 +0000 [thread overview] Message-ID: <CALCETrWoSAf4hHCXvqVZhQ5YAMBaZzaBCfnb6sC8JPrSs6FRog@mail.gmail.com> (raw) In-Reply-To: <1547016579.2789.17.camel@HansenPartnership.com> >> On Jan 8, 2019, at 10:49 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: >> >> On Tue, 2019-01-08 at 17:43 -0800, Andy Lutomirski wrote: >> [Adding Jarkko because this stuff relates to the TPM.] > >> Anyway, if we're talking about the TPM, it seems like the entire >> "trusted key" mechanism in the kernel is missing the point. If I >> want to encrypt something like a hibernation image on a machine with >> a TPM, it makes essentially no sense to me that we would get a key >> with a known raw value that is merely TPM-backed (i.e. the "trusted >> key") and use that to decrypt the image. The right way to do it is >> to the use the TPM as it was intended to be used: generate a single- >> use key that protects the hibernation image and seal *that* directly >> on the TPM, such that it can only be unsealed with appropriate PCR >> values. Heck, we could even use one of the fancy NV counters such >> that we *can't* decrypt the image later on. And using HMAC or any AE >> construction the normal way is also wrong -- we should *hash* the >> image and sign the hash directly on the TPM so that the restore code >> can validate the PCR values that were in place when the hibernation >> image was created. [0] > > Well, theoretically, trusted keys can be used for PCR sealed bundles, > at least in 1.2 ... I'm not sure the 2.0 one actually works because you > have to construct the policy session outside the kernel. I suppose I should go read the 2.0 spec. I’ve read the 1.2 spec, but I always assumed that 2.0 was essentially a superset of 1.2 functionality. >> Presumably we should at least try to replay the PCR operations that >> have occurred so that we can massage the PCRs into the same state >> post-hibernation. Also, do we have any way for the kernel to sign >> something with the TPM along with an attestation that the signature >> was requested *by the kernel*? Something like a sub-hierarchy of >> keys that the kernel explicitly prevents userspace from accessing?) > > We're just growing that now with the TPM asymmetric operations. > Attesting that the kernel requested the signature is harder. The TPM > can attest to log entries (as it does for the UEFI log and IMA) and it > can certify keys, but that only proves they're TPM resident not who the > requestor was. Effectively the latter is an assertion about who knows > the key authority, which is hard to prove. Can the kernel filter TPM 2.0 operations? If so, then a signature that the kernel would have prevented user code from generating is de facto an attestation that the kernel generated it (or that the kernel was compromised, which is sort of equivalent). > >> [0] If you take some data, run it through an authenticated encryption >> algorithm, and sign (key, nonce, tag), I think you're operating >> outside of the accepted security definitions if you expect this to >> guarantee that the data wasn't tampered with. I'm reasonably >> confident that there are quite a few excellent AE algorithms that >> completely fail if used this like this. In fact, pretty much all of >> the modern fast ones probably fail. AE is for when the key is >> *secret*. > > Well, I think here, if we were actually trying to solve the problem of > proving the hibernated image were the same one we would need to prove > some log of the kernel operation came to a particular value *after* the > hibernated image were restored ... it's not really possible to > condition key release which must occur before the restore on that > outcome, so it strikes me we need more than a simple release bound to > PCR values. I’m not sure I follow. Here are the two properties I’d like to see: 1. If you have an encrypted hibernation image, the only thing you should be able to do with it is to restore it. So only an actual Linux kernel in hibernation restore mode ought to be able to restore it. We get this if the image can only be read with appropriate PCRs and then only by the kernel. This way, you can’t just read out secrets from the image if you steal a laptop — you have to actually boot the thing. 2. You shouldn’t be able to create an intentionally corrupt image that pwns you when you restore it unless you have already pwned the kernel. Maybe the “kernel” bit in #1 can be relaxed to “root” without totally defeating the purpose, but if some random non-root process that happens to have access to /dev/tpm* can make a valid-looking TPM image, then I think we fail. Limiting it to the kernel is only dubiously better than limiting it to root until we implement lockdown, in which case it's important. #2 only really matters with lockdown. I suppose that a good summary of my opinion is that there is no point to kernel support for encrypted hibernation images until lockdown is upstream. --Andy
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@kernel.org> To: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: Andy Lutomirski <luto@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, Stephan Mueller <smueller@chronox.de>, Herbert Xu <herbert@gondor.apana.org.au>, "Lee, Chun-Yi" <joeyli.kernel@gmail.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, 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>, David Howells <dhowells@redhat.com>, Giovanni Gherdovich <ggherdovich@suse.cz>, Randy Dunlap <rdunlap@infradead.org>, Jann Horn <jannh@google.com> Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Date: Wed, 9 Jan 2019 10:34:42 -0800 [thread overview] Message-ID: <CALCETrWoSAf4hHCXvqVZhQ5YAMBaZzaBCfnb6sC8JPrSs6FRog@mail.gmail.com> (raw) In-Reply-To: <1547016579.2789.17.camel@HansenPartnership.com> >> On Jan 8, 2019, at 10:49 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: >> >> On Tue, 2019-01-08 at 17:43 -0800, Andy Lutomirski wrote: >> [Adding Jarkko because this stuff relates to the TPM.] > >> Anyway, if we're talking about the TPM, it seems like the entire >> "trusted key" mechanism in the kernel is missing the point. If I >> want to encrypt something like a hibernation image on a machine with >> a TPM, it makes essentially no sense to me that we would get a key >> with a known raw value that is merely TPM-backed (i.e. the "trusted >> key") and use that to decrypt the image. The right way to do it is >> to the use the TPM as it was intended to be used: generate a single- >> use key that protects the hibernation image and seal *that* directly >> on the TPM, such that it can only be unsealed with appropriate PCR >> values. Heck, we could even use one of the fancy NV counters such >> that we *can't* decrypt the image later on. And using HMAC or any AE >> construction the normal way is also wrong -- we should *hash* the >> image and sign the hash directly on the TPM so that the restore code >> can validate the PCR values that were in place when the hibernation >> image was created. [0] > > Well, theoretically, trusted keys can be used for PCR sealed bundles, > at least in 1.2 ... I'm not sure the 2.0 one actually works because you > have to construct the policy session outside the kernel. I suppose I should go read the 2.0 spec. I’ve read the 1.2 spec, but I always assumed that 2.0 was essentially a superset of 1.2 functionality. >> Presumably we should at least try to replay the PCR operations that >> have occurred so that we can massage the PCRs into the same state >> post-hibernation. Also, do we have any way for the kernel to sign >> something with the TPM along with an attestation that the signature >> was requested *by the kernel*? Something like a sub-hierarchy of >> keys that the kernel explicitly prevents userspace from accessing?) > > We're just growing that now with the TPM asymmetric operations. > Attesting that the kernel requested the signature is harder. The TPM > can attest to log entries (as it does for the UEFI log and IMA) and it > can certify keys, but that only proves they're TPM resident not who the > requestor was. Effectively the latter is an assertion about who knows > the key authority, which is hard to prove. Can the kernel filter TPM 2.0 operations? If so, then a signature that the kernel would have prevented user code from generating is de facto an attestation that the kernel generated it (or that the kernel was compromised, which is sort of equivalent). > >> [0] If you take some data, run it through an authenticated encryption >> algorithm, and sign (key, nonce, tag), I think you're operating >> outside of the accepted security definitions if you expect this to >> guarantee that the data wasn't tampered with. I'm reasonably >> confident that there are quite a few excellent AE algorithms that >> completely fail if used this like this. In fact, pretty much all of >> the modern fast ones probably fail. AE is for when the key is >> *secret*. > > Well, I think here, if we were actually trying to solve the problem of > proving the hibernated image were the same one we would need to prove > some log of the kernel operation came to a particular value *after* the > hibernated image were restored ... it's not really possible to > condition key release which must occur before the restore on that > outcome, so it strikes me we need more than a simple release bound to > PCR values. I’m not sure I follow. Here are the two properties I’d like to see: 1. If you have an encrypted hibernation image, the only thing you should be able to do with it is to restore it. So only an actual Linux kernel in hibernation restore mode ought to be able to restore it. We get this if the image can only be read with appropriate PCRs and then only by the kernel. This way, you can’t just read out secrets from the image if you steal a laptop — you have to actually boot the thing. 2. You shouldn’t be able to create an intentionally corrupt image that pwns you when you restore it unless you have already pwned the kernel. Maybe the “kernel” bit in #1 can be relaxed to “root” without totally defeating the purpose, but if some random non-root process that happens to have access to /dev/tpm* can make a valid-looking TPM image, then I think we fail. Limiting it to the kernel is only dubiously better than limiting it to root until we implement lockdown, in which case it's important. #2 only really matters with lockdown. I suppose that a good summary of my opinion is that there is no point to kernel support for encrypted hibernation images until lockdown is upstream. --Andy
next prev parent reply other threads:[~2019-01-09 18:34 UTC|newest] Thread overview: 181+ 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 ` Lee, Chun-Yi 2019-01-03 14:32 ` [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-06 8:01 ` Stephan Mueller 2019-01-06 8:01 ` Stephan Mueller 2019-01-06 8:25 ` Stephan Mueller 2019-01-06 8:25 ` Stephan Mueller 2019-01-07 15:33 ` joeyli 2019-01-07 15:33 ` joeyli 2019-01-07 15:52 ` Stephan Mueller 2019-01-07 15:52 ` Stephan Mueller 2019-01-08 5:03 ` Herbert Xu 2019-01-08 5:03 ` Herbert Xu 2019-01-08 7:09 ` Stephan Mueller 2019-01-08 7:09 ` Stephan Mueller 2019-01-08 23:54 ` Andy Lutomirski 2019-01-08 23:54 ` Andy Lutomirski 2019-01-09 0:44 ` James Bottomley 2019-01-09 0:44 ` James Bottomley 2019-01-09 0:44 ` James Bottomley 2019-01-09 1:43 ` Andy Lutomirski 2019-01-09 1:43 ` Andy Lutomirski 2019-01-09 6:49 ` James Bottomley 2019-01-09 6:49 ` James Bottomley 2019-01-09 18:11 ` joeyli 2019-01-09 18:11 ` joeyli 2019-01-11 15:53 ` Jarkko Sakkinen 2019-01-11 15:53 ` Jarkko Sakkinen 2019-01-09 18:34 ` Andy Lutomirski [this message] 2019-01-09 18:34 ` Andy Lutomirski 2019-01-09 19:46 ` James Bottomley 2019-01-09 19:46 ` James Bottomley 2019-01-09 20:12 ` Andy Lutomirski 2019-01-09 20:12 ` Andy Lutomirski 2019-01-09 21:43 ` James Bottomley 2019-01-09 21:43 ` James Bottomley 2019-01-09 22:19 ` Pavel Machek 2019-01-09 22:19 ` Pavel Machek 2019-01-11 16:04 ` Jarkko Sakkinen 2019-01-11 16:04 ` Jarkko Sakkinen 2019-01-11 14:02 ` Jarkko Sakkinen 2019-01-11 14:02 ` Jarkko Sakkinen 2019-01-11 15:28 ` James Bottomley 2019-01-11 15:28 ` James Bottomley 2019-01-18 14:33 ` Jarkko Sakkinen 2019-01-18 14:33 ` Jarkko Sakkinen 2019-01-18 20:59 ` James Bottomley 2019-01-18 20:59 ` James Bottomley 2019-01-20 16:02 ` Jarkko Sakkinen 2019-01-20 16:02 ` Jarkko Sakkinen 2019-01-09 6:45 ` Stephan Mueller 2019-01-09 6:45 ` Stephan Mueller 2019-01-09 6:58 ` James Bottomley 2019-01-09 6:58 ` James Bottomley 2019-01-09 7:05 ` Stephan Mueller 2019-01-09 7:05 ` Stephan Mueller 2019-01-09 8:21 ` Eric Biggers 2019-01-09 8:21 ` Eric Biggers 2019-01-09 10:17 ` Stephan Mueller 2019-01-09 10:17 ` Stephan Mueller 2019-01-09 17:34 ` Eric Biggers 2019-01-09 17:34 ` Eric Biggers 2019-01-09 18:18 ` Stephan Mueller 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:08 ` Stephan Müller 2019-01-11 19:09 ` [PATCH 1/6] crypto: add template handling for RNGs Stephan Müller 2019-01-11 19:09 ` Stephan Müller 2019-01-11 19:10 ` [PATCH 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller 2019-01-11 19:10 ` Stephan Müller 2019-01-12 5:27 ` Eric Biggers 2019-01-12 5:27 ` Eric Biggers 2019-01-14 9:31 ` Stephan Müller 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-11 19:10 ` Stephan Müller 2019-01-12 5:26 ` Eric Biggers 2019-01-12 5:26 ` Eric Biggers 2019-01-14 9:26 ` Stephan Müller 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-11 19:10 ` Stephan Müller 2019-01-12 5:12 ` Eric Biggers 2019-01-12 5:12 ` Eric Biggers 2019-01-12 9:55 ` Herbert Xu 2019-01-12 9:55 ` Herbert Xu 2019-01-13 7:56 ` Stephan Müller 2019-01-13 7:56 ` Stephan Müller 2019-01-13 16:52 ` James Bottomley 2019-01-13 16:52 ` James Bottomley 2019-01-14 9:30 ` Stephan Müller 2019-01-14 9:30 ` Stephan Müller 2019-01-14 17:53 ` Eric Biggers 2019-01-14 17:53 ` Eric Biggers 2019-01-14 18:44 ` Stephan Mueller 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-11 19:10 ` Stephan Müller 2019-01-12 5:19 ` Eric Biggers 2019-01-12 5:19 ` Eric Biggers 2019-01-14 9:25 ` Stephan Müller 2019-01-14 9:25 ` Stephan Müller 2019-01-14 17:44 ` Eric Biggers 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-11 19:11 ` Stephan Müller 2019-01-16 11:06 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Müller 2019-01-16 11:06 ` 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:07 ` 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 ` 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 ` 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:08 ` 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 ` Stephan Müller 2019-01-16 11:09 ` [PATCH v2 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller 2019-01-16 11:09 ` Stephan Müller 2019-01-28 10:07 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Mueller 2019-01-28 10:07 ` Stephan Mueller 2019-01-30 10:08 ` Herbert Xu 2019-01-30 10:08 ` Herbert Xu 2019-01-30 14:39 ` Stephan Mueller 2019-01-30 14:39 ` Stephan Mueller 2019-02-08 7:45 ` Herbert Xu 2019-02-08 7:45 ` Herbert Xu 2019-02-08 8:00 ` Stephan Mueller 2019-02-08 8:00 ` Stephan Mueller 2019-02-08 8:05 ` Herbert Xu 2019-02-08 8:05 ` Herbert Xu 2019-02-08 8:17 ` Stephan Mueller 2019-02-08 8:17 ` Stephan Mueller 2019-02-19 5:44 ` Herbert Xu 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 15:34 ` James Bottomley 2019-01-09 6:27 ` Stephan Mueller 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-03 14:32 ` Lee, Chun-Yi 2019-01-06 8:09 ` Stephan Mueller 2019-01-06 8:09 ` Stephan Mueller 2019-01-07 18:58 ` Dan Carpenter 2019-01-07 18:58 ` Dan Carpenter 2019-01-03 14:32 ` [PATCH 3/5] PM / hibernate: Encrypt " Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-06 8:23 ` Stephan Mueller 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 ` 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-03 14:32 ` Lee, Chun-Yi 2019-01-06 18:10 ` [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image Pavel Machek 2019-01-06 18:10 ` Pavel Machek 2019-01-07 17:37 ` joeyli 2019-01-07 17:37 ` joeyli 2019-01-07 18:07 ` Pavel Machek 2019-01-07 18:07 ` Pavel Machek 2019-01-08 21:41 ` Andy Lutomirski 2019-01-08 21:41 ` Andy Lutomirski 2019-01-08 23:42 ` Pavel Machek 2019-01-08 23:42 ` Pavel Machek 2019-01-09 16:39 ` joeyli 2019-01-09 16:39 ` joeyli 2019-01-09 16:47 ` Stephan Mueller 2019-01-09 16:47 ` Stephan Mueller 2019-01-11 14:29 ` joeyli 2019-01-11 14:29 ` joeyli 2019-01-09 16:51 ` joeyli 2019-01-09 16:51 ` joeyli 2019-01-09 18:47 ` Andy Lutomirski 2019-01-09 18:47 ` Andy Lutomirski 2019-01-10 15:12 ` joeyli 2019-01-10 15:12 ` joeyli 2019-01-11 1:09 ` Andy Lutomirski 2019-01-11 1:09 ` Andy Lutomirski 2019-01-11 14:59 ` joeyli 2019-01-11 14:59 ` joeyli
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=CALCETrWoSAf4hHCXvqVZhQ5YAMBaZzaBCfnb6sC8JPrSs6FRog@mail.gmail.com \ --to=luto@kernel.org \ --cc=James.Bottomley@hansenpartnership.com \ --cc=dhowells@redhat.com \ --cc=ggherdovich@suse.cz \ --cc=herbert@gondor.apana.org.au \ --cc=jannh@google.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=joeyli.kernel@gmail.com \ --cc=keyrings@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.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=smueller@chronox.de \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.