Hacker News Reader

Comment by audunw | Hacker News Reader

> "getting crushed by a wave of very low cost Chinese competitors"

That's an odd way of spelling "maintaining a stable market share in the face of Chinese competition".

Going forward, IoT security is going to be an increasingly important factor for new designs. The EU is quite serious about combating security problems with IoT devices. And security is something that the new products coming out of Nordic is very serious about.

I don't think many big, serious device manufacturers are willing to risk being the target of the first catastrophic IoT attack just to save some pennies on a dirt cheap Chinese design, with some poorly verified RISC-V core thrown in with a power hungry Bluetooth radio.

ARM TrustZone is not something the RISC-V ecosystem has a clear standardized answer to yet. So I think that's a reason why ARM will keep its role as the main application processor in high-end BT/Thread chips for the next several years.

View on HN

Having bought a few hundred thousand Nordic chips I can assure you they don’t care about security in a meaningful sense.

All Nordic chips are susceptible to bootloader attacks which make them a poor choice for storing key material. This can be mitigated in the design phase by adding an external security chip like a ATECC608B but if you were to tear down a device and see a board present without this module it certainly will have other vulnerabilities too.

Having worked extensively with both Nordic and Chinese chips, what makes Nordic win is the ease of development - they are by far the best in market when it comes to programmability. Hands down.

The security problems have been known since the NRF51 and despite that those vulnerabilities were carried over into the NRF52 because the cost of validation of chip designs is so prohibitive they did not want to touch it and filed the “oh some random person can extract the entire contents of the chip” bug as “won’t fix”. They are baked into a silicon ip core and can’t be fixed with a software update.

As for RISC-V, there are some amazingly innovative and brilliant alternatives to TrustZone presented at the conference but I suspect Rambus may block innovation here using their position on the board (and chairing the security standing committee) in favor of their own (patented) solutions using an embrace, extend, extinguish strategy.

The famous APProtect bug was patched in a silicon rev IIRC. Unless you're thinking of another exploit

Through voltage glitching isn't it? Which rev protects against it? Must be quite new.

Yes, this fix was mentioned in IN-142 from Nordic.

>Having worked extensively with both Nordic and Chinese chips, what makes Nordic win is the ease of development

This seems to be the norm for Chinese chips in general.

Poor documentation, even in the native Chinese, no official dev boards, sometimes no JTAG debuggers, random bugs, just a whole lot of bullshit to deal with as a foreign developer.

I suspect it might be a cultural thing; developers are less prone to pouring over data sheets and more prone to asking their friends/colleagues to introduce them to someone who works at one of the microcontroller companies. (This is just a hunch, and I could be completely wrong.)

The security issues also cause inconvenience, e.g. the later revisions of the nrf52 needing either a recover operation or updated firmware (the hack of flashing a default bootloader in recovery mode that disables security is...interesting).

That aside, Nordic still seems the best choice out there though quite a lot of features are leveraging the ARM ecosystem. RISC-V involvement is possibly toe in the water stuff/de-risking from ARM ("who owns them today?"). The recent big switch in SDK's (nrfSDK to Zephyr) wasn't teribly welcome, so the possiblility of another one is not welcome (if there was an approximately equal competitor with more stability we'd jump ship).

>I suspect Rambus may block innovation here using their position on the board (and chairing the security standing committee) in favor of their own (patented) solutions using an embrace, extend, extinguish strategy.

RISC-V members have to sign an agreement when they join, which has clauses to prevent this sort of situation.

"I don't think many big, serious device manufacturers are willing to risk being the target of the first catastrophic IoT attack [..]"

You must be kidding, right? It's not that they would have cared much in the past. Now, I would be the first to celebrate a change in that regard, but it's just not the world we live in now.

> I don't think many big, serious device manufacturers are willing to risk being the target of the first catastrophic IoT attack just to save some pennies on a dirt cheap Chinese design, with some poorly verified RISC-V core thrown in with a power hungry Bluetooth radio.

The small budget OEMs will save some pennies on a dirt cheap Chinese design. The big, serious device manufacturers will do the design themselves by starting with an open reference design and making some minor modifications that suit them, then pay someone to fab it because they're shipping millions of units. Who does that even leave?

> ARM TrustZone is not something the RISC-V ecosystem has a clear standardized answer to yet.

This has almost nothing to do with IoT security, if not being directly opposed to it as a thing used to prevent people from installing custom firmware on devices the OEM fails to support.

The #1 problem in IoT security is OEMs that release a device which they neither patch nor allow anyone else to patch. And the first can't be a solution for small OEMs because they go out of business, so the only way to actually fix it is to have devices that users can update with third party firmware. For which the lack of ARM TrustZone is an advantage, since it's often used to prevent this.

Every IoT device already uses esp chips, that's the only reason they can afford to make them. Them being low security doesn't matter, it's not like smart homes are secure now. Security is not important to IoT devices.

Esp32 is not low security: https://blog.espressif.com/esp32-s2-security-improvements-5e...

It is up to the manufacturer to implement it, most esp devices like 8266 and 32 have weak security firmware, are easily hackable (benefit to me). Most don't have security in mind and don't get security updates.

The new ESP32 models coming out, especially the RISC-V models, all have security features like Flash encryption and hardware cryptography modules. Unfortunate for those who like to reflash consumer devices.

The chips themselves are $1 qty 1. Remove the old chip, put your unlocked chip in its place.

It's beyond most people's ability, equipment and effort threshold to order 1 chip from digikey (how much is delivery on that $1?) and replace a QFN package.

>how much is delivery on that $1?

From AliExpress, it'd probably be $2-$3 including shipping.

They don't ask questions when ordering large volumes of microcontrollers either.

Most people aren't going to be tearing down consumer goods and reflashing the firmware.

If someone wants to get a hot air station and a bunch of $1 chips and reprogram their own devices, it would cost them less than a hundred dollars, 150 tops.

Anyone can learn any skill. If you can draw anything recognizable, you can do electronics.

how much is the soldering station to do that?

$100 and a steady hand :)

