Avatar for ssievert

ssievert

Member since May 2024 • Last active Jun 2024
  • 0 conversations
  • 2 comments

Most recent activity

  • in Puck.js, Pixl.js and MDBT42
    Avatar for ssievert

    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?

  • in Puck.js, Pixl.js and MDBT42
    Avatar for ssievert

    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.

Actions