AES CBC跨平台加解密仅首16字节输出不一致故障排查

问题现象 #

使用Python脚本加密128字节数据块，在TI C2000微控制器端执行解密操作时，仅解密结果的前16字节与原始明文不符，剩余112字节解密结果完全正确。经初步排查，加解密流程所有输入（密钥、IV、待解密密文）均无损坏，Python端对生成的密文执行解密可得到与原始明文完全一致的结果。

测试参数 #

密钥（16字节） #

key[16] = {0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6,
           0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c}

初始向量IV（16字节） #

iv[16] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
          0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}

原始明文（128字节） #

data_unencrypted[128] = {0x00,0x00,0x1b,0x00,0x01,0x00,0x00,0x00,0x02,0x00,0x76,0x58,0x08,
0x00,0x10,0x00,0xf0,0xff,0x00,0x00,0x46,0x55,0x08,0x00,0x7f,0x58,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x63,
0x08,0x00,0x30,0xa1,0x00,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}

Python端生成的密文（128字节） #

data_encrypted_python[128] = {0x2f,0xf2,0x20,0x85,0x2d,0xcd,0xb7,0x5e,0xfe,0x2b,0x90,0xe7,0x66,
0x3e,0xbb,0x3e,0xfa,0x15,0xf1,0xca,0x3e,0xc4,0x92,0x33,0x1a,0xc1,0xea,0x36,0x33,0xc5,0xeb,0xd4,0x33,0x5f,
0xcd,0x06,0x74,0xd4,0x85,0x79,0xed,0xf8,0xdc,0x5e,0x45,0x3d,0x74,0x29,0x63,0x69,0x77,0xc9,0x8b,0xdd,0x09,
0x8b,0xb4,0x2c,0xd7,0xf9,0xe9,0x94,0x1b,0x5d,0x20,0xa4,0x01,0xa7,0x91,0x67,0x24,0xa3,0x78,0xf7,0x72,0x6e,
0xbd,0xd3,0x37,0x27,0x13,0xcd,0x44,0x40,0x35,0x49,0x2d,0xf7,0xdd,0x58,0x35,0xe9,0x1b,0x1d,0x1f,0x97,0xe0,
0xe4,0xc4,0x89,0x0c,0x88,0x46,0x61,0x47,0xbc,0x87,0x3a,0xf5,0x50,0x9b,0xb0,0x4b,0xd9,0x8e,0x05,0x31,0x7c,
0x2a,0xd3,0xb5,0x3b,0xdd,0xa1,0x67,0xc3,0x60,0x39}

C2000端解密结果（128字节） #

data_decrypted_c2000[128] = {0x1c,0xc4,0x2b,0xb7,0xd2,0x8d,0x18,0x31,0xe8,0x96,0x30,0x70,0xb5,
                     0x6a,0xad,0xd3,0xf0,0xff,0x00,0x00,0x46,0x55,0x08,0x00,0x7f,0x58,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x63,
                     0x08,0x00,0x30,0xa1,0x00,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
                     0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
                     0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
                     0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
                     0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}

原因结论 #

即使所有输入数据均无损坏，该现象也完全可能出现，根因是C2000端CBC解密流程仅首个块的IV异或步骤出错，AES核心解密运算、密文读取、密钥加载均完全正常。

AES CBC模式的解密逻辑按块执行，128字节数据共分为8个16字节块，每个块的计算规则为：

1. 对当前16字节密文块执行AES ECB模式解密，得到中间结果
2. 第1个密文块的中间结果，与外部输入的初始IV异或，得到第1块明文
3. 从第2个密文块开始，每个块的中间结果与前一个位置的密文块异或，得到对应块的明文

从规则可以看出：从第2个块开始，解密流程完全不会用到初始IV，只要AES ECB核心运算正确、密文数据传输正确，后续所有块的解密结果就会完全正确。只有第1块的解密结果依赖初始IV，出现仅首块错误、后续块全对的现象，100%说明第一块异或步骤实际使用的IV和预期定义的IV不一致，和密钥、密文、AES核心逻辑无关。

C2000平台上出现该问题的常见诱因：

• IV数组未按AES库要求做内存对齐。TI C2000的硬件AES加速器通常要求密钥、IV、数据缓冲区按4字节对齐，未对齐时DMA或寄存器读取IV会出现数据错位，读到相邻内存的垃圾值
• IV加载时字节序处理错误。C2000为小端内核，部分硬件AES驱动要求IV按大端顺序写入寄存器，未做字节重排会导致IV值错乱
• 栈溢出意外改写IV。如果IV定义在栈上，相邻数组的越界写操作可能覆盖IV所在内存，导致解密时读到错误值
• 传参错误。调用解密函数时误传IV的地址偏移，导致实际读取IV的起始位置错误

排查时不要仅检查变量初始化时的IV值，要在解密函数执行第一块异或操作前打断点，直接读取实际参与运算的16字节IV，即可快速定位问题。

内容的提问来源于stack exchange，提问作者HansPeterLoft