基于可信执行环境集成虚拟机的方法、终端与流程

文档序号:12818750阅读:382来源:国知局
基于可信执行环境集成虚拟机的方法、终端与流程

本发明涉及可信执行技术,尤其涉及一种基于可信执行环境集成虚拟机的方法、终端。



背景技术:

目前,终端大多集成了可信执行环境(tee,trustedexecutionenvironment),如图1所示,终端包括应用执行环境(ree,richexecutionenvironment)和tee。其中,ree由客户端应用(ca,clientapplication)、客户端应用程序编辑接口(clientapi,clientapplicationprogramminginterface)以及应用操作系统(richos,richoperatingsystem)组成。tee由可信应用(ta,trustedapplication)、内部应用程序编辑接口(internalapi,internalapplicationprogramminginterface)以及可信操作系统(trustedos,trustedoperatingsystem)组成。

其中,ree与终端操作系统(os,operatingsystem)一样,如安卓(android)系统,ree支持丰富的应用,但是,ree存在一定的安全风险。tee是终端中一块独立的区域,向该区域安装应用受管理服务器平台(tsm,trustedservermanager)控制;该区域可接管关键设备、提供硬件级别的安全隔离、以及保护资源和执行可信代码。ree只能通过专用的clientapi访问ta。ca为运行于ree系统的客户端应用,如支付宝。ta为运行在tee系统中的可信应用,为相应的ca提供安全服务,如输入密码,保存交易记录等。ca通过调用clientapi来访问ta。ta通过调用internalapi实现安全存储、加解密等安全服务。tsm为tee系统的管理服务器平台,可以提供ta的下载、删除等服务。

用户在ree(如安卓(android))系统中使用ca(如支付宝)提供的服 务时,ca与tee系统中相应的ta进行交互,以使用tee系统提供的安全服务(如存储认证密钥、存储指纹信息、加解密等),从而保证ca服务的安全性。

全球平台国际标准组织(gp,globalplatform)定义了tee系统的基本框架,并且在ree系统中定义了clientapi以及在tee系统中定义了internalapi。gp提供了认证服务,来认证终端的tee系统的安全性及internalapi是否符合gp的规范。

参照图2,以用户手机支付为例对tee系统的工作原理进行说明如下:

1、用户打开支付应用(ca),如手机银行进行支付。

2、当输入密码时,支付应用通过clientapi调用tee系统中的支付插件(ta)。此时切换到tee系统,避免在ree系统中输入密码遭到窃取。

3、支付插件通过调用internalapi,弹出个人身份号码(pin,personalidentificationnumber)输入界面,用户输入密码后将密码加密传并输至业务平台进行验证,验证成功后完成支付。

目前gp没有考虑到ta的跨平台问题,仅仅使用c语言定义了internalapi,gp没有规定统一的trustedos以及ta可执行文件格式,这样,对于每种型号的终端都必须针对各自型号使用c语言开发维护相应的ta,给运营商通过tsm管理ta带来了非常大的麻烦。



技术实现要素:

为解决上述技术问题,本发明实施例提供了一种基于可信执行环境集成虚拟机的方法、终端。

本发明实施例提供的基于可信执行环境集成虚拟机的方法,包括:

基于ca调用opensession指令,所述opensession指令中携有至少如下参数:虚拟机对应的uuid1、可信应用ta对应的uuid2;

通过tee对所述opensession指令进行解析,得到所述虚拟机对应的uuid1,并将所述opensession指令发送至所述uuid1指向的虚拟机;

通过所述虚拟机对所述opensession指令进行解析,得到所述ta对应的 uuid2,并将所述opensession指令发送至所述uuid2指向的ta,以建立所述ca与所述ta之间的连接。

本发明实施例中,所述方法还包括:在ree中建立lib库,所述lib库用于调用所述opensession指令;

所述基于ca调用opensession指令,包括:

基于ca调用所述lib库中的opensession指令,并在所述opensession指令中将所述虚拟机对应的uuid1设置在标准字段中,将所述ta对应的uuid2设置在自定义字段中。

本发明实施例中,所述通过tee对所述opensession指令进行解析之前,所述方法还包括:

调用clientapi将所述opensession指令发送至所述tee。

本发明实施例中,所述通过所述虚拟机对所述opensession指令进行解析,得到所述ta对应的uuid2,并将所述opensession指令发送至所述uuid2指向的ta,包括:

在所述opensession指令中将所述标准字段中的所述虚拟机对应的uuid1修改为所述ta对应的uuid2;

