linux-kernel - Re: [RFC PATCH 0/2] TPM derived keys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 14 May 2024 15:41:50 +0100
From: Ignat Korchagin <ignat@...udflare.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>, 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 3:00 PM Jarkko Sakkinen <jarkko@...nel.org> 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 connected
> > 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.

> >   * if someone steals one of the disks - we don't want them to see it
> > has encrypted data (no LUKS header)
>
> So what happens when you reconnect?

We recover/derive the encryption key and unlock the disk again.

> > Additionally we may want to SSH into the NAS for configuration and we
> > don't want the SSH server key to change after each boot (regardless if
> > disks are connected or not).
>
> Right, interesting use case. Begin before any technical jargon exactly
> with a great example like this. Then it is easier to start to anchoring
> stuff and not be misleaded.
>
> BR, Jarkko