Multiple ways to unlock encrypted root (was: [PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon)

[Wiktor Kwapisiewicz]

Hi Peter,

This definitely helps!

I've already got GnuPG smartcard LUKS decryption working using this 
project [0]. It looks and works very well.

And I've noticed LUKS slots, the LUKS TPM project [1] requires specific 
slots but the GnuPG LUKS [0] does not so it may really easy to setup 
both of them (for a specific definition of "easy" ;).

One way or another your idea, scripts and configs will be handy along 
the way.

Thanks for taking your time to describe your setup!

Kind regards,
Wiktor

[0]: https://github.com/fuhry/initramfs-scencrypt

[1]: https://github.com/electrickite/luks-tpm

> On 31/07/18 21:15, Wiktor Kwapisiewicz via Gnupg-devel wrote:
>> ...I'd be very happy if I could have the same key wrapped by TPM and on
>> a smartcard (for recovery purposes).
> 
> I once wrote a little thing to do that on Debian[1], and it was
> ported[2] to Debian stretch by Erik Nellessen. That solution used LUKS,
> and LUKS has multiple keyslots. You could have a keyscript that unlocked
> using TPM, and another keyscript that unlocked using OpenPGP smartcard,
> each using a different keyslot if desired. You could create a boot
> loader entry that overrides the keyscript (see below).
> 
> But you don't even need the multiple keyslots that LUKS offers. That's
> for multiple passphrases. But if you regard the passphrase as just a
> random key encryption key, you could have the TPM unwrap and OpenPGP
> decrypt just produce the same random key that is used as key encryption
> key, or directly as disk encryption key if you want that. So, as long as
> you use the TPM, you're not using OpenPGP, and when you use your OpenPGP
> smartcard, you're not using the TPM at all. They just produce the same
> value.
> 
> BTW, overriding a keyscript is distribution-specific, but on Debian:
> 
> $ mkdir tmp
> $ cd tmp
> $ zcat /boot/initrd.img-4.9.0-7-amd64 | cpio -i
> $ cd conf/conf.d
> $ cat cryptroot
> target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,rootdev,lvm=terrence--hg6-root,discard,key=none
> target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,lvm=terrence--hg6-usr,discard,key=none
> target=tosh-hg6_crypt,source=UUID=0b3a0f85-0ba5-426b-a116-0967b9f255e8,resumedev,lvm=terrence--hg6-swap,discard,key=none
> 
> My laptop, which uses full disk encryption with LUKS and a regular
> passphrase, has these three entries for unlocking the volumes necessary
> (root fs, /usr, resume partition). But if you supply the options on the
> kernel command line, these entries from conf/conf.d/cryptroot are not
> used; your specified options, and only those, are used. You'll get a
> really long kernel command line. For each line in conf/conf.d/cryptroot,
> supply one kernel argument "cryptopts=<line>" with options adapted to
> your liking, and those are the options that will be used. Example:
> 
> cryptopts=target=mx500_crypt,source=UUID=0de2d0b5-30f2-4308-8141-763a29fe8029,rootdev,lvm=terrence--hg6-root,discard,key=none
> 
> I've specified a different LUKS partition to decrypt, but kept the rest
> the same. If I only specify this one, my /usr and resume partition will
> not be unlocked since command-line cryptopts cause the config file to be
> ignored entirely.
> 
> It's clearly no fun to enter these values by hand; you could configure
> your boot loader to automatically produce a boot entry which has them
> with the appropriate options, or even extend the initramfs scripts to
> gracefully handle multiple alternative configs, or write your own
> keyscript that can fall  back to the smartcard when it notices the TPM
> method is unsuccesful. The latter is probably the cleanest, and doesn't
> actually need anything from the above :-). Still, it's very useful to
> know when fiddling with custom encrypted roots, or even when swapping
> drives, as per the example.
> 
> HTH,
> 
> Peter.
> 

-- 
https://metacode.biz/@wiktor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180801/121ba4c3/attachment-0001.sig>