可信应用程序的远程证明方法及装置、电子设备与流程

本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种可信应用程序的远程证明方法及装置、电子设备。

背景技术：

远程证明(remoteattestation)，是一种硬件或者软硬件获得远程提供者或生产者的信任的方法，是可信计算的关键技术之一。例如，在实际应用中，可以将可信应用程序中的受保护代码在可信执行环境中进行隔离，并且可以基于远程证明技术，在不泄露受保护代码的基础上，向远程接收对象证明这些受保护代码的执行结果为可信数据。

技术实现要素：

本说明书提出一种可信应用程序的远程证明方法，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述方法包括：

调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；

通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；

获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；

将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。

可选的，调用所述目标函数在所述目标容器中生成私钥以及公钥，包括：

响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，

基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。

可选的，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储，包括：

基于生成的所述公钥创建远程证明凭证；

将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；

获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；

将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。

可选的，所述可信执行环境为基于sgx技术搭建的可信执行环境；所述目标容器为sgx技术中的enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-mrenclave策略。

可选的，所述远程接收对象为发布至区块链的智能合约。

本说明书还提出一种可信应用程序的远程证明装置，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述装置包括：

生成模块，调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；

证明模块，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；

获取模块，获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；

验证模块，将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。

可选的，所述生成模块：

响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，

基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。

可选的，所述证明模块：

基于生成的所述公钥创建远程证明凭证；

将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；

获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；

将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。

可选的，所述可信执行环境为基于sgx技术搭建的可信执行环境；所述目标容器为sgx技术中的enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-mrenclave策略。

可选的，所述远程接收对象为发布至区块链的智能合约。

本说明书还提出一种电子设备，包括：

处理器；

用于存储机器可执行指令的存储器；

其中，通过读取并执行所述存储器存储的与基于区块链的可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述处理器被促使：

调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；

通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；

获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；

将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。

在以上技术方案中，一方面，由于用于远程证明的公私钥对在作为可信执行环境的目标容器中自主生成，不再由软件提供商来生成；并且，持久化存储的加密后的私钥，被设置了仅由该目标容器进行解密的解密策略；因此，即便是软件开发者也无法获取到生成的私钥，从而可以显著提升私钥的安全等级；

另一方面，由于可信应用程序仅需要通过第三方远程证明服务端，向远程接收对象发起一次针对自主生成的公钥的远程证明，并在该公钥通过远程证明之后，后续就可以直接使用生成的私钥对受保护代码中的待执行代码的执行结果进行签名，并将签名后的执行结果发送给远程接收对象完成针对该执行结果的远程证明，而不再需要通过第三方远程证明服务端来向远程接收对象发起针对该执行结果的远程证明；因此，可以不再需要与第三方远程证明服务端进行频繁的交互，就可以基于自主生成的公私钥对就可以便捷的向远程接收对象证明该执行结果为可信数据。

附图说明

图1是一示例性实施例提供的一种可信应用程序的远程证明方法的流程图。

图2是一示例性实施例提供的一种电子设备的结构示意图。

图3是一示例性实施例提供的一种可信应用程序的远程证明装置的框图。

具体实施方式

在实际应用中，通常可以通过搭建tee(trustedexecutionenvironment，可信执行环境)，并将可信应用程序中的受保护代码，在tee中进行隔离，来实现对这些受保护代码的安全防护。

其中，在搭建tee时，通常可以将设备底层的处理器作为硬件支撑，来搭建一个仅能由处理器来访问的容器(container)作为可信执行环境，并将可信应用程序中的受保护代码隔离加载在该容器中，以对容器中的受保护代码进行隔离保护。

例如，以利用intel的sgx(softwareguardextensions，软件保护扩展)技术来搭建tee为例，基于sgx技术，通常会将设备的cpu作为硬件支撑，来创建称之为enclave的程序作为保护容器，并将需要受到保护的代码隔离加载在enclave程序中，保护其不受到攻击。

而在一些场景下，上述可信应用程序中的受保护代码的执行结果，如果需要参与远程的可信计算，则该可信应用程序除了需要将上述受保护代码的执行结果发送给远程接收对象以外，通常还需要基于远程证明技术，在不泄露受保护代码的基础上，向远程接收对象证明这些受保护代码的执行结果为可信数据。

