深入解析AES硬件加速器：CCM/GCM与优化模式的实现原理与实战

1. 项目概述

在嵌入式系统，尤其是网络通信、物联网网关和边缘计算设备中，数据的安全传输与存储是核心需求。AES（高级加密标准）作为对称加密的黄金标准，其算法本身虽然高效，但在处理海量数据流时，纯软件实现往往会成为性能瓶颈，消耗大量CPU资源。这时，硬件加密加速器（Cryptographic Hardware Accelerator, CHA）的价值就凸显出来了。它就像一颗专为加密运算设计的“协处理器”，能够以极低的功耗和极高的吞吐量，卸载主CPU的加密解密负担。

然而，仅仅有AES的ECB或CBC模式是不够的。现代安全协议，如IPsec、TLS 1.2/1.3、Wi-Fi WPA3等，普遍要求同时实现数据的机密性（加密）和完整性/认证（防篡改）。这就催生了像CCM（Counter with CBC-MAC）和GCM（Galois/Counter Mode）这样的认证加密（Authenticated Encryption, AE）模式。它们在一个算法流程内，同时完成加密和生成消息认证码（MAC）。在硬件中高效、正确地实现这些模式，涉及到一系列精巧的状态管理和数据流控制。

本文将以NXP QorIQ LS1046A处理器中的AES加速器（AESA）模块为蓝本，深入剖析CCM、GCM以及为特定协议优化的CBC-XCBC等模式在硬件中的实现原理。我们不会停留在API调用层面，而是深入到上下文寄存器、数据流FIFO、多会话处理和ICV检查这些硬件工程师和底层驱动开发者必须面对的细节。理解这些，你才能写出不仅功能正确，而且性能最优的驱动程序，并能在出现异常时，快速定位问题是出在算法逻辑、数据填充，还是硬件状态机的配置上。

2. 核心概念与硬件加速器基础

在深入具体模式之前，我们需要建立几个关键概念，并了解AESA这类硬件加速器的基本工作模型。这有助于理解后续所有配置和流程的“为什么”。

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

CCM和GCM是两种最主流的认证加密模式，但设计哲学和内部结构截然不同。

AES-CCM本质上是两个经典模式的组合：CTR模式用于加密，CBC-MAC用于生成认证标签（MAC）。它的流程是串行的：先准备好认证数据（B0，附加数据AAD，明文），完成CBC-MAC计算得到一个原始MAC，然后用CTR模式加密明文，并顺便加密这个原始MAC得到最终的ICV。CCM的一个特点是，其MAC长度、AAD长度等信息都编码在初始向量B0中，且整个流程对数据的长度和结构有严格限制（例如，消息长度需要在处理前确定）。这种确定性在某些嵌入式场景中是优点，但也带来了灵活性上的限制。

AES-GCM则采用了并行的结构。它同样使用CTR模式进行加密，但认证部分使用了基于伽罗华域（Galois Field）的GHASH算法。GHASH是一种“通用哈希”，它能够以流式方式处理任意长度的数据和AAD，计算效率极高，并且天然支持并行化。GCM的IV处理也更灵活：如果IV不是12字节，会先通过GHASH计算出一个初始计数器Y0。GCM通常比CCM拥有更高的吞吐量，尤其是在硬件实现中，GHASH的乘法运算可以被高度优化。

简单类比：CCM像是一个严谨的、需要提前报备所有材料的审批流水线；而GCM则像一条灵活的、可以随时加塞原料的自动化生产线。在硬件加速器中，这两种模式都被实现为独立的“硬件电路”，通过配置不同的模式寄存器来激活相应的数据通路。

2.2 硬件加速器的工作模型：描述符与状态机

像NXP AESA这样的硬件加速器，通常不是通过简单的函数调用来工作的。它遵循一种“描述符”（Descriptor）驱动模型。软件（驱动）需要准备一个或多个描述符，每个描述符本质上是一个包含了所有操作指令和参数的数据结构包，然后将其提交给加速器。

一个典型的描述符会包含以下信息：

