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"
> 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
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.
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.
I suspect if many people knew how much their phone was broadcasting to the world around them they'd be quite unhappy. I know I'm rather disgruntled at how much my phone talks and how little I can control it outside of manually toggling it on and off with use.
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.
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
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.
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.
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".
I think they have linked to the wrong paper. This paper https://cseweb.ucsd.edu/~schulman/docs/oakland24-phyobfuscat... more closely matches the article and it explains that the obfuscation is possible due to the TI CC2640 having a variable frequency synthesiser which has 16 bits of resolution. It's a clever technique but I'm not sure it is easily implemented on other chipsets. And this is only valid against one fingerprinting methodology: carrier frequency offset (CFO), there are other fingerprinting techniques which are more difficult to defend against.
There are many flaws in the paper's approach. There is much literature on this already, it has been investigated for decades. Much of the fingerprinting used comes from non-linearities in the RF power amplifiers, not the frequency.
Most Bluetooth being GFSK means the TX chain is completely non-linear to begin with, so the frequency error is an easier target for fingerprinting.
That said, most also have ramp-up and ramp-down slopes on the transmission start and end to control and shape the spectral emissions.
So there might also be something to that.
Still a harder thing to fingerprint than frequency errors relating to transmit center frequency and baudrate.
> A possible solution for authenticating IoT devices with limited computing resources when accessing wireless networks is to extract a unique and unclonable identifier of the device.. The effectiveness of the physical layer fingerprint lies in the subtle random differences that occur during the manufacturing process of the device.. The accuracy of Wi-Fi device identification based on physical layer fingerprint features.. can reach 98% for 15 different types of IoT Wi-Fi devices, and 90.76% for 10 network cards, having smaller differences in manufacturing, with the same type of chips.
Of course, if Auto-Join is enabled, the client device broadcasts the Wi-Fi access points it has previously joined, which can be informative without an SDR.
> “This defense can be rolled out incrementally, requiring only software modification on at least one widely-used Bluetooth Low Energy chipset,” said Hadi Givehchian, the paper’s first author and a Ph.D. student in the UC San Diego Department of Computer Science and Engineering. “But in order to deploy this defense widely, we need to partner with Bluetooth chip manufacturers.”
Essentially, this is useless. It doesn’t apply to most chipsets and would require changing the firmware on existing beacon hardware. The chip manufacturers would have put this in the hardware if they wanted it.
>Broadcom bluetooth/wifi chips ran out of firmware hot patch ram slots long time ago. Company seems to be too cheap to respin the rom mask with all the fixes baked in. From what I remember even brand new iphone x ships with no room for BT firmware patching.
This is a very confusing article. Surely it's the beacons that transmit beacons, not phones? And what is the signature based on? What is the fix? Terrible reporting.
In any case I doubt this has much practical impact given you presumably need an SDR to do this tracking.
Phones can also transmit beacons. The same as laptops, actually, some of them constantly broadcast BLE beacons.
The signature is based on physical layer characteristics, according to the linked paper : « They result in two measurable metrics in BLE and WiFi transmissions: Carrier Frequency Offset (CFO) and I/Q imperfections, specifically: I/Q offset and I/Q imbalance. ».
Yes, you would probably need SDR to do this tracking, but SDR are generally not this expensive.
> Mobile devices, including phones, smartwatches and fitness trackers, constantly transmit signals, known as Bluetooth beacons, at the rate of roughly 500 beacons per minute. These beacons enable features like Apple’s “Find My”--a tracking service to find a lost device as well as COVID-19 tracing apps; and connect smartphones to other devices such as wireless earphones.
> The current approach taken by smartphone companies to make the devices hard to track by their Bluetooth signals is to randomly change the phone’s identity, its MAC address. However, that doesn’t address the physical-layer fingerprints inherent in each device’s transmissions due to unique hardware imperfections.
> All wireless devices have small manufacturing imperfections in the hardware used to emit these beacons that are unique to each device. These fingerprints are an accidental byproduct of the manufacturing process. These imperfections in Bluetooth hardware result in unique distortions, which can be used as a fingerprint to track a specific device.
For example, your first question exposed that you had a misconception of what "beacon" means, and the first sentence of these excerpts is exactly an utter layperson definition of what "beacon" actually means.
I don't know how you can say "I read the article" and then read these bits yet a 2nd time, and still claim to have those questions.
> given you presumably need an SDR to do this tracking.
SDRs and the software to make good use of them are cheap and readily available. Using them is well within the ability of almost everybody. All you need is the desire.
I’m with you: I read the link and think they are referring to BLE advertisements. The frequency of such advertisements is configurable. AIR, the advertisement interval has to be a multiple of 0.625msec. Per the spec, a random delay of 0-10msec is added in between the interval to aid in collision prevention.
I’ve mainly seen “BLE beacon” used to refer to types of devices, especially ones that primarily advertise.
There are some devices, like BLE-based remote controls, that advertise very frequently, I assume to reduce latency between a user’s action and response by the receiving device. It makes for a very noisy environment if you’re playing at home and not filtering based on MAC, etc.
> The current approach taken by smartphone companies to make the devices hard to track by their Bluetooth signals is to randomly change the phone’s identity, its MAC address. However, that doesn’t address the physical-layer fingerprints inherent in each device’s transmissions.. All wireless devices have small manufacturing imperfections in the hardware used to emit these beacons.. These imperfections in Bluetooth hardware result in unique distortions, which can be used as a fingerprint to track a specific device.
Hey, I admitted it. I see a number of others that didn't. Looks like a number of folks didn't read it, and there's a number of others that are taking great glee in pointing it out.
There's utility in promptly admitting when we're wrong.
Maybe people downvoted you for choosing to attempt humour in your mea culpa while not bothering to either thank the person who took time to answer you nor apologise for wasting their time. Though I'm not a mind reader, maybe that's not why they felt downvotes were warranted and only I had that thought.
Nah. I sincerely want to contribute, and deserved the downvotes. I could have deleted it, but didn't, because I think folks around here could probably use some object lessons, on what admitting error looks like.
I didn't waste anyone's time. They were more than happy to ding me. In fact, there's few things that geeks like doing, more than telling other geeks, they are wrong, so I maybe did a public service.
I'll do humor, and, if people want to get butthurt, they'll bang on the down button, just like they always have.
I'm not sure what you're saying "nah" to, you didn't seem happy that your (second) comment had been downvoted, I explained why people may have downvoted it (and why I agree with them, though it was already grey when I arrived). If you really don't care about the downvotes then that's good but you can skip commenting about them next time. If you do care about them, react by not posting comments that waste people's time rather than complaining about it.
(Unless I was wrong to read "I don't know why people are downvoting my mea culpa" into this comment - https://news.ycombinator.com/item?id=40961512 - but I can't think what other meaning it could have in the context of replying to your own comment which had been downvoted).
Regardless, I won't bother coming back to this thread as I've wasted enough time myself by choosing to comment to not care further.
Maybe you're running an old version (or not BLE). It's been doing it for a long time. Same with a lot of other types of devices, I'm sure. It's standard security practice, these days.
I've written BT software[0], and it always randomizes it. I don't think it randomizes for every transaction, but it does use different UUIDs, when I run the device at different times. You can't switch the UUID, after establishing a connection.
I did look, back when, but it’s been a few years, since I wrote that, and it hasn’t really been a priority.
When I was writing it, I spent a lot of time with a sniffer and WireShark, so I was looking at the raw data.
[EDITED TO ADD] Sniffers are of minimal use, with BLE, since everything gets encrypted, as soon as devices start talking to each other, but you can see the advertisements. I used one, because all the Apple devices seem to have a different opinion, on what's out there. I'd see a device with the Watch, but not the phone or TV, and vice-versa.
I actually submitted a bug report on it, but I don't think Apple ever even looked at it. I'm sure they are well aware of this. I suspect the Apple engineers are probably some of the top BT people in the world.
That doesn't surprise me. I don't think classic can handle changed UUIDs. I didn't really spend much time on Classic.
In any case, I'm pretty sure all BT will look like BLE, sooner or later. I know that they are already starting to implement high-bandwidth BLE, and that's about the only reason to use Classic.
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"