Especificação do acessório da Rede Localizador

v1.3

A especificação de acessórios da Rede Localizador (FHN, na sigla em inglês) define uma abordagem criptografada de ponta a ponta para rastrear dispositivos Bluetooth de baixa energia (BLE) de beacon. Esta página descreve o FHN como uma extensão da especificação do Fast Pair. Os provedores precisam ativar essa extensão se tiverem dispositivos compatíveis com o FHN e quiserem ativar o rastreamento de localização para eles.

Especificação GATT

Uma característica genérica adicional de atributos (GATT, na sigla em inglês) precisa ser adicionada ao Serviço Fast Pair 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 FHN.

Autenticação

As operações exigidas por 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 fazer 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	Nonce aleatório único	varia

Cada operação de leitura precisa resultar em um nonce diferente, e um único nonce só pode ser válido para uma única operação. O nonce precisa ser invalidado mesmo se a operação falhar.

Em seguida, o Seeker calcula uma chave de autenticação única para ser usada em uma solicitação de gravação subsequente. A chave de autenticação é calculada conforme descrito nas tabelas de 2 a 5. Dependendo da operação solicitada, o Seeker 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 existentes como a chave da conta de proprietário na primeira vez que um buscador acessa a característica de ações do Beacon. A chave da conta de proprietário escolhida não pode ser alterada até que o provedor seja redefinido para a configuração de fábrica. O provedor não pode remover a chave da conta do proprietário quando ela ficar sem slots de chave de conta sem custo financeiro.

  • Os provedores que já oferecem suporte ao FHN quando pareados pela primeira vez (ou quando pareados após a redefinição de fábrica) escolhem a primeira chave da conta, porque essa é a única chave da conta existente quando o Seeker lê o estado de provisionamento durante o pareamento.

  • Os provedores que recebem suporte ao FHN depois de já estarem pareados (por exemplo, por uma atualização de firmware) podem escolher qualquer chave de conta existente. É razoável escolher a primeira chave de conta usada para ler o estado de provisionamento da característica de ações do beacon após a atualização do firmware, supondo que o usuário que realizou a atualização seja o proprietário atual do provedor.

• Chave de identidade efêmera (EIK): uma chave de 32 bytes escolhida aleatoriamente pelo Seeker ao realizar o processo de provisionamento do FHN. Essa chave é usada para derivar chaves criptográficas usadas para criptografar relatórios de localização de ponta a ponta. O Seeker nunca o revela ao back-end.

• Chave de recuperação: definida como SHA256(ephemeral identity key || 0x01), truncada nos primeiros 8 bytes. A chave é armazenada no back-end, e o Seeker pode usá-la para recuperar o EIK, desde que o usuário dê consentimento ao pressionar um botão no dispositivo.

• Chave de toque: definida como SHA256(ephemeral identity key || 0x02), truncada para os primeiros 8 bytes. A chave é armazenada no back-end, e o Seeker só pode usá-la para tocar o dispositivo.

• Chave de proteção contra rastreamento indesejado: definida como SHA256(ephemeral identity key || 0x03), truncada nos 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 de 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 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	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 efêmera, AES-ECB-128 criptografada com a chave da conta. Se o provedor já tiver um conjunto de chaves de identidade efêmeras, 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: ler a chave de identidade temporária com o 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 da chave de provisionamento do beacon.

Octet	Tipo de dados	Descrição	Valor
0	uint8	ID dos dados	0x05: tocar 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 indicando o estado, a duração e o volume do toque. 0x06: n/a

Tabela 4:solicitação de toque.

Octet	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 antirrastreamento 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 um ID de dados diferente de 0x05: mudança no estado do toque precisam ser enviadas antes da conclusão da transação de gravação que aciona a notificação, ou seja, antes do envio de uma PDU de resposta para a solicitação de gravação.

