Hacker News Reader

Comment by londons_explore | Hacker News Reader

Hardware protection against this class of attacks seems relatively straightforward... simply have a few wire loops snaking around most of the die. Then measure the voltage on those wires, and if they ever go too high or too low, reset the CPU.

Also... The CPU needs to have brownout detection to detect people messing with the supply voltage, and clock glitch detection to detect inconsistent clocking inputs.

All that I think could be added with no major downsides (it wouldn't use a lot of silicon area or power).

How come this design didn't already have that?

View on HN

I get the feeling it might not be as easy to implement as your comment makes it sound. Granted, I have no idea about hardware design, but it would be hilarious if you e.g. calibrated your EMI-detection a little too sensitively and your PC shuts down every time your colleague gets up from their office chair.

Not the first or last time that this kind of problem already happened in practice. My favorite is https://patrickthomson.tumblr.com/post/2499755681/the-best-d...

“Brown-out detection” is a pretty standard feature even in cheap microcontrollers (which, granted, are much more straightforward about their power). Don’t know how it holds up in an adversarial situation—not that well, probably. (You’re ultimately powering the comparators and voltage references off the same power supply, would be the first possible class of problems.)

Sadly it's not precise enough.

The only obvious downside I can see is that these protection limits have to be set within the operational envelope of the CPU to be effective. That effectively narrows the range of possible voltages and frequencies that the user can use the CPU at. Some types of overclocking would go out of the window.

On the other hand, such checks could be disable-able at runtime by sufficiently trusted code - although you obviously have to choose between security and overclockability.

There is also the issue that such things are decidedly 'analogue' things - and integrating them into a digital design toolchain sounds hard. Trying to tell EDA software 'send this wire all the way around the outside of the chip and back to where it started' is a bit like trying to tell a C compiler 'I want you to write all the code so all jumps go to prime numbered memory addresses'.

I think hardware protection against EMFI isn’t important for consumer electronics or even commercial servers.

1. It requires physical access.

2. Password based disk encryption would still protect against EMFI attacks for data exfiltration. There are easier methods to bypass TPM than EMFI.

Reply on news.ycombinator.com