Dispositivo Bluetooth de baixa energia (BLE)
A implementação do serviço Google Fast Pair (GFPS) para dispositivos BLE é compatível com a especificação central do Bluetooth v4.2 ou mais recente.
O adendo a seguir da especificação do Par rápido vai permitir o suporte a dispositivos de baixa energia (LE) e de áudio de baixa energia (LEA) no GFPS.
Níveis de compliance
As palavras-chave "deve", "deve", "deve", "deve", "pode" e "pode" mencionadas na especificação são explicadas abaixo:
| Termo | Descrição |
|---|---|
| dever | é obrigatório: usado para definir requisitos. |
| precisa | é usado para expressar: uma consequência natural de um requisito obrigatório declarado anteriormente OU uma declaração incontestável de fato (que é sempre verdadeira, independentemente das circunstâncias). |
| vai | É verdade que: só é usado em declarações de fato. |
| deveria | é recomendado que - é usado para indicar que, entre várias possibilidades, um é recomendado como particularmente adequado, mas não obrigatório. |
| podem | is allowed to: usado para permitir opções. |
| pode | Pode: é usado para relacionar a declaração de maneira causal. |
Característica de pareamento com base em chaves
Mensagem do buscador para o provedor
A solicitação bruta type 0x00 da característica de pareamento baseada em chave usa o bit 4
para indicar se o Seeker oferece suporte à especificação de dispositivo BLE e usa o
bit 5 para indicar se o Seeker oferece suporte ao áudio LE.
| Octet | Tipo de dado | Descrição | Valor | Obrigatório? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo de mensagem | 0x00 = solicitação de pareamento com base em chave |
Obrigatório |
| 1 | uint8 |
Sinalizações
|
varia | Obrigatório |
| 2 a 7 | uint48 |
Você pode:
|
varia | Obrigatório |
| 8 a 13 | uint48 |
Endereço BR/EDR do solicitante | varia | Presente apenas se os bits 1 ou 3 das flags estiverem definidos |
| n - 15 | Valor aleatório (sal) | varia | Obrigatório |
Mensagem do provedor para o solicitante
Quando o bit 4 da solicitação é definido, a nova mensagem de resposta type 0x02 para
a característica de pareamento baseada em chave pode ser usada para oferecer mais opções de
vinculação ao solicitante.
| Octet | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 |
Tipo de mensagem | 0x02 = resposta estendida do pareamento baseado em chaves |
| 1 | uint8 |
Flags
|
varia |
| 2 | uint8 |
Número de endereços do provedor (na versão atual, o número é 1 ou 2, porque precisamos modificar o modo de cifra de bloco para AES-CTR se o número for maior ou igual a 3) |
varia |
| 3 a 8 ou 3 a 14 |
|
varia | |
| 9 a 15 ou 15 | Valor aleatório (sal) | varia |
Um provedor que oferece suporte à especificação de dispositivo BLE precisa ler os bits 4 e 5 para entender os recursos do Seeker.
- Quando o Bit 4 é 0, o provedor deve ignorar o Bit 5 e responder com o formato
type 0x01 - Quando o bit 4 é 1,
- Para o provedor somente LE, ele responderá com
type 0x02para indicar a preferência de vinculação LE. - Para o provedor de modo duplo, ele pode responder com
type 0x02para indicar a preferência de vinculação BR/EDR ou LE.
- Para o provedor somente LE, ele responderá com
- Para casos de provedor de modo dual de áudio LE (LEA), consulte Exemplo: pareamento com o provedor de modo dual de LEA para referência.
Característica de PSM (Protocol Service Multiplexor) do fluxo de mensagens
Para oferecer suporte ao fluxo de mensagens em dispositivos BLE, o Pareamento rápido vai estabelecer e manter um canal BLE L2CAP para enviar e receber mensagens. O servidor Fast Pair L2CAP precisa implementar o controle de fluxo baseado em crédito LE.
Essa característica permite que o Seeker leia o valor do PSM e estabeleça uma conexão L2CAP segura pelo valor do PSM.
| Característica do serviço de Pareamento rápido | Criptografado | Permissões | UUID |
|---|---|---|---|
| PSM de stream de mensagens | Sim | Ler | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octet | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 |
Estado
|
varia |
| 1 - 2 | uint16 |
O valor do PSM precisa estar no intervalo entre 0x80 e 0xFF | varia |
Observação:o TWS tem dois
componentes: primário e secundário. O papel desses componentes é
intercambiável em determinadas condições. Supondo que A seja o componente principal e B seja
o componente secundário, devido ao consumo de bateria no componente A, o componente B precisa
assumir o papel de componente principal, e esse cenário é chamado de role switch.
Após role switch, se o provedor
não conseguir processar o stream de mensagens de Pareamento rápido, ele vai desconectar proativamente a
conexão L2CAP atual. O buscador do Pareamento rápido pode restabelecer a conexão do fluxo de mensagens
L2CAP com o novo componente principal.
Característica de chave de acesso extra
Essa característica é para fornecer proteção MITM nos componentes adicionais.
Proteção contra MITM de membro falso do CSIS
O Pareamento rápido exige a proteção MITM como parte do procedimento. Como o CSIS não oferece proteção contra MITM, o design atual de FP para vários componentes precisa ser estendido para fornecer proteção contra MITM nos componentes adicionais.
Definição da característica
| Característica do serviço de pareamento rápido | Criptografado | Permissão | UUID |
|---|---|---|---|
| Chave de acesso extra | Sim | Ler,gravar,notificar | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Mensagens
O formato da mensagem é aplicado a operações de leitura, gravação e notificação.
Formato de dados criptografados
Os dados criptografados são enviados usando a conexão GATT do Pareamento rápido.
| Octet | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0-15 | uint128 | Bloco de chaves de acesso adicionais criptografadas | varia |
Formato de dados brutos
Depois de descriptografar os dados criptografados com o secret compartilhado, o formato é o seguinte:
| Octet | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Tipo de mensagem | um de
|
| 1-3 | uint24 | Chave de acesso de seis dígitos | varia |
| 4-9 | uint48 | Endereço do componente de vinculação de destino | varia |
| 10 | uint8 | Código de status, usado apenas pela operação de leitura | Uma das
|
| 11-15 | Valor aleatório (sal) | varia |
O primário (primeiro componente vinculado) é a ponte entre o Seeker do Fast Pair e os componentes de vinculação adicionais. A característica precisa seguir as diretrizes:
- Ao receber uma solicitação de gravação do Buscador de Pareamento rápido, o provedor
- Define o endereço do componente que está sendo vinculado
- Enviar a chave de acesso para o componente que está sendo vinculado
- Definir o código de status como pendente, 0x01
- Ao receber qualquer solicitação de leitura antes de receber a chave de acesso do componente
que está sendo vinculado, o provedor vai retornar uma mensagem com
- Chave de acesso, qualquer valor
- Endereço do componente que está sendo vinculado
- Código de status pendente, 0x01
- Antes que o provedor envie uma notificação para o Fast Pair Seeker, ele define o resultado
da solicitação de leitura com
- Chave de acesso do componente que está sendo vinculado
- Endereço do componente que está sendo vinculado
- Código de status de sucesso, 0x00
- Se houver algum erro irrecuperável no lado do provedor, defina o resultado
- Chave de acesso, qualquer valor
- Endereço do componente que está sendo vinculado
- Código de status de falha, 0x02
Consulte o diagrama 1 do MITM e o diagrama 2 do MITM para mais detalhes.
Requisitos do dispositivo LE
LE Advertising
Para o modo detectável ou não detectável, o provedor deve usar RPA para anunciar dados do FastPair.
Capacidade de ligação
Para dispositivos compatíveis com LE, o Seeker precisa criar um vínculo com a conexão de LE atual. Depois de passar pela verificação de pareamento baseada na chave do Pareamento rápido, o provedor vai permitir a vinculação com a RPA e definir o capability de E/S como DisplayYesNo para a verificação da chave de acesso do Pareamento rápido.
Requisitos do dispositivo para o LEA
Publicidade do LEA
Para dispositivos de modo duplo: no modo detectável, o provedor precisa anunciar os dados do Pareamento rápido com o endereço de identidade. No modo não detectável, o provedor precisa anunciar os dados do Pareamento rápido com RPA. É altamente recomendável usar publicidade legada (BT 4.2) para oferecer suporte a dispositivos mais antigos e oferecer compatibilidade com versões anteriores. É necessário mudar o IRK sempre que o dispositivo for redefinido para a configuração original.
Para dispositivos não de modo duplo: no modo detectável ou não detectável, o provedor precisa usar a publicidade estendida (BT 5.0) com RPA para anunciar dados do FastPair.
O anúncio conectável LE que contém dados de serviço de FP deve incluir UUID do CAS em conformidade com o Perfil de Adaptador Bluetooth (BAP 1.0.1) e o requisito do Perfil de Áudio Comum. Para anúncios não detectáveis, se não houver espaço suficiente no anúncio legado devido à inclusão de dados de bateria e SASS, será obrigatório incluir o UUID do CAS na resposta de verificação.
Recurso de vinculação de LEA
O Buscador precisa criar uma vinculação com a conexão LE existente. Depois de passar pela verificação de pareamento baseada na chave do Pareamento rápido, o provedor de modo duplo vai permitir a vinculação com o endereço de identidade e o RPA, enquanto o provedor de modo não duplo vai permitir a vinculação com o RPA e definir o recurso de E/S como DisplayYesNo para a verificação de chave de acesso do Pareamento rápido.
Canal de comunicação interno entre componentes
A conexão GATT atual é mantida para executar a proteção MITM nos outros componentes. O componente principal vinculado precisa processar as entregas de mensagens entre o Buscador do Fast Pair e os componentes restantes.
A comunicação interna é usada para Initial Pair e Subsequent Pair
- Quando o procedimento de pareamento baseado em chave é transmitido para o componente principal, o componente principal precisa enviar uma mensagem para mudar o recurso de E/S dos componentes restantes.
- Quando o Pareamento rápido for concluído, o componente principal vai enviar uma mensagem para redefinir a capacidade de E/S dos componentes restantes
- Ao executar o procedimento de chave de acesso adicional, o componente principal precisa processar as chaves de acesso entre o Buscador de pareamento rápido e os componentes restantes.
Tempo para mudar o recurso de E/S
- Mudança do recurso de E/S para DisplayYesNo quando o procedimento de pareamento baseado em chaves é aprovado.
- Se o dispositivo tiver vários componentes, todos eles serão definidos como DisplayYesNo.
- Uma exceção que o provedor não pode
mudar o capability de E/S para DisplayYesNo é
Retroactive Pair, cujo bit 3 da solicitação de pareamento baseada em chave é definido como 1. Consulte Mensagem do solicitante para o provedor.
- Mudar a capacidade de E/S para a configuração padrão
- Pareamento inicial
- Se a conexão LE for desconectada, encerre a sessão do Pareamento rápido
- Depois que o primário for vinculado, se não houver outra solicitação de gravação de chave de acesso em 15 segundos, encerre a sessão do Par rápido.
- Depois que a solicitação de gravação de chave de acesso adicional for recebida, se o componente que está sendo vinculado não for vinculado em 15 segundos, encerre a sessão do Par rápido.
- Depois que todos os componentes forem vinculados, se não houver uma solicitação de gravação de chave de conta em 15 segundos, encerre a sessão do Par rápido
- Depois que a solicitação de gravação da chave da conta for recebida, defina o tempo limite de 15 segundos para encerrar a sessão do Par rápido.
- Pareamento subsequente
- Se a conexão de LE estiver desconectada, encerre a sessão de Pareamento rápido
- Depois que o primário for vinculado, se não houver outra solicitação de gravação de chave de acesso em 15 segundos, encerre a sessão do Par rápido.
- Depois que a solicitação de gravação de chave de acesso adicional for recebida, se o componente que está sendo vinculado não for vinculado em 15 segundos, encerre a sessão do Par rápido.
- Quando todos os componentes estiverem vinculados, encerrar a sessão do Pareamento rápido
- Pareamento inicial
Ocultar indicação da interface
Quando o fone de ouvido não estiver pronto para parear, o provedor usará type 0b0010
para definir a indicação de ocultação da interface para os dados da chave da conta e informar ao solicitante que não mostre
a interface de pareamento subsequente (consulte Payload de publicidade: dados da conta do Fast Pair).
Requisitos do dispositivo de áudio LE
Requisitos do Bluetooth
Consulte Recomendações de fones de ouvido para Android e LE Audio.
Suporte a CTKD
Para dispositivos de modo duplo, a CTKD de LE para BR/EDR é obrigatória e está alinhada aos requisitos do BAP.
Anúncio do destino
Um dispositivo periférico precisa usar o anúncio direcionado para solicitar uma conexão de um dispositivo central pareado. Os anúncios direcionados são definidos no BAP e no CAP para gerenciamento de conexão de acordo com a tabela 8.4 do CAP 1.0 (p48/58).
Suporte ao servidor GATT EATT
O EATT permite que o dispositivo central envie várias transações GATT em paralelo quando o dispositivo está vinculado. Para o dispositivo compatível com CSIP, ele aumentará a performance da conexão de perfil e, em breve, iniciará o procedimento de vinculação do CSIP para os outros fones de ouvido.
Armazenamento em cache robusto do GATT (recomendado)
Se o provedor não for um único dispositivo, mas um conjunto coordenado com implementação de CSIP, para reduzir o número de vezes que a descoberta de serviços é feita e acelerar a conexão, o provedor precisa implementar a armazenagem em cache GATT definida no Bluetooth 5.1.
Requisitos do Pareamento rápido
LE Advertising
Para o modo detectável ou não detectável, se o dispositivo tiver vários componentes, os dados do Pareamento rápido vão ser divulgados pelo componente principal. Se o dispositivo não estiver pronto para o próximo pareamento, o componente secundário poderá anunciar dados de Pareamento rápido para recursos estendidos. Consulte Ocultar indicação da interface.
Visibilidade do serviço GATT
O banco de dados GATT deve ser o mesmo para todas as conexões LE transporte GATT. O serviço de áudio LE (0x184E) será incluído no banco de dados GATT da conexão do Pareamento rápido.
Exemplo: pareamento com o provedor de modo duplo do LEA
Cenário 1: quando o Seeker não oferece suporte ao LEA
O provedor precisa ter compatibilidade com versões anteriores para o solicitante que não oferece suporte a LEA.
Componentes
- Provedor: A2DP/HFP/LEA
- Buscador: A2DP/HFP
Comportamento esperado para o par inicial / par subsequente
- O provedor anuncia dados de serviço do Par rápido (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar a publicidade legada
- O solicitante recebe o anúncio do provedor com o endereço de identidade para o pareamento inicial ou RPA para o pareamento subsequente.
- O solicitante envia uma solicitação de pareamento baseada em chave
- O bit 5 da sinalização da solicitação de pareamento baseada em chave é definido como 0.
- O provedor envia a resposta de pareamento com base na chave com o endereço público em uma das
seguintes formas:
- Se o tipo de mensagem 0x01 for usado, o endereço será público
- Se o tipo de mensagem 0x02 for usado
- O bit 0 precisa ser 0
- O bit-1 será 0
- O endereço precisa ser público
- O Seeker cria vínculo com o transporte BR/EDR
- A capacidade de E/S está definida como DisplayYesNo para BR/EDR
- O procedimento de verificação da chave de acesso do solicitante e do provedor do Fast Pair
Cenário 2: quando o usuário que busca ajuda com LEA
Componentes
- Provedor
- Suporte a A2DP/HFP/LEA
- Componente único
- Pessoas que procuram
- Suporte a A2DP/HFP/LEA
Comportamento esperado para o par inicial / par subsequente
- O provedor anuncia dados de serviço do Par rápido (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar publicidade legada
- O solicitante envia uma solicitação de pareamento baseado em chaves.
- O bit-5 da flag da solicitação de pareamento baseado em chaves está definido como 1.
- O provedor envia a resposta de pareamento baseada em chave com o tipo de mensagem 0x02
- O bit 0 precisa ser 0
- O bit 1 precisa ser 1
- O endereço é um endereço de identidade
- O Seeker cria uma ligação com a conexão
LE existente no transporte LE
- A direção da CTKD é de LE para BR/EDR
- O capability de IO é definido como DisplayYesNo para LE.
- O procedimento de verificação da chave de acesso do solicitante e do provedor do Fast Pair
Cenário 3: quando o Seeker oferece suporte para a LEA e a CSIP
Componentes
- Provedor
- Suporte a A2DP/HFP/LEA
- Vários componentes
- O componente principal é BR/EDR/LE
- O componente secundário é exclusivo para LE
- Buscador
- Suporte a A2DP/HFP/LEA
Comportamento esperado para o par inicial / par subsequente
- O componente principal anuncia dados de serviço do
Par rápido (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar a publicidade legada
- O Seeker envia a solicitação de pareamento baseada em chave para o componente principal
- O bit 5 da sinalização da solicitação de pareamento baseada em chave é definido como 1.
- O componente principal envia a resposta de pareamento baseado em chaves com o tipo de mensagem 0x02.
- O bit 0 precisa ser 0
- O bit-1 será 1
- O endereço é o seguinte:
- O primeiro endereço é o endereço de identidade do componente principal
- O segundo endereço é o endereço para o componente secundário. O segundo componente também o usa para fazer a divulgação CSIP.
- O Seeker cria uma ligação com o componente
principal na conexão LE existente
- A direção da CTKD é de LE para BR/EDR
- O recurso de E/S está definido como DisplayYesNo para LE
- O Seeker cria uma ligação com o componente secundário
cujo endereço é da resposta estendida de pareamento baseada em chave
- O recurso de E/S deve ser DisplayYesNo. Caso contrário, rejeitar a solicitação de pareamento
- O Seeker e o Provedor fazem o procedimento de proteção MITM para parear o componente secundário. O provedor implementará os dois cenários
- O Seeker espera até ser conectado ao componente secundário
Diagrama sequencial para o MITM
Esta sessão descreve a sequência do procedimento de proteção contra MITM.
Receber a chave de acesso do componente que está sendo vinculado por notificação
Receber a chave de acesso do componente que está sendo vinculado por leitura
Problema conhecido
O FP para LEA foi otimizado para funcionar com o Android V(Android 15).
Por outro lado, encontramos vários problemas com fones de ouvido que oferecem suporte ao LEA, mas não têm a implementação correta do Pareamento rápido sobre o LEA (ou seja, apenas o Pareamento rápido clássico). Por exemplo, quando a RPA do provedor não é gerada pela chave de resolução de identidade (IRK) correta e o endereço não pode ser resolvido. Embora não tenhamos conseguido testar uma lista abrangente de configurações de fones de ouvido, nossos testes limitados revelaram vários problemas, incluindo falha na exibição de notificações de bateria dos fones de ouvido, falta de funcionalidade de troca de áudio (SASS, na sigla em inglês), falhas iniciais e subsequentes generalizadas de pareamento e muito mais.
Portanto, recomendamos que os parceiros implementem a especificação do Pareamento rápido-LEA para novos dispositivos e dispositivos existentes no campo (por atualizações over-the-air) que ofereçam suporte a modos duplos.