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

v1.3

A especificação do acessório da rede Encontre Meu Dispositivo (FMDN, na sigla em inglês) define uma abordagem criptografada de ponta a ponta para rastrear dispositivos de beacon de Bluetooth de baixa energia (BLE). Esta página descreve o FMDN como uma extensão da especificação de Pareamento rápido. Os provedores precisarão ativar essa extensão se tiverem dispositivos compatíveis com FMDN e se estiverem dispostos a ativar o rastreamento de localização para eles.

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

Especificação GATT

Outra característica de atributos genéricos (GATT, na sigla em inglês) 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 do 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.

Proporção de Eficiência Energética (EER)

As operações exigidas por essa extensão são executadas como uma operação de gravação, protegida por um mecanismo de resposta do teste. Antes de realizar qualquer operação, espera-se que o Seeker execute uma operação de leitura a partir da característica da 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 único	varia

Cada operação de leitura precisa resultar em um valor de uso único diferente, e um único valor de uso único precisa ser válido somente para uma única operação. O valor de uso único precisa ser invalidado mesmo que a operação falhe.

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 Seeker prova conhecimento de uma ou mais das chaves a seguir:

• Chave da conta: a chave da conta de Pareamento rápido de 16 bytes, conforme definido na especificação do Pareamento rápido.

• Chave da conta do proprietário: o provedor escolhe uma das chaves de conta atuais como a chave da conta de proprietário na primeira vez que um Seeker acessa a característica das 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 original. O provedor não pode remover a chave da conta de proprietário quando ela ficar sem slots de chave de conta sem custo financeiro.

  • Os provedores que já oferecem suporte à FMDN quando pareados pela primeira vez (ou com suporte após a redefinição para a configuração original) escolhem a primeira chave de conta, porque essa é a única chave de conta atual quando o Seeker lê o estado de provisionamento durante o pareamento.

  • Os provedores que recebem suporte ao FMDN após o pareamento (por exemplo, em uma atualização de firmware) podem escolher qualquer chave de conta atual. É 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 Seeker ao executar o processo de provisionamento de FMDN. Essa chave é usada para derivar chaves criptográficas que são usadas para a criptografia de ponta a ponta nos Relatórios de local. O Buscador nunca a revela 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 o EIK, desde que o usuário expresse o 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 usuário pode usá-la apenas para fazer o toque do dispositivo.

• Chave de proteção de rastreamento indesejadas: definida como SHA256(ephemeral identity key || 0x03), truncada para os primeiros 8 bytes. A chave é armazenada no back-end, e o Seeker pode usá-la apenas para ativar o modo de proteção de 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 posteriormente nesta seção.

Octeto	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x00: ler parâmetros de beacon 0x01: Ler o estado de provisionamento 0x02: definir chave de identidade temporária 0x03: limpar chave de identidade temporária
1	uint8	Tamanho 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	Dados extras	0x00: n/d 0x01: n/d 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 um conjunto de chaves de identidade temporárias, 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.

Octeto	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x04: ler a chave de identidade temporária com o consentimento do usuário
1	uint8	Tamanho 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.

Octeto	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x05: Anel 0x06: Ler o estado do toque
1	uint8	Tamanho 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	Dados extras	0x05: 4 bytes indicando o estado, a duração e o volume do toque. 0x06: n/d

Tabela 4:pedido de toque.

Octeto	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x07: Ativar o modo indesejado de proteção contra rastreamento 0x08: desativar o modo de proteção contra rastreamento indesejado
1	uint8	Tamanho 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	Dados extras	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 de rastreamento indesejada.

Gravações bem-sucedidas acionam notificações conforme listado na Tabela 6.

As notificações com ID de dados diferente de 0x05: alteração do 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 do envio de uma PDU de resposta para a solicitação de gravação.

