基于SE Android结合远程控制提升移动系统安全性

杨中皇, 董伦铭

(高雄师范大学 软件工程与管理学系， 台湾 高雄 82444)



基于SE Android结合远程控制提升移动系统安全性

杨中皇, 董伦铭

(高雄师范大学 软件工程与管理学系， 台湾 高雄 82444)

修改Google公司和美国国家安全局合作发布的SE Android原始码，修改seadmin功能，结合远程控制设备应用程序权限，支持移动设备管理(MDM)功能，整合出适合企业使用的安卓(Android)设备控管系统。以控制设备应用程序权限的方式，可确保安卓设备运作，防止恶意攻击者窃取重要数据，维护移动设备安全。

移动设备；移动设备管理；权限管理；安全加强Linux；SE Android；系统安全

移动设备越来越普及，使用者经常将隐私数据储存至其中，故其系统安全性应被重视。根据IDC的调查结果[1]，2015年第一季度全球智慧型手机的出货量为3.344亿台，较2014年第一季度的2.883亿台成长了16%，其中搭载Android系统的智慧型手机占比78%。又根据市场研究机构Global WebIndex的调查报告[2]，从2012年开始，全球搭载Android系统的移动设备已从数量上超越搭载iOS系统的移动设备的，在全球被使用的移动设备中，2012年搭载Android系统的占比31%，搭载iOS系统的占比10%，而到2015年成长为Android系统占比54%和iOS系统占比18%。以上数据显示，Android系统最为普遍。然而，从移动安全方面考察，根据国际研究暨顾问机构Gartner的调查报告[3]，移动设备经常包含使用者的敏感信息，因此，应该加以保护。

在解决应用程序滥用移动设备敏感信息的相关研究中，Gilbert等人[4]发现，移动设备的第三方应用软件(third -party apps)可能滥用或不正当处理使用者的隐私信息，因此，提出了自动化安全验证系统AppInspector，该系统对移动设备的应用程序进行分析，并产生潜在的安全和隐私行为报告。Yang等人[5]建议，使用应用程序的Context来分析移动设备软件的恶意行为，因为，他们发现，移动设备的恶意软件可能通过模仿一般应用软件安全取用隐私或敏感信息的行为(如发送短信)，来逃避应用软件安全性分析检测，并控制恶意行为只发生在特定的时刻(如夜间)，这是由于，一般分析恶意软件的应用程序不太可能24小时运作。

以前两项工作为例，大部分相关研究都以分析应用程序恶意取用移动设备权限的行为来解决移动设备隐私数据的保护，使用者都需经过分析才能适时给予应对。另外，使用特定方法来检测恶意行为，虽然能检测出确定为恶意行为的机率已经很高，却并非全面。

为了解决恶意软件借由取得某些权限来获取使用者隐私信息的问题，不妨摒除对恶意软件分析的想法，直接提供使用者控管移动设备软件是否可以取得权限的方法，从而限制移动设备上个别软件取用的权限，或为所有软件限定一个是否可以取用的权限，来确保使用者隐私数据的安全，并结合远程控制，形成类似MDM的管理模式，以供管理域内移动设备或保护重要隐私数据者参考使用[6-7]。

使用由美国国家安全局(National Security Agency，NSA)以及Google发行的Android Open Source Project(AOSP)[8]，合作产生SE Android[9-12]的开放原始码，导出其特定的应用程序SE Admin，并分离出权限管理应用程序appops，之后，以eclipse程序编辑器新增一键管理所有设备上应用程序特定权限的功能。设备应用程序权限控管实现的过程并不经由SE Linux的MAC机制，但会受到MAC的限制，以确保实现过程不会受到刻意行为修改。此外，结合新增SSL/TLS安全通信协定的androRAT程序，可以达到远程控制的效果。由此，通过管理应用程序的权限，即可达到保护使用者隐私信息的目的。

开发Android智慧型行动设备控管系统，包含在设备上管理应用程序权限、远程管理设备应用程序权限、远程监控设备位置信息、远程发送警告信息、远程获取设备当前信息以及远程监控设备档案目录等功能，行动设备控管系统使用Java为主要之开发语言，并且系统使用图形化界面显示，使用者只需选择需要控管的界面并点击相关的功能按钮，即可执行各项功能。

1　SE Android与移动设备管理

