处理数据的方法及装置

技术领域

本公开涉及互联网技术领域以及计算机数据处理领域，并且更具体地，涉及一种处理数据的方法、一种用户终端、一种可信执行环境中的密钥管理装置、一种可信执行环境中的应用装置、一种处理数据的装置、计算机可读存储介质以及计算机程序产品。

背景技术

随着互联网技术的不断发展，人们的生活已经与互联网密不可分。由于互联网已经深入到人们生活的方方面面，网络数据传输的安全也就显得极为重要。为了保证网络数据传输的安全性，人们往往会对需要经过互联网传输的会话数据进行加密处理。然而，当前的加密数据传输系统仍需要较大的存储空间用于存储加密密钥，甚至还存在密钥泄露的风险。此外，目前仍缺乏能够有效地兼顾安全性和易用性的加密数据传输系统。因此，需要对现有的加密数据传输系统进行改进。

发明内容

为了解决上述问题，本公开提供了一种处理数据的方法、一种用户终端、一种可信执行环境中的密钥管理装置、一种可信执行环境中的应用装置、一种处理数据的装置、计算机可读存储介质以及计算机程序产品。

根据本公开实施例的一个方面，提供了一种处理数据的方法，包括：由可信执行环境中的密钥管理装置生成自签名证书，所述自签名证书用于审计或验证密钥管理逻辑；以及由用户终端对所述自签名证书进行验证，并响应于所述自签名证书通过验证，所述用户终端向所述可信执行环境中的密钥管理装置申请数据加密公钥，所述数据加密公钥用于非对称地对通信数据进行加密。

根据本公开实施例的一个方面，提供了一种用户终端，所述用户终端包括一个或多个处理器，其中所述一个或多个处理器被配置为：从可信执行环境中的密钥管理装置，接收自签名证书，所述自签名证书用于审计或验证密钥管理逻辑；对所述自签名证书进行验证，并响应于所述自签名证书通过验证，所述用户终端向所述可信执行环境中的密钥管理装置申请数据加密公钥，所述数据加密公钥用于非对称地对通信数据进行加密。

根据本公开实施例的一个方面，提供了一种可信执行环境中的密钥管理装置，所述可信执行环境中的密钥管理装置包括一个或多个处理器，其中所述一个或多个处理器被配置为：向用户终端发送自签名证书，所述自签名证书用于审计或验证密钥管理逻辑；从所述用户终端接收数据密钥请求，生成数据加密公钥和数据解密私钥；向用户终端发送所述数据加密公钥。

根据本公开实施例的一个方面，提供了一种可信执行环境中的应用装置，所述可信执行环境中的应用装置包括一个或多个处理器，其中所述一个或多个处理器被配置为：从用户终端接收通信数据，所述通信数据包括授权凭据和经数据加密密钥加密的数据；向所述可信执行环境中的密钥管理装置发送第一远程证明并从所述可信执行环境中的密钥管理装置接收第二远程证明；响应于第一远程证明和第二远程证明均通过验证，从所述可信执行环境中的密钥管理装置接收数据解密私钥。

根据本公开实施例的一个方面，提供了一种处理数据的装置，包括：一个或多个处理器；以及一个或多个存储器，其中所述存储器中存储有计算机可读代码，所述计算机可读代码在由所述一个或多个处理器运行时，使得所述一个或多个处理器执行如上述的方法。

根据本公开实施例的另一方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，所述计算机可读指令在被处理器执行时，使得所述处理器执行如本公开上述各个方面中任一项所述的方法。

根据本公开实施例的另一方面，提供了一种计算机程序产品，其包括计算机可读指令，所述计算机可读指令在被处理器执行时，使得所述处理器执行如本公开上述各个方面中任一项所述的方法。

本公开上述各个方面不仅能够规避密钥泄露风险，还能避免用户处理复杂的可信环境应用，提高了加密数据传输系统的易用性。

附图说明

通过结合附图对本公开实施例进行更详细的描述，本公开实施例的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开实施例一起用于解释本公开，并不构成对本公开的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1示出了根据本公开实施例的应用场景的示意图。

图2示出了根据本公开实施例的区块结构的示意图。

图3示出了TEE应用与用户终端共享密钥的示意图。

图4示出了TEE应用与用户终端协商密钥的示意图。

图5示出了根据本公开实施例的处理数据的方法的可选流程图。

图6示出了根据本公开实施例的处理数据的方法的可选示意图。

图7示出了根据本公开实施例的用户终端向tKMS申请数据加密公钥的可选示意图。

图8示出了根据本公开实施例的处理数据的方法的又一可选示意图。

图9示出了根据本公开实施例的电子设备的示意图。

图10示出了根据本公开实施例的示例性计算设备的架构的示意图。

图11示出了根据本公开实施例的存储介质的示意图。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

本公开的实施例涉及云计算技术。云计算(cloud computing)是一种计算模式，它将计算任务分布(例如，计算多种方案中的每种方案的用户偏好)在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

本公开提供了一种处理数据的方法、一种处理数据的装置、计算机可读存储介质以及计算机程序产品。

首先参照图1描述根据本公开实施例的处理数据的方法以及相应的装置等的应用场景。图1示出了根据本公开实施例的应用场景100的示意图。