Octeto	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x00: ler parâmetros de beacon 0x01: Ler o estado de provisionamento 0x02: definir chave de identidade temporária 0x03: limpar chave de identidade temporária 0x04: ler a chave de identidade temporária com o consentimento do usuário 0x05: Alteração do estado do toque 0x06: Ler o estado do toque 0x07: Ativar o modo indesejado de proteção contra rastreamento 0x08: desativar o modo de proteção contra rastreamento indesejado
1	uint8	Tamanho dos dados	varia
2 a 9	matriz de bytes	Proporção de Eficiência Energética (EER)	Detalhado por operação
10 - var	matriz de bytes	Dados extras	0x00: 8 bytes indicando a potência de transmissão, o valor do clock, o método de criptografia e os recursos de toque, AES-ECB-128 criptografado com a chave da conta (zero preenchido) 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 gatilho da alteração 0x06: três bytes indicando os componentes tocando ativamente e o número de decissegundos restantes para o toque 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.

Programar	Descrição	Observações
0x80	Não autenticadas	Retornado em resposta a uma solicitação de gravação quando a autenticação falha (inclusive no 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: read 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 Seeker pode consultar o provedor sobre os parâmetros do sensor executando uma operação de gravação para a 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 alguma das chaves de conta armazenadas no dispositivo.

Se a verificação falhar, o provedor retornará um erro de autenticação.

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 0m (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 curvas	A curva elíptica usada para criptografia: 0x00 (padrão): SECP160R1 0x01: SECP256R1 (requer publicidade estendida)
6	uint8	Componentes	O número de componentes que podem tocar: 0x00: indica que o dispositivo não pode tocar. 0x01: indica que apenas um componente pode tocar. 0x02: indica que dois componentes, os fones de ouvido esquerdo e direito, podem tocar de maneira independente. 0x03: indica que três componentes, os fones esquerdo e direito e a caixa, podem tocar independentemente.
7	uint8	Recursos de toque	Estas são as opções aceitas: 0x00: seleção de volume do toque indisponí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	Padding zero para criptografia AES.

Os dados devem ser criptografados em AES-ECB-128 com a chave de 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 usuário pode consultar o provedor sobre o estado de provisionamento 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 0x01. O provedor verifica se a chave de autenticação única fornecida corresponde a alguma das chaves de conta armazenadas no dispositivo.

Se a verificação falhar, o provedor retornará um erro de autenticação.

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 bitmask com os seguintes valores: Bit 1 (0x01): definido se uma chave de identidade temporária estiver definida para o dispositivo. Bit 2 (0x02): define 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 anunciado pelo beacon, 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 FMDN ou alterar a chave de identidade temporária do provedor já provisionado, o buscador executa uma operação de gravação para a característica que consiste em uma solicitação da tabela 2 com 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 tiver sido fornecido, verifique se o provedor já não foi provisionado como um beacon FMDN.

Se a verificação falhar, o provedor retornará um erro de autenticação.

Em caso de sucesso, a chave de identidade temporária é recuperada pelo AES-ECB-128, que a descriptografa usando a chave de conta correspondente. A chave precisa ser mantida no dispositivo e, a partir desse ponto, o provedor precisa começar a divulgar 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 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 desprovisionar a parte do beacon do provedor, o Seeker executa uma operação de gravação na característica, que consiste em uma solicitação da tabela 2 com 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 beacon FMDN ou se a verificação falhar, ele vai retornar um erro não autenticado.

Se for bem-sucedido, o Provedor esquece a chave e para de anunciar frames FMDN. O provedor notifica com uma resposta da tabela 6 com 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 apenas pelo buscador. Dessa forma, esse recurso só fica disponível quando o dispositivo está no modo de pareamento ou por um tempo limitado depois que um botão físico é pressionado no dispositivo, o que constitui o consentimento do usuário.

O Seeker precisa armazenar a chave de recuperação no back-end para recuperar a chave de texto não criptografado, mas não armazena o EIK.

Para ler o EIK, o Seeker executa uma operação de gravação para a 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 esperada.
• O dispositivo está no modo de recuperação EIK.

Se a verificação falhar, o provedor retornará um erro de autenticação.

Se o dispositivo não estiver no modo de pareamento, o provedor vai retornar um erro de 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 pedir ao provedor para tocar um som executando uma operação de gravação na característica, que consiste em uma solicitação da tabela 4 com 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 bitmask com os seguintes valores: Bit 1 (0x01): Tocar para a direita Bit 2 (0x02): anel para a esquerda Bit 3 (0x04): anel 0xFF: tocar todos os componentes 0x00: parar de tocar
1 - 2	uint16	Tempo limite	Tempo limite em decissegundos. Não pode ser zero nem maior que o equivalente a 10 minutos. O provedor usa esse valor para determinar por quanto tempo ele deve tocar antes de se silenciar. O tempo limite vai substituir o que já está em vigor se algum componente do dispositivo já estiver tocando. Se a operação de toque for definida como 0x00, o tempo limite será ignorado.
3	uint8	Volume	0x00: padrão 0x01: Baixo 0x02: Médio 0x03: 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 de toque.
• O estado solicitado corresponde aos componentes que podem tocar.

Se o provedor não for provisionado como um beacon FMDN ou se a verificação falhar, ele vai retornar um erro não autenticado. No entanto, se o provedor tiver a proteção de rastreamento indesejada ativa e a solicitação de proteção de rastreamento indesejada estiver ativada, o provedor precisará pular essa verificação. Os dados de autenticação ainda precisam ser fornecidos pelo Seeker, mas podem ser definidos com um valor arbitrário.

Quando o toque é iniciado ou encerrado, uma notificação é enviada conforme indicado na tabela 6 com ID de dados 0x05. O conteúdo da notificação é definido da seguinte maneira:

Octeto	Tipo de dados	Descrição	Valor
0	uint8	Estado do toque	0x00: iniciado 0x01: falha ao iniciar ou parar (todos os componentes solicitados estão fora do intervalo) 0x02: Parado (tempo limite) 0x03: Parado (pressionar um botão) 0x04: Parado (solicitação GATT)
1	uint8	Componentes de toque	Uma bitmask dos componentes tocando ativamente, conforme definido na solicitação.
2 a 3	uint16	Tempo limite	Tempo restante para o toque em decissegundos. Se o dispositivo parar de tocar, 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 para tocar ou parar de tocar for recebida, o provedor precisará enviar uma notificação com um estado de toque ou 0x00: iniciado ou 0x04: interrompido (solicitação GATT), respectivamente. Essa solicitação substitui os parâmetros do estado existente, para que a duração do toque possa ser estendida.

Se o provedor tiver um botão físico (ou a detecção de toque estiver ativada), esse botão vai interromper a função de toque se for pressionado enquanto o toque estiver ativo.

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

Observação: o provedor precisa continuar tocando, independente do status da conexão do usuário que solicitou o toque. Isso evita uma situação em que o dispositivo para de tocar porque a conexão é perdida devido ao movimento do cliente muito longe do dispositivo. O dispositivo não é encontrado porque parou de tocar e está muito longe do cliente para solicitar o toque novamente.

Descobrir o estado de toque do sensor

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 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 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 estão tocando ativamente, conforme definido na solicitação.
1 - 2	uint16	Tempo limite	Tempo restante para o toque em decissegundos. Se o dispositivo não estiver tocando, 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 na rotação de IDs. O serviço Encontre Meu Dispositivo pode redirecionar uma solicitação indesejada de ativação do modo de proteção contra rastreamento 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 indesejado de proteção contra rastreamento do beacon, o Seeker executa uma operação de gravação para a característica, que consiste em uma solicitação da tabela 5 com ID de dados 0x07 ou 0x08, respectivamente.

Ao ativar o modo indesejado de proteção contra rastreamento

O provedor constrói o segmento de dados da seguinte maneira:

Octeto	Tipo de dados	Descrição	Valor
0	uint8	Flags de controle	0x01: pular a autenticação de toque. Quando definido, as solicitações de toque não serão autenticadas no modo de proteção de rastreamento indesejado. Se nenhuma flag estiver sendo definida (o byte é só zeros), é válido omitir completamente a seção de dados e enviar uma seção de dados vazia. As sinalizações vão ficar em vigor somente 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 de rastreamento indesejadas. Se o provedor não for provisionado como um beacon FMDN ou se a verificação falhar, ele retornará um erro não autenticado.

Quando o modo de proteção de rastreamento indesejado está ativado, o sensor precisa reduzir a frequência de rotação do endereço particular do MAC para uma vez a cada 24 horas. O identificador temporário anunciado precisa continuar em rotação normalmente. O tipo de frame deve ser definido como 0x41. O estado também é refletido na seção de sinalizações com hash.

Ao desativar o modo de proteção antirrastreamento

O Provedor verifica se:

• A chave de autenticação única fornecida corresponde à chave de proteção de 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 se a verificação falhar, ele vai retornar um erro não autenticado.

Quando o modo de proteção de rastreamento indesejado é desativado, o beacon precisa começar a girar o endereço MAC a uma taxa normal novamente, sincronizado com a rotação do identificador temporário. O tipo de frame deve ser definido novamente 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 o provisionamento, espera-se que o provedor anuncie 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 de FMDN nos anúncios comuns de Pareamento rápido. Por exemplo, a cada dois segundos, o provedor precisa anunciar sete anúncios de Pareamento rápido e um anúncio FMDN.

Observação: é recomendado anunciar os frames FMDN mesmo quando o dispositivo está no modo de baixa energia, porque isso permite encontrar o dispositivo em caso de perda. Para alguns dispositivos, talvez não seja possível anunciar quando eles estão desligados devido às implicações da duração da bateria. Nesses casos, é altamente recomendável ativar o dispositivo periodicamente e anunciar por um curto período (por exemplo, acordar a cada 10 minutos e anunciar por 10 segundos).

O frame FMDN tem uma chave pública usada para criptografar os relatórios de localização de qualquer cliente de suporte que contribua para a rede de crowdsourcing. Dois tipos de chave 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 estendidos de publicidade. A implementação do provedor determina qual curva é usada.

Observação: o uso de chaves de 256 bits significa que smartphones mais antigos incompatíveis com BLE 5 não podem verificar nem gerar relatórios para dispositivos de publicidade, reduzindo assim o tamanho da rede.

Um frame FMDN é estruturado da seguinte maneira.

Octeto	Valor	Descrição
0	0x02	Comprimento
1	0x01	Valor do tipo de dados das flags
2	0x06	Dados de sinalizações
3	0x18 ou 0x19	Comprimento
4	0x16	Valor do tipo 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 de rastreamento
8 a 27		Identificador temporário de 20 bytes
28		Sinalizações com hash

Tabela 8:frame FMDN com suporte a uma curva de 160 bits.

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

Octeto	Valor	Descrição
0	0x02	Comprimento
1	0x01	Valor do tipo de dados das flags
2	0x06	Dados de sinalizações
3	0x24 ou 0x25	Comprimento
4	0x16	Valor do tipo 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 de rastreamento
8 a 39		Identificador temporário de 32 bytes
40		Sinalizações com hash

Tabela 9:frame FMDN com suporte a uma curva de 256 bits.

Computação de identificador temporário (EID, na sigla em inglês)

Um 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 sensor, no formato big-endian de 32 bits. Os mais baixos são apagados.
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 sensor, no formato big-endian de 32 bits. Os mais baixos são apagados.

Tabela 10. Criaçã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, o que corresponde a 1.024 segundos.

O resultado desse cálculo é um número de 256 bits, indicado 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 definem Fp, n e G referenciados a seguir.

r' agora é projetado no campo finito Fp pelo cálculo de r = r' mod n. Por fim, calcule R = r * G, que é um ponto na curva que representa a chave pública que está sendo usada. O sensor divulga Rx, que é a coordenada x de R, como identificador temporário.

Sinalizações com hash

O campo de sinalizações com hash é calculado da seguinte maneira (os bits são referenciados do mais significativo ao menos significativo):

• Bits 0 a 4: reservado (definido como zeros).
• Os bits 5 a 6 indicam o nível de bateria do dispositivo da seguinte maneira:
  • 00: Indicação do nível da bateria incompatível
  • 01: Nível normal de bateria
  • 10: Baixo nível de bateria
  • 11: nível de bateria muito baixo (a bateria precisa ser substituída em breve)
• O bit 7 é definido como 1 se o sensor estiver no modo de proteção contra rastreamento indesejado e como 0 se não estiver.

Para produzir o valor final desse byte, ele é xor-ed com o byte menos significativo de SHA256(r).

Observe que r deve 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 sensor não tiver suporte à indicação de nível de bateria e não estiver no modo de proteção de rastreamento indesejado, será permitido omitir esse byte totalmente do anúncio.

Criptografia com EID

Observação: os detalhes a seguir de criptografia e descriptografia com EIDs são incluídos apenas para garantir a integridade da especificação. Somente o Buscador implementa isso, não o Provedor.

Para criptografar uma mensagem m, um observador (ao ler Rx do beacon) fará o seguinte:

1. Escolha um número aleatório s em Fp, conforme definido na seção Computação de EID.
2. Calcule S = s * G.
3. Calcule R = (Rx, Ry) por substituição na equação de curva e escolhendo um valor arbitrário Ry fora dos 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 de curva. O sal não é especificado.
5. Permita que URx e LRx sejam os 80 bits superiores e inferiores de Rx, respectivamente, no formato big-endian. Da mesma forma, 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) 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 tem o EIK e o expoente do período de rotação, descriptografa a mensagem da seguinte maneira:

1. Dado URx, extraia o valor do contador de tempo do sensor em que URx se baseia. Para isso, o cliente do proprietário calcula os valores de Rx dos valores do contador de tempo do beacon para o passado recente e o futuro próximo.
2. Considerando o valor do contador de tempo do sensor em que URx se baseia, 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 visualizador.
4. Calcule S = (Sx, Sy) por substituição na equação de curva e escolhendo um valor arbitrário Sy fora dos resultados possíveis.
5. Calcule k = HKDF-SHA256((r * S)x), em que (r * S)x é a coordenada x do resultado da multiplicação de 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 resolvido (RPA) ou não resolvível (NRPA) precisa ser usado para publicar frames FMDN. O RPA é obrigatório para dispositivos LE Audio (LEA, na sigla em inglês) e é recomendado para outros, exceto as tags de localizador que não usam vinculação.

A divulgação de Pareamento rápido, a divulgação FMDN e os endereços BLE correspondentes precisam ser alternados ao mesmo tempo. A rotação acontece 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 na janela.

A abordagem recomendada para randomizar o tempo de rotação é defini-lo para o próximo tempo de rotação previsto (se nenhuma ordem aleatória tiver sido aplicada), além de um fator de tempo aleatório positivo no intervalo de 1 a 204 segundos.

Quando o dispositivo está no modo de proteção de rastreamento indesejado, o endereço BLE do anúncio FMDN precisa ser corrigido, mas o RPA para anúncios não detectáveis de FP (como Pareamento rápido) precisa continuar em rotação. É aceitável usar endereços diferentes para cada protocolo.

Recuperação de queda de energia

A resolução do identificador temporário está fortemente vinculada ao valor do relógio no momento do anúncio. Por isso, é importante que o provedor recupere o valor do relógio se houver uma queda de energia. É recomendado 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 se há um valor de inicialização. Os resolvedores do identificador temporário implementariam a resolução em uma janela de tempo suficiente para permitir deslocamentos razoáveis de relógio e esse tipo de recuperação de perda de energia.

Os provedores ainda precisam fazer todos os esforços para minimizar os desvios do relógio, porque a janela de tempo de resolução é limitada. Pelo menos mais um método de sincronização do relógio precisa ser implementado, divulgando frames de Pareamento rápido não detectáveis ou implementando o fluxo de mensagens.

Diretrizes de implementação do Pareamento rápido

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

Diretrizes específicas para tags de localizador

• Se o provedor tiver sido pareado, mas o FMDN não tiver sido provisionado em até cinco minutos (ou se uma atualização OTA tiver sido aplicada enquanto o dispositivo estiver pareado, mas não provisionado com o FMDN), o provedor precisará reverter para a configuração de fábrica e limpar as chaves da conta armazenadas.
• Depois que o provedor for pareado, ele não mudará o endereço MAC até o FMDN até ser provisionado ou após cinco minutos.
• Se a chave de identidade temporária for removida do dispositivo, ele precisará redefinir para a configuração original e limpar as chaves da conta armazenadas também.
• O provedor precisa rejeitar as tentativas normais de pareamento do Bluetooth e aceitar apenas o Pareamento rápido.
• 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, pressionar uma combinação de botões).
• Após uma queda de energia, o dispositivo precisa anunciar frames de Pareamento rápido não detectáveis até a próxima invocação dos parâmetros de beacon de leitura. Isso permite que o Seeker detecte o dispositivo e sincronize o relógio mesmo que ocorra um deslocamento significativo do relógio.
• Ao anunciar frames de Pareamento rápido não detectáveis, as indicações de interface não podem ser ativadas.
• Os frames de Pareamento rápido detectáveis não podem ser anunciados enquanto o provedor está provisionado para o FMDN.
• O provedor não pode expor informações de identificação de maneira não autenticada (por exemplo, nomes ou identificadores).

