제공업체 기기가 BR/EDR 검색 가능 (즉, 페어링 모드)인 경우 BLE를 통해 빠른 페어링 모델 ID 데이터를 광고해야 하며 BLE 주소는 회전되어서는 안 됩니다.
광고 간격: 검색 가능한 경우
광고 간격은 100ms (10Hz) 이하여야 합니다. 빠른 속도를 사용하면 탐색기가 저전력 모드에서 스캔하는 경우에도 제공자를 빠르게 찾을 수 있습니다.
광고 페이로드: 빠른 페어링 모델 ID 데이터
광고에는 서비스 데이터 데이터 유형이 포함되어야 합니다. § 1.11. UUID는 0xFE2C의 빠른 페어링 서비스 UUID여야 합니다. 서비스 데이터에는 다음이 포함되어야 합니다.
옥텟
데이터 유형
설명
값
0-2
uint24
24비트 모델 ID
다름
광고: 검색할 수 없는 경우
검색할 수 없는 경우 (즉, 페어링 모드가 아닌 경우) 제공업체 기기는 다음 가이드라인에 따라 빠른 페어링 계정 데이터를 광고해야 합니다.
계정 데이터를 광고하면 근처의 검색자가 제공업체가 자신의 계정에 속하는지 인식하고 제공업체를 먼저 페어링 모드로 다시 전환하지 않고도 페어링을 시작할 수 있습니다. 이는 사용자 불만의 일반적인 원인입니다. 시커는 사용자가 제공업체와 페어링할 때까지 기다리지 않거나 브로드캐스트가 관련이 없는 경우 (예: 이미 페어링된 경우) 이 브로드캐스트를 무시할 수 있는 기회를 제공합니다.
또한 계정 데이터가 잘못 구성된 경우와 같이 분명히 잘못된 방송은 자동으로 필터링됩니다.
광고 간격: 검색할 수 없는 경우
광고 간격은 최대 250ms (4Hz)여야 합니다.
광고 페이로드: 빠른 페어링 계정 데이터
광고에는 서비스 데이터 데이터 유형이 포함되어야 합니다(Ibid.). § 1.11. UUID는 0xFE2C의 빠른 페어링 서비스 UUID여야 합니다. 서비스 데이터에는 다음이 포함되어야 합니다.
옥텟
데이터 유형
설명
값
0
uint8
버전 및 플래그 0bVVVVFFFF
V = 버전
F = flags
0x00 (나중에 사용하기 위해 예약됨)
1 - 다름
계정 키 데이터
다름
계정 키 데이터에는 다음이 포함됩니다.
옥텟
데이터 유형
설명
값
0
uint8
필드 길이 및 유형 0bLLLLTTTT
L = 계정 키 필터의 길이(바이트)
T = 유형
0bLLLL0000
길이 = 0bLLLL = 다양함
type = 0b0000 (UI 표시) 또는 0b0010 (UI 표시 숨기기), 계정 키 필터
광고된 계정 키 필터를 사용하면 검색자가 추가 상호작용 전에 제공업체가 특정 계정 키를 보유하고 있는지 빠르게 확인할 수 있습니다 (거짓양성 확률이 낮음, 평균 0.5% 미만). 거짓양성률을 더욱 줄이기 위해 시커는 유형 0으로 브로드캐스트되는 필터(즉, 계정 키 중 하나를 포함할 수 있는 UI 표시)를 감지하면 자동으로 연결되고 절차를 시작하려고 시도할 수 있습니다. 경우에 따라 제공업체가 페어링 준비가 되지 않은 상태에서 검색자에게 인식되기를 원할 수 있습니다. 한 가지 예로 케이스에 이어폰을 다시 넣으면 헤드셋에서 페어링을 거부할 수 있으므로 후속 페어링 알림을 표시하지 않는 것이 좋습니다.
필터의 크기(바이트)인 s를 (1.2*n + 3)으로 자릅니다. 예를 들어 키 1개가 유지되는 경우 s = 4바이트입니다. uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);
필터 F를 각각 0으로 설정된 s바이트 배열로 초기화합니다. uint8_t F[s] = {0};
영구 저장된 계정 키 목록의 각 계정 키 K에 대해 다음을 실행합니다.
a. V를 concat(K, Salt)로 정의합니다.
// In the sample code, the size of salt is 2 bytes.#define SALT_SIZE 2uint8_tV[FASTPAIR_ACCOUNT_KEY_SIZE+SALT_SIZE];for(uint8_tkeyIndex=0;keyIndex < n;keyIndex++){// concat (K, Salt)fastpair_get_account_key_by_index(keyIndex,V);uint8_trandomSalt=(uint8_t)rand();V[FASTPAIR_ACCOUNT_KEY_SIZE]=randomSalt;...}
b. SHA256을 사용하여 V를 해싱하여 32바이트 값 H = {H0, …, H31}를 가져옵니다.
uint8_tH[32]={0};SHA256_hash_function(V,H);
c. H를 빅엔디언의 4바이트 부호 없는 정수 8개로 나눕니다. X = {X0, …, X7}. 여기서 X0 = 0xH0H1H2H3입니다.
[null,null,["최종 업데이트: 2025-08-13(UTC)"],[[["\u003cp\u003eProvider devices advertise Fast Pair Model ID Data over BLE when in pairing mode to enable quick discovery by Seeker devices.\u003c/p\u003e\n"],["\u003cp\u003eWhen not discoverable, Provider devices advertise Fast Pair Account Data, allowing Seekers to recognize them and initiate pairing without requiring the Provider to re-enter pairing mode.\u003c/p\u003e\n"],["\u003cp\u003eThe Account Key Filter, a Bloom filter included in the Account Key Data, helps Seekers quickly assess the potential presence of a specific account key on the Provider, reducing false positives and unnecessary pairing attempts.\u003c/p\u003e\n"],["\u003cp\u003eThe salt, a random value appended to account keys during Bloom filter construction, is regenerated with each Provider RPA update to prevent tracking across address rotations, enhancing privacy.\u003c/p\u003e\n"]]],[],null,["Provider Advertising signal\n---------------------------\n\n### Advertising: When discoverable\n\nWhen the Provider device is BR/EDR discoverable (that is, in pairing mode), it\nshall advertise Fast Pair Model ID Data over BLE, and the BLE address shall not\nbe rotated.\n\n#### Advertising interval: When discoverable\n\nThe interval between advertisements should be no larger than 100ms (10Hz). A\nfast rate allows the Seeker to quickly find the Provider, even when scanning in\nlow-power mode.\n\n#### Advertising payload: Fast Pair Model ID Data\n\nThe advertisement shall contain the Service Data data type, ibid., § 1.11. The\nUUID shall be the Fast Pair Service UUID of `0xFE2C`. The service data shall\ncontain the following:\n\n| Octet | Data type | Description | Value |\n|-------|-----------|-----------------|----------|\n| 0-2 | `uint24` | 24-bit model ID | *varies* |\n\n### Advertising: When not discoverable\n\nWhen not discoverable (that is, not in pairing mode), the Provider device shall\nadvertise Fast Pair Account Data, using the following guidelines.\n\nAdvertising the account data allows Seekers nearby to recognize when a provider\nbelongs to their account and initiate pairing without having to force the\nprovider back into pairing mode first, which is a common cause for user\ncomplaint. Seekers will provide the opportunity for users to be able to ignore\nthis broadcast in the case where they do not wait to pair with the provider or\nthe broadcast is not relevant (for example, if they have already paired).\nSeekers will also filter out obviously bad broadcasts automatically, such as\nwhen the account data is misconfigured.\n\n#### Advertising interval: When not discoverable\n\nThe interval between advertisements should be at most 250ms (4Hz).\n\n#### Advertising payload: Fast Pair Account Data\n\nThe advertisement shall contain the Service Data data type, Ibid., § 1.11. The\nUUID shall be the Fast Pair Service UUID of `0xFE2C`. The service data shall\ncontain the following:\n\n| Octet | Data type | Description | Value |\n|--------------|-----------|--------------------------------------------------------|----------------------------------|\n| 0 | `uint8` | Version and flags 0bVVVVFFFF - V = version - F = flags | `0x00` (reserved for future use) |\n| 1 - *varies* | | Account Key Data | *varies* |\n\n| **Note:** The provider shall advertise its Fast PairAccount Data only if the Account Key List has one or more entries.\n\nThe Account Key Data contains:\n\n| Octet | Data type | Description | Value |\n|-------------------|-----------|-----------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------|\n| 0 | `uint8` | Field length and type 0bLLLLTTTT - L = length of account key filter in bytes - T = type | 0bLLLL0000 - length = 0bLLLL = *varies* - type = 0b0000 (show UI indication) or 0b0010 (hide UI indication), Account Key Filter |\n| 1 - *s* | | Account Key Filter | *varies* |\n| *s* + 1 | `uint8` | Field length and type 0bLLLLTTTT - L = length in bytes - T = type | 0b00100001 - length = 0b0010 = 2 - type = 0b0001, [Salt](#SaltField) |\n| *s* + 2 - *s* + 3 | `uint16` | Salt | *varies* |\n\n#### Account Key Filter\n\n| **Note:** Google recommends implementing the [Cryptographic Test Cases](/nearby/fast-pair/specifications/appendix/cryptotestcases \"Link to the Cryptographic Test Cases.\") to ease verification of these requirements.\n\nThe advertised Account Key Filter allows a Seeker to quickly check whether a\nProvider might possess a certain account key (with a low false-positive\nprobability, on average much less than 0.5%), before further interactions. The\nSeeker may automatically connect and attempt to start the procedure when it sees\na filter being broadcast with type 0, i.e. showing UI indication, that\npotentially contains one of its account keys, so as to reduce the rate of false\npositives further. In some situations, the Provider may want to be recognized\nby the Seeker while not ready for pairing. One example is that when buds get put\nback into case, we want to stop showing the subsequent pairing notification\nsince that pairing could be rejected by the headset.\n\nThe Account Key Filter is a variable-length\n[Bloom filter](https://en.wikipedia.org/wiki/Bloom_filter) constructed as\nfollows:\n\n1. Let *n* be the number of account keys (*n* \\\u003e= 1) in the persisted [Account Key list](/nearby/fast-pair/specifications/configuration#AccountKeyList \"Account Key List\").\n2. Let *s* , the size of the filter in bytes, be (1.2\\**n* + 3) truncated. For example, if 1 key is persisted, *s* = 4 bytes. \n `uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);`\n3. Initialize the filter *F* as an array of *s* bytes, each set to 0. \n `uint8_t F[s] = {0};`\n4. For each account key *K* in the persisted [Account Key list](/nearby/fast-pair/specifications/configuration#AccountKeyList \"Account Key List\"): \n\n a. Let *V* be concat(*K* , [Salt](#SaltField)). \n\n // In the sample code, the size of salt is 2 bytes.\n #define SALT_SIZE 2\n\n uint8_t V[FASTPAIR_ACCOUNT_KEY_SIZE + SALT_SIZE];\n for (uint8_t keyIndex = 0; keyIndex \u003c n; keyIndex++)\n {\n // concat (K, Salt)\n fastpair_get_account_key_by_index(keyIndex, V);\n\n uint8_t randomSalt = (uint8_t)rand();\n V[FASTPAIR_ACCOUNT_KEY_SIZE] = randomSalt;\n ... }\n\n b. Hash *V* using SHA256, obtaining a 32-byte value *H* =\n {H~0~, ..., H~31~}. \n\n uint8_t H[32] = {0};\n SHA256_hash_function(V, H);\n\n c. Divide *H* into eight 4-byte unsigned integers in big-endian,\n X = {X~0~, ..., X~7~}, where\n X~0~ = 0xH~0~H~1~H~2~H~3~. \n\n uint32_t X[8];\n for (index = 0; index \u003c 8; index++)\n {\n X[index] = (((uint32_t)(H[index * 4])) \u003c\u003c 24) |\n (((uint32_t)(H[index * 4 + 1])) \u003c\u003c 16) |\n (((uint32_t)(H[index * 4 + 2])) \u003c\u003c 8) |\n (((uint32_t)(H[index * 4 + 3])) \u003c\u003c 0);\n }\n\n d. For each X~i~: \n\n i. Let *M* be *X~i~* modulo the number of bits in the filter,\n (*s* \\* 8). \n\n ii. Get the byte in *F* at index (*M* / 8), rounded down. \n\n iii. Within the byte, set the bit at index (*M* % 8) to 1. \n\n iv. In other words: \n\n // M = Xi % (s * 8)\n // F[M/8] = F[M/8] | (1 \u003c\u003c (M % 8))\n for (index = 0; index \u003c 8; index++)\n {\n uint32_t M = X[index] % (s * 8);\n F[M / 8] = F[M / 8] | (1 \u003c\u003c (M % 8));\n }\n\nInclude the filter *F* as the Account Key Filter field, in the advertising data.\nNote that there is no \"endianness\" to this value, since there is no more or less\nsignificant byte---don't alter the byte order.\n\n##### Salt field\n\nThe salt is a random value that is appended to account keys when building the\nbloom filter. This salt should be regenerated every time the RPA is updated for\nthe Provider to avoid tracking across address rotation.\n\nTo generate the Account Key Filter using the salt:\n\n1. Generate a random 2-byte *S*. Note that there is no \"endianness\" to this value, since there is no more or less significant byte --- don't alter the byte order.\n2. Use the 2-byte *S* as the Salt.\n3. In the advertised Fast Pair Account Data, include the generated filter in the Account Key Filter field, and *S* in the Salt field."]]
