Hacker News Reader

Comment by eternityforest | Hacker News Reader

Encryption kind of sucks for these tiny IoT gadgets. I'd much rather have everything completely open and local only, and just not give out access to my network to people I don't trust.

It's always possible that another device hacks its firmware update, and leave a payload that then hacks a NAS or something, but that's a fair tradeoff to have devices that don't phone home to some server that could vanish at any time, considering that it's pretty unlikely unless you buy really bad no name stuff.

Plus, it can be very easily prevented by just not having a firmware update that can be accessed without a physical connection or button.

A lot of this stuff doesn't need updates regularly. It's just a light bulb. It doesn't have to be secure against people on the same network.

The cloud stuff is the stuff that gets obsolete or gets hacked, so it should go through a separate hub.

View on HN

Well, sometimes you do want to control something directly over the internet, especialyl in industrial applications, like imagine you are monitoring a vehicle's location or temperature/humidity of a fridge in a supermarket.

My limited understanding of encryption/TLS and playing with microcontrollers, these devices can't have the full list of root certificates that we would have access to with our browsers / on linux. So you can't just go out and use any SSL/TLS certificate, you have to flash into the device either the signature of the cert you will use, or the root of trust you expect to use for the next X years.

Just look at Azure IoT Hub documentation right now:

> During a TLS handshake, IoT Hub presents RSA-keyed server certificates to connecting clients. Its' root is the Baltimore Cybertrust Root CA. Because the Baltimore root is at end-of-life, we'll be migrating to a new root called DigiCert Global G2. This change will impact all devices currently connecting to IoT Hub. To prepare for this migration and for all other details

It seems to me, that if you have these problems anyway, you might as well use Authenticated symmetric encryption - it is perfectly feasible to give each device a unique key, and you could use that until the end of days with much lesser requirements on the hardware. LoraWan uses symmetric equipment only.

Also, in the case of Fridge temperature monitoring, I don't even care if someone else can snoop on the data - I only care that the device is sending data to the real server, and not an imposter, so something like HMAC should work for that.

Most IoT stuff has no random number generator anyway. Without a random number generator you can't do TLS properly.

Without that, you might as well just use HTTP and stop pretending it's secure.

Can't you just gatuer some entropy from your environment? That would prevent most classes of attacks you care about

Most little embedded machines don't have much environment to get entropy from. If you boot up and download your config from an https server, there is a good chance the whole machine state (ie. Every byte of ram) is identical to the last time you did that.

Couple of ways to do that.

You can feed the lower bits from a ADC converter into a hash algorithm. You can feed the RSSI readings from the radio as well. And finally newer embedded processors and some radio transceivers have built in random number generators. Helps to to flash each device with a unique random seed too.

I consider RNGs basically solved. It's possible to do them wrong, and hardware backdoors could happen, but it's not like we don't have plenty of entropy sources on almost all platforms.

There are solutions to such problems, for example by using custom CAs + cert pinning or pinning cross-signed intermediates; if the Baltimore CA signed an intermediate together with the DigiCert CA then that intermediate can be pinned and used for as long as the Baltimore CA is considered valid by the device. Implementing DANE might also be an option, negating the need for CAs entirely at the cost of extra network traffic (and angering some very dedicated internet people who detest DANE for some reason despite its usefulness in such scenarios).

The RNG problem can be solved relatively inexpensively by dedicated hardware for good enough RNGs (all you really need is enough floating voltage to seed a PRNG and it should probably work well _enough_ in practice). Because of the limited data throughput of many IoT solutions, it's quite difficult to capture enough traffic to reverse the state of the RNG compared to desktop applications where you can capture many gigabytes of data per second.

Symmetric keys also work well if you can figure out secrets management. Managing many secrets can quickly become a pain, though, so it really depends on what kind of devices you use and how many.

But yes, I think most IoT data is pretty worthless for attackers, so it can probably be sent without encryption. If you hack into my network to monitor the temperature of my room then I don't know what to tell you, there are probably better targets out there.

Since the ESP32 chips support Wi-Fi, I assume they must have a RNG for Wi-Fi encryption to work properly, right? If so, is the RNG accessible to the application?

Yes and yes, the SDK has esp_random() and esp_fill_random() which hook into the hardware RNG.

I don't see why a fridge should talk directly do a server. That would be a lot of fridges to reflash or more likely replace the sensor if the server changes.

If they all go to a hub, all you have to do is update the hub, plus, the hub can do stuff like local alerts.

Symmetric encryption is probably the way to go for use cases that directly connect.

I wish there was something like an IPv9 (7 and 8 are probably taken!) with 48 byte addresses and a fixed layout. 8 byte ISP identifier, 4 bytes customer, 2 bytes subnet, 2 bytes device, and 32 bytes for a public key hash.

No more certificates, no more insecure LAN connections, just IP that's always secure no matter what as long as you have the right address, and even if you change ISPs you keep the key part of the address.

I've been working on little temp/humidity/air qual sensors on ESP32, and I've been feeling the MQTT+TLS pain as well. I was thinking I might create a separate wifi network just for these devices, with a rule on the router that only allows MQTT from the sensor network to the main network, and ssh from the main network to the sensor network. Then I can just get rid of TLS. Sure, the MQTT will flow in cleartext from the AP, through the switch, and to the MQTT broker machine, but I think that's fine.

What are your issues with MQTT+TLS in practice? If you can keep the TCP connection open then you shouldn't have too much overhead, should you?

You may want to look into the Matter standard, which already takes security into account and provides some non-certificate based security options. Such devices should integrate well with current and upcoming home automation products from tech giants like Google and Apple. Implementing it from scratch seems very very complicated, but it seems there are premade examples available for ESP32 and other such devices. As an added bonus, Matter can work over other physical protocols such as Bluetooth LE and 802.15.4 + Thread which may take some of the load of your WiFi routing.

Reply on news.ycombinator.com