Find My Device Network Accessory Specification

v1.3

The Find My Device Network (FMDN) accessory specification defines an end-to-end encrypted approach for tracking beaconing Bluetooth Low Energy (BLE) devices. This page describes FMDN as an extension to the Fast Pair specification. Providers should enable this extension if they have devices that are compatible with FMDN and are willing to enable location tracking for those devices.

GATT Specification

An additional generic attributes (GATT) characteristic should be added to the Fast Pair Service with the following semantics:

Fast Pair Service characteristic	Encrypted	Permissions	UUID
Beacon actions	No	Read, write and notify	FE2C1238-8366-4814-8EB0-01DE32100BEA

Table 1: Fast Pair Service characteristics for FMDN.

Authentication

The operations required by this extension are performed as a write operation, secured by a challenge-response mechanism. Prior to performing any operation, the Seeker is expected to perform a read operation from the characteristic in table 1, which results in a buffer in the following format:

Octet	Data Type	Description	Value
0	uint8	Protocol major version number	0x01
1 - 8	byte array	One-time random nonce	varies

Each read operation should result in a different nonce, and a single nonce should be valid only for a single operation. The nonce must be invalidated even if the operation failed.

The Seeker then calculates a one-time authentication key to be used in a subsequent write request. The authentication key is calculated as described in tables 2 through 5. Depending on the operation being requested, the Seeker proves knowledge of one or more of the following keys:

• Account key: The 16-byte Fast Pair account key, as defined in the Fast Pair specification.

• Owner account key: The Provider chooses one of the existing account keys as the owner account key the first time a Seeker accesses the Beacon Actions characteristic. The chosen owner account key can't be changed until the Provider is factory reset. The Provider must not remove the owner account key when it runs out of free account key slots.

  • Providers that already support FMDN when paired for the first time (or support it when paired after factory reset) choose the first account key, because this is the only existing account key when the Seeker reads the provisioning state during pairing.

  • Providers that gain FMDN support after they're already paired (for example, through a firmware update) can choose any existing account key. It's reasonable to choose the first account key that is used to read the provisioning state from the beacon actions characteristic after the firmware update, assuming the user who performed the update is the Provider's current owner.

• Ephemeral identity key (EIK): A 32-byte key chosen at random by the Seeker when performing the FMDN provisioning process. This key is used to derive cryptographic keys that are used for end-to-end encrypting location reports. The Seeker never reveals it to the backend.

• Recovery key: Defined as SHA256(ephemeral identity key || 0x01), truncated to the first 8 bytes. The key is stored on the backend and the Seeker can use it to recover the EIK, provided the user expresses consent by pressing a button on the device.

• Ring key: Defined as SHA256(ephemeral identity key || 0x02), truncated to the first 8 bytes. The key is stored on the backend and the Seeker can use it only to ring the device.

• Unwanted tracking protection key: Defined as SHA256(ephemeral identity key || 0x03), truncated to the first 8 bytes. The key is stored on the backend and the Seeker can use it only to activate unwanted tracking protection mode.

Operations

The format of the data written to the characteristic is given in tables 2 through 5. Each of the operations is discussed in more details later in this section.

Octet	Data Type	Description	Value
0	uint8	Data ID	0x00: Read beacon parameters 0x01: Read provisioning state 0x02: Set ephemeral identity key 0x03: Clear ephemeral identity key
1	uint8	Data length	varies
2 - 9	byte array	One-time authentication key	The first 8 bytes of HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	byte array	Additional data	0x00: n/a 0x01: n/a 0x02: 32 bytes that are the ephemeral identity key, AES-ECB-128 encrypted with the account key. If the Provider already has an ephemeral identity key set, also send the first 8 bytes of SHA256(current ephemeral identity key || the last nonce read from the characteristic) 0x03: The first 8 bytes of SHA256(ephemeral identity key || the last nonce read from the characteristic)

Table 2: Beacon provisioning request.

