深入解析NXP SEC引擎：校验和、算法分类与密钥加载实战

1. 项目概述：深入SEC安全引擎的校验和与密钥管理

在嵌入式系统，尤其是网络通信与安全设备的设计中，数据完整性与机密性是两条必须守住的底线。无论是设备间传输的指令，还是需要加密存储的敏感信息，任何一位数据的错误或泄露都可能导致系统功能异常乃至安全防线崩溃。为此，现代高性能处理器，如NXP的LS系列，通常会集成一个专门的安全引擎（Security Engine, SEC），将繁重的加解密、哈希、校验和计算等任务从CPU卸载，由硬件加速执行。

今天，我们就来深入聊聊NXP SEC引擎里几个既基础又关键的技术点：校验和（Checksum）计算逻辑、密码算法的硬件分类（Class 1/Class 2），以及安全操作的基石——KEY密钥加载命令。这些内容绝非纸上谈兵，它们直接关系到你写的驱动代码能否正确、高效、安全地驱动硬件。我曾在一个网关项目上，因为对Black Key加载的副作用理解不清，导致加密上下文被意外清除，调试了整整两天。希望通过这次分享，能帮你避开这些“坑”。

简单来说，你可以把SEC引擎想象成一个高度专业化、流水线化的“安全车间”。校验和是车间的“质检员”，确保数据在搬运（存储）过程中没有损坏；密码算法分类是车间的“工种划分”（比如AES组和SHA组），让不同的硬件加速器（CHA）各司其职，避免资源争用；而KEY命令则是车间的“保险库钥匙管理”，负责将密钥（无论是明文的Red Key还是加密的Black Key）安全地送入对应的密钥寄存器，供后续加解密操作使用。理解这三者，是玩转SEC引擎、构建可靠嵌入式安全应用的必修课。

2. 校验和计算逻辑的深度解析与实战应用

校验和，本质上是一种用于检测数据在传输或存储过程中是否发生错误的技术。SEC引擎实现的是一种与UDP、TCP协议兼容的**16位反码求和（One‘s Complement Sum）**校验和。它的核心思想很简单：将数据视为一系列16位的字（word），将它们全部相加，再将累加过程中产生的任何进位（carry）回加到结果的最低有效位，最后对结果取反码。这个最终值就是校验和。接收方可以用同样的算法计算接收到的数据，若结果与传输来的校验和匹配（或按协议规定，所有16位字，包括校验和本身，求和结果为全1），则认为数据正确。

2.1 SEC中校验和的触发与控制

在SEC引擎中，校验和计算并非默认对所有输出数据生效，而是需要通过特定的描述符命令来精确控制。核心命令是SEQ STORE和SEQ FIFO STORE，它们负责将处理后的数据从SEC内部写回到系统内存。

注意：SEQ FIFO STORE命令拥有更精细的控制能力，它通过输出数据类型（Output Data Type）字段来开关校验和逻辑。具体来说，输出数据类型31h用于启用（Enable）校验和计算，而30h用于禁用（Disable）。这是一个非常实用的特性。

这里有一个关键细节：当你第一次发送一个启用校验和的SEQ FIFO STORE命令（即使数据长度为零）时，SEC内部的校验和寄存器（DECO checksum register）会被自动清零。这意味着你可以精确地控制校验和计算的起始边界。例如，在一个数据包中，你可能只想对载荷（Payload）部分计算校验和，而跳过包头。你可以先发送一个禁用校验和的命令写出包头，再发送一个启用校验和的命令（或带启用类型的零长度命令）来“开启”计算，接着写出载荷数据。

2.2 多段数据与边界处理

在实际应用中，一个完整的数据包可能通过多个STORE命令分段写出。SEC的校验和逻辑会智能地将所有被标记为“启用校验和”的数据段**虚拟地拼接（concatenate）**起来，作为一个连续的数据流进行计算。

