Характеристики

Служба быстрого сопряжения

Поставщик быстрого соединения должен иметь следующую услугу GATT.

Эта услуга должна иметь следующие характеристики.

Информационная служба устройства

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

Fast Pair Seeker использует следующие характеристики.

Характеристика: Идентификатор модели

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

Характеристика: Сопряжение на основе ключей

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

• Случай 1: Предварительный общий ключ основан на паре открытого/закрытого ключей защиты от спуфинга и собственной паре открытого/закрытого ключей Искателя, которая будет меняться при каждой попытке соединения.

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

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

• Случай 2: Общий ключ является одним из ключей учетной записи .

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

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

Формат данных

См. процедуру использования каждого формата.

Таблица 1.1: Зашифрованный запрос, записанный в характеристику Искателем.

Таблица 1.2.1: Необработанный запрос (тип 0x00). Расшифровано из зашифрованного запроса в таблице 1.1 .

Таблица 1.2.2: Необработанный запрос (тип 0x10). Расшифровано из зашифрованного запроса в таблице 1.1 .

Таблица 1.3: Необработанный ответ. Зашифровано для получения зашифрованного ответа в таблице 1.4 .

Таблица 1.4: Зашифрованный ответ, отправленный Поставщиком Искателю через уведомление.

Характеристика: Ключ доступа

Эта характеристика используется во время процедуры сопряжения на основе ключа .

Таблица 2.1: Зашифрованный блок ключа доступа. См. процедуру сопряжения на основе ключей.

Таблица 2.2: Блок необработанного ключа доступа. Расшифрованная версия Таблицы 2.1 .

Характеристика: Ключ учетной записи

После сопряжения искатель быстрого сопряжения запишет ключ учетной записи поставщику быстрого сопряжения.

После получения запроса на запись поставщик быстрого соединения должен сделать следующее:

1. Расшифруйте ключ учетной записи, используя общий секрет, созданный на шаге 4 процедуры .
   • Для провайдеров, которым требуется соединение (обычное):
     • Перед расшифровкой убедитесь, что общий секрет использовался для расшифровки запроса ключа доступа, полученного на шаге 12. Если этот шаг не был пройден с использованием этого секрета, проигнорируйте эту запись и выйдите.
   • На этом этапе общий секрет ( K в процедуре) больше не будет использоваться для этого соединения. Любые запросы, которые поступают зашифрованными с помощью этого ключа без перезапуска процедуры, должны быть отклонены.
2. Убедитесь, что расшифрованное значение начинается с 0x04 . Если это не так, проигнорируйте эту запись и выйдите.
3. Проверьте, есть ли в сохраненном списке ключей учетной записи место для нового значения.
4. Если нет, удалите из списка последнее использованное значение.
5. Добавьте новое значение в список.

Ключи учетной записи в списке используются во время сопряжения на основе ключей .

Характеристика: Версия прошивки

Эта характеристика позволяет Искателю считывать версию прошивки Провайдера по мере необходимости. Он всегда должен возвращать следующие данные:

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

1. status-updating : если провайдер в данный момент обновляется до новой прошивки. Альтернативно, Поставщик может вернуть версию установленной прошивки.

2. status-abnormal : если Провайдер находится в ненормальном состоянии. Например, он неисправен из-за сбоя обновления прошивки. Это значение приведет к тому, что Seeker покажет сообщение, сообщающее пользователю, что его необходимо обновить сейчас.

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

• подключенные устройства должны иметь доступ в любое время
• любое устройство должно иметь доступ, когда поставщик доступен для обнаружения

Характеристика: Дополнительные данные

Эта услуга должна иметь следующую характеристику.

Прежде чем писать или уведомлять эту характеристику, необходимо выполнить подтверждение связи через характеристику FE2C1234-8366-4814-8EB0-01DE32100BEA , чтобы иметь общий секрет. AES-CTR будет использоваться для шифрования данных, проходящих через эту характеристику, алгоритм которой определен ниже. Этот режим более безопасен для данных, выходящих за рамки одного 16-байтового блока. HMAC-SHA256 будет использоваться для обеспечения целостности данных, что также определено ниже.

Таблица 3.1: Пакет данных, отправленный Поставщиком Искателю через уведомление или отправленный Искателем Поставщику посредством записи.

Таблица 3.2: Исходные данные. Расшифровано из зашифрованных данных в таблице 3.1 .

Когда запрашивается уведомление (например, запросить персонализированное имя через бит 2 в таблице 1.2.1 ), поставщик быстрого соединения должен сделать следующее:

1. Сгенерируйте криптографически случайные 8 байтов для Nonce.

2. Зашифруйте данные с помощью AES-CTR, где каждый 16-байтовый блок генерируется с использованием

   encryptedBlock[i] = clearBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))
   

   где

   1. Ключ AES — это общий секрет, полученный на этапе 4 процедуры .
   2. ClearBlock[i] — это 16-байтовый блок, начинающийся с data[i * 16]. Последний блок может быть меньше 16 байт.

3. Выполните concat(encryptedBlock[0], EncryptedBlock[1],...) для создания зашифрованных данных.

4. Создать HMAC-SHA256 с помощью

   sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, encrypted_data)))))
   

   где

   1. K генерируется с помощью concat(shared_secret, 48-байтовые НУЛИ), общий_секрет берется из шага 4 процедуры .
   2. opad — это внешнее заполнение размером 64 байта, состоящее из повторяющихся байтов со значением 0x5C .
   3. ipad — это внутреннее заполнение размером 64 байта, состоящее из повторяющихся байтов со значением 0x36 .

5. Возьмите первые 8 байт из HMAC-SHA256 в качестве префикса пакета данных .

После получения запроса на запись поставщик быстрого соединения должен сделать следующее:

1. Проверьте целостность данных, проверив первые 8 байтов HMAC-SHA256.

2. Расшифруйте зашифрованные данные с помощью AES-CTR, где каждый блок генерируется с использованием

   clearBlock[i] = encryptedBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))
   

   где

   1. EncryptedBlock[i] — это 16-байтовый блок, начинающийся с Encrypted_data[i * 16]. Последний блок может быть меньше 16 байт.
   2. Ключ AES генерируется или идентифицируется в ходе рукопожатия, например
      1. в потоке именования 1 он принадлежит ECDH и больше не будет использоваться для этого соединения. Любые запросы, которые поступают зашифрованными с помощью этого ключа без перезапуска процедуры, должны быть отклонены.
      2. в потоке именования 2 это ключ учетной записи.

3. Выполните concat(clearBlock[0],clearBlock[1],...) для создания необработанных данных.