将修改后的所述opensession指令发送至所述uuid2指向的ta。

本发明实施例中,所述方法还包括:

通过所述ta调用虚拟api,以及所述虚拟机调用internalapi为所述ca提供安全服务。

本发明实施例中,所述虚拟机对一个opensession指令进行处理,或者两个以上opensession指令同时进行处理。

本发明实施例提供的终端,包括:

第一调用单元,用于基于ca调用opensession指令,所述opensession指令中携有至少如下参数:虚拟机对应的uuid1、ta对应的uuid2;

第一处理单元,用于通过tee对所述opensession指令进行解析,得到所述虚拟机对应的uuid1,并将所述opensession指令发送至所述uuid1指向的虚 拟机;

第二处理单元,用于通过所述虚拟机对所述opensession指令进行解析,得到所述ta对应的uuid2,并将所述opensession指令发送至所述uuid2指向的ta,以建立所述ca与所述ta之间的连接。

本发明实施例中,所述终端还包括:设置单元,用于在ree中建立lib库,所述lib库用于调用所述opensession指令;

所述第一调用单元,还用于基于ca调用所述lib库中的opensession指令,并在所述opensession指令中将所述虚拟机对应的uuid1设置在标准字段中,将所述ta对应的uuid2设置在自定义字段中。

本发明实施例中,所述第一调用单元,还用于调用clientapi将所述opensession指令发送至所述tee。

本发明实施例中,所述第二处理单元包括:

修改子单元,用于在所述opensession指令中将所述标准字段中的所述虚拟机对应的uuid1修改为所述ta对应的uuid2;

发送子单元,用于将修改后的所述opensession指令发送至所述uuid2指向的ta。

本发明实施例中,所述终端还包括:第二调用单元,用于通过所述ta调用虚拟api,以及所述虚拟机调用internalapi为所述ca提供安全服务。

本发明实施例中,所述虚拟机对一个opensession指令进行处理,或者两个以上opensession指令同时进行处理。

本发明实施例的技术方案中,基于ca调用opensession指令,所述opensession指令中携有至少如下参数:虚拟机对应的通用唯一标识码(uuid,universallyuniqueidentifier)1、a对应的uuid2;通过tee对所述opensession指令进行解析,得到所述虚拟机对应的uuid1,并将所述opensession指令发送至所述uuid1指向的虚拟机;通过所述虚拟机对所述opensession指令进行解析,得到所述ta对应的uuid2,并将所述opensession指令发送至所述uuid2指向的ta,以建立所述ca与所述ta之间的连接。这里,虚拟机尤指java虚拟机, 考虑到java具有较好的跨平台特性,本发明实施例在符合gp定义的tee系统中集成java虚拟机(vm,virtualmachine)及运行环境(也相当于os),来实现ta。这样,运营商通过tsm管理ta时,不需要针对特定型号的终端进行ta的开发和后续维护,给运营商带来了极大的便利性。

附图说明

图1为现有终端的系统架构图;

图2为tee系统的工作原理示意图;

图3为本发明实施例的终端的系统架构图;

图4为本发明实施例的ca与ta的交互流程示意图一;

图5为本发明实施例的ca与ta的交互流程示意图二;

图6为本发明实施例的基于可信执行环境集成虚拟机的方法的流程示意图;

图7为本发明实施例的终端结构组成示意图。

具体实施方式

为了能够更加详尽地了解本发明的特点与技术内容,下面结合附图对本发明的实现进行详细阐述,所附附图仅供参考说明之用,并非用来限定本发明。

考虑到java具有较好的跨平台特性,本发明实施例在符合gp定义的tee系统中集成java虚拟机(vm,virtualmachine)及运行环境(也相当于os),来实现ta。这样,运营商通过tsm管理ta时,不需要针对特定型号的终端进行ta的开发和后续维护,给运营商带来了极大的便利性。

基于此,本发明实施例旨在基于符合gp认证的tee系统上,将javavm集成在tee系统中,以实现ree系统中的ca可以访问到tee系统中的ta。

图3为本发明实施例的终端的系统架构图,如图3所示,所述终端包括:ree和tee。其中,ree由ca11、ca12、ca2、lib、clientapi以及richos组成。tee由ta1、ta2、internalapi等接口、以及trustedos组成。为了将 javavm集成在tee中,在tee侧进行如下设置:

javavm、javaapi以及javata整体作为trustedos的一个ta,例如图2中的ta1、ta2,这样,没有改变原有gp定义的tee系统架构,不影响gp的认证。参照图2,以ta1为例,ta1由javavm、javaapi、ta11、ta12组成,这里,ta11和ta12为javata。

javata调用javaapi,javavm调用internalapi为javata提供tee的服务。

将trustedos的ta的gpd.ta.multisession属性设为true,这样,ta可以同时被多个ca访问。

与此同时,在ree侧进行如下设置:建立lib库,lib库用于访问javata。

本发明实施例中,javata相当于嵌套在c语言的ta中,ca如何访问到javata是本发明实施例所要解决的问题,为了更便于理解本发明实施例的技术方案,下面对gp规范定义的ca与ta的交互流程进行描述。

如图4所示,所述ca与ta的交互流程包括以下步骤:

步骤401:ca通过clientapi调用opensession命令开始与ta交互。

这里,tee系统中通过uuid标识每一个ta,opensession指令通过标准字段(uuid)标识与ca与哪一个ta交互,trustedos会维护每一个session的上下文。

步骤402:ca与ta在session期间通过invokecommand命令交互。

步骤403:ca与ta通过closesession命令结束交互。

这里,在一个session期间,ta根据收到不同的命令实现不同的逻辑功能,通过调用internalapi向ca提供安全服务。

上述方案中,gp定义的clientapi中的opensession指令定义如下:

teec_resultteec_opensession(

teec_context*context,

teec_session*session,

constteec_uuid*destination,

uint32_tconnectionmethod,

constvoid*connectiondata,

teec_operation*operation,

uint32_t*returnorigin)

其中,destination标识ta的uuid,teec_operation的定义如下:

typedefstruct

{

uint32_tstarted;

uint32_tparamtypes;

teec_parameterparams[4];

<implementation-definedtype>imp;//可以增加实现相关自定义字段

}teec_operation;

本发明实施例利用opensession指令中的自定义字段,实现javata的调度,这样仍然符合gp规范的要求。

具体地,在gp规范中,ca与ta通过opensession指令建立连接,本发明实施例在opensession指令的参数中,指定建立连接的javata的uuid,参数的指定可通过如下表达式进行简述:opensession[uuid,imp,…(其它参数忽略)],其中,imp为自定义字段,将该自定义字段扩展为临时存储javata的uuid2字段,而原来的标准字段uuid则存储trustedos中的ta的uuid1,由于trustedos中的ta与javavm相对应,因此,也可称为在标准字段uuid中存储javavm对应的uuid1,这样,opensession指令就指定了两个uuid:opensession[uuid(uuid1),imp(uuid2),…]。

为了更便于理解本发明实施例的技术方案,下面对图3中各模块的功能再进行补充解释说明。

ca11、ca12、ca2:为客户端应用,如支付应用。

lib:在ree中重新封装clientapi,在opensession命令中将uuid指向javavm所在ta的uuid,并将javata(ta11、ta12)的uuid设置在自定义字段中,这样,trustedos可以将这条opensession指令交个javavm来处理。

clientapi:与gp规范定义保持一致,提供访问trustedos的api方法。

ta1:javavm所在的ta,javata由javavm管理及调度,将opensession指令中的uuid指定为自定义字段中缓存的javata的uuid。

ta11:javata,如支付插件,用于让用户安全输入密码及加密等。

opensession[uuid(uuid)]:表示与uuid指定的ta建立连接。

opensession[uuid(uuid1),imp(uuid2)]:表示与uuid2指定与javata建立连接,自定义字段缓存javata的uuid。

下面结合具体流程对本发明实施例的基于可信执行环境集成虚拟机的方法进行描述,ca11为支付应用,ta11为支付插件,ta1与javavm对应uuid1,ta11对应uuid11。如图5所示,所述流程包括以下步骤:

步骤501:用户打开ca11输入密码,ca11调用lib的opensession指令,指定uuid为支付插件ta11:opensession[uuid(uuid11)]。

步骤502:lib将uuid指向javavm所在ta的uuid1,并将javata的uuid11存在自定义字段中,opensession[uuid(uuid1),imp(uuid11)]。

步骤503:与gp规范一致,clientapi将opensession指令发送给tee,trustedos根据uuid1将opensession指令发送到ta1。

步骤504:javavm将opensession指令中的imp自定义字段中缓存的uuid11恢复:opensession[uuid(uuid11)],并将此指令发送给ta11,从而ca11与ta11成功建立连接。

