Найти спецификацию сетевого аксессуара концентратора,Найти спецификацию сетевого аксессуара концентратора,Найти спецификацию сетевого аксессуара концентратора,Найти спецификацию сетевого аксессуара концентратора

версия 1.3

Спецификация аксессуаров Find Hub Network (FHN) определяет сквозной шифрованный подход к отслеживанию маяковых устройств Bluetooth Low Energy (BLE). На этой странице FHN описывается как расширение спецификации Fast Pair. Поставщикам следует включить это расширение, если у них есть устройства, совместимые с FHN, и они готовы включить отслеживание местоположения для этих устройств.

Спецификация ГАТТ

В службу Fast Pair Service следует добавить дополнительную характеристику общих атрибутов (GATT) со следующей семантикой:

Таблица 1: Характеристики быстрой парной службы для FHN.

Аутентификация

Операции, требуемые этим расширением, выполняются как операция записи, защищённая механизмом «запрос-ответ». Перед выполнением любой операции Искатель должен выполнить операцию чтения из характеристики, представленной в таблице 1, что приводит к созданию буфера следующего формата:

Каждая операция чтения должна приводить к созданию нового одноразового значения, и одно одноразовое значение должно быть допустимо только для одной операции. Одноразовое значение должно быть аннулировано даже в случае сбоя операции.

Затем Искатель вычисляет одноразовый ключ аутентификации, который будет использоваться в последующем запросе на запись. Ключ аутентификации рассчитывается, как описано в таблицах 2–5. В зависимости от запрашиваемой операции Искатель подтверждает знание одного или нескольких из следующих ключей:

• Ключ учетной записи : 16-байтовый ключ учетной записи Fast Pair, как определено в спецификации Fast Pair.

• Ключ учётной записи владельца : Поставщик выбирает один из существующих ключей учётной записи в качестве ключа учётной записи владельца при первом доступе Искателя к характеристике «Действия маяка». Выбранный ключ учётной записи владельца не может быть изменён до тех пор, пока Поставщик не сбросит настройки до заводских. Поставщик не должен удалять ключ учётной записи владельца, если у него закончились свободные слоты для ключей.

  • Поставщики, которые уже поддерживают FHN при первом сопряжении (или поддерживают его при сопряжении после сброса настроек к заводским), выбирают первый ключ учетной записи, поскольку это единственный существующий ключ учетной записи, когда Seeker считывает состояние подготовки во время сопряжения.

  • Провайдеры, получающие поддержку FHN после того, как они уже подключены (например, через обновление прошивки), могут выбрать любой существующий ключ учётной записи. Разумно выбрать первый ключ учётной записи, который будет использоваться для считывания состояния подготовки из характеристики действий маяка после обновления прошивки, предполагая, что пользователь, выполнивший обновление, является текущим владельцем провайдера.

• Эфемерный ключ идентификации (EIK) : 32-байтовый ключ, выбираемый Искателем случайным образом при выполнении процесса подготовки FHN. Этот ключ используется для получения криптографических ключей, используемых для сквозного шифрования отчётов о местоположении. Искатель никогда не раскрывает его серверной части.

• Ключ восстановления : определяется как SHA256(ephemeral identity key || 0x01) , усеченный до первых 8 байт. Ключ хранится на сервере, и Искатель может использовать его для восстановления EIK , если пользователь выразит согласие, нажав кнопку на устройстве.

• Ключ звонка : определяется как SHA256(ephemeral identity key || 0x02) , усеченный до первых 8 байт. Ключ хранится на сервере, и Seeker может использовать его только для звонка на устройство.

• Ключ защиты от нежелательного отслеживания : определяется как SHA256(ephemeral identity key || 0x03) , усеченный до первых 8 байт. Ключ хранится на сервере, и Seeker может использовать его только для активации режима защиты от нежелательного отслеживания .

Операции

Формат данных, записываемых в характеристику, приведен в таблицах 2–5. Каждая из операций более подробно обсуждается далее в этом разделе.

