[HN Gopher] Firmware update hides a device's Bluetooth fingerprint
       ___________________________________________________________________
        
       Firmware update hides a device's Bluetooth fingerprint
        
       Author : transpute
       Score  : 105 points
       Date   : 2024-07-14 05:01 UTC (17 hours ago)
        
 (HTM) web link (today.ucsd.edu)
 (TXT) w3m dump (today.ucsd.edu)
        
       | IshKebab wrote:
       | 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.
        
         | arlort wrote:
         | I think they might be referring to ble advertisement packets
        
           | jbgreer wrote:
           | 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.
        
         | Reventlov wrote:
         | 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.
        
         | 0xDEADFED5 wrote:
         | it all makes sense if you read the paper linked at the top of
         | the article.
        
         | codetrotter wrote:
         | From the article:
         | 
         | > 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.
        
           | IshKebab wrote:
           | Yes I read the article. This doesn't answer the questions in
           | my comment.
        
             | Brian_K_White wrote:
             | What is missing?
             | 
             | 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.
        
         | surajrmal wrote:
         | It's a press release, not a white paper. Phones do transmit
         | beacons.
        
         | JohnFen wrote:
         | > 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.
        
       | schobi wrote:
       | 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 wrote:
         | > 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
        
         | JohnFen wrote:
         | > 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 wrote:
           | 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 wrote:
             | TIL apple is dumb
             | 
             | just... why
        
         | mafuyu wrote:
         | 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.
        
       | barbegal wrote:
       | 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.
        
         | RachelF wrote:
         | Thank you for that link.
         | 
         | 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.
        
           | transpute wrote:
           | Could you recommend a good paper on the topic?
        
             | RachelF wrote:
             | Google "umop ew" for a list.
             | 
             | UMOP stands for unintentional modulation on pulse. This
             | will start you off with the foundation papers in the field.
        
       | ChrisMarshallNY wrote:
       | Apple has been obfuscating the bluetooth MAC for a while.
        
         | transpute wrote:
         | From the article:
         | 
         |  _> 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._
        
           | ChrisMarshallNY wrote:
           | Fair 'nuff. I didn't read the article. Fair cop, Guv.
        
             | ChrisMarshallNY wrote:
             | 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.
        
               | swores wrote:
               | 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.
        
               | ChrisMarshallNY wrote:
               | 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.
        
               | swores wrote:
               | 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.
        
         | sulandor wrote:
         | just fired up airmon and cannot reproduce your observation
        
           | ChrisMarshallNY wrote:
           | 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.
           | 
           | https://support.apple.com/guide/security/bluetooth-
           | security-...
        
             | sulandor wrote:
             | > old version (or not BLE)
             | 
             | both actually, but i am seeing unrandomized normal bt
             | beacons.
             | 
             | how about your device?
        
               | ChrisMarshallNY wrote:
               | 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.
               | 
               | [0] https://riftvalleysoftware.com/work/ios-
               | apps/bluevanclef/
        
       | jtrueb wrote:
       | > "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.
        
         | transpute wrote:
         | _> The chip manufacturers would have put this in the hardware
         | if they wanted it._
         | 
         | High-volume device customers of chip manufacturers can make it
         | a requirement, e.g. if their marketing and business model
         | support privacy.
        
       | transpute wrote:
       | Wi-Fi radios can be similarly identified, "Wi-Fi device
       | identification based on multi-domain physical layer fingerprint"
       | (2023),
       | https://www.sciencedirect.com/science/article/abs/pii/S01403...
       | 
       |  _> 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.
        
       | motohagiography wrote:
       | it appears from the article this method of detection is viable
       | until chipset mfgs adopt the randomization technique.
        
       ___________________________________________________________________
       (page generated 2024-07-14 23:00 UTC)