移动互联网的安全防护方法探索与研究

宋啸天 石力 胡向涛

1.江苏省镇江市审计局；2.江苏省镇江市公安局京口分局；3.江苏省镇江市润清苑管理服务中心

0 引言

2017年1月，中共中央办公厅和国务院办公厅印发《关于促进移动互联网健康有序发展的意见》，提出防范移动互联网安全风险。移动互联网的安全问题愈加被人们所重视。

本文认为，移动互联网中的安全问题可以归纳为以下三个方面：

一是网络安全。指移动通信网络自身的安全，以及移动用户与终端应用进行信息交互时的安全。移动通信网络自身的安全主要包含网络的设计方法、透明原则和拓扑结构等。一个具备良好安全性的网络应当是恶意第三方无法针对节点发起攻击。移动用户与终端应用进行信息交互时，需要业务的具体提供方具备较为严格的认证和鉴权机制，才能在一定程度上保障用户的信息不受威胁。

二是终端安全。指移动终端本身的安全性，如操作系统是否存在安全漏洞，这些安全漏洞是否会遭受第三方的恶意入侵。

三是位置安全。对于安全要求级别较高的工作而言，为强化工作的属地性，应对工作的移动办公地理位置进行安全管控，防止信息泄露于监管范围之外。

同时我们需要认识到，由于移动互联网的空中开放性，移动终端的用户必然会面临数据窃听、篡改等风险，更有甚者可以通过干涉协议和物理要素来阻断服务和业务，这是首要考虑的重要问题之一。因为一旦发生安全事故，如信息窃取者编写恶意API（Application Programming Interface，应用程序编程接口）窃取手机信息，将可能对工作带来无法弥补的严重后果。所以，移动互联网的信息安全问题日渐凸显，本文认为，只有解决好移动环境下的信息安全问题，才能够使移动互联网更好地发挥作用。

本文针对移动互联网的安全问题，设计了一个面向移动互联网的安全防护方法，该方法从网络、终端和位置三个层面，展开了各具针对性的信息防护方式，旨在为移动互联网中的安全防护提供一定的参考。

1 基于HOTP的身份认证防护方法

1.1 设计思路

HOTP（HMAC-Based One-Time Password Algorithm，基于HMAC的一次性口令算法）是一种由OATH组织提出的OTP（One-Time Password，动态口令）算法标准，主要应用于传统网络下的各类服务、路由及强认证等领域。其算法示意图如下所示。

图1 HOTP算法示意图

其中，Key为共享密钥，通常是由服务器下发的共享强密钥；Count为计数器值，通过递增的逻辑计算得到HOTP结果；HS1为运用HMAC-SHA-1（一种由SHA1哈希函数构建而成的键控算法）对Key和Count进行加密的模块，输出HMAC-SHA-1（Key，Count）；DT为运用DT函数对模块A的输出结果进行十进制转换的模块，并输出HOTP的结果（HOTP_Client）。

在进行HOTP的验证时，服务器根据Key和Count的数值计算得到HOTP值（HOTP_Server），随后比较获取到的HOTP_Client，并依据比较情况实施4种操作：

一是不等情况。此时服务器会自动生成一个重同步的进程，发送至终端要求进行下一次认证的提交操作。

二是相等情况。服务器认证用户通过，服务器的计数器数值加1；

三是不等情况下重新同步再次失败。若终端的请求次数小于服务器设置的最大认证阈值，则继续要求终端提交下一次认证。

四是不等情况下同步失败次数已达服务器设置的最大阈值。服务器通知用户认证失败并实施用户锁定操作。

HOTP的优势主要有以下三点：

一是密钥由不确定的单项散列函数生成，确保密码的一次性；

二是HOTP模式下的通信的数据量和次数均较低，适用于移动互联网；

三是HOTP本身算法较易实现，可匹配目前绝大多数移动终端。

在移动互联网中，信息安全的核心问题之一就是身份的认证及鉴权。

一是身份认证。指移动终端使用者对外声称的身份是否与真实身份相同。由于用户权限的鉴权建立在身份认证的有效识别上，所以身份认证是鉴权的基础。

二是鉴权。指通过身份认证的用户在请求某项信息的权限时，其是否确实拥有操作权限。

在移动互联网中，信息以数字信号的形式进行传输，同时移动终端及用户基本为一对一的关系，所以加密方便、认证实现较为简单。但同时也有着信息可靠性较低、计算能力及存储能力不足、续航能力较差等缺点。本文结合移动互联网下的各项优缺点及移动互联网下业务的新型特点，设计了一种基于HOTP的身份认证防护方法，在用户认证过程中加入一定的动态要素，实现密码的动态变换，提高用户登录的安全性。

1.2 基于HOTP的认证机制算法

