Dispositivo Bluetooth de baixa energia (BLE)
A implementação do Serviço de pareamento rápido do Google (GFPS, na sigla em inglês) para dispositivos BLE é compatível com a especificação principal do Bluetooth v4.2 ou mais recente.
O seguinte adendo à especificação do pareamento rápido vai permitir a compatibilidade com dispositivos somente de baixa energia (LE) e áudio de baixa energia (LEA) no GFPS.
Níveis de conformidade
As palavras-chave "deve", "precisa", "vai", "deveria", "pode" e "consegue" mencionadas na especificação são explicadas abaixo:
| Termo | Descrição |
|---|---|
| dever | é obrigatório para: usado para definir requisitos. |
| precisa | é usado para expressar: uma consequência natural de um requisito obrigatório declarado anteriormente OU uma declaração indiscutível de um fato (que é sempre verdadeiro, independente das circunstâncias). |
| vai | é verdade que: usado apenas em declarações de fatos. |
| deveria | é recomendado que: usado para indicar que, entre várias possibilidades, uma é recomendada como particularmente adequada, mas não obrigatória. |
| podem | tem permissão para: usado para permitir opções. |
| pode | é capaz de: usado para relacionar declarações de maneira causal. |
Característica de pareamento baseada em chave
Mensagem do solicitante para o provedor
A solicitação bruta type 0x00 da característica de pareamento com base em chaves usa o bit 4
para indicar se o buscador é compatível com a especificação do dispositivo BLE e usa o
bit 5 para indicar se o buscador é compatível com o LE Audio.
| 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 |
Flags
|
varia | Obrigatório |
| 2 a 7 | uint48 |
Uma das seguintes opções:
|
varia | Obrigatório |
| 8 a 13 | uint48 |
Endereço de BR/EDR do requerente | varia | Presente apenas se o bit 1 ou 3 das flags estiver definido |
| n: 15 | Valor aleatório (salt) | 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 baseado em chave pode ser usada para oferecer mais opções de
vinculação ao Seeker.
| Octet | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 |
Tipo de mensagem | 0x02 = resposta estendida de pareamento com base em chave |
| 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 criptografia de bloco para AES-CTR se o número for >= 3) |
varia |
| 3 a 8 ou 3 a 14 |
|
varia | |
| 9 a 15 ou 15 | Valor aleatório (salt) | varia |
Um provedor que oferece suporte à especificação de dispositivo BLE precisa ler o bit 4 e o bit 5 para entender os recursos do buscador.
- Quando o bit 4 é 0, o provedor ignora o bit 5 e responde com o formato
type 0x01. - Quando o bit 4 é 1,
- Para um provedor somente LE, ele vai 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 de BR/EDR ou LE.
- Para um provedor somente LE, ele vai responder com
- Para casos de provedores de modo duplo LE Audio (LEA), consulte Exemplo: pareamento com um provedor de modo duplo LEA para referência
Característica do PSM (multiplexador de serviço de protocolo) de fluxo de mensagens
Para oferecer suporte ao fluxo de mensagens em dispositivos BLE, o Pareamento rápido vai estabelecer e manter um canal L2CAP BLE para enviar e receber mensagens. Pareamento rápido O servidor 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 |
|---|---|---|---|
| Gerente de vendas de parceiro do Message Stream | Sim | Ler | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octet | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 |
Estado
|
varia |
| 1 - 2 | uint16 |
O valor de PSM precisa estar entre 0x80 e 0xFF. | varia |
Observação:para o TWS, há dois componentes: primário e secundário. Em determinadas condições, as funções desses componentes são intercambiáveis. Supondo que A seja o componente principal e B seja o secundário, devido ao consumo da bateria no componente A , o componente B precisa assumir a função de componente principal. Esse cenário é chamado de role switch.
Depois de role switch, se o provedor
não conseguir processar o fluxo de mensagens do Pareamento rápido, ele vai desconectar proativamente a
conexão L2CAP atual. Em seguida, o buscador do Pareamento Rápido pode restabelecer a conexão de fluxo de mensagens L2CAP com o novo componente principal.
Característica adicional da chave de acesso
Essa característica é para oferecer proteção contra MITM nos componentes adicionais.
Proteção contra MITM de membros falsos do CSIS
O Pareamento rápido exige proteção contra MITM como parte do procedimento de pareamento. Como o CSIS não oferece proteção contra MITM, o design atual de FP para vários componentes precisa ser estendido para oferecer proteção contra MITM nos componentes adicionais.
Definição de 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 às 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 chave de acesso adicional criptografado | varia |
Formato de dados brutos
Depois de descriptografar os dados criptografados usando a senha secreta, o formato será como abaixo
| Octet | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Tipo de mensagem | um destes:
|
| 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 seguintes opções:
|
| 11-15 | Valor aleatório (salt) | varia |
O principal (primeiro componente vinculado) é a ponte entre o Seeker do pareamento rápido e os outros componentes de vinculação. A característica precisa seguir as diretrizes:
- Ao receber uma solicitação de gravação do Fast Pair Seeker, o provedor precisa
- Defina 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 sendo vinculado
- Código de status pendente, 0x01
- Antes de o provedor enviar a notificação para o Fast Pair Seeker, defina o resultado
para a solicitação de leitura com
- Chave de acesso do componente que está sendo vinculado
- Endereço do componente sendo vinculado
- Código de status de sucesso, 0x00
- Se houver um erro irrecuperável no lado do provedor, defina o resultado
- Chave de acesso, qualquer valor
- Endereço do componente 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
No modo detectável ou não detectável, o provedor precisa usar RPA para anunciar dados do FastPair.
Capacidade de vinculação
Para dispositivos compatíveis com LE, o Seeker precisa criar uma vinculação com a conexão LE atual. Depois de passar na verificação de pareamento com base em chaves do Pareamento rápido, o provedor vai permitir a vinculação com o RPA e definir a capacidade de E/S como DisplayYesNo para a verificação de senha do Pareamento rápido.
Requisitos de dispositivos para LEA
Anúncio da LEA
Para dispositivos de modo duplo: No modo detectável, o provedor vai anunciar dados de Pareamento rápido com endereço de identidade. No modo não detectável, o provedor precisa anunciar dados do Pareamento rápido com RPA. É altamente recomendável usar publicidade legada (BT 4.2) para oferecer suporte a dispositivos mais antigos e compatibilidade com versões anteriores. É necessário mudar o IRK sempre que o dispositivo for redefinido para a configuração original.
Para dispositivos que não são de modo duplo: No modo detectável ou não detectável, o provedor usará publicidade estendida (BT 5.0) com RPA para anunciar dados do FastPair.
O anúncio conectável LE que contém dados do serviço FP precisa incluir o UUID do CAS de acordo com o perfil do adaptador Bluetooth (BAP 1.0.1) e o requisito do perfil de áudio comum.
O provedor pode indicar a capacidade de LEA incluindo o UUID do CAS (0x1853) nos dados de serviço (tipo de anúncio 0x16) ou nos UUIDs de classe de serviço de 16 bits (tipo de anúncio 0x02 ou 0x03), independente do modo detectável.
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, é obrigatório incluir o UUID do CAS na resposta de verificação.
Capacidade de vinculação de LEA
O Seeker precisa criar uma vinculação com a conexão LE atual. Depois de passar pela verificação de pareamento baseada em 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 único vai permitir a vinculação com o RPA e definir a capacidade de E/S como DisplayYesNo para a verificação de senha do Pareamento rápido.
Canal de comunicação interna entre componentes.
A conexão GATT atual é mantida para realizar a proteção MITM nos componentes adicionais. O componente principal vinculado vai processar as entregas de mensagens entre o pareamento rápido Seeker e os componentes restantes.
A comunicação interna é usada para Initial Pair e Subsequent Pair
- Quando o procedimento de pareamento baseado em chave for aprovado no componente principal, ele vai enviar uma mensagem para mudar a capacidade 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 vai processar as entregas de chaves de acesso entre o Fast Pair Seeker e os componentes restantes.
Hora de mudar a capacidade de E/S
- Mudar a capacidade de E/S para DisplayYesNo quando o procedimento de pareamento baseado em chave for aprovado
- Se o dispositivo tiver vários componentes, todos eles deverão ser definidos como DisplayYesNo
- Uma exceção é que o provedor não pode mudar a capacidade de E/S para DisplayYesNo. É
Retroactive Pair, cujo bit 3 da solicitação de pareamento com base em chave está definido como 1. Consulte Mensagem do buscador 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 de pareamento rápido.
- Depois que a chave principal for vinculada, se não houver outra solicitação de gravação de chave de acesso em 15 segundos, encerre a sessão do pareamento rápido.
- Depois que outra solicitação de gravação de chave de acesso for recebida, se o componente que está sendo vinculado não for vinculado em 15 segundos, encerre a sessão do pareamento rápido.
- Depois que todos os componentes estiverem conectados, se não houver uma solicitação de gravação da chave da conta em 15 segundos, encerre a sessão do pareamento 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 pareamento rápido.
- Pareamento subsequente
- Se a conexão LE for desconectada, encerre a sessão de pareamento rápido.
- Depois que a chave primária for vinculada, se não houver outra solicitação de gravação de chave de acesso em 15 segundos, encerre a sessão do pareamento rápido.
- Depois que outra solicitação de gravação de chave de acesso for recebida, se o componente que está sendo vinculado não for vinculado em 15 segundos, encerre a sessão do pareamento rápido.
- Quando todos os componentes estiverem conectados, encerre a sessão de pareamento rápido.
- Pareamento inicial
Ocultar indicação da interface
Quando o headset não estiver pronto para pareamento, o provedor vai usar type 0b0010
para definir a indicação de ocultar a interface do usuário para dados da chave da conta e informar ao buscador para não mostrar
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 Android, recomendações de fones de ouvido LE Audio.
Suporte a CTKD
Para dispositivos de modo duplo, a CTKD do LE para BR/EDR é obrigatória e está alinhada aos requisitos do BAP.
Anúncio de destino
Um dispositivo periférico precisa usar o anúncio segmentado para solicitar uma conexão de um dispositivo central pareado. Os anúncios segmentados são definidos no BAP e no CAP para gerenciamento de conexões de acordo com a Tabela 8.4 do CAP 1.0 (p48/58).
Suporte ao servidor EATT GATT
O EATT permite que o dispositivo central envie várias transações GATT em paralelo quando o dispositivo está conectado. Para o dispositivo compatível com CSIP, isso vai aumentar o desempenho da conexão de perfil e, em seguida, iniciar o procedimento de vinculação CSIP para os outros buds.
Armazenamento em cache robusto do GATT (altamente 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 o cache GATT definido no Bluetooth 5.1.
Requisitos do Pareamento Rápido
LE Advertising
No modo detectável ou não detectável, se o dispositivo tiver vários componentes, os dados do Pareamento Rápido serão anunciados pelo componente principal. Se o dispositivo não estiver pronto para o pareamento subsequente, 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 precisa ser o mesmo para todas as conexões GATT de transporte LE. O serviço LE Audio (0x184E) precisa ser incluído no banco de dados GATT da conexão do Pareamento rápido.
Exemplo: pareamento com um provedor de modo duplo LEA
Cenário 1: quando o Seeker não é compatível com LEA
O provedor precisa ter compatibilidade com versões anteriores para o requerente que não oferece suporte à LEA.
Componentes
- Provedor: A2DP/HFP/LEA
- Procurador: A2DP/HFP
Comportamento esperado para o pareamento inicial / subsequente
- O provedor anuncia dados do serviço de pareamento rápido (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar a publicidade legada
- O Seeker recebe o anúncio do Provider com o endereço de identidade para pareamento inicial ou RPA para pareamentos subsequentes.
- O solicitante envia uma solicitação de pareamento com base em chave
- O bit 5 da flag da solicitação de pareamento com base em chave está definido como 0.
- O provedor envia a resposta de pareamento baseado em chave com o endereço público em uma das seguintes opções:
- 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 precisa ser 0
- O endereço precisa ser público.
- O Seeker cria vínculo com o transporte de BR/EDR
- A capacidade de E/S é definida como DisplayYesNo para BR/EDR
- O solicitante e o provedor fazem o procedimento de verificação da chave de acesso do Pareamento rápido
Cenário 2: quando o Seeker é compatível com LEA
Componentes
- Provedor
- Suporte a A2DP/HFP/LEA
- Componente único
- Seeker
- SupportA2DP/HFP/LEA
Comportamento esperado para o pareamento inicial / subsequente
- O provedor anuncia dados do serviço de pareamento rápido (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar a publicidade legada
- O solicitante envia uma solicitação de pareamento com base em chave
- O bit 5 da flag da solicitação de pareamento com base em chave está definido como 1.
- O provedor envia uma resposta de pareamento baseado em chave com o tipo de mensagem 0x02
- O bit 0 precisa ser 0
- O bit 1 precisa ser 1
- O endereço é o endereço de identidade
- O Seeker cria uma vinculação com a conexão
LE atual no transporte
- A direção do CTKD é de LE para BR/EDR
- A capacidade de E/S é definida como DisplayYesNo para LE
- O solicitante e o provedor fazem o procedimento de verificação da chave de acesso do Pareamento rápido
Cenário 3: quando o requerente tem suporte para LEA e CSIP envolvidos
Componentes
- Provedor
- Suporte a A2DP/HFP/LEA
- Vários componentes
- O componente principal é BR/EDR/LE
- O componente secundário é exclusivo para LE
- Seeker
- Suporte a A2DP/HFP/LEA
Comportamento esperado para o pareamento inicial / subsequente
- O componente principal anuncia dados do serviço de pareamento rápido (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar a publicidade legada
- O Seeker envia uma solicitação de pareamento com base em chave ao componente principal
- O bit 5 da flag da solicitação de pareamento com base em chave está definido como 1.
- O componente principal envia a resposta de pareamento com base em chave com o tipo de mensagem 0x02
- O bit 0 precisa ser 0
- O bit 1 precisa ser 1
- Os endereços são:
- O primeiro endereço é o endereço de identidade do componente principal.
- O segundo endereço é o endereço vinculável do componente secundário. O segundo componente também usa esse endereço para fazer a publicidade de CSIP.
- O Seeker cria uma conexão com o componente principal na conexão LE atual.
- A direção do CTKD é de LE para BR/EDR
- A capacidade de E/S é definida como DisplayYesNo para LE
- O Seeker cria uma vinculação com o componente
secundário cujo endereço é da resposta estendida de pareamento
baseado em chave.
- A capacidade de E/S precisa ser DisplayYesNo. Caso contrário, rejeite a solicitação de pareamento.
- O Solicitante e o Provedor fazem o procedimento de proteção MITM para parear o componente secundário. O Provedor precisa implementar os dois cenários.
- O Seeker aguarda até que esteja vinculado ao componente secundário.
Diagrama sequencial para 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 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 headsets que oferecem suporte a LEA, mas não têm a implementação correta do Pareamento rápido via LEA (ou seja, apenas Pareamento rápido via Classic). 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), falhas generalizadas de pareamento inicial e subsequente e muito mais.
Por isso, recomendamos que os parceiros implementem a especificação Fast Pair-LEA para dispositivos novos e atuais em campo (por atualizações OTA) que oferecem suporte a modos duplos.