一种基于Trust应用的信息传输方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种基于Trust应用的信息传输方法及装置。

背景技术：

随着信息技术的发展，终端设备(如手机、平板电脑等)中可以安装越来越多的应用程序(以下简称应用)。这些应用作为其服务提供商(如：网站、银行、电信运营商、设备制造商等)提供的业务入口，使用户可以通过该入口便捷地获取到服务提供商提供的各类业务服务。在这些业务服务中，某些类别的业务服务与用户信息安全密切相关，比如：支付业务、转账业务等等。这就要求安装在终端设备上的这类应用应当具备足够的安全性。

为了使这些应用具备足够的安全性，目前，服务提供商在开发应用时会基于一种称为Trustzone的安全性架构进行开发。Trustzone架构在终端设备中通常会为应用提供两种运行环境，即安全环境和通用环境，用以满足不同安全级别的运行要求。基于Trustzone架构开发的“Trustzon应用”(以下简称Trust应用)便运行在安全环境中。运行在安全环境中的Trust应用在实现与用户的信息安全密切相关的业务服务时，通常需要从同样运行在安全环境中的另一个Trust应用中获取用户信息，从而利用这些信息完成一项安全级别较高的业务服务。比如：假设服务提供商的Trust应用中提供了安全级别较高的指纹支付业务，当用户进行指纹支付业务时，该Trust应用在Trustzone的安全环境下从终端设备本地的指纹管理应用(该指纹管理应用是运行在Trustzone的安全环境下另一个Trust应用)获取用户输入的指纹信息，从而完成该指纹支付业务。

在上述完成业务服务过程中，基于Trustzone架构的特性，终端设备会将 Trust应用所需的信息(如：上例中的指纹信息)添加至该Trust应用自身的内存空间。由于需要访问内存空间，使得应用提供服务的效率较低。为了避免或改善这种情况，现有技术采用Trustzone板级支持包(Board Support Package，BSP)的方式，通过对TrustzoneBSP的编辑，使TrustzoneBSP可提供相应的接口和通信协议，从而实现不同Trust应用之间的信息交互，达到提升Trust应用之间信息交互的效率。

但是，TrustzoneBSP并不运行在Trustzone架构的安全环境内，在信息交互的过程中，TrustzoneBSP容易被非法操作者进行篡改和攻击，从而导致用户信息的泄露，使Trust应用信息交互的安全性较低。

技术实现要素：

本申请实施例提供一种基于Trust应用的信息传输方法及装置，用以解决现有技术中Trust应用的信息交互的安全性较低。

本申请实施例提供的一种基于Trust应用的信息传输方法，所述Trust应用包括运行在Trustzone安全环境下的第一应用和第二应用，所述方法包括：

接收来自通用环境的用于触发进行业务操作的业务请求；

根据所述业务请求确定能够执行业务操作的第一应用，以及提供该业务操作所需信息的第二应用；

将所述业务请求发送给所述第二应用；

获取所述第二应用加密后的所述业务请求的响应信息；

将所述加密结果发给所述第一应用，以便所述第一应用对所述加密结果进行解密，并保存在安全环境中供执行业务操作时使用。

本申请实施例还提供的一种信息传输装置，包括：

接收模块，用于接收来自通用环境的用于触发进行业务操作的业务请求；

确定模块，用于根据所述业务请求确定能够执行业务操作的第一应用，以及提供该业务操作所需信息的第二应用；

请求发送模块，用于将所述业务请求发送给所述第二应用；

获取模块，用于获取所述第二应用加密后的所述业务请求的响应信息；

转发处理模块，用于将所述加密后的响应信息转发给所述第一应用，以便所述第一应用对所述加密结果进行解密，并保存在安全环境中供执行业务操作时使用。

本申请实施例提供一种基于Trust应用的信息传输方法及装置，在终端设备内，要完成某一安全性较高的业务服务时，相应的应用或服务会发出业务请求给终端设备系统，由终端设备系统根据业务请求，确定出安全环境下参与执行业务操作的第一应用(一种Trust应用)和第二应用(另一种Trust应用)，并向将该业务请求转发给对应的第二应用，之后，第二应用将根据业务请求生成响应信息并针对生成的响应信息进行加密处理，再通过终端设备系统将加密后的响应信息转发给第一应用，从而，第一应用便可以获取到加密后的响应信息，供执行业务操作时使用。这样的方式可以有效保证在传输过程中响应信息的安全性，同时，第一应用会将响应信息保存在安全环境中，当再次执行业务操作时，第一应用便可以直接使用该响应信息，从而提升了执行业务操作的效率。此外，终端设备系统会调用其中可访问底层操作环境的接口完成Trust应用之间的信息交互，可避免向Trust应用对应的内存空间中添加信息的操作，有效提升了信息交互的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术中Trustzone架构在终端设备内提供的两种运行环境的示意图；

