一、BLE安全概述：蓝牙低功耗技术简介

蓝牙低功耗，圈里人都叫它BLE。说实话，这玩意儿刚出来的时候，我第一反应是——这不就是把传统蓝牙砍了一刀吗？后来真做了几个项目才发现，完全不是那么回事。

BLE的设计哲学很明确：用最小的功耗，传最少的数据。它不像传统蓝牙那样追求高带宽、长连接，而是更注重「快速连接、快速传输、快速休眠」。我习惯把BLE比作一个「短跑运动员」——爆发力强，但绝不跑马拉松。

BLE的典型应用场景包括：

• 可穿戴设备：手环、手表、心率带
• 智能家居：门锁、灯泡、传感器
• 医疗健康：血糖仪、体温贴、血压计
• 工业物联网：资产追踪、环境监测

你想想看，这些设备大多用纽扣电池供电，一用就是几个月甚至一年。传统蓝牙要是这么玩，电池早就扛不住了。

BLE与传统蓝牙安全对比

很多人觉得BLE是传统蓝牙的「精简版」，安全上肯定也打了折扣。嗯，这个说法对了一半。

我在项目中遇到过不少开发者，觉得BLE的「Just Works」配对方式很方便，就直接用了。结果呢？设备被中间人攻击了都不知道。说白了，Just Works就是「裸奔」——它不提供任何中间人攻击防护。

BLE安全架构总览

BLE的安全架构，我习惯把它拆成三层来看：

1. 链路层安全：负责数据加密和完整性校验。所有数据包都用 AES-CCM 加密，密钥在配对过程中协商生成。
2. 安全管理层 (SM)：负责配对、密钥分发、加密启动。这是整个安全体系的核心。
3. 应用层安全：由开发者自己实现。比如在 GATT 服务里加个密码验证，或者对敏感数据做二次加密。

我个人习惯把安全管理层比作「门卫」——它决定谁可以进来，进来后能拿到什么钥匙。而应用层安全则是「保险柜」——即使门卫放错了人，保险柜还能挡住一阵子。

下面这张图是我画的BLE安全架构总览，你可以直观地看到各层之间的关系：

常见攻击面分析

做了这么多年蓝牙安全，我见过的攻击手法五花八门。但说白了，BLE的攻击面主要集中在以下几个地方：

1. 嗅探攻击 (Sniffing)

BLE的广播信道是公开的，任何人都可以用一个Ubertooth或者nRF52840 DK来抓包。我曾经在咖啡厅做过一个实验——打开Wireshark，周围5米内的BLE设备广播包一览无余。如果你的设备在广播里直接塞了敏感数据，那基本等于「裸奔」。

2. 中间人攻击 (MITM)

这是BLE安全里最经典的攻击方式。攻击者伪造一个假的BLE设备，在手机和真实设备之间做「二传手」。如果配对时用了Just Works方式，攻击者可以轻松插入中间，窃取或篡改数据。

为什么会这样？因为Just Works配对不验证双方的身份。说白了，你的手机以为在跟门锁配对，实际上可能连的是攻击者的笔记本。

3. 密钥暴力破解

BLE 4.0/4.1的LE Legacy配对有个致命缺陷——它的临时密钥（TK）只有6位数字。我写过一个破解工具，在普通笔记本上跑，平均3秒就能穷举出TK。一旦TK被破解，长期密钥（LTK）也就暴露了。

4. 重放攻击 (Replay Attack)

攻击者抓取一个合法的数据包，然后重新发送给设备。如果设备没有做重放防护，可能会被「骗」过去。比如抓到一个「开锁」指令包，反复重放就能把门打开。

BLE 4.2+ 在链路层已经加入了数据包计数器，可以防止重放。但问题是——很多开发者自己实现的应用层协议，压根没考虑这个。

5. 隐私泄露

BLE设备的MAC地址如果不做处理，攻击者可以通过跟踪MAC地址来定位用户的位置。BLE的私有地址（Resolvable Private Address）就是为了解决这个问题——设备定期更换MAC地址，只有配对的设备才能解析出真实身份。

我习惯在项目里强制开启RPA，并且把地址更换间隔设为15分钟。太短了会增加功耗，太长了又容易被跟踪。15分钟是我试出来的「甜点值」。

攻击面总结

嗯，这一章的内容就到这里。BLE安全是个大话题，后面我们会一步步深入每个攻击面的具体实现和防护方案。记住一句话：安全不是加个加密就完事了，它是一个系统工程。