后续的invokecommand和closesession与gp标准流程一致,ta11调用javaapi,javavm调用internalapi为ca11提供输入密码、加密等安全服务。

这里,ca11与ta11交互期间,ca12可以访问ta12,由于ta1的gpd.ta.multisession属性设为true,即javavm可以被同时被多个session访问,所以trustedos同时维护ca11与ta11和ca12与ta12的两个session,这样是符合gp规范要求的。ca2访问ta2与gp规范标准流程一致。

图6为本发明实施例另一实施例的基于可信执行环境集成虚拟机的方法的流程示意图,如图6所示,所述方法包括以下步骤:

步骤601:基于ca调用opensession指令,所述opensession指令中携有至少如下参数:虚拟机对应的uuid1、ta对应的uuid2。

这里,ca位于ree中,ree中建立了lib库,所述lib库用于调用所述opensession指令。

基于此,基于ca调用所述lib库中的opensession指令,并在所述opensession指令中将所述虚拟机对应的uuid1设置在标准字段中,将所述ta对应的uuid2设置在自定义字段中。这里,标准字段为opensession指令中的uuid字段。

然后,调用clientapi将所述opensession指令发送至所述tee。

步骤602:通过tee对所述opensession指令进行解析,得到所述虚拟机对应的uuid1,并将所述opensession指令发送至所述uuid1指向的虚拟机。

这里,tee的trustedos对所述opensession指令进行解析,得到所述虚拟机对应的uuid1,并将所述opensession指令发送至所述uuid1指向的虚拟机。

这里,虚拟机可以是javavm。

步骤603:通过所述虚拟机对所述opensession指令进行解析,得到所述ta对应的uuid2,并将所述opensession指令发送至所述uuid2指向的ta,以建立所述ca与所述ta之间的连接。

这里,虚拟机在所述opensession指令中将所述标准字段中的所述虚拟机对应的uuid1修改为所述ta对应的uuid2;将修改后的所述opensession指令发送至所述uuid2指向的ta。

本发明实施例的技术方案中,虚拟机可以对一个opensession指令进行处理,或者两个以上opensession指令同时进行处理。

图7为本发明实施例的终端的结构组成示意图,如图7所示,所述终端包括:

第一调用单元71,用于基于ca调用opensession指令,所述opensession指令中携有至少如下参数:虚拟机对应的uuid1、ta对应的uuid2;

第一处理单元72,用于通过tee对所述opensession指令进行解析,得到 所述虚拟机对应的uuid1,并将所述opensession指令发送至所述uuid1指向的虚拟机;

第二处理单元73,用于通过所述虚拟机对所述opensession指令进行解析,得到所述ta对应的uuid2,并将所述opensession指令发送至所述uuid2指向的ta,以建立所述ca与所述ta之间的连接。

所述终端还包括:设置单元74,用于在ree中建立lib库,所述lib库用于调用所述opensession指令;

所述第一调用单元71,还用于基于ca调用所述lib库中的opensession指令,并在所述opensession指令中将所述虚拟机对应的uuid1设置在标准字段中,将所述ta对应的uuid2设置在自定义字段中。

所述第一调用单元71,还用于调用clientapi将所述opensession指令发送至所述tee。

所述第二处理单元73包括:

修改子单元731,用于在所述opensession指令中将所述标准字段中的所述虚拟机对应的uuid1修改为所述ta对应的uuid2;

发送子单元732,用于将修改后的所述opensession指令发送至所述uuid2指向的ta。

所述终端还包括:第二调用单元75,用于通过所述ta调用虚拟api,以及所述虚拟机调用internalapi为所述ca提供安全服务。

所述虚拟机对一个opensession指令进行处理,或者两个以上opensession指令同时进行处理。

本领域技术人员应当理解,图7所示的终端中的各单元的实现功能可参照前述基于可信执行环境集成虚拟机的方法的相关描述而理解。图7所示的终端中的各单元的功能可通过运行于处理器上的程序而实现,也可通过具体的逻辑电路而实现。

本发明实施例所记载的技术方案之间,在不冲突的情况下,可以任意组合。

在本发明所提供的几个实施例中,应该理解到,所揭露的方法和智能设备, 可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的,作为单元显示的部件可以是、或也可以不是物理单元,即可以位于一个地方,也可以分布到多个网络单元上;可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外,在本发明各实施例中的各功能单元可以全部集成在一个第二处理单元中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。

以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1