业务处理的方法和相关装置

摘要

本申请实施例提供的业务处理的方法和相关装置，通过在终端设备运行多个可信执行环境，以用于对具有不同安全需求的业务进行处理，从而使得不同安全性的业务的执行环境可得到有效隔离，进一步保证业务访问安全。

权利要求

1.一种业务处理的方法，其特征在于，所述方法应用于终端设备，所述终端设备中运行有第一可信执行环境和第二可信执行环境；所述终端设备中还包括评估单元；

所述方法包括：

所述评估单元获取客户端应用CA发起的业务处理请求；

所述评估单元对所述业务处理请求所请求的业务进行安全性评估，得到所述业务的安全评分；

根据所述业务的安全评分，所述终端设备采用所述第一可信执行环境或采用所述第二可信执行环境对所述业务处理请求进行处理；

其中，当所述业务的安全评分大于阈值时，采用所述第一可信执行环境对所述业务处理请求进行处理；当所述业务的安全评分小于所述阈值时，采用所述第二可信执行环境对所述业务处理请求进行处理；

所述第一可信执行环境运行有第一可信应用TA，所述第二可信执行环境中运行有第二可信应用TA，所述第一可信应用TA和所述第二可信应用TA提供相同的应用功能；

所述终端设备采用所述第一可信执行环境或采用第二可信执行环境对所述业务处理请求进行处理，还包括：所述第一可信应用TA，或，所述第二可信应用TA对获取到的所述业务处理请求进行处理得到处理结果；

所述终端设备将所述处理结果返回所述客户端应用CA；

所述终端设备还包括有信任区TrustZone、虚拟机以及安全监视器Secure Monitor，所述虚拟机包括虚拟机管理器Hypervisor；

其中，所述第一可信执行环境运行在所述信任区TrustZone中；所述第二可信执行环境运行在所述虚拟机中；

所述评估单元对所述业务处理请求所请求的业务进行安全性评估，得到所述业务的安全评分，包括：所述评估单元获取所述业务处理请求所请求的业务的CA信息；

所述评估单元计算所述CA信息中每一信息项的风险系数；

所述评估单元根据各信息项的风险系数，计算所述业务的安全评分。

2.根据权利要求1所述的方法，其特征在于，当所述终端设备采用所述第一可信执行环境对所述业务处理请求进行处理时，所述方法还包括：所述终端设备通过所述安全监视器Secure Monitor，将所述业务处理请求发送至所述第一可信执行环境；

所述第一可信执行环境中的所述第一可信应用TA对所述业务处理请求进行处理，得到处理结果；

所述第一可信执行环境通过所述安全监视器Secure Monitor，将所述处理结果返回所述客户端应用CA。

3.根据权利要求1所述的方法，其特征在于，当所述终端设备采用所述第二可信执行环境对所述业务处理请求进行处理时，所述方法还包括：所述终端设备通过所述虚拟机管理器Hypervisor，将所述业务处理请求发送至所述第二可信执行环境；

所述第二可信执行环境中的所述第二可信应用TA对所述业务处理请求进行处理，得到处理结果；

所述第二可信执行环境通过所述虚拟机管理器Hypervisor，将所述处理结果返回所述客户端应用CA。

4.根据权利要求1所述的方法，其特征在于，所述终端设备还包括有虚拟机，所述虚拟机还包括虚拟机管理器Hypervisor；其中，所述第一可信执行环境和所述第二可信执行环境均运行在所述虚拟机中。

5.根据权利要求4所述的方法，其特征在于，当所述终端设备采用所述第一可信执行环境对所述业务处理请求进行处理时，所述方法还包括：所述终端设备通过所述虚拟机管理器Hypervisor，将所述业务处理请求发送至所述第一可信执行环境；

所述第一可信执行环境中的所述第一可信应用TA对所述业务处理请求进行处理，得到处理结果；

所述第一可信执行环境通过所述虚拟机管理器Hypervisor，将所述处理结果返回所述客户端应用CA。

6.根据权利要求4所述的方法，其特征在于，当所述终端设备采用所述第二可信执行环境对所述业务处理请求进行处理时，所述方法还包括：所述终端设备通过所述虚拟机管理器Hypervisor，将所述业务处理请求发送至所述第二可信执行环境；

所述第二可信执行环境中的所述第二可信应用TA对所述业务处理请求进行处理，得到处理结果；

所述第二可信执行环境通过所述虚拟机管理器Hypervisor，将所述处理结果返回所述客户端应用CA。

7.根据权利要求1‑6任一项所述的方法，其特征在于，所述终端设备还包括操作系统内核驱动；

所述终端设备根据所述业务的安全评分，采用所述第一可信执行环境或采用第二可信执行环境对所述业务处理请求进行处理，包括：所述评估单元根据所述业务的安全评分，将所述第一可信执行环境的环境标识或所述第二可信执行环境的环境标识发送至所述操作系统内核驱动；

所述操作系统内核驱动根据接收到的环境标识，将所述业务处理请求发送至与所述环境标识相应的所述第一可信执行环境或所述第二可信执行环境。

8.根据权利要求1所述的方法，其特征在于，所述CA信息包括以下信息项中的至少一种：签名类型，业务类型，CA来源信息，可信应用规格信息，异常表现信息，设备状态信息。

9.一种终端设备，其特征在于，所述终端设备包括处理器，所述处理器用于调用存储器中的计算机程序，以执行如权利要求1‑8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在终端设备上运行时，使得所述终端设备执行如权利要求1‑8中任一项所述的方法。

11.一种芯片，其特征在于，所述芯片包括处理器，所述处理器用于调用存储器中的计算机程序，以执行如权利要求1‑8中任一项所述的方法。

说明书

业务处理的方法和相关装置

技术领域

