3G/LTE PDU安全处理实战：从协议原理到NXP SEC硬件加速实现

1. 项目概述：移动通信协议数据单元的安全处理核心

在移动通信系统的开发与调试中，无论是基站侧还是终端侧，协议数据单元（PDU）的安全处理都是一个绕不开的核心环节。这不仅仅是简单地调用一个加密库函数，而是涉及协议栈深度、硬件加速优化和实时性要求的复杂系统工程。我曾在多个嵌入式通信项目里，从早期的3G模块到后来的LTE Cat.1/Cat.4模组，都深度参与过这部分的设计与实现。今天，我想抛开那些标准文档里晦涩的流程图，从一个一线工程师的视角，聊聊3G RLC和LTE PDCP层PDU加解密与完整性保护背后的那些“门道”，特别是如何理解并高效利用像NXP LS2088A这样的安全引擎（SEC）来完成这些繁重的计算任务。

简单来说，PDU安全处理的核心目标就两个：机密性和完整性。机密性确保数据内容不被窃听，通过对载荷进行加密实现；完整性确保数据在传输过程中未被篡改，通过生成并校验消息认证码（MAC）来实现。在3G的RLC层，标准主要关注机密性，使用如Kasumi-f8或SNOW-3G-f8这样的流密码算法。而到了LTE的PDCP层，需求变得更加复杂，控制面信令必须同时具备机密性和完整性，用户面数据通常只需机密性，但对于中继节点等特殊场景，用户面也可能需要完整性保护。这就对处理引擎提出了更高的要求：需要能灵活支持多种算法组合，并能高效处理协议头解析、序列号管理、超帧号（HFN）滚动以及初始化向量（IV）构建等一系列琐碎但至关重要的前置工作。

2. 核心概念与协议数据块（PDB）深度解析

在开始动手之前，我们必须把几个关键概念和数据结构吃透。安全引擎（SEC）并非直接处理原始的无线帧，它需要一份清晰的“食谱”，这就是协议数据块。

2.1 协议数据块（PDB）的角色与结构

你可以把PDB想象成厨师做菜前准备好的那份配料单和工序表。它不是一个承载用户数据的容器，而是一个控制结构，里面包含了处理当前这个PDU所需的所有元数据和状态信息。SEC硬件在运行时，会严格遵循PDB中的指示进行操作。

一份典型的PDB（以3G RLC封装为例）通常包含以下几个关键部分：

• 描述符头：标识协议类型（如3G RLC加密）、操作方向（封装/解封装）等。
• 选项字节：这是一个控制位集合，包含了决定处理模式的关键开关。例如，SNS位用于指示序列号长度（7位用于非确认模式，12位用于确认模式），optShift位则控制是否对输出帧进行4比特的移位操作（这通常用于字节对齐或特定的硬件接口需求）。
• 超帧号：这是一个由协议栈维护的、不断递增的计数器。由于无线链路上的序列号（SN）位数有限（如5、7、12、15位），会周期性回绕。HFN作为SN的高位部分，与SN共同组成一个更长的、不会在短时间内重复的计数器COUNT，这是生成加密密钥流或MAC的核心输入之一，防止重放攻击。
• 承载与方向：Bearer标识逻辑信道，Dir指示传输方向（上行/下行）。它们也是IV的一部分，确保了即使COUNT相同，不同承载或方向上的密钥流也是不同的。
• 阈值：这是一个预警机制。当HFN增长到接近或达到预设的阈值时，SEC会在处理完成后返回一个警告，提示上层协议栈“该重新协商密钥了”。这是实现前向安全的重要一环。

实操心得：在调试初期，最容易出问题的地方就是PDB的配置与协议栈状态不同步。比如，协议栈已经因为大量数据传输导致HFN递增了，但你的PDB中的HFN字段没有及时更新，或者更新了但没写回内存，会导致加解密双方使用的COUNT值不一致，加解密必然失败。务必确保PDB在共享描述符中的更新机制是可靠且原子性的。

