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

[Mikko Rapeli]

Hi,

On Tue, Jun 17, 2025 at 01:37:19PM +0200, Claudius Heine wrote:
> On Tue Jun 17, 2025 at 11:56 AM CEST, Mikko Rapeli wrote:
> > 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.
> 
> My issue was about encrypted partitions, of course they are just one
> part of the bigger secure boot process, that might, or might not use
> dm-verity, or other mechanism. In some projects the rootfs is read-only,
> is some they aren't. It all depends on other project requirements.
> 
> So whereever or not dm-verity is used, shouldn't matter in regards to
> the (re-)encryption process. Because encryption solves a different issue
> than a verification layer.
> 
> Keep in mind that with A/B system, there also often is a shared
> writeable data partition, that might need to be re-encrypted, if it
> contains important information, instead of overwriting it with an empty
> encrypted partition.

Well, re-encryption may not be needed unless the TPM device is changed, which
is basically never. Data format migration on writable partition may be
needed but those details can be completely application specific.
Depending on TPM PCR policy, re-encryption may not be needed at all.
Attestation may be needed, or re-attestation at every boot but that may
also be outside the A/B update or writable per-device encrypted
storage scope.

With dm-verity and secure boot covering kernel and initrd (like UKI),
those binaries can be shared across all devices and the device specific
encrypted storage can be then tied to the TPM in each device. There is no
need for re-encryption also with A/B updates. Even the A/B update
selection becomes simpler with dm-verity since root hash is the binding element
and it can exist anywhere as long as kernel or initrd have drivers to find it.

Preparing devices in production reduces to setting up secure boot keys
with HW and firmware, and then booting once per device with the
production block devices containing dm-verity partition and space
for the writable TPM backed storage.

But I guess you know all these details already :)

Cheers,

-Mikko