智能手机操作系统安全技术探讨

开篇：润墨网以专业的文秘视角，为您筛选了一篇智能手机操作系统安全技术探讨范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

【摘 要】介绍了智能手机操作系统关键安全技术及存在的问题，并针对运营商的具体情况提出了解决方案建议。

【关键词】安全 操作系统 智能手机

doi：10.3969/j.issn.1006-1010.2015.05.004 中图分类号：TN929.5 文献标识码：A 文章编号：1006-1010（2015）05-0017-04

引用格式：何i，乔雅莉，戴国华，等. 智能手机操作系统安全技术探讨[J]. 移动通信， 2015，39（5）： 17-20.

Discussion on Security Technology of Smart Phone Operating System

HE Yao， QIAO Ya-li， DAI Guo-hua， WANG Zhao-hui

（Guangzhou Research Institute of China Telecom Co.， Ltd.， Guangzhou 510630， China）

[Abstract]

This paper introduced the key security technology and corresponding issue of smart phone operating system， and then put forward solution recommendation according to the specific situations of operators.

[Key words]security operating system smart phone

1 引言

随着移动互联网的迅速发展，智能手机高度普及，智能手机在为用户带来便捷体验的同时，其存在的各种安全问题如隐私泄露、恶意骚扰、耗费流量、病毒感染等逐渐呈现。特别是在斯诺登事件、苹果iCloud“艳照门”等事件曝光后，智能手机的安全问题已经引起相关政府部门、运营商和终端厂商的高度重视。

2 关键安全技术分析及存在的问题

本文选取具有代表性的、占据主要市场份额的两大智能手机操作系统Android和iOS进行分析探讨。

2.1 数据保护

（1）Android的全盘加密

Android 3.0开始引入全盘加密（Full Disk Encryption，

FDE），这是个很重要的安全特性，尤其是在解决设备丢失后的数据安全问题方面。

全盘加密使用的主密钥是通过锁屏密码或设备PIN码来保护的，保护机制如图1所示。

系统首先使用/dev/urandom随机数产生工具，产生基于硬件的128位FDE主密钥，以及用于PBKDF2算法的128位盐值;然后系统使用PBKDF2算法、密码或PIN码+盐值，经过多次哈希计算得到32字节长的用于AES（高级加密标准）加密的密钥和IV向量，其中AES密钥长128位，初始IV向量长128位;最后系统以128位的AES对称加密算法的CBC（加密分组链接模式）模式，使用AES密钥和初始IV向量对FDE主密钥明文进行加密，得到128位的主密钥密文。经过上述处理，大大增加了利用彩虹表进行攻击的难度。具体的加密过程是透明的，也就是说用户无感知、应用无感知，但存储在FLASH上的数据是加密的。FDE并非真的全盘加密，只是加密用户数据分区。

从以上对FDE主密钥的保护机制可见，保护全依赖于屏保密码或设备PIN码，是纯软件的保护方式，一旦密码或PIN码被攻破，FDE主密钥就被暴露。

全盘加密的安全性和密码/PIN码的强度息息相关，如果设置成弱口令，则全盘加密的安全性会大打折扣。

由于加密后的密钥、盐值等数据都是明文存在的，可以通过多种手段获取。如拥有Root权限的用户，可通过ADB工具读取所有文件;Hashcat工具在730M主频的芯片下，每秒可获得20 000个PBKDF2计算出来的哈希值，即不到10秒就可恢复一个6位纯数字的密码，4小时就可恢复6位小写字母的密码。

Android 4.4的改进：用scrypt算法取代PBKDF2，提升了破解难度。scrypt不仅所需计算时间长，而且占用的内存也多，使得并行计算多个摘要异常困难，因此利用彩虹表进行暴力攻击更加困难。

Android 5.0缺省开启全盘加密，只加密存储中已使用的块，缩短了加密时间。ext4和f2fs的文件系统支持快速加密。采用强制加密机制，用户无需自行开启，初次启动时使用临时密码对密钥进行加密，用户设置密码后，只需要重新加密密钥，而无需对数据重新加密。即使用户不设置PIN码也是加密状态，而且支持基于硬件方案存储密钥，如TEE或SE（具体如2.3节所述）。

（2）iOS的文件加密

