1. 项目概述TLS 1.2密钥派生的硬件加速之路在构建现代安全通信链路时TLS协议是基石。握手过程中最核心、最耗时的环节之一就是从短暂的预主密钥premaster_secret派生出用于实际数据加密和完整性校验的一整套会话密钥材料。这个过程依赖于一个称为伪随机函数PseudoRandom Function, PRF的密码学组件。在软件中实现PRF尤其是面对高并发、低延迟的服务器场景会消耗可观的CPU资源。因此将这部分计算卸载到专用的硬件安全引擎Security Engine, SEC成为提升系统整体性能与安全性的关键。NXP的QorIQ LS1046A处理器集成的SEC模块正是为此而生。它不仅仅是一个协处理器更是一个理解TLS协议语义的“智能”加速器能够高效、安全地完成从预主密钥到最终密钥材料的完整派生流程。本文将深入剖析SEC对TLS 1.2 PRF的硬件实现机制从算法原理到硬件指令集从数据块格式到安全考量为你呈现一套完整的硬件加速密钥派生方案。2. TLS 1.2 PRF算法原理与SEC的硬件映射2.1 PRF算法核心基于HMAC的迭代扩展TLS 1.2的PRF定义在RFC 5246中其核心思想是使用HMAC基于哈希的消息认证码作为密码学原语从一个秘密种子secret和标签label、种子seed等输入材料中确定性地生成任意长度的伪随机字节流。算法可以概括为两个阶段P_hash 函数这是PRF的基础。给定一个秘密secret、一个种子seed和所需的输出长度P_hash通过迭代HMAC计算来生成输出。首先计算A(1) HMAC_hash(secret, A(0) seed)。然后计算A(2) HMAC_hash(secret, A(1))以此类推生成序列A(i)。对于每个A(i)i1计算HMAC_hash(secret, A(i) seed)并将其输出依次拼接直到达到所需的字节数。TLS PRFTLS 1.2的PRF实际上是两个P_hash的拼接分别使用SHA-256和SHA-384哈希算法然后将它们的输出进行异或XOR。这种设计提供了额外的安全冗余。具体公式为PRF(secret, label, seed) P_SHA256(secret, label seed) XOR P_SHA384(secret, label seed)。在SEC的硬件实现中它巧妙地封装了这个过程。硬件并不需要软件预先计算好A(i)序列而是内部状态机自动处理迭代。用户只需要提供最原始的输入secret即预主密钥或主密钥、label如“client write key”和seed来自握手消息的随机数并指定输出长度和目的地SEC就能自动完成整个PRF计算。2.2 SEC硬件实现的优化与约束SEC的硬件设计对算法进行了深度优化同时也引入了一些必须了解的约束输入预处理协议标准对premaster_secret的长度没有硬性限制但SEC硬件有物理限制。它不支持长度超过512字节的预主密钥。此外HMAC算法的密钥即这里的secret也有长度限制对于大多数HMAC算法如HMAC-SHA256最大为64字节对于HMAC-SHA384/512最大为128字节。如果提供的secret超过这个长度SEC会在内部自动执行预处理——使用指定的哈希算法对过长的secret进行哈希将哈希结果作为新的、长度合规的secret用于后续PRF计算。这个过程对用户透明但开发者需要知晓此限制避免提供超长的密钥材料导致性能非预期下降因为多了一次哈希运算。输入拼接的持久化在PRF计算中label和seed需要拼接成一个连续的输入字符串。SEC在硬件层面实现了这一优化它将所有标记为label和seed的输入材料在计算开始前就拼接成一个持久的内部字符串。在整个P_hash迭代计算过程中这个拼接后的字符串被反复使用避免了软件实现中每次迭代都需要进行内存拷贝或拼接的开销显著提升了效率。密钥材料的定向分发这是SEC硬件PRF最强大的特性之一。它不仅仅是生成一堆随机字节而是理解TLS协议中密钥材料的具体用途。SEC的PRF函数被设计成可以将生成的字节流按需、安全地分发到最多8个不同的“目的地”。每个目的地可以独立配置其安全属性。例如在典型的TLS密钥派生中PRF输出会被分割为客户端写MAC密钥Client-write MAC secret服务器写MAC密钥Server-write MAC secret客户端写加密密钥Client-write key服务器写加密密钥Server-write key客户端写IVClient-write IV服务器写IVServer-write IV SEC允许在单个操作中指定每个目标输出的长度并决定其是否为“敏感密钥材料”。对于敏感材料如MAC密钥和加密密钥SEC可以启用输出加密功能使用一个密钥加密密钥Key Encryption Key, KEK对其在离开安全边界前进行加密保护。而对于非敏感数据如IV则可以明文输出。这种“生成即保护”的机制极大地增强了整个密钥生命周期的安全性。算法套件感知SEC的硬件逻辑与协议深度结合。例如当选择的加密套件是AES-GCM时由于GCM模式使用认证加密不再需要独立的MAC运算因此也就没有MAC密钥。SEC能够识别这一情况并自动跳过为“client-write MAC secret”和“server-write MAC secret”分配输出长度的步骤无论协议数据块PDB中为这两个字段指定了何种长度。这种智能行为减少了软件配置的复杂性并避免了潜在的错误。3. TLS 1.2 PRF协议数据块PDB详解要驱动SEC执行PRF操作软件需要构建一个称为协议数据块Protocol Data Block, PDB的命令结构。这个PDB包含了所有必要的控制信息和数据指针。理解PDB的每个字段是正确使用硬件加速器的关键。3.1 PDB整体结构与选项字节Options ByteTLS 1.2 PRF的PDB格式相对复杂其核心控制部分是一个“选项字节”Options Byte它位于PDB的特定偏移位置。这个字节的每一位都控制着关键的安全和处理行为。表 3-1: TLS 1.2 PRF PDB 选项字节格式与描述位名称描述详解与配置建议7-4Reserved保留位必须设置为0。3IEKT(Input Encryption Key Type)输入加密密钥类型此字段仅当输入的主密钥master_secret被加密时才有效。它定义了用于解密输入密钥的算法。•0: 使用AES-ECB-256算法解密。•1: 使用AES-CCM-256算法解密。注意如果输入是明文IEOV1此字段被忽略。AES-CCM模式能同时提供加密和完整性校验安全性更高但计算开销略大于ECB。2OEKT(Output Encryption Key Type)输出加密密钥类型此字段仅当生成的密钥材料需要加密输出时才有效。它定义了用于加密输出密钥材料的算法。•0: 使用AES-ECB-256算法加密。•1: 使用AES-CCM-256算法加密。注意是否加密由OEOV字段及PROTINFO共同决定。同样CCM模式是更安全的选择。1IEOV(Input Encryption Override)输入加密覆盖控制输入的主密钥master_secret的加密状态。•1:输入是明文。SEC将直接使用提供的master_secret进行PRF计算。•0:输入是密文。SEC会先使用IEKT指定的算法和相应的KEK对其进行解密然后再使用。这是最常见的使用场景用于保护存储在外部内存中的主密钥。0OEOV(Output Encryption Override)输出加密覆盖控制输出的密钥材料是否加密。此字段仅在PROTINFO字段值为FFFF或FFFE时被忽略此时加密行为由其他机制决定。在其他情况下•1: 如果PROTINFOFFFF/FFFE生成的密钥材料不加密明文输出。•0: 如果PROTINFOFFFF/FFFE生成的密钥材料被加密。加密算法由OEKT指定。实操提示在典型的TLS会话建立中PROTINFO会携带加密套件信息因此OEOV通常有效。设置为0可以确保派生的会话密钥在离开SEC硬件时已被加密是推荐的安全实践。注意PROTINFO是操作命令OPERATION Command中的一个字段用于指示协议类型和算法套件。当它为FFFF或FFFE时通常表示一个“原始”的PRF计算不关联特定TLS套件此时输出加密行为由OEOV直接控制。当它表示一个具体的TLS套件时SEC内部逻辑可能会覆盖OEOV的设置。3.2 输入与输出引用Input/Output ReferencePDB中包含了指向输入数据和输出缓冲区的“引用”Reference。每个引用由两部分组成一个指针Pointer和一个控制字Control Word。指针Pointer指向数据在内存中的地址。其长度32位或64位由主配置寄存器Master Configuration Register的PS字段决定。这是开发驱动时需要特别注意的移植性问题。控制字Control Word描述了所指向数据的属性和长度。输入引用控制字的字段至关重要Input Secret Length (30-21位)输入密钥secret的长度以字节为单位。关键约束如果PRF输出被分割成多个密钥即PROTINFO ! FFFF/FFFE那么输入的必须是标准的48字节TLS主密钥master_secret并且此字段被忽略长度固定为48。Input Label Length (20-14位)输入标签label的长度以字节为单位。根据协议定义合法值在11到15之间含。例如“client finished”是15字节“server write key”是14字节。Input Seed Part 1 Length (13-7位)输入种子第一部分seed的长度合法值为16或32字节。这通常对应客户端随机数ClientHello.random或服务器随机数ServerHello.random。Input Seed Part 2 Length (6-0位)输入种子第二部分seed的长度合法值为20或32字节。这通常对应另一个随机数或握手消息的哈希值。输出引用控制字的字段SGT (31位)指定指针是直接指向数据0还是指向一个散点/聚集表Scatter/Gather Table, 1。SGT允许将输出分散到多个不连续的内存块这在复杂的内存管理场景中很有用。LENGTH (23-16位)数据长度字节。行为取决于PROTINFO如果PROTINFO FFFF/FFFE此字段表示输出的主密钥或验证数据verify_data的长度。如果PROTINFO ! FFFF/FFFE即指定了TLS套件此字段被忽略。输出长度由PROTINFO所指示的加密套件决定。3.3 配置示例与流程假设我们要为一个TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256套件的连接派生密钥且主密钥已加密存储在外部DDR内存中。构建PDB设置IEKT0AES-ECB-256解密输入。设置IEOV0输入是密文。设置OEKT1AES-CCM-256加密输出更安全。设置OEOV0加密输出密钥材料。在OPERATION命令中设置PROTINFO为该加密套件对应的值。配置输入引用Input Secret Length: 忽略因为PROTINFO非特殊值且输入是密文长度由解密后决定但硬件知道是48字节。Input Label Length: 根据派生阶段设置如扩展主密钥时是“key expansion”。Input Seed Part 1/2 Length: 设置为客户端和服务器随机数的长度各32字节。配置6个输出引用分别对应client write key,server write key,client write IV,server write IV。注意AES-GCM套件无MAC密钥SEC会自动跳过对应的引用。为每个输出引用设置LENGTH此处被忽略但需预留空间、SGT并指向准备好的输出缓冲区或SGT。驱动执行将构建好的PDB和OPERATION命令提交给SEC的描述符控制器。SEC会依次执行解密输入主密钥 - 拼接label和seed - 执行PRF迭代计算 - 按指定长度分割输出 - 使用KEK加密敏感密钥材料 - 将结果写入各个输出目的地。软件后处理软件从输出缓冲区获取加密后的会话密钥材料。这些材料在用于加解密操作前可能需要先加载回SEC的内部密钥寄存器这通常由后续的对称加解密描述符自动完成使用相同的KEK解密。4. 派生密钥协议DKP的深度解析与应用除了PRFSEC还提供了一个极为重要的辅助协议派生密钥协议Derived Key Protocol, DKP。它的主要目的不是生成新密钥而是对现有密钥进行格式转换以适配硬件加速器的内部处理格式从而获得巨大的性能提升。4.1 DKP的核心价值HMAC Split KeyDKP最典型的应用是生成HMAC的“分裂密钥”Split Key也称为IPAD/OPAD格式。在HMAC算法中密钥K会与两个固定的填充常量ipad和opad进行异或生成K_ipad和K_opad然后才参与哈希运算。在软件实现中这一步通常在每次HMAC计算时动态完成。SEC的MDHA消息摘要硬件加速器模块在设计上可以直接接受这种预计算好的K_ipad和K_opad作为输入从而跳过异或步骤直接开始哈希压缩。DKP的作用正是将原始的、协商好的HMAC密钥Negotiated Key一次性计算并转换成(K_ipad, K_opad)对即“分裂密钥”。性能优势对于IPsec、TLS等需要处理大量小数据包认证的场景每个数据包的HMAC计算如果都从原始密钥开始做异或会引入不必要的开销。通过DKP预计算并存储分裂密钥后续的每一个HMAC操作都节省了这一步在高速网络处理中累积的性能收益非常显著。4.2 DKP的工作机制与描述符内替换DKP的设计非常巧妙它支持“就地”in-place替换。这意味着你可以在一个描述符Descriptor即SEC的指令序列中直接完成密钥转换和后续的加密/认证操作。工作流程如下在描述符中你首先放置一个DKP操作命令OPERATION Command。在该命令之后你提供原始的、协商好的HMAC密钥可能是明文也可能是特定格式的密文。DKP命令执行它读取原始密钥计算其分裂密钥形式。关键步骤DKP硬件不仅计算分裂密钥还会动态修改你提交的描述符。它会将描述符中的DKP操作命令本身替换成一个标准的KEY命令。同时它将描述符中提供的原始密钥数据替换成刚刚计算好的分裂密钥。分裂密钥会被写入SEC的Class 2密钥寄存器供紧随其后的MDHA命令例如用于计算IPsec的AH/ESP认证数据直接使用。描述符继续执行此时它“看到”的已经是一个标准的KEY命令和可用的分裂密钥了。这种“描述符内替换”机制使得软件可以编写一个统一的、包含密钥协商和数据处理流程的描述符。DKP在运行时自动完成密钥格式的适配无需软件中断处理或额外的内存拷贝实现了极高的流水线效率和简洁的编程模型。警告描述符作者必须确保DKP操作输出的分裂密钥数据不会覆盖描述符中后续需要保留的命令或数据。这需要仔细计算描述符的内存布局。通常的做法是在原始密钥数据后预留足够的空间分裂密钥的长度是原始密钥的两倍见下文表4-1或者使用分散/聚集表SGT来管理输出。4.3 DKP的输入/输出源与长度DKP操作命令中的PROTINFO字段的I/O控制子域bits 16-19被分为两部分分别指定输入源和输出目的地。输入源Input Source, bits 16-1700(IMM)原始密钥紧跟在DKP命令之后。此选项只能与输出目的地00(IMM)配对使用。01(SEQ)原始密钥位于由SEQ IN PTR命令定义的输入帧中。在可信描述符Trusted Descriptor中必须使用此选项。10(PTR)原始密钥的地址指针紧跟在DKP命令之后。11(SGF)原始密钥分散在由散点/聚集表指定的多个内存位置。输出目的地Output Destination, bits 18-1900(IMM)计算出的分裂密钥将写回描述符紧挨着被替换成的KEY命令之后。这会覆盖该位置原有的数据。01(SEQ)分裂密钥写入由SEQ OUT PTR命令定义的输出帧。仅当输入源也是SEQ时才有效且是可信描述符的必须选择。10(PTR)分裂密钥写入DKP命令后指定的地址指针处。不能与输入源IMM或SGF共用。11(SGF)分裂密钥根据DKP命令后的散点/聚集表写入内存。不能与输入源IMM或PTR共用。分裂密钥长度派生出的分裂密钥长度取决于底层哈希算法是固定的与原始密钥长度无关。表 4-1: HMAC派生密钥分裂密钥长度哈希算法派生“分裂”密钥长度对应字数32位系统MD532 字节8 字SHA-140 字节10 字SHA-224 / SHA-25664 字节16 字SHA-384 / SHA-512128 字节32 字例如如果你有一个20字节的原始SHA-256 HMAC密钥经过DKP处理后你会得到一个64字节的数据块其中前32字节是K_ipad后32字节是K_opad。后续的MDHA命令在配置为HMAC-SHA256时会期望从这个64字节的缓冲区中读取密钥。5. 硬件加速器协同工作与安全考量SEC不是一个单一的模块而是由多个密码学硬件加速器CHA协同工作的综合体。理解PRF和DKP如何与其他CHA交互对于设计高效安全的系统至关重要。5.1 与MDHA和AESA的协作PRF MDHAPRF的核心是HMAC而HMAC的核心是哈希函数如SHA256。SEC内部的MDHA模块就是专门执行哈希运算的硬件。当PRF命令被执行时它会在内部调用MDHA来完成HMAC计算。这种调用对软件完全透明但意味着PRF的性能与MDHA的性能直接相关。PRF/DKP AESA当启用输入/输出加密时通过IEKT/OEKT配置PRF和DKP会调用AESAAES加速器来执行AES-ECB或AES-CCM算法。KEK通常存储在SEC内部受保护的密钥寄存器中。这种设计确保了密钥材料在SEC芯片边界之外即在系统内存中始终处于加密状态即使物理内存被窃取攻击者也无法直接获得明文密钥。密钥传递DKP生成的Split Key或PRF生成的会话密钥通常不会直接返回给主CPU。它们被直接写入SEC内部的Class 1或Class 2密钥寄存器。随后当描述符中的下一个命令如AESA用于加密MDHA用于认证需要密钥时它直接从这些寄存器中读取。这实现了密钥材料在安全引擎内部的“闭环”流动最大限度地减少了密钥在总线或内存中暴露的风险。5.2 安全最佳实践与常见陷阱密钥生命周期管理预主密钥应在安全环境如TEE中生成或通过PKHA公钥硬件加速器计算得到。进入SEC参与PRF计算前应始终以加密形式IEOV0提供。主密钥PRF扩展出的48字节主密钥是会话安全的根。如果不需要存储应尽快使用并让SEC在内部销毁。如果需要存储例如用于会话恢复必须使用OEKT加密后输出。会话密钥PRF派生的最终加密密钥和MAC密钥必须设置为加密输出OEOV0。IV可以明文输出。KEK管理用于加密输入/输出密钥的KEK是更高层级的秘密。它应由安全的随机源生成并存储在SEC的受保护密钥寄存器或硬件安全模块HSM中绝不能出现在普通内存中。防侧信道攻击SEC的PKHA模块在执行模幂运算等公钥操作时支持时序均衡化timing-equalized模式以抵御时序攻击。在配置ECC或RSA操作时应优先启用此功能。虽然PRF和DKP本身是确定性的但确保其输入随机数的熵值足够高是防御各类密码分析攻击的前提。配置错误排查PRF输出长度异常检查PROTINFO字段是否与预期的加密套件匹配。如果PROTINFO设置为FFFF但期望输出多个密钥会导致错误因为此时SEC期望的是单一输出如主密钥或Finished验证数据。DKP描述符崩溃最常见的原因是分裂密钥的输出覆盖了描述符后续的指令。务必精确计算IMM输出模式下的内存偏移。使用PTR或SGF模式将输出指向独立的缓冲区是更安全的选择。性能未达预期如果PRF计算慢检查输入的secret长度是否超过了HMAC密钥限制64/128字节导致SEC内部触发了预处理哈希。尽量使用标准长度的密钥。与Blob协议的结合SEC还支持Blob协议用于跨芯片上下电周期加密保护用户数据。虽然本文未深入展开但它的思想与PRF的输出加密一脉相承使用一个非易失性主密钥派生出临时密钥来加密数据。在需要持久化加密密钥或敏感配置的场景可以将PRF输出的、经KEK加密的会话密钥再用Blob协议封装一次后存储到Flash中实现双层保护。6. 总结与实战心得将TLS 1.2的密钥派生工作卸载到NXP QorIQ SEC硬件引擎远不止是获得计算性能的提升。它更是一种系统级的安全架构升级。通过深入理解PRF PDB的每个比特位、DKP的原地替换机制以及各CHA间的协同开发者能够设计出既高效又健壮的网络安全应用。从我多年的嵌入式安全开发经验来看成功集成此类硬件加速器关键在于转变思维从“调用一个库函数”转变为“编排一个安全的数据处理流水线”。你需要像设计硬件电路一样思考描述符的编排确保密钥的生成、转换、使用、销毁都在硬件的安全边界内完成软件只负责触发和提供必要的参数。一个实用的建议是在项目初期就构建一个完备的测试向量套件。不仅包括标准RFC的测试向量还应模拟各种边界情况超长的预主密钥触发预处理、使用AES-GCM套件验证MAC密钥被跳过、配置错误的输出长度等。硬件行为有时比软件更“固执”清晰的文档和充分的测试是避免后期调试噩梦的最佳良药。最后永远不要忽视那个最简单的选项——OEOV。除非有极其特殊的调试需求否则永远将其设置为0加密输出。让密钥在离开安全引擎的瞬间就被锁进“保险箱”这是利用此类硬件所能获得的最基本、也最重要的安全收益。
TLS 1.2密钥派生硬件加速：NXP SEC引擎的PRF与DKP深度解析
发布时间：2026/6/22 13:55:08
1. 项目概述TLS 1.2密钥派生的硬件加速之路在构建现代安全通信链路时TLS协议是基石。握手过程中最核心、最耗时的环节之一就是从短暂的预主密钥premaster_secret派生出用于实际数据加密和完整性校验的一整套会话密钥材料。这个过程依赖于一个称为伪随机函数PseudoRandom Function, PRF的密码学组件。在软件中实现PRF尤其是面对高并发、低延迟的服务器场景会消耗可观的CPU资源。因此将这部分计算卸载到专用的硬件安全引擎Security Engine, SEC成为提升系统整体性能与安全性的关键。NXP的QorIQ LS1046A处理器集成的SEC模块正是为此而生。它不仅仅是一个协处理器更是一个理解TLS协议语义的“智能”加速器能够高效、安全地完成从预主密钥到最终密钥材料的完整派生流程。本文将深入剖析SEC对TLS 1.2 PRF的硬件实现机制从算法原理到硬件指令集从数据块格式到安全考量为你呈现一套完整的硬件加速密钥派生方案。2. TLS 1.2 PRF算法原理与SEC的硬件映射2.1 PRF算法核心基于HMAC的迭代扩展TLS 1.2的PRF定义在RFC 5246中其核心思想是使用HMAC基于哈希的消息认证码作为密码学原语从一个秘密种子secret和标签label、种子seed等输入材料中确定性地生成任意长度的伪随机字节流。算法可以概括为两个阶段P_hash 函数这是PRF的基础。给定一个秘密secret、一个种子seed和所需的输出长度P_hash通过迭代HMAC计算来生成输出。首先计算A(1) HMAC_hash(secret, A(0) seed)。然后计算A(2) HMAC_hash(secret, A(1))以此类推生成序列A(i)。对于每个A(i)i1计算HMAC_hash(secret, A(i) seed)并将其输出依次拼接直到达到所需的字节数。TLS PRFTLS 1.2的PRF实际上是两个P_hash的拼接分别使用SHA-256和SHA-384哈希算法然后将它们的输出进行异或XOR。这种设计提供了额外的安全冗余。具体公式为PRF(secret, label, seed) P_SHA256(secret, label seed) XOR P_SHA384(secret, label seed)。在SEC的硬件实现中它巧妙地封装了这个过程。硬件并不需要软件预先计算好A(i)序列而是内部状态机自动处理迭代。用户只需要提供最原始的输入secret即预主密钥或主密钥、label如“client write key”和seed来自握手消息的随机数并指定输出长度和目的地SEC就能自动完成整个PRF计算。2.2 SEC硬件实现的优化与约束SEC的硬件设计对算法进行了深度优化同时也引入了一些必须了解的约束输入预处理协议标准对premaster_secret的长度没有硬性限制但SEC硬件有物理限制。它不支持长度超过512字节的预主密钥。此外HMAC算法的密钥即这里的secret也有长度限制对于大多数HMAC算法如HMAC-SHA256最大为64字节对于HMAC-SHA384/512最大为128字节。如果提供的secret超过这个长度SEC会在内部自动执行预处理——使用指定的哈希算法对过长的secret进行哈希将哈希结果作为新的、长度合规的secret用于后续PRF计算。这个过程对用户透明但开发者需要知晓此限制避免提供超长的密钥材料导致性能非预期下降因为多了一次哈希运算。输入拼接的持久化在PRF计算中label和seed需要拼接成一个连续的输入字符串。SEC在硬件层面实现了这一优化它将所有标记为label和seed的输入材料在计算开始前就拼接成一个持久的内部字符串。在整个P_hash迭代计算过程中这个拼接后的字符串被反复使用避免了软件实现中每次迭代都需要进行内存拷贝或拼接的开销显著提升了效率。密钥材料的定向分发这是SEC硬件PRF最强大的特性之一。它不仅仅是生成一堆随机字节而是理解TLS协议中密钥材料的具体用途。SEC的PRF函数被设计成可以将生成的字节流按需、安全地分发到最多8个不同的“目的地”。每个目的地可以独立配置其安全属性。例如在典型的TLS密钥派生中PRF输出会被分割为客户端写MAC密钥Client-write MAC secret服务器写MAC密钥Server-write MAC secret客户端写加密密钥Client-write key服务器写加密密钥Server-write key客户端写IVClient-write IV服务器写IVServer-write IV SEC允许在单个操作中指定每个目标输出的长度并决定其是否为“敏感密钥材料”。对于敏感材料如MAC密钥和加密密钥SEC可以启用输出加密功能使用一个密钥加密密钥Key Encryption Key, KEK对其在离开安全边界前进行加密保护。而对于非敏感数据如IV则可以明文输出。这种“生成即保护”的机制极大地增强了整个密钥生命周期的安全性。算法套件感知SEC的硬件逻辑与协议深度结合。例如当选择的加密套件是AES-GCM时由于GCM模式使用认证加密不再需要独立的MAC运算因此也就没有MAC密钥。SEC能够识别这一情况并自动跳过为“client-write MAC secret”和“server-write MAC secret”分配输出长度的步骤无论协议数据块PDB中为这两个字段指定了何种长度。这种智能行为减少了软件配置的复杂性并避免了潜在的错误。3. TLS 1.2 PRF协议数据块PDB详解要驱动SEC执行PRF操作软件需要构建一个称为协议数据块Protocol Data Block, PDB的命令结构。这个PDB包含了所有必要的控制信息和数据指针。理解PDB的每个字段是正确使用硬件加速器的关键。3.1 PDB整体结构与选项字节Options ByteTLS 1.2 PRF的PDB格式相对复杂其核心控制部分是一个“选项字节”Options Byte它位于PDB的特定偏移位置。这个字节的每一位都控制着关键的安全和处理行为。表 3-1: TLS 1.2 PRF PDB 选项字节格式与描述位名称描述详解与配置建议7-4Reserved保留位必须设置为0。3IEKT(Input Encryption Key Type)输入加密密钥类型此字段仅当输入的主密钥master_secret被加密时才有效。它定义了用于解密输入密钥的算法。•0: 使用AES-ECB-256算法解密。•1: 使用AES-CCM-256算法解密。注意如果输入是明文IEOV1此字段被忽略。AES-CCM模式能同时提供加密和完整性校验安全性更高但计算开销略大于ECB。2OEKT(Output Encryption Key Type)输出加密密钥类型此字段仅当生成的密钥材料需要加密输出时才有效。它定义了用于加密输出密钥材料的算法。•0: 使用AES-ECB-256算法加密。•1: 使用AES-CCM-256算法加密。注意是否加密由OEOV字段及PROTINFO共同决定。同样CCM模式是更安全的选择。1IEOV(Input Encryption Override)输入加密覆盖控制输入的主密钥master_secret的加密状态。•1:输入是明文。SEC将直接使用提供的master_secret进行PRF计算。•0:输入是密文。SEC会先使用IEKT指定的算法和相应的KEK对其进行解密然后再使用。这是最常见的使用场景用于保护存储在外部内存中的主密钥。0OEOV(Output Encryption Override)输出加密覆盖控制输出的密钥材料是否加密。此字段仅在PROTINFO字段值为FFFF或FFFE时被忽略此时加密行为由其他机制决定。在其他情况下•1: 如果PROTINFOFFFF/FFFE生成的密钥材料不加密明文输出。•0: 如果PROTINFOFFFF/FFFE生成的密钥材料被加密。加密算法由OEKT指定。实操提示在典型的TLS会话建立中PROTINFO会携带加密套件信息因此OEOV通常有效。设置为0可以确保派生的会话密钥在离开SEC硬件时已被加密是推荐的安全实践。注意PROTINFO是操作命令OPERATION Command中的一个字段用于指示协议类型和算法套件。当它为FFFF或FFFE时通常表示一个“原始”的PRF计算不关联特定TLS套件此时输出加密行为由OEOV直接控制。当它表示一个具体的TLS套件时SEC内部逻辑可能会覆盖OEOV的设置。3.2 输入与输出引用Input/Output ReferencePDB中包含了指向输入数据和输出缓冲区的“引用”Reference。每个引用由两部分组成一个指针Pointer和一个控制字Control Word。指针Pointer指向数据在内存中的地址。其长度32位或64位由主配置寄存器Master Configuration Register的PS字段决定。这是开发驱动时需要特别注意的移植性问题。控制字Control Word描述了所指向数据的属性和长度。输入引用控制字的字段至关重要Input Secret Length (30-21位)输入密钥secret的长度以字节为单位。关键约束如果PRF输出被分割成多个密钥即PROTINFO ! FFFF/FFFE那么输入的必须是标准的48字节TLS主密钥master_secret并且此字段被忽略长度固定为48。Input Label Length (20-14位)输入标签label的长度以字节为单位。根据协议定义合法值在11到15之间含。例如“client finished”是15字节“server write key”是14字节。Input Seed Part 1 Length (13-7位)输入种子第一部分seed的长度合法值为16或32字节。这通常对应客户端随机数ClientHello.random或服务器随机数ServerHello.random。Input Seed Part 2 Length (6-0位)输入种子第二部分seed的长度合法值为20或32字节。这通常对应另一个随机数或握手消息的哈希值。输出引用控制字的字段SGT (31位)指定指针是直接指向数据0还是指向一个散点/聚集表Scatter/Gather Table, 1。SGT允许将输出分散到多个不连续的内存块这在复杂的内存管理场景中很有用。LENGTH (23-16位)数据长度字节。行为取决于PROTINFO如果PROTINFO FFFF/FFFE此字段表示输出的主密钥或验证数据verify_data的长度。如果PROTINFO ! FFFF/FFFE即指定了TLS套件此字段被忽略。输出长度由PROTINFO所指示的加密套件决定。3.3 配置示例与流程假设我们要为一个TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256套件的连接派生密钥且主密钥已加密存储在外部DDR内存中。构建PDB设置IEKT0AES-ECB-256解密输入。设置IEOV0输入是密文。设置OEKT1AES-CCM-256加密输出更安全。设置OEOV0加密输出密钥材料。在OPERATION命令中设置PROTINFO为该加密套件对应的值。配置输入引用Input Secret Length: 忽略因为PROTINFO非特殊值且输入是密文长度由解密后决定但硬件知道是48字节。Input Label Length: 根据派生阶段设置如扩展主密钥时是“key expansion”。Input Seed Part 1/2 Length: 设置为客户端和服务器随机数的长度各32字节。配置6个输出引用分别对应client write key,server write key,client write IV,server write IV。注意AES-GCM套件无MAC密钥SEC会自动跳过对应的引用。为每个输出引用设置LENGTH此处被忽略但需预留空间、SGT并指向准备好的输出缓冲区或SGT。驱动执行将构建好的PDB和OPERATION命令提交给SEC的描述符控制器。SEC会依次执行解密输入主密钥 - 拼接label和seed - 执行PRF迭代计算 - 按指定长度分割输出 - 使用KEK加密敏感密钥材料 - 将结果写入各个输出目的地。软件后处理软件从输出缓冲区获取加密后的会话密钥材料。这些材料在用于加解密操作前可能需要先加载回SEC的内部密钥寄存器这通常由后续的对称加解密描述符自动完成使用相同的KEK解密。4. 派生密钥协议DKP的深度解析与应用除了PRFSEC还提供了一个极为重要的辅助协议派生密钥协议Derived Key Protocol, DKP。它的主要目的不是生成新密钥而是对现有密钥进行格式转换以适配硬件加速器的内部处理格式从而获得巨大的性能提升。4.1 DKP的核心价值HMAC Split KeyDKP最典型的应用是生成HMAC的“分裂密钥”Split Key也称为IPAD/OPAD格式。在HMAC算法中密钥K会与两个固定的填充常量ipad和opad进行异或生成K_ipad和K_opad然后才参与哈希运算。在软件实现中这一步通常在每次HMAC计算时动态完成。SEC的MDHA消息摘要硬件加速器模块在设计上可以直接接受这种预计算好的K_ipad和K_opad作为输入从而跳过异或步骤直接开始哈希压缩。DKP的作用正是将原始的、协商好的HMAC密钥Negotiated Key一次性计算并转换成(K_ipad, K_opad)对即“分裂密钥”。性能优势对于IPsec、TLS等需要处理大量小数据包认证的场景每个数据包的HMAC计算如果都从原始密钥开始做异或会引入不必要的开销。通过DKP预计算并存储分裂密钥后续的每一个HMAC操作都节省了这一步在高速网络处理中累积的性能收益非常显著。4.2 DKP的工作机制与描述符内替换DKP的设计非常巧妙它支持“就地”in-place替换。这意味着你可以在一个描述符Descriptor即SEC的指令序列中直接完成密钥转换和后续的加密/认证操作。工作流程如下在描述符中你首先放置一个DKP操作命令OPERATION Command。在该命令之后你提供原始的、协商好的HMAC密钥可能是明文也可能是特定格式的密文。DKP命令执行它读取原始密钥计算其分裂密钥形式。关键步骤DKP硬件不仅计算分裂密钥还会动态修改你提交的描述符。它会将描述符中的DKP操作命令本身替换成一个标准的KEY命令。同时它将描述符中提供的原始密钥数据替换成刚刚计算好的分裂密钥。分裂密钥会被写入SEC的Class 2密钥寄存器供紧随其后的MDHA命令例如用于计算IPsec的AH/ESP认证数据直接使用。描述符继续执行此时它“看到”的已经是一个标准的KEY命令和可用的分裂密钥了。这种“描述符内替换”机制使得软件可以编写一个统一的、包含密钥协商和数据处理流程的描述符。DKP在运行时自动完成密钥格式的适配无需软件中断处理或额外的内存拷贝实现了极高的流水线效率和简洁的编程模型。警告描述符作者必须确保DKP操作输出的分裂密钥数据不会覆盖描述符中后续需要保留的命令或数据。这需要仔细计算描述符的内存布局。通常的做法是在原始密钥数据后预留足够的空间分裂密钥的长度是原始密钥的两倍见下文表4-1或者使用分散/聚集表SGT来管理输出。4.3 DKP的输入/输出源与长度DKP操作命令中的PROTINFO字段的I/O控制子域bits 16-19被分为两部分分别指定输入源和输出目的地。输入源Input Source, bits 16-1700(IMM)原始密钥紧跟在DKP命令之后。此选项只能与输出目的地00(IMM)配对使用。01(SEQ)原始密钥位于由SEQ IN PTR命令定义的输入帧中。在可信描述符Trusted Descriptor中必须使用此选项。10(PTR)原始密钥的地址指针紧跟在DKP命令之后。11(SGF)原始密钥分散在由散点/聚集表指定的多个内存位置。输出目的地Output Destination, bits 18-1900(IMM)计算出的分裂密钥将写回描述符紧挨着被替换成的KEY命令之后。这会覆盖该位置原有的数据。01(SEQ)分裂密钥写入由SEQ OUT PTR命令定义的输出帧。仅当输入源也是SEQ时才有效且是可信描述符的必须选择。10(PTR)分裂密钥写入DKP命令后指定的地址指针处。不能与输入源IMM或SGF共用。11(SGF)分裂密钥根据DKP命令后的散点/聚集表写入内存。不能与输入源IMM或PTR共用。分裂密钥长度派生出的分裂密钥长度取决于底层哈希算法是固定的与原始密钥长度无关。表 4-1: HMAC派生密钥分裂密钥长度哈希算法派生“分裂”密钥长度对应字数32位系统MD532 字节8 字SHA-140 字节10 字SHA-224 / SHA-25664 字节16 字SHA-384 / SHA-512128 字节32 字例如如果你有一个20字节的原始SHA-256 HMAC密钥经过DKP处理后你会得到一个64字节的数据块其中前32字节是K_ipad后32字节是K_opad。后续的MDHA命令在配置为HMAC-SHA256时会期望从这个64字节的缓冲区中读取密钥。5. 硬件加速器协同工作与安全考量SEC不是一个单一的模块而是由多个密码学硬件加速器CHA协同工作的综合体。理解PRF和DKP如何与其他CHA交互对于设计高效安全的系统至关重要。5.1 与MDHA和AESA的协作PRF MDHAPRF的核心是HMAC而HMAC的核心是哈希函数如SHA256。SEC内部的MDHA模块就是专门执行哈希运算的硬件。当PRF命令被执行时它会在内部调用MDHA来完成HMAC计算。这种调用对软件完全透明但意味着PRF的性能与MDHA的性能直接相关。PRF/DKP AESA当启用输入/输出加密时通过IEKT/OEKT配置PRF和DKP会调用AESAAES加速器来执行AES-ECB或AES-CCM算法。KEK通常存储在SEC内部受保护的密钥寄存器中。这种设计确保了密钥材料在SEC芯片边界之外即在系统内存中始终处于加密状态即使物理内存被窃取攻击者也无法直接获得明文密钥。密钥传递DKP生成的Split Key或PRF生成的会话密钥通常不会直接返回给主CPU。它们被直接写入SEC内部的Class 1或Class 2密钥寄存器。随后当描述符中的下一个命令如AESA用于加密MDHA用于认证需要密钥时它直接从这些寄存器中读取。这实现了密钥材料在安全引擎内部的“闭环”流动最大限度地减少了密钥在总线或内存中暴露的风险。5.2 安全最佳实践与常见陷阱密钥生命周期管理预主密钥应在安全环境如TEE中生成或通过PKHA公钥硬件加速器计算得到。进入SEC参与PRF计算前应始终以加密形式IEOV0提供。主密钥PRF扩展出的48字节主密钥是会话安全的根。如果不需要存储应尽快使用并让SEC在内部销毁。如果需要存储例如用于会话恢复必须使用OEKT加密后输出。会话密钥PRF派生的最终加密密钥和MAC密钥必须设置为加密输出OEOV0。IV可以明文输出。KEK管理用于加密输入/输出密钥的KEK是更高层级的秘密。它应由安全的随机源生成并存储在SEC的受保护密钥寄存器或硬件安全模块HSM中绝不能出现在普通内存中。防侧信道攻击SEC的PKHA模块在执行模幂运算等公钥操作时支持时序均衡化timing-equalized模式以抵御时序攻击。在配置ECC或RSA操作时应优先启用此功能。虽然PRF和DKP本身是确定性的但确保其输入随机数的熵值足够高是防御各类密码分析攻击的前提。配置错误排查PRF输出长度异常检查PROTINFO字段是否与预期的加密套件匹配。如果PROTINFO设置为FFFF但期望输出多个密钥会导致错误因为此时SEC期望的是单一输出如主密钥或Finished验证数据。DKP描述符崩溃最常见的原因是分裂密钥的输出覆盖了描述符后续的指令。务必精确计算IMM输出模式下的内存偏移。使用PTR或SGF模式将输出指向独立的缓冲区是更安全的选择。性能未达预期如果PRF计算慢检查输入的secret长度是否超过了HMAC密钥限制64/128字节导致SEC内部触发了预处理哈希。尽量使用标准长度的密钥。与Blob协议的结合SEC还支持Blob协议用于跨芯片上下电周期加密保护用户数据。虽然本文未深入展开但它的思想与PRF的输出加密一脉相承使用一个非易失性主密钥派生出临时密钥来加密数据。在需要持久化加密密钥或敏感配置的场景可以将PRF输出的、经KEK加密的会话密钥再用Blob协议封装一次后存储到Flash中实现双层保护。6. 总结与实战心得将TLS 1.2的密钥派生工作卸载到NXP QorIQ SEC硬件引擎远不止是获得计算性能的提升。它更是一种系统级的安全架构升级。通过深入理解PRF PDB的每个比特位、DKP的原地替换机制以及各CHA间的协同开发者能够设计出既高效又健壮的网络安全应用。从我多年的嵌入式安全开发经验来看成功集成此类硬件加速器关键在于转变思维从“调用一个库函数”转变为“编排一个安全的数据处理流水线”。你需要像设计硬件电路一样思考描述符的编排确保密钥的生成、转换、使用、销毁都在硬件的安全边界内完成软件只负责触发和提供必要的参数。一个实用的建议是在项目初期就构建一个完备的测试向量套件。不仅包括标准RFC的测试向量还应模拟各种边界情况超长的预主密钥触发预处理、使用AES-GCM套件验证MAC密钥被跳过、配置错误的输出长度等。硬件行为有时比软件更“固执”清晰的文档和充分的测试是避免后期调试噩梦的最佳良药。最后永远不要忽视那个最简单的选项——OEOV。除非有极其特殊的调试需求否则永远将其设置为0加密输出。让密钥在离开安全引擎的瞬间就被锁进“保险箱”这是利用此类硬件所能获得的最基本、也最重要的安全收益。
设计：跨平台开发与裸机到RTOS平滑迁移)