例如，在一个场景下，假设部署在区块链上的智能合约需要将可信应用程序中的受保护代码的执行结果作为输入数据，在区块链上进行可信计算；在这种情况下，由于可信应用程序并不是链上节点，对于智能合约来说是非授信的一方；因此，可信应用程序在将受保护代码的执行结果发送给部署在区块链上的智能合约时，则需要依靠远程证明技术，在不泄露受保护代码的基础上，向智能合约证明这些受保护代码的执行结果为可信数据(即链上证明)。

而基于目前的远程证明技术，可信应用程序向远程接收对象发起针对特定数据的远程证明时，通常需要依赖第三方远程证明服务端来完成；

例如，仍然以intel的sgx技术中的远程证明机制为例，基于sgx技术，intel会提供用于远程证明的第三方的ias(intelattestationservice，因特认证服务)服务器。隔离加载在enclave中的受保护代码的执行结果，如果需要参与可信计算，则可信应用程序可以与ias服务器进行交互，通过ias服务器向远程接收对象发起针对该受保护代码的执行结果的远程认证，向远程接收对象证明该受保护代码的执行结果为可信数据。

由于依赖第三方远程证明服务端来完成远程证明，需要与第三方远程证明服务端进行频繁交互，因此需要一种更加便捷的远程证明机制。

基于此，本说明书提出一种基于作为可信执行环境的容器独立生成的公私钥对，来便捷向远程接收对象发起对受保护代码的执行结果的远程证明方案。

在实现时，可信应用程序的软件开发者，可以基于特定的tee搭建技术(比如，采用intel的sgx技术)，来开发作为tee的目标容器(比如，sgx技术中的enclave程序)，并将可信应用程序中的受保护代码隔离加载在该目标容器中。

其中，在本方案中，隔离加载在上述目标容器中的受保护代码，可以包括执行结果需要向远程接收方进行远程证明的待执行代码，和用于生成私钥以及公钥的目标函数(本质上是一些生成私钥公钥的特殊代码)。

进一步的，可信应用程序可以调用隔离加载在上述目标容器中的受保护代码中的目标函数，在目标容器中生成一对公钥和私钥；

一方面，对于生成的私钥，还可以在目标容器中进行加密处理；其中，在目标容器中对生成的私钥进行加密时，可以为加密后的私钥设置仅由该目标容器进行解密的解密策略(即仅该目标容器具有解密权限)；然后，由处理器将加密后的私钥进行持久化存储。

另一方面，对于生成的公钥，可以通过第三方远程证明服务端，向远程接受对象发起针对该公钥的远程证明，并在该公钥通过远程证明时，将生成的该公钥发送至远程接收对象，由远程接收对象进行持久化存储。

后续，当上述待执行代码执行完毕，上述目标容器可以对上述加密的私钥进行解密，基于该私钥对该待执行代码的执行结果进行签名处理。而可信应用程序可以获取由上述目标容器签名处理后的执行结果，并将该执行结果发送至远程接收对象，来发起针对该执行结果的远程证明。

远程接收对象在接收到可信应用程序发送的执行结果后，可以基于已经存储的公钥，对该执行结果的签名进行验证，来确定该执行结果是否为可信数据。

在以上技术方案中，一方面，由于用于远程证明的公私钥对在作为可信执行环境的目标容器中自主生成，不再由软件提供商来生成；并且，持久化存储的加密后的私钥，被设置了仅由该目标容器进行解密的解密策略；因此，即便是软件开发者也无法获取到生成的私钥，从而可以显著提升私钥的安全等级；

另一方面，由于可信应用程序仅需要通过第三方远程证明服务端，向远程接收对象发起一次针对自主生成的公钥的远程证明，并在该公钥通过远程证明之后，后续就可以直接使用生成的私钥对受保护代码中的待执行代码的执行结果进行签名，并将签名后的执行结果发送给远程接收对象完成针对该执行结果的远程证明，而不再需要通过第三方远程证明服务端来向远程接收对象发起针对该执行结果的远程证明；因此，可以不再需要与第三方远程证明服务端进行频繁的交互，就可以基于自主生成的公私钥对就可以便捷的向远程接收对象证明该执行结果为可信数据。

