移动通信网中的密码算法演进之完整性保护

最新推荐文章于 2024-03-22 16:29:13 发布

yimenren

最新推荐文章于 2024-03-22 16:29:13 发布

阅读量4.3k

点赞数 1

转自：https://www.sohu.com/a/217061921_722211

移动研究院出品，必属精品

我们之前介绍过移动通信网用于保护空口机密性的算法演进，本篇主要介绍完整性保护算法的演进。完整性是确保信息或数据不被未授权的篡改或在篡改后能够被迅速发现的必要技术手段。

由于在通信系统演进的过程中，空口的完整性保护算法与机密性保护算法相同但参数与计算流程不同，因此本篇主要介绍移动通信网络在演进过程中所采用的完整性保护机制与机密性保护机制不同的地方。

2G（GSM）

传统的GSM网络没有对信息提供独立的完整性保护[1]。这是由于在通信系统设计之初，人们对于GSM的期望是实现一个能够在无线环境下“像有线电话一样的通信”，其通信网络重点考虑话音的传输，因此主要考虑的是空口信息传输时如何防止话音信息被窃听，用户信息被泄露，未充分考虑对信息篡改或者伪造等问题的防护。因此对于信息可能被篡改的攻击，GSM系统并未设计独立的完整性保护算法，而是在通过使用加密的方式同时实现对信息的完整性保护，即通过加密的方式，使得攻击者无法获知明文，进而无法对密文进行修改，从而无法保证篡改内容符合攻击者的要求。而且在以语音通信为主的GSM系统中，不对用户语音施加完整性保护只是会导致声音识别难度加大，但施加了完整性保护反而会导致语音信息断断续续影响用户感受，所以GSM系统通过加密用户通信信息的方式防止被修改，没有专门针对信令、语音和用户数据提供独立的完整性保护。

3G（UMTS）

随着GSM网络系统的广泛使用，人们发现，仅通过加密的方式提供完整性保护是不够的，因为加密流程是可选的，不加密的信息无法受到任何保护。此外，虽然语音信息对完整性的需求不高，但是信令消息一旦被篡改或者伪造，则可能带来非常严重的问题，比如将语音通信重定向到非法用户。信令消息中的控制消息是维护无线通信系统正常工作的重要信息，其格式与内容均是被严格定义的，因此对控制消息的改动将会导致严重的系统问题，或者导致用户被精心构造的消息所欺骗，如伪基站的问题等。在这种情况下，3G网络加入了独立于加密之外的信令完整性保护机制[2]。

从用户面来考虑，3G仍然是以语音为主的通信系统，同GSM一样，对语音施加完整性保护同样是弊大于利的。所以3G没有对语音施加完整性保护。此外，考虑到无线信道的链路质量弱于有线链路，对数据施加完整性保护可能导致错误丢包重传进而带来的较大时延问题，3G的用户数据传输也同样没有考虑施加完整性保护。

同机密性保护一样，3G网络中也有两种算法用于完整性保护，即KASUMI和SNOW 3G，这两种算法采用的密钥长度也均为128bit，但与机密性保护相比，其对应的命名为UIA（UMTS Integrity Algorithm）系列，名称分别为UIA1和UIA2。上篇提到过，机密性保护算法被命名为UEA1和UEA2，与UIA1和UIA2编号不同。因此，即使使用的基础加密算法相同，3G网络系统也是将机密性算法和完整性算法视为不同的算法，所以完整性保护所需的密钥，以及完整性算法的选定都是与机密性保护相独立的。

同样的基础算法对应的加密算法和完整性算法不同

由于完整性保护通常还同时兼顾抗重放攻击的任务，所以在完整性计算的输入参数中，除了完整性保护密钥，消息与消息长度外，还需要输入包括消息传递方向，消息序列号与新鲜值。这些参数可以有效保证消息的唯一性，所以通过保护这些信息不受篡改，就可以保证消息不可被重放。而完整性保护的输出则是一个32bit长的校验码。完整性保护的示意图如下：

