Hacker News Reader

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?

View on HN

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