NXP SEC引擎校验和与密钥加载机制详解：嵌入式安全硬件加速实战

1. 项目概述：硬件安全引擎中的校验和与密钥管理

在嵌入式系统，尤其是网络设备、网关和物联网安全模块的开发中，数据完整性和机密性是两大基石。前者确保数据在传输或存储过程中未被意外篡改或恶意破坏，后者则保护数据内容不被未授权方窥探。为了实现高性能的实时处理，现代SoC（片上系统）通常会集成专用的硬件安全引擎（Security Engine, SEC），将复杂的密码学运算和协议处理卸载到硬件，从而释放CPU资源，提升系统整体吞吐量和能效。

NXP的SEC引擎便是这类硬件的典型代表。它不仅仅是一个简单的加解密协处理器，而是一个集成了多个密码学硬件加速器（Cryptographic Hardware Accelerator, CHA）、描述符解析单元（Descriptor Controller, DECO）和复杂数据流管理逻辑的子系统。开发者通过编写“描述符”（Descriptor）——一种特殊的数据结构或微程序——来指挥SEC引擎完成一系列操作，例如从内存加载数据、进行AES加密、计算SHA-256哈希，最后将结果存回内存。这种方式将软件从繁重的逐字节处理中解放出来，只需配置好任务描述符并提交，硬件便会自动完成后续所有步骤。

本次我们深入探讨SEC引擎中两个看似基础但至关重要的机制：校验和计算与密钥加载。校验和是网络协议（如IP、UDP、TCP）和数据完整性验证的通用手段；而密钥的安全加载与管理则是所有密码学操作的前提。理解SEC如何通过其精妙的描述符命令体系来高效、安全地实现这两大功能，对于设计高性能、高可靠的嵌入式安全应用至关重要。无论你是在调试一个IPsec VPN网关的吞吐量瓶颈，还是在为一个物联网设备设计安全启动流程，这些底层细节都将直接影响系统的性能、安全性和稳定性。

2. 校验和计算逻辑的深度解析

校验和（Checksum）是一种简单高效的数据完整性校验方法。其核心思想是对一段数据（通常被视为16位字的序列）进行累加，并将累加结果的补码作为校验值。接收方对数据（含校验和）进行同样的计算，若结果为零，则认为数据在传输过程中没有出错。SEC引擎内置的校验和逻辑专门为优化网络协议处理而设计，特别是IPsec ESP（封装安全载荷）隧道模式下的UDP封装（UDP-encapsulated-ESP），这是一种用于穿越NAT（网络地址转换）设备的常见技术。

2.1 校验和的计算规则与硬件实现

SEC引擎实现的校验和算法是16位反码求和（16-bit one‘s complement sum），这与RFC 793（TCP）和RFC 768（UDP）中定义的算法完全兼容。算法描述为：将所有需要校验的数据（包括头部和载荷），以16位（2字节）为单位进行分割，将这些16位字进行反码求和（即普通的二进制加法，但最高位的进位要循环加回到最低位），最后对求和结果取反码，即得到16位的校验和。

在硬件层面，SEC通过一个专用的校验和计算寄存器来实时维护这个累加和。其计算行为有几个关键特性需要明确：

1. 字节序与填充处理：数据流被视为连续的字节流。如果数据总字节数为奇数，则在计算校验和的最后，硬件会自动在最后一个字节的右侧填充一个值为0的字节，以构成一个完整的16位字进行计算。这意味着开发者无需在软件层面进行填充操作。
2. 分段存储的连续性：数据可能通过多个SEQ STORE或SEQ FIFO STORE命令分段写入输出缓冲区。校验和逻辑会将这些分段的数据在逻辑上拼接起来，再进行连续计算。即使两段启用校验和计算的数据之间，夹杂了一段禁用校验和计算的数据，计算逻辑也会忽略中间段，仿佛它们不存在，直接衔接前后两段有效数据进行计算。这种设计为复杂协议处理提供了极大的灵活性。
3. 计算范围：一个重要的细节是，校验和计算的是实际被硬件写入内存的字节数。在某些协议操作（如IPsec ESP传输模式解封装）中，硬件可能会先解密出包含填充（Padding）和填充长度（Pad Length）的完整数据块，写入内存，随后再根据Pad Length的值调整输出帧描述符中的长度字段，以“隐藏”填充字节。此时，校验和计算仍然包含了所有被写入的字节（包括后续被“隐藏”的填充），确保了完整性验证与解密过程的一致性。

