硬件安全引擎中DTLS/SRTP协议数据块(PDB)配置与优化实践

1. 项目概述：当硬件引擎遇上安全协议

在音视频通话、物联网设备通信这些对实时性要求极高的场景里，数据包跑在UDP这种“发了就不管”的协议上。速度快是快了，但数据裸奔可不行，得给它们穿上“防弹衣”——这就是DTLS和SRTP干的活。DTLS给不可靠的UDP连接加上TLS级别的安全保障，SRTP则专门为实时流媒体提供加密和认证。不过，光有协议标准还不够，真要在每秒处理几十万甚至上百万个数据包的网卡或处理器上跑起来，纯软件实现那点CPU算力根本不够看，延迟和抖动能让你抓狂。

这时候，硬件安全引擎（Security Engine， 比如NXP LS2系列里的那个SEC模块）就派上用场了。它就像个专门处理加密解密的“协处理器”，协议封装解封装那些繁琐的步骤——拼装头、算IV、加密、算MAC、抗重放检查——全都能用硬件流水线一口气搞定，把主CPU彻底解放出来。但想让这个“硬汉”听话，你得用它能懂的语言——协议数据块（PDB）——来精确指挥它每一步操作。这活儿干好了，性能飙升；配置错了，轻则丢包，重则安全漏洞。我折腾过不少基于这类硬件的项目，踩过的坑不少，今天就把DTLS和SRTP在这类硬件引擎里的封装解封装流程，掰开揉碎了讲清楚，重点就是那个指挥一切的PDB该怎么配。

2. 核心原理：PDB——硬件安全引擎的“作战指令”

在深入流程之前，必须彻底搞懂PDB（Protocol Data Block）。你可以把它理解为发给硬件安全引擎（SEC）的一份详细“作战指令单”。SEC自己并不理解DTLS或SRTP的RFC文档，它只认PDB里配置的参数。PDB定义了本次处理的所有关键信息：用哪种算法（AES-CBC还是AES-GCM？）、密钥在哪、初始向量（IV）怎么生成、序列号是多少、输出格式长啥样等等。

PDB通常是一个在内存中预先定义好的数据结构，由驱动软件根据当前的安全会话（例如DTLS握手协商好的密码套件）进行填充，然后连同待处理的数据包描述符一起提交给SEC。SEC读取PDB，就像工厂流水线读取生产工单一样，严格按照上面的步骤执行加密、认证、封装或解封装操作。

注意：PDB的格式和字段含义是芯片厂商定义的，不同厂商、甚至同一厂商不同系列的硬件都可能不同。本文以NXP LS2088A SEC手册为参考，但其设计思想是相通的。你的代码必须严格对照你所用芯片的参考手册，一个比特位都不能错。

2.1 PDB的关键字段解析

虽然具体字段因协议和模式（封装/解封装）而异，但一些核心概念是通用的：

1. 算法与模式选择：通过PROTINFO等字段告诉SEC，当前是DTLS封装还是SRTP解封装？用的是AES-CTR流加密还是AES-CBC块加密？认证算法是HMAC-SHA1还是AEAD内置认证？
2. 密钥句柄：指向存储在SEC内部或特定安全内存中的加密密钥和认证密钥。硬件引擎直接读取，软件无需接触明文密钥，安全性更高。
3. 序列号与抗重放：对于DTLS/SRTP，序列号是至关重要的。PDB中会包含当前待处理的序列号（Seq Num），以及对于SRTP的滚动计数器（ROC）。在解封装时，PDB中的选项位（如ARS）可以开启硬件的抗重放窗口检查，SEC会自动比对序列号是否在有效窗口内，标记重放或过时的包。
4. Salt/Nonce相关参数：用于生成IV或Nonce的盐值（Salt Key）存放在PDB中。例如，SRTP的AES-CTR IV就是由Salt、SSRC、序列号和ROC异或生成的。
5. 输出格式控制：OutFMT等选项位控制SEC输出哪些内容。是只输出解密后的净载荷？还是包含完整的解密后记录头？这对于后续软件处理流程至关重要。
6. 长度字段：明确指示ICV长度、填充长度、可选的MKI（主密钥标识符）长度等，确保SEC能正确解析输入帧的边界。

实操心得：调试硬件加解密问题，十有八九首先怀疑PDB配置。务必写一个PDB打印函数，在提交给硬件前，将PDB每个字段的值以十六进制和二进制形式打印出来，与手册中的位图逐一核对。我曾经因为一个保留位（Reserved bit）错误地设置为1（本应为0），导致整个封装流程被SEC拒绝，返回“Protocol PDB error”，排查了半天。

3. DTLS记录封装流程详解

DTLS记录层封装的目标，是为一个上层消息（如握手报文或应用数据）加上记录头，并进行加密和完整性保护。硬件引擎的处理流程与协议栈软件实现逻辑一致，但被固化成了硬件步骤。

