本人就职于国际知名终端厂商，负责modem芯片研发。
在5G早期负责终端数据业务层、核心网相关的开发工作，目前牵头6G算力网络技术标准研究。


博客内容主要围绕：
       5G协议讲解
       算力网络讲解（云计算，边缘计算，端计算）
       高级C语言讲解
       Rust语言讲解

PDCP完整性保护与加密流程

完整性保护:就是保证信令或者数据内容的完整性，防止信令或者数据在传输过程中被“中间人”修改。与之相对应的是完整性校验流程，用来校验信令或者数据的完整性。

加密：将明文数据变成密文。与之相反的流程是解密过程

一、PDCP密钥的衍生

上面这张图很重要，是整个5G安全的概览图，我们《5G安全系列》就是围绕这幅图进行讲解的。

PDCP层的密钥有4个：

• K_UPint ：用户面的完整性保护/校验密钥；
• K_UPenc：用户面的加密/解密密钥；
• K_RRCint：信令面的完整性保护/校验密钥；
• k_RRCenc：信令面的加密/解密密钥；

这4个密钥是在RRC层生成，在激活AS层安全的时候配置给PDCP层。

这4个密钥的长度都是 128 bit，其实由KDF算法计算出原始的密钥长度是 256bit，在配置给PDCP层之前RRC层会将其截断为 256bit中的低128bit（具体算法参考【5G】NAS安全密钥衍生算法详解）。

注意 ：KDF算法计算出的结果是按照大端保存，同学们coding时别截断错误，错误截断成高128bit

二、PDCP算法和密钥的配置流程

       AS层信令和数据安全是由PDCP层负责的，但是PDCP层安全的激活/去激活、安全算法的选择 又受到RRC层的控制。

2.1 初始AS 安全的激活

       RRC 连接建立的过程中会通过 Security mode command 流程建立AS 层安全，

下面是SecurityModeCommand 信令的内容，里面包含了网络配置给UE的具体算法，

终端在收到SecurityModeCommand message之后RRC会根据信令给出的算法，计算K_UPint 、K_UPenc 、K_RRCint 、k_RRCenc 4个密钥，并配置给PDCP层，此时可以认为 AS 层安全已经激活。

注意 ： 在衍生这4个密钥并配置给PDCP层之前，终端不能发送SecurityModeComplete消息，只有上述的流程都完成后才可以发送。但是对于SecurityModeComplete 信令终端只进行完整性保护，不进行加密。在发送完SecurityModeComplete之后的所有消息才 既进行完整性保护又进行加密。

2.2 AS 安全更新

       基站通过发送RRC reconfiguration信令实现AS 层安全的更新过程，RRC reconfiguration信令中会包含特定的IE （ie，SecurityConfig），终端随后重新衍生K_UPint 、K_UPenc 、K_RRCint 、k_RRCenc 4个密钥，并配置给PDCP层（详细内容参考TS38.331 5.3.5.7）。

三、PDCP加密与解密流程

3.1 加密与解密的应用范围

当安全激活后加密会应用到 上行/下行 所有的PDCP数据PDUs，不会应用的信令 PDUs。

但是不是整个PDCP数据PDU都被加密，只有MAC-I 与 PDCP数据PDU的数据部分才会应用加密，下面的部分不会应用加密过程：

• PDCP 数据 PDU Header；
• PDCP 控制 PDUs；
• 如果PDCP 数据PDU中包括SDAP的Header 或者 SDAP的控制PDU，则SDAP的Header 或者 SDAP的控制PDU 也不应用加密；

为什么Header不加密？
①因为对端的PDCP在解密之前需要获取这个Package的信息，如果加密了就无法正确获取了，因为解密需要PDCP COUNT作为入参，这个参数正好就在PDCP Header中；
②这部分信息不属于用户隐私信息，完全是流程控制信息，可以暴露出来（想想WireShark），并且有完整性保护流程保证其不会被篡改，通过减少加密/解密的数据长度有利于缩短数据包发送时间；

3.1 加密与解密算法参数介绍

• COUNT value (32-bit )：特定BEARER、特定DIRECTION 下的PDCP PDU COUNT，由 HFN和PDCP SN 组成；
• DIRECTION (1-bit)：指示上行还是下行；
• BEARER (5-bit) ：SRB 或者 DRB id - 1（注意这里是减 1）；
• KEY (128-bit) ： K_RRCenc 或者 K_UPenc 取决于待加密/解密的消息是 信令还是用户数据；
• Message : 待加密/解密的数据；
• Message Length：待加密/解密数据的长度（单位是 bit）；

加密/解密算法生成一个 KEYSTREAM BLOCK，使用这个 KEYSTREAM BLOCK 与待加密/解密的数据进行异或运算即可得到 密文/明文。

具体算法参考【5G/4G】NAS与AS层 完整性保护与加密算法系列文章

四、PDCP完整性保护与校验流程

4.1 完整性保护与校验的应用范围

注意 ： AS 层的数据 是 先完整性保护，然后再加密。

完整性保护与校验被激活后，会应用在所有上行/下行的PDCP PDU Header，以及PDCP PDU的数据部分（也就是整个PDCP PDU，不包括 PDCP 控制PDUs）。

完整性保护与校验，总是会被应用在信令面的PDUs上，对于用户面的PDUs是否应用完整性保护与校验是由RRC进行配置的。

完整性保护与校验不会应用在 PDCP 控制 PDUs上。

4.1 完整性保护与校验算法参数介绍

• COUNT value (32-bit )：特定BEARER、特定DIRECTION 下的PDCP PDU COUNT，由 HFN和PDCP SN 组成；
• DIRECTION (1-bit)：指示上行还是下行；
• BEARER (5-bit) ：SRB 或者 DRB id - 1（注意这里是rb id 减 1）；
• KEY (128-bit) ： K_RRCint 或者 K_UPint 取决于待完整性保护与校验的消息是 信令还是用户数据；
• Message : 待完整性保护与校验的数据；
• Message Length：待完整性保护与校验数据的长度（单位是 bit）；

完整性保护算法生成 MAC-I，将MAC-I附加到 PDCP PDU后面，完整性保护流程结束。在对端会进行完整性校验，使用相同的算法和参数计算出X-MAC，与接收到PDCP PDU中的MAX-I进行比较，如果相同完整性校验通过，否则完整性校验失败该PDU被丢弃。

具体算法参考【5G/4G】NAS与AS层 完整性保护与加密算法系列文章

原文链接:https://blog.csdn.net/qq_31985307/article/details/120247240