4 ms·

It seems the main thing eating RAM is TLS. It's kind of funny we have these protocols like MQTT that are designed to be simple with MCUs in mind, but then use t

It seems the main thing eating RAM is TLS. It's kind of funny we have these protocols like MQTT that are designed to be simple with MCUs in mind, but then use them over TLS which is way more overhead than say HTTP. It would be interesting to have a secure communication channel that is simpler than TLS. OTOH I guess we can just wait and the RAM will get cheaper.

eternityforest 4y ago
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.
londons_explore 4y ago
Does TLS require lots of RAM? Surely just keeping a 16 byte key in RAM is all that's needed once the connection is established? I imagine establishing the connection requires more RAM, but thats an event that can just use stack space, freeing it all up again when the connection is established. (assuming nothing async).
- chinabot 4y ago
  No ROM on these chips so RAM is both code and data
  - crest 4y ago
    How much of that code has to be resident in SRAM or XIP cache once a session key has been established to handle the common TLS record types? Is it feasible to execute the whole TLS session setup code either in place from serial flash or at least copy it to SRAM on demand allowing the application to use more SRAM once a session has been established?
jeroenhd 4y ago
If you have control over the software I think you can get significant size shavings by throwing out everything but the most recent TLS 1.3 protocol, use certificate pinning to not need the full CA cert list and remove things like session resumption, client side certificate authentication, you name it. The MQTT overhead with the right security layer on top (i.e. 0-RTT TLS with extra checking on the backend to prevent replay attacks) should be quite minimal. There's a computational overhead for calculating the keys of course but the algorithm itself shouldn't need too many extra bytes. Similarly, CoAP + DTLS also lends itself to quite little network overhead.
koffiezet 4y ago
That's why I'm interested in what wireguard op these devices would do, there's a library for that, but haven't experimented with it yet.

eternityforest 4y ago

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.

londons_explore 4y ago

Does TLS require lots of RAM? Surely just keeping a 16 byte key in RAM is all that's needed once the connection is established? I imagine establishing the connection requires more RAM, but thats an event that can just use stack space, freeing it all up again when the connection is established. (assuming nothing async).

chinabot 4y ago
No ROM on these chips so RAM is both code and data
- crest 4y ago
  How much of that code has to be resident in SRAM or XIP cache once a session key has been established to handle the common TLS record types? Is it feasible to execute the whole TLS session setup code either in place from serial flash or at least copy it to SRAM on demand allowing the application to use more SRAM once a session has been established?

jeroenhd 4y ago

If you have control over the software I think you can get significant size shavings by throwing out everything but the most recent TLS 1.3 protocol, use certificate pinning to not need the full CA cert list and remove things like session resumption, client side certificate authentication, you name it. The MQTT overhead with the right security layer on top (i.e. 0-RTT TLS with extra checking on the backend to prevent replay attacks) should be quite minimal. There's a computational overhead for calculating the keys of course but the algorithm itself shouldn't need too many extra bytes. Similarly, CoAP + DTLS also lends itself to quite little network overhead.

koffiezet 4y ago

That's why I'm interested in what wireguard op these devices would do, there's a library for that, but haven't experimented with it yet.