Google Find My Device Network implementation

[Nareshpatel]

Hello, 

I need to implement Find My Device for nRF52833. 

From Sample I could find "samples/bluetooth/fast_pair/Locator Tag" example. I tried to go through it. but I could not able to map with fast pair specification(Fast Pair  |  Google for Developers). 

I want to check in which function advertisement is prepared ?

How keys(account keys,anti-snoofing keys) are sent in encrypted ?

In the advertisement which data we are sending(like fast pair UUID, Model id, anti snoofing keys, unique mac address,salt field ) etc ?  

[PaKa]

So the locator sample in the nRF Connect SDK includes all the mandatory features to make a FMD tag. There are restrictions on what you are allowed to do with the transmitted frames when using FMD, this as the solution should not allow user to track the devices outside the FMD ecosystem. Devices are uniquely identified on the device owner device side, not on "any device" side. This is again to protect privacy.

Adding the MAC address to the frame would break privacy hard so I would seriously doubt that will be allowed to do.

The Google FMD spec is available in the open so if you want to modify the frames then I suggest checking that before determining the solution.

Can you share why you want to do this? There may be other ways of fixing it than transmitting the MAC address.

[Edvin]

The MAC address is part of every advertising packet, but it is not part of the payload in RAW data. 

I am not sure exactly what Google requires you to include in the fast pair advertisements. I guess it depends on the use. It seems that at least you need to include the Service UUID of the Fast Pair Service, 0xFE2C.

This according to Google's own documentation:

https://developers.google.com/nearby/fast-pair/specifications/bledevice

Particularly mentioned here.

I can try to break down the advertisement packet for you. As you can see, all elements in a BLE packet consists of 1 byte for length of the element, one byte for the element "type", and the remaining data in that element is the payload of that type. 

So the first element is 0x06162CFE4A436B. 

Length 6 (including the byte describing the type), type 0x16, and the remaining 5 bytes are the payload: 0x2C FE 4A 43 6B

That gives you the list in your screenshot. 

The different types are described in the "Assigned Numbers" document from Bluetooth SIG (Section 2.3)

Type:

0x16: Service Data
0x01: Flags
0x0A: TX power level
0x09: Complete Local Name

So the last 3 are quite straight forward. The first one, however, is up to the owner of that service, which in this case is Google (you can tell from the Assigned Numbers document. Search for FE2C, belonging to Google LLC). So Google decides the format of this data. The first 2 bytes, 2CFE (the bit order is a bit confusing) is the 16 bit service, and the remainding data is, according to the Core Specification Supplement, section 1.11: "Any remainder contains additional service data."

So from there, I can only point to the first link in this reply. 

Best regards,

Edvin

[Nareshpatel]

Thank you for your response. I am mapping find my protocol ble message frame with "Locator Tag" sample.   

Find My Device Network Accessory Specification  |  Fast Pair  |  Google for Developers

I would like to map specification of Google's FMDN and nordic "locator tag". How I would map message frame ? Please guide me. 

Please help me to understand FMDN technology to track item. Suppose I have manufacturer 100 quantities ble devices(same hardware model). I would like to track each device. How Google identify each device uniquely ?

[PaKa]

All of this is covered by the FMD specification so you will need to look at that. The nRF Connect SDK implementation is a spec compliant implementation so if you start to change the frame content than I would expect you will fail compliancy tests and it won't work as an FMD tag.

The technology uses the ephemeral data to uniquely identify the tag and allow the owner to track it. This is encrypted data so can only be used by the owner, you can't change how this works as that will break the FMD compliance.

Maybe you could explain why you want to break down these features as there may already be a solution for what you want to do, or we may already know this can't be done.

[Nareshpatel]

Thank you PaKa for giving this information. This is very useful so I cannot modify FMDN frame in sample code.  

I can directly use "location tag" for my product. I want to understand FMDN technology and BLE message frame preparation. So in source code where BLE message frame parameters(16 bit UUID 0xFEAA, FMDN frame type - 0x41 and ephemeral  identifier etc)  are filled  ?