本公开实施例涉及的系统可以是由客户端、多个节点(接入网络中的任意形式的计算设备，如服务器、用户终端)通过网络通信的形式连接形成的分布式系统。这里的服务器可以是独立的服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、定位服务以及大数据和人工智能平台等基础云计算服务的云服务器，本公开实施例对此不作具体限制。这里的多个用户终端可以是诸如台式计算机等的固定终端，诸如智能手机、平板电脑、便携式计算机、手持设备、个人数字助理、智能可穿戴设备、车载终端等具有网络功能的移动终端，或者它们的任意组合，本公开实施例对此不作具体限制。

本公开实施例提供的分布式系统100可选地能够应用于区块链系统。如图1所示的多个节点之间形成组成的点对点(P2P，Peer To Peer)网络，P2P协议是一个运行在传输控制协议(TCP，Transmission Control Protocol)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。

参见图1示出的各节点可能涉及路由功能，其用于支持节点之间的通信。各个节点还可能涉及各种应用功能。以区块链应用功能为例，各节点能够根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。

图1中的各节点的应用功能与应用业务相关联。例如，应用业务可以是钱包业务，其用于提供进行电子货币的交易的功能，包括发起交易(即，将当前交易的交易记录发送给区块链系统中的其他节点，其他节点验证成功后，作为承认交易有效的响应，将交易的记录数据存入区块链的临时区块中；当然，钱包还支持查询电子货币地址中剩余的电子货币。又例如，应用业务还可以是共享账本业务，其用于提供账目数据的存储、查询和修改等操作的功能，将对账目数据的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认账目数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的节点发送确认。又例如，应用业务还可以是智能合约业务，其用于实现计算机化的协议，可以执行某个合约的条款，通过部署在共享账本上的用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的交易，例如查询买家所购买商品的物流状态，在买家签收货物后将买家的电子货币转移到商户的地址；当然，智能合约不仅限于执行用于交易的合约，还可以执行对接收的信息进行处理的合约。

当然上述的各节点还可以涉及操作区块链的功能。区块链是包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。参见图2，图2是本公开实施例提供的区块结构(Block Structure)一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了相关的信息，用于验证其信息的有效性(防伪)和生成下一个区块。

又例如，图1所示的各节点还可以用于可信计算。也即，分布式系统100能够提供基于硬件支撑的可信执行环境，以保护计算过程安全、数据隐私和认证数据完整性、来源可靠性等。由此，分布式系统100中的各个节点都能可选地使得可信执行环境内的数据、程序逻辑在没有主动输出的情况下无法被外部环境窥探。

例如，图1所示的各节点都可能是可信计算(Trusted Computing，TC)节点。可信计算节点是包含有可信执行环境(Trusted Execution Environment，TEE)的节点设备。可信计算节点上搭载有一个或多个TEE应用，TEE应用能够与用户终端上的多媒体执行环境(Rich Execution Environment，REE)进行交互。为保证TEE资源的安全，TEE能够访问REE可以访问的资源，而除非有TEE的明确授权，否则TEE上的可信资源只允许其他可信资源访问。

目前，在一些情况下，TEE应用已经能够与用户终端共享密钥，以实现用户终端安全地访问TEE环境中的数据。例如，如图3所示，可以利用密钥管理系统(Key ManagementSystem，KMS)来对密钥进行托管。例如，用户终端可以提前向KMS申请对称密钥，然后用户终端通过KMS使用对称密钥对数据进行加密，将所得密文传输给TEE应用。TEE应用通过KMS获得会话密钥以对密文进行解密，将明文用于TEE应用的应用逻辑。

又例如，如图4所示，用户还可与TEE应用进行密钥协商。每次传输数据前，用户终端将和TEE应用执行密钥交换协议，协商出一次性的会话密钥对，然后用户终端使用会话加密密钥对会话数据进行加密，然后将所得密文传输给TEE应用，TEE应用基于会话解密密钥对密文进行解密，以还原会话数据以用于后续计算。此外，若TEE应用之间需要通信，也需要两两协商会话密钥对。

然而，图3和图4中示出的方案都无法有效地兼顾安全性和易用性。例如，在图3所示的KMS托管密钥的方案中，由于KMS管理逻辑运行在远程服务处，用户终端无法实时验证KMS的机密性和完整性。如果KMS中存在恶意程序或后门则有泄漏用户密钥的风险。此外，通常情况下，KMS管理的密钥通常是不能直接导出的。虽然这样的设计有利于提高类似于REE中的应用的安全性，但对于TEE应用来说，这限制了TEE应用使用密钥的灵活性。更进一步地，KMS需要额外的设备，增加了成本。此外，图3所示的KMS托管密钥的方案也不能适用于外包计算/多方计算。

又例如，在图4所示的实时协商密钥的方案中，每次协商过程都要求用户终端对TEE应用进行验证，使用门槛高。同时，两两协商的方案不仅通信复杂度高效率低下，还导致无法复用密钥。TEE应用必须先于密钥存在，无法在线下预先执行耗时较高的数据加密。

基于此，本公开的实施例既能规避密钥泄露风险还能减少用户终端对于TEE中的复杂信息(例如TEE度量信息)的处理。并且，经过用户终端对数据解密私钥授权后，就能将该数据解密私钥从基于TEE的KMS(以下又简称为tKMS)安全地发放给TEE应用进行使用。

例如，本公开的一些实施例使得用户终端可以向tKMS申请用于非对称加密数据的加密公钥，并授权相应的解密私钥给指定TEE应用使用。TEE应用在借助远程证明机制向tKMS证明TEE应用的环境合法性后，只需出示用户授权凭据即可获得相应的数据解密私钥用于解密密文。相较于传统的KMS，tKMS还能够以层次化方式派生数据加密密钥，节省存储空间。

又例如，本公开的一些实施例使得数据解密私钥经过严格授权后安全地流通在TEE环境之内，不泄露给其他无关方，规避由于数据解密私钥需要人为保管而导致的泄露风险。由TEE实现的KMS相比于传统KMS能够为外包计算/多方计算提供数据隐私保障。其中，外包计算/多方计算可以用于解决一组互不信任的参与方之间保护隐私的协同计算问题，其能够在实现输入的独立性、计算的正确性、去中心化的情况下，同时保证各个参与方的输入值不被泄露给参与计算的其他成员。也即，多方计算可以用于是针对无可信第三方的情况下，如何安全地计算一个约定函数的问题，同时要求每个参与主体除了计算结果外不能得到其他实体任何的输入信息。

下面参照图5至图8描述根据本公开实施例的处理数据的方法。例如，图5示出了根据本公开实施例的处理数据的方法50的可选流程图。图6示出了根据本公开实施例的处理数据的方法50的可选示意图。图7示出了根据本公开实施例的用户终端向tKMS申请数据加密公钥的可选示意图。图8示出了根据本公开实施例的处理数据的方法50的又一可选示意图。方法50可以由参考图1至图2描述的分布式系统100执行，当然本公开并不限于此。

结合图6，分布式系统100包括可信执行环境中的密钥管理装置(其在图6中被示出为tKMS)、用户终端、和可信执行环境中的应用装置(其在图6中被示出为TEE应用)。作为一个示例，方法50包括图5所示的操作S510和S520。此外方法50还可选地包括操作S530至S560。当然本公开并不以此为限。

例如，结合图5，在操作S510中，由可信执行环境中的密钥管理装置生成自签名证书，所述自签名证书用于审计或验证密钥管理逻辑。在操作S520中，由用户终端对所述自签名证书进行验证，并响应于所述自签名证书通过验证，所述用户终端向所述可信执行环境中的密钥管理装置申请数据加密公钥，所述数据加密公钥用于非对称地对通信数据进行加密。

例如，可信执行环境可由终端设备上处理器、安全存储器、可信用户接口界面(Trusted User Interface，TUI)、可信操作系统(Trusted Operating System，TOS)和可信应用(Trusted Application，TA)等可信软硬件资源组成，这些装置共同构造了一个安全的运行环境。

例如，在本公开的一些实施例中，上述的可信执行环境均能够采用非对称加密的方式生成用于识别可信执行环境的身份的公私密钥对。在芯片生产时，可信执行环境的私钥被写入芯片中。除了可信执行环境以外，没有任何节点能够获知该私钥。而可信执行环境的公钥则是公开的。任意通过该芯片对应的公钥加密后的文件，只有在该芯片中利用该私钥才能被解密。需要说明的是，各个芯片中的私钥是唯一且不可篡改的。这样，在这个与REE(例如，用户终端)相隔离的运行环境里可以更安全地存储和处理用户的个人信息，使得用户能够安心地执行电子支付等保密性要求较高的操作。

又例如，可信执行环境中的密钥管理装置tKMS是一种能够在可信执行环境中运行密钥管理逻辑的装置。密钥管理逻辑包括代理用户终端生成密钥、派发密钥、更新密钥、存储密钥等等。本公开对此不进行限制。相较于传统的仅能处理对称密钥的密钥管理装置(例如图3中的KMS)，可信执行环境中的密钥管理装置tKMS不仅能够处理非对称密钥，还能够生成自签名证书。其中，该自签名证书用于审计(例如，公开审计)和验证(例如，运行时验证)密钥管理逻辑。

在一些实施例中，所述自签名证书是tKMS的可信身份标识。传统的KMS往往不能生成可信的身份标识。即使传统的KMS也能够对自身的证书进行自签名，其往往也无法通过其它节点的验证。然而，由于操作S510中的自签名证书是在可信执行环境中生成的，其能够被任意节点审计和验证，从而保证了自签名证书的可信性。

可选地，所述自签名证书是在tKMS第一次启动时或部署tKMS时随机生成的。在生成所述自签名证书的同时，tKMS还生成所述自签名证书对应的私钥和公钥，以下将自签名证书对应的私钥称为自签名证书私钥，并将自签名证书对应的公钥称为自签名证书公钥。自签名证书私钥和自签名证书公钥用于验证所述自签名证书的合法性。

例如，在本公开的一些实施例中，自签名证书的签名信息是基于所述自签名证书私钥生成的，其能够被自签名证书公钥进行验证。其中，基于所述自签名证书私钥生成自签名证书的签名信息的过程(也叫做签名过程)也是可公开审计和实时验证的。从而，任意需要与tKMS交互的节点都能够验证tKMS提供的自签名证书的签名信息的合法性。例如，用户终端能够使用自签名证书公钥来验证该自签名证书的签名信息的合法性。

在本公开的一些实施例中，自签名证书私钥被加密封存在本地，而自签名证书公钥则被公开。其中，“加密封存”是指将基于硬件派生的密钥(非对称密钥或对称密钥)等加密数据保存到本地的行为。其中，同一硬件为度量信息相同的tKMS派生出的密钥完全相同，硬件或度量信息发生变化都会导致派生出的密钥不同。

可选地，在tKMS第一次启动时或部署tKMS时，tKMS还将随机生成一个主密钥MK，并将该主密钥MK加密封存在本地。此后，如果tKMS重启，tKMS可从加密封存的密文中还原相同主密钥MK，从而保证向外提供的服务的连续性。

在本公开的一些实施例中，可选地，所述自签名证书还包括所述可信执行环境tKMS的度量信息，并且所述度量信息包括自签名证书公钥的信息。例如，所述可信执行环境的度量信息可以被嵌入至证书拓展字段中。自签名证书公钥的信息可以嵌入至所述度量信息的自定义字段中。此外，在本公开的有一些示例中，tKMS在生成自签名证书时，基于自签名证书私钥，对上述包括自签名证书公钥的信息的度量信息进行签名，以保证自签名证书不可篡改。

在本公开的一些实施例中，自签名证书公钥的信息例如是自签名证书公钥对应的哈希值。自签名证书公钥对应的哈希值可以利用各种类型的哈希算法对自签名证书的公钥进行哈希运算得到，哈希算法包括但不限于SM3、SHA256等常用哈希算法之一。本公开并不以此为限。

可选地，所述可信执行环境的度量信息(以下又称为TEE度量信息)是用于证明tKMS与其代码逻辑、运行时硬件环境对应关系的凭据。例如，TEE度量信息可选地包括：应用代码逻辑的哈希度量、硬件对代码逻辑哈希度量的签名(签名私钥由硬件厂商内置到硬件)、硬件厂商对硬件公钥的签名等等信息。如果硬件厂商对硬件公钥的签名能够通过任意一个节点对其的验证，即可证明硬件源自合法的硬件厂商。如果硬件对密钥管理逻辑的签名能够通过任意一个节点对其的验证，那么该节点即可确定其预期的tKMS应当执行的密钥管理逻辑的确在预期硬件环境中运行，从而证明tKMS的完整性。而tKMS的安全性由硬件提供的TEE保障。在又一些示例中，度量信息还包括基于tKMS确定的数据，例如密钥交换协议的中间数据。这些中间数据例如是在tKMS与TEE应用之间、tKMS与非TEE应用之间、tKMS与用户终端之间协商依赖的公钥(例如，tKMS的证书公钥、或TEE应用的证书公钥、或用户终端的身份公钥)，这些公钥辅助计算会话密钥以用于双方之间的加密通信。

例如，图1中的任意一个节点都能对tKMS的密钥管理逻辑进行公开审计。对tKMS的密钥管理逻辑进行审计不仅能够确定密钥管理逻辑对应的软件源码或任意静态文件未被篡改，还能够确定该软件源码或任意静态文件没有留有后门或者漏洞，从而保证了tKMS的密钥管理逻辑不会泄露用户密钥。又例如，图1中的任意一个节点还可以对tKMS的密钥管理逻辑进行运行时验证(又称为实时验证)。对tKMS的密钥管理逻辑进行运行时验证能够保证密钥管理逻辑运行了预期的软件源码。有些恶意攻击者很可能会尝试攻击密钥管理逻辑以使得密钥管理逻辑不运行经审计的软件源码而是运行错误的恶意代码。通过对tKMS的密钥管理逻辑进行运行时验证，能够保证用户终端每次请求tKMS提供密钥时，密钥管理逻辑都能运行正确的代码以提供正确且安全的密钥。

例如，假设存在这样的一种攻击场景：恶意攻击者利用tKMS’去仿冒tKMS以尝试骗取图1中的任意一个节点或图6中的用户终端/TEE应用的信任。为了使得tKMS’能够成功仿冒tKMS，恶意攻击者需要使得tKMS’能够提供伪造证书，并且需要用户终端/其它节点难以区分伪造证书与tKMS的自签名证书。为此，恶意攻击者需要构造这样的伪造证书，该伪造证书包括伪造的tKMS的度量信息，并且该伪造的tKMS的度量信息中包括tKMS’的伪造证书的公钥的信息。

然而，根据上述证书的构造规则，度量信息包括tKMS的自签名证书公钥的信息。如果恶意攻击者仅将伪造证书对应的公钥设置为tKMS’的公钥，而不更改度量信息中嵌入的自签名证书公钥的信息，用户终端则能够很容易地识别出伪造证书的公钥不同于度量信息中嵌入的公钥，从而能够容易地验证出伪造证书是非法的，而不会从tKMS’申请数据加密密钥。

如果恶意攻击者将伪造证书对应的公钥设置为tKMS’的公钥并将度量信息中嵌入的tKMS的公钥信息篡改为tKMS’的公钥信息，那么恶意攻击者必须能够生成tKMS的度量信息。而硬件只会为tKMS生成和tKMS强关联的度量信息(对tKMS应用的任何改动都会导致度量信息发生变化)。强行替换度量信息嵌入的公钥信息会导致度量信息无法被正确识别为tKMS的度量信息。并且一旦度量信息的结构被破坏，保护结构完整性的签名等均无法验证通过。因此，恶意攻击者不可能基于tKMS的度量信息和tKMS’的公钥伪造出能够通过用户终端/TEE应用验证的证书，从而无法冒用tKMS的身份。

可选地，在步骤520中，在用户终端接收到tKMS传输的自签名证书后，用户终端可以从所述自签名证书的度量信息中获取所述自签名证书的公钥信息。然后用户终端可以通过验证自签名证书中的公钥信息与自签名证书的公钥是否匹配(该过程又叫做关联性验证)，即可确定该自签名证书与tKMS之间的关联性(也即确定该自签名证书是否必然是由tKMS生成的)。例如，在自签名证书中的公钥信息与自签名证书的公钥匹配的情况下，则该自签名证书通过关联性验证。在自签名证书中的公钥信息与自签名证书的公钥不匹配的情况下，则该自签名证书无法通过关联性验证，则所述自签名证书验证失败。

然后用户终端再对证书签名进行合法性验证，如果自签名证书通过了关联性验证和合法性验证两者，则所述自签名证书通过验证(也即用户终端认定所述自签名证书合法)。此外，如果用户终端确定证书签名不合法(也即，用户终端认定所述自签名证书非法)，则所述自签名证书也验证失败。

上述过程也即用户终端对tKMS的公开审计和运行时验证的过程的示例。当然，根据自签名证书的构造方式的不同，用户终端还可以通过其它的方式来验证自签名证书的合法性，本公开并不以此为限。

接着，用户终端在确定该自签名证书合法后，便能确定该自签名证书中的度量信息仅能由tKMS生成，并且该自签名证书的私钥只有tKMS持有，从而用户终端能够基于此自签名的证书与tKMS执行密钥交换协议以向tKMS申请数据加密公钥X，其用于非对称地对通信数据进行加密。在一些实施例中，该通信数据是由用户终端传输至TEE应用的。更进一步地，用户终端与tKMS之间的通信信道是安全的，第三方无法获得会话密钥，从而第三方无法获知用户终端与tKMS之间的通信数据，从而保证了数据加密公钥X不会被泄露。

例如，如图7所示，用户终端可以下述方式向tKMS申请数据加密公钥。首先，用户终端将获取一对用于用户终端的身份验证的非对称密钥对(y，Y)，以下将用于用户终端的身份验证的公钥Y称为用户身份公钥，将用于用户终端的身份验证的私钥y称为用户身份私钥。用户终端可能提前运算出用户身份公钥和用户身份私钥，用户终端也可以在与tKMS进行密钥协商之前随机生成用户身份公钥和用户身份私钥。本公开不对用户身份公钥和用户身份私钥的获取方式进行限制。

接着，用户终端将基于用户身份公钥Y和tKMS的证书公钥与tKMS进行密钥协商以确定会话密钥，从而从tKMS接收会话密钥，而tKMS将保存会话密钥。其中，会话密钥仅用于对用户终端向tKMS传递的信息进行加密，而会话密钥仅用于tKMS对来自用户终端的信息的解密。密钥协商的过程可以基于各种密钥交换协议。例如，密钥协商的过程可以基于DHE(Diffie-Hellman-Ephemeral)密钥交换协议。DHE密钥交换协议是一种让双方在完全没有对方任何预先信息的条件下通过不安全信道协商出临时会话密钥的安全协议。这个密钥可以在后续的通讯中作为对称密钥来加密会话内容。又例如，密钥交换协议还可以是ECDHE密钥交换协议。ECDHE密钥交换协议是DHE密钥交换协议基于椭圆曲线实现的变种，可以达到相同效果。

用户终端在获得会话密钥之后，将利用会话密钥对数据密钥请求进行加密。所述数据密钥请求包括用户身份公钥Y。tKMS在接收到用会话密钥对数据密钥请求加密后的密文后，利用会话密钥对该密文进行解密，以获取用户身份公钥Y。接着，tKMS将利用步骤510中生成的主密钥MK和用户身份公钥Y确定数据解密私钥z。例如，tKMS将主密钥MK和用户身份公钥Y的哈希值拼接成一个字符串“MK|Y的哈希值”(其中，“|”表示字符串的拼接)，然后将字符串“MK|Y的哈希值”的哈希值确定为数据解密私钥z。

在本公开的一些实施例中，所述数据密钥请求可选地还包括授权次数T。tKMS在接收到用会话密钥对数据密钥请求加密后的密文后，利用会话密钥对该密文进行解密，以获取用户身份公钥Y和授权次数上限T。tKMS将以Y的哈希值为键设置其可授权次数为T。响应于Y对应的T已存在，则更新Y的授权次数。如果T小于等于0则表示用户终端希望注销其的密钥授权许可。例如，假设数据密钥请求中包括的授权次数上限T为5，而tKMS在密钥协商过程中确定用户身份公钥Y对应的授权次数上限为2，则tKMS将根据该数据密钥请求，将2修改为5。假设数据密钥请求中包括的授权次数上限T为-1，而tKMS在密钥协商过程中确定用户身份公钥Y对应的授权次数上限为2，则tKMS将根据该数据密钥请求，将授权次数上限T从2修改为-1，直接注销该用户身份公钥Y或者直接删除该用户身份公钥Y。此时，如果TEE应用向tKMS申请获取用于解密用户终端的密文的数据解密私钥时，tKMS将拒绝提供。

在本公开的一些实施例中，所述数据密钥请求可选地还包括用户终端生成的随机字符串nonce。tKMS在接收到用会话密钥对数据密钥请求加密后的密文后，利用会话密钥对该密文进行解密，以获取用户身份公钥Y、授权次数上限T和随机字符串nonce。基于随机字符串nonce，tKMS可以确定该数据密钥请求是用户终端提供的一个新的数据密钥请求，而非恶意攻击者在重放攻击中提供的数据密钥请求。

在tKMS获得数据解密私钥z之后，tKMS将基于数据解密私钥z，确定数据加密公钥Z，并将该数据加密公钥Z提供给用户终端。由此，用户终端成功申请到了数据加密公钥Z。

返回参考图6，用户终端将利用数据加密公钥Z与TEE应用进行通信。例如，用户终端使用数据加密公钥Z对通信数据进行加密，然后将加密后的通信数据发送给TEE应用。上述通信数据中还包括用户终端对TEE应用使用数据解密私钥的授权。TEE应用基于该授权在从tKMS中获得数据解密私钥之后，将利用数据解密私钥对通信数据进行解密，从而完成通信数据相关的计算。

接下来参考图8进一步描述TEE应用向tKMS申请数据解密私钥的示例过程。可选地，方法50还可选地包括操作S530至操作S560。本公开并不以此为限。

在操作S530中，由用户终端向可信执行环境中的应用装置发送经由数据加密公钥加密的通信数据。可选地，如上所述，TEE应用将从用户终端中接收通信数据，该通信数据用数据加密公钥加密，并且该通信数据包括授权凭据和经数据加密密钥X加密的数据。在图8中，经数据加密密钥X加密的数据被示出为密文。又例如，授权凭据是TEE应用向tKMS证明其与用户终端之间的通信的合法性的凭证，其指示TEE应用使用数据解密私钥是合法的。

作为一个示例，授权凭据包括：用户身份公钥Y、凭据信息M和利用用户身份私钥y对凭据信息M的签名Sig。凭据信息M包括：可信执行环境中的应用装置的度量信息、待由TEE应用计算的数据的哈希值、以及用户终端自定义的数据。其中，通过在凭据信息M包括可信执行环境中的应用装置(TEE应用)的度量信息，能够使得只有与该度量信息一一对应的TEE应用才有权获得数据解密私钥。授权凭据中还可以包括其它信息，本公开对此不进行限制。

接着在操作S540中，由所述可信执行环境中的应用装置向所述可信执行环境中的密钥管理装置发送第一远程证明，并且所述可信执行环境中的密钥管理装置向所述可信执行环境中的应用装置发送第二远程证明。

例如，所述可信执行环境中的应用装置将向可信执行环境中的密钥管理装置提供第一远程证明。例如，第一远程证明使得TEE应用能够向第三方(例如，tKMS)证明自身所运行环境硬件合法性。如果第三方向TEE应用发起挑战，TEE应用可以发送包含自身代码逻辑的哈希度量在内的信息集合，并对其签名，再返回给第三方进行身份验证。如果验证成功，则远程证明完成。类似地，所述可信执行环境中的密钥管理装置也将向所述可信执行环境中的应用装置提供第二远程证明。TEE应用与tKMS互相提供远程证明的过程在图8中被描述为双向远程证明过程。经过双向远程证明过程之后，TEE应用与tKMS均确认了对方的合法性。

在本公开的一些实施例中，第一远程证明还包括授权凭据。此时，tKMS除了验证承载TEE应用的度量信息(例如，以上的包含自身代码逻辑的哈希度量)之外，还可验证用户身份公钥Y对应授权次数T。例如，tKMS以用户身份公钥Y为键，查找其对应的授权次数T。响应于度量信息合法并且授权次数T大于零，则tKMS则可确认授权凭据中的用户身份公钥Y仍是有效的。此时，tKMS将把授权次数T减一，并确定TEE应用有权使用数据解密私钥z。响应于授权次数T小于等于零，tKMS则可确认授权凭据中的用户身份公钥Y无效，需要用户终端重新申请数据加密公钥并更新授权次数T。

在本公开的一些实施例中，tKMS除了验证上述的TEE应用的度量信息、用户身份公钥Y对应的授权次数T以外，还利用用户身份公钥Y来验证授权凭据中的签名Sig的合法性。响应于度量信息合法、授权次数T大于零并且签名Sig的合法，tKMS将把授权次数T减一，并确定TEE应用有权使用数据解密私钥z。此外，tKMS均认定TEE应用无权使用数据解密私钥z。

接下来，在操作S550中，响应于第一远程证明和第二远程证明均通过验证，由所述可信执行环境中的密钥管理装置向所述可信执行环境中的应用装置发送数据解密私钥。例如，所述数据解密私钥用于解密所述通信数据。例如，该数据解密私钥z用于解密由用户装置向TEE应用发送的密文。

值得注意的是，在操作S540和S550中，tKMS和TEE应用之间的通信信息均可以通过安全信道发送和接收的，从而保证了tKMS和TEE应用之间的通信的安全性。在安全信道中通信的所有数据都是经过加密的。

在操作S560中，由所述可信执行环境中的应用装置，基于数据解密私钥，对所述通信数据解密。

作为一个示例，方法50可以应用于对患者的电子医疗记录(Electronic HealthRecord,EHR)进行可信计算，其计算结果例如是患者的病情信息。由于医疗行业的快速发展，医疗健康数据快速增加，许多医疗机构采用了电子医疗记录来记录病人的医疗数据。由于EHR数据复杂，其包括造影产生的图片、医生问诊的文字记录、处方信息等等。要从EHR中预测处患者的病情是非常复杂的，且其涉及到大量运算。通常情况下，患者的用户终端的算力往往是有限的。为此，患者需要一个远程的可信应用来辅助其病情的预测。

那么此时，患者的用户终端将向已经部署完成的tKMS申请数据加密公钥Z，然后利用该数据加密公钥Z对用户私密的电子医疗记录(其包括造影产生的图片、医生问诊的文字记录、处方信息等等)进行加密以形成密文。

患者的用户终端将密文和授权凭据发向TEE应用。TEE应用利用该授权凭据向tKMS申请数据解密私钥z的使用权。在TEE应用成功对密文进行解密之后，将基于神经网络对该电子医疗记录进行分析，以确定患者的病情信息，从而保证了患者的病情信息不会被泄露。

例如，TEE应用可以使用神经网络模型来从用户在通信数据中提供的EHR数据中通过机器学习来生成健康评分。随着机器学习的发展，可以使用各种神经网络模型来完成上述的机器学习的任务，例如可以采用深度神经网络(DNN)模型、因子分解机(FM)模型等等。这些神经网络模型可以被实现为无环图，其中神经元布置在不同的层中。通常，神经网络模型包括输入层和输出层，输入层和输出层通过至少一个隐藏层分开。隐藏层将由输入层接收到的输入变换为对在输出层中生成输出有用的表示。神经网络节点经由边全连接至相邻层中的节点，并且每个层内的节点之间不存在边。在神经网络的输入层的节点处接收的数据经由隐藏层、激活层、池化层、卷积层等中的任意一项被传播至输出层的节点。神经网络模型的输入输出可以采用各种形式，本公开对此不作限制。在TEE应用中处理医疗健康数据(例如，EHR数据)这样的高度隐私且具有价值的数据，有助于保护用户终端的隐私。

本公开的上述实施例将可信执行环境与密钥管理逻辑相结合，能够使得密钥的生成过程可审计可验证，并且还保证了仅有用户授权的TEE应用才能使用密钥，相比已有方案，降低密钥泄露的风险的同时也减轻用户的使用负担。

相较于传统的方案，本公开的各个实施例至少还可选地具有以下的各项优势中的至少一项。

①本公开的各项实施例利用TEE加固密钥管理装置以生成tKMS，确保密钥管理逻辑可公开审计和运行时可验证，无需依赖除硬件产商外的第三方。tKMS能够安全地托管数据解密私钥。tKMS的源代码均是经第三方(例如用户终端)审计后才上线运行的，并且其行状态不泄露任何密钥信息。

②本公开的各项实施例不存在泄露数据解密私钥的风险。用户终端仅能申请到数据加密公钥来加密数据，无法获取tKMS内的数据解密私钥。由此，避免了在用户终端处泄露的数据解密私钥的问题。

③本公开的各项实施例的密钥授权流程简洁、高效。TEE远程证明流程只需低频地(一次或几次)发生在用户终端和tKMS之间，使得用户终端无需重复验证执行计算的TEE应用，简化用户使用流程。

④本公开的各项实施例的数据解密私钥的流转过程安全可控。tKMS严格和TEE应用强制实施双向远程证明机制，严格互相验证彼此TEE合法性，且tKMS确保TEE应用的授权合法后才会下发数据解密私钥，确保数据解密私钥不会流转到无关TEE应用处或其它设备处，保证了数据解密私钥安全性。

⑤本公开的各项实施例的tKMS仅需要较小的密钥存储空间。用户终端使用的数据加密公钥和数据解密私钥均由tKMS基于层次化的密钥派生算法(也即，均使用主密钥MK实时派生)生成。tKMS无需存储派生所得子密钥。

⑥本公开的各项实施例的密钥使用次数可控。用户终端可设置或更新数据解密私钥可被授权使用的次数上限，使得使用次数超过上限时被冻结或上限低于使用次数时解冻。

根据本公开的又一方面，还提供了一种用户终端，所述用户终端包括一个或多个处理器，其中所述一个或多个处理器被配置为：从可信执行环境中的密钥管理装置，接收自签名证书，所述自签名证书用于审计或验证密钥管理逻辑；对所述自签名证书进行验证，并响应于所述自签名证书通过验证，所述用户终端向所述可信执行环境中的密钥管理装置申请数据加密公钥，所述数据加密公钥用于非对称地对通信数据进行加密。可选地，所述用户终端的一个或多个处理器还被配置为：向可信执行环境中的应用装置发送通信数据，所述通信数据包括授权凭据和经数据加密密钥加密的数据。本公开已经参考图5至图8详细的描述了用户终端的各个操作，在这里就不再赘述。

根据本公开的又一方面，还提供了一种可信执行环境中的密钥管理装置，所述可信执行环境中的密钥管理装置包括一个或多个处理器，其中所述一个或多个处理器被配置为：向用户终端发送自签名证书，所述自签名证书用于审计或验证密钥管理逻辑；从所述用户终端接收数据密钥请求，生成数据加密公钥和数据解密私钥；向用户终端发送所述数据加密公钥。可选地，所述可信执行环境中的密钥管理装置的处理器还被配置为：从所述可信执行环境中的应用装置接收第一远程证明并向所述可信执行环境中的应用装置发送第二远程证明，响应于第一远程证明和第二远程证明均通过验证，向所述可信执行环境中的应用装置发送数据解密私钥。本公开已经参考图5至图8详细的描述了可信执行环境中的密钥管理装置的各个操作，在这里就不再赘述。

根据本公开的又一方面，还提供了一种可信执行环境中的应用装置，所述可信执行环境中的应用装置包括一个或多个处理器，其中所述一个或多个处理器被配置为：从用户终端接收通信数据，所述通信数据包括授权凭据和经数据加密密钥加密的数据；向所述可信执行环境中的密钥管理装置发送第一远程证明并从所述可信执行环境中的密钥管理装置接收第二远程证明；响应于第一远程证明和第二远程证明均通过验证，从所述可信执行环境中的密钥管理装置接收数据解密私钥。可选地，所述可信执行环境中的应用装置的处理器还被配置为：基于数据解密私钥，对所述通信数据解密。本公开已经参考图5至图8详细的描述了可信执行环境中的应用装置的各个操作，在这里就不再赘述。

根据本公开的又一方面，还提供了一种处理数据的装置，用于实施根据本公开实施例的方法。图9示出了根据本公开实施例的电子设备2000的示意图。

如图9所示，所述电子设备2000可以包括一个或多个处理器2010，和一个或多个存储器2020。其中，所述存储器2020中存储有计算机可读代码，所述计算机可读代码当由所述一个或多个处理器2010运行时，可以执行如上所述的方法。

本公开实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。上述处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本公开实施例中的公开的各方法、操作及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，可以是X86架构或ARM架构的。

一般而言，本公开的各种示例实施例可以在硬件或专用电路、软件、固件、逻辑，或其任何组合中实施。某些方面可以在硬件中实施，而其他方面可以在可以由控制器、微处理器或其他计算设备执行的固件或软件中实施。当本公开实施例的各方面被图示或描述为框图、流程图或使用某些其他图形表示时，将理解此处描述的方框、装置、系统、技术或方法可以作为非限制性的示例在硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备，或其某些组合中实施。

例如，根据本公开实施例的方法或装置也可以借助于图10所示的计算设备3000的架构来实现。如图10所示，计算设备3000可以包括总线3010、一个或多个CPU 3020、只读存储器(ROM)3030、随机存取存储器(RAM)3040、连接到网络的通信端口3050、输入/输出组件3060、硬盘3070等。计算设备3000中的存储设备，例如ROM 3030或硬盘3070可以存储本公开提供的方法的处理和/或通信使用的各种数据或文件以及CPU所执行的程序指令。计算设备3000还可以包括用户界面3080。当然，图10所示的架构只是示例性的，在实现不同的设备时，根据实际需要，可以省略图10示出的计算设备中的一个或多个组件。

根据本公开的又一方面，还提供了一种计算机可读存储介质。图11示出了根据本公开的存储介质4000的示意图。

如图11所示，所述计算机存储介质4020上存储有计算机可读指令4010。当所述计算机可读指令4010由处理器运行时，可以执行参照以上附图描述的根据本公开实施例的方法。本公开实施例中的计算机可读存储介质可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)或闪存。易失性存储器可以是随机存取存储器(RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(SDRAM)、双倍数据速率同步动态随机存取存储器(DDRSDRAM)、增强型同步动态随机存取存储器(ESDRAM)、同步连接动态随机存取存储器(SLDRAM)和直接内存总线随机存取存储器(DR RAM)。应注意，本文描述的方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。应注意，本文描述的方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本公开实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行根据本公开实施例的方法。

需要说明的是，附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

一般而言，本公开的各种示例实施例可以在硬件或专用电路、软件、固件、逻辑，或其任何组合中实施。某些方面可以在硬件中实施，而其他方面可以在可以由控制器、微处理器或其他计算设备执行的固件或软件中实施。当本公开实施例的各方面被图示或描述为框图、流程图或使用某些其他图形表示时，将理解此处描述的方框、装置、系统、技术或方法可以作为非限制性的示例在硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备，或其某些组合中实施。

在上面详细描述的本公开的示例实施例仅仅是说明性的，而不是限制性的。本领域技术人员应该理解，在不脱离本公开的原理和精神的情况下，可对这些实施例或其特征进行各种修改和组合，这样的修改应落入本公开的范围内。