3 ms·

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

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: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/432128 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?

xvector 7y ago
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.
jlujan 7y ago
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. https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/650792 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/p/758149/2801182#2801182 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

xvector 7y ago

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.

jlujan 7y ago

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. https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/650792 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/p/758149/2801182#2801182 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