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

[Claudius Heine]

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.

Cheers,
Claudius

-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de