MSPM0 AES-GCM/CCM硬件加速实战：从原理到DMA配置与避坑指南

1. 项目概述与核心价值

在嵌入式系统开发中，数据安全已经从“加分项”变成了“必选项”。无论是智能家居设备间的指令传输，还是工业传感器数据的云端同步，确保数据的机密性和完整性都至关重要。AES（高级加密标准）作为对称加密的基石，其硬件加速器能极大解放主控MCU的算力，而GCM和CCM这两种认证加密模式，则能一站式解决“加密”和“验签”两大核心需求。

最近在基于TI的MSPM0 G系列MCU开发一个安全通信模块时，我深入研究了其内置的AESADV硬件加速器。官方手册虽然详尽，但关于GCM/CCM模式的实际配置流程，尤其是DMA联动和边界对齐这些“魔鬼细节”，往往散落在数百页的文档中。我踩过不少坑，也总结出一套稳定可靠的配置流程。这篇文章，我就结合实战经验，为你彻底拆解AES-GCM/CCM在MSPM0上的硬件级实现，从理论到寄存器配置，再到代码实操和避坑指南，手把手带你搞定嵌入式认证加密。

如果你正在为如何高效、正确地使用MCU的硬件加密引擎而头疼，或者对GCM/CCM的工作机制感到模糊，那么这篇内容正是为你准备的。我们将不仅知道“怎么配”，更深入理解“为什么要这么配”，从而在面对其他芯片的加密模块时也能游刃有余。

2. AES-GCM/CCM模式核心原理与MSPM0实现机制

2.1 为什么是GCM和CCM？

在深入寄存器之前，我们必须先理解为什么在嵌入式领域GCM和CCM如此受青睐。传统的加密模式如ECB、CBC只能保证机密性，接收方无法确认数据在传输过程中是否被篡改。而像HMAC这样的认证方式，又需要先加密再计算MAC，两次遍历数据，效率较低。

GCM和CCM属于认证加密（AEAD， Authenticated Encryption with Associated Data）模式。它们在一次处理流程中，同时完成加密和生成认证标签（TAG）。GCM基于CTR模式进行加密，并使用Galois域乘法进行认证，非常适合硬件并行实现，速度极快。CCM则是将CBC-MAC（用于认证）和CTR模式（用于加密）顺序结合，虽然流程上稍显复杂，但其结构被许多无线通信协议（如IEEE 802.11i, Bluetooth LE）所采用。

MSPM0的AESADV模块同时支持这两种模式，其核心设计思想是：将复杂的认证加密算法流程，通过硬件状态机固化，开发者只需按步骤配置上下文（密钥、IV、长度等），然后通过DMA或CPU喂入数据，硬件即可自动完成剩余的所有计算。这大大降低了软件复杂度和时序不确定性。

2.2 MSPM0 AESADV模块架构透视

要驾驭这个硬件加速器，不能把它当成一个黑盒。你需要理解它的几个关键部分：

1. 加密核心（Crypto Core）：执行标准的AES加密/解密运算。这是所有模式的基础。
2. GHASH引擎：这是GCM模式专用的组件，用于在Galois域上进行乘法运算，以生成认证标签。CCM模式不使用此引擎，其认证基于CBC-MAC。
3. 上下文寄存器组：这是配置的核心。包括KEY0-KEY7（密钥）、IV0-IV3（初始化向量）、CTRL（控制模式）、C_LENGTH_0/1（加密数据长度）、AAD_LENGTH（附加认证数据长度）等。一次配置好这些寄存器，就定义了一个完整的加密/解密任务。
4. 数据缓冲区（DATA_IN/OUT）：128位宽度的输入输出缓冲区。数据必须按块（16字节）写入和读出。
5. DMA与事件系统：这是实现高效数据传输的关键。模块可以产生DMA_TRIG_DATAIN和DMA_TRIG_DATAOUT事件，分别触发DMA向DATA_IN送数据和从DATA_OUT取数据。同时，CPU_INT事件用于通知CPU任务完成或状态变化。