2.2 初始化向量（IV）的构建：安全性的基石

IV是分组密码或流密码算法开始工作的“起点”，它的唯一性直接决定了加密密钥流的唯一性，从而保障了“一次一密”的安全性。如果IV重复，那么相同的明文可能产生相同的密文，这会带来严重的安全风险。3GPP协议对IV的构造有非常严谨的定义。

以LTE PDCP层SNOW-3G算法为例，其机密性IV和完整性IV的构建逻辑是理解整个机制的关键：

1. 构造COUNT：将PDB中的HFN（高位）与从PDU头部提取的SN（低位）拼接起来。例如，对于12位SN，HFN占20位，共同组成一个32位的COUNT值。
2. 构建机密性IV：将COUNT、Bearer、Dir以及一段固定的零常量拼接起来，形成一个64位或128位的比特串，作为加密算法的IV。
3. 构建完整性IV：过程类似，但格式可能不同。对于SNOW-3G，其完整性IV是96位的，构建方式是在COUNT后插入Bearer和Dir，但位置与机密性IV略有不同，最后补零至96位。

为什么需要不同的IV？即使对于同一个PDU，其机密性和完整性保护也应使用不同的密钥流。通过精心设计的IV构造规则，使用同一个根密钥（CK和IK），却能衍生出完全不同的、用于加密和完整性校验的密钥流，这实现了算法层面的密钥分离。

注意事项：不同算法的IV构造规则天差地别。AES-CTR模式的IV是128位的，并且其构造方式与SNOW-3G不同。ZUC算法的IV构造则更为特殊，其完整性IV并非简单重复机密性IV，而是进行了比特位的重排和异或操作。在实现时，必须严格按照标准文档（如3GPP 33.401）或芯片手册（如本文参考的NXP手册）中定义的比特位顺序进行拼接，一个比特的错误都会导致对端无法正确解密或验证。

3. 3G RLC PDU加解密的实现流程与细节

3G RLC层的安全处理相对单纯，只提供机密性保护。其流程是理解更复杂场景的基础。

3.1 封装流程详解

假设我们现在要发送一个RLC PDU，流程如下：

1. 准备与提取：协议栈准备好RLC PDU（包含头部和载荷），并提交给SEC。SEC首先从PDU头部提取序列号。
2. COUNT管理与预警：将提取的SN与PDB中维护的HFN组合成COUNT。检查SN是否回绕（从全1变为0），如果是，则将PDB中的HFN加1并写回。无论是否递增，都会比较HFN与阈值，触发必要的密钥更新预警。
3. IV构建与加载：使用COUNT、Bearer、Dir以及协议规定的常量（在PDB中指定），按照Kasumi-f8或SNOW-3G-f8算法的要求，构建64位的初始化向量。
4. 加密操作：将构建好的IV写入SEC的Class 1上下文寄存器。随后，将PDU的载荷部分送入加密引擎进行流加密。这里有一个关键点：PDU头部是原样透传的，不参与加密。因为对端需要依靠头部信息（如SN）来重建IV以进行解密。
5. 输出组装：将未加密的PDU头部和加密后的载荷拼接，形成最终的输出帧。如果optShift位被置位，还会在帧首和帧尾进行4比特的移位和填充。

3.2 解封装流程详解

接收端的流程是发送端的逆过程，但包含状态回写：

1. 输入解析：SEC收到封装后的帧。如果optShift有效，先进行反向移位操作，恢复出标准的PDU头部和密文载荷。
2. 状态同步：提取头部中的SN，与本地PDB中的HFN组合。同样，需要处理SN回绕，递增HFN并写回PDB。这里有一个重要约束：解封装必须按序进行。因为HFN只能递增不能回退，如果收到一个SN更小但HFN更大的乱序包（理论上由于SN回绕可能发生），解密���失败。这通常由RLC层的重排序功能来保证。
3. IV重建与解密：使用与发送端完全相同的规则重建IV，加载到硬件引擎。然后将密文载荷送入解密引擎。
4. 输出：将原始头部和解密后的明文载荷输出，上交更高协议层。

