1、BLE安全概述：为什么需要安全配对？BLE 4.2与5.0安全特性对比
1.1 为什么我们需要安全配对？
说实话，我刚入行做蓝牙开发那会儿，对安全配对这事儿也没太当回事。觉得不就是两个设备连一下嘛，能有什么大问题？直到有一次，我在一个智能门锁项目里踩了坑——设备配对时没有启用安全连接，结果被第三方设备轻松嗅探到了配对密钥。嗯，从那以后，我再也不敢轻视安全配对了。
你想想看，蓝牙设备现在到处都是：智能门锁、手环、医疗设备、车载系统……如果配对过程不安全，攻击者完全可以：
- 窃听配对过程：拿到你的加密密钥，后续所有通信都等于裸奔
- 中间人攻击（MITM）：假装是合法设备，截获并篡改数据
- 重放攻击：记录下配对数据包，后面再重放一遍就能冒充你
说白了，安全配对就是给蓝牙通信上了一把锁。没有这把锁，你的设备就像没关门的房子，谁都能进。
核心要点：安全配对的目标是解决三个问题——机密性（别人听不到）、完整性（别人改不了）、真实性（对方是真的）。
1.2 BLE 4.2 的安全特性回顾
BLE 4.2 其实已经做了不少安全工作。我记得当时4.2刚出来的时候，圈内人都挺兴奋的，因为终于有了像样的安全机制。
4.2 引入了 LE Secure Connections，核心变化是：
- 使用 ECDH（椭圆曲线 Diffie-Hellman）密钥交换：替代了之前简单的 AES-128 加密，安全性上了一个台阶
- 支持 FIPS 认可的算法：包括 P-256 椭圆曲线、AES-CCM 加密等
- 四种配对方式：Just Works、Numeric Comparison、Passkey Entry、Out of Band
这里我特别想提一下 Numeric Comparison 这种方式。我在一个智能家居项目里用过它，用户体验还不错——两个设备屏幕上显示相同的6位数字，用户确认一下就行。这能有效防止中间人攻击，因为攻击者没法伪造出相同的数字。
我的经验：4.2 的 Secure Connections 虽然好，但有个问题——它要求双方都支持4.2及以上版本。如果一方是4.0或4.1的老设备，就会回退到传统的 Legacy Pairing，安全性大打折扣。我在项目中就遇到过这种兼容性问题，最后不得不强制要求所有设备升级固件。
1.3 BLE 5.0 的安全特性升级
到了 BLE 5.0，安全方面其实没有翻天覆地的变化，但有几个关键点值得注意：
| 特性 | BLE 4.2 | BLE 5.0 |
|---|---|---|
| 核心加密算法 | ECDH P-256 + AES-CCM | 同左，保持不变 |
| 配对方式 | 4种（Just Works、Numeric Comparison、Passkey Entry、OOB） | 同左，但优化了流程 |
| 密钥生成 | 基于 ECDH | 同左，但支持更长的密钥 |
| 隐私特性 | 支持 Resolvable Private Address | 增强：支持更频繁的地址更新 |
| LE Secure Connections | 可选 | 推荐强制使用 |
你可能会问：那5.0到底升级了啥？
我个人觉得，5.0最大的安全改进不在算法层面，而在 协议流程的优化 和 隐私保护 上。
- 更快的配对流程：5.0优化了配对阶段的交互次数，减少了被攻击的时间窗口
- 增强的隐私功能：5.0允许设备更频繁地更换自己的蓝牙地址，让攻击者更难追踪
- 强制 Secure Connections 倾向：虽然5.0仍然兼容 Legacy Pairing，但规范强烈建议使用 Secure Connections
注意：BLE 5.0 并没有引入新的加密算法。如果你看到有人宣传"5.0比4.2更安全"，那多半是营销话术。实际上，只要双方都使用 Secure Connections，4.2和5.0的安全性是一样的。区别在于5.0让安全机制更好用了。
1.4 实际项目中的选择建议
我在做项目选型时，一般会这样判断：
- 如果设备双方都支持4.2+：直接上 Secure Connections，用 Numeric Comparison 或 Passkey Entry
- 如果有一方是老设备（4.0/4.1）：那就只能回退到 Legacy Pairing，但我会在应用层额外加一层加密
- 如果是 IoT 传感器这类无显示设备：用 Just Works 配合 OOB（比如通过 NFC 交换密钥）
举个例子，我之前做的一个医疗手环项目，手环端没有屏幕，手机端有屏幕。我们用了 Passkey Entry 方式——手机显示6位数字，用户在手表上输入。虽然操作多了一步，但安全性高了很多。
一句话总结：BLE 4.2 打好了安全地基，BLE 5.0 在这个地基上把房子盖得更舒服了。但不管用哪个版本，安全配对这个环节绝对不能省。
1.5 避坑指南
最后分享几个我踩过的坑：
- 别迷信"5.0更安全"：我见过有人为了"更安全"硬上5.0，结果设备兼容性一塌糊涂。安全的关键在于正确配置，不是版本号
- 注意配对超时：有些设备配对过程太长，用户等不及就取消了。我建议把配对超时设在30秒以内
- 密钥存储要小心：配对成功后生成的长期密钥（LTK），一定要安全存储在设备 flash 里。我曾经见过一个产品，密钥直接明文存着……嗯，后果你懂的
好了，这一章就聊到这儿。下一章我们会深入具体的配对流程，看看每一步到底发生了什么。