这引出了一个重要的边界情况：奇数长度数据。RFC 793（TCP规范）明确指出，如果待校验的数据字节数为奇数，则在最后一个字节的右侧填充一个值为零的字节，以构成一个完整的16位字进行计算。SEC硬件严格遵循了这一标准。也就是说，即使你通过多个命令输出数据，只要整个启用校验和的数据流总长度为奇数，SEC在计算时会自动为你补上一个零字节。这对于实现标准的网络协议校验和至关重要，你无需在软件层面进行填充。

另一个需要留意的场景是，某些协议（如IPsec ESP传输模式解封装）在解密完成前，可能无法确定最终有效数据的精确长度。协议处理器可能会先写出包含填充字节的完整数据块，然后再调整输出帧长度以“隐藏”这些填充。SEC的校验和逻辑是“诚实”的——它计算的是实际被写入内存的所有字节的校验和，而非最终调整后帧长度的字节。这一点在调试协议相关问题时需要特别注意，校验和值可能与仅基于“有效数据”的软件计算结果不同。

2.3 校验和的获取与IPsec ESP的特殊应用

计算完成的校验和值存放于何处？这取决于作业的返回路径：

• 返回至AIOP：校验和存放在响应帧描述符的FLC字段中。
• 返回至Qman：如果流程上下文中的EAO位被设置为1，则校验和存放在输出帧ASA段的FLC字段中。

校验和功能的一个高级应用场景是支持UDP封装的IPsec ESP隧道模式。在这种模式下，外层的UDP头需要包含校验和。SEC的IPsec ESP隧道协议硬件可以覆盖（override）常规的校验和控制逻辑，自动为UDP封装生成正确的校验和。当协议控制块（PDB）中的NAT和NUC标志同时置位时，协议硬件会根据需要自动启用和禁用校验和计算，以确保UDP校验和的正确生成。对于其他协议（包括传统的IPsec ESP隧道和传输模式），则不会干预校验和逻辑的开关，由描述符完全控制。

实操心得：在调试涉及校验和的网络数据包处理时，务必使用抓包工具（如Wireshark）捕获SEC硬件处理前后的数据包，并验证其校验和字段。对于UDP封装ESP这类复杂协议，优先查阅SEC参考手册中对应的协议章节，确认硬件是否以及如何自动处理校验和，避免软件重复计算或计算错误。

3. 密码算法分类（Class 1/Class 2）与硬件资源调度

SEC引擎内部并非只有一个万能的计算单元，而是包含了多个专门的密码硬件加速器（Cryptographic Hardware Accelerator, CHA），例如专门处理AES的CHA、专门处理SHA的CHA等。为了高效管理和调度这些硬件资源，SEC将不同的密码学算法划分为了两个“类别”（Class）：Class 1和Class 2。

3.1 算法分类详解

这个分类主要是基于算法实现的硬件电路特性来划分的。理解这个分类是正确编写描述符的关键，因为很多与密钥和数据移动相关的命令（如LOAD,STORE,KEY）都需要指定一个CLASS值，以确保指令被发送到正确的CHA队列。

下表清晰地展示了常见算法的分类：

一个重要特例：一些优化的复合操作模式（例如同时进行加密和认证的AES-GCM）需要同时使用Class 1和Class 2的资源。对于这种模式，认证密钥必须放在Class 2密钥寄存器中，而加密/解密密钥必须放在Class 1密钥寄存器中。描述符中需要包含对两类CHA的请求。

3.2 死锁规避与命令顺序强制规则

当单个描述符需要同时使用Class 1和Class 2的CHA时，SEC硬件强制规定了一个重要的顺序：必须先请求（acquire）Class 2 CHA，然后再请求Class 1 CHA。

这条规则是为了防止在多DECO（描述符控制器）的SEC版本中出现死锁。想象一下有两个描述符（X和Y）在两个DECO上同时执行：

1. 描述符X锁定了Class 1 CHA，然后尝试请求Class 2 CHA。
2. 描述符Y锁定了Class 2 CHA，然后尝试请求Class 1 CHA。
3. 此时，两个描述符都在等待对方释放资源，但谁都不会先释放自己已持有的资源，从而形成死锁。