图2为本申请实施例提供的基于Trust应用的信息传输过程；

图3为本申请实施例提供的在实际应用场景下支付应用和指纹应用之间的信息传输过程；

图4为本申请实施例提供的基于Trust应用的信息传输装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

如前所述，Trustzone架构在终端设备内提供的两种运行环境，如图1所示。图1为Trustzone架构在终端设备内提供的两种运行环境的示意图。在图1中，两种运行环境包括：安全环境和通用环境，用以满足不同安全级别的运行要求。在通用环境下，通常可运行通用应用(如：拍照应用、天气应用等等)，或执行对安全级别要求不高的操作(如：拍照、编辑照片等)。而对于那些涉及到用户信息的管理、传输、获取终端设备权限等操作，由于所需的安全级别较高，则通常在在图1中所示的安全环境中执行相应操作。现有技术中使用TrustzoneBSP虽然可以便捷实现Trust应用之间的信息交互，但是TrustzoneBSP并不运行在图1中的安全环境内，也就增加了被篡改和攻击的风险。因此，本申请提供下述的基于Trust应用的信息传输方法。如图2所示。

图2为本申请实施例提供的信息传输过程，在该过程中，Trust应用包括运行在Trustzone安全环境下的第一应用和第二应用，该过程具体包括以下步骤：

S201：接收来自通用环境的用于触发进行业务操作的业务请求。

如前述，Trustzone架构在终端设备中提供了两种运行环境：通用环境和安全环境，对于服务提供商而言，会基于Trustzone架构，分别在通用环境和安 全环境中开发相应的应用或服务，用于完成不同安全级别的业务服务或操作。通常，对于安全级别较高的业务服务，可由处于通用环境和安全环境中的应用或服务共同完成。当然，在本申请实施例中，所述的终端设备，包括但不限于：手机、平板电脑、智能手表等终端设备。

例如：用户通过运行在通用环境下的某服务提供商开发的应用(或服务)，对展示在终端设备中的商品进行购买，在支付阶段，服务提供商提供了一种基于用户指纹的支付业务，可以认为，支付阶段所需的安全级别较高，那么，该过程就可由运行在安全环境下的应用完成。此时，运行在通用环境下的应用(或服务)就会发出业务请求，以使得运行在安全环境下获得支付过程中所需的指纹。

结合上例可见，对于本申请实施例的上述步骤而言，当用户通过运行在通用环境下的应用或服务获得某些业务服务时，可由运行在通用环境下的应用或服务发出业务请求，该业务请求用于触发相应的业务操作(如：后续过程的指纹支付操作等)。

S202，根据所述业务请求确定能够执行业务操作的第一应用，以及提供该业务操作所需信息的第二应用。

本申请实施例中所述的第一应用是由服务提供商开发的Trust应用，并运行在终端设备内的Trustzone安全环境下，可以认为，该第一应用具有安全性较高的业务功能，可以执行安全级别较高的业务操作，如：访问并获取终端设备内部安全级别较高的资源(包括终端设备中存储的用户的密码信息、生物特征信息等)，以实现支付、转账等业务。

所述的第二应用，也是一种Trust应用，通常由原始设备制造商(Original Equipment Manufacturer，OEM)提供。在本申请实施例中，第二应用与第一应用可具有不同的业务功能，第二应用可为第一应用提供所需的各类安全性较高的信息。如：第二应用可以是终端设备上采集、管理用户生物特征信息的应用，可为第一应用提供相应的用户的生物特征信息。

上述步骤中的业务请求中，通常会携带相应的标识信息，这些标识信息表明了该业务请求所要请求调用的应用程序编程接口(Application Programming Interface，API)、请求的目标应用等等，那么，根据业务请求，也就可以确定出完成业务服务所需的目标应用(即，第一应用)，以及可提供完成业务服务所需的目标应用(即，第二应用)。

