首页/资讯中心/详情

移动通信协议数据单元加解密：从3G RLC到LTE PDCP的硬件实现与调试

移动通信协议数据单元加解密：从3G RLC到LTE PDCP的硬件实现与调试
📅 发布时间：2026/6/22 14:06:49

1. 协议数据单元加解密：从理论到硬件的实现脉络

在移动通信系统的协议栈开发中，尤其是涉及到物理层之上的数据安全处理，协议数据单元的封装与解封装是一个绕不开的核心环节。无论是做基站侧的协议栈开发，还是终端芯片的基带设计，你总会遇到需要处理3G的RLC PDU或者LTE的PDCP PDU。这些PDU的加解密过程，远不止是调用一个加密库函数那么简单，它涉及到序列号管理、超帧号同步、初始化向量构建以及硬件加速引擎的精准配置。很多刚接触这块的工程师，往往会被协议文档里大段的描述和复杂的位域操作搞得晕头转向，而实际在芯片或FPGA上实现时，一个字节的对齐错误、一个比特的顺序错位，都可能导致整个数据流加解密失败。这篇文章，我就结合多年的底层开发经验，把3G RLC和LTE PDCP PDU加解密的整个流程，从协议原理到硬件描述符的配置，掰开揉碎了讲清楚，希望能帮你避开那些我当年踩过的坑。

简单来说，PDU加解密的核心目标，是在无线空口上为数据提供机密性和完整性保护。机密性确保数据内容不被窃听，完整性确保数据在传输过程中未被篡改。3G时代，机密性主要在RLC层通过流密码算法实现；到了LTE，安全功能被提升到了PDCP层，并且同时支持机密性和完整性保护。实现这一过程的关键，在于如何根据协议状态（如承载标识、方向、序列号）动态生成每次加密都不同的密钥流，这就是初始化向量的作用。而硬件加速引擎（如NXP SEC）则通过一套称为协议描述块的配置结构，将这一系列复杂的协议规则固化下来，实现线速处理。下面，我们就从最核心的构建块开始拆解。

2. 核心构建块解析：PDB、IV与算法套件

在深入流程之前，必须理解三个最基础的组件：协议描述块、初始化向量和算法套件。它们是整个加解密引擎的“配置手册”、“调味盐”和“烹饪方法”。

2.1 协议描述块：硬件加速的“配置手册”

协议描述块是硬件安全引擎理解并执行特定协议加解密操作的指令集。它不是一个软件数据结构，而是直接映射到硬件寄存器或DMA描述符中的一段内存布局。PDB包含了处理一个数据流（如某个无线承载上的所有PDU）所需的全部静态和动态上下文信息。

一个典型的PDB会包含以下几个关键字段：

  • 超帧号：这是一个由协议栈维护的计数器，其宽度取决于序列号的长度。例如，对于一个7比特序列号的RLC UM模式，HFN可能是25比特。HFN与序列号共同组成一个更长的、不会重复的COUNT值，是生成密钥流的根基。HFN会在序列号翻转时自动递增，并写回PDB，这个“写回”操作通常由硬件自动完成，这对维持加解密同步至关重要。
  • 承载与方向：承载标识符用于区分不同的逻辑信道，方向比特则指明当前处理的是上行还是下行数据。这两个参数确保了不同信道、不同方向的数据使用不同的密钥流，避免了密钥流重用带来的安全风险。
  • 序列号大小：这个选项决定了如何解析输入PDU的头部。例如，在3G RLC中，SNS=01b表示使用7比特序列号的非确认模式，头部为1字节；SNS=00b表示使用12比特序列号的确认模式，头部为2字节。在LTE PDCP中，控制面固定使用5比特序列号，用户面则可能使用7、12或15比特。
  • 阈值：这是一个安全相关的参数。当HFN增长到超过预设的阈值时，硬件会返回一个警告，提示上层协议需要重新协商密钥了。这防止了因COUNT值循环使用而可能引发的密钥流重复问题。
  • 选项字节：包含一些处理模式开关，比如前面提到的optShift位，它控制是否对输出帧进行4比特的移位对齐。这在某些特定的内存布局或后续处理单元要求字节对齐时非常有用。

注意：PDB通常存储在片外内存中，由DMA读取。在配置PDB时，必须严格注意字节序和位域的对齐方式，确保其格式与硬件手册定义完全一致。一个常见的错误是，在软件中定义PDB结构体时，忽略了编译器的内存对齐，导致某个字段错位了几个比特，从而引发不可预知的加解密错误。

