4 ms·

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 up

by wepple 3y ago

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

wepple 3y ago
I guess as a follow-up, you possibly can’t actually “update” firmware for this, without it creating entirely new keys that would have to be registered with every application
- kfreds 3y ago
  You're mostly correct. The immutable firmware derives unique key material for each device+application combination. However, nothing prevents the loaded application from loading another application. This allows the developer to construct their own update logic. For instance, the first application could simply exist to verify a digital signature over some hash, then load an application, hash it, compare it to the trusted hash, and then execute it. The first application could hand over its own key material.
kfreds 3y ago
Sure. Specifically regarding not storing firmware: The TKey does have roughly 6 KB of immutable firmware which is responsible for loading device applications sent by the host. This firmware receives and then hashes the application together with the Unique per Device Secret. The resulting hash is handed to the loaded application as key material, which is now unique per device+application combination. This model doesn't prevent storing applications on the device, but to enable the user to have flexibility to load other apps we would need to change things a bit. 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.
lxgr 3y ago
If you think about it, no secure computing device of this form factor usually stores its own firmware: 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.
- kfreds 3y ago
  If you really want to get into the details, effectively all modern CPU chips does have some firmware in ROM on-die. (I'm sure you know this but I'm writing it out here for the benefit of others) 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.

by wepple 3y ago

wepple 3y ago

I guess as a follow-up, you possibly can’t actually “update” firmware for this, without it creating entirely new keys that would have to be registered with every application

kfreds 3y ago
You're mostly correct. The immutable firmware derives unique key material for each device+application combination. However, nothing prevents the loaded application from loading another application. This allows the developer to construct their own update logic. For instance, the first application could simply exist to verify a digital signature over some hash, then load an application, hash it, compare it to the trusted hash, and then execute it. The first application could hand over its own key material.

kfreds 3y ago

Sure. Specifically regarding not storing firmware: The TKey does have roughly 6 KB of immutable firmware which is responsible for loading device applications sent by the host. This firmware receives and then hashes the application together with the Unique per Device Secret. The resulting hash is handed to the loaded application as key material, which is now unique per device+application combination. This model doesn't prevent storing applications on the device, but to enable the user to have flexibility to load other apps we would need to change things a bit. 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.

lxgr 3y ago

If you think about it, no secure computing device of this form factor usually stores its own firmware: 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.

kfreds 3y ago
If you really want to get into the details, effectively all modern CPU chips does have some firmware in ROM on-die. (I'm sure you know this but I'm writing it out here for the benefit of others) 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.