1. 模式寄存器（Mode Register）：告诉硬件要执行什么操作（加密/解密、CCM/GCM模式、是否进行ICV检查等）。
2. 上下文指针（Context Pointer）：指向一块内存区域（上下文寄存器镜像），用于保存和恢复中间状态，这是实现多会话处理的关键。
3. 密钥指针/数据：提供加密密钥。
4. 数据大小（Data Size Register）：要处理的数据总字节数。
5. 输入/输出数据指针：指向待处理数据和结果存放位置。
6. 其他模式特定参数：如AAD大小、ICV大小等。

硬件加速器内部是一个精密的状态机。它读取描述符，按配置加载密钥和上下文，然后从输入FIFO读取数据块，经过加密/认证核心处理，将结果写入输出FIFO，并更新上下文状态。处理完毕后，通过中断或轮询方式通知CPU。

多会话处理是这个模型的核心能力。一个大的消息（例如一个IPsec数据包）可以被分成多个物理上不连续的数据块（会话），分多次提交。硬件依靠上下文寄存器在会话间保存和恢复中间计算状态（如CBC-MAC的中间值、CTR计数器的当前值、GHASH的累加状态等），从而实现无缝的连续处理。这极大地提升了驱动程序的灵活性，允许进行零拷贝（zero-copy）数据处理。

2.3 关键硬件寄存器精讲

理解寄存器是理解硬件行为的基础。以下是几个贯穿所有模式的核心寄存器：

1. 模式寄存器（Mode Register）：这是加速器的“控制面板”。几个关键字段决定了整个操作的走向：

• 算法（ALG）：设置为10h来激活AESA引擎。
• 算法状态（AS）：这是多会话处理的核心。它定义了当前描述符在完整消息处理流程中的位置：
  • UPDATE (0h)：中间会话。处理消息的一部分，既不是开始也不是结束。
  • INITIALIZE (1h)：初始化或特定中间状态。对于CCM/GCM，可能意味着开始处理或进行GHASH的最终步骤。对于优化模式，意味着首次会话，用于计算派生密钥。
  • FINALIZE (2h)：最终会话。处理最后一部分数据并计算最终MAC。
  • INITIALIZE/FINALIZE (3h)：单会话模式。从开始到结束在一个描述符内完成。
• 加密（ENC）：1为加密，0为解密。在认证加密中，解密流程通常也包含认证计算。
• ICV测试（ICV_TEST）：设置为1时，硬件会在处理结束后，自动比较计算出的MAC和从输入FIFO收到的MAC（ICV），如果不匹配则产生错误。重要规则：此位为1时，AS通常必须设置为FINALIZE或INITIALIZE/FINALIZE，除非是纯ICV检查作业（AS=UPDATE且数据大小为0）。
• 附加算法信息（AAI）：用于选择具体的子模式，例如80h对应CCM，90h对应GCM，0A0h-0E0h对应不同的优化模式。

2. 上下文寄存器（Context Register）：这是一组（通常是8个128位）的寄存器或对应的内存区域。它是硬件加速器的“短期记忆”。在不同模式下，它存储的内容完全不同：

• 在CCM中，它存储B0、初始计数器CTR0、中间MAC状态、加密后的计数器等。
• 在GCM中，它存储中间MAC（GHASH状态）、当前计数器Yi、初始计数器Y0、以及IV/AAD/文本数据的位长度累计值。
• 在优化模式中，它可能存储CBC-IV、CTR0、派生密钥（K1, K2, K3, L）或部分数据块。
• 关键作用：当一个会话（描述符）处理完毕，硬件会将当前状态写回上下文内存。下一个会话开始前，软件必须将这份上下文数据重新加载到硬件中，处理才能从上次中断的地方继续。这是实现流式处理和数据分片的基石。

3. 数据大小寄存器（Data Size Register）：指定当前描述符要处理的字节长度。对于多会话，第一次写入会初始化内部计数器，后续写入会进行累加。硬件在处理每个16字节块后递减该值。一个极易出错的点：对于大多数模式，消息分割（多会话）必须在16字节边界上进行，这意味着Data Size的最终值（或每个会话的值）必须是16的倍数，否则会触发数据大小错误。

3. AES-CCM模式硬件实现深度解析

CCM模式在硬件中的实现，可以看作是对其标准算法流程的硬件化映射，并增加了状态保存和多会话支持。

3.1 CCM数据流与寄存器配置实战

让我们跟随一个CCM加密请求，看数据如何在AESA中流动。假设我们要加密一段消息，并包含一些附加认证数据（AAD）。