踩坑记录：在早期测试中，我们遇到过解密持续失败的问题。经过逐比特比对，发现是Bearer和Dir在构建IV时，比特位顺序弄反了。芯片手册的图表有时是从最高位画到最低位，而代码实现时是数组的第0个字节对应最低位，这个转换非常容易出错。务必用已知正确的测试向量进行反复验证，最好能构建一个从PDB到IV的单元测试模块。

4. LTE PDCP PDU的封装与解封装：更复杂的场景

LTE PDCP层引入了完整性保护，并且算法套件更多样，其处理流程成为了一个经典的双通道（Confidentiality & Integrity）处理模型。

4.1 控制面PDU的封装流程

控制面PDU（如RRC信令）要求同时进行加密和完整性保护，其流程最具代表性：

1. 输入与提取：SEC收到包含PDU头和载荷的输入帧，提取SN。
2. 双IV构建：根据所选算法（如EEA2和EIA2），分别构建用于加密的IV和用于完整性保护的IV（对于AES-CMAC，这个“IV”实际上作为附加认证数据AAD处理）。这两个IV被分别写入Class 1和Class 2上下文寄存器。
3. 并行处理：
   • 头部处理：PDU头部被同时写入输出帧缓冲区和完整性认证引擎的输入FIFO。
   • 载荷处理：PDU载荷被写入一个“分叉”通道。一方面，它进入加密引擎进行加密，加密后的密文写入输出帧；另一方面，明文载荷也被送入完整性认证引擎。这里请注意：完整性计算是基于明文的。这是通用MAC计算的要求。
4. MAC生成与保护：完整性引擎计算出一个4字节的MAC-I值。这个MAC-I值还需要被加密，以防止其本身被篡改。因此，它会被传递给加密引擎进行加密。
5. 最终输出：输出帧由“原始PDU头 + 加密后的载荷 + 加密后的MAC-I”三部分组成。

4.2 用户面PDU的封装与解封装

用户面PDU的处理相对简单，通常只进行加密。其流程与3G RLC封装非常相似，主要区别在于PDU头部格式和SN长度（可能是7、12或15位），以及使用的算法可能是AES-CTR或ZUC。

对于需要完整性保护的用户面（如中继节点场景），其流程则与控制面相同。

4.3 解封装流程中的完整性验证

解封装是封装的反向过程，但核心在于验证：

1. 分离与提取：接收端收到帧后，分离出PDU头、密文载荷和加密的MAC-I（称为XMAC-I）。
2. 解密与验证准备：使用相同的规则重建双IV。先对密文载荷进行解密，得到明文载荷。同时，将加密的XMAC-I解密，得到对方发送的原始MAC-I。
3. 完整性计算与比对：将收到的PDU头和解密得到的明文载荷，送入完整性认证引擎，按照相同的算法和密钥计算出一个新的MAC-I值。
4. 裁决：比较计算得到的MAC-I与解密得到的XMAC-I。如果两者完全一致，则完整性验证通过，输出明文载荷；如果不一致，则SEC会返回一个错误标识，该PDU将被丢弃。

核心技巧：在实现双算法（如加密用AES-CTR，完整性用AES-CMAC）时，要特别注意密钥的加载。SEC通常有独立的密钥寄存器组（Class 1 Key, Class 2 Key）。你需要确保将加密密钥CK正确加载到Class 1密钥寄存器，将完整性密钥IK正确加载到Class 2密钥寄存器。混淆两者会导致加解密和验证全部失败。

5. 实战中的关键问题与性能优化

理解了原理和流程，在实际的嵌入式开发中，我们还会面临一系列工程挑战。

5.1 PDB的动态覆盖机制

在一个数据流中，HFN是随着每个PDU的处理而递增的。如果每个PDU都使用一个全新的描述符，会造成巨大的内存和性能开销。因此，SEC支持“共享描述符”机制：一个描述符（包含PDB）被创建后，可以用于处理一个流中的所有PDU。但是，HFN在每个包处理后都需要更新。为了解决这个问题，SEC提供了DPOVRD寄存器覆盖机制。