Octet	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: mudança de 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 antirrastreamento indesejado
1	uint8	Duração dos dados	varia
2 a 9	matriz de bytes	Autenticação	Detalhado por operação
10 - var	matriz de bytes	Outros dados	0x00: 8 bytes indicando a potência de transmissão, o valor do clock, o método de criptografia e os recursos de toque, criptografados com AES-ECB-128 com a chave da conta (com preenchimento de zero). 0x01: 1 byte indicando o estado de provisionamento, seguido pelo ID efêmero atual (20 ou 32 bytes), se aplicável 0x04: 32 bytes que são a chave de identidade efêmera, AES-ECB-128 criptografada com a chave da conta 0x05: 4 bytes que indicam o novo estado e o gatilho da mudança 0x06: 3 bytes indicando os componentes que estão tocando e o número de decisegundos restantes para tocar Outros IDs de dados usam dados extras vazios

Tabela 6:resposta do serviço de beacon.

A Tabela 7 lista os possíveis códigos de erro do GATT retornados pelas operações.

Código	Descrição	Observações
0x80	Não autenticadas	Retornado em resposta a uma solicitação de gravação quando a autenticação falha (incluindo o caso em que um nonce antigo foi usado).
0x81	Valor inválido	Retornado quando um valor inválido é fornecido ou os dados recebidos têm um número inesperado de bytes.
0x82	Nenhum consentimento do usuário	Retornado em resposta a uma solicitação de gravação com ID de dados 0x04: ler chave de identidade efêmera 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 Provider para receber os parâmetros do beacon realizando uma operação de gravação na característica que consiste em uma solicitação da tabela 2 com ID de dados 0x00. O provedor verifica se a chave de autenticação única fornecida corresponde a alguma das chaves da conta armazenadas no dispositivo.

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

Em caso de sucesso, o provedor notifica com uma resposta da tabela 6 com o ID de dados 0x00. O provedor cria o segmento de dados da seguinte forma:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Potência calibrada	A potência calibrada recebida a 0 m (um valor no intervalo [-100, 20]). Representado como um número inteiro 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 (requer 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 componente é capaz de tocar. 0x02: indica que dois componentes, os fones esquerdo e direito, podem tocar de forma independente. 0x03: indica que três componentes, os fones esquerdo e direito e o estojo, podem tocar de forma independente.
7	uint8	Recursos de toque	As opções aceitas são: 0x00: a seleção do volume da campainha não está disponível. 0x01: seleção de volume de 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 precisam ser criptografados com AES-ECB-128 usando 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 Provider 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 ID de dados 0x01. O provedor verifica se a chave de autenticação única fornecida corresponde a alguma 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 cria o segmento de dados da seguinte forma:

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 efêmera for definida para o dispositivo. Bit 2 (0x02): definido se a chave de autenticação única fornecida corresponder à chave da conta do proprietário.
1 a 20 ou 32	matriz de bytes	Identificador efêmero atual	20 ou 32 bytes (dependendo do método de criptografia usado) que indicam o ID efêmero 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 efêmera

Para provisionar um provedor não provisionado como um beacon FHN ou mudar a chave de identidade efêmera de um provedor já provisionado, o Seeker realiza uma operação de gravação na 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 foi fornecido, a chave de identidade temporária com hash vai corresponder à chave de identidade temporária atual.
• Se um hash de uma chave de identidade efêmera não foi fornecido, verifique se o provedor já não foi provisionado como um beacon FHN.

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

Se a operação for bem-sucedida, a chave de identidade temporária será recuperada com a descriptografia AES-ECB-128 usando a chave de conta correspondente. A chave precisa ser mantida no dispositivo, e a partir desse momento, o provedor vai começar a anunciar frames de FHN. A nova chave de identidade efêmera entra em vigor imediatamente após o término da conexão BLE. O provedor notifica com uma resposta da tabela 6 com o ID de dados 0x02.

O segmento de autenticação é definido como os primeiros 8 bytes de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Limpar a chave de identidade temporária

Para desprovisionar a parte de beacon do provedor, o buscador realiza uma operação de gravação na característica, consistindo 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 FHN ou a verificação falhar, ele retornará um erro não autenticado.

Se a operação for bem-sucedida, o provedor vai esquecer a chave e parar de anunciar frames FHN. 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 efêmera com o consentimento do usuário

Essa opção só está disponível para recuperar uma chave perdida, já que ela é armazenada localmente pelo Seeker. Por isso, essa capacidade só está disponível quando o dispositivo está no modo de pareamento ou por um período limitado após o pressionamento de um botão físico no dispositivo (o que constitui consentimento do usuário).

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

Para ler o EIK, o Seeker realiza 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 do EIK.

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

Se o dispositivo não estiver no modo de pareamento, o provedor vai retornar um erro de "Consentimento do usuário não concedido".

Se a operação for bem-sucedida, o provedor vai notificar 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 Seeker pode pedir ao Provider para tocar um som realizando uma operação de gravação na característica, que consiste em uma solicitação da tabela 4 com o ID de dados 0x05. O provedor cria o segmento de dados da seguinte forma:

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): tocar do lado direito Bit 2 (0x02): tocar do lado esquerdo Bit 3 (0x04): toque 0xFF: tocar em todos os componentes 0x00: parar de tocar
1 - 2	uint16	Tempo limite	O 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 substitui 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: baixa 0x02: média 0x03: alta 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 do toque.
• O estado solicitado corresponde aos componentes que podem tocar.