iOS终端出厂时，在AP芯片的Secure Enclave协处理器内置了2个用于AES 256-bit加解密的密钥，这2个密钥分别是标识设备唯一的UID，标识AP芯片类型的GID，2个密钥都无法通过JTAG（联合测试工作组）接口或其它调试接口获得，成为硬件密钥。在FLASH存储与RAM之间的DMA通道上，部署了专用的AES 256位密码引擎，大幅提升了文件的加密效率。

如图2所示，iOS对文件系统的加密方式是为每一个文件生成一个文件密钥，文件密钥对文件内容进行加密。文件密钥则被类型密钥加密，密文放在文件头信息中，文件头信息被文件系统密钥加密。文件系统密钥由存于硬件中的硬件密钥生成。每个文件根据不同的加密类型，分到不同的类型中，每个类型对应配备一个类型密钥，有些类型密钥由硬件密钥加密保护，有些则由锁屏密码加密保护。

图2 iOS文件加密机制

由此可见，iOS对文件系统的加密方式与Android最大的不同在于密钥衍生的层次中，根密钥不只是锁屏密码，而且还有由硬件保护的硬件密钥，因此具备了较高的安全性。

2.2 权限策略

（1）增强安全Linux系统SELinux

Android系统权限主要由应用层权限和Linux内核的文件系统权限组成，APP应用通过在AndroidManifest.xml文件中声明申请应用层权限，Linux文件权限则明确了系统内每个文件的读、写、执行、拥有者和分组的权限。Android系统宽松的开放性为其带来高速的发展，但同时也暴露出各种安全问题，从Android 4.3版本开始，在内核集成了SELinux，增强操作系统的安全性。

SELinux提供了一种灵活的强制访问控制（MAC）系统，且内嵌于Linux Kernel中。SELinux定义了系统中每个用户、进程、应用和文件的访问和转变的权限，然后它使用一个安全策略来控制这些实体（用户、进程、应用和文件）之间的交互，安全策略指定如何严格或宽松地进行检查。只有同时满足了“标准Linux访问控制”和“SELinux访问控制”时，主体才能访问客体。

在SELinux中，通过事先定义每个进程的允许操作，来禁止其进行越轨的操作。集成了SELinux的Android系统沿袭了这一机制，通过限制各进程的操作权限，可以防止恶意软件篡改系统。一般来说，攻击漏洞的恶意软件为了长久利用篡夺到的Root权限（系统超级权限），会在Android的系统区中埋设特点命令（如su切换用户命令），而在SELinux中，通过事先设定不允许以Root权限执行的各种进程改写系统区和重复挂载，就可以有效回避此类攻击。

Android 5.0之前的SELinux默认设置为Permissive模式，即对违规行为只作日志记录，供事后审计，而5.0版本则默认设置为Enforcing模式，真正启用SELinux，对违规行为进行拒绝并日志记录。

由于Android系统的开源特性，开发者可对操作系统的内核源码进行修改，放宽SELinux策略检查，向没有锁定Bootloader的终端设备刷入定制的内核，以获得不受限制的Root权限。

（2）用户参与的权限管理

针对一些敏感的权限，iOS都会弹窗请求用户的许可，如开启GPS定位、网络连接、拨打电话等，而对一些涉及隐私的权限，则不对第三方APP开放，如收发短信、联系人管理等。由于iOS的封闭性对于权限管理机制有一定程度的保护，而且随着iOS系统的不断改进，越狱困难越来越大。

2.3 安全域隔离

（1）TEE隔离

iOS在推出TOUCH ID功能的同时也推出了Secure Enclave安全域，Secure Enclave是苹果A7及以上主处理器的协处理器，其自身具有微操作系统，与主处理器共享加密RAM，通过中断与主处理器通信，操作系统借助它实现指纹特征数据、UID和GID密钥等需高安全级别关键数据的存储，其在架构上与TEE相似。

TEE系统架构标准由智能卡及终端安全的标准组织Global Platform，它提出了在原有硬件和软件的基础上，隔离出可信执行环境TEE（Trusted Execution Environment）和富执行环境REE（Rich Execution Environment），其中TEE用于安装、存储和保护可信应用（TA），而REE用于安装、存储其它的应用。

TEE具有自身的操作系统，与REE环境中的操作系统（如iOS、Android）相隔离。REE中的授权应用，通过驱动程序才能与TEE中的驱动程序通信，不可直接访问TEE的资源。TEE还可具备可信用户界面（TUI），为一些关键的屏幕显示和交互提供了安全保障。图3为TEE系统架构示意图。

