2016, Vol. 27
2. 中国科学院大学, 北京 100049 ;
3. 计算机科学国家重点实验室(中国科学院 软件研究所), 北京 100190
2. University of Chinese Academy of Sciences, Beijing 100049, China ;
3. State Key Laboratory of Computer Science (Institute of Software, The Chinese Academy of Sciences), Beijing 100190, China
随着云计算技术、移动终端设备、移动通信技术和移动互联网应用的高速发展,移动云计算(mobile cloud computing,简称MCC)概念正在逐渐影响人们的日常生活.国际移动云计算论坛[1]和Intel Aepona[2]给出的相关定义指出,移动云计算是移动终端设备通过移动云应用将数据处理和数据存储外包给云中资源丰富的计算平台的一种综合性技术.移动云计算可以有效降低移动设备计算资源、存储资源和电量的开销,提升复杂应用在移动终端的可用性[3].相比于PC平台云计算服务,移动云计算呈现给用户的多为软件即服务(software as a service,简称SaaS)的层次[4],用户使用移动设备瘦客户端软件或Web浏览器通过无线网络访问远程云服务.近年来,移动云计算推广涉及的领域包括云办公、云邮件、云存储、云支付、云游戏和云视频等,各公司也为移动云计算推出了相应的支持技术和产品,其中包括苹果的iCloud、谷歌的Cloud Console、微软的OneDrive和亚马逊的AppStream等,它们极大地提升了移动用户体验云服务的便捷性.
根据市场研究公司Visiongain发表的移动云计算行业市场报告预测[5],移动云计算市场正进入快速增长期,到2016年,移动云计算服务年收入将达到450亿美元.
然而,伴随着移动云计算的普及,移动用户的信息安全正面临着日益严峻的威胁.除了传统云计算云端安全问题之外,移动终端的安全问题为移动云计算安全提出了新的挑战,也为潜在的敌手提供了新的突破口.在云计算安全研究中,用户的数据安全和隐私保护被作为云安全技术框架的主要目标[6],但移动终端安全的脆弱性可能破坏整个云计算框架的鲁棒性,造成用户的隐私数据泄露,甚至影响云端主机的安全和稳定. 当前,恶意代码对移动终端软件和系统的攻击屡见不鲜,一旦用户的移动设备被攻破,敌手可以轻松窃取用户的账户口令,冒名访问用户的的敏感云服务进而获取其在云端存储的私有数据,导致隐私信息的泄露.2014年9月,黑客攻击了多个苹果iCloud 账号,导致詹妮弗·劳伦斯等好莱坞明星裸照被泄露于互联网.在云计算环境下,上述安全问题来源于云服务缺乏对移动用户有效的安全认证.在移动终端及应用得不到认证保护的情况下,用户口令极易被盗用,云端无法与移动用户建立足够的信任关系[7],使得传统的安全认证机制很难发挥作用.云安全联盟(cloud security alliance,简称CSA)在发布的最新版云计算服务安全实践手册《云计算安全指南(v3.0)》[8]中,着重强调了数据安全、应用安全和身份授权对于云安全的重要性,只有这3方面同时满足要求,移动云计算用户的信息安全才可能得到保障.
在现有的安全技术中,可信计算[9]和可信虚拟化[10]被广泛应用于构建可信云[11-15].可信云架构可以良好地保护用户数据在云端主机上的机密性和完整性,能够提供用户PC端与云端主机之间的安全证明,但目前尚无成熟有效的可信移动终端解决方案能够保证移动设备安全接入可信云服务.传统的传输层安全协议如TLS (transport layer security)等可以被用于保护用户数据在移动终端与云端主机之间网络传输的安全,借助PKI (public key infrastructure)技术,可以进一步实现对移动云计算参与实体的认证.然而这些技术的安全性基于移动终端系统和应用程序均为安全的前提假设下,在针对移动设备攻击极为活跃的今天,这些假设是很难被满足的.因此,需要面向移动云计算场景设计一种云服务安全接入方案,在保证移动终端可信的基础上构建移动设备客户端与云服务之间端到端的信任连接.
面对层出不穷的移动系统及应用安全漏洞,在移动终端设备上构建可信执行环境(trusted execution environment,简称TEE)成为近年来一个备受关注的研究领域.隔离于通用执行环境(rich execution environment,简称REE),TEE旨在保护安全敏感的代码执行和相关数据信息免受恶意敌手的攻击和破坏[16].TEE是建立可信移动终端的基础,也是建立移动云计算安全架构的重要环节.作为ARM架构的安全扩展技术,TrustZone[17]提供了基于硬件的隔离机制,目前已被移动嵌入式设备广泛支持,各大移动设备厂商正积极研发基于TrustZone的安全应用.TrustZone技术可以被用于构建灵活高效的TEE,但尚无统一标准的构建方法.此外,可信移动终端的构建需要可靠的信任根和密钥与数据管理机制,TrustZone技术本身并不能提供这些功能,物理不可克隆函数(physical unclonable function,简称PUF)[18]可作为TrustZone技术的补充,实现密钥与敏感数据管理机制,进而为移动终端提供良好的信任根.本文将利用TrustZone技术和PUF技术构建可信移动终端.
本文的主要贡献如下:
· 面向移动云计算场景,提出了基于TrustZone技术构建可信移动终端的方法,确保云服务客户端程序及相关敏感操作在移动终端运行的安全与可靠;
· 提出了基于PUF技术的密钥与敏感数据管理机制,该机制配合TrustZone技术为可信移动终端及云服务安全接入提供信任根功能;
· 提出了一种可信移动终端云服务安全接入协议,利用可信计算技术,在云服务端与移动客户端间建立端到端的双向认证通道,保护用户数据和云服务访问请求在接入过程中的认证性、机密性和完整性.该协议兼容可信云架构;
· 给出了一种基于本文方案的移动云存储应用实例设计,证明了方案具有良好的可用性与可扩展性;
· 实现了本文方案的原型系统.实验评估表明,本文方案在整体上具有良好的运行效率.
本文第1节讨论本研究领域的相关工作.第2节介绍预备知识、涵盖可信计算技术、TrustZone技术和PUF技术.第3节提出方案的系统模型与假设.第4节从可信移动终端体系结构、密钥与敏感数据管理、云服务安全接入协议和安全性分析4个方面详细阐述可信移动终端云服务安全接入方案的设计.第5节提出基于本文方案的移动云存储应用实例.第6节是原型系统的实现.基于该系统的方案评估在第7节给出.第8节对本文方案涉及的匿名性问题展开讨论.第9节对全文进行总结,并展望未来的研究工作.
1 相关工作为了从计算机底层硬件解决信息安全问题,可信计算概念被提出并在科研和产业界得到了一定的推广.国际可信计算组织TCG(Trusted Computing Group)针对x86硬件平台推出了可信平台模块(trusted platform module,简称TPM)的安全解决方案,由TCG于2003年制定的TPM1.2主规范[19]经过多次修订在2009年被接收为ISO国际标准,2013年,TCG正式发布了最新的TPM2.0标准[20].在我国,国家密码管理局于2007年提出了具有自主知识产权的可信密码模块(trusted cryptography module,简称TCM)[21]和相关接口规范.作为基础安全技术,可信计算的一个重要应用场景是构建可信虚拟化平台,虚拟可信平台模块vTPM[22]可以用于保护虚拟机监视器的安全,TrustVisor[23]通过创建虚拟TPM的实例为隔离的代码提供可信服务.由于在安全隔离、安全干预和数据保护等方面的优势,基础设施虚拟化技术被云计算架构广泛使用,利用可信虚拟化技术构建可信云计算环境成为近年来的研究热点.文献[12]概述了可信云计算平台(trusted cloud computing platform,简称TCCP)理念,TCCP通过将可信平台的功能延伸至云基础设施的方式为用户虚拟机提供封闭的运行环境,可以有效保护用户数据的机密性和完整性,并保证云端主机的安全.武汉大学赵波教授等人[11]总结了可信云计算环境构建的技术方法和面临的挑战.TrustCloud[14]为云计算设计了一种信任构建和安全审计的框架.Cloud Terminal[15]使用可信证明方法将用户敏感应用的数据处理安全外包给云服务提供商,用户本地主机只进行界面显示.CloudProxy[13]借助可信计算技术在云端主机与用户主机间建立了端到端的信任连接,保护用户数据在传输和云端运行过程中的安全.然而,上述可信云计算环境的构建方法都是针对x86硬件平台设计的,移动终端设备如何安全有效地接入可信云环境,仍是一个有待解决的问题.
在移动云计算发展迅速的今天,移动云计算安全受到了越来越多人的关注.相关研究[24, 25]指出:移动用户的私有数据在移动终端、云端主机和通信信道上的机密性和完整性,是移动云计算安全的关键.可信虚拟化技术和可信云架构可以保护用户数据在云端主机的安全,但目前缺乏配套的、能够在移动终端及移动网络通信中保护用户数据且面向云环境设计的可信解决方案.为移动终端构建云服务安全接入方法,是解决上述问题的一个重要途径,而可信移动终端的设计与实现是构建该方法的基础.文献[26]给出了基于移动操作系统访问控制策略的可信安全隔离方法,该类方法建立在移动操作系统安全的前提下.然而,成功利用Android系统漏洞实施攻击的事件层出不穷,操作系统本身并不能提供高强度的安全.对于可信移动终端的研究,TCG继承了传统PC平台的可信计算思路,从底层硬件出发,为移动终端发布了移动可信模块(mobile trusted module,简称MTM)规范[27],但由于需要依赖额外的硬件模块,该规范并没有在移动产业界得到推广.
相比于TCG的可信计算思路,使用灵活的TEE技术构建可信移动终端的方法得到了更为广泛的研究和支持.移动平台的TEE标准化概念[28]最早由GP(GlobalPlatform)给出,TEE能够结合移动终端设备的特点,为实际应用提供可行的安全执行环境解决方案.由于使用ARM架构处理器的移动设备占据市场的主流地位,当前最为流行的构建移动平台TEE方法是利用ARM TrustZone提供的基于硬件扩展的安全隔离技术.TI(texas instruments)在文献[29]中介绍了运用TrustZone建立移动平台TEE的潜在方式.文献[30]提出了一种基于TrustZone构建移动终端信任链的方法,该方法可以为移动应用提供可信运行时环境.文献[31]在TrustZone构建的TEE基础上设计了一套移动平台匿名购物系统.在实际应用中,三星在TrustZone技术基础上开发和实现的KNOX[32]正在为其移动设备提供安全服务,苹果的移动终端产品使用了基于TrustZone技术设计的Apple Pay安全支付方案,苹果和华为的移动设备指纹识别功能也被认为构建在TrustZone的基础之上.虽然目前使用TrustZone技术构建移动平台TEE及其应用的方法有很多,但他们或多或少都存在一些不足,仍然没有一种被广泛认可的移动TEE构建及应用方法.
2 预备知识 2.1 可信计算技术可信计算存在多种不同的定义,广义的可信计算平台能够保护数据存储区域,避免敌手直接物理访问到机密数据存储区,并保证系统的运行环境是安全的、未被篡改,所有的代码能够运行于一个未被篡改的执行环境内.在TCG的可信计算概念中,可信指的是对行为的信任,即,平台实现特定目标的计算行为与预期一致.TCG提出了通过嵌入在硬件平台上的TPM安全芯片来提高计算机系统安全性的技术思路,所构建的可信平台能够证明平台自身的安全属性、保证部分关键计算和数据不受干扰、标识计算平台的身份、对外提供自身行为和环境的证据.可信计算涉及的特征技术包含了信任根提供、完整性度量、敏感数据封装以及可信环境的构建和证明等.以可信虚拟化为核心的可信云计算架构采用了可信计算中的相关技术,在本文所提出的方案中,可信移动终端的构建和云服务安全接入协议的设计也借鉴了可信计算技术的部分思想.
2.2 TrustZone安全技术作为一种硬件安全扩展技术,TrustZone自ARM v6开始引入ARM架构规范,支持用户自主开发、设计特定的安全系统,被大量移动嵌入式设备所应用.该技术提供两个执行环境:安全世界SW(secure world)和普通世界NW(normal world).两个世界实现了代码隔离,通过安全监视器(secure monitor)控制两个世界的切换.其中: SW通常用于实现TEE,执行定制的安全OS以及安全敏感的任务;而NW用于实现REE,可以运行通用OS和普通应用程序.SW与NW由底层ARM芯片提供基于硬件的物理隔离,两个世界具有独立的系统资源,包括寄存器、物理内存和外设,SW中的代码和资源受到严格的访问控制策略保护.TrustZone的一大优势是在通用的ARM处理器中实现扩展,通过额外增加的扩展,单个处理器能够以时间片的方式安全有效地执行不同世界的代码,无需使用专用安全处理器即可实现类似的安全功能.此外,TrustZone在同一时刻只允许运行一个世界的代码,每个世界运行时都可以独占CPU资源,这使得SW中的安全运算性能要远高于一般资源受限的安全处理器.
2.3 物理不可克隆函数(PUF)PUF[18]是输入/输出关系,由特殊物理系统决定的一种函数,这里的输入/输出也被认为是一对挑战和响应.PUF具有随机和不可克隆两个重要属性,其不可克隆性来源于物理设备生产过程中随机引入的不确定因素. PUF的响应具有一定的噪声,模糊提取器[33]能够帮助PUF消减噪声干扰.PUF的物理优势使其可以隐式存储一段若干字节的秘密数据,该秘密数据不会显式暴露于外界,通过物理特性提取秘密数据的过程无法被其他设备所克隆.相比于普通的非易失性存储器,PUF提供了更高的物理安全特性,可以防止秘密数据直接从存储器中被恶意读出.PUF是一项低成本技术,可以利用当前普通的生产处理工艺快速实现.
事实上,TrustZone技术仅提供隔离执行环境,唯有配备可靠且可用于证明的信任根,才能真正实现TEE[18].由于对于支持TrustZone的移动设备来说可用的内置设备密钥不是通用必选配置,因而移动终端自身并不总是具备提供信任根的能力.为了弥补这一可能的缺陷,PUF可以作为一个有效的信任根与TrustZone配合使用.本文方案将PUF提取的唯一性秘密数据作为根密钥种子,以此派生其他安全密钥,进而实现身份证明和数据保护功能.本文方案采用了以静态随机存储器SRAM为物理介质的PUF[34],该PUF以SRAM的单元地址访问作为挑战,以SRAM加电后短时间内的随机值作为响应.
3 系统模型与假设 3.1 系统模型在本文提出的可信移动终端云服务安全接入方案的系统模型中,共有4个参与实体:移动终端制造商M (manufacturer)、移动终端T(mobile terminal)、应用服务提供商A(application service provider)和云服务提供商C (cloud service provider).在实际应用场景中,T由M生成制造,是移动用户直接操作的实体,配备了支持TrustZone安全扩展技术的ARM处理器芯片.在T出厂前,M为T颁发设备证书,证书将被嵌入设备中进行存储.A是移动云计算应用的提供商,其可以是云服务账户的管理者,如管理iCloud的苹果公司,也可以是具体应用的设计与发布者,如提供云存储应用的DropBox公司.A在本系统模型中主要负责识别希望接入云服务的T及其用户的身份,并给予合法T访问云服务的授权.移动应用后台的服务实际由C提供,C可能拥有多个数据中心(data center),具有强大的计算与存储能力.在云计算环境下,A和C可以位于同一公司内部,云计算平台由移动应用提供商自主搭建,移动用户可以体验一体化的云服务;A也可以租用第三方云服务提供商C提供的基础设施和计算能力,将应用服务外包给C后,由C向移动用户提供基于软件应用的云服务.图1描绘了本文所提方案的系统模型.
|
Fig. 1 System model of secure access scheme 图 1 安全接入方案的系统模型 |
3.2 安全假设与敌手模型
在系统模型中,我们假设A与C之间的数据通信建立在诸如TLS/SSL的安全传输层协议基础之上,数据的传输受到机密性、完整性和认证性的保护,C 的数据中心可以正确获取A发送的相关秘密数据.此外,T在下载由A提供的移动应用时,也被认为可以从应用中直接提取A的公钥.如何防止T从非法的移动应用市场下载敌手冒充A提供的恶意应用已经超出了本文的研究范围,在此不再赘述.
安全接入方案的运行依赖于应用提供商A对于移动终端制造商M的前提信任,在这里,A信任M只为支持TrustZone技术且符合一定安全标准的移动终端T颁发设备证书.这一假设在现实中是合理的,为了维护品牌信誉,M的行为将受到市场的监督和政府的监管.本文方案以移动终端安全为出发点,不考虑A和C自身内部的恶意行为以及可被敌手利用的安全漏洞.
根据上述安全假设,本文提出的安全接入方案可以防御具有以下能力的敌手:
· 敌手攻击方案中的安全接入协议,试图盗用或伪装移动终端和用户的合法身份访问云服务,试图窃取、伪造或篡改实体间的通信数据;
· 敌手对移动终端实施基于软件代码的攻击,破坏运行在TrustZone NW(REE)中的通用移动OS或应用程序,敌手可以访问本方案相关程序(如云服务应用客户端)在NW中的接口;
· 敌手对移动终端具有一定的物理接入能力,可以重启设备并直接读取设备中非易失性存储器的数据.
本文方案信任提供TrustZone技术的终端硬件安全性,不考虑针对TrustZone的恶意物理攻击和针对PUF的侧信道攻击.
4 可信移动终端云服务安全接入方案设计本节首先给出面向云环境的可信移动终端体系结构设计,再介绍密钥与敏感数据管理机制,然后结合体系结构和管理机制详细阐述云服务安全接入协议,最后对本文所提出的方案进行安全性分析.
4.1 可信移动终端体系结构借助TrustZone和PUF技术,我们面向云计算场景设计了可信移动终端体系结构.在现有移动终端硬件架构的基础上,我们的可信终端方案以基于软件的设计和实现为主,以低成本性、高灵活性和易扩展性为设计目标.图2展示了本文提出的可信移动终端体系结构以及各组件间的交互细节.
|
Fig. 2 Architecture of trusted mobile terminal for cloud computing 图 2 面向云计算环境的可信移动终端体系结构 |
利用文献[31]给出的方法,可以在TrustZone的SW中安全有效地构建TEE.SW中实现的TEE物理隔离于NW中实现的通用移动系统环境,SW中运行有定制的TEE OS,用于执行安全敏感的程序代码,NW中运行有通用的移动OS,该OS可以是Android或iOS系统,能够执行常规的移动应用程序.下面将详细介绍各组件的功能.
(1) 可信代理(trusted proxy)
可信代理在NW中直接与移动应用程序交互.该组件接收移动应用程序的可信服务请求,根据请求类型组装调用SW中可信服务组件的命令,为SW中的实质性安全运算做准备.该组件包含如下两个子组件:
· 软件栈(software stack):为移动应用程序提供高层可信服务接口,负责解析应用程序请求数据,并返回服务响应结果;
· 命令调用器(command caller):组装可信服务调用命令,与SW中的可信服务组件交互,通过规范的TEE客户端命令接口(GP TEE client API)[35]实现命令的发送,借助NW底层驱动请求NW向SW的切换并等待数据返回.
(2) 可信服务(trusted service)
可信服务组件是可信移动终端的核心组件,不仅实现了信任根呈现、密钥与敏感数据管理和可信环境证明等可信计算相关功能,还实现了安全计入协议在移动终端的执行逻辑.该组件的代码执行受到TrustZone隔离机制的保护,由以下5个子组件组成:
· 应用程序接口函数(API functions):接收来自NW中可信代理发送的可信服务请求,解析命令数据,将运算指令传递给逻辑引擎并等待结果返回可信代理;
· 密钥管理器(key manager):利用从SRAM PUF中提取的根密钥种子生产多种密码学密钥,将密钥提供给数据处理器使用;
· 数据处理器(data handler):为了防止敌手伪造安全参数(通常是用户名和口令),数据处理器只接收来自SW中移动应用程序可信单元的参数输入,并将参数传递给逻辑引擎;此外,该子组件还负责敏感数据的封装与解封,封装后的数据可以存储在移动设备的通用非易失性存储器中;
· 密码算法库(crypto library):为密钥管理器、数据处理器和逻辑引擎提供密码学算法支持,其实现有对称和非对称加解密与签名验证算法及多种消息摘要算法;
· 逻辑引擎(logic engine):从其他子组件获取必要的参数输入,依据所设计的安全接入协议逻辑,执行移动终端安全敏感的可信服务运算操作,输出执行结果;此外,该子组件实现了对SW中应用程序进程的加载度量和启动管控.
(3) 移动应用程序(App)和移动应用程序可信单元(App trustlet)
当移动用户希望访问C处的云服务时,无论是采用浏览器方式还是客户端方式,都需要启动相应的移动应用.针对可信移动终端,应用服务提供商A提供的移动应用包含两个部分:运行在NW中的移动应用程序和运行在SW中的移动应用程序可信单元.App只向用户提供图形用户界面(GUI)和基本的非安全敏感功能,App trustlet负责收集和预处理接入云服务所需要的敏感数据信息,并将其呈递给可信服务以用于安全接入协议的运算.当App需要通过执行安全接入协议访问云服务时,其通过调用可信代理的软件栈进行可信服务请求,在TrustZone使用系统中断完成NW向SW的切换后,可信服务将加载启动App trustlet,其代码完整性由可信服务的逻辑引擎负责度量.基于我们之前的研究工作[36],使用白名单机制在SW中一旦发现App trustlet被敌手篡改,可以禁止其启动.当App trustlet被正确启动后,用户可以在安全模式下将云服务用户名和口令等敏感数据信息输入App trustlet,进而交由可信服务进行处理.App通过TrustZone提供的域间通信机制[37]实现与App trustlet的业务通信,此处的移动应用程序设计符合当前TrustZone的常规应用模式.
(4) 内核中的组件
在SW的TEE操作系统内核中,有驱动组件SW-Driver;在NW的移动操作系统内核中,有驱动组件NW- Driver.以上两个驱动组件用于处理在TrustZone两个世界切换时的请求与响应命令,其中包含了两个世界的通信数据.作为TrustZone定义的安全监视器的实现,监视器(monitor)位于SW的系统内核中,其控制底层硬件完成TrustZone世界切换的具体动作.除了这些特殊的组件外,NW中的OS内核实现有各种通用的硬件驱动,这其中包含有网络通信驱动,可信移动终端与云服务的数据通信均依赖于该驱动.
(5) 硬件中的组件
可信移动终端设备的硬件支持ARM TrustZone扩展技术,受到该技术的保护,位于硬件中的SRAM PUF物理组件仅能被SW访问,PUF的软件算法由可信服务的密钥管理器实现.
4.2 密钥与敏感数据管理在详细阐述本文提出的云服务安全接入协议之前,首先介绍由SRAM PUF提取根密钥种子以及使用该种子派生多种不同用途密钥的方法;此外,使用派生密钥保护敏感数据的机制也将在本小节给出.
4.2.1 根密钥种子的提取本文使用文献[18]提出的SRAM PUF技术提取根密钥种子s,s是移动终端制造商M在设备生产过程中随机选取的一段具有唯一性的比特串,M利用移动终端T中SRAM特定区域的物理特性将s存储在其中.s仅在T每次正常加电启动时被从SRAM PUF组件中重现出来,并被SW中的密钥管理器安全缓存.s的机密性受到TrustZone的严格保护.
4.2.2 密钥派生在移动终端SW中,可信服务的密钥管理器具有密钥生成函数KDF(key derivation function),该函数是一种确定性的映射:$\tilde S \times \tilde P \to \tilde K$,其中,$\tilde S$是密钥种子空间,$\tilde P$是声明密钥用途的字符串参数集合,$\tilde K$是生成密钥的空间.使用KDF和根密钥种子s,可以生成唯一标识移动终端身份的设备密钥公私钥对(dpk T,dsk T),生成方式为
| $(dp{k_T},ds{k_T}) \leftarrow KD{F_s}("identity").$ |
类似地,可以生成存储根密钥srk,生成方式为srk←KDFs(“storage_root”).srk用于进一步生成存储保护实际敏感数据的存储密钥,该套存储密钥层次结构增强了密钥使用的隔离性和安全性.值得强调的一点是:这里生成的所有存储密钥和设备密钥的私钥从不离开SW,也不在移动设备的非易失性存储器上存储,如果需要使用,它们将被使用KDF以同样的方式重构,这样可以减小密钥丢失的风险.
4.2.3 敏感数据管理我们使用由srk派生的多种存储密钥对应用服务提供商A的公钥apk和云服务会话所需的密钥包(ID,kenc,kmac,ni)进行封装存储保护,这些密钥数据的具体含义及用途将在第4.3节中详细介绍.封装操作在SW可信服务的数据处理器中进行,数据处理器实现了数据封装函数Data_Seal(),封装后的数据块可以存储在设备的公共非易失性存储器中.在本文中,我们用MACk(m)表示使用密钥k对数据m计算消息认证码;Enck(m)表示使用密钥k对数据m进行加密,根据k的类型可以相应表示对称与非对称加密;Signk(m)表示签名操作;||表示数据的连接操作.以下给出具体的封装方法:
· 对于公钥apk,封装时只需保护其完整性,防止移动应用被恶意篡改后造成的公钥破坏,步骤为
| $\eqalign{ & {\text{m}}{{\text{k}}_{{\text{apk}}}} \leftarrow KD{F_{syk}}("storage\_key","MAC",apk), \cr & blo{b_{apk}} \leftarrow Data\_Seal("MAC",m{k_{apk}},apk); \cr} $ |
其中,${\text{blo}}{{\text{b}}_{{\text{apk}}}}{\text{: = apk||MA}}{{\text{C}}_{{\text{mk}}}}_{_{{\text{apk}}}}(apk)$
· 对于密钥包(ID,kenc,kmac,ni),封装时需要保护其机密性和完整性,防止敌手的窃取或篡改,步骤为
| $\eqalign{ & {\text{(s}}{{\text{k}}_{{\text{ID}}}}{\text{,m}}{{\text{k}}_{{\text{ID}}}}{\text{)}} \leftarrow {\text{KD}}{{\text{F}}_{{\text{srk}}}}("{\text{storage}}\_{\text{key}}","{\text{Enc}} + {\text{MAC}}",ID), \cr & {\text{Blo}}{{\text{b}}_{{\text{ID}}}} \leftarrow {\text{Data\_Seal("Enc}} + {\text{MAC}}",{\text{s}}{{\text{k}}_{{\text{ID}}}}{\text{,m}}{{\text{k}}_{{\text{ID}}}}{\text{,(ID,}}{{\text{k}}^{{\text{enc}}}}{\text{,}}{{\text{k}}^{{\text{mac}}}}{\text{,}}{{\text{n}}_{\text{i}}})); \cr} $ |
其中,skID为对称密钥,${\text{blo}}{{\text{b}}_{{\text{ID}}}}: = {\text{En}}{{\text{c}}_{s{k_{ID}}}}{\text{(ID,}}{{\text{k}}^{{\text{enc}}}}{\text{,}}{{\text{k}}^{{\text{mac}}}}{\text{,}}{{\text{n}}_{\text{i}}}||{\text{MA}}{{\text{C}}_{s{k_{ID}}}}({\text{ID,}}{{\text{k}}^{{\text{enc}}}}{\text{,}}{{\text{k}}^{{\text{mac}}}}{\text{,}}{{\text{n}}_{\text{i}}})).$.
利用密钥管理器中重构出的存储密钥,数据处理器可以调用Data_Unseal()函数从相应的数据块中恢复并验证敏感数据.
4.3 云服务安全接入协议云服务安全接入协议的交互参与实体有T,A和C,在正常情况下,协议执行的概述如图3所示.在某段时间内,当T首次访问位于C处的云服务时,其首先向A发送接入服务的授权请求;经过计费和合法性认证后,A生成会话密钥包,将其颁发给T;同时,A通过安全信道将已认证的用户数据发送给C,在这里,我们对C中的用户管理主机和服务运算主机不作区分;当获得授权的会话密钥包后,T使用相关密钥和认证信息向C发送服务接入请求;C对请求进行验证后,将验证结果返回T;完成接入认证后,T与C展开正常的云服务交互.我们给出的安全接入协议可以与可信云架构进行对接,实现T与C间安全执行环境的双向认证,本文假设C采用文献[13]提出的可信云架构,C在返回T服务接入请求验证结果时,将附带云端主机云服务程序的完整性度量值.
|
Fig. 3 An overview of secure access protocol under normal condition 图 3 安全接入协议在正常情况下的执行概述 |
在安全接入协议执行前,需要完成一些准备工作.T出厂之前,M选取良好的根密钥种子s存入T的SRAM PUF中,并引导T在SW中生成唯一标识身份的设备密钥对(dpkT,dskT).M为其公钥颁发设备证书,该证书能够证明T已通过M的安全与合法性测试和认证.此外,中还可包含设备T的若干配置信息,例如芯片类型、芯片版本号和TrustZone是否可用等.
以可信移动终端为核心的安全接入协议由授权申请、接入请求、验证响应和授权撤销4个部分组成,其中,授权申请只在3种情况下被执行:(1) 用户首次使用T请求接入云服务;(2) 上一次授权申请已过期;(3) 因网络错误或恶意攻击造成授权被撤销.在成功执行授权申请后,用户使用T可以在一定时间内多次请求接入云服务,协议的接入请求和验证响应可以随之多次被执行.
4.3.1 授权申请在本部分协议中,用户使用T向A发送云服务接入授权的申请,A验证申请中的相关参数,在确定T及其用户的合法性后,生成用于T与C未来进行会话的密钥包,将其分别发送给双方,具体步骤如下:
(1) 用户在NW中操作App请求访问云服务,TrustZone切换至SW,T调用KDF生成消息完整性保护密钥mkauth,该密钥用于A向T发送会话密钥包时保护数据通信的完整性,密钥生成方法为
| ${\text{m}}{{\text{k}}_{{\text{auth}}}} \leftarrow {\text{KD}}{{\text{F}}_s}("{\text{session\_key}}","{\text{MAC}}",r).$ |
其中,r是密钥管理器生成的随机数,用于生成不同的mkauth.
(2) T在SW中加载启动App trustlet时,对加载的代码进行完整性度量,利用哈希函数得到度量值m(app).基于我们的白名单机制[37],可以发现App trustlet的篡改,如果被篡改,协议将终止执行.
(3) 用户向SW的App trustlet输入登陆云服务的用户名user和口令pswd,App trustlet计算口令哈希值H(pswd)后,连同用户名一起发送给可信服务的数据处理器,可信服务将App trustlet关闭;
(4) SW中可信服务的逻辑引擎调用授权申请API:Apply(),生成授权申请消息m_apply:
| ${\text{m\_ apply}} \leftarrow {\text{Apply}}({\text{Cer}}{{\text{t}}_{\text{T}}}{\text{ ,ds}}{{\text{k}}_{\text{T}}}{\text{ ,blo}}{{\text{b}}_{{\text{apk}}}}{\text{ ,m}}{{\text{k}}_{{\text{auth }}}}{\text{,}}\mu {\text{(app),user,H}}({\text{pswd}})).$ |
该API具体执行操作如下:
1) 调用密钥管理器重构设备密钥私钥dskT;
2) 调用密钥管理器重构apk的存储保护密钥,调用数据处理器解封blobapk,得到正确的apk;
3) 调用签名函数生成签名:ω := Signdsk (mkauth ,μ (app),user,H( pswd));
4)调用加密函数生成最终的通信消息:m_ apply := Encapk (CertT ,mkauth ,μ (app),user,H( pswd),ω).
这里的apk来源于A,实际上,A为发行的每一种应用生成一对公私钥对(apk,ask),在应用程序安装时,apk可以被T提取用于与A的认证通信;此外,apk可以唯一标识一个应用程序.
(5) T从SW切换至NW,向A发送m_apply,A使用自己掌握的私钥ask解密消息,使用权威发布的M公钥证设备证书,并从中获得T的设备密钥公钥dpkT,验证相关数据的签名,提取授权申请消息的有效数据元组:
| $({\text{m}}{{\text{k}}_{{\text{auth}}}}{\text{,}}\mu {\text{(app}}){\text{,user,H}}({\text{pswd}})).$ |
(6) A根据自己发布的应用程序代码验证T中App trustlet的完整性度量值m(app),使用user和H(pswd)验证用户账户的合法性,可以对账户的余额进行检查:若相关验证失败,返回T申请失败的消息及原因;若所有验证通过,A为T和C生成会话密钥包元组(ID,kenc,kmac,n0),其中:ID唯一标识该密钥包;kenc用于保护会话的机密性;kmac用于保护会话的完整性;n0是随机选取的nonce值,用于防止重放攻击.T与C每经过一次正确的服务访问连接,各自将该值加1,第i+1次连接,使用的即为ni;
(7) A为T颁发授权的会话密钥包,A将会话密码包签名后与相关信息一起使用dpkT加密生成σ:
| $\sigma : = En{c_{dp{k_T}}}(apk,(ID,{k^{enc}},{k^{mac}},{n_0}),Sing{n_{ask}}(ID,{k^{enc}},{k^{mac}},{n_0})),$ |
其中,apk用于标识该加密数据对应的应用程序.最终,A以如下方式生成授权响应消息:
| ${\text{m reply}}: = \sigma ||MA{C_{{\text{mk}}}}_{_{{\text{auth}}}}(\sigma )$ |
(8) A将m_reply发送给T后,通过安全信道将(ID,kenc,kmac,n0)连同user和m(app)一起发送给C,C如果在数据库中通过user查找到同一用户之前的会话密钥包,则将旧的密钥包删除.会话密钥包的有效期可以根据云服务的安全敏感度设置不同的长度,可以是1天、7天或30天.该有效期记录在C处,如果超过有效期,会话密钥包将自动失效,失效的会话密钥包由C定期清理删除;
(9) T接收m_reply后切换至SW,可信服务对m_reply进行解析,通过验证消息完整性和签名正确性后,将提取的会话密钥包(ID,kenc,kmac,n0)封装为blobID,存储于移动设备中.
4.3.2 接入请求在本部分协议中,T利用会话密钥包向C发送云服务接入请求,具体步骤如下:
(1) T重新加载启动App trustlet,对加载的代码再一次进行完整性度量,利用哈希函数得到度量值μ′(app),可以使用白名单机制再次检查App trustlet是否被篡改;
(2) SW中可信服务的逻辑引擎调用云服务接入请求API:Request(),生成m_request:
| ${\text{m\_request}} \leftarrow {\text{Request}}({\text{blo}}{{\text{b}}_{{\text{ID}}}}{\text{,}}\mu '(app)).$ |
该API具体执行操作如下:
1) 调用密钥管理器重构会话密钥包的存储保护密钥,调用数据处理器解封blobID,得到正确会话密钥包元组(ID,kenc,kmac,ni);
2) 生成云服务接入请求通信消息m_request:
| ${\text{m request: = ID ||En}}{{\text{c}}_{\text{k}}}_{^{{\text{enc}}}}("{\text{request}}",{n_i},\mu '(app))||{\text{MA}}{{\text{C}}_k}_{^{enc}}(ID,En{c_k}_{^{enc}}("{\text{request}}",{n_i},\mu '(app)),$ |
其中,ID用于告知C使用哪个会话密钥包解密和验证消息;request是标识T请求C处云服务执行的命令参数,这里表示申请接入云服务的命令.
(3) T切换至NW,将m_request发送给C.
4.3.3 验证响应在本部分协议中,C利用会话密钥包解析来自T的接入请求,并将验证结果与云服务执行程序的完整性度量值返回给T,具体步骤如下:
(1) C接收到m_request后,根据其中的ID查找到数据库中对应的会话密钥包,检查会话密钥包是否仍然有效、过期或已被撤销,对于未能查找到密钥包或密钥包失效的情况,C发送标记为验证失败的响应给T,T将重新执
行授权申请协议.
(2) C使用合法密钥包解析m_request后,将其中的ni与数据库中会话密钥包记录的当前nonce值比对,如果不相同,返回验证失败的响应给T,T将重新执行授权申请协议.
(3) C将m_request中的μ′(app)与数据库中关联相应会话密钥包的原始m(app)比对,如果不相同,说明T中的App trustlet很有可能已被篡改,C将拒绝T的接入请求,返回验证失败的响应.
(4) 通过上述3步验证后,C使用可信云架构中的安全方法生成虚拟机中具体运行T所请求云服务的程序的完整性度量值μ(csp),在一些特定的应用场景中,该度量值可能来源于对整个虚拟机镜像的哈希度量,对于μ(csp)的证明方法可参见可信云架构的具体协议.
(5) C生成验证响应的通信消息m_response:
| $\eqalign{ & {\text{m\_response : = ID ||En}}{{\text{c}}_{\text{k}}}_{^{{\text{enc}}}}("{\text{response}}","{\text{passed}}",{n_i},{\text{apk}},\mu (csp)), \cr & ||{\text{MA}}{{\text{C}}_{{{\text{k}}^{{\text{mac}}}}}}{\text{ (ID ,Enc}}{{\text{ }}_{{{\text{k}}^{{\text{enc}}}}}}("{\text{response}}","{\text{passed}}",{n_i},{\text{apk}},\mu (csp))), \cr} $ |
其中,“passed”表示验证通过,公钥apk标识了消息针对的移动云应用.
(6) C将m_response发送给T后,更新nonce值:ni+1=ni+1,并设置此后接入服务次数的nonce限定值limit_n= ni+j,j代表此次验证后允许T接入云服务发送操作命令的次数,若在第x次接入时,C的ni+x>limit_n,T需要重新执行接入请求协议,使C设置更新limit_n;
(7) T收到m_response后切换至SW对其进行解析和验证,同时更新自己的会话密钥包nonce值:ni+1=ni+1,配合可信云架构的安全方法可以通过m(csp)验证云端服务程序的完整性.待验证通过,App trustlet根据用户请求云服务的具体功能向可信服务传送命令参数,可信服务使用会话密钥包组装云服务操作命令,与C进行交互通信以完成具体的云服务功能.本文第5节将给出一种基于本协议的移动云存储应用实例.
4.3.4 授权撤销当T的会话密钥包尚在有效期内但遇到以下4种情况时,T原有的合法授权将被撤销:
· C发现T当前发送的某个通信消息中的ni与云端存储的当前ni不一致;
· A发现发布的移动应用存在漏洞;
· A发布移动应用更新;
· A或C根据网络监控与分析推断会话密钥包信息可能已被泄露.
在撤销协议被触发后,C自身或由A通知C将C存储的相应会话密钥包信息删除,T只有重新执行授权申请协议才可能再次正常访问云服务.
4.4 安全性分析在第3.2节中给出的安全假设下,本文提出的可信移动终端云服务安全接入方案具有数据机密性与完整性、用户身份不可伪造性、授权不可伪造性、应用程序可证明性、授权可撤销性和设备丢失保护性6种安全属性.假设密码学原语(如加密解密、签名验证和消息认证码等操作)的实现是安全的,以下给出对本方案的非形式化安全分析.
(1) 数据机密性与完整性
数据机密性与完整性一方面指的是可信移动终端对用户数据和接收到的敏感数据提供本地的机密性和完整性保护,另一方面指的是T和A之间以及T和C之间数据通信受到机密性和完整性的保护.
· 首先,用户的核心数据,即用户名和口令,只被允许输入到T的SW中,这由App trustlet的安全性和TrustZone的隔离机制提供保护,而App trustlet的安全加载受到SW中可信服务的监控,因此,用户口令难以以明文的形式流入T的NW中,这减小了其受到恶意代码攻击的可能;类似地,在接入云服务后,用户的私有信息均通过App trustlet输入,经过SW中的密码学处理后受保护地发送给云端.可信移动终端对于提取到的移动应用公钥和接收到的会话密钥包进行封装存储,封装过程在SW中完成,封装使用的密钥不会泄露到SW外,因此上述数据在可信移动终端通用非易失性存储器上的存储是安全的;
· 其次,即使敌手攻破了移动终端的NW,也无法通过窥探SW可信服务的接口获取有价值的数据.这是因为流入NW的敏感数据都是经过SW加密或封装的;
· 最后,T和A之间以及T和C之间的数据通信受到方案的安全接入协议保护,其中:T向A发送的授权申请消息m_apply机密性受到应用公钥apk的保护,完整性间接由设备证书CertT及证书中的相关信息提供保护;A向T返回的的授权响应消息m_reply机密性受到设备密钥公钥保护,完整性受到密钥mkauth保护;授权申请过程中,敌手无法通过转发m_apply实现重放攻击,这源于他没有T的设备密钥私钥,进而也无法从获得的m_reply中解密出合法的会话密钥包;T与C之间的所有通信消息(包括m_request和m_response)的机密性和完整均受到密钥kenc和kmac的保护,消息新鲜性由ni给予保护.
(2) 用户身份不可伪造性用户身份不可伪造性指的是:在没有获得某用户U的用户名和口令的情况下,敌手无法伪造U的合法身份并冒名接入U的云服务账户.由上一个安全属性可知:敌手无法通过攻击本方案获取U的口令,也无法直接截获由A颁发给U的会话密钥包;在没有U的口令情况下,即使敌手使用一个合法的移动设备向A发送授权申请,他也无法通过验证并获得U与C的会话密钥包.缺少U的会话密钥包,敌手无法接入U的云服务,也无法访问其云端的私有数据.
(3) 授权不可伪造性
授权不可伪造性指的是:敌手无法伪造A的身份颁发合法的会话密钥包,进而利用密钥包访问用户U的云端私有数据.根据假设,T可以安全获取A为移动应用生成的公钥apk,T使用apk加密相关数据后生成授权申请消息m_apply,因为缺乏私钥ask,敌手无法解密m_apply,也就无法生成具有A签名的且由mkauth保护完整性的授权响应消息m_reply,这使得敌手无法向T发送伪造的会话密钥包.类似地,A与C的通信受到安全信道的保护,敌手无法将伪造的会话密钥包成功地发送给C.在无法伪造会话密码包的情况下,敌手无法介入T与C的数据通信.
(4) 应用程序可证明性
应用程序可证明性指的是:移动终端中,执行敏感数据操作的App trustlet和云服务端提供服务的程序代码可被度量和报告,实现完整性的证明.可证明性的概念来源于可信计算技术,在移动终端,可信服务对App trustlet进行度量得到m(app),在授权申请时,移动终端对μ(app)签名后发送给C,C通过验证签名和比对μ(app)可以确定移动终端T运行的App trustlet没有被篡改.反过来,本方案接入可信云架构时,可以通过比对μ(csp)来判断云服务主机上运行的云服务程序是否被篡改.只有完成双向的完整性验证,用户才能放心的通过T接入C,C才能安全接收T的消息,减少恶意代码入侵的几率.
(5) 授权可撤销性
授权可撤销性指的是方案支持特殊情况下对合法授权的紧急撤销,这样可以尽可能地减少用户的损失.根据安全接入协议的撤销部分功能,A与C一旦发现网络通信可能被攻击、移动应用存在漏洞、用户版本老旧或会话密钥包可能被泄露,将触发撤销协议.本方案的撤销协议既可以作为一种主动防御措施,又可以作为一种紧急补救措施,提升方案整体的可控性和安全性.
(6) 设备丢失保护性
设备丢失保护性指的是:当用户发现自己的移动终端设备丢失且之前正确接入过云服务时,可以通过一定的主动行为阻止丢失设备再次接入自己的云服务账户,保护自己的隐私数据.在本方案中,用户只要使用另一台合法的移动终端设备和自己的用户名与口令再次尝试接入一次自己的云服务即可.当授权申请被重新执行后,新生成的会话密码包连同user被发送到C,C如果在数据库中通过user查找到之前旧的会话密钥包,则将其删除以替换新的密钥包,敌手无法使用丢失设备继续访问失主的云服务账户.
5 移动云存储应用实例基于本文提出的可信移动终端云服务安全接入方案,我们设计了一个移动云存储应用实例MCFile.MCFile的安全目标主要包括:(1) 保护移动终端用户向云服务器发送和接收文件的机密性和完整性;(2) 云服务端能够对移动终端用户的接入请求和文件访问采取强制的安全认证和访问控制策略.仿照当前市场上的云存储应用,MCFile实现的云存储服务操作命令可以有:创建文件(create)、删除文件(delete)、写文件(write)、读文件(read)、添加权限(addright)和取消权限(removeright).
假设有两个用户,其用户名分别为user1和user2,user1在云端存储有名为F user1的文件,那么在user1使用移动终端T成功执行完云服务安全接入协议的验证响应后,可以在SW中生成如下云服务请求命令读取云端文件F user1:
| ${\text{ID}}||En{c_{{{\text{k}}^{{\text{enc}}}}}}("red",{F_{{\text{user}}1}},{n_{i + 1}})||MA{C_{{{\text{k}}^{{\text{enc}}}}}}(ID,En{c_{{{\text{k}}^{{\text{enc}}}}}}("red",{F_{{\text{user}}1}},{n_{i + 1}})).$ |
C收到命令后,根据ID查找相关联的会话密钥包和用户名user1,在解析请求命令并验证命令的合法性后,C检查user1对于文件F user1拥有的权限,如果判断为可读,则返回以下服务响应:
ID|| Enc kenc ("Res_read", "true", ni+1,apk, File(Fuser1) ||MACkenc (ID,Enc kenc ("Res_read", true2,ni+1, apk, File, (Fuser1)) .
其中File(F user1)表示F user1指明的文件实体,使用数据分块技术可以实现大体积文件的网络加密传输.
如果user1希望将文件F user1分享给user2阅读,其可以将F user1的可读权限添加给user2,相应的云服务请求命令如下:
ID|| Enc kenc ("addright", user2,"read", Fuser1, ni+1) ||MACkenc (ID,Enc kenc ("addright",user2,"read", Fuser1,ni+1)) .
C收到命令经过一些列验证后,在文件F user1的权限列表中增加user2可读的条目,但此时F user1的拥有者仍是user1,user1可以发送命令取消user2对F user1的可读权限.此外,当在上述请求命令中使用符号*代替user2时,user1将F user1可读的权限赋予给所有合法用户,即实现了文件的公开分享.MCFile其他云存储服务功能的实现方式可以以此类推,在此不再过多叙述.
6 实 现我们实现了本文方案的原型系统,第7节将给出基于该原型系统的方案评估,以下先从硬件平台和软件实现两个方面详细介绍原型系统的实现方法.
6.1 硬件平台我们分别模拟实现了移动终端T、应用服务提供商A和云服务提供商C.对于移动终端设备的仿真实现,我们采用了嵌入式开发板Zynq-7000 AP Soc Evaluation Kit[38].该开发板支持TrustZone安全扩展,配备有ARM Cortex-A9 MPCore处理器、1GB DDR3内存以及包括256KB SRAM在内的OCM(on-chip memory)模块.由于该开发板加电后,SRAM会立刻被引导只读存储器BootROM初始化,我们无法直接读取SRAM的初始数据,因此,我们使用一块SRAM芯片作为我们的SRAM PUF,该芯片型号为IS61LV6416-10TL[39].SRAM芯片的初始数据由通用异步收发器UART(universal asynchronous receiver/transmitter)传送到Zynq开发板上,我们使用Verilog硬件描述语言以FPGA的方式实现了UART.在Zynq开发板上,UART接收器将SRAM初始数据存储在RAM缓存中,开发板处理器可以通过总线从RAM缓存中读取SRAM初始数据.在安全世界SW中,我们使用了Open Virtualization SirerrTEE作为TEE OS,该OS与GP的TEE规范[28]相兼容.在普通世界NW中,我们使用内核版本为3.8.6的Linux系统作为REE OS,该系统是SirerrTEE项目中提供的具有NW-Driver和GP TEE Client API的Linux.
对于应用服务提供商的仿真实现,我们使用了一台戴尔OptiPlex 990台式计算机,该计算机配备3.3GHz Intel i3-2120双核处理器和4GB内存,运行有内核版本为Linux 2.6.32的Ubuntu10.04操作系统.对于云服务提供商的仿真实现,我们使用了一台联想ThinkCentre M8500t台式计算机,配备有3.4GHz Intel i7-4770四核处理器和8GB内存,操作系统与前者相同.
6.2 软件实现在仿真移动终端的嵌入式开发板上,以C语言为主的软件实现主要分两个部分:在SW中,我们实现了可信服务,其中的密钥管理器包含有PUF模糊提取器,具备使用SRAM PUF的能力,模糊提取器使用开源的BCH代码[40]实现;对于密码算法库,我们利用OpenSSL-0.9.8y实现了所需的密码学算法.在具体实现过程中:我们使用密钥长度为2048 bit的RSA作为非对称加解密与签名验证算法;128 bit安全强度的AES作为对称加解密算法; SHA256作为MAC和代码完整性度量算法,MAC实现时将128 bit MAC密钥填充为SHA256的前128 bit进行计算.在NW中,我们在通用OS上实现了相应的可信代理.此外,具备最基本功能的App和App trustlet也被实现,App trustlet可以模拟用户输入用户名和口令.
在两个台式计算机上,我们使用C语言分别实现了安全接入方案中实体A和实体C所需执行的安全接入协
议的程序代码,配套算法同样采用OpenSSL-0.9.8y实现.对于网络通信与交互,两台计算机均以服务器的形式实现,提供C语言实现的socket连接,支持并发的连接请求与数据处理.
7 评估 7.1 代码量与可信计算基在方案的原型系统中,实现各组件的C程序代码近似行数(lines of code,简称LoC)见表1.一台设备的可信计算基(trusted computing base,简称TCB)是实现设备安全所需的软件、硬件和固件集合,其规模越小越不容易产生可被敌手利用的漏洞,安全性也相对更容易被保证.本文方案中,可信移动终端的TCB仅包含移动设备硬件和运行在SW中的软件,根据文献[41]中所述,目前被投入移动商业市场的某型SW安全OS具有6000 LoC,如果采用该型OS,加上我们实现的可信服务和App trustlet,本文方案的TCB软件部分仅有约9100 LoC.这一规模是相对较小的,系统安全的可控性相对较高.
|
Table 1 Code sizes and TCB of implemented components 表 1 实体组件代码量与TCB |
7.2 性能评估 7.2.1 移动终端方案性能评估
使用原型系统,我们对移动终端T在执行本文方案时所需要的相关操作进行了实验,操作包括封装与解封敏感数据以及生成与解析授权申请、接入请求和云服务请求过程中的通信交互消息,其中,云服务请求与响应消息不考虑具体的云服务命令.各操作时间开销统计结果取100次运行的平均值,实验结果见表2.
|
|
Table 2 Time overheads of the operations on mobile terminal 表 2 移动终端相关操作执行的时间开销 |
从实验结果中可以看出:主要采用对称加解密和消息摘要算法的数据封装与解封操作、接入请求生成与与验证响应解析和云服务请求生成与云服务响应解析的时间开销均不超过0.16ms,这些操作在移动终端执行本方案时被较为频繁地使用.相对应的,由于使用了非对称加解密和签名验证算法,授权申请的生成和授权响应的解析操作耗时在130ms左右.这一时间开销造成的移动用户等待时延是完全可以接受的,而且该操作仅在用户首次使用移动设备等3种情况下执行(见第4.3节),使用频率相对较低.本实验基于资源受限的嵌入式开发板完成,如果使用目前市场主流的移动终端设备,运算性能会有较大幅度的提高,方案的时间开销会进一步下降.因此,根据实验结果可知:本文方案在移动终端具有良好的运行性能,各操作引起的等待时延几乎不会给用户带来困扰.
7.2.2 服务端方案性能评估使用原型系统,我们对应用服务提供商A和云服务提供商C在执行本文方案时所需要的相关操作进行了实验.A在方案中主要负责接收和解析移动终端发送的授权申请消息,并对其进行验证后生成授权响应消息.实验时,我们将这一过程作为一次响应.首先,我们实验了A单线程完成一次响应的时间开销,耗时取独立100次运行的平均值,实验结果为单线程单次响应耗时13.225ms.随后,我们实验了A接收大量授权申请时在使用线程池并发执行的情况下完成单条响应所需要的时间,实验结果如图4所示.从图中可以看出:随着并发请求数量从100个上升到500个,单条请求的响应时间从约400ms增长到约2 300ms.这一较大幅度的增长源于A在一次响应过程中需要执行非对称加密、解密和签名、验证各一次,这些运算较为消耗系统资源.我们的实验基于通用台式计算机完成,考虑到实际应用中A通常由若干专业服务器集群实现,经过优化的并发响应速度将会有很大的提升空间.此外,移动用户执行授权申请的频率不高,相比于移动网络延时,2 000ms左右的服务器响应延时也是可以被接受的.
|
Fig. 4 Authorization response latency in A 图 4 A对授权申请的响应延时 |
C在方案中主要负责接收和解析移动终端发送的接入请求消息,并对其进行验证后生成验证响应消息.实验时,我们将这一过程作为一次响应.同样地,我们首先实验了C单线程完成一次响应的执行情况,实验结果为单线程单次响应耗时0.016ms.随后,我们实验了C在并发执行的情况下完成单条响应的时间,实验结果如图5所示.从图中可以看出:随着并发请求数量的上升,单条请求的响应时间从约0.030ms增长到约0.100ms,绝对数值与增长幅度均不大,这源于C在一次响应过程中需要的运算操作并不消耗大量的系统资源.除了发送验证响应消息给移动终端外,C还将与移动终端大量交互以完成具体的云服务功能响应,这些响应处理方式与验证响应基本一致.在不考虑具体云服务操作情况下,响应时间开销将与图5中的实验结果处于同一水平.C负责处理的请求响应在本方案中将会被频繁执行,其占据方案实际运行交互量的较大比重,实验中反映出的低响应延时表明了方案在云服务提供商处具有良好的性能.
|
Fig. 5 Authentication response latency in C 图 5 C对接入请求的响应延时 |
综合服务器端的性能表现,本文方案对于移动用户来说整体上具有较高的运行效率,所有操作等待和服务响应时延均在可接受范围内.
8 讨 论本文提出的可信移动终端云服务安全接入方案可以有效防止敌手访问、窃取和篡改合法用户在云端服务存储的隐私数据,然而方案并没有考虑用户对于应用服务提供商A和云服务提供商C的匿名性:首先A可以利用唯一的设备证书识别用户移动终端的身份;其次,A和C可以利用用户名user识别用户的身份.在识别身份的情况下,A和C可以链接用户或者移动终端对于云服务操作的所有行为,这间接导致了用户隐私的泄露.在某些场景中,例如移动云购物,用户可能在访问云服务购物时希望具有一定的匿名性,不愿意自己的购物和支付行为被服务提供者链接以造成购物习惯等隐私信息的泄露.事实上,现有的匿名认证系统可以解决这一问题,既能完成对用户和终端的合法性认证,又可以保护用户的匿名性.
在众多匿名认证系统中,直接匿名证明(direct anonymous attestation,简称DAA)协议由TCG最先正式发布用于基于TPM的匿名证明,现已被接收为ISO标准.该协议可以被适当修改后应用于本文方案,以实现服务提供商对用户的匿名认证.在之前的工作中.我们基于DAA协议专为移动终端设计了DAA-TZ方案[42],方案使用了TrustZone的良好特性,可以提供安全高效的匿名认证服务,方案系统已被完整实现并进行了测试.因此,结合DAA-TZ,设计和实现具有匿名属性的可信终端云服务安全接入方案已成为可能.
9 总 结本文针对移动云计算场景分析了移动终端接入云服务的相关安全问题,提出了一种可信移动终端云服务安全接入方案.该方案首先利用TrustZone安全扩展技术构建可信移动终端体系结构,可信移动终端使用SRAM PUF获得根密钥种子,实现了密钥与敏感数据的安全管理机制;其次,借鉴可信计算技术思想,在可信移动终端的基础上设计了云服务安全接入协议,协议兼容可信云计算架构.本文分析了方案具有的安全属性,给出了基于方案设计的移动云存储应用实例,实现了方案的原型系统.分析和实验结果表明:本文提出的安全接入方案能够有效实现移动终端在接入云服务过程中的安全认证,保护移动用户在云服务端的私有数据安全;方案具有较好的可扩展性和较小的移动终端TCB,其整体运行效率较高,移动用户等待时延在可接受范围之内.在未来的工作中,我们将对方案中提出的安全接入协议进行形式化分析,给出更为详细的安全证明.
致谢: 在此,感谢中国科学院软件研究所赵世军博士、首都师范大学张倩颖博士对本文工作的支持和帮助,感谢实验室杨糠同学在本文写作过程中给予的建议和鼓励.| [1] | Dinh HT, Lee C, Niyato D, Wang P. A survey of mobile cloud computing: Architecture, applications, and approaches. Wireless Communications & Mobile Computing, 2013, 13 (18) :1587–1611 . [doi:10.1002/wcm.1203] |
| [2] | Alzahrani A, Alalwan N, Sarrab M. Mobile cloud computing: advantage, disadvantage and open challenge. In: Proc. of the 7th Euro American Conf. on Telematics and Information Systems. ACM Press, 2014. [doi:10.1145/2590651.2590670] |
| [3] | Preston AC. Mobile cloud computing: Devices, trends, issues, and the enabling technologies. IBM Developer Works, 2011 . |
| [4] | Fernando N, Seng WL, Rahayu W. Mobile cloud computing: A survey. Future Generation Computer Systems, 2013, 29 (1) :84–106 . [doi:10.1016/j.future.2012.05.023] |
| [5] | Visiongain. Mobile cloud computing industry outlook report. 2011-2016. Report, 2011 :1–153 . |
| [6] | Feng DG, Zhang M, Zhang Y, Xu Z. Study on cloud computing security. Ruan Jian Xue Bao/Journal of Software, 2011, 22 (1) :71–83 . [doi:10.3724/SP.J.1001.2011.03958] |
| [7] | Wang YD, Yang JH, Xu C, Ling X, Yang Y. Survey on access control technologies for cloud computing. Ruan Jian Xue Bao/ Journal of Software (in Chinese with English abstract), 2015, 26 (5) :1129–1150 . [doi:10.13328/j.cnki.jos.004820] |
| [8] | Chris H, Paul S. Security guidance for critical areas of focus in cloud computing V3.0. Technique Guidance, Cloud Security Alliance, 2011. |
| [9] | Proudler G, Chen LQ, Dalton C. Trusted Computing Platforms. Berlin, Heidelberg: Springer-Verlag, 2014 . |
| [10] | Nicolae P. Trusted computing and secure virtualization in cloud computing [MS. Thesis]. Swedish Institute of Computer Science, 2012. |
| [11] | Zhao B, Yan F, Zhang LQ, Wang J. Build trusted cloud computing environment. Communications of CCF (China Computer Federation) (in Chinese with English abstract), 2012, 8 (7) :28–34 . |
| [12] | Santos N, Gummadi KP, Rodrigues R. Towards trusted cloud computing. 2009. https://www.usenix.org/legacy/event/hotcloud09/ tech/full_papers/santos.pdf |
| [13] | John M, Tom R, Fred S. The CloudProxy Tao for trusted vomputing. Technical Report, No.UCB/EECS-2013-135, University of California at Berkeley, 2013. http://www.eecs.berkeley.edu/Pubs/TechRpts/2013/EECS-2013-135.html |
| [14] | Ko RKL, Jagadpramana P, Mowbray M, Pearson S, Kirchberg M, Liang Q, Lee BS. TrustCloud: A framework for accountability and trust in cloud computing. In: Proc. of the 2011 IEEE World Congress on Services. IEEE Computer Society, 2011. 584-588. [doi:10.1109/SERVICES.2011.91] |
| [15] | Martignon, L, Poosankam P, Zaharia M, Han J, Mccamant S, Song D, Paxson V, Perrig A, Shenker S, Stoica I. Cloud terminal: Secure access to sensitive applications from untrusted systems. In: Proc. of the 2012 USENIX Conf. on Annual Technical Conf. 2012. 14-14. |
| [16] | Trusted Computing Group. TPM MOBILE with trusted execution environment for comprehensive mobile device security. White Paper, Trusted Computing Group, Incorporated, 2012 . |
| [17] | ARM. ARM security technology: Building a secure system using TrustZone technology. ARM Limited, 2009. http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf |
| [18] | Zhao SJ, Zhang QY, Hu GY, Qin Y, Feng DG. Providing root of trust for ARM TrustZone using on-chip SRAM. In: Proc. of the 4th Int’l Workshop on Trustworthy Embedded Devices. ACM Press, 2014. [doi:10.1145/2666141.2666145] |
| [19] | Trusted Computing Group. TPM main specification, version1.2, revision 116. Trusted Computing Group, Incorporated, 2011. http://www.trustedcomputinggroup.org |
| [20] | Trusted Computing Group. Trusted platform module library, family 2.0, revision 01.16. Trusted Computing Group, Incorporated, 2014. http://www.trustedcomputinggroup.org |
| [21] | Wu QX, Yang XW, Zou H, Yu FJ, Ning XK, Wang Z. Technic specification of cryptography supporting platform for trusted computing. China State Password Administration Committee (in Chinese), 2007 . |
| [22] | Berger S, Caceres R, Goldman KA, Perez R, Sailer R, Doorn L. vTPM: Virtualizing the trusted platform module. In: Proc. of the 15th USENIX Security, 2006. 305-320. |
| [23] | Mccune JM, Li Y, Qu N, Zhou Z, Datta A, Gligor V, Perrig A. TrustVisor: Efficient TCB reduction and attestation. In: Proc. of the IEEE Symp. on Security and Privacy (S&P), IEEE, 2010. 143-158. [doi:10.1109/SP.2010.17] |
| [24] | Klein A, Mannweiler C, Schneider J. Access schemes for mobile cloud computing. In: Proc. of the 11th Int’l Conf. on Mobile Data Management. IEEE, 2010. 387-392. [doi:10.1109/MDM.2010.79] |
| [25] | Khana AN, Kiaha MLM, Khanb SU, Madanic SA. Towards secure mobile cloud computing: A survey. Future Generation Computer Systems, 2013, 29 (5) :1278–1299 . [doi:10.1016/j.future.2012.08.003] |
| [26] | Wu C, Zhou YJ, Patel K, Liang ZK, Jiang XX. AirBag: Boosting smartphone resistance to malware infection. In: Proc. of the 2014 Network and Distributed System Security Symp. (NDSS 2014). Internet Society, 2014. |
| [27] | Trusted Computing Group. TCG mobile trusted module specification, version1.0, revision 7.02. Trusted Computing Group, Incorporated, 2010. http://www.trustedcomputinggroup.org |
| [28] | Samuel AB, Don F, Virginie G, Franz H, Janne H, Milas F. The trusted execution environment: Delivering enhanced security at a lower cost to the mobile market. White Paper, GlobalPlatform, 2011 . |
| [29] | Atul V. Get into the zone: Building secure systems with ARM TrustZone technology. White Paper, Texas Instruments, 2013 . |
| [30] | Santos N, Raj H, Saroiu S, Wolman A. Using ARM TrustZone to build a trusted language runtime for mobile applications. In: Proc. of the ASPLOS 2014. ACM Sigplan Notices, 2014,49(1):67-80. [doi:10.1145/2541940.2541949] |
| [31] | Yang B, Feng DG, Qin Y. A lightweight anonymous mobile shopping scheme based on DAA for trusted mobile platform. In: Proc. of the IEEE 13th Int’l Conf. on Trust, Security and Privacy in Computing and Communications (TrustCom 2014). IEEE, 2014. 9-17. [doi:10.1109/TrustCom.2014.6] |
| [32] | Samsung. An overview of Samsung KNOX. White Paper, Samsung Electronics Co., Ltd, 2013 . |
| [33] | Dodis Y, Reyzin L. Fuzzy extractors: How to generate strong keys from biometrics and other Noisy data. In: Proc. of the Advances in Cryptology (EUROCRYPT 2004). Berlin, Heidelberg: Springer-Verlag, 2004. 523-540. [doi:10.1007/978-3-540-24676-3_31] |
| [34] | Guajardo J, Kumar SS. FPGA intrinsic PUFs and their use for IP protection. In: Proc. of the 9th Int’l Workshop on Cryptographic Hardware and Embedded Systems. Berlin, Heidelberg: Springer-Verlag, 2007. 63-80. [doi:10.1007/978-3-540-74735-2_5] |
| [35] | GlobalPlatform Device Technology. TEE client API specification version 1.0. GlobalPlatform, 2010. http://globalplatform.org |
| [36] | Zhang YJ, Feng DG, Qin Y, Yang B. A TrustZone based trusted code execution with strong security requirements. Journal of Computer Research and Development, 2015, 52 (10) :2224–2238 . |
| [37] | Jang J, Kong S, Kim M, Kim D, Kang BB. SeCReT: Secure channel between rich execution environment and trusted execution environment. In: Proc. of the 2015 Network and Distributed System Security Symp. (NDSS 2015). Internet Society, 2015. [doi:10.14722/ndss.2015.23189] |
| [38] | Xilinx. Zynq-7000 all programmable SoC ZC702 evaluation kit. http://www.xilinx.com/products/boards-and-kits/ek-z7-zc702-g.html |
| [39] | Integrated Silicon Solution, Inc. IS61LV6416-10TL. http://www.alldatasheet.com/datasheet-pdf/pdf/505020/ISSI/IS61LV6416- 10TL.html |
| [40] | Morelos-Zaragoza R. Encoder/decoder for binary BCH codes in C (Version 3.1). http://www.rajivchakravorty.com/source-code/uncertainty/multimedia-sim/html/bch_8c-source.html |
| [41] | Li WH, Li HB, Chen HB, Xia YB. AdAttester: Secure online mobile advertisement attestation using TrustZone. In: Proc. of the 13th Annual Int’l Conf. on Mobile Systems, Applications, and Services (MobiSys 2015). ACM Press, 2015. 75-88. [doi:10.1145/2742647.2742676] |
| [42] | Yang B, Yang K, Qin Y, Zhang ZF, Feng DG. DAA-TZ: An efficient DAA scheme for mobile devices using ARM TrustZone. In: Proc. of the 8th Int’l Conf. on Trust and Trustworthy Computing (TRUST 2015). LNCS 9229, Springer Int’l Publishing, 2015. 209-227. [doi:10.1007/978-3-319-22846-4_13] |
| [6] | 冯登国, 张敏, 张妍, 徐震. 云计算安全研究. 软件学报, 2011,22 (1) :71–83. [doi:10.3724/SP.J.1001.2011.03958] |
| [7] | 王于丁, 杨家海, 徐聪, 凌晓, 杨洋. 云计算访问控制技术研究综述. 软件学报, 2015,26 (5) :1129–1150. [doi:10.13328/j.cnki.jos.004820] |
| [11] | 赵波, 严飞, 张立强, 王鹃. 可信云计算环境的构建. 中国计算机学会通讯, 2012,8 (7) :28–34. |
| [21] | 吴秋新, 杨贤伟, 邹浩, 余发江, 宁晓魁, 王梓. 可信密码支撑平台技术规范. 国家密码管理局, 2007 . |
| [36] | 张英骏, 冯登国, 秦宇, 杨波. 基于TrustZone的强安全需求环境下可信代码执行方案. 计算机研究与发展, 2015,52 (10) :2224–2238. |