蓝牙低功耗 (BLE) 设备

适用于 BLE 设备的 Google 快速配对服务 (GFPS) 实现与蓝牙核心规范 v4.2 或更高版本兼容。

快速配对规范的以下附录将允许在 GFPS 中支持仅限低功耗 (LE) 和低功耗音频 (LEA) 设备。

合规性级别

下面说明了规范中提及的关键字“shall”“must”“will”“should”“may”和“can”：

术语 说明
应该 必须 - 用于定义要求。
must 用于表示：
先前所述强制性要求的自然结果
或
无可争议的事实陈述（无论情况如何，都是事实陈述）。
将 确实 - 仅用于陈述事实。
应 建议采用以下做法：用于表示在几种可能的情况下，推荐采用一种特别适合的方式，但这并非强制性要求。
5 月 is allowed to - 用于提供选项。
罐头 能够 - 用于以因果关系将陈述相关联。

基于键的配对特性

查找者向提供商发送的消息

基于密钥的配对特征的原始请求 type 0x00 使用位 4 来指示 Seeker 是否支持 BLE 设备规范，并使用位 5 来指示 Seeker 是否支持 LE 音频。

Octet 数据类型 说明 值 是否必需？
0 uint8 消息类型 0x00 = 基于密钥的配对请求 强制
1 uint8 标志
  • 位 0 (MSB)：已弃用并被 Seeker 忽略。
  • 第 1 位：如果查找器请求提供方发起配对，并且此请求包含查找器的 BR/EDR 地址，则为 1。否则为 0。
  • 位 2：1 如果搜寻者请求提供程序应通知现有姓名。否则为 0。
  • 第 3 位：如果是用于回溯写入账号密钥，则为 1。否则为 0。
  • 位 4：1（如果搜寻器支持 BLE 设备规范）。否则为 0。
  • 位 5：如果 Seeker 支持 LE 音频，则为 1。否则为 0。
  • 位 6-7 预留以供日后使用，应被忽略。
 不定 强制
2 - 7 uint48 请执行以下任一操作：
  • 提供商的当前 BLE 地址
  • 提供方的身份地址
 不定 强制
8 - 13 uint48 搜寻者的巴西/EDR 地址 不定 仅当标志位 1 或 3 被设置时才存在
n - 15 随机值（盐） 不定 强制

提供商向查询者发送的消息

设置请求的位 4 后，基于密钥的配对特性的新响应消息 type 0x02 可用于向 Seeker 提供其他配对选项。

Octet 数据类型 说明 值
0 uint8 消息类型 0x02 = 基于密钥的配对扩展响应
1 uint8 标志
  • 位 0（最有显位）：如果提供程序是仅限 LE 的设备，则为 1，否则为 0。如果将位 0 设置为 1，则 Seeker 会假定位 1 也设置为 1。
  • 第 1 位：如果提供程序首选 LE 配对，则为 1，否则为 0。
  • 第 2 位：如果第二个地址的地址类型为“随机”，则为 1；如果为“公开”，则为 0。
  • 位 3-7 预留以供日后使用，应被忽略。
 不定
2 uint8 提供商的地址数量
（在当前版本中，此数量为 1 或 2，因为如果数量大于等于 3，我们需要将块加密模式修改为 AES-CTR）		 不定
3 - 8 或
3 - 14
  • 第一个地址应为主设备的身份地址，如果首选 BR/EDR 配对，则应可配对
  • 第二个地址应为次要地址（如果有）的可抵押地址
 不定
9 - 15 或 15 随机值（盐） 因人而异

支持 BLE 设备规范的提供程序应读取位 4 和位 5，以了解查找器的功能

  • 当位 4 为 0 时，提供程序应忽略位 5 并以 type 0x01 格式进行响应
  • 当第 4 位为 1 时，
    • 对于仅限 LE 的提供程序，它应响应 type 0x02 以指示 LE 配对偏好设置。
    • 对于双模式提供程序，它可以使用 type 0x02 进行响应，以指示 BR/EDR 或 LE 配对偏好。
  • 如需了解 LE Audio (LEA) 双模式提供程序用例，请参阅示例：与 LEA 双模式提供程序配对以作参考

消息流 PSM（协议服务多路复用器）特征

为了支持 BLE 设备的消息流，快速配对将建立并维护一个 BLE L2CAP 通道，以发送和接收消息。快速配对 L2CAP 服务器应实现基于 LE 信用的流控制。

