1. 引言
移动终端的可信性已成为互联网时代的重要挑战。Android系统基于Linux内核,其开放源代码的特性虽然促进了定制化开发,但也引入了诸多安全隐患。据统计,Linux系统每年有近百个漏洞被CVE收录,攻击者常利用这些漏洞实施恶意行为。此外,Android平台缺乏严格的第三方审查机制,进一步加剧了其安全风险。
移动终端存储了大量敏感信息,一旦被恶意代码入侵,可能导致用户隐私泄露和财产损失。尽管用户安全意识有所提升,但隐蔽性强的恶意软件仍能绕过传统防护手段。因此,从底层硬件环境入手,构建可信的移动终端架构,成为解决安全问题的关键。可信计算技术通过建立信任传递体系,为终端平台的可信性提供了理论支撑。
为此,论文基于可信计算思想,重点针对影响Android终端性能的硬件环境(如CPU、内存和电池)进行实时监测与评估,为移动终端平台的安全解决方案提供技术支撑。
2. 移动可信计算技术
移动智能终端面对的是一个开放性的使用环境,受到的攻击风险种类繁多而且不断进化,针对移动智能终端不断出现的安全问题,在传统安全防护技术基础上,具备主动防御能力的可信计算技术成为了移动安全领域一个新的研究热点。
可信计算的概念最早由美国国防部1983年在其制定的《可信计算机系统评价准则》中第一次提出。随后,Microsoft、Intel、IBM等IT巨头公司于1999年领头发起和成立了可信计算平台联盟(TCPA),并在2003年将其正式更名为可信计算组织TCG (Trusted Computing Group) [1],TCG发布了一系列可信计算标准,介绍了如何利用可信平台模块(TPM)提供的各种功能来保护系统平台的安全。国内1992年正式在可信计算领域立项并开始研究。2004年10月,武汉大学和瑞达公司合作研制出我国第一款自主研制的可信计算平台。2008年中国可信计算联盟(CTCU)成立。随后各大公司推出了各自的可信产品,如兆日公司的可信计算机密码模块芯片、中兴集成电路公司的可信计算支撑平台等,并且都获得了国家密码管理局的认证。
与传统的安全防护技术相比,可信计算是指在运算的同时进行安全防护,使计算结果总是与预期相一致,计算全程可测可控,是一种运算与防护并存的主动免疫的计算模式。可信计算在移动智能终端安全研究中得到了极大的关注,取得了一系列成果。
2005年TCG附属移动电话工作组MPWG (Mobile Phone Work Group)发布了移动电话工作组白皮书,对可信计算应用在移动领域进行了展望和案例分析。欧洲国家于2006年开始了名为“开放式可信计算(Open Trusted Computing)”的研究计划,该计划基于TPM构建统一安全体系,实现安全的电子交易、家用协同计算以及虚拟数据中心等多个应用[2]。2007年MPWG发布了移动可信模块MTM (Mobile Trusted Module)规范,主要目的是为适应移动设备的特点,在移动平台上构建可信技术架构,为高端的移动设备提供安全保证。随着移动可信计算技术不断发展和成熟,许多外国学者开始研究可信移动平台的构建。
与依赖底层硬件隔离不同,另一类研究聚焦于通过系统级接口采集终端在运行过程中的性能状态,以此构建轻量级的安全评估与行为检测模型。该类方法强调部署简便性与对终端资源消耗的最小化开销,适用于资源受限的中低端移动设备场景。典型实现如Google官方提供的Android Profiler与Battery Historian工具,可分别用于监测CPU使用率、内存占用、电池放电速率等性能指标[3] [4]。第三方工具如DevCheck也被广泛用于实时采集/proc与/sys虚拟文件系统中的状态参数,便于开发者评估系统负载状态[5]。在学术研究方面,Zhao等提出一种基于资源使用模式的行为识别方法,利用内存、CPU、I/O访问特征构建轻量型分类模型,以识别潜在恶意后台任务[6]。Adhikari等提出的VolMemDroid框架则进一步结合 volatile memory特征,通过内存快照序列识别恶意任务执行痕迹,体现出运行态内存级可信性建模的可行性[7]。Bampatsikos等将多属性决策(MADM)机制引入终端信任管理,综合考虑访问风险、可用性与安全级别等因素构建信任评分函数,并结合层次分析法实现权重调优与动态更新机制[8]。Nazir等则结合 MITRE ATT&CK攻击模型,构建了ZTA (Zero Trust Architecture)架构下的恶意行为识别体系,实现了行为级别的动态风险建模与安全策略自动联动,拓展了可信性评估的实时响应能力[9]。尽管上述研究在信息采集与可信建模方面取得一定进展,但仍侧重于单一指标,缺乏多源资源联合分析,并依赖经验阈值,缺乏可信语义解释等问题。
Android终端的可信性依赖于软硬件协同保障。硬件资源(如CPU和内存)的合理分配直接影响用户体验。研究表明,终端卡顿等问题多由硬件资源使用不当引起,例如低内存或高CPU负载运行[10]。
3. 移动终端硬件环境可信评估方法
硬件环境可信评估分为两步,即实时监测关键硬件参数,并将数据输入评估模型进行量化分析。
3.1. 硬件环境可信评估
论文选取了Android终端中CPU、存储、电池等重要硬件为对象,自定义参数指标及其评估规则,通过后台服务的形式实时监测其状态变化,建立硬件的可信评估方法。评估规则分为两步,首先计算单项的评分,最后综合单项的评分计算出总的系统评分,评估流程如图1所示。
(1) CPU可信性评估
CPU频率和温度是两项至关重要的性能指标,一般来讲,频率越高则处理速度越快,但同时也会造成温度的上升,长时间在高温下运行会对CPU造成危害,此时则需要降频以达到保护CPU的目的。基于此,本文将频率和温度作为CPU可信评估的两项主导性指标。从内核文件中读取其最大和最小频率,取最小频率作为CPU频率的基准值,定为100分。CPU温度工作范围为25~75度之间,50度以上即为不安全温度区域,因此,本文将人体恒温37度作为温度指标的基准值,定为80分。
确定了指标的基准值后,在此基础上进行增减计算得到各指标的评分。由于目前的移动终端均支持多个处理核心,因此本模块对每个核心单独计算,对多个核心的评估值总和再取均值,最终得到CPU的可信性评估值。
CPU频率的评估规则如公式(1)所示:
(1)
式(1)中,
表示当前内核的最高频率,
表示最低频率也即为频率的基准值,
表示第
个内核当前的实时频率。
Figure 1. Hardware environment trust evaluation process
图1. 硬件环境可信评估流程
CPU温度的评估规则如公式(2)所示:
(2)
式(2)中,
表示内核
当前的温度,
为温度的基准值,本系统中取值为37。
(2) 内存可信性评估
Table 1. Average performance metrics of top 10 android application categories
表1. Android平台十大主流分类应用性能指标平均情况
应用分类 |
内存消耗 |
浏览器 |
35.21 MB |
图书阅读 |
25.17 MB |
社交网络 |
24.25 MB |
机票出行 |
28.35 MB |
新闻资讯 |
28.28 MB |
影音播放 |
30.27 MB |
系统工具 |
22.22 MB |
通话通讯 |
23.14 MB |
拍摄美化 |
25.72 MB |
网购支付 |
26.36 MB |
根据Testin2013年8月发布的一份《中国好应用质量排行》中[11] (如表1所示),通过计算这十大主流分类的内存的平均值作为评分规则的80分的基准。通过应用内存消耗进行统计,得出主流应用平均消耗内存为26.90 MB,因此,论文将内存消耗为26.9 MB的应用内存评分定为80分。
为反映当前系统的内存消耗状态,选取当前系统中运行进程中内存消耗最大的应用作为系统当前内存的评分。内存可信性评估规则如下:
(3)
式(3)中,M代表当前应用的内存消耗,S为内存消耗的基准值,这里取26.9,
代表进程可分配的最大内存,lowMem为低内存运行标志。
(3) 电池可信性评估
电池可信性评估考虑的因素主要包括电量、电压及电池温度。对于电量的评估,只要获得当前电池的电量值即为电量参数的评估值。电池的工作温度为0~40度,但实际中20~30区间为正常使用时的温度范围,一般超过50度即为危险区间,因此,将30度作为电池温度的基准值,评分为80。正常电压为3.6 v~4.2 v,充电电压可达4.3 v~5.5 v,随着电量的消耗电压会逐渐降低,当电压低于3.6v时会自动关机。因此,本文选择将3.9 v作为电压的基准值参与电压的评估。
在电池可信性评估过程中,当电池健康状态属性异常时,评分结果为0,在健康状态属性为良好时,电池温度的可信性评估规则如公式(4)所示。
(4)
式(4)中,T为电池的当前温度,P为基准温度,取值为30。
电池电压的可信性评估规则如公式(5)所示。
(5)
式(5)中,P表示基准电压取值为3.9 v,
表示正常运行的最低电压取值为3.6 v,
表示正常运行的最高电压取值为4.2 v,V表示当前的电池电压。
一般地,将单个指标的评估结果累加并取均值,即可得到当前硬件环境的可信度评估值。
3.2. 硬件状态监测
Android内核文件系统Linux提供了sys文件,可以通过访问目录/sys实时查看系统运行时的内部数据和一些重要的系统信息。
(1) CPU状态监测
Android四层架构的最底层即是Linux内核,Android系统的一切服务都是以Linux为基础[12]。Android文件系统如图2所示。
移动设备会由于CPU负载过高导致发热,从而造成整体性能下降,甚至ANR (Application Not Responding)等一系列问题。图3为使用ADB [13]工具通过访问/sys/devices/system/cpu/cpuNum/cpufreq/目录下的scaling_cur_freq文件得到的CPU频率信息。
CPU状态参数是以后台服务的形式实时采集,由于CPU状态监测是一个耗时的任务,使用普通的Service会造成主线程阻塞,导致应用的崩溃问题。因此,本文选用IntentService代替Service实现状态监测任务,具体的状态监测过程如表2所示。
Figure 2. Android file system structure
图2. Android文件系统
Figure 3. CPU frequency information extraction
图3. CPU频率信息
Table 2. CPU status monitoring process
表2. CPU状态监测流程
1. 首先获取当前设备CPU内核数量 int cpuCores = Runtime.getRuntime().availableProcessors(); 2. 遍历/sys/devices/system/cpu目录,读取内核实时频率信息 FileReader fileReader = new FileReader(“/sys/devices/system/cpu/” +
cpuNum + “/cpufreq/scaling_cur_freq”); BufferedReader bf = new BufferedReader(fileReader); Cpufrequence = bf.readLine().trim(); 3. 遍历/sys/class/thermal目录,读取当前内核温度信息 FileReader fileReader = new FileReader(“/sys/class/thermal/thermal_zone/” + coreNum + “/temp”); BufferedReader bt = new BufferedReader(fileReader);
long temperature = Long.parseLong(bt.readLine()) / 1000.0; 4. 对获取到的数据进行格式化处理,保存并通知UI刷新显示。 |
(2) 内存状态监测
内存消耗是影响移动平台应用性能的一个重要指标。Android为设备的每个应用都设定了一个最高的可用内存阈值,当一个应用的内存超过该阈值就会发生OOM (Out Of Memory)错误,进而引发程序卡死及界面崩溃等问题。为此,论文选用Android原生API实现对系统及进程的内存状态进行实时监控。Android系统不仅包含了C/C++语言实现的nativ进程,还有Java语言实现的dalvik虚拟机进程。因此,Android内存分析包含native heap和dalvik heap两部分。
Android程序框架层提供的ActivityManager类,可以获得当前系统中正在运行的应用进程、服务、任务和内存等信息。对于系统内存使用情况,首先通过Context的getSystemService获取ActivityManager对象,然后调用其getMemoryInfo函数可以获得系统的内存状态信息,该函数需要传递MemoryInfo对象作为参数,而且将返回的内存信息存放到该MemoryInfo对象中。MemoryInfo中包含的内存相关的重要属性如表3所示。
Table 3. Attribute description of MemoryInfo
表3. MemoryInfo属性信息
属性 |
含义 |
totalMem |
可访问的总内存容量 |
availMem |
系统当前可用内存容量 |
threshold |
低内存门限值 |
lowMemory |
低内存运行标志 |
Table 4. Memory status monitoring process
表4. 内存状态监测流程
1. 获取ActivityManager对象 ActivityManager manager = (ActivityManager)getSystemService(ACTIVITY_SERVICE); 2. 获取系统内存信息 ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo(); manager.getMemoryInfo(info);
sumMem = formatSize(info.totalMem);
availMem = formatSize(info.availMem);
thread = formatSize(info.threshold);
isLow = info.lowMemory; |
续表
3. 检测当前系统中运行的进程,并查看各个进程的内存占用情况 List<ActivityManager.RunningAppProcessInfo> appProcessList = manager.getRunningAppProcesses(); Debug.MemoryInfo[] memoryInfo = manager.getProcessMemoryInfo(memoryPid); totalPss = memoryInfo[0].getTotalPss(); dalvikPss = memoryInfo[0].dalvikPss; nativePss = memoryInfo[0].nativePss; 4. 对内存使用情况进行汇总,通知主线程在UI刷新显示。 |
进程的内存使用情况的原理是调用ActivityManager类的getProcessMemoryInfo函数,并传入运行进程ID,得到Debug.MemoryInfo数组对象,Debug.MemoryInfo继承Parcelable,用于统计进程的内存信息。通过调用Debug.MemoryInfo相应方法可获取该进程的堆栈内存信息。
内存状态监测被设计为一个服务,在后台实时对系统中内存使用情况进行统计,内存监测的过程如表4所示。
(3) 电池状态监测
电池对于系统的威胁性相对较低,但移动终端的运行必须得到电池的能量供给。因此,电池状态也是可信评估的重要指标。
电池监控采用监听系统广播的方式。当终端电池状态发生变化时,Android系统会对外发送一条常量系统广播,其Intent对象携带标志电池状态的属性,通过设置监听对应Intent的BroadcastReceiver,即可获取终端电池相关信息。因此,电池监控定义一个监听系统广播的广播接收器BroadcastReceiver,用来接收及处理电池状态的信息。表5列出了系统广播携带的有关电池状态的重要属性信息。
Table 5. Attributes of battery status
表5. 电池状态属性
属性 |
状态 |
电池健康状态 |
BATTERY_HEALTH_OVERHEAT (电池温度过高) |
BATTERY_HEALTH_DEAD (无电) |
BATTERY_HEALTH_OVER_VOLTAGE (电压过大) |
BATTERY_HEALTH_COLD (电池温度过低) |
BATTERY_HEALTH_GOOD (电池状态良好) |
level |
电池当前电量 |
scale |
电池最大容量 |
voltage |
电池电压 |
temperature |
电池温度 |
电池监控的实现过程包括广播接收器的注册、广播接收器处理逻辑的定义和监测结果的发送,实现的监测流程如表6所示。
4. 硬件环境可信评估方法验证
Android是基于Linux内核实现的,在内核文件中记录了系统的硬件运行参数,同时Android系统本身也提供了相应的系统广播和类库,通过访问内核文件及调用系统API的方式即可获取系统硬件状态参数。
为此,硬件环境可信评估方法的验证选用基于Android操作系统的荣耀V20手机作为移动终端测试设备,负责终端硬件环境监测、软硬件环境可信评估及用户间的交互。
Table 6. Battery status monitoring process
表6. 电池状态监测流程
1. 注册接收电池状态的广播接收器 BroadcastReceive receiver = new BatteryBroadCastReceiver(); registerReceiver(receiver, new IntentFilter(Intent.ACTION_BATTERY_CHANGED)); 2. 定义广播接收器处理逻辑,计算电池状态信息 class BatteryBroadCastReceiver extends BroadcastReceiver { level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, 0);
scale = intent.getIntExtra(BatteryManager.EXTRA_SCALE, 1);
battery = (level * 100) / scale;
power = intent.getIntExtra(BatteryManager.EXTRA_VOLTAGE, 0);
technology = intent.getStringExtra(BatteryManager.EXTRA_TECHNOLOGY); health = getHealth(intent.getIntExtra(“health”, BatteryManager.BATTERY_HEALTH_UNKNOWN)); } 3. 向主线程发送状态广播,通知UI显示 |
4.1. 移动智能终端的可信评估系统
采用C/S架构设计移动智能终端的可信评估系统用于硬件环境可信评估方法验证。客户端负责从Android内核获取硬件状态参数并实时监测硬件环境状态变化,服务器端对大量的APK样本进行模型训练,并对客户端提交的待测APK进行权限预测,反馈预测结果给客户端,使其作为安全决策的依据。客户端与服务器之间通过网络进行通信。系统总体架构如图4所示。
Figure 4. Overall architecture of the trusted system
图4. 可信系统总体架构
部署移动终端可信系统后,便可对当前的硬件环境各项指标进行性能监测,并对检测结果进行实时分析。图4中,硬件环境可信评估时,客户端实时从系统内核获取硬件状态参数,进行量化评估后得到当前硬件环境可信等级,将其作为当前系统硬件环境的性能评估指标并以此为应用软件的运行提供参考依据,为系统应用层提供可信的底层硬件运行环境。
4.2. 硬件环境监测
监测项按照性能指标分为CPU性能、内存使用和电池状态。Android可信监测软件的性能监测任务都是以服务的形式在后台实时采集数据,再将性能数据以广播的形式通知给UI显示。移动终端可信系统的运行效果如图5所示。
图5中检测到的数据均为系统运行所产生的实时数据。从数据分析可知,选用的测试设备包含8个CPU内核,当前运行频率及温度均在正常阈值内,同时电池及内存消耗均表现正常,系统当前的整体硬件性能良好。
Figure 5. Runtime performance of the trusted system
图5. 可信系统运行效果
4.3. 硬件环境可信评估
硬件环境可信评估完成6类性能指标监测结果的量化,并根据性能综合得分情况,给出当前系统硬件环境的可信度。图6为硬件环境监测功能的执行结果。
结合图5中监测的性能实时数据进行分析评估表明:
1) 由于当前系统前台进程只有监测软件自身,CPU频率及温度均处于比较低的运行状态,评分也就相对较高。
2.当前系统运行进程中内存消耗最高的为29 MB,超出了内存消耗的基准值26.9,评分低于其基准分80分。
3) 电池模块,其性能指标均达到了基准值以上,评分高于基准值。
由此可见,论文提出的硬件环境可信评估方法实现了对移动终端硬件环境的实时监测和可信评估。同时,实验验证对于硬件环境的主观评价与系统评估结果几乎一致,证明了方法的有效性。
Figure 6. Evaluation results of hardware trustworthiness
图6. 硬件环境可信评估结果
5. 小结
移动智能终端应用信息领域的安全成为亟待解决的问题。作为一个嵌入式系统,论文提出实时监测CPU、内存和电池等物理硬件参数的变化,进行硬件环境的综合可信评估。实验表明,研究的方法可以有效地评价系统的安全状态,支撑面向异常性能指标解决方案建立,保障移动终端运行的正确性和良好的用户体验。未来研究可扩展至更多硬件指标,进一步提升评估的全面性。