Octet	Data Type	Description	Value
0	uint8	Data ID	0x04: Read ephemeral identity key with user consent
1	uint8	Data length	0x08
2 - 9	byte array	One-time authentication key	The first 8 bytes of HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length)

Table 3: Beacon provisioning key recovery request.

Octet	Data Type	Description	Value
0	uint8	Data ID	0x05: Ring 0x06: Read ringing state
1	uint8	Data length	varies
2 - 9	byte array	One-time authentication key	The first 8 bytes of HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	byte array	Additional data	0x05: 4 bytes indicating the ringing state, ringing duration and ringing volume. 0x06: n/a

Table 4: Ringing request.

Octet	Data Type	Description	Value
0	uint8	Data ID	0x07: Activate unwanted tracking protection mode 0x08: Deactivate unwanted tracking protection mode
1	uint8	Data length	varies
2 - 9	byte array	One-time authentication key	The first 8 bytes of HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	byte array	Additional data	0x07: 1 byte of control flags (optional) 0x08: The first 8 bytes of SHA256(ephemeral identity key || the last nonce read from the characteristic)

Table 5: Unwanted tracking protection request.

Successful writes trigger notifications as listed in table 6.

Notifications with data ID other than 0x05: Ring state change should be sent before the write transaction that triggers the notification is completed, that is, before a response PDU for the write request is sent.

Octet	Data Type	Description	Value
0	uint8	Data ID	0x00: Read beacon parameters 0x01: Read provisioning state 0x02: Set ephemeral identity key 0x03: Clear ephemeral identity key 0x04: Read ephemeral identity key with user consent 0x05: Ring state change 0x06: Read ringing state 0x07: Activate unwanted tracking protection mode 0x08: Deactivate unwanted tracking protection mode
1	uint8	Data length	varies
2 - 9	byte array	Authentication	Detailed per operation
10 - var	byte array	Additional data	0x00: 8 bytes indicating the transmission power, clock value, encryption method and ringing capabilities, AES-ECB-128 encrypted with the account key (zero padded) 0x01: 1 byte indicating the provisioning state, followed by the current ephemeral ID (20 or 32 bytes) if applicable 0x04: 32 bytes that are the ephemeral identity key, AES-ECB-128 encrypted with the account key 0x05: 4 bytes indicating the new state and trigger for the change 0x06: 3 bytes indicating the components actively ringing and the number of deciseconds remaining for ringing Other data IDs use empty additional data

Table 6: Beacon service response.

Table 7 lists the possible GATT error codes returned by the operations.

Code	Description	Notes
0x80	Unauthenticated	Returned in response to a write request when authentication fails (including the case where an old nonce was used).
0x81	Invalid value	Returned when any invalid value is provided or the data received has an unexpected number of bytes.
0x82	No user consent	Returned in response to a write request with data ID 0x04: Read ephemeral identity key with user consent when the device isn't in pairing mode.

Table 7: GATT error codes.

Read the beacon's parameter

The Seeker can query the Provider for the beacon's parameters by performing a write operation to the characteristic consisting of a request from table 2 with data ID 0x00. The Provider verifies that the provided one-time authentication key matches any of the account keys stored on the device.

If verification fails the Provider returns an unauthenticated error.

On success, the Provider notifies with a response from table 6 with data ID 0x00. The Provider constructs the data segment as follows:

Octet	Data Type	Description	Value
0	uint8	Calibrated power	The calibrated power as received at 0m (a value in the range [-100, 20]). Represented as a signed integer, with 1 dBm resolution.
1 - 4	uint32	Clock value	The current clock value in seconds (big endian).
5	uint8	Curve selection	The elliptic curve being used for encryption: 0x00 (default): SECP160R1 0x01: SECP256R1 (requires extended advertising)
6	uint8	Components	The number of components capable of ringing: 0x00: Indicates that the device is incapable of ringing. 0x01: Indicates that only a single component is capable of ringing. 0x02: Indicates that two components, left and right buds, are capable of ringing independently. 0x03: Indicates that three components, left and right buds and the case, are capable of ringing independently.
7	uint8	Ringing capabilities	The supported options are: 0x00: Ringing volume selection not available. 0x01: Ringing volume selection available. If set, the Provider must accept and handle 3 volume levels as indicated in Ring operation.
8-15	byte array	Padding	Zero padding for AES encryption.

