Hacker News Reader

Comment by purpleidea | Hacker News Reader

The big anti-feature is that developers can block users from flashing the chips.

Yes, there's a security angle, but if I have the chip in my hands, I should be able to flip some pin to reprogram the chip and prevent all the e-waste.

View on HN

A major worry I have is: the EU is bringing forth some serious cybersecurity regulations (affecting equipment with radios (WiFi, Bluetooth, ...) as part of the Radio Equipment Directive later this year, soon to affect everything as part of the Cyber Resiliency Act). This enforces some good security practice, but also has a lot of stuff in it that's way easier to comply with if you just say, "the device is locked down with hardware-protected write protection (or Secure Boot)".

To my understanding, there's nothing specifically preventing companies from giving the user the ability to disable write protection or load their own signing keys, but it means that the default will be to have locked-down devices and companies will have to invest extra resources and take extra risks with regard to certification into enabling users to do what they want with the hardware. I predict that the vast majority of companies making random IoT crap won't bother, so it's e-waste.

I am afraid this is a very narrow reading of the CRA. Did you read the act yourself or some qualified opinion by a European lawyer? Security updates are the default demand of CRA and not having them is an exception that requires an assessment of risk (which I would assume mean that it's only viable for devices not directly connected to Internet).

An (equally narrow ;)) quote:

"ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;"

Thus, I expect RED to stipulate only radio firmware to be locked down to prevent you from unlocking any frequencies but the CRA to require all other software to be updatable to patch vulns.

I have not read the RED or the CRA, nor discussed what they specifically say with a lawyer who has read them. However, I have gone through a recent product R&D process in Europe where the product has WiFi and LTE connectivity, so it falls under the RED (even though WiFi and 4G are handled by off-the-shelf modules). I have read parts of the EN-18031 standards (mostly using their decision trees and descriptions of decision nodes as reference), I've been on a seminar with a Notified Body about what the practical implications of the RED are, I've filled out a huge document going through all the decision trees in 18031 and giving justifications for the specific path through the decision tree applies to our product. I've also discussed the implications of the RED and 18031 with consultants.

I don't doubt you with regard to what the RED and the CRA actually says. However I'm afraid that my understanding of it better reflects the practical real-world implications of companies who just need to go through the certification process.

18031 requires an update mechanism for most products, yes, however it some very stringent requirements for it to be considered a Secure Update Mechanism. I sadly don't have the 18031 standard anymore so I can't look up the specific decision nodes, but I know for sure that allowing anyone with physical access to just flash the product with new unsigned firmware would not count as a Secure Update Mechanism (I think unless you can justify that the operational environment of the product ensures that no unauthorized person has physical access to the device, or something like that).

EDIT: And I wanted to add, in one common use case for microcontrollers, namely as one part of a larger product with some SoC running Linux being the main application processor and with MCUs handling specific tasks, you can easily get a PASS in all the EN-18031 decision trees without an upgrade mechanism for the MCUs themselves. In such products, I can imagine a company deciding that it's easier to just permanently lock down the MCU with a write protect than to justify leaving it writeable.

Thank you, an interesting (and somewhat sad) perspective. Would be unfortunate if these two regulations combined result in less firmware update capabilities not more.

Yeah, it's sad. I can say with certainty that there are products whose developers would have decided to leave MCUs and/or SoMs writeable based on analysing the threat model, but where the rigid decision trees in EN-18031 around secure storage mechanisms and secure update mechanisms makes that too difficult to justify.

>> The big anti-feature is that developers can block users from flashing the chips.

There's a liability angle too. If a company (or person) makes a product that has any potential for harm and you reprogram it prior to an accident, YOU must take responsibility but will probably not.

Another angle is that the hardware may be cloneable and there's no reason anyone should be able to read out the code and put it into a clone device. There is a valid use case in making a replacement chip for yourself.

Companies will buy far more chips than hobbyists, so this feature caters to them and for valid reasons.

>> Yes, there's a security angle, but if I have the chip in my hands, I should be able to flip some pin to reprogram the chip and prevent all the e-waste.

What if the chip used masked ROM? Your desire is not always feasible. You can always replace the chip with another one - and go write your own software for it </sarcasm>.

BTW I'm a big fan of Free Software and the GPL, but there are places where non-free makes sense too.

> there are places where non-free makes sense too

Seriously now, where is that? The only scenarios I can think of are devices that could put others at risk. Large vehicles. But even, many countries allow modified vehicles on the road.

