From: Ignat Korchagin <ignat@cloudflare.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
serge@hallyn.com, linux-integrity@vger.kernel.org,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@cloudflare.com
Subject: Re: [RFC PATCH 0/2] TPM derived keys
Date: Tue, 14 May 2024 17:01:03 +0100 [thread overview]
Message-ID: <CALrw=nFABteNOAOpvaGOMrpUOMW1LMJfRB5EXxs_dPH70G_LGQ@mail.gmail.com> (raw)
In-Reply-To: <c8b98d9fc2ac4062d6c010551244da184af1244d.camel@HansenPartnership.com>
On Tue, May 14, 2024 at 4:54 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2024-05-14 at 16:38 +0100, Ignat Korchagin wrote:
> > On Tue, May 14, 2024 at 4:30 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > >
> > > On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
> > > > * if someone steals one of the disks - we don't want them to
> > > > see it has encrypted data (no LUKS header)
> > >
> > > What is the use case that makes this important? In usual operation
> > > over the network, the fact that we're setting up encryption is
> > > easily identifiable to any packet sniffer (DHE key exchanges are
> > > fairly easy to fingerprint), but security relies on the fact that
> > > even knowing that we're setting up encryption, the attacker can't
> > > gain access to it. The fact that we are setting up encryption
> > > isn't seen as a useful thing to conceal, so why is it important for
> > > your encrypted disk use case?
> >
> > In some "jurisdictions" authorities can demand that you decrypt the
> > data for them for "reasons". On the other hand if they can't prove
> > there is a ciphertext in the first place - it makes their case
> > harder.
>
> Well, this isn't necessarily a good assumption: the way to detect an
> encrypted disk is to look at the entropy of the device blocks. If the
> disk is encrypted, the entropy will be pretty much maximal unlike every
> other use case. The other thing is that if the authorities have your
What if the disk is filled with random data? Would it not be at maximal entropy?
> TPM, they already have access to the disk in this derived key scenario.
I'm thinking more of a datacenter scenario here - it is much easier to
"steal" a disk rather than a server from a datacenter. So it is
possible that someone has the disk but no access to the TPM.
> If *you* still have access to your TPM, you can update the storage seed
> to shred the data.
The point here is not if I was able to shred the data or not, but the
fact I have something encrypted. Even if I shred the key I would be
considered "uncooperative and refusing to provide the key" vs "I don't
have anything encrypted in the first place".
> James
>
prev parent reply other threads:[~2024-05-14 16:01 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 22:16 [RFC PATCH 0/2] TPM derived keys Ignat Korchagin
2024-05-03 22:16 ` [RFC PATCH 1/2] tpm: add some algorithm and constant definitions from the TPM spec Ignat Korchagin
2024-05-14 22:51 ` Jarkko Sakkinen
2024-05-14 22:52 ` Jarkko Sakkinen
2024-05-03 22:16 ` [RFC PATCH 2/2] KEYS: implement derived keys Ignat Korchagin
2024-05-14 23:10 ` Jarkko Sakkinen
2024-05-14 23:44 ` Jarkko Sakkinen
2024-05-15 0:00 ` Jarkko Sakkinen
2024-05-15 6:44 ` Ignat Korchagin
2024-05-15 12:00 ` Jarkko Sakkinen
2024-05-15 12:03 ` Jarkko Sakkinen
2024-05-15 7:26 ` Ignat Korchagin
2024-05-04 0:21 ` [RFC PATCH 0/2] TPM " Jarkko Sakkinen
2024-05-04 13:55 ` Ben Boeckel
2024-05-04 14:51 ` Jarkko Sakkinen
2024-05-04 15:35 ` Jarkko Sakkinen
2024-05-13 17:09 ` Ignat Korchagin
2024-05-13 22:33 ` James Bottomley
2024-05-14 9:50 ` Ignat Korchagin
2024-05-14 14:11 ` James Bottomley
2024-05-14 14:54 ` Ignat Korchagin
2024-05-13 17:11 ` Ignat Korchagin
2024-05-14 0:28 ` Jarkko Sakkinen
2024-05-14 10:05 ` Ignat Korchagin
2024-05-14 12:09 ` Jarkko Sakkinen
2024-05-14 13:11 ` Ignat Korchagin
2024-05-14 14:00 ` Jarkko Sakkinen
2024-05-14 14:30 ` Jarkko Sakkinen
2024-05-14 15:21 ` Jarkko Sakkinen
2024-05-14 15:26 ` Jarkko Sakkinen
2024-05-14 15:30 ` Ignat Korchagin
2024-05-14 15:42 ` Jarkko Sakkinen
2024-05-14 16:08 ` Ignat Korchagin
2024-05-14 16:22 ` Jarkko Sakkinen
2024-05-14 14:41 ` Ignat Korchagin
2024-05-14 14:45 ` Jarkko Sakkinen
2024-05-14 15:30 ` James Bottomley
2024-05-14 15:38 ` Ignat Korchagin
2024-05-14 15:54 ` James Bottomley
2024-05-14 16:01 ` Ignat Korchagin [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='CALrw=nFABteNOAOpvaGOMrpUOMW1LMJfRB5EXxs_dPH70G_LGQ@mail.gmail.com' \
--to=ignat@cloudflare.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=kernel-team@cloudflare.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.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 read-only IMAP folder(s) and NNTP newsgroup(s).