3.1 块密码套件（如AES-CBC + HMAC）封装流程

这是最经典的模式。假设我们使用TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384这样的套件。

流程拆解与PDB配置：

1. 准备输入与PDB：软件准备好明文载荷（Payload），并填充好PDB。PDB中需包含：加密算法（CHA选择AES，模式为CBC）、认证算法（MDHA选择SHA384，模式为HMAC）、加密密钥和HMAC密钥的句柄、当前Epoch和Sequence Number、以及用于CBC模式的IV生成方式（w/b和e/i位）。

2. 生成完整性校验值（ICV）：

   • SEC首先计算明文的HMAC。但注意，DTLS认证的数据不仅包括载荷，还包括一个特殊的“认证头”。
   • 这个“认证头”由Epoch (2字节) + Sequence Number (6字节) + Type (1字节) + Version (2字节)拼接而成。关键点在于，这个顺序与最终发送出去的记录头顺序不同。发送顺序是：Type, Version, Epoch, Seq Num。硬件在认证时内部进行了重排。
   • PDB中的length (pre ICV)字段（完整记录长度减去ICV、填充和填充长度的长度）也会被加入认证计算。

3. 处理填充（Padding）：对于块密码，明文长度必须是块大小的整数倍。SEC会自动添加填充字节（Padding）和一个标识填充长度的字节（Pad Length）。例如AES块大小16字节，如果明文27字节，则需要添加5个填充字节（填充值可能是0x05），最后再加一个字节的0x05（填充长度）。

4. 构造初始向量（IV）：这是块密码的关键。PDB的Options字节中的e/i和w/b位控制IV生成。

   • e/i=1（显式IV）：这是DTLS 1.2的标准做法。SEC会生成一个随机数作为IV，并将其放在加密数据（密文）的最前面一起输出。接收方需要先取出这个IV，才能开始解密。
   • w/b=1（弱IV）：使用上一个密文块的最后一块作为下一个记录的IV（CBC残块模式）。DTLS 1.2不建议使用此模式，因为它存在安全隐患。
   • 在我们的PDB配置中，应明确设置w/b=0, e/i=1。

5. 加密：SEC使用配置的密钥和生成的IV，以CBC模式对整个块（Payload + ICV + Padding + Pad Length Byte）进行加密。

6. 组装输出帧：SEC按照以下顺序输出：

   • 记录头：Type, Version, Epoch, Sequence Number, Length (full rec)。
   • （如果e/i=1）显式IV。
   • 密文（加密后的 Payload+ICV+Padding+Pad Len）。
   • 注意，ICV（HMAC）是先计算，然后和Payload一起被加密的。这与某些“先加密后MAC”的模式不同，DTLS采用的是“MAC-then-Encrypt”。

7. 更新状态：序列号（Sequence Number）在操作完成后会自动递增，并写回PDB在内存中的副本，供下一个记录使用。

避坑指南：务必理解“认证顺序”与“传输顺序”的差异。硬件在认证时，把Epoch和Seq Num提到了最前面，这是为了与TLS的隐式序列号处理逻辑保持一致。如果你在软件侧模拟这个过程进行验证，顺序弄错会导致ICV校验失败。

3.2 流密码套件（如AES-CTR + HMAC）封装流程

使用AES-CTR模式时，加密是流式的，不需要填充。流程相对简化。

流程拆解：

1. 准备：同样配置PDB，选择AES-CTR算法和HMAC算法。
2. 认证头处理：与块密码流程相同，SEC将Epoch + Seq Num + Type + Version送入HMAC引擎进行认证。
3. 构造计数器（Counter）：AES-CTR模式需要一个初始计数器（Initial Counter）。SEC从PDB中提取Write_IV（一个随机值）和当前的Sequence Number，组合成初始的Counter值。这个Counter会随着加密每个块而递增。
4. 加密与认证并行：明文Payload被送入AES-CTR引擎加密。同时，length (pre ICV)字段和明文Payload被送入HMAC引擎计算ICV。注意，这里的ICV是计算自明文，然后这个明文的ICV被加密。
5. 输出：输出记录头，然后是加密后的Payload + ICV。

关键区别：在AES-CTR模式下，ICV是作为数据流的一部分被加密的，而不是像CBC那样先算完再整体加密。同时，由于是流密码，没有填充操作，数据长度可以任意。

3.3 AEAD密码套件（如AES-GCM）封装流程

AES-GCM和AES-CCM属于“认证加密”模式，加密和认证在一次操作中完成，效率更高，也更安全。

流程拆解：