正如上例所述，接收到获取用户指纹信息的业务请求后，也就可以确定出该业务请求所对应的目标应用为运行在Trustzone安全环境下的支付应用，以及运行在Trustzone安全环境下的终端设备内负责采集、管理指纹信息的应用。从而，将终端设备内运行在Trustzone安全环境下的支付应用作为第一应用，将负责指纹信息管理的应用作为第二应用，第二应用所提供的指纹信息，就是第一应用完成支付业务所需的信息。

S203，获取所述第二应用加密后的所述业务请求的响应信息。

将业务请求发送给第二应用后，第二应用就会对该业务请求进行处理，生成相应的响应信息。

考虑到实际应用中，某些业务服务需要较高的安全性，如：支付业务、转账业务等。这些业务服务通常需要较为关键的用户信息，如：用户的生物特征信息(包括：指纹信息、掌纹信息、声音信息、视网膜信息等)、或用户设置的密码信息等(在本申请实施例中，上述的关键的用户信息，就是第二应用生成的响应信息)，若这些关键的用户信息在终端中被盗取，将导致用户的信息安全受到威胁。

为了保证第二应用所生成的响应信息的安全性，故在本步骤中，第二应用将对其生成的响应信息进行加密处理，得到加密后的响应信息。本申请中对响应信息的加密方式，可采用具有极高的安全级别的Trustzone安全环境下的加密方式，当然，这里并不构成对本申请的限定。

S204，将所述加密后的响应信息转发给所述第一应用，以便所述第一应用对所述加密结果进行解密，并保存在安全环境中供执行业务操作时使用。

第一应用接收到了加密后的响应信息，便可以通过Trustzone提供的相应解密方式进行解密处理，得到响应信息，相应地，第一应用会将响应信息保存在Trustzone安全环境中(如：保存在第一应用所对应的Trustzone安全环境中的内存空间中)，以便后续再执行该业务操作时，可以无需再通过第二应用获取相应的信息，而是可以直接由第一应用提供该响应信息进行使用。

基于Trustzone架构的特性，为了保证Trust应用之间可以传递信息以完成相应的业务服务，同时保证信息传输的效率(不同于现有技术中将信息添加至Trust应用对应的内存空间中)，故在本申请实施例中，可由终端设备内操作系统作为不同Trust应用之间进行信息交互的“桥梁”，换言之，对于本申请实施例中的上述步骤而言，是由终端设备内的操作系统执行的。具体地，可由操作系统中可访问底层操作环境的接口实现，如：Java本地接口(Java Native Interface，JNI)。这里并不构成对本申请的限定。

通过上述步骤，在终端设备内，要完成某一安全性较高的业务服务时，相应的应用或服务会发出业务请求给终端设备系统，由终端设备系统根据业务请求，确定出安全环境下参与执行业务操作的第一应用(一种Trust应用)和第二应用(另一种Trust应用)，并向将该业务请求转发给对应的第二应用，之后，第二应用将根据业务请求生成响应信息并针对生成的响应信息进行加密处理，再通过终端设备系统将加密后的响应信息转发给第一应用，从而，第一应用便可以获取到加密后的响应信息，供执行业务操作时使用。这样的方式可以有效保证在传输过程中响应信息的安全性，同时，第一应用会将响应信息保存在安全环境中，当再次执行业务操作时，第一应用便可以直接使用该响应信息，从而提升了执行业务操作的效率。此外，终端设备系统会调用其中可访问底层操作环境的接口完成Trust应用之间的信息交互，可避免向Trust应用对应的内存空间中添加信息的操作，有效提升了信息交互的效率。

需要说明的是，上述实施例中作为两个Trust应用之间进行信息传输“桥梁”的终端设备系统，运行于Trustzone所提供的通用环境中，也即，富可执 行环境(Rich Execution Environment，REE，在下文中，为了方便描述，以REE指代通用环境)，在REE下传输的信息存在被盗取或篡改的可能。但考虑到Trustzone架构中的安全环境，是一种可信执行环境(Trusted Execution Environment，TEE，在下文中，为了方便描述，以TEE指代Trustzone安全环境)，可为运行在其中的Trust应用提供加密式的安全传输方式，而运行在终端设备系统中的JNI提供了丰富的调用支持，可调用TEE下的安全传输方式，那么，作为本申请实施例中的一种可选方式，可通过JNI调用TEE下的加密式的安全传输方式。