通过此特征，查找器可以读取 PSM 值，然后根据 PSM 值建立安全的 L2CAP 连接。

快速配对服务特性 已加密 权限 UUID
消息流 PSM 是 读取 FE2C1239-8366-4814-8EB0-01DE32100BEA
Octet 数据类型 说明 值
0 uint8 状态
  • 0x00 = 未知。FP Seeker 会多次重试
  • 0x01 = 可以连接
  • 0x02 = 不可用。FP Seeker 这次不会使用此组件进行连接
 不定
1 - 2 uint16 PSM 值应在 0x80 到 0xFF 之间 不定

注意：TWS 有两个组件：主要组件和次要组件。在某些情况下，这些组件的角色是可互换的。假设 A 是主要组件，B 是次要组件，由于组件 A 的电池电量耗尽，因此组件 B 需要承担主要组件角色，这种情况称为 role switch。

role switch 之后，如果提供程序无法处理快速配对消息流，则应主动断开现有 L2CAP 连接。然后，快速配对搜寻者可以与新的主要组件重新建立 L2CAP 消息流连接。

其他通行密钥特征

此特性用于对其他组件提供 MITM 保护。

CSIS 虚假成员 MITM 保护

快速配对要求在配对过程中提供 MITM 保护。由于 CSIS 不提供 MITM 保护，因此需要扩展多个组件的当前 FP 设计，以便为其他组件提供 MITM 保护。

特征定义

快速配对服务特性 已加密 权限 UUID
其他通行密钥 是 读取、写入、通知 FE2C123A-8366-4814-8EB0-01DE32100BEA

消息

消息格式适用于读取、写入和通知操作。

加密数据格式

系统会使用快速配对 GATT 连接发送加密数据。

Octet 数据类型 说明 值
0-15 uint128 已加密的其他通行密钥屏蔽设置 不定
原始数据格式

使用共享密钥对加密的数据进行解密后，格式如下所示

Octet 数据类型 说明 值
0 uint8 消息类型 以下任一情况
  • 0x00 = 搜寻者的通行密钥
  • 0x01 = 提供商的通行密钥
1-3 uint24 6 位数通行密钥 不定
4-9 uint48 目标绑定组件地址 不定
10 uint8 状态代码，仅供读取操作使用 以下各项之一
  • 0x00 = 成功
  • 0x01 = 待处理。FP Seeker 会重试，直到超时
  • 0x02 = 失败。FP Seeker 停止重试
11 - 15 年 随机值（盐） 不定

主要（第一个键结组件）是快速配对搜寻器和其他键结组件之间的桥梁。该特征应遵循以下准则：

  • 当从快速配对查询器收到写入请求时，提供程序应
    • 设置要绑定的组件的地址
    • 将通行密钥发送到要绑定的组件
    • 将状态代码设置为“待处理”(0x01)
  • 如果在从要绑定的组件收到通行密钥之前收到任何读取请求，提供程序应返回包含
    • 通行密钥，任意值
    • 要绑定的组件的地址
    • 待处理状态代码，0x01
  • 在提供程序向快速配对查找器发送通知之前，使用
    • 要绑定的组件中的通行密钥
    • 要绑定的组件的地址
    • 成功状态代码，0x00
  • 如果提供程序端出现任何不可恢复的错误，请设置结果
    • 通行密钥，任意值
    • 要绑定的组件的地址
    • 失败状态代码，0x02

如需了解详情，请参阅 MITM 示意图 1 和 MITM 示意图 2。

LE 设备要求

LE 通告

对于可检测到模式或不可检测到模式，提供方应使用 RPA 通告 FastPair 数据。

绑定功能

对于支持 LE 的设备，查找器必须与现有 LE 连接建立配对。通过基于密钥的快速配对验证后，提供程序应允许与 RPA 建立配对，并将 IO 功能设置为 DisplayYesNo 以进行快速配对通行密钥验证。

LEA 设备要求

LEA 广告

对于双模式设备：对于可检测到模式，提供程序应使用身份地址通告快速配对数据。对于不可检测的模式，提供程序应使用 RPA 通告快速配对数据。强烈建议使用旧版广告 (BT 4.2) 来支持旧版设备，以实现向后兼容。每当设备恢复出厂设置时，都必须更改 IRK。

对于非双模设备：无论处于可检测到模式还是不可检测到模式，提供方都应将增强型广告 (BT 5.0) 与 RPA 搭配使用，以通告 FastPair 数据。