1. 构造Nonce/IV：这是AEAD的核心。以AES-GCM为例，它需要一个12字节的Nonce。对于DTLS 1.2，其构造方式与TLS 1.2相同。通常，PDB中会提供一个salt，并与一个每包不同的nonce_explicit（随机数）组合生成最终的IV。在封装端，nonce_explicit会被生成并放入输出帧中。
2. 准备附加认证数据（AAD）：AAD是参与认证但不被加密的数据。对于DTLS，AAD就是经过重排的记录头：Epoch + Seq Num + Type + Version + Length (pre ICV)。注意，Length (pre ICV)是不包含ICV本身长度的记录长度。
3. 执行AEAD加密：SEC将AAD、明文Payload、以及Nonce一起送入Class 1 CHA（加密硬件），指定为AES-GCM模式。硬件一次性输出密文和认证标签（Tag，即ICV）。
4. 输出：输出完整的记录头（包含nonce_explicit），然后是密文，最后是认证标签。

配置要点：在PDB中，需要正确设置AES-GCM相关的标志位，并确保salt值已正确加载。nonce_explicit由硬件随机数生成器或软件提供。

4. DTLS记录解封装流程详解

解封装是封装的逆过程，但多了“验证”这一关键环节，且需要处理可能的乱序到达。

4.1 块密码套件解封装流程

1. 解析与预解密：SEC收到数据包，首先根据记录头中的Length字段，找到最后两个密文块。它用倒数第二个密文块作为临时IV，解密最后一个块，从而得到填充长度字节。这一步是为了提前知道填充长度，以便后续正确划分数据边界。
2. 提取头信息：SEC从输入帧中提取Type, Version, Epoch, Sequence Number, Length等字段。
3. 认证数据准备：和封装时一样，SEC将Epoch + Seq Num + Type + Version以及计算出的Length (pre ICV)送入HMAC引擎，准备认证。
4. 抗重放检查：如果PDB中使能了抗重放（Anti-Replay），SEC会在此刻检查序列号是否在滑动窗口内，标记重复或过时的包。重要：抗重放状态的更新通常在ICV验证通过后才进行。
5. 解密：根据IV的提供方式（显式IV从帧中提取，隐式IV从PDB或上下文获得），SEC对密文（Payload+ICV+Padding）进行CBC解密。
6. 验证与输出：解密后的明文Payload被送入HMAC引擎完成ICV计算。SEC将计算得到的ICV与从解密数据中提取出的接收到的ICV进行比较。如果匹配，则将解密后的Payload（根据OutFMT选项，可能还包含记录头）输出。如果不匹配，则产生错误。

4.2 流密码与AEAD套件解封装

流程与封装对应，核心步骤包括：提取序列号等信息构造Counter/Nonce，将接收到的记录头重排后作为AAD（对于AEAD）或认证数据的一部分，进行解密/验证操作，最后进行ICV比对。

乱序处理的核心：DTLS解封装硬件支持乱序处理，因为它有显式的Epoch和Sequence Number。软件需要维护一个足够大的缓冲区来缓存乱序到达并解密验证通过的记录，然后按序列号顺序提交给上层应用。硬件本身只负责单个包的解密和验证，不负责排序。

5. SRTP数据包处理流程详解

SRTP用于保护RTP媒体流。它与DTLS有相似之处（如使用AES-CTR、有序列号），但结构更简单，且专门针对RTP头格式进行了优化。

5.1 关键参数：SSRC、序列号与ROC

• SSRC：同步源标识符，在RTP头中，用于标识一个媒体流源。
• 序列号（Seq Num）：RTP包自带的16位序列号，每个包递增1。
• 滚动计数器（ROC）：一个32位的计数器，每当16位的RTP序列号回绕（从65535跳到0）时，ROC就加1。ROC是SRTP会话状态的一部分，必须被安全地同步和维护。在PDB中，ROC是需要被软件更新和维护的关键字段。

5.2 SRTP封装流程（以AES-CTR+HMAC-SHA1为例）

1. 构建初始计数器（Counter IV）：这是SRTP AES-CTR加密的起点。SEC执行一个112位（14字节）的按位异或操作：
   • 操作数A：来自PDB的14字节Salt Key。
   • 操作数B：由输入帧中的4字节SSRC、2字节序列号和PDB中的4字节ROC拼接而成，高位补零至14字节。
   • 结果：16字节的AES-CTR初始计数器（Counter IV）。
2. 处理头与载荷：
   • SRTP头（RTP头+可能的CSRC列表+扩展头）被直接送入HMAC引擎进行认证，然后原样输出到输出帧（不加密）。
   • RTP载荷（Payload）、填充（Padding）和填充长度字节被送入AES-CTR引擎进行加密。
