[systemd-devel] [Question] Create and (re)encrypt LUKS partition directly with hw token

[Mikko Rapeli]

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 (ch at 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