2.2 初始化向量：确保每次加密不同的“调味盐”

初始化向量是流密码算法或分组密码计数器模式生成密钥流的“种子”。它的核心要求是：对于相同的密钥，每次加密使用的IV必须不同，否则就会导致密钥流重复，严重威胁安全性。在移动通信中，IV的构造巧妙地利用了协议状态。

IV的构造公式可以抽象为：IV = f(HFN, SN, Bearer, Direction, ...)。具体形式因算法而异：

  • 对于SNOW-3G：其IV长度为64位（用于机密性）或96位（用于完整性）。它将COUNT、承载、方向等字段按特定顺序拼接，并用零填充至所需长度。
  • 对于AES-CTR：在CTR模式下，IV（即初始计数器值）的构造与SNOW-3G类似，但需要填充至128位。对于AES-CMAC完整性算法，它本身不需要IV，但SEC硬件会将生成的类似IV的数据作为附加认证数据使用。
  • 对于ZUC：这是中国提出的流密码算法。其机密性IV是SNOW-3G机密性IV的重复，而完整性IV的构造则更为特殊，需要对HFN和方向位进行异或和移位操作。

理解IV的生成规则，是调试加解密问题的关键。当发现加解密结果不对时，第一步就应该核对计算出的IV值是否与预期相符。很多仿真工具或测试向量都会给出中间IV值，这是非常重要的调试依据。

2.3 算法套件：3G与LTE的演进

算法套件定义了使用何种密码算法来提供安全服务。

3G RLC层主要关注机密性，支持的算法包括：

  • UEA0：空算法，即不加密。
  • UEA1：基于KASUMI算法的f8保密性算法。
  • UEA2：基于SNOW-3G算法的f8保密性算法。

LTE PDCP层则同时支持机密性和完整性，算法更为丰富：

  • 机密性算法：
    • 128-EEA0：空算法。
    • 128-EEA1：SNOW-3G。
    • 128-EEA2：AES-CTR。
    • 128-EEA3：ZUC。
  • 完整性算法：
    • 128-EIA0：空算法。
    • 128-EIA1：SNOW-3G（基于128-EIA1）。
    • 128-EIA2：AES-CMAC。
    • 128-EIA3：ZUC。

实操心得：在芯片选型或协议栈移植时，一定要确认硬件加速引擎是否支持目标网络要求的所有算法套件。例如，某些早期芯片可能不支持ZUC算法。此外，虽然协议允许机密性和完整性算法任意组合，但在实际部署中，运营商通常会指定固定的组合，如EEA2/EIA2（AES家族）或EEA3/EIA3（ZUC家族）。

3. 3G RLC PDU封装与解封装全流程拆解

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

3.1 封装流程：从明文到密文

封装，即发送端的加密过程。假设我们已经有了一个待发送的RLC PDU，其中包含头部和载荷。

第一步：提取与更新COUNT值。硬件首先从输入帧的PDU头部提取序列号。这个SN的解析方式由PDB中的SNS字段决定。接着，硬件将SN与PDB中维护的HFN拼接，形成完整的COUNT值。这里有一个关键操作：硬件会检查SN是否从全1翻转到0。如果是，则自动将PDB中的HFN加1，并将新值写回PDB。这个“写回”机制是保证收发双方HFN同步的核心，无需软件干预，但要求软件必须按序提交PDU进行处理。

第二步：阈值检查与密钥更新预警。无论HFN是否递增，硬件都会将其与PDB中的阈值字段进行比较。如果HFN达到或超过阈值，硬件在完成本帧处理后，会返回一个警告状态。协议栈必须监听这个状态，并尽快触发密钥重协商流程。这是一个重要的安全特性，防止了过长的密钥流使用。

第三步：构建初始化向量并启动加密。硬件利用COUNT、承载标识、方向比特以及PDB中预置的常量，按照所选算法（UEA1或UEA2）的规则构建64位的IV。这个IV被写入硬件上下文寄存器。同时，PDU头部被原封不动地复制到输出帧缓冲区，它不参与加密，但用于生成IV。

