1. 项目概述与核心价值

在嵌入式安全领域，尤其是物联网和边缘计算设备中，数据在传输和存储时的机密性与完整性是产品设计的生命线。AES（高级加密标准）算法作为对称加密的基石，其软件实现虽然灵活，但在处理大量数据或对实时性要求苛刻的场景下，CPU的算力消耗和延迟往往成为瓶颈。这时，硬件AES加速器的价值就凸显出来了——它就像在主处理器旁边安置了一个专业的“加密协处理器”，专门负责处理繁重的加解密运算，让主CPU得以解放，专注于业务逻辑。

然而，仅仅实现加密（机密性）在今天已经不够了。攻击者可以篡改密文，导致解密出乱码，或者重放有效的加密数据包进行攻击。因此，现代安全协议普遍要求“认证加密”，即同时提供机密性、完整性和真实性。GCM（Galois/Counter Mode）和CCM（Counter with CBC-MAC）正是为了满足这一需求而诞生的两种重要模式。它们将加密和消息认证码（MAC）计算融合在一个步骤中，效率远高于先加密再单独计算MAC的传统方式。

本文将以德州仪器（TI）某款微控制器中的AES硬件加速器模块为蓝本，深入剖析其内部机制。我们不止步于手册的翻译，而是结合我多年在嵌入式安全驱动开发中的实战经验，带你穿透寄存器配置的表象，理解GCM/CCM模式在硬件中是如何流水线化执行的，如何通过DMA和中断高效搬运数据，以及如何避开那些手册里不会写明、但实际开发中一踩一个坑的陷阱。无论你是正在为产品添加安全功能的嵌入式软件工程师，还是希望深入理解硬件加密原理的开发者，这篇指南都将提供从理论到寄存器位操作的完整路径。

2. AES硬件加速器架构与工作模式深度解析

要驾驭一个硬件模块，首先要理解它的“脾气”和“能力边界”。TI的这款AES加速器是一个相对独立的硬件IP，通过系统总线与CPU核心、内存以及DMA控制器连接。其核心是一个高度优化的AES轮函数计算单元，能够在一个或几个时钟周期内完成一轮AES运算（包括SubBytes, ShiftRows, MixColumns, AddRoundKey）。对于128-bit数据块，完成一次加密或解密需要10/12/14轮（对应128/192/256-bit密钥）。

2.1 核心引擎与宽总线设计

模块手册中提到的“wide-bus engine”是一个关键设计。这意味着数据通路可能被设计为128位或更宽，使得一个完整的AES数据块（16字节）可以在一个总线周期内被吞入或吐出，极大提升了数据吞吐率，减少了总线访问开销。这是硬件加速器相对于软件实现（通常以字节或32位字为单位操作）的巨大优势。

模块支持多种基础模式：

• ECB (Electronic Codebook)： 最基础的模式，每个数据块独立加密。因其固有的安全性缺陷（相同的明文块产生相同的密文块），在实际安全通信中应避免使用。
• CBC (Cipher Block Chaining)： 引入初始化向量（IV）和链式反馈，相同明文加密后密文不同，是早期广泛使用的模式。
• CTR (Counter)： 将IV与一个计数器加密后，再与明文进行异或得到密文。它具有并行计算、无需填充、可随机访问等优点，是GCM模式的基础。
• CFB (Cipher Feedback) & OFB (Output Feedback)： 流密码模式，适用于实时数据流加密，但在此硬件中可能以特定变体（如CFB128）实现。

2.2 认证加密模式：GCM vs. CCM

这是本文的重点。GCM和CCM目标一致，但实现路径和硬件需求不同。

GCM (Galois/Counter Mode) 模式：GCM本质上是CTR模式（用于加密）加上GMAC（Galois Message Authentication Code，用于认证）。其精妙之处在于认证部分使用了伽罗瓦域（Galois Field, GF(2^128)）上的乘法，这是一种非常高效的硬件友好型运算。

1. 加密流程： 完全基于CTR模式。使用一个IV生成初始计数器，然后对递增的计数器值进行AES加密，生成密钥流，再与明文异或。
2. 认证流程： 将所有需要认证的数据（包括附加认证数据AAD和密文）进行GF(2^128)乘法运算，最终生成一个128位的认证标签（Tag）。关键在于，GF乘法可以与CTR模式的加密并行执行，因为它们是两个独立的计算单元。这正是手册中提到“authentication operation does not require the cryptographic core but only the polynomial multiplication, encryption, decryption, and authentication can be performed in parallel”的原因。硬件内部很可能有一个独立的伽罗瓦域乘法器。

