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 o suporte para dispositivos 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 | is required to: usado para definir requisitos. |
| precisa | é usado para expressar: uma consequência natural de um requisito obrigatório declarado anteriormente OU uma declaração de fato indiscutível (que é sempre verdadeira, independentemente das circunstâncias). |
| vai | it is true that: usado apenas em declarações de fatos. |
| deveria | is recommended that: usado para indicar que, entre várias possibilidades, uma é recomendada como particularmente adequada, mas não obrigatória. |
| podem | is permitted to: usado para permitir opções. |
| pode | is able to: usado para relacionar declarações de maneira causal. |
Característica de pareamento com base em chave
Mensagem do buscador para o provedor
A solicitação bruta type 0x00 da característica de pareamento baseado em chave usa o bit 4
para indicar se o buscador é compatível com a especificação de dispositivo BLE e usa o
bit 5 para indicar se o buscador é compatível com o LE Audio.
| Octeto | 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 - 7 | uint48 |
Você pode:
|
varia | Obrigatório |
| 8 - 13 | uint48 |
Endereço BR/EDR do buscador | 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 buscador
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 fornecer mais opções de vinculação
ao buscador.
| Octeto | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 |
Tipo de mensagem | 0x02 = Resposta longa de pareamento com base em chave |
| 1 | uint8 |
Sinalizações
|
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 >= 3) |
varia |
| 3 a 8 ou 3 a 14 |
|
varia | |
| 9 - 15 ou 15 | Valor aleatório (salt) | varia |
Um Provedor compatível com a Especificação de Dispositivo BLE precisa ler os bits 4 e 5 para entender os recursos do Buscador.
- Quando o bit 4 é 0, o provedor precisa ignorar o bit 5 e responder com o formato
type 0x01. - Quando o bit 4 é 1,
- Para o provedor somente LE, ele deve 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 deve responder com
- Para casos de Provedor de modo duplo de LE Audio (LEA), consulte Exemplo: pareamento com Provedor de modo duplo de LEA para referência.
Característica do PSM (multiplexador de serviço de protocolo) do fluxo de mensagens
Para oferecer suporte ao fluxo de mensagens para dispositivos BLE, o Pareamento rápido vai estabelecer e manter um canal BLE L2CAP 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 Buscador leia o valor do PSM e estabeleça uma conexão L2CAP segura com base nele.
| Característica do serviço de Pareamento Rápido | Criptografado | Permissões | UUID |
|---|---|---|---|
| PSM do fluxo de mensagens | Sim | Ler | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octeto | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 |
Estado
|
varia |
| 1 - 2 | uint16 |
O valor de PSM precisa estar no intervalo entre 0x80 e 0xFF | varia |
Observação: para TWS, há dois
componentes: primário e secundário. A função desses componentes é
intercambiável em determinadas condições. Supondo que A seja o componente principal e B seja o
secundário, devido ao consumo de bateria no componente A , o componente B precisa
assumir o papel de componente principal. Esse cenário é chamado de role switch.
Após role switch, se o provedor
não puder processar o fluxo de mensagens do 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 adicional da chave de acesso
Essa característica é para fornecer proteção MITM nos componentes adicionais.
Proteção contra MITM de membro falso do CSIS
O Pareamento Rápido requer proteção contra MITM como parte do procedimento de pareamento. Como o CSIS não oferece proteção contra MITM, o design atual do 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 adicional | Não | 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.
| Octeto | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0-15 | uint128 | Bloco de chave de acesso extra criptografado | varia |
Formato de dados brutos
Depois de descriptografar os dados criptografados usando o secret compartilhado, o formato é o seguinte:
| Octeto | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Tipo de mensagem | um de
|
| 1-3 | uint24 | Chave de acesso de 6 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 | Um de
|
| 11-15 | Valor aleatório (salt) | varia |
O principal (primeiro componente vinculado) é a ponte entre o buscador de 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 buscador de Pareamento rápido, o provedor precisa
- Definir o endereço do componente que está sendo vinculado
- Envie a chave de acesso para o componente que está sendo vinculado.
- Defina 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 precisa retornar uma mensagem com
- Chave de acesso, qualquer valor
- Endereço do componente que está sendo vinculado
- Código de status pendente, 0x01
- Antes de enviar a notificação ao buscador de Pareamento rápido, o provedor 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 um 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 de MITM e o diagrama 2 de MITM para mais detalhes.
Requisitos do dispositivo LE
Anúncio de LE
Para o modo detectável ou não detectável, o Provedor precisa usar o RPA para anunciar dados do Pareamento rápido.
Capacidade de vinculação
Para dispositivos compatíveis com LE, o Buscador precisa criar um vínculo com a conexão LE existente. Depois de passar na verificação de pareamento baseado em chave do Pareamento rápido, o provedor precisa 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 de 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 o RPA. É altamente recomendável usar o anúncio legado (BT 4.2) para oferecer suporte a dispositivos mais antigos para compatibilidade com versões anteriores. É necessário mudar a IRK sempre que o dispositivo for redefinido para a configuração original.
Para dispositivos que não são de modo duplo: para o modo detectável ou não detectável, o provedor precisa usar a publicidade estendida (BT 5.0) com RPA para anunciar dados do Pareamento rápido.
O anúncio conectável de LE que contém dados de serviço de FP precisa incluir o UUID de 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 o recurso 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), independentemente 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 nesse caso.
Capacidade de vinculação de LEA
O buscador precisa criar um vínculo com a conexão LE atual. Depois de passar na verificação de pareamento com base em chave do Pareamento rápido, o provedor de modo duplo precisa permitir a vinculação com o endereço de identidade e o RPA, enquanto o provedor de modo não duplo precisa 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 interna entre componentes
A conexão GATT atual é mantida para realizar a proteção contra MITM nos componentes adicionais. O componente vinculado principal precisa processar as entregas de mensagens entre o buscador de Pareamento rápido e os componentes restantes.
A comunicação interna é usada para Initial Pair e Subsequent Pair.
- Quando o procedimento de pareamento baseado em chave é transmitido no componente principal, ele precisa 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 precisa processar as entregas de chaves de acesso entre o buscador do Pareamento rápido e os componentes restantes.
Hora de mudar a capacidade de IO
- 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 precisarão ser definidos como DisplayYesNo.
- Uma exceção em que o Provedor não
pode mudar o recurso de E/S para DisplayYesNo é
Retroactive Pair, em que o Bit 3 da Solicitação de Pareamento Baseado 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 o dispositivo principal for vinculado, se não houver outra solicitação de gravação de chave de acesso em 15 segundos, encerre a sessão de 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 até 15 segundos, encerre a sessão de Pareamento 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 de 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 de Pareamento rápido.
- Pareamento subsequente
- Se a conexão LE for desconectada, encerre a sessão de Pareamento rápido.
- Depois que o dispositivo principal for vinculado, se não houver outra solicitação de gravação de chave de acesso em até 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 até 15 segundos, encerre a sessão de Pareamento rápido.
- Quando todos os componentes estiverem vinculados, encerre a sessão de Pareamento rápido.
- Pareamento inicial
Ocultar indicação da interface
Quando o fone de ouvido não estiver pronto para pareamento, o Provedor vai usar type 0b0010
para definir a indicação de ocultar a IU para os dados da chave da conta, informando ao Buscador que não deve mostrar
a IU de pareamento subsequente (consulte Payload de publicidade: dados da conta de Pareamento rápido).
Requisitos de dispositivos LE Audio
Requisitos do Bluetooth
Consulte as recomendações de fones de ouvido LE Audio para Android.
Suporte ao CTKD
Para dispositivos de modo duplo, a CTKD de LE para BR/EDR é obrigatória e está alinhada aos requisitos do BAP.
Anúncio de destino
Um dispositivo periférico deve usar o anúncio direcionado para solicitar uma conexão de um dispositivo central pareado. Os anúncios segmentados são definidos em BAP e CAP para gerenciamento de conexão de acordo com a Tabela 8.4 (p48/58) do CAP 1.0.
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 o CSIP, ele vai aumentar o desempenho da conexão do perfil e, em seguida, iniciar o procedimento de vinculação do CSIP para os outros fones.
Armazenamento em cache robusto do GATT (altamente recomendado)
Se o provedor não for um único dispositivo, mas um conjunto coordenado com a implementação do 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 armazenamento em cache do GATT definido no Bluetooth 5.1.
Requisitos do Pareamento Rápido
Anúncio de LE
Para o 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 de pareamento rápido.
Exemplo: pareamento com o provedor de modo duplo LEA
Cenário 1: quando o buscador não é compatível com LEA
O Provedor precisa ter compatibilidade com versões anteriores para o Buscador que não oferece suporte a LEA.
Componentes
- Provedor: A2DP/HFP/LEA
- Buscador: A2DP/HFP
Comportamento esperado para o pareamento inicial / subsequente
- O provedor anuncia os dados de serviço do Pareamento rápido (0xFE2C) com o endereço de identidade (inicial) ou RPA (subsequente).
- Usar publicidade legada
- O buscador recebe o anúncio do provedor com o endereço de identidade para o pareamento inicial ou o RPA para o pareamento subsequente.
- O buscador envia uma solicitação de pareamento baseado em chave
- O bit-5 da flag da solicitação de pareamento baseado em chave está definido como 0
- O Provedor envia uma resposta de pareamento com base em chave com 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 Buscador cria um vínculo com o transporte BR/EDR
- O recurso de E/S está definido como DisplayYesNo para BR/EDR
- O buscador e o provedor realizam o procedimento de verificação da chave de acesso do Pareamento rápido.
Cenário 2: quando o buscador é compatível com LEA
Componentes
- Provedor
- Suporte a A2DP/HFP/LEA
- Componente único
- Seeker
- Suporte a A2DP/HFP/LEA
Comportamento esperado para o pareamento inicial / subsequente
- O provedor anuncia os dados de serviço do Pareamento rápido (0xFE2C) com o endereço de identidade (inicial) ou RPA (subsequente).
- Usar publicidade legada
- O buscador envia uma solicitação de pareamento baseado em chave
- O bit-5 da flag da solicitação de pareamento baseado em chave está definido como 1.
- O provedor envia uma 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
- O endereço é o endereço de identidade
- O Buscador cria um vínculo com a conexão LE
existente no transporte LE
- A direção do CTKD é de LE para BR/EDR
- O recurso de E/S está definido como DisplayYesNo para LE
- O buscador e o provedor realizam o procedimento de verificação da chave de acesso do Pareamento rápido.
Cenário 3: quando o Seeker é compatível com LEA e CSIP
Componentes
- Provedor
- Suporte a A2DP/HFP/LEA
- Vários componentes
- O componente principal é BR/EDR/LE
- O componente secundário é somente LE
- Seeker
- Suporte a A2DP/HFP/LEA
Comportamento esperado para o pareamento inicial / subsequente
- O componente principal anuncia os dados de serviço
da Pareamento rápido (0xFE2C) com o endereço de identidade (inicial) ou o RPA (subsequente).
- Usar publicidade legada
- O buscador envia uma solicitação de pareamento com base em chave para o componente principal.
- O bit-5 da flag da solicitação de pareamento baseado em chave está definido como 1.
- O componente principal envia uma 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
- O endereço é o seguinte:
- 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, que também usa esse endereço para fazer o anúncio do CSIP.
- O buscador cria um vínculo com o componente principal
na conexão LE atual
- A direção do CTKD é de LE para BR/EDR
- O recurso de E/S está definido como DisplayYesNo para LE
- O buscador cria um vínculo com o componente secundário
com o endereço da resposta estendida do pareamento baseado em chave
- A capacidade de E/S precisa ser DisplayYesNo. Caso contrário, rejeite a solicitação de pareamento.
- O buscador e o provedor realizam o procedimento de proteção contra MITM para parear o componente secundário. O provedor precisa implementar os dois cenários.
- O buscador aguarda até que o vínculo com o componente secundário seja estabelecido.
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 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 por LEA (ou seja, apenas o Pareamento Rápido por Classic). Especificamente e, por exemplo, quando o RPA do provedor não é gerado pela chave de resolução de identidade (IRK, na sigla em inglês) 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 da funcionalidade de troca de áudio (SASS), falhas generalizadas de pareamento inicial e subsequente e muito mais.
Portanto, recomendamos que os parceiros implementem a especificação Pareamento rápido-LEA para dispositivos novos e atuais em campo (com atualizações OTA) que oferecem suporte a modos duplos.