第四步：载荷加密与输出。PDU载荷被送入加密引擎（如KFHA或SNOW-3G-f8）。加密引擎使用配置的密钥和刚刚构建的IV，生成密钥流，与明文载荷进行逐比特异或，产生密文载荷。密文载荷被追加到输出帧的头部之后。如果PDB中的optShift位被置位，输出帧会在头部前插入PDB中指定的前导半字节，在尾部填充4比特零，使得整个PDU在帧内偏移4比特。这通常用于满足某些特定接口的字节边界要求。

整个流程的输入输出关系清晰：输入是明文PDU（头+载荷）和配置好的PDB，输出是密文PDU（原头部+加密载荷，可能带移位）。

3.2 解封装流程：从密文到明文

解封装是封装的逆过程，发生在接收端。

第一步：提取COUNT与更新HFN。与封装端完全一致，硬件从收到的密文PDU头部提取SN，与本地PDB中的HFN拼接成COUNT。同样，在SN翻转时自动递增HFN并写回。这里有一个至关重要的约束：由于HFN只能递增不能回滚，接收端必须严格按照PDU的发送顺序提交给硬件处理。乱序的PDU会导致HFN不同步，从而无法正确解密。

第二步：阈值检查。同样进行HFN与阈值的比较，并在需要时产生警告。

第三步：构建IV并启动解密。使用与封装端完全相同的规则构建IV。如果optShift位被置位，硬件会先对输入帧进行4比特的反向移位，移除添加的前导半字节和尾部填充，然后再提取PDU头部和密文载荷进行解密。

第四步：载荷解密与输出。解密引擎使用相同的密钥和IV生成相同的密钥流，与密文载荷异或，恢复出明文载荷。输出帧包含原始的PDU头部和解密后的载荷。

3.3 PDB覆盖机制：应对特殊场景

标准流程假设一个数据流的所有PDU共享同一个PDB。但有时需要对某个特定的PDU使用不同的HFN。例如，在切换或重建场景下。SEC硬件提供了通过DPOVRD寄存器覆盖PDB中HFN的机制。

在作业描述符中，可以通过一条LOAD IMMEDIATE指令，将新的HFN值加载到DPOVRD寄存器，并设置其OVRD位。当硬件处理该作业时，会使用DPOVRD中的HFN值，而不是PDB中的值。处理完成后，PDB中的HFN不会被这次覆盖操作所更新。这个机制为处理异常序列提供了灵活性。

踩坑记录：PDB覆盖功能非常强大，但使用不当极易导致状态不一致。务必确保覆盖操作是原子性的，并且软件清楚地知道何时使用覆盖的HFN，何时切换回PDB自身的HFN。在一个项目中，我们曾因在覆盖后没有正确清理状态，导致后续一批PDU使用了错误的HFN，造成大规模解密失败。建议为每个需要使用覆盖HFN的PDU单独创建临时的硬件作业，避免状态残留。

4. LTE PDCP PDU封装与解封装详解

LTE将安全功能提升至PDCP层，并引入了完整性保护，流程比3G RLC更为复杂。根据数据面（用户面/控制面）和是否中继节点，其处理模式也不同。

4.1 用户面与控制面PDU的差异

首先需要区分两种主要的PDU类型：

  • 控制面 PDCP PDU：主要用于传输RRC信令。其头部固定为1字节，包含一个5比特的序列号。控制面PDU必须同时进行机密性和完整性保护。
  • 用户面 PDCP PDU：用于传输用户数据。其序列号长度可以是7、12或15比特，对应头部长度为1或2字节。对于非中继节点的普通用户面，通常只进行机密性保护。但对于中继节点，用户面也可能需要完整性保护。

这种差异直接影响了后续IV的构建和硬件处理流程。

4.2 初始化向量生成的算法差异

LTE支持多种算法，不同算法的IV构造方式不同，这是实现中最容易混淆的地方。

对于SNOW-3G：

  • 机密性IV：由COUNT (HFN || SN)、承载、方向以及26比特的零常量拼接而成，共64位。
  • 完整性IV：由COUNT、5比特零、承载、方向以及27比特零拼接而成，共96位。注意，承载和方向在完整性IV中的位置与机密性IV不同。

对于AES-CTR：

  • 机密性IV：构造方式与SNOW-3G类似，但需要填充零至128位，作为AES-CTR模式的初始计数器值。
  • 完整性IV：对于AES-CMAC算法，它本身不需要IV。SEC硬件会将生成的96位数据（构造方式同SNOW-3G完整性IV）作为附加认证数据提供给CMAC算法。

