v1.3
A especificação de acessório da rede Encontre Meu Dispositivo (FMDN, na sigla em inglês) define uma abordagem criptografada de ponta a ponta para rastrear dispositivos Bluetooth de baixa energia (BLE, na sigla em inglês) com beacons. Esta página descreve a FMDN como uma extensão da especificação do Par rápido. Os provedores precisam ativar essa extensão se tiverem dispositivos compatíveis com a FMDN e quiserem ativar o rastreamento de localização para esses dispositivos.
Especificação GATT
Uma característica de atributos genéricos (GATT) precisa ser adicionada ao serviço de pareamento rápido com a seguinte semântica:
| Característica do serviço de Pareamento rápido | Criptografado | Permissões | UUID |
|---|---|---|---|
| Ações de beacon | Não | Ler, gravar e notificar | FE2C1238-8366-4814-8EB0-01DE32100BEA |
Tabela 1:características do serviço de pareamento rápido para FMDN.
Autenticação
As operações necessárias para essa extensão são realizadas como uma operação de gravação, protegida por um mecanismo de desafio-resposta. Antes de realizar qualquer operação, o Seeker precisa realizar uma operação de leitura da característica na tabela 1, o que resulta em um buffer no seguinte formato:
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Número da versão principal do protocolo | 0x01 |
| 1 - 8 | matriz de bytes | Valor de uso único aleatório | varia |
Cada operação de leitura precisa resultar em um valor de uso único diferente, e um único valor de uso precisa ser válido apenas para uma única operação. O valor de uso único precisa ser invalidado mesmo se a operação falhar.
O Seeker calcula uma chave de autenticação única para ser usada em uma solicitação de gravação subsequente. A chave de autenticação é calculada conforme descrito nas tabelas 2 a 5. Dependendo da operação solicitada, o solicitante prova o conhecimento de uma ou mais das seguintes chaves:
Chave da conta: a chave de conta de 16 bytes do Pareamento rápido, conforme definido na especificação do Pareamento rápido.
Chave da conta de proprietário: o provedor escolhe uma das chaves de conta atuais como a chave da conta de proprietário na primeira vez que um solicitante acessa a característica Ações do beacon. A chave da conta de proprietário escolhida não pode ser alterada até que o provedor seja redefinido para a configuração de fábrica. O provedor não pode remover a chave da conta do proprietário quando ele ficar sem slots de chaves de conta disponíveis.
Os provedores que já oferecem suporte à FMDN quando pareados pela primeira vez (ou quando pareados após a redefinição de fábrica) escolhem a primeira chave de conta, porque essa é a única chave de conta existente quando o Seeker lê o estado de provisionamento durante o pareamento.
Os provedores que ganham suporte a FMDN depois de já terem sido pareados (por exemplo, por uma atualização de firmware) podem escolher qualquer chave de conta existente. É razoável escolher a primeira chave de conta usada para ler o estado de provisionamento da característica de ações do beacon após a atualização do firmware, supondo que o usuário que realizou a atualização seja o proprietário atual do provedor.
Chave de identidade temporária (EIK, na sigla em inglês): uma chave de 32 bytes escolhida aleatoriamente pelo Buscador ao realizar o processo de provisionamento do FMDN. Essa chave é usada para derivar chaves criptográficas que são usadas para relatórios de localização com criptografia de ponta a ponta. O Seeker nunca revela isso ao back-end.
Chave de recuperação: definida como
SHA256(ephemeral identity key || 0x01), truncada para os primeiros 8 bytes. A chave é armazenada no back-end, e o Seeker pode usá-la para recuperar a EIK, desde que o usuário expresse consentimento pressionando um botão no dispositivo.Chave de anel: definida como
SHA256(ephemeral identity key || 0x02), truncada para os primeiros 8 bytes. A chave é armazenada no back-end, e o Seeker só pode usá-la para tocar o dispositivo.Chave de proteção contra rastreamento indesejado: definida como
SHA256(ephemeral identity key || 0x03), truncada para os primeiros 8 bytes. A chave é armazenada no back-end, e o Seeker só pode usá-la para ativar o modo de proteção contra rastreamento indesejado.
Operações
O formato dos dados gravados na característica é fornecido nas tabelas 2 a 5. Cada uma das operações é discutida em mais detalhes mais adiante nesta seção.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | ID de dados |
|
| 1 | uint8 | Comprimento dos dados | varia |
| 2 a 9 | matriz de bytes | Chave de autenticação única | Os primeiros 8 bytes de
HMAC-SHA256(account key, protocol major version number || the last nonce
read from the characteristic || data ID || data length || additional data) |
| 10 - var | matriz de bytes | Outros dados |
|
Tabela 2:solicitação de provisionamento de beacons.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | ID de dados | 0x04: Ler chave de identidade temporária com consentimento do usuário |
| 1 | uint8 | Comprimento dos dados | 0x08 |
| 2 a 9 | matriz de bytes | Chave de autenticação única | Os primeiros 8 bytes de
HMAC-SHA256(recovery key, protocol major version number || the last nonce
read from the characteristic || data ID || data length) |
Tabela 3:solicitação de recuperação da chave de provisionamento do beacon.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | ID de dados |
|
| 1 | uint8 | Comprimento dos dados | varia |
| 2 a 9 | matriz de bytes | Chave de autenticação única | Os primeiros 8 bytes de
HMAC-SHA256(ring key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data) |
| 10 - var | matriz de bytes | Outros dados |
|
Tabela 4:solicitação de toque.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | ID de dados |
|
| 1 | uint8 | Comprimento dos dados | varia |
| 2 a 9 | matriz de bytes | Chave de autenticação única | Os primeiros 8 bytes de
HMAC-SHA256(unwanted tracking protection key, protocol major version number
|| the last nonce read from the characteristic || data ID || data length ||
additional data) |
| 10 - var | matriz de bytes | Outros dados |
|
Tabela 5:solicitação de proteção antirrastreamento indesejada.
As gravações bem-sucedidas acionam notificações, conforme listado na tabela 6.
As notificações com o ID de dados diferente de 0x05: mudança de estado do toque precisam ser enviadas antes que a transação de gravação que aciona a notificação seja concluída, ou seja, antes que uma PDU de resposta para a solicitação de gravação seja enviada.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | ID de dados |
|
| 1 | uint8 | Comprimento dos dados | varia |
| 2 a 9 | matriz de bytes | Autenticação | Detalhes por operação |
| 10 - var | matriz de bytes | Outros dados |
|
Tabela 6:resposta do serviço de beacon.
A Tabela 7 lista os possíveis códigos de erro do GATT retornados pelas operações.
| Código | Descrição | Observações |
|---|---|---|
| 0x80 | Não autenticadas | Retornado em resposta a uma solicitação de gravação quando a autenticação falha (incluindo o caso em que um valor de uso único antigo foi usado). |
| 0x81 | Valor inválido | Retorna quando um valor inválido é fornecido ou quando os dados recebidos têm um número inesperado de bytes. |
| 0x82 | Sem consentimento do usuário | Retornado em resposta a uma solicitação de gravação com o ID de dados 0x04: ler chave de identidade temporária com consentimento do usuário quando o dispositivo não está no modo de pareamento. |
Tabela 7:códigos de erro do GATT.
Ler o parâmetro do farol
O Seeker pode consultar o provedor para os parâmetros do beacon executando uma operação de gravação na característica que consiste em uma solicitação da tabela 2 com ID de dados 0x00. O provedor verifica se a chave de autenticação única fornecida corresponde a qualquer uma das chaves da conta armazenadas no dispositivo.
Se a verificação falhar, o provedor vai retornar um erro não autenticado.
Em caso de sucesso, o provedor notifica com uma resposta da tabela 6 com o ID de dados 0x00. O provedor constrói o segmento de dados da seguinte maneira:
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Potência calibrada | A potência calibrada recebida a 0 m (um valor no intervalo [-100, 20]). Representado como um número inteiro assinado, com resolução de 1 dBm. |
| 1 a 4 | uint32 | Valor do relógio | O valor atual do relógio em segundos (big endian). |
| 5 | uint8 | Seleção de curva | A curva elíptica usada para criptografia:
|
| 6 | uint8 | Componentes | O número de componentes capazes de tocar:
|
| 7 | uint8 | Recursos de toque | As opções compatíveis são:
|
| 8-15 | matriz de bytes | Padding | Zero padding para criptografia AES. |
Os dados precisam ser criptografados com AES-ECB-128 com a chave da conta usada para autenticar a solicitação.
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data after
encryption || 0x01).
Ler o estado de provisionamento do beacon
O Seeker pode consultar o estado de provisionamento do beacon ao provedor realizando uma operação de gravação na característica que consiste em uma solicitação da tabela 2 com o ID de dados 0x01. O provedor verifica se a chave de autenticação única fornecida corresponde a qualquer das chaves da conta armazenadas no dispositivo.
Se a verificação falhar, o provedor vai retornar um erro não autenticado.
Em caso de sucesso, o provedor notifica com uma resposta da tabela 6 com o ID de dados 0x01. O provedor constrói o segmento de dados da seguinte maneira:
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Estado de provisionamento | Uma máscara de bits com os seguintes valores:
|
| 1 a 20 ou 32 | matriz de bytes | Identificador temporário atual | 20 ou 32 bytes (dependendo do método de criptografia usado) indicando o ID temporário atual anunciado pelo beacon, se um tiver sido definido para o dispositivo. |
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01).
Definir uma chave de identidade temporária
Para provisionar um provedor não provisionado como um beacon de FMDN ou mudar a chave de identidade temporária de um provedor já provisionado, o Buscador executa uma operação de gravação na característica que consiste em uma solicitação da tabela 2 com o ID de dados 0x02. O provedor verifica se:
- A chave de autenticação única fornecida corresponde à chave da conta do proprietário.
- Se um hash de uma chave de identidade temporária foi fornecido, a chave de identidade temporária hashada corresponde à chave de identidade temporária atual.
- Se um hash de uma chave de identidade temporária não foi fornecido, verifique se o provedor não foi provisionado como um beacon FMDN.
Se a verificação falhar, o provedor vai retornar um erro não autenticado.
Se for bem-sucedido, a chave de identidade temporária será recuperada pelo AES-ECB-128, descriptografando-a usando a chave de conta correspondente. A chave precisa ser mantida no dispositivo e, a partir desse ponto, o provedor precisa começar a anunciar frames FMDN. A nova chave de identidade temporária entra em vigor imediatamente após o encerramento da conexão BLE. O provedor notifica com uma resposta da tabela 6 com o ID de dados 0x02.
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01).
Limpar a chave de identidade temporária
Para remover a parte do farol do provedor, o buscador executa uma operação de gravação na característica, que consiste em uma solicitação da tabela 2 com o ID de dados 0x03. O provedor verifica se:
- A chave de autenticação única fornecida corresponde à chave da conta do proprietário.
- A chave de identidade temporária com hash corresponde à chave de identidade temporária atual.
Se o provedor não for provisionado como um farol FMDN ou a verificação falhar, um erro não autenticado será retornado.
Em caso de sucesso, o provedor esquece a chave e para de anunciar frames FMDN.
O provedor notifica com uma resposta da tabela 6 com o ID de dados 0x03.
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01).
Ler a chave de identidade temporária com o consentimento do usuário
Essa opção só está disponível para recuperar uma chave perdida, já que ela é armazenada localmente pelo Buscador. Portanto, esse recurso só está disponível quando o dispositivo está no modo de pareamento ou por um tempo limitado depois que um botão físico foi pressionado no dispositivo (o que constitui o consentimento do usuário).
O Seeker precisa armazenar a chave de recuperação no back-end para poder recuperar a chave de texto simples, mas não armazena a EIK.
Para ler o EIK, o Seeker executa uma operação de gravação na característica, que consiste em uma solicitação da tabela 3 com o ID de dados 0x04. O provedor verifica que:
- A chave de recuperação com hash corresponde à chave de recuperação esperada.
- O dispositivo está no modo de recuperação de EIK.
Se a verificação falhar, o provedor vai retornar um erro não autenticado.
Se o dispositivo não estiver no modo de pareamento, o provedor vai retornar um erro de consentimento do usuário.
Em caso de sucesso, o provedor notifica com uma resposta da tabela 6 com o ID de dados 0x04.
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256(recovery key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01).
Operação de toque
O solicitante pode pedir ao provedor para tocar um som realizando uma operação de gravação na característica, que consiste em uma solicitação da tabela 4 com o ID de dados 0x05. O provedor constrói o segmento de dados da seguinte maneira:
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Operação de toque | Uma máscara de bits com os seguintes valores:
|
| 1 - 2 | uint16 | Tempo limite | O tempo limite em decímetros. Não pode ser zero nem
maior que o equivalente a 10 minutos. O provedor usa esse valor para determinar por quanto tempo o toque deve durar antes de ser silenciado. O tempo limite substitui o que já está em vigor se algum componente do dispositivo já estiver tocando. Se a operação de toque estiver definida como 0x00, o tempo limite será ignorado. |
| 3 | uint8 | Volume |
|
Ao receber a solicitação, o provedor verifica se:
- A chave de autenticação única fornecida corresponde à chave de anel.
- O estado solicitado corresponde aos componentes que podem tocar.
Se o provedor não for provisionado como um farol FMDN ou a verificação falhar, um erro não autenticado será retornado. No entanto, se o provedor tiver a proteção contra rastreamento indesejado ativada e a solicitação de proteção contra rastreamento indesejado acionada tiver a flag de autenticação de desativação de toque ativada, o provedor vai pular essa verificação. Os dados de autenticação ainda precisam ser fornecidos pelo solicitante, mas podem ser definidos como um valor arbitrário.
Quando o toque começa ou termina, uma notificação é enviada, conforme indicado na tabela 6 com o ID de dados 0x05. O conteúdo da notificação é definido da seguinte maneira:
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Estado de chamada |
|
| 1 | uint8 | Componentes de toque | Uma máscara de bits dos componentes que estão tocando ativamente, conforme definido na solicitação. |
| 2 a 3 | uint16 | Tempo limite | O tempo restante para o toque em decêmetros. Se o dispositivo parar de tocar, o valor 0x0000 será retornado. |
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256(ring key, protocol major version number || the nonce used to
initiate the ringing command || data ID || data length || additional data ||
0x01).
Se o dispositivo já estiver no estado de toque solicitado quando uma solicitação de toque ou de desativação for recebida, o provedor precisará enviar uma notificação com um estado de toque ou 0x00: iniciado ou 0x04: interrompido (solicitações GATT), respectivamente. Essa solicitação substitui os parâmetros do estado atual para que a duração do toque possa ser estendida.
Se o provedor tiver um botão físico (ou se o recurso Touch Sense estiver ativado), esse botão vai interromper a função de toque se for pressionado enquanto o toque estiver ativo.
Receber o estado de toque do beacon
Para receber o estado de toque do beacon, o Seeker executa uma operação de gravação na característica, que consiste em uma solicitação da tabela 4 com o ID de dados 0x06. O provedor verifica se a chave de autenticação única fornecida corresponde à chave de anel.
Se o provedor não for provisionado como um beacon FMDN ou se a verificação falhar, o provedor vai retornar um erro não autenticado.
Em caso de sucesso, o provedor notifica com uma resposta da tabela 6 com o ID de dados 0x06. O provedor constrói o segmento de dados da seguinte maneira:
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Componentes de toque | Os componentes que estão tocando ativamente, conforme definido na solicitação de toque. |
| 1 - 2 | uint16 | Tempo limite | O tempo restante para o toque em decêmetros. Se o dispositivo não estiver tocando, o valor 0x0000 será retornado. |
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256 (ring key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01).
Modo de proteção contra rastreamento indesejado
O modo de proteção contra rastreamento indesejado permite que qualquer cliente identifique dispositivos abusivos sem comunicação com o servidor. Por padrão, o provedor precisa alternar todos os identificadores, conforme descrito em Rotação de ID. O serviço Encontre Meu Dispositivo pode transmitir uma solicitação de ativação do modo de proteção contra rastreamento indesejada pela rede Encontre Meu Dispositivo. Ao fazer isso, o serviço faz com que o provedor use temporariamente um endereço MAC fixo, permitindo que os clientes detectem o dispositivo e avisem o usuário sobre um possível rastreamento indesejado.
Para ativar ou desativar o modo de proteção contra rastreamento indesejado do beacon, o Seeker executa uma operação de gravação na característica, que consiste em uma solicitação da tabela 5 com o ID de dados 0x07 ou 0x08, respectivamente.
Ao ativar o modo de proteção contra rastreamento indesejado
O provedor constrói o segmento de dados da seguinte maneira:
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Flags de controle |
As flags só têm efeito até que o modo de proteção contra rastreamento indesejado seja desativado. |
O provedor verifica se a chave de autenticação única fornecida corresponde à chave de proteção contra rastreamento indesejado. Se o provedor não for provisionado como um beacon FMDN ou a verificação falhar, ele retornará um erro não autenticado.
Quando o modo de proteção contra rastreamento indesejado é ativado, o beacon precisa reduzir a frequência de rotação do endereço privado MAC para uma vez a cada 24 horas. O identificador efetivo anunciado precisa continuar sendo alternado normalmente. O tipo de frame precisa ser definido como 0x41. O estado também é refletido na seção flags com hash.
Como desativar o modo de proteção contra rastreamento indesejado
O provedor verifica se:
- A chave de autenticação única fornecida corresponde à chave de proteção contra rastreamento indesejado.
- A chave de identidade temporária com hash corresponde à chave de identidade temporária atual.
Se o provedor não for provisionado como um beacon FMDN ou a verificação falhar, o provedor vai retornar um erro não autenticado.
Quando o modo de proteção contra rastreamento indesejado é desativado, o beacon começa a girar o endereço MAC a uma taxa normal novamente, sincronizado com a rotação de identificador temporária. O tipo de frame precisa ser definido novamente como 0x40. O estado também é refletido na seção flags com hash.
Em caso de sucesso, o provedor notifica com uma resposta da tabela 6 com o ID de dados 0x07 ou 0x08.
O segmento de autenticação é definido como os primeiros 8 bytes de
HMAC-SHA256(unwanted tracking protection key, protocol major version number ||
the last nonce read from the characteristic || data ID || data length ||
0x01).
Frames anunciados
Após a provisionamento, o provedor deve anunciar frames FMDN pelo menos uma vez a cada dois segundos. Se os frames do Pareamento rápido forem anunciados, o provedor vai intercalar os frames do FMDN nos anúncios normais do Pareamento rápido. Por exemplo, a cada dois segundos, o provedor precisa anunciar sete anúncios do Fast Pair e um anúncio da FMDN.
A potência de transmissão Bluetooth conduzida para anúncios de FMDN precisa ser definida como pelo menos 0 dBm.
O frame FMDN tem uma chave pública usada para criptografar relatórios de localização por qualquer cliente de suporte que contribua para a rede de crowdsourcing. Dois tipos de chaves de curva elíptica estão disponíveis: uma chave de 160 bits que se encaixa em frames BLE 4 legados ou uma chave de 256 bits que exige BLE 5 com recursos de publicidade estendidos. A implementação do provedor determina qual curva é usada.
Um frame FMDN é estruturado da seguinte maneira.
| Octeto | Valor | Descrição |
|---|---|---|
| 0 | 0x02 | Comprimento |
| 1 | 0x01 | Sinaliza o valor do tipo de dados |
| 2 | 0x06 | Flags de dados |
| 3 | 0x18 ou 0x19 | Comprimento |
| 4 | 0x16 | Valor do tipo de dados de dados do serviço |
| 5 | 0xAA | UUID de serviço de 16 bits |
| 6 | 0xFE | … |
| 7 | 0x40 ou 0x41 | Tipo de frame FMDN com indicação do modo de proteção contra rastreamento indesejado |
| 8..27 | Identificador temporário de 20 bytes | |
| 28 | Flags com hash |
Tabela 8:frame FMDN com suporte para uma curva de 160 bits.
A tabela 9 mostra os deslocamentos e valores de byte para uma curva de 256 bits.
| Octeto | Valor | Descrição |
|---|---|---|
| 0 | 0x02 | Comprimento |
| 1 | 0x01 | Sinaliza o valor do tipo de dados |
| 2 | 0x06 | Flags de dados |
| 3 | 0x24 ou 0x25 | Comprimento |
| 4 | 0x16 | Valor do tipo de dados de dados do serviço |
| 5 | 0xAA | UUID de serviço de 16 bits |
| 6 | 0xFE | … |
| 7 | 0x40 ou 0x41 | Tipo de frame FMDN com indicação do modo de proteção contra rastreamento indesejado |
| 8,39 | Identificador temporário de 32 bytes | |
| 40 | Flags com hash |
Tabela 9:frame FMDN com suporte para uma curva de 256 bits.
Cálculo do identificador temporário (EID)
Um valor aleatório é gerado pelo AES-ECB-256, criptografando a seguinte estrutura de dados com a chave de identidade temporária:
| Octeto | Campo | Descrição |
|---|---|---|
| 0 a 10 | Padding | Valor = 0xFF |
| 11 | K | Expoente do período de rotação |
| 12 a 15 | TS[0]...TS[3] | Contador de tempo do farol, no formato big-endian de 32 bits. Os bits mais baixos de K são limpos. |
| 16 a 26 | Padding | Valor = 0x00 |
| 27 | K | Expoente do período de rotação |
| 28 - 31 | TS[0]...TS[3] | Contador de tempo do farol, no formato big-endian de 32 bits. Os bits mais baixos de K são limpos. |
Tabela 10:construção de um número pseudoaleatório.
O resultado dessa computação é um número de 256 bits, indicado por r'.
Para o restante do cálculo, SECP160R1 ou SECP256R1 são usados para
operações criptográficas de curva elíptica. Consulte as definições de curva em
SEC 2: Parâmetros de domínio de curva elíptica recomendados, que define Fp, n e G
referenciados a seguir.
r' agora é projetado para o campo finito Fp calculando r = r' mod n.
Por fim, calcule R = r * G, que é um ponto na curva que representa a chave pública usada. O beacon anuncia Rx, que é a coordenada x
de R, como o identificador temporário.
Flags em hash
O campo de flags com hash é calculado da seguinte maneira (os bits são referenciados do mais significativo para o menos significativo):
- Bits 0 a 4: reservados (definidos como zeros).
- Os bits 5 a 6 indicam o nível de bateria do dispositivo da seguinte maneira:
- 00: Não há suporte para a indicação do nível da bateria
- 01: Nível de bateria normal
- 10: Nível de bateria baixo
- 11: Nível de bateria muito baixo (troca de bateria necessária em breve)
- O bit 7 é definido como 1 se o beacon estiver no modo de proteção contra rastreamento indesejado e como 0, caso contrário.
Para produzir o valor final desse byte, ele é XOR com o byte menos significativo
de SHA256(r).
Observe que r precisa estar alinhado ao tamanho da curva. Adicione zeros como os bits mais significativos se a representação for menor que 160 ou 256 bits. Caso contrário, os bits mais significativos precisarão ser truncados se a representação for maior que 160 ou 256 bits.
Se o beacon não oferecer suporte à indicação do nível da bateria e não estiver no modo de proteção contra rastreamento indesejado, ele poderá omitir esse byte totalmente do anúncio.
Criptografia com EID
Para criptografar uma mensagem m, um observador (que leu Rx do farol) faria
o seguinte:
- Escolha um número aleatório
semFp, conforme definido na seção Cálculo do ID do evento. - Calcule
S = s * G. - Calcule
R = (Rx, Ry)pela substituição na equação da curva e escolha um valorRyarbitrário entre os resultados possíveis. - Calcule a chave AES de 256 bits
k = HKDF-SHA256((s * R)x), em que(s * R)xé a coordenadaxdo resultado da multiplicação da curva. O sal não foi especificado. - Vamos supor que
URxeLRxsejam os 80 bits superiores e inferiores deRx, respectivamente, no formato big-endian. De forma semelhante, definaUSxeLSxparaS. - Calcule
nonce = LRx || LSx. - Calcule
(m’, tag) = AES-EAX-256-ENC(k, nonce, m). - Enviar
(URx, Sx, m’, tag)para o proprietário, possivelmente por um serviço remoto não confiável.
Descriptografia de valores criptografados com EID
O cliente do proprietário, que está de posse do EIK e do expoente do período de rotação, descriptografa a mensagem da seguinte maneira:
- Dado
URx, obtenha o valor do contador de tempo do beacon em queURxé baseado. Isso pode ser feito pelo cliente do proprietário computando valoresRxpara valores de contagem de tempo do beacon para o passado recente e o futuro próximo. - Considerando o valor do contador de tempo do beacon em que
URxé baseado, calcule o valor esperado der, conforme definido na seção Cálculo do EID. - Calcule
R = r * Ge verifique uma correspondência com o valor deURxfornecido pelo observador. - Calcule
S = (Sx, Sy)pela substituição na equação da curva e escolha um valorSyarbitrário entre os resultados possíveis. - Calcule
k = HKDF-SHA256((r * S)x), em que(r * S)xé a coordenadaxdo resultado da multiplicação da curva. - Calcule
nonce = LRx || LSx. - Calcule
m = AES-EAX-256-DEC(k, nonce, m’, tag).
Rotação de ID
Um endereço BLE solucionável (RPA) ou não solucionável (NRPA) precisa ser usado para frames de FMDN de publicidade. A RPA é obrigatória para dispositivos LE Audio (LEA) e é recomendada para outros dispositivos, com exceção das tags de localizador que não usam pareamento.
O anúncio do Pareamento rápido, o anúncio do FMDN e os endereços BLE correspondentes precisam ser alternados ao mesmo tempo. A rotação precisa acontecer a cada 1.024 segundos, em média. O ponto exato em que o beacon começa a anunciar o novo identificador precisa ser aleatório dentro da janela.
A abordagem recomendada para randomizar o tempo de rotação é defini-lo como o próximo tempo de rotação previsto (se nenhuma randomização tiver sido aplicada) mais um fator de tempo randomizado positivo na faixa de 1 a 204 segundos.
Quando o dispositivo está no modo de proteção contra rastreamento indesejado, o endereço BLE do anúncio FMDN precisa ser fixo, mas o RPA para o anúncio não detectável de FP (como o Fast Pair) precisa continuar girando. É aceitável usar endereços diferentes para os protocolos diferentes.
Recuperação de perda de energia
A resolução do identificador temporário está fortemente vinculada ao valor do relógio no momento do anúncio. Portanto, é importante que o provedor possa recuperar o valor do relógio em caso de perda de energia. É recomendável que o provedor grave o valor atual do relógio na memória não volátil pelo menos uma vez por dia e que, na inicialização, o provedor verifique a NVM para saber se há um valor para inicializar. Os solucionadores do identificador temporário implementariam a resolução em uma janela de tempo suficiente para permitir uma deriva de relógio razoável e esse tipo de recuperação de perda de energia.
Os provedores ainda precisam fazer todos os esforços para minimizar a deriva do relógio, já que a janela de tempo de resolução é limitada. Pelo menos um método de sincronização de relógio adicional precisa ser implementado (anunciar frames não detectáveis do Fast Pair ou implementar o fluxo de mensagens).
Diretrizes de implementação do Fast Pair
Esta seção descreve aspectos especiais da implementação do Par rápido em provedores compatíveis com a FMDN.
Diretrizes específicas da tag de localização
- Se o provedor foi pareado, mas o FMDN não foi provisionado em cinco minutos (ou se uma atualização OTA foi aplicada enquanto o dispositivo estava pareado, mas não provisionado pelo FMDN), o provedor vai reverter para a configuração original e limpar as chaves de conta armazenadas.
- Depois que o provedor for pareado, ele não vai mudar o endereço MAC até que a FMDN seja provisionada ou até que 5 minutos se passem.
- Se a chave de identidade temporária for apagada do dispositivo, ele vai fazer uma redefinição de fábrica e limpar as chaves de conta armazenadas.
- O provedor precisa rejeitar as tentativas normais de pareamento Bluetooth e aceitar apenas o pareamento Fast Pair.
- O provedor precisa incluir um mecanismo que permita que os usuários parem temporariamente a veiculação de anúncios sem redefinir o dispositivo para a configuração original (por exemplo, pressionando uma combinação de botões).
- Após uma perda de energia, o dispositivo precisa anunciar frames do Pareamento rápido não detectáveis até a próxima invocação de leitura de parâmetros de beacon. Isso permite que o Seeker detecte o dispositivo e sincronize o relógio, mesmo que ocorra uma variação significativa.
- Ao anunciar frames não detectáveis do Pareamento rápido, as indicações da interface não devem ser ativadas.
- Os frames detectáveis do Par rápido não podem ser anunciados enquanto o provedor está provisionado para FMDN.
- O provedor não pode expor informações de identificação de forma não autenticada (por exemplo, nomes ou identificadores).
Diretrizes específicas a dispositivos Bluetooth clássico
Esta seção descreve aspectos especiais de dispositivos Bluetooth clássicos com suporte a FMDN.
Provisionamento de FMDN de dispositivos já pareados
O provedor nem sempre é provisionado para FMDN ao parear com o Seeker, mas um pouco depois. Nesse caso, o provedor pode não ter um endereço MAC BLE atualizado, que é necessário para estabelecer uma conexão GATT. O provedor precisa oferecer suporte a pelo menos uma das seguintes maneiras para que o dispositivo de busca consiga o endereço BLE enquanto já está pareado:
- O provedor pode anunciar periodicamente os dados da conta do Par rápido
que permitem que o dispositivo de busca encontre o endereço BLE por meio de uma verificação BLE.
Essa abordagem é adequada para provedores que não implementam o fluxo de mensagens. - O provedor pode fornecer esses dados pelo fluxo de mensagens do Pareamento rápido pelo
Bluetooth clássico.
Essa abordagem é adequada para provedores que não anunciam frames do Pareamento rápido enquanto estão conectados ao Seeker por Bluetooth.
O suporte a ambas as abordagens aumenta as chances de o usuário provisionar o dispositivo para a FMDN.
Fluxo de mensagens do Pareamento rápido
O provedor pode implementar o fluxo de mensagens do Pareamento rápido e usá-lo para notificar o buscador sobre as informações do dispositivo. A implementação do fluxo de mensagens ativa alguns recursos, conforme descrito nesta seção.
O provedor precisa enviar mensagens de informações do dispositivo sempre que o canal de streaming de mensagens RFCOMM for estabelecido.
Versão do firmware (código de informações do dispositivo 0x09) e a capacidade de rastreamento
Quando uma atualização de firmware adiciona suporte a FMDN ao provedor, um buscador conectado pode notificar o usuário sobre isso e oferecer o provisionamento. Caso contrário, o usuário precisa navegar até a lista de dispositivos Bluetooth manualmente para iniciar o provisionamento de FMDN.
Para permitir isso, o provedor precisa usar a propriedade "Versão do firmware" (código 0x09) para informar um valor de string que represente a versão do firmware. Além disso, o provedor precisa oferecer suporte ao protocolo que informa ao solicitante sobre mudanças de recursos devido a atualizações de firmware.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Evento de informações do dispositivo | 0x03 |
| 1 | uint8 | Versão do firmware | 0x09 |
| 2 a 3 | uint16 | Duração dos dados adicionais | varia |
| var | matriz de bytes | String de versão | varia |
Tabela 11:evento de informações do dispositivo: versão do firmware atualizada.
Ao receber uma solicitação de atualização de capability (0x0601), se o provedor tiver ativado o suporte ao rastreamento de FMDN, ele vai responder conforme mostrado na tabela 12.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Evento de sincronização de recursos do dispositivo | 0x06 |
| 1 | uint8 | Rastreamento de FMDN | 0x03 |
| 2 a 3 | uint16 | Duração dos dados adicionais | 0x0007 |
| 4 | uint8 | Estado de provisionamento da FMDN | 0x00 se não provisionado; 0x01 se provisionado por qualquer conta |
| 5 - 10 | matriz de bytes | O endereço MAC BLE atual do dispositivo | varia |
Tabela 12:evento de sincronização de recursos do dispositivo: capacidade de rastreamento adicionada.
Identificador temporário atual (código de informações do dispositivo 0x0B)
O provedor pode usar o identificador temporário atual (código 0x0B) para informar o EID e o valor do relógio atuais quando o provedor é provisionado para FMDN, para sincronizar o Buscador em caso de deriva do relógio (por exemplo, devido à bateria descarregada). Caso contrário, o Seeker inicia uma conexão mais cara e menos confiável para essa finalidade.
| Octeto | Tipo de dados | Descrição | Valor |
|---|---|---|---|
| 0 | uint8 | Evento de informações do dispositivo | 0x03 |
| 1 | uint8 | Identificador temporário atual | 0x0B |
| 2 a 3 | uint16 | Duração dos dados adicionais | 0x0018 ou 0x0024 |
| 4 a 7 | matriz de bytes | Valor do relógio | Exemplo: 0x13F9EA80 |
| 8 a 19 ou 31 | matriz de bytes | EID atual | Exemplo: 0x1122334455667788990011223344556677889900 |
Tabela 13:evento de informações do dispositivo: sincronização do relógio.
Redefinir para a configuração original
Para dispositivos com suporte à redefinição para a configuração original: se uma redefinição para a configuração original for realizada, o provedor precisará interromper o beacon e apagar a chave de identidade temporária e todas as chaves de conta armazenadas, incluindo a chave de conta do proprietário.
Após uma redefinição de fábrica (manual ou programática), o provedor não deve começar a anunciar o Par rápido imediatamente para evitar que o fluxo de pareamento seja iniciado imediatamente após a exclusão do dispositivo.
Prevenção de rastreamento indesejado
Os dispositivos FMDN certificados também precisam atender aos requisitos da versão de implementação da especificação multiplataforma para detectar rastreadores de localização indesejados (DULT, na sigla em inglês).
Diretrizes relevantes específicas para a FMDN para estar em conformidade com a especificação DULT:
- Qualquer dispositivo compatível com FMDN precisa estar registrado no Nearby Device Console e ter o recurso "Find My Device" ativado.
- O dispositivo precisa implementar o serviço e a característica de acessório para não proprietários definidos na versão de implementação da especificação DULT, incluindo as operações de informações do acessório e os controles para não proprietários.
- Durante o período de compatibilidade com versões anteriores, conforme definido na especificação DULT, não há mudanças no frame anunciado, conforme definido neste documento.
- O "modo de proteção contra rastreamento indesejado" definido neste documento é mapeado para o "estado separado" definido pela especificação DULT.
- Diretrizes para implementar os opcodes de informações do acessório:
- A função Get_Product_Data precisa retornar o ID do modelo fornecido pelo console, preenchido com zeros para atender ao requisito de 8 bytes. Por exemplo, o ID do modelo 0xFFFFFF é retornado como 0x0000000000FFFFFF.
- Get_Manufacturer_Name e Get_Model_Name precisam corresponder aos valores fornecidos no console.
- A Get_Accessory_Category pode retornar o valor genérico "Local Tracker" se nenhuma outra categoria se encaixa melhor no tipo do dispositivo.
- Get_Accessory_Capabilities precisa indicar o suporte para toque e pesquisa de identificador BLE.
- O método Get_Network_ID precisa retornar o identificador do Google (0x02).
- Diretrizes para implementar o opcode Get_Identifier:
- A operação só poderá retornar uma resposta válida por 5 minutos depois que o usuário ativar o modo "identificação", que exige uma combinação de pressionamentos de botão. Um sinal visual ou sonoro precisa indicar ao usuário que o provedor entrou nesse modo. As instruções específicas do modelo para ativar esse modo precisam ser fornecidas ao Google como um requisito para a certificação e pelo menos 10 dias antes de qualquer atualização ou modificação das instruções.
- A resposta é construída como: os primeiros 10 bytes do identificador
efetivo atual, seguidos pelos primeiros 8 bytes de
HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
- Diretrizes para implementar o identificador por NFC:
- Como URL, use
find-my.googleapis.com/lookup. - Como parâmetro
e, use a mesma resposta que foi criada para Get_Identifier, codificada em hexadecimal. - Como parâmetro
pid, use a mesma resposta construída para Get_Product_Data, codificada em hexadecimal.
- Como URL, use
- É obrigatório que o dispositivo inclua um criador de som e ofereça suporte à função de toque. De acordo com a especificação DULT, o criador de som precisa emitir um som com um nível de volume mínimo de 60 phon, conforme definido pela ISO 532-1:2017.
- Diretrizes para implementar o opcode Sound_Start:
- O comando deve acionar o toque em todos os componentes disponíveis.
- O volume máximo compatível precisa ser usado.
- A duração recomendada para o toque é de 12 segundos.
- As tags de localizador precisam incluir um mecanismo que permita aos usuários interromper temporariamente
a publicidade sem redefinir o dispositivo para a configuração original (por exemplo, pressionando uma
combinação de botões).
- As instruções de desativação precisam ser documentadas em um URL disponível publicamente e enviadas ao Google como um requisito para certificação e pelo menos 10 dias antes de qualquer atualização ou modificação das instruções.
- O URL precisa oferecer suporte à localização. Dependendo do cliente, o idioma será fornecido como um parâmetro de consulta ("hl=pt-br") ou usando o cabeçalho HTTP "accept-language".
Diretrizes de protocolo comutável
- Apenas um protocolo pode ser usado por vez. Garanta que apenas uma rede possa operar no dispositivo ao mesmo tempo. Esse requisito é necessário para garantir que não haja mistura de dados sensíveis do usuário entre diferentes protocolos.
- É recomendável incorporar um fluxo de trabalho de redefinição forçada ao dispositivo, que permite que o usuário configure o dispositivo novamente com uma rede diferente.
- O processo de atualização de um dispositivo para uma rede precisa ser fácil de usar e justo entre as redes. O usuário precisa poder escolher qual rede ele quer usar sem dar preferência a uma delas. Esse fluxo precisa ser aprovado pela equipe do Google.
Atualizações de firmware
O processo e a distribuição de atualizações OTA precisam ser gerenciados pelo parceiro usando o próprio fluxo de trabalho de apps para dispositivos móveis ou Web.
O Pareamento rápido oferece suporte ao envio de notificações ao usuário, informando as atualizações OTA disponíveis. Para usar esse mecanismo:
- A versão mais recente do firmware precisa ser atualizada no console de dispositivos próximos.
- Um app complementar precisa ser definido no console de dispositivos por perto. Ele precisa oferecer suporte à intent de atualização de firmware.
- O provedor precisa implementar a característica GATT Revisão do firmware.
Para evitar o rastreamento, o acesso à característica Revisão do firmware precisa ser restringido. O Seeker primeiro lê o estado de provisionamento e fornece uma chave de autenticação, conforme definido nesta especificação, e só depois lê a revisão do firmware. Isso será feito pela mesma conexão. Se uma tentativa for feita para ler a revisão do firmware e o provedor não estiver vinculado nem uma operação autenticada tiver sido concluída com sucesso nessa mesma conexão, o provedor vai retornar um erro não autenticado.
Compatibilidade
É necessário ativar os Serviços de localização e o Bluetooth para usar a rede Encontre Meu Dispositivo. É preciso ter uma rede celular ou uma conexão de Internet. Funciona no Android 9 e em versões mais recentes em alguns países para usuários de idades adequadas.
Registro de alterações
| Versão do FMDN | Data | Comentário |
|---|---|---|
| v1 | Lançamento inicial da especificação FMDN para acesso antecipado. | |
| v1.1 | Feb 2023 |
|
| v1.2 | Abril de 2023 |
|
| v1.3 | Dezembro de 2023 |
|