Especificação do acessório de rede do Encontre Meu Dispositivo

v1.3

A especificação de acessório da rede Encontre Meu Dispositivo (FMDN) define uma abordagem de criptografia de ponta a ponta para rastrear beacons em dispositivos Bluetooth de baixa energia (BLE). 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.

Observação: se você tem interesse em integrar a especificação do acessório do Encontre Meu Dispositivo, envie um formulário de proposta de dispositivo. Vamos compartilhar mais detalhes sobre as etapas de integração e certificação em breve.

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:

Octet	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 único	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.

Em seguida, o Seeker calcula uma chave de autenticação única a 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 farol. A chave da conta do proprietário escolhida não pode ser alterada até que o provedor seja redefinido para a configuração original. 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 ao FMDN quando pareado pela primeira vez (ou oferecem suporte quando pareado após a redefinição para a configuração original) 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 de 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 buscador pode usá-la apenas para fazer o dispositivo tocar.

• 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.

Octet	Tipo de dados	Descrição	Valor
0	uint8	ID de dados	0x00: Ler parâmetros do farol 0x01: ler o estado de provisionamento 0x02: definir a chave de identidade temporária 0x03: limpar chave de identidade temporária
1	uint8	Duração 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	0x00: n/a 0x01: n/a 0x02: 32 bytes que são a chave de identidade temporária, AES-ECB-128 criptografada com a chave da conta. Se o provedor já tiver uma chave de identidade temporária definida, envie também os primeiros 8 bytes de SHA256(current ephemeral identity key || the last nonce read from the characteristic). 0x03: os primeiros 8 bytes de SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabela 2:solicitação de provisionamento de beacon.

Octet	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x04: leitura da chave de identidade temporária com consentimento do usuário
1	uint8	Duração 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 de chave de provisionamento de beacon.

Octet	Tipo de dados	Descrição	Valor
0	uint8	ID de dados	0x05: Anel 0x06: Ler o estado de toque
1	uint8	Duração 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	0x05: 4 bytes que indicam o estado, a duração e o volume do toque. 0x06: n/d

Tabela 4:solicitação de toque.

Octeto	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x07: Ativar o modo de proteção contra rastreamento indesejado 0x08: desativar o modo de proteção contra rastreamento indesejado
1	uint8	Duração 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	0x07: 1 byte de flags de controle (opcional) 0x08: os primeiros 8 bytes de SHA256(ephemeral identity key || the last nonce read from the characteristic)

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.

Octet	Tipo de dados	Descrição	Valor
0	uint8	ID de dados	0x00: Ler parâmetros do farol 0x01: ler o estado de provisionamento 0x02: definir a chave de identidade temporária 0x03: Limpar a chave de identidade temporária 0x04: leitura da chave de identidade temporária com consentimento do usuário 0x05: alteração no estado do toque 0x06: ler o estado de toque 0x07: ativar o modo de proteção contra rastreamento indesejado 0x08: desativar o modo de proteção contra rastreamento indesejado
1	uint8	Duração dos dados	varia
2 a 9	matriz de bytes	Autenticação	Detalhes por operação
10 – var	matriz de bytes	Outros dados	0x00: 8 bytes indicando a potência de transmissão, o valor do relógio, o método de criptografia e os recursos de toque, criptografados com AES-ECB-128 com a chave da conta (preenchimento com zero) 0x01: 1 byte indicando o estado de provisionamento, seguido pelo ID temporário atual (20 ou 32 bytes), se aplicável 0x04: 32 bytes que são a chave de identidade temporária, AES-ECB-128 criptografada com a chave da conta 0x05: 4 bytes indicando o novo estado e o acionador da alteração 0x06: três bytes que indicam os componentes que estão tocando ativamente e o número de deciségundos restantes para tocar Outros IDs de dados usam dados adicionais vazios

Tabela 6:resposta do serviço de beacon.

A Tabela 7 lista os possíveis códigos de erro 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	Retornado quando algum valor inválido é fornecido ou 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 beacon