Diretrizes específicas para o dispositivo Bluetooth clássico

Esta seção descreve aspectos especiais de dispositivos Bluetooth clássico com suporte ao FMDN.

Provisionamento de FMDN de dispositivos já pareados

O provedor nem sempre é provisionado para o FMDN ao parear com o Seeker, mas um pouco depois disso. Nesse caso, o provedor pode não ter um endereço MAC BLE atualizado necessário para estabelecer uma conexão GATT. O provedor precisa oferecer suporte a pelo menos uma das seguintes maneiras para que o Seeker consiga o endereço BLE enquanto já estiver pareado:

• O provedor pode anunciar periodicamente os dados da conta do Pareamento rápido que permitem ao usuário encontrar o endereço BLE por meio de uma verificação de BLE.
  Essa abordagem é adequada para provedores que não implementam o stream de mensagens.
• O provedor pode fornecer esses dados pelo stream de mensagens de Pareamento rápido usando o Bluetooth clássico.
  Essa abordagem é adequada para provedores que não anunciam frames de Pareamento rápido enquanto estão conectados à busca por Bluetooth.

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

Stream de mensagens com 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 alguns recursos, conforme descrito nesta seção.

O provedor precisa enviar mensagens de informações do dispositivo uma vez sempre que o canal RFCOMM de fluxo 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 para FMDN ao provedor, um buscador conectado pode notificar o usuário sobre isso e se oferecer para provisioná-lo. Caso contrário, o usuário vai precisar navegar até a lista de dispositivos Bluetooth manualmente para iniciar o provisionamento do FMDN.