模块的工作流程可以概括为：配置上下文 -> 启动传输（DMA或CPU）-> 硬件自动按模式处理数据块 -> 产生完成事件/中断 -> 获取结果和TAG。GCM和CCM的复杂性就隐藏在“按模式处理”这一步中，而硬件为我们代劳了。

2.3 关键约束与硬件特性

从手册的“Note”部分，我们就能挖出几个极易出错的硬件特性，这些是后续配置的基石：

• 数据对齐要求：AAD和加密数据可以以非128位（16字节）对齐结束。但是，CPU必须用零将它们填充到128位边界。这意味着，如果你有23字节的AAD，你需要填充到32字节（下一个16字节的整数倍）。硬件只按整块处理，填充是软件的责任。
• 内存连续性要求（DMA模式）：当使用单个DMA通道来提供AAD和明文数据时，这些数据在内存中必须是连续存放的，顺序是M块AAD紧跟着N块明文。这是因为DMA通道被触发后，会连续不断地传输数据，硬件根据AAD_LENGTH和C_LENGTH寄存器来区分何时AAD结束、何时加密数据开始。如果使用CPU通过中断方式逐个写入数据，则无此限制。
• 长度寄存器重用：如果前后两个数据流使用相同的密钥和控制配置（CTRL寄存器），那么只需要重新加载IV和长度寄存器即可，无需重复配置密钥和模式。这有利于提升连续加密相同类型数据包的效率。
• GMAC模式：这是GCM的一个特例，即没有加密载荷（N=0），只进行认证。此时需要将C_LENGTH_0和C_LENGTH_1寄存器设置为0。

理解这些硬件层面的“脾气”，是成功配置的第一步。接下来，我们将进入具体的配置实战。

3. GCM模式配置详解与实操流程

GCM模式在MSPM0上有多种子模式，主要区别在于哈希子密钥H和初始计数器块Y0的生成方式。手册中提到了“预计算H”和“预计算H与Y0”的模式，我们以最典型的“GCM Operation With Precalculated H- and Y0-Encrypted Forced to Zero”流程为例，因为它清晰地分离了阶段。

3.1 操作流程拆解

这种模式假设我们已经提前计算好了哈希子密钥H（通过一次AES-ECB加密零块得到），并且将加密后的Y0（即J0）强制设为零。其操作序列如下：

1. 提供GCM上下文：写入密钥、预计算的H、数据长度、模式字到相应寄存器。此时CTRL[GCM]应设置为01b（H已加载，Y0加密值强制为0）。
2. 提供AAD数据：将附加认证数据块写入DATA_IN。如果AAD长度不是16字节的整数倍，最后一块需要补零。
3. 提供加密数据：AAD全部提供完毕后，开始写入明文数据块。
4. 读取结果数据：在写入下一个数据块的同时，可以读取上一个块产生的密文输出。这是一个“乒乓”操作。
5. 读取认证标签（TAG）：在所有数据块处理完毕后，连续进行两次“读结果数据”操作（实际是读空，用于清空流水线），最后读取TAG0-3寄存器，得到128位的认证标签。

这个过程高度依赖DMA的自动触发来维持数据流。如果使用CPU轮询，则需要严格遵循“写-等-读-写”的顺序，并监控CTRL[INPUT_RDY]和CTRL[OUTPUT_RDY]状态位。

3.2 寄存器配置实战步骤

假设我们要加密一段数据，并包含一些AAD。以下是基于DMA的配置步骤，这也是最推荐的高效方式：

步骤一：DMA通道配置这是实现“乒乓”操作的关键。我们需要两个DMA通道：一个用于输入（AAD+明文），一个用于输出（密文）。

