蓝牙低功耗 (BLE) 设备

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

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

一致性级别

下面对本规范中提及的关键字“应”“必须”“将会”“应该”“可以”和“可以”进行说明：

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

基于密钥的配对特性

从寻找者到提供者的消息

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

八位字节 数据类型 说明 值 是否必需？
0 uint8 邮件类型 0x00 = 基于密钥的配对请求 强制
1 uint8 标志
  • 位 0 (MSB)：已弃用并被 Seeker 忽略。
  • 位 1：1：如果搜寻者请求提供程序应发起绑定，并且此请求包含搜寻者的 BR/EDR 地址。否则为 0。
  • 位 2：1 如果搜寻者请求提供程序应通知现有姓名。否则为 0。
  • 位 3：1（如果是追溯写入账号密钥）。否则为 0。
  • 位 4：1（如果搜寻器支持 BLE 设备规范）。否则为 0。
  • 位 5：1（如果搜寻器支持 LE 音频）。否则为 0。
  • 位 6 - 7 保留以供将来使用，并且应被忽略。
 因人而异 强制
2 - 7 人 uint48 以下两个字段之一：
  • 提供商当前的 BLE 地址
  • 提供方的身份地址
 因人而异 强制
8 - 13 人 uint48 搜寻者的 BR/EDR 地址 因人而异 仅在已设置标志位 1 或 3 时显示
n - 15 随机值（盐） 因人而异 强制

从提供者发送给寻找者的消息

设置请求的位 4 后，针对type 0x02 基于密钥的配对特性可用于提供额外的绑定 选项。

八位字节 数据类型 说明 值
0 uint8 邮件类型 0x02 = 基于密钥的配对扩展响应
1 uint8 标志
  • 位 0 (MSB)：如果提供程序是仅支持 LE 的设备，则为 1，否则为 0。如果位 0 设为 1，则搜寻器会假定位 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
八位字节 数据类型 说明 值
0 uint8 州
  • 0x00 = 未知。FP 追逐者将进行多次重试
  • 0x01 = 已准备好进行连接
  • 0x02 = 不可用。FP 追逐者这次不会使用此组件进行连接
 因人而异
1 - 2 uint16 PSM 值应在 0x80 到 0xFF 之间 因人而异

注意：对于 TWS，有两个 主要组件和次要组件这些组件的作用包括 在特定情况下可互换假设 A 是主组件，B 是 由于组件 A 耗电过快，因此 B 组件需要 主要组件角色，这种情况称为 role switch。

role switch之后，如果提供商 无法处理快速配对消息流，则应主动断开与 现有 L2CAP 连接。然后，查找快速配对的用户就可以重新建立 L2CAP 消息流连接。

其他通行密钥特征

此特性可在附加 组件。

CSIS 虚假成员 MITM 保护

快速配对要求在配对过程中提供 MITM 保护。作为 CSIS 不提供 MITM 保护，当前针对多个 FP 的设计 这些组件需要进行扩展，以便在 组件。

特征定义

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

消息

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

加密数据格式

加密后的数据会通过快速配对 GATT 连接进行发送。

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

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

八位字节 数据类型 说明 值
0 uint8 邮件类型 以下之一：<ph type="x-smartling-placeholder">
    </ph>
  • 0x00 = 搜寻者的通行密钥
  • 0x01 = 提供方的通行密钥
1-3 uint24 6 位数通行密钥 不定
4-9 uint48 目标绑定组件地址 不定
10 uint8 状态代码，仅供读取操作使用 以下之一：
  • 0x00 = 成功
  • 0x01 = 待处理。FP 追踪器在超时之前重试
  • 0x02 = 失败。FP 追踪器停止重试
11 - 15 年 随机值（盐） 不定

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

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

请参阅 MITM 图 1 和 MITM 图 2。

LE 设备要求

LE 通告

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

绑定功能

对于支持 LE 的设备，寻求者必须与现有 LE 连接。通过“基于快速配对密钥的配对”验证之后， 提供方应允许与 RPA 绑定，并将 IO 功能设置为 DisplayYesNo 。

LEA 设备要求

LEA 广告

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

对于非双模式设备： 对于可检测到的模式或不可检测到的模式，提供商应使用扩展 使用 RPA 投放广告 (BT 5.0)，以通告 FastPair 数据。

包含 FP 服务数据的 LE 可连接通告应包括： CAS UUID（遵循 蓝牙适配器配置文件 (BAP 1.0.1) 和 通用音频配置文件 。适用于因没有足够的可用空间时不可检测到的通告 因为其中包含电池和 SASS 数据， 在这种情况下，必须在扫描响应中包含 CAS UUID。