步骤1：准备阶段（软件驱动完成）

1. 构造B0和CTR0：根据CCM标准，生成包含标志、Nonce、消息长度等信息的B0块，以及初始计数器CTR0。这是软件的责任。
2. 配置模式寄存器：
   • ALG = 10h(激活AESA)
   • AAI = 80h(选择CCM模式)
   • ENC = 1(加密)
   • ICV_TEST = 0(假设我们只生成MAC，暂不验证)
   • AS = 3h(假设我们单会话完成，即INITIALIZE/FINALIZE)
3. 准备上下文：将B0和CTR0分别写入上下文寄存器的DWord 0-1和DWord 2-3。DWord 6的高32位写入AAD的字节长度（如果无AAD则为0），低32位写入编码后的MAC长度（如MAC为16字节则编码为4）。
4. 设置数据大小：将整个消息（明文）的字节长度写入数据大小寄存器。
5. 加载密钥：将AES加密密钥写入密钥寄存器。

步骤2：硬件初始化处理当驱动写入最后一个必要寄存器（通常是数据大小寄存器）后，硬件状态机启动：

1. 加密CTR0：硬件使用加载的密钥，在CTR模式下加密CTR0，结果存入上下文DWord 4-5。这个加密后的值将用于后续生成密钥流。
2. 处理B0：将B0作为第一个块，进行CBC-MAC计算。得到的中间MAC状态存入上下文DWord 0-1。
3. 解码长度：从B0中解码出MAC大小，存入上下文DWord 6的低位。

步骤3：核心加密与认证流程

1. 处理AAD：如果存在AAD，硬件会从输入FIFO（数据类型标记为AAD）读取数据，进行CBC-MAC处理，更新上下文DWord 0-1中的中间MAC状态。AAD的总长度会被记录在DWord 6的高位。
2. 处理明文：对于每一个16字节的明文块：
   • 加密：使用CTR模式生成密钥流（基于加密后的CTR0和递增的计数器），与明文异或得到密文，输出到输出FIFO。
   • 认证：将密文（注意，CCM的CBC-MAC是对密文进行的，这与一些其他模式不同）送入CBC-MAC链，更新上下文DWord 0-1中的中间MAC状态。
   • 每处理一个块，数据大小寄存器值减16，内部CTR计数器递增。
3. 生成最终ICV：所有数据处理完毕后：
   • 完成CBC-MAC的最后计算，得到原始MAC。
   • 使用CTR模式的一个特定计数器（通常是CTR0，计数器字段为0）加密这个原始MAC，得到最终的ICV。
   • 将最终ICV写入上下文DWord 4-5（覆盖之前加密的CTR0）。同时，原始的（未加密的）MAC也会被写入上下文DWord 0-1。

关键注意事项：CCM的“先到先得”CCM要求消息总长度在处理开始前就必须确定，并编码在B0中。这意味着在硬件实现中，Data Size Register必须在第一个描述符中一次性写入总长度，或者在多会话中，第一个描述符写入的长度必须是最终总长度。你不能像流式加密那样，不知道总长度就开始处理。这是CCM协议本身的特性，硬件会严格执行，如果后续累计长度与初始B0中的长度不符，会导致认证失败。

3.2 多会话CCM处理与上下文切换

对于超长消息，单会话可能不现实。CCM支持多会话，但规则严格。

场景：一个消息被分成两个会话处理。

• 会话1 (AS = UPDATE)：
  • 驱动配置AS为UPDATE。
  • 上下文初始化时包含B0和CTR0。
  • 写入第一部分消息的数据大小（必须是16的倍数）。
  • 硬件处理这部分数据，更新中间MAC状态和CTR计数器，并将这些新状态写回上下文内存。
• 会话间：驱动必须保存会话1结束后的完整上下文。
• 会话2 (AS = FINALIZE)：
  • 驱动在启动会话2前，必须将保存的上下文（包含最新的中间MAC和CTR值）重新加载到硬件上下文寄存器中。
  • 配置AS为FINALIZE。
  • 写入剩余消息的数据大小。
  • 硬件从恢复的状态继续处理，最后完成MAC计算和加密，生成ICV。

一个常见的坑：忘记在FINALIZE会话前恢复上下文。这会导致硬件从初始状态重新开始计算，MAC验证必然失败。上下文管理是驱动开发者的核心责任。

