5 ms·

The article is indeed hard to understand on its own. From the linked 2022 paper: BLE sends beacons hundred times per minute, even from phones. For privacy reas

by schobi 2y ago

The article is indeed hard to understand on its own. From the linked 2022 paper: BLE sends beacons hundred times per minute, even from phones. For privacy reasons the Mac addresses are randomized. The attacker can further analyze the beacons for imperfections in the rf signal and get a fingerprint for devices from frequency offsets/drift/iq imbalance. Haven't seen the new paper, but the article suggests the a firmware change can even reduce this attack vector. I guess that introducing further randomization in chipset parameters for each beacon can make this kind of tracking harder still. I doubt that this hides all aspects of fingerprinting and settings stepsizes would still be observable, just harder to track. "Randomization pattern F is this manufacturer gen 2025 devices" My take on this: most of the day, I would not need any beacons at all - maybe there is an intelligent limit on avoiding them? Configurable? Only when unlocked? Only when in motion? Sometimes sending half the beacons would double the time needed for tracking already. Again, this would boil down to "a firmware update could improve privacy"

dylan604 2y ago
> BLE sends beacons hundred times per minute > Sometimes sending half the beacons would double the time needed Great, so still within one second. Not seeing how that's doing anything detrimental to the trackers. Even when walking through a store, 50 tracks per second is really accurate. The best thing you could do to improve privacy from blue tooth trackers is to disable blue tooth
- throwaway562if1 2y ago
  Only within one second if fingerprinting can be done from a single data point. If it takes 10,000 beacons to identify a device with reasonable certainty, doubling that count is significant.
