Google Find My Device

I liked Eddystone https://www.espruino.com/Eddystone before but it's been disabled for sometime now due to abuse.

Now it looks like Google is again trying something similar with the "Find My Device" function:

https://arstechnica.com/gadgets/2023/05/­bluetooth-tags-for-androids-3-billion-st­rong-tracking-network-are-here/
https://blog.google/products/android/goo­gle-android-safety-features/

I'm guessing this would also run through BLE

Has anyone else worked on this? I can't seem to find any documentation on the protocol; I'm guessing once we have docs it should be relatively straightforward(?) to turn a puck into a tracker that shows up in Find My Device. There might be some process to register trackers in order to avoid abuse but that's not necessarily a technical limitation.

I'm guessing this would also run through BLE

Yes, absolutely - I'd be pretty sure it works like Apple's iTrackers - there's some info on that at https://github.com/seemoo-lab/openhaysta­ck

When I first heard about this a few months ago I did try and find info and to reach out to someone at Google, but they didn't know much about it either or who to contact.

If anyone knows about this or has a contact at Google that might be some help please let me know. I'd be very happy to do the legwork to get this in Espruino devices

edit: I just asked someone else - at some point, someone must know about it!

There's a bunch of docs now that appeared on the google developers website: https://developers.google.com/nearby/fas­t-pair/specifications/extensions/fmdn

From quickly skimming through those, it seems that supporting "Google Fast Pair" is a requirement for the normal provisioning process to work, but fast pair requires registering a device with google, and getting a device id and anti-tampering key from them; the key is supposed to be kept private and stored in a secure element - I guess this might clash with having open source firmware :(

However once provisioning is complete (if I understood it correctly) we'd ideally only need to send advertisement frames and not have to deal with a device wanting to connect to us.
Those frames include an "ephemeral identifier" (EID) that is generated using the current time, the exponent of the time between EID changes, and an "ephemeral identity key" (EIK), which the android device usually makes up during provisioning, encrypts with a key used for fast pair, and sends to the device that should be provisioned.
So we'd "just" need to make up a 32-byte EIK, an exponent for the time between EID changes, and an initial timer value, and could then theoretically start sending valid advertisement frames.

Android devices that come across those frames should then start sending their location in a message (couldn't find more info on what that message looks like), that is encrypted using the EID, to googles servers.
That message can be decrypted by someone that knows the EIK, exponent of the time between EID changes and guesses the correct timer value.

The tricky part (or at least it seems to me like that) would be to ask googles servers for encrypted messages, without google deciding that they don't like something other than the find my device app asking for data, and maybe also understanding the contents of those messages.

The sad part is, that if a device that can only send valid advertisement frames (and ignores the rest of the spec) "just works", and getting encrypted messages from googles servers is possible, the whole unwanted tracking protection stuff is utterly useless, because (as far as I understood it) it relies on the device cooperating and only changing its BLE address every 24 hours.

Thanks! That's really interesting!

The whole anti tamper key is a bit annoying - I bet most of these trackers have something like nRF52832 in which doesn't have any kind of private key storage.

So you're saying that potentially it may be possible to skip the whole pairing process and just broadcast using a random EIK, and then you can query based on that? Or I guess Google will only handle EIKs that have been registered with it?

... the mention of a 'message' that can be decrypted sounds super exciting - but I don't see any message of it in the advertising frame format? So maybe that's just something to do with the 'message stream' bit?

The sad part is... it relies on the device cooperating and only changing its BLE address every 24 hours.

You mean if someone were to make a device that changed it's address more often, it'd totally sidestep it?

I guess the same is probably true for airtags? If you used OpenHaystack (or just cloned airtags) and had say 4 tags, and just cycled to the next every hour, it would probably think you weren't being tracked?

the mention of a 'message' that can be decrypted sounds super exciting, but I don't see any message of it in the advertising frame format?

By message I meant the stuff that a phone generates when it sees the tag. So probably current location of the phone, encrypted with the EID that the tag is advertising. Some more info on what such a message looks like, and what it actually contains, might be really interesting, but I've kind of given up on finding any, at least for now.

Or I guess Google will only handle EIKs that have been registered with it?

That's the thing: There doesn't seem to be anything, aside from the EIK, that allows someone to identify a tag, and ideally Google doesn't know the EIK; otherwise they'd be able to decrypt those messages containing location info on the server side, which they claim is not possible here, in the section about end-to-end encryption.
But I'm betting my (at least two) blocked Google accounts, that I created for using in the work profile of my phone, that there's some kind of login requirement 😅

I guess the same is probably true for airtags? If you used OpenHaystack (or just cloned airtags) and had say 4 tags, and just cycled to the next every hour, it would probably think you weren't being tracked?

Well, there is this project: https://github.com/positive-security/fin­d-you that claims to do pretty much exactly that. The last update was more than two years ago, so it may be outdated by now.

Usually devices should change their address and EID every 1024 seconds anyways, to fulfill the requirement that your stuff cannot be tracked by someone else.
I guess you could also change the tx power to simulate getting closer and further away, stop sending advertisements entirely for a period of time, or vary the time between advertisements in some way ¯\_(ツ)_/¯

Interestingly the Pixel 8 can apparently still be tracked if it is powered off, using "specialized Pixel hardware" (first section).
So, depending on how much that "specialized Pixel hardware" can do, Google may need to officially support a device that can only send advertisements.

But I probably just missed something, and unwanted tracking protection is a little more advanced than relying on the tag being nice :)

So you think doing all the crypto stuff on a Puck.js would be feasible?

Ahh - I misread the messages thing. That's a shame - I still can't believe nobody at Google thought to allow devices to advertise any data (even a few bytes).

Google doesn't know the EIK; otherwise they'd be able to decrypt those messages

Well that's an interesting thought! That's probably how it works though - any EIK really will be automatically pushed through Google's network, but maybe you'll only be able to query an EIK via Google, so it'll have to be a device that you have paired with them?

unwanted tracking protection is a little more advanced than relying on the tag being nice :)

I wouldn't bet on it :) I guess they're really just trying to catch the 99.9% of people that just buy a tag off the shelf. If you really want to track someone you can get a GPS and LoRa radio and look it up and nobody can do anything about that.

So you think doing all the crypto stuff on a Puck.js would be feasible?

I haven't had time to delve into it too deeply, but it all sounds pretty feasible. I'd be pretty sure they would have targeted nRF52832 as it's so prevalent, and ideally maybe even low enough you could get to a 52810 where the price really drops.

I've got people using Puck.js with signed keys that rotate every hour or so already (and we already support SHA256 and AES), so I don't see this being a huge issue - it's just navigating all the docs and finally making it work :)