1. 项目概述与核心价值在移动通信网络里数据从你的手机出发经过基站、核心网最终到达互联网上的服务器这中间要穿越一段不设防的“空中走廊”——无线空口。这段路谁都能“听”到数据裸奔是绝对不行的。因此3GUMTS和4GLTE标准都定义了一套严密的“装甲”铸造与拆卸流程这就是协议数据单元PDU的封装与解封装。简单说封装就是给原始数据PDU载荷穿上加密和完整性保护的“装甲”解封装就是验证并卸下这层“装甲”还原出原始数据。这不仅是简单的加密解密更是一套与通信协议状态如序列号、承载信道深度绑定的动态安全机制。其核心价值在于它为高速移动数据业务提供了“无感”的安全保障。你在刷视频、传文件时感觉不到任何卡顿或延迟背后正是像NXP QorIQ LS1046A内部的安全引擎SEC这类硬件加速模块在默默承担着繁重的加解密运算。它们将标准化的安全流程固化在硬件中通过协议描述块PDB进行灵活配置实现了线速处理既保证了安全又丝毫不影响用户体验。本文将深入这套机制的内部拆解从配置、初始化向量IV构建到数据处理的完整链条让你不仅知道通信是安全的更明白它是如何安全起来的。2. 安全机制核心从算法到协议描述块PDB在深入流程之前必须理解构成这套安全体系的几个核心部件。它们就像乐高积木共同搭建起完整的保护墙。2.1 加密与完整性保护算法选型3GPP标准为不同网络和场景指定了特定的算法套件SEC等硬件引擎则是对这些标准的高效实现。对于3G RLC层用户面机密性算法UEA1 (Kasumi-f8)基于Kasumi分组密码的流加密模式。这是3G时代的核心算法在硬件中实现效率极高。UEA2 (SNOW-3G-f8)基于SNOW-3G流密码的加密模式。相比Kasumi它被视为更现代、强度可能更高的选择。UEA0即空算法NULL用于测试或不需加密的场景数据明文传输。完整性保护在3G中RLC层仅提供机密性完整性保护由更高层的RRC协议负责。因此3G RLC PDU处理不涉及完整性校验值ICV/MAC-I的计算与验证。对于LTE PDCP层 LTE将安全功能上移至PDCP层并可根据需求同时或单独启用机密性与完整性保护。机密性算法EEA128-EEA1 (SNOW-3G)流密码加密。128-EEA2 (AES-CTR)基于高级加密标准AES的计数器模式。这是目前全球最主流、最受信任的对称加密算法。128-EEA3 (ZUC)我国自主设计的流密码算法已成为3GPP标准。128-EEA0空加密算法。完整性算法EIA128-EIA1 (SNOW-3G)基于SNOW-3G的完整性算法。128-EIA2 (AES-CMAC)基于AES的Cipher-based Message Authentication Code模式。128-EIA3 (ZUC)基于ZUC的完整性算法。128-EIA0空完整性算法。注意在LTE中当需要完整性保护时如控制面信令或中继节点用户面机密性算法和完整性算法可以独立选择。例如完全可以使用AES-CTREEA2进行加密同时使用SNOW-3GEIA1进行完整性保护。这种解耦设计提供了更大的灵活性。2.2 协议描述块PDB硬件加速的“配方单”PDB是驱动SEC硬件执行特定协议处理的核心数据结构。它不是一个需要开发者手动解析的复杂文件而是一组由驱动或库填充、硬件直接读取的寄存器或内存块。理解PDB的字段就理解了硬件工作的前提条件。一个典型的3G RLC或LTE PDCP PDB通常包含以下关键字段超帧号HFN一个长计数器的高位部分。由于无线帧序列号SN长度有限如5、7、12、15比特会循环重复。HFN在SN回滚时递增与SN拼接形成全局唯一的COUNT值。这是保证每次加密密钥流不同的关键。承载标识Bearer与方向DirBearer标识特定的数据无线承载DRB或信令无线承载SRBDir指示上行UE到网络或下行网络到UE。它们确保不同信道、不同方向的数据使用不同的密钥流。序列号大小SNS指示PDU头部中SN的长度决定了如何解析头部。例如SNS01b表示7比特SN3G非确认模式SNS00b表示12比特SN3G确认模式或LTE用户面一种模式。可选移位optShift一个硬件处理对齐的优化位。当置1时输出帧会在PDU前添加4比特来自PDB的Lead Nibble字段并在PDU后填充4比特零。这通常用于满足某些DMA或总线传输的字节对齐要求。阈值Threshold一个预警机制。当HFN增长到等于或超过此阈值时硬件会在处理完成后返回一个警告标志提示上层协议“密钥需要尽快重新协商了”。这是防止COUNT值重复导致安全弱化的前摄性措施。算法保留字段CA CE一些为特定算法如SNOW-3G、ZUC保留的常量或配置位用于构建特定的初始化向量IV。2.3 初始化向量IV的构建安全的“随机种子”对称加密尤其是流密码和计数器模式的安全性严重依赖于每次加密使用的IV不重复。在移动通信中IV不是随机数而是由COUNT、Bearer、Dir等参数确定性生成的。只要通信双方同步这些状态参数就能生成相同的IV从而解密数据。IV构建的通用逻辑IV f(COUNT, Bearer, Dir, [算法特定常量])其中COUNT (HFN SN位宽) | SN不同算法的IV构造差异以LTE为例SNOW-3G (EEA1/EIA1)机密性IV[COUNT (32位) | Bearer (5位) | Dir (1位) | 0 (26位)]共64位。完整性IV[COUNT (32位) | 0 (5位) | Bearer (5位) | Dir (1位) | 0 (27位)]共96位。注意Bearer的位置发生了变化。AES-CTR (EEA2)机密性IVCTR0[COUNT (32位) | Bearer (5位) | Dir (1位) | 0 (90位)]共128位构成一个完整的AES块。完整性“IV”用于EIA2的AES-CMAC实际上作为附加认证数据AAD的第一块输入其格式与SNOW-3G的机密性IV相同64位。ZUC (EEA3/EIA3)机密性IV直接将SNOW-3G的64位机密性IV重复一次构成128位。完整性IV构造更为复杂涉及对HFN部分与方向位Dir进行异或操作和位移确保其与机密性IV不同。实操心得IV的构造是协议实现中最容易出错的地方之一。务必严格按照标准文档如3GPP 33.401和硬件手册的位域图进行拼接。一个比特的错误会导致收发双方IV不同加解密完全失败。在调试初期建议将生成的IV值打印出来与标准测试向量或对端实现进行比对。3. 3G RLC PDU封装与解封装全流程解析3G RLC层的安全处理相对单纯仅聚焦于用户面数据的机密性保护。我们以封装加密发送和解封装解密接收两个角度拆解。3.1 3G RLC PDU封装加密发送流程假设SEC硬件已配置好PDB并收到了一个待处理的RLC PDU输入帧。提取与更新COUNT硬件首先根据PDB中SNS位的配置从输入帧的PDU头部解析出序列号SN。将SN与PDB中维护的超帧号HFN拼接形成完整COUNT值。关键操作检查SN是否从全1回滚到0。如果是则将PDB中的HFN值加1并写回存储如内存中的PDB副本。这个“写回”动作至关重要它保证了同一数据流中HFN的单调递增。阈值检查与预警无论HFN是否递增硬件都会将其与PDB中的Threshold字段比较。若HFN Threshold则在本次帧处理完成后硬件会置位一个状态标志或产生中断向上层软件发出“密钥需要重新协商”的预警。构建初始化向量IV硬件按照f8算法Kasumi或SNOW-3G的流加密模式的要求构建IV。IV的组成IV [HFN | Bearer Dir (来自PDB) | SN]。注意PDU头部本身不参与加密但其SN是IV的一部分。执行加密将构建好的IV写入加密引擎如KFHA或SNOW-3G-f8的上下文寄存器。将输入帧中的PDU载荷部分送入加密引擎的输入FIFO。加密引擎使用预加载的密钥Ciphering Key, CK和IV生成密钥流与明文载荷进行异或产生密文载荷。组装输出帧将未加密的PDU头部原样复制到输出帧。将加密后的密文载荷附加在头部之后。如果PDB中optShift位为1则在输出帧的头部前插入4比特Lead Nibble在载荷后填充4比特零以满足对齐要求。3.2 3G RLC PDU解封装解密接收流程解封装是封装的逆过程但包含对数据顺序的依赖。提取COUNT与封装过程相同根据SN和HFN生成COUNT。更新HFN同样检测SN回滚并递增PDB中的HFN。这里有一个重要限制硬件设计通常不支持HFN回退。这意味着接收端必须按序提交PDU给SEC处理。如果后一个PDU先到其SN回滚会错误地递增HFN导致之后到来的、真正序号更大的PDU无法正确解密。这通常由上层驱动或协议栈保证。阈值检查与封装相同。构建IV使用与发送端完全相同的逻辑构建IV。这就要求收发双方的PDB配置HFN初始值、Bearer、Dir必须同步。执行解密将IV写入解密引擎上下文寄存器。将输入帧中的密文载荷送入引擎。引擎使用相同的CK和IV生成相同的密钥流与密文异或恢复出明文载荷。组装输出帧将PDU头部和明文载荷输出。3.3 PDB覆盖PDB Override机制这是一个高级且实用的功能。通常一个数据流如一个QoS承载的所有PDU共享同一个PDB。但某些特殊场景下需要对某个特定PDU使用不同的HFN。SEC通过DPOVRD寄存器支持此功能。操作方式在提交给SEC的作业描述符Job Descriptor中包含一条“立即加载”指令将新的HFN值写入DPOVRD寄存器并设置其覆盖位OVRD。硬件行为当SEC处理该作业时会优先使用DPOVRD寄存器中的HFN值而不是PDB中存储的值。处理完成后PDB中的HFN值不会被这次覆盖操作所修改。应用场景处理乱序到达的PDU需小心计算正确的覆盖值、测试、或特定的协议交互场景。注意事项滥用PDB覆盖可能导致状态不同步。务必确保覆盖逻辑的正确性并且理解覆盖仅对当前作业生效。对于按序处理的主流场景应依赖PDB自身的HFN维护机制。4. LTE PDCP PDU封装与解封装深度剖析LTE PDCP的安全处理更为复杂和全面支持机密性与完整性的组合。我们分场景讨论。4.1 仅机密性保护用户面典型场景这是最常见的用户数据传输场景流程与3G RLC封装高度相似主要区别在于算法和IV构造。COUNT构建与HFN管理与3.1节流程完全一致。构建算法特定的IV根据PDB配置的算法EEA1/2/3按照第2.3节描述的格式构建机密性IV。例如若使用AES-CTREEA2则构建128位的CTR0。加密与输出将IV写入Class 1上下文寄存器对应机密性引擎。复制PDU头部到输出帧。将PDU载荷用指定算法加密密文输出。4.2 机密性与完整性双重保护控制面及中继节点用户面这是信令或高安全需求数据的处理场景流程最为复杂。核心在于先完整性计算再加密且完整性校验值MAC-I本身也被加密。封装发送端流程参数提取从输入帧提取SN与PDB中的HFN形成COUNT。双IV构建根据算法分别构建用于机密性的IV写入Class 1上下文寄存器和用于完整性的IV或AAD写入Class 2上下文寄存器。例如对于EEA2EIA2组合会构建一个AES-CTR模式的IV和一个作为AES-CMAC AAD的输入块。并行/流水处理PDU头部被写入输出帧同时也作为消息的一部分送入完整性Class 2引擎。PDU载荷被送入两个引擎在Class 1机密性引擎被加密。在Class 2完整性引擎作为计算消息认证码MAC的数据的一部分。加密后的载荷被写入输出帧。生成并加密MAC-I完整性引擎计算出一个4字节的MAC-I值。这个明文MAC-I被传递给机密性引擎进行加密。最终输出输出帧由[PDU头] [加密后的载荷] [加密后的MAC-I]组成。解封装接收端流程接收端需要验证完整性并解密顺序与发送端相反。参数提取与双IV构建与发送端相同。分离数据输入帧包含[PDU头] [加密的载荷] [加密的MAC-I (记为XMAC-I)]。解密与验证PDU头部被送入完整性引擎。加密的载荷被Class 1引擎解密解密后的明文载荷同时被送入完整性引擎。接收到的XMAC-I被送入完整性引擎作为比对值。完整性校验完整性引擎基于收到的头部、解密后的载荷重新计算出一个MAC-I值。硬件将计算出的MAC-I与接收到的XMAC-I需注意比较的是解密后的XMAC-I不这里有个关键点接收到的XMAC-I是加密过的而计算出的MAC-I是明文的。实际上硬件内部会先解密XMAC-I或者更常见的流程是将计算出的明文MAC-I与解密XMAC-I后的结果进行比较进行比对。结果判定如果两者一致验证通过输出明文载荷和头部。如果不一致硬件会返回一个完整性校验失败的错误该PDU会被丢弃。关键点澄清在LTE标准中MAC-I在发送端是先计算后加密。因此接收端收到的XMAC-I是加密后的值。在解密流程中SEC硬件内部的处理顺序是先解密载荷和加密的MAC-I然后用解密后的明文载荷和头部去计算MAC-I最后将计算出的MAC-I与解密得到的MAC-I进行比对。手册中的图表Figure 9-108展示了ICVr接收到的ICV与ICVc计算出的ICV的比较隐含了接收端对ICVr的解密步骤。4.3 LTE PDCP PDB的序列号适配LTE PDCP PDB的Word 1格式会根据序列号长度5, 7, 12, 15比特动态变化主要是HFN字段的位宽不同分别为27, 25, 20, 17比特。这是因为COUNT的总长度固定为32比特SN占用的比特数越多HFN占用的比特数就越少。硬件根据SNS字段自动选择正确的解释格式。SNS 值序列号长度适用场景HFN位宽COUNT构成 (HFN:SN)00b12-bitLTE用户面 (一种模式)20 bits20:1201b7-bitLTE用户面 (另一种模式)25 bits25:710b15-bitLTE用户面 (扩展模式)17 bits17:15(隐含)5-bitLTE控制面(C-Plane)27 bits27:5实操心得在配置PDB时必须根据协议栈给出的序列号长度准确设置SNS字段。配置错误会导致HFN字段错位进而使构建的COUNT完全错误加解密必然失败。控制面5比特SN的SNS在PDB中通常有特殊处理或忽略需参考具体芯片手册。5. 常见问题、调试技巧与实战经验在实际开发和调试中仅仅理解流程还不够会遇到各种棘手问题。以下是一些常见坑点与解决思路。5.1 加解密失败问题排查清单当数据无法正确加解密时可以按照以下顺序进行排查密钥检查确认加载到SEC硬件密钥寄存器或密钥内存中的Ciphering Key (CK)和Integrity Key (IK)是否正确。确认密钥是否与算法匹配如AES-128密钥为16字节。确认密钥是否在有效期内是否已同步更新。PDB配置检查Bearer ID和Direction确认收发双方是否一致。上行和下行、不同承载的密钥流是不同的。HFN初始值这是最常见的错误来源。确保收发双方的HFN在连接建立时同步并且在后续通信中通过RRC信令正确同步如切换过程。SNS字段确认与PDU头部实际的序列号长度匹配。算法标识在作业描述符中指定的算法套件如PROTOPDCP_C_ENC对应控制面加密是否与PDB及密钥匹配。COUNT同步与HFN管理乱序问题确认是否提交了乱序的PDU给SEC解密。对于不支持HFN回退的硬件乱序会导致状态不同步。需要在驱动层实现排序缓冲区。HFN更新逻辑检查HFN在SN回滚时的递增逻辑是否正确实现。是否在每次递增后都正确写回了PDB存储区Threshold预警是否处理了硬件返回的阈值警告忽略它可能导致COUNT循环复用严重威胁安全。数据与格式问题PDU头部格式确认输入的PDU头部格式是否符合预期1字节还是2字节各比特位定义。数据对齐检查optShift位的设置。如果硬件要求4比特对齐而数据未按此准备会导致处理错误。输入/输出长度确认输入帧的长度描述符是否正确特别是包含MAC-I时。5.2 性能优化要点批量处理尽量将多个PDU组合成一个大的作业提交给SEC减少硬件上下文切换和软件中断的开销。描述符链预构建对于稳定的数据流可以预构建并缓存整个作业描述符链包括PDB仅在实际处理时更新变化的部分如SN所在的PDU头部。避免内存拷贝利用SEC的分散-聚集Scatter-GatherDMA能力直接描述输入/输出数据在内存中的位置避免不必要的内存拷贝。阈值合理设置根据业务模型和密钥更新策略设置合理的Threshold值。设置过小会导致频繁预警增加软件开销设置过大则有安全风险。5.3 跨算法移植注意事项当需要从一种算法如SNOW-3G切换到另一种如AES-CTR或ZUC时除了更换算法标识和密钥必须重点关注IV构造函数的改变这是必须修改的。不同算法的IV格式、长度、位域排列完全不同。密钥长度与格式虽然都是128位但加载到硬件寄存器的格式可能因算法而异。完整性验证的区别EIA2AES-CMAC没有传统IV其AAD的构造方式特殊。EIA3ZUC的IV构造也独树一帜。硬件引擎支持确认目标SEC硬件是否支持该算法。例如较老的硬件可能不支持ZUC。5.4 调试辅助手段寄存器与内存快照在加解密前后 dump SEC相关的上下文寄存器、PDB内存区域、输入输出数据缓冲区。对比发送和接收两端的数据。使用测试向量3GPP和算法标准文档提供了丰富的测试向量。用已知的密钥、COUNT、Bearer、Dir、明文和密文在隔离环境中测试SEC的配置这是验证硬件配置正确性的黄金标准。分步验证先关闭加密使用空算法EEA0/EIA0验证数据通路和PDB配置是否正确。再启用加密但使用简单的测试数据最后使用真实业务数据。日志记录在驱动层详细记录每次提交作业的HFN、SN、Bearer、算法等参数。当出现问题时这些日志是回溯状态同步情况的无价之宝。理解3G和LTE的PDU加解密与完整性保护不仅仅是读懂一份芯片手册。它要求开发者具备系统性的视角将通信协议的状态机、密码学的算法原理、以及硬件加速器的微架构特性融合贯通。从正确的PDB配置到精准的IV构建再到严谨的HFN状态管理每一个环节的失误都可能导致整个安全链条的断裂。在实际工作中我最大的体会是“状态即一切”。确保收发两端每一个比特的状态信息HFN, SN, Bearer, Dir严格同步是比选择何种加密算法更为基础、也更容易出错的关键。这份手册提供的硬件加速细节正是将这套复杂状态机安全、高效落地的基石。当你下次拿起手机享受高速网络时或许可以想到在芯片的深处正有无数个这样的硬件引擎按照我们刚才剖析的精密流程无声地守护着每一个数据比特的旅程。
3G/4G PDU安全封装与硬件加速：从算法原理到NXP SEC实践
发布时间：2026/6/13 13:29:11
1. 项目概述与核心价值在移动通信网络里数据从你的手机出发经过基站、核心网最终到达互联网上的服务器这中间要穿越一段不设防的“空中走廊”——无线空口。这段路谁都能“听”到数据裸奔是绝对不行的。因此3GUMTS和4GLTE标准都定义了一套严密的“装甲”铸造与拆卸流程这就是协议数据单元PDU的封装与解封装。简单说封装就是给原始数据PDU载荷穿上加密和完整性保护的“装甲”解封装就是验证并卸下这层“装甲”还原出原始数据。这不仅是简单的加密解密更是一套与通信协议状态如序列号、承载信道深度绑定的动态安全机制。其核心价值在于它为高速移动数据业务提供了“无感”的安全保障。你在刷视频、传文件时感觉不到任何卡顿或延迟背后正是像NXP QorIQ LS1046A内部的安全引擎SEC这类硬件加速模块在默默承担着繁重的加解密运算。它们将标准化的安全流程固化在硬件中通过协议描述块PDB进行灵活配置实现了线速处理既保证了安全又丝毫不影响用户体验。本文将深入这套机制的内部拆解从配置、初始化向量IV构建到数据处理的完整链条让你不仅知道通信是安全的更明白它是如何安全起来的。2. 安全机制核心从算法到协议描述块PDB在深入流程之前必须理解构成这套安全体系的几个核心部件。它们就像乐高积木共同搭建起完整的保护墙。2.1 加密与完整性保护算法选型3GPP标准为不同网络和场景指定了特定的算法套件SEC等硬件引擎则是对这些标准的高效实现。对于3G RLC层用户面机密性算法UEA1 (Kasumi-f8)基于Kasumi分组密码的流加密模式。这是3G时代的核心算法在硬件中实现效率极高。UEA2 (SNOW-3G-f8)基于SNOW-3G流密码的加密模式。相比Kasumi它被视为更现代、强度可能更高的选择。UEA0即空算法NULL用于测试或不需加密的场景数据明文传输。完整性保护在3G中RLC层仅提供机密性完整性保护由更高层的RRC协议负责。因此3G RLC PDU处理不涉及完整性校验值ICV/MAC-I的计算与验证。对于LTE PDCP层 LTE将安全功能上移至PDCP层并可根据需求同时或单独启用机密性与完整性保护。机密性算法EEA128-EEA1 (SNOW-3G)流密码加密。128-EEA2 (AES-CTR)基于高级加密标准AES的计数器模式。这是目前全球最主流、最受信任的对称加密算法。128-EEA3 (ZUC)我国自主设计的流密码算法已成为3GPP标准。128-EEA0空加密算法。完整性算法EIA128-EIA1 (SNOW-3G)基于SNOW-3G的完整性算法。128-EIA2 (AES-CMAC)基于AES的Cipher-based Message Authentication Code模式。128-EIA3 (ZUC)基于ZUC的完整性算法。128-EIA0空完整性算法。注意在LTE中当需要完整性保护时如控制面信令或中继节点用户面机密性算法和完整性算法可以独立选择。例如完全可以使用AES-CTREEA2进行加密同时使用SNOW-3GEIA1进行完整性保护。这种解耦设计提供了更大的灵活性。2.2 协议描述块PDB硬件加速的“配方单”PDB是驱动SEC硬件执行特定协议处理的核心数据结构。它不是一个需要开发者手动解析的复杂文件而是一组由驱动或库填充、硬件直接读取的寄存器或内存块。理解PDB的字段就理解了硬件工作的前提条件。一个典型的3G RLC或LTE PDCP PDB通常包含以下关键字段超帧号HFN一个长计数器的高位部分。由于无线帧序列号SN长度有限如5、7、12、15比特会循环重复。HFN在SN回滚时递增与SN拼接形成全局唯一的COUNT值。这是保证每次加密密钥流不同的关键。承载标识Bearer与方向DirBearer标识特定的数据无线承载DRB或信令无线承载SRBDir指示上行UE到网络或下行网络到UE。它们确保不同信道、不同方向的数据使用不同的密钥流。序列号大小SNS指示PDU头部中SN的长度决定了如何解析头部。例如SNS01b表示7比特SN3G非确认模式SNS00b表示12比特SN3G确认模式或LTE用户面一种模式。可选移位optShift一个硬件处理对齐的优化位。当置1时输出帧会在PDU前添加4比特来自PDB的Lead Nibble字段并在PDU后填充4比特零。这通常用于满足某些DMA或总线传输的字节对齐要求。阈值Threshold一个预警机制。当HFN增长到等于或超过此阈值时硬件会在处理完成后返回一个警告标志提示上层协议“密钥需要尽快重新协商了”。这是防止COUNT值重复导致安全弱化的前摄性措施。算法保留字段CA CE一些为特定算法如SNOW-3G、ZUC保留的常量或配置位用于构建特定的初始化向量IV。2.3 初始化向量IV的构建安全的“随机种子”对称加密尤其是流密码和计数器模式的安全性严重依赖于每次加密使用的IV不重复。在移动通信中IV不是随机数而是由COUNT、Bearer、Dir等参数确定性生成的。只要通信双方同步这些状态参数就能生成相同的IV从而解密数据。IV构建的通用逻辑IV f(COUNT, Bearer, Dir, [算法特定常量])其中COUNT (HFN SN位宽) | SN不同算法的IV构造差异以LTE为例SNOW-3G (EEA1/EIA1)机密性IV[COUNT (32位) | Bearer (5位) | Dir (1位) | 0 (26位)]共64位。完整性IV[COUNT (32位) | 0 (5位) | Bearer (5位) | Dir (1位) | 0 (27位)]共96位。注意Bearer的位置发生了变化。AES-CTR (EEA2)机密性IVCTR0[COUNT (32位) | Bearer (5位) | Dir (1位) | 0 (90位)]共128位构成一个完整的AES块。完整性“IV”用于EIA2的AES-CMAC实际上作为附加认证数据AAD的第一块输入其格式与SNOW-3G的机密性IV相同64位。ZUC (EEA3/EIA3)机密性IV直接将SNOW-3G的64位机密性IV重复一次构成128位。完整性IV构造更为复杂涉及对HFN部分与方向位Dir进行异或操作和位移确保其与机密性IV不同。实操心得IV的构造是协议实现中最容易出错的地方之一。务必严格按照标准文档如3GPP 33.401和硬件手册的位域图进行拼接。一个比特的错误会导致收发双方IV不同加解密完全失败。在调试初期建议将生成的IV值打印出来与标准测试向量或对端实现进行比对。3. 3G RLC PDU封装与解封装全流程解析3G RLC层的安全处理相对单纯仅聚焦于用户面数据的机密性保护。我们以封装加密发送和解封装解密接收两个角度拆解。3.1 3G RLC PDU封装加密发送流程假设SEC硬件已配置好PDB并收到了一个待处理的RLC PDU输入帧。提取与更新COUNT硬件首先根据PDB中SNS位的配置从输入帧的PDU头部解析出序列号SN。将SN与PDB中维护的超帧号HFN拼接形成完整COUNT值。关键操作检查SN是否从全1回滚到0。如果是则将PDB中的HFN值加1并写回存储如内存中的PDB副本。这个“写回”动作至关重要它保证了同一数据流中HFN的单调递增。阈值检查与预警无论HFN是否递增硬件都会将其与PDB中的Threshold字段比较。若HFN Threshold则在本次帧处理完成后硬件会置位一个状态标志或产生中断向上层软件发出“密钥需要重新协商”的预警。构建初始化向量IV硬件按照f8算法Kasumi或SNOW-3G的流加密模式的要求构建IV。IV的组成IV [HFN | Bearer Dir (来自PDB) | SN]。注意PDU头部本身不参与加密但其SN是IV的一部分。执行加密将构建好的IV写入加密引擎如KFHA或SNOW-3G-f8的上下文寄存器。将输入帧中的PDU载荷部分送入加密引擎的输入FIFO。加密引擎使用预加载的密钥Ciphering Key, CK和IV生成密钥流与明文载荷进行异或产生密文载荷。组装输出帧将未加密的PDU头部原样复制到输出帧。将加密后的密文载荷附加在头部之后。如果PDB中optShift位为1则在输出帧的头部前插入4比特Lead Nibble在载荷后填充4比特零以满足对齐要求。3.2 3G RLC PDU解封装解密接收流程解封装是封装的逆过程但包含对数据顺序的依赖。提取COUNT与封装过程相同根据SN和HFN生成COUNT。更新HFN同样检测SN回滚并递增PDB中的HFN。这里有一个重要限制硬件设计通常不支持HFN回退。这意味着接收端必须按序提交PDU给SEC处理。如果后一个PDU先到其SN回滚会错误地递增HFN导致之后到来的、真正序号更大的PDU无法正确解密。这通常由上层驱动或协议栈保证。阈值检查与封装相同。构建IV使用与发送端完全相同的逻辑构建IV。这就要求收发双方的PDB配置HFN初始值、Bearer、Dir必须同步。执行解密将IV写入解密引擎上下文寄存器。将输入帧中的密文载荷送入引擎。引擎使用相同的CK和IV生成相同的密钥流与密文异或恢复出明文载荷。组装输出帧将PDU头部和明文载荷输出。3.3 PDB覆盖PDB Override机制这是一个高级且实用的功能。通常一个数据流如一个QoS承载的所有PDU共享同一个PDB。但某些特殊场景下需要对某个特定PDU使用不同的HFN。SEC通过DPOVRD寄存器支持此功能。操作方式在提交给SEC的作业描述符Job Descriptor中包含一条“立即加载”指令将新的HFN值写入DPOVRD寄存器并设置其覆盖位OVRD。硬件行为当SEC处理该作业时会优先使用DPOVRD寄存器中的HFN值而不是PDB中存储的值。处理完成后PDB中的HFN值不会被这次覆盖操作所修改。应用场景处理乱序到达的PDU需小心计算正确的覆盖值、测试、或特定的协议交互场景。注意事项滥用PDB覆盖可能导致状态不同步。务必确保覆盖逻辑的正确性并且理解覆盖仅对当前作业生效。对于按序处理的主流场景应依赖PDB自身的HFN维护机制。4. LTE PDCP PDU封装与解封装深度剖析LTE PDCP的安全处理更为复杂和全面支持机密性与完整性的组合。我们分场景讨论。4.1 仅机密性保护用户面典型场景这是最常见的用户数据传输场景流程与3G RLC封装高度相似主要区别在于算法和IV构造。COUNT构建与HFN管理与3.1节流程完全一致。构建算法特定的IV根据PDB配置的算法EEA1/2/3按照第2.3节描述的格式构建机密性IV。例如若使用AES-CTREEA2则构建128位的CTR0。加密与输出将IV写入Class 1上下文寄存器对应机密性引擎。复制PDU头部到输出帧。将PDU载荷用指定算法加密密文输出。4.2 机密性与完整性双重保护控制面及中继节点用户面这是信令或高安全需求数据的处理场景流程最为复杂。核心在于先完整性计算再加密且完整性校验值MAC-I本身也被加密。封装发送端流程参数提取从输入帧提取SN与PDB中的HFN形成COUNT。双IV构建根据算法分别构建用于机密性的IV写入Class 1上下文寄存器和用于完整性的IV或AAD写入Class 2上下文寄存器。例如对于EEA2EIA2组合会构建一个AES-CTR模式的IV和一个作为AES-CMAC AAD的输入块。并行/流水处理PDU头部被写入输出帧同时也作为消息的一部分送入完整性Class 2引擎。PDU载荷被送入两个引擎在Class 1机密性引擎被加密。在Class 2完整性引擎作为计算消息认证码MAC的数据的一部分。加密后的载荷被写入输出帧。生成并加密MAC-I完整性引擎计算出一个4字节的MAC-I值。这个明文MAC-I被传递给机密性引擎进行加密。最终输出输出帧由[PDU头] [加密后的载荷] [加密后的MAC-I]组成。解封装接收端流程接收端需要验证完整性并解密顺序与发送端相反。参数提取与双IV构建与发送端相同。分离数据输入帧包含[PDU头] [加密的载荷] [加密的MAC-I (记为XMAC-I)]。解密与验证PDU头部被送入完整性引擎。加密的载荷被Class 1引擎解密解密后的明文载荷同时被送入完整性引擎。接收到的XMAC-I被送入完整性引擎作为比对值。完整性校验完整性引擎基于收到的头部、解密后的载荷重新计算出一个MAC-I值。硬件将计算出的MAC-I与接收到的XMAC-I需注意比较的是解密后的XMAC-I不这里有个关键点接收到的XMAC-I是加密过的而计算出的MAC-I是明文的。实际上硬件内部会先解密XMAC-I或者更常见的流程是将计算出的明文MAC-I与解密XMAC-I后的结果进行比较进行比对。结果判定如果两者一致验证通过输出明文载荷和头部。如果不一致硬件会返回一个完整性校验失败的错误该PDU会被丢弃。关键点澄清在LTE标准中MAC-I在发送端是先计算后加密。因此接收端收到的XMAC-I是加密后的值。在解密流程中SEC硬件内部的处理顺序是先解密载荷和加密的MAC-I然后用解密后的明文载荷和头部去计算MAC-I最后将计算出的MAC-I与解密得到的MAC-I进行比对。手册中的图表Figure 9-108展示了ICVr接收到的ICV与ICVc计算出的ICV的比较隐含了接收端对ICVr的解密步骤。4.3 LTE PDCP PDB的序列号适配LTE PDCP PDB的Word 1格式会根据序列号长度5, 7, 12, 15比特动态变化主要是HFN字段的位宽不同分别为27, 25, 20, 17比特。这是因为COUNT的总长度固定为32比特SN占用的比特数越多HFN占用的比特数就越少。硬件根据SNS字段自动选择正确的解释格式。SNS 值序列号长度适用场景HFN位宽COUNT构成 (HFN:SN)00b12-bitLTE用户面 (一种模式)20 bits20:1201b7-bitLTE用户面 (另一种模式)25 bits25:710b15-bitLTE用户面 (扩展模式)17 bits17:15(隐含)5-bitLTE控制面(C-Plane)27 bits27:5实操心得在配置PDB时必须根据协议栈给出的序列号长度准确设置SNS字段。配置错误会导致HFN字段错位进而使构建的COUNT完全错误加解密必然失败。控制面5比特SN的SNS在PDB中通常有特殊处理或忽略需参考具体芯片手册。5. 常见问题、调试技巧与实战经验在实际开发和调试中仅仅理解流程还不够会遇到各种棘手问题。以下是一些常见坑点与解决思路。5.1 加解密失败问题排查清单当数据无法正确加解密时可以按照以下顺序进行排查密钥检查确认加载到SEC硬件密钥寄存器或密钥内存中的Ciphering Key (CK)和Integrity Key (IK)是否正确。确认密钥是否与算法匹配如AES-128密钥为16字节。确认密钥是否在有效期内是否已同步更新。PDB配置检查Bearer ID和Direction确认收发双方是否一致。上行和下行、不同承载的密钥流是不同的。HFN初始值这是最常见的错误来源。确保收发双方的HFN在连接建立时同步并且在后续通信中通过RRC信令正确同步如切换过程。SNS字段确认与PDU头部实际的序列号长度匹配。算法标识在作业描述符中指定的算法套件如PROTOPDCP_C_ENC对应控制面加密是否与PDB及密钥匹配。COUNT同步与HFN管理乱序问题确认是否提交了乱序的PDU给SEC解密。对于不支持HFN回退的硬件乱序会导致状态不同步。需要在驱动层实现排序缓冲区。HFN更新逻辑检查HFN在SN回滚时的递增逻辑是否正确实现。是否在每次递增后都正确写回了PDB存储区Threshold预警是否处理了硬件返回的阈值警告忽略它可能导致COUNT循环复用严重威胁安全。数据与格式问题PDU头部格式确认输入的PDU头部格式是否符合预期1字节还是2字节各比特位定义。数据对齐检查optShift位的设置。如果硬件要求4比特对齐而数据未按此准备会导致处理错误。输入/输出长度确认输入帧的长度描述符是否正确特别是包含MAC-I时。5.2 性能优化要点批量处理尽量将多个PDU组合成一个大的作业提交给SEC减少硬件上下文切换和软件中断的开销。描述符链预构建对于稳定的数据流可以预构建并缓存整个作业描述符链包括PDB仅在实际处理时更新变化的部分如SN所在的PDU头部。避免内存拷贝利用SEC的分散-聚集Scatter-GatherDMA能力直接描述输入/输出数据在内存中的位置避免不必要的内存拷贝。阈值合理设置根据业务模型和密钥更新策略设置合理的Threshold值。设置过小会导致频繁预警增加软件开销设置过大则有安全风险。5.3 跨算法移植注意事项当需要从一种算法如SNOW-3G切换到另一种如AES-CTR或ZUC时除了更换算法标识和密钥必须重点关注IV构造函数的改变这是必须修改的。不同算法的IV格式、长度、位域排列完全不同。密钥长度与格式虽然都是128位但加载到硬件寄存器的格式可能因算法而异。完整性验证的区别EIA2AES-CMAC没有传统IV其AAD的构造方式特殊。EIA3ZUC的IV构造也独树一帜。硬件引擎支持确认目标SEC硬件是否支持该算法。例如较老的硬件可能不支持ZUC。5.4 调试辅助手段寄存器与内存快照在加解密前后 dump SEC相关的上下文寄存器、PDB内存区域、输入输出数据缓冲区。对比发送和接收两端的数据。使用测试向量3GPP和算法标准文档提供了丰富的测试向量。用已知的密钥、COUNT、Bearer、Dir、明文和密文在隔离环境中测试SEC的配置这是验证硬件配置正确性的黄金标准。分步验证先关闭加密使用空算法EEA0/EIA0验证数据通路和PDB配置是否正确。再启用加密但使用简单的测试数据最后使用真实业务数据。日志记录在驱动层详细记录每次提交作业的HFN、SN、Bearer、算法等参数。当出现问题时这些日志是回溯状态同步情况的无价之宝。理解3G和LTE的PDU加解密与完整性保护不仅仅是读懂一份芯片手册。它要求开发者具备系统性的视角将通信协议的状态机、密码学的算法原理、以及硬件加速器的微架构特性融合贯通。从正确的PDB配置到精准的IV构建再到严谨的HFN状态管理每一个环节的失误都可能导致整个安全链条的断裂。在实际工作中我最大的体会是“状态即一切”。确保收发两端每一个比特的状态信息HFN, SN, Bearer, Dir严格同步是比选择何种加密算法更为基础、也更容易出错的关键。这份手册提供的硬件加速细节正是将这套复杂状态机安全、高效落地的基石。当你下次拿起手机享受高速网络时或许可以想到在芯片的深处正有无数个这样的硬件引擎按照我们刚才剖析的精密流程无声地守护着每一个数据比特的旅程。
的演进与通信机制)