Таблица 2: Запрос на предоставление маяка.

Таблица 3: Запрос на восстановление ключа предоставления маяка.

Таблица 4: Запрос на звонок.

Таблица 5: Запрос на защиту от нежелательного отслеживания.

Успешные записи вызывают уведомления, как указано в таблице 6.

Уведомления с идентификатором данных, отличным от 0x05: изменение состояния кольца должно быть отправлено до завершения транзакции записи, которая запускает уведомление, то есть до отправки ответного PDU для запроса записи.

Таблица 6: Ответ службы маяка.

В таблице 7 перечислены возможные коды ошибок GATT, возвращаемые операциями.

Таблица 7: Коды ошибок ГАТТ.

Прочитать параметр маяка

Искатель может запросить у Поставщика параметры маяка, выполнив операцию записи в характеристику, состоящую из запроса из таблицы 2 с идентификатором данных 0x00. Поставщик проверяет, соответствует ли предоставленный одноразовый ключ аутентификации любому из ключей учётной записи, хранящихся на устройстве.

Если проверка не пройдена, провайдер возвращает ошибку отсутствия аутентификации.

В случае успешного выполнения провайдер отправляет ответ из таблицы 6 с идентификатором данных 0x00. Провайдер формирует сегмент данных следующим образом:

Данные должны быть зашифрованы по алгоритму AES-ECB-128 с использованием ключа учетной записи, используемого для аутентификации запроса.

Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01) .

Прочитать состояние подготовки маяка

Искатель может запросить у Поставщика информацию о состоянии подготовки маяка, выполнив операцию записи в характеристику, состоящую из запроса из таблицы 2 с идентификатором данных 0x01. Поставщик проверяет, соответствует ли предоставленный одноразовый ключ аутентификации любому из ключей учётной записи, хранящихся на устройстве.

Если проверка не пройдена, провайдер возвращает ошибку отсутствия аутентификации.

В случае успешного выполнения провайдер уведомляет об этом ответом из таблицы 6 с идентификатором данных 0x01. Провайдер формирует сегмент данных следующим образом:

Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) .

Установить временный ключ идентификации

Чтобы предоставить неподготовленному поставщику доступ в качестве маяка FHN или изменить временный ключ идентификации уже подготовленного поставщика, Искатель выполняет операцию записи в характеристику, состоящую из запроса из таблицы 2 с идентификатором данных 0x02. Поставщик проверяет, что:

• Предоставленный одноразовый ключ аутентификации совпадает с ключом учетной записи владельца.
• Если был предоставлен хэш эфемерного ключа идентификации, хэшированный эфемерный ключ идентификации соответствует текущему эфемерному ключу идентификации.
• Если хэш эфемерного ключа идентификации не был предоставлен, проверьте, не был ли поставщик еще предоставлен в качестве маяка FHN.

Если проверка не пройдена, провайдер возвращает ошибку отсутствия аутентификации.

В случае успешного выполнения кратковременный ключ идентификации восстанавливается с помощью алгоритма AES-ECB-128, расшифровывая его с использованием соответствующего ключа учётной записи. Ключ должен быть сохранён на устройстве, и с этого момента провайдер должен начать анонсировать кадры FHN. Новый кратковременный ключ идентификации вступает в силу сразу после завершения соединения BLE. Провайдер уведомляет об этом ответом из таблицы 6 с идентификатором данных 0x02.

Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) .

Очистить эфемерный ключ идентификации

Чтобы отменить выделение маяковой части Поставщика, Искатель выполняет операцию записи в характеристику, состоящую из запроса из таблицы 2 с идентификатором данных 0x03. Поставщик проверяет, что:

• Предоставленный одноразовый ключ аутентификации совпадает с ключом учетной записи владельца.
• Хешированный эфемерный ключ идентификации соответствует текущему эфемерному ключу идентификации.

Если поставщик не настроен как маяк FHN или проверка не пройдена, возвращается ошибка отсутствия аутентификации.