下面通过具体实施例并结合具体的应用场景对本说明书进行描述。

请参考图1，图1是本说明书一实施例提供的一种可信应用程序的远程证明方法，应用于可信应用程序；所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述方法执行以下步骤：

步骤102，调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；

步骤104，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；

步骤106，获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；

步骤108，将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。

上述可信应用程序，包括由软件开发者开发的能够向第三方提供可信服务的应用程序；其中，可信应用程序中的程序代码，通常包括受保护部分，和不受保护。

上述目标容器，在本说明书泛指基于特定的tee搭建技术，搭建出的一个能够为可信应用程序中的受保护代码提供安全保护的隔离的安全运行环境；

其中，在实际应用中，上述目标容器可以是一个以处理器作为底层硬件支撑，且仅能由处理器进行访问的隔离的软件环境；例如，以采用intel的sgx技术搭建tee为例，上述目标容器具体可以是sgx技术中的enclave程序，通常将可信应用程序中的受保护代码隔离加载到enclave程序中，来对上述受保护代码进行安全防护。

当然，在实际应用中，也不排除上述目标容器具体也可以是一个在物理上隔离的硬件环境；比如，上述目标容器具体可以是一个在物理上隔离的物理芯片，可以将可信应用程序中的受保护代码隔离加载在该物理芯片中，来对上述受保护代码进行安全防护。

其中，需要强调的是，搭建tee所采用的tee搭建技术，在本说明书中不进行特别限定，本领域技术人员可以基于实际的开发需求来灵活的选择。不难理解的是，上述目标容器的具体形态，通常也取决于本领域技术人员所采用的tee搭建技术；也即，上述目标容器最终是一个隔离的软件环境，还是一个隔离的硬件环境，取决于本领域技术人员所采用的tee搭建技术；例如，如果本领域技术人员采用intel的sgx技术来搭建tee，则上述目标容器是一个以cpu作为底层硬件支撑，且仅能由cpu进行访问的隔离的软件环境(即enclave程序)。

上述远程接收对象，具体是指可信应用程序中的受保护代码的执行结果的远程数据使用方；例如，在实际应用中，上述远程接收对象可以是一个独立的可信主机、可信系统；或者，也可以是一个在区块链上部署的智能合约。

在以下实施例中，将以基于intel的sgx技术来搭建tee为例进行说明；其中，需要强调的是，以基于intel的sgx技术来搭建tee为例，仅为示意性的；显而易见的，在实际应用中，显然也可以采用其它的tee搭建技术，来搭建tee；比如，还可以采用诸如arm的trustzone技术，在本说明书中不在进行一一列举。

在本说明书中，可信应用程序的软件开发者，可以基于intel的sgx技术，来创建作为tee的enclave程序，并将可信应用程序中的受保护代码隔离加载在该目标容器中。

需要说明的是，基于sgx技术创建enclave程序，以及将受保护代码隔离加载在该目标容器中的具体实现过程，在本说明书中不再进行详细说明，本领域技术护人员在将本说明书的技术方案付诸实现时，可以参考相关技术中的记载。

对于隔离加载在该enclave程序中的受保护代码，通常称之为该可信应用程序的可信区(trustedpart)；而其它未被隔离加载在enclave程序中的代码，则称之为该可信应用程序的非可信区(untrustedpart)。

其中，对于隔离加载在上述enclave程序中的受保护代码，至少可以包括待执行代码和目标函数两部分；

上述待执行代码，即为执行结果需要发送给远程接收对象进行可信计算的受保护代码；也即，可信应用程序需要通过可信证明技术，向远程接收对象证明上述待执行代码的执行结果为可信数据。而上述目标函数，具体用于为上述目标容器生成公钥和私钥。

在sgx技术中，可信应用程序向远程接收对象发起对受保护代码的执行结果的远程证明，通常是通过与部署的ias服务器进行交互来完成的。

