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