Para permitir isso, o provedor precisa usar a propriedade da versão do firmware (código 0x09) para informar um valor de string que representa a versão do firmware. Além disso, o provedor precisa ser compatível com o protocolo que informa ao usuário sobre as mudanças nos 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	Comprimento de dados adicional	varia
var	matriz de bytes	String da versão	varia

Tabela 11. Evento com informações do dispositivo: versão atualizada do firmware.

Ao receber uma solicitação de atualização de capacidade (0x0601), se o provedor tiver ativado o suporte para rastreamento FMDN, ele responderá como mostrado na tabela 12.

Octeto	Tipo de dados	Descrição	Valor
0	uint8	Evento de sincronização da capacidade do dispositivo	0x06
1	uint8	Monitoramento de FMDN	0x03
2 a 3	uint16	Comprimento de dados adicional	0x0007
4	uint8	Estado de provisionamento do FMDN	0 x 00 se não aprovisionado. 0 x 01 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 da capacidade do dispositivo: recurso de rastreamento adicionado.

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 for provisionado para o FMDN, para sincronizar o Seeker em caso de deslocamento 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	0 x 0 bi
2 a 3	uint16	Comprimento de dados adicional	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 compatíveis com a redefinição para a configuração original: se essa redefinição for realizada, o provedor precisará interromper o beaconing e excluir 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 para a configuração original (manual ou programática), o provedor não pode começar a anunciar o Pareamento rápido imediatamente para evitar que o fluxo de pareamento comece imediatamente após a exclusão do dispositivo.