通过强制规定所有描述符都按照Class 2 -> Class 1的相同顺序请求资源，就彻底杜绝了这种循环等待的可能性。SEC硬件会进行检查，如果检测到描述符在已获得Class 1 CHA后再去请求Class 2 CHA，将会产生错误。

关键提醒：即使你当前开发的芯片是单DECO的SEC版本，软件也必须遵守此规则。这是保证代码可移植到未来多DECO SEC版本的最佳实践。在编写描述符时，务必检查所有涉及双Class操作的命令序列。

3.3 CLASS字段的编码含义

在描述符命令中，CLASS字段通常是一个2位的编码，其含义根据命令类型略有不同：

这里的“CCB”指的是命令控制块（Command Control Block），是SEC内部的一种数据结构。对于大多数应用层开发者而言，我们更关注的是后三种情况，即明确指定算法类别。

踩坑记录：在一次实现AES-GCM的驱动中，我按照算法逻辑先配置了加密（Class 1），后配置认证（Class 2），结果作业一直报错。排查了很久才发现是描述符中请求CHA的顺序违反了“Class 2先于Class 1”的规则。调整顺序后问题立即解决。这个坑非常隐蔽，因为从算法逻辑上看先加密后认证似乎很合理，但硬件调度有其自身的约束，必须遵守。

4. KEY密钥加载命令全解：从明文到黑钥的安全加载

密钥是密码学操作的灵魂，如何安全、正确地将密钥加载到SEC的硬件寄存器中，是启动任何加密、解密、签名、验证操作的前提。SEC提供了功能强大的KEY命令（及其序列化版本SEQ KEY）来完成这项任务。

4.1 KEY命令的核心功能与格式

KEY命令的核心目的是将一段密钥数据加载到指定的目标寄存器中。这个目标可以是Class 1密钥寄存器、Class 2密钥寄存器或是PKHA E-Memory（用于公钥算法）。命令的格式非常丰富，涵盖了多种场景：

关键字段解析：

• CTYPE (命令类型)：00000b代表标准KEY命令，00001b代表SEQ KEY命令。后者是前者的序列化版本，其数据源来自输入数据序列（Input Data Sequence），而非直接的内存指针。
• CLASS：指定密钥的类别，必须与KDEST（目标）匹配。例如，加载到Class 2密钥寄存器的密钥，其CLASS必须为10b。
• SGF/VLF：
  • 在KEY命令中，这是散点/聚集表标志（SGF）。如果密钥数据在内存中是非连续的，可以设置此位，让指针指向一个描述数据块位置和大小的表。
  • 在SEQ KEY命令中，这是可变长度标志（VLF）。如果置位，则密钥长度由VSIL寄存器的值决定，而非命令字中的LENGTH字段。
• IMM/AIDF：
  • 在KEY命令中，这是立即数标志（IMM）。如果置位，密钥数据直接跟在命令字后面，作为描述符的一部分。这对于短小且固定的密钥（如调试用的测试密钥）很方便，但要注意描述符缓冲区的大小限制，特别是对于巨大的公钥。
  • 在SEQ KEY命令中，这是已在输入数据FIFO中标志（AIDF）。如果置位，表示密钥数据已经通过之前的SEQ FIFO LOAD等命令读入了输入数据FIFO，本命令直接从中取用，无需再次发起DMA读取。
• ENC (加密标志)：这是区分Red Key和Black Key的关键。如果ENC=0，密钥是明文（Red Key），直接加载。如果ENC=1，密钥是加密状态（Black Key），SEC会在加载过程中自动使用JDKEK（或可信描述符的TDKEK）对其进行解密。
• EKT (加密密钥类型)：当ENC=1时，此位指定了解密Black Key所使用的算法。0代表AES-ECB模式，1代表AES-CCM模式。必须与当初加密该黑钥时使用的模式一致，否则解密出的密钥是错误的，且可能不会报错，导致后续加密操作全部失败，这种静默错误极其危险。
• KDEST (密钥目标)：指定加载位置。00b到密钥寄存器（Class 1/2），01b到PKHA E-Memory（仅Class 1），11b作为MDHA分割密钥加载到Class 2密钥寄存器（仅Class 2）。分割密钥是HMAC优化的一种形式，将IPAD和OPAD材料拼接在一起一次性加载。