对于ZUC：

  • 机密性IV：就是SNOW-3G的64位机密性IV重复一次，形成128位。
  • 完整性IV：构造最为特殊。它基于机密性IV，但会将方向比特与HFN的最高有效位进行异或，并进行比特位的移位操作，最终生成一个128位的IV。具体位操作需要严格参照手册中的图示。

注意：完整性IV仅在协议要求完整性保护时才需要构建和配置。在硬件描述符中，这通常意味着需要同时填充Class 1和Class 2的上下文寄存器。

4.3 仅机密性保护的用户面封装流程

这是最常见的用户数据处理场景。流程与3G RLC封装高度相似：

  1. 构建COUNT（HFN + SN），管理HFN翻转和阈值告警。
  2. 根据所选算法构建机密性IV，写入Class 1上下文寄存器。
  3. 将PDU头部复制到输出帧。
  4. 使用配置的加密算法对PDU载荷进行加密，密文追加到输出帧。
  5. 输出帧仅包含头部和加密后的载荷。

4.4 机密性与完整性保护的控制面封装流程

这是控制面或中继节点用户面的处理流程，最为复杂。

  1. 准备阶段：提取SN，构建COUNT。同时，根据算法规则，分别构建机密性IV和完整性IV，并写入Class 1和Class 2上下文寄存器。
  2. 完整性计算：硬件开始并行或流水处理。首先，PDU头部和明文载荷被提交给完整性算法进行计算，生成一个4字节的完整性校验值。
  3. 机密性处理：与此同时或稍后，明文载荷被提交给机密性算法进行加密。
  4. ICV加密与附加：计算出的完整性校验值，在附加到帧尾之前，需要先使用机密性算法进行加密。这一步很关键，它保护了ICV本身。最终，加密后的ICV被附加到加密载荷之后。
  5. 输出：输出帧结构为：[PDU头部] + [加密后的PDU载荷] + [加密后的4字节ICV]。

4.5 解封装流程：解密与验证

解封装是封装的逆过程，但完整性验证环节是关键。

对于仅机密性的用户面：流程与3G RLC解封装类似，构建IV，解密载荷即可。

对于需要完整性的PDU：

  1. 接收到的帧包含：头部、加密载荷、加密的ICV。
  2. 硬件首先构建用于解密的机密性IV和用于验证的完整性IV。
  3. 解密载荷：使用机密性IV和密钥，解密PDU载荷。
  4. 解密ICV：使用相同的机密性流程，解密收到的ICV，得到原始的、发送端计算的MAC-I值。
  5. 完整性验证：将PDU头部和解密后的载荷，提交给完整性算法，使用完整性IV和密钥，本地重新计算一个MAC-I‘值。
  6. 比对：比较本地计算的MAC-I‘和解密得到的MAC-I。如果两者完全相同，则验证通过，输出解密后的载荷；如果不同，则硬件会返回一个完整性验证错误，该PDU应被丢弃。

实操心得：完整性验证失败是调试中的常见问题。除了密钥和IV错误外，还需要检查：1）PDU头部是否被正确地包含在完整性计算中；2）对于AES-CMAC，附加认证数据的构造是否正确；3）接收端在提交数据给硬件时，是否将加密的ICV部分正确地分离并提供给验证流程。很多时候，问题出在数据分段的边界上。

5. 工程实现中的常见问题与深度排查指南

理论清晰之后，落地实现才是真正的挑战。以下是我在多个项目中总结出的典型问题及其排查思路。

5.1 加解密结果不一致：从COUNT同步查起

这是最经典的问题。发送端加密成功，接收端解密失败，或者解密出来是乱码。

排查步骤：

  1. 确认COUNT同步：这是首要怀疑对象。在收发两端同时打印或记录处理每个PDU时的HFN和SN值。确保在SN翻转时，HFN的递增逻辑一致。检查是否有PDU丢失或乱序到达，导致接收端HFN提前递增。
  2. 核对IV生成：在调试阶段，可以编写一个软件函数，模拟硬件IV生成过程。在收发两端分别用当前的HFN、SN、承载、方向计算IV，并进行比对。务必逐比特核对，特别是位域拼接的顺序和填充零的位数。
  3. 检查算法与密钥：确认收发双方配置的算法标识完全一致。对于LTE，是EEA1/EIA1还是EEA2/EIA2？密钥是否相同？密钥是否在正确的时间点进行了更新？
  4. 验证PDB配置：仔细核对PDB中每一个字段：HFN初始值、承载、方向、SNS模式、阈值等。确保其内存布局与硬件手册定义的位域完全匹配。可以使用内存查看工具，直接查看提交给硬件的PDB内存块内容。
  5. 检查数据边界：确认提交给硬件的输入帧指针和长度是否正确包含了整个PDU（头部+载荷），没有多一个字节或少一个字节。对于有optShift或填充的场景，要特别注意输入输出缓冲区的长度和对齐。