完整性保护计算示意图

与机密性保护相比，完整性保护还具有几个特别的地方。首先，在3G中信令的完整性保护为强制性的。也就是说，对于3G的信令，要么选择基于KASUMI的完整性保护，要么选择基于SNOW 3G的完整性保护，否则通信链路将被释放。

其次，与机密性保护不改变原有消息长度不同，完整性保护需要在受保护消息的最后增加一个32bit的校验值。

最后，由于完整性保护需要产生一个32bit的校验码，对于流算法SNOW 3G，需要设置一个初始向量来计算该校验码。

关于信令的完整性保护的强制性，再补充说明一点：由于用户需要首先与网络建立连接才能与网络协商开启完整性保护，故而用于建立连接的这部分信令交互发生在完整性保护启用前，这些“例外”的信令在交互时可以没有完整性保护。

4G（LTE）

在4G网络技术制定的初期，虽然4G已经是全部面向数据通信的网络，完整性保护依然只是针对信令提供，用户面仍然不进行完整性保护。这是由于，在数据业务发展初期，系统的设计要求仍然是要保证系统空口的吞吐效率最大化和时延最小化。如果假设平均数据报文长度100字节，而对应完整性保护所需要增加的MAC-I长度为32bit（4字节），则意味着需要给数据包增加约4%的额外代价。

另外，对于大块或者大流量的数据而言，机密性能够提供一定程度的完整性保护，因为需要篡改的核心数据是难以定位到的。特别是对于数据承载类业务中的语音（VoIP/VoLTE）类业务、流媒体类业务等，针对这些业务，仍然可以沿用前述3G语音消息完整性分析考虑，其完整性是不必要的。

再者，无线通信网络中传输的数据以IP数据包为主，而大部分数据包则是通过TCP协议承载，TCP协议本身提供完整性检查和校验能力，因此在无线通信系统中再次提供完整性保护容易导致重复保护。

但随着LTE Relay特性的提出，出现了一种需要在用户面传输控制信令的场景，如下图所示。因此针对该场景特别制定了用户数据的完整性保护机制，所以在4G/LTE网络中，只有特定场景下才会存在用户数据完整性保护的情况。

LTE Relay场景示意图

同机密性保护一样，4G网络的完整性保护也有3种算法，称为EIA（EPS Integrity Algorithm）系列[3]。即基于SNOW 3G的完整性保护算法EIA1，基于AES的完整性保护算法EIA2，以及基于祖冲之算法ZUC的完整性保护算法EIA3。其输入参数与3G相比，使用了无线承载的标识符取代新鲜值参与运算来保证消息不可被重放。

4G与2G互操作的时候的完整性保护应用

为什么单独提到这个场景呢？是因为前段时间曝出了一个4G伪基站的安全风险[4]，而这个风险是通过信令的完整性保护而降低的。

4G伪基站有机可乘，是通信系统为了更好地兼容网络、更好地服务用户造成的。攻击者可以设立一个4G伪基站，由于这种情况下，用户与网络之间需要双向鉴权，所以用户是不会在这个4G伪基站建立起安全上下文并进行后续通信的。但攻击者可以在双向鉴权失败后，发送一条无线资源释放消息(RRC Release)，将用户重定向到一个2G的伪基站上。在2G伪基站上由于没有双向鉴权，则可以在2G伪基站上截获用户的标识、进行发送短信等操作。如下图所示：

4G“伪基站”攻击示意图

通过完整性保护，可以降低这种攻击的可能性。基于3GPP几个工作组的联合讨论，在2016年12月明确了一个方案：用户在没有收到来自网络的策略——即允许用户接收未受保护的重定向消息时，用户只接收具有完整性保护且完整性校验成功的重定向消息。这样，用户就可以拒绝接收未受到保护的重定向消息。