而本说明书中，可以不再利用sgx技术中现有的远程证明机制，通过与ias服务器进行交互，来向远程接收对象发起对受保护代码的执行结果的远程证明，而是仅利用sgx技术中现有的远程证明机制，向远程接收对象发起一次对在enclave程序内部独立生成的公私钥对的远程证明，而后可以在上述公私钥对的远程证明通过后，基于上述公私钥对，来便捷向远程接收对象发起对受保护代码的执行结果的远程证明，而不再需要与ias进行交互。

在初始状态下，可信应用程序的非可信区，可以通过ecall的方式，调用隔离加载在该enclave程序中的受保护代码中的目标函数，在enclave程序内部生成一对公钥以及私钥。

其中，需要说明的是，非可信区通过ecall的方式，针对隔离加载在该enclave程序中的受保护代码中的目标函数的调用，可以在执行受保护代码中的待执行代码时实时的调用，也可以基于一定的调用周期，来周期性的调用。

例如，在一种实现方式中，非可信区在接收到针对受保护代码中的待执行代码的执行指令时，可以实时响应该执行指令，立即通过ecall的方式，调用隔离加载在该enclave程序中的受保护代码中的目标函数，在enclave内部生成一对公钥和私钥。

在另一种实现方式中，也可以为非可信区预先设定一个调用周期，使得非可信区可以基于该调用周期，来周期性调用隔离加载在该enclave程序中的受保护代码中的目标函数，在enclave程序内部生成一对公钥和私钥。通过这种方式，可以定时的对enclave程序的公钥和私钥进行更新。

一方面，对于生成的私钥，可以由处理器在enclave程序内部进行加密处理(密钥由处理器持有)，并由处理器为加密后的私钥设置解密策略，然后将加密后的私钥进行持有化存储；

其中，基于sgx技术，针对加密后的信息的解密策略，通常包括keypolicy-mrenclave(以下简称mrenclave策略)和keypolicy-mrsigner(以下简称mrsigner)两种策略。

所谓mrenclave策略，是指仅仅可被当前的enclave解密；而所谓mrsigner策略，是指可以被同一开发者开发和签署的所有enclave进行解密。

由于采用mrsigner策略，需要信任开发者；因此，对于获取到开发者的私钥的恶意者而言，通过开发恶意的enclave，并基于掌握的开发者的私钥对该恶意的enclave进行签署，就可以通过该恶意的enclave对加密后的私钥进行解密，从而导致加密后的私钥的明文数据泄露。

基于此，在本说明书中，处理器在为加密后的私钥设置解密策略时，可以将解密策略设置为mrenclave策略；即，仅当前的enclave具有对持久化存储的加密后的私钥进行解密的权限。

通过这种方式，可以确保即便是软件开发者也无法获取到enclave独立生成的私钥，从而可以显著提升私钥的安全等级。

另一方面，对于生成的公钥，可以由可信执行程序的可信区通过ias服务器，向远程接受对象发起针对该公钥的远程证明，并在该公钥通过远程证明时，将生成的该公钥发送至远程接收对象，由远程接收对象进行持久化存储。

基于sgx技术，可信执行程序的可信区，向远程接受对象发起针对该公钥的远程证明时，首先可以基于生成的公钥或者公钥的hash值，创建一个作为远程证明凭证的quote；

例如，基于sgx技术，上述quote通常是由enclave和一个特殊的quoteenclave进行内部交互，由quoteenclave来创建完成的。其中，由quoteenclave为enclave创建用于远程证明的quote的具体实施过程，在本说明书中不在进行详述，本领域技术人员在将本说明书的技术方案辅助时间时，可以参考相关技术中的技术。

在本说明书中，最终创建完成的quote，通过可以包括epid签名、生成的公钥或者公钥的hash值(即需要远程证明的userdata)、mrenclave标识、处理器的epid标识等信息。

也即，最终创建完成的quote，是针对生成的公钥或者公钥的hash值(即需要远程证明的userdata)、mrenclave标识、处理器的epid标识等信息整体进行epid签名后得到的信息。

