프로필은 빠른 페어링 탐색기와 빠른 페어링 제공자라는 두 가지 역할을 정의합니다. 탐색기는 일반적으로 페어링할 기기를 찾는 휴대전화입니다. 제공자는 존재를 알리고 페어링할 준비가 되었음을 광고하는 기기입니다 (예: 검색 가능한 헤드폰 쌍).
빠른 페어링 탐색기는 GAP 중앙 역할을 사용해야 합니다. 빠른 페어링 제공자는 GAP 주변기기 역할을 사용해야 합니다(shall).
기기 검색
기기 검색을 용이하게 하기 위해 빠른 페어링 제공자는 Google 빠른 페어링 서비스 지원을 나타내는 페이로드를 광고해야 합니다 (아래 설명된 데이터 포함). 빠른 페어링 탐색기는 주기적으로 빠른 페어링 제공자 광고 프레임의 존재를 검색하고 관찰하며 관심이 있는 경우 조치를 취해야 합니다.
모델 ID
각 제공업체 모델에는 24비트 모델 ID가 있으며 이는 모델 등록 중에 Google에서 제공합니다.
전송 전력
제공자 기기는 광고 기기의 노출을 제한하기 위해 낮은 전송 전력 (TxPower)으로 광고해야 합니다. 하지만 광고가 최소 1m 떨어진 모든 휴대전화에 표시될 수 있을 만큼 전력이 높아야 합니다.
근접성을 확인하려면 빠른 페어링 탐색기가 빠른 페어링 제공자의 전송 전력을 알아야 합니다. 이 프로필의 목적상 TxPower는 소스 (0미터)에서 수신된 신호 강도로 정의되며 dBm으로 측정됩니다 (이는 Eddystone에서 정의하는 방식과 동일함).
이 측정값은 다음 방법 중 하나를 사용하여 전송해야 합니다.
광고 기록에 포함됨
기기에는 Tx Power Level 데이터 유형이 포함됩니다. ibid. § 1.5에 따라 광고를 게재해야 합니다.
모델 등록 시 제공됨
제조업체는 모델 등록 중에 Google에 전송 전력과 이를 측정하는 데 사용된 기기 모델을 제공합니다.
이 옵션을 사용할 때 거리 측정이 정확하도록 기기는 모든 브로드캐스트에 대해 전송 전력을 일정하게 유지해야 합니다.
키: 스푸핑 방지 공개/비공개 키 쌍
모델 등록 후 Google은 모델 ID와 함께 256비트 위조 방지 비공개 키 (secp256r1 타원 곡선의 [1, n–1] 정수)를 배포합니다. 이 키는 제공자 기기에 유지되어야 하며 이상적으로는 보안 요소 (SE) 내에 저장되어야 합니다. 보안 요소는 적극 권장됩니다. 보안 요소가 없으면 비공개 키가 유출될 수 있으므로 공격자가 제공자 역할을 스푸핑하지 못한다는 보장이 없습니다. 이 키 유출로 인해 중간자 공격이 발생할 수 있으므로, 가장 또는 악용이 감지되면 이 키를 사용하는 빠른 페어링 기능이 사용 중지될 수 있습니다 (예: 제공자가 페어링 모드에 있을 때 '탭하여 페어링' 알림).
해당 위조 방지 공개 키가 현재 제공업체에서 사용되지 않습니다. 이는 탐색기에서 제공자에게 보낼 메시지를 암호화하는 데 사용됩니다(키 기반 페어링 참고).
키: 계정 키 목록
제공자는 지속되는 128비트 계정 키 목록을 저장할 공간을 할당해야 합니다. 각 계정 키를 통해 제공업체가 특정 사용자 계정에 속한 것으로 인식될 수 있습니다.
목록은 키를 5개 이상 저장할 수 있어야 합니다 (즉, 이 목록에 전용으로 할당된 공간이 80바이트 이상이어야 함). 제공자는 선택적으로 이보다 더 많은 키를 저장할 수 있지만 키가 광고 패킷 내에 맞아야 합니다. 저장할 수 있는 정확한 수는 광고 패킷에서 사용할 수 있는 여유 바이트 수에 따라 달라집니다. 각 키가 차지하는 바이트 수를 확인하는 방법에 관한 자세한 내용은 계정 키 필터 섹션을 참고하세요. 예를 들어 계정 키 10개를 광고하려면 패킷에서 15바이트를 사용할 수 있어야 합니다. 하지만 개인 기기 (예: 헤드폰)의 경우 계정 키 수가 5개를 초과해서는 안 됩니다. 이는 계정 키의 수가 너무 많아지는 것을 방지하기 위한 것으로, 고유하고 추적 가능해야 합니다.
이 목록은 처음에는 비어 있으며 제공자가 초기화되는 경우 (사용자가 페어링된 기기 목록을 삭제하는 경우) 삭제해야 합니다. 목록은 계정 키 특성 섹션에 설명된 대로 채워집니다.
BLE 주소 정보
추적을 방지하기 위해 BLE 광고는 무작위로 해결 가능한 비공개 주소 (RPA)를 사용해야 합니다. 기기가 적극적으로 광고하는 동안에는 최소 15분마다 주소를 순환해야 하고, 광고하지 않는 상태에서 광고하는 상태로 변경될 때마다 주소를 순환해야 합니다. 무작위 오프셋을 사용하여 주소 무작위화 간격을 변경해야 합니다.
속성 프로토콜 (ATT) MTU 크기 협상
가능한 경우 ATT 최대 전송 단위 (MTU) 값 83을 사용해야 하지만 기본값 23도 허용됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-13(UTC)"],[[["\u003cp\u003eFast Pair uses Bluetooth Low Energy (BLE) and defines two roles: Seeker (typically a phone) and Provider (a device like headphones).\u003c/p\u003e\n"],["\u003cp\u003eProvider devices advertise their presence and support for Fast Pair, allowing Seekers to discover them.\u003c/p\u003e\n"],["\u003cp\u003eEach Provider model has a unique Model ID and transmits at a low power while ensuring discoverability within 1 meter.\u003c/p\u003e\n"],["\u003cp\u003eSecurity is emphasized through anti-spoofing keys and an Account Key list to link the Provider to user accounts.\u003c/p\u003e\n"],["\u003cp\u003ePrivacy is maintained by using random, rotating BLE addresses to minimize tracking.\u003c/p\u003e\n"]]],[],null,["Configuration\n-------------\n\n### Roles\n\nThe profile defines two roles: *Fast Pair Seeker* , and *Fast Pair Provider*. The\nSeeker is normally a phone, looking for a device to pair with. The Provider is a\ndevice that is advertising its presence and readiness to pair (e.g. a\ndiscoverable pair of headphones).\n\nThe Fast Pair Seeker shall use the GAP Central role. The Fast Pair Provider\nshall use the GAP Peripheral role.\n\n### Device discovery\n\nTo facilitate device discovery, the Fast Pair Provider shall advertise a payload\nindicating support for the Google Fast Pair Service (with data as described\nbelow). The Fast Pair Seeker shall periodically scan for and observe the\npresence of Fast Pair Provider advertising frames, and take action if\ninterested.\n\n### Model ID\n\nEach Provider model has a 24-bit model ID, which is provided by Google during\n[Model Registration](/nearby/fast-pair/specifications/service/modelregistration \"Model Registration\").\n\n### Transmit power\n\nProvider devices should advertise at a low transmit power (*TxPower*) to limit\nexposure of the advertised device. However, the power shall be high enough such\nthat the advertisement is visible by any phone at least 1 meter away.\n\nTo determine proximity, the Fast Pair Seeker must know the Fast Pair Provider's\ntransmit power. For the purposes of this profile, TxPower is defined as the\nreceived signal strength at source (0 meters), measured in dBm (this is the same\nway that\n[Eddystone](https://github.com/google/eddystone/tree/master/eddystone-uid#tx-power)\ndefines it).\n| **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.\n\nThis measured value shall be transmitted using one of these methods:\n\n**Included in the Advertisement Record**\n: The device includes the *Tx Power Level* data type, **ibid.**, § 1.5, in its\n advertisement.\n\n**Provided during model registration**\n: The manufacturer provides Google with the transmit power, and the device model\n used to measure it, during Model Registration.\n: The device must keep its transmit power constant for all broadcasts when\n using this option so that distance measurements are accurate.\n\n### Keys: Anti-Spoofing Public/Private Key Pair\n\nAfter model registration, along with the Model ID, Google will distribute a\n256-bit Anti-Spoofing Private Key (an integer in \\[1,n--1\\] on the secp256r1\nelliptic curve). This key shall be persisted on the Provider device, and ideally\nstored inside a Secure Element (*SE*). Note that a Secure Element is strongly\nrecommended---in the absence of one, there is no guarantee that attackers could\nnot spoof the provider role, because the private key could leak. This key\nleaking opens up the possibility of man in the middle attacks; therefore, if\nimpersonation or abuse is detected, Fast Pair features that use this key may be\ndisabled (for example, the \"Tap to pair\" notification when the Provider is in\npairing mode).\n\nThe corresponding Anti-Spoofing Public Key is not currently used by the\nProvider. It is used by the Seeker, to encrypt a message to send to the Provider\n(see [Key-based Pairing](/nearby/fast-pair/specifications/characteristics#KeyBasedPairing \"Key Based Pairing\")).\n\n### Keys: Account Key List\n\nThe Provider shall allocate space to store a persisted list of 128-bit Account\nKeys. Each Account Key allows the Provider to be recognized as belonging to a\ncertain user account.\n\nThe list must be able to store at least five keys (that is, there must be at\nleast 80 bytes of space dedicated to this list). Providers can optionally store\nmore than this, they just must make sure that the keys will fit inside of their\nadvertising packet. The exact number that can be stored will depend on how many\nfree bytes are available in the advertising packet; see the [Account Key\nFilter](/nearby/fast-pair/specifications/service/provider#AccountKeyFilter \"Account Key Filter\") section for more information on determining how many\nbytes each key will take up. For example, to advertise 10 account keys, 15 bytes\nneed to be available in the packet.But for personal devices (e.g. headphones),\nthe number of account keys should not be greater than 5. This is to avoid the\nnumber of account keys becoming too large, and hence it could be unique and\ntrackable.\n\nThis list is initially empty, and must be cleared if the Provider is\nfactory-reset (if the user clears its paired device list). The list is populated\nas described in the [Account Key characteristic](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\") section.\n\n### BLE address information\n\nTo prevent tracking, BLE advertising shall use the random resolvable private\naddress (*RPA*). The address shall be rotated at minimum every 15 minutes while\nthe device is actively advertising, and every time the state changes from not\nadvertising to advertising. A randomized offset should be used to alter the\naddress randomization interval.\n\n### Attribute Protocol (ATT) MTU Size Negotiation\n\nAn ATT maximum transmission unit (MTU) value of 83 should be used whenever\npossible, but the default value of 23 is allowed."]]