对于每个不同的终端，对其中的各项应用设置一个独立的HOTP值，服务器在校验HOTP值后获取用户的合法信息。在认证开始前，移动终端需要和服务器建立一个共享密钥，与计数器共同作为算法的输入要素。本文设计的基于HOTP的认证机制算法在原有HOTP的框架基础上，实施了针对移动互联网特性的改进，改进后的算法如下图所示。

图2 基于HOTP的改进认证机制算法

其中，Key为共享密钥；Count为计数器值；HS256为SHA-256加 密 模 块， 输 出 HMAC-SHA-256（Key，Count）；T为字符转换模块，输出Tru（H），经过Base64编码后得到最终的HOTP值。

具体步骤如下：

步骤一：根据Key和Count的值输出HMAC-SHA-256（K，C）；

步骤二：利用截断获取T值，其中，H={H（0）,H（1）,…H（31）}，H（n）为H的第n个字符，取H（31）的末4位，输出B_Set（十进制数），0

步骤三：将第三步中输出的P值转换为字符P_Set，0

步骤四：输出HOTP初始值，HOTP=P_Set×mod10num_HOTP。其中，6≤num_HOTP≤8；

步骤五：为提高信息传输的安全可靠性，最终将HOTP进行Base64编码，生成最终的HOTP值，HOTPend=Base64（HOTP）。

由于计数器Count值可能在实际应用中发生偏移（终端计数大于服务器计数或终端计数小于服务器计数），本文设计了一个面向窗口值的容错算法。具体操作步骤如下：

步骤一：计算移动终端与服务器之间计数器的差值极限（极限窗口），如下式所示：

Req_Max ＞ |Req_Server-Req_Client| （式 1）

其中，Req_Max为极限窗口值，Req_Server为服务器计数器值，Req_Client为移动终端计数器值。

步骤二：移动终端发出Req_Client请求；

步骤三：当Req_Client在窗口范围内时，服务器校验成功；

步骤四：服务器采用Req_Client进行用户的身份认证，不更新Req_Server。

由上述算法中可以看出，Req_Max越小，业务整体的安全性越高，这是由于窗口的缩小降低了伪造请求的可能，增强了机制的容错性能。但是需要注意的是，Req_Max并不是越小越好，而是要根据网络实际环境、业务吞吐量等因素进行综合分析，才能达到效率与安全的统一。

但是Req_Max的引入，使得HOTP较容易遭受重放攻击。对此本文设计了面向偏移量和历史请求值的双重安全加固方法。其中，偏移量指业务两端计数器的绝对差值，本文中表示为REQ_Dev，计算次数与终端的认证请求数相同（每次认证计算一次），表达式如下：

Req_Dev=|Req_Server-Req_Client| （式 2）

历史请求值是指在Req_Max内已被终端用户选用过的Req_Client值的集合，本文中表示为Req_Used。一般情况下，由于Req_Max＜32，所以Req_Used可以表示为32bits的整数值。当Req_Client在Req_Max的窗口范围内时，Req_Used的Req_Dev位的值标记为1（代表该C值已使用），可以表示为：

Req_Used（Req_Dev）=1 （式 3）

认证Req_Client可以分为以下四种情况进行考虑：

情况一：Req_Client＜Req_Server，且Req_Client超出Req_Max范围。

服务器判断终端的计数值无效，并反馈错误报告。

情况二：Req_Client＜Req_Server，且Req_Client未超出Req_Max范围。

服务器判断Req_Client是否存在于Req_Dev中，若不存在，则验证成功，随后计算HOTP值并进行认证；反之则反馈错误报告。

情况三：Req_Client＞Req_Server。

服务器验证成功，并计算HOTP值，置Req_Client<

情况四：Req_Client=Req_Server。

服务器判断该终端发起重放攻击，记录日志并反馈错误报告。

1.3 安全性分析

本文设计的网络环境下基于HOTP的身份认证防护方法具备强密钥及防御重放攻击的能力，使得恶意第三方无法通过窃取某次的HOTP值实现移动终端的认证操作。同时，由于HOTP值在线性上是无关的，所以恶意第三方也无法通过推算来获取到某一节点下一时刻可能出现的HOTP值。

传统的HOTP认证结构大多采用的是HMAC-SHA-1，本文设计了一种应用HMAC-SHA-256的HOTP认证结构，破解难度大，安全性与传统的HOTP认证结构相比有较为显著的提升。将本文设计的网络环境下基于HOTP的身份认证防护方法与消息验证码MAC（Message Authentication Codes）防护方法、TIMESTAMP（时间戳，用于验证数据的存在性、有效性和完整性）、应用密钥一次下发及双向对比等方法相结合，可以针对移动业务提供较为全面的防护，提升业务的安全可靠性。

2 基于移动终端的安全防护方法

2.1 方法流程

