[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALrw=nFABteNOAOpvaGOMrpUOMW1LMJfRB5EXxs_dPH70G_LGQ@mail.gmail.com>
Date: Tue, 14 May 2024 17:01:03 +0100
From: Ignat Korchagin <ignat@...udflare.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, Mimi Zohar <zohar@...ux.ibm.com>,
David Howells <dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>,
James Morris <jmorris@...ei.org>, serge@...lyn.com, linux-integrity@...r.kernel.org,
keyrings@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-team@...udflare.com
Subject: Re: [RFC PATCH 0/2] TPM derived keys
On Tue, May 14, 2024 at 4:54 PM James Bottomley
<James.Bottomley@...senpartnership.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@...senpartnership.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
>
Powered by blists - more mailing lists