文章目录
- 文章背景介绍
- 文章中的问题介绍
- 问题处理状态
-
- [一、2021 年论文提出的修复方案（§VIII-B）](#一、2021 年论文提出的修复方案（§VIII-B）)
- [二、Bluetooth SIG 实际做了什么](#二、Bluetooth SIG 实际做了什么)
- [三、2025 年跟进：SIG 提出的修复方案又被发现有问题](#三、2025 年跟进：SIG 提出的修复方案又被发现有问题)
- 四、厂商层面实际可用的缓解
文章背景介绍
这篇论文的全名是 "Method Confusion Attack on Bluetooth Pairing"，由慕尼黑工业大学的 Maximilian von Tschirschnitz、Ludwig Peuckert、Fabian Franzen 和 Jens Grossklags 发表，被 IEEE S&P 2021（安全领域的顶会）接收，对应 CVE-2020-10134。
文章中的问题介绍
蓝牙设备首次配对时需要"建立信任"------双方协商一个长期密钥，防止被窃听或篡改。蓝牙规范提供了多种配对方法（Association Model），从弱到强依次是：
| 方法 | 用户参与 | 防 MitM |
|---|---|---|
| Just Works (JW) | 无 | 否 |
| Numeric Comparison (NC) | 双方屏幕各显示 6 位数字，用户比对后点确认 | 是 |
| Passkey Entry (PE) | 一端显示 6 位数字，用户输入到另一端 | 是 |
| Out-of-Band (OOB) | 通过 NFC 等带外通道 | 是 |
| NC 和 PE 是蓝牙最高安全模式下仅有的两种防中间人（MitM）的方法，也是论文的攻击目标。 |
核心发现：方法混淆
作者发现了一个协议级设计缺陷：蓝牙配对流程的三个阶段（特性交换、公钥交换、认证）中，没有任何一个阶段验证双方实际执行的是不是同一种 Association Model。
同时 NC 和 PE 都产生 6 位十进制数，形式完全相同。这意味着攻击者可以做一件事------
让设备 A 以为自己在跑 NC（屏幕显示 6 位数字，等用户点确认），同时让设备 B 以为自己在跑 PE（弹出一个输入框让用户输数字）。用户看到的界面跟一次正常的 PE 配对几乎无法区分，于是把 A 屏幕上的数字输进 B 的输入框。
攻击者就拿到了两个配对会话各自的密钥，稳定驻留在中间人位置，能解密、篡改、中继双方后续所有通信。
论文作者自己的原话（§I）：
"The cryptography of each single pairing method itself is not broken by our attack."
NC 的密码学没被攻破，PE 的也没被攻破。被攻破的是两种方法之间的边界------协议从来不检查对端到底在跑哪个方法。
实验验证
作者用开源蓝牙栈 BTstack + CSR dongle 搭了一套端到端的攻击框架（BThack），配合三个 micro:bit 做广播压制，在以下设备上验证：
1、实验室测试：两种 IOCap 组合（PoN / NoP）均成功
2、生产设备测试：OnePlus 7 Pro、iPhone 11、Thinkpad W540 作为发起端；Samsung Galaxy Watch 42mm（NC 端，PoN）和 Reiner SCT tanJack 金融 TAN 生成器（PE 端，NoP）作为响应端------全部被攻下
3、用户研究：40 名参与者中 37 人（92.5%） 完成了被攻击的配对流程，0 人识破攻击；失败的 3 人以为是自己的操作失误或蓝牙连接问题
攻击的硬前提
不是所有场景都能被攻击，需要同时满足：
1、IOCap 不对称：一边只能显示（DisplayYesNo → NC），另一边有键盘能输入（KeyboardOnly / KeyboardDisplay → PE）。双方都是 DisplayYesNo 时，攻击不适用（论文 Fig. 9 矩阵明确标注 "Attack not applicable"）
2、首次配对（Trust on First Use）或已删除旧绑定
3、攻击者在无线范围内，必要时压制真设备的广播
4、用户把 NC 显示的数字输进了对面的 passkey 框
影响范围
1、BLE 的 LE Secure Connections 和 BR/EDR 的 Secure Simple Pairing / Secure Connections 都受影响
2、所有使用 NC 或 PE 做 MitM 保护的蓝牙设备都潜在暴露
3、论文估算了智能手表市场（Samsung/Garmin/Fossil 约 12-15% 份额）和车载多媒体系统（2019 年销量超 830 万辆）都依赖蓝牙 MitM 保护
问题处理状态
现状是这样的：协议层面至今没有根治，应用层有缓解措施，但 Bluetooth SIG 自己提出的修复方案被原团队 2025 年又发现还有问题。
一、2021 年论文提出的修复方案（§VIII-B）
作者给了两条路：
| 方案 | 做法 | 代价 |
|---|---|---|
| LSB 标记法 | 让 PE 的 passkey 最低位恒为 1，NC 的值最低位恒为 0；收到值的一方检查最低位，发现方法错配就中止配对 | 20-bit 值空间从 1,000,000 降到 500,000，在线猜中概率翻倍（作者认为仍然可接受） |
| 值空间拆分 | 比如 PE 只用 5 位拉丁字母、NC 只用 6 位数字，两组互不相交 | 改动幅度大，需要改协议和设备接口，向后兼容更难 |
二、Bluetooth SIG 实际做了什么
根据 Bluetooth SIG 官方声明（bluetooth.com/security/method-vulnerability/）和论文 §X：
1、没有批准把作者的修复写进规范------理由是不遵循新指引的设备会导致 50% 的连接尝试失败（向后兼容问题），邮件摘录日期 2020-03-12
2、推荐的应用层缓解：在用户界面或文档里加文字警告，"不要把这个数字输入到另一台设备上"------这相当于把防御责任推给了用户
3、通过 CERT/CC（VU#534195）向成员通报，鼓励各厂商自行打补丁
4、Google 和 Apple 都表示"正在处理"但没有公开细节
5、所以 CVE-2020-10134 至今在协议规范层面仍然是一个 open issue------SIG 选了"通知 + 建议"而不是"改规范"。
三、2025 年跟进：SIG 提出的修复方案又被发现有问题
同一作者团队（von Tschirschnitz 等）在 NDSS 2025 发表了一篇 "Rediscovering Method Confusion in Proposed Security Fixes for Bluetooth"（DOI 10.14722/ndss.2025.240310），标题本身就是结论
1、他们回头检查了 Bluetooth SIG 后续针对方法混淆提出的安全修复方案
2、发现 SIG 的修复方案仍然存在方法混淆漏洞------攻击者依然可以在修复后的协议下完成混淆
3、他们提出了一种新的配对方法叫 Extended Numeric Comparison（XNC），把通用的 NC 方案改造为能从根本上区分 Association Model 的版本
也就是说，截至 2025 年，协议级的彻底修复仍未落地，原团队还在持续推动。
四、厂商层面实际可用的缓解
虽然协议没改，但厂商可以自行堵住：
1、固定配对方法（论文 §VIII-A/1）：如果两端是自家产品互配，直接用 IOCap 把 Association Model 锁死成单一方法（比如只走 NC 不走 PE），混淆的前提就不存在了。Apple Watch 走 OOB 配对就绕开了这个问题。
2、UI 热修（§VIII-A/2）：在 NC 对话框里明确写上"请勿将此数字输入任何地方"，并做视觉区分（颜色、图标、不同的对话框样式）。论文引 Uzun 等的用户研究说明清晰的措辞确实能显著提升用户警觉。
3、应用层加密：在蓝牙加密之上再加一层端到端加密（比如某些金融设备或 IoT 平台的做法），即使蓝牙层被 MitM 了也拿不到明文。