1. BLE安全概述：蓝牙安全发展史、BLE安全架构、核心安全概念

各位同学，咱们今天聊聊BLE安全。说实话，我刚入行那会儿，蓝牙安全还是个“附加功能”——能连上就行，谁管它加密不加密。但后来经历了几次真实的安全事件，我才意识到：安全不是功能，是底线。

蓝牙安全的发展，说白了就是一部“攻防对抗史”。我把它分成三个阶段：

阶段	版本	安全特点	典型问题
蛮荒时代	BR/EDR (v1.0–v2.0)	固定PIN码、无加密可选	PIN码可暴力破解、窃听无门槛
补丁时代	BR/EDR (v2.1+Secure Simple Pairing)	引入公钥交换、MITM保护可选	仍存在“Just Works”无认证配对
铠甲时代	BLE (v4.0–v5.4)	LE Secure Connections、CTKD、Privacy 1.2	实现复杂度高，配置不当仍有漏洞

我记得2017年有个项目，客户要求用BLE做门锁。当时我查了一下，发现v4.0的配对方式里，Just Works 模式根本不防中间人攻击。你想想看，一个门锁如果配对时能被劫持，那跟没锁有什么区别？从那以后，我对安全版本的选择就特别敏感。

⚠️ 避坑指南： 我曾经在v4.0时代踩过一个坑——默认使用LE Legacy Pairing，结果被测试团队用现成的破解工具直接拿到了LTK。后来我强制要求所有新项目必须使用LE Secure Connections（v4.2+），除非芯片不支持。

BLE的安全架构不是一堵墙，而是洋葱皮——每一层都承担不同的职责。我习惯把它画成下面这张图：

这张图我每次培训都会拿出来讲。为什么？因为很多开发者只关注“配对”那一层，忽略了应用层和物理层。我见过一个产品，配对用了Secure Connections，但应用层直接把密钥明文存到Flash里——这就像给保险箱装了金库门，但钥匙挂在门上。

做安全绕不开CIA——不是中央情报局，是机密性、完整性、可用性。这三个词听着抽象，我结合BLE给你拆开讲。

机密性就是不让不该看的人看到数据。在BLE里，靠的是AES-128加密。

核心机制：

我遇到过最典型的机密性漏洞是什么？配对时没有验证身份。比如Just Works模式，虽然数据加密了，但中间人可以插入自己的密钥。你加密你的，我解密再加密给另一边——双方都以为自己在安全通信，其实中间人看得一清二楚。

💡 我的建议： 只要产品涉及敏感数据（门锁、支付、健康数据），绝对不要用Just Works。至少用Passkey Entry或Numeric Comparison。如果必须用Just Works，那就在应用层额外做一次认证。

完整性保证数据没有被篡改。BLE用MIC（消息完整性校验码）来实现。

你想想看，如果攻击者不能解密你的数据，但他可以篡改加密后的密文——接收方解密出来就是乱码，甚至可能触发错误逻辑。MIC就是为了防止这种情况。

这里有个细节：MIC是4字节还是8字节？ 我踩过坑。BLE 4.0/4.1默认用4字节MIC，但4.2之后可以协商8字节。8字节当然更安全，但每个包多4字节开销。如果你的产品对功耗和带宽敏感，需要权衡。

可用性就是该用的时候能用。在BLE安全里，这往往被忽视。

举个例子：你设计了一个BLE门锁，安全做得很好，加密、认证、防重放都齐了。但攻击者不需要破解你的加密——他只需要在门口用干扰器持续发送噪声，让你的门锁无法扫描到合法的手机。这就是DoS攻击。

⚠️ 注意： 可用性不是纯技术问题，它涉及产品设计。我曾经在一个项目中，为了安全把配对超时设成5秒——结果用户经常配对失败。后来我改成15秒，配合UI提示，体验好了很多。安全不能以牺牲可用性为代价，否则用户会绕过安全机制。

机密性、完整性、可用性不是孤立的。我习惯用一个例子串起来：

缺了任何一个，这个门锁都不安全。你想想看，如果机密性和完整性都做到了，但可用性被破坏——你被锁在门外，那安全还有什么意义？

总结一下：

嗯，这一章的内容就到这里。记住一句话：安全不是加一个开关，而是贯穿整个设计流程的思维。后面我们会深入每个安全机制的实现细节，到时候再手把手带大家写代码。