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.
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.
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.
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.
Without that, you might as well just use HTTP and stop pretending it's secure.
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.
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.
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.
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.
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).