3.3 ICV检查流程详解

ICV检查是认证解密的关键。在解密端，流程稍有不同。

1. 解密流程：配置ENC=0。硬件处理流程与加密类似，但CTR密钥流用于解密（CTR模式加解密相同），同时它对接收到的密文进行CBC-MAC计算。
2. 提供接收到的ICV：发送方传来的ICV（即加密后的MAC）必须被放置在输入FIFO中紧接在密文数据之后，并且必须将这部分数据的FIFO数据类型标记为ICV。
3. 启用自动检查：设置ICV_TEST=1，并且AS必须为FINALIZE或INITIALIZE/FINALIZE。
4. 硬件自动比对：硬件在内部计算出原始MAC后，会用CTR模式解密接收到的ICV，然后将解密结果与自己计算的原始MAC进行比较。
5. 结果：如果匹配，正常完成；如果不匹配，硬件会置位错误状态寄存器（产生ICV错误）。绝对不要在启用ICV检查的同时设置ENC=1，这会产生非法模式错误。

4. AES-GCM模式硬件实现深度解析

GCM的硬件实现逻辑与CCM有显著区别，其并行特性和灵活的IV处理带来了不同的配置方式。

4.1 GCM数据流与寄存器配置实战

GCM处理的数据类型和顺序是固定的：IV -> AAD -> 消息数据（明文/密文）-> （可选的接收ICV）。每种数据都必须通过FIFO数据类型字段明确告知硬件。

步骤1：准备与初始化

1. 配置模式寄存器：
   • ALG = 10h
   • AAI = 90h(选择GCM模式)
   • ENC = 1或0
   • ICV_TEST = 0或1
   • AS：根据是否多会话选择。单会话用FINALIZE (2h)。
2. 设置长度寄存器：
   • IV大小寄存器：写入IV的实际字节数（非填充后）。如果IV是标准的12字节，就写12。
   • AAD大小寄存器：写入AAD的实际字节数。
   • ICV大小寄存器：指定期望的MAC长度（4-16字节）。如果为0或16，则使用16字节MAC。
   • 数据大小寄存器：写入所有数据（IV、AAD、消息数据）填充到16字节后的总长度。这是GCM与CCM的一个关键区别：数据大小寄存器管理的是输入FIFO的总数据流长度。
3. 加载密钥：写入AES密钥。

步骤2：IV处理与初始计数器生成硬件不会等待所有数据到位才开始。一旦启动，它就从输入FIFO读取数据。

1. 驱动首先将IV数据送入输入FIFO，并标记类型为IV。
2. 硬件读取IV。如果IV长度恰好为12字节，则直接在其后添加一个32位的计数器0x00000001构成初始计数器Y0。如果IV长度不是12字节，则硬件会使用GHASH函数对IV（填充后）进行计算，输出结果作为Y0。
3. 计算出的Y0被保存在上下文DWord 4-5中，用于后续CTR加密。同时，IV的位长度（bit length）被累计到上下文DWord 6中。

步骤3：并行处理AAD与消息数据这是GCM高效的关键。虽然标准规定GHASH是先处理AAD再处理密文，但在硬件流水线中，相关计算可以高效组织。

1. 处理AAD：驱动将AAD数据送入FIFO，类型标记为AAD。硬件使用GHASH处理AAD，更新其内部GHASH状态（保存在上下文DWord 0-1），并将AAD位长度累计到DWord 6。
2. 处理消息数据：
   • 驱动将消息数据送入FIFO，类型标记为Message Data。
   • 加密（ENC=1）：使用CTR模式（基于Y0）生成密钥流，与明文异或产生密文输出。同时，将产生的密文送入GHASH计算。
   • 解密（ENC=0）：同样使用CTR模式生成密钥流，与密文异或得到明文输出。同时，将接收到的密文送入GHASH计算。注意，无论加密还是解密，GHASH认证的对象都是密文。
   • 消息数据的位长度被累计到上下文DWord 7。