1. 配置输出DMA通道（用于搬运密文）：

   • 触发源：选择AES Trig1(DMA_TRIG_DATAOUT事件)。
   • 源地址：设置为AES模块的DATA_OUT寄存器地址（0x4003_1188）。
   • 目的地址：设置为SRAM中存放密文的目标缓冲区地址。
   • 传输大小：设置为N * 4（因为DATA_OUT是32位寄存器，每个数据块16字节即4个字，N是加密数据的块数）。
   • 模式：设置为单次传输模式（Burst或Single根据DMA控制器特性决定）。
   • 使能事件：在AES的DMA_TRIG_DATAOUT.IMASK寄存器中，取消屏蔽TRIG1事件。

2. 配置输入DMA通道（用于喂入AAD和明文）：

   • 触发源：选择AES Trig0(DMA_TRIG_DATAIN事件)。
   • 源地址：设置为SRAM中存放AAD和明文数据的源缓冲区起始地址。务必确保AAD在前，明文紧接在后，连续存放。
   • 目的地址：设置为AES模块的DATA_IN寄存器地址（0x4003_1184）。
   • 传输大小：设置为(M + N) * 4，其中M是AAD的块数，N是明文的块数。
   • 模式：同样设置为单次传输模式。
   • 使能事件：在AES的DMA_TRIG_DATAIN.IMASK寄存器中，取消屏蔽TRIG0事件。

步骤二：AES模块基础配置在启动DMA之前，需要先设置好AES模块的上下文。

1. 使能DMA握手：将DMA_HS[DMA_DATA_ACK]位设置为1。这告诉AES模块，数据的输入输出确认将通过DMA握手信号进行，而不是CPU轮询DATA_IN/OUT寄存器。
2. 加载密钥：将128位或256位的AES密钥写入KEY0至KEY3（或KEY7）寄存器。
3. 加载初始化向量（IV）：将96位或128位的IV写入IV0至IV3寄存器。对于GCM，通常使用96位IV，剩余32位硬件会用于计数器。
4. 配置控制寄存器（CTRL）：
   • KEY_SIZ[4:3]：选择密钥长度，01b为128位，11b为256位。
   • DIR[2]：方向，1为加密。
   • GCM[17:16]：设置为01b，表示使用预计算H且Y0加密值强制为0的模式。
   • CTR[6]：必须设置为1，因为GCM的加密部分基于CTR模式。
   • SAVE_CNTXT[29]：强烈建议设置为1。这样在操作结束后，认证标签（TAG）会被保存到TAG0-3寄存器，并产生SAVEDCNTXTRDY中断，方便我们读取。
5. 加载预计算的哈希子密钥H：将预先通过AES-ECB加密零块得到的H值，写入GHASH_H0至GHASH_H3寄存器。
6. 设置数据长度：
   • 将加密数据的字节数（N * 16）写入C_LENGTH_0和C_LENGTH_1寄存器。注意，这里写入的是字节数，不是块数。
   • 将AAD数据的字节数（M * 16）写入AAD_LENGTH寄存器。

步骤三：启动与完成

1. 启动DMA：使能配置好的输入和输出DMA通道。
2. 等待完成：等待输出DMA通道传输完成中断，或者等待AES模块的SAVEDCNTXTRDY中断（如果使能了）。
3. 获取结果：
   • 密文已通过DMA自动存放到目标SRAM缓冲区。
   • 从TAG0、TAG1、TAG2、TAG3寄存器中读取128位的认证标签。通常通信中只传输前若干字节（如96位或128位），由通信协议规定。

关键提示：在配置CTRL寄存器时，GCM和CTR位必须同时有效。GCM位选择认证加密模式，CTR位启用内部的计数器模式用于加密。单独设置GCM位而不设CTR位，将只进行GHASH认证运算，不产生密文输出。

4. CCM模式配置详解与实操流程

CCM模式将认证（CBC-MAC）和加密（CTR）两个阶段串联起来。MSPM0的硬件巧妙地将其整合为一个连续的流程。

