蓝牙AES加密通信中PKCS7填充导致的崩溃问题解析

1. 背景与问题概述

最近在调试一个蓝牙键盘与智能门铃的通信项目时，遇到了一个棘手的崩溃问题。这两个设备通过BLE（蓝牙低功耗）进行通信，应用层数据采用AES-128加密传输。具体实现上，蓝牙键盘使用了702L芯片的硬件AES加解密接口。

在实际测试中，我们发现当测试人员将已配对的设备与其他未配对设备混用时，设备会出现异常崩溃。经过初步排查，这是由于两端设备使用的AES密钥不一致导致的解密失败。但奇怪的是，这种崩溃并不是每次都会发生，有时会出现刷屏打印异常数据的情况。

关键点：AES是对称加密算法，通信双方必须使用相同的密钥才能正确加解密数据。密钥不一致时，理论上应该只是解密出乱码，而不应该导致程序崩溃。

2. 问题排查过程

2.1 AES解密行为验证

首先，我需要确认AES解密接口对错误密钥的处理方式。查阅芯片资料并与原厂确认后，发现一个重要的特性：AES解密本身不会验证密钥的正确性。也就是说，无论使用什么密钥，AES解密都会执行并输出结果（尽管可能是乱码）。

这个特性其实符合加密算法的设计原则 - 加密算法本身不应该提供任何关于密钥正确性的线索，否则会降低安全性。因此，单纯从AES解密的角度来看，使用错误密钥不应该导致崩溃。

2.2 实际测试现象

使用测试代码模拟错误密钥解密的情况，观察到以下现象：

1. 有时程序会直接崩溃
2. 有时会出现大量刷屏打印，显示异常大的长度值
3. 正确解密时，输出长度应为9字节，但错误解密时显示的长度值异常大

通过进一步分析发现，解密接口实际上包含两个部分：

• 硬件AES解密（bl_aes_transform）
• PKCS7填充去除（cutting函数）

2.3 解密流程分解

让我们仔细看看解密的具体流程：

1. 输入16字节加密数据
2. AES解密输出16字节数据（无论密钥是否正确）
3. PKCS7 cutting函数处理解密后的数据

测试发现，即使使用错误密钥，AES解密也能正常输出16字节数据（虽然是乱码）。这说明问题很可能出在后续的PKCS7 cutting处理环节。

3. PKCS7填充机制深入分析

3.1 PKCS7填充原理

PKCS7是一种常见的数据填充方案，其规则如下：

• 加密前，数据长度必须为块大小的整数倍（A