智能手机操作系统安全技术探讨
2015-07-11何峣乔雅莉戴国华王朝晖
何峣,乔雅莉,戴国华,王朝晖
(中国电信股份有限公司广州研究院,广东 广州 510630)
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并非真的全盘加密,只是加密用户数据分区。
图1 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对文件系统的加密方式是为每一个文件生成一个文件密钥,文件密钥对文件内容进行加密。文件密钥则被类型密钥加密,密文放在文件头信息中,文件头信息被文件系统密钥加密。文件系统密钥由存于硬件中的硬件密钥生成。每个文件根据不同的加密类型,分到不同的类型中,每个类型对应配备一个类型密钥,有些类型密钥由硬件密钥加密保护,有些则由锁屏密码加密保护。由此可见,iOS对文件系统的加密方式与Android最大的不同在于密钥衍生的层次中,根密钥不只是锁屏密码,而且还有由硬件保护的硬件密钥,因此具备了较高的安全性。
图2 iOS文件加密机制
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系统架构示意图。
图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.