3 ms·

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

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.

kelnos 4y ago
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.
- jeroenhd 4y ago
  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.
ClumsyPilot 4y ago
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.
- londons_explore 4y ago
  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.
  - Schroedingersat 4y ago
    Can't you just gatuer some entropy from your environment? That would prevent most classes of attacks you care about
    - londons_explore 4y ago
      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.

kelnos 4y ago

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.

jeroenhd 4y ago
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.

ClumsyPilot 4y ago

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.

londons_explore 4y ago
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.
- Schroedingersat 4y ago
  Can't you just gatuer some entropy from your environment? That would prevent most classes of attacks you care about
  - londons_explore 4y ago
    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.