The data should be AES-ECB-128 encrypted with the account key used for authenticating the request.

The authentication segment is defined as the first 8 bytes of HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01).

Read the beacon's provisioning state

The Seeker can query the Provider for the beacon's provisioning state by performing a write operation to the characteristic consisting of a request from table 2 with data ID 0x01. The Provider verifies that the provided one-time authentication key matches any of the account keys stored on the device.

If verification fails, the Provider returns an unauthenticated error.

On success, the Provider notifies with a response from table 6 with data ID 0x01. The Provider constructs the data segment as follows:

Octet	Data Type	Description	Value
0	uint8	Provisioning state	A bitmask having the following values: Bit 1 (0x01): Set if an ephemeral identity key is set for the device. Bit 2 (0x02): Set if the provided one-time authentication key matches the owner account key.
1 - 20 or 32	byte array	Current ephemeral identifier	20 or 32 bytes (depending on the encryption method being used) indicating the current ephemeral ID advertised by the beacon, if one is set for the device.

The authentication segment is defined as the first 8 bytes of HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Set an ephemeral identity key

To provision an unprovisioned Provider as an FMDN beacon, or change the ephemeral identity key of already provisioned Provider, the Seeker performs a write operation to the characteristic consisting of a request from table 2 with data ID 0x02. The Provider verifies that:

• The provided one-time authentication key matches the owner account key.
• If a hash of an ephemeral identity key was provided, the hashed ephemeral identity key matches the current ephemeral identity key.
• If a hash of an ephemeral identity key wasn't provided, verify that the Provider wasn't already provisioned as an FMDN beacon.

If verification fails, the Provider returns an unauthenticated error.

On success, the ephemeral identity key is recovered by AES-ECB-128 decrypting it using the matched account key. The key should be persisted on the device, and from that point on the Provider should start advertising FMDN frames. The new ephemeral identity key takes effect immediately after the BLE connection is terminated. The Provider notifies with a response from table 6 with data ID 0x02.

The authentication segment is defined as the first 8 bytes of HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Clear the ephemeral identity key

To unprovision the beacon portion of the Provider, the Seeker performs a write operation to the characteristic, consisting of a request from table 2 with data ID 0x03. The Provider verifies that:

• The provided one-time authentication key matches the owner account key.
• The hashed ephemeral identity key matches the current ephemeral identity key.

If the Provider isn't provisioned as an FMDN beacon or verification fails, it returns an unauthenticated error.

On success, the Provider forgets the key and stops advertising FMDN frames. The Provider notifies with a response from table 6 with data ID 0x03. The authentication segment is defined as the first 8 bytes of HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Read the ephemeral identity key with user consent

This option is only available to recover a lost key, as the key is only stored locally by the Seeker. As such, this capability is available only when the device is in pairing mode or for some limited time after a physical button was pressed on the device (which constitutes user consent).

The Seeker must store the recovery key on the backend to be able to recover the cleartext key, but it doesn't store the EIK itself.

To read the EIK, the Seeker performs a write operation to the characteristic, consisting of a request from table 3 with data ID 0x04. The Provider verifies that:

• The hashed recovery key matches the expected recovery key.
• The device is in EIK recovery mode.

If verification fails, the Provider returns an unauthenticated error.

If the device isn't in pairing mode, the Provider returns a No User Consent error.

On success, the Provider notifies with a response from table 6 with data ID 0x04.

The authentication segment is defined as the first 8 bytes of HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Ring operation

The Seeker can ask the Provider to play a sound by performing a write operation to the characteristic, consisting of a request from table 4 with data ID 0x05. The Provider constructs the data segment as follows:

Octet	Data Type	Description	Value
0	uint8	Ring operation	A bitmask having the following values: Bit 1 (0x01): Ring right Bit 2 (0x02): Ring left Bit 3 (0x04): Ring case 0xFF: Ring all components 0x00: Stop ringing
1 - 2	uint16	Timeout	The timeout in deciseconds. Must not be zero and must not be greater than the equivalent of 10 minutes. The Provider uses this value to determine how long it should ring before silencing itself. The timeout overrides the one already in effect if any component of the device is already ringing. If ring operation is set to 0x00, the timeout is ignored.
3	uint8	Volume	0x00: Default 0x01: Low 0x02: Medium 0x03: High The exact meaning of these values is implementation dependent.

Upon receiving the request, the Provider verifies that:

• The provided one-time authentication key matches the ring key.
• The requested state matches the components that can ring.

If the Provider isn't provisioned as an FMDN beacon or verification fails, it returns an unauthenticated error. However, if the Provider has unwanted tracking protection active, and the triggering unwanted tracking protection request had the skip ringing authentication flag turned on, the Provider should skip that check. The authentication data is still expected to be provided by the Seeker, but it could be set to an arbitrary value.

When ringing starts or terminates a notification is sent as indicated in table 6 with data ID 0x05. The contents of the notification are defined as follows:

Octet	Data Type	Description	Value
0	uint8	Ringing state	0x00: Started 0x01: Failed to start or stop (all requested components are out of range) 0x02: Stopped (timeout) 0x03: Stopped (button press) 0x04: Stopped (GATT request)
1	uint8	Ringing components	A bitmask of the components actively ringing, as defined in the request.
2 - 3	uint16	Timeout	The remaining time for ringing in deciseconds. If the device has stopped ringing, 0x0000 should be returned.

The authentication segment is defined as the first 8 bytes of HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01).

If the device is already in the requested ring state when a request to ring or stop ringing is received, the Provider should send a notification with a ringing state or either 0x00: Started or 0x04: Stopped (GATT request), respectively. This request overrides the existing state's parameters, so that the ringing duration can be extended.

If the Provider has a physical button (or touch sense is enabled), that button should stop the ringing function if pressed while the ringing is active.

Get the beacon's ringing state

To get the ringing state of the beacon, the Seeker performs a write operation to the characteristic, consisting of a request from table 4 with data ID 0x06. The Provider verifies that the provided one-time authentication key matches the ring key.

If the Provider isn't provisioned as an FMDN beacon or if verification fails, the Provider returns an unauthenticated error.

On success, the Provider notifies with a response from table 6 with data ID 0x06. The Provider constructs the data segment as follows:

Octet	Data Type	Description	Value
0	uint8	Ringing components	The components actively ringing, as defined in the ringing request.
1 - 2	uint16	Timeout	The remaining time for ringing in deciseconds. Note that if the device isn't ringing, 0x0000 should be returned.

The authentication segment is defined as the first 8 bytes of HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Unwanted tracking protection mode

Unwanted tracking protection mode is intended to let any client identify abusive devices with no server communication. By default, the Provider should rotate all identifiers as described in ID rotation. The Find My Device service can relay an unwanted tracking protection mode activation request through the Find My Device network. By doing so, the service causes the Provider to temporarily use a fixed MAC address, allowing clients to detect the device and warn the user of possible unwanted tracking.

To activate or deactivate the unwanted tracking protection mode of the beacon, the Seeker performs a write operation to the characteristic, consisting of a request from table 5 with data ID 0x07 or 0x08 respectively.

When enabling unwanted tracking protection mode

The Provider constructs the data segment as follows:

Octet	Data Type	Description	Value
0	uint8	Control Flags	0x01: Skip ringing authentication. When set, ringing requests aren't authenticated while in unwanted tracking protection mode. If no flag is being set (the byte is all zeros), it's valid to omit the data section altogether and send an empty data section. The flags are in effect only until the unwanted tracking protection mode is deactivated.

The Provider verifies that the provided one-time authentication key matches the unwanted tracking protection key. If the Provider isn't provisioned as an FMDN beacon or verification fails, it returns an unauthenticated error.

