第2章 BLE配对机制详解

课程目录第2章 BLE配对机制详解

BLE配对机制详解：从流程到实战

BLE配对，说白了就是两个蓝牙设备互相确认身份、协商密钥的过程。我做了这么多年蓝牙安全，见过太多开发者把配对当成"点一下确认就行"的简单操作。嗯，如果你也这么想，那今天这章可能会让你改观。

先说说我的一个教训。几年前有个IoT项目，设备端用了Just Works配对，结果测试时发现数据包能被轻易抓取并重放。当时我就在想——如果当初选了合适的配对模式，这坑根本不用踩。

BLE配对不是一步到位的。它分三个阶段，每个阶段都有明确的任务。我个人习惯把这三个阶段比作"握手→协商→加密"。

你想想看，Phase 1就像两个人见面先亮出身份——"我能显示数字"、"我能输入PIN码"。Phase 2才是真正的"对暗号"环节。Phase 3则是把长期密钥存下来，下次见面就不用再走一遍完整流程了。

关键点：Phase 2生成的STK（Short Term Key）只用于本次会话的加密。真正的长期安全，靠的是Phase 3分发的LTK（Long Term Key）。

BLE定义了四种配对模式。选哪种，取决于设备的IO能力和你的安全需求。我建议你根据实际场景来选，别图省事就全用Just Works。

Just Works，名字就告诉你——"只管干就完了"。它不需要用户交互，没有PIN码，没有数字比对。说白了就是：两个设备直接生成密钥，然后加密通信。

我在项目中遇到过，很多智能灯泡、传感器都用这个模式。为什么？因为设备没有屏幕也没有键盘，你没法让用户输入什么东西。

注意：Just Works虽然方便，但它不提供中间人攻击（MITM）防护。攻击者可以在配对过程中插入自己的设备，拦截或篡改通信。我曾经在一个智能门锁项目里看到厂商用Just Works，结果测试时我用一个树莓派就完成了MITM攻击——门锁直接被我控制了。

Passkey Entry要求一个设备显示6位数字，另一个设备输入这6位数字。比如你的手机显示"123456"，你在键盘上输入这串数字，配对就完成了。

这种模式的好处是：它提供了MITM防护。因为攻击者不知道你输入的密码是什么，他没法伪造配对。

嗯，这里要注意：Passkey Entry的6位数字是随机生成的，每次配对都不一样。我曾经见过一个产品，它的Passkey是固定的"000000"——这跟没设密码有什么区别？

Numeric Comparison是BLE配对中最安全的一种模式。两个设备各自计算出一个6位数字，然后显示在屏幕上。用户需要确认两个数字是否一致。

为什么会这样？因为攻击者虽然能看到通信内容，但他没法伪造出相同的数字。只有真正的配对双方才能计算出匹配的验证码。

我记得有一次帮客户做安全审计，他们的医疗设备用了Numeric Comparison。我问他们为什么选这个，他们说："病人的生命数据，不能冒任何风险。" 嗯，这个选择很对。

OOB（Out of Band）配对，就是通过蓝牙以外的通道交换配对信息。比如用NFC碰一下、扫个二维码、或者用Wi-Fi直连。

OOB的好处是：攻击者必须同时攻破蓝牙和另一个通道才能完成MITM。这难度就大多了。

我在一个智能家居项目中用过OOB——用户用手机NFC碰一下智能音箱，配对就完成了。体验很好，安全性也高。但要注意，OOB通道本身必须安全。如果你用了一个不加密的二维码，那跟没用OOB一样。

我的建议：如果设备有屏幕和输入能力，优先用Numeric Comparison。如果只有一方有屏幕，用Passkey Entry。如果双方都没有交互能力，只能用Just Works——但一定要在应用层做额外的安全加固。

下面这张图是我自己整理的，帮你快速判断该用哪种配对模式：

最后，我把四种模式的核心差异整理成一张表，方便你对照：

配对模式	MITM防护	用户交互	适用场景
Just Works	❌ 无	无需交互	无屏幕/键盘的设备（传感器、灯泡）
Passkey Entry	✅ 有	一方显示，一方输入	智能锁、键盘+屏幕设备
Numeric Comparison	✅ 强	双方显示，用户确认	手机+手表、医疗设备
OOB	✅ 强（取决于OOB通道）	通过其他通道交换	NFC碰触配对、扫码配对

避坑指南：我曾经在一个项目中看到开发者把Passkey Entry的密钥写死在代码里。结果呢？攻击者反编译APK就拿到了密钥，所有设备都能被任意配对。记住：密钥必须动态生成，永远不要硬编码。

好了，这一章的内容就到这里。配对机制是BLE安全的地基，选对了模式，后面的加密通信才有意义。下一章我们会深入Phase 2的密钥生成细节，看看STK和LTK到底是怎么算出来的。