CCM (Counter with CBC-MAC) 模式：CCM则是先CBC-MAC（用于认证），后CTR（用于加密）的顺序组合模式。

1. 认证流程： 首先，它使用CBC模式（但仅使用加密操作）处理一个经过特定格式编排的B0块（包含标志、随机数、消息长度等），然后是AAD和明文数据，最终输出一个CBC-MAC值（即认证码的雏形）。这个过程完全占用AES核心。
2. 加密流程： 然后，切换为CTR模式，对明文进行加密。最后，还需要对第1步得到的CBC-MAC值进行一次CTR模式的加密，得到最终的认证标签。
3. 核心差异： CCM的认证和加密是顺序执行的，都依赖同一个AES密码核心。这意味着其吞吐率理论上低于可以并行的GCM。CCM的优势在于它只使用标准的AES加密原语，无需额外的伽罗瓦域乘法器，在资源受限且只需支持CCM的平台上可能实现更简单。

模式选择实战建议：

• 性能优先： 选择GCM。其并行架构在硬件支持下能提供更高的吞吐率。
• 兼容性与资源： 如果对接的旧有协议或标准强制要求CCM，或者目标硬件没有专用的GF乘法器（纯软件模拟GCM的GF乘法很慢），则选择CCM。
• AAD处理： GCM明确支持任意长度的AAD，且AAD处理独立于加密数据流，非常灵活。CCM的AAD处理则被整合在CBC-MAC计算序列中，格式要求更严格。

3. 关键寄存器详解与编程模型

手册列出了数十个寄存器，但驱动开发者的关注点应集中在几个控制核心流程的寄存器上。盲目地对照手册“填寄存器”很容易出错，必须理解每个位域背后的状态机。

3.1 控制核心：AES_CTRL寄存器

这是整个模块的“大脑”。其位域配置决定了加速器的一切行为。我们逐位域分析其配置逻辑和陷阱：

位域[24:22] CCM_M与[21:19] CCM_L：

• CCM_M： 定义认证字段（Authentication Tag）的长度。计算公式为Tag长度（字节） = 2 * (CCM_M值 + 1)。例如，CCM_M=3，则Tag长度为2*(3+1)=8字节。硬件总是计算一个128位（16字节）的Tag，但只返回最低的M字节有效。常见坑点： 必须与通信对端协商一致。TLS中常用8字节或16字节Tag，CCM_M需相应设置为3或7。
• CCM_L： 定义长度字段（L）的宽度。L = CCM_L值 + 1（单位：字节）。手册指出仅支持L=2,4,8字节（即CCM_L=1,3,7）。这决定了IV（Nonce）的长度为15-L字节。配置错误将导致加解密双方对数据长度的解读完全不同，认证必然失败。

位域[17:16] GCM：此字段选择GCM的子模式，关乎初始向量Y0和哈希子密钥H的生成方式。

• 00： 非GCM模式。
• 01：GHASH with H loaded and Y0-encrypted forced to zero。此模式下，你需要通过AES_KEY2寄存器手动加载哈希子密钥H（即对全0块加密的结果），并且硬件假设Y0（由IV生成）的加密值为0。这是一种高级优化模式，用于连续处理多个数据包时复用已计算的H，但初始设置复杂，容易出错，新手不建议使用。
• 10：GHASH with H loaded and Y0-encrypted calculated internally。你需要手动加载H，但硬件会自己计算Y0的加密值。这是最常用的模式，在单次或多次操作中提供了灵活性。
• 11：Autonomous GHASH。你只需要提供IV和密钥，硬件内部自动计算H和Y0的加密值。最简单易用，但可能每次操作都有少量固定开销。

位域[8:7] CTR_WIDTH：此字段在CTR、GCM、CCM模式下都至关重要。它定义了计数器的宽度。

