You are reading a single comment by @ssievert and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@ssievert
There's a bunch of docs now that appeared on the google developers website: https://developers.google.com/nearby/fast-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.