4.1 CCM操作流程解析

CCM协议要求认证数据（AAD）必须在加密数据之前处理。硬件严格按照此顺序执行：

1. 构造并加密B0块：硬件内部根据CTRL[CCML]、[CCMM]、Nonce（来自IV）和长度信息构造B0块，并进行一次AES加密，启动CBC-MAC链。
2. 处理AAD：接着处理所有的AAD数据块，更新CBC-MAC。
3. 加密/解密并认证：然后，对于每一块明文，硬件并行执行两个操作：a) 使用CTR模式加密该块；b) 将加密前的明文（或解密后的密文）纳入CBC-MAC计算。这是一个“一次处理，两个结果”的精妙设计。
4. 生成最终TAG：最后，将CBC-MAC的中间结果用加密后的A0块（IV||计数器0）进行加密，得到最终的认证标签。

4.2 CCM寄存器配置步骤

CCM的配置与GCM类似，但有一些特有的参数。

步骤一：DMA通道配置与GCM完全一致，配置输入和输出两个DMA通道，分别绑定到Trig0和Trig1。

步骤二：AES模块CCM上下文配置

1. 使能DMA握手：同样，设置DMA_HS[DMA_DATA_ACK] = 1。
2. 加载密钥与IV：将密钥写入KEYx寄存器，将IV写入IVx寄存器。注意，CCM的IV中需要包含特定的标志位（Flags）和随机数（Nonce），其格式需要遵循CCM标准（RFC 3610）。这部分构造需要由软件完成，然后填入IV寄存器。
3. 配置控制寄存器（CTRL）：
   • KEY_SIZ[4:3]：选择密钥长度。
   • DIR[2]：方向，1为加密。
   • CCM[18]：必须设置为1，选择CCM模式。
   • CTR[6]：同样必须设置为1，启用内部的CTR加密模式。
   • SAVE_CNTXT[29]：设置为1，以便获取TAG。
   • CCML[21:19]：设置长度字段L的值。L决定了消息长度编码的字节数，L = 值，长度字段占L+1字节。例如，CCML=2表示长度字段为3字节。这必须与IV中构造的L值一致。
   • CCMM[24:22]：设置认证字段长度M。M = 值，最终TAG的有效长度为2*(M+1)字节。硬件总是生成128位TAG，但只有低2*(M+1)字节是有效的。例如，CCMM=3表示TAG有效长度为8字节（64位）。
   • CTR_WIDTH[8:7]：设置计数器宽度。此宽度必须足够覆盖CCM-L定义的计数器字段。例如，若CCML=2（长度字段3字节），则计数器部分占15 - 3 = 12字节（从IV中分配），那么CTR_WIDTH必须设置为能容纳12字节的宽度（通常就是128位计数器，即3h）。
4. 设置数据长度：
   • 将加密数据的字节数写入C_LENGTH_0/1。
   • 将AAD数据的字节数写入AAD_LENGTH。

步骤三：启动与完成

1. 使能DMA通道。
2. 等待输出DMA完成中断或SAVEDCNTXTRDY中断。
3. 从SRAM读取密文。
4. 从TAG0-3寄存器读取完整的128位TAG，并根据CCMM的设置，只取相应长度的有效字节用于验证。

避坑指南：CCM参数一致性：CCM配置中最容易出错的地方是CCML、CCMM、CTR_WIDTH以及软件构造的IV（包含Flags和Nonce）这几者之间的一致性。必须严格按照RFC 3610规范计算，确保长度字段、计数器字段、认证字段长度匹配，否则通信双方无法正确加解密和验证。建议将参数计算和IV构造封装成函数，并进行充分的单元测试。

5. 中断与DMA事件管理精要

高效的驱动离不开正确的事件处理。AESADV模块提供了丰富的事件机制，理解它们才能构建稳定可靠的驱动。