3. GHASH最终化：当所有数据（IV、AAD、消息）都处理完毕后，硬件将AAD和消息的位长度信息组合成一个128位块，进行最后一次GHASH乘加运算，最终生成128位的MAC。
4. 输出MAC/ICV：如果ICV_TEST=0，计算出的MAC会被输出（通常到输出FIFO或指定内存），并同时写回上下文DWord 0-1。如果ICV_TEST=1，则硬件会等待从输入FIFO（类型为ICV）读取接收到的ICV，并进行比对。

4.2 GCM多会话的复杂性：AS字段的独特含义

GCM的多会话处理比CCM更复杂，主要体现在AS字段的语义上。在GCM中，AS=INITIALIZE (1h)并不代表开始一个新消息，而是代表“需要执行GHASH的最终步骤”。

一个典型的多会话GCM加密例子： 假设一个长消息，其AAD也被分片。

• 会话1 (AS = UPDATE)：处理第一部分IV数据。
• 会话2 (AS = INITIALIZE)：处理最后一部分IV数据。因为IV数据结束了，需要完成对IV的GHASH计算以产生Y0，所以AS设为INITIALIZE。此时，上下文DWord 6-7必须提供IV的总位长度。
• 会话3 (AS = UPDATE)：处理第一部分AAD数据。
• 会话4 (AS = UPDATE)：处理第一部分消息数据。
• 会话5 (AS = INITIALIZE/FINALIZE)：处理最后一部分消息数据。因为所有数据结束，需要完成对整个消息（AAD+密文）的GHASH最终计算并生成MAC，所以AS设为INITIALIZE/FINALIZE。

核心规则：每当一部分数据（IV、AAD或消息数据）在某个会话中结束时，如果这不是整个消息的结束，就需要设置AS=INITIALIZE来触发一次GHASH的最终步骤。这要求软件驱动必须精确跟踪每种数据类型已处理的和剩余的长度，并在上下文中提供正确的总长度信息。这是GCM硬件驱动中最容易出错的部分之一。

5. 优化模式：为协议而生的硬件特化

CBC-XCBC、CTR-XCBC、CBC-CMAC、CTR-CMAC、CTR-CMAC-LTE这些模式，并非标准的AES模式，而是NXP AESA为了高效支持特定网络协议（如IPsec ESP、LTE PDCP）而设计的“硬件优化模式”。它们的核心思想是：在同一个硬件流水线中，并行或紧耦合地执行两种密码学操作（通常是CBC/CTR加密和XCBC-MAC/CMAC认证），最大化硬件利用率和吞吐量，减少数据搬运和上下文切换开销。

5.1 优化模式的工作原理与数据格式

以CTR-XCBC为例，它常用于IPsec ESP协议。其数据格式是硬编码的：

1. 一个16字节的认证头：这部分数据只进行XCBC-MAC认证，不加密。
2. N个16字节的CTR加密块：这部分数据先进行CTR模式加密，然后对加密后的密文进行XCBC-MAC认证。
3. 一个可选的4字节尾部：可能包含序列号等，也只进行认证。

硬件在内部设计了两条紧密耦合的数据通路：一条CTR加密流水线，一条XCBC-MAC认证流水线。数据块流经硬件时，几乎同时经历两种处理。CBC-XCBC、CTR-CMAC等模式同理，只是将认证算法换成了CMAC。

CTR-CMAC-LTE则是为LTE控制面（PDCP）量身定制的。它的数据格式固定为：9字节仅认证头 + 后续的认证加密数据。硬件知道这个固定格式，因此可以做出更极致的优化，比如将9字节头特殊处理。

5.2 优化模式的密钥派生与上下文管理

优化模式的一个关键步骤是密钥派生。XCBC-MAC和CMAC算法在开始处理实际数据前，需要根据原始密钥预先计算出一个或多个派生密钥（K1, K2, K3 或 L）。

• 初始化会话（AS = INITIALIZE）：在这个首次会话中，硬件的主要任务不是处理用户数据，而是进行密钥派生计算。例如，在CTR-XCBC模式下，硬件会计算K1, K2, K3。计算出的K1会直接替换Class 2密钥寄存器中的原始MAC密钥，而K2和K3则被写入上下文寄存器（DWord 4-7）保存，供后续会话使用。
• 中间与最终会话：在UPDATE和FINALIZE会话中，驱动需要从保存的上下文中恢复这些派生密钥（对于XCBC是K2/K3，对于CMAC是L）到硬件上下文寄存器，并将派生密钥K1（对于XCBC）或原始密钥（对于CMAC，硬件内部会实时计算K1/K2）加载到密钥寄存器。硬件利用这些预先计算好的密钥，高速处理数据。