В случае успеха провайдер забывает ключ и прекращает рассылку кадров FHN. Провайдер уведомляет ответом из таблицы 6 с идентификатором данных 0x03. Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) .

Считывание эфемерного ключа идентификации с согласия пользователя

Эта возможность доступна только для восстановления утерянного ключа, поскольку он хранится локально в Seeker. Таким образом, эта возможность доступна только когда устройство находится в режиме сопряжения или в течение ограниченного времени после нажатия физической кнопки на устройстве (что является согласием пользователя).

Искатель должен хранить ключ восстановления на бэкэнде, чтобы иметь возможность восстановить открытый текстовый ключ, но он не хранит сам EIK.

Для чтения EIK Искатель выполняет операцию записи в характеристику, состоящую из запроса из таблицы 3 с идентификатором данных 0x04. Поставщик проверяет, что:

• Хешированный ключ восстановления совпадает с ожидаемым ключом восстановления.
• Устройство находится в режиме восстановления EIK.

Если проверка не пройдена, провайдер возвращает ошибку отсутствия аутентификации.

Если устройство не находится в режиме сопряжения, поставщик возвращает ошибку «Нет согласия пользователя».

В случае успеха провайдер уведомляет ответом из таблицы 6 с идентификатором данных 0x04.

Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) .

Кольцевая операция

Искатель может запросить у Поставщика воспроизведение звука, выполнив операцию записи в характеристику, состоящую из запроса из таблицы 4 с идентификатором данных 0x05. Поставщик формирует сегмент данных следующим образом:

Получив запрос, Поставщик проверяет, что:

• Предоставленный одноразовый ключ аутентификации совпадает с кольцевым ключом.
• Запрошенное состояние соответствует компонентам, которые могут звонить.

Если провайдер не настроен как маяк FHN или проверка не пройдена, возвращается ошибка отсутствия аутентификации. Однако, если у провайдера активирована защита от нежелательного отслеживания, и в запросе на защиту от нежелательного отслеживания был включён флаг аутентификации с пропуском звонка, провайдер должен пропустить эту проверку. Ожидается, что данные аутентификации будут предоставлены Seeker, но им может быть присвоено произвольное значение.

При начале или завершении звонка отправляется уведомление, как указано в таблице 6, с идентификатором данных 0x05. Содержание уведомления определяется следующим образом:

Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01) .

Если устройство уже находится в запрошенном состоянии звонка при получении запроса на звонок или его прекращение, провайдер должен отправить уведомление с состоянием звонка или кодом 0x00: Started (запрос GATT) или 0x04: Stopped (запрос GATT) соответственно. Этот запрос переопределяет параметры текущего состояния, что позволяет увеличить длительность звонка.

Если у провайдера имеется физическая кнопка (или включена сенсорная функция), нажатие этой кнопки должно остановить функцию звонка во время активности звонка.

Получить состояние звонка маяка

Чтобы получить состояние вызова маяка, Искатель выполняет операцию записи в характеристику, состоящую из запроса из таблицы 4 с идентификатором данных 0x06. Поставщик проверяет, что предоставленный одноразовый ключ аутентификации соответствует ключу вызова.

Если поставщик не настроен как маяк FHN или проверка не пройдена, поставщик возвращает ошибку отсутствия аутентификации.

В случае успешного выполнения провайдер уведомляет об этом ответом из таблицы 6 с идентификатором данных 0x06. Провайдер формирует сегмент данных следующим образом:

Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) .

Режим защиты от нежелательного отслеживания

Режим защиты от нежелательного отслеживания предназначен для того, чтобы любой клиент мог идентифицировать вредоносные устройства без подключения к серверу. По умолчанию провайдер должен выполнять ротацию всех идентификаторов, как описано в разделе «Ротация идентификаторов» . Служба Find Hub может ретранслировать запрос на активацию режима защиты от нежелательного отслеживания через сеть Find Hub. При этом служба заставляет провайдера временно использовать фиксированный MAC-адрес, что позволяет клиентам обнаруживать устройства и предупреждать пользователей о возможном нежелательном отслеживании.

