第29章 BLE安全实战项目

课程目录第29章 BLE安全实战项目

一、BLE安全实战项目全景

说实话，做了这么多年蓝牙安全，我见过太多纸上谈兵的安全方案。今天咱们直接上硬菜——四个实战项目，每一个都是我踩过坑、流过汗的成果。你跟着做一遍，比看十本理论书都管用。

核心目标：从攻击者视角理解漏洞，用防御者思维构建系统。

1.1 安全BLE聊天应用开发

先说说聊天应用。很多人觉得聊天嘛，发个消息而已，能有什么安全问题？我当年也这么想，直到在一次CTF比赛中，亲眼看着别人的聊天内容被明文截获……那场面，尴尬到脚趾抠地。

安全聊天应用的核心设计原则：

端到端加密：使用ECDH密钥交换 + AES-256-GCM加密
身份认证：基于数字签名的设备配对验证
防重放攻击：每条消息携带递增序列号和时间戳
完美前向安全性：每次会话生成临时密钥

来看一个核心的加密通信流程：

// 密钥交换阶段
1. 设备A生成临时密钥对 (skA, pkA)
2. 设备B生成临时密钥对 (skB, pkB)
3. 通过BLE GATT交换公钥 pkA 和 pkB
4. 双方计算共享密钥: sharedKey = ECDH(skA, pkB) = ECDH(skB, pkA)
5. 使用HKDF派生会话密钥: sessionKey = HKDF(sharedKey, salt, info)

// 消息加密阶段
1. 生成随机IV (12字节)
2. ciphertext = AES-256-GCM-Encrypt(sessionKey, IV, plaintext, aad)
3. 发送: IV || ciphertext || tag

// 消息解密阶段
1. 提取IV、ciphertext、tag
2. plaintext = AES-256-GCM-Decrypt(sessionKey, IV, ciphertext, aad, tag)
3. 验证序列号防止重放

我的经验：千万别用ECB模式！我曾经在一个项目中看到有人用ECB加密聊天内容，结果头像图标重复的像素块直接暴露了加密模式。用GCM模式，既加密又认证，一步到位。

1.2 BLE安全扫描器实现

安全扫描器是什么？说白了就是蓝牙世界的「安检仪」。我开发第一个扫描器时，只是想看看周围有哪些设备，结果发现了一个大问题——很多设备广播包里的数据，完全是明文裸奔。

扫描器需要检测的安全风险：

风险类型	检测方法	严重程度
广播包明文敏感数据	解析AD Type字段，检查是否包含UUID、MAC等	高
未启用加密配对	检查IO Capabilities和配对模式	高
固定PIN码	检测Legacy Pairing中的PIN固定值	中
可连接但未绑定	检查广播包中的Connectable标志和绑定状态	中
厂商自定义数据泄露	解析Manufacturer Specific Data	低-高

扫描器的核心逻辑其实不复杂：

class BLESecurityScanner:
    def __init__(self):
        self.known_vulnerabilities = []
        self.device_database = {}
    
    def scan_and_analyze(self, scan_result):
        device = {
            'address': scan_result.device.address,
            'rssi': scan_result.rssi,
            'advertisement_data': self.parse_advertisement(scan_result),
            'security_score': 100  # 初始满分
        }
        
        # 检查广播包
        if self.has_plaintext_sensitive_data(device):
            device['security_score'] -= 30
            self.log_vulnerability('广播包包含明文敏感数据')
        
        # 检查配对模式
        if self.is_legacy_pairing(device):
            device['security_score'] -= 20
            self.log_vulnerability('使用Legacy Pairing，易受MITM攻击')
        
        # 检查服务特征
        if self.has_insecure_characteristics(device):
            device['security_score'] -= 25
            self.log_vulnerability('存在未加密的特征值')
        
        return device

注意：扫描器本身也可能被反检测。有些恶意设备会伪装成正常设备，等你扫描器靠近时发起攻击。我在一次渗透测试中就遇到过这种「蜜罐设备」，差点中招。

1.3 MITM攻击防御系统

中间人攻击，这是BLE安全里最经典的攻击方式。攻击者就像个「二传手」，在你和设备之间偷偷传递消息。我见过最骚的操作是——攻击者用两个手机，一个伪装成手环，一个伪装成手机，中间搭个桥，所有数据过一遍手。