When unwanted tracking protection mode is activated, the beacon should reduce MAC private address rotation frequency to once per 24 hours. The advertised ephemeral identifier should keep rotating as usual. The frame type should be set to 0x41. The state is also reflected in the hashed flags section.

When disabling unwanted tracking protection mode

The Provider verifies that:

• The provided one-time authentication key matches the unwanted tracking protection key.
• The hashed ephemeral identity key matches the current ephemeral identity key.

If the Provider isn't provisioned as an FMDN beacon or verification fails, the Provider returns an unauthenticated error.

When unwanted tracking protection mode is deactivated, the beacon should start rotating the MAC address at a normal rate again, synchronized with ephemeral identifier rotation. The frame type should be set back to 0x40. The state is also reflected in the hashed flags section.

On success, the Provider notifies with a response from table 6 with data ID 0x07 or 0x08.

The authentication segment is defined as the first 8 bytes of HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Advertised frames

After provisioning, the Provider is expected to advertise FMDN frames at least once every 2 seconds. If Fast Pair frames are advertised, the Provider should interleave the FMDN frames within the regular Fast Pair advertisements. For example, every two seconds, the Provider should advertise seven Fast Pair advertisements and one FMDN advertisement.

The FMDN frame carries a public key used to encrypt location reports by any supporting client that contributes to the crowdsourcing network. Two types of elliptic curve keys are available: a 160-bit key that fits legacy BLE 4 frames, or 256-bit key that requires BLE 5 with extended advertising capabilities. The Provider's implementation determines which curve is used.

An FMDN frame is structured as follows.

Octet	Value	Description
0	0x02	Length
1	0x01	Flags data type value
2	0x06	Flags data
3	0x18 or 0x19	Length
4	0x16	Service data data type value
5	0xAA	16-bit service UUID
6	0xFE	...
7	0x40 or 0x41	FMDN frame type with unwanted tracking protection mode indication
8..27		20-byte ephemeral identifier
28		Hashed flags

Table 8: FMDN frame supporting a 160-bit curve.

Table 9 shows the byte offsets and values for a 256-bit curve.

Octet	Value	Description
0	0x02	Length
1	0x01	Flags data type value
2	0x06	Flags data
3	0x24 or 0x25	Length
4	0x16	Service data data type value
5	0xAA	16-bit service UUID
6	0xFE	...
7	0x40 or 0x41	FMDN frame type with unwanted tracking protection mode indication
8..39		32-byte ephemeral identifier
40		Hashed flags

Table 9: FMDN frame supporting a 256-bit curve.

Ephemeral identifier (EID) computation

A random is generated by AES-ECB-256 encrypting the following data structure with the ephemeral identity key:

Octet	Field	Description
0 - 10	Padding	Value = 0xFF
11	K	Rotation period exponent
12 - 15	TS[0]...TS[3]	Beacon time counter, in 32-bit big-endian format. The K lowest bits are cleared.
16 - 26	Padding	Value = 0x00
27	K	Rotation period exponent
28 - 31	TS[0]...TS[3]	Beacon time counter, in 32-bit big-endian format. The K lowest bits are cleared.

Table 10: Construction of a pseudorandom number.

The result of this computation is a 256-bit number, denoted r'.

For the rest of the calculation, SECP160R1 or SECP256R1 are used for elliptic curve cryptographic operations. See curve definitions in SEC 2: Recommended Elliptic Curve Domain Parameters, which defines Fp, n and G referenced next.

r' is now projected to the finite field Fp by calculating r = r' mod n. Finally, compute R = r * G, which is a point on the curve representing the public key being used. The beacon advertises Rx, which is the x coordinate of R, as its ephemeral identifier.

Hashed flags

The hashed flags field is calculated as follows (bits are referenced from most significant to least significant):

• Bits 0-4: Reserved (set to zeros).
• Bits 5-6 indicates the battery level for the device as follows:
  • 00: Battery level indication unsupported
  • 01: Normal battery level
  • 10: Low battery level
  • 11: Critically low battery level (battery replacement needed soon)