这种“一次派生，多次使用”的机制，避免了在每个数据块上重复进行密钥扩展操作，极大地提升了性能。

5.3 优化模式的多会话处理表格解读

手册中的表11-110是优化模式多会话处理的“食谱”，极其重要但也很容易让人困惑。我们来解读其中几行：

• 会话1.1 (初始化)：AS=1,ICV=0,AAD size=0,Data size=0。这个会话不处理任何用户数据，只执行密钥派生（计算L或K2/K3），并将结果存入上下文。
• 会话1.2 (仅处理头)：例如CTR-CMAC-LTE，AS=1或0,AAD size=9,Data size=16。这里Data size=16是因为9字节的头在FIFO中需要按16字节对齐提交。此会话处理仅认证的头。
• 会话2.1 (仅处理消息)：AS=0,AAD size=0,Data size = 16 * N。这是最常见的中间会话，处理纯消息数据块（认证并加密）。
• 会话2.2 (最终消息)：AS=2,ICV=1或0,AAD size=0,Data size > 0。处理最后一部分消息数据，并计算最终MAC。如果ICV=1，则还会进行比对。
• 会话5 (纯ICV检查)：AS=0,ICV=1,AAD size=0,Data size=0。这是一个特殊的“空”会话，用于在之前所有数据都已处理、MAC已计算并保存在上下文后，单独进行ICV比对。这在某些协议流程中很有用。

驱动开发者的任务就是根据协议数据包的实际结构，选择合适的会话序列进行组合，并正确设置每个会话的寄存器参数。这需要对协议格式和硬件行为都有深刻理解。

6. 常见问题、调试技巧与实战心得

在基于此类硬件加速器开发驱动或调试应用时，你会遇到一些典型问题。以下是我从实际项目中总结的经验。

6.1 典型错误与排查清单

6.2 调试与性能优化心得

1. 从单会话开始：在实现复杂的多会话驱动前，务必先让单会话（AS = INITIALIZE/FINALIZE或FINALIZE）模式工作正常。使用标准的测试向量（如NIST或RFC 3610/3686/4493等提供的向量）进行验证。这是建立信心的基础。
2. 善用“纯ICV检查”会话：在调试认证问题时，可以先让硬件完成所有数据处理和MAC计算（ICV_TEST=0），然后读取上下文中的计算出的MAC。接着，再发起一个AS=UPDATE,Data size=0,ICV_TEST=1的会话，并提交待验证的ICV。这可以将“计算”和“比较”分离，便于定位是计算错误还是比较错误。
3. 上下文寄存器的“快照”调试法：在复杂多会话流程中，在每次硬件操作（INITIALIZE,UPDATE,FINALIZE）前后，都读取并保存完整的上下文寄存器内容到日志中。对比这些快照，可以清晰地看到计数器、中间MAC状态、派生密钥等是如何变化的，能快速定位状态机在哪一步出现了偏差。
4. 理解数据对齐与填充：硬件加速器几乎总是以16字节块为单位工作。驱动必须负责对非16字节倍数的数据进行填充（PKCS#7等）。对于GCM的AAD和消息，虽然GHASH内部处理填充，但提交到Data Size Register的长度必须是填充后的长度。一个易错点：GCM的IV Size和AAD Size寄存器写入的是实际长度，而Data Size寄存器写入的是填充后的长度。
5. 性能考量：对于小数据包（如小于256字节），硬件加速的启动开销（描述符准备、DMA设置、上下文切换）可能抵消其计算优势。对于流式大数据，尽量使用多会话和DMA描述符链，让硬件连续工作。确保密钥、上下文等数据位于Cache一致的内存区域，避免不必要的缓存维护操作。

硬件加速器是性能利器，但也是一头需要精细驾驭的猛兽。对寄存器每一位的含义、对数据流每一字节的路径、对状态机每一次切换的时机都了如指掌，才能写出稳定、高效、可靠的底层代码。这份手册片段提供的正是驾驭这头猛兽最详细的“操作手册”，希望本文的解读能帮你把手册上的冰冷文字，变成脑海中生动的运行图景。