Making it easier to deploy TPMTOTP on non-EFI systems

[mjg59]

I've been working on TPMTOTP a little this weekend. I merged a pull request that adds command-line argument handling, which includes the ability to choose the set of PCRs you want to seal to without rebuilding the tools, and also lets you print the base32 encoding of the secret rather than the qr code so you can import it into a wider range of devices. More importantly it also adds support for setting the expected PCR values on the command line rather than reading them out of the TPM, so you can now re-seal the secret against new values before rebooting.

I also wrote some new code myself. TPMTOTP is designed to be usable in the initramfs, allowing you to validate system state before typing in your passphrase. Unfortunately the initramfs itself is one of the things that's measured. So, you end up with something of a chicken and egg problem - TPMTOTP needs access to the secret, and the obvious thing to do is to put the secret in the initramfs. But the secret is sealed against the hash of the initramfs, and so you can't generate the secret until after the initramfs. Modify the initramfs to insert the secret and you change the hash, so the secret is no longer released. Boo.

On EFI systems you can handle this by sticking the secret in an EFI variable (there's some special-casing in the code to deal with the additional metadata on the front of things you read out of efivarfs). But that's not terribly useful if you're not on an EFI system. Thankfully, there's a way around this. TPMs have a small quantity of nvram built into them, so we can stick the secret there. If you pass the -n argument to sealdata, that'll happen. The unseal apps will attempt to pull the secret out of nvram before falling back to looking for a file, so things should just magically work.

I think it's pretty feature complete now, other than TPM2 support? That's on my list.

Comments

Point?

[(Anonymous)]

I'm not sure I understand the point of verifying system state is.

It is really not going to know if your keyboard records the key
strokes as you type. Such an attack could have been deployed years
earlier, perhaps when you bought the keyboard (with the laptop it
is sitting in).

Re: Point?

[(Anonymous)]

Well if you are in the business of running any arbitrary user uploaded/controlled stuff you might wish to verify that said stuff didn't acciddentally/maliciously manage to escape your 'secure' sandbox and backdoor the host OS, quite possibly because the crap was so broken that 27 different botnets 1 crytolocker scam began to call your machine/VM/container 'home' within 5 hours of it booting up...

... And when it comes to that, once you are in that line of work then you start to wonder just how feasible the scenario is and just how many threats are actually credible. And once you start looking you see things you cannot unsee, and a certain measure of paranoia/depression/substance abuse is the natural expected end state -- which also primes you for this kind of programming work.

At which point you might as well try to make the world a slightly less terrible place for early boot security.

Copy the design of jar signing?

[(Anonymous)]

Instead of hashing the whole initramfs, you could hash the contents of the files. Add the hash as a file, then build it. Though that would make measuring the boot process itself more complex.