Se o provedor não for provisionado como um beacon FHN ou a verificação falhar, ele retornará um erro não autenticado. No entanto, se o provedor tiver uma proteção contra rastreamento indesejado ativa, e a solicitação de ativação da proteção contra rastreamento indesejado tiver a flag de autenticação de toque ignorada ativada, o provedor deverá ignorar essa verificação. Os dados de autenticação ainda precisam ser fornecidos pelo Seeker, 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 forma:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Estado de chamada	0x00: iniciada 0x01: falha ao iniciar ou parar (todos os componentes solicitados estão fora do intervalo) 0x02: interrompido (tempo limite) 0x03: parado (pressionamento de botão) 0x04: interrompido (solicitação GATT)
1	uint8	Componentes de toque	Uma máscara de bits dos componentes que estão tocando ativamente, conforme definido na solicitação.
2 - 3	uint16	Tempo limite	O tempo restante para tocar em decissegundos. Se o dispositivo parou de tocar, 0x0000 deve 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 deverá enviar uma notificação com um estado de toque ou 0x00: Iniciado ou 0x04: Parado (solicitação 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 sensor de toque estiver ativado), ele deverá interromper a função de toque se for pressionado enquanto o toque estiver ativo.

Receber o estado de toque do beacon

Para receber o estado de toque do beacon, o Seeker realiza uma operação de gravação na característica, consistindo 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 do toque.

Se o provedor não for provisionado como um beacon FHN ou se a verificação falhar, ele vai retornar um erro não autenticado.

Se a operação for bem-sucedida, o provedor vai notificar com uma resposta da tabela 6 com o ID de dados 0x06. O provedor cria o segmento de dados da seguinte forma:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Componentes de toque	Os componentes tocando ativamente, conforme definido na solicitação de toque.
1 - 2	uint16	Tempo limite	O tempo restante para tocar 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 deve alternar todos os identificadores conforme descrito em Alternância de ID. O serviço Localizador pode retransmitir um pedido de ativação indesejado do modo de proteção contra rastreamento pela rede do Localizador. 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 realiza uma operação de gravação na característica, consistindo em uma solicitação da tabela 5 com ID de dados 0x07 ou 0x08, respectivamente.

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

O provedor cria o segmento de dados da seguinte forma:

Octet	Tipo de dados	Descrição	Valor
0	uint8	Flags de controle	0x01: pule 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 é todo zero), é válido omitir a seção de dados e enviar uma seção de dados vazia. Os flags ficam em vigor apenas até que o modo de proteção contra rastreamento indesejado seja desativado.

O provedor verifica se a chave de autenticação única fornecida corresponde à chave de proteção contra rastreamento indesejado. Se o provedor não for provisionado como um beacon FHN ou a verificação falhar, ele vai 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 MAC privado para uma vez a cada 24 horas. O identificador efêmero anunciado deve continuar mudando normalmente. O tipo de frame precisa ser definido como 0x41. O estado também é refletido na seção flags com hash.

