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

Peter Lebbing peter at digitalbrains.com
Wed Aug 1 11:56:39 CEST 2018


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.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-pete

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


More information about the Gnupg-devel mailing list