Prevenção de rastreamento indesejado

Os 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, na sigla em inglês).

Diretrizes relevantes específicas do FMDN para serem compatíveis com as especificações DULT:

• Qualquer dispositivo compatível com FMDN precisa ser registrado no console de dispositivos por perto e ter o recurso "Encontre Meu Dispositivo" ativado.
• O dispositivo precisa implementar o serviço e as características de não proprietário do acessório definidas na versão de implementação da especificação DULT, incluindo as operações de Informações sobre acessórios e os controles de não proprietário.
• 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 códigos de operações das informações sobre acessórios:
  • Get_Product_Data precisa retornar o ID do modelo fornecido pelo console, sem preenchimento 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 "Rastreador de localização" se nenhuma outra categoria se encaixar melhor no tipo do dispositivo.
  • Get_Accessory_Capabilities precisa indicar o suporte para toque, bem como a pesquisa de identificador BLE.
  • Get_Network_ID deve retornar o identificador do Google (0x02).
• Diretrizes para implementar o código de operação Get_Identifier:
  • A operação só precisa retornar uma resposta válida durante cinco minutos após o usuário ativar o modo "identificação", 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 requisito de certificação e pelo menos 10 dias antes de qualquer atualização ou modificação das instruções.
  • A resposta é criada 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 código de operação Sound_Start:
  • O comando acionará o toque em todos os componentes disponíveis.
  • O volume máximo permitido 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, pressionar 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 a certificação e pelo menos 10 dias antes de qualquer atualização ou modificação das instruções.
  • O URL deve oferecer suporte à localização. Dependendo do cliente, o idioma será fornecido como um parâmetro de consulta ("hl=en") ou usando o cabeçalho HTTP "accept-language".

