低功耗蓝牙 (BLE) 设备

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

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

一致性级别

规范中提及的“应”“必须”“将”“应该”“可以”和“能”等关键字的含义如下：

术语 说明
应 是必需的 - 用于定义要求。
必须 用于表达：
先前所述强制性要求的自然结果
或
无可辩驳的事实陈述（无论在何种情况下都始终为真）。
将 it is true that - 仅用于事实陈述。
should 建议 - 用于表示在多种可能性中，有一种特别适合，但不是必需的。
5 月 允许 - 用于允许选项。
能提供以下 能够 - 用于以因果方式关联语句。

基于密钥的配对特征

求助者向提供者发送的消息

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

Octet 数据类型 说明 值 是否为必需参数？
0 uint8 消息类型 0x00 = 基于密钥的配对请求 强制
1 uint8 标志
  • 位 0（最高有效位）：已弃用，并被 Seeker 忽略。
  • 位 1：如果探索者请求提供者发起配对，并且此请求包含探索者的 BR/EDR 地址，则为 1。否则为 0。
  • 位 2：如果搜索者请求提供方通知现有名称，则为 1。否则为 0。
  • 位 3：如果这是为了追溯写入账号密钥，则为 1。否则为 0。
  • 位 4：如果 Seeker 支持 BLE 设备规范，则为 1。否则为 0。
  • 位 5：如果 Seeker 支持 LE 音频，则为 1。否则为 0。
  • 第 6 位至第 7 位预留以供将来使用，应忽略。
 各不相同 强制
2 - 7 uint48 满足以下任一条件：
  • 提供方的当前 BLE 地址
  • 提供方的身份地址
 各不相同 强制
8 - 13 uint48 搜索者的 BR/EDR 地址 各不相同 仅在设置了标志位 1 或 3 时显示
n - 15 随机值（盐） 各不相同 强制

提供者向寻求者发送的消息

当请求的位 4 设置为 1 时，可使用基于密钥的配对特征的新响应消息 type 0x02 向搜索者提供额外的绑定选项。

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 音频 (LEA) 双模式提供方用例，请参阅示例：与 LEA 双模式提供方配对以供参考

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

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

此特征允许 Seeker 读取 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 以进行快速配对 Passkey 验证。

LEA 设备要求

LEA 广告

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

对于非双模式设备：在可检测到模式或不可检测到模式下，提供方应使用扩展通告 (BT 5.0) 和 RPA 来宣传 FastPair 数据。

包含 FP 服务数据的 LE 可连接广播应包含 CAS UUID，以符合 Bluetooth Adapter Profile (BAP 1.0.1) 和通用音频配置文件要求。

提供方可以在服务数据（AD 类型 0x16）或 16 位服务类 UUID（AD 类型 0x02 或 0x03）中包含 CAS UUID (0x1853)，以指示 LEA 功能，无论可发现模式如何。

对于不可发现的广告，如果由于包含电池和 SASS 数据而导致旧版广告中没有足够的空间，则必须在这种情况下在扫描响应中包含 CAS UUID。

LEA 绑定功能

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

组件之间的内部通信渠道

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

内部通信用于 Initial Pair 和 Subsequent Pair

  • 当基于密钥的配对程序在主组件上通过时，主组件应发送消息以更改其剩余组件的 IO 功能
  • 快速配对完成后，主组件应发送消息以重置其余组件的 IO 功能
  • 在运行“附加通行密钥”程序时，主要组件应处理快速配对搜索器及其剩余组件之间的通行密钥传递

更改 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 要求。

Target 公告

外围设备应使用定向广播来请求与配对的中央设备建立连接。根据 CAP 1.0 表 8.4（第 48/58 页），在 BAP 和 CAP 中定义了用于连接管理的定向公告。

GATT EATT 服务器支持

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

如果提供方不是单个设备，而是具有 CSIP 实现的协调集，为了减少执行服务发现的次数并加快连接速度，提供方应实现 Bluetooth 5.1 中定义的 GATT 缓存。

快速配对要求

LE 通告

对于可发现模式或不可发现模式，如果设备有多个组件，则应由主组件播发快速配对数据。如果设备未准备好进行后续配对，辅助组件可以广播快速配对数据以实现扩展功能。请参阅隐藏界面指示。

GATT 服务可见性

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

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

场景 1 - 当 Seeker 不支持 LEA 时

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

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

场景 2 - 当 Seeker 支持 LEA 时

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

场景 3 - 当搜索者支持 LEA 且涉及 CSIP 时

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

中间人攻击的顺序图

本会话旨在介绍 MITM 保护程序的序列。

通过通知从正在配对的组件获取通行密钥

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

已知问题

LEA 的 FP 已优化为可与 Android V（Android 15）搭配使用。

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

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