其中，mrenclave标识，通常为enclave代码的hash值，用于唯一标识一个enclave。epid标识，也称之为basename，用于匿名标识一个处理器。而epid签名，是intel的sgx技术采用的一种可以保持匿名的群签名技术，在本说明书中对于epid签名的签名处理过程，以及epid签名的签名验证过程，不再进行详述，本领域技术人员可以参考相关技术中的记载。

在本说明书中，当生成了作为远程证明凭证的quote之后，可信执行程序的可信区，可以将该quote发送给ias服务器进行远程验证。而ias服务器收到该quote之后，可以对该quote的epid签名进行验证，然后基于ias服务器持有的私钥，对该quote和针对该quote的验证结果整体进行签名处理，生成对应的avr(attestationverificationreport，证明验证报告)。

也即，在本说明书中，上述avr通常可以包括上述quote、quote验证结果和ias签名等信息。

在本说明书中，ias服务器可以将生成的avr返回给可信执行程序的可信区，可信执行程序的可信区在收到ias服务器返回的avr后，可以将该avr以及通过调用上述目标函数生成的公钥，进一步发送给远程接收对象。

或者，可信执行程序的可信区也可以将该avr以及通过调用上述目标函数生成的公钥，进一步发送给可信执行程序的非可信区，由上述非可信区将该avr以及通过调用上述目标函数生成的公钥，进一步发送给远程接收对象。

而远程接收对象在收到可信执行程序的可信区发送的avr之后，首先可以对avr的状态进行验证；比如验证avr中的状态字段的取值是否为指示该avr状态正常的特定值；当avr的状态验证通过之后，可以基于ias服务器持有的私钥对应的公钥，对该avr的ias签名进行验证；如果签名验证通过，此时可以进一步针对该avr中携带的quote中的公钥或者公钥的hash值、mrenclave标识、处理器的epid标识等信息进行验证。

其中，对quote中的公钥或者公钥的hash值进行的验证，即为验证quote中的公钥或者公钥的hash值，与可信执行程序的可信区发送的公钥是否匹配的过程；比如，如果quote中携带的是公钥的hash值，则可以进一步计算可信执行程序的可信区发送的公钥的hash值，然后将计算出的hash值，与quote中携带的公钥的hash值进行匹配；如果二者匹配，则可以确认验证通过。

其中，对quote中的mrenclave标识和处理器的epid等信息进行的验证，即为验证与mrenclave标识对应enclave，以及验证与处理器的epid对应的处理器是否可信的过程。

在实现时，enclave的开发者可以通过开源enclave代码来证明enclave代码中不包含恶意代码，而远程接收对象的管理员，可以对开源的enclave代码进行安全审计，为远程接收对象设置mrenclave白名单。同样，也可以按照实际需求，为远程接收对象设置epid标识白名单。从而，远程接收对象在对quote中的mrenclave标识和处理器的epid标识等信息进行验证时，可以通过将quote中的mrenclave标识与mrenclave白名单进行匹配，以及将quote中的处理器的epid标识与epid标识白名单进行匹配，来确认与mrenclave标识对应enclave，以及与处理器的epid对应的处理器是否可信。

请继续参见图2，当avr的ias签名；以及该avr中携带的quote中的公钥或者公钥的hash值、mrenclave标识、处理器的epid标识等信息均验证通过之后，远程接收对象可以将可信执行程序的可信区发送的通过调用上述目标函数生成的上述公钥，以及对应的mrenclave和epid在本地进行持久化存储。

也即，将与调用上述目标函数生成的上述公钥对应的mrenclave作为可信程序标识，将与上述公钥对应的epid作为可信硬件标识，与上述公钥一起进行持久化存储。

在本说明书，当上述远程接收对象将通过调用上述目标函数生成的上述公钥在其本地进行持久化存储之后，后续上述可信应用程序可以不再需要与ias服务器进行交互，来发起针对上述待执行代码的执行结果的远程证明，而是直接通过调用上述目标函数创建的上述公私钥对，来便捷向远程接收对象发起对受保护代码的执行结果的远程证明。

具体地，当隔离加载在上述enclave中的待执行代码执行完毕，上述enclave可以对已经持久化存储的加密后的私钥进行解密(只有该enclave具有解密权限)，并基于解密出的私钥，对该待的执行结果进行签名处理。

