Today everyone will be talking about the newest variant of Spectre: NetSpectre. Leaking arbitrary memory remotely over the network without having to execute code on the machine that is being compromised does sound scary, regardless of whether the maximum throughput to leak memory is 60 bits per hour.

Ever since the paper was released at 6pm yesterday, the world has gone crazy and if you goolge “NetSpectre” everyone has a story about it.

But this is not what I wanted to discuss today. Today I wanted to talk about Bluetooth, one of my favorite topics. A few years ago I did a lot of work on Bluetooth and BLE and witnessed with my own eyes the highly insecure connectivity these technologies offer. If it was up to me, I would not use Bluetooth for connectivity of anything that has security requirements, unless you build yourself a solid extra layer of security yourself and literally turn off all Bluetooth and BLE security features.

Back then, I read a lot about Bluetooth 4.2, back then the “newest” (introduced in December 2014) Bluetooth standard. The disparity between standards world and the real world always fascinates me, and Bluetooth is another example. While the latest “IoT” gadgets announcemhow they are Bluetooth 4.2, with all their great features, Bluetooth 4.2 is actually a “legacy” specification as per the Bluetooth SIG Working Group.

Bluetooth 4.2 introduced LE Secure Connections, an enhanced security framework for BLE to prevent the well known weaknesses of BLE. Among other things, Diffie-Hellman key exchange was to be used to provide a secure pairing process.

Back when I was working on Bluetooth, that sounded so exciting, except that all manufacturers of SoC for Bluetooth and BLE claiming to implement Bluetooth 4.2, did not really implement the entire specification, but only the “mandatory specifications”. I never read in the specifications themselves that LE Secure Connections was optional, but according to the industry, it was.

It was recently discovered how, evven if LE Secure Connections is implemented, the hopes of Bluetooth and, particularly, BLE finally being secure are still just that, hopes. Researchers discovered a bug in most Bluetooth 4.2 implementations, with many devices not sufficiently validating encryption parameters during the secure key exchange, making that key exchange anything but secure. The pairing devices do not sufficiently validate elliptic curve parameters used to generate public keys during a Diffie-Hellman key exchange. The bug affects multiple vendors.

Long story short, once it finally looked like I could perhaps even remotely consider BLE as connectivity option for devices with high security requirements, a bug in the software implementation of the specifications makes LE Secure Connections useless. For now, if you are building a device with high security requirements, do not use BLE. I mean, who would even consider BLE for, for example, a smart credit card?

Happy Friday!