TD-LTE中数据完整性保护0算法导致UE无法鉴权

《TD-LTE中数据完整性保护0算法导致UE无法鉴权》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、.TD-LTE中数据完整性保护0算法导致UE无法鉴权一、概述2二、现场测试问题如下：2三、原因分析：3四、解决方案：8五、验证结果：9..一、概述新购买的TD-LTE测试终端型号E5776S,软件版本号为B161、B211为目前最新版本测试终端，在上海现场进行LTE测试时发现无法正常鉴权附着失败，导致无法进行正常测试。二、现场测试问题如下：SecuritymoderejectEMMcause显示为24Securitymoderejected,unspecifiedAttachreject..EMMc

2、ause:Protocolerror,unspecified一、原因分析：根据上面的测试截图我们发现，EPS已经下发Securitymodecommand,而且UE侧发起Securitymodereject，此行为为UE侧拒绝导致attachreject.securitymodecommand，一个是NAS层的，一个是PDCP的，我们需要对比的是authentication完成后的securitymodecommand，也就是NAS层的。1、对比正常的测试流程Securitymodecommand（

3、B120版本）与B211、B161版本的UE侧拒绝的Securitymodecommand：..正常B120版本的NAS层SecuritymodecommandB211版本的NAS层Securitymodecommand发现B120与B211版本的Securitymodecommand无任何差异，故怀疑此B211版本UE存在故障。2、为了确定UE故障，我们将此款UE在南京现场进行业务测试发现同款UE在南京现场测试正常，测试如下：..PDCP层Securitymodecommand再次对比南京现场测试

4、的NAS层Securitymodecommand与上海现场的信令Securitymodecommand信息南京现场的Securitymodecommand信息..上海现场的Securitymodecommand信息南京路测的截图，与上海的差别就是Typeofintegrityprotectionalgorithm不一样，南京是128-EIA1，上海是EIA0，为数据完整性保护算法不相同，eNODEB侧参数设置完全一至均为EIA2。所以可以确定为核心网侧integrityprotectionalgor

5、ithm设置存在差异。但从UE上报的能力来看EIA0算法是可以支持的如下图UE信息：3、参照规范：3GPP33.401..关于完整性保护算法MME应该包含3GPP定义了的所有的完整性和加密算法(核心网三种都支持),NAS层建立连接时，终端上报安全能力，那么MME根据终端能力选择算法。我们的问题在于MME上配置的listsofalgorithms和UE上报的securitycapabilities列表没交集，所以发生鉴权失败了。同时hisi芯片厂家反映：芯片硬件本身是支持EIA0的，现在用新协议要求不

6、允许只使用0算法（NullIntegrityProtectionalgorithm），E1AO主要针对紧急呼叫的，安全性无法保障，目前统一用A1算法南京MMEAlgorithmselected如下：..经分析，UE及网络侧如下配合更为合理：ü如果UE只是用紧急呼叫的话，应该只带上来EIA0；ü如果UE3个都带了，那对于核心网来说，应该选择非EIA0的完整性保护算法；一、解决方案：给出3点解决建议，满足一项即可：1.对华为新出的终端也是对EIA0做限制，在终端在上报支持能力时就不上报了EIA0了2.M

7、ME侧把NASsecurityalgorithm中EIA0改成128-EIA1..3.如果终端上报支持EIA0，在核心网做完整性保护算法选择时，也不会优先选择EIA0，应该是EIA1或者EIA2，同时打开3个完整性保护算法开关。一、验证结果：最终用户协调经华为对核心网算法的修正（方案3），经测试验证，同款UE（UE前后的能力没有改变）已经可以接入网络了，MME下发的完整性保护算法为EIA2，附着成功。.