SwaraLink

It’s actually possible to use the debugger on the NRF dev kits to flash/debug custom PCBs with NRF chips. So a separate (more expensive) JTAG debugger is in fact not required.

BLE has a privacy feature that enables MAC address rotation, but it isn't a requirement. Apple products and Android phones use the privacy feature, but other than that most products don't. The possibility of tracking someone via the MAC address of their Bluetooth devices is very real.

But you are correct that regular apps can't address the MAC address of connected Bluetooth devices, so the tracking vulnerability that OP is suggesting isn't really possible.

Apple devices all use a private resolvable Bluetooth address that changes every 15 minutes. That, along with a cryptographic payload, protect against this.

Aside from Apple products and Android phones, most other Bluetooth Products do not use private resolvable addresses, and many have the issue that you describe. The name isn’t always so obvious, but sometimes there is identifiable data that can be read.

Not sure I agree here. Most Bluetooth Low Energy devices (aside from Apple Devices and Android phones) don't make use the privacy feature and therefore their device address can be linked to a specific product. Many Bluetooth products have user accounts attached to them (think fitness trackers and AirTag-like products) meaning that the device address can be tied to a specific user.

Now consider the vast number of “smart nodes” out there (eg street lights) that have multi-protocol connectivity built into them. Whoever controls these nodes can simply scan and log every BLE advertisement that is nearby.

I’m not saying that this is the only way that a person can tracked or that this kind of tracking is definitely happening right now, but it’s a very real possibility.

There’s no actual Bluetooth connection that happens here. The AirTag or other FindMy-enabled device is purely transmitting. The packets being transmitted are Bluetooth Low Energy advertisements (sometimes referred to as “beacons”). Any Apple device can perform Bluetooth Low Energy scanning and can listen for these advertisements, and report what they’ve found to Apple’s servers.

Private resolvable addresses are a BLE thing, but very few devices (aside from Apple products and Android phones) actually use them. It’s a shame, really, because most embedded BLE stacks support the feature.

My company is working on a platform to make BLE product development much easier than it is today, and also to improve the quality of BLE products. We plan to make privacy a standard feature.

It’s a little bit better than that, in that only some nodes rebroadcast everything while you can have lower-power nodes be primarily in transmit mode. But yes, I think the spec could use a lot of improvement.

It does seem like there’s a lot of momentum in the BT-SIG to grow the standard over a long period of time, and there also are a lot of active contributors, so I do expect it to mature in the future.

The Bluetooth Mesh standard actually is based on a Bluetooth 4.0 feature set (basic advertising and scanning), so really any BLE device can support it. The problem is that the software is complicated, so typically only newer devices have software support.

Many chip vendors have BT mesh implementations, including Nordic, TI, SiLabs, Cypress, Dialog, and ST.

Easy to say, and I can’t know for sure exactly what factored impacted Broadcom’s decisions here, but I can tell you that chip manufacturers are under extreme pressure to keep costs down, which means that they may under-spec systems at times. Also, with the long design cycles involved in chip design the patch capabilities may have been decided years in advance, before realizing how much would be needed.

In general I agree with your comment, though it’s a lot easier to say this in hindsight.

Bluetooth has the Secure Simple Pairing (SSP) feature, and Bluetooth Low Energy has the LE Secure Connections feature, which both use Elliptic Curve Diffie-Hellman Key Exchange and therefore is protected against passive eavesdropping. The standard also includes the ability to support authenticated pairing for protection against Man-in-the-Middle attacks; if you've ever had to see if a 6-digit number matches on the two devices that are being paired, then you are seeing the authenticated pairing taking place.

Even though the Bluetooth standard includes these features, many products don't actually use them and simply transmit data without any encryption or authentication procedure. This is particularly a problem with many Bluetooth LE products.

No, iOS devices enable Bluetooth Low Energy advertising pretty much the entire time that Bluetooth is on. This is used for features such as handover and Airdrop (and now for contact tracing, if enabled).

SEEKING WORK AND SEEKING FREELANCER | San Diego, CA | Remote