But everything else should be game. If it's my device and only me at risk, why should anyone else get a say.

At least the European countries I am aware of, the owners will have a hard time on a police control if the modifications aren't part of the allowed ones by law, and depending on the modification, it is missing from the car documentation.

I think that's what I was saying. Vehicle control software is the only place I think where certified code makes sense. When others' safety can be put at risk by your crappy coding. That's not a copyright/licencing issue, or even something solved by making chips harder to flash, it's a vehicle law.

TFA makes it sound like there are many others. What else is there?

Liability like in any other products.

It is about time people start returning software, or getting free repairs if the software is faulty, instead of rebooting and hoping for the best.

The European cybersecurity laws in a few jurisdictions are already a good step into that direction.

How much chip re-flashing / re-use is being done at the moment? I'm not convinced e-waste is repurposed in any kind at any scale... although it's an interesting premise if electronics are more modular and can easily be disassembled, and e.g. millions of esp32 based chips end up on the secondhand market.

The ESP32 (and other ESP chips) are somewhat common in smart home/IoT gear, particularly for devices that are dependent on a cloud service to function. There's a growing trend in the smart home community of re-flashing cloud-dependent ESP32 based hardware with ESPHome, which makes the device fully local controlled, eliminating the risk of the cloud service being discontinued/enshitified.

It's not a particularly common thing yet, but smart home enthusiasts are becoming increasingly concerned about the expense and effort required to replace cloud-dependent hardware because the manufacturer decided the cloud service isn't worth maintaining anymore.

From what I've seen very little. I _think_ it's something to do with the kind of people who work on embedded systems generally wanting the freedom that comes with making things from scratch resulting in not that much interest in repurposing old things outside of making them work with their overall IoT network.