在这种情况下的一种场景中，TEE可提供安全传输所需的加密密钥-解密密钥对，本申请中的上述第一应用和第二应用，均是基于Trustzone架构开发的Trust应用，且都运行在TEE下，所以，第一应用和第二应用也就可以使用TEE中的加密密钥-解密密钥对，进行相应的加密处理或解密处理。

具体地，对于第二应用而言，在根据业务请求生成了响应信息后，会使用TEE中的加密密钥对响应信息进行加密处理，故上述步骤中获取所述第二应用加密后的所述业务请求的响应信息，具体包括：获取所述第二应用针对生成的所述响应信息，根据TEE中存储的加密密钥进行加密处理，得到的加密后的响应信息。

终端设备系统在接收到第二应用所反馈的加密后的响应信息后，也就会将加密后的响应信息发送给第一应用，相应地，将所述响应信息转发给所述第一应用，以完成所述业务服务，具体包括：将加密后的响应信息转发给所述第一应用，使得所述第一应用根据TEE中与所述加密密钥匹配的解密密钥对加密后的响应信息进行解密，得到所述响应信息，以完成所述业务服务。

针对上述内容，在实际应用时，当不同的两个Trust应用要进行信息交互时，终端设备系统会为两个Trust应用分配加密密钥和解密密钥，如前所述，第二应用接收到第一应用的业务请求后，会生成响应信息，第二应用需要对该响应信息进行加密，那么，终端设备系统就会为第二应用分配加密密钥。第一 应用在后续流程中会接收到加密后的响应信息，并需要对加密后的响应信息进行解密，那么，终端设备系统就会为第一应用分配与所述的加密密钥相匹配的解密密钥。这种方式通常是两个Trust应用每一次进行信息交互时，终端设备系统就分配一次加密密钥和解密密钥，并在第一应用解密后，回收该加密密钥和解密密钥。

可见，上述方式中，终端设备系统在两个Trust应用每一次进行信息交互时，都需要分别为这两个Trust应用分配加密密钥和解密秘钥，这种方式可能会占增加终端设备的工作量，故在本申请实施例的另一些场景下，终端设备系统会为需要执行解密操作的Trust应用分配解密密钥，使得该Trust应用持续持有该解密密钥，当该Trust应用向其他的Trust应用发送业务请求后，终端设备系统会向其他的Trust应用分配与所述解密密钥匹配的加密密钥。在这种方式中，终端设备系统无需回收解密密钥，从而可以减少在Trust应用每一次信息交互时的工作量。

当然，上述加密密钥-解密密钥对的使用只是本申请中的示例，这并不构成对本申请的限定。此外，在某些场景下，在第二应用向终端设备系统返回加密后的响应信息的同时，也会同时返回一个未加密的响应信息。此时，终端设备系统会将加密后的响应信息转发给第一应用，而将未加密的响应信息反馈给发出业务请求的应用或服务。

通过上述加密传输的方式，可以对第二应用的响应信息进行加密处理，即使在传输过程中被盗取，也无法获知真实的响应信息(因为此时终端设备系统已将相应的解密密钥分配给了第一应用，其他Trust应用无法获得解密密钥，也就无法对加密的响应信息进行解密处理)。此外，在实际应用中，不同的服务提供商均可以采用Trustzone架构开发不同的Trust应用，换言之，在同一终端设备中的TEE下，可能运行有多种Trust应用，而某些Trust应用可能在其他Trust应用进行信息交互的过程中，“窥测”传输的信息，那么，加密后的响应信息的在TEE部分的传输过程中，也具有极高的保密性，可以认为，在TEE 中加密传输的方式形成了一种“双保险”的信息传输方式(即保证了在Trust安全环境以外的完全性，也保证了在Trust安全环境中的安全性)，从而使得Trust应用之间的信息传输过程具有极高的安全性。

上述内容是基于第二应用成功接收到业务请求的基础上实现的，而在实际应用场景中，第二应用可能处于未启动的状态，此时，即使终端设备系统将业务请求转发给第二应用后，由于第二应用未启动，那么第二应用也不会进行响应。此外，第一应用也可能处于关闭会话的状态，如果在这期间，终端系统向第一应用转发加密后的响应信息，那么，第一应用也无法接收该加密后的响应信息。在实际应用中，无论出现哪一种情况，都会影响业务服务的实现效率。

所以，在本申请中，在将业务请求发送给所述第二应用之前，所述方法包括：向确定出的所述第二应用以及所述第一应用发送会话通知，指示所述第二应用与所述第一应用同时进入会话状态。

