7、Passkey Entry漏洞：PIN码暴力破解、Passkey输入监听、Passkey重放攻击、安全增强方案

Passkey Entry，说白了就是蓝牙配对时让你在设备上输一串数字PIN码的那种方式。很多物联网设备、智能锁、健康手环都在用。嗯，这个机制看起来简单，但坑特别多。我这些年做蓝牙安全审计，Passkey Entry相关的漏洞几乎占了BLE漏洞的三分之一。

为什么会这样？因为Passkey Entry本质上依赖一个6位数字的PIN码。你想想看，6位数字，总共才100万种组合。对于现代计算设备来说，暴力破解根本不是问题。更可怕的是，很多厂商为了用户体验，把PIN码设成了固定值，比如"000000"或"123456"——我在项目中遇到过不止一次。

7.1 PIN码暴力破解

暴力破解Passkey Entry的PIN码，说白了就是穷举所有可能的6位数字组合。但这里有个关键点：蓝牙协议本身对尝试次数有限制吗？

答案是：没有强制限制。蓝牙Core Spec只定义了配对流程，但没有规定设备必须限制失败次数。这就给了攻击者可乘之机。

攻击流程其实很简单：

1. 攻击者伪装成合法设备，发起配对请求
2. 进入Passkey Entry模式，等待用户输入PIN码
3. 攻击者开始穷举：从000000开始，每次尝试一个PIN码
4. 如果配对成功，说明猜中了；如果失败，继续下一个

你可能觉得这很慢？实际上，利用现代蓝牙适配器和优化后的协议栈，每秒可以尝试50-100次。100万次组合，最多也就几个小时。我曾经在测试一款智能门锁时，用Python脚本配合nRF52840 DK，3小时就破解了它的固定PIN码"888888"。

7.2 Passkey输入监听

这个漏洞更隐蔽。Passkey Entry要求用户在设备上输入PIN码，但输入过程本身可能被监听。

攻击方式主要有两种：

• 侧信道攻击： 通过分析按键时间、按键声音、甚至电磁辐射来推断输入的PIN码
• 中间人监听： 攻击者位于两个配对设备之间，截获并分析Passkey Entry过程中的加密数据包

我记得有一次帮客户做智能手表的安全评估。手表和手机配对时，用户需要在手表上输入手机上显示的6位数字。但手表的触摸屏特别小，输入时手指会遮挡屏幕。用户不得不慢慢按，每个数字间隔1-2秒。攻击者只要在附近用高灵敏度麦克风录制按键声音，就能通过声音特征还原出PIN码。嗯，这听起来像电影情节，但实际测试中成功率超过70%。

7.3 Passkey重放攻击

重放攻击，说白了就是攻击者把之前截获的合法配对数据包重新发送一遍，试图欺骗设备建立连接。

Passkey Entry的重放攻击有个特殊之处：它依赖于Short Term Key（STK）的生成过程。STK是由PIN码和两个随机数（Mrand、Srand）共同计算得出的。如果攻击者能截获一次完整的配对过程，就能拿到这些随机数。

攻击步骤：

1. 攻击者监听一次合法的Passkey Entry配对过程
2. 记录下Mrand、Srand以及加密后的数据包
3. 攻击者伪造设备身份，重放之前截获的数据包
4. 如果目标设备没有验证时间戳或随机数新鲜度，就可能被欺骗

这里有个关键点：蓝牙4.0/4.1的Passkey Entry实现中，随机数生成器的质量参差不齐。有些设备用伪随机数生成器（PRNG），种子是固定的。这意味着每次配对的随机数其实是可以预测的。我在测试一款国产蓝牙耳机时发现，它每次配对生成的Mrand居然完全一样——这等于把大门敞开了。

7.4 安全增强方案

说了这么多漏洞，那怎么修？我根据自己的项目经验，总结了几条实用的增强方案：

7.4.1 动态PIN码生成

不要用固定PIN码。每次配对时，由设备端生成一个随机6位数字，显示在设备屏幕上，用户在手机端输入。这样即使攻击者破解了一次PIN码，下一次又变了。

// 伪代码示例：动态PIN码生成
uint32_t generate_dynamic_pin() {
    // 使用硬件随机数生成器
    uint32_t random_value = hw_random_generator();
    // 取模得到6位数字（000000-999999）
    return random_value % 1000000;
}

7.4.2 增加重试延迟和锁定机制

这个最简单也最有效。每次PIN码输入失败后，增加指数级延迟：第一次失败等1秒，第二次等2秒，第三次等4秒...连续失败5次后锁定设备30分钟。

失败次数	延迟时间	锁定状态
1	1秒	正常
2	2秒	正常
3	4秒	正常
4	8秒	正常
5	30分钟锁定	锁定

我曾经帮一家智能锁厂商做过方案，加了重试延迟后，暴力破解100万次PIN码的时间从3小时变成了理论上的3年多——攻击者基本放弃了。

7.4.3 使用OOB（带外）通道传输PIN码

PIN码不通过蓝牙传输，而是通过其他通道（如NFC、二维码、声波）传递给用户。这样攻击者即使监听了蓝牙信道，也拿不到PIN码。

7.4.4 升级到LE Secure Connections

蓝牙4.2引入了LE Secure Connections，使用ECDH（椭圆曲线Diffie-Hellman）密钥交换。Passkey Entry在Secure Connections模式下，PIN码只用于验证，不直接参与密钥生成。即使PIN码被破解，攻击者也拿不到长期密钥。

嗯，这里要提醒一下：很多老设备不支持LE Secure Connections。如果你在维护一个蓝牙4.0/4.1的产品，建议尽快升级硬件或至少打上安全补丁。

7.5 知识体系总览

下面这张图总结了Passkey Entry漏洞的核心攻击面和防御措施：

说实话，Passkey Entry这个机制本身设计得不算差，问题出在实现层面。很多厂商为了省成本，直接拿参考设计改一改就量产，安全测试基本没做。我建议你在做蓝牙产品时，至少把上面提到的四点增强方案实现两到三个。别等到出了安全事件再补救，那时候就晚了。

---

公众号:蓝海资料掘金营，微信deep3321