We are a small consulting and design services firm focused on Bluetooth and Bluetooth Low Energy (BLE) technology. We design Bluetooth products (hardware and software) and assist our clients with all types of Bluetooth-related issues, including power optimization, throughput optimization, security and privacy, interoperability issues, and much more.

The primary embedded BLE platforms/devices that we work with are Nordic nRF52/nRF53, TI SimpleLink CC25xx/26xx, SiLabs Blue Gecko, STMicro BlueNRG and STM32WB, and Dialog SmartBond. We have some experience and are willing to work with others as well

While our main internal technical expertise is in Bluetooth system architecture and embedded software development, we are willing to take ownership of larger projects or even provide full product development services. This includes hardware development, mobile applications, testing and debugging, and IoT system architecture.

We are always looking to grow our network for potential partnerships and sub-contracting opportunities. Here are some areas in which we often need help:

Mobile Application Developers (iOS/Android)- in particular if you have experience writing apps that involve Bluetooth/BLE

Embedded Linux Software Developers- in particular if you have experience with the BlueZ stack

EE/Hardware Developers/PCB Designers- Experience with RF systems and low-power embedded systems is a plus

Cloud Software- AWS, MQTT, general experience with IoT applications

If you are interested in using our services, or interested in potential future partnerships, please contact us via our website, LinkedIn, or email.

Website: https://www.swaralink.com

LinkedIn: https://www.linkedin.com/company/swaralink

Email: info (at) swaralink (dot) com

Nordic provides some easy-to-use tools and examples for encrypting and signing firmware images when using a bootloader for in-field updates. I would expect that most products based on the nRF52 that support firmware updates encrypt the image.

I don't know of any because I haven't tested too many, but LE Secure Connections has been around since the Bluetooth 4.2 spec, which was adopted in 2014. The feature is supported by most single-mode BLE chipsets / stacks that have been released since then. I'd be surprised if there were none that supported it, though I don't know for sure.

Sadly, many BLE keyboards on the market today are still not using the LE Secure Connections feature during pairing. The LE legacy pairing algorithm does not use Elliptic Curve Diffie-Hellman Key Exchange, and is easily susceptible to having the encryption cracked via passive eavesdropping.

That is correct. The vulnerability note clearly states that this only impacts "Bluetooth BR/EDR Core v5.1 and earlier". "BR/EDR" is the technical term for Classic Bluetooth; in other words not Bluetooth Low Energy.

I think the biggest misconception here is the belief that Bluetooth LE beacons are tracking phones. The beacons themselves operate as transmit-only and don’t receive any data and therefore don’t perform any tracking themselves. The more correct way to look at this is that the apps are tracking a user’s location, and the beacons are providing the app with information to determine the current location.

If the app’s knowledge of your location provides some service and the user is opting-in, this shouldn’t be a problem (just like I opt-in to provide Google Maps my location).

The keys here are (1) users should be aware that an app knows your location, and (2) User should have the ability to opt-in to providing my location to the app. The mobile operating systems should do a better job of making the user aware and making it very easy to opt in or out.

Maybe an ideal solution would be where (assuming the user opts-in) the OS automatically controls whether an app has the ability to use Bluetooth locationing when the GPS detects that I’m in a certain area. For example, the Target app is prevented from using Bluetooth tracking most of the time, but when my phone GPS sees that I’m in a Target store it automatically enables it while I’m there, and disables it when I leave.

It's true that only paying companies (associate membership or higher) can participate in working groups and contribute to the specifications, but once a specifications has been adopted it becomes public.

All of the adopted core specifications, profile specifications, and errata documents are public: https://www.bluetooth.com/specifications/

And this article doesn't even mention Bluetooth Mesh. Yes, it's still very new and yet to be deployed to the extent of Z-Wave and ZigBee, but with the ability to directly connect to smartphones Bluetooth Mesh could overtake those protocols in a few years.

With the CC26xx parts you can use a 32kHz RCOSC and get accurate enough timing for BTLE connections, so with the CC2652RB you should be able to have true "crystal-less" Bluetooth LE.