4 ms·

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 sensit

by ohazi 7y ago

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.

mrlambchop 7y ago
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...).
remcob 7y ago
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.
- ohazi 7y ago
  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.

by ohazi 7y ago

mrlambchop 7y ago

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...).

remcob 7y ago

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.

ohazi 7y ago
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.