## Configuration ### Roles The profile defines two roles: *Fast Pair Seeker* , and *Fast Pair Provider*. The Seeker is normally a phone, looking for a device to pair with. The Provider is a device that is advertising its presence and readiness to pair (e.g. a discoverable pair of headphones). The Fast Pair Seeker shall use the GAP Central role. The Fast Pair Provider shall use the GAP Peripheral role. ### Device discovery To facilitate device discovery, the Fast Pair Provider shall advertise a payload indicating support for the Google Fast Pair Service (with data as described below). The Fast Pair Seeker shall periodically scan for and observe the presence of Fast Pair Provider advertising frames, and take action if interested. ### Model ID Each Provider model has a 24-bit model ID, which is provided by Google during [Model Registration](https://developers.google.com/nearby/fast-pair/specifications/service/modelregistration "Model Registration"). ### Transmit power Provider devices should advertise at a low transmit power (*TxPower*) to limit exposure of the advertised device. However, the power shall be high enough such that the advertisement is visible by any phone at least 1 meter away. To determine proximity, the Fast Pair Seeker must know the Fast Pair Provider's transmit power. For the purposes of this profile, TxPower is defined as the received signal strength at source (0 meters), measured in dBm (this is the same way that [Eddystone](https://github.com/google/eddystone/tree/master/eddystone-uid#tx-power) defines it). > [!NOTE] > **Note:** The best way to determine the value is to measure the actual output of the device using an Android phone at 1 meter away, and then add 41 dBm to that. 41 dBm is the average signal strength loss that occurs over 1 meter. This measured value shall be transmitted using one of these methods: **Included in the Advertisement Record** : The device includes the *Tx Power Level* data type, **ibid.**, ยง 1.5, in its advertisement. **Provided during model registration** : The manufacturer provides Google with the transmit power, and the device model used to measure it, during Model Registration. : The device must keep its transmit power constant for all broadcasts when using this option so that distance measurements are accurate. ### Keys: Anti-Spoofing Public/Private Key Pair After model registration, along with the Model ID, Google will distribute a 256-bit Anti-Spoofing Private Key (an integer in \[1,n--1\] on the secp256r1 elliptic curve). This key shall be persisted on the Provider device, and ideally stored inside a Secure Element (*SE*). Note that a Secure Element is strongly recommended---in the absence of one, there is no guarantee that attackers could not spoof the provider role, because the private key could leak. This key leaking opens up the possibility of man in the middle attacks; therefore, if impersonation or abuse is detected, Fast Pair features that use this key may be disabled (for example, the "Tap to pair" notification when the Provider is in pairing mode). The corresponding Anti-Spoofing Public Key is not currently used by the Provider. It is used by the Seeker, to encrypt a message to send to the Provider (see [Key-based Pairing](https://developers.google.com/nearby/fast-pair/specifications/characteristics#KeyBasedPairing "Key Based Pairing")). ### Keys: Account Key List The Provider shall allocate space to store a persisted list of 128-bit Account Keys. Each Account Key allows the Provider to be recognized as belonging to a certain user account. The list must be able to store at least five keys (that is, there must be at least 80 bytes of space dedicated to this list). Providers can optionally store more than this, they just must make sure that the keys will fit inside of their advertising packet. The exact number that can be stored will depend on how many free bytes are available in the advertising packet; see the [Account Key Filter](https://developers.google.com/nearby/fast-pair/specifications/service/provider#AccountKeyFilter "Account Key Filter") section for more information on determining how many bytes each key will take up. For example, to advertise 10 account keys, 15 bytes need to be available in the packet.But for personal devices (e.g. headphones), the number of account keys should not be greater than 5. This is to avoid the number of account keys becoming too large, and hence it could be unique and trackable. This list is initially empty, and must be cleared if the Provider is factory-reset (if the user clears its paired device list). The list is populated as described in the [Account Key characteristic](https://developers.google.com/nearby/fast-pair/specifications/characteristics#AccountKey "Account Key") section. ### BLE address information To prevent tracking, BLE advertising shall use the random resolvable private address (*RPA*). The address shall be rotated at minimum every 15 minutes while the device is actively advertising, and every time the state changes from not advertising to advertising. A randomized offset should be used to alter the address randomization interval. ### Attribute Protocol (ATT) MTU Size Negotiation An ATT maximum transmission unit (MTU) value of 83 should be used whenever possible, but the default value of 23 is allowed.