Apple devices listen for BLE advertisements of a certain form to indicate a "Find My" network lost device.
The lost device advertisements mainly contain the public key part of a key pair.
The public key does not fit in the in payload of the advertisements, so it is stuffed into the address field. Edit: Only 46 bits of the full 224 bit public key is stored in the address field.
In general anyone can make a "lost device" advertisement as demonstrated by OpenHayStack[1]. The requirement is the address field needs to be fully controllable.
BLE advertisements have a header that indicates what kind of address is present (specified by 3 bits: Public, NRPA, RPA, Random Static). The lost device advertisements are supposed to be "Random Static", but the researchers found that Apple "Find My" listeners ("finders") will accept advertisements for any address type.
They use this fact to generate the private key part of a public key that matches an existing host adapter BLE address. The host adapter BLE address cannot generally be changed unless user has root/superuser privileges. This step is computationally expensive. However, private keys can be precomputed (rainbow tables) because a large chunk of the address is a manufacturer code (OUI).
> Hold up, how are they generating a private key from a public key?
They are not. They are generating a private/public key pair where the first 46 bits of the public key happen to match the victim's BLE address.
The find-my network then accepts beacons (encrypted with the attacker's private key) from this address, and stores it in iCloud to be retrieved by the attacker via the 46-bit prefix.
They patched the finders, presumably by fixing this:
> The lost device advertisements are supposed to be "Random Static", but the researchers found that Apple "Find My" listeners ("finders") will accept advertisements for any address type.
Expensive computed public key first 46 bits == Victim's BLE address
The Apple FindMy system doesn't (or didn't) validate that the public key being broadcast had ever been manufactured or registered. So anyone with an iCloud account could query the Apple FindMy hashtable for the last observed encrypted payload, which contains the observed location generated by the nearby phone.
If you have root on the victim's device, you don't need the expensive computation step. You just take a public/private keypair of your choice and reprogram the victim's Bluetooth hardware to broadcast that instead.
ok so it seems like 2 attack patterns, one where you can replace the bluetooth on the target device, and another where you can find a matching public key prefix and set up an beacon for it using your own private key ? or am I still not getting that
It was always possible to configure a victim device to be a Bluetooth beacon if you had root on the victim device. You just clone an AirTag to the victim by changing the victim's Bluetooth address (using root access) and start broadcasting FindMy beacons.
What is novel in this attack is that you can use non-root access. You observe the victim's fixed Bluetooth address, and then craft a FindMy beacon that happens to match. Since the FindMy beacon is basically just a public key that the receiver uses to encrypt location data, crafting the beacon is just finding a public/private key pair that matches the victim's Bluetooth address. Since broadcasting a beacon requires less rights (less than root), this is much more broadly exploitable (excluding the expensive precomputation step).
No, they find the victim's MAC and generate a payload to broadcast from the victim's device, which will make the device appear to Apple devices as a genuine Airtag. Apple devices then upload location reports to Apple, and the attacker downloads them. No real Airtags are involved.
They're brute-forcing the generation of a public key using random private keys. The exact private key doesn't matter. The full length of the generated public key doesn't even matter, only the first 46 bits. Since they only need to find a public key matching those 46 bits instead of the full 226 bits, that makes a brute force search possible.
Hm, interesting. 2^46 is only 70 trillion, so yeah, totally computationally feasible. So,
if i understand correctly, they only need a GPU to generate a database of 70 trillion private / public keys? Damn, not bad.
They pregenerate the key pairs. The trojan sends the MAC to the server, and the server looks in its (precomputed) stash of key pairs, to find a public key that matches.
could Android users in a place like NYC/LA/London create a mesh network of "virtual airtags" that virtually follow all the iPhones around the city advertising to each that it is mysteriously being followed endlessly? I would switch to Android to participate. (ok, that's my opsec, i'm already on Android. haha gotcha! that's my opsec, i actually have...)
It's not something I'd do, but there are a number of reasons people might do something like this, including:
1. To demonstrate technical flaws, on a purely technical basis.
2. As political action in opposition to surveillance or inadequate security measures.
3. Interest in loose-knit collaborative systems with emergent effects that people can assemble together.
4. As a fun prank, not thinking enough about how it would affect other people.
5. The point being to hurt other people, and/or to feel power over them. (This is a thing, including by organized groups/clubs on the Internet, but I think it's a small minority, and doesn't apply to the commenter.)
Incidentally, when I started skimming that comment, I thought it might be about organizing a non-proprietary, open network, for the same benefits as Apple users get, which could be great.
That's certainly a more charitable interpretation of their comment than I gave it, perhaps I was unfair though I rather suspect the intent was closer to my reaction than your ideas
Text-based communication, especially informal comment text, are obviously pretty terrible at accurately conveying tone and intent. I like to adhere to the “assume good faith” maxim whenever possible, although that’s increasingly difficult in this polarized age of “Roman salutes.” Anyhow, I personally read their comment as something of a tongue-in-cheek chaotic neutral sort of curiosity.
> "I like to adhere to the “assume good faith” maxim whenever possible"
That's generally my policy too, when I wrote the comment I felt confident that I wasn't missing a less mean-spirited interpretation that they may have meant instead, but it's possible my mood this evening clouded my judgement. If I was wrong, apologies to fsckboy
Maybe an off-the-cuff idea, in curiosity and good-natured mischievousness, and then minutes later, while thinking it through, would realize, oh yeah, that could be bad, whew, sigh, and that's humbling.
Then sometimes the thinking leads from there, maybe from a bad idea to a good idea, or maybe realizing a related thing in the world is also secretly bad, and can we address that.
I use Apple and Android because I like gadgets and technology and software. I dislike anything proprietary. I am up for doing anything to undermine Apple's proprietary products. If Apple has a proprietary means of telling people they are being stalked by stalking devices that Apple also sells, yes, i will do anything to undermine it. And anyway, it's Apple stalking and telling people they are being stalked, not me.
Would you be interested in creating a non-proprietary alternative for functionality people desire (with whatever technical and philosophical differences you want)?
Maybe see it as undermining via creating what you see as good, rather than as destroying what you see as bad?
At this point the best thing is mave sure this is well known. If he has the idea you can bet evil [china, north korea, russia... should come to mind] will too. If I do it I'm harmless but it forces apple to react. If evil does that they will also hide their tracks and so we are less likely to find out while they do their harm.
Apple devices listen for BLE advertisements of a certain form to indicate a "Find My" network lost device.
The lost device advertisements mainly contain the public key part of a key pair.
The public key does not fit in the in payload of the advertisements, so it is stuffed into the address field. Edit: Only 46 bits of the full 224 bit public key is stored in the address field.
In general anyone can make a "lost device" advertisement as demonstrated by OpenHayStack[1]. The requirement is the address field needs to be fully controllable.
BLE advertisements have a header that indicates what kind of address is present (specified by 3 bits: Public, NRPA, RPA, Random Static). The lost device advertisements are supposed to be "Random Static", but the researchers found that Apple "Find My" listeners ("finders") will accept advertisements for any address type.
They use this fact to generate the private key part of a public key that matches an existing host adapter BLE address. The host adapter BLE address cannot generally be changed unless user has root/superuser privileges. This step is computationally expensive. However, private keys can be precomputed (rainbow tables) because a large chunk of the address is a manufacturer code (OUI).
[1] https://github.com/seemoo-lab/openhaystack