Hacker News Reader

Comment by jeroenhd | Hacker News Reader

This reads like "the full TPM spec is too complicated for my use case, so I made my own TPM for my personal use case". That's not fixing TPM, that's inventing your own, custom TPM, that only works for a subset of the intended audience of the thing you're replacing.

It's like replacing all private cars by bikes and public transit. This solves the pollution problem, the traffic casualties program, and would solve transportation for the vast majority of people traveling on the road. It doesn't solve some niche use cases, like "trucks" or "construction work", but those are just bloat almost nobody needs in the first place, right?

From this description, Tillitis sure seems like a good alternative for TPMs. However, there's no Tillitis chip in my laptop or my desktop, but I do have a TPM. Things like SSH and PGP are already implemented. Tillitis isn't very interesting to me in its current state as advertised in this article.

View on HN

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.

What 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?

Could 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.

It'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.

Reply on news.ycombinator.com