2.2 校验和的启用、禁用与输出控制

校验和计算并非默认对所有输出数据生效。SEC提供了精细的控制命令，主要通过SEQ FIFO STORE命令的“输出数据类型”字段来操控。

• 输出数据类型 30h：禁用校验和计算。此后通过SEQ FIFO STORE写入的数据将不参与校验和累加。
• 输出数据类型 31h：启用校验和计算。这是一个关键动作：当第一次发出启用命令时，硬件会清零校验和计算寄存器的当前值。这意味着你可以通过先启用、再写入数据的方式，开始一个全新的校验和计算序列。即使启用命令的数据长度为零，它也能起到“清零并开启计算”的作用。
• SEQ STORE命令：该命令没有专门的启用/禁用位，它写入的数据默认被包含在校验和计算中。因此，通常的流程是：使用SEQ FIFO STORE（类型31h）启用并开始计算，然后混合使用SEQ STORE和SEQ FIFO STORE进行数据写入，最后可能再用SEQ FIFO STORE（类型30h）禁用计算。

校验和的结果需要被获取并放置到正确的位置。SEC提供了两种主要方式：

1. 写入校验和寄存器：可以通过STORE或SEQ STORE命令，直接将当前校验和计算寄存器（DCHKSM）的值写入内存的任意位置。这允许你将校验和作为数据的一部分进行存储。
2. 自动填充到帧描述符：在作业（Job）完成时，SEC可以自动将最终的校验和结果填写到输出帧的特定字段中。
   • 对于返回给AIOP（高级IO处理器）的作业，校验和放在响应帧描述符的FLC字段。
   • 对于返回给QMan（队列管理器）的作业，如果流上下文（flow context）中的EAO位被置1，校验和会被放在输出帧ASA（附加状态区域）的FLC字段中。这在处理网络数据包时非常方便，硬件可以自动完成协议要求的校验和填充。

注意：协议覆盖场景。在IPsec ESP隧道模式下处理UDP封装时，协议逻辑会覆盖上述常规的校验和控制。为了正确计算UDP头的校验和，SEC的内部逻辑会根据NAT和NUC标志位自动管理校验和计算的启用和禁用。此时，开发者配置的SEQ FIFO STORE命令中的启用/禁用位可能被忽略。对于其他协议（如IPsec ESP传输模式），则完全依赖描述符命令进行控制。

3. 密钥加载命令的机制与安全考量

密钥是密码学运算的种子，其加载过程的安全性和效率直接关系到整个系统的安全边界。SEC引擎的KEY命令（及其序列化版本SEQ KEY）是密钥材料进入硬件安全边界的主要通道。理解其工作模式、安全属性和限制条件，是编写正确、安全描述符的前提。

3.1 密钥的类型与目的地

SEC引擎区分两种密钥状态和多个加载目的地：

1. 红密钥与黑密钥：

   • 红密钥：明文密钥。在内存或描述符中以明文形式存在，通过KEY命令加载时，ENC位为0。
   • 黑密钥：加密密钥。密钥在离开安全存储（如HSM、安全元件）时已被加密，在系统内存中以密文形式存在。通过KEY命令加载时��ENC位为1，SEC引擎会在加载过程中自动解密。这是保护静态密钥（Key at Rest）安全的关键机制。

2. 密钥目的地：

   • Class 1 密钥寄存器：用于AES、DES、3DES、Kasumi、ZUC等对称加密算法以及公钥运算和随机数生成。
   • Class 2 密钥寄存器：用于SHA系列、MD5、CRC等哈希算法以及ZUC的完整性算法。
   • PKHA E-Memory：专用于公钥算法（如RSA、ECC）的大数存储区域。
   • MDHA Split Key：这是一个特殊目的。当KDEST字段为11b时，密钥被视为HMAC算法所需的“分割密钥”，即IPAD和OPAD值的拼接体，它将被加载到Class 2密钥寄存器。使用分割密钥可以避免HMAC运算中重复的异或和哈希初始化步骤，显著提升性能。

3.2 KEY命令字段详解与实战配置

KEY命令的格式包含多个控制字段，每个字段的配置都需谨慎。

