Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Procedimento de pareamento rápido
Procedimento
Em vez de invocar imediatamente qualquer um dos procedimentos normais de vinculação BR/EDR ou BLE, o Seeker primeiro ativa notificações na característica de pareamento baseado em chaves e, em seguida, grava os dados da Tabela 1.1 nela.
Ao processar uma solicitação de gravação de um Buscador de pareamento rápido, o provedor de pareamento rápido
vai fazer o seguinte:
Se o campo opcional "Chave pública" estiver presente:
Se o dispositivo não estiver no modo de pareamento, ignore a gravação e saia.
Caso contrário:
Use a chave pública recebida (um ponto de 64 bytes na curva elíptica
secp256r1), a chave privada antispoofing pré-instalada, também
secp256r1, e o algoritmo de curva elíptica Diffie-Hellman para
gerar uma chave AES de 256 bits.
Use SHA-256 para gerar hash da chave AES de 256 bits.
Pegue os primeiros 128 bits do resultado. Essa é a chave AES antispoofing
usada na próxima etapa.
Usando o AES-128, tente descriptografar o valor. Como o valor é um único
bloco AES de 16 bytes, não é necessário nenhum modo de criptografia de IV ou de vários blocos.
Qual chave usar:
Se uma chave AES antispoofing tiver sido gerada na etapa 1, use essa chave.
Caso contrário, tente cada chave na lista de chaves da conta mantida.
Se uma chave descriptografar o valor com êxito, será necessário fazer uma interrupção e prosseguir para a próxima etapa.
O valor será descriptografado se a saída corresponder ao formato da
Tabela 1.2.1 ou da Tabela 1.2.2, ou seja, se ele
contiver o endereço BLE atual do provedor de pareamento rápido ou o endereço público
do provedor de Pareamento rápido.
OBSERVAÇÃO: no final do pacote, há um sal anexado. Quando
possível, esses sais precisam ser rastreados e, se o provedor receber uma
solicitação com um sal já usado, ela precisará ser ignorada para
evitar ataques de repetição.
Como alternativa ao rastreamento de sais, se a gravação incluir o endereço particular
do provedor, outra maneira de evitar ataques de repetição é adiar
o tempo da próxima rotação de endereço particular resolvível para que
a rotação ocorra antes que a próxima gravação do pareamento baseado em chaves seja
aceita.
Se nenhuma chave conseguir descriptografar o valor, ignore a gravação e saia.
Mantenha uma contagem dessas falhas. Quando a contagem de falhas atingir 10, todas as novas solicitações serão reprovadas imediatamente. Redefina a contagem de falhas após cinco minutos,
após a ligação ou após uma conclusão.
Caso contrário, salve a chave de sucesso como K. Marque esse K como utilizável para
descriptografar gravações de chave de acesso e de nome personalizadas recebidas neste link de LE, mas
não em outras gravações nem em qualquer outro link. Inicie um timer para descartar
K após 10 segundos se o pareamento não tiver sido iniciado. Descarte também K se
esse link LE for desconectado.
Produza a resposta bruta de 16 bytes mostrada na Tabela 1.3, concatenando o tipo e o endereço BR/EDR do provedor e preenchendo o restante do pacote com um bloco de bytes aleatórios (ou seja, um sal).
Criptografe a resposta bruta com K para produzir a Resposta criptografada de 16 bytes mostrada na Tabela 1.4. Envie essa mensagem por uma notificação sobre a característica do pareamento
baseado em chaves.
Leia a sinalização da solicitação:
Se o byte de flags da solicitação tiver o bit 2 definido como 1, notifique a
Característica de dados adicionais com um nome personalizado.
Se o byte de flags da solicitação tiver o bit 1 definido como 1:
Isso indica que o Seeker está solicitando que o provedor inicie
a vinculação com o endereço BR/EDR do Seeker, que está presente nos bytes
8 a 13.
Envie um pedido de pareamento ao endereço BR/EDR da pessoa. A solicitação
de pareamento precisa ser a descrita abaixo (etapa "Durante o pareamento").
Motivo necessário: pedir para o provedor iniciar resolve um
problema em alguns dispositivos.
Se o byte de flags da solicitação tiver o bit 1 definido como 0:
Aguarde até 10 segundos por uma solicitação de pareamento. Se nenhum for recebido,
saia.
Pode ser uma solicitação BR/EDR de um endereço diferente
(o endereço público do Seeker, em vez do endereço particular resolvível).
Durante o pareamento, vamos verificar novamente se o dispositivo solicitante está
em posse de K.
Durante o pareamento:
Quando um pacote de solicitação/resposta de pareamento for recebido do Seeker:
se os recursos do dispositivo na solicitação forem NoInput/NoOutput, encerre o pareamento
para evitar o uso do método de pareamento Just Works.
Para o pacote de solicitação/resposta de pareamento enviado pelo provedor: defina o
campo "Device Capabilities" como Display/YesNo e defina os requisitos de
autenticação como MITM Protection necessária. Isso aciona o método de pareamento
de comparação numérica, também conhecido como Confirmação da chave de acesso
no Android.
Dependemos disso para confirmar se o dispositivo solicitante é de fato a pessoa que busca
pare rápido e que não há interceptação. Confira
exemplos.
O motivo é necessário: o método de pareamento fora de banda seria mais adequado, mas a plataforma não o expõe em todas as versões desejadas do
Android.
Quando a confirmação da chave de acesso for necessária, aguarde até 10 segundos para uma
gravação da característica da chave de acesso.
Normalmente, com esse método de pareamento, o usuário confirmaria que
as chaves de acesso exibidas na tela de cada dispositivo são idênticas. Em vez disso,
apenas para esse pareamento, transferimos
por BLE, criptografados com a chave pré-compartilhada confiável.
Observe que essa abordagem não deve ser adotada para dispositivos que têm uma
tela ou um teclado, porque isso compromete um pouco a proteção MITM.
No momento, o Pareamento rápido ainda não oferece suporte a esses tipos de dispositivos por
esse motivo.
Se o timer de 10 segundos expirar sem uma chave de acesso ser gravada,
descarte K.
Quando um valor é gravado na característica da chave de acesso, esse é o
bloco de chave de acesso criptografada. Descriptografe com K para gerar um bloco de chave de acesso bruta, com
o formato mostrado em Característica: chave de acesso>Tabela 2.2 - (tipo =
Chave de acesso do Seeker).
Se a descriptografia falhar, ignore a gravação e descarte K.
Caso contrário, o bloco de chave de acesso bruta vai conter uma chave de acesso
PSeeker de seis dígitos, que é esperada pelo usuário.
Compare o PSeeker com nossa chave de acesso esperada,
PProvider.
Se os valores forem iguais, responda "sim" à confirmação.
Caso contrário, responda "não" à confirmação, fazendo com que o pareamento falhe.
Mesmo que o pareamento falhe, produza outro bloco de chave de acesso bruta, com
o formato mostrado em Característica: chave de acesso>Tabela 2.2,
contendo nossa própria chave de acesso esperada, PProvider.
Verifique se o bloco tem o tipo correto (chave de acesso do provedor; consulte a tabela).
OBSERVAÇÃO: não reutilize o sal do bloco de chave de acesso recebido do
buscador. Gere um novo valor aleatório.
Criptografe o bloco de chave de acesso bruta com K e envie o
bloco de chave de acesso criptografado resultante com uma notificação na característica da chave de acesso.
Se o pesquisador receber e descriptografar a chave de acesso P correta, ele
também vai responder "sim" à confirmação e o pareamento será bem-sucedido.
Se o pareamento for bem-sucedido, marque K como utilizável para descriptografar as gravações
de chave de conta nesse link LE, mas não para gravações de chave de acesso
subsequentes nem gravações em qualquer outro link. Inicie um timer para descartar K após 10
segundos. Descarte também K após qualquer tentativa de gravar uma chave de conta
e, conforme a etapa 4, se o link LE for desconectado.
Se o pareamento falhar, descarte K.
Mude o campo de recursos do dispositivo de volta para os recursos padrão de E/S e
os requisitos de autenticação para o padrão para que os novos
pares continuem conforme o esperado.
Para provedores que não exigem vinculação, o buscador não envia uma
solicitação de pareamento ao provedor. As etapas 8 e 17 são ignoradas. Além disso,
"K" é usado em Características da chave da conta.
Exemplos
Exemplo 1:tentativa de pareamento bem-sucedida
(sem "man-in-the-middle").Exemplo 2:falha na tentativa de pareamento, com um
man-in-the-middle.
[null,null,["Última atualização 2025-08-13 UTC."],[[["\u003cp\u003eFast Pair utilizes BLE for initial key exchange and then triggers BR/EDR pairing for secure connection.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider verifies the Seeker's authenticity using encryption, a shared secret, and a numeric comparison pairing method.\u003c/p\u003e\n"],["\u003cp\u003eAccount Keys are exchanged securely after successful pairing to enable seamless future connections.\u003c/p\u003e\n"],["\u003cp\u003eThe process includes anti-spoofing measures like public key cryptography and salt tracking to enhance security.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider initiates the BR/EDR pairing to address compatibility issues with certain devices.\u003c/p\u003e\n"]]],[],null,["Fast Pair Procedure\n-------------------\n\n### Procedure\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\nInstead of immediately invoking any of the normal BR/EDR or BLE bonding\nprocedures, the Seeker first enables Notifications on the Key-based Pairing\ncharacteristic, and then writes the data in [Table 1.1](/nearby/fast-pair/specifications/characteristics#table1.1 \"table 1.1\") to it.\n\nWhen handling a write request from a Fast Pair Seeker, the Fast Pair Provider\nshall do the following:\n\n1. If the optional Public Key field **is present** :\n 1. If the device is not in pairing mode, ignore the write and exit.\n 2. Otherwise:\n 1. Use the received Public Key (a 64-byte point on the secp256r1 elliptic curve), the pre-installed [Anti-Spoofing Private Key](/nearby/fast-pair/specifications/configuration#antispoofing \"Anti-Spoofing\") - also secp256r1, and the Elliptic-Curve Diffie-Hellman algorithm to generate a 256-bit AES key.\n 2. Use SHA-256 to hash the 256-bit AES key.\n 3. Take the first 128 bits of the result. This is the Anti-Spoofing AES Key, used in the next step.\n2. Using AES-128, attempt to decrypt the value. Since the value is a single\n 16-byte AES block, no IV or multi-block cipher mode is necessary.\n\n 1. Which key to use:\n 1. If an Anti-Spoofing AES Key was generated in step 1, use that key.\n 2. Otherwise, try each key in the persisted Account Key List.\n 2. If a key successfully decrypts the value, break, and continue to the next step.\n 3. The value is decrypted successfully if the output matches the format in\n [Table 1.2.1](/nearby/fast-pair/specifications/characteristics#table1.2.1 \"table 1.2.1\") or [Table 1.2.2](/nearby/fast-pair/specifications/characteristics#table1.2.2 \"table 1.2.2\") - (that is, if it\n contains either the Fast Pair Provider's current BLE address, or the Fast\n Pair Provider's public address).\n\n NOTE: At the end of the packet there is a salt attached. When\n possible, these salts should be tracked, and if the Provider receives a\n request containing an already used salt, the request should be ignored to\n prevent replay attacks.\n 4. As an alternative to tracking salts, if the write includes the Provider's\n private address, another way to prevent replay attacks is to bring\n forward the time of the next resolvable private address rotation so that\n the rotation occurs before the next Key-based Pairing write will be\n accepted.\n\n3. If no key could successfully decrypt the value, ignore the write and exit.\n\n 1. Keep a count of these failures. **When the failure count hits 10, fail\n all new requests immediately. Reset the failure count after 5 minutes,\n after power on, or after a success.**\n4. Otherwise, save the successful key as *K* . Mark this *K* as usable for\n decrypting Passkey and Personalized name writes received on this LE link, but\n not other writes nor any writes on any other link. Start a timer to discard\n *K* after 10 seconds if pairing has not been started. Also discard *K* if\n this LE link disconnects.\n\n5. Produce the 16-byte Raw Response shown in [Table 1.3](/nearby/fast-pair/specifications/characteristics#table1.3 \"table 1.3\"), by\n concatenating the type and the Provider's BR/EDR address, and then filling\n the remainder of the packet with a block of random bytes (that is, a salt).\n\n6. Encrypt the Raw Response with K to produce the 16-byte Encrypted Response\n shown in [Table 1.4](/nearby/fast-pair/specifications/characteristics#table1.4 \"table 1.4\"). Send this via a notify on the Key-based Pairing\n characteristic.\n\n7. Read the request flag:\n\n 1. **If the Request's Flags byte has bit 2 set to 1** , notify [Additional Data characteristic](/nearby/fast-pair/specifications/characteristics#AdditionalData \"Characteristic - Additional Data\") with personalized name.\n 2. **If the Request's Flags byte has bit 1 set to 1:**\n 1. This indicates that the Seeker is requesting the Provider to initiate bonding to the Seeker's BR/EDR address, which is present in bytes 8-13.\n 2. Send a pairing request to the Seeker's BR/EDR address. The pairing request must be as described below (\"During pairing\" step).\n 3. Reason this is needed: Having the Provider initiate works around an issue on some devices.\n 3. **If the Request's Flags byte has bit 1 set to 0:**\n 1. Wait up to 10 seconds for a pairing request. If none is received, exit.\n 2. Note that this might be a BR/EDR request, from a different address (the Seeker's public address, instead of its resolvable private address). We will re-verify during pairing that the requesting device is in possession of *K*.\n8. During pairing:\n\n 1. When a **pairing request/response packet** is received from the Seeker: If the Device Capabilities in the request are NoInput/NoOutput, end pairing, to avoid using the Just Works pairing method.\n 2. For the pairing request/response packet sent by the Provider: Set the Device Capabilities field to **Display/YesNo** and set Authentication Requirements to **MITM Protection Required** . This triggers the Numeric Comparison pairing method (also known as [Passkey Confirmation](https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#PAIRING_VARIANT_PASSKEY_CONFIRMATION) on Android). We rely on this to confirm that the requesting device is in fact the Fast Pair Seeker, and that there is no man-in-the-middle. See [examples](#ProcedureExamples).\n 3. Reason this is needed: The Out-of-Band pairing method would be a better fit, but the platform does not expose it on all desired versions of Android.\n9. When **confirmation of the passkey is needed** , wait up to 10 seconds for a\n write to the [Passkey characteristic](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\").\n\n 1. Normally, with this pairing method, the user would confirm that the passkeys displayed on each device's screen are identical. Instead, only for this pairing, we transfer them over BLE, encrypted with the trusted pre-shared key.\n 2. Note that this approach should not be taken for devices that have a screen or a keyboard as it makes a slight compromise on MITM protection. Fast Pair currently does not support those device types yet because of this.\n 3. If the 10 second timer expires without a passkey being written, then discard *K*.\n10. When a **value is written to the Passkey characteristic** , this is the\n Encrypted Passkey Block. Decrypt it with K to yield a Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\") - (type =\n Seeker's Passkey).\n\n11. If decryption fails, ignore the write and discard *K*.\n\n12. Otherwise, the Raw Passkey Block contains a 6-digit passkey\n *P~Seeker~*, which is the passkey that the Seeker expects.\n\n13. Compare *P~Seeker~* with our own expected passkey,\n *P~Provider~*.\n\n 1. If the values are equal, reply \"yes\" to the confirmation.\n 2. Otherwise, reply \"no\" to the confirmation, causing pairing to fail.\n14. Regardless of whether pairing failed, produce another Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\"),\n containing our own expected passkey, *P~Provider~*.\n\n 1. Ensure the block has the correct type (Provider's Passkey; see table). NOTE: Do not reuse the salt from the Passkey Block received from the Seeker. Generate a new random value.\n15. Encrypt the Raw Passkey Block with *K*, and send the resulting Encrypted\n Passkey Block via a notify on the Passkey characteristic.\n\n16. If the Seeker receives and decrypts the correct passkey *P*, the Seeker will\n also reply \"yes\" to the confirmation, and pairing will succeed.\n\n 1. If the pairing succeeds, then mark *K* as usable for decrypting Account Key writes on this LE link, but not for any subsequent Passkey writes nor any writes on any other link. Start a timer to discard *K* after 10 seconds. Also discard *K* following any attempt to write an Account Key and, as per step 4, if the LE link disconnects.\n 2. If the pairing fails, discard *K*.\n17. Switch the device capabilities field back to default I/O capabilities and\n Authentication Requirements to default so that new\n pairings continue as expected.\n\nNote that for Providers that don't require bonding, the Seeker does not send a\npairing request to the Provider, that is step 8 - step 17 are skipped. Also,\n\"K\" is used in [Account Key characteristic](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\").\n\n##### Examples\n\n***Example 1:** Successful pairing attempt\n(no man-in-the-middle).* ***Example 2:** Failed pairing attempt, with a\nman-in-the-middle.*"]]
