Comment by ohazi | Hacker News Reader

Comment by ohazi | Hacker News Reader

To be fair, "restricting" flash readout while allowing hardware debug access always seemed like a minefield, and I would hope that anyone with a security sensitive application would have seen this from a mile away.

You could have a completely bug-free, constant-time, constant-power cryptographic library running on one of these microcontrollers, and debug access would allow you to reliably extract encryption keys just by examining the execution path.

The amount of processor and system state that you have access to with a hardware ARM debugger is crazy, but that isn't really the problem -- you can extract a ton of state with a minimal debugger too. Just a log of instruction pointer values would get you 90% of the way there.

I think it's reasonable to assume that microcontrollers with exposed debug interfaces simply cannot be made secure, just as people generally assume that it's game over once someone has physical access to a computer.

Yup - this exactly. The JTAG fuses should be blown on all devices that need to secure their flash (or secrets).

Working on these specific processors around 5 years ago, we implemented a serial port based "unlock" that would generate a challenge/response from the device that if correctly acknowledged, would unlock the JTAG whilst the chip has power (it locks again when it looses power). This worked great - we spent a lot of time on the UART driver to make sure it was super simple and robust during the period when it could listen to incoming bytes (no interrupts etc...).

Modern cryptography libraries make sure that the execution path (and memory access patterns) do not depend on sensitive data. Usually this is what is meant with 'constant-time'.

If a debugger can read out registers or memory you can just read out the sensitive material of course.

Whoops... Yeah, you're right. You wouldn't expect to see instructions like bne, bge, etc. that depend on key material directly, so you wouldn't be able to rely the instruction pointer alone.

Instead, you might see instructions like addlt, so you'd also need to inspect the value before and after, which, as you correctly state, the debugger will happily let you do.

Reply on news.ycombinator.com