Ao desativar o modo de proteção antirrastreamento indesejado

O provedor verifica se:

• A chave de autenticação única fornecida corresponde à chave de proteção contra rastreamento indesejado.
• A chave de identidade temporária com hash corresponde à chave de identidade temporária atual.

Se o provedor não for provisionado como um beacon FHN 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 novamente em uma taxa normal, sincronizado com a rotação do identificador efêmero. O tipo de frame precisa ser redefinido como 0x40. O estado também é refletido na seção flags com hash.

Se for bem-sucedido, o provedor vai notificar com uma resposta da tabela 6 com 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 de FHN pelo menos uma vez a cada dois segundos. Se os frames do Pareamento Rápido forem anunciados, o provedor deverá intercalar os frames do FHN nos anúncios regulares do Pareamento Rápido. Por exemplo, a cada dois segundos, o provedor precisa anunciar sete anúncios do Fast Pair e um do FHN.

A potência de transmissão Bluetooth conduzida para anúncios de FHN precisa ser definida como pelo menos 0 dBm.

O frame FHN carrega uma chave pública usada para criptografar relatórios de localização por qualquer cliente compatível que contribua para a rede de crowdsourcing. Dois tipos de chaves de curva elíptica estão disponíveis: uma chave de 160 bits que se encaixa em frames BLE 4 legados ou uma chave de 256 bits que exige BLE 5 com recursos de publicidade estendidos. A implementação do provedor determina qual curva é usada.

Um frame FHN é estruturado da seguinte forma.

Octet	Valor	Descrição
0	0x02	Comprimento
1	0x01	Valor do tipo de dados de flags
2	0x06	Dados de flags
3	0x18 ou 0x19	Comprimento
4	0x16	Valor do tipo de dados de dados de serviço
5	0xAA	UUID de serviço de 16 bits
6	0xFE	…
7	0x40 ou 0x41	Tipo de frame FHN com indicação do modo de proteção antirrastreamento indesejado
8..27		Identificador efêmero de 20 bytes
28		Flags com hash

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

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

Octet	Valor	Descrição
0	0x02	Comprimento
1	0x01	Valor do tipo de dados de flags
2	0x06	Dados de flags
3	0x24 ou 0x25	Comprimento
4	0x16	Valor do tipo de dados de dados de serviço
5	0xAA	UUID de serviço de 16 bits
6	0xFE	…
7	0x40 ou 0x41	Tipo de frame FHN com indicação do modo de proteção antirrastreamento indesejado
8..39		Identificador efêmero de 32 bytes.
40		Flags com hash

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

Cálculo do identificador efêmero (EID)

Um valor aleatório é gerado pela criptografia AES-ECB-256 da seguinte estrutura de dados com a chave de identidade temporária:

Octet	Campo	Descrição
0 - 10	Padding	Valor = 0xFF
11	K	Expoente do período de rotação
12 a 15	TS[0]...TS[3]	Contador de tempo de beacon, no formato big-endian de 32 bits. Os bits K mais baixos são limpos.
16 a 26	Padding	Value = 0x00
27	K	Expoente do período de rotação
28 - 31	TS[0]...TS[3]	Contador de tempo de beacon, no formato big-endian de 32 bits. Os bits K mais baixos são limpos.

Tabela 10:construção de um número pseudorrandômico.

O resultado dessa computação é um número de 256 bits, indicado como r'.

Para o restante do cálculo, SECP160R1 ou SECP256R1 são usados em operações criptográficas de curva elíptica. Consulte as definições de curva em SEC 2: Recommended Elliptic Curve Domain Parameters (em inglês), que define Fp, n e G referenciados a seguir.

Agora, r' é projetado para o campo finito Fp ao calcular r = r' mod n. Por fim, calcule R = r * G, que é um ponto na curva que representa a chave pública usada. O beacon anuncia Rx, que é a coordenada x de R, como identificador efêmero.

Flags com hash

O campo de flags com hash é calculado da seguinte forma (os bits são referenciados do mais significativo para o menos significativo):

