Hector Martin

ROCA was so obvious once the finger was pointed at the problem area that I had friends who reverse engineered it through key analysis and guessed at what the bad code was doing, before the official research paper was published.

This is an endemic problem in parts of the industry, where half-competent people are the ones doing the audits, while access is denied to those who could actually find problems quicker (but might not work for a big auditing firm).

Ok I got your point and I don't disagree. I just want to insist on the fact that the solution is more to try to open Secure chips, rather than using broken ones... Telling the opposite is a big fallacy, and I hope it's just a troll

Oh, I absolutely would *love* to have open secure ICs. But since that doesn't seem to be happening any time soon, you're left with a choice, and I'm starting to wonder if the open alternative might actually be better given that we can't have both.

It sounds like a more balanced opinion. There are many issues using broken chips: - no physical security (it's bad for an on-the-field security device) - no way to guarantee the code running in it is actually yours - not possible to implement attestation mechanism ...

#1 is the only real problem; if anything, with vendor locked down black boxes you have fewer true attestation capabilities (sure there are mechanisms, but they depend on trusting the vendor). With an open chip it's easy to validate that it is wiped clean and then flash your code.

(keep in mind that the use case here is personal tokens and thus personal validation; remote attestation is desirable in other use cases but not really very compelling here)

- Firmware upgrade over the air... Having an upgradable FW is a must-have in terms of security. - Integrity of code is also a must-have. You can't sell Yubikey like products and asking your customers to load the code using the JTAG...