3 ms·
Author here. Did you miss the part where users can load arbitrary programs into the "new custom TPM"? If we can do that, solving all use cases for all users is
by loup-vaillant 3y ago
Author here. Did you miss the part where users can load arbitrary programs into the "new custom TPM"? If we can do that, solving all use cases for all users is very easy: just write the appropriate program whenever a new use case pops up. This is not supporting a subset of current users, this is supporting all users. Every last one of them.
Believe me, given the current complexity of the TPM 2.0 interface, writing a custom program for any single use case is not any harder than wading through the current TPM documentation. Given suitable crypto libraries I'm guessing it's quite a bit easier in most cases.
> However, there's no Tillitis chip in my laptop or my desktop
Yeah, that's the thing with new approaches: they're new. Now if someone made an HSM with the same pinout as a discrete TPM, with a DICE-aware approach under the hood, you could plug it on your motherboard today.
- Corsome 3y agoWhat if the firmware program has a bug that needs to be fixed? Fixing it would change the hash and thus lock it out from key access but leaving it unchanged will mean the keys can be compromised. How does Tillitis handle this case?
- A1kmm 3y agoCould you not have a tiny certified kernel program with an embedded public key that reads the main program, hashes it, checks the signature, and executes it (providing the keys to the main program). Obviously, if you change the kernel program, you would change the keys, but you could change the main program. Anyone with the private key then has the power... they could migrate by running a new kernel (while the TKey is under their physical control) and generate a keypair (deterministically from the new secret key) and export the public key. Then the controller of the private key could sign a program to run under the old kernel that will encrypt that old key with the new public key.
- loup-vaillant 3y agoIt's tedious, but simple: revoke the old key, rotate to the new one. If you need the old key to revoke it (say you encrypted a disk, or you have wrapped credentials you need to unwrap first), then use the old buggy firmware to do the necessary decryption, then encrypt again with the new one. Writing the migration program that loads the two pieces of firmware (the old, then the new) to the dongle however is a pain in the butt. Especially if you can't restart the device without physically plugging it out and back in again.