Can anyone comment on the design decision to not store device firmware? Is this common?
I would’ve assumed it would generally be safer to have permanent but updatable firmware, to reduce the attack surface of malicious firmware loadings
I would’ve assumed it would generally be safer to have permanent but updatable firmware, to reduce the attack surface of malicious firmware loadings
Regarding security: This is a question of measured vs verified boot. Until the TKey, users of USB authenticators had to choose between security and flexibility. Yubikey is not updatable at all, but several USB authenticators have updatable firmware using signed firmware updates. Some of them are open source software, and of those a few are open source hardware in the sense that they provide BOM, schematics and PCB design. We do all of the above, and in addition we provide the HDL / "chip design" / FPGA configuration. In any case, having a USB authenticator which is updatable using a signed update begs the question of who is allowed to sign updates, which then leads to central control and a long tail of interesting use cases not being signed. TKey aims to combine security, openness and flexibility. We accomplish this thanks to unconditional measured boot as a KDF, as opposed to verified boot.
There is more information on our website.
Apple's Secure Enclave and (I believe) Google's Titan security coprocessors both load their firmware from untrusted flash and validate it on-chip against an embedded signing key.
Sometimes, they do have a very limited amount of on-chip storage, but that's usually only used to prevent rollbacks to older, potentially compromised firmware versions or implement rollback-proof PIN or biometric authentication; sometimes this is also solved by burning e-fuses.
As the name Read-Only Memory implies it is immutable, unchangeable. These are the first machine instructions executed by the CPU once it comes out of reset. It is the ultimate Core Root of Trust for Measurement and Verification.
In my opinion the industry should move away from embedding verified boot (digital signature verification) firmware in this ROM. What I would like to see instead is the ROM stage doing unconditional measured boot a la TKey / TCG DICE. The second (mutable) stage could be loaded from Flash, and include the preferred verified boot policy for verifying the third stage. This has several advantages:
* It reduces the software complexity of the immutable firmware on-die. This reduces the likelihood of vulnerabilities that can only be fixed by creating a new mask set.
* It reduces the size of the mask ROM.
* It causes the identity / attestation of the device to change if the second stage is modified, allowing some attacks to be detectable that are not detectable today.
* It allows the manufacturer and its customers more flexibility in upgrading the verified boot policy. Intel BootGuard is stuck on single RSA 2048 bits. Why not m-of-n signatures, or m-of-n Ed25519 with a transparency log requirement? As we've seen from several firmware vendors they don't seem to protect their signing keys very well. How many of them are compromised? Having transparency log verification very early in the boot process, and thereby making key compromise discoverable, would be fantastic. This type of experimentation / innovation / improvement, or post-quantum verified boot for that matter, is very unlikely to be placed in the mask ROM of an IC anytime soon. That's another reason to change to the TKey / TCG DICE approach.
* It allows more flexibility in deciding how to enforce owner control and how to do ownership transfer. Intel BootGuard blows fuses that represent a hash of the RSA key. The same can be done by the measured boot firmware in ROM, effectively making the second stage immutable as well. Some will want that, while others are satisfied with something equivalent to a fuse but reversible through physical access, allowing for easier ownership transfer.
Interesting, is it possible to perform attestation without an embedded signing or verification key that way as well? If so, how is it possible to tie an attestation statement to a vendor that way?
1. The ROM stage measures the first mutable application stage A1, and makes the Compound Device Identifier (CDI) available to A1. CDI=Hash(UDS, Hash(A1), USS).
2. A1 creates a key pair for itself using CDI.
3. A1 measures A2 and creates a key pair for A2.
4. A1 signs A2's public key. This is the attestation.
5. A1 scrubs CDI and its private key from memory while ensuring that the attestation as well as A2's key pair is available to A2. Note that the TKey only supports two-stage boot chains at the moment.
A1's key pair could also be signed by the vendor before shipping. We do it like this: https://github.com/tillitis/tkey-verification
Very interesting, I’ll have to wrap my head around the idea a bit more, but I think this also answered a couple of questions I had around PUFs.
Thank you, and good luck with the project, I’m always happy to see open projects in this space!