引言
为什么BLE需要隐私保护？
BLE设备在广播和连接过程中使用48位设备地址进行身份标识。
如果设备始终使用固定的公共地址，任何具备BLE嗅探能力的第三方都可以通过持续监听，将该地址与特定设备（乃至特定用户）关联起来，实现长期位置追踪和行为画像。这对于智能手表、健康监测器、资产标签等随身设备而言，是一个严重的隐私威胁。
BLE链路层隐私保护的核心目标，就是让设备在无线通信中使用的地址无法被非授权方关联到设备的真实身份。
蓝牙核心规范将链路层操作描述为一个状态机，包含广播状态、扫描状态、发起状态和连接状态等。隐私保护机制并非独立于这些状态运行，而是深度嵌入每一个状态的行为逻辑之中。
本文将从地址类型、核心加密机制、各链路层状态下的隐私行为、以及实际配置等维度，系统梳理BLE链路层隐私保护的完整技术体系。
1. BLE地址类型体系
理解隐私保护的前提是理解BLE的地址体系。BLE设备使用48位地址，分为两大类：公共地址 和随机地址。
公共地址在设备制造时编程写入，注册于IEEE，全球唯一且终身不变。随机地址则无需IEEE注册，可在制造时编程或在运行时生成。随机地址又分为两个子类型：
静态随机地址，在设备生命周期内固定不变，或仅在设备启动时更改，但一旦进入运行状态就不再变化。
私有地址，可在运行时周期性变更，这是隐私保护得以实现的基础。私有地址进一步细分为两种：
- 不可解析私有地址（NRPA），纯粹随机生成，通常每次重连时更换，任何设备都无法将其关联回设备身份，但不支持地址过滤等高级功能；
- 可解析私有地址（RPA），这是BLE隐私保护的核心机制。
RPA最显著的特征是其最高两个比特位被固定为0b01，接收方可以通过这一特征快速识别出这是一个可解析私有地址。
2. 可解析私有地址（RPA）
2.1 RPA的结构
RPA本质上是一个经过加密变换的48位地址，由两部分构成：24位的prand 和24位的hash 。prand是一个随机数，其最高两个比特位被设置为0b01，以确保地址类型标识合法。hash部分则是通过一个名为 ah 的哈希函数，以prand和身份解析密钥（IRK） 作为输入计算得出的。
2.2 IRK：隐私保护的密钥基础
IRK是一个128位密钥，在设备配对绑定过程中通过加密链路交换。
它的角色非常明确：只有持有相同IRK的设备，才能验证并解析对方使用的RPA。未参与绑定的第三方设备即使截获了RPA，也无法通过哈希计算匹配出设备的真实身份。
2.3 RPA的生成与解析流程
生成端 ：设备使用一个随机生成的prand，结合自身持有的IRK，通过ah哈希函数计算出hash值，拼接为完整的RPA，用于广播或连接请求。
解析端 ：接收方收到一个RPA后，提取其prand部分，然后逐一尝试使用自己持有的所有IRK进行相同的哈希计算。如果对某个IRK计算出的hash值与接收到的RPA中的hash部分匹配，则解析成功，接收方即可确认该RPA来自持有同一IRK的绑定设备。
2.4 RPA的更新周期
RPA需要定期更换，以降低被追踪的风险。蓝牙核心规范推荐约15分钟的更新间隔，但具体时机由实现决定。
从Privacy 1.1到Privacy 1.2，RPA超时时间的可配置范围发生了显著变化，从固定15分钟扩展到1秒至11.5小时，为不同场景下的隐私与功耗权衡提供了更大的灵活性。
蓝牙6.1进一步引入了随机化RPA更新机制，允许在指定时间范围内随机化RPA超时，使攻击者更难以通过观察更新模式来建模设备行为。
3. 从Privacy 1.1到Privacy 1.2
BLE隐私保护机制经历了重要的架构性演进，理解这一演进是掌握整个体系的关键。
在蓝牙4.1的Privacy 1.1 中，地址解析列表由主机 维护，RPA的解析在主机层完成。这意味着控制器无法自行判断接收到的数据包是否来自可信设备，因此在使用RPA时无法实现设备过滤和定向连接广播等依赖地址识别的功能。
蓝牙4.2引入的Privacy 1.2 （又称链路层隐私 ）将解析列表和RPA解析能力下沉到链路层（即控制器侧）。这一架构变化带来了两个关键收益：
- 设备过滤成为可能。 链路层可以利用解析列表将收到的RPA解析为身份地址，再与白名单进行比对，从而实现基于设备身份的过滤。在蓝牙4.2之前，白名单的检查发生在RPA解析之前，导致使用RPA的设备无法被正确过滤；Privacy 1.2之后，链路层可以在检查远程设备身份地址是否在白名单中之前，先解析远程设备身份地址。
- 能效显著提升。 以GAP Central为例，在启用设备过滤和控制器隐私后，链路层仅将解析列表和白名单中设备的定向广播和扫描响应上报给主机，大幅减少了主机的处理负担。
4. 隐私保护在各链路层状态中的行为
链路层的操作通过一个状态机来描述，隐私保护机制在每一个状态中都有明确的行为定义。以下按照链路层的四个核心状态分别展开。
4.1 广播状态（Advertising State）
广播状态下，设备作为广播者（Advertiser）在广播信道上发送数据包。
- 控制器隐私下的广播行为。
当外设启动广播且控制器隐私已启用时，广播参数结构中的 ownAddressType 字段不再被使用。控制器始终生成一个RPA并将其作为广播地址。这意味着主机不需要显式指定使用什么地址，控制器会自动完成RPA的生成与轮换。
- 定向广播与RPA。
对于可连接定向广播，广播报文中包含广播端和目标端的RPA。在蓝牙4.2的链路层隐私机制下，链路层可以通过解析列表对RPA进行解析，从而确定该定向广播的目标是否为自身。广播端仅允许向解析列表中的设备发起定向广播，因为只有这样才能生成正确的目标RPA。
- 广播数据与RPA轮换的协同。
RPA轮换时，广播数据中包含的随机值也应同步重新生成，以防止通过广播内容与地址的关联来破坏隐私保护。
未配对设备的隐私限制。 值得注意的是，尚未与任何中心设备配对或绑定的外设，还没有启用隐私模式，因此其广播地址仍然是可追踪的。只有完成配对并交换IRK后，隐私保护才真正生效。
4.2 扫描状态（Scanning State）
扫描状态下，设备作为扫描者（Scanner）监听广播信道上的数据包。
- 控制器隐私下的扫描行为。
当中心设备在控制器隐私启用的情况下进行扫描时，控制器会主动尝试解析广播地址字段中出现的任何RPA 。如果在解析列表中找到了与某个对端IRK匹配的记录，扫描结果结构中的 advertisingAddressResolved 参数会被设置为TRUE。此时，addressType 和 address 字段不再包含空中实际看到的广播地址，而是包含被解析出的设备身份地址。应用程序可以直接使用这些身份地址字段来发起连接请求。
- 解析失败的情况。
如果 advertisingAddressResolved 等于FALSE，说明广播者使用的是公共地址、静态随机地址、NRPA，或者是一个无法解析的RPA。在这种情况下，与该设备的连接将按照未启用控制器隐私的方式发起，usePeerIdentityAddress 字段应设置为FALSE。
- 主机隐私下的扫描行为。
在主机隐私模式下，控制器不具备解析能力，所有收到的广播包（包括含RPA的包）都会原样上报给主机。主机随后在自身的绑定数据库中逐一尝试使用每个IRK进行解析，这是一个计算开销较大的过程。
- 扫描状态下的隐私风险控制。
主动扫描会发送扫描请求，这可能暴露扫描者自身的地址信息。当LE隐私已启用时，扫描者应使用RPA；如果隐私选项关闭，则应使用不可解析私有地址进行主动扫描，以避免向对端设备暴露自身身份。此外，当不需要建立连接时，使用被动扫描和非可扫描广播是避免追踪的适当方式。
4.3 发起状态（Initiating State）
发起状态下，设备作为发起者（Initiator）监听特定设备的广播包，并发送连接请求（CONNECT_REQ）以建立连接。
- 连接请求中的InitA字段。
连接请求PDU中包含发起者地址（InitA）和目标地址（TargetA）两个关键字段。在隐私保护启用的情况下，发起者的InitA应设置为RPA。链路层在构造连接请求时，如果InitA是一个RPA，需要检查它是否能够基于对端IRK进行解析。
- 控制器隐私下的发起行为。
在控制器隐私启用且对端设备在解析列表中的情况下，链路层会代表主机生成RPA 。如果控制器隐私未启用，则使用由主机生成的RPA或NRPA。在发起连接时，如果控制器能够解析对端的RPA并找到对应的身份地址，主机可以设置 usePeerIdentityAddress 为TRUE，使用身份地址来发起连接，控制器会在链路层将其翻译为正确的空中RPA。
- 主机隐私下的发起行为。
在主机隐私模式下，如果控制器不具备地址解析能力，主机需要自行将缓存的RPA填入连接请求的目标地址中。如果主机错误地使用了身份地址而非RPA，而对端正在使用RPA广播，连接尝试将无法得到响应，每次失败的连接尝试都会消耗完整的创建连接超时时间。
一个重要的约束。 链路层不应将InitA字段设置为与收到的广播PDU中的TargetA字段相同的值，以避免地址冲突。
4.4 连接状态（Connection State）
连接状态下，两个设备已建立连接，通过数据信道进行通信。连接状态可以从发起状态或广播状态进入，分别对应中心角色和外围角色。
- 连接建立后的地址解析。
当设备在控制器隐私启用的情况下建立连接时，连接事件参数结构包含 peerRpaResolved 字段。如果对端使用的是RPA且该RPA被解析列表中IRK成功解析，则 peerRpaResolved 等于TRUE，peerAddressType 和 peerAddress 字段将包含对端的身份地址，而非空中实际使用的RPA。
- RPA在连接期间的轮换。
连接期间，设备仍然需要定期更换RPA以维持隐私保护。RPA的轮换由控制器自主管理（在控制器隐私模式下），或由主机驱动（在主机隐私模式下）。连接建立时使用的RPA与后续通信中使用的RPA可能不同，但对端设备始终可以通过IRK完成解析，保证通信的连续性。
- 回连时的地址处理。
当中心设备尝试重新连接一个已绑定的外围设备时，主机需要确保使用正确的对端地址。如果控制器具备地址解析能力且该对端已在解析列表中，主机可以使用对端的身份地址，控制器会将其翻译为当前的RPA。如果解析列表中没有该对端，或者控制器不支持链路层隐私，主机需要使用缓存的RPA来发起连接，而不是身份地址。
5. 解析列表与隐私模式
5.1 解析列表
解析列表是控制器隐私的核心数据结构。当应用将某个对端设备添加到解析列表中时，需要提供该设备的身份地址和对应的IRK。此后，控制器在收到包含RPA的数据包时，会自动尝试用列表中的IRK进行解析。一旦解析成功，上报给主机的事件中携带的将是对端设备的身份地址，而非空中的RPA。
解析列表还支持设备过滤功能。链路层可以在解析RPA之后，将解析出的身份地址与白名单进行比对，仅将白名单中设备的广播和扫描响应上报给主机，从而在控制器层面完成过滤，减少主机的处理负担。
5.2 隐私模式
蓝牙5.0引入了隐私模式的概念，它定义了一个设备对来自已绑定对端的通信的接受策略，存储在解析列表的每个对端条目中。
网络隐私模式：
是默认模式。在此模式下，设备仅接受来自对端的使用私有地址（RPA或NRPA）的数据包。如果对端使用身份地址（公共地址或静态随机地址）发送，设备将不予接受。这种模式提供最强的隐私保护。
设备隐私模式：
则更为宽松。设备同时接受对端使用私有地址或身份地址发送的数据包。这在某些互操作性场景下很有用，例如对端设备可能因为某些原因暂时无法生成RPA，此时设备隐私模式可以保证通信不中断，代价是接受了一定程度的可追踪性。
6. 控制器隐私与主机隐私的对比
从蓝牙4.2开始，隐私保护可以在主机 或控制器中实现。
- 控制器隐私
将RPA的生成与解析完全下沉到控制器硬件，主机只需通过HCI命令将身份信息和IRK写入解析列表。在广播场景中，控制器始终生成RPA并以其作为广播地址；在扫描场景中，控制器主动解析广播地址中的RPA并将解析结果以身份地址形式上报主机。这种方式最大的优势是降低主机唤醒频率、节省系统功耗，同时支持基于解析列表的设备过滤功能。
- 主机隐私
则由主机侧的协议栈负责RPA的生成与解析。在某些芯片平台上，如果控制器不支持RPA列表功能，地址解析只能在主机中完成，此时依赖控制器进行地址过滤的功能将无法使用。主机隐私的灵活性更高，但功耗代价也更大。
7. 随机化RPA更新
传统的RPA更新机制采用固定超时值（默认为900秒），设备按照固定的时间间隔更换RPA。这种模式存在两个局限：
- 可预测性风险------攻击者可能通过观察RPA更新规律来建模设备行为；
- 能效问题------对可预测性要求高的应用需要由系统主机直接管理RPA的随机化，导致频繁的主机唤醒和额外功耗。
蓝牙6.1引入的随机化RPA更新特性解决了上述问题。它将RPA超时参数从固定值变为在指定时间范围内的随机值，同时允许控制器在随机时间点自主生成新的RPA，无需主机干预。这一特性在不牺牲隐私强度的情况下，显著降低了主机唤醒频率，为高隐私需求场景提供了一种兼顾安全与能效的解决方案
8. 总结
BLE链路层隐私保护是一套从地址类型设计、密钥交换、哈希解析到控制器架构协同工作的完整体系。其核心逻辑可以概括为：用IRK作为"信任凭证"，用RPA作为"一次性身份"，用解析列表作为"信任设备名册"，用隐私模式作为"接受策略"。
从链路层状态的角度来看：
- 在广播状态，控制器自动生成RPA作为广播地址，使广播者不被第三方追踪；
- 在扫描状态，控制器主动解析广播地址中的RPA，使扫描者能够以身份地址识别可信设备，同时通过过滤机制减少不必要的上报；
- 在发起状态，链路层在连接请求中使用RPA作为发起者地址，并能够将对端身份地址翻译为正确的目标RPA；
- 在连接状态，RPA持续轮换，但双方通过IRK保持对彼此身份的识别能力。
从Privacy 1.1到Privacy 1.2的架构下沉，使隐私保护从一种纯软件层面的能力演变为链路层原生的、兼顾能效的基础设施。而随机化RPA更新等新特性的加入，则在持续推动隐私保护向更细粒度、更自适应方向发展。对于BLE开发者而言，理解这套机制不仅有助于正确配置设备的隐私行为，也是在产品设计中做出合理隐私-功耗权衡的基础。