1.1SE Android作业系统概述

1.1.1Android Open Source Project

Google对于Android的发展留有一个管道进行持续升级，但AOSP[8]还是要依系统的硬件性能作为判断依据。在AOSP中，Nexus作为标准点代表原生设备。大部分原始设备制造商(Original Equipment Manufacturer，OEM)借由AOSP开发属于自己的行动设备系统，如SONY、HTC、ASUS、Samsung，等等。另外，也有些公司借由修改AOSP来提升Android系统性能或安全性，并编译出ROM，放在网路上供他人下载使用，如CyanogenMod。

1.1.2Android安全增强内容

Android 4.3开始支持SE Android[12]的系统功能。SE Android将系统核心由原先的Linux核心修改为SE Linux核心，让原本的Android系统多了SE Linux的安全性机制，如强制存取机制。SE Android的最大特点在于，应用程序利用user或是root身份取用系统资源时，会先经由SELinux安全机制中制定的policy做筛选动作，若不通过即会被拒绝取用。SE Android系统架构[8]如图1所示，其中粗体所示为SE Android的修改内容，例如：系统应用新增了SE Admin应用，Settings应用中新增了支持SE Android的设定项目；另外，API以及JNI中也新增了支持SE Android的方法与指令；最后，将Linux修改为SE Linux kernel。

图1　SE Android系统架构

SE Android以AOSP原始码为例所做的修改内容如表1所示。AOSP/external/目录下新增修改了政策内容，AOSP/packages/apps/目录下有SEAdmin和Settings两项应用修改，AOSP/bionic /、AOSP/bootable/recovery/和AOSP/build/三项目录修改系统运行基础，最后，AOSP/ frameworks/base/以及AOSP/system/目录下的core/修改Android系统底层。

表1　SE Android修改的属性

1.1.3Recovery模式与OTA更新

Recovery模式[13]是一个较Android系统小的操作系统，一般用来执行不能直接在Android系统执行的命令，如系统OTA更新(包含只处理应用程序)或恢复出厂设置等功能。Recovery分区实现了Google公告的Android兼容性定义文档(CDD)要求关于操作系统升级的基本功能和使用的更新机制必须支持在不清除用户数据的情况下的升级。升级过程首先在主操作系统中下载一般为ZIP之压缩过的更新档案，然后，经由Recovery系统使用更新档案进行更新。另外，它还支持tethered更新，即用户将更新档案下载至台式机，再使用adb sideload OTAupdate.zip命令，将更新档案推送到设备的Recovery系统中进行更新。

一般来说，OTA[13]更新档案中包含操作系统开发者或开发商Google的签章文件，在更新过程中会验证此签章文件以确保目前使用的OTA更新档案是经由同一个开发者或开发商提供，如果验证不通过，更新将会失败。另外，在Android操作系统中，为了确保应用程序更新时也是由相同的开发者提供，Android操作系统在应用程序更新时也会验证在应用程序安装文件(.apk)中的签章文件，这也包含系统应用程序。但是，为了确保操作系统在运行过程中不会因为用户更改了system分区的内容使得操作系统出现错误，Android操作系统在运行过程中system分区处于read-only状态。由于Client端应用引用的API要求系统应用的权限，为了将Client端应用安装至system分区中，须经由Recovery系统推送，又因Recovery系统推送档案时必须验证开发者签章，所以，可考虑使用第三方开源的Recover系统TWRP，将Client端应用推送至操作系统system分区中。