• CLASS：指定算法类别（01b为Class 1，10b为Class 2）。这决定了密钥被送往哪个硬件加速器簇。一个关键的死锁规避规则是：如果一个描述符需要同时使用Class 1和Class 2的CHA，必须先请求Class 2，再请求Class 1。在多DECO的SEC版本中，违反此顺序可能导致两个描述符互相等待对方释放资源而形成死锁。即使你的硬件只有一个DECO，遵循此规则也能保证软件的可移植性。
• ENC与EKT：ENC指示是否为黑密钥。EKT指示黑密钥的加密模式：0为AES-ECB，1为AES-CCM。必须匹配密钥最初的加密方式，否则解密不会报错但会得到错误密钥，导致后续所有加解密操作失败且难以排查。
• KDEST：如前所述，选择密钥目的地。需注意，加载到PKHA E-Memory的密钥必须是Class 1密钥。
• TK：仅用于可信描述符。当ENC=1且TK=1时，使用可信描述符密钥加密密钥进行解密，否则使用作业描述符密钥加密密钥。
• PTS与NWB：这两个位共同控制密钥的“可导出性”。
  • NWB：无回写。若置1，则禁止通过FIFO STORE命令将此密钥以任何形式（包括黑密钥形式）写回内存。这提供了更强的密钥保护。
  • PTS：明文存储。这是一个更宽松的控制。若置1，且密钥是红密钥（ENC=0），则允许后续通过FIFO STORE命令将该密钥以明文形式存储出去。存在严格的限制：PTS不能与ENC=1或NWB=1同时设置；对于Class 2寄存器，仅当加载的是分割密钥或后续运行MDHA INIT模式生成分割密钥后，才允许明文存储。

3.3 加载黑密钥的副作用与命令顺序

加载一个黑密钥（ENC=1）是SEC引擎中一个重量级操作，因为它触发了内部的AES解密电路。这个操作会产生显著的副作用：它会清空输入/输出数据FIFO、Class 1密钥寄存器、Class 1数据大小寄存器、Class 1模式寄存器以及Class 1上下文（如果EKT也置位）。

这意味着，在描述符中安排KEY命令加载黑密钥时，必须非常小心前置命令。安全的做法是，在加载黑密钥之前，只允许执行以下几类不冲突的命令：

• JUMP
• SEQ IN PTR/SEQ OUT PTR
• 向上述被清除寄存器之外的寄存器进行LOAD或MOVE操作。

一个重要的实践顺序是：先加载Class 2的黑密钥（如果需要），再加载Class 1的黑密钥。因为加载Class 1黑密钥的副作用会清除Class 1相关资源，如果先加载Class 1密钥，后加载的Class 2密钥操作可能会受到影响。

实操心得：阻塞与性能。KEY命令在多种情况下是“阻塞”的，例如解密黑密钥、加载非立即数的红密钥、等待CHA空闲、等待输入FIFO数据等。在编写高性能描述符时，应尽量避免在关键路径上执行可能阻塞的KEY命令。例如，可以提前在作业提交前或上一个作业的尾部预加载密钥，或者使用立即数方式嵌入使用频率高、生命周期短的会话密钥。

4. 描述符命令体系与HEADER命令解析

描述符是SEC引擎的“机器语言程序”。一个作业描述符（Job Descriptor）定义了从输入数据获取、密码学处理到输出数据存储的完整流程。共享描述符（Shared Descriptor）则封装了可重用的操作序列，可以被多个作业描述符引用，提高代码复用率和缓存效率。

4.1 HEADER命令：描述符的起点

每个描述符都必须以HEADER命令开始。它定义了描述符的基本属性和执行上下文。

作业描述符HEADER关键字段：

• DNR：不运行位。若上游处理出现问题，可置位此位，使描述符流经硬件流水线但不执行，便于软件在后期修复问题后重新提交。
• SHR：共享描述符标志。置1表示本作业描述符关联一个共享描述符，其指针紧跟在HEADER命令之后。
• START INDEX：当SHR=0时，此字段指定描述符缓冲区中开始执行的单词索引（跳过HEADER本身）。这允许在描述符开头存放元数据。
• SHARE：共享状态。定义了该共享描述符如何在不同作业间共享（如“不共享”、“串行共享”、“并行共享”）。这对于多核/多DECO环境下的资源同步至关重要。
• DESCLEN：描述符总长度（以4字节字为单位）。最大为64字。
• EXT：扩展头标志。置1时，HEADER后跟一个扩展头字，其中包含FTD（伪可信描述符）和DECO_SELECT（指定运行DECO）等高级字段。特别注意：如果SHR=0且START INDEX=1（即跳过HEADER后直接开始），此时若EXT=1会导致HEADER错误，因为扩展头字无处安放。

