Comment by ohazi | Hacker News Reader

Comment by ohazi | Hacker News Reader

This isn't actually as bad as it sounds.

Almost all general purpose microcontrollers with "readout protection" are vulnerable to glitching attacks like this one. It may be a stretch to claim that most embedded engineers understand this, but successful attacks like this one are published at least a few times a year, and eventually one of them targets a part that you've used before.

All it does is force you to think about your threat model. You shouldn't keep sensitive or long-term secrets on a microcontroller and expect them to remain safe. Transient things like BLE session keys? Sure, whatever.

It's why you don't see (responsible) people designing HSMs using parts like these, and why extreme skepticism is warranted when people try to build things like cryptocurrency hardware wallets out of Arduino-caliber parts.

There are special classes of parts with more robust security features that you should consider using if you need anything resembling an HSM. Even those parts get broken from time to time, and those breaks are rarely fixable without new hardware.

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.

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.

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.

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.

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.

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?

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

I'm very excited about the new Solo keys coming out, but am apprehensive because they use an NXP LPC55S69 processor, which doesn't look like a secure element to me. Does anyone have experience with it?

Regardless, I think the security benefit will be substantial, since the ease of use will outweigh the risk of someone physically getting the device and extracting the keys by a lot.

Almost all general purpose microcontrollers with "readout protection" are vulnerable to glitching attacks like this one.

...and even if they aren't, you can find companies that will read out protected MCUs for a few k$. Keywords are "MCU break". (Whose Google results are currently flooded with other things.)

I have memories of this sort of thing going on back in the early 2000s with DirecTV access cards. One of the methods was to glitch the access card processor during bootup by pulsing and otherwise messing with the power. IIRC, it could be put into a test or debug mode if it was timed right.

On one hand I'd expect most systems that take security seriously would defend against this, but on the other hand the pitiful state of mass market and consumer hardware would indicate that very low expectations would be appropriate.

Reply on news.ycombinator.com