4.2 加载Black Key的副作用与命令顺序

加载一个Black Key（ENC=1）不是一个简单的数据搬运操作，它内部触发了AES解密流程。这个流程会占用和影响SEC内部的多个资源。因此，KEY命令在加载Black Key时，具有显著的副作用（Side Effects）：它会清除（Clear）输入数据FIFO、输出数据FIFO、Class 1密钥寄存器、Class 1数据大小寄存器、Class 1模式寄存器，以及Class 1上下文（如果EKT也同时被设置）。

这个副作用带来了一个至关重要的约束：加载Class 2的Black Key必须先于加载Class 1的Black Key。因为加载Class 1 Black Key会清除Class 1的密钥寄存器，如果先加载了Class 1密钥，再加载Class 2密钥，那么之前加载的Class 1密钥就白费了。更糟糕的是，如果描述符中后续操作依赖那个被清除的Class 1上下文，就会导致作业失败。

因此，在编写包含多个Black Key加载的描述符时，一个安全的命令顺序是：

1. JUMP,SEQ IN PTR,SEQ OUT PTR（这些是设置类命令，无副作用）
2. 向上述副作用未提及的寄存器执行LOAD或MOVE。
3. 加载Class 2 Black Key（如果有）。
4. 加载Class 1 Black Key。
5. 执行其他操作。

4.3 密钥的存储与安全控制

KEY命令还提供了两个与密钥导出相关的控制位：

• NWB (No Write Back)：如果设置，则阻止被加载的密钥后续通过FIFO STORE命令以任何形式（包括再次加密成Black Key）写回内存。这提供了更高的安全性，确保密钥一旦进入安全硬件，就再也无法离开。
• PTS (Plaintext Store)：如果设置，则允许被加载的密钥后续以明文形式通过FIFO STORE命令存储。这个标志有严格限制：它不能与ENC=1（Black Key）同时设置；不能与NWB=1同时设置；不能用于目标为PKHA E-Memory的加载；对于Class 2寄存器，仅当加载的是分割密钥或后续运行MDHA INIT模式生成分割密钥时，才允许存储。

一个常见的误区：认为PTS=1就可以随意将密钥寄存器中的明文读出来。实际上，即使设置了PTS，也需要通过特定的FIFO STORE命令并指向正确的密钥寄存器地址才能实现。硬件仍然有严格的访问控制。

4.4 可信描述符与密钥加载

对于运行在TrustZone安全世界（Secure World）的可信描述符（Trusted Descriptor），KEY命令中的TK位变得有意义。当TK=1且ENC=1时，SEC将使用可信描述符密钥加密密钥（TDKEK）来解密Black Key，而非普通的JDKEK。这为安全世界和非安全世界提供了密钥隔离的能力。如果描述符不是可信描述符，却设置了TK=1，将会产生错误。

阻塞场景：KEY命令在某些情况下是“阻塞”的，即DECO必须等待该命令完成才能继续执行后续命令。这些情况包括：解密Black Key、加载非立即数的Red Key、相关的CHA尚未完成、数据需要经过输入FIFO但被其他数据阻塞、需要CCB DMA但DMA忙等。在编写高性能、低延迟的描述符时，需要合理安排命令顺序，尽量减少这种阻塞。

5. 描述符命令的基石：HEADER命令详解

任何SEC描述符（无论是作业描述符Job Descriptor还是共享描述符Shared Descriptor）都必须以HEADER命令开始。它定义了描述符的基本属性和执行上下文，是SEC硬件解析描述符的起点。

5.1 作业描述符与共享描述符的HEADER

两者格式相似，但字段含义有专属部分。HEADER命令的第一个字（Word）包含了一个CTYPE字段来区分类型：10110b代表作业描述符，10111b代表共享描述符。

几个通用且关键的字段：

