Open5GS项目中NAS强制加密问题的分析与解决

问题背景

在5G核心网Open5GS项目的实际部署中，发现了一个关于NAS(非接入层)安全的有趣现象。尽管网络和UE(用户设备)在安全模式命令(SMC)信令中协商确定NEA(加密算法)为NULL(即不加密)，但后续的NAS消息却仍然被强制加密传输。

现象描述

通过抓包分析N2接口的数据，可以观察到以下关键现象：

1. 在Packet 62的安全模式命令(SMC)中，网络和UE明确协商NEA=NULL，表示双方同意不对NAS消息进行加密
2. 然而从Packet 64开始，所有的NAS消息都被加密传输
3. 这种行为与协议预期不符，因为当NEA=NULL时，NAS层不应进行加密

技术分析

5G安全机制基础

在5G网络中，NAS安全包括两个主要方面：

• 完整性保护(由NIA算法控制)
• 加密保护(由NEA算法控制)

当NEA设置为NULL时，表示双方同意不启用NAS加密功能，但完整性保护仍然可以独立启用。

Open5GS实现细节

经过深入分析，发现问题出在Open5GS的实现逻辑上：

1. Open5GS的安全处理模块在处理安全模式命令时，虽然正确协商了NEA=NULL
2. 但在后续的消息处理流程中，安全上下文管理模块错误地强制对所有NAS消息应用加密
3. 这种实现方式与3GPP TS 33.501规范中关于NAS安全处理的要求不符

解决方案

解决此问题的关键在于修改Open5GS的安全处理逻辑：

1. 在安全上下文管理中，严格遵循NEA协商结果
2. 当NEA=NULL时，应跳过加密处理流程
3. 仅当NEA协商为非NULL值时，才启用NAS加密功能

技术影响

这一问题的解决对于5G网络具有重要意义：

1. 协议合规性：确保Open5GS实现完全符合3GPP规范要求
2. 互操作性：避免与某些严格遵循标准的UE设备出现兼容性问题
3. 性能优化：当确实不需要加密时，可以节省加密计算资源

实施建议

对于Open5GS开发者，建议：

1. 在安全模式命令处理流程中增加NEA有效性检查
2. 分离加密和完整性保护的处理逻辑
3. 添加详细的日志记录，便于后续问题排查

总结

通过对Open5GS中NAS强制加密问题的分析和解决，我们不仅修复了一个具体的技术问题，更重要的是加深了对5G安全机制实现细节的理解。这种类型的问题分析过程对于5G核心网开发者和维护人员具有很好的参考价值，特别是在处理安全相关功能时，必须严格遵循协议规范，同时考虑各种边界条件的正确处理。