第一应用和第二应用和同时进入会话状态，就表示两个应用均启动，并且两个应用均准备接收信息，显然，在该场景下，第二应用可以及时地接收到业务请求，在反馈了加密后的响应信息后，第一终端也能及时接收到加密后的响应信息。

当第一应用针对加密后的响应信息进行解密获得了响应信息后，也就表示第一应用和第二应用完成了相应的信息交互，之后，第一应用可以执行后续的业务服务，而第二应用也可能被其他Trust应用调用，那么，为了不影响两个应用各自的运行状态，也就可以关闭第一应用和第二应用的会话状态，故将加密后的所述响应信息转发给所述第一应用后，所述方法包括：向所述第二应用以及所述第一应用发送会话终止通知，指示所述第二应用与所述第一应用同时结束会话状态。

为了能够更清楚地阐述上述在TEE下的Trust应用间的信息交互过程，下 面将以第一应用为具有指纹支付功能的支付应用、第二应用为终端设备内负责管理指纹信息的指纹应用的场景进行详细说明(该场景下的支付应用和指纹应用均是Trust应用，支付应用由相应的网络服务商提供，指纹应用由终端设备的OEM提供)。

在该场景中，用户可以使用安装在终端设备内的支付应用，对某笔交易进行支付，正如前述假设条件，该支付应用所提供的支付方式为指纹支付，也即，用户需要输入自身的指纹信息后，才能完成支付业务。而用户输入的指纹信息可能是正确的，也可能是错误的，此时，指纹应用就会对用户输入的指纹信息进行校验，也即，在本申请实施例中，获取所述第二应用根据所述业务请求生成的响应信息，具体包括：指示所述第二应用接收用户输入的指纹信息，并根据所述第二应用中预存的标准指纹信息，对用户输入的所述指纹信息进行校验，获取通过校验的、由所述第二应用进行加密处理的加密后的指纹信息。

终端设备系统接收到指纹应用反馈的加密后的指纹信息后，就会将加密后的指纹信息转发给支付应用，那么，支付应用也就可以对加密后的指纹信息进行解密，从而获得指纹支付业务所需的指纹信息。

对于上述内容而言，其完整的过程如图3所示，在图3所示的过程中，支付应用(第一应用)和指纹应用(第二应用)均属于Trust应用，运行在终端设备上的TEE中，也即Trustzone安全环境，JNI以及与第一应用对应的REE应用(在本场景中，可以认为REE应用与第一应用是由同一服务提供商开发的应用，分别运行在REE和TEE下，这并不构成对本申请的限定)，均运行在终端设备上的REE中，也即，通用环境，所述过程包括：

S301：REE应用向终端设备系统内的JNI发送指纹获取请求。

其中，REE应用提供了购买商品的服务，当用户通过该REE应用购买了某种商品后，便进入支付阶段，假设本示例中的支付方式为指纹支付，故此时REE应用就会向JNI发起指纹获取请求。

JNI是终端设备内可以访问底层操作环境的接口，通过JNI，可以在TEE 中为支付应用和指纹应用建立信息交互的桥梁。

S302：JNI同时向支付应用和指纹应用发送会话通知，使支付应用和指纹应用同时进入会话状态。

这就表明后续的指纹支付过程将在TEE下进行。

S303：JNI向指纹应用发送指纹获取请求。

S304：指纹应用接收用户输入的指纹信息，并根据预存的标准指纹信息，对用户输入的所述指纹信息进行校验。

S305：当校验通过时，指纹应用将用户输入的所述指纹信息作为与所述指纹信息获取请求对应的响应信息，并对所述响应信息加密。

S306：将加密后的响应信息反馈给JNI。

S307：JNI将加密后的响应信息转发给支付应用。

S308：支付应用使用解密密钥对加密的响应信息进行解密，获得指纹信息，并保存在支付应用本地。

在本场景中，通过指纹应用验证的指纹信息，可以认为是正确的指纹信息，那么，当支付应用获取到了指纹信息后，就可以保存在TEE本地，这样一来，当后续用户再次使用该支付应用进行指纹支付时，支付应用便可以通过保存在安全环境本地的指纹信息进行校验或直接支付。

S309：支付应用通过其支付服务接口将指纹信息发送至服务器。

支付应用中的支付服务接口与相应的服务器向连接，当支付应用获得了用户的指纹信息后，便可将指纹信息通过其支付服务接口发送至服务器，用以完成支付。