包含 FP 服务数据的可连接 LE 广告应遵循 Bluetooth 适配器配置文件 (BAP 1.0.1) 和通用音频配置文件要求，包含 CAS UUID。对于不可检测到的广告，如果由于包含电池和 SASS 数据而导致旧版广告中没有足够的空间，则必须在扫描响应中包含 CAS UUID。

LEA 粘合功能

查找器必须与现有 LE 连接建立配对。通过基于快速配对密钥的配对验证后，双模式提供程序应允许与身份地址和 RPA 建立配对，而非双模式提供程序应允许与 RPA 建立配对，并将 IO 功能设置为 DisplayYesNo 以进行快速配对通行密钥验证。

组件之间的内部通信渠道

系统会保留现有 GATT 连接，以对其他组件执行 MITM 保护。主要绑定组件应处理快速配对查找器及其余组件之间的消息传递。

内部通信用于 Initial Pair 和 Subsequent Pair

  • 当基于密钥的配对过程通过主要组件时，主组件应发送消息以更改其其余组件的 IO 功能
  • 快速配对完成后，主组件应发送消息以重置其余组件的 IO 功能
  • 运行“其他通行密钥”过程时，主要组件应处理 Fast Pair Seeker 及其其他组件之间的通行密钥传递

更改 IO 功能的时间

  • 通过基于密钥的配对过程后，将 IO 功能更改为 DisplayYesNo
    • 如果设备具有多个组件，则应将所有组件都设置为 DisplayYesNo
    • 提供方不得将 IO 功能更改为 DisplayYesNo 的一个例外情况是 Retroactive Pair，其基于密钥的配对请求的位 3 设置为 1，请参阅从查找器发送给提供方的邮件
  • 将 IO 功能更改为默认设置
    • 初始配对
      • 如果 LE 连接断开，则结束快速配对会话
      • 主设备建立配对后，如果 15 秒内没有其他通行密钥写入请求，则结束快速配对会话
      • 收到其他通行密钥写入请求后，如果要绑定的组件未在 15 秒内绑定，则会结束快速配对会话
      • 所有组件都建立配对关系后，如果 15 秒内没有账号密钥写入请求，则结束快速配对会话
      • 收到账号密钥写入请求后，将超时设置为 15 秒以结束快速配对会话
    • 后续配对
      • 如果 LE 连接断开，请结束快速配对会话
      • 主设备配对后，如果 15 秒内没有其他通行密钥写入请求，则结束快速配对会话
      • 收到其他通行密钥写入请求后，如果要绑定的组件未在 15 秒内绑定，则会结束快速配对会话
      • 当所有组件绑定后，结束快速配对会话

隐藏界面指示

当耳机尚未准备好配对时，提供方应使用 type 0b0010 为账号密钥数据设置“隐藏界面”指示，以告知查找器不要显示后续配对界面（请参阅广告载荷：快速配对账号数据）。

LE 音频设备要求

蓝牙要求

请参阅 Android，LE 音频耳机建议。

CTKD 支持

对于双模式设备，从 LE 到 BR/EDR 的 CTKD 是强制性的，并且符合 BAP 要求。

目标公告

外围设备应使用定向通知向已配对的中央设备请求连接。根据 CAP 1.0 表 8.4 (p48/58)，在 BAP 和 CAP 中针对连接管理定义了“目标公告”。

GATT EATT 服务器支持

EATT 允许中央设备在设备绑定时并行发送多个 GATT 事务。对于支持 CSIP 的设备，这会提高配置文件连接的性能，然后很快会为其他耳机启动 CSIP 绑定程序。

如果提供程序不是单一设备，而是使用 CSIP 实现的协调集合，为了减少执行服务发现的次数并加快连接速度，提供程序应实现蓝牙 5.1 中定义的 GATT 缓存。

快速配对要求

LE 通告

对于可检测到模式或不可检测到模式，如果设备具有多个组件，则主组件应通告快速配对数据。如果设备尚未准备好进行后续配对，次要组件可以为扩展功能通告快速配对数据。请参阅隐藏界面指示。

GATT 服务可见性

所有 LE 传输 GATT 连接的 GATT 数据库都应相同。LE 音频服务 (0x184E) 应包含在快速配对连接的 GATT 数据库中。

示例：与 LEA 双模式提供程序配对

场景 1 - 查询方不支持 LEA

提供方应向后兼容不支持 LEA 的 Seeker。

