On Tue, May 14, 2024 at 3:00 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx> 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
