[PATCH tpm-work 0/3] move the tpm-work branch to an assuan based tpm handling daemon

[Wiktor Kwapisiewicz]

Hi James,

> OK, so there's a problem here: disk encryption has to be done with a
> symmetric key because asymmetric operations are too slow.  The TPM can
> do symmetric key operations, but certainly not fast enough for bulk
> data, so the only viable mechanism for disk encryption is for something
> to release the symmetric key to a software encrypt/decrypt system.  In
> the LUKS model (and the TPM trusted keys model in the kernel), the TPM
> does this by a data unseal operation which can be linked to PCRs.
> 
> Gnupg does have a sort of equivalent in the way it encrypts and
> decrypts messages: it generates a temporary symmetric key and wraps
> that symmetric key with the recipient public keys but to preserve
> forward secrecy, the symmetric key is different for every message.  So
> while one could imagine using the gnupg wrapping mechanism for key
> unsealing it's a bit of a stretch use case.

Agreed, in my setup that I'm... setting up, I'll be using GnuPG to 
decrypt the keyfile (that's on an unencrypted disk or initramfs) using 
OpenPGP smartcard. All of this will happen very early in the boot 
process, that requires some GnuPG binaries to be available by then.

The idea is not new and there are already projects that implement that:

https://github.com/xdbob/mkinitcpio-gpg-encrypt#configuration-process

The TPM could give me additional advantage of knowing the system state 
did not change and although there are projects for that too...

https://github.com/electrickite/luks-tpm

...I'd be very happy if I could have the same key wrapped by TPM and on 
a smartcard (for recovery purposes).

But that's another issue. TPM keys, as an alternative for 
always-connected smartcard, are very useful on their own in my opinion.

Kind regards,
Wiktor

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