5.1 三大事件发布者

模块有三个事件发布者，它们的作用截然不同：

• CPU_INT：向CPU子系统发布中断。用于通知CPU“上下文就绪可写”、“数据输入就绪”、“数据输出就绪”、“保存的上下文（TAG）就绪可读”等状态变化。当使用DMA握手时，INPUTRDY和OUTPUTRDY中断不应被使用，因为数据搬运由DMA自动完成。
• DMA_TRIG_DATAIN：向DMA发布触发事件0。当AES引擎的输入缓冲区空，可以接收新数据时，会发布此事件。通常用于触发DMA将下一块数据从内存搬运到DATA_IN。
• DMA_TRIG_DATAOUT：向DMA发布触发事件1。当AES引擎的输出缓冲区有有效数据时，会发布此事件。通常用于触发DMA将密文从DATA_OUT搬运到内存。

5.2 典型的中断/DMA配置策略

对于GCM/CCM这种流式处理，推荐采用DMA全程搬运数据，CPU仅处理开始和结束的策略。

1. 初始化阶段（CPU负责）：

   • 配置AES上下文寄存器（密钥、IV、模式、长度）。
   • 配置DMA通道（源、目标、长度、触发源）。
   • 在AES模块中，使能DMA_TRIG_DATAIN和DMA_TRIG_DATAOUT的相应事件（设置IMASK寄存器）。
   • 在AES模块中，使能SAVEDCNTXTRDY中断（设置CPU_INT.IMASK寄存器对应位），以便在操作结束时获取TAG。
   • 将DMA_HS[DMA_DATA_ACK]设置为1，启用DMA握手。

2. 数据传输阶段（DMA自动进行）：

   • CPU启动DMA通道。
   • AES引擎处理完一个数据块，输出缓冲区满，触发DMA_TRIG_DATAOUT事件，DMA将密文搬走。
   • 输入缓冲区空，触发DMA_TRIG_DATAIN事件，DMA将下一块AAD/明文搬入。
   • 此过程自动循环，直到所有C_LENGTH和AAD_LENGTH指定的数据全部处理完毕。

3. 结束阶段（CPU中断处理）：

   • 当整个数据流处理完成，且SAVE_CNTXT位被设置，AES模块会产生SAVEDCNTXTRDY中断。
   • CPU在中断服务程序（ISR）中，读取TAG0-3寄存器获取认证标签。
   • 清除中断标志。

这种配置将CPU从繁重的数据搬运中解放出来，仅在关键节点进行干预，极大地提高了系统效率和实时性。

5.3 关键寄存器速查

为了便于配置，这里列出事件管理中最关键的几个寄存器及其功能：

6. 实战中的常见问题与深度排查

即便按照手册配置，在实际调试中依然会遇到各种问题。以下是我在项目中总结的几个典型问题及其排查思路。

6.1 数据对齐与填充陷阱

问题现象：加密/解密结果不对，或者TAG验证失败，尤其是在数据长度不是16字节整数倍时。

根因分析：这是手册中强调但极易忽略的一点。硬件要求AAD和加密数据各自的结尾必须填充到128位边界。即使总长度是16字节的倍数，但如果AAD长度不是，也必须填充。例如，AAD长30字节，加密数据长34字节，总长64字节是16的倍数。但你需要将AAD填充到32字节（补2字节0），加密数据填充到48字节（补14字节0），然后分别设置AAD_LENGTH=32，C_LENGTH=48。

解决方案：

• 在准备发送缓冲区时，显式地进行填充操作。
• 可以使用以下辅助函数：

  // 计算填充到16字节边界后的长度 uint32_t get_padded_length(uint32_t original_len) { return (original_len + 15) & ~0x0F; }

• 在接收端进行解密验证时，也需要知道原始长度以去除填充。通常原始长度会作为协议的一部分进行传输。

6.2 DMA传输长度配置错误