• Bit 7 is set to 1 if the beacon is in unwanted tracking protection mode, and 0 otherwise.

To produce the final value of this byte, it is xor-ed with the least significant byte of SHA256(r).

Note that r should be aligned to the curve's size. Add zeros as most significant bits if its representation is shorter than 160 or 256 bits, or the most significant bits should be truncated if its representation is larger than 160 or 256 bits.

If the beacon doesn't support battery level indication, and isn't in unwanted tracking protection mode, it's allowed to omit this byte entirely from the advertisement.

Encryption with EID

To encrypt a message m, a sighter (having read Rx from the beacon) would do the following:

1. Choose a random number s in Fp, as defined in the EID computation section.
2. Compute S = s * G.
3. Compute R = (Rx, Ry) by substitution in the curve equation and picking an arbitrary Ry value out of the possible results.
4. Compute the 256-bit AES key k = HKDF-SHA256((s * R)x) where (s * R)x is the x coordinate of the curve multiplication result. Salt isn't specified.
5. Let URx and LRx be the upper and lower 80-bits of Rx, respectively, in big-endian format. In a similar way, define USx and LSx for S.
6. Compute nonce = LRx || LSx.
7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
8. Send (URx, Sx, m’, tag) to the owner, possibly through an untrusted remote service.

Decryption of values encrypted with EID

The owner's client, which is in possession of the EIK and the rotation period exponent, decrypts the message as follows:

1. Given URx, obtain the beacon time counter value on which URx is based. This can be done by the owner's client computing Rx values for beacon time counter values for the recent past and near future.
2. Given the beacon time counter value on which URx is based, compute the anticipated value of r as defined in the EID computation section.
3. Compute R = r * G, and verify a match to the value of URx provided by the sighter.
4. Compute S = (Sx, Sy) by substitution in the curve equation and picking an arbitrary Sy value out of the possible results.
5. Compute k = HKDF-SHA256((r * S)x) where (r * S)x is the x coordinate of the curve multiplication result.
6. Compute nonce = LRx || LSx.
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag).

ID rotation

A resolvable (RPA) or non-resolvable (NRPA) BLE address must be used for advertising FMDN frames. RPA is required for LE Audio (LEA) devices and is recommended for other devices, with the exception of locator tags that don't use bonding.

Fast Pair advertisement, FMDN advertisement and the corresponding BLE address(es) should rotate at the same time. Rotation should happen every 1024 seconds on average. The precise point at which the beacon starts advertising the new identifier must be randomized within the window.

The recommended approach to randomize the rotation time is to set it to the next anticipated rotation time (if no randomization was applied) plus a positive randomized time factor in the range of 1 to 204 seconds.

When the device is in unwanted tracking protection mode, the BLE address of the FMDN advertisement should be fixed, but the RPA for FP non-discoverable advertisement (such as Fast Pair) must keep rotating. It's acceptable to use different addresses for the different protocols.

Recovery from power loss

Resolving the ephemeral identifier is strongly tied to its clock value at the time of the advertisement, so it's important that the Provider can recover its clock value if there's a power loss. It is recommend that the Provider writes its current clock value to nonvolatile memory at least once per day, and that at boot time the Provider checks the NVM to see if there's a value present from which to initialize. Resolvers of the ephemeral identifier would implement resolution over a time window sufficient to allow for both reasonable clock drift and this type of power loss recovery.

Providers should still make all efforts to minimize clock drifts, as the resolution time window is limited. At least one additional clock synchronization method should be implemented (advertising non-discoverable Fast Pair frames or implementing the message stream).

Fast Pair implementation guidelines

This section describes special aspects of the Fast Pair implementation on Providers that support FMDN.

Locator tag specific guidelines