对于上述过程而言，是用户输入的指纹信息成功通过验证的情况下执行的，而在实际应用中，用户所输入的指纹信息可以未通过验证，当然，也有可能是非法操作者提供的虚假指纹信息，为了保证支付业务的安全，所述方法还包括：当校验未通过时，向所述第二应用以及所述第一应用发送会话终止通知，指示所述第二应用与所述第一应用同时结束会话状态。也即，一旦在指纹应用 的校验过程中未通过校验，那么，JNI直接向支付应用和指纹应用发起通知，使支付应用和指纹应用同时结束会话状态。

上述如图3所示的示例，仅以第二应用为指纹应用为例进行说明，在实际应用中，第二应用可以是终端设备中采集、管理用户个人信息的本地应用，包括但不限于，声音采集应用、视网膜采集应用、密码管理应用等等，这里并不构成对本申请的限定。

以上为本申请实施例提供的信息传输方法，基于同样的思路，本申请实施例还提供一种信息传输装置，如图4所示。

图4中基于Trust应用的信息传输装置，所述Trust应用包括运行在Trustzone安全环境下的第一应用和第二应用，所述装置包括：

接收模块401，用于接收来自通用环境的用于触发进行业务操作的业务请求。

确定模块402，用于根据所述业务请求确定能够执行业务操作的第一应用，以及提供该业务操作所需信息的第二应用。

请求发送模块403，用于将所述业务请求发送给所述第二应用。

获取模块404，用于获取所述第二应用加密后的所述业务请求的响应信息。

转发处理模块405，用于将所述加密后的响应信息转发给所述第一应用，以便所述第一应用对所述加密结果进行解密，并保存在安全环境中供执行业务操作时使用。

通过本申请实施例中所提供的上述装置，在终端设备内，要完成某一安全性较高的业务服务时，相应的应用或服务会发出业务请求给终端设备系统，那么，接收模块401便可以接收到该业务请求，之后，确定模块402根据接收模块401接收到的业务请求，可确定出运行在Trustzone安全环境下的第一应用(一种Trust应用)和第二应用(另一种Trust应用)，相应地，请求发送模块403会将业务请求发送给第二应用，之后，第二应用根据业务请求生成的响应 信息并针对生成的响应信息进行加密处理，获取模块404获取到加密后的响应信息后，再通过转发处理模块405将加密后的响应信息转发给第一应用，从而，第一应用便可以获取到加密后的响应信息，以完成业务服务。这样的方式可以有效保证在传输过程中响应信息的安全性，同时，终端设备系统会调用其中可访问底层操作环境的接口完成Trust应用之间的信息交互，可避免向Trust应用对应的内存空间中添加信息的操作，有效提升了信息交互的效率。

具体地，在Trustzone中的安全环境下，第二应用会使用Trustzone的安全环境中的加密密钥对响应信息进行加密处理，那么，所述获取模块403，具体用于获取所述第二应用针对生成的所述响应信息，根据Trustzone安全环境中存储的加密密钥进行加密处理，得到的加密后的响应信息。

相应地，所述转发处理模块404，具体用于将加密后的响应信息转发给所述第一应用，使得所述第一应用根据Trustzone安全环境中与所述加密密钥匹配的解密密钥对加密后的响应信息进行解密，得到所述响应信息并保存在安全环境中，供执行所述业务操作。

另外，为了保证第一应用和第二应用均可以顺利接收到信息，所述装置还包括：会话处理模块405，用于在指示所述第二应用根据所述业务请求反馈加密后的响应信息之前，向确定出的所述第二应用以及所述第一应用发送会话通知，指示所述第二应用与所述第一应用同时进入会话状态；以及，用于在所述第一应用获得所述响应信息后，向所述第二应用以及所述第一应用发送会话终止通知，指示所述第二应用与所述第一应用同时结束会话状态。

在所述业务请求包括指纹信息获取请求、所述第二应用用于对指纹信息进行处理的场景下，所述获取模块403，具体用于指示所述第二应用接收用户输入的指纹信息，指示所述第二应用根据预存的标准指纹信息，对用户输入的所述指纹信息进行校验，当校验通过时，将用户输入的所述指纹信息作为与所述指纹信息获取请求对应的响应信息，对所述响应信息加密后反馈。

此时，所述会话处理模块404，还用于当校验未通过时，向所述第二应用 以及所述第一应用发送会话终止通知，指示所述第二应用与所述第一应用同时结束会话状态。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算 机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。