共享描述符HEADER关键字段：

• RIF：尽早读取输入帧。置1时，DECO会尽快根据作业描述符中的SEQ IN PTR读取整个输入帧到输入FIFO，以降低处理延迟。但存在诸多使用禁忌，例如描述符中包含非立即数的LOAD/KEY命令、包含加密密钥加载、或包含特定协议操作（如SSL/TLS解封装、带外部IP头引用的IPsec ESP隧道封装等）时不能使用。
• CIF：清空输入FIFO。在自共享（同一DECO内连续执行相同共享描述符）时，若置位，则在作业间重置输入FIFO和NFIFO条目。
• SC：保存上下文。在串行共享且自共享时，若置位，则当前描述符完成后，其上下文寄存器（如哈希中间状态）会被保留，供下一个共享此描述符的作业使用。这对于将一个大的加密或哈希操作拆分成多个作业连续处理至关重要。
• PD：传播DNR。若作业描述符的DNR位置位且本位置位，则同时置位共享描述符HEADER中的DNR位。这可以“冻结”一个有问题的共享描述符，防止其被后续作业使用。

4.2 地址指针与字节序处理

SEC支持32位和49位地址指针，由主配置寄存器中的PS位决定。49位指针的格式较为特殊：低32位存放在一个双字中，高17位存放在下一个双字的[16:0]位，[31:17]位保留。

在小端模式下处理多字地址时需要特别注意：在内存中，低有效位字在前。如果描述符中需要对此类地址进行数学运算（如地址递增），可以使用MOVEW命令将其移动到数学寄存器，此时数据会被组装成一个完整的8字节整数以供操作，操作完毕后再用MOVEW移回。

5. 实战案例：构建一个支持校验和的IPsec ESP解密描述符

假设我们需要为接收到的UDP封装的IPsec ESP隧道数据包编写一个解密描述符。该描述符需要：1）验证并剥离UDP头；2）解密ESP载荷；3）计算解密后数据的校验和（用于上层协议验证）；4）将解密后的数据和校验和输出。

5.1 描述符结构设计

1. 作业描述符HEADER：设置SHR=1，指向共享描述符。SHARE根据并发需求设置（例如001b表示串行共享）。
2. 共享描述符指针：指向共享描述符的内存地址。
3. 共享描述符HEADER：由于涉及协议解密，根据手册，不能设置RIF位。SC位可能置1，以便处理分片的大数据包。
4. 协议命令：使用PROTOCOL OPERATION命令，选择IPsec ESP Tunnel Decapsulation协议。在协议参数块中，需要配置：
   • 加密算法（如AES-CBC）、认证算法（如HMAC-SHA256）。
   • 设置NAT和NUC标志，以指示存在UDP封装。此时，校验和逻辑将由协议硬件自动管理，用于计算和验证UDP头的校验和。
   • 指向外部IP头、ESP头、加密数据等的指针。
5. 输出配置：协议引擎解密后，数据会被输出。我们需要使用SEQ OUT PTR命令设置输出缓冲区。
6. 启用校验和计算：在协议命令之后、实际数据输出之前，插入一个SEQ FIFO STORE命令，设置输出数据类型为31h（启用校验和），长度可以为0，目的仅是“开启”对后续解密载荷的校验和计算。
7. 数据输出：协议引擎会自动将解密后的数据通过输出FIFO写出。我们可以用SEQ FIFO STORE命令（或SEQ STORE）将这些数据存储到输出缓冲区。由于步骤6已启用校验和，这些数据会被自动累加。
8. 获取并存储校验和：在数据输出完毕后，有两种方式处理校验和：
   • 方式A（自动）：依赖SEC在作业完成时，将校验和自动填入输出帧描述符的指定字段（需配置流上下文）。这对于标准网络包处理最方便。
   • 方式B（手动）：在描述符末尾，使用SEQ STORE命令，将DCHKSM寄存器的值存储到输出缓冲区的特定偏移位置。这提供了更灵活的控制。
9. 禁用校验和：如果后续还有操作，可插入SEQ FIFO STORE（类型30h）禁用计算。

5.2 密钥加载步骤

在这个描述符中，我们需要加载ESP SA（安全关联）所需的加密密钥和认证密钥。