[0001] 本申请涉及安全技术领域，尤其涉及业务处理的方法和相关装置。

背景技术

[0002] 随着移动技术的发展，终端设备可以支持对不同类型业务的处理。在终端设备处理这些业务时容易因系统漏洞而遭受攻击，这将使得业务安全性得不到保障。

[0003] 随着可信执行环境(也称TEE)技术的发展，在终端设备中构建可信执行环境以对业务进行处理成为解决业务运行安全隐患的一种实现方式。在现有技术中，可信执行环境将为终端设备的富执行环境(也称REE)所发起的各类业务应用提供访问接口并开放部分访问权限，来完成对业务的处理。

发明内容

[0004] 本申请是实施例提供了业务处理的方法和相关装置，以提升业务的安全性。

[0005] 第一方面，本申请实施例提出一种业务处理的方法，该方法应用于终端设备，终端设备中运行有第一可信执行环境和第二可信执行环境；终端设备中还包括评估单元；

[0006] 该方法包括：

[0007] 评估单元获取客户端应用CA发起的业务处理请求；该评估单元对业务处理请求所请求的业务进行安全性评估，得到业务的安全评分；根据业务的安全评分，终端设备采用第一可信执行环境或采用第二可信执行环境对业务处理请求进行处理；其中，当业务的安全评分大于阈值时，采用第一可信执行环境对该业务处理请求进行处理；当业务的安全评分小于阈值时，采用第二可信执行环境对该业务处理请求进行处理。

[0008] 这样，通过在终端设备运行多个可信执行环境，以用于对具有不同安全评分的业务进行分别处理，实现将具有不同安全需求的业务的执行环境有效隔离的效果，保证业务访问安全。

[0009] 可选的，第一可信执行环境运行有第一可信应用TA，第二可信执行环境中运行有第二可信应用TA，第一可信应用TA和第二可信应用TA提供相同的应用功能；在终端设备采用第一可信执行环境或采用第二可信执行环境对业务处理请求进行处理时，第一可信应用TA，或，第二可信应用TA对获取到的业务处理请求进行处理得到处理结果；终端设备将该处理结果返回客户端应用CA。

[0010] 这样，客户端应用CA可获得业务处理请求的处理结果，且客户端应用CA对于可信执行环境的选择过程无感知。

[0011] 可选的，终端设备还包括有信任区TrustZone、虚拟机以及安全监视器Secure Monitor，该虚拟机包括虚拟机管理器Hypervisor；其中，第一可信执行环境运行在信任区TrustZone中；第二可信执行环境运行在虚拟机中。

[0012] 可选的，当终端设备采用第一可信执行环境对业务处理请求进行处理时，终端设备通过安全监视器Secure Monitor，将该业务处理请求发送至第一可信执行环境；第一可信执行环境中的第一可信应用TA对该业务处理请求进行处理，得到处理结果；第一可信执行环境通过安全监视器Secure Monitor，将该处理结果返回客户端应用CA。

[0013] 可选的，当终端设备采用第二可信执行环境对该业务处理请求进行处理时，终端设备通过虚拟机管理器Hypervisor，将业务处理请求发送至第二可信执行环境；第二可信执行环境中的第二可信应用TA对业务处理请求进行处理，得到处理结果；第二可信执行环境通过虚拟机管理器Hypervisor，将该处理结果返回客户端应用CA。

[0014] 这样，由于终端设备中包括信任区TrustZone和虚拟机，通过在信任区TrustZone中运行第一可信执行环境，在虚拟机中运行第二可信执行环境的方式，使多个可信执行环境之间形成主机级别的硬件隔离，实现不同安全性业务在执行时的相对隔离，进一步提升业务处理安全性。

[0015] 可选的，终端设备还包括有虚拟机，虚拟机还包括虚拟机管理器Hypervisor；其中，第一可信执行环境和第二可信执行环境均运行在虚拟机中。

[0016] 可选的，当终端设备采用第一可信执行环境对业务处理请求进行处理时，终端设备通过虚拟机管理器Hypervisor，将业务处理请求发送至第一可信执行环境；第一可信执行环境中的第一可信应用TA对业务处理请求进行处理，得到处理结果；第一可信执行环境通过虚拟机管理器Hypervisor，将处理结果返回客户端应用CA。

[0017] 可选的，当终端设备采用第二可信执行环境对业务处理请求进行处理时，终端设备通过虚拟机管理器Hypervisor，将业务处理请求发送至第二可信执行环境；第二可信执行环境中的所第二可信应用TA对业务处理请求进行处理，得到处理结果；第二可信执行环境通过虚拟机管理器Hypervisor，将处理结果返回客户端应用CA。

[0018] 这样，由于终端设备中包括虚拟机，通过利用虚拟化技术使得第一可信执行环境和第二可信执行环境在虚拟机中形成容器级别的资源隔离，实现不同安全性业务在执行时的相对隔离，进一步提升业务处理安全性。

[0019] 可选的，终端设备还包括操作系统内核驱动；在终端设备根据业务的安全评分，采用第一可信执行环境或采用第二可信执行环境对业务处理请求进行处理时，评估单元根据业务的安全评分，将第一可信执行环境的环境标识或第二可信执行环境的环境标识发送至操作系统内核驱动；该操作系统内核驱动根据接收到的环境标识，将该业务处理请求发送至与所述环境标识相应的所述第一可信执行环境或所述第二可信执行环境。

[0020] 这样，操作系统内核驱动可在接收到可信执行环境的环境标识之后，直接将该业务处理请求发送至相应的可信执行环境中，实现对业务处理请求的分发处理。

[0021] 可选的，在评估单元对业务处理请求所请求的业务进行安全性评估，得到业务的安全评分过程中，该评估单元获取业务处理请求所请求的业务的CA信息，根据所述CA信息对该业务进行安全性评估，得到该业务的安全评分。