I recently reverse engineered an e-waste STEM toy from scratch ( https://github.com/padraigfl/awesome-arcade-coder ) and the general response I got from places were:

a. to salvage the microcontroller and other relevant parts (probably worth $4 off a board that would cost $100+ to replicate)

b. a weirdly hostile attitude about the ethics of reverse engineering regardless of the motives (guessing people have been burned a lot with people stealing their designs)

I've mostly worked on the frontend and don't have much knowledge of embedded systems at all but it wasn't anywhere near as hard as I expected. Keen to find some other ESP32 devices to tweak (suggestions welcome!). I guess even if making them unflashable becomes the norm it won't be too hard to just swap the ESP32 off the board with a new one.

Quite a bit in IoT market, especially in the low-mid tier and Chinese imports. There’s an entire ecosystem of custom OS’s for home automation that runs on these ESPs, ESPHome for example. I have flashed quite a few smart sockets to run Matt/kafka messaging client rather than unknown vendors software that has an open socket to offshore ips.

How is this different in practice to the regular ESP32's secure boot, where you can technically flash the chip with whatever you like but unless you have the signing key the bootloader will refuse to load it?

If the key is stolen, you can still protect your hardware.

You can generate the keys on-device during the initial provisioning and have it encrypt the flash with that key, so every device generates its own unique key and there isn't any practical way to extract it; even the developer can't flash it directly, and OTAs are required to update the firmware. This effectively means nobody can flash the chip anyway since you can't know the keys. Is there some sort of attack vector here I'm missing that gets mitigated by preventing flashing entirely?

If the developers really wanted to you have the key, they could just write the per device unique key in the box or on the pcb. What you’re suggesting is more or less possible, the problem is you represent a very niche case. 99.9% of consumers don’t want to reprogram a chip already soldered to a board and it’s not worth the time catering to them. Also some IOT devices are left in physically insecure places like on the exterior of the home, you’d never want some to be able to extract the firmware key or re-flash those devices.

This is explicitly for IoT manufacturers that want to lock out people easily modifying a device (or bringing it back to life after it receives an "update of death") or the kinds of industrial customers that need to check a box for a cybersecurity audit.

These IoT manufacturers keep making all of these new products but the thing is, an ESP32 from several years ago is not that much different than one from today. They don't need much compute, anything difficult can take place on the cloud. So how do you sell someone new hardware if the first gen device is still perfectly capable? How do you sell a premium version if it's just the same parts inside? For the former, you can EoL a product by blocking it from cloud services (like Nest this week). If the firmware is locked, a hobbyist can't just flash modified gen 2 firmware and have the device functioning like normal. For the latter, you can lock the bootloader firmware so that it will only load the firmware that you want it to run (i.e. the basic or premium version).

When you say “this is explicitly for iot manufacturers…” are you referring to secure boot? That’s what I was referring to. I’ve done embedded development for about a decade, 6 at an IOT company, and our main motivation for using secure boot was to keep our firmware secure. The last thing we want is someone writing an article on the internet about how with this one easy trick you can break the security of the device and do whatever you want ( the devices are related to access control). If the company went out of business we’d have the option of publishing the signing key but it’d render all the devices vulnerable to malicious OTAs. Point is we’re not trying to lock folks out of tinkering, we’re trying to keep the devices secure. I understand as a side effect it means you can’t flash the device to whatever you want.

Also for what it’s worth these ESP chips are unbelievably cheap when bought at scale. The box the product comes in is probably more expensive

You obviously apply to the latter of my first paragraph. There are certainly applications where a device absolutely cannot be modified because then it defeats the purpose (i.e. security systems). What I'm talking about is something like a zigbee widget where it's job is non-critical. Not allowing user OTA updates is probably a good idea but preventing any changes to firmware for a non-critical device seems questionable.

E-waste prevention is hella important. It's a tough situation though. I think for a board that goes out in the public, even at a prototyping level, it's important to know the chip you have is not tampered with. I once wanted to make a little people counter at a university campus with an ESP8266. I simply couldn't make sure it's resilient against some CS students poking at it.

Let's say the chip was lockable, what would prevent someone from using a bit of hot air and flux from just swapping out your chip with whatever?

The firmware that's missing on that new chip

That's why you force a full erase to clear the non programmable bit?

It takes little skill, 15USD soldering iron to solder 4-5 through holes wires, connect 10 usd programmer and flash a new firmware. Investing in a (de)soldering station, with the risk of pulling all the neighboring components, breadboard/something to plugin your new controller or memory into for programming and what not? I’m not sure if I’d go through that trouble

Yes, but this I think is a bit sad. Once you have proper hard to crack security a smart kid from CS won't find it hidden decide to hack it and write blog post about it how he has done it. As long as it is not something dangerous sometimes having less security is better

Sounds like you're trying to deprive CS students of their practical education :P

Yes, it's one thing to prevent others from reading the flash, but I don't see the value in preventing reflashing it.

It counters evil maid attacks.

Not really, if the evil maid is sophisticated enough to bring their own firmware to reflash your devices, they could also just swap the PCB containing the controller or solder in a new chip

I chose the word counters rather than eliminate for the reason you outlined.

If you're the vendor, you can add a tamper-resistant or tamper-evident design to raise the cost of ,component-replacement attacks. Which can be countered by whole-device replacement, which in turn is countered by device identity attestation, amd so on, in an endless arms-race.

Tamper-evident stuff and device attestation solve all these problems even without preventing reflashing. If you can't check if the device has been tampered with or replaced, preventing flashing won't help. If you can, you don't need to.

Means the Russians can't repurpose the washing machines to build drones.

Most IoT devices implement security and integrity using one time burnable registers (more importantly for keys). It's sad but yes, those devices are permanently bound to the vendor. There is no real alternative though, a TPM based approach makes it more complex and is another closed system.

You can. It's not that hard to physically put a new chip on. Software people are too afraid to get their hands dirty.

This was about reusing the chip. Since these things are built using finite resources, maybe we should also design them with that reality in mind?

Usually in secure systems you can't read out all of the data from the old chip.

De-soldering an MCU and soldering on a new oneis typically far from trivial. We're typically not talking about dedicated big through-hole flash chips here. We're often talking about MCUs with integrated flash memory which are surface-mounted and often with pins on the underside.

In general, I find it easier to desolder and replace surface mounted parts. With those, you just have to hit it with some hot air, it melts all the solder at once, and lifts right away. The chips are small, so it's not too bad to heat the whole thing evenly with a small air gun.

Through hole parts need a lot more heat across a bigger area, or you have to go pin by pin. I've scorched many a through hole board trying to desolder something, cursing at those who didn't socket the chip in the first place.

Want to annoy a repair person? Pot the whole thing in epoxy.

The saving grace here is that ESPs have radios and require certification which is expensive. As a result it is common for vendors to use pre-certified modules that are provided on a modular PCB with castellated half-holes. These are relatively easy to desolder.

For ESP these modules are the WROOM line.

Still easier than replacing the software on the chip, IMO.

Any alternatives that aren't consumer hostile?

Should we just be pushing harder for "Works with Homeassistant" certification?

Reply on news.ycombinator.com