O buscador pode consultar o provedor em busca dos parâmetros do beacon executando uma operação de gravação na característica que consiste em uma solicitação da tabela 2 com o código de dados 0x00. O provedor verifica se a chave de autenticação única fornecida corresponde a qualquer uma das chaves de 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:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Energia calibrada	A potência calibrada recebida a 0 m (um valor no intervalo [-100, 20]). Representado como um número inteiro com sinal, 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: 0x00 (padrão): SECP160R1 0x01: SECP256R1 (exige publicidade estendida)
6	uint8	Componentes	O número de componentes capazes de tocar: 0x00: indica que o dispositivo não pode tocar. 0x01: indica que apenas um único componente é capaz de tocar. 0x02: indica que dois componentes, fones esquerdo e direito, podem tocar de forma independente. 0x03: indica que três componentes, os fones de ouvido esquerdo e direito e o estojo, podem tocar de forma independente.
7	uint8	Recursos de toque	As opções aceitas são estas: 0x00: a seleção do volume do toque não está disponível. 0x01: seleção de volume do toque disponível. Se definido, o provedor precisa aceitar e processar três níveis de volume, conforme indicado em Operação de toque.
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 provedor sobre o estado de provisionamento do beacon 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:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Estado de provisionamento	Uma máscara de bits com os seguintes valores: Bit 1 (0x01): é definido se uma chave de identidade temporária está definida para o dispositivo. Bit 2 (0x02): definido se a chave de autenticação única fornecida corresponde à chave da conta do proprietário.
1 - 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 divulgado pelo sensor, se um estiver 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 Seeker 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 tiver sido fornecido, a chave de identidade temporária com hash corresponderá à 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 o processo for bem-sucedido, a chave de identidade temporária será recuperada pelo AES-ECB-128, que a descriptografará 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 a conexão BLE ser encerrada. 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 não criptografado, mas não armazena a EIK em si.

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 se:

• A chave de recuperação com hash corresponde à chave de recuperação esperada.
• O dispositivo está no modo de recuperação EIK.

Se a verificação falhar, o provedor retornará um erro não autenticado.

Se o dispositivo não estiver no modo de pareamento, o provedor retornará um erro "Sem 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 buscador pode solicitar ao provedor que reproduza um som executando uma operação de gravação na característica, que consiste em uma solicitação da tabela 4 com o código de dados 0x05. O provedor constrói o segmento de dados da seguinte maneira:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Operação de toque	Uma máscara de bits com os seguintes valores: Bit 1 (0x01): toque à direita Bit 2 (0x02): toque à esquerda Bit 3 (0x04): caso de anel 0xFF: tocar em todos os componentes 0x00: parar de tocar
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	0x00: padrão 0x01: baixa 0x02: Médio 0 x 03: Alto O significado exato desses valores depende da implementação.

Ao receber a solicitação, o provedor verifica se:

• A chave de autenticação única fornecida corresponde à chave ring.
• 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, será retornado um erro não autenticado. No entanto, se o provedor tiver a proteção contra rastreamento indesejado ativada e a solicitação de proteção contra rastreamento indesejado acionar a flag de autenticação de ignorar toque, 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:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Estado de chamada	0x00: iniciado 0x01: falha ao iniciar ou parar (todos os componentes solicitados estão fora do intervalo) 0x02: Interrompida (tempo limite) 0x03: interrompido (pressionamento do botão) 0x04: Interrompida (solicitação GATT)
1	uint8	Componentes de toque	Um bitmask 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 interrupçã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.

Observação: para provedores que incluem a detecção no fone de ouvido, verifique se o dispositivo não está no fone de ouvido antes de tocar no volume máximo. Se a detecção no fone não tiver suporte ou não for confiável, aumente o volume gradualmente para que o usuário tenha tempo de parar o toque ou remover os fones de ouvido.

Observação: o provedor deve continuar tocando, independentemente do status de conexão do solicitante que solicitou o toque. Isso evita uma situação em que o dispositivo para de tocar porque a conexão é perdida devido ao cliente se afastar muito do dispositivo. Assim, o dispositivo não será encontrado porque parou de tocar e está muito longe do cliente para solicitar o toque de novo.

Acessar 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:

Octet	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	Tempo restante para o toque em decissegundos. 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 antirrastreamento 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:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Sinalizações de controle	0x01: Ignorar a autenticação de toque. Quando definido, as solicitações de toque não são autenticadas no modo de proteção contra rastreamento indesejado. Se nenhuma flag estiver sendo definida (o byte for todo zeros), é válido omitir a seção de dados inteira e enviar uma seção de dados vazia. 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 farol 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 girando normalmente. O tipo de frame precisa ser definido como 0x41. O estado também é refletido na seção de sinalizações 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 indesejada.
• 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 de volta para 0x40. O estado também é refletido na seção de sinalizações 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 de Pareamento rápido forem anunciados, o provedor precisará intercalar os frames FMDN nos anúncios normais de 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.

Observação: é recomendável anunciar os frames FMDN mesmo quando o dispositivo está no modo de baixo consumo, porque isso permite encontrar o dispositivo em caso de perda. Em alguns dispositivos, pode não ser possível anunciar quando o dispositivo está desligado devido às implicações na duração da bateria. Nesses casos, é altamente recomendável ativar o dispositivo periodicamente e anunciar por um curto período de tempo (por exemplo, ativar a cada 10 minutos e anunciar por 10 segundos).

O frame FMDN carrega 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 requer BLE 5 com recursos de publicidade estendidos. A implementação do provedor determina qual curva é usada.

