文章总结： NDSS2026论文BLERP揭示BLE重配对机制缺陷：攻击者无需破解原密钥，通过冒充设备发起未认证安全请求，即可诱使目标用新密钥覆盖旧密钥实现接管。实测影响多款主流系统。但研究未充分探讨RPA地址机制下的身份识别难题，未知IRK时攻击链难闭环。建议厂商重配对时强制校验旧密钥。 综合评分： 87 文章分类： 漏洞分析,IoT安全,移动安全,网络安全

G.O.S.S.I.P 特别推荐 2026-07-27 BLERP 通过重配对给BLE“换锁”

Chapoly Chapoly

安全研究GoSSIP

2026年7月27日 22:36 德国

在小说阅读器读本章

去阅读

TL;DR：BLERP 发现，攻击者不必破解 BLE 设备原有的配对密钥。只要能冒充其中一方并诱导设备重新配对，就可能让目标主动用攻击者的新密钥覆盖旧密钥。不过，论文对一个关键前提讨论不足：在设备严格使用 RPA、攻击者又不知道 IRK 时，攻击者是否还能先被识别成原来的设备？

我们平时使用蓝牙键盘、耳机或者智能手表时，大概不会对“配对”这件事想太多。屏幕上确认一次数字，或者干脆点一下连接，之后设备就会自动重连，仿佛双方交换了信物，从此正式确立关系。

这里我们先给 Bluetooth 一个面子，假设用户最初的配对过程完全安全：没有攻击者混进来，长期密钥也没有泄露。这样就真的安全了吗？

来自 NDSS 2026 的论文 BLERP: BLE Re-Pairing Attacks and Defenses 给出了一个有些反直觉的答案：攻击者并不需要破解原来的密钥，也可能把其中一台设备从原有的信任关系中“挤出去”，自己取而代之。

问题出在一个平时很少有人注意的功能：re-pairing，也就是重新配对。

BLE 允许已经配对的设备再次执行 pairing，并用一把新密钥覆盖原来的长期密钥。这个功能听起来很合理：设备可能需要提升安全等级，或者在某些情况下重新建立信任。

但 BLERP 的作者发现了一个设计缺陷：在 BLE 的 re-pairing 流程中，“更换旧密钥”这件事，并没有被旧密钥充分认证。

换句话说，攻击者不需要偷走钥匙。他只需要让设备接受一句话：

旧钥匙不用了，我们重新换一把吧。

原主人手里的钥匙仍然完好无损，只不过设备已经不认它了。

先冒充键盘，再让电脑主动换掉密钥

论文介绍的第一个核心攻击叫作 Peripheral Impersonation。

假设 Alice 是一台电脑，Bob 是已经和它配对的蓝牙键盘，Charlie 是攻击者。

1. Charlie 首先复刻 Bob 的地址、名称和设备类型，伪装成 Bob 进行广播。Alice 一旦连接过来，就会按照正常流程，尝试使用原来的长期密钥恢复加密连接。
2. Charlie 当然不知道这把密钥，于是故意拒绝 Alice 发来的 Encryption Request，让旧会话建立失败。
3. 接下来才是整个攻击最巧妙的地方：Charlie 向 Alice 发送一条 Security Request，声称自己希望使用更高的安全等级重新配对。但这条请求并没有被旧密钥认证。Alice 只看到对方提出了“安全升级”，却无法确认发出请求的真是 Bob。
4. 于是，Alice 可能真的和 Charlie 重新配对，并用新密钥覆盖原来的密钥。Charlie 没有破解 Bob 的密钥，却继承了 Bob 原本拥有的权限。真正的 Bob 之后重新上线，因为手里拿的还是旧密钥，反而无法再连接 Alice。

反过来冒充手机，把手表“接管”过来

第二个攻击叫作 Central Impersonation，流程更加直接。

这一次，Alice 是手机，Bob 是已经与它配对的智能手表。

1. 攻击者 Charlie 冒充 Alice 连接 Bob，随后直接发送新的 Pairing Request。Bob 并不会先使用旧密钥确认：发起请求的真是原来的 Alice。
2. 如果 Bob 接受重新配对，它就会生成一把与 Charlie 共享的新密钥，并覆盖原来与 Alice 共享的密钥。
3. 从此，Bob 会把 Charlie 当成 Alice。Charlie 继承原手机的访问权限，而真正的手机回来后，手里只剩下一把已经作废的旧密钥。

