Reclaim Your Data: Freeing a Wi-Fi Sensor from the Cloud
embeddedartistry.com
embeddedartistry.com
One more very good reason for preventing requests to "the cloud".
However, I find it funny that the lack of proper certificate validation (which is a security issue in principle) is a pre-requisite for the "de-cloudification" process.
I avoid as much as possible, devices with cloud connections, but those which I somehow end up with anyway that do have such services, I've found almost none of them do any sort of certificate validation.
Load up any certificate you like on your MiTM proxy and go to town.
Sadly, despite embedded hardware being much more capable, some of them having hardware secure-elements and cryptographic extensions, people making these devices either don't have the expertise or just don't care.
Once upon a time I dreamt of creating IoT devices with security, openness and longevity in mind.
A self renewing free certificate (eg: Letsencrypt) still requires some maintenance. A non free certificate also costs money. It's probably a no-no for many of those manufacturers or the company that give them the servers. Razor thin margins, know how, dedicated staff, etc.
If you're building products that talk only to your APIs, you issue your own CA, at the very, very minimum you can put a fingerprint in the end-device to verify it, that can be updated OTA if you need to change the CA/server-cert because you kept the lifetime short.
My experience is that for people outside of the "security" space (I'm in secure-comms, backend), most of them don't have a clue. Some believe the only solution is a cert issued by some "trusted" org like LE, others don't know what pinning or verification is, self-sign is often mis-used as a term for self-CA, and then more generally speaking understanding or TLS is low.
The low-resource nature of microcontrollers has certainly made it difficult to do this well/easily in the past, but with micro-sized TLS libraries, and secure-elements on board many of them now, it can absolutely be done with a little effort and understanding. Coupled with EC/certs keys with smaller memory footprints and hardware-crypto accel the only take home I can find in any of this, is that these people simply don't give a shit about the security of the devices they sell and the data about their end-users they're spitting out.
> Razor thin margins, know how, dedicated staff
Half of this "smart" junk is sold at overinflated prices thanks to the "smart-tax". I have a heater which has an ESP32 and you manage it with an app (which I won't do), they spent a bunch on the app, put an ESP32 and some other electronics in what otherwise could have been a £20 heater instead of a £80 heater, and yet I can MiTM their TLS MQTT connection because they make no effort to protect it, all while this thing is spewing mountains of environmental data up to their cloud every 30 seconds that could quite easily be used to detect presence, amongst other things in my home, even when the thing isn't running.
I'm biased being a dev in the security space, but this sort of careless approach shouldn't be allowed when selling consumer electronics. Fortunately, in the UK, NCSC is making efforts to improve this with security labels[0] and requirements at PoS for consumer electronic devices, and I hope to see it develop further.
[0] https://www.ncsc.gov.uk/files/Security-law-smart-devices-NCS...
Not sure what your project was doing, but one doesn't generally want to install a full set of CAs. If you're creating a product that'll talk to your APIs you pin your own CA, ensure that the server name matches and verify it, anything else is a failure.
I've got bad news for you...
Many devices have very little effort; It'd easier however for something that might be storing its filesystem on EEPROM or NAND than say, a microcontroller storing it on-module.
My experience is that most devices I've tested, that use something like an ESP32, make little to no effort to validate the CA; even if you don't have the resources to do it cryptographically, you could still do it with a fingerprint check or at the very least a server name validation, but often none of these things are done.
I have a "smart" room heater which requires an app to control, the heater talks to their server using MQTT; pointing the DNS name on my LAN at a local IP, and starting an MQTT server, I can get full control even with a server cert that isn't signed by the CA they use and doesn't even contain the server name of their server; so long as it's an unexpired certificate, it'll happily accept it.