Observação: o uso de chaves de 256 bits significa que smartphones mais antigos que não oferecem suporte a BLE 5 não podem verificar e gerar relatórios para dispositivos de publicidade, reduzindo o tamanho da rede.

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	Dados de sinalizações
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 a 27		Identificador temporário de 20 bytes
28		Flags com hash

Tabela 8:frame FMDN compatível com uma curva de 160 bits.

A tabela 9 mostra os deslocamentos de bytes e os valores para uma curva de 256 bits.

Octet	Valor	Descrição
0	0x02	Comprimento
1	0x01	Sinaliza o valor do tipo de dados
2	0x06	Dados de sinalizações
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 indesejada do modo de proteção contra rastreamento
8 a 39		Identificador temporário de 32 bytes
40		Flags com hash

Tabela 9:frame FMDN compatível com uma curva de 256 bits.

Cálculo do identificador temporário (EID)

Uma aleatória é gerada pelo AES-ECB-256 criptografando a seguinte estrutura de dados com a chave de identidade temporária:

Octet	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 beacon, no formato big-endian de 32 bits. Os bits mais baixos de K são apagados.
16 a 26	Padding	Valor = 0x00
27	K	Expoente do período de rotação
28 - 31	Solução de problemas[0]...Solução de problemas[3]	Contador de tempo do beacon, no formato big-endian de 32 bits. Os bits mais baixos de K são apagados.

Tabela 10:construção de um número pseudoaleatório.

Observação: presume-se que o dispositivo tenha um contador de tempo de 32 bits em segundos.

Observação: o expoente do período de rotação é fixo e definido como 10, correspondendo a 1.024 segundos.

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 em uso. 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 ao 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 bits mais significativos se a representação for menor que 160 ou 256 bits, ou 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

Observação: os detalhes a seguir para criptografia e descriptografia com EIDs são incluídos apenas para completar a especificação. Somente o solicitante implementa essas ações, não o provedor.

Para criptografar uma mensagem m, um observador (que leu Rx do farol) faria o seguinte:

1. Escolha um número aleatório s em Fp, conforme definido na seção Cálculo de EID.
2. Calcule S = s * G.
3. Calcule R = (Rx, Ry) substituindo os valores na equação de curva e escolhendo um valor arbitrário de Ry entre os resultados possíveis.
4. Calcule a chave AES de 256 bits k = HKDF-SHA256((s * R)x), em que (s * R)x é a coordenada x do resultado da multiplicação da curva. O sal não foi especificado.
5. Vamos supor que URx e LRx sejam os 80 bits superiores e inferiores de Rx, respectivamente, no formato big-endian. De forma semelhante, defina USx e LSx para S.
6. Calcule nonce = LRx || LSx.
7. Calcule (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
8. Envie (URx, Sx, m’, tag) ao proprietário, possivelmente por meio de 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:

1. Dado URx, obtenha o valor do contador de tempo do beacon em que URx é baseado. Isso pode ser feito pelo cliente do proprietário que calcula os valores Rx para os valores do contador de tempo do beacon no passado recente e no futuro próximo.
2. Considerando o valor do contador de tempo do farol em que URx é baseado, calcule o valor previsto de r, conforme definido na seção Cálculo de EID.
3. Calcule R = r * G e verifique uma correspondência com o valor de URx fornecido pelo observador.
4. Calcule S = (Sx, Sy) pela substituição na equação da curva e escolha um valor Sy arbitrário entre os resultados possíveis.
5. Calcule k = HKDF-SHA256((r * S)x), em que (r * S)x é a coordenada x do resultado da multiplicação da curva.
6. Calcule nonce = LRx || LSx.
7. 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. O RPA é necessário para dispositivos de áudio de baixo consumo (LEA, na sigla em inglês) e é recomendado para outros dispositivos, exceto tags de localização que não usam vínculo.

O anúncio do Pareamento rápido, o anúncio da 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 ordem aleatória foi aplicada) com um fator de tempo aleatório positivo no intervalo 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 corrigido, 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. Recomenda-se 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, no momento da inicialização, o provedor verifique a NVM para saber se há um valor para inicializar. Os resolvedores do identificador temporário implementam a resolução em uma janela de tempo suficiente para permitir um deslocamento razoável do relógio 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 stream de mensagens).

Diretrizes de implementação do Pareamento rápido

Esta seção descreve aspectos especiais da implementação de Pareamento rápido em provedores com suporte a FMDN.

Diretrizes específicas da tag de localizador

• Se o provedor tiver sido pareado, mas a FMDN não tiver sido provisionada em até cinco minutos (ou se uma atualização OTA tiver sido aplicada enquanto o dispositivo estiver pareado, mas não aprovisionado por FMDN), o provedor precisará reverter para a configuração original e limpar as chaves de conta armazenadas.
• Depois que o provedor é pareado, ele não pode mudar o endereço MAC até que o FMDN seja provisionado ou até cinco minutos se passarem.
• Se a chave de identidade temporária for apagada do dispositivo, ele precisará redefinir para a configuração original 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 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).
• 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 farol. Isso permite que o Seeker detecte o dispositivo e sincronize o relógio, mesmo que ocorra uma variação significativa.
• Ao anunciar frames do Pareamento rápido não detectáveis, 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 para dispositivos Bluetooth clássicos

