Hi, On Tue, Jun 17, 2025 at 11:32:37AM +0200, Claudius Heine wrote: > On Tue Jun 17, 2025 at 10:54 AM CEST, Lennart Poettering wrote: > > On Di, 17.06.25 10:33, Claudius Heine (c...@denx.de) wrote: > >> > systemd-repart seems to be what you are looking for. It can > >> > create partitions at boot them, set up LUKS for them, lock them to TPM > >> > and put a file system inside. It's really the tool of choice if you > >> > want to augment disk images at first boot wit local keys that never > >> > leave the host. > >> > > >> > if you let systemd-repart do its thing you never have to enroll any > >> > intermediary key or deal with volume keys or so, repart deals with > >> > that and locks immediately and only to TPM. > >> > >> Thanks for the hint. I used systemd-repart before, but didn't connect it > >> with the cryptsetup requirements. > >> > >> Hmm... There is an RFC for letting systemd-repart support reencryption > >> of existing LUKS partitions [1]. So I guess that isn't quite there yet, > >> right? > > > > We do not support reencryption, because in my PoV that's a hack and > > unnecessary? Usually there are better ways to put together your > > image. Others disagree, but at least from my perspective it's > > something to avoid, a waste of resources. > > > > But I don't get it? you are saying you want reencryption but you also > > want to start out with only being tpm-locked, without any other keys? > > how are these two requirements compatible? if you do reencryption you > > usually start out with a vendor key, which you replace with a local > > key. But a vendor key is definitely not a tpm key, so so how can you > > "start out" with a tpm key then? This doesn't compile in my head? > > Well... Maybe there is a misunderstanding here. This is the general > use-case is about initial provisioning of a embedded device (preferably > in factory, there are some asterisks to that) > > Here is the general process: > > 1. A generic unencrypted image is produced and written onto a flash card. > (system contains A/B partition sets for image based updating) > 2. Flash card is inserted into a device, device starts up > 3. Initramfs is booted, which contains scripting to detect if the system > is encrypted or not, and what to do next, based on some dynamic and > static information. > If the scripting decides that the conditions are right, reencrypt > the root partition(s), and, if configured, create additional encrypted > data partitions. > (Depending on the conditions, it might also continue any aborted > encryption or even boot the unencrypted system.) > > Currently the encryption process of step (3) is done like this: > - Create a random password > - Store password in TPM2 > - Use password to start (re)encryption process > - If process is aborted here, continue with reencryption on next boot > using the password from the TPM2 > - If encryption has finished, use systemd-cryptenroll to create and > enroll TPM2 token. > - Delete password from luks slot and TPM2 > > Some of this stuff is messy, but there are also messy requirements that > lead to them. For instance a device needed to add encryption in field > via an update (previous bios version didn't support TPM2, and now they > do). And to provide fallback-compatibility, an intermediate version > needs to support booting from encrypted partitions, while not encrypting > any partition itself. > > In a 'more optimal' factory setting, it would have been better to not > bother with reencryption and just write scripts (or use systemd-repart) > that create a new encrypted partition and write an image to it, but alas > this isn't always possible or desired. Sometimes it is difficult to > control the factory provisioning process. > > I hope this clears it up.
Why not dm-verity protection for the read-only (?) rootfs? Then a writable partition based on TPM encryption setup at first boot with the initramfs, which can be systemd based and thus setup is a few config lines to systemd-repart. Then secure boot to protect the kernel, kernel command line with dm-verity hash and initrd with keys tied to HW and firmware. Cheers, -Mikko