• 00(32-bit)： 计数器为32位。这意味着在IV固定的前提下，最多可以加密2^32个数据块。超过此限制，计数器会回绕，导致密钥流重复，这是灾难性的安全漏洞。GCM规范通常使用32位计数器。
• 01(64-bit)/10(128-bit)/11(192-bit)： 提供更宽的计数器，支持加密海量数据而无需更换IV。必须根据你协议中IV和计数器的定义来严格设置此字段。例如，某些实现可能使用64位Nonce+64位计数器。

位域[6] CTR：这是一个极易被忽略的陷阱位。手册明确写道：“This bit must also be set for GCM and CCM, when encryption or decryption is required.” 这意味着，即使你设置了GCM=2或CCM=1，如果操作涉及加密/解密（而不仅仅是纯认证），你必须同时将CTR位置1。因为GCM的加密部分和CCM的加密部分都是CTR模式。忘记设置此位，可能导致加密/解密功能不生效，而认证计算却看似正常，问题非常隐蔽。

位域[4:3] KEY_SIZE与[2] DIRECTION：

• KEY_SIZE： 必须与AES_KEY1（和AES_KEY2，如果使用）寄存器中实际写入的密钥数据位数严格匹配。写入128位密钥却配置为256位模式，会导致行为未定义。
• DIRECTION： 加密（1）或解密（0）。在GCM和CCM模式下，解密操作同样需要验证Tag。流程通常是：硬件同时进行CTR模式解密和认证计算，最后比较生成的Tag与附带的Tag是否一致。

3.2 数据与长度寄存器

• AES_KEY1_*,AES_KEY2_*： 密钥寄存器。注意字节序（Endianness）。通常，最低地址的寄存器（如AES_KEY1_0）存储密钥的最低有效字（LSW）。写入前务必确认芯片的字节序（通常是小端）。
• AES_IV_IN_*： 初始化向量寄存器。对于GCM/CCM，这里填入的不是简单的IV，而是根据模式规范构造的“初始化向量”。例如GCM，通常这里填入的是J0（经过GHASH处理的IV）。这是另一个常见错误来源：直接填入协议层的IV，而非硬件期望的格式。
• AES_C_LENGTH_0/1：加密/解密数据的长度（字节数）。手册强调，对于GCM和CCM，此长度仅指需要加密/解密的数据（Ciphertext/Plaintext）长度，不包括附加认证数据（AAD）。AAD的长度由AES_AUTH_LENGTH寄存器指定。写入此寄存器会触发上下文加载或操作开始（对于非GCM/CCM模式）。
• AES_AUTH_LENGTH：仅认证数据（AAD）的长度（字节数）。用于GCM和CCM模式。即使AAD长度为0，也需要正确配置该寄存器为0。

3.3 状态与中断寄存器

• AES_IRQSTATUS&AES_IRQENABLE： 用于软件轮询或中断模式。可以监控上下文输入/输出就绪、数据输入/输出就绪。
• AES_SYSCONFIG： 包含DMA使能位。要使用DMA传输数据，必须在此使能相应的DMA通道请求。
• DTHE_AES_*： 这一组寄存器是连接到系统DMA控制器的，用于管理DMA传输完成中断等。需要与芯片的通用DMA控制器配置协同工作。

4. 实战编程流程与代码剖析

理解了寄存器，我们来看如何将它们串联起来完成一次GCM加密操作。假设场景：使用128位密钥，GCM模式（自动生成H和Y0），通过DMA传输数据。

4.1 全局初始化序列

这是任何操作开始前必须执行的一次性设置。

// 1. 使能加密模块时钟（此寄存器地址需查具体芯片手册） volatile uint32_t *cryptoclken = (volatile uint32_t*)0x440250B8; *cryptoclken |= (1 << 0); // 假设R0位是AES时钟使能位 // 2. 配置DMA通道映射（此处为示例，需根据具体μDMA控制器编程） // 通常需要设置DMA_CHMAPn寄存器，将AES的Context In/Out, Data In/Out请求映射到具体的DMA通道。 configure_dma_channel(AES_CONTEXT_IN_CH, ...); configure_dma_channel(AES_DATA_IN_CH, ...); // ... 配置其他通道 // 3. 配置AES_SYSCONFIG，使能所需的DMA请求 AES->SYSCONFIG = (1 << 5); // 使能Data In DMA请求，位位置需查证 // 同时使能DMA完成中断（如果需要） DTHE_AES->IM |= DTHE_AES_IM_DMA_DONE_MASK; // 4. 密钥大小在后续AES_CTRL中设置，此处暂不操作。 // 5. & 6. 加载密钥。在操作序列中完成。