TWRP是一个自定义recovery mode的开源项目(https://twrp.me/FAQ/)，一开始由4个人开发而成，后由类似于开发者论坛的模式，让许多人除错、更新和提出意见演化至今。自定义的recovery可以让开发者安装自定义的应用软件，甚至可以安装完整的ROM来更新或是修改Android设备的操作系统。

1.2Android SSL/TLS安全通信协定

使用SSLSocket[14]实现Server端与Client端之间信息的安全传输，其实是对Socket通信的的拓展，在socket通信的基础上添加了一层安全性保护，提供了更高的安全性，包括身份验证、数据加密以及完整性验证。其中，身份验证用于数字凭证的发放和应用；数据加密可以防止消息传递过程中被别人监听而造成的损失，即使第三方监听到传递的消息，但是由于没有正确的密钥，其仍然无法得到正确的消息完整性验证，以防止消息在传递过程中被别人修改。

1.2.1SSL/TLS安全通信基础

SSL/TLS通信握手基础的9个步骤如图2所示。

(1) 将客户端支持的SSL版本和加密算法等信息发送给服务器。

(2) 服务器确定本次通信采用的SSL版本和加密套件后，回复信息给客户端。

(3) 服务器将包含本身公钥的数字证书传送给客户端。

(4) 服务器发送初始完成信息，通知客户端SSL版本和加密套件协商结束，并开始进行密钥交换。

(5) 当客户端验证SSL服务器的证书合法后，利用服务器的证书中之公钥加密客户端随机生成的随机数(这是一个用在对称加密密钥的乱数)，并将消息发送给服务器。

(6) 客户端通知服务器后续传输信息时，将采用协商好的密钥和加密套件进行加密传输。

(7) 客户端计算已交互的握手信息的Hash值，利用协商好的密钥和加密算法处理Hash值，并发送给服务器。服务器利用同样的计算方式计算已交互的握手信息的Hash值，并与客户端传送过来的信息解密后比较，如果两者相同，则证明密钥和加密套件协商成功。

(8) 服务器通知客户端后续传输信息时，将采用协商好的密钥和加密套件进行加密传输。

(9) 服务器计算已交互的握手信息的Hash值，利用协商好的密钥和加密套件处理Hash值，并发送给客户端。客户端利用同样的方式计算已交互的握手信息的Hash值，并与服务器传送过来的信息解密后比较，如果两者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

图2　SSL安全传输机制握手基础

在客户端接收到服务器发送的Hash后，如果解密验证成功，则可以判断服务器是数字证书的拥有者，即服务器身份验证成功。这是因为,只有拥有私钥的服务器才能从Client Key Exchange消息中解密得到Premaster Secret，从而实现客户端对服务器的身份验证。

1.2.2SSL/TLS安全疑虑

2016年3月发布的DROWN(Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800)漏洞[14]，是利用过时、较弱的一种RSA加密算法来破解取得TLS协议中被该算法加密的沟通密钥。SSL v2发表于1995年2月，美国政府的管制条例使得SSLv2不得不采用弱化的加密算法。虽然，SSL v2只发表一年就被SSL v3取代，但许多私人服务器端并没有随着SSL的更新去改变配置，这导致直至现在依然存在许多支持SSL v2的服务器，当然也包含存在的漏洞。另外，RSA公钥原始算法利用的是余数计算，如c=memodN，其中(e，N)是算法之公钥，m是客户端要发送给服务器端的明文信息，为了确保明文的安全性，客户端用服务器端的公钥加密明文m为密文c，只有服务器端的私钥才能将c解密还原成明文m。但是，像这样原始的RSA算法的密文，可以被任意篡改且服务器端无法得知。比如，某中间人取得密文c，将其乘以某被公钥处理过的分数S(S=(1/5)emodN)得到c′，由于c′=Sc=(m/5)emodN，因此服务器用私钥解密得到的明文m将不是m，而是m除以5。

为改善此情况，SSL v2使用PKCS#1 v1.5规定的padding格式，以试图让服务器端可借由在明文中添加验证字节确保明文的完整性，在服务器端用私钥解密密文时，就算该密文已被修改过，服务器端也可比对添加的验证字节来得知明文是否被篡改，若确定已被篡改则被服务器拒绝并回复信息。但是，只是让服务器端得知是否被篡改，仍无法改变明文已被篡改的事实，并且，这样的方式依然存在一定的机率，在篡改拦截的密文时不会更动到验证字节，导致服务器端对密文完整性判断出现错误，误以为已被篡改的密文没被篡改。因此，攻击者利用此现象，通过对服务器发送大量的伪造密文，并根据服务器的大量回复(Yes or No)，即可在大量交互过程中获得解密信息。

1994年，Bellare-Rogaway提出了RSA Optimal Asymmetric Encryption Padding(OAEP)padding格式。OAEP采用由Shannon提出的对称式加密算法Substitution-Permutation Network(SP-Network)构造，彻底破坏了原始RSA算法密文与明文之间的乘法相关构造，服务器可以从解密结果明确得知解密的明文是来自于真正的加密者，而非来自于攻击者；使用OAEP算法，如果服务器判定正确，攻击者也无法得知发送的伪造密文究竟是Yes还是No，反之服务器如判定解密无效，即可安全终止协议，使攻击者无法借助大量尝试取得明文信息。使用RSA OAEP padding后，所有利用乘法相关问题的攻击技巧全都失效。1998年10月，RSA PKCS#1 v2 padding采用的即是RSA OAEP padding。

Android最初于2007年推出系统第一版，并不会有因为支持较旧的SSL版本而产生的漏洞，而且，Android操作系统还提供SSL/TLS安全传输协定的API，支持开发者指定在通信协定使用的算法padding格式，同时也包含OAEP padding格式。如此，开发者可借由对安全传输协定指定OAEP padding格式来确保安全传输协定密文之完整性，而不会因为前述漏洞的存在导致明文被攻击者取得。

1.3移动设备管理概述

移动设备管理 (Mobile Device Management, MDM)[6,15]指在公司行政业务范围内对移动设备，如智慧型手机、平板电脑和笔记型电脑，进行部署、保护、监测、集成和管理。MDM的意图是优化企业内部移动设备的安全性，确保企业重要信息即使放在员工自行携带的移动设备中也能受到适时监控，使企业资讯不会外泄，以提升安全性。

2　系统架构与开发

2.1系统架构

系统由安装于移动设备上的应用程序Client端以及电脑上的远程控制Server端所组成，如图3所示。

图3　远程设备控管系统架构

Client端主要进行移动设备的权限管理与连接设定，使用者可以由此部分得知设备上每个应用程序要求的权限，并管理特定应用要求的权限，或以权限名称为主，管理所有应用程序的特定权限，并可设定待连接Server的信息以实现远程控制功能。

远程控制Server端则提供4个操作界面：

(1) “取得信息控制界面”可以显示移动设备的信息，如Wifi状态、3G/4G网络状态、系统版本和电池状态，同时可对设备发出警告信息与震动；

(2) “取得位址控制界面”可以借由设备的GPS芯片或行动网络取得设备所在位址，并利用简易的地图显示出来；

(3) “取得目录控制界面”可以取得移动设备的档案系统目录结构，并可下载设备上的档案；

(4) “应用权限控制界面”可以远程管理移动设备某一特定权限，让设备上所有应用无法取用以确保隐私数据的泄漏。

移动设备第三方应用程序的恶意行为可能取得使用者的隐私数据[16]，但应用程序如需要取得设备上的数据，就必须具有相应权限，故系统借由管理权限来保护设备的隐私信息，并经实测确定可以限制应用程序要求的权限不被取用。

2.2系统开发

系统由跨平台程序语言Java设计,并针对Android的第三方远程控制开源软件AndroRAT(Remote Administration Tool，RAT)修改而成，如表2所示。因为是由Java开发，server平台只要有支持安装Java的电脑环境皆可运行；APP端在Eclipse上使用Java结合Android开发工具(Android Developer Tools，ADT)与Google Android APIs开发而成。API中又以AppOpsManager和SSLSocket最为重要。

表2　系统开发与测试环境

AppOpsManager包含Android设备权限管理的所有方法，如表3所示。由于AppOpsManager仅支持SE Android系统环境,仅提供系统应程序取用，故新系统APP端必须运行在Android 4.3以后的版本，利用第三方开源recovery系统备份还原软件TWRP，将APP端打包成支持Recovery Mode的OTA更新文件格式(*.zip)，安装至系统应用的目录下。为了在不修改原始系统的前提下运行TWRP，使用SDK工具包的fastboot指令让TWRP的镜像可借由外部储存区在设备上开启。然而，在此过程中，设备必须解锁Bootloader，故只有将其列为研究限制。

SSLSocket API的重要性来源于远程控制应用程序开源码在传送信息时的安全性。将原来仅使用一般传输协定Socket修改为附加上SSl安全协定的SSlSocket，使得传送信息时必须包含密钥认证，从而可识别Client和Server端的身份，达到预防网络传输时可能发生的中间人攻击。另外，密钥可借由Ubuntu操作系统预载工具Keytool，产生长度预设为1 024位的密钥，若想改变生成密钥长度，可以借由指令设定。

表3　AppOpsManager权限对照

续表3　AppOpsManager权限对照

3　系统测试与结果

3.1Android 6.0权限管理与新系统

所开发系统能以简洁的GUI和简易的操作方法，提供使用者在APP Client端快速管理设备应用程序的权限，也可利用远程联机方式，在Server端监控与管理设备的信息与权限。使用者在Android设备上完成APP的OTA安装后，即可开始使用此系统。相关流程如图4所示。

图4　Client系统流程

2015年10月发布的Android 6.0，在系统设定的应用中新增了权限管理功能，其与所开发的新系统的差别如表4所示。

表4　Android 6.0权限管理应用与新系统功能对比

3.2Client端执行结果

APP开始执行时，会出现如图5(a)所示的执行画面；使用者只需滑动页面，选择被取用的权限类别，分别为LOCATION、PERSONAL、MESSAGING、MEDIA和DEVICE，选择其中一个应用管理其权限，如图5(b)所示。

图5　单一应用权限管理画面

如果使用者想切换模式,可以点击主画面右上的MENU键,如图6所示，主要功能选项分别为PermmissionManager以及RemoteSet两者。

图6　模式选择画面

当使用者选择“PermissionManager”选项时，即可进入一次管理所有应用程序特定权限的画面，或使用者选择『RemoteSet』选项时，即可设定与远程server的联机IP以及Port，如图7所示。

图7　应用权限与远程设定画面

3.3Server端执行结果

使用者在APP端设定完联机后，即可在Server端看到联机的设备以及设备的基本信息,如图8所示。此时，点击设备信息的图标，进入设备管理画面。管理画面分别有Home，Permission manager，Map，以及File tree。

进入设备管理画面,首先会看到Home画面,如图9所示。这里显示当前设备的详细信息，如Android系统信息、网路连线信息以及设备信息。另外，在这里可以远程对设备发出警告信息以及震动，当设备遗失时可对拾获设备的人提出警示信息。

Permission manager画面显示了43项行动设备应用程序权限，如图10所示，以提供管理者对联机设备上所有应用的特定权限控管。新系统仅提供以权限为主体对设备上所有应用的权限管理，是因为系统Server端可以连接多个设备，且其上的应用也是未知数，如实作针对单一应用的权限管理，可能造成管理者控管权限的困难。

Map画面和File tree画面延用原AndroRAT的画面。Map可以获取设备由网络或GPS取得的位址信息，并在画面的左边显示地图，以方便管理者监控受到控管的行动设备。File tree可以获取联机设备的档案目录以及下载指定的档案至设定好的路径位址，也就是在画面右下方的文字输入方块输入路径位址即可。

综上可见新系统的设计意图，就是使管理者能保护受到管制的行动设备里的内部资料不被恶意修改，从而提升行动安全。

图8　远程Server选择连接设备画面

图9　设备管理的主画面

图10　远程应用权限管理画面

4　结语

以移动设备管理为基础，对照Google Android API AppOpsManager所提供的权限项目，开发出一套监控及权限管理系统，可以限制第三方应用可能对设备上隐私数据的窃取或不正当使用；借由修改AndroRAT原始码的传输协定，能使其在传送信息时确保信息安全，改善系统远程设备控管的安全性。

设计开发的新系统已能在由美国国家安全局建议与开发的SE Android系统中运作。新系统以远程权限控管为主轴开发，比市面上的移动设备管理系统呈现出新的功能，但对于完整的保护、监控与集成还需要完善。此外，新系统以新增安全传输协定来认证Server身份，并能使信息以加密状态传输，但由于未能让Server针对Client身份做验证，可能无法防止攻击者使用类似拒绝服务(Denial of Service，DoS)攻击，恶意新增过多的Client会导致Server崩溃。

[1]IDC. Smartphone OS Market Share, 2015 Q2[EB/OL]. [2016-04-03]. http://www.idc.com/prodserv/smartphone-os-market-share.jsp.

[2]GLOBALWEBINDEX. Android mobile now has huge lead over iOS[EB/OL]. [2016-04-03]. http://www.globalwebindex.net/blog/android-mobile-now-has-huge-lead-over-ios.

[3]GARTNER. Mobile Device Security: A Comparison of Platforms[EB/OL].[2016-04-03].https://www.gartner.com/doc/2988420.

[4]GILBERT P, CHUN B G, COX L P, et al. Automated Security Validation of Mobile Apps at App Markets[C/OL]//MCS '11 Proceedings of the second international workshop on Mobile cloud computing and services. New York: ACM, 2011:21-26[2016-04-05].http://dx.doi.org/10.1145/1999732.1999740.

[5]YANG W, XIAO X S, ANDOW B, et al. AppContext: Differentiating Malicious and Benign Mobile App Behaviors Using Context[C/OL〗//2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (Volume:1). Florence: IEEE, 2015:303-313[2016-04-06].http://dx.doi.org/10.1109/ICSE.2015.50.

[6]RHEE K, JEON W, WON D. Security Requirements of a Mobile Device Management System[J/OL]. International Journal of Security and Its Applications, 2012,6(2):353-358[2016-05-01].http://sersc.org/journals/IJSIA/vol6_no2_2012/49.pdf.

[7]LIU L, MOULIC R, SHEA D. Cloud Service Portal for Mobile Device Management[C/OL]//2010 IEEE 7th International Conference on e-Business Engineering (ICEBE).Shanghai:IEEE, 2010, 474-478[2016-05-01].http://dx.doi.org/10.1109/ICEBE.2010.102.

[8]YAGHMOUR K, Embedded Android[M/OL]. Sebastopol: O’Reilly Media, 2013:79-105[2016-05-20].http://www.gbv.de/dms/tib-ub-hannover/684154994.pdf.

[9]VERMEULEN S. SELinux System Administration[M/OL]. Mumbai: Packt Publishing, 2013：7-24[2016-05-05].http://dl.acm.org/citation.cfm?id=2566830.

[10] HAINES R. The SELinux Notebook(4th Edition)[M/OL].[2016-05-05〗. http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf.

[11] NATIONAL SECURITY AGENCY. SELinux Frequently Asked Questions (FAQ)[EB/OL]. [2016-05-05].https://www.nsa.gov/research/selinux/faqs.shtml.

[12] SMALLEY S, CRAIG R. Security Enhanced (SE) Android: Bringing Flexible MAC to Android[C/OL〗.[2016-05-05]. http://www.internetsociety.org/sites/default/files/02_4.pdf.

[13] ELENKOV N. Android Security Internals[M]. San Francisco: Oreilly & Associates Inc, 2015:349-376.

[14] AVIRAM N, SCHINZEL S, SOMOROVSKY J, et al. DROWN: Breaking TLS using SSLv2[EB/OL]. [2016-06-20]. https://drownattack.com/drown-attack-paper.pdf.

[15] MILLER K W, VOAS J, HURLBURT G F. BYOD: Security and Privacy Considerations[J/OL]. IT Professional, 2012,14(5):53-55[2016-06-06].http://dx.doi.org/10.1109/MITP.2012.93.

[16] BACKES M, BUQIEL S, GERLING S, et al. Android Security Framework: extensible multi-layered access control on Android[C/OL]//ACSAC’14 Proceedings of the 30th Annual Computer Security Applications Conference. New York: ACM, 2014, 46-55[2016-06-06]. http://dx.doi.org/10.1145/2664243.2664265.

[责任编辑:陈文学]

A remote control system for improves the mobile device security based on SE Android

YANG Chunghuang,TUNG Lunming

(Department of Software Engineering and Management, National Kaohsiung Normal University, Kaohsiung 82444, Taiwan)

In order to manage permission systems of mobile devices to protect privacy information from malicious attacks, the Android Open Source Project (AOSP), extensible security framework “SE Android”, is introduced, which is developed by Google and National Security Agency (NSA) together. SE Android provides a security application that supports Android systems of permission management. the seadmin application combined with remote service is modified to form remote control software that provides additional security features as a mobile device management (MDM) system.

mobile devices, mobile device management, permission management, SE Linux, SE Android, system security

2016-07-01

(台湾)“科技部”资助項目(MOST 102-2221-E-017-003-MY3)

杨中皇 (1958-)，男，博士，教授，从事移动终端安全研究。E-mail: chyang@nknu.edu.tw

董伦铭(1990-)，男，硕士研究生，研究方向为网络信息安全。E-mail: k49918135@gmail.com

10.13682/j.issn.2095-6533.2016.05.001

TP309

A

2095-6533(2016)05-0001-10