NB-IoT

为适应大规模低功耗物联网设备的接入需求，3GPP对LTE网络整体架构和流程进行了精简，引入了NB-IoT技术。NB-IoT流量可能传递了一些物联网设备测量出的关键信息或是对一些物联网设备的控制信息。由于NB-IoT上的流量主要是小包用户数据，即每个用户数据包都比较短小，那么一个比特的翻转，可能就会产生大相径庭的测量结果，或者是控制语义。针对这样的流量模型，完整性保护的重要性就完全不同于语音和大数据流量的业务模型了。

在数据的传输方面，NB-IoT用户数据传输方式分为控制面优化方案和用户面优化方案两种方式[5]。顾名思义，即使是NB-IoT的用户数据，也存在通过网络的信令（即控制面）传输和用户面传输两种方式。

控制面优化方案改变了3G、4G中用户数据通过用户面承载的方式，通过控制面的信令来实现用户数据在终端和网络间的传输。因此，NB-IoT控制面优化方案可沿用4G网络中针对信令的三种完整性保护算法提供对控制面信令和用户数据的完整性保护。

用户面优化方案的中的“优化”主要是指无线链路建立流程的优化，使得用户在并不进行安全连接重建的情况下快速发送数据，这样做的目的主要是为了减少在无线连接建立上的开销，毕竟物联网设备在计算能力和电量使用上可能会存在限制。由于在用户数据的承载方式上还是基于用户面来承载数据，且采用了与LTE一样的安全机制，因此用户面优化方案没有提供对用户数据的完整性保护。在国际标准中曾讨论过增加用户面完整性保护的需求，但被部分厂家因实现代价过高及无法满足上市时间要求等原因拒绝将此纳入国际标准。

EC-GSM

与NB-IoT同一时期还出现了另外一种面向物联网的通信技术。2010年之后，随着低能耗物联网设备的大规模应用，GSM也被用于物联网通信并对GSM系统进行了改造，此时的GSM系统被称为增强GSM，即EC-GSM）。EC-GSM增加了用户数据的完整性保护能力，主要原因是由于EC-GSM针对物联网用户数据与针对手机终端的传统GSM[PJ1] [QMP2] 语音数据相比较有不同安全的威胁，其数据完整性要求更高，另外一些原因也是借鉴了3/4G演进过程中对完整性保护的考虑与实现方法。

这种情况下，EC-GSM使用了基于Kasumi 128的GIA4和基于SNOW 3G的GIA5 用于用户面的数据完整性保护。

场景的考量

5G面向增强宽带eMBB、大规模蜂窝物联网mIoT、高可靠超低时延通信uRLLC三大应用场景，其完整性需求也不完全相同，所以对完整性保护算法到的要求也不完全一样。

❖ eMBB场景：

信令要求等同于4G，即强制对信令进行完整性保护；
不同应用场景产生不同类型的通信数据对数据完整性的需求也不一样，因此要求完整性保护针对不同类型的通信数据灵活考虑是否施加完整性保护。

❖ mIoT场景：

部分物联网终端的能力有限，要求信令完整性保护计算能耗要小；
物联网终端消息可能用来控制设备，所以对用户数据完整性的需求更加强烈，要求提供独立的用户数据完整性保护。

❖ uRLLC场景：

对时延的苛刻要求导致信令的处理网元更加贴近网络边缘，从而使得信令面完整性保护尤其是与核心网之间的信令完整性保护可能发生变化
高可靠要求提高对用户数据完整性保护强度的要求。

5G网络与终端对完整性要求强制实现，可选使用。由于5G的标准化进程分成了两个阶段，Phase1和Phase2，Phase1主要面向eMBB场景，目前还处在Phase1标准的制定过程中[6]，因此针对mIoT和uRLLC的完整性保护具体要求暂未做定义。