5.2 性能瓶颈与优化策略

在高速数据场景下，PDU加解密可能成为性能瓶颈。

  • 批处理与描述符链：不要为每个PDU都发起一次硬件操作。利用SEC的Job Ring或Queue Manager接口，构建描述符链，让DMA连续处理一批PDU，可以极大减少硬件交互的开销和中断频率。
  • PDB复用：对于同一个无线承载上的大量PDU，其PDB中的大部分字段（如承载、方向、算法、密钥索引）是固定的，只有HFN会变化。可以创建一个PDB模板，在需要更新HFN时，只修改HFN字段并写回，而不是重建整个PDB。
  • 避免内存拷贝：尽可能让硬件引擎直接从网络数据包缓冲区读取数据，并将结果写入目标缓冲区。避免在软件层进行不必要的内存拷贝。
  • 阈值预警的异步处理：HFN达到阈值产生的警告，通常不需要实时处理。可以设置一个阈值预警队列，由后台任务定期检查并触发密钥更新，避免影响实时数据路径。

5.3 多核与多承载环境下的并发处理

在基站等设备中，需要同时处理成百上千个无线承载。

  • 承载上下文隔离：每个承载的PDB和密钥必须严格隔离。通常使用不同的硬件上下文ID或不同的队列来区分。确保一个承载的作业不会错误地使用另一个承载的PDB。
  • HFN的原子性更新：HFN的“读-递增-写回”操作必须是原子的。虽然硬件在单次作业内能保证原子性，但在多核软件环境中，为同一个承载提交作业时需要加锁，或者采用每个核处理独立承载集合的方式避免竞争。
  • 错误处理与状态恢复：当硬件返回解密失败或完整性验证错误时，协议栈应有明确的恢复机制。对于RLC AM模式，可能触发重传；对于无法恢复的错误，可能需要上报高层协议进行承载重建。错误统计和日志对于定位间歇性问题至关重要。

5.4 与协议栈的集成要点

硬件加速引擎是协议栈的一个部件，良好的集成设计能事半功倍。

  • 抽象接口层：设计一个统一的加解密接口层，向上层协议提供encrypt_pdu和decrypt_pdu等函数。接口层内部处理PDB管理、作业提交、结果回调等细节。这样，上层协议无需关心底层是硬件实现还是软件实现。
  • 状态管理：将HFN、承载ID、密钥索引、算法套件等状态信息与协议栈的承载上下文绑定。在承载建立、修改、释放时，同步初始化和清理硬件侧的PDB资源。
  • 测试与验证：建立完善的测试框架。包括：1）单元测试：针对IV生成、COUNT计算等核心函数；2）基于标准测试向量的算法验证；3）与协议栈模拟器对接的集成测试，模拟各种网络场景（如切换、重传、乱序）下的加解密行为。

6. 从3G到5G的演进思考

虽然本文聚焦于3G和LTE，但其核心思想——利用协议状态生成IV，通过硬件加速实现线速安全处理——在5G NR中得到了延续和增强。

在5G NR中，安全功能依然位于PDCP层。算法套件在LTE的基础上进行了精简和增强，例如，128-EEA4和128-EIA4是基于AES-CTR和AES-CMAC的更强版本。IV的构造原则类似，但COUNT的构成可能更加复杂，引入了更长的PDCP序列号。此外，5G引入了更多的安全上下文和派生密钥，用于不同的网络切片和业务类型。

理解3G/4G的PDU加解密机制，是掌握5G乃至未来移动通信安全技术的坚实基础。这套机制的精髓在于，它将动态变化的协议状态与密码学算法紧密结合，在保证每次传输密钥流唯一性的同时，又通过硬件加速实现了对海量数据的高效处理。无论底层算法如何演进，这套“状态+算法+硬件”的框架，依然是构建可靠无线空口安全防线的核心。