Received-SPF: pass (google.com: domain of linux-kernel+bounces-178823-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 14 May 2024 17:45:49 +0300
Message-Id: <D19G5WTFSJ40.1D0KEUQO6Q8AT@kernel.org>
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Ignat Korchagin" <ignat@cloudflare.com>
Cc: "James Bottomley" <James.Bottomley@hansenpartnership.com>, "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
References: <20240503221634.44274-1-ignat@cloudflare.com>
 <CALrw=nGhgRrhJ5mWWC6sV2WYWoijvD9WgFzMfOe6mHmqnza-Hw@mail.gmail.com>
 <D18XXJ373C2V.2M6AOMKD1B89W@kernel.org>
 <CALrw=nHGLN=dn3fbyAcXsBufw0tAWUT1PKVHDK5RZkHcdd3CUw@mail.gmail.com>
 <D19CUF0H9Q3S.3L5Y5S9553S5@kernel.org>
 <CALrw=nEZ07U9VhbGsnpchOYw1icUZCnuoHHXkJLzhFqSPe9_fQ@mail.gmail.com>
 <D19F74M6B8UC.2VEOOZHGOS87V@kernel.org>
 <CALrw=nE_sV=1DnCx1eM8Sgno-di0yCaWHX467ZEf1Fddwg7_rA@mail.gmail.com>
In-Reply-To: <CALrw=nE_sV=1DnCx1eM8Sgno-di0yCaWHX467ZEf1Fddwg7_rA@mail.gmail.com>

On Tue May 14, 2024 at 5:41 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 3:00=E2=80=AFPM Jarkko Sakkinen <jarkko@kernel.or=
g> wrote:
> >
> > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > For example, a cheap NAS box with no internal storage (disks connecte=
d
> > > externally via USB). We want:
> > >   * disks to be encrypted and decryptable only by this NAS box
> >
> > So how this differs from LUKS2 style, which also systemd supports where
> > the encryption key is anchored to PCR's? If I took hard drive out of my
> > Linux box, I could not decrypt it in another machine because of this.
>
> It differs with the fact that the disk has a clearly identifiable
> LUKS2 header, which tells an adversary that this is a disk with some
> data that is encrypted. With derived keys and plain dm-crypt mode
> there is no LUKS header, so it is not possible to tell if it is an
> encrypted disk or a disk with just random data. Additionally, if I
> accidentally wipe the sector with the LUKS2 header - all my data is
> lost (because the data encryption key from the header is lost). With
> derived keys I can always decrypt at least some data, if the disk is
> available.

I figured most of this out myself and sent a follow-up but yeah thnaks
for confirming my toughts. I get this part now.

Follow-ups to my follow-up...

BR, Jarkko