3. 认证ROC：ROC字段虽然不输出到网络，但它是HMAC认证的一部分。在HMAC计算的最后阶段，ROC被加入计算。
4. 输出与更新：加密后的载荷输出到头之后。HMAC计算完成后，指定长度（n_tag，如SHA-1是20字节）的ICV被附加在最后。如果PDB中配置了可选的MKI，它会被插入在填充长度字节和ICV之间。最后，软件需要检查RTP序列号是否回绕（变为0xFFFF），如果是，则需将PDB中的ROC加1并写回。

5.3 SRTP解封装与抗重放

解封装是封装的逆过程，但同样包含关键的验证步骤。

1. 构建Counter IV：与封装端相同，使用接收包中的SSRC、Seq Num和本地PDB中的ROC、Salt Key来生成Counter IV。
2. 认证与解密：SRTP头被送入HMAC认证。加密的载荷和ICV被送入AES-CTR解密。ROC同样被加入认证计算。
3. ICV校验：计算接收到的HMAC，并与解密后得到的ICV进行比较。
4. 抗重放检查：这是SRTP解封装的重要环节。SEC支持一个基于滑动窗口的硬件抗重放检查。PDB中的ARS（Anti-Replay Scorecard）位可以设置为01b（64位窗口）或10b（128位窗口）。SEC内部会维护一个位图（可能就存储在PDB后续的字中），标记哪些序列号已经收到过。如果收到包的序列号落在窗口内但已被标记，则视为重放包；如果序列号太旧，落在窗口左侧之外，则视为迟到包。这些包会被SEC直接拒绝，并返回相应的错误状态。

严重注意事项：硬件抗重放检查依赖于ROC的正确性。如果两端ROC不同步（例如一方崩溃重启后ROC重置），会导致大量合法包被误判为“迟到”而丢弃。因此，实现中必须有一套可靠的ROC同步和持久化存储机制（例如在SDP交换或DTLS-SRTP密钥导出时确定初始值，并定期或将会话结束时保存到非易失存储）。

5.4 AEAD模式下的SRTP（AES-GCM）

流程与DTLS的AEAD类似，但Nonce的构造方式不同。SRTP的AEAD Nonce是12字节，由PDB中的12字节Salt Key与（SSRC + ROC + Seq Num）填充至12字节后异或生成。在封装时，整个SRTP头作为AAD，载荷被加密和认证。解封装时，SEC使用相同的Nonce和AAD进行验证和解密。

6. 常见问题排查与调试心得

在实际驱动开发和调试中，以下几个问题是高频雷区：

1. ICV校验失败：这是最常见的问题。

   • 首先检查PDB：确认认证算法（如SHA256 vs SHA384）、密钥、Salt是否与对端完全一致。确认OutFMT等选项位配置是否正确，是否意外修改了认证数据的范围。
   • 检查数据顺序：对于DTLS，确认认证数据的拼接顺序（Epoch+Seq Num在前）是否正确。对于SRTP，确认ROC是否被正确加入HMAC计算。
   • 检查长度字段：Length (pre ICV)和Length (full rec)是否计算正确？这直接影响了认证数据的边界。

2. 解密失败或输出乱码：

   • 检查IV/Nonce：确认IV的生成方式（显式/隐式）、Salt值、以及Counter/Nonce的构造逻辑两端是否一致。特别是AES-CTR模式，Counter的生成公式必须严格遵循RFC。
   • 检查密钥：确认加载到安全引擎的密钥是否正确，密钥句柄是否指向了预期的密钥材料。
   • 检查数据对齐：对于块密码，输入数据长度是否已包含填充并是块大小的整数倍？

3. 抗重放误报：

   • ROC不同步：这是根本原因。检查ROC的初始化、更新和持久化逻辑。确保在会话恢复时能读取到正确的ROC值。
   • 序列号跳跃：如果发送端序列号不是严格单调递增（如跳变很大），可能瞬间超出接收端的抗重放窗口，导致后续合法包被误判为“迟到”。需要根据应用特性调整窗口大小或处理逻辑。

4. 性能问题：

   • PDB重用与池化：对于每个流或每个会话，其PDB的大部分字段（如密钥、Salt、算法）是固定的。应该初始化一个PDB模板，每次处理包时只更新序列号、ROC等变化字段，避免重复构建整个PDB结构体。
   • 描述符链优化：SEC通常支持描述符链（Descriptor Chain）来批量处理数据包。合理组织输入/输出缓冲区描述符和PDB，利用硬件的DMA和流水线能力，能极大提升吞吐量。

调试建议：在初期，可以先用一个已知正确的软件实现（如OpenSSL的DTLS或libSRTP）与你的硬件引擎实现进行“环回测试”。即用软件加密，硬件解密，反之亦然。从最简单的密码套件（如AES128-CBC）开始，逐步增加复杂度。同时，充分利用芯片的调试功能，如SEC可能提供的错误状态寄存器，能快速定位是PDB错误、密钥错误还是数据错误。