Dispositivo Bluetooth de baixa energia (BLE)
A implementação do Serviço de Pareamento rápido do Google (GFPS) para dispositivos BLE é compatíveis com a especificação Bluetooth Core v4.2 ou mais recente.
O adendo a seguir à especificação Pareamento rápido permite que o suporte somente para dispositivos de baixa energia (LE) e de áudio de baixa energia (LEA) no GPPS.
Níveis de conformidade
As palavras-chave "deve", "deve", "deve", "deve", "pode" e "pode" mencionadas na especificação são explicadas abaixo:
| Termo | Descrição |
|---|---|
| dever | is required to: usada para definir requisitos. |
| precisa | é usada 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 | é verdade que - usado apenas em declarações de fatos. |
| 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 uma declaração de maneira causal. |
Característica de pareamento com base em chaves
Mensagem do buscador para o provedor
O type 0x00 da solicitação bruta da característica de pareamento baseado em chaves usa o Bit 4.
para indicar se o candidato é compatível com a especificação do dispositivo BLE e usa o
Parte 5 para indicar se o Seeker oferece suporte a LE Audio.
| Octeto | Tipo de dado | Descrição | Valor | Obrigatório? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo de mensagem | 0x00 = solicitação de pareamento baseado em chaves |
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 usuário que fez a busca | varia | Presente apenas se as flags 1 ou 3 estiverem definidas |
| n a 15 | Valor aleatório (sal) | varia | Obrigatório |
Mensagem do provedor ao buscador
Quando o bit 4 da solicitação é definido, a nova mensagem de resposta type 0x02 para
A característica de pareamento baseado em chaves pode ser usada para fornecer mais ligações
ao Seeker.
| Octeto | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 |
Tipo de mensagem | 0x02 = resposta estendida do pareamento baseado em chaves |
| 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 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 compatível com a Especificação de dispositivo BLE deve ler os bits 4 e 5. compreender as capacidades do buscador
- Quando o bit 4 for 0, o provedor ignorará o bit 5 e responderá com o formato
type 0x01. - Quando o bit 4 é 1,
- Para um provedor somente de LE, ele responderá com
type 0x02para indicar LE. preferência de vínculo. - Para o provedor de modo dual, ele pode responder com
type 0x02para indicar Preferência de ligação BR/EDR ou LE.
- Para um provedor somente de LE, ele responderá com
- Para casos de provedores de dual modo de LE Audio (LEA), consulte Exemplo: pareamento com provedor de modo duplo de LEA para referência
Característica do Message Stream PSM (multiplexor de serviço de protocolo)
Para oferecer suporte ao stream de mensagens em dispositivos BLE, o Pareamento rápido estabelece e manter um canal BLE L2CAP para enviar e receber mensagens. Pareamento rápido O servidor L2CAP deve implementar o controle de fluxo baseado em crédito de LE.
Essa característica permite que o buscador leia o valor do PSM e estabeleça conexão L2CAP segura pelo valor 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 |
| Octeto | 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:para o TWS, há duas
componentes: primário e secundário. A função desses componentes é
intercambiáveis em certas condições. Supondo que A seja o componente principal e B seja
componente secundário, devido ao consumo da bateria no componente A , o componente B precisa
para assumir o papel do componente principal, e esse cenário é chamado de role switch.
Depois de role switch, se o provedor
não consegue processar o fluxo de mensagens de Pareamento rápido, ele vai desconectar proativamente o
conexão L2CAP atual. O usuário que busca o Pareamento rápido pode restabelecer o L2CAP
conexão de stream de mensagens com o novo componente principal.
Característica adicional da chave de acesso
Essa característica é fornecer proteção MITM na componentes de solução.
Proteção do MITM de membro falso do CSIS
O Pareamento rápido exige a proteção MITM como parte do procedimento. Como CSIS não fornece proteção MITM, o projeto atual para FP para múltiplos precisam ser estendidos para fornecer proteção contra MITM nos demais componentes de solução.
Definição da característica
| Característica do serviço de Pareamento rápido | Criptografado | Permissão | UUID |
|---|---|---|---|
| Chave de acesso adicional | 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 de Pareamento rápido.
| Octeto | Tipo de dado | Descrição | Valor |
|---|---|---|---|
| 0-15 | uint128 | Bloqueio de chave de acesso extra criptografado | varia |
Formato de dados brutos
Depois de descriptografar os dados criptografados com 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 seis dígitos | varia |
| 4-9 | uint48 | Endereço do componente de vinculação desejada | varia |
| 10 | uint8 | Código de status, usado apenas pela operação de leitura | Um de
|
| 11-15 | Valor aleatório (sal) | varia |
O primário (primeiro componente vinculado) é a ponte entre o Pareamento rápido Seeker e outros componentes de ligação. A característica deve siga as diretrizes:
- Ao receber uma solicitação de gravação do buscador de pareamento rápido, o provedor deve
- Define o endereço do componente que está sendo vinculado.
- Enviar a chave de acesso para o componente que está sendo vinculado
- Definir código de status como Pendente, 0x01
- Ao receber qualquer solicitação de leitura antes de receber a chave de acesso do componente
está vinculado, o Provedor 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 ao buscador de pareamento rápido, define o resultado
para a solicitação de leitura
- 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 por parte 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 Diagrama MITM 2 para mais detalhes.
Requisitos para dispositivos LE
Publicidade de LE
Para o modo detectável ou não detectável, o Provedor deve usar o RPA para anunciar dados do Pareamento rápido.
Capacidade de ligação
Para dispositivos compatíveis com LE, o Seeker precisa criar vínculos com o LE. Depois de passar pela verificação do Pareamento rápido baseado em chaves, o O provedor vai permitir o vínculo com RPA e definir a capacidade de pedido de inserção como DisplayYesNo para a verificação da chave de acesso de Pareamento rápido.
Requisitos para dispositivos LEA
Publicidade LEA
Para dispositivos de modo dual: Para o modo detectável, o Provedor precisa anunciar os dados do Pareamento rápido com o Identity endereço IP. Para o modo não detectável, o provedor precisa anunciar dados de Pareamento rápido com o RPA. É altamente recomendável usar publicidade legada (BT 4.2) para dar suporte a 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 dual: Para o modo detectável ou não detectável, o Provedor deve usar o publicidade on-line (BT 5.0) com RPA para anunciar dados do Pareamento rápido.
O anúncio LE conectável que contém dados de serviço de FP deve incluir UUID de CAS em conformidade com o Perfil de adaptador Bluetooth (BAP 1.0.1) e Perfil de áudio comum requisito fundamental. Para anúncios não detectáveis, se não houver espaço suficiente disponível em publicidade legada 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 ligação de LEA
O candidato precisa criar um vínculo com a conexão de LE atual. Depois de passar Verificação de pareamento baseado em chaves de Pareamento rápido, o provedor de modo duplo deve permitir vinculação com o endereço de identidade e RPA, enquanto o provedor não dual modo deve permitir vinculação com RPA e definir a capacidade de E/S como DisplayYesNo para Pareamento rápido Verificação da chave de acesso.
Canal de comunicação interno entre componentes
A conexão GATT existente é mantida para executar a proteção MITM no componentes extras. O componente vinculado principal processa a mensagem entregas entre o Fast Pair Seeker e os componentes restantes.
A comunicação interna é usada para Initial Pair e Subsequent Pair
- Quando o procedimento de pareamento baseado em chaves passa para o componente principal, o componente deverá enviar uma mensagem para alterar a capacidade de IO de seus componentes
- Quando o Pareamento rápido for concluído, o componente principal vai enviar uma mensagem para ser redefinido Capacidade de E/S dos componentes restantes
- Ao executar o procedimento "Chave de acesso adicional", o componente principal deve processar entregas de chaves de acesso entre o Fast Pair Seeker e os componentes restantes
Tempo para alterar o recurso de E/S
- Alteração do recurso 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 deve
não muda o recurso de E/S para DisplayYesNo
Retroactive Pair, com o Bit 3 da solicitação de pareamento baseado em chaves for definido como 1, consulte Mensagem do Seeker para o provedor
- Alterar o recurso de E/S para a configuração padrão
- Pareamento inicial
- Se a conexão de LE estiver desconectada, encerre a sessão de Pareamento rápido
- Após a vinculação da instância principal, se não houver outras gravações de chaves de acesso solicitação em 15 segundos, encerrar a sessão de Pareamento rápido
- Após o recebimento da solicitação de gravação da chave de acesso extra, se o componente a ligação não acontece em até 15 segundos, encerra a sessão de Pareamento rápido
- Depois que todos os componentes estiverem vinculados, se não houver uma chave de conta, grave solicitação dentro de 15 segundos, encerrar a sessão de Pareamento rápido
- Após receber a solicitação de gravação de chave da conta, defina o tempo limite de 15 segundos como encerrar a sessão de Pareamento rápido
- Pareamento subsequente
- Se a conexão de LE estiver desconectada, encerre a sessão de Pareamento rápido
- Após a vinculação da instância principal, se não houver outras gravações de chaves de acesso solicitação em até 15 segundos, encerrar a sessão de Pareamento rápido
- Após o recebimento da solicitação de gravação da chave de acesso extra, se o componente a ligação não acontece em até 15 segundos, encerra a sessão de Pareamento rápido
- Quando todos os componentes estiverem ligados, 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 o pareamento, o Provedor usará o type 0b0010
para definir a ocultação da indicação da interface de usuário para que os dados principais da conta avisem ao buscador que ele não deve ser mostrado
interface de pareamento subsequente (consulte Payload de publicidade: Pareamento rápido de dados da conta).
Requisitos de dispositivos de LE Audio
Requisitos de Bluetooth
Veja as recomendações de headsets para Android e LE Audio.
Suporte de CTKD
Para dispositivos de modo duplo, o CTKD de LE para BR/EDR é obrigatório e está alinhado com BAP.
Anúncio sobre metas
Um dispositivo periférico deve usar o Anúncio Direcionado para solicitar uma conexão de um dispositivo central pareado. Anúncios segmentados são definidos em BAP e CAP para gerenciamento de conexões de acordo com CAP 1.0 Tabela 8.4 (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 estiver conectado. Para o dispositivo compatível com CSIP, esse valor vai aumentar a performance da conexão com o perfil e logo iniciar a vinculação do CSIP para os outros parceiros.
Armazenamento em cache robusto do GATT (altamente recomendado)
Se o provedor não é um único dispositivo, mas um conjunto coordenado com a implementação do CSIP, para reduzir o número de vezes fazendo descoberta de serviços e acelerar a conexão, o provedor deve implementar o cache GATT definido no Bluetooth 5.1.
Requisitos do Pareamento rápido
Publicidade de LE
Para o modo detectável ou não detectável, se o dispositivo tiver vários componentes, os dados de Pareamento rápido serão divulgados 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. ver 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. Áudio de baixa energia (0x184E) deve ser incluído no banco de dados GATT da conexão de Pareamento rápido.
Exemplo: pareamento com provedor de modo duplo de LEA
Cenário 1: quando o usuário que busca a experiência não oferece suporte a LEA
O Provedor deve ter compatibilidade com versões anteriores do Seeker que não oferecer suporte à LEA.
Componentes
- Provedor: A2DP/HFP/LEA
- Buscador: A2DP/HFP
Comportamento esperado para o par inicial e para o segundo
- O provedor anuncia o serviço de Pareamento rápido
dados (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar publicidade legada
- O Buscador recebe o anúncio com endereço de identidade para inicial ou RPA para pareamento subsequente
- 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 0.
- O provedor envia uma resposta de pareamento baseado em chaves com o endereço público em um dos
o seguinte:
- Se o tipo de mensagem 0x01 for usado, o endereço deverá ser público
- Se o tipo de mensagem 0x02 for usado
- O bit-0 será 0
- O bit-1 será 0
- O endereço deve ser público
- The Seeker cria um vínculo com o transporte BR/EDR
- A capacidade de E/S está definida como DisplayYesNo para BR/EDR
- O buscador e o provedor fazem o procedimento de verificação da chave de acesso com Pareamento rápido
Cenário 2: quando o usuário que busca ajuda com LEA
Componentes
- Prestador de serviço
- Suporte a A2DP/HFP/LEA
- Componente único
- Pessoas que procuram
- SupportA2DP/HFP/LEA
Comportamento esperado para o par inicial e para o segundo
- O provedor anuncia o serviço de Pareamento rápido
dados (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 baseado em chaves com o tipo de mensagem 0x02
- O bit-0 será 0
- O bit-1 será 1
- O endereço é um endereço de identidade
- O Seeker cria um vínculo com o
Conexão LE 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 fazem o procedimento de verificação de chave de acesso de Pareamento rápido
Cenário 3: quando o buscador apoia LEA e CSIP envolvidos
Componentes
- Prestador de serviço
- Suporte a A2DP/HFP/LEA
- Vários componentes
- O componente principal é BR/EDR/LE
- O componente secundário é somente LE
- Pessoas que procuram
- Suporte a A2DP/HFP/LEA
Comportamento esperado para o par inicial e para o segundo
- O componente principal anuncia o Pareamento rápido
dados de serviço (0xFE2C) com endereço de identidade (inicial) ou RPA (subsequente).
- Usar publicidade legada
- O Seeker envia uma solicitação de pareamento baseado em chaves para o componente principal
- O bit-5 da flag da solicitação de pareamento baseado em chaves está definido como 1.
- O componente principal envia a resposta de pareamento baseado em chaves com o tipo de mensagem 0x02
- O bit-0 será 0
- O bit-1 será 1
- Os endereços são os seguintes :
- 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 usa esse endereço para fazer a divulgação CSIP.
- O candidato cria um vínculo com o
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 Seeker cria um vínculo com
componente com endereço que é da resposta estendida de pareamento baseado em chaves
- O recurso de E/S deve ser DisplayYesNo. Caso contrário, rejeitar a solicitação de pareamento
- O Seeker e o Provedor realizam o procedimento de proteção MITM para parear o componente secundário, o provedor implementará os dois cenários
- O buscador aguarda a ligação com o componente secundário
Diagrama sequencial para o MITM
Esta sessão descreve a sequência do procedimento de proteção 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 pela leitura
Problema conhecido
O FP para LEA foi otimizado para funcionar com o Android V.
Por outro lado, encontramos vários problemas com fones de ouvido compatíveis com LEA. mas não têm o Pareamento rápido correto sobre a implementação de LEA (ou seja, apenas Pareamento rápido por excesso de Clássico). Especificamente, 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 poderá ser resolvido. Embora não tenha sido possível testar uma lista abrangente de headsets do aplicativo, nossos testes limitados revelaram vários problemas, incluindo falhas para mostrar as notificações de bateria dos fones de ouvido, falta de seleção de áudio (SASS) falhas de pareamento iniciais e subsequentes, entre outras.
Portanto, recomendamos que os parceiros implementem o Pareamento rápido e LEA. especificações para dispositivos novos e existentes no campo (via atualizações OTA) compatíveis com modos duplos.