(They are great for makers though, very affordable, lots of features.)
(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.
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.)
Edit: it was for sure SuperMicro and Amazon.
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
This is false. In most western countries governments cant force HW makers to add backdoor.
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.
They can't do that.
It can only compel the release of collected metadata to agencies.
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.
That doesn’t prove they have done it. But arguing they can’t is crazy.
Care to state your belief about the relations between the TLAs and the larger networking and communications firms in the US?
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].
[1] The famous "smiley slide" https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns... or https://slate.com/technology/2013/10/nsa-muscular-program-sp...
[2] https://arstechnica.com/information-technology/2013/11/googl...
I'm not aware of anything that would prevent the court from ordering a vendor to implement features to effectuate surveillance ordered by the court.
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.
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.
Plus Broadcom is a US-based company and can be compelled by the US government to place hardware back doors.
Sadly this isn't a tin foil hat possibility.
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.
[1] https://www.brothers-brick.com/2018/11/05/lepin-ordered-to-s...
[2] https://www.brothers-brick.com/2019/04/28/arrests-made-in-le...
https://github.com/espressif/esp32-wifi-lib/issues/2 https://github.com/espressif/esp-idf/commit/c1396830243b4c8f...
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:
https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...
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?
https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...
They did finally provide a method to use a custom root CA for SSL a year later, https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/....
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.
[edit] spelling, clarity
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.
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.
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.