Esta seção descreve aspectos especiais de dispositivos Bluetooth clássicos compatíveis com FMDN.

Provisionamento de FMDN de dispositivos já pareados

O provedor nem sempre é provisionado para FMDN ao parear com o solicitante, 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.

A compatibilidade com as duas abordagens aumenta as chances de o usuário provisionar o dispositivo para FMDN.

Fluxo de mensagens do Pareamento rápido

O provedor pode implementar o stream de mensagens de Pareamento rápido e usá-lo para notificar o buscador sobre as informações do dispositivo. A implementação do fluxo de mensagens ativa certos recursos, conforme descrito nesta seção.

O provedor precisa enviar mensagens de informações do dispositivo sempre que o canal RFCOMM de streaming de mensagens for estabelecido.

Versão do firmware (código de informações do dispositivo 0x09) e o recurso de rastreamento

Quando uma atualização de firmware adiciona suporte a FMDN ao provedor, um Seeker conectado pode notificar o usuário sobre isso e oferecer o provisionamento. Caso contrário, o usuário precisa navegar manualmente até a lista de dispositivos Bluetooth 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 Buscador sobre mudanças de recursos devido a atualizações de firmware.

Octet	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	Tamanho 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 recurso (0x0601), se o provedor tiver ativado o suporte para rastreamento FMDN, ele responderá conforme mostrado na tabela 12.

Octet	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: adição de um recurso de rastreamento.

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 for provisionado para FMDN e sincronizar o buscador em caso de deslocamento do relógio (por exemplo, devido a bateria esgotada). Caso contrário, o Seeker inicia uma conexão mais cara e menos confiável para essa finalidade.

Octet	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	Tamanho dos dados adicionais	0x0018 ou 0x0024
4 - 7	matriz de bytes	Valor do relógio	Exemplo: 0x13F9EA80
8 - 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 compatíveis com a redefinição para a configuração original: se uma redefinição para a configuração original for realizada, o Provedor precisará interromper os beacons e apagar a chave de identidade temporária e todas as chaves de conta armazenadas, incluindo a chave da conta do proprietário.

Após uma redefinição de fábrica (manual ou programática), o provedor não pode começar a anunciar o Par rápido imediatamente para evitar que o fluxo de pareamento seja iniciado logo após a exclusão do dispositivo.

Prevenção contra rastreamento indesejado

Dispositivos FMDN certificados também precisam atender aos requisitos na versão de implementação da especificação multiplataforma para Detecção de rastreadores de localização indesejados (DULT).

Diretrizes relevantes específicas para a FMDN para 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.
  • Get_Accessory_Category pode retornar o valor genérico "Location Tracker" se nenhuma outra categoria se encaixa melhor no tipo do dispositivo.
  • Get_Accessory_Capabilities precisa indicar suporte a toque, bem como a pesquisa do 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 de áudio 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 temporário 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.
• Diretrizes para implementar o código de operação Sound_Start:
  • O comando deve acionar o toque em todos os componentes disponíveis.
  • Use o volume máximo aceito.
  • A duração recomendada para o toque é de 12 segundos.
• As tags de localização 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 fornecidas 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 deve 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 protocolos variados.
• É recomendável incorporar um fluxo de trabalho de redefinição forçada ao dispositivo, que permite que o usuário configure novamente um dispositivo 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 app da Web ou para dispositivos móveis.

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 de FMDN	Data	Comentário
v1		Versão inicial da especificação FMDN para acesso antecipado.
v1.1	Feb 2023	Foi adicionada uma indicação de texto não criptografado do modo de proteção contra rastreamento indesejado. Foi adicionada uma opção para pular a autenticação de solicitações de toque no modo de proteção contra rastreamento indesejado.
v1.2	Abril de 2023	Atualizamos a definição do AK de um proprietário. Foi adicionada uma recomendação para recuperação de perda de energia em tags de localizadores. Adicionamos um esclarecimento sobre a randomização de endereços MAC. Adicionamos esclarecimentos sobre a rotação de endereços MAC no modo de proteção contra rastreamento indesejado. Adicionamos uma orientação sobre como desativar uma tag de localizador.
v1.3	Dezembro de 2023	Adicionamos um esclarecimento sobre a identificação de informações expostas por tags de localizador. Foi adicionado um requisito para implementar a especificação de prevenção de rastreamento indesejado. Foram adicionadas diretrizes para dispositivos de protocolo comutável.