JohnFen 2y ago
> most of the day, I would not need any beacons at all - maybe there is an intelligent limit on avoiding them? My approach is to leave bluetooth (and every other radio, but that's neither here nor there) turned off when I'm not actively using it.
- transpute 2y ago
  Since iOS Control Center no longer turns off (only disconnects) radios, a shortcut/automation can be linked to a Control Center button (e.g. low power mode) status, to control radio power with a single tap.
  - compootr 2y ago
    TIL apple is dumb just... why
    - ComputerGuru 2y ago
      Because turning it back on is faster.
    - sitharus 2y ago
      I’m not saying any of this is _good_, just the rationale for the feature being the way it is. Non-technical people read articles telling them to turn off Bluetooth but they do not understand the consequences of turning off Bluetooth, then Apple gets bad reviews because their IoT door lock “doesn’t work with their phone”, or AirDrop doesn’t work, etc, etc. So the quick access turn off just disables the connections for the day. If you go to system settings and toggle it off there it’s actually disabled. Same for why toggling WiFi in control centre only disables searching for networks. People would disable WiFi then blame Apple for the excess cellular data charges.
mafuyu 2y ago
BLE beacons use advertisement packets with a payload, and at the end of the day, are sent actively by an application (like COVID tracing). With MAC address randomization, it's possible to make them anonymous and untrackable at the protocol level. This paper uses data from the physical layer to pull more metadata to track devices, ie. error and drift in its RF frontend. It's not, not a concern, but it's also not data you'd be able to grab with a normal BLE chipset in sniffer mode. You'd likely need an SDR, and that's what they use in the paper. It's an attack that's on a different level of sophistication and cost. Additionally, I wouldn't worry too much about beacons on their own (at least, in this context). Beacons are just a form of BLE advertisement packet. Your BLE devices need to send out advertisements anyways to let your phone to know they exist and connect to them. I assume this attack works on any advertisement packet (and also data packets to a connected device). Normally, rotating private addresses will mitigate some attacks tracking two devices talking to each other, at the protocol layer. This paper is more just a broader look at what features you can extract at the physical layer with an SDR to identify a specific device or chipset.
- ryukoposting 2y ago
  So, just to get the obvious out of the way, all competent dev teams enable random addresses. It's a no-brainer and it has no effect on the usability of most BT products. Regardless, even if they do that, the payload of the advertising packet is still useful for tracking purposes. You're probably relying on hueristics at that point, but you can also rely on some devices including a service UUID, device name, or some very specific information in the manufacturer-specific data field.
  - mafuyu 2y ago
    Yeah, at the end of the day, you're probably going to advertise with some sort of unique short name (so humans know what to pick in the a connect/pairing menu), and have at least one Service UUID (even if you only expose the juicy stuff after bonding.) But that still pushes it back up to a software policy concern, and it's up to the developers to make the appropriate privacy/security tradeoffs. The only real way around this is to do discovery out-of-band via NFC or QR codes or something. The other detail worth mentioning is that generic service advertisements and beacons will have different behaviors and payloads, since they have different goals. With the former, the device is advertising because it's disconnected and needs to be discovered. Service discovery necessarily means you're sending out some sort of information about what you are. If it only expects to be connected to one device (ie. the phone), it's going to turn off advertising when connected to said phone. You technically don't need to advertise the service UUID either once you're bonded, although I don't think would happen much in practice, as it makes recovering from an unbond event harder. Meanwhile, a beacon is data that is intentionally being broadcast out to the world by an application. The application will probably send out beacons regularly no matter what, since that's usually the point (Find My, COVID tracing, etc.) I would expect companies like Apple to ensure that these advertising packets aren't leaking any identifying information. This is easier to do than the above case, because the goal isn't service discovery, but to intentionally broadcast a piece of (anonymous) info. tl;dr Beacons are fine, especially in comparison to your headphones or smartwatch loudly announcing itself to the world because it's disconnected
mrandish 2y ago
I wanted to know how practical this BT tracking vulnerability is but TFA is terrible so I read the linked 2022 paper describing the potential tracking vuln and found the answer. > "In summary, we find that physical layer tracking of BLE devices is indeed feasible, but it is only reliable under limited conditions, and for specific devices with extremely unique fingerprints, and when the target device has a relatively stable temperature." So, possibly able to track a BT fingerprint, once seen and positively identified by other means, in a given location on a given day but apparently not unique or reliable enough to consistently differentiate that device out of many devices in another place on another day. BTW, the physical layer traits which may be unique enough for tracking are "Carrier Frequency Offset and I/Q Offset".

by schobi 2y ago

dylan604 2y ago

> BLE sends beacons hundred times per minute > Sometimes sending half the beacons would double the time needed Great, so still within one second. Not seeing how that's doing anything detrimental to the trackers. Even when walking through a store, 50 tracks per second is really accurate. The best thing you could do to improve privacy from blue tooth trackers is to disable blue tooth

throwaway562if1 2y ago
Only within one second if fingerprinting can be done from a single data point. If it takes 10,000 beacons to identify a device with reasonable certainty, doubling that count is significant.

JohnFen 2y ago

> most of the day, I would not need any beacons at all - maybe there is an intelligent limit on avoiding them? My approach is to leave bluetooth (and every other radio, but that's neither here nor there) turned off when I'm not actively using it.

transpute 2y ago
Since iOS Control Center no longer turns off (only disconnects) radios, a shortcut/automation can be linked to a Control Center button (e.g. low power mode) status, to control radio power with a single tap.
- compootr 2y ago
  TIL apple is dumb just... why
  - ComputerGuru 2y ago
    Because turning it back on is faster.
  - sitharus 2y ago
    I’m not saying any of this is _good_, just the rationale for the feature being the way it is. Non-technical people read articles telling them to turn off Bluetooth but they do not understand the consequences of turning off Bluetooth, then Apple gets bad reviews because their IoT door lock “doesn’t work with their phone”, or AirDrop doesn’t work, etc, etc. So the quick access turn off just disables the connections for the day. If you go to system settings and toggle it off there it’s actually disabled. Same for why toggling WiFi in control centre only disables searching for networks. People would disable WiFi then blame Apple for the excess cellular data charges.

mafuyu 2y ago

BLE beacons use advertisement packets with a payload, and at the end of the day, are sent actively by an application (like COVID tracing). With MAC address randomization, it's possible to make them anonymous and untrackable at the protocol level. This paper uses data from the physical layer to pull more metadata to track devices, ie. error and drift in its RF frontend. It's not, not a concern, but it's also not data you'd be able to grab with a normal BLE chipset in sniffer mode. You'd likely need an SDR, and that's what they use in the paper. It's an attack that's on a different level of sophistication and cost. Additionally, I wouldn't worry too much about beacons on their own (at least, in this context). Beacons are just a form of BLE advertisement packet. Your BLE devices need to send out advertisements anyways to let your phone to know they exist and connect to them. I assume this attack works on any advertisement packet (and also data packets to a connected device). Normally, rotating private addresses will mitigate some attacks tracking two devices talking to each other, at the protocol layer. This paper is more just a broader look at what features you can extract at the physical layer with an SDR to identify a specific device or chipset.

ryukoposting 2y ago
So, just to get the obvious out of the way, all competent dev teams enable random addresses. It's a no-brainer and it has no effect on the usability of most BT products. Regardless, even if they do that, the payload of the advertising packet is still useful for tracking purposes. You're probably relying on hueristics at that point, but you can also rely on some devices including a service UUID, device name, or some very specific information in the manufacturer-specific data field.
- mafuyu 2y ago
  Yeah, at the end of the day, you're probably going to advertise with some sort of unique short name (so humans know what to pick in the a connect/pairing menu), and have at least one Service UUID (even if you only expose the juicy stuff after bonding.) But that still pushes it back up to a software policy concern, and it's up to the developers to make the appropriate privacy/security tradeoffs. The only real way around this is to do discovery out-of-band via NFC or QR codes or something. The other detail worth mentioning is that generic service advertisements and beacons will have different behaviors and payloads, since they have different goals. With the former, the device is advertising because it's disconnected and needs to be discovered. Service discovery necessarily means you're sending out some sort of information about what you are. If it only expects to be connected to one device (ie. the phone), it's going to turn off advertising when connected to said phone. You technically don't need to advertise the service UUID either once you're bonded, although I don't think would happen much in practice, as it makes recovering from an unbond event harder. Meanwhile, a beacon is data that is intentionally being broadcast out to the world by an application. The application will probably send out beacons regularly no matter what, since that's usually the point (Find My, COVID tracing, etc.) I would expect companies like Apple to ensure that these advertising packets aren't leaking any identifying information. This is easier to do than the above case, because the goal isn't service discovery, but to intentionally broadcast a piece of (anonymous) info. tl;dr Beacons are fine, especially in comparison to your headphones or smartwatch loudly announcing itself to the world because it's disconnected

mrandish 2y ago

I wanted to know how practical this BT tracking vulnerability is but TFA is terrible so I read the linked 2022 paper describing the potential tracking vuln and found the answer. > "In summary, we find that physical layer tracking of BLE devices is indeed feasible, but it is only reliable under limited conditions, and for specific devices with extremely unique fingerprints, and when the target device has a relatively stable temperature." So, possibly able to track a BT fingerprint, once seen and positively identified by other means, in a given location on a given day but apparently not unique or reliable enough to consistently differentiate that device out of many devices in another place on another day. BTW, the physical layer traits which may be unique enough for tracking are "Carrier Frequency Offset and I/Q Offset".