• If the Provider was paired, but FMDN wasn't provisioned within 5 minutes (or if an OTA update was applied while the device is paired but not FMDN-provisioned), the Provider should revert to its factory configuration and clear the stored account keys.
• After the Provider is paired, it shouldn't change its MAC address until FMDN is provisioned or until 5 minutes pass.
• If the ephemeral identity key is cleared from the device, the device should perform a factory reset and clear the stored account keys as well.
• The Provider should reject normal Bluetooth pairing attempts and accept only Fast Pair pairing.
• The Provider must include a mechanism that lets users temporarily stop advertising without factory resetting the device (for example, pressing a combination of buttons).
• After a power loss, the device should advertise non-discoverable Fast Pair frames until the next invocation of read beacon parameters. This lets the Seeker detect the device and synchronize the clock even if a significant clock drift occurred.
• When advertising non-discoverable Fast Pair frames, UI indications shouldn't be enabled.
• Discoverable Fast Pair frames shouldn't be advertised while the Provider is provisioned for FMDN.
• The Provider shouldn't expose any identifying information information in an unauthenticated manner (e.g. names or identifiers).

Classic Bluetooth device-specific guidelines

This section describes special aspects of classic Bluetooth devices that support FMDN.

FMDN provisioning of already paired devices

The Provider isn't always provisioned for FMDN when pairing with the Seeker, but a while after that. In that case, the Provider might not have an up-to-date BLE MAC address that's required to establish a GATT connection. The Provider must support at least one of the following ways for the Seeker to get its BLE address while it's already paired:

• The Provider can periodically advertise the Fast Pair account data that lets the Seeker find its BLE address through a BLE scan.
  This approach suits Providers that don't implement the message stream.
• The Provider can provide this data through the Fast Pair message stream over classic Bluetooth.
  This approach suits Providers that don't advertise Fast Pair frames while connected to the Seeker over Bluetooth.

Supporting both approaches increases the chances that the user can provision the device for FMDN.

Fast Pair message stream

The Provider can implement Fast Pair message stream and use it to notify the Seeker about Device information. Implementing the message stream enables certain features as described in this section.

The Provider should send device information messages once every time the message stream RFCOMM channel is established.

Firmware version (device information code 0x09) and the tracking capability

When a firmware update adds FMDN support to the Provider, a connected Seeker can notify the user about that and offer to provision it. Otherwise, the user has to navigate to the Bluetooth device list manually to initiate FMDN provisioning.

To allow that, the Provider should use the Firmware version property (code 0x09) to report a string value that represents the firmware version. In addition, the Provider should support the protocol that lets the Seeker know about Capability changes due to firmware updates.

Octet	Data Type	Description	Value
0	uint8	Device information event	0x03
1	uint8	Firmware version	0x09
2 - 3	uint16	Additional data length	varies
var	byte array	Version string	varies

Table 11: Device information event: updated firmware version.

Upon receiving a capability update request (0x0601), if the Provider has enabled support for FMDN tracking, it should respond as shown in table 12.

Octet	Data Type	Description	Value
0	uint8	Device capability sync event	0x06
1	uint8	FMDN tracking	0x03
2 - 3	uint16	Additional data length	0x0007
4	uint8	FMDN provisioning state	0x00 if unprovisioned; 0x01 if provisioned by any account
5 - 10	byte array	The current BLE MAC address of the device	varies

Table 12: Device capability sync event: added tracking capability.

Current ephemeral identifier (device information code 0x0B)

The Provider can use the current ephemeral identifier (code 0x0B) to report the current EID and clock value when the Provider is provisioned for FMDN, to sync the Seeker in case of a clock drift (for example, due to drained battery). Otherwise, the Seeker initiates a more expensive and less reliable connection for this purpose.

Octet	Data Type	Description	Value
0	uint8	Device information event	0x03
1	uint8	Current ephemeral identifier	0x0B
2 - 3	uint16	Additional data length	0x0018 or 0x0024
4 - 7	byte array	Clock value	Example: 0x13F9EA80
8 - 19 or 31	byte array	Current EID	Example: 0x1122334455667788990011223344556677889900

Table 13: Device information event: clock sync.

Factory reset

For devices that support factory reset: if a factory reset is performed, the Provider must stop beaconing and wipe out the ephemeral identity key and all stored account keys, including the owner's account key.

