📚 课程目录第3章蓝牙配对与绑定

3、蓝牙配对与绑定：配对机制（Just Works、Passkey Entry、OOB）、绑定与密钥存储、MITM保护与安全等级

蓝牙配对，说白了就是两个设备互相确认身份、协商密钥的过程。很多工程师觉得配对就是“点一下连接”，其实里面的门道不少。我最早做蓝牙项目时，就因为在配对模式上选错了，导致产品死活连不上手机——后来才发现是 Just Works 和 Passkey Entry 的兼容性问题。

这一节，咱们把配对绑定的核心机制拆开揉碎。你搞懂了这些，后面调试连接问题会顺手很多。

蓝牙规范定义了三种配对方式。选哪种，取决于你的设备有没有输入输出能力。

配对方式	IO能力要求	用户交互	MITM保护	典型场景
Just Works	无	无	无	耳机、传感器、灯泡
Passkey Entry	一方显示，一方输入	确认6位数字	有	手机配键盘、门锁
OOB（带外）	NFC/二维码等通道	碰一碰或扫码	有（取决于OOB通道）	快速配对、高安全场景

Just Works 不需要用户做任何操作。设备之间自动完成密钥交换。嗯，这里要注意——它其实不提供中间人攻击（MITM）保护。

为什么叫“Just Works”？因为它真的就是“直接工作”。两个设备建立连接后，蓝牙协议栈自动走完配对流程，用户完全无感知。

⚠️ 安全警告：

Just Works 虽然方便，但攻击者可以在配对过程中插入伪造设备。我曾在一次安全审计中，用一台树莓派配合蓝牙嗅探器，成功劫持了 Just Works 配对的智能灯泡控制权。如果你的产品涉及门锁、支付等场景，千万别用 Just Works。

Passkey Entry 要求一方显示一个6位数字，另一方输入这个数字。这个数字是临时生成的，每次配对都不一样。

它的核心逻辑是：攻击者虽然能听到蓝牙空口上的数据包，但他看不到屏幕上显示的数字。所以只要用户确认数字一致，就能保证中间没有人在捣鬼。

我在项目中遇到过一个问题：某款智能门锁用 Passkey Entry 配对，但手机端总是提示“密钥不匹配”。查了半天，发现是门锁的显示屏刷新率太低，用户看到的数字其实是上一轮的。嗯，这种硬件问题，协议栈可不会帮你兜底。

💡 实战建议：

Passkey Entry 的6位数字是随机生成的，不要用固定密码。我曾经见过某厂商把 Passkey 写死在固件里——那跟没配对有什么区别？

OOB 的意思是“带外”——通过蓝牙之外的通道交换配对信息。最常见的做法是用 NFC 碰一碰，或者扫二维码。

为什么 OOB 更安全？因为攻击者要同时攻破蓝牙通道和 OOB 通道，难度大得多。比如你用手机扫设备上的二维码，二维码里包含了蓝牙配对所需的公钥和随机数。攻击者能嗅探蓝牙，但他看不到你手机摄像头里的二维码。

我做过一个项目，用 OOB 配合二维码实现“扫码即配”。用户体验很好，但要注意二维码的生成和解析必须可靠。有一次二维码里的数据编码格式不对，导致配对失败——折腾了两天才发现是字符串末尾多了个换行符。

配对是一次性的。绑定是把配对产生的密钥存下来，下次连接时直接复用。

绑定机制的核心是：设备把配对过程中协商出来的 长期密钥（LTK）、身份解析密钥（IRK） 等安全凭证写入非易失性存储。下次两台设备再见面时，直接拿存储的密钥做加密连接，不用重新配对。

🔑 绑定存储的关键数据：

存储位置通常是芯片内部的 Flash 或 NVRAM。我建议你把绑定信息放在一个独立分区，避免固件升级时被擦掉。曾经有客户反馈“每次升级都要重新配对”，一查就是存储分区规划出了问题。

MITM（中间人攻击）是蓝牙配对中最常见的威胁。攻击者伪装成合法设备，截获并篡改通信内容。

蓝牙规范定义了四个安全等级，从低到高：

安全等级	配对方式	加密	MITM保护	适用场景
Level 1	无配对	无	无	广播、非敏感数据
Level 2	Just Works	有	无	普通消费电子
Level 3	Passkey Entry / OOB	有	有	门锁、支付设备
Level 4	LE Secure Connections + Passkey/OOB	有（ECDH）	有	医疗、金融等高安全场景

Level 4 是蓝牙 4.2 引入的 LE Secure Connections，使用椭圆曲线 Diffie-Hellman（ECDH）密钥交换。说白了，就是比传统配对方式多了一层非对称加密，安全性上了一个台阶。

我个人的习惯是：只要产品涉及用户隐私或财产安全，至少做到 Level 3。Level 2 的 Just Works 虽然开发简单，但风险太大。你想想看，一个智能门锁如果只用 Just Works，攻击者在 10 米范围内就能轻松配对成功——这跟没锁有什么区别？

下面这张图把配对绑定的完整流程串起来了。从设备发现开始，到密钥存储结束，每一步都对应着蓝牙协议栈里的具体操作。

做蓝牙配对开发，有几个地方特别容易出问题。我列出来，你遇到类似情况可以少走弯路。

⚠️ 常见坑1：绑定信息丢失

设备断电或固件升级后，绑定信息被擦除。用户需要重新配对。解决方案：把绑定信息放在独立存储分区，升级时保留该分区。

⚠️ 常见坑2：IO能力声明不一致

两个设备都声明“无输入无输出”，协议栈自动降级为 Just Works。即使你想用 Passkey Entry，也跑不起来。检查一下你的 GAP 初始化代码里的 IO 能力设置。

💡 调试技巧：

用蓝牙抓包工具（如 Ellisys、Frontline）观察配对过程中的 SMP（安全管理协议）数据包。你能看到设备交换的配对请求和响应，里面包含了 IO 能力、OOB 标志、密钥大小等信息。这是定位配对失败最直接的手段。

我曾经遇到一个案例：设备 A 和设备 B 都能正常配对，但设备 A 和设备 C 就是配不上。抓包一看，设备 C 在配对请求里声明了“键盘输入”，但实际它根本没有键盘。嗯，这种固件里的 IO 能力写死了，跟硬件对不上，协议栈可不背这个锅。

配对绑定这块，说白了就是“协商-生成-存储”三步。但每一步都有细节。你把这些细节吃透了，后面做 Wi-Fi 模块的透传调试时，蓝牙连接这块就不会成为瓶颈。