对于eMBB场景，信令和用户数据的完整性保护的一些基本需求主要承袭于4G，但在标准化过程中，也根据业务发展而对完整性保护进行了重新思考，如对用户面完整性保护必要性的考虑，对完整性保护密钥长度的考虑等。另外针对前文提到的“例外”的信令的保护方法也有一些考虑。

算法的考量

对于一阶段的eMBB场景而言，主要的终端形态仍以手机、MiFi，或者其他有一定计算能力且带有5G模组的智能硬件为主。算法也仍然沿用AES，SNOW 3G和ZUC。

完整性保护强制与可选的权衡

从3G到4G，一直都强调了对信令的完整性保护，但用户数据的完整性保护始终未能提供。到5G时代，数据应用超越了语音通话，完整性保护需求变得更强；而网络能力的增强，使得容忍额外的完整性保护开销成为可能；并且上层应用也变得越来越复杂，非TCP的应用场景也越来越多，所以对网络层的完整性保护需求也越来越强烈。目前Phase1标准的标准已经要求终端和网络侧强制实现完整性保护。

消息验证码

对于3/4G来说，采用的MAC-I的长度主要是32bit，随着破解技术和量子计算机的发展，可能对现有128bit长的密钥实现破解，进而对32bit长的MAC-I实现破解。因此phase2考虑将128bit长的密钥扩展至256bit，因此同期考虑增加消息验证码的长度来匹配增强的密钥。因此，是否将MAC-I的长度扩展到64bit或者128bit，则可能是phase 2阶段需要考虑的事情。

信令消息完整性保护的进一步增强

一般终端和网络的信令交互都在受完整性保护的信令连接上进行。但在终端的空闲状态下，终端监听网络的广播消息，这时候没有特定的信令连接，从而也没有完整性保护。5G标准考虑了针对终端空闲态的信令交互进行安全增强，从而防止攻击者利用空闲态下交互的消息如应急通信的广播消息传播虚假信令，或让空闲态终端驻留在伪基站式上。目前，5G标准过程中被提出的建议方案包括事前发现阻止攻击和侦测攻击事后防范两种思路，如下图所示：

空闲态伪基站的两种防护思路

事前发现指的是基站采用非对称加密技术，对每一条下发的消息都进行签名，然后由终端基于签名验证结果判断是否可以接收该消息。而事后防范指的则是终端收集与移动性关系相关的信令消息，并在终端状态切换移至新的基站下面时上报信令信息，从而网络可以得知伪基站攻击的发生，然后再通过其他手段去削弱或者清除伪基站。由于事前发现阻止攻击所需要付出的代价较大，会严重影响系统性能，因此并不在phase 1阶段考虑，而侦测攻击事后防范则被认可为可实施的方案，其细节正在进一步的制定过程中[6]。

此外，在终端从空闲态向连接态转换的过程中，终端与网络将进行一些建立连接的信令交互，这些连接建立的信令也会激活安全上下文，使得后续的信令受到完整性保护。但这些信令交互本身没有完整性保护，存在被篡改的风险。

5G系统希望能够对其中重要的初始连接消息进行“延迟”的完整性校验，从而能够尽可能早的发现存在的问题并进行纠正。所谓“延迟”，则是指在消息发送时并不对消息进行完整性校验，而是接收方暂时对消息中的内容进行处理，同时暂时存储该消息并标记为“待验证”，等完整性保护启用后，再对该消息进行完整性保护后重新发送，由接收方根据收到的被保护消息对原消息进行核对。使得对原消息的验证被“延迟”到完整性保护建立之后才开始的样子。

这个做法要求网络在在算法协商流程（同时也是完整性保护激活起始点）中，告知终端需要在算法协商确认流程中重传初始消息（或其中的关键字段）。由于算法协商确认流程时完整性保护已经启动，因此消息不会再被篡改，这样接收方可以根据重新发来的消息与原先保留的信息进行对比确认初始消息是否被更改。如下图所示：