Diretrizes de protocolo alternável

• Use apenas um protocolo por vez. Garanta que nenhuma rede possa operar no dispositivo ao mesmo tempo. Esse requisito é necessário para garantir que não haja mistura de dados confidenciais do usuário entre protocolos variados.
• É recomendado incorporar um fluxo de trabalho de reinicialização forçada no dispositivo que permita que o usuário reconfigure um dispositivo com uma rede diferente.
• O processo de atualização de um dispositivo para uma rede precisa ser fácil de usar e equitativo entre as redes. Um usuário precisa poder escolher qual rede 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 da Web.

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 versões mais recentes e em determinados países para usuários de idades adequadas.

Registro de alterações

Versão 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 de rastreamento indesejado. Foi adicionada uma opção para pular a autenticação de solicitações que tocam durante o modo de proteção de rastreamento indesejado.
v1.2	Abril de 2023	Atualizamos a definição da AK de um proprietário. Adicionamos uma recomendação para recuperação da perda de energia em tags de localizador Adição de um esclarecimento sobre a ordem aleatória de endereços MAC. Adicionamos um esclarecimento sobre a rotação de endereços MAC no modo de proteção de rastreamento indesejado. Adicionamos uma diretriz sobre como desativar uma tag de localizador.
v1.3	Dezembro de 2023	Adicionamos um esclarecimento sobre como identificar informações expostas pelas tags de localização. Adicionamos um requisito para implementar a especificação indesejada de prevenção de rastreamento. Adição de diretrizes para dispositivos de protocolo alternáveis.