组件
  • 提供商：A2DP/HFP/LEA
  • 查找器：A2DP/HFP
初始配对 / 后续配对的预期行为
  • 提供程序使用身份地址（初始）或 RPA（后续）通告快速配对服务数据 (0xFE2C)。
    • 使用旧版广告
  • 查找方会收到提供商的广告，其中包含用于初始配对的身份地址或用于后续配对的 RPA
  • 查找器发送基于密钥的配对请求
    • 基于密钥的配对请求的标志位 5 设置为 0
  • 提供程序会发送基于密钥的配对响应，其中包含以下任一公共地址：
    • 如果使用消息类型 0x01，则地址应为公共地址
    • 如果使用消息类型 0x02
      • 位 0 应为 0
      • 第 1 位应为 0
      • 地址应为公共地址
  • 查找器与 BR/EDR 传输层建立了绑定
    • 对于 BR/EDR，IO 功能设置为 DisplayYesNo
  • 查找器和提供程序执行快速配对通行密钥验证流程

场景 2 - 查询者支持 LEA

组件
  • 提供方
    • 支持 A2DP/HFP/LEA
    • 单个组件
  • 追逐者
    • SupportA2DP/HFP/LEA
初始配对 / 后续配对的预期行为
  • 提供程序使用身份地址（初始）或 RPA（后续）通告快速配对服务数据 (0xFE2C)。
    • 使用旧版广告功能
  • 搜寻者发送基于密钥的配对请求
    • 基于密钥的配对请求的标志位 5 设置为 1
  • 提供程序发送消息类型为 0x02 的基于密钥的配对响应
    • 位 0 应为 0
    • 第 1 位应为 1
    • 地址是身份证件地址
  • 在 LE 传输上，查找器与现有 LE 连接建立配对
    • CTKD 方向为从 LE 到 BR/EDR
    • 将 IO 功能设置为 LE 的 DisplayYesNo
  • 查找器和提供程序执行快速配对通行密钥验证流程

场景 3 - 当 Seeker 支持相关的 LEA 和 CSIP 时

组件
  • 提供方
    • 支持 A2DP/HFP/LEA
    • 多个组件
      • 主要组件是 BR/EDR/LE
      • 辅助组件仅限 LE
  • 搜索者
    • 支持 A2DP/HFP/LEA
初始配对 / 后续配对的预期行为
  • 主要组件使用身份地址（初始）或 RPA（后续）通告快速配对服务数据 (0xFE2C)。
    • 使用旧版广告功能
  • 查找器向主要组件发送基于密钥的配对请求
    • 基于密钥的配对请求的标志位 5 设置为 1
  • 主要组件发送消息类型为 0x02 的基于密钥的配对响应
    • 位 0 应为 0
    • 第 1 位应为 1
    • 地址如下：
      • 第一个地址是主要组件的身份地址
      • 第二个地址是辅助组件的可绑定地址，第二个组件也使用此地址进行 CSIP 通告
  • 查找器在现有 LE 连接上与主组件建立配对
    • CTKD 方向为从 LE 到 BR/EDR
    • 将 IO 功能设置为 LE 的 DisplayYesNo
  • Seeker 与辅助组件建立连接，辅助组件的地址来自基于密钥的配对扩展响应
    • IO 功能应为 DisplayYesNo，否则拒绝配对请求
  • 查找器和提供程序执行 MITM 保护程序以配对次要组件，提供程序应在两种情况下都实现此操作
  • 直到与辅助组件建立连接为止

MITM 序列图

本会话将介绍 MITM 保护程序的顺序。

通过通知从正在绑定的组件获取通行密钥

通过读取从正在绑定的组件获取通行密钥

已知问题

针对 LEA 的 FP 已经过优化，可与 Android V（Android 15）搭配使用。

相反，我们发现支持 LEA 但缺少正确的 LEA 快速配对实现（即仅支持通过传统配对方式快速配对）的耳机存在许多问题。具体而言（例如，当提供程序的 RPA 不是由正确的身份解析密钥 (IRK) 生成且地址无法解析时）。虽然我们无法测试完整的耳机配置列表，但在有限的测试中发现了各种问题，包括无法显示耳机电池通知、缺少音频切换 (SASS) 功能、初始配对和后续配对普遍失败等。

因此，我们强烈建议合作伙伴为支持双模式的新设备和现有设备（通过无线更新）实现快速配对-LEA 规范。