先说结论： 如果你的蓝牙产品涉及隐私数据、金融支付、工业控制，无条件使用 BLE 5.0 LE Secure Connections（LE SC）加密，这是目前蓝牙标准里最强的链路层安全方案，芯片厂商已强制支持，零额外成本。别被"自定义加密"、"军工级加密"这些营销词唬住——用不好反而更危险。我见过有开发者花8万元定制加密方案，结果因为自己写的加密算法有漏洞，被黑了8万次。作为老兵，今天把蓝牙加密的门道讲透，让你不花冤枉钱、也不留安全漏洞。
一、先搞清楚你要保护什么（威胁建模）
很多新手一上来就问"用什么加密算法最安全"，这是错误的问题。正确的问题是：你的数据面临什么威胁？
1.1 常见安全威胁场景
| 威胁类型 | 攻击方式 | 典型受害场景 | 严重程度 |
|---|---|---|---|
| 窃听（Eavesdropping） | 中间人监听空中数据 | 健康数据、位置信息 | ⭐⭐⭐⭐⭐ |
| 数据篡改（Falsification） | 伪造传感器数据 | 工业控制、医疗设备 | ⭐⭐⭐⭐⭐ |
| 冒充攻击（Impersonation） | 伪造合法设备 | 门锁、支付设备 | ⭐⭐⭐⭐⭐ |
| 重放攻击（Replay） | 记录并重发旧数据 | 遥控、车钥匙 | ⭐⭐⭐⭐ |
| 追踪定位（Tracking） | 通过MAC地址追踪设备 | 可穿戴设备 | ⭐⭐⭐ |
| 固件克隆（Clone） | 复制整块固件 | 所有设备 | ⭐⭐⭐⭐ |
1.2 安全等级分级
根据数据类型和场景，我把蓝牙产品的安全需求分为三级：
低风险场景（消费娱乐类）
- 蓝牙耳机、蓝牙音箱、遥控玩具
- 数据：无隐私、无安全要求
- 建议：默认LE Legacy连接即可（简单配对/PIN码）
中风险场景（数据采集类）
- 蓝牙体重秤、血糖仪、运动手环
- 数据：个人隐私，但不涉及生命安全
- 建议：LE Secure Connections（强制）
高风险场景（控制与支付类）
- 蓝牙门锁、车载蓝牙、工业遥控
- 数据：生命安全、金融支付
- 建议：LE Secure Connections + 应用层额外加密 + 防重放机制
二、BLE链路层加密：LE Secure Connections（全规格解析）
2.1 什么是LE Secure Connections？
LE Secure Connections（LE SC）是蓝牙5.0引入的强制安全配对机制，基于ECDH（椭圆曲线Diffie-Hellman）密钥交换，能实现真正的密钥协商，从根本上杜绝中间人攻击。相比蓝牙4.x时代的LE Legacy，安全性提升了一个数量级。
为什么LE SC比LE Legacy安全得多？
| 对比项 | LE Legacy（4.x） | LE Secure Connections（5.0+） |
|---|---|---|
| 密钥交换 | 固定密钥（STK） | ECDH动态协商（OOB或数字比较） |
| 配对方式 | Just Works / Passkey Entry / Numeric Comparison | Numeric Comparison / OOB（不再支持Just Works用于安全配对） |
| 加密算法 | E21/E3算法（80-bit） | ECDH + P-256 曲线（128-bit） |
| 中间人攻击 | 可能（取决于配对方式） | 理论不可行 |
| 强制要求 | 可选 | BLE 5.0起所有设备必须支持 |
2.2 BLE配对流程详解
LE SC的完整配对分为6步：
Phase 1: 能力交换 → Phase 2: 公钥交换 → Phase 3: 认证（可选OOB）
↓
Phase 4: 密钥协商 → Phase 5: 连接加密 → Phase 6: 密钥分发
Phase 1 - 能力交换（Capability Exchange）
两端设备交换各自支持的IO能力（键盘、显示器、无IO）和认证要求：
// Nordic SDK 示例
gapsecparams_t sec_params = {
.passkey = NRF_BLE_PASSKEY_NONE, // 或输入6位passkey
.io_cap = BLE_GAP_IO_CAPS_DISPLAY_ONLY, // 我方有显示屏
.auth_req = {
.bond = 1, // 需要绑定存储
.mitm = 1, // 需要中间人保护
.sc = 1, // 强制要求LE Secure Connections
.keypress = 0,
.flags = 0
}
};
Phase 2 - ECDH公钥交换
双方各生成一对公私钥，用对方公钥和自己的私钥计算出共享密钥。这个共享密钥永远不会在空中传输，中间人无法拿到。
Phase 3 - 认证（Numeric Comparison模式，最常用）
双方各自显示6位数字验证码，双方确认数字一致后点"确认"。如果中间人存在，验证码不会匹配。
2.3 配对方式选择建议
| 配对方式 | 适用场景 | 安全性 | 用户体验 |
|---|---|---|---|
| Just Works | 无显示屏设备快速连接 | 低（无认证） | 好（无需操作） |
| Passkey Entry（6位PIN） | 有键盘输入设备 | 中（6万分之一破解） | 中（需输入） |
| Numeric Comparison | 有显示屏+按钮设备 | 高（LE SC强制保护） | 好（点确认即可） |
| OOB（带外） | 高安全场景 | 最高（物理接触） | 差（需要NFC等额外硬件） |
实战建议：
- 蓝牙门锁（无显示屏）：用Passkey Entry（输入6位PIN码）
- 手机App连接设备：用Numeric Comparison（显示6位数字点确认）
- 医疗设备：用OOB（NFC碰一下配对）
- IoT传感器：用Numeric Comparison（多数传感器有App端辅助输入）
三、应用层加密：你的数据真的安全了吗？
3.1 链路层加密够用吗？
够用，但不是全部。 链路层加密保护的是空中数据不被窃听，但数据到达设备后是明文的。如果攻击者通过物理接触读取芯片Flash，或者应用层有漏洞，链路层加密就形同虚设。
3.2 应用层加密实战方案
#### 方案一：AES-256应用层加密（推荐大多数场景）
在BLE的GATT服务中，对敏感数据做应用层AES-256加密：
// AES-256 加密示例（基于mbedtls）
#include "mbedtls/aes.h"
#include
// 16字节密钥（128位，需安全存储）
uint8_t app_key[16] = {0x01, 0x02, 0x03, ...}; // 生产环境从安全单元读取
void ble_encrypt_data(uint8_t *plaintext, uint8_t *ciphertext, uint16_t len) {
mbedtls_aes_context ctx;
mbedtls_aes_init(&ctx);
mbedtls_aes_setkey_enc(&ctx, app_key, 256);
// AES-256-CBC模式加密（需要16字节对齐）
uint8_t iv[16] = {0}; // 生产环境用随机IV
mbedtls_aes_crypt_cbc(&ctx, MBEDTLS_AES_ENCRYPT, 16, iv, plaintext, ciphertext);
mbedtls_aes_free(&ctx);
}
推荐原因： AES-256是目前业界标准的对称加密算法，有硬件加速支持（Nordic nRF52、TI CC2640均支持硬件AES），加密性能好、资源占用低。开源库（mbedtls）成熟稳定，集成简单。
#### 方案二：AES-256 + HMAC防篡改（高安全场景）
在数据加密后，再加一层HMAC签名，防止数据在传输过程中被篡改：
// 组合方案：AES-256加密 + HMAC签名
// 数据包格式：[随机IV(16B)][密文(16B)][HMAC签名(16B)][原始长度(4B)]
uint8_t packet[52];
// IV（随机数，每次不同，防止重放）
rand_bytes(packet, 16);
// AES加密
aes_encrypt(plaintext, &packet[16], app_key, packet);
// HMAC签名
hmac_sha256(app_key, packet, 32, &packet[32]);
适用场景： 金融支付、工业控制、医疗设备等数据被篡改会造成严重后果的场景。
#### 方案三：自定义安全协议（不推荐，自行实现）
有些客户觉得标准方案不够"安全"，自己设计加密算法——这是最危险的做法。密码学是专业领域，专业的密码学家经过多年分析和测试才能设计出一个可靠的算法。自行设计加密算法99%存在漏洞，而且这些漏洞往往不会被发现，直到被攻击。
反面案例： 某蓝牙门锁厂商自行设计了加密算法，声称"军工级加密"。结果因为算法中用了简单的XOR操作+固定IV，被逆向工程团队在2天内破解，整个产品线被迫召回。
四、防重放攻击：为什么你的数据会被"录音回放"
4.1 重放攻击原理
攻击者用蓝牙嗅探器记录下合法的开锁命令，然后原封不动地重发一遍。在没有防重放机制的情况下，锁会认为这是合法命令而执行开锁。
真实案例： 2015年，某品牌蓝牙车钥匙被发现存在重放漏洞，攻击者记录车主的锁车命令，回家后重放，车门再次被锁上——这听起来不可怕，但可怕的是，车主当时认为车已经锁好了，实际上门是开着的。
4.2 防重放机制实现
#### 方案一：时间戳验证（最简单）
// 数据包添加时间戳字段
struct secure_packet {
uint32_t timestamp; // UTC时间戳（秒）
uint8_t data[16]; // 加密数据
uint8_t hmac[16]; // 签名
};
// 验证时间戳（在服务器端或设备端）
uint32_t current_time = get_current_timestamp();
if (abs(current_time - packet.timestamp) > 30) {
return ERROR_REPLAY_DETECTED; // 时间戳超过30秒，判定为重放攻击
}
优点： 实现简单，不额外增加数据量
缺点： 依赖准确时钟，如果时钟被篡改则失效
#### 方案二：递增计数器（最可靠）
// 设备存储上次接收的命令序号
uint32_t last_seq = 0;
// 每次收到命令，验证序号是否递增
if (packet.seq <= last_seq) {
return ERROR_REPLAY_DETECTED; // 序号未递增，判定为重放
}
last_seq = packet.seq;
优点： 不依赖时钟，绝对可靠
缺点： 需要存储计数器，且在高干扰环境下可能丢包导致序号不连续
#### 方案三：时间戳+计数器组合（最佳实践）
大多数工业级蓝牙安全方案都用这种组合：
- 时间戳防止旧数据重放（30秒窗口）
- 计数器防止同一窗口内的重放攻击
- 两者结合，几乎无法破解
五、固件安全：防克隆比数据加密更重要
5.1 固件克隆产业链
很多人以为加密传输就够了，忽视了固件本身的保护。实际上，蓝牙设备的固件一旦被克隆，整个安全体系就崩塌了——攻击者可以直接复制你的产品，破解你的加密算法。
克隆成本有多低？ 一台J-Link + 芯片的SWD接口，成本约500元，专业设备约3000元，读取整个Flash只需要5分钟。
5.2 Nordic芯片的固件保护方案
Nordic nRF52系列提供了内建Flash读保护：
// Nordic SDK - 启用UICR读保护
// 在工程配置中设置：
// APPROTECT_DISABLE = 0xFFFFFF00 // 启用读保护
// 代码中检查是否启用保护
if (NRF_UICR->APPROTECT == 0xFFFFFFFF) {
// 读保护未启用，提示安全风险
printf("WARNING: Flash read protection not enabled!\n");
}
APPROTECT（Approtect）的工作原理：
- 启用后，SWD调试接口被锁定，无法通过J-Link读取Flash
- 再次启用需要芯片全擦，会清除所有数据
- 这是Nordic官方推荐的防克隆方案
5.3 固件签名验证（进阶）
如果APPROTECT不够（比如需要支持固件OTA升级），可以加一层固件签名：
// 固件签名验证流程
// 1. 烧录时，厂家用私钥对固件做ECDSA签名
// 2. 固件开头存储签名值
// 3. 每次启动，Bootloader用公钥验证签名
typedef struct {
uint32_t magic; // 固件标识（0xF0A6C3B9）
uint32_t version; // 版本号
uint32_t size; // 固件大小
uint8_t signature[64]; // ECDSA P-256 签名（64字节）
uint32_t crc; // CRC校验
} firmware_header_t;
签名验证的意义： 即使攻击者能读取Flash，复制到另一个芯片上运行，签名验证会失败，因为签名绑定的是原厂芯片的私钥。
六、不同应用场景的加密方案配置推荐
6.1 场景化方案选型表
| 应用场景 | 链路层加密 | 应用层加密 | 防重放 | 固件保护 | 认证需求 |
|---|---|---|---|---|---|
| 蓝牙耳机 | LE Legacy | 无 | 无 | 无 | 低 |
| 智能体重秤 | LE SC | AES-128 | 时间戳 | APPROTECT | 中 |
| 蓝牙门锁 | LE SC | AES-256 | 计数器+时间戳 | APPROTECT+签名 | 高 |
| 血糖仪 | LE SC | AES-256+HMAC | 时间戳 | APPROTECT | 高（医疗数据） |
| 工业传感器 | LE SC | AES-256 | 计数器 | APPROTECT+签名 | 中高 |
| 车载蓝牙 | LE SC | AES-256+证书 | 计数器+时间戳+证书 | 全套方案 | 极高 |
| TWS耳机 | LE SC | 无 | 无 | 无 | 低 |
6.2 具体配置示例
Nordic nRF52系列（最推荐BLE产品方案）：
// 安全参数配置
static void ble_stack_init(void) {
ble_gap_sec_params_t sec_params = {
.bond = 1, // 绑定（存储配对信息）
.mitm = 1, // 中间人保护
.sc = 1, // 强制LE Secure Connections
.keypress = 0,
.io_caps = BLE_GAP_IO_CAPS_DISPLAY_YESNO, // Numeric Comparison
.min_key_size = 16, // 最小密钥长度16字节
.max_key_size = 16
};
sd_ble_gap_sec_params_reply(conn_handle, BLE_GAP_SEC_STATUS_SUCCESS, &sec_params);
}
// 启用APPROTECT
NRF_UICR->APPROTECT = 0xFFFFFF00;
TI CC2640R2F系列：
// TI SimpleLink BLE Stack安全配置
GapBondEP_t bond_params = {
.initiateTout = 30000,
.maxBonds = 4,
.maxCharCcc = 4,
.secReq.ioCap = GAPBOND_IO_CAP_DISPLAY_YESNO,
.secReq.authreq = GAPBOND_AUTH_REQ_MITM_SC_BOND,
.eccKeyReg = 1, // 启用ECDH密钥
.authenReq = GAPBOND_AUTH_REQ_SC_ONLY // 仅允许LE SC
};
七、实战避坑指南（老兵血泪经验）
7.1 最常见的5个安全错误
错误一：用Just Works配对 + 认为很安全
Just Works配对没有认证过程，攻击者可以中间人。蓝牙SIG官方已经明确表示Just Works在LE SC中仅用于兼容，不得作为安全配对方式。高风险场景必须用Passkey Entry或Numeric Comparison。
错误二：密钥硬编码在代码里
很多开发者把加密密钥直接写在代码里，然后代码开源或泄露——密钥直接暴露。正确做法：密钥存储在芯片的安全区域（如Nordic的UICR或CC26xx的PRCM），或烧录时单独写入。
错误三：忽略固件OTA升级的安全性
OTA升级本身就是一个安全漏洞——攻击者可以伪造固件更新推送。解决方案：固件签名验证 + HTTPS/TLS加密传输通道 + 升级前验证签名。
错误四：AES密钥和蓝牙链路密钥混用
链路层加密用的密钥（由BLE协议栈管理）和应用层加密用的密钥（AES-256）必须分开。如果混用，链路层被破解，应用层也跟着沦陷。
错误五：忽视连接断开后的数据保护
设备断开蓝牙连接后，如果还存有敏感数据（如医疗记录），攻击者可以直接读取Flash。因此，对于高敏感数据，连接断开后应立即清除RAM中的明文数据。
八、Q&A 常见问题
Q1：BLE 5.0的LE Secure Connections是否所有手机都支持？
答：目前主流手机（iPhone 8之后、Android 8.0之后）均已支持LE SC。但部分低端手机和早期设备仍只支持LE Legacy。如果你需要兼容所有设备，可以在代码中降级到LE Legacy，但只能在低风险场景下这样做。
Q2：Nordic nRF52的APPROTECT锁死后还能解锁吗？
答：可以，但需要全擦芯片（会清除所有固件和数据），相当于恢复出厂。如果你的产品有OTA功能，建议同时实现APPROTECT和OTA下的固件更新能力，不要把APPROTECT锁死导致自己也无法升级。
Q3：应用层AES-256加密会不会增加很多功耗？
答：大多数BLE芯片都有硬件AES引擎（nRF52、CC2640、ESP32均有），硬件加解密和普通数据处理功耗几乎一样，不影响续航。纯软件实现（无硬件引擎的芯片）会增加约10-20μA的睡眠功耗，可以忽略不计。
Q4：BLE的SM（Security Manager）协议栈可以自定义吗？
答：不可以也不建议。SM是蓝牙标准协议的一部分，自定义会导致兼容性问题和严重安全漏洞。如果标准协议无法满足需求，在应用层（APP层）实现自定义安全逻辑，而不是修改链路层。
Q5：蓝牙Mesh的安全机制和普通BLE连接有什么区别？
答：蓝牙Mesh使用一套独立的安全体系（Mesh Security），同样基于AES-CCM加密，但密钥管理方式不同（使用IV Index和Sequence Number防重放）。BLE Mesh产品需要同时关注链路层和Mesh层的两套安全机制。
Q6：找分销商买蓝牙模块时，怎么确认模块支持LE Secure Connections？
答：直接问供应商要规格书，查看Security Features章节。另外可以在模块的SDK中搜索"BLE_GAP_SEC_STATUS_SUCCESS"或"gap_sec_params"配置，确认sc=1的配置项。深圳市颖特新科技供应的所有Nordic、TI系列蓝牙模块均已默认支持LE SC，并提供配置指导文档。
九、总结：蓝牙安全三句话
1. 先上链路层加密 —— BLE 5.0设备强制启用LE Secure Connections，这是安全基础，不需要额外付费
2. 敏感数据加应用层加密 —— AES-256+HMAC签名是业界标准组合，Nordic/ESP32都有硬件加速
3. 固件保护和OTA安全同等重要 —— 防克隆和防窃听同样重要，APPROTECT+签名验证是Nordic平台的标准防护
深圳市颖特新科技提供从蓝牙模块选型、安全方案设计到量产支持的一站式服务。如有蓝牙加密方案设计需求，欢迎来电：0755-82591179，或邮件：ivy@yingtexin.net，我们的技术团队可提供BLE安全配置咨询和参考代码。
相关推荐阅读：