防御系统的三层架构：

链路层防御：强制使用LE Secure Connections，拒绝Legacy Pairing
应用层防御：端到端加密 + 数字签名，即使链路被攻破也读不懂数据
行为层防御：检测异常RSSI变化、连接延迟、重连频率

来看一个RSSI异常检测的实现思路：

class MITMDetector:
    def __init__(self):
        self.rssi_history = []
        self.alert_threshold = 15  # dBm变化阈值
    
    def detect_rssi_anomaly(self, current_rssi):
        if len(self.rssi_history) < 5:
            self.rssi_history.append(current_rssi)
            return False
        
        # 计算移动平均
        avg_rssi = sum(self.rssi_history[-5:]) / 5
        deviation = abs(current_rssi - avg_rssi)
        
        # 如果RSSI突然变化超过阈值，可能是中继攻击
        if deviation > self.alert_threshold:
            self.trigger_alert(f'检测到RSSI异常: {deviation}dBm')
            return True
        
        self.rssi_history.append(current_rssi)
        return False
    
    def trigger_alert(self, message):
        # 断开连接，重新配对
        self.disconnect_and_rebond()
        # 记录日志
        self.log_security_event(message)

避坑指南：我曾经在RSSI检测上吃过亏——阈值设得太小，结果用户正常走动就触发告警。后来我加了时间窗口和置信度判断，误报率从30%降到了2%以下。

1.4 安全BLE固件更新

固件更新，这是BLE设备最脆弱的环节。你想啊，设备要下载新固件，如果这个过程中被篡改，那整个设备就变成别人的傀儡了。我见过一个智能门锁，因为固件更新没做签名校验，被攻击者远程刷了个后门固件，直接变成「公共厕所」——谁都能开。

安全固件更新的核心流程：

安全固件更新协议:
1. 版本协商阶段
   - 设备上报当前固件版本和哈希值
   - 服务器返回最新版本信息和签名

2. 固件下载阶段
   - 分块下载，每块附带签名
   - 设备验证每块签名的有效性
   - 使用安全通道传输（BLE加密连接）

3. 完整性校验阶段
   - 计算完整固件的SHA-256哈希
   - 验证固件包的数字签名（ECDSA）
   - 比对哈希值和签名是否匹配

4. 安全烧录阶段
   - 写入备份分区，保留回滚能力
   - 烧录完成后进行自检
   - 自检通过后切换启动分区

固件签名验证代码示例：

def verify_firmware_signature(firmware_data, signature, public_key):
    """
    验证固件签名
    使用ECDSA with SHA-256
    """
    # 计算固件哈希
    firmware_hash = hashlib.sha256(firmware_data).digest()
    
    # 验证签名
    try:
        # 使用设备的公钥验证
        ec_key = ECC.import_key(public_key)
        verifier = DSS.new(ec_key, 'fips-186-3')
        verifier.verify(firmware_hash, signature)
        return True
    except ValueError:
        # 签名验证失败
        log_security_event('固件签名验证失败！可能被篡改')
        return False
    except Exception as e:
        log_error(f'签名验证异常: {str(e)}')
        return False

血的教训：千万别把私钥硬编码在固件里！我见过一个厂商，把签名私钥直接写在固件代码里，结果攻击者反编译固件拿到私钥，直接给所有设备推送了恶意更新。私钥要放在安全元件（SE）或TEE里，或者使用HSM管理。

知识体系总览

这四个项目不是孤立的，它们构成了一个完整的BLE安全知识体系。我画了张图，帮你理清它们之间的关系：

看到这张图你就明白了——这四个项目不是各自为战，而是环环相扣。扫描器帮你发现漏洞，聊天应用教你如何加密通信，MITM防御系统教你如何检测攻击，固件更新则教你如何修补后门。做完这四个项目，你基本就掌握了BLE安全的全链路。

我的建议：别急着一次性全做完。先挑一个你最感兴趣的项目入手，比如安全聊天应用，把端到端加密搞明白。然后你会发现，其他项目里的很多概念都是相通的。我当年就是这么一步步啃下来的。

📚 课程目录

一、BLE安全实战项目全景

1.1 安全BLE聊天应用开发

1.2 BLE安全扫描器实现

1.3 MITM攻击防御系统

1.4 安全BLE固件更新

知识体系总览