值得注意的是，这两种攻击都不要求两台合法设备同时在线。攻击电脑时，真正的键盘可以关机；攻击手表时，真正的手机可以不在通信范围内。合法设备不在场，攻击者反而更不容易遇到连接竞争。

论文还进一步把两种攻击组合起来，构造了 single-channel 和 double-channel MitM。不过，要理解论文最核心的发现，记住前面两种“换锁”攻击就足够了：

攻击者没有恢复旧密钥，而是让目标主动抛弃了旧密钥。

这只是纸面上的协议问题吗？

作者开发了基于 NimBLE、Scapy 和 nRF52840 的攻击工具，并测试了 22 个目标，覆盖 macOS、iOS、Android、Windows、Linux、多个嵌入式 BLE 协议栈，以及键盘、鼠标、游戏手柄和 Garmin 手表。

测试范围横跨 Bluetooth 4.2 至 5.4，也包括 Secure Connections、MitM protection 和 Secure Connections Only 等较强配置。

结果并不是“所有蓝牙设备都能零点击接管”，但攻击面确实相当广：

• 论文测试的 macOS、iOS 和多款 Android 设备可以受到 Peripheral Impersonation 攻击；
• 多款 Logitech 外设和 Xbox 手柄可以受到 Central Impersonation 攻击；
• Windows、Linux 和 ESP32 会在旧密钥加密失败后主动断开，因此论文默认的 Peripheral Impersonation 流程无法继续；
• Garmin Vivoactive 5 强制使用 Secure Connections 和 Numeric Comparison，因此攻击需要用户完成认证式确认，难度明显更高。

键盘、鼠标等交互能力有限的设备可能不需要用户操作；手机和电脑通常需要点击一次普通确认框。论文将其分别称为 0-click 和 1-click。

不过，这个攻击还有一个没有讲清楚的前提

BLERP 的完整攻击链其实分成两步：

1. 先让目标把攻击者识别成原来的设备；
2. 再触发 re-pairing，用新密钥覆盖旧密钥。

论文主要分析了第二步。它的公开 Artifact 也很好地证明了：只要攻击者能够复制一个会被目标识别为原 peer 的地址，re-pairing 就可能被滥用。

但论文几乎把第一步当成了理所当然的准备工作，也没有将它作为 limitation 认真展开。

如果设备使用固定的 Public Address 或 Static Random Address，复制地址确实相对容易。但许多 BLE 设备为了防止被长期跟踪，会使用 Resolvable Private Address，简称 RPA。

RPA=hash(IRK,prand) CONCAT prand

RPA 不是一个长期固定的地址。它由设备的 Identity Resolving Key，也就是 IRK，配合一个随机数生成。

已经配对的设备保存了对方的 IRK，因此即使地址不断变化，也能把它解析回同一个设备身份 （它会把自己配对的所有IRK全部试一遍）。攻击者如果不知道 IRK，就无法生成一个能被对端识别为原设备的新 RPA。

考虑这样一个场景：

• 手机和手表已经正常配对；
• 手机连接手表时使用 RPA；
• 手表保存了手机的 IRK，并通过 resolving list 识别手机；
• 手机现在不在附近；
• 攻击者不知道手机的 IRK；
• 攻击者之前也没有监听过手机使用的 RPA。

简单来说，手机的地址虽然会不断变化，手表却能凭配对时保存的 IRK 把它认回来。而攻击者没有 IRK，用自己的地址连接时，通常只会被当作陌生设备，甚至可能直接被拒绝，而不是被当成原来的手机。

这并不推翻 BLERP 的核心发现。BLERP 证明了：re-pairing 在替换一段已经建立的信任关系时，没有得到旧密钥的充分授权。但要把这个协议问题变成一条完整的现实攻击链，攻击者还需要先跨过身份识别这一关。

在严格使用 RPA 的场景中，他仍然需要回答另一个问题：

怎么让手表相信，我就是原来那台手机？

论文链接：

https://www.ndss-symposium.org/wp-content/uploads/2026-f121-paper.pdf

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全研究GoSSIP Chapoly Chapoly《G.O.S.S.I.P 特别推荐 2026-07-27 BLERP 通过重配对给BLE“换锁”》