First and foremost, this speaks to the ubiquity and hacker friendliness of Espressif's chips. Most of their competitors (I'm looking at you, Broadcom), prefer security through obscurity and make it extremely difficult to get access to chips, let alone SDKs. I am certain that similar vulnerability exist in every embedded WiFi chipset out there.
That being said, the status quo is completely untenable. Connectivity has become the norm in the hardware space, and it is built on a shoddy software foundation. Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability. The results are clear: "the S in IOT stands for security" has become a trope, and connected cameras, locks, washing machines, and many more are getting owned on a weekly basis.
This will change, and whoever cracks this nut will be very successful indeed.
Uhh, their WiFi implementation is hacked-together old open source code distributed as statically linked binary blobs. And that is just the software part, there isn't much visibility into the silicon side..
Every hardware manufacturer can be instructed/bribed/forced to add backdoors to their hardware by their own government, hence the necessary push for open drivers/firmware (Broadcom itself, just to name one, has had strong ties with the US govt for a long time).
I can imagine a meeting in which some high rank officer says "Here's our backdoor blob, you merge this to all your chipsets firmware, so when necessary we can selectively either shut off Ethernet chips or have them relay information elsewhere as instructed through magic packets, which of course won't be noticed because the leds won't blink and any other chipset seeing these packets will comply as well letting them pass through without allowing any form of sniffing or telling the system administrator (1)". I can't imagine any manufacturer risking their business by replying "nope, we won't comply"; they will jump when commanded to do so and if caught the standard reply will be "we were forced" or "they say it's for national security, you know, to catch those evil terrorists!".
(1) it may seem absurd, sort of sci-fi, but having access to the underlying hardware and its firmware would make it not that hard to do. In that case, the only way to safely analyze network traffic would require very fast logic analyzers that wouldn't use any dedicated network chipsets.
The point is: security through obscurity usually doesn't work well, unless the untrusted party is the hardware maker itself, or whoever decides what they put in the hardware; in that case security through obscurity becomes a lot more about obscurity than security, which makes it near 100% effective.
> I can't imagine any manufacturer risking their business by replying "nope, we won't comply"
How about the risk to their business when a multinational corporation is X-raying their cores for backdoors (as one does) and finds the state backdoor, and then decides to no longer do business with the hardware manufacturer because of it—and also publicizes the existence of the backdoor, such that other multinationals pull out as well?
(I say "multinationals" because, presumably, purely-domestic corporations could be compelled by the state to accept the backdoor and say nothing about it.)
I didn’t say it wasn’t debunked, I said that it is what GP was talking about. I didn’t think the “debunked” part was relevant to the question asked that I was responding to. I guess you think it is, so my apologies.
Portions of the US government have tried multiple times to make the addition of backdoors required via public force of law. They're still trying to promote it now. Short of that public requirement, they can ask & issue orders to not discuss the matter, tie it with defense orders, or imply the withholding of export or trade licenses, all contingent upon cooperation. In the end it looks pretty blurry between a request for cooperation and and order.
Even in China, they might not need to rely on explicit state security authority, just tie it up with state sponsored funding or other softer measures.
Are holes in security infrastructure required to collect metadata? Are keys, data that secures content - considered metadata? They're not content. Since you can't discuss the letters publicly, a claim could be that it is metadata, and compel keeping the request to collect it as such secret - similarly the fight from the silenced party, if there were any fight, could be out of public visibility.
No they aren't. Read the Wikipedia page you linked to.
It's great that you can make claims like this based on zero evidence or even allegations, but there is no basis in fact for it.
What's more the number of 3rd party people that have to be involved in something like this make it virtually impossible that the national security letter structure could keep them all silent, especially since there are numerous foreign nationals in the supply chains.
Go read the huge amount of ACLU coverage of these, or the many articles linked, or the congressional testimony. There are no allegations that this mechanism is being used to do what you say.
You seem to be making specific, narrow arguments to cast doubt on a much wider claim.
Not the OP, but I think that addressing specific parts of the claim is extremely important.
We've seen this around the PRISM program, where the allegations of support by tech companies were confused by their support for lawful law enforcment warrants (as opposed to the NSA's dragnet surveillance via PRISM). This confusion has reached the point where I saw a lecturer claiming Google helped the NSA collect data as part of PRISM, where the NSA's own slides[1] show the opposite[2].
FISC/FISCR don't order surveillance, they permits it; the only compulsory powers they have are to limit the scope and conditions of the surveillance permitted, and that's binding on the government under FISA, which criminalizes certain surveillance unless authorized by FISC/FISCR.
And that's a pretty weak compulsion, since the people who are bound are the people who would ordinarily prosecute any federal crime, and they probably aren't interested in prosecuting themselves.
FISA courts issue warrants, which are court orders. All US courts have the power of the writ which means they can issue further orders to effectuate an order or ruling. So a court can order a company to assist the government in the execution of a warrant. This is pretty long-settled law.
The fact that some government agent applies for the warrant does not alter the fact that the warrant, once granted, is an order nor does it remove the power of the writ for further orders to effectuate the warrant.
Ive looked - a lot - to try and find a reasonable alternative. I haven't found any devices that are as inexpensive and convenient as the ESP chips. Microchip have some relatively inexpensive WiFi modules that need to be used with another MCU and Silabs have some modules including an ARM MCU (WGM160P). These still need blobs but I'm a little happier with a larger more established silicon vendor.
I think (at least a couple of years ago) you could get a dev kit for Microchips parts. The difficulty was then you're responsible for keeping the WiFi stack up to date.
Not unique to Chinese firms either. Sprint resisted blanket surveillance, for a while, and were finally coerced into line. Do you imagine hardware vendors are immune to the same pressure, in the US, Japan, and Europe?
While it is true that the core WiFi code is not open source, the ESP-IDF is significantly more open than anything else on the market today.
This is not to say that Espressif is the bee's knees. I personally wouldn't use their hardware in production. But by making their product easily accessible, and much of the source code open, they have made it easier for white hats to raise security issues.
Has there been any successful patent infringement lawsuits over the last three years that targets a Chinese company that has infringed upon a US company? Isn't that part of the issue in the current trade deal talks with China?
Not a US company being infringed, but Lego has gotten a Chinese court to order Lepin to stop making imitations of Lego products. [1] Since arrests have been made over Lepin not complying [2], it seems like the ruling has teeth.
Several years ago Scottish chip company FTDI took matters into their own hands by releasing a driver that would brick counterfeits of their USB to serial converter chip: https://en.wikipedia.org/wiki/FTDI#Driver_controversy
And honestly it's a little harder than Broadcom's to reverse. Xtensa doesn't have nearly the same support in reversing tools as ARM and MIPS. On the plus side though you do get unstripped binaries since it's a static library.
I agree, it is for sure harder to reverse, on the other side without releasing the source, it is also much easier to hide in and keep secret vulnerabilities and or zero-days.
yes. "Most of their competitors... prefer security through obscurity"
Count Texas Instruments ("TI") in this camp.
For example, Josh Wyatt of TI is proud of TI's "black box" approach to security, and even became a bit defensive about TI's closed source / "you don't need to know" aspects of its security for its CC3220 chips:
Why the F would anyone use these chips, when you can use a garden variety MCU, use a good TLS stack like WolfSSL or BearSSL, and fully control / own what goes into your product?
Their "Trusted Root Catalog" is a total fiasco as well. They were one of the AWS IoT launch partners and they apparently repeatedly failed to including AWS root authorities in their catalog. They were responsive in acknowledging, but typically took a month plus to actually update the SDK, (released quarterly,) to address it.
They seemingly failed to comprehend why anyone would not want to use TI's chain of trust, that is not manufacturer customizable, on proprietary IoT devices. This was explicitly an issue for code signing as well, as it required obtaining a third-party code signing certificate from any number of CA's instead of using our explicit root CA.
The fact that Wyatt & co. needed to question in the first place why the stack should be open is disturbing to say the least.
I hope no one seriously relies on any of these products in any secure application. Indeed, many of the vendors in that thread described how they are moving away from the chip due to TI's asinine stance on the issue.
> Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability.
Having worked for a while with the state of the art of microcontroller internet connectivity I can unfortunately second this. Some vendor SDKs are a mess of copied together source code (e.g. old versions of mbedtls and LWIP libraries), random modifications, no clear integration and often quite a few multithreading and memory issues right out of the box. And that's not even to mention that there are often exists exactly 0 unit-tests.
I really hope the state of this space improves in the future, e.g. through new higher quality stacks. Rust would be a great candidate for these things, since it prevents lots of the issues upfront by refusing to compile. But building better stacks takes a lot of time and effort, and someone would first need to start those invest this.
I agree there is a huge problem with security in IoT and it could be a great startup business for the near future. I met somebody in Redwood City who was working on the security on a hardware level, but I guess they have not been very successful.
For those unfamiliar with the topic, these two chips are by and far the most common wifi chips for DIY and are also very common in IoT devices. Due to cheap price ($2—$5 depending on the model) and very low barrier to entry technically, these devices are both very popular as well as very wide spread in those two categories.
These chips are the first hits for searches such as "Arduino wifi module", "breadboard wifi", "IoT wifi module", and many, many more as they're the downright easiest way to add wifi to something that doesn't have it out of the box.
I'm not sure how applicable these attack vectors are in the real world, but they affect a very large number of devices for sure.
They are also really capable processors on their own with some nice I/O, and they can be integrated to be really low power so things can run on battery power for months to years.
Can they really last that long (on their own)? I looked into this when the ESP8266 first became popular maybe 4 years ago as I wanted to build WiFi temperature and humidity sensors. My calculations were that a set of AAA rechargable batteries (~2000mAh) would last a few days at most, with the device in deep sleep most of the time and waking up every 10 mins to take a reading and send it over WiFi.
Right now I'm looking to create smart blinds. The motors don't use that much power, but the issue is the MCU listening for commands. The ESP32 support BLE, but it's power consumption is still rather high, so batteries would only last a few days at most.
Personal experience: I have a ESP32 that runs as a sort of weather station. It has a ~2000mAh battery and lasts almost 2 months, getting a data point once every 30 minutes. That is using the ESPHome to program it.
Even at once every 10 minutes, it should manage almost 3 weeks without requiring a recharge.
Some options that definitely help is to quicken the Wifi reconnect. ESPHome has options to disable AP scanning and doing a fast-and-dirty connect&send. Using MQTT also helped a lot compared to using HTTP.
The most important part is to reduce the on-time as much as possible. 30 seconds is still way above the lower limit that I can do. If you halve it you can double the amount of data points without additional energy by reducing the sleep time.
I'm working on replacing the battery with a solar panel and supercap to power it from ambient shadow light entirely, the numbers to agree that it is possible in my case. Would help to keep it alive in cold weather.
Ah ha, that's good to know! Yeah in my case I had a small solar panel (a few quid of eBay, I guess around 1W) which was able to power it through a British winter (it did get direct sunlight though). I had some rechargable AAA batteries and just wired the solar panel in parallel with them.
After a few months it stopped working, I think some moisture got in and the DHT11 failed.
I was able to power ESP-12E based humidity and temperature sensor for about 6 months from 18650 cell. I've used deep sleep and 15 minutes intervals between readings.
Not totally sure about the ESP8266. I used a WiFly RN131 in a sensor product that woke up every 15 minutes and sent a reading. AA batteries lasted probably 18 months.
Biggest problem we found was enterprise networks would randomly kick you off if you were using DHCP. I think because they would assume that if you hadn't transmitted in five to ten minutes it meant you'd gone away. Using static IP fixed that.
Edit: Friend of mine that mucks with ESP8266's uses the low power timer to reset and wake the device up out of deep sleep. (Via a simple hack I think just connecting a timer pin to the reset).
Star-mesh topology, with batteries on the leaf nodes. Solar further in. Excerpt: "I’m expecting about 3 months at a 5min log interval using a 2000mAh lipo battery."
on Amazon the 4 pack listing has 548 customer reviews and there are other listings with hundreds of reviews and probably lot more people bought it than the reviews.
I'd say Espressif has a near monopoly due to first comer advantage.
There are way, way more moneyed companies in the wifi MCU game, but I have not seen a single competitor chip outside sales demos yet.
Redpine had big dotcoms backing, but it seems that even they dropped the ball on them in favour of Chinese chipmakers. Amazon and Google recently reached out for MXCHIP and Espressif, and their Redpine based solutions never went beyond the tech demo stage.
Realtek has the RTL8710, which is a lot like the ESP8266 but with an ARM Cortex-M3 (while Espressif uses the rather obscure Xtensa architecture), which has the advantage of getting an LLVM toolchain for it, which means you can program it in Rust (while the ESPs are mostly limited to C).
The real advantage of the ESP8266 however is its raw popularity. It has an Arduino environment, tons of ready to run sketches, Basic, Javascript, Lua and Python interpreter environments and lots of interesting projects already done with it.
The ESP32 follows right in its foot steps with even more features, power and power saving features. Espressif really saw the market the DIY community means and did some minor tweaks to its policies to cater to it, which probably helped its popularity with commercial hardware makers as well.
I heard of Realtek,and took a look at it. It still comes with fever RF accessories on package, and thus grows your BOM. And their wireless docs and SDK as a whole are kind of obscure/"Taiwan style"
Plus, since it comes from "another China" it's subject to Chinese customs duty which negates whatever cost advantage it could have.
Realtek has the RTL8710, which is a lot like the ESP8266 but with an ARM Cortex-M3 (while Espressif uses the rather obscure Xtensa architecture), which has the advantage of getting an LLVM toolchain for it, which means you can program it in Rust (while the ESPs are mostly limited to C).
Any recommendations for good, affordable dev boards (say under 20Euro/USD), that are easily available?
(I have been playing with RobotDyn Blue Pills and Rust, but no wireless or Bluetooth connectivity.)
>I'd say Espressif has a near monopoly due to first comer advantage.
No. Espressif is used because it is _cheap_ and has relatively good support libraries. Just the chips/modules from other vendors are usually 15 to 20€ in single quantities while you can get an ESP8266 minimum development board (almost all normal arduino boards are minimum development boards) for like 3€.
Unless other vendors reach that same level, they will always stay back.
We began switching to ESP as our primary platform just around 2 years ago, just as wifi gadgets were starting to boom.
To date, we got 500 megs of MCU project in our repo. Though most of code is repetitive, there is no chance we will part with such a huge codebase.
Being able to complete a $200k project in a few weeks through code reuse, instead of few months is huge, and imagine how it is for bigger companies with own hardware. No chance anybody switching now.
No. It was first comer advantage in affordable wifi MCUs since they existed just fine before but only as more expensive solutions as I mentioned. You can keep on claiming otherwise but the facts don't support you in claiming that there weren't wifi MCUs before.
You are wrong. There were many Wifi MCU solutions available before.
Espressif did not innovate in the technology space but in pricing and having enough documentation available that hackers could piece together an open source toolchain and libs for the chip.
Well that sucks. I have probably 20 esp8266 chips around the house doing various things (when you can get an MCU for like $2, you find a lot more uses!), but I don't think any of them really need to worry about this aside from the DoS attacks taking them offline. I'll need to maybe look into some alerts when they start going offline, but not much.
I'm not familiar with the Enterprise WPA2 stuff. Is it widely used in high security environments or "enterprise" areas? and is the ability to gain control over a device on those networks a big deal?
Enterprise WPA2 always seemed crazy complex, and the fact that many devices can't even seem to do WPA2 Personal completely correctly, I never had a good feeling about the Enterprise stuff.
A few are powered by mains (I have a habit of using them to automate "dumb" appliances. So I put one in a cheap dehumidifier in place of the physical on switch), and the rest with repurposed small lithium ion rechargable batteries meant to be used with drones.
The battery powered ones need to be careful with how they sip power, but in most cases I can rig something up to get them to last. And the batteries I got off eBay all came with their own USB charger, so like 30 minutes of charging every few months and they are good.
I want to look into solar, but I just haven't had time to tinker with it yet.
> I'm not familiar with the Enterprise WPA2 stuff.
WPA2 Enterprise doesn't use a preshared key, instead relying on something like RADIUS Authentication to validate usernames/passwords and then providing a custom key.
If you uses your Active Directory credentials to login to corporate WiFi then you're using WPA2 Enterprise.
Enterprise requires everyone to use a different key while wireless communication in a group wants traffic to be possible between the clients directly and broadcasted. That’s conflicting.
It feels somewhat irresponsible to not have some scare quotes or a disclaimer or something in there. There's probably some people who are just learning about "enterprise TLS" who don't know that it's hobbled: https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s...
Looks like it was a question about where to report it, followed by a handful of suggestions and _then_ the close. I don't see any reason for bad blood from that, especially since there was a bit of follow-on discussion and by the look of it, a fix was released a couple of weeks back.
Yeah, on second read I agree with you. I'm just wondering why the public PoC disclosure before that team had more chance to fix. The arduino-esp8266 folks are super popular in the ESP community.
Re: wifi bulbs: I think most of them just inherently trust WLAN and broadcast to / accept any connections or instructions from WLAN. Especially if they don't connect to cloud at all, it's a fairly simple solution (albeit with low-security too). Basically, your WiFi password is the password.
The fake beacon frame issue is the key one here - relatively few people are using Enterprise WPA2, but ESP8266 (or compatible - such as the Tuya TYWE3S) chips are in all kinds of random low cost IoT devices. I've got some smart plugs which use them, as well as a few of the dev boards connected up to various sensors, so looks like will have some patching to do...
I suppose "relatively few people" is true if you define people the way it would have been understood a century ago. Corporate and institutional systems will almost invariably do WPA2 Enterprise.
Without Enterprise, there's just one magic shared key "password" known to every user of the network.
The Enterprise mode outsources authentication of participants to a separate service using EAP and nearly always ends up leveraging TLS to actually make this secure one way or another.
This enables, for example, EduROAM in which academics and students use their "home" institution credentials to get network access in any participating educational network.
I was talking in terms of IoT devices using these chips - more of them are likely to be on home networks, using WPA2 Personal than in offices using the enterprise version. For offices, wired smart devices or higher end wireless devices are more common, which tend to use custom silicon, rather than COTS modules like the ESP ones. Hue bulbs, for example, don't use ESP derived chips (if only because they need Zigbee rather than WiFi), and not does Lutron kit (z-wave), although Lifx bulbs do.
Home automation on personal networks is certainly a large use case for these devices, but I think you underestimate the number of ESP8266/32 devices that are used in enterprise environments. The Industrial IoT space is pretty big, using small wifi chips like the ESPs for stuff like factory data collection or data center monitoring. I also have personally seen them used in medical device environments and security systems (think wireless door sensors and the like).
The "big boys" probably use custom made silicon (but even then I've seen custom-made silicon with an ESP8266 mounted onto it to abstract out the wifi connection part), but I wouldn't be surprised if the majority of IIoT startups use the ESPs as part of their products.
So if it's the norm to connect to unknown APs with SSID "eduroam" and submit your username and password, can I make a rogue AP that sniffs everyone's credentials? Or is this prevented under Enterprise, e.g. through a pre-shared certificate for the authentication server (which isn't run by the AP host)?
The AP needs to arrange (typically with a RADIUS server) to tunnel the authentication to a remote EAP at the users institution. The local RADIUS server will discover your username (often an email address) but the other credentials used are up to the institution and only delivered there. It will often be MSCHAPv2 which is designed to authenticate Windows passwords, but it could even do X.509 client certificates.
Since TLS ends up in the picture many institutions use the Web PKI, so a typical modern device already understands how to verify that this is the right server for example@example.com to authenticate against, it's the one with a Certificate for the DNS name example.com. But yes, they can do all this with custom certificates instead and I'm sure lots do that.
Yes, you can in principle make an EduROAM service. You should probably talk to whatever higher education or further education IT body exists in your country.
Notice that only academics and students get to access the network, so unless you're either of those things you'll need to also add an escape hatch for yourself and anybody else you want using it. Offering the service to others does not entitle you to any access, it would be only a courtesy to others.
Yeah, I've caused some of these crashes. The IDF needs a lot of work when it comes to some of the stacks.
I've been trying to bring the Bluetooth stack (which shares a common ancestor with the Android one) closer to the current Android Bluetooth stack, since that's well maintained (ish) and I'm extending it.
Maybe, I'll have to look into that. My application is an A2DP enhancement, and I think it would be at least a bit of work to implement an A2DP service in NimBLE; very cool nonetheless, thanks for bringing it up!
ESP8266 is a low-cost Wi-Fi microchip with full TCP/IP stack and microcontroller capability produced by Shanghai-based Chinese manufacturer, Espressif Systems.
ESP32 is a series of low cost, low power system on a chip microcontrollers with integrated Wi-Fi and dual-mode Bluetooth.
some kind of IoT chips? can't tell what the real world impact of this is.
edit: whoa, thanks for context folks! i'm surprised this wasn't obvious from wiki pages.
These are really nice $5 chips with Wifi programmable with the Arduino toolset. Tons of IoT people use these to integrate various instrumentation and control into their houses or science projects. For instance, you can hook one up to a temperature sensor and a relay and control your heater. There are probably millions of these installed, hooked up to important hardware. So this makes wardriving fun again, I guess, if not destructive.
Just to give you some idea of how easy these are to use: In 20 mins with a small breadboard, a few Dupont wires, a Nodemcu ESP8266, a DHT22 with a pull up resister I've got a desk temperature sensor.
If a NodeMCU board is too big for you then an ESP 01S is smaller and even cheaper. Less I/O options though but very useful. Needs a writer and wires to program. You can get one with a relay that is capable of switching 16A.
I don't do Arduino. esphome is a lot easier for me. You use pip to get the thing installed under your user account. Write a .yaml file which is largely copy and paste from examples and then install it through a USB cable the first time and then over the air after that.
The ESP 01S is particularly good once you get to grips with writing to them because you can power them from any old phone charger that spits out 5V. You simply cut off the plug, look for the wire with the white stripe on it to determine polarity, strip the ends and screw into the relay block.
Be prepared to wave goodbye to your spare time and seriously consider a separate VLAN/SSID for these things.
Heh, I came across your site last week, so thank you! (Oh, maybe it's not your site)
I got the DHT22 to work at 3.3V. But an old 1-Wire DS18B20 I have is very finicky. The pullup needs to be 500-800 ohms. Any experience with 1-wire at 3.3V? (Parasitic power mode). Worked great on a 5V nano.
I tend to power my devices via a simple USB phone-charger.
Like the parent I have a few temperature/humidity sensors dotted around the house. Using a PI would be overkill and I'd have to keep the system packages up to date, worry about failing storage-device, etc.
Yep. Most have a micro-USB connector which supplies power, and handles uploading/logging. So when you're done debugging, you just need a phone charger with a long enough cable.
It is a WiFi enabled microcontroller locally designed and produced in china with a "100 million units sold" target. It is widely used by the makers community and by many new "smart" products. I would say that this has a really large scale impact and a lot of people will need to update the firmware.
Anything. From things like nanny cams in a teddy bear that can be remotely hacked. (although more likely that they just had an easy to guess password if they had one at all or other more common vulnerabilities) to smart traffic lights. p.s. regarding the nanny cams: I wish I was making this up: https://www.forbes.com/sites/thomasbrewster/2018/02/21/50000...
AFAIK they are largely used in home-automation systems, especially home-made ones due to their low price, good enough specs and availability on resellers like AliExpress
The silicon vendor Espressif has already patched the last firmware (SDK) of such devices. However, other products that uses this chips with still have to patch against it.
The beautiful part of IoT is how there's billions of devices out in the wild with no upgrade plan.
The ESP chips are OTA capable with example code provided, but that still means vendors have to incorporate the function, provide a way for the device to check for updates, care enough to produce updates, and secure the upgrade mechanism enough that it's not a worse vulnerability than an unpatched device.
This is interesting for screwing up badges at Defcon, but I wouldn't lose too much sleep over it. They're neat devices but not really used for anything critical. I'm also not sure they're being used for a lot of consumer devices. If you war drived a major hackerspace you might reset an led light art project.
They're a lot more ubiquitous than some burner's art projects. While I wouldn't necessarily fret over a light switch crashing, expressif chips are popping up in home security products like SimpliSafe. Likely safe in a home from the WPA2 Enterprise hijack, simply crashing SimpliSafe base stations might lead to fun times.
It's fine to say we want everything as secure as possible. But what about the tradeoff between a system being easy to connect/use and making it so difficult to connect that hobbyist users can't get the device to work.
If you are doing mission critical or life-safety related work with $3 devices, you are doing it wrong. Spend a little more and use something else.
In my case, I am monitoring room temperatures in my house with several ESP8266 devices so I want easy-to-connect features. I don't care about security in this application.
It would be really hard to "clone" a SOC. Since its not a board that you can print for a buck these days, it actually requires a fab to print chips ... which is not something that is common to open source yet.
That being said, the status quo is completely untenable. Connectivity has become the norm in the hardware space, and it is built on a shoddy software foundation. Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability. The results are clear: "the S in IOT stands for security" has become a trope, and connected cameras, locks, washing machines, and many more are getting owned on a weekly basis.
This will change, and whoever cracks this nut will be very successful indeed.