[jws]

Synopsis: Secret keys are embedded in the device's e-fuses and are not readable by normal means because of a protection e-fuse. By measuring current draw during power up an interval is determined to be the time when the CPU is reading the e-fuses. At that time the power supplies are "glitched" from 3.3v to 6v using unspecified patterns from a signal generator. This causes errors in the e-fuse reading, one of which is to make a bank of read protected fuses readable. The read values have errors in them, but multiple runs and statistical error correction can retrieve the actual values.

Physical access to the device is required. Security compromise is permanent.

[jeremyjh]

Just piggy backing on the top comment to point out that the primary concern here is not necessarily for the security of the devices that you own and physically control (although that could be an issue in some cases, if others can access them too), but for the IP of the OEM which can now be extracted and flashed to cloned boards. So this may well be a serious issue for some of Espressif's customers, who are mostly OEMs, even if it is not an issue for the consumers who buy from that OEM.

[swiley]

In other words, it’s good for users, who’s should have access to the source much less the binary anyway.

[Arnt]

I think you mean that the owners should have.

Owners have physical access to their devices, but so do others. It's far from obvious to me that as owner, I benefit from elevated privileges, when anyone with temporary physical access also get the same elevated privileges.

[SlowRobotAhead]

I have a product in the field, Chinese clones are on the market using my firmware that was pulled via voltage glitch.

Two things,

1. You know you’ve made it when there is a Chinese clone of your product.

2. I’ll never use that chip again.

[sokoloff]

What chip (family) would you use instead if firmware protection is important to your application?

[SlowRobotAhead]

Depends. But the simple fact is if it’s REALLY important; you had better be doing it online and passing the result to the device.

I could tell you about hardware security modules (HSM) or the new ARM trustzone for small micros, but I’m designing new products so that if I handed you the source - you still can’t clone a board. That requires a connection to a better trusted device.

[baybal2]

> So this may well be a serious issue for some of Espressif's customers, who are mostly OEMs

I highly doubt that. From what I know, that feature was more of a nod to their customers from the West.

To most Chinese entrepreneurs, it makes no sense how your software being copied be an issue:

1. If you have a real specific reason why disclosure of your code be an end to your business, it will get hacked and copied anyways.

2. If you rely on that to stave away competition, you are already are in a such competitive market where this will make no difference, and your business will be cloned anyways.

3. You will get bad rep for that

[petra]

So how do Chinese Entrepreneurs maintain competitive advantage and profit ?

[baybal2]

Think a bit yourself. If you struck gold, you have zero chance not being cloned.

1. Do not strike gold — look for an easily entrechable position in niche market, like a lot of companies in US do

2. Economies of scale — works until your competitor bribes a banker for a giant loan

3. Be one step ahead — look at FAB business. In microelectronics fabrication, everybody copy each other, and you can't do anything about it, but somehow companies still maintain their positions

[petra]

You always have to be one step ahead. No competitive edge lasts forever.

But there's a big difference between being cloned in a month, and being cloned in a year.

Within a year, maybe you could build a brand, create v2, have some economies of scale in dealing with your suppliers(harder to bribe), create some internal expertise.

The last situation is somewhat similar to the fabless companies.

[userbinator]

By cloning and then improving.

[Scoundreller]

Sounds like there’s a “branch if equals” step that checks the fuse in the ROM. You can trigger the code to actually perform your read without branching if you glitch the right part of the cycle. Maybe enough current leaks around at 6V triggering a “not broken” value at the fuse, or just skips the instruction pointer change.

My guess is that the e-fuse is checked on every bit-read, so sometimes you don’t get the true value because your glitch isn’t precise enough.

Possibly there’s some randomization in the timing of each read, but there’s a signature current draw before each read that you can use to trigger your glitch.