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 793TCP规范明确指出如果待校验的数据字节数为奇数则在最后一个字节的右侧填充一个值为零的字节以构成一个完整的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将不同的密码学算法划分为了两个“类别”ClassClass 1和Class 2。3.1 算法分类详解这个分类主要是基于算法实现的硬件电路特性来划分的。理解这个分类是正确编写描述符的关键因为很多与密钥和数据移动相关的命令如LOAD,STORE,KEY都需要指定一个CLASS值以确保指令被发送到正确的CHA队列。下表清晰地展示了常见算法的分类算法类别包含的算法Class 1AES所有模式、DES、3DES、Kasumi、SNOW f8、ZUC加密、公钥算法如RSA、ECC、随机数生成器RNGClass 2SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256、SNOW f9、CRC、ZUCA AES认证模式、MD5一个重要特例一些优化的复合操作模式例如同时进行加密和认证的AES-GCM需要同时使用Class 1和Class 2的资源。对于这种模式认证密钥必须放在Class 2密钥寄存器中而加密/解密密钥必须放在Class 1密钥寄存器中。描述符中需要包含对两类CHA的请求。3.2 死锁规避与命令顺序强制规则当单个描述符需要同时使用Class 1和Class 2的CHA时SEC硬件强制规定了一个重要的顺序必须先请求acquireClass 2 CHA然后再请求Class 1 CHA。这条规则是为了防止在多DECO描述符控制器的SEC版本中出现死锁。想象一下有两个描述符X和Y在两个DECO上同时执行描述符X锁定了Class 1 CHA然后尝试请求Class 2 CHA。描述符Y锁定了Class 2 CHA然后尝试请求Class 1 CHA。此时两个描述符都在等待对方释放资源但谁都不会先释放自己已持有的资源从而形成死锁。通过强制规定所有描述符都按照Class 2 - Class 1的相同顺序请求资源就彻底杜绝了这种循环等待的可能性。SEC硬件会进行检查如果检测到描述符在已获得Class 1 CHA后再去请求Class 2 CHA将会产生错误。关键提醒即使你当前开发的芯片是单DECO的SEC版本软件也必须遵守此规则。这是保证代码可移植到未来多DECO SEC版本的最佳实践。在编写描述符时务必检查所有涉及双Class操作的命令序列。3.3 CLASS字段的编码含义在描述符命令中CLASS字段通常是一个2位的编码其含义根据命令类型略有不同CLASS值对于LOAD/STORE命令的含义对于其他命令的含义00CCB类无关CCB class independent无或对于SEQ FIFO LOAD表示跳过序列数据01CCB Class 1Class 110CCB Class 2Class 211DECO同时涉及Class 1和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的关键。如果ENC0密钥是明文Red Key直接加载。如果ENC1密钥是加密状态Black KeySEC会在加载过程中自动使用JDKEK或可信描述符的TDKEK对其进行解密。EKT (加密密钥类型)当ENC1时此位指定了解密Black Key所使用的算法。0代表AES-ECB模式1代表AES-CCM模式。必须与当初加密该黑钥时使用的模式一致否则解密出的密钥是错误的且可能不会报错导致后续加密操作全部失败这种静默错误极其危险。KDEST (密钥目标)指定加载位置。00b到密钥寄存器Class 1/201b到PKHA E-Memory仅Class 111b作为MDHA分割密钥加载到Class 2密钥寄存器仅Class 2。分割密钥是HMAC优化的一种形式将IPAD和OPAD材料拼接在一起一次性加载。4.2 加载Black Key的副作用与命令顺序加载一个Black KeyENC1不是一个简单的数据搬运操作它内部触发了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加载的描述符时一个安全的命令顺序是JUMP,SEQ IN PTR,SEQ OUT PTR这些是设置类命令无副作用向上述副作用未提及的寄存器执行LOAD或MOVE。加载Class 2 Black Key如果有。加载Class 1 Black Key。执行其他操作。4.3 密钥的存储与安全控制KEY命令还提供了两个与密钥导出相关的控制位NWB (No Write Back)如果设置则阻止被加载的密钥后续通过FIFO STORE命令以任何形式包括再次加密成Black Key写回内存。这提供了更高的安全性确保密钥一旦进入安全硬件就再也无法离开。PTS (Plaintext Store)如果设置则允许被加载的密钥后续以明文形式通过FIFO STORE命令存储。这个标志有严格限制它不能与ENC1Black Key同时设置不能与NWB1同时设置不能用于目标为PKHA E-Memory的加载对于Class 2寄存器仅当加载的是分割密钥或后续运行MDHA INIT模式生成分割密钥时才允许存储。一个常见的误区认为PTS1就可以随意将密钥寄存器中的明文读出来。实际上即使设置了PTS也需要通过特定的FIFO STORE命令并指向正确的密钥寄存器地址才能实现。硬件仍然有严格的访问控制。4.4 可信描述符与密钥加载对于运行在TrustZone安全世界Secure World的可信描述符Trusted DescriptorKEY命令中的TK位变得有意义。当TK1且ENC1时SEC将使用可信描述符密钥加密密钥TDKEK来解密Black Key而非普通的JDKEK。这为安全世界和非安全世界提供了密钥隔离的能力。如果描述符不是可信描述符却设置了TK1将会产生错误。阻塞场景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这两个固定位ONE1, ZRO0组成一个魔术字Magic Number用于检测描述符的字节序Endianness。SEC需要兼容大端和小端处理器通过检查这两个固定位硬件可以判断描述符在内存中的存储格式是否正确从而避免因字节序误解而执行乱码指令。DNR (Do Not Run)这是一个非常有用的流控制位。如果上游软件在准备作业时发现问题例如资源不足可以将此位置1。SEC硬件在遇到DNR1的描述符时会跳过其执行但仍会获取关联的共享描述符并将作业沿管道传递下去最终返回给软件。软件可以修复问题后清除DNR位重新提交作业。在共享描述符中如果PD位被设置作业描述符的DNR状态会传播到共享描述符头中使其也停止运行直到被软件清除。SHARE这个字段定义了共享描述符的共享状态即它如何在不同作业之间被共享例如不共享、串行共享、并行共享等。这直接影响SEC的调度和上下文管理策略。5.2 作业描述符HEADER的特殊字段SHR (Shared Descriptor Flag)指示本作业描述符是否关联一个共享描述符。如果SHR1则HEADER命令后面紧跟的就是指向共享描述符的指针。START INDEX / SHR DESCR LENGTH这个字段的意义取决于SHR位。如果SHR0无共享描述符它是START INDEX指定了描述符缓冲区中开始执行的位置跳过头部的某些协议信息字。如果SHR1有关联共享描述符它是SHR DESCR LENGTH指明了共享描述符的长度以32位字为单位。REO (Reverse Execution Order)当SHR1时此位控制执行顺序。REO0是默认顺序先执行共享描述符再执行作业描述符的剩余部分。REO1则相反先执行作业描述符再执行共享描述符。这在某些需要先由作业描述符准备数据再由共享描述符可能被多个作业共享处理的场景下有用。注意可信描述符不允许设置REO1。EXT 扩展头如果EXT1则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。SC1保证了在串行执行的多个UPDATE作业间上下文不会丢失。我第一次实现AES-CBC流加密时没设置SC位导致每个数据块的加密都是独立的完全失去了CBC模式的意义密文根本无法解密。