Bluetooth privacy: MAC address randomization

not-a-rola

Will GOS implement BT MAC address randomization as it already is with WiFi MAC addresses?

de0u

not-a-rola Will GOS implement BT MAC address randomization as it already is with WiFi MAC addresses?

Unfortunately Bluetooth doesn't use MAC addresses the same way as Wi-Fi. In particular, traditional Bluetooth devices such as many headsets use the other party's MAC address to identify which encryption key to use. So if the GrapheneOS device used a different MAC address the headset wouldn't recognize the GrapheneOS device and re-pairing would be necessary.

Johnnyloans

Some context behind this is needed for all readers to be on the same page. I am not an RF expert but this is my understanding.

Perhaps @grapheneOS will chime in. The OS could selectively enable BTC on demand. (if this is even possible)

tl;dr: There would have to be hardware and software changes to make bluetooth more private.

Classic Bluetooth (BTC) and Bluetooth Low Energy (BLE) are fundamentally different protocols. The distinction is closer to something like Bluetooth vs Zigbee than just improvements built upon an original foundation.

BLE:

The vast majority of headlines are about BLE improvements. Classic BT has only been granted minor tweaks since 2009, similar to the linux kernel 5.10 now on 5.10.252 not making major, compatibility changes.
Most peripherals in the wild--outside of IoT--don't use BLE. (e.g. speakers, cars)
Many are capable of both; however, I am not sure which protocol host devices prefer. (e.g. android, PC, or Apple)
Phones already use a Resolvable random Private Address (RPA) for active BLE scanning. This broadcasted address is changed at fixed or random intervals depending on your phone's BT version. Once you have paired to a device, it can resolve to your random static address which can only be changed on device boot-up according to the BT spec. (BTC doesn't use RPA, it's more static in nature.) (I don't think GOS changes the Random static address; however, as you'll see below, BTC reveals a hardware identifier even if GOS changed it for ble)

Privacy implications

There have been several papers published outlining BT privacy vulnerabilities.

5 years ago, the researchers in the above paper were able to find out the BT address when both protocols were active but it was primarily through bluetooth classic.

1 second of sniffing: 70% success
10 seconds: 100%

The key weakness was that both protocols share the same hardware clock.

They recommended the following:

Major changes in the BT spec, unlikely.
Separate BTC & BLE
Disable BTC while inactive. (Many health devices use BLE, so outright disabling only BLE can cause issues.)
reduce BLE transmit power while using BTC
routine reduction in BLE transmit power
Random intervals for restarting advertisements. (I believe BT 6.1 didn't completely addresses this)

Johnnyloans

Johnnyloans Perhaps @grapheneOS will chime in

@GrapheneOS

not-a-rola

My goal is to avoid tracking by the device's MAC address.

cloop

de0u So if the GrapheneOS device used a different MAC address the headset wouldn't recognize the GrapheneOS device and re-pairing would be necessary.

I'd be happy just to have the ability to change the Bluetooth MAC at all. Even if it causes the phone to forget all its paired devices. Even if it requires a reboot. Even if it's only randomized once, at install time. Anything would be better than what we have now...

Which is: the permanent MAC which is burned into the hardware, persists flashing between stock and GrapheneOS (or other OS), cannot be changed without root (that I know of), and can be read by paired devices, unpaired devices when the phone is discoverable, any nearby devices capable of passively sniffing Bluetooth packets, as well as apps* with Bluetooth permissions.

*: According to the FAQ, "As of Android 10, apps cannot obtain permission to access non-resettable hardware identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial numbers and subscriber IDs," but according to the Android documentation, any app with BLUETOOTH or BLUETOOTH_CONNECT (depending on version) can access the Bluetooth MAC via BluetoothAdapter.getAddress(), even on current Android versions. Can someone clarify?

de0u

cloop I'd be happy just to have the ability to change the Bluetooth MAC at all. Even if it causes the phone to forget all its paired devices. Even if it requires a reboot. Even if it's only randomized once, at install time. Anything would be better than what we have now...

I don't know enough about Bluetooth hardware to know how easy or hard this would be. Also, if it happens to be easy on some Pixel devices and harder on others that might reduce interest on the part of the project for spending developer time.

de0u

cloop According to the FAQ, "As of Android 10, apps cannot obtain permission to access non-resettable hardware identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial numbers and subscriber IDs," but according to the Android documentation, any app with BLUETOOTH or BLUETOOTH_CONNECT (depending on version) can access the Bluetooth MAC via BluetoothAdapter.getAddress(), even on current Android versions. Can someone clarify?

I agree there is room to improve that text. For sure apps can get access to the Wi-Fi MAC address (the Settings app) and IMEI (again, the Settings app). And Google Messages can get access to the IMEI too, if the appropriate toggle is flipped. So I suspect that language means that access to hardware identifiers is gated by permissions, and apps can't access those things unless granted those permissions. I think some time back apps had free access to all of those, and over time permissions are being progressively added for more of them. Also the package manager is over time throwing up more alerts before granting sensitive permissions.

not-a-rola

https://discuss.grapheneos.org/d/7677-bluetooth-address-tracking-and-randomization

https://www.nytimes.com/interactive/2019/06/14/opinion/bluetooth-wireless-tracking-privacy.html

https://jacobsschool.ucsd.edu/news/release/3461?id=3461

https://dl.acm.org/doi/10.1145/3744559