TEE在实际应用中也存在一些问题与缺点：TEE的硬件隔离主要体现在对CPU资源的分时或分核隔离、RAM资源和存储资源的寻址隔离等，物理器件上仍然与REE环境共享，实质上只是芯片内的软件调度隔离，因此不具备较高的防篡改能力。同时，TEE仍存在认证的问题，CC（信息技术安全评价通用准则）组织的EAL（评估保证级别）等级认证仍在进行中。

针对TEE架构的移动平台攻击包括：

1）芯片攻击

利用JTAG调试接口对MMU（内存管理单元）处理器单元重新编程，修改RAM及存储的寻址范围，以获得相应数据的访问权限。

利用物理探针在SoC芯片的数据总线上进行信号窃听。

2）共享资源攻击

如果REE环境中的非法代码能共享访问与TEE相同的CPU或RAM资源，那么TEE就存在受到共享资源攻击的风险。

3）系统漏洞攻击

在智能手机设备上发现了TEE内存访问控制的漏洞。

Bootloader存在设计漏洞，可用于系统非法提权。

整数溢出会给TEE的运行带来风险。

在安全启动代码中存在证书处理或签名有效期的漏洞，允许黑客插入恶意代码。

4）入侵式攻击

篡改代码签名机制可允许黑客插入恶意代码。

（2）SE隔离

SIMallicance组织提出了基于Java语言的Open Mobile API机卡通信接口，使得运行于智能手机操作系统上的应用可通过操作系统提供Open Mobile API接口，使用ISO7816协议与SE安全单元中的Applet应用通信，现主要应用于Android系统。SE是具有防物理攻击的高安全性的芯片，内含独立的CPU、RAM、FLASH和操作系统，SE可存储密钥等关键数据信息，SE中的Applet应用可进行各种加解密算法的运算。主流SE芯片厂家通过了CC组织的EAL5+安全认证，这是目前较为安全的系统隔离方案。

由于SE自身不具备UI界面，需借助上层操作系统（即REE），用户输入的PIN码等仍有被截获的风险。由于Android系统的开源特性，黑客可对操作系统中安全规则检查模块代码进行修改、编译并向终端重新刷入更改的模块，使得非授权应用可直接与SE中的Applet通信，为终端安全带来极大的风险。

3 安全解决方案建议

REE+TEE方案或REE+SE方案在一定程度上提升了终端系统的安全性，但仍然存在一定的缺陷，难以抵挡高级别的攻击。以下针对运营商的具体情况给出一些建议：

（1）架构方面：建议SE不直接与REE对接，而是与TEE的Trusted Kernal对接，REE对SE的访问，可通过TEE进行，即REE+TEE+SE方案。

（2）关键信息存储方面：原存储于TEE中的密钥、密码等关键信息，可转移放至SE中，借助SE的抗攻击能力，对关键信息实施保护。

（3）关键运算载体：大数据量的加解密预算，如对称加解密运算等，建议由TEE中TA应用负责，借助TEE丰富的运算和内存资源保障响应性能;小数据量的加解密运算，如数字签名等，建议由SE中的Applet应用负责。

（4）实施建议：电信运营商的SIM卡是现成的SE资源，且具有成熟的TSM后台对其管理，终端TEE可通过ISO7816接口与SIM卡SE进行对接，把SIM卡SE作为可信设备，从而构建出软件+硬件的整套安全解决方案。

4 结束语

智能手机操作系统的安全问题，不可只从软件层面去解决，还需要借助硬件本身的能力对其进行完善。可信执行环境的架构已逐渐被终端厂家采用，并且已有移动支付类的代表性应用落地，相信在不久的将来，安全智能手机操作系统将会得到普及。

参考文献：

[1] GlobalPlatform Inc. TEE System Architecture V1.0[S]. 2011.

[2] Apple Inc. iOS Security Guide[S]. 2014.

[3] GlobalPlatform Inc. Secure Element Access Control V1.0[S]. 2012.

[4] Samsung Electronics Co.， Ltd. Meet evolving enterprise mobility challenges with Samsung KNOX[Z]. 2014.

[5] SIMalliance. Open Mobile API specification V2.03[S]. 2012.