4.2 GCM加密单次操作序列

我们采用“Autonomous GHASH”模式（GCM=3），以简化流程。

// 步骤 1: 配置AES_CTRL寄存器，设置模式、密钥大小、方向等。 // 假设我们使用128位密钥，GCM模式，加密方向，32位计数器。 uint32_t ctrl_value = 0; ctrl_value |= (3 << 16); // GCM[1:0] = 0b11, Autonomous GHASH ctrl_value |= (0 << 7); // CTR_WIDTH[1:0] = 0b00, 32-bit counter ctrl_value |= (1 << 6); // CTR = 1, 必须设置！ ctrl_value |= (1 << 3); // KEY_SIZE[1:0] = 0b01, 128-bit key ctrl_value |= (1 << 2); // DIRECTION = 1, 加密 // 注意：SAVE_CONTEXT位用于在操作结束后保存上下文（如Tag），如果需要获取Tag则置1。 ctrl_value |= (1 << 29); // SAVE_CONTEXT = 1 AES->CTRL = ctrl_value; // 步骤 2: 加载认证数据(AAD)长度。假设本次没有AAD。 AES->AUTH_LENGTH = 0; // 步骤 3: 加载初始化向量(IV)。对于GCM Autonomous模式，直接写入12字节的IV（96位是GCM推荐长度）。 // 写入AES_IV_IN_0到AES_IV_IN_2（3个32位寄存器=96位）。 AES->IV_IN_0 = iv_word0; // IV的低32位 AES->IV_IN_1 = iv_word1; AES->IV_IN_2 = iv_word2; // IV的高32位 AES->IV_IN_3 = 0; // 高32位补0，因为我们是96位IV // 步骤 4: 加载密钥到AES_KEY1寄存器。 AES->KEY1_0 = key_word0; AES->KEY1_1 = key_word1; AES->KEY1_2 = key_word2; AES->KEY1_3 = key_word3; // 步骤 5: 写入加密数据长度，这将触发上下文加载并启动准备。 // 假设需要加密`data_len`字节的数据。 AES->C_LENGTH_0 = data_len & 0xFFFFFFFF; // 低32位 AES->C_LENGTH_1 = (data_len >> 32) & 0x1FFFFFFF; // 高29位，注意寄存器位宽 // 步骤 6: 等待上下文就绪（CONTEXT_READY）。 while (!(AES->CTRL & (1 << 31))) { // 忙等待或让出CPU。在实际中，应使用中断或超时机制。 } // 步骤 7: 启动DMA传输明文数据到AES_DATA_IN寄存器，并传输密文数据从AES_DATA_OUT。 // 这里需要配置DMA描述符，源地址=明文缓冲区，目的地址=&AES->DATA_IN_0，传输长度=data_len。 // 同时配置另一个DMA通道，源地址=&AES->DATA_OUT_0，目的地址=密文缓冲区。 start_dma_transfer(AES_DATA_IN_CH, plaintext_buf, (void*)&AES->DATA_IN_0, data_len); start_dma_transfer(AES_DATA_OUT_CH, (void*)&AES->DATA_OUT_0, ciphertext_buf, data_len); // 步骤 8: 等待DMA传输完成中断或轮询状态。 wait_for_dma_completion(); // 步骤 9: 操作完成后，读取认证标签(Tag)。 // 因为SAVE_CONTEXT被设置，Tag会被保存在上下文输出区域，通常可通过AES_TAG_OUT寄存器或DMA读取。 uint32_t tag[4]; // 128位Tag tag[0] = AES->TAG_OUT_0; tag[1] = AES->TAG_OUT_1; tag[2] = AES->TAG_OUT_2; tag[3] = AES->TAG_OUT_3; // 注意：实际传输的Tag可能只有一部分有效（如GCM通常输出128位，CCM可能只取前M字节）。

4.3 DMA模式与中断模式的选择

