[alias_neo]

I might not have been clear, but this is exactly what I'm talking about.

When you buy a WiFi connected IoT device, they don't know your WiFi credentials, so you enter them, and they get stored on the device so they can be used to connect to your network, just like any other device.

Of course these are not encrypted, because the device need them to connect to your WiFi.

When you build a home made IoT device, using an ESP32 for example, your can take these easy route, and hard code your WiFi password into the code before your write the firmware.

To avoid this in a user-made IoT device, you'd need to configure it to set up a WiFi hotspot, unprotected, so you can connect to it and tell it your WiFi password, like one does with a Chromecast, and like the device in the article and any other sensible production device.

It then stores this in EEPROM or NVRAM, and "reboots" to connect to your network, disabling its hotspot in the process. This unencrypted storage is what the article refers to and is largely unavoidable.

[gh02t]

> This unencrypted storage is what the article refers to and is largely unavoidable.

It is avoidable, the ESP32 supports transparently encrypted flash memory using a key that is stored in one-time-programmable, tamper-resistant fuse bits. The intended use is to make exactly this sort of attack considerably more difficult. Unlike the ESP8266, the '32 has quite a few security features, none of which are enabled here apparently.

[alias_neo]

We aren't in disagreement, I mentioned the secure key storage ("secure element") in my first comment, the problem is that people aren't using it.

I qualified my point with "largely" to be clear that I'm not saying it's unavoidable.

[gh02t]

Yes, I guess my point was that in this case it's trivially avoidable. Enabling these features in the ESP32 is really easy and doesn't have any significant downsides AFAIK, I don't understand why LIFX didn't. It's far from unhackable but I think enabling flash encryption and locking the JTAG and flash read would be perfectly acceptable security-wise.

[solarkraft]

All of this crap is why I'm now a fan of Zigbee. If I have to set up a new network anyway it might as well be better suited for the iot.

A down side is that there's no nicely integrated module like the ESP8266 available for diy.

[alias_neo]

Agreed, I started with XBee radios, they do secure networking and full mesh but they're relatively expensive, a single radio cost about £40 a few years back.

To add an MCU and peripherals brings a single device cost up considerably.

I'd hoped, some years ago when I first started my IoT endeavours that the cost would come down but ZigBee has not, and sadly things like ZLL (ZigBee Light Link) that companies such as Philips use for Hue, perpetuate the propriety nature.

My entire home is Hue (ZLL) but for anything non-Hue I use Z-Wave devices which are relatively cheaper and support secure mode.

[pbhjpbhj]

Passwords? Maybe WPS, or a variant, can be used for IoT devices?

[alias_neo]

There are solutions, but as I mentioned in my original comment, previous hardware has generally not had the power to implement secure cryptographic solutions.

As an example, an ES8266 would be unable to verify a server certificate for a TLS connection against a CA, cryptographically due to memory/compute constraints so historically it's been done by just verifying the fingerprint with a simple comparison.

WPS is insecure and shouldn't be used at all.

One way to do the password system safely is to have a one time pass in volatile memory that is provisioned in a secure environment where you're confident it can't be captured as you pass it over an insecure channel.

The ESP32 is a huge improvement, hardware wise in security capability, it has hardware cryptographic extensions and a secure element, but it's rarely used properly as the article is an example of.