After a factory reset (either manual or programmatic), the Provider shouldn't start advertising Fast Pair right away, to prevent the pairing flow to start immediately after the user deletes the device.

Unwanted tracking prevention

Certified FMDN devices must also meet the requirements in the implementation version of the cross-platform specification for Detecting Unwanted Location Trackers (DULT).

Relevant guidelines specific to FMDN to be compliant with DULT spec:

• Any FMDN compatible device must be registered in the Nearby Device Console, and have the "Find My Device" capability activated.
• The device must implement the Accessory Non-Owner service and characteristic defined in the implementation version of the DULT spec, including the Accessory Information operations and Non-owner controls.
• During the backward compatibility period, as defined in the DULT spec, there are no changes to the advertised frame as defined in this document.
• "Unwanted tracking protection mode" defined in this document maps to the "separated state" defined by the DULT spec.
• Guidelines for implementing the Accessory Information opcodes:
  • Get_Product_Data should return the model ID provided by the console, zero padded to fit the 8-byte requirement. For example, model ID 0xFFFFFF is returned as 0x0000000000FFFFFF.
  • Get_Manufacturer_Name and Get_Model_Name should match the values provided in the console.
  • Get_Accessory_Category can return the generic "Location Tracker" value if no other category better fits the type of the device.
  • Get_Accessory_Capabilities must indicate the support for ringing as well as BLE identifier lookup.
  • Get_Network_ID should return Google's identifier (0x02).
• Guidelines for implementing the Get_Identifier opcode:
  • The operation should only return a valid response for 5 minutes after the user activated the 'identification' mode, which requires a combination of button presses. A visual or audio signal should indicate to the user that the provider entered that mode. The model-specific instructions for activating that mode must be provided to Google as a requirement for certification and at least 10 days prior to any update or modification to the instructions.
  • The response is constructed as: the first 10 bytes of current ephemeral identifier, followed by the first 8 bytes of HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Guidelines for implementing the Sound_Start opcode:
  • The command should trigger ringing in all available components.
  • The maximal supported volume should be used.
  • The recommended duration for ringing is 12 seconds.
• Locator tags must include a mechanism that lets users temporarily stop advertising without factory resetting the device (for example, pressing a combination of buttons).
  • The disablement instructions must be documented in a publicly available URL and provided to Google as a requirement for certification and at least 10 days prior to any update or modification to the instructions.
  • The URL should support localization. Depending on the client, the language will be provided either as a query param ("hl=en") or using the "accept-language" HTTP header.

Switchable protocol guidelines

• Only one protocol should be used at a time. Ensure that no more than one network can operate on the device simultaneously. This requirement is needed to ensure that there is no commingling of sensitive user data between varying protocols.
• It is suggested to incorporate a hard reset workflow into the device that allows a user to re-setup a device with a different network.
• The process of updating a device to a network should be user friendly and equitable between networks. A user must be able to choose which network they want to use without giving preference to one of the networks. This flow needs to be approved by the Google team.

Firmware updates

The process and distribution of OTA updates should be managed by the partner using their own Mobile or Web app workflow.

Compatibility

Find My Device network requires location services and Bluetooth to be turned on. Requires cell service or internet connection. Works on Android 9+ and in certain countries for age-eligible users.

Changelog

FMDN Version	Date	Comment
v1		Initial release of the FMDN spec for early access.
v1.1	Feb 2023	Added a cleartext indication of unwanted tracking protection mode. Added an option to skip authentication of ringing requests while in unwanted tracking protection mode.
v1.2	Apr 2023	Updated the definition of an owner's AK. Added a recommendation for recovering from power loss in locator tags. Added a clarification for MAC address randomization. Added a clarification on MAC address rotation while in unwanted tracking protection mode. Added a guideline on having a way to deactivate a locator tag.
v1.3	Dec 2023	Added a clarification on identifying information exposed by locator tags. Added a requirement to implement the unwanted tracking prevention specification. Added guidelines for switchable protocol devices.