I got a cheap hot air station from amazon for only $40, works quite well! Maybe another $10 for solder wire and $10 for flux and you're good to go

The chances that the popular wireless chip subsidized heavily by the CCP does not have a backdoor somewhere are too low to consider seriously.

They are popular only because they are so cheap. Also, so far as chip shortage, China kept pumping them out.

Not every...

Ikea, for example, ships tons of "smart lightbulbs" with silabs/EFR32.

That's not true anymore. There was a shift to Beken Chips a year or two ago so a lot of your Amazon WiFi iot stuff uses that now (Tuya and Tasmota). Check out OpenBeken. I can't find much info on it but thinking it's cheaper than esp's probably more similar to esp8266 than esp32. Espressif chips are much more secure nowadays compared to the esp8266 days.

The beken ones don't have cheap Dev boards but I heard they are better sometimes. I don't know if they're better but DIY for them isn't so far.

I don't think security is a real problem for me. Smart devices on their own intranet takes away a lot of problems.

Isn't TrustZone inherently evil, though? Isn't its main use to let the megacorps trust that your device won't do what you want and will keep secrets from you?

I can't tell if this is sarcasm. TrustZone is a technology for resource isolation. At an extremely high nontechnical level, it's conceptually similar to memory protection.

The problem with TrustZone is that control of it always resides with a megacorp and never with the owner of the device. It's not that it isn't security at all, but rather that it's security against the owner.

The owner can control Trustzone if the device is shipped with unfused OTP registers.

On Raspberry Pi for example, you can write the hash of your own public key to locations 47-54 of the OTP memory block:

https://www.raspberrypi.com/documentation/computers/raspberr...

Here's the QuickStart for the entire process: https://github.com/raspberrypi/usbboot/blob/master/secure-bo...

Note that the Raspberry Pi does not have a full TrustZone implementation to protect secure mode memory, etc. But it is a widely available device with good documentation and allows developers to experiment with and learn about the basics of TrustZone architecture.

OTP and e-fuses are also evil. Devices should never be forced to become e-waste over them being set "wrong". There should always be a factory reset option that clears everything.

How do you propose patching security vulnerabilities in deployed devices?

Why would that require fuses? You store the firmware in flash, which can be updated to a newer version, restored to the original version or replaced entirely with third party firmware by the device's owner if the OEM fails to patch it, e.g. because they go out of business.

What are you talking about? TrustZone is an ISA feature which lets you mark certain pages as "secure only". Compliant devices with SMMUs should not allow any access to these pages except when initiated by the secure world. It's not some big evil plan by Arm. It's up to vendors how they use it. Many just use it for key storage and verifying biometric data so that even a compromised kernel can't trivially steal the most sensitive data on a device.

If you start building your own hardware and/or buy devices with unlocked bootloaders, you can load whatever you want in EL3 to play with TZ. This isn't a problem with TZ.

This shouldn't be downvoted. It is a legitimate question and widely held misconception that is addressed in several of the responses to parent.

TrustZone doesn't run on a separate processor like the x86 TPM. It's more like a hypervisor-level ring fence than a coprocessor.

Reply on news.ycombinator.com