Для активации или деактивации режима защиты от нежелательного слежения маяка Искатель выполняет операцию записи в характеристику, состоящую из запроса из таблицы 5 с идентификатором данных 0x07 или 0x08 соответственно.

При включении режима защиты от нежелательного отслеживания

Поставщик конструирует сегмент данных следующим образом:

Поставщик проверяет, соответствует ли предоставленный одноразовый ключ аутентификации ключу защиты от нежелательного отслеживания. Если поставщик не настроен как маяк FHN или проверка не пройдена, возвращается ошибка отсутствия аутентификации.

При активации режима защиты от нежелательного отслеживания маяк должен снизить частоту ротации частного MAC-адреса до одного раза в 24 часа. Объявленный эфемерный идентификатор должен продолжать ротацию в обычном режиме. Тип кадра должен быть установлен на 0x41. Состояние также отражается в разделе хэшированных флагов .

При отключении режима защиты от нежелательного отслеживания

Поставщик подтверждает, что:

• Предоставленный одноразовый ключ аутентификации совпадает с ключом защиты от нежелательного отслеживания.
• Хешированный эфемерный ключ идентификации соответствует текущему эфемерному ключу идентификации.

Если поставщик не настроен как маяк FHN или проверка не пройдена, поставщик возвращает ошибку отсутствия аутентификации.

После отключения режима защиты от нежелательного отслеживания маяк должен снова начать ротацию MAC-адреса с обычной частотой, синхронизированной с ротацией эфемерных идентификаторов. Тип кадра должен быть сброшен до 0x40. Состояние также отражается в разделе хэшированных флагов .

В случае успеха провайдер уведомляет ответом из таблицы 6 с идентификатором данных 0x07 или 0x08.

Сегмент аутентификации определяется как первые 8 байтов HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) .

Рекламируемые рамки

После настройки провайдер должен анонсировать кадры FHN не реже одного раза в 2 секунды. При анонсировании кадров Fast Pair провайдер должен чередовать кадры FHN с обычными объявлениями Fast Pair. Например, каждые две секунды провайдер должен анонсировать семь объявлений Fast Pair и одно объявление FHN.

Мощность передаваемого сигнала Bluetooth для рекламы FHN должна быть установлена ​​на уровне не менее 0 дБм.

Кадр FHN содержит открытый ключ, используемый для шифрования отчётов о местоположении любым поддерживающим клиентом, участвующим в краудсорсинговой сети. Доступны два типа ключей на основе эллиптических кривых: 160-битный ключ, подходящий для устаревших кадров BLE 4, или 256-битный ключ, требующий BLE 5 с расширенными возможностями рекламы. Реализация провайдера определяет, какая кривая будет использоваться.

Кадр FHN имеет следующую структуру.

Таблица 8: Кадр FHN, поддерживающий 160-битную кривую.

В таблице 9 показаны смещения байтов и значения для 256-битной кривой.

Таблица 9: Кадр FHN, поддерживающий 256-битную кривую.

Вычисление эфемерного идентификатора (EID)

Случайный код генерируется с помощью алгоритма AES-ECB-256, шифрующего следующую структуру данных с помощью эфемерного ключа идентификации:

Таблица 10: Построение псевдослучайного числа.

Результатом этого вычисления является 256-битное число, обозначаемое r' .

Для остальной части вычислений для криптографических операций на эллиптических кривых используются SECP160R1 или SECP256R1 . См. определения кривых в разделе SEC 2: Рекомендуемые параметры домена эллиптических кривых , где определены Fp , n и G упомянутые далее.

Теперь r' проецируется в конечное поле Fp путём вычисления r = r' mod n . Наконец, вычисляется R = r * G , что является точкой на кривой, представляющей используемый открытый ключ. Маяк объявляет Rx , то есть x координату R , в качестве своего эфемерного идентификатора.

Хешированные флаги