其中，需要说明的是，实际应用中，上述执行结果除了可以包括上述待执行代码在执行完毕后的输出结果以外，也可以引入其它的信息；即可以根据实际的业务需求，将上述待执行代码的输出结果以外的其它信息也作为执行结果的一部分进行签名处理，然后发起远程认证；例如，在一个例子中，可以将上述待执行代码在执行时的输入数据(比如待执行代码在执行时输入的执行参数)，也作为上述执行结果的一部分，进行签名处理。

而可信应用程序的非可信区，可以获取由上述enclave签名处理后的执行结果，将该执行结果直接发送给远程接收对象，发起针对该执行结果的远程证明。

当然，在实际应用中，也可以由可信应用程序的可信区，直接将签名处理后的上述执行结果发送给远程接收对象，发起针对该执行结果的远程证明。

而远程接收对象在收到该执行结果后，可以基于在本地持久化存储的上述公钥(即调用上述目标函数生成的公钥)，基于该公钥对该执行结果的签名进行验证；如果该签名验证通过，则可以直接认定该执行结果为，在可信的处理器上创建的可信的enclave所生成的可信数据；此时针对上述待执行代码的执行结果的远程证明完成。

通过这种方式，在向远程接收对象对上述待执行代码的执行结果进行远程证明时，可以不再需要与ias服务器进行交互，从而可以更加便捷的完成远程证明。

在以上技术方案中，一方面，由于用于远程证明的公私钥对在作为可信执行环境的目标容器中自主生成，不再由软件提供商来生成；并且，持久化存储的加密后的私钥，被设置了仅由该目标容器进行解密的解密策略；因此，即便是软件开发者也无法获取到生成的私钥，从而可以显著提升私钥的安全等级；

另一方面，由于可信应用程序仅需要通过第三方远程证明服务端，向远程接收对象发起一次针对自主生成的公钥的远程证明，并在该公钥通过远程证明之后，后续就可以直接使用生成的私钥对受保护代码中的待执行代码的执行结果进行签名，并将签名后的执行结果发送给远程接收对象完成针对该执行结果的远程证明，而不再需要通过第三方远程证明服务端来向远程接收对象发起针对该执行结果的远程证明；因此，可以不再需要与第三方远程证明服务端进行频繁的交互，就可以基于自主生成的公私钥对就可以便捷的向远程接收对象证明该执行结果为可信数据。

与上述方法实施例相对应，本说明书还提供了一种可信应用程序的远程证明装置的实施例。本说明书的可信应用程序的远程证明装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图2所示，为本说明书的可信应用程序的远程证明装置所在电子设备的一种硬件结构图，除了图2所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。

图3是本说明书一示例性实施例示出的一种可信应用程序的远程证明装置的框图。

请参考图3，所述可信应用程序的远程证明装置30可以应用在前述图2所示的电子设备中；其中，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；

所述装置30包括：

生成模块301，调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；

证明模块302，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；

获取模块303，获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；

验证模块304，将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。

在本实施例中，所述生成模块301：

响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，

基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。

在本实施例中，，所述证明模块302：

基于生成的所述公钥创建远程证明凭证；

将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；

获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；

将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。

在本实施例中，，所述可信执行环境为基于sgx技术搭建的可信执行环境；所述目标容器为sgx技术中的enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-mrenclave策略。

在本实施例中，，所述远程接收对象为发布至区块链的智能合约。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

与上述方法实施例相对应，本说明书还提供了一种电子设备的实施例。该电子设备包括：处理器以及用于存储机器可执行指令的存储器；其中，处理器和存储器通常通过内部总线相互连接。在其他可能的实现方式中，所述设备还可能包括外部接口，以能够与其他设备或者部件进行通信。

在本实施例中，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；

通过读取并执行所述存储器存储的与可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述处理器被促使：

调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；

通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；

获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；

将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。

在本实施例中，通过读取并执行所述存储器存储的与可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述处理器被促使：

响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，

基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。

在本实施例中，通过读取并执行所述存储器存储的与可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述处理器被促使：

基于生成的所述公钥创建远程证明凭证；

将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；

获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；

将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。