• 轮询模式： 最简单，但CPU利用率低。适用于极少量数据或调试阶段。流程就是写数据到AES_DATA_IN_n，轮询OUTPUT_READY位，然后从AES_DATA_OUT_n读取。
• 中断模式： 每次处理完一个数据块（16字节）就会产生中断。这对于大数据量来说中断频率太高，会严重拖累系统性能。手册也明确指出：“To support larger data flow, AES μDMA mode should be used”。
• DMA模式：生产环境的必然选择。CPU只需初始化DMA和AES，然后处理DMA完成中断即可。数据搬运完全由DMA控制器负责，AES加速器和DMA并行工作，实现最高的吞吐率。关键在于正确配置AES_SYSCONFIG中的DMA使能位，并设置好DMA通道的源/目标地址和传输量。

5. 常见问题排查与调试心得

在调试硬件AES驱动时，问题往往不是算法错误，而是配置或时序的细微差错。

问题1：GCM/CCM认证失败，但加密数据看似正确。

• 排查思路：
  1. 检查AES_CTRL的CTR位： 这是最容易被忽略的。确认在GCM/CCM加密/解密时，此位已置1。
  2. 核对IV格式： 确认写入AES_IV_IN_n寄存器的值是否符合GCM/CCM规范。对于GCM，96位IV是直接使用的；对于CCM，IV需要构造为B0块的一部分。强烈建议在代码中打印出准备写入寄存器的IV值，与标准测试向量或软件实现进行比对。
  3. 检查长度寄存器： 确认AES_C_LENGTH是加密数据的长度，AES_AUTH_LENGTH是AAD的长度。两者之和不能超过模式规定的最大长度（特别是GCM的2^36-32字节限制）。
  4. 验证Tag比较逻辑： 解密时，硬件计算出的Tag需要与数据包中附带的Tag进行恒定时间比较（即无论是否匹配，比较所花时间都应相同），以防止侧信道攻击。不要用简单的memcmp。

问题2：DMA传输后，数据损坏或长度不对。

• 排查思路：
  1. 字节序与数据对齐： 确保DMA传输的数据是字节对齐的（8-bit），且内存中的字节序与寄存器期望的字节序一致。有些硬件要求数据在内存中按特定方式对齐（如32位对齐）。
  2. DMA传输大小： AES引擎一次处理16字节块。确保DMA传输的总长度是16的倍数。如果不是，需要根据模式的处理规则处理剩余字节（例如，CTR模式可以处理任意长度，但硬件可能仍要求以块为单位传输，最后一个块由硬件或软件处理填充）。
  3. 上下文就绪等待： 在启动DMA传输数据之前，必须确保CONTEXT_READY位为1。如果在上下文未就绪时写入数据，行为是未定义的。
  4. 缓冲区溢出： 确保为DMA配置的输出缓冲区足够大，能够容纳密文和Tag。

问题3：性能未达到预期。

• 排查思路：
  1. 使用DMA而非中断： 这是最大的性能提升点。
  2. 检查总线竞争： 如果AES加速器、DMA和CPU频繁访问同一块内存或总线，会产生仲裁延迟。考虑使用专为DMA设计的静态缓冲区（SRAM中），并与CPU缓存区域隔离。
  3. 批处理操作： 对于多个独立的数据包，是否可以复用密钥和部分上下文（如GCM的H）？通过合理设置SAVE_CONTEXT和GCM模式位，可以减少重复初始化开销。
  4. 测量实际时钟： 确认AES加速器的时钟（CRYPTOCLKEN）是否已正确使能并运行在预期频率下。

问题4：在多任务或RTOS环境中，驱动重入问题。

• 解决方案： AES硬件加速器通常是一个全局资源。驱动必须实现互斥锁（mutex）来保证同一时间只有一个任务/线程访问该硬件。在初始化序列和每次操作序列开始前加锁，在DMA完成中断处理程序或操作完成后解锁。

调试技巧：

• 寄存器快照： 在关键步骤（初始化后、启动DMA前、中断发生时）打印所有关键寄存器的值（AES_CTRL,AES_IRQSTATUS, 长度寄存器等），与预期值对比。
• 使用已知向量测试： NIST或RFC 3610（CCM）、RFC 4543（GCM）提供了标准测试向量。首先用一个小数据块，禁用DMA，使用轮询模式，一步步比对中间结果（如第一次CTR输出、第一次GF乘法结果）和最终Tag，这是定位问题最有效的方法。
• 逻辑分析仪/示波器： 如果问题极其棘手，可以尝试抓取AES模块与DMA之间的请求/应答信号，或者查看总线上的数据流，确认数据传输的时序和内容是否正确。