• Bits 0 a 4: reservados (definidos como zeros).
• Os bits 5 a 6 indicam o nível da bateria do dispositivo da seguinte forma:
  • 00: indicação do nível da bateria não aceita
  • 01: Nível normal da bateria
  • 10: Nível da bateria baixo
  • 11: Nível de bateria criticamente baixo (é necessário substituir a bateria em breve)
• O bit 7 é definido como 1 se o beacon estiver no modo de proteção antirrastreamento indesejado e 0 caso contrário.

Para produzir o valor final desse byte, ele é XORed 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 trunque os bits mais significativos se a representação for maior que 160 ou 256 bits.

Se o beacon não for compatível com a indicação do nível da bateria e não estiver no modo de proteção contra rastreamento indesejado, será permitido omitir esse byte completamente da publicidade.

Criptografia com EID

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

1. Escolha um número aleatório s em Fp, conforme definido na seção Cálculo do EID.
2. Compute S = s * G.
3. Calcule R = (Rx, Ry) por substituição na equação da curva e escolha um valor Ry arbitrário 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. Sejam URx e LRx os 80 bits superiores e inferiores de Rx, respectivamente, no formato big-endian. Da mesma forma, defina USx e LSx para S.
6. Compute nonce = LRx || LSx.
7. Compute (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 está de posse do EIK e do expoente do período de rotação, descriptografa a mensagem da seguinte maneira:

1. Dado URx, receba o valor do contador de tempo do beacon em que URx se baseia. 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 beacon em que URx se baseia, calcule o valor previsto de r, conforme definido na seção Cálculo do EID.
3. Calcule R = r * G e verifique se há uma correspondência com o valor de URx fornecido pelo observador.
4. Calcule S = (Sx, Sy) por 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. Compute nonce = LRx || LSx.
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotação de ID

Um endereço BLE resolúvel (RPA) ou não resolúvel (NRPA) precisa ser usado para anunciar frames FHN. O RPA é obrigatório para dispositivos LE Audio (LEA) e recomendado para outros dispositivos, exceto tags de localizador que não usam vinculação.

O anúncio do Pareamento rápido, o anúncio da FHN e os endereços BLE correspondentes precisam ser alternados ao mesmo tempo. A rotação deve ocorrer 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 é definir o próximo tempo de rotação previsto (se nenhuma randomização foi aplicada) mais um fator de tempo randomizado 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 FHN precisa ser fixo, mas o RPA para anúncio não detectável de FP (como o Fast Pair) precisa continuar girando. É aceitável usar endereços diferentes para os diferentes protocolos.

Recuperação de perda de energia

A resolução do identificador efêmero está fortemente vinculada ao valor do relógio no momento do anúncio. Por isso, é importante que o provedor possa recuperar o valor do relógio em caso de perda de energia. Recomendamos que o provedor grave o valor atual do relógio na memória não volátil pelo menos uma vez por dia e que, na hora da inicialização, o provedor verifique a NVM para saber se há um valor presente para inicializar. Os resolvedores do identificador efêmero implementariam a resolução em uma janela de tempo suficiente para permitir tanto um desvio razoável do relógio quanto esse tipo de recuperação de perda de energia.

Os provedores ainda precisam fazer o possível para minimizar os desvios de relógio, já que a janela de tempo de resolução é limitada. Pelo menos um método adicional de sincronização de relógio precisa ser implementado (anunciando frames Fast Pair 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 Fast Pair em provedores que oferecem suporte ao FHN.

Diretrizes específicas da tag de localização

• Se o provedor foi pareado, mas o FHN não foi provisionado em cinco minutos (ou se uma atualização OTA foi aplicada enquanto o dispositivo estava pareado, mas não provisionado com FHN), o provedor vai reverter para a configuração de fábrica e limpar as chaves de conta armazenadas.
• Depois que o provedor for pareado, ele não poderá mudar o endereço MAC até que o FHN seja provisionado ou até que 5 minutos se passem.
• Se a chave de identidade temporária for apagada do dispositivo, ele precisará fazer uma redefinição de fábrica e limpar as chaves de conta armazenadas também.
• O provedor precisa rejeitar tentativas normais de pareamento por 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, pressionando uma combinação de botões).
• Depois de uma perda de energia, o dispositivo precisa anunciar frames de Pareamento rápido não detectáveis até a próxima invocação de read beacon parameters. Isso permite que o Seeker detecte o dispositivo e sincronize o relógio mesmo que tenha ocorrido um desvio significativo.
• Ao anunciar frames do Pareamento rápido não detectáveis, as indicações da interface não devem ser ativadas.
• Os frames do Fast Pair detectáveis não devem ser anunciados enquanto o provedor estiver provisionado para FHN.
• 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 dispositivos Bluetooth clássico

Esta seção descreve aspectos especiais dos dispositivos Bluetooth clássicos que oferecem suporte a FHN.

Provisionamento de FHN de dispositivos já pareados

O provedor nem sempre é provisionado para FHN ao parear com o Solicitante, mas um tempo 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 buscador receba o endereço BLE enquanto já está pareado:

• O provedor pode anunciar periodicamente os dados da conta do Fast Pair que permitem ao buscador encontrar o endereço BLE por uma verificação BLE.
  Essa abordagem é adequada para provedores que não implementam o stream de mensagens.
• O provedor pode fornecer esses dados pelo fluxo de mensagens do Pareamento Rápido via Bluetooth clássico.
  Essa abordagem é adequada para provedores que não anunciam frames de pareamento rápido enquanto estão conectados ao Seeker por Bluetooth.

Ao oferecer suporte às duas abordagens, aumentam as chances de o usuário provisionar o dispositivo para FHN.

Fluxo de mensagens do Pareamento Rápido

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

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

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

Quando uma atualização de firmware adiciona suporte a FHN ao provedor, um buscador conectado pode notificar o usuário sobre isso e oferecer o provisionamento. Caso contrário, o usuário precisará acessar a lista de dispositivos Bluetooth manualmente para iniciar o provisionamento da FHN.

Para permitir isso, o provedor precisa usar a propriedade "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 oferecer suporte ao protocolo que informa ao requerente sobre mudanças de capacidade 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 - 3	uint16	Duração adicional dos dados	varia
var	matriz de bytes	String da versão	varia

Tabela 11:evento de 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 de FHN, ele deverá responder conforme mostrado na tabela 12.

Octet	Tipo de dados	Descrição	Valor
0	uint8	Evento de sincronização de capacidade do dispositivo	0x06
1	uint8	Rastreamento de FHN	0x03
2 - 3	uint16	Duração adicional dos dados	0x0007
4	uint8	Estado de provisionamento do FHN	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 capacidade do dispositivo: capacidade de rastreamento adicionada.

Identificador temporário atual (código de informações do dispositivo 0x0B)

O provedor pode usar o identificador efêmero atual (código 0x0B) para informar o EID e o valor do relógio atuais quando o provedor é provisionado para FHN, para sincronizar o Seeker em caso de desvio do relógio (por exemplo, devido ao esgotamento da bateria). Caso contrário, o Seeker vai iniciar 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 efêmero atual	0x0B
2 - 3	uint16	Duração adicional dos dados	0x0018 ou 0x0024
4 - 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 que aceitam a redefinição de fábrica: se uma redefinição de fábrica for realizada, o provedor precisará interromper a transmissão de beacons e apagar a chave de identidade efêmera e todas as chaves de conta armazenadas, incluindo a chave de conta do proprietário.

Após uma redefinição de fábrica (manual ou programática), o provedor não deve começar a anunciar o Fast Pair imediatamente para evitar que o fluxo de pareamento comece imediatamente após o usuário excluir o dispositivo.

Prevenção de rastreamento indesejado

Os dispositivos FHN 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 para FHN em conformidade com a especificação DULT:

• Qualquer dispositivo compatível com FHN precisa ser registrado no console de dispositivos por perto e ter o recurso "Encontrar Hub" ativado.
• O dispositivo precisa implementar o serviço e a característica de não proprietário do acessório definidos na versão de implementação da especificação DULT, incluindo as operações de Informações do acessório e 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 corresponde ao "estado separado" definido pela especificação DULT.
• Diretrizes para implementar os opcodes de Informações do acessório:
  • Get_Product_Data precisa retornar o ID do modelo fornecido pelo console, com preenchimento de zero 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 "Localizador" se nenhuma outra categoria se adequar melhor ao tipo de dispositivo.
  • O Get_Accessory_Capabilities precisa indicar o suporte para toque e pesquisa de identificador BLE.
  • Get_Network_ID precisa retornar o identificador do Google (0x02).
• Diretrizes para implementar o opcode Get_Identifier:
  • A operação só vai retornar uma resposta válida por cinco minutos depois que o usuário ativar o modo de 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 requisito para certificação e pelo menos 10 dias antes de qualquer atualização ou modificação nas instruções.
  • A resposta é construída da seguinte forma: os primeiros 10 bytes do identificador efêmero atual, seguidos pelos primeiros 8 bytes de HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Diretrizes para implementar o identificador por NFC:
  • Como um URL, use find-my.googleapis.com/lookup.
  • Como o parâmetro e, use a mesma resposta construída para Get_Identifier, codificada em hexadecimal.
  • Como o parâmetro pid, use a mesma resposta criada para Get_Product_Data, codificada em hexadecimal.
• É obrigatório que o dispositivo inclua um dispositivo de som e ofereça suporte à função de toque. De acordo com a especificação DULT, o dispositivo precisa emitir um som com intensidade de pico mínima de 60 Phon, conforme definido pela norma ISO 532-1:2017.
• Diretrizes para implementar o opcode 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.
• Os localizadores 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 nas instruções.
  • O URL precisa ser compatível com 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

• Apenas um protocolo pode ser usado por vez. Verifique se apenas uma rede pode operar no dispositivo por vez. Esse requisito é necessário para garantir que não haja mistura de dados sensíveis do usuário entre protocolos diferentes.
• É recomendável incorporar um fluxo de trabalho de redefinição forçada ao dispositivo que permita que um 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 equitativo entre as redes. O usuário precisa poder escolher qual rede 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 para dispositivos móveis ou Web.

O Pareamento rápido oferece suporte ao envio de notificações ao usuário, informando sobre atualizações OTA disponíveis. Para usar esse mecanismo:

• A versão mais recente do firmware precisa ser atualizada no console de dispositivos próximos.
• Um app complementar precisa ser definido no console de dispositivos por perto. Ele precisa oferecer suporte à intenção de atualização de firmware.
• O provedor precisa implementar a característica GATT Revisão de firmware.

Para evitar o rastreamento, o acesso à característica Revisão de firmware precisa ser restrito. O Seeker primeiro lê o estado de provisionamento e fornece uma chave de autenticação, conforme definido nesta especificação, e só então lê a revisão do firmware. Isso será feito na mesma conexão. Se uma tentativa for feita para ler a revisão do firmware, e o provedor não estiver vinculado nem uma operação autenticada tiver sido concluída com êxito na mesma conexão, o provedor vai retornar um erro não autenticado.

Compatibilidade

Para usar a rede do Localizador, ative os Serviços de localização e o Bluetooth. É preciso ter uma rede celular ou uma conexão de Internet. Funciona no Android 9 e mais recentes em alguns países para usuários de idades adequadas.

Registro de alterações

Versão do FHN	Data	Comentário
v1		Lançamento inicial da especificação FHN para acesso antecipado.
v1.1	Feb 2023	Adicionamos uma indicação em texto simples do modo de proteção contra rastreamento indesejado. Adicionamos uma opção para ignorar 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 de uma AK de proprietário. Adicionamos uma recomendação para recuperação de perda de energia em tags de localizador. Adicionamos um esclarecimento sobre a randomização de endereço MAC. Adicionamos um esclarecimento sobre a rotação de endereço MAC no modo de proteção contra rastreamento indesejado. Adicionamos uma diretriz 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. Adicionamos um requisito para implementar a especificação de prevenção de rastreamento indesejado. Adição de diretrizes para dispositivos de protocolo comutável.