移动终端作为接入业务服务的媒介之一，其安全性在一定程度上影响着业务能否长期平稳有效运转。所以，本文认为，移动化不仅需要配备专属的移动终端，同时还需要针对移动终端设计一套安全策略。

策略下发流程如下图所示。

图3 基于移动终端的安全管理策略流程图

基本流程如下：

步骤一：移动终端安装安全策略管理程序，程序安装完成后自动设为静默开机启动，权限等级最高。

步骤二：判断程序的运行次数。若首次运行，则采集用户信息进行注册；否则进入后台启动运行并开启进程保护功能。

步骤三：手机移动终端上相关的硬件信息和软件信息，上传至安全策略管理数据库。

步骤四：服务器下发策略配置文件，移动终端将配置文件保存在本地文件夹之中，并写保护。

步骤五：初始化并执行策略，监听服务。

步骤六：移动终端接收到新策略后进行策略对比。若相同，则忽略策略更新，否则停止旧策略，导入新策略后运行新策略。

需要注意的是，由于策略模块具有唯一性，所以当策略模块过多时，一次性将其纳入主体框架结构将严重影响程序的运转效率，资源利用率低。对此，本文设计的基于移动终端的安全管理方法采用动态类加载技术（获取类加载器并loadClass方法）。该方法仅将策略模块的JAR（Java Archive，Java归档文件）包加载到主体框架之中，策略在调用之时，根据策略对应的ID（标识号）信息实现实时调用，进而提供对应的策略服务。此方法结构灵活、便于操作，后期扩展性较强。

2.2 安全防护策略

由于移动终端与PC终端相比，在存储空间及硬件水平等方面均存在一定的差距，所以本文针对移动终端的特性，设计了十三种安全策略，分别是：

（1）通讯防护策略

主要用于控制移动终端的各类对外通讯方式，包括2/3/4G、WIFI模块、蓝牙通信等。当终端在特定时间段之外使用通讯功能时，可以自动停用服务，并生成日志上传至防护记录服务器。

（2）病毒防护策略

由于移动终端的普及，针对移动终端的各类病毒、木马也层出不穷。对此，针对移动业务，防护策略应当做到实时/定时对设备进行病毒检查、记录、消除以及路径回溯，并及时更新病毒库，确保移动终端的使用安全。

（3）软件防护策略

原则上，安装有特殊应用的移动终端，应当做到专机专用。因此，防护策略在检测到移动终端安装应用时，首先与应用白名单进行比对，若比对通过，则安装应用并记录上传相关信息；否则取消安装，并上传告警日志至防护记录服务器。

（4）浏览器防护策略

移动终端启用浏览器服务访问网络时，将访问地址与访问白名单进行比对，若地址存在于白名单之中，则允许访问并记录上传缓存信息；否则禁止访问，并上传告警日志至防护记录服务器。

（5）SIM卡（Subscriber Identi fi cation Module，用户身份识别卡）防护策略

防护策略能够对移动终端使用的SIM卡进行监测，用户在首次运行应用时，系统自动将SIM卡与设备进行绑定，之后有任意一端发生变动，均视为非法操作，系统自动锁定终端并上传告警日志至防护记录服务器。

（6）注销防护策略

当移动终端因为某种原因不再使用或报废时，服务器注销或转移与该终端相关的所有信息，同时停止下发策略并进行全网更新。

（7）用户防护策略

用户防护策略除了最基本的账号密码防护外，还应具备多用户防护策略，即同一设备上多个不同用户进行访问应用业务时，需要移动终端归属人授权，否则视为非法操作，锁定终端并上传告警日志至防护记录服务器。

（8）环境防护策略

在首次运行各项应用前，对移动终端的硬件环境及软件环境进行全方位扫描，检测设备的SD卡、ROOT情况、安装环境与要求环境是否吻合等，若不满足安装条件，则停止服务并告知使用者问题节点及修正方案。

（9）流量防护策略

自动检测移动终端的流量使用情况，将某一时间周期内的流量使用情况与提供服务的实际流量消耗量阈值进行比对，若存在异常流量消耗，则锁定终端、停止服务并上传异常流量行为记录至防护记录服务器。

（10）存储防护策略

记录移动终端的文件传输行为，如USB传输、特定应用局域网传输等，并将传输双方的信息记录于本地LOG，随后上传至防护记录服务器。

（11）应用防护策略

移动终端在安装相关应用时，应由管理员通过正则表达式（防止管理员下发非法路径）进行统一调配、下发，并根据反馈的安装情况确定应用配置的实际效果，便于对移动终端的应用进行集中管理，如下图所示。

图4 应用交互流程示意图

（12）信息防护策略

对移动终端接收、发送的短信及电话进行记录，同时对服务器与终端交互的信息进行加密，确保信息不会产生泄漏风险。

（13）设备加速策略

能够对移动终端的内存、缓存进行自动/手动清洗，提升系统性能、释放设备资源、降低安全隐患。