工作原理：在作业描述符中，可以通过一条LOAD IMMEDIATE指令，将一个特定的HFN值加载到DPOVRD寄存器，并设置覆盖位。当SEC处理该作业时，它会使用DPOVRD寄存器中的HFN值，而不是共享PDB中存储的HFN值。处理完成后，SEC会自动将更新后的HFN值写回共享PDB中。这样，协议栈只需要在初始化时设置好共享描述符，之后每个包只需提交一个轻量级的作业描述符（包含数据指针和可选的HFN覆盖值），极大地提升了效率。

配置示例：假设我们使用队列管理器接口，通常的步骤是：

1. 在内存中创建并初始化一个LTE PDCP的共享协议描述符，填写算法、Bearer、Dir、初始HFN、阈值等静态字段。
2. 对于每个要发送的PDU，协议栈构建一个帧描述符。帧描述符的某个字段（如FRC字段）可以用来携带当前PDU对应的HFN值。
3. 队列管理器硬件在构建实际发给SEC的作业描述符时，会自动将FRC字段的值通过LOAD IMMEDIATE指令加载到DPOVRD寄存器。
4. SEC处理时，使用这个动态的HFN，并在处理后将其递增写回共享描述符所在的内存。

5.2 算法选择与性能考量

不同的算法在安全强度和计算开销上各有不同：

• SNOW-3G：专门为无线通信设计的流密码，速度快，但在通用处理器上软件实现效率不高，极度依赖硬件加速。
• AES-CTR：基于AES的流密码模式，是国际通用标准，许多CPU都有AES-NI指令集加速，在有些平台上软件实现也可能很快。但在纯硬件引擎上，SNOW-3G可能更有优势。
• ZUC：中国自主设计的流密码算法，已成为3GPP标准。其硬件实现也有很高的效率。

在选择算法时，除了合规性要求，还需要进行实际的性能测试。需要关注SEC硬件对不同算法的吞吐量、延迟以及开启完整性保护后的性能损耗。通常，硬件数据手册会提供这些数据。

5.3 常见问题排查速查表

在集成和调试阶段，以下问题最为常见：

5.4 内存与数据对齐要求

SEC作为硬件加速器，对数据缓冲区和对齐通常有严格要求：

• 描述符对齐：协议描述符、作业描述符通常需要128位或256位对齐。
• 数据对齐：输入/输出数据帧的起始地址最好也能按缓存行对齐，以获得最佳DMA性能。
• 字节序：特别注意PDB中多字节字段（如HFN）的字节序（Endianness）。芯片手册通常以比特位图定义，在写入内存时需要根据处理器架构进行转换。大端模式的处理器和网络字节序可能更直观，小端模式则需要仔细转换。

6. 从3G/LTE到5G的思考

虽然本文聚焦于3G和LTE，但其核心思想——基于COUNT、Bearer、Dir构建IV，区分机密性和完整性处理通道，使用PDB控制硬件行为——在5G NR的PDCP层安全中得到了延续和增强。5G引入了更长的序列号、新的加密算法（如128-EEA4，基于AES-CTR的变种）和完整性算法（128-EIA4），并且对用户面完整性保护的支持更为普遍。

理解本文所述的LS2088A SEC实现机制，相当于掌握了移动通信协议硬件安全加速的“基本语法”。当面临更复杂的5G场景，甚至未来6G的演进时，你能够快速抓住本质：协议层安全的核心始终是密钥派生、状态同步和硬件高效调度。无论算法如何迭代，这个底层逻辑是相通的。在实际项目中，最宝贵的经验往往来自于对芯片手册每个比特位的深究，以及对每次加解密失败日志的耐心分析。希望这些基于实战的拆解，能让你在下一个通信项目里，面对PDU加解密时，多一份从容，少踩一个坑。