1. 加载认证密钥：首先使用KEY命令，CLASS=10b（Class 2），KDEST=00b（Class 2 Key Register），加载HMAC-SHA256所需的密钥。如果密钥是黑密钥，则ENC=1，并正确设置EKT。
2. 加载加密密钥：然后使用KEY命令，CLASS=01b（Class 1），KDEST=00b（Class 1 Key Register），加载AES-CBC密钥。同样，如果是黑密钥则设置ENC=1。
3. 注意顺序：遵循“先Class 2，后Class 1”的原则，避免潜在的资源冲突和死锁风险。如果都是黑密钥，此顺序也符合加载黑密钥的副作用要求。

6. 常见问题与调试技巧实录

在实际开发和调试SEC描述符时，经常会遇到一些棘手问题。以下是一些典型场景和排查思路：

问题1：作业提交后，SEC返回“Header Error”或“Descriptor Error”。

• 排查思路：
  1. 检查HEADER命令：确认ONE和ZRO位是否正确设置（23位为1，15位为0），这是字节序验证位。确认DESCLEN是否准确描述了整个描述符的长度（包括所有命令字）。
  2. 检查扩展头：如果EXT=1，确保后面跟了扩展头字。同时检查SHR和START INDEX的组合，避免SHR=0,START INDEX=1,EXT=1的错误组合。
  3. 检查命令字对齐：所有命令字必须是32位对齐的。指针长度（32位或64位/98位）需与系统配置一致。
  4. 使用仿真器或调试器：如果可用，在SEC仿真模型上单步执行描述符，查看在哪个命令字处报错。

问题2：解密或认证结果不正确，但密钥确认无误。

• 排查思路：
  1. 检查黑密钥解密模式：确认EKT位设置是否正确，必须与密钥加密时使用的模式（AES-ECB或AES-CCM）完全匹配。
  2. 检查密钥加载顺序：确认是否遵循了先Class 2后Class 1的顺序。在多DECO系统中，违反此顺序可能不报错但导致性能下降或死锁。
  3. 检查协议参数块：确认PDB中的算法、模式、IV、长度等字段与SA协商的参数完全一致。一个字节的偏差都会导致结果全错。
  4. 检查输入/输出指针和长度：确认SEQ IN PTR和SEQ OUT PTR指向了正确的数据区域，且长度字段包含了所有必要的头部和填充。

问题3：启用校验和计算后，输出的校验和值与软件计算值不符。

• 排查思路：
  1. 确认计算范围：检查SEQ FIFO STORE命令的启用（31h）/禁用（30h）设置是否正确。确认是否有意料之外的数据（如协议自动添加的尾部）被包含进了计算。回忆“计算范围”特性，硬件计算的是实际写入的字节。
  2. 检查协议覆盖：如果是在IPsec ESP隧道（UDP封装）场景，校验和可能被协议逻辑覆盖。此时应关注协议参数中NAT/NUC的设置，而非描述符中的SEQ FIFO STORE命令。
  3. 校验和寄存器访问时机：如果通过STORE DCHKSM手动获取校验和，确保该命令在所有需要计算的数据都通过STORE命令写入之后执行。在数据写入过程中读取寄存器，得到的是中间结果。

问题4：性能未达到预期，SEC引擎利用率低。

• 排查思路：
  1. 减少阻塞操作：审视描述符，将可能阻塞的KEY命令（尤其是加载黑密钥）移至描述符开头或前一个作业的末尾。考虑使用立即数红密钥用于频繁变化的会话密钥。
  2. 利用共享描述符：将通用的、不变的操作序列（如固定的密钥加载、协议初始化）放入共享描述符。多个作业描述符引用它，可以减少描述符解析开销和提高DECO内部缓存命中率。
  3. 优化数据流：如果条件允许，尝试设置共享描述符HEADER中的RIF位，让DECO提前读取输入数据。但务必确认你的操作不违反其使用禁忌列表。
  4. 平衡DECO负载：在多DECO系统中，避免所有繁重作业都集中在同一个DECO。虽然可以用DECO_SELECT指定，但需注意可能引入的死锁风险，建议谨慎使用或确保流内所有作业指定同一DECO。

掌握SEC引擎的校验和与密钥加载机制，是深入利用其硬件加速能力的关键。从精准控制数据完整性的计算流程，到安全高效地管理密钥生命周期，每一个细节都影响着最终应用的性能和安全性。希望这篇结合手册原理与实战经验的解析，能帮助你在下一次面对嵌入式安全性能挑战时，更加游刃有余。