低功耗蓝牙 (BLE) 设备
BLE 设备的 Google 快速配对服务 (GFPS) 实现与蓝牙核心规范 v4.2 或更高版本兼容。
以下快速配对规范附录将允许在 GFPS 中支持仅低功耗 (LE) 和低功耗音频 (LEA) 设备。
一致性级别
规范中提及的关键字“应”“必须”“将”“应该”“可能”和“可以”解释如下:
| 术语 | 说明 |
|---|---|
| shall | is required to - 用于定义要求。 |
| 必须 | 用于表达: 先前所述强制性要求的自然结果 或 不容置疑的事实陈述(无论在何种情况下都始终为真)。 |
| will | it is true that - 仅用于陈述事实。 |
| 应该 | is recommended that - 用于表示在多种可能性中,有一种特别适合,但并非强制要求。 |
| 5 月 | is permitted to - 用于允许选项。 |
| 能提供以下 | is able to - 用于以因果方式关联语句。 |
基于密钥的配对特征
从搜索者到提供者的消息
基于密钥的配对特征的原始请求 type 0x00 使用第 4 位来指示 Seeker 是否支持 BLE 设备规范,并使用第 5 位来指示 Seeker 是否支持 LE 音频。
| 八位字节 | 数据类型 | 说明 | 值 | 是否强制? |
|---|---|---|---|---|
| 0 | uint8 |
消息类型 | 0x00 = 基于密钥的配对请求 |
强制 |
| 1 | uint8 |
标志 | 视情况而定 | 强制 |
| 2 - 7 | uint48 |
请执行以下任一操作:
|
视情况而定 | 强制 |
| 8 - 13 | uint48 |
Seeker 的 BR/EDR 地址 | 视情况而定 | 仅在设置了标志位 1 或 3 时显示 |
| n - 15 | 随机值(盐) | 视情况而定 | 强制 |
提供方发送给搜索方的消息
设置请求的第 4 位后,基于密钥的配对特征的新响应消息 type 0x02 可用于向 Seeker 提供其他绑定选项。
| 八位字节 | 数据类型 | 说明 | 值 |
|---|---|---|---|
| 0 | uint8 |
消息类型 | 0x02 = 基于密钥的配对扩展响应 |
| 1 | uint8 |
标志
|
视情况而定 |
| 2 | uint8 |
提供商的地址数量 (在当前版本中,该数量为 1 或 2,因为如果数量 >= 3,我们需要将分块加密模式修改为 AES-CTR) |
视情况而定 |
| 3 - 8 或 3 - 14 |
|
视情况而定 | |
| 9 - 15 或 15 | 随机值(盐) | 视情况而定 |
支持 BLE 设备规范的提供方应读取第 4 位和第 5 位,以了解 Seeker 的功能
- 当位 4 为 0 时,提供方应忽略位 5,并以
type 0x01格式响应 - 当第 4 位为 1 时,
- 对于仅支持 LE 的提供方,它应使用
type 0x02进行响应,以指示 LE 绑定偏好。 - 对于双模提供程序,它可以响应
type 0x02,以指示 BR/EDR 或 LE 绑定偏好。
- 对于仅支持 LE 的提供方,它应使用
- 对于 LE 音频 (LEA) 双模提供方用例,请参阅示例:与 LEA 双模提供方配对
消息流 PSM(协议服务多路复用器)特征
为了支持 BLE 设备的消息流,快速配对将建立并维护一个 BLE L2CAP 通道,用于发送和接收消息。快速配对 L2CAP 服务器应实现基于 LE 积分的流量控制。
此特征可让 Seeker 读取 PSM 值,然后通过 PSM 值建立安全的 L2CAP 连接。
| 快速配对服务特征 | 已加密 | 权限 | UUID |
|---|---|---|---|
| 消息流 PSM | 是 | 读取 | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| 八位字节 | 数据类型 | 说明 | 值 |
|---|---|---|---|
| 0 | uint8 |
州/省/自治区/直辖市
|
视情况而定 |
| 1 - 2 | uint16 |
PSM 值应介于 0x80 和 0xFF 之间 | 视情况而定 |
注意:对于 TWS,有两个组件:主组件和辅助组件。在某些情况下,这些组件的角色可以互换。假设 A 是主要组件,B 是次要组件,由于组件 A 的电池电量耗尽,组件 B 需要承担主要组件角色,这种情况称为role switch。
在 role switch 之后,如果提供方无法处理快速配对消息流,则应主动断开现有的 L2CAP 连接。然后,快速配对 seeker 可以与新的主要组件重新建立 L2CAP 消息流连接。
其他通行密钥特征
此特征旨在为其他组件提供 MITM 保护。
CSIS 伪造成员中间人攻击防护
快速配对要求在配对过程中提供 MITM 保护。由于 CSIS 不提供 MITM 保护,因此需要扩展当前针对多个组件的 FP 设计,以便为其他组件提供 MITM 保护。
特征定义
| 快速配对服务特征 | 已加密 | 权限 | UUID |
|---|---|---|---|
| 其他通行密钥 | 否 | 读取、写入、通知 | FE2C123A-8366-4814-8EB0-01DE32100BEA |
消息
消息格式适用于读取、写入和通知操作。
加密数据格式
加密数据会通过快速配对 GATT 连接发送。
| 八位字节 | 数据类型 | 说明 | 值 |
|---|---|---|---|
| 0-15 | uint128 | 加密的额外通行密钥块 | 不定 |
原始数据格式
使用共享密钥解密加密数据后,格式如下
| 八位字节 | 数据类型 | 说明 | 值 |
|---|---|---|---|
| 0 | uint8 | 消息类型 | 以下之一:
|
| 1-3 | uint24 | 6 位数通行密钥 | 不定 |
| 4-9 | uint48 | 目标绑定组件地址 | 不定 |
| 10 | uint8 | 状态代码,仅供读取操作使用 | 以下权限之一:
|
| 11 - 15 年 | 随机值(盐) | 不定 |
主组件(第一个绑定组件)是快速配对寻找器与其他绑定组件之间的桥梁。该特征应遵循以下准则:
- 收到来自快速配对 Seeker 的写入请求时,提供方应
- 设置正在绑定的组件的地址
- 将通行密钥发送到正在绑定的组件
- 将状态代码设置为“待处理”(0x01)
- 在收到来自正在绑定的组件的密钥之前,如果收到任何读取请求,提供方应返回一条消息,其中包含
- 通行密钥,任意值
- 要绑定的组件的地址
- 待处理状态代码,0x01
- 在提供方将通知发送到快速配对寻觅方之前,请使用以下命令设置读取请求的结果:
- 来自正在绑定的组件的通行密钥
- 要绑定的组件的地址
- 成功状态代码,0x00
- 如果提供方端出现任何不可恢复的错误,请将结果设置为
- 通行密钥,任意值
- 要绑定的组件的地址
- 失败状态代码,0x02
如需了解详情,请参阅 MITM 图表 1 和 MITM 图表 2。
LE 设备要求
LE 通告
对于可检测到模式或不可检测到模式,提供方应使用 RPA 来通告快速配对数据。
粘合能力
对于支持 LE 的设备,Seeker 必须与现有 LE 连接建立绑定。通过快速配对基于密钥的配对验证后,提供方应允许与 RPA 绑定,并将 IO 功能设置为 DisplayYesNo 以进行快速配对通行密钥验证。
LEA 设备要求
LEA 广告
对于双模设备: 对于可检测到模式,提供方应使用身份地址通告快速配对数据。 对于不可检测模式,提供方应使用 RPA 广播快速配对数据。 强烈建议使用旧版通告 (BT 4.2) 来支持旧设备,以实现向后兼容。 每当设备恢复出厂设置时,都需要更改 IRK。
对于非双模设备: 对于可检测到模式或不可检测到模式,提供方应使用具有 RPA 的扩展广播 (BT 5.0) 来广播快速配对数据。
包含 FP 服务数据的 LE 可连接通告应包含 CAS UUID,以符合蓝牙适配器配置文件 (BAP 1.0.1) 和通用音频配置文件要求。
无论处于哪种可检测模式,提供方都可以通过在服务数据(AD 类型 0x16)或 16 位服务类 UUID(AD 类型 0x02 或 0x03)中添加 CAS UUID (0x1853) 来表明 LEA 功能。
对于不可检测到的通告,如果由于包含电池和 SASS 数据而导致旧版通告中没有足够的可用空间,则必须在扫描响应中包含 CAS UUID。
LEA 绑定功能
Seeker 必须与现有 LE 连接建立绑定。通过快速配对基于密钥的配对验证后,双模提供方应允许与身份地址和 RPA 绑定,而非双模提供方应允许与 RPA 绑定,并将 IO 功能设置为 DisplayYesNo 以进行快速配对通行密钥验证。
组件之间的内部通信渠道
系统会保留现有的 GATT 连接,以便对其他组件执行 MITM 保护。主要绑定组件应处理快速配对寻标器与其其余组件之间的消息传递。
内部通信用于 Initial Pair 和 Subsequent Pair
- 当基于密钥的配对过程在主要组件上通过时,主要组件应发送消息以更改其其余组件的 IO 功能
- 快速配对完成后,主要组件应发送一条消息,以重置其其余组件的 IO 功能
- 运行附加通行密钥程序时,主要组件应处理快速配对寻觅端与其其余组件之间的通行密钥传递
更改 IO 功能的时间
- 当基于密钥的配对过程通过时,将 IO 功能更改为 DisplayYesNo
- 如果设备有多个组件,则所有组件都应设置为 DisplayYesNo
- 提供方不得将 IO 功能更改为 DisplayYesNo 的一个例外情况是
Retroactive Pair,其基于密钥的配对请求的第 3 位设置为 1,请参阅从 Seekers 到提供方的消息
- 将 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(第 48/58 页),BAP 和 CAP 中定义了定向通告,用于连接管理。
GATT EATT 服务器支持
EATT 允许中央设备在设备绑定后并行发送多个 GATT 事务。对于支持 CSIP 的设备,这会提高配置文件连接的性能,然后很快就会为另一个耳机启动 CSIP 绑定过程。
GATT 稳健缓存(强烈建议)
如果提供方不是单个设备,而是具有 CSIP 实现的协调集,为了减少服务发现次数并加快连接速度,提供方应实现蓝牙 5.1 中定义的 GATT 缓存。
快速配对要求
LE 通告
对于可检测到模式或不可检测到模式,如果设备有多个组件,则应由主要组件通告快速配对数据。如果设备尚未准备好进行后续配对,则次要组件可以通告快速配对数据以实现扩展功能。请参阅隐藏界面指示。
GATT 服务可见性
对于所有 LE 传输 GATT 连接,GATT 数据库应相同。LE 音频服务 (0x184E) 应包含在快速配对连接的 GATT 数据库中。
示例:与 LEA 双模式提供程序配对
场景 1 - Seeker 不支持 LEA
Provider 应向后兼容不支持 LEA 的 Seeker。
组件
- 提供方:A2DP/HFP/LEA
- Seeker:A2DP/HFP
初始配对/后续配对的预期行为
- 提供方使用身份地址(初始)或 RPA(后续)通告快速配对服务数据 (0xFE2C)。
- 使用旧版广告
- Seeker 收到 Provider 的通告,其中包含用于初始配对的身份地址或用于后续配对的 RPA
- Seeker 发送基于密钥的配对请求
- 基于密钥的配对请求的标志位 5 设置为 0
- 提供方通过以下方式之一发送包含公共地址的基于密钥的配对响应:
- 如果使用消息类型 0x01,则地址应为公开地址
- 如果使用消息类型 0x02
- 位 0 应为 0
- 第 1 位应为 0
- 地址应为公共地址
- Seeker 通过 BR/EDR 传输创建绑定
- BR/EDR 的 IO 功能设置为 DisplayYesNo
- Seeker 和 Provider 执行快速配对通行密钥验证过程
场景 2 - 搜索器支持 LEA
组件
- 提供商
- 支持 A2DP/HFP/LEA
- 单个组件
- Seeker
- SupportA2DP/HFP/LEA
初始配对/后续配对的预期行为
- 提供方使用身份地址(初始)或 RPA(后续)通告快速配对服务数据 (0xFE2C)。
- 使用旧版广告
- Seeker 发送基于密钥的配对请求
- 基于密钥的配对请求的标志位 5 设为 1
- 提供方发送消息类型为 0x02 的基于密钥的配对响应
- 位 0 应为 0
- 第 1 位应为 1
- 地址为身份地址
- Seeker 在 LE 传输上与现有 LE 连接建立绑定
- CTKD 方向是从 LE 到 BR/EDR
- LE 的 IO 功能设置为 DisplayYesNo
- Seeker 和 Provider 执行快速配对通行密钥验证过程
场景 3 - 涉及 Seeker 支持 LEA 和 CSIP 的情况
组件
- 提供商
- 支持 A2DP/HFP/LEA
- 多个组件
- 主要组件为 BR/EDR/LE
- 次要组件仅支持 LE
- Seeker
- 支持 A2DP/HFP/LEA
初始配对/后续配对的预期行为
- 主要组件会使用身份地址(初始)或 RPA(后续)通告快速配对服务数据 (0xFE2C)。
- 使用旧版广告
- Seeker 向主要组件发送基于密钥的配对请求
- 基于密钥的配对请求的标志位 5 设为 1
- 主组件发送消息类型为 0x02 的基于密钥的配对响应
- 位 0 应为 0
- 第 1 位应为 1
- 地址如下:
- 第一个地址是主要组件的身份地址
- 第二个地址是次要组件的可绑定地址,第二个组件也使用此地址进行 CSIP 通告
- Seeker 在现有 LE 连接上与主要组件建立绑定
- CTKD 方向是从 LE 到 BR/EDR
- LE 的 IO 功能设置为 DisplayYesNo
- Seeker 与地址来自基于密钥的配对扩展响应的辅助组件建立绑定
- IO 功能应为 DisplayYesNo,否则拒绝配对请求
- Seeker 和 Provider 执行中间人保护程序来配对辅助组件,Provider 应实现以下两种场景:
- Seeker 等待与辅助组件绑定
MITM 序列图
本部分将介绍 MITM 保护过程的顺序。
从通过通知绑定的组件获取通行密钥

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

已知问题
LEA 的 FP 已针对支持 Android V (Android 15) 的设备进行了优化。
相反,我们遇到了许多支持 LEA 但缺少正确的 Fast Pair over LEA 实现(即仅支持 Fast Pair over Classic)的耳机。具体而言,例如,当提供方的 RPA 不是由正确的身份解析密钥 (IRK) 生成,并且无法解析地址时。 虽然我们无法测试所有耳机配置,但有限的测试已揭示出各种问题,包括无法显示耳机电池通知、缺少音频切换 (SASS) 功能、广泛存在的初始和后续配对失败等。
因此,我们强烈建议合作伙伴为支持双模的新设备和现有设备(通过无线下载更新)实现快速配对-LEA 规范。