5、中间人攻击（MITM）原理
聊到蓝牙安全，中间人攻击（MITM）是个绕不开的话题。说实话，我早期做蓝牙开发时，对MITM的认知还停留在“有人偷偷插在中间”这种模糊概念上。直到有一次，我在一个智能门锁项目里，亲眼看到攻击者用一块几十块钱的开发板，就轻松骗过了配对流程——那一刻我才真正意识到，MITM在BLE世界里有多“接地气”。
这一节，我们就来拆解MITM攻击的底层逻辑。我会结合自己的踩坑经历，把模型、场景、伪装手法、嗅探与篡改这些点，一个一个讲清楚。
5.1 MITM攻击模型：谁在中间？
先看最基础的模型。正常的BLE通信，是两台设备直接握手：
手机（Initiator） ←→ 智能锁（Responder）中间人攻击，就是攻击者插在中间，同时扮演两个角色：
手机 ←→ 攻击者设备（伪装成锁） ←→ 智能锁（伪装成手机）攻击者跟手机说：“我就是那把锁，来配对。” 转头又跟锁说：“我就是那台手机，来配对。” 两边都信了。从此，所有数据都经过攻击者中转——它能看到、能改、能丢包。
核心要点：MITM的本质是身份欺骗。攻击者不需要破解加密算法，只需要让两端都认错人。
我个人习惯把这种攻击模型叫做“双面人模型”。你想想看，攻击者手里有两套连接参数、两套密钥——一套跟手机协商，一套跟锁协商。手机和锁各自以为自己在跟对方说话，实际上都在跟攻击者说话。
5.2 BLE MITM攻击场景：真实世界里的“插队”
理论说完了，咱们看看实际场景。我在项目中遇到过几种典型的BLE MITM攻击，这里列三个最常见的：
场景一：智能门锁配对劫持
用户第一次配锁，手机靠近门锁。攻击者提前在附近放了一个信号更强的“假锁”。手机扫描时，假锁的信号强度（RSSI）更高，手机优先连上了假锁。假锁再连真锁。从此，攻击者可以记录开锁指令，甚至篡改指令——比如把“开锁”改成“关锁”。
避坑指南：我曾经在一个门锁项目里，发现攻击者用一块nRF52840开发板，把发射功率调到+8dBm，就能让手机在10米外优先连上它。真锁就在旁边1米，反而被忽略。后来我们强制要求配对时必须在APP里确认设备名称和MAC地址，才堵住这个漏洞。
场景二：蓝牙耳机固件OTA劫持
耳机通过BLE接收固件升级包。攻击者伪装成耳机厂商的服务器，向耳机推送恶意固件。耳机以为是官方升级，照单全收。结果呢？耳机被植入后门，通话内容被实时窃听。
场景三：医疗设备数据篡改
血糖仪通过BLE把读数传给手机。攻击者插在中间，把“血糖 5.2 mmol/L”改成“血糖 12.8 mmol/L”。患者看到高血糖读数，可能错误地注射胰岛素——这是要命的事。
| 攻击场景 | 攻击目标 | 后果 |
|---|---|---|
| 智能门锁配对劫持 | 配对阶段 | 开锁指令被窃取/篡改 |
| 耳机固件OTA劫持 | 固件升级阶段 | 植入后门，窃听通话 |
| 医疗设备数据篡改 | 数据传输阶段 | 错误读数导致误诊/误操作 |
5.3 攻击者设备伪装：怎么让手机“认错人”？
攻击者要伪装成合法设备，靠的是BLE广播包里的几个关键字段。说白了，就是伪造身份信息。
BLE广播包包含：
- 设备名称（Complete Local Name）：比如“Smart Lock v2”
- MAC地址：攻击者可以修改自己网卡的MAC地址，克隆真锁的MAC
- 服务UUID：比如门锁的专有服务UUID 0xFFE0
- 发射功率（TX Power Level）：调高可以让手机优先选择
攻击者只需要一个支持BLE的MCU（比如ESP32、nRF52840），写一段广播代码，就能完美克隆这些信息。我见过最离谱的一次，攻击者连广播间隔都克隆得一模一样——手机端完全看不出区别。
// 攻击者设备伪装的伪代码示例
// 注意：仅用于教学演示，请勿用于非法用途
void setup_mitm_advertising() {
// 1. 设置广播数据：克隆目标设备的名称、UUID、MAC
uint8_t adv_data[] = {
0x02, 0x01, 0x06, // Flags
0x0A, 0x09, 'S','m','a','r','t',' ','L','o','c','k', // 设备名称
0x03, 0x03, 0xE0, 0xFF, // 服务UUID
0x05, 0x0A, 0x08, 0x00, 0x00, 0x00 // TX Power Level: +8dBm
};
// 2. 设置扫描响应数据（可选）
uint8_t scan_rsp_data[] = {
0x05, 0x08, 0x00, 0x00, 0x00, 0x00 // 更多设备信息
};
// 3. 修改MAC地址（需要硬件支持）
set_mac_address(0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF);
// 4. 开始广播
ble_advertising_start(adv_data, sizeof(adv_data),
scan_rsp_data, sizeof(scan_rsp_data));
}注意：修改MAC地址在大多数蓝牙芯片上是可行的，但有些芯片（比如某些USB蓝牙适配器）会限制MAC修改。攻击者通常会选择支持MAC自定义的芯片，比如nRF52系列或ESP32。
5.4 数据包嗅探与篡改：攻击者能做什么？
一旦攻击者成功插在中间，它就能做两件事：嗅探和篡改。
嗅探：偷看你在说什么
攻击者可以记录所有经过的数据包。如果配对时没有启用加密（比如Just Works配对），那所有数据都是明文——攻击者直接看到密钥、指令、敏感数据。
我记得有一次，我在测试一个智能灯泡的配对流程。灯泡用的是Just Works配对，没有MITM保护。攻击者用Wireshark抓包，几秒钟就看到了配对过程中交换的临时密钥（TK）。有了TK，后续的加密密钥也能算出来——整个通信形同虚设。
篡改：改掉你想说的话
如果攻击者能看懂数据包的内容，它就能修改。比如：
- 把“开锁”指令改成“关锁”
- 把“转账100元”改成“转账10000元”
- 把“固件版本1.0”改成“固件版本0.9”，诱导设备降级
篡改的关键在于：攻击者必须知道数据包的格式。如果数据是加密的，攻击者无法篡改（除非它破解了密钥）。但如果配对阶段没有MITM保护，攻击者就能拿到密钥——这就是为什么BLE的MITM保护如此重要。
一句话总结：没有MITM保护的BLE配对，就像在公共场合用明信片写银行卡密码——谁都能看，谁都能改。
5.5 如何防御？先看攻击者怕什么
了解了攻击者的手法，防御思路就清晰了。攻击者最怕两件事：
- 身份验证：如果手机和锁在配对时能互相证明“我就是我”，攻击者就插不进来。
- 加密通信：即使攻击者插在中间，如果数据是加密的，它看不懂也改不了。
BLE规范里提供了几种防御机制，比如Numeric Comparison配对、Passkey Entry配对、OOB（带外）配对。这些我们会在后面的章节详细讲。这里先记住一个原则：永远不要用Just Works配对来传输敏感数据。
我的经验：在BLE项目立项时，我就会问产品经理一个问题：“这个设备的数据被篡改，会死人吗？” 如果答案是“会”，那MITM保护就是强制要求，没得商量。如果答案是“不会”，那也要评估风险——毕竟，用户的隐私也是钱。
好了，这一节我们拆解了MITM攻击的完整链条：从模型到场景，从伪装到嗅探篡改。下一节我们会深入BLE配对协议，看看这些攻击到底是怎么在协议层面发生的——嗯，那才是真正有意思的部分。
公众号:蓝海资料掘金营，微信deep3321