本文认为，上述策略在实际操作过程中应使用分布式系统，将整个系统分解为各个功能模块，便于管理及后续的开发、更新。

3 面向可信位置的安全防护方法

3.1 设计方法

随着移动终端在互联网中的不断接入，网络资源已经跨越时空的阻隔实现了共享。位置信息的共享易导致安全问题，泄漏信息。本文认为应当对能够使用移动应用的地理位置做一定限制，尽管这样做有悖于“随处可用”的思路，但也能在一定程度上位置信息被恶意窃取；而且，有的恶意第三方也可通过位置信息发起系统攻击。

因此，本文设计了一种面向可信位置的安全防护方法，用于提升移动终端的位置安全性及利用率。

图5 LBAC模型示意图

如上图所示，在LBAC中，箭头为“一对多”的逻辑关系，箭头出发端为“一”，指向端为“多”。例如，位置→客体，指一个位置能够对应多个客体，但一个客体只能在某一时刻对应一个位置。Control和Contain分别表示安全等级和位置是从高级别至低级别的支配和包含关系。

在LBAC（Location-Based Access Control，位置访问控制）模型的基础上，本文针对该模型位置信息传输安全性较低的问题，提出了一种改进的可信位置防护方法，通过构建T-LBAC（Trusted-Location-Based Access Control，可信的位置访问控制）模型来确保位置信息的可信度。

首先构建可信度函数，表示为Yt→{0,1}，Yt的取值为0或1。当获取的位置来源于可信位置模块时，Yt=1；否则Yt=0。

随后结合主客体双方的安全等级以及可信位置的安全等级设置强访问策略，以代替LBAC模型中缺少位置可靠性的弱访问策略。可信位置与访问原则如表1所示。

表1 可信位置与访问原则表

表中，主位表示主体位置，主体表示对其它实体进行操作的实体；客位表示客体位置，客体表示被主体施加操作的实体。其中，可信主位能够读可信/不可信客位，可信/非可信主位能够写可信客位。

主体对客体实施写操作时，限制条件有以下四个，分别是：

条件一：主客体安全等级相同；

条件二：客位可信度=1；

条件三：主客体的许可访问列表分别包含主客可信位；

条件四：主客体的可读访问位置的安全等级分别支配主客体的安全等级。

主体对客体实施读操作时，限制条件有以下四个，分别是：

条件一：主体安全等级大于客体安全等级；

条件二：主位可信度=1；

条件三：主客位的许可访问列表包含主客位可信位置；

条件四：主客体的可读访问位置的安全等级分别支配主客体的安全等级。

其中，主客体的安全等级表示安全性能的集合，主体的安全等级指主体能够访问的信息类别范围，客体的安全等级指客体所包含的信息类别范围。位置安全等级与主客体安全等级类似，指进入某一位置所必须的安全范畴（一般分为四个范畴），并且由位置集合中所有元素的安全等级共同决定。原则上，不论是主客体还是位置，均是由高级别安全等级向低级别安全等级单向流动的信息流，从而确保流程中的信息不会泄露。

读写控制原则如下表所示。

表2 读写控制原则表

其中，主位可信度表示为Y_S，客位可信度表示为Y_B，主体安全等级表示为G_S，客体安全等级表示为G_B。

3.2 改进优势说明

在本文提出的面向可信位置的安全防护方法中，由于引进了可信位置参数，所以业务应用安全性有了一定的提升，主要体现在以下三个方面：

一是避免遭受位置欺骗类型的恶意攻击。TLBAC模型约束于可信位置的加密信息传输，较LBAC模型能够确保授权主体的真实性，非授权主体无法通过伪造位置来发起攻击。

二是确保位置信息的完整保密。TLBAC模型中的可信位置由对应的模块及算法计算得出，无法经由第三方伪造、篡改。对于第三方而言，在窃取到当前时刻的位置信息时，也无法将伪造的信息传输给主体。

三是安全扩展性能强。可信计算应用于位置信息的安全防护只是该方法的运用方式之一，TLBAC模型在此基础上能够进行深度扩展，进一步完善业务整体的安全性。

4 结语

本文设计的面向移动互联网的安全防护方法从理论层面上为移动互联网中的安全防护方法提供了一定的参考，实用性较高。但在实际应用中，还需要考虑诸如连接数超限、端口非法占用、硬件断电、网络连接异常等问题所带来的影响。所以，在方案部署之时还需要进行深入调研，并思考多级冗余备份等辅助支撑方法的可行性。此外，随着混合云技术的不断发展和IT资源的集中化、服务化，混合云环境下的移动应用也会得到一定的增长和完善。本文将继续研究混合云技术下的移动互联网安全问题，针对混合云，积极思考面向移动互联网的安全防护框架体系，努力为今后混合云的发展建设提供技术参考。