[alias_neo]

Spot on, OP shows a cursory knowledge of what they're seeing but not the specifics to explain the issue.

WiFi creds have long been an issue with IoT devices, the fact they're added at runtime is a step forward over a lot of the DIY stuff where they really are written to firmware when you write your code, because it's easier than writing code to allow a user-set WiFi password.

There are currently few ways to protect against physical access, but one simple protection is to keep your smart bulbs on their own VLAN and SSID. If they're compromised, the rest of your network is safe, and you're not risking your main SSID password leaking.

Security settings, again, mostly physical, but signatures and secure boot would prevent someone MiTM an update to gain control/access, or just borrowing a bulb and doing the same.

As for the certs, without details of what they are for is hard to say for sure but I doubt there generated separately for each device. These companies are notoriously bad at this stuff.

ESP32 is a major step forward in IoT devices over the previous, it has more resources so in theory it should have sufficient memory and compute to work with certs/keys cryptographically rather then just verifying fingerprints.

It also comes with promise of a secure element, but the SDK is "immature" and I'm yet to see any wide use of those features.

[retSava]

This seems to be user-provided wifi credentials added at the setup-stage at the customer time and location.

What I guess you are thinking about is a problem too, defaults, but this is not what the article point 1 is about.

[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.