移动终端数据业务高安全通信方案研究
摘 要：
要满足特殊行业或企业的移动终端数据业务的高安全通信需求，必须在运营商通道上构建自主可控的移动 VPN 协议。针对小规模高安全接入应用场景，具体借鉴 L2TP/IPSec VPN 协议框架，对与协议封装、身份认证、策略交换、密钥协商相关的协商协议流程及交互内容等方面均提出了改进措施，可作为专用无线接入设备实现移动 VPN 软件功能的重要参考。最后，从产品实践的角度提出还应综合考虑设备硬件架构安全、器件及操作系统的自主可控安全等问题，全方位提升移动终端数据业务高安全通信能力。
随着移动通信技术的发展、移动终端处理与接入能力的提升，传统以电脑基于固定场所通过固网虚拟专用网络（Virtual Private Network，VPN）访问企业应用的办公模式，拓展出智能终端通过移动 VPN 访问企业应用的办公模式。为确保移动办公信息安全，配套的政策要求及支撑技术也在逐步完善中。政 策 方 面，2019 年 5 月， 国 家 标 准 GB/T22239—2019《信息安全技术 网络安全等级保护基本要求》发布，并于同年 12 月 1 日正式实施，其中新纳入了采用移动互联技术的系统作为保护对象。新的标准对物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全，以及安全管理等方面均进行了约束，为解决移动办公安全问题提供了细分研究方向。
技术方面，许艳萍等人对基于安卓操作系统的智能终端安全框架进行研究，发现隐患并提出防范措施。李济洋等人设计了基于加密 SD 卡的内网移动终端可信接入方案，支持移动终端与内网间数据交互过程中的加密通信与安全存储。陈洋等人 [3] 研究了移动办公 VoLTE语音安全为什么不能与移动终端数据业务安全采用相同安全防护技术。李辉 [4] 对移动 VPN进行了分类研究、对比分析，并提出了相关技术要求。陈楠等人 [5] 改进了互联网安全协议（Internet Protocol Security，IPSec）的互联网密钥 交 换（Internet Key Exchange，IKE） 协 议 以支持移动 VPN 构建。罗杰等人 [6] 对主流 L2TP/IPSec VPN 的安全缺陷进行剖析，为数据取证、网络攻防、情报侦察、反恐维稳等领域提供技术手段。
可见移动办公所涉及的安全问题颇多且热度不减，本文对有高安全性要求的行业或企业在移动办公中的数据业务安全通信问题进行研究，该研究属于等级保护要求中的网络和通信安全领域，探索移动 VPN 差异化需求的解决方案。
1 移动虚拟专网概述
本文主要从移动办公系统网络模型和移动虚拟专网建设方式两个方面进行阐述。
1.1 移动办公系统网络模型
具有高安全性要求的行业或企业移动办公仅允许终端访问企业内网，公网仅作为传输通道，终端与公网间逻辑隔离。依据网络资产归属及功能划分，移动办公系统网络模型由移动终端用户区、公网传输服务区、总部业务服务区组成。移动办公系统网络模型如图 1 所示。
图 1 移动办公系统网络模型
1.1.1 移动终端用户区
移动终端用户区由高安全性行业、企业及其用户所属的智能终端组成，提供终端办公软件所需的计算能力及移动 VPN 接入能力。当前，智能终端本身的硬件安全、系统安全、应用安全、用户身份认证、访问控制等定制需求已有相关研究，其共同点是要实现 VPN 客户端功能。该 VPN 客户端以加密隧道方式接入总部，与普通个人智能终端一般软件的应用层加密或传统代理型安全套接字协议（Secure SocketsLayer，SSL）传输层加密不同，VPN 客户端须实现所有终端业务 IP 报文与公网间的逻辑隔离和加密保护。
1.1.2 公网传输服务区
公网传输服务区由运营商网络基础设施组成，一端为企业总部业务服务区提供传统有线接入能力，一端为移动终端用户区提供多样的空口接入能力。截至 2021 年，国内运营商 4G 基站建设已覆盖近 100% 行政村，5G 基站已向下覆盖至所有地级市，中国移动还实现了全 IPv6的国内移动互联网。图 1 中示意了公共 Wi-Fi、4G、5G 三种主要的接入方式以及移动互联网和专网两种通道支撑方式，由于运营商无线接入网与有线核心网均独立演进发展，因此可以对移动 VPN 的构建提供差异化服务标准的 IP 承载网络，不影响移动 VPN 的既有实现。
1.1.3 总部业务服务区
总部业务服务区由业务服务器系统、局域网安防类系统、网络边界安防类系统等组成，具备与公网的隔离能力、与移动终端 VPN 构建能力。安防措施上，与传统利用公网构建企业分支与总部的 VPN 的方法类似，VPN 网关作为独立设备需部署于局域网边界最外侧。该服务区与运营商可通过传统互联网方式接入，也可采用专网方式接入。
1.2 移动虚拟专网建设方式
移动虚拟专网建设的第一步是高安全性要求的行业或企业向运营商购买产品与服务。其中包括终端所需的全球用户识别卡（UniversalSubscriber Identity Module，USIM），以及签约明确用户终端与总部之间采用互联网通道或专网通道等技术要求。两种通道方式的差异如表 1 所示。
表 1 互联网通道与专网通道对比
移动虚拟专网建设的第二步是总部侧自行搭建 VPN 网关设备、终端侧启用专用 VPN 客户端。鉴于高安全性要求的行业或企业必须构建端到端加密的移动虚拟专网，即便运营商网络内部能够提供足够的安全措施，也必须在运营商通道上通过特定 VPN 协议构建自主可控的移动 VPN。
2 移动虚拟专网通信技术与数据业务安全性分析
本文通过对常见移动 VPN 通信技术的机理介绍以及各类移动 VPN 对数据业务安全性保障能力方面的分析对比，引出本方案在安全通信方面改进的着力点。
2.1 常见移动 VPN 通信技术
智能终端厂商一般集成有常用移动 VPN 客户端软件，通过购买服务，VPN 客户端软件可用于连接运营商的服务端设备，及符合协议标准的第三方 VPN 服务公司的服务端设备。不同厂家的智能终端在 VPN 标准及具体实现上具有一定差异，比如苹果终端启用 IPSec VPN 客户端时支持思科 IPSec 设备，不一定支持其他厂商的IPSec 设备。图 2 显示了国内主流品牌、主要操作系统、可接入 4G 或 5G 移动网络的智能终端支持的移动 VPN 类型。
图 2 常见智能终端移动 VPN 支持情况
常见的协议类型包括点对点隧道协议（Point-to-Point Tunneling Protocol，PPTP）、二层隧 道 协 议（Layer 2 Tunneling Protocol，L2TP）、IPSec 协议，以及 L2TP/IPSec 组合协议。上述协议的数据通道报文在进入空口协议栈前的典型封装格式如图 3 所示。
图 3 主要移动 VPN 协议数据包典型封装格式
2.1.1 PPTP VPN
PPTP 协议最初由微软等公司牵头起草，并在 RFC 2637 中得到标准化定义 。PPTP 协议是多通道协议，其中，控制通道负责控制通道自身以及数据通道的创建、维护、终止，由客户端发起目的端口号为 1723 的传输控制协议（Transmission Control Protocol，TCP）连接、承载点对点协议（Point to Point Protocol，PPP），PPTP 协议依赖 PPP 协议规范实现通信双方的身份认证、客户端私网 IP 地址分配等功能，无数据通道加密保护机制。数据通道负责将用户 IP包封装在 PPP 协议中，再利用增强型通用路由封装（Generic Routing Encapsulation，GRE） 隧道协议承载。
由于 PPTP 的数据通道业务封装采用了 GRE协议承载，能适应具有网络地址转换（Network Address Translation，NAT） 网 关 的 网 络 环 境，但不能适应具有网络地址端口转换（Network Address Port Transfer，NAPT）网关的网络环境。利用移动互联网方式构建移动 VPN 时，往往受到防火墙等安全设备的拦截、需要运营商放行1723 端口、GRE 协议等。
2.1.2 L2TP VPN
L2TP 协议最初由思科等公司牵头起草，在 RFC 2661 中 得 到 标 准 化 定 义， 并 在 RCF3931 中 更 新 了 V3 版 本 。L2TP 使 用 目 的 端口号为 1701 的用户数据报协议（User DatagramProtocol，UDP）封装，L2TP 协议是单通道协议，在该 UDP 隧道中，通过 L2TP 报头区分控制消息与数据消息。L2TP 的控制消息自行设计了“消息丢失重传”“定时检测隧道连通性”机制，数据消息则继承了 UDP 的不可靠传输特性。L2TP协议仍然依赖 PPP 协议规范实现通信双方的身份认证、客户端私网 IP 地址分配等功能，L2TP本身也不提供加密机制。
L2TP 设计之初就是要保障分支机构、远程拨号用户访问总部，UDP 封装方式具备了互联网 NAPT 穿越的能力。尽管不同厂家基于 RFC文档在实现和运用 L2TP 协议时常因兼容性问题导致丢包、连接不稳定等现象发生，但从 4G移动网络发展开始，L2TP 成为移动 VPN 的主要隧道协议之一 。
2.1.3 IPSec VPN
IPSec 是 由 20 世 纪 90 年 代 美 国 资 助 的IETF 相关网络层加密研究组提出的一套安全框架，是一系列加密 VPN 技术的集合。IPSec 协议是多通道协议，控制通道使用 UDP500 端口，承 载 IKE 协 商 协 议。数 据 通 道 根 据 IKE 协 商结果确定是由 IP 隧道承载或源目端口 4500 的UDP 隧道承载。由于 IPSec 协议框架中封装模式、加密算法、验证算法、密钥交换协议等子规范在实现中能够根据具体网络情况手工配置或依靠 IKE 协商，还能够与其他不具备加密功能的VPN 协议组合运用，具有极大的灵活性，但其应用比较复杂。
对于移动接入，由于 RFC 标准的 IPSec 均未涉及给终端分配私网 IP 地址的机制，往往需要运营商直接提供网络层专网或移动终端上由L2TP 先行构建两层虚链路，并给终端分配好私网 IP 地址，IPSec 仅采用传输模式封装发挥加密作用。不同厂商自行实现了 IPSec 的各 RFC 版本功能或子集，给跨厂商 IPSec 设备的兼容互通带来问题，多名学者从移动适应性 、协商安全性、协商效率、隐蔽性 等方面研究优化提升IPSec 在移动 VPN 构建上的综合能力，使 IPSec产品呈现多样性。
2.1.4 L2TP/IPSec VPN
L2TP/IPSec 组 合 协 议 实 际 上 是 L2TP overIPSec 的一种组合运用，被普遍认为是“强加密”的 VPN 协议 ，其结合源于 RFC 标准的 IPSec手工配置是由安全联盟（Security Association，SA）提供加密机制，但又不支持 NAPT 环境，无法为移动接入终端分配私网 IP，而 L2TP 恰好有 PPP 协议提供的认证机制，支持移动接入、缺少业务加密机制，于是二者互补 。
由于 IPSec 有多种实现方式，因此在终端上配置 L2TP/IPSec VPN 时可以有多种选择。例如，用 户 选 择 L2TP/IPSec PSK 方 式， 实 际 上 是 选择了 IPSec 采用预共享密钥（Pre-Shared Key，PSK）的认证和加密方式，不进行 IKE 协商过程。封装模式上推荐并普遍使用 L2TP 结合传输模式的 IPSec，可避免双层隧道导致的大量分片重组消耗，但结合隧道模式的 IPSec 也有可行场景。
2.2 数据业务安全性分析
将移动 VPN 业务数据保护涉及的几项关键技术进行对比分析，如表 2 所示。
表 2 常见移动 VPN 业务数据保护关键技术对比
针 对 PPTP VPN 和 L2TP VPN 在 加 密 和 认证方面的短板，微软公司在自身操作系统上实现 了 微 软 点 对 点 加 密（Microsoft Point-to-Point Encryption，MPPE）协议，对 PPTP 的业务提供链路层加密机制，使用 MS-CHAP 认证协议加强PPP 协议的双向认证机制，但在 4 种常见移动VPN 中，移动终端 L2TP/IPSec VPN 协议的安全机制更完备、实际应用更广。
罗杰等人对 L2TP/IPsec VPN 的加密机制的脆弱性进行分析，提出了对 L2TP 登录口令、IPSec 预共享密钥的直接或间接破译方法，证实了有条件利用 Diffie-Hellman 算法实现的漏洞，使其产生密钥泄露，最终还原加密信息的可能性。此外，有公开报道提及有国家曾利用标准制定优势开发并推广国际标准的加密技术，其安全部门在该技术中秘密植入后门、具备破译能力，该国的商业公司被要求在移动终端中广泛使用基于该技术的安全软件，企业级用户还以为自己使用了国际认证的加密标准。因此，即便采用“国际认证”的更安全的公开算法及相关实现软件，也并非就实现了高安全，对具有高安全性要求的行业、企业的移动 VPN 组网，可借鉴 L2TP/IPSec VPN 的构建思想，但必须从更多方面加强安全性设计。
3 移动终端数据业务高安全通信方案探索
为达成宏观安全目标，在需采取的措施中明确了本方案主要的改进方向。
3.1 宏观安全目标及改进方向
聚焦移动办公对移动终端数据业务高安全性通信的要求，推荐按照图 1 中的计算终端串接含有专用 VPN 客户端软件的独立无线接入设备的方式组织运用，类似 2020 年抗击新冠肺炎疫情期间采用的用户前置设备（Customer Premises Equipment，CPE）商用解决方案 ，实现方舱内网经 5G 接入公网专线与托管医院内网以 IPSec VPN 方式加密互通，其他组织运用方式不在本文论述。对标等级保护 2.0 相关要求，计算终端可视为局域网设备采取国产化平台、自主软件、主机监控、病毒查杀等安全加固措施，接入设备则作为独立边界类设备，完善自主可控、访问控制、认证加密等安全措施，二者可独立发展，低耦合。在计算终端与接入设备之间增加接入认证功能，可确保只有可信任的终端才能与接入设备配套使用。重点从接入设备的移动 VPN 协议如何改进的角度给出解决方案。
3.2 移动 VPN 协议改进
本文主要从协议封装格式改进和协商协议改进两个方面详细介绍解决方案。
3.2.1 封装格式改进
L2TP/IPSec VPN 组合协议对移动接入场景具有普适性，弊端是封装嵌套过深，导致数据处理效率较低。考虑到高安全用户群体移动办公接入设备与总部VPN网关硬件及协议均可定制，因此可按照单通道化、整合协商、叠加安全机制的定制思路提升数据业务安全性。为便于区别，将改进的移动 VPN 命名为 Hybrid VPN，协议封装格式对比如图 4 所示。
图 4 Hybrid VPN 协议封装格式
协商包与数据包共用封装公网 IP 头（借用 L2TP 的公网 IP 头）和传输层头（将 L2TP 的UDP 头和 IPSec NAT-T 模式下的 UDP 头整合为一个封装UDP头，可沿用L2TP协议UDP端口号）。
外 层 加 密 借 鉴 IPSec 的 传 输 模 式 及 ESP（Encapsulating Security Payload，封装有效载荷）封装并修改，外层密报头设置消息类型字段区分协商包报文和数据包报文，并形成单通道协议，保留其安全参数索引（Security Parameter Index，SPI）、序列号（Sequence Number，SN）字段，确保安全联盟（Security Association，SA）的查找与抗重放功能实施。
内层封装参考 MPPE 协议的点对点二层隧道加密封装并修改，通过增加完整性校验值再加密的方式确保机密性和完整性。内层密报头去掉了所有 L2TP 头和 PPP 头的非必要字段（如 PPP协 议 头 部 Flag、Address、Control、FCS、Flag、Code 字段可弃用，Protocol 字段可隐含，L2TP 的T 字段等已不必要；会话号、序号字段也可弃用，依赖外层密报头及协商包即可确保字段功能的实现），保留与整合长度字段、类安全参数索引功能字段等。
数 据 部 分 明 确 只 承 载 私 网 IP 包， 借 鉴PPP 协议，可以按照最大传送单元（Maximum Transfer Unit，MTU）值拼接多个较短的 IP 包以提升小包转发性能。
3.2.2 协商协议改进
移动 VPN 的协商协议均需实现通信双方的身份认证、策略交换、密钥协商 3 大功能。受具体采用的算法套件、承载协议特性等因素影响，协商协议的设计是相对灵活的。理论上，借鉴 TCP 协议 3 次握手过程，通信双方既能确保可靠建链，又能最少 3 包即可完成协商过程，缺点是首包必有公钥密码运算，且不易应对 DoS 攻 击。例 如，RFC 标 准 的 IPSec IKEv1的主模式协商过程，至少交互 9 包才可建立一对 IPSec SA，缺点是效率较低。Hybrid VPN 主要针对小规模移动接入场景，规划专用算法套件，整合并改造了 L2TP 和 IPSec 的协商过程，如图 5 所示。
图 5 协商协议的工作流程示例
（1）身份认证方面。协商阶段采用基于身份的公钥机制，基于身份的系统中设备公开的身份信息是实体唯一标识，起着公钥的作用。特定的用户公开数据（如设备 ID）不需要明显地验证，如果用户的公开数据不正确，会导致后续的密码运算失败，例如导致双方产生的会话密钥不同、使业务包无法正确加脱密等情况。通信双方通过第 1 条、第 2 条、第 3 条消息交换设备 ID、Rand 随机数作为输入，即可获得共享的会话密钥，可派生出认证密钥（分量一）。第 3 条、第 4 条消息可利用认证密钥（分量一）对之前所有交互消息进行消息验证码（Message Authentication Code，MAC）计算，若验证通过，则认可对端设备身份。业务阶段将预置的共享密钥派生出业务阶段认证密钥（分量二）。业务阶段消息认证密钥利用分量一与分量二结合的方式对业务数据进行数据源认证和完整性保护，可以达到更高安全的认证要求。
（2）策略交换方面。明确采用客户 / 服务端通信模式，固定并统一密码套件。服务端在前3 条消息中完成对客户端身份认证后，移动终端的安全接入策略（如密钥滚动机制、重协商机制、私网 IP 地址、包起始序号、可访问的 IP 地址资源、分片大小等策略内容）由第 4 条消息加密推送，可确保客户端策略配置工作的高度安全、灵活受控。
（3）密钥协商方面。借助基于身份的公钥机制，第 1 条、第 2 条消息中明文传送的 Rand_a、Rand_b 随 机 数 与 第 3 条 消 息 中 加 密 传 递 的Rand_c 随机数共同确保随机性并生成会话密钥，再用于派生加密密钥。外层类 IPSec 单元使用协商产生加密密钥分量一作为加密密钥，内层类 L2TP 单元使用预制派生叠加协商产生的加密密钥分量二作为加密密钥。客户端外层单元主动与服务端进行身份认证、策略协商、密钥协商等过程，构建类 IPSec 加密隧道。随后将 SA 信息（如会话号、子网关联等）通知给本设备的内层单元，内层单元基于 SA 直接构建类 L2TP 加密隧道。
在接入设备公网侧 IP 地址因 Wi-Fi、4G、5G 网络切换而变更，信道通联不稳定，带宽不对称不稳定等场景下，对协商协议的协商成功率以及是否会触发频繁协商均有负面影响，因此有必要借鉴 SSL 会话重用技术，在 Hybrid VPN重协商条件未触发（如加密业务数据量未超过阈值、加密密钥使用未超期）而需要重接入的情况下，客户端能够主动发起重协商并运用会话重用技术迅速恢复业务密通。协商协议会话重用流程如图 6 所示。
图 6 协商协议会话重用流程
客户端发起重协商时，携带会话重用命令及相关身份信息、原会话号等信息与服务器通信，服务器接收后，在核实本地留存的内外层加密隧道与会话号关联的安全参数有效的情况下，响应客户端允许重用，并利用上一次协商出来的认证密钥（分量一）计算本轮交互信息的 MAC 值。客户端收到认证响应后，如果 MAC 值比对成功，说明服务器端身份可信，能够恢复使用原加密隧道安全参数，并构造协商确认消息发送给服务端，服务端同样通过验证 MAC 值的方式确认客户端身份可信。至此，双方能够恢复安全参数，从约定的报文序号重新继续加密服务。
4 结 语
在移动终端数据业务高安全通信方案的探索中，重点从接入设备的移动 VPN 协议如何改进的角度给出解决方案。本文提出的 Hybrid VPN 混合型 VPN 协议设计思路主要针对小规模移动接入场景，吸纳常见移动 VPN 协议优点，采用了预置方式结合基于身份的公钥协商方式的协商协议来产生相关密钥，确保内外层加密密钥产生方式不同，可进一步防范单层破防风险，采用了隐式与显式相结合的设备双向认证、双层加密、双层完整性保护、单层数据源认证、快速重协商机制等方法，兼顾了使用高效性与数据安全性需求。
鉴 于 国 内 5G 网 络 已 经 全 面 支 持 IPv4、IPv6 双栈并将长期并存，接入设备均能获得IPv6 的全局单播地址，其全局路由前缀、子网标识符、接口标识符均有标准定义、分配或产生。尽 管 Hybrid VPN 协 议 框 架 适 用 于 IPv4 和IPv6，但相对于运营商 IPv4 所具有的动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）、NAT、NAPT 等地址分配、转换机制，在 IPv6 环境下的单播地址极易被溯源，对高安全行业或企业构建移动VPN的安全性风险较大，因此在 IPv6 环境下的接入设备实现还待进一步权衡利弊。此外，从产品实践的角度还应综合考虑设备硬件架构安全、器件及操作系统的自主可控安全、设备组织运用安全、专用算法密码密钥保障安全等因素，全方位提升移动终端数据业务高安全通信能力，本方向待持续深入研究。
