Hacker News Reader

Comment by londons_explore | Hacker News Reader

It is not awfully hard to protect a chip against readout through glitching.

All it takes is having brown-out detection which is always on and forces the chip into reset immediately (ie. No 4 cycle interrupt delay). Rate of change of voltage detection might be easier to implement without a precision voltage reference.

Another approach is to put current measurement on the pins. Glitching requires changing the voltage on a pin very quickly, and since the die has quite a lot of capacitance, the current flow is large and easy to measure.

Pretty much, there are lots of solutions to this problem, and any chip designed after 2010 that doesn't implement these shouldn't be considered well designed.

View on HN

I mean, you're not wrong... but the chip industry moves slowly, and by your own definition, most chips produced today would not be considered well designed.

Also, once you protect against power glitching, they'll move on to clock glitching. It's endless.

Historically, this is not something that chip companies or their customers have cared about. Again, unless you're designing an HSM, hardware security is a checkbox sales item that is adequately satisfied by a probably-not-actually-secure firmware readout bit. The sales team is happy with this. The buyers on the other end designing shitty IoT products with a 2 year lifespan can now put a "secure" sticker on the box.

The shitty IoT products can then also use a shitty battery/power supply because the advanced brownout protection the grandparent is talking about won't be spazzing out every 5 minutes that a LED causes voltage to droop. It's a win-win.

I worked in consumer, industrial and medical device testing industry for several years. When working with device manufacturers in the consumer space, for most of them most of the time cost of the device is the primary and overriding concern for the product.

Cost mattered for industrial too, but it was balanced by performance and other considerations. For consumer, it's just cost. Anything that pushed the bill of materials up = bad, not at all win-win in their mind. "Grandpa buys bad electronic devices all the time and will keep doing so, why throw our money away for no reason?" would be a summery of their argument/thought process.

Medical devices are a whole different beast and money was far less of a consideration, or rather, they are far less worried about the cost because it's far easier to recoup the cost of the device.

I don’t know a more better designed BLE SoC than nRF51/52 though...

You might check out the EFR32BG22 from Silicon Labs. It has alot of great security functions, including a dedicated security core with secure boot, secure debug, and unique ID.

Yeah but realistically this isn't a security chip. It's a BLE chip first. Readout protection is mostly added so that customers don't worry so much about trivial IP theft.

Kind of like obfuscators in software. It doesn't really make reverse engineering impossible, it just makes it non-trivial.

I have bad news for you: you can glitch through electromagnetic induction.

I always thought those movie scenes where the protagonist holds a device up to a keypaf and the door unlocks were pure fantasy. But with tight enough control over a phased array, and detailed knowledge of the hardware.... anything might be possible.

Brownout detection is not a protection against glitching, in general. You need to actually be looking for and have specific fault injection attacks in mind to protect against; generic brownout detection is often bypassable.

> All it takes is having brown-out detection which

The moment you say "All it takes" or "Just" or "Simply", you're probably on shaky ground.

The downside of your solutions is "sleep current" which translates directly to "battery life" which translates to "product is nonviable".

Not everything has an HSM threat model.

Part of the reason certain things have a cloud component IS the fact that the client device has to be assumed adversarial under all conditions. (see: practically all modern multiplayer videogames)

Obviously JTAG access is not the only way get chip readout, but couldn't this entire channel be removed by a physical write-once fuse to ground of the JTAG lines?

Reply on news.ycombinator.com