LEA 绑定功能

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

组件之间的内部通信通道

系统会保留现有的 GATT 连接，以便在 其他组件主要绑定组件应处理消息 快速配对追踪器与其其余组件之间的传送。

内部通信用于 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 要求。

目标公告

外围设备应使用定向通知请求连接 。“定位通知”在 BAP 和 CAP 中定义 根据 CAP 1.0 表 8.4 (p48/58) 进行连接管理。

GATT EATT 服务器支持

EATT 允许中央设备并行发送多个 GATT 事务 当设备绑定时。对于支持 CSIP 的设备，该上限值将增加 配置文件连接的性能，然后很快开始 CSIP 绑定 为其他耳机做准备。

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

快速配对要求

LE 通告

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

GATT 服务可见性

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

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

场景 1 - 探索者不支持 LEA

“提供者”应与“探索者”向后兼容， 支持 LEA。

组件
  • 提供商：A2DP/HFP/LEA
  • 搜寻器：A2DP/HFP
初始配对 / 后续配对的预期行为
  • 提供商通告快速配对服务 带有身份地址（初始）或 RPA（后续）的数据 (0xFE2C)。
    • 使用旧版广告功能
  • 寻找者会收到提供者的 使用身份地址进行初始配对或 RPA 进行后续配对的广告
  • 搜寻者发送基于密钥的配对请求
    • 基于密钥的配对请求的标志 bit-5 设为 0
  • 提供程序会发送基于密钥的配对响应，其中包含以下任一公共地址： 以下：
    • 如果使用消息类型 0x01，该地址应为公开地址
    • 如果使用消息类型 0x02
      • 位 0 应为 0
      • 位-1 应为 0
      • 地址应为公开地址
  • “追逐者”与 BR/EDR 交通建立起联系
    • 针对 BR/EDR 的 IO 功能设置为 DisplayYesNo
  • 搜寻者和提供者执行快速配对通行密钥验证程序

场景 2 - 当寻求者支持 LEA 时

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

场景 3 - 搜寻者支持涉及 LEA 和 CSIP 时

组件
  • 提供方
    • 支持 A2DP/HFP/LEA
    • 多个组件
      • 主要组件为 BR/EDR/LE
      • 辅助组件仅限 LE
  • 追逐者
    • 支持 A2DP/HFP/LEA
初始配对 / 后续配对的预期行为
  • 主要组件通告快速配对 带有身份地址（初始）或 RPA（后续）的服务数据 (0xFE2C)。
    • 使用旧版广告功能
  • 搜寻者向主要组件发送基于密钥的配对请求
    • 基于密钥的配对请求的标志 bit-5 设为 1
  • 主要组件发送消息类型为 0x02 的基于密钥的配对响应
    • 位 0 应为 0
    • 位-1 应为 1
    • 地址如下所示：
      • 第一个地址是主要组件的身份地址
      • 第二个地址是次要组件的可绑定地址， 第二个组件也使用该地址进行 CSIP 通告
  • 探寻者与主角建立联系 组件（位于现有 LE 连接上）
    • CTKD 方向为从 LE 到 BR/EDR
    • LE 的 IO 功能设置为 DisplayYesNo
  • 探寻者与次世代成为了亲密伙伴 组件，其地址来自基于密钥的配对扩展响应
    • IO 功能应为 DisplayYesNo，否则应拒绝配对请求
  • 搜寻者和提供者执行 MITM 保护程序，以配对 次要组件，提供程序应在这两种情况下都实现
  • 寻找者会等待与次要成分结合

MITM 序列图

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

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

通过读取操作从要绑定的组件中获取通行密钥

已知问题

LEA 的 FP 已经过优化，可与 Android V 配合使用。

反过来，我们在支持 LEA 的耳机方面也遇到了许多问题。 但缺少正确的 LEA 快速配对实现（即 传统版）。具体而言（例如，当未生成提供商的 RPA 时） 由正确的身份解析密钥 (IRK) 发出，并且地址无法解析。 尽管我们还无法测试完整的耳机列表 我们的有限测试发现了各种问题， 显示入耳式耳机电池通知，缺少音频切换功能 (SASS) 大范围的初始和后续配对失败等。

因此，我们强烈建议合作伙伴实现快速配对 LEA。 在实际使用中的新设备和现有设备的规格要求 （通过无线下载更新）。