• ONE & ZRO：这两个固定位（ONE=1, ZRO=0）组成一个魔术字（Magic Number），用于检测描述符的字节序（Endianness）。SEC需要兼容大端和小端处理器，通过检查这两个固定位，硬件可以判断描述符在内存中的存储格式是否正确，从而避免因字节序误解而执行乱码指令。
• DNR (Do Not Run)：这是一个非常有用的流控制位。如果上游软件在准备作业时发现问题（例如资源不足），可以将此位置1。SEC硬件在遇到DNR=1的描述符时，会跳过其执行（但仍会获取关联的共享描述符），并将作业沿管道传递下去，最终返回给软件。软件可以修复问题后，清除DNR位重新提交作业。在共享描述符中，如果PD位被设置，作业描述符的DNR状态会传播到共享描述符头中，使其也停止运行，直到被软件清除。
• SHARE：这个字段定义了共享描述符的共享状态，即它如何在不同作业之间被共享（例如，不共享、串行共享、并行共享等）。这直接影响SEC的调度和上下文管理策略。

5.2 作业描述符HEADER的特殊字段

• SHR (Shared Descriptor Flag)：指示本作业描述符是否关联一个共享描述符。如果SHR=1，则HEADER命令后面紧跟的就是指向共享描述符的指针。
• START INDEX / SHR DESCR LENGTH：这个字段的意义取决于SHR位。
  • 如果SHR=0（无共享描述符），它是START INDEX，指定了描述符缓冲区中开始执行的位置（跳过头部的某些协议信息字）。
  • 如果SHR=1（有关联共享描述符），它是SHR DESCR LENGTH，指明了共享描述符的长度（以32位字为单位）。
• REO (Reverse Execution Order)：当SHR=1时，此位控制执行顺序。REO=0是默认顺序：先执行共享描述符，再执行作业描述符的剩余部分。REO=1则相反：先执行作业描述符，再执行共享描述符。这在某些需要先由作业描述符准备数据，再由共享描述符（可能被多个作业共享）处理的场景下有用。注意：可信描述符不允许设置REO=1。
• EXT & 扩展头：如果EXT=1，则HEADER命令后跟一个扩展头字。扩展头包含了FTD（伪可信描述符）、DSELECTVALID和DECO_SELECT等字段，用于更精细的控制，例如将作业绑定到特定的DECO上执行。但手册也警告，将作业指定到特定DECO可能会在流处理中引发死锁，需谨慎使用。

5.3 共享描述符HEADER的特殊字段

• RIF (Read Input Frame)：这是一个性能优化位。如果设置，DECO会尽可能早地读取整个输入帧（如作业描述符中SEQ IN PTR所定义）到输入数据FIFO中，以减少处理延迟。但是，它的使用有很多禁忌，例如描述符中包含非立即数的LOAD或KEY命令、包含加密密钥加载、包含带RTO的SEQ IN PTR、指定了某些特定的协议操作（如SSL/TLS解封装、带外部IP头的IPsec ESP隧道封装等）时，不能使用RIF。在使用前必须仔细核对手册。
• CIF (Clear Input FIFO)：在自共享（同一个DECO内连续执行相同共享描述符的作业）场景下，如果此位置位，则在作业之间会清空输入FIFO和NFIFO条目。这确保了每个作业都有干净的输入起点。
• SC (Save Context)：在串行共享且自共享的场景下，如果此位置位，则当前描述符执行完毕后，其上下文寄存器（Context Registers）将被保留，供下一个使用相同共享描述符的作业使用。这对于需要将单个加密操作（如处理一个很长的消息）拆分成多个连续作业的场景至关重要，它允许跨作业维持加密状态（如AES-CTR模式的计数器、CBC模式的初始化向量IV等）。

经验之谈：SC位是实现流式加密/认证（如加密一个大文件）的关键。你需要精心设计共享描述符，使其包含算法的初始化（INIT）和更新（UPDATE）部分，并在最后一个作业中使用不同的描述符或协议命令来执行最终化（FINALIZE）。SC=1保证了在串行执行的多个UPDATE作业间，上下文不会丢失。我第一次实现AES-CBC流加密时，没设置SC位，导致每个数据块的加密都是独立的，完全失去了CBC模式的意义，密文根本无法解密。