1. At setup, Find My generates private key shared to all your Apple devices.
2. The private key generates a perpetual sequence of public keys. These change (iterates to the next) "frequently".
3. The rotating public key is shared accross all (including other people's) Apple devices via Bluetooth and can even do this when it's off.
4. The shared scheme pings to Apple's central system and uploads A. hashes of the public keys in the area and B. the location.
5. When you try to find a device you send your hashed public key to Apples server and they return the last picked up location (encrypted). (You thus need at least 2 Apple devices, one to find the other. Also, they don't say how the previously iterated public keys are remembered.)
This seems very very impressive. But I have so many questions still. The most important one being, there has to be a way to reset these tracking keys for cases like
- Resell
- Loss of a companion device that was never found and it took the private keys with it
- Got a new companion device
How do I reset the keys and how do I make sure a theif can't reset these?
It feels like that can be exploited in some ways. As a first thought it reduces the privacy of the reporting 3rd party phone. I.e. I can leave a fully charged phone in my wife’s car and track her for weeks while she will have the burden to recharge her phone for network/gps power.
A regular gps tracker would need much more energy.
Edit: another scenario, leave it in an isolated hut. If I get a signal, someone is close to the hut.
Edit 2: if I piggy back the protocol and can manipulate the key schedule (chose key A or B) then I can leak one bit of information through the third party phone. The third party phone may be allowed to communicate while my sender isn’t.
Another scenario, leave it in an isolated hut. If I get a signal, someone is close to the hut.
You could do that already with a device, just by making an app that listens for Bluetooth or WiFi traffic. You’d also be able to grab MAC addresses of the nearby phones. Your ‘exploit’ isn’t revealing any more than you can already discover today.
Anecdotally: a friend of mine left his iPad in his wife’s car. When looking for through Find My iPhone, he realized that she’s at her ex-boyfriend’s place. He is married happily to another wife now...
You can already do this with a Tile. Leave a Tile in your wife's car and every phone with the Tile app in her vicinity will report her location to you.
This mechanism is very low power, and it allows making tiny devices that can be used for tracking suspects. Maybe this is actually why they made it (someone asked if they could make it).
Edit: Maybe Apple will introduce tiny key fobs that can be tracked so you can find your keys or other things.
If you have a subpoena to sniff data to Apple from device X then you can use that to some extent track the location of X by spreading your Tags T_1,...,T_n in interesting places. If X reports T_i you know the location of X, this could be more precise than the usual cell phone tracking because X reports its position with GPS precision.
I am reminded of a section in Neal Stephenson's The Diamond Age where (some guy) takes a whole day to track the history of the young protagonist in an internet cafe - and an explanation of passing packets between passing devices as if handing parcels to random strangers as they walk down the street always stuck in my mind
This seems to be saying that Apple has a big mesh network play ready sometime soon.
Want to bet they have a good idea of coverage already and need some testing - they might not be able to see your location but they will see the location of every phone passing your public key encrypted bits back - they get to test their mesh network ? Or am I missing something?
> see the location of every phone passing your public key encrypted bits back
My understanding is that (in this scheme) all location data is encrypted by keys unknown to apple, i.e. the reporter uses the lost device’s public key to encrypt its location and transmits it together with the hash of the key.
Is this scheme where the public key can somehow rotate on it's own, while still being decryptable by the unrotated private key a new thing?
I had not heard of it before.
Edit: This other comment in the thread points at an article with some guesses as to how it might work. It mentions a system called Elgamal that has a scheme somewhat like my description above: https://news.ycombinator.com/item?id=20134956
If the phone is broadcasting the public key couldn't some malicious actor simply send the wrong location? Also couldn't they simply put it in a faraday bag or wrap in some tin foil?
There is always the risk of rogue employees, but what they're probably talking about here is that they also can't be compelled to reveal the location by someone else. They probably don't want to actually say that since it might be misconstrued as trying to skirt the law or being uncooperative with law enforcement.
The feature of rotating public keys to enhance privacy is already used in cryptocurrencies, especially in the underpinnings of Monero. Here's one thread discussing how to make a mechanism to generate new public keys on demand: https://crypto.stackexchange.com/questions/58022/a-method-to...
Instead of only finding the location of my stolen device, what I really would like is using this to remote wipe my device, before someone else can or will turn it on (if it has been turned off).
Because it is not like I will fly to some other country to catch the thief or new owner of my stolen device.
That's a feature of Find My, and has been for years on iOS. They're bringing it to macOS this year for devices with a T2 chip (the newer MacBooks, basically).
I keep reading that Apple already randomises MAC addresses for privacy purposes, but then how do its devices stay logged in to 'captive' WiFi, or more problematically, paired with Bluetooth devices?
Are the addesses only randomised for broadcast / new pairs?
Is the connectivity layer considered: Is the 3rd party "proxy" handler uploading the information using an Apple ID? Does Apple record, store IP information? It seems to me that by using this system you volunteer to send data to Apple constantly which may not reveal your GPS location but will reveal your network location.
I'm happy to see someone trying to innovate in this space. I still wonder if it is okay for journalists and risk affected users to use this or if they should be advised to avoid it.
>Matthew Green, a cryptographer at Johns Hopkins University. "Even if I tracked you walking around, I wouldn’t be able to recognize you were the same person from one hour to the next."
Thos sounds like a great way to track shoppers in, for example, a shopping mall.
If the BLE beacon is broadcasting at a predetermined rate this may also extend tracking past the rotation of keys right?
They aren’t using your social graph, they are using location proximity and transmitting the data inside existing packets sent to cell towers for connectivity purposes. There’s already a ton of information passing to cell towers to identify and negotiate connections with phones that could be used to infer your social graph. You’d have to correlate that with a geo location database that knows about what type of locations you visit as there would be tremendous amounts of false signals at public places like restaurants and malls.
Long story short, Apple, cell tower operators, and mobile providers already have all the data they’d need to make these graphs. If this functions as designed, it will contain much less information and wouldn’t be useful for this purpose (I.e. encrypt requests and don’t pass IP info with them to any systems that have the ability to decrypt them. If you make a few hops to the systems which have the ability to decrypt them and don’t share correlation IDs or the origin IP, there’s no way to correlate these requests back to which device sent them or what IP or cell tower it had).
This was to be expected, given that apple has been slowly taking away the ability to physically turn off your device. Isn't anyone else concerned about the fact that a shutdown laptop will continue to broadcast defying convention and expectations?
That’s not so bad considering that right now, if you don’t have a network connection (say a non-cellular iPad) you can’t find your device AT ALL unless it’s on Wi-Fi.
The Wired article is not detailed enough to definitively poo-poo this scheme, but I am pretty skeptical about some of the claims, given a) how easy it is to map an IP to a coarse location, b) how easy it is to map many IPs to a small number of already-known humans/users.
That is to say: the asym crypto may strongly protect the precise (GPS or LTE triangulation) location from Apple and from others, but I do not see how a cloud-based system can ever hide coarse location from Apple and/or from governments as, given the short range of BT, they can reliably infer that a device (and hence its owner) is/was near whatever IP sends the encrypted precise location to their cloud. Then it's just a matter of mapping the device's "randomized" ID back to an actual user/phone. That seems easy enough as soon as a second device accesses it from an IP that's mappable to a specific residential address, Apple account, etc.
e.g.
A and B both log into iTunes or some other Apple service using [email protected] and [email protected] from HOMEIP at some point in the past. HOMEIP is never used by any other Apple accounts.
A(lice) and B(ob) exchange a secret and otherwise begin participating in this "private" tracking scheme.
A goes out shopping and while there it pushes its encrypted precise location to the Apple cloud, using random ID 424242, from MALLIP. Perhaps A's device sends it directly, or perhaps it's relayed from BT to Mall wifi to Cloud by C's device if A has both LTE and wifi disabled.
A few minutes later S(omeone) requests encrypted location for random ID 424242, from HOMEIP.
Apple (and any government compelling it to share information) can reliably infer that "Someone" was A or B attempting to track either B or A, and that the tracked phone was at/near the business address of MALLIP - their coarse location - even if they can't decrypt the precise location without the secret key. If you know from public records that A and B are married, and assume that women are more likely to be at a mall on their own than men, you may further assume that A is at the Mall while B is at home.
Result: the "private"/"encrypted" precise location beaconing has an unfixable metadata side channel that will leak coarse location data to Apple and to any governments that compell it.
What you're saying is basically that this scheme will leak the IP address you're on, because that's just how the internet works.
There's... not much that can be done about that, and there's no need for the scare quotes on the words private or encrypted. Any encrypted communication still uses an IP address that can be mapped to a coarse location; this isn't an Apple related thing.
If you want to be able to find your device (it's opt-in), it needs to relay its location via the Internet. Doing so requires an IP address, which can indeed be mapped to a coarse location in some cases (my own home IP address is totally useless, it says I'm in London when I'm on the other side of the country). I'm not sure what the big deal is.
If the gateway used to receive these requests cannot decrypt them and they pass through other connections before decryption, why wouldn’t this be possible? At the point of decryption you’d have the connecting IP of the last hop but if the origin IP isn’t forwarded, and there’s no request correlation ID or other identifying information, the machine processing the request wouldn’t know where the original request came from.
Of course any of the intermediate machines could be tracking this data for correlation purposes but it should be possible to strip it along the way.
If the request data containing the 424242 is encrypted and only the machine without origin info has access to that identifier, how would you know the request is for 424242?
[+] [-] mikorym|6 years ago|reply
1. At setup, Find My generates private key shared to all your Apple devices.
2. The private key generates a perpetual sequence of public keys. These change (iterates to the next) "frequently".
3. The rotating public key is shared accross all (including other people's) Apple devices via Bluetooth and can even do this when it's off.
4. The shared scheme pings to Apple's central system and uploads A. hashes of the public keys in the area and B. the location.
5. When you try to find a device you send your hashed public key to Apples server and they return the last picked up location (encrypted). (You thus need at least 2 Apple devices, one to find the other. Also, they don't say how the previously iterated public keys are remembered.)
[+] [-] omk|6 years ago|reply
- Resell
- Loss of a companion device that was never found and it took the private keys with it
- Got a new companion device
How do I reset the keys and how do I make sure a theif can't reset these?
[+] [-] lixtra|6 years ago|reply
A regular gps tracker would need much more energy.
Edit: another scenario, leave it in an isolated hut. If I get a signal, someone is close to the hut.
Edit 2: if I piggy back the protocol and can manipulate the key schedule (chose key A or B) then I can leak one bit of information through the third party phone. The third party phone may be allowed to communicate while my sender isn’t.
[+] [-] joosters|6 years ago|reply
You could do that already with a device, just by making an app that listens for Bluetooth or WiFi traffic. You’d also be able to grab MAC addresses of the nearby phones. Your ‘exploit’ isn’t revealing any more than you can already discover today.
[+] [-] baxtr|6 years ago|reply
[+] [-] amelius|6 years ago|reply
You could do the same thing with a regular phone with an app that uses GPS. Just attach a powerbank if you're concerned about the power.
[+] [-] rando444|6 years ago|reply
To me just the fact that these things are on when you ask for them to be off is problematic.
[+] [-] lurking_around|6 years ago|reply
[+] [-] Atheros|6 years ago|reply
[+] [-] Geee|6 years ago|reply
Edit: Maybe Apple will introduce tiny key fobs that can be tracked so you can find your keys or other things.
[+] [-] lixtra|6 years ago|reply
[+] [-] lixtra|6 years ago|reply
[+] [-] threeseed|6 years ago|reply
Far easier and more reliable than using a phone.
[+] [-] m463|6 years ago|reply
I wonder if you can turn off "Find My" just like "find my iphone" and it will prevent these sorts of things.
[+] [-] zer0gravity|6 years ago|reply
No guarantees are provided that this network, under Apples's exclusive control, won't relay other type of information.
[+] [-] lifeisstillgood|6 years ago|reply
This seems to be saying that Apple has a big mesh network play ready sometime soon.
Want to bet they have a good idea of coverage already and need some testing - they might not be able to see your location but they will see the location of every phone passing your public key encrypted bits back - they get to test their mesh network ? Or am I missing something?
[+] [-] parrellel|6 years ago|reply
Someone needs to push mesh networking on a more consumer level, if it has to be Apple, so be it.
[+] [-] lixtra|6 years ago|reply
My understanding is that (in this scheme) all location data is encrypted by keys unknown to apple, i.e. the reporter uses the lost device’s public key to encrypt its location and transmits it together with the hash of the key.
However, apple seems to be able to infer proximity of two reporters, as described here https://news.ycombinator.com/item?id=20135995
Edit: except if the Lost device is controlled by Apple, then they can decrypt the location of the reporting device.
[+] [-] RcouF1uZ4gsC|6 years ago|reply
https://blog.cryptographyengineering.com/2019/06/05/how-does...
[+] [-] xattt|6 years ago|reply
[+] [-] tyingq|6 years ago|reply
I had not heard of it before.
Edit: This other comment in the thread points at an article with some guesses as to how it might work. It mentions a system called Elgamal that has a scheme somewhat like my description above: https://news.ycombinator.com/item?id=20134956
[+] [-] knolax|6 years ago|reply
[+] [-] convivialdingo|6 years ago|reply
I’d suspect they’re using something similar to Moxie’s Double Ratchet algorithm since it’s got some years of real world usage.
https://en.m.wikipedia.org/wiki/Double_Ratchet_Algorithm
[+] [-] StavrosK|6 years ago|reply
[+] [-] ape4|6 years ago|reply
[+] [-] bonestamp2|6 years ago|reply
[+] [-] nayuki|6 years ago|reply
[+] [-] tomputer|6 years ago|reply
Because it is not like I will fly to some other country to catch the thief or new owner of my stolen device.
[+] [-] zapzupnz|6 years ago|reply
[+] [-] OJFord|6 years ago|reply
Are the addesses only randomised for broadcast / new pairs?
[+] [-] nerdbaggy|6 years ago|reply
[+] [-] cyphunk|6 years ago|reply
I'm happy to see someone trying to innovate in this space. I still wonder if it is okay for journalists and risk affected users to use this or if they should be advised to avoid it.
[+] [-] taxidump|6 years ago|reply
Thos sounds like a great way to track shoppers in, for example, a shopping mall.
If the BLE beacon is broadcasting at a predetermined rate this may also extend tracking past the rotation of keys right?
[+] [-] lixtra|6 years ago|reply
[+] [-] sansnomme|6 years ago|reply
[+] [-] nonamechicken|6 years ago|reply
https://weather.com/apps/ibm/meshnetworkalerts
[+] [-] slim|6 years ago|reply
Supposing apple can't infer the precise location, of every user, they still can infer the social graph
[+] [-] dkoston|6 years ago|reply
Long story short, Apple, cell tower operators, and mobile providers already have all the data they’d need to make these graphs. If this functions as designed, it will contain much less information and wouldn’t be useful for this purpose (I.e. encrypt requests and don’t pass IP info with them to any systems that have the ability to decrypt them. If you make a few hops to the systems which have the ability to decrypt them and don’t share correlation IDs or the origin IP, there’s no way to correlate these requests back to which device sent them or what IP or cell tower it had).
[+] [-] callmeal|6 years ago|reply
[+] [-] dalyons|6 years ago|reply
[+] [-] paxys|6 years ago|reply
[+] [-] snorrah|6 years ago|reply
[+] [-] contravariant|6 years ago|reply
[+] [-] MBCook|6 years ago|reply
[+] [-] tyingq|6 years ago|reply
[+] [-] mekazu|6 years ago|reply
[+] [-] rphlx|6 years ago|reply
That is to say: the asym crypto may strongly protect the precise (GPS or LTE triangulation) location from Apple and from others, but I do not see how a cloud-based system can ever hide coarse location from Apple and/or from governments as, given the short range of BT, they can reliably infer that a device (and hence its owner) is/was near whatever IP sends the encrypted precise location to their cloud. Then it's just a matter of mapping the device's "randomized" ID back to an actual user/phone. That seems easy enough as soon as a second device accesses it from an IP that's mappable to a specific residential address, Apple account, etc.
e.g.
A and B both log into iTunes or some other Apple service using [email protected] and [email protected] from HOMEIP at some point in the past. HOMEIP is never used by any other Apple accounts.
A(lice) and B(ob) exchange a secret and otherwise begin participating in this "private" tracking scheme.
A goes out shopping and while there it pushes its encrypted precise location to the Apple cloud, using random ID 424242, from MALLIP. Perhaps A's device sends it directly, or perhaps it's relayed from BT to Mall wifi to Cloud by C's device if A has both LTE and wifi disabled.
A few minutes later S(omeone) requests encrypted location for random ID 424242, from HOMEIP.
Apple (and any government compelling it to share information) can reliably infer that "Someone" was A or B attempting to track either B or A, and that the tracked phone was at/near the business address of MALLIP - their coarse location - even if they can't decrypt the precise location without the secret key. If you know from public records that A and B are married, and assume that women are more likely to be at a mall on their own than men, you may further assume that A is at the Mall while B is at home.
Result: the "private"/"encrypted" precise location beaconing has an unfixable metadata side channel that will leak coarse location data to Apple and to any governments that compell it.
[+] [-] moreira|6 years ago|reply
There's... not much that can be done about that, and there's no need for the scare quotes on the words private or encrypted. Any encrypted communication still uses an IP address that can be mapped to a coarse location; this isn't an Apple related thing.
If you want to be able to find your device (it's opt-in), it needs to relay its location via the Internet. Doing so requires an IP address, which can indeed be mapped to a coarse location in some cases (my own home IP address is totally useless, it says I'm in London when I'm on the other side of the country). I'm not sure what the big deal is.
[+] [-] dkoston|6 years ago|reply
Of course any of the intermediate machines could be tracking this data for correlation purposes but it should be possible to strip it along the way.
If the request data containing the 424242 is encrypted and only the machine without origin info has access to that identifier, how would you know the request is for 424242?
[+] [-] bluesign|6 years ago|reply
- A and B connect from same home network with their apple IDs - B checks location of someone (you assume it is A) - so we have A’s coarse location
Depending on implementation details, this randomIDs you mentioned not needed to be same when submitting and querying (and probably not)