Поле хешированных флагов рассчитывается следующим образом (биты нумеруются от наиболее значимых к наименее значимым):

• Биты 0-4: зарезервированы (установлены на нули).
• Биты 5-6 показывают уровень заряда батареи устройства следующим образом:
  • 00: Индикация уровня заряда батареи не поддерживается
  • 01: Нормальный уровень заряда батареи
  • 10: Низкий уровень заряда батареи
  • 11: Критически низкий уровень заряда батареи (скоро потребуется замена батареи)
• Бит 7 устанавливается в 1, если маяк находится в режиме защиты от нежелательного слежения, и в 0 в противном случае.

Для получения окончательного значения этого байта он подвергается операции xor с наименее значимым байтом SHA256(r) .

Обратите внимание, что r должно быть выровнено с размером кривой. Добавьте нули в качестве старших битов, если представление короче 160 или 256 бит, или усеките старшие биты, если представление длиннее 160 или 256 бит.

Если маяк не поддерживает индикацию уровня заряда батареи и не находится в режиме защиты от нежелательного слежения, разрешается полностью исключить этот байт из объявления.

Шифрование с EID

Чтобы зашифровать сообщение m , наблюдатель (прочитавший Rx с маяка) должен сделать следующее:

1. Выберите случайное число s в Fp , как определено в разделе вычисления EID .
2. Вычислите S = s * G
3. Вычислите R = (Rx, Ry) путем подстановки в уравнение кривой и выбора произвольного значения Ry из возможных результатов.
4. Вычислите 256-битный ключ AES k = HKDF-SHA256((s * R)x) где (s * R)x — координата x результата умножения кривой. Соль не указана.
5. Пусть URx и LRx — старшие и младшие 80 бит Rx соответственно в формате big-endian. Аналогичным образом определим USx и LSx для S
6. Вычислить nonce = LRx || LSx .
7. Вычислить (m', tag) = AES-EAX-256-ENC(k, nonce, m) .
8. Отправьте (URx, Sx, m', tag) владельцу, возможно, через ненадежный удаленный сервис.

Расшифровка значений, зашифрованных с помощью EID

Клиент владельца, обладающий EIK и показателем периода вращения, расшифровывает сообщение следующим образом:

1. По заданному URx получить значение счётчика времени маяка, на котором основан URx . Это может сделать клиент владельца, вычислив значения Rx для счётчиков времени маяка за недавнее прошлое и ближайшее будущее.
2. Учитывая значение счетчика времени маяка, на котором основан URx , вычислите ожидаемое значение r , как определено в разделе вычисления EID .
3. Вычислите R = r * G и проверьте соответствие значению URx , предоставленному визиром.
4. Вычислите S = (Sx, Sy) путем подстановки в уравнение кривой и выбора произвольного значения Sy из возможных результатов.
5. Вычислить k = HKDF-SHA256((r * S)x) где (r * S)x — координата x результата умножения кривой.
6. Вычислить nonce = LRx || LSx .
7. Вычислить m = AES-EAX-256-DEC(k, nonce, m', tag) .

ротация идентификаторов

Для объявления кадров FHN необходимо использовать разрешаемый (RPA) или неразрешимый (NRPA) адрес BLE. RPA требуется для устройств LE Audio (LEA) и рекомендуется для других устройств, за исключением меток локатора, не использующих связывание.

Объявление Fast Pair, объявление FHN и соответствующие адреса BLE должны чередоваться одновременно. В среднем ротация должна происходить каждые 1024 секунды. Точная точка начала объявления маяком нового идентификатора должна быть рандомизирована в пределах окна.

Рекомендуемый подход к рандомизации времени вращения заключается в установке его на уровне следующего ожидаемого времени вращения (если рандомизация не применялась) плюс положительный рандомизированный временной фактор в диапазоне от 1 до 204 секунд.

Когда устройство находится в режиме защиты от нежелательного отслеживания, адрес BLE для объявления FHN должен быть фиксированным, но RPA для необнаруживаемого объявления FP (например, Fast Pair) должен постоянно меняться. Допустимо использовать разные адреса для разных протоколов.

Восстановление после потери мощности

Разрешение эфемерного идентификатора тесно связано со значением его тактовой частоты на момент объявления, поэтому важно, чтобы поставщик мог восстановить его значение в случае отключения питания. Рекомендуется, чтобы поставщик записывал текущее значение тактовой частоты в энергонезависимую память не реже одного раза в день, а при загрузке проверял энергонезависимую память на наличие значения, с которого можно инициализироваться. Резолверы эфемерного идентификатора должны реализовывать разрешение в течение временного окна, достаточного для обеспечения как приемлемого дрейфа тактовой частоты, так и такого типа восстановления после отключения питания.

Поставщики по-прежнему должны прилагать все усилия для минимизации дрейфа часов, поскольку временной интервал разрешения ограничен. Следует реализовать как минимум один дополнительный метод синхронизации часов (объявление необнаруживаемых кадров Fast Pair или реализация потока сообщений ).

Руководство по внедрению Fast Pair

В этом разделе описываются особенности реализации Fast Pair у провайдеров, поддерживающих FHN.

Специальные рекомендации по тегам локаторов

• Если провайдер был сопряжен, но FHN не был инициализирован в течение 5 минут (или если обновление OTA было применено, когда устройство было сопряжено, но не инициализировано FHN), провайдер должен вернуться к заводской конфигурации и очистить сохраненные ключи учетной записи.
• После сопряжения провайдера MAC-адрес не должен меняться до тех пор, пока не будет предоставлен FHN или пока не пройдет 5 минут.
• Если временный ключ идентификации удален с устройства, следует выполнить сброс настроек устройства к заводским настройкам и удалить сохраненные ключи учетной записи.
• Провайдер должен отклонять обычные попытки сопряжения Bluetooth и принимать только быстрое сопряжение.
• Поставщик должен включить механизм, позволяющий пользователям временно останавливать рекламу без сброса настроек устройства к заводским настройкам (например, нажатием комбинации кнопок).
• После отключения питания устройство должно передавать необнаруживаемые кадры Fast Pair до следующего вызова функции чтения параметров маяка . Это позволяет Seeker обнаружить устройство и синхронизировать часы даже при значительном дрейфе часов.
• При объявлении необнаруживаемых кадров Fast Pair индикация пользовательского интерфейса не должна быть включена.
• Обнаруживаемые кадры Fast Pair не следует объявлять, пока поставщик настроен на FHN.
• Поставщик не должен раскрывать какую-либо идентифицирующую информацию неаутентифицированным образом (например, имена или идентификаторы).

Классические рекомендации по устройствам Bluetooth

В этом разделе описываются особенности классических Bluetooth-устройств, поддерживающих FHN.

Предоставление FHN уже сопряженных устройств

Поставщик не всегда подключается к FHN при сопряжении с Seeker, но через некоторое время после этого. В этом случае у поставщика может не быть актуального MAC-адреса BLE, необходимого для установления соединения GATT. Поставщик должен поддерживать по крайней мере один из следующих способов, чтобы Seeker мог получить свой адрес BLE, пока он уже подключен:

• Поставщик может периодически объявлять данные учетной записи Fast Pair , что позволяет Искателю найти свой адрес BLE посредством сканирования BLE.
  Этот подход подходит провайдерам, которые не реализуют поток сообщений.
• Провайдер может предоставить эти данные через поток сообщений Fast Pair через классический Bluetooth.
  Этот подход подходит провайдерам, которые не объявляют кадры Fast Pair при подключении к Seeker через Bluetooth.

Поддержка обоих подходов увеличивает вероятность того, что пользователь сможет подготовить устройство для FHN.

Поток сообщений быстрого соединения

Провайдер может реализовать поток сообщений Fast Pair и использовать его для уведомления Искателя об информации об Устройстве . Реализация потока сообщений обеспечивает определенные функции, описанные в этом разделе.

Поставщик должен отправлять информационные сообщения об устройстве один раз при каждом установлении канала RFCOMM потока сообщений.

Версия прошивки (информационный код устройства 0x09) и возможность отслеживания

Когда обновление прошивки добавляет поддержку FHN к поставщику, подключенный Seeker может уведомить об этом пользователя и предложить его предоставить. В противном случае пользователю придется вручную перейти к списку устройств Bluetooth, чтобы инициировать настройку FHN.

Чтобы разрешить это, поставщик должен использовать свойство версии встроенного ПО (код 0x09), чтобы сообщить строковое значение, представляющее версию встроенного ПО. Кроме того, Поставщик должен поддерживать протокол, который позволяет Искателю узнать об изменениях Возможностей вследствие обновлений встроенного ПО.

Таблица 11. Событие с информацией об устройстве: обновленная версия встроенного ПО.

При получении запроса на обновление возможностей (0x0601), если поставщик включил поддержку отслеживания FHN, он должен ответить, как показано в таблице 12.

Таблица 12. Событие синхронизации возможностей устройства: добавлена ​​возможность отслеживания.

Текущий эфемерный идентификатор (информационный код устройства 0x0B)

Поставщик может использовать текущий эфемерный идентификатор (код 0x0B) для сообщения текущего EID и значения часов, когда поставщик предоставляется для FHN, для синхронизации Seeker в случае отклонения часов (например, из-за разряженной батареи). В противном случае Искатель инициирует для этой цели более дорогое и менее надежное соединение.

Таблица 13. Событие с информацией об устройстве: синхронизация часов.

Сброс к заводским настройкам

Для устройств, поддерживающих сброс настроек к заводским настройкам: если выполнен сброс к заводским настройкам, Поставщик должен прекратить передачу сигналов и удалить эфемерный идентификационный ключ и все сохраненные ключи учетной записи, включая ключ учетной записи владельца.

После сброса настроек (ручного или программного) поставщику не следует сразу же начинать рекламировать быстрое соединение, чтобы предотвратить запуск процесса сопряжения сразу после того, как пользователь удалит устройство.

Предотвращение нежелательного отслеживания

Сертифицированные устройства FHN также должны соответствовать требованиям версии реализации кросс-платформенной спецификации по обнаружению нежелательных средств отслеживания местоположения (DULT).

Соответствующие рекомендации, относящиеся к FHN, для обеспечения соответствия спецификации DULT:

• Любое устройство, совместимое с FHN, должно быть зарегистрировано в консоли ближайших устройств и иметь активированную функцию «Найти концентратор».
• Устройство должно реализовывать службу и характеристики аксессуара, не являющегося владельцем, определенные в версии реализации спецификации DULT, включая операции с информацией об аксессуарах и элементы управления, не принадлежащие владельцу .
• В течение периода обратной совместимости, как определено в спецификации DULT, в объявленном кадре, как определено в этом документе, не происходит никаких изменений.
• «Режим защиты от нежелательного отслеживания», определенный в этом документе, соответствует «разделенному состоянию», определенному спецификацией DULT.
• Рекомендации по реализации кодов операций с вспомогательной информацией :
  • Get_Product_Data должен возвращать идентификатор модели, предоставленный консолью, дополненный нулями, чтобы соответствовать требованию в 8 байт. Например, идентификатор модели 0xFFFFFF возвращается как 0x0000000000FFFFFF.
  • Get_Manufacturer_Name и Get_Model_Name должны соответствовать значениям, указанным в консоли.
  • Get_Accessory_Category может возвращать общее значение «Отслеживание местоположения», если никакая другая категория лучше не соответствует типу устройства.
  • Get_Accessory_Capabilities должен указывать на поддержку звонков, а также поиск идентификатора BLE.
  • Get_Network_ID должен возвращать идентификатор Google (0x02).
• Рекомендации по реализации кода операции Get_Identifier :
  • Операция должна возвращать действительный ответ только в течение 5 минут после того, как пользователь активировал режим «идентификации», для которого требуется комбинация нажатий кнопок. Визуальный или звуковой сигнал должен указать пользователю, что провайдер перешел в данный режим. Инструкции по активации этого режима для конкретной модели должны быть предоставлены Google в качестве требования для сертификации не менее чем за 10 дней до любого обновления или изменения инструкций.
  • Ответ строится как: первые 10 байт текущего эфемерного идентификатора, за которыми следуют первые 8 байтов HMAC-SHA256(recovery key, the truncated current ephemeral identifier) .
• Рекомендации по реализации идентификатора через NFC:
  • В качестве URL-адреса используйте find-my.googleapis.com/lookup .
  • В качестве параметра e используйте тот же ответ, который создан для Get_Identifier в шестнадцатеричном кодировании.
  • В качестве параметра pid используйте тот же ответ, который создан для Get_Product_Data , в шестнадцатеричном кодировании.
• Устройство обязательно должно иметь звуковой генератор и поддерживать функцию звонка. Согласно спецификации DULT, звукорежиссер должен издавать звук с пиковой громкостью не менее 60 Phon, как определено стандартом ISO 532-1:2017.
• Рекомендации по реализации кода операции Sound_Start :
  • Команда должна вызвать вызывной сигнал во всех доступных компонентах.
  • Следует использовать максимальный поддерживаемый объем.
  • Рекомендуемая продолжительность звонка – 12 секунд.
• Теги локатора должны включать в себя механизм, позволяющий пользователям временно прекращать рекламу без сброса настроек устройства (например, нажатия комбинации кнопок).
  • Инструкции по отключению должны быть задокументированы в общедоступном URL-адресе и предоставлены Google в качестве требования для сертификации не менее чем за 10 дней до любого обновления или изменения инструкций.
  • URL-адрес должен поддерживать локализацию. В зависимости от клиента язык будет указан либо как параметр запроса («hl=en»), либо с использованием HTTP-заголовка «accept-language».

Рекомендации по переключаемому протоколу

• Одновременно следует использовать только один протокол. Убедитесь, что на устройстве одновременно может работать не более одной сети. Это требование необходимо для того, чтобы гарантировать отсутствие смешивания конфиденциальных пользовательских данных между различными протоколами.
• Предлагается включить в устройство рабочий процесс аппаратного сброса, который позволит пользователю повторно настроить устройство для работы в другой сети.
• Процесс обновления устройства в сети должен быть удобным для пользователя и справедливым для разных сетей. Пользователь должен иметь возможность выбирать, какую сеть он хочет использовать, не отдавая предпочтения одной из сетей. Этот процесс должен быть одобрен командой Google.

Обновления прошивки

Процессом и распространением OTA-обновлений должен управлять партнер, используя собственный рабочий процесс мобильного или веб-приложения.

Fast Pair поддерживает доставку уведомлений пользователю, информирующих о доступных OTA-обновлениях. Чтобы использовать этот механизм:

• Последняя версия прошивки должна быть обновлена ​​в консоли близлежащего устройства.
• Сопутствующее приложение должно быть установлено в консоли близлежащего устройства. Он должен поддерживать намерение обновления прошивки .
• Поставщик должен реализовать характеристику версии прошивки GATT.

Чтобы предотвратить отслеживание, доступ к характеристике версии прошивки должен быть ограничен. Seeker сначала прочитает состояние подготовки и предоставит ключ аутентификации, как определено в этой спецификации, и только затем прочитает версию встроенного ПО. Это будет сделано через то же соединение. Если предпринята попытка прочитать версию встроенного ПО, а поставщик не подключен и операция аутентификации не была успешно завершена через то же соединение, поставщик должен вернуть неаутентифицированную ошибку.

Совместимость

Для работы сети Find Hub необходимо включить службы определения местоположения и Bluetooth. Требуется сотовая связь или подключение к Интернету. Работает на Android 9+ и в некоторых странах для пользователей соответствующего возраста.

Журнал изменений