[0022] 可选的，该CA信息包括以下信息项中的至少一种：签名类型，业务类型，CA来源信息，可信应用规格信息，异常表现信息，设备状态信息。

[0023] 可选的，在评估单元根据CA信息对该业务进行安全性评估，得到业务的安全评分的过程中，评估单元计算CA信息中每一信息项的风险系数，根据各信息项的风险系数计算该业务的安全评分。

[0024] 这样，利用终端设备增设的评估单元可对业务在多个信息项下的风险系数进行计算，以实现对业务的安全评分的确定，便于后续对业务处理请求进行分发和处理。

[0025] 第二方面，本申请实施例提供了一种终端设备，终端设备也可以称为终端(terminal)、用户设备(user equipment，UE)、移动台(mobile station，MS)、移动终端(mobile terminal，MT)等。终端设备可以是手机(mobile phone)、智能电视、穿戴式设备、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality， AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(self‑driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等等。

[0026] 该终端设备包括处理器，处理器用于调用存储器中的计算机程序以执行如第一方面所述的方法。

[0027] 第三方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，当计算机指令在终端设备上运行时，使得终端设备执行如第一方面所述的方法。

[0028] 第四方面，本申请实施例提供了一种芯片，芯片包括处理器，处理器用于调用存储器中的计算机程序，以执行如如第一方面所述的方法。

[0029] 应当理解的是，本申请的第二方面至第四方面与本申请的第一方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

附图说明

[0030] 图1为一种终端设备的框架示意图；

[0031] 图2为终端设备的第一交互流程示意图；

[0032] 图3为现有技术中的的另一种终端设备的框架示意图；

[0033] 图4为现有技术中终端设备的第二交互流程示意图；

[0034] 图5A为本申请实施例适用的终端设备的一种结构示意图；

[0035] 图5B为本申请实施例适用的终端设备的一种软件结构框图；

[0036] 图5C为本申请实施例适用的终端设备的另一种软件结构框图；

[0037] 图5D为本申请实施例适用的终端设备的又一软件结构框图；

[0038] 图6A为本申请实施例提供一种的业务处理的方法的流程示意图；

[0039] 图6B为本申请提供的一种应用场景示意图；

[0040] 图7为本申请提供的一种终端设备的框架示意图；

[0041] 图8为本申请提供的一种终端设备中的第三交互流程示意图；

[0042] 图9为本申请提供的一种终端设备中的第四交互流程示意图；

[0043] 图10为本申请提供的另一种终端设备的框架示意图；

[0044] 图11为本申请提供的一种终端设备中的第五交互流程示意图；

[0045] 图12为本申请提供的一种终端设备中的第六交互流程示意图；

[0046] 图13为本申请实施例提供的一种业务处理的装置的硬件结构示意图。

具体实施方式

[0047] 为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一芯片和第二芯片仅仅是为了区分不同的芯片，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

[0048] 需要说明的是，本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

[0049] 本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/ 或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a‑b，a‑c，b‑c，或a‑b‑c，其中a，b，c可以是单个，也可以是多个。

[0050] 本申请实施例提供的业务处理的方法，可以应用在设置有可信执行环境的终端设备中。终端设备也可以称为终端(terminal)、用户设备(user equipment，UE)、移动台(mobile station， MS)、移动终端(mobile terminal，MT)等。终端设备可以是手机(mobile phone)、智能电视、穿戴式设备、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR) 终端设备、增强现实(augmented reality，AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(self‑driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等等。本申请的实施例对终端设备所采用的具体技术和具体设备形态不做限定。

[0051] 为了能够更好地理解本申请实施例，下面对本申请实施例涉及的技术框架进行介绍：

[0052] 信任区(Trust Zone)技术是基于处理器架构实现的一种安全扩展技术，其可为客户端应用提供真实的硬件支持的安全环境。图1为一种终端设备的框架示意图，图2为终端设备的第一交互流程示意图。结合图1和图2可知，该框架中包括相对独立的运行环境：TEE可信执行环境以及REE富执行环境。

[0053] 其中，REE为终端设备中的富执行环境，在REE中可以运行客户端应用11(client application，CA)和富执行环境操作系统12(Rich Execution Environment operating system，REE OS)。CA11中包括可以为用户提供可信应用的应用。

[0054] ARM(Advanced RISC Machines)将TrustZone技术与Coretex‑A处理器集成，提供了能够支持完全可信执行环境TEE以及安全感知应用程序和安全服务的平台，即将TEE作为为电子设备中的可信执行环境，为REE侧提供可信应用。TEE建立在信任区(TrustZone)中。在该信任区的独立环境中运行有可信应用21(trust application，TA)以及可信执行环境操作系统 22(trusted execution environment operating system，TEE OS)，可以确保TEE中加载的代码和数据的机密性和完整性都得到保护。

[0055] TEE OS通过调用可信执行环境内部应用编程接口与REE OS进行通信，提供可信应用支持。

[0056] 当需要调用可信应用时，REE OS11通过客户端应用编程接口(application programming interface，API)与可信执行环境操作系统TEE OS 12通信，请求可信应用支持。REE OS11中包括内核驱动，用于支持系统与硬件设备之间完成数据传送，以及支持REE与TEE之间可信应用的交互工作。

[0057] 此外，该框架中还包括有ARM可信固件31(arm trusted firmware，ATF)，其中设置有Secure Monitor(安全监视器)。另外一方面，ARM也推出了Virtualization Extension技术(虚拟化扩展技术)用于支持ARM平台的硬件虚拟机化，从而在正常运行环境也能实现为不同的运行环境提供硬件的隔离。此外，ARMv8开始支持四种EL(异常级别，Exception Level)，分别为从EL0到EL3，并且异常级别后面的数字越大，则，安全等级越高。一般来说，应用程序运行在EL0层，系统内核(在一些实施例中称为操作系统)运行在EL1层，hypevisor(虚拟机管理器)运行在EL2层，Secure Monitor(安全监视器)运行在EL3层。这些技术的发展使得基于虚拟机的TEE环境得以实现，从而实现更为复杂的安全场景。

[0058] 例如，在上述框架示意图中，其中可信应用21以及客户端应用11位于框架中的EL0层，可信执行环境操作系统22以及富执行环境操作系统12位于框架中的EL1层，ARM可信固件31位于框架中的EL3层。

[0059] 在图1所示的结构的基础上，图2中通过箭头以及标号①至标号⑧表明了客户端应用CA 调用可信应用TA的具体流程。

[0060] ①REE中的客户端应用CA11需要调用TEE中的可信应用TA21时，客户端应用CA11 通过调用REE中的API接口(图未示出)向REE OS12发出请求。

[0061] ②REE OS12中的内核驱动通过调用SMC(Secure Monitor Call)指令将CA的请求发送至ATF31。

[0062] ③ATF31对SMC指令进行解析，并将解析后的请求发送至信任区TEE中的TEE OS22。

[0063] ④TEE OS22对CA的请求进行分发，以将CA的请求发送至对应的TA21。

[0064] ⑤TA21对接收到的请求进行处理之后，通过调用可信执行环境TEE的接口(图未示出) 将处理结果发送至TEE OS22。

[0065] ⑥TEE OS22通过调用SMC指令，将处理结果返回至ATF31。

[0066] ⑦ATF31对SMC指令进行解析，并将解析后得到的处理结果返回至REE OS12。

[0067] ⑧REE OS12将处理结果返回给CA11。

[0068] 通过上述的标号①至标号⑧的各步骤，REE中的客户端应用CA11完成了对TEE中的可信应用TA21的调用，并获得了处理结果。

[0069] 与图1所示框架不同的是，虚拟化技术是一种在同一终端设备上同时运行多种操作系统的技术，而利用虚拟化技术，也可实现可信执行环境的构建。图3为现有技术中的的另一种终端设备的框架示意图。在该框架示意图中，包括有REE环境和VM TEE环境。

[0070] 其中，该VM TEE环境为基于虚拟机(即ARM框架中的EL2层)实现的可信执行环境。 VM TEE为终端设备中的基于虚拟机实现的可信执行环境，其结构与前述的TEE类似，其同样可以为REE侧提供可信应用。REE依旧为终端设备中的普通执行环境。在REE中可以运行客户端应用11(client application，CA)和富执行环境操作系统12(Rich Execution Environment operating system，REE OS)。CA11中包括可以为用户提供可信应用的应用。

[0071] 与前述图1和图2所示的建立在信任区(TrustZone)中TEE不同的是，VM TEE和REE 是构建在同一个虚拟机上的，其通过虚拟机管理器43(hypervisor)实现交互。

[0072] 图4为现有技术中终端设备的第二交互流程示意图。在图3所示的框架的基础上，图4 中通过箭头以及标号①至标号⑧表明了客户端应用CA11调用可信应用TA41的具体流程。

[0073] ①客户端应用CA11需要调用可信应用TA41时，客户端应用CA11通过调用REE中的 API接口(图未示出)向REE OS12发出请求。

[0074] ②REE OS12中的内核驱动后通过调用HVC(hypervisor call)指令将CA请求发送至虚拟机管理器43hypervisor。

[0075] ③虚拟机管理器43hypervisor对基于HVC指令的CA请求进行处理，以将请求发送至 VM TEE OS42。

[0076] ④VM TEE OS42对CA请求进行分发，以将CA请求发送至对应的TA41。

[0077] ⑤在TA41对接收到的请求进行处理之后，通过调用可信执行环境VM TEE的接口(图未示出)将处理结果发送至VM TEE OS42。

[0078] ⑥VM TEE OS42通过调用HVC指令，将处理结果返回至hypervisor43。

[0079] ⑦hypervisor43对HVC指令进行解析，并将解析后得到的处理结果返回至REE OS12。

[0080] ⑧REE OS12将处理结果返回给CA11。

[0081] 一些示例中，终端设备中还包括硬件平台，用于支撑终端设备运行，硬件平台中包括了一些安全硬件。例如，安全硬件可以包括：安全内存、安全键盘、摄像头等实体硬件。

[0082] 基于上述两种可能的可信执行环境的框架和技术，终端设备REE的客户端应用CA可完成对于可信执行环境TEE或VM TEE中可信应用TA的访问，得到处理结果。

[0083] 尽管上述两种方式提供的框架能够构建可信执行环境，并通过利用富执行环境中的CA 访问可信执行环境中的TA的方式实现业务处理，能够在一定程度上提升业务运行安全，但安全性还存在不确定性，具体如下所述。

[0084] 示例性的，对于调用面部识别这一可信应用TA来说，其可运用在多个CA发起的业务请求中，如：

[0085] 当某一CA的访问请求来自于支付类软件，那么该CA将调用TA，以利用TA对用户进行面部识别处理，并将“识别通过”或“识别未通过”的识别结果返回CA，以供CA根据识别结果执行支付流程。又如，当另一CA的访问请求来自于视频软件，那么该CA将调用同一TA，以利用该同一TA对用户进行面部识别处理，并将“识别通过”或“识别未通过”的识别结果返回 CA，以供CA根据识别结果执行视频软件的账号登陆流程。

[0086] 由于上述框架中均运行唯一的可信执行环境，且该唯一可信执行环境需要将对于来自不同业务的CA访问请求进行处理。这会导致如下情况的发生：当REE的视频软件的CA在发出访问后，遭到了攻击，此时，执行访问的TA所在的可信执行环境的可信度和安全性将相应降低。当该TA后续响应支付类CA所发出的访问时，其环境安全性将存在不确定性。

[0087] 基于此，本申请的一些实施例考虑到来自于支付类软件的CA对于TA运行环境的安全性要求，要高于来自于视频软件的CA对于TA运行环境的安全性要求这一特性，通过在终端设备上构建多个可信执行环境，并为不同可信执行环境赋予不同安全性(安全级别)，以使得终端设备的CA在对TA发起访问时，可基于CA所发起的业务的安全性来选择与该安全性相应的可信执行环境以对业务进行处理。

[0088] 这样具有高安全性需求的业务的执行环境，与具有低安全性需求的业务的执行环境相对隔离，有利于保障业务访问安全，特别是高安全性业务的访问安全。

[0089] 下面将对本申请实施例所涉及的结构和框架进行介绍。

[0090] 首先，将针对本申请实施例的终端设备的结构进行介绍：图5A为本申请实施例适用的终端设备的一种结构示意图。

[0091] 如图5A所示，该终端设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM) 卡接口195等。可以理解的是，本实施例示意的结构并不构成对终端设备100的具体限定。在本申请另一些实施例中，终端设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件，或软件和硬件的组合实现。

[0092] 处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器 (application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，显示处理单元(display process unit，DPU)，和/或神经网络处理器(neural‑network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。在一些实施例中，终端设备100也可以包括一个或多个处理器110。其中，处理器可以是终端设备100的神经中枢和指挥中心。处理器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。处理器110 中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110用过或循环使用的指令或数据。如果处理器110 需要再次使用该指令或数据，可从所述存储器中直接调用。这就避免了重复存取，减少了处理器110的等待时间，因而提高了终端设备100的效率。

[0093] 在本申请的一些实施例中，处理器110的运行环境可以包括：REE以及至少两个可信执行环境(一个TEE和至少一个VM TEE，或者，至少两个VM TEE)。

[0094] 其中，TEE中运行有可信应用程序以及TEE OS，VM TEE中运行有可信应用程序以及 VM TEE OS，REE中运行有客户端应用以及REE OS。REE用于接收用户通过客户端应用发起的可信应用请求，并根据该可信应用请求调用TEE或者HTEE中的可信应用TA，并由TA 返回相应的结果。

[0095] 示例性的，图5B为本申请实施例适用的终端设备的一种软件结构框图。该图5B示出了富执行环境REE中的一种软件分层架构。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

[0096] 示例性的，图5C为本申请实施例适用的终端设备的另一种软件结构框图。该图5C示出了可信执行环境TEE的一种软件分层架构。在TEE的分层架构中一般包括有至少一种可信应用，如图5C所示的，指纹识别应用TA、面部识别引用TA以及支付应用TA等。这些可信应用TA可过TEE内部的接口API与可信执行环境操作系统TEE OS进行交互。而在可信执行环境操作系统TEE OS中还将包括TEE通信代理，可信内核框架以及可信驱动等多个程序等。这些程序将相互配合，以支撑可信执行应用TA的运行。

[0097] 示例性的，图5D为本申请实施例适用的终端设备的又一软件结构框图，其示出了Android 上的指纹软件框架，在该示例中，REE环境下主要分为APP，Framework，HAL和linux kernel。 APP主要负责指纹录入解锁调用逻辑，Framework主要负责回调HAL层相关函数，HAl层负责和硬件以及指纹TA交互。而TEE主要是指纹TA，指纹TA负责控制指纹sensor和执行指纹算法相关函数。

[0098] 为了实现对本申请中的业务请求进行处理，基于前述的构思，本申请的终端设备的框架中将布设有多个可信执行环境。

[0099] 下面将以可信执行环境的数量为两个为例对本申请提供的业务处理的方法进行说明。当然，下面的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

[0100] 基于前述构思，图6A为本申请实施例提供一种的业务处理的方法的流程示意图。如图 6A所示，本申请中的业务处理的方法可以包括：

[0101] S601、评估单元获取客户端应用CA发起的业务处理请求。

[0102] 具体的，该业务处理请求可为终端设备响应用户触发的预设操作后生成的。其中，预设操作可以包括触控操作指令或者语音操作指令或者体感操作指令等用于控制客户端应用CA 进入业务处理流程的操作。一般的，触发不同类型的客户端应用CA发起的业务处理请求的预设操作是不同的。

[0103] S602、评估单元对业务处理请求所请求的业务进行安全性评估，得到业务的安全评分。

[0104] 具体的，评估单元在获取到业务处理请求之后，将会按照既定评估方式对业务进行安全性评估，以计算出业务的安全评分，其中，业务的安全评分可用于反映业务的运行风险。

[0105] 可选实现方式中，安全性评估可基于CA信息实现。具体的，评估单元可获取业务处理请求所请求的业务的CA信息；然后，评估单元再根据CA信息对业务处理请求所请求的业务进行安全性评估，得到业务的安全评分。

[0106] 示例性的，CA信息包括的信息项为如下的至少一种：签名类型，业务类型，CA来源信息，可信应用规格信息，异常表现信息，设备状态信息。

[0107] 其中，签名类型用于反映触发该业务处理请求的发起来源，其包括但不限于：操作系统、平台、三方；

[0108] 业务类型，用于反映发起该业务处理请求的客户端应用CA的应用类型，其包括但不限于：支付类、身份认证类、多媒体类；

[0109] CA来源，用于反映业务来源，其包括但不限于：可信实体以及其他；

[0110] TA规格，用于反映运行业务所需要系统权限级别，其包括但不限于：高、中、低；

[0111] 异常表现，用于反映业务在历史运行时对异常行为的表现，其包括但不限于：优、良和不及格；

[0112] 设备状态信息，用于反映评估单元在获取业务处理请求时的终端设备的设备状态，其包括但不限于：正常、异常和丢失。

[0113] 可选实现方式中，评估单元可先计算CA信息中每一信息项的风险系数；然后根据各信息项的风险系数，计算所述业务的安全评分。

[0114] 对于风险系数，可理解为当业务收到攻击时的危害程度。以业务类型这一信息项来说，支付类业务发生被攻击产生的危害程度将大于身份认证类业务发生被攻击所产生的危害程度，身份认证类业务发生被攻击所产生危害程度大于视频类业务发生被攻击产生的危害程度。

[0115] 假设风险系数范围为1‑3，其中风险系数为1时，风险最低，风险系数为3时，风险最高。那么，当业务类型这一信息项反映为支付类业务时，其风险系数认定为3；当业务类型这一信息项反映为身份认证类业务时，其风险系数认定为2；当业务类型这一信息项反映为视频类业务时，其风险系数认定为1。

[0116] 利用上述可选方式，评估单元可对业务处理请求所请求的业务进行安全性评估，计算出该业务在每一信息项上的风险系数。

[0117] 再后，评估单元还会将各风险系数进行一定整合，以计算出该业务的整体风险情况，即得到安全评分。

[0118] 示例性的，在计算安全评分时，可将各风险系数进行加权处理，以将加权处理结果作为业务的安全评分。.

[0119] 示例性的，在计算安全评分时，还可运用预设的风险评估模型，以对各风险系数进行模型运算处理，以将模型运算处理结果作为业务的安全评分。

[0120] S603、根据业务的安全评分，终端设备采用第一可信执行环境或采用第二可信执行环境对业务处理请求进行处理；

[0121] 其中，当业务的安全评分大于阈值时，采用第一可信执行环境对业务处理请求进行处理；当业务的安全评分小于阈值时，采用第二可信执行环境对业务处理请求进行处理。

[0122] 此外，当业务的安全评分等于阈值时，可根据实际需求采用第一可信执行环境或第二可信执行环境对业务处理请求进行处理。

[0123] 可知的是，上述的阈值可为预设固定值，也可为经验值，本申请不对该阈值的范围进行限定。

[0124] 基于前述提及的安全评分的计算原理可知的是，当该业务的安全评分较高时，其在被攻击时产生危害程度较大，反之；当该业务的安全评分较低时，其业务在被攻击时所产生的危害程度较小。

[0125] 利用阈值与业务的安全评分之间的比对结果，可将业务处理请求分发至不同的可信执行环境中运行，从而使得安全评分均大于阈值的业务的业务处理请求均集中在第一可信执行环境中运行，而安全评分小于等于阈值的业务的业务处理请求均集中在第二可信执行环境中运行，进而将不同安全性的业务请求的执行环境进行环境隔离，有利于保障业务访问安全。

[0126] 图6B为本申请提供的一种应用场景示意图，如图6B所示的，在该场景中，可信执行环境将用于支持基于人脸识别的各类应用。其中，REE中的应用在发起人脸认证请求之后，REE 将调用人脸识别服务请求可信执行环境对请求进行处理。在可信执行环境中，人脸识别TA 进行包括人脸图像采集、特征提取、活体检测、特征比对等多个处理过程，并得到处理结果返回给应用以进行使用。

[0127] 在上述基于信任区Trust Zone技术和虚拟化技术的可信执行环境构建原理的基础上，下面将结合终端设备的框架对本申请提供的业务处理的方法进行进一步说明：

[0128] 在其中一种框架结构中，通过将信任区Trust Zone技术和虚拟化技术进行结合，可实现在终端设备中布设多个可信执行环境的布设需求。

[0129] 图7为本申请提供的一种终端设备的框架示意图，如图7所示的，该框架中同时运用了信任区Trust Zone技术和虚拟化技术以分别构建多个可信执行环境。

[0130] 其中，该框架中包括相对独立的运行环境：第一可信执行环境TEE、第二可信执行环境 VM TEE以及富执行环境REE。

[0131] 在本框架中，考虑到基于信任区技术构建可信执行环境的环境安全性，相对于基于虚拟化技术构建可信执行环境的环境安全性更高。因此，将信任区Trust Zone中运行的可信执行环境作为执行高风险业务的第一可信执行环境TEE；将虚拟机中运行的可信执行环境作为执行低风险业务的第二可信执行环境VM TEE。

[0132] 在第一可信执行环境TEE中运行有第一可信应用TA，在第二可信执行环境VM TEE中运行有第二可信应用TA。该第一可信应用TA和第二可信应用TA可执行相同的可信应用功能，如第一可信应用TA和第二可信应用TA均可调用拍摄组件以实现面部识别功能。

[0133] 此外，为了使得各执行环境可进行通信，EL2层的虚拟机包括虚拟机管理器Hypervisor， EL3层设置有安全监视器Secure Monitor，评估单元将设置在终端设备REE中的EL0层。

[0134] 图8为本申请提供的一种终端设备中的第三交互流程示意图，图8以业务处理请求为支付请求为例，示出了当业务的安全评分大于阈值时的业务处理流程，其中的标号①至标号⑨示出了支付请求在终端设备的处理流程。

[0135] 如图8所示的，REE中的支付类应用CA51响应用户触发的支付操作，生成了支付请求。

[0136] ①支付类应用CA51将该支付请求发送给评估单元52，评估单元52会对支付请求所请求的支付业务进行安全性评估。

[0137] ②评估单元52计算出该支付业务的安全评分之后，由于该安全评分大于阈值该支付请求应被发送至第一可信执行环境TEE中进行处理。此时，评估单元将调用REE中的API接口 53，并将该支付请求和第一可信执行环境的环境标识一并发送给富执行环境的操作系统内核驱动REE OS54。

[0138] ③由于第一可信执行环境是基于信任区Trust Zone实现的，REE OS54中的操作系统内核驱动在接收到第一可信执行环境的环境标识之后，需要调用SMC(Secure Monitor Call)指令对支付请求进行编译，并将编译后的SMC指令发送至位于EL3层的安全监视器Secure Monitor91。

[0139] ④安全监视器Secure Monitor91对SMC指令进行解析，并将解析后的支付请求发送至第一可信执行环境的操作系统TEE OS73。

[0140] ⑤第一可信执行环境的操作系统TEE OS73对支付请求进行分发，并将支付请求发送至面部识别的可信应用TA71。

[0141] ⑥面部识别的可信应用TA71基于支付请求启动并对用户面部图像进行采集、比对和分析，得到处理结果，并通过调用第一可信执行环境TEE的接口72将“面部识别通过”或“面部识别不通过”的处理结果返回至第一可信执行环境的操作系统TEE OS73。

[0142] ⑦第一可信执行环境的操作系统TEE OS73通过调用SMC指令，将处理结果返回至安全监视器Secure Monitor91。

[0143] ⑧安全监视器Secure Monitor91对SMC指令进行解析，并将解析后得到的处理结果返回给REE OS54。

[0144] ⑨REE OS54将“面部识别通过”或“面部识别不通过”的处理结果返回给支付类应用 CA51。

[0145] 可知的是，在标号⑨之后，还应包括有支付类应用CA51根据处理结果执行支付处理或拒绝支持处理等进程，本实施例对后续步骤不再做赘述。

[0146] 图9为本申请提供的一种终端设备中的第四交互流程示意图，图9以业务处理请求为账号登陆请求为例，示出了当业务的安全评分小于等于阈值时的业务处理流程，其中的标号①至标号⑨示出了账号登陆请求在终端设备终端处理流程。

[0147] 如图9所示的，REE中的视频类应用CA55响应用户触发的账号登陆操作，生成了账号登陆请求。

[0148] ①视频类应用CA55将该账号登陆请求发送给评估单元52，评估单元52会对账号登陆请求所对应的视频业务进行安全性评估。

[0149] ②评估单元52计算出该视频业务的安全评分之后，由于该安全评分小于阈值该账号登陆请求应被发送至第二可信执行环境VM TEE中进行处理。此时，评估业务将调用REE中的 API接口53并将该账号登陆请求和第二可信执行环境的环境标识一并发送给富执行环境的操作系统内核驱动REE OS54。

[0150] ③由于第二可信执行环境是基于虚拟机实现的，REE OS54中的操作系统内核驱动在接收到第二可信执行环境的环境标识之后，需要调用HVC(hypervisor call)指令对账号登陆请求进行编译，并将编译后的HVC指令发送至位于EL2层虚拟机管理器hypervisor81。

[0151] ④虚拟机管理器hypervisor81对基于HVC进行解析，并将解析得到的账号登陆请求发送至第二可信执行环境的操作系统VM TEE OS63。

[0152] ⑤第二可信执行环境的操作系统VM TEE OS63对账号登陆请求进行分发，以将账号登陆请求发送至第二可信执行环境中的面部识别的第二可信应用TA61。

[0153] ⑥面部识别的可信应用TA61基于账号登陆请求启动并对用户面部图像进行采集、比对和分析，得到处理结果，并通过调用第二可信执行环境TEE的接口62将“面部识别通过”或“面部识别不通过”的处理结果返回至第二可信执行环境的操作系统VM TEE OS63。

[0154] ⑦第二可信执行环境的操作系统VM TEE OS63通过调用HVC指令，将处理结果返回至 hypervisor81。

[0155] ⑧hypervisor81对HVC指令进行解析，并将解析后得到的处理结果返回至REE OS54。

[0156] ⑨REE OS54将“面部识别通过”或“面部识别不通过”的处理结果返回给视频类应用 CA55。

[0157] 可知的是，在标号⑨之后，还应包括有视频类应用CA根据处理结果执行账号登陆处理进程，本实施例对后续步骤不再做赘述。

[0158] 而在另一框架结构中，终端设备将利用虚拟化技术实现多个可信执行环境。

[0159] 图10为本申请提供的另一种终端设备的框架示意图，如图10所示的，该框架中运用了利用虚拟化技术构建可信执行环境。其中，该框架中包括相对独立的运行环境：第一可信执行环境VM TEE 1、第二可信执行环境VM TEE 2以及富执行环境REE。

[0160] 具体的，终端设备还包括有虚拟机，虚拟机还包括设置在EL2层的虚拟机管理器 Hypervisor；而第一可信执行环境VM TEE 1和所述第二可信执行环境VM TEE 2均运行在虚拟机中。

[0161] 与前述架构类似的，终端设备REE中的EL0层同样设置有评估单元，该评估单元可在获取客户端应用CA发起的业务处理请求之后，结合前述提及的方案确定其相应的可信执行环境。

[0162] 图11为本申请提供的一种终端设备中的第五交互流程示意图，图11以业务处理请求为支付请求为例，示出了当业务的安全评分大于阈值时的业务处理流程，其中的标号①至标号⑨示出了支付请求在终端设备的处理流程。

[0163] 如图11所示的，REE中的支付类应用CA响应用户触发的支付操作，生成了支付请求。

[0164] ①支付类应用CA51将该支付请求发送给评估单元52，评估单元52会对本次的支付业务进行安全性评估。

[0165] ②评估单元52计算出该支付业务的安全评分之后，由于该安全评分大于阈值该支付请求应被发送至第一可信执行环境TEE中进行处理。此时，评估单元52将调用REE中的API接口53，并将该支付请求和第一可信执行环境的环境标识一并发送给富执行环境的操作系统内核驱动REE OS54。

[0166] ③由于第一可信执行环境VM TEE 1是基于虚拟机实现的，REE OS64中的操作系统内核驱动在接收到第一可信执行环境的环境标识之后，需要调用HVC(hypervisor call)指令对支付请求进行编译，并将编译后的HVC指令发送至位于EL2层虚拟机管理器hypervisor81。

[0167] ④虚拟机管理器hypervisor81对基于HVC进行解析，并将解析得到的账号登陆请求发送至第一可信执行环境的操作系统VM TEE 1OS631。

[0168] ⑤第一可信执行环境的操作系统VM TEE 1OS631对支付请求进行分发，并将支付请求发送至VM TEE 1中的面部识别的第一可信应用TA611。

[0169] ⑥面部识别的第一可信应用TA611基于支付请求启动并对用户面部图像进行采集、比对和分析，得到处理结果，并通过调用第一可信执行环境VM TEE 1的接口621将“面部识别通过”或“面部识别不通过”的处理结果返回至第一可信执行环境的操作系统VM TEE 1OS631。

[0170] ⑦第一可信执行环境的操作系统VM TEE 1OS631通过调用HVC指令，将处理结果返回至hypervisor81。

[0171] ⑧hypervisor81对HVC指令进行解析，并将解析后得到的处理结果返回给REE OS54。

[0172] ⑨REE OS54将“面部识别通过”或“面部识别不通过”的处理结果返回给支付类应用 CA51。

[0173] 可知的是，在标号⑨之后，还应包括有支付类应用CA根据处理结果执行支付处理或拒绝支持处理等进程，本实施例对后续步骤不再做赘述。

[0174] 图12为本申请提供的一种终端设备中的第六交互流程示意图，图12以业务处理请求为账号登陆请求为例，示出了当业务的安全评分小于等于阈值时的业务处理流程，其中的标号①至标号⑨示出了账号登陆请求在终端设备的处理流程。

[0175] 如图12所示的，REE中的视频类应用CA响应用户触发的账号登陆操作，生成了账号登陆请求。

[0176] ①视频类应用CA55将该账号登陆请求发送给评估单元52，评估单元52会对账号登陆请求所对应的视频业务进行安全性评估。

[0177] ②评估单元52计算出该视频业务的安全评分之后，由于该安全评分小于阈值该账号登陆请求应被发送至第二可信执行环境VM TEE 2中进行处理。此时，评估业务将调用REE中的 API接口53并将该账号登陆请求和第二可信执行环境的环境标识一并发送给富执行环境的操作系统内核驱动REE OS54。

[0178] ③由于第二可信执行环境是基于虚拟机实现的，REE OS54中的操作系统内核驱动在接收到第二可信执行环境的环境标识之后，需要调用HVC(hypervisor call)指令对账号登陆请求进行编译，并将编译后的HVC指令发送至位于EL2层虚拟机管理器hypervisor81。

[0179] ④虚拟机管理器hypervisor81对基于HVC进行解析，并将解析得到的账号登陆请求发送至第二可信执行环境的操作系统VM TEE 2 OS632。

[0180] ⑤第二可信执行环境的操作系统VM TEE 2 OS632对账号登陆请求进行分发，以将账号登陆请求发送至第二可信执行环境中的面部识别的第二可信应用TA612。

[0181] ⑥面部识别的可信应用TA612基于账号登陆请求启动并对用户面部图像进行采集、比对和分析，得到处理结果，并通过调用第二可信执行环境TEE的接口622将“面部识别通过”或“面部识别不通过”的处理结果返回至第二可信执行环境的操作系统VM TEE 2 OS632。

[0182] ⑦第二可信执行环境的操作系统VM TEE 2 OS632通过调用HVC指令，将处理结果返回至hypervisor81。

[0183] ⑧hypervisor81对HVC指令进行解析，并将解析后得到的处理结果返回至REE OS54。

[0184] ⑨REE OS54将“面部识别通过”或“面部识别不通过”的处理结果返回给视频类应用 CA55。

[0185] 可知的是，在标号⑨之后，还应包括有视频类应用CA根据处理结果执行账号登陆处理进程，本实施例对后续步骤不再做赘述。

[0186] 图13为本申请实施例提供的一种业务处理的装置的硬件结构示意图。请参见图13，该装置包括：存储器1301、处理器1302和接口电路1303。其中，存储器1301、处理器1302、接口电路1303可以通信；示例性的，存储器1301、处理器1302、接口电路1303可以通过通信总线通信，存储器1301用于存储计算机执行指令，由处理器1302来控制执行，并由接口电路
1303来执行通信，从而实现本申请实施例提供的业务处理的方法。

[0187] 可选的，接口电路1303还可以包括发送器和/或接收器。可选的，上述处理器1302可以包括一个或多个CPU，还可以是其他通用处理器、数字信号处理器(digital signal processor， DSP)、专用集成电路(application specific integrated circuit，ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

[0188] 可能的实现方式中，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

[0189] 本申请实施例提供的业务处理的装置，用于执行上述实施例的业务处理的方法，技术原理和技术效果相似，此处不再赘述。

[0190] 本申请实施例提供一种终端设备。终端设备的存储器可用于存储至少一个程序指令，处理器用于执行至少一个程序指令，以实现上述方法实施例的技术方案。其实现原理和技术效果与上述方法相关实施例类似，此处不再赘述。

[0191] 本申请实施例提供一种芯片。芯片包括处理器，处理器用于调用存储器中的计算机程序，以执行上述实施例中的技术方案。其实现原理和技术效果与上述相关实施例类似，此处不再赘述。

[0192] 本申请实施例提供一种计算机程序产品，当所述计算机程序产品在终端设备运行时，使得所述终端设备执行上述实施例中的技术方案。其实现原理和技术效果与上述相关实施例类似，此处不再赘述。

[0193] 以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。