Re: dm-integrity volume with TPM key?

[Sebastian Wiesner <sebastian@xxxxxxxx>]

Hello,

thanks for quick reply, I guess this explains the lack of instructions
^^

As a workaround you'd use a regular file key for dm-integrity and put
that on a TPM-protected partition, if I understand you correctly?

I.e. you'd

1. enable secureboot (custom keys or shim),
2. bundle kernel & initrd into signed UEFI image for systemd-boot,
3. make / a LUKS-encrypted parition with systemd-cryptenroll, bound to
the TPM (perhaps PCR 0 and 7) aund unlocked automatically at boot,
4. make /home a dm-integrity partition, with a regular keyfile from
e.g. /etc/integrity.key (which is on the encrypted partition), and
5. use homed for LUKS-encrypted home areas on /home?

Does this sound reasonable?  

That's actually not too hard to setup on Arch :)

Cheers,
Basti

Am Donnerstag, dem 30.09.2021 um 10:15 +0200 schrieb Lennart
Poettering:
> On Mi, 29.09.21 21:53, Sebastian Wiesner (sebastian@xxxxxxxx) wrote:
> 
> > Hello,
> > 
> > "Authenticated Boot and Disk Encryption on Linux" [1] suggests to
> > "make
> > /home/ its own dm-integrity volume with a HMAC, keyed by the TPM"
> > when
> > using systemd-homed for user home directories.
> > 
> > I'd like to try that but… how? I can use systemd-cryptenroll to
> > make a
> > encrypted volume with a TPM key, but how do I make a dm-integrity
> > volume with a TPM key?  I've gone through the manpage for
> > integritysetup and did a few unsuccessful google searches, but I've
> > not
> > found any answer.
> 
> It's not easy to find, because it doesn't exist. ;-)
> 
> We have the TPM stuff in place, and we cover both cryptsetup +
> veritysetup pretty nicely. We are still missing the final glue here
> though. systemd-integritysetup + /etc/integritytab. The hard plumbing
> problems are all solved, what's missing is just putting together the
> porcelain for it.
> 
> I had hope that libcryptsetup would support a mode where we can use a
> LUKS2 superblock with only dm-integrity without dm-crypt (which would
> give us proper key management for this thing). But the idea is not
> attractive to the libcryptsetup people unfortunately, as it turns
> out.
> 
> My current thinking how I'd personally deploy this is actually not
> necessarily by directly enrolling the HMAC key for dm-integrity with
> the TPM, but instead just piggyback things to an otherwise protected
> /etc/ or /var/. i.e. define a key file /etc/integrity.key (with a
> fallback to /var/lib/integrity.key) or similar, that is used as
> implicit HMAC key for all dm-integrity needs. Then, because (at least
> in my idealized view) /etc or /var are authenticated territory (bound
> to TPM) we get the property we want, indirectly.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin