2017 年，Google 推出 Fast Pair 协议，旨在简化蓝牙设备与 Android 系统的配对流程。用户只需轻点一次，即可完成设备连接与账户同步。这套以用户体验为中心的设计理念，让 Fast Pair 在短短几年内被数十家音频厂商采纳，覆盖数亿级设备。然而，KU Leuven 大学安全研究团队的最新研究表明，这种 "便利优先" 的协议设计，恰恰成为安全盲区的根源。攻击者可在 10 至 15 秒内完成设备劫持，无需任何用户交互，便可激活麦克风、注入恶意音频，甚至将设备转化为持续跟踪受害者的定位信标。这一发现不仅揭示了单一协议层面的技术缺陷，更引发我们对整个物联网生态安全验证体系的深刻反思。
协议层设计缺陷的深层机理
Fast Pair 协议的核心问题在于其配对模式验证机制存在根本性缺陷。传统蓝牙协议要求设备必须明确进入配对模式，通常通过物理按键触发，以确保只有用户意图配对的设备才能建立连接。这层保障依赖于硬件状态与应用逻辑的配合，形成一道明确的安全边界。然而，Fast Pair 协议为了追求无感配对体验，将这一验证过程简化为设备固件层面的软件检查，而非密码学层面的身份绑定。研究人员发现，大量通过 Google 认证的设备并未正确实现这一检查逻辑，导致攻击者可向处于正常工作状态的设备发送伪造的配对请求，绕过所有安全验证步骤。
具体而言，攻击者只需获取目标设备型号对应的 Model ID 值，即可发起配对劫持。这个 ID 值可通过多种渠道获取：购买同型号设备、监听设备广播信息，或直接调用 Google 公开的 API 接口枚举所有已注册设备。攻击者使用树莓派等低成本硬件平台，在 14 米范围内即可完成整个劫持流程。一旦配对请求被设备接受，攻击者便获得对设备的完整控制权，可自由播放音频、录制环境声音，或建立持久的蓝牙连接通道。这一过程的隐蔽性在于，整个劫持发生在用户不知情的状态下，设备不会显示任何配对成功的提示信息。
攻击链的工程化实现路径
WhisperPair 攻击链的工程实现可分为三个递进阶段，每个阶段对应不同的攻击目标与技术复杂度。第一阶段是设备劫持，攻击者利用 Model ID 向目标设备发送 Fast Pair 初始请求，由于设备未正确验证配对模式状态，攻击者的设备被错误地识别为合法请求方。随后，攻击者完成标准蓝牙配对流程，建立加密会话，此时原用户与设备的连接被强制断开。这种劫持方式对攻击设备无特殊要求，市售的蓝牙适配器配合开源工具即可完成全部操作。
第二阶段涉及音频注入与麦克风窃听。成功劫持后，攻击者获得与设备音频子系统交互的完整权限，可向耳机或音箱发送任意音频数据，音量不受设备原有限制。更严重的是，带麦克风功能的耳机和耳塞会被攻击者激活，周围的对话和环境声音被实时传输至攻击设备。在研究人员演示的场景中，受害者在通勤途中佩戴耳机听音乐时，攻击者可在数秒内接管设备并开始录音，整个过程无任何物理接触，也无需设备进入特殊模式。这种攻击向量对隐私的威胁极为直接，受害者的私密对话可能在毫无察觉的情况下被持续监听。
第三阶段是账户绑定与位置追踪，这是 WhisperPair 攻击中最具隐蔽性的部分。Fast Pair 协议与 Google Find Hub 网络深度集成，用于帮助用户定位丢失的蓝牙设备。协议设计将首次与设备配对的 Android 账户标记为 "所有者账户"，这一身份决定了设备在 Find Hub 网络中的归属关系。研究人员发现，如果受害者的设备从未与 Android 系统配对过，例如仅连接过 iPhone，攻击者在劫持设备后可将自己的 Google 账户与设备绑定，从而将设备注册到 Find Hub 网络中。此后，无论设备实际连接至何处，其位置信息都会通过周围 Android 设备的蓝牙广播被上传至 Find Hub，攻击者可在自己的 Google 账户中实时查看受害者位置。
这种追踪方式的技术持续性远超传统蓝牙定位。由于 Find Hub 采用众包定位机制，即使攻击者与受害者相距数公里，只要周围有开启蓝牙的 Android 设备，受害者的位置就会被这些设备 "无意中" 采集并上报。研究人员指出，Google 和 Apple 虽已部署防跟踪告警机制，但这类警告存在明显延迟，可能需要 48 小时才会触发，且警告内容会将追踪设备标记为受害者自己的设备，导致用户误认为是系统误报而忽略。这意味着攻击者可能在数天甚至数周内持续追踪目标，而受害者毫无察觉。
行业认证体系失效的警示意义
WhisperPair 漏洞的广泛影响远超单一产品或厂商的安全问题。研究团队测试了来自 16 家厂商、涵盖 17 种不同蓝牙芯片的 25 款商业设备，发现其中 68% 存在可被劫持的漏洞。这意味着问题的根源并非某家厂商的实现失误，而是整个 Fast Pair 生态系统在安全验证环节存在系统性失效。更值得警惕的是，所有接受测试的设备均已通过 Google 的 Fast Pair 认证流程，包括使用 Google 提供的 Validator 应用进行自测，以及在 Google 指定实验室进行的最终验证。然而，这些验证机制均未能检测出配对模式检查的缺失，认证过程形同虚设。
这一事件暴露出物联网设备安全验证的深层困境。设备厂商和芯片制造商在实现 Fast Pair 协议时缺乏统一的安全规范，协议规范本身也未强制要求密码学层面的配对验证。Google 的 Validator 工具主要用于验证核心功能的可用性，而非安全属性的正确实现。当便利性成为产品设计的首要目标时，安全往往被降级为 "nice to have" 的可选项。芯片供应商在底层固件中的非标准配置进一步加剧了这一问题，Xiaomi 在回应中承认，其 Redmi Buds 系列设备的漏洞源于芯片供应商提供的 Fast Pair 协议配置不符合规范要求。
从技术修复角度，研究团队提出了 IntentPair 方案作为长期解决思路。IntentPair 的核心思想是将用户的物理操作 —— 按下配对按钮 —— 以密码学方式绑定到连接密钥生成过程中。设备只有在检测到按钮被按下后，才会生成与当前配对请求匹配的加密密钥，否则即使收到伪造的配对请求，因无法生成正确的密钥，攻击也将自然失败。这种设计从根本上将安全验证从 "软件自检" 提升为 "密码学证明"，不依赖设备厂商的固件实现质量。短期来看，Google 和各厂商已发布软件更新修复具体漏洞，但更新推送依赖于用户主动安装厂商应用程序，这一环节的覆盖率通常极低。
工程实践中的缓解策略与监控建议
对于无法立即更新的设备，有几种缓解策略可在一定程度上降低风险。工厂重置可清除攻击者已建立的配对关系，但这只是临时措施，攻击者只需重新实施劫持即可恢复控制。更重要的是，用户应警惕任何异常的蓝牙配对提示，即使设备未主动发起配对，攻击者仍可能利用协议缺陷建立连接。由于大多数 Fast Pair 设备无法在系统设置中关闭该功能，用户在公共场合尤其是拥挤的交通环境中应更加注意音频设备的行为异常，例如音量突然变化或音频播放出现卡顿。
从企业安全运维角度，建议将蓝牙音频设备纳入资产管理范围，定期核查设备固件版本，并在可能的范围内部署设备管理解决方案。安全团队可在网络层面监控异常的蓝牙配对流量，尽管这类检测在消费级设备上实现难度较高。对于高安全敏感场景，考虑限制蓝牙音频设备的使用场景，避免在讨论敏感信息的场合佩戴可能存在漏洞的设备。同时，关注 Google 和设备厂商发布的安全公告，建立漏洞响应流程，确保在补丁发布后能够及时覆盖受影响设备。
WhisperPair 事件为整个行业敲响警钟：在物联网设备快速普及的背景下，便利性与安全性的平衡需要被重新审视。当数十亿设备依赖同一协议实现无感连接时，协议层面的设计缺陷会产生连锁反应，影响数亿用户的安全。安全不应被视为功能的附属品，而应在协议设计阶段就被置于核心位置。IntentPair 所代表的密码学强制验证思路，或许代表了下一代配对协议的发展方向。唯有将安全属性写入协议的技术规范，而非依赖于设备厂商的自觉实现，才能从根本上遏制类似 WhisperPair 的系统性风险。
资料来源：WhisperPair 官方研究站点（whisperpair.eu）、KU Leuven 工程学部新闻公告。