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

[Claudius Heine]

Hi Mikko,

On Tue Jun 17, 2025 at 11:56 AM CEST, Mikko Rapeli wrote:
> 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.

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.

kind regards,
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