问题现象：DMA传输提前结束，或者卡死，AES引擎状态异常。

根因分析：DMA的传输长度配置错误。输入DMA的传输长度必须是(M + N) * 4（32位字数量），其中M和N是填充后的AAD和加密数据的块数（1块=16字节）。如果配置的是字节数，会导致DMA传输量不足或过剩。

解决方案：

• 明确区分“字节长度”和“块数”。AES引擎的C_LENGTH和AAD_LENGTH寄存器配置的是字节长度。而DMA的传输大小配置，针对的是32位寄存器访问，因此是块数 * 4。
• 建议在代码中定义清晰的变量：

  uint32_t aad_byte_len = ...; // 原始AAD字节长度 uint32_t crypto_byte_len = ...; // 原始加密数据字节长度 uint32_t aad_padded_len = get_padded_length(aad_byte_len); uint32_t crypto_padded_len = get_padded_length(crypto_byte_len); uint32_t aad_block_num = aad_padded_len / 16; uint32_t crypto_block_num = crypto_padded_len / 16; uint32_t dma_input_transfer_size = (aad_block_num + crypto_block_num) * 4; // DMA传输字数

6.3 CCM模式TAG验证失败

问题现象：加解密过程正常，但对方计算的TAG与本方计算的TAG不一致。

根因分析：CCM有多个参数需要双方严格一致，任何细微差别都会导致TAG不同。

1. Nonce不唯一：CCM要求同一个密钥下，每次加密使用的Nonce必须唯一。如果重复使用，会严重破坏安全性。
2. 参数（L, M）不一致：通信双方必须约定相同的CCML（长度字段大小）和CCMM（TAG长度）。一方加密时用L=2，M=3，另一方解密时必须用同样的值。
3. AAD处理不一致：一方发送了AAD，另一方解密时没有提供相同的AAD进行验证。
4. 字节序问题：在将多字节整数（如数据长度）填入IV寄存器或构造B0块时，需要确认芯片的字节序（MSPM0为小端模式），并与协议规范对比。

解决方案：

• 严格管理Nonce：使用一个可靠的计数器或随机数生成器来产生Nonce。
• 参数固化：在协议层将L和M定义为固定值，避免运行时配置错误。
• 完整传递参数：在加密数据包中，可以包含Nonce、AAD长度等元信息（当然，AAD本身可能也需要传输）。或者，这些信息通过带外方式同步。
• 单元测试：编写测试用例，使用标准的测试向量（如NIST提供的CAVP测试向量）来验证你的CCM实现是否正确，这能排除绝大多数参数和实现逻辑错误。

6.4 上下文就绪与连续操作

问题现象：连续加密多个数据包时，第二个包操作无法启动或数据混乱。

根因分析：没有正确管理AES引擎的上下文状态。当一个数据流结束后，硬件可能还在等待读取TAG（如果SAVE_CNTXT被设置），或者上下文寄存器未被释放。此时直接写入新的数据会导致冲突。

解决方案：

1. 等待上下文就绪：在启动新的加密操作前，检查CTRL[CNTXT_RDY]位是否为1。或者，等待CNTXTRDY中断。
2. 正确读取TAG：如果上一个操作设置了SAVE_CNTXT，必须在启动新操作前从TAG0-3寄存器读取TAG，否则SAVEDCNTXTRDY状态会一直保持，阻止新上下文写入。
3. 利用手册提示：如果前后数据流使用相同的密钥和CTRL配置，可以只重载IV和长度寄存器，这比完全重新配置上下文更高效。但前提是上一个操作已经完全结束，且上下文处于就绪状态。

通过系统地理解原理、仔细地配置寄存器、并警惕这些常见的陷阱，你就能稳健地在MSPM0乃至其他嵌入式平台上驾驭AES-GCM/CCM硬件加速器，为你的产品构建坚实的安全基石。安全无小事，每一个细节都值得深究。