基于去中心化信任的公有云下TEE状态连续性保护方法

基于去中心化信任的公有云下tee状态连续性保护方法
技术领域
1.本发明涉及计算机技术领域，尤其涉及的是一种基于去中心化信任的公有云下tee状态连续性保护方法、系统、智能终端及计算机可读存储介质。


背景技术：

2.随着科技不断发展，越来越多的厂商选择将业务部署到公有云上，在带来便利的同时，隐私保护和数据安全问题也日益严峻，由于操作系统的复杂性以及安全漏洞、安全机制容易被绕过等问题，把用户指纹、证书等机密数据和普通应用数据保存在公有云上无法保证其机密性、完整性和可用性。为此，业界提出了可信执行环境（trusted execution environment，tee）的设计，例如亚马逊云，谷歌云，阿里巴巴云平台使用tee技术为用户提供机密计算服务，但tee保护的应用程序仍然会受到回滚攻击或者分叉攻击，攻击者通过这些攻击可以将tee的状态回滚到过时的版本或被分叉成多个版本，导致tee的状态连续性被破坏。
3.现有技术中，通常利用硬件可信计数器提供一个安全容器，远程用户将代码和数据上载到安全容器中，在对容器执行计算时，安全容器用来保护数据的机密性和完整性，但硬件可信计数器的状态更新和读取的速度慢，不能满足云环境中对更新状态的要求。
4.因此，现有技术还有待改进和发展。


技术实现要素：

5.本发明的主要目的在于提供一种基于去中心化信任的公有云下tee状态连续性保护方法，旨在解决现有技术中硬件可信计数器的状态更新和读取的速度慢，不能满足云环境中对更新状态的要求的问题。
6.为了实现上述目的，本发明第一方面提供一种基于去中心化信任的公有云下tee状态连续性保护方法，所述基于去中心化信任的公有云下tee状态连续性保护方法包括：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取存储在所述状态服务实例中的最新状态；当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
7.可选的，所述基于去中心化信任的公有云下tee状态连续性保护方法还包括：通过所述区块链的第一接口将所述状态服务实例的身份标识号码和公钥写到所述区块链上，并记录初始化信息；通过所述区块链的第二接口根据所述状态服务实例的身份标识号码和公钥在所述区块链上查询初始化信息；通过所述区块链的第三接口在所述应用程序实例更新状态摘要时，向所述状态服务实例请求更新是否合法；通过所述区块链的第四接口获取所述应用程序实例的状态摘要。
8.可选的，所述基于区块链对所述状态服务实例进行初始化处理，具体包括：将任意一个所述状态服务实例设置为领导者，通过远程证明相互验证所述领导者
和其他状态服务实例的身份，并建立所述领导者与其他状态服务实例的安全通信信道；控制所述领导者和其他状态服务实例生成非对称密钥对，并将所述状态服务实例的公钥发送给所述领导者，所述领导者将接收到的公钥列表分发给其他状态服务实例；控制每个所述状态服务实例向所述区块链发送读请求，所述读请求包括所述状态服务实例的唯一标识符；控制每个所述状态服务实例向所述区块链发送写请求，当收到来自所述区块链的确认字符时，控制每个所述状态服务实例创建本地内存，所述本地内存包括其他状态服务实例状态条目的状态服务实例状态表和空的应用程序实例状态表；控制本地状态服务实例将所述公钥列表放置到所述本地状态服务实例的本地内存以生成状态服务实例配置表，并控制所述本地状态服务实例通过运行经过验证的密钥协议与其他状态服务实例建立成对会话密钥；密封并存储所述本地状态服务实例的密钥对、所述状态服务实例配置表和所述应用程序实例状态表。
9.可选的，所述基于加密传输和会话密钥更新所述应用程序实例的状态请求，具体包括：当所述应用程序实例接收到用户请求时，密封并存储所述应用程序实例的状态快照到磁盘上，并更新所述应用程序实例的状态摘要，向所述本地状态服务实例发送状态更新请求；当所述本地状态服务实例接收到状态更新请求时，存储所述状态更新请求到请求队列；当处理所述状态更新请求时，控制所述本地状态服务实例向所述本地状态服务实例和其他状态服务实例发送所述状态更新请求；当所述本地状态服务实例和其他状态服务实例接收到所述状态更新请求时，更新所述本地状态服务实例和其他状态服务实例状态内存中所述本地状态服务实例的状态摘要并发送回复消息；当所述本地状态服务实例收到超过f 1个所述回复消息时，所述本地状态服务实例向其他状态服务实例发送决定消息，其中，f为共识节点容错数；当其他状态服务实例收到所述决定消息后，检查其他状态服务实例是否已回复所述准备消息，若是，则控制所述状态服务实例发回包含状态摘要的确认字符；当所述本地状态服务实例收到超过f 1个所述确认字符时，控制所述本地状态服务实例更新所述应用程序实例的状态摘要并向所述应用程序实例回复包含状态摘要的确认字符；当所述应用程序实例收到所述确认字符时，将其状态更新为最新状态并发布相关输出。
10.可选的，所述控制所述应用程序实例读取所述状态服务实例的最新状态，具体包括：控制所述应用程序实例调用函数向所述本地状态服务实例发送状态读取请求；当所述本地状态服务实例收到所述状态读取请求时，检索全部所述状态服务实例的最新状态；
检查每个所述状态服务实例的状态服务实例状态表，并将存储的状态摘要发回给所述本地状态服务实例；当收到f 1个所述状态摘要时，选择索引最大的状态摘要作为所述本地状态服务实例的状态摘要。
11.可选的，所述当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态，具体包括：控制重启后的所述状态服务实例与其他状态服务实例建立新的会话密钥；控制重启后的所述状态服务实例获取所述状态服务实例和其他状态服务实例的状态摘要；选择索引最大的状态摘要作为重启后的所述状态服务实例的状态摘要；控制所述状态服务实例从操作系统获取密封的状态摘要，将所述状态摘要与从其他状态服务实例获取的状态摘要进行匹配，若匹配，则控制所述状态服务实例恢复所述状态服务实例的状态摘要。
12.可选的，所述当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态，具体包括：控制重启后的所述应用程序实例向所述本地状态服务实例请求最新状态摘要；控制所述应用程序实例获取所述操作系统的密封状态数据，将所述密封状态数据与所述最新状态摘要进行匹配，若匹配成功，则更新重启后所述应用程序实例的状态摘要并发布输出。
13.本发明第二方面提供一种基于去中心化信任的公有云下tee状态连续性保护系统，其特征在于，所述基于去中心化信任的公有云下tee状态连续性保护系统包括：初始化模块，用于基于区块链对状态服务实例进行初始化处理；状态更新模块，用于基于加密传输和会话密钥更新应用程序实例的状态请求；状态读取模块，用于控制所述应用程序实例读取所述状态服务实例的最新状态；重启模块，用于当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；还用于当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
14.本发明第三方面提供一种智能终端，所述智能终端包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的基于去中心化信任的公有云下tee状态连续性保护程序，所述基于去中心化信任的公有云下tee状态连续性保护程序被所述处理器执行时实现如上任意一项所述基于去中心化信任的公有云下tee状态连续性保护方法的步骤。
15.本发明第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有基于去中心化信任的公有云下tee状态连续性保护程序，所述基于去中心化信任的公有云下tee状态连续性保护程序被处理器执行时实现如上任意一项所述基于去中心化信任的公有云下tee状态连续性保护方法的步骤。
16.由上可见，本发明实施例提供的一种基于去中心化信任的公有云下tee状态连续性保护方法，所述基于去中心化信任的公有云下tee状态连续性保护方法包括：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取所述状态服务实例的最新状态；当所述状态服务实例发生
重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。与现有技术相比，本发明使用区块链消除了对中心化可信实体的依赖，且只依赖区块链进行初始化，提高了状态更新和读取的速度。
附图说明
17.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
18.图1是本本发明实施例提供一种基于去中心化信任的公有云下tee状态连续性保护方法的流程示意图；图2是本发明实施例提供的步骤s10的流程示意图；图3是本发明实施例提供的系统初始化协议的交互示意图；图4是本发明实施例提供的本地状态服务实例的内存布局示意图；图5是本发明实施例提供的步骤s20的流程示意图；图6是本发明实施例提供的状态更新协议的交互示意图；图7是本发明实施例提供的步骤s30的流程示意图；图8是本发明实施例提供的状态读取协议的交互示意图；图9是本发明实施例提供的基于去中心化信任的公有云下tee状态连续性保护系统的结构示意图；图10是本发明实施例提供的基于去中心化信任的公有云下tee状态连续性保护系统的架构示意图；图11是本发明实施例提供的智能终端的内部结构原理框图。
具体实施方式
19.以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况下，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。
20.应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
21.还应当理解，在本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
22.还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
23.下面结合本发明实施例的附图，对本发明实施例中的技术方案进行清楚、完整地
描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
24.在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其它不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。
25.随着科技不断发展，越来越多的厂商选择将业务部署到公有云上，例如英特尔软件保护扩展（software guard extension，sgx)能够使应用程序直接计算，不会泄露机密数据。例如，英特尔sgx为受保护的计算提供安全的隔离环境飞地（enclave），并将代码和数据存储在飞地（enclave）中，enclave是一个被保护的内容容器，用于存放应用程序敏感数据和代码；现有技术中通常通过tee为用户提供机密计算服务，旨在增强客户外包数据或代码的安全和隐私性。但tee中的状态应用程序依赖于不受信任的操作系统来存储状态，因此会遭受回滚或分叉攻击，它们的状态可能回滚到正确但已经过时的版本或被分叉成多个版本，导致状态连续性造成破坏，另外，当系统发生重启、断电或崩溃时，受保护模块应在状态连续性中断之前恢复到相同的状态。
26.状态连续性一旦违规将会产生严重后果，例如支付、信用系统、可信存储、智能合约等都会受到影响，例如，在tee中实现的支付系统中，状态连续性一旦违规，攻击者可以通过还原其账户余额的状态在多个支付中花费相同的硬币（即双花攻击）。
27.针对上述问题现有技术中有基于硬件的解决方案，例如，使用定时计数器做状态更新，不但只有有限次的写操作，且状态更新和读取的速度较慢，不能满足云环境中对更新状态的要求。基于软件的解决方案，例如，将可信计数器装载到单个可信服务器或分布式集合服务器，则依赖于可信的管理员做系统初始化，使得这类方案仍然存在依赖中心化信任的问题。
28.为了解决现有技术中的问题，本发明提供一种基于去中心化信任的公有云下tee状态连续性保护方法，该方法依赖于区块链（即去中心化信任）和基于tee的分布式系统，能够为云上用户的受保护tee应用实例提供高性能的状态连续性保护，例如能够支持应用在云tee环境下无限且快速的状态更新。
29.示例性方法如图1所示，本发明实施例提供一种基于去中心化信任的公有云下tee状态连续性保护方法的流程示意图，具体的，所述基于去中心化信任的公有云下tee状态连续性保护方法包括：步骤s10：基于区块链对状态服务实例进行初始化处理；步骤s20：基于加密传输和会话密钥更新应用程序实例的状态请求；步骤s30：控制所述应用程序实例读取自身存储在所述状态服务实例中的最新状态；步骤s40：当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
30.本实施例中，仅在初始化处理中使用区块链，既奠定了去中心化的信任，消除了对
中央可信实体的依赖，同时尽可能减少与区块链的互动，使得系统可以减少高昂的区块链交互开销，降低成本。
31.需要说明的是，本实施例可以应用在由云服务商管理可信平台上，例如，支持英特尔sgx的平台，其中，每个支持sgx的可信平台运行多个飞地（enclave）实例，具体的，所述飞地实例可以分为以下两种类型：应用程序实例(application enclave，ae)，ae是由独立软件供应商创建和上传的应用程序，用于处理客户的请求并返回相应的输出。
32.状态服务实例(state enclave，se)，se是为ae提供状态连续性服务的enclave实例。每个ae都可以链接到同一平台上的本地se（即目标se），并根据所述方法保护其状态连续性。
33.本实施例中，所述状态服务实例通过区块链接口与所述区块链进行交互，所述区块链使用拜占庭容错共识作为骨干协议，进一步实现了键值存储，使用户能够通过身份标识号码（identity document，id）识别将元组〈key，blob〉写入区块链，其中blob是任意与键映射的字符串，客户的身份id既可以是账本标识符，也可以是数字的公钥签名方案，只有密钥所有者有权更新关联值，而任何一方都可以使用密钥读取关联的值，密钥的创建者可以加密关联的值以保护数据隐私。
34.本实施例中，通过所述区块链的第一接口将所述状态服务实例的身份标识号码和公钥写到所述区块链上，并记录初始化信息；通过所述区块链的第二接口根据所述状态服务实例的身份标识号码和公钥在所述区块链上查询初始化信息；通过所述区块链的第三接口在所述应用程序实例更新状态摘要时，向所述状态服务实例请求更新是否合法；通过所述区块链的第四接口获取所述应用程序实例的状态摘要。
35.具体的，所述第一接口为blockchain.write(id，〈key，blob〉)：用于状态服务实例把请求记录在区块链。id是区块链的标识，key和blob是一对键值存储。如果写入成功，就会返回一个的σ。客户端可以运行签名算法进行验证。
36.所述第二接口为blockchain.read(id，key)
→
(blob，σ)：读取算法返回与key和验证器σ关联的blob。状态服务实例通过σ可以检查返回值的完整性。
37.所述第三接口为writestate(value)：用于在应用程序实例更新自身状态时，向状态服务实例请求更新是否合法，如果合法，返回一个确认字符以确认应用程序实例。
38.所述第四接口为readstate()
→
value：用于获取所述应用程序实例的状态摘要。需要注意的是，若应用程序实例没有之前写入任何值，则返回一个空值。
39.通过以上接口，本实施例中应用程序实例可以实行先记录后执行，当应用程序实例更新其状态时，首先密封并存储一个状态快照在磁盘上，然后调用函数writestate()来存储关联的状态摘要，一旦应用程序实例收到确认字符，就可以更新其状态并发布输出。
40.当应用程序实例需要验证重新启动后操作系统提供的数据的新鲜度时，调用函数readstate()获取其最新的状态摘要，检查状态摘要是否与未密封的状态快照数据匹配。本发明中，每个应用程序实例都与一个本地状态服务实例链接，本地状态服务实例提供多个接口提高证明速度和状态管理灵活性。
41.需要说明的是，本实施例的目的是实现一个初始化协议，其中，所有的状态服务实例自主完成配置，不涉及任何受信任的管理员，需要注意的是，在初始化的过程中应该确保
只有一组合法的状态服务实例具有已知的在支持sgx的可信平台上运行的身份。如果没有此保证，应用程序实例可以链接到多个组，且每个组可以存储不同的状态，将导致违反状态连续性。
42.由于缺乏可信性，在初始化过程中存在两个挑战：第一、所有状态服务实例必须以分布式方式构建pki方式，这通常会导致较高的消息复杂性。第二、对保证只有一个初始化组，一个集中式系统通常使用受信任的管理员来提供密钥配置。
43.为了应对第一个挑战，本实施例中采用领导者模式进行初始化，将任意一个所述状态服务实例设置为领导者，领导者可以由云服务商委派，且领导者选择不影响安全性。首先，领导者通过远程证明相互验证其他所述状态服务实例，并与其他所述状态服务实例建立通信通道，互相证明彼此的身份后建立信任链条，然后，领导者可以收集和分发其他状态服务实例的公钥。
44.为了应对第二个挑战，本实施例依赖于与区块链的交互，在初始化期间，一个状态服务实例必须在账本上发布记录〈uid，blob〉，其中uid是平台上飞地（enclave）程序唯一的标识符，且blob可以是配置信息；当另一个状态服务实例在同一个平台开始初始化，它也会生成相同的uid，在区块链中找到之前的记录，然后中止初始化。因此，本实施例中在同一个平台不会出现分叉状态服务实例。整个初始化是自主完成的不涉及任何受信任的管理员。
45.本实施例中，如图2所示，图2是本发明实施例提供的基于区块链对所述状态服务实例进行初始化处理的流程示意图，所述步骤s10具体包括：步骤s101：将任意一个所述状态服务实例设置为领导者，通过远程证明相互验证所述领导者和其他状态服务实例的身份，并建立所述领导者与其他状态服务实例的安全通信通道；步骤s102：控制所述领导者和其他状态服务实例生成非对称密钥对，并将所述状态服务实例的公钥发送给所述领导者，所述领导者将接收到的公钥列表分发给其他状态服务实例；步骤s103：控制每个所述状态服务实例向所述区块链发送读请求，所述读请求包括所述状态服务实例的唯一标识符；在同一可信执行环境平台上的多个应用实例具有相同的标识符；步骤s104：控制每个所述状态服务实例向所述区块链发送写请求，当收到来自所述区块链的确认字符时，控制每个所述状态服务实例创建本地内存，所述本地内存包括其他状态服务实例状态条目的状态服务实例状态表和空的应用程序实例状态表；步骤s105：控制本地状态服务实例将所述公钥列表放置到所述本地状态服务实例的本地内存以生成状态服务实例配置表，并控制所述本地状态服务实例通过运行经过验证的密钥协议与其他状态服务实例建立成对会话密钥；步骤s106：密封并存储所述本地状态服务实例的密钥对、所述状态服务实例配置表和所述应用程序实例状态表。
46.需要说明的是，所述步骤s101至步骤s104为初始化协议架构的方法，具体的，如图3所示，图3是本发明实施例提供的系统初始化协议的交互示意图，通过步骤s101建立安全的沟通渠道。领导者使用远程证明相互证明每个其他状态服务实例，同时与所有其他状态服务实例建立安全的通信通道。需要注意的是，在创建时，每个状态服务实例（包括领导者）
都需要计算它的飞地（enclave）身份，并比较其与其他人的身份，一起验证被证明的飞地（enclave）是否是状态服务实例。领导者使用远程证明来相互验证其他每个状态服务实例，同时与这些状态服务实例建立安全的通信通道，在创建时，每个状态服务实例（包括领导者）都会计算其enclave标识（即mrenclave），并将其标识与其他enclave的身份进行比较，以验证已证明的enclave是否为状态服务实例。
47.通过步骤s102进行身份建立，所有状态服务实例（包括领导者）生成一个非对称密钥对（pk，sk），并将它们的公钥发送给领导者，领导者收到公钥后分发收到的公钥列表（由表示）到其他状态服务实例，以便他们可以相互验证。
48.通过步骤s103进行第一次初始化检查，每个状态服务实例发送一个读请求到第二接口blockchain.read(id，uid)的分类帐，其中id为状态服务实例的账本标识符（由它的pk生成），而uid是状态服务实例在启用sgx的可信平台上的唯一标识符。当另一个状态服务实例在同一个平台开始初始化，它也会生成相同的uid，状态服务实例向区块链发送读取请求，区块链根据请求来返回blob，如果blob为空，说明该状态服务实例没有被初始化，是第一次加入群组。如果返回的blob不为空，说明已经有另一个状态服务实例初始化，则状态服务实例将中止初始化。
49.通过步骤s104记录初始化，状态服务实例通过第一接口blockchain.write(id，)发送写请求，当收到一个来自区块链的确认字符（ack）时，状态服务实例创建一个包含其他状态服务实例的状态条目的状态服务实例状态表和一个空的应用程序实例状态表，状态服务实例将公钥列表pksei放到状态服务实例配置表并建立成对会话密钥keysei与所有其他状态服务实例通过运行经过身份验证的密钥协议，如图4所示，图4是本发明实施例提供的本地状态服务实例的内存布局示意图，其中的数据灰色矩形被密封用于状态快照，状态服务实例密封并存储其密钥对、状态服务实例配置表和应用程序实例状态表，最终状态服务实例完成初始化并服务应用程序实例的请求。
50.需要说明的是，步骤s103中的标识符是enclave身份标识，使其他人能够验证身份报价是由同一个平台发出。状态服务实例应在步骤s104执行期间保持活动状态。因为无法区分正常崩溃是否来自创建分叉组的恶意行为，如果状态服务实例在收到blob之前崩溃，则无法初始化。然而，因为初始化过程只会发生一次，本地状态服务实例的身份可以硬编码到应用程序实例实现或由独立软件开发商提供。应用程序实例可以与本地状态服务实例运行经过身份验证的密钥建立协议，并通过该协议共享密钥k；状态服务实例为应用程序实例创建一个状态条目，包括唯一的身份应用程序实例（即使用应用程序实例代码的哈希）、共享密钥和一个空的状态摘要，可参见图4中的应用程序实例状态表。
51.本实施例中，如图5所示，图5是本发明实施例提供的基于加密传输和会话密钥更新所述应用程序实例的状态请求的流程示意图，所述步骤s20包括以下步骤：步骤s201：当所述应用程序实例接收到用户请求时，密封并存储所述应用程序实例的状态快照到磁盘上，并更新所述应用程序实例的状态摘要，向所述本地状态服务实例发送状态更新请求；步骤s202：当所述本地状态服务实例接收到状态更新请求时，存储所述状态更新
请求到请求列队；步骤s203：当处理所述状态更新请求时，控制所述本地状态服务实例向全部状态服务实例（包括本地状态服务实例和其他状态服务实例）发送所述状态更新请求；步骤s204：当全部状态服务实例（包括本地状态服务实例和其他状态服务实例）接收到所述状态更新请求时，更新全部状态服务实例（包括本地状态服务实例和其他状态服务实例）状态内存中所述本地状态服务实例的状态摘要并发送回复消息；步骤s205：当所述本地状态服务实例收到超过f 1个所述回复消息时，所述本地状态服务实例向其他状态服务实例发送决定消息，其中，f为共识节点容错数；步骤s206：当其他状态服务实例收到所述决定消息后，检查其他状态服务实例是否已回复所述准备消息，若是，则控制所述状态服务实例发回包含状态摘要的确认字符；步骤s207：当所述本地状态服务实例收到超过f 1个所述确认字符时，控制所述本地状态服务实例更新所述应用程序实例的状态摘要并向所述应用程序实例回复包含状态摘要的确认字符；步骤s208：当所述应用程序实例收到所述确认字符时，将其状态更新为最新状态并发布相关输出。
52.需要说明的是，所述步骤s201至步骤s207为状态更新协议的架构方法，具体的，如图6所示，图6是本发明实施例提供的状态更新协议的交互示意图，也就是说，当本地状态服务实例准备好处理应用程序实例的状态更新请求时，遵循图6所示的状态更新协议，所述状态更新协议基于回声广播协议，应用程序实例和状态服务实例的消息通过加密方式传输和使用秘密会话密钥更新所述应用程序实例的状态请求。此外，可以为每条消息添加随机数以防止消息重播攻击。
53.举例说明，当接收到用户请求时，应用程序实例首先密封并存储状态磁盘上的快照，其中状态摘要为。然后，应用程序实例调用函数更新它的状态摘要，为了清楚起见，假设需要随机性附有；本地状态服务实例收到状态更新请求时，将其缓存在先进先出(fifo)队列中，一旦请求在头部并且没有其他服务请求，状态服务实例密封并存储它在磁盘上的状态快照，其中是应用程序实例的状态摘要；状态服务实例向全部状态服务实例（包括当前状态服务实例和其他状态服务实例）发送准备消息；当接收到prepare消息时，每个状态服务实例都会更新状态内存中本地状态服务实例的摘要并发送回复消息，所述回复消息包含的消息；收到超过f 1个回复消息后，本地状态服务实例向组中所有状态服
务实例发送决定消息；当状态服务实例收到决定消息后，检查是否已回显相关的准备消息。如果是，则发回包含的确认字符。当接收到超过f 1个确认字符时，本地状态服务实例更新应用程序实例的状态摘要并返回包含的确认字符。当应用程序实例接收到确认字符后，应用程序实例将其状态更新为并且发布相关的输出。
54.需要说明的是，所述状态更新协议可以在较小的传输控制协议中实现，首先，在处理请求时，应用程序实例必须进行密封和存储本地磁盘中的状态快照。对于某些应用程序，如支付，整个状态很大，因此此操作会产生加密数据和输入输出的繁重任务；其次，状态服务实例依次处理应用程序实例的状态更新。序列化会限制状态服务实例每秒处理请求的能力（即吞吐量）；此外，当支持的数量应用程序实例和关联请求很大，吞吐量低会导致到长时间的服务延迟，每次更新涉及两轮状态服务实例之间的消息交换，是影响的主要因素延迟和吞吐量。
55.为了解决上述问题，本实施例中，采用以下方式优化所述状态更新协议：（1）利用检查点减少密封和存储数据的大小，此方式适用于应用程序实例和状态服务实例。为了清楚起见，我们从应用程序实例的角度描述优化，需要说明的是，由于程序是确定性的，可以恢复最新状态执行所有历史输入，也就是说，应用程序实例只需要密封并将输入请求存储在磁盘上，同时记录摘要状态服务实例中的输入历史，对于大多数应用程序，输入通常是远小于整个应用程序状态，因此可以减少密封和存储数据的大小。
56.（2）利用批处理处理提升系统处理请求的能力。使状态服务实例可以同时服务多个运行不同应用程序的应用程序实例，即不需要串行处理不同应用程序实例的状态更新请求。在步骤s202中状态服务实例获取一批来自队列的请求，并将这些请求作为一个请求。然后，状态服务实例遵循步骤s203至步骤s207处理这些请求。执行上述步骤后，状态服务实例会一一处理并发送确认字符。批处理的开销可以忽略不计，原因有以下两个：首先，密封和存储数据的大小仅略有增加执行时间，其次，协议传输的网络消息（即准备消息和决定消息）的大小保持不变，因为输出大小无论输入的大小如何，散列函数的值都是固定的。
57.当应用程序实例想要检查其状态或密封状态的新鲜度时。应用程序实例调用函数readstate()获取最新的来自本地状态服务实例的状态摘要。当接收到状态读取请求时，本地状态服务实例无法直接返回应用程序实例的记录状态。主要是因为可能因为存在多个本地状态服务实例（即分叉攻击），因此请求的状态服务实例保存的状态不是最新的。为了解决这个问题，应用程序实例必须检查它的状态是否是最新的，如果是，则安全地返回应用程序实例的状态摘要。所述控制所述应用程序实例读取所述状态服务实例的最新状态，如图7所示。图7是本发明实施提供的所述应用程序实例读取所述状态服务实例的最新状态的流程示意图，步骤s30包括以下步骤：步骤s301：控制所述应用程序实例调用函数向所述本地状态服务实例发送状态读取请求；
步骤s302：当所述本地状态服务实例收到所述状态读取请求时，检索全部所述状态服务实例的最新状态；步骤s303：检查每个所述状态服务实例的状态服务实例状态表，并将存储的状态摘要发回给所述本地状态服务实例；步骤s304：当收到f 1个所述状态摘要时，选择索引最大的状态摘要作为所述本地状态服务实例的状态摘要。
58.需要说明的是，所述步骤s301至步骤s304为状态读取协议的架构方法，具体的，如图8所示。图8是本发明实施例提供的状态读取协议的交互示意图，应用程序实例调用readstate()函数向目标状态服务实例发送状态读取请求，本地状态服务实例收到状态读取请求时，检索组中所有状态服务实例的最新状态，每个状态服务实例检查其状态服务实例状态表，并将存储的状态摘要发回本地状态服务实例，在收到至少f 1个回复后，本地状态服务实例选择具有最大索引和序列号的状态摘要；然后，本地状态服务实例将选择的状态摘要与前一次的状态摘要进行比较，如果它的状态是最新的，则发回记录的状态摘要给应用程序实例，否则，不回复。
59.会话密钥作为状态服务实例的身份，在同一平台上只允许有一个正在工作中的状态服务实例。然而，现有技术中的重启协议存在安全问题，即对手可以利用该协议创建两个并行运行的系统，然后启动对tee应用程序的回滚和分叉攻击。为了解决上述问题，本实施例中当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；也就是说，重启后的状态服务实例必须与其他状态服务实例建立新的会话密钥。
60.当所述状态服务实例发生重启时，所述基于会话密钥恢复所述状态服务实例的状态包括以下步骤：控制重启后的所述状态服务实例与其他状态服务实例建立新的会话密钥；需要说明的是，当某一个状态服务实例（se）被强制重启后，重启后的状态服务实例（se）会失去所有的内存数据，但是之前建立的会话控制（session）会保存在状态服务实例（se）中，此时重启后的状态服务实例（se）无法重新加入集群。本实施例中，每一个状态服务实例（se）会存在一个“ping”的功能，检查自己是否仍与其他状态服务实例保持链接。
61.控制重启后的所述状态服务实例执行所述步骤s302至所述步骤s304以获取所述状态服务实例和其他状态服务实例的状态摘要；选择索引最大的状态摘要作为重启后的所述状态服务实例的状态摘要，重启的状态服务实例（se）需要恢复内存数据，因此选择最新的状态摘要；控制所述状态服务实例从操作系统获取密封的状态摘要，将所述状态摘要与从其他状态服务实例获取的状态摘要进行匹配，若匹配，则控制所述状态服务实例恢复状态摘要对应的状态。
62.具体的，重启后的服务实例需要与其他状态服务实例建立新的会话密钥，因为它已经失去了以前的全部数据。其次，在会话密钥建立之前，其他状态服务实例必须检查他们是否仍维持与其他状态服务实例的链接，即他们的会话密钥是否仍处于活动状态，为此，每个状态服务实例发送一个ping请求向其他状态服务实例发送消息并等待ack，如果他们无法收到来自其他状态服务实例的ack，则拒绝与重启状态服务实例建立新的会话密钥；重启状态服务实例执行状态读取协议中的步骤s302至步骤s304以获取其和其他状态服务实例
的最新状态摘要，步骤s302至步骤s304可以在一个读取请求中；重启状态服务实例选择索引最大的状态摘要，也就是最新的状态摘要作为每个状态服务实例（包括重启状态服务实例）的序列号。为了重启后的状态服务实例和群组保持同步，增加序列号并重新执行状态更新协议中步骤s202至步骤s206来更新其最新的状态摘要。如此，可以保证最新的状态摘要被安全地记录在至少f 1个状态服务实例上。
63.当所述应用程序实例发生重启时，所述基于操作系统的密封状态数据恢复所述应用程序实例的状态，包括以下步骤：控制重启后的所述应用程序实例执行所述步骤s301至所述步骤s304向所述本地状态服务实例请求最新状态摘要；控制所述应用程序实例获取所述操作系统的密封状态数据，将所述密封状态数据与所述最新状态摘要进行匹配，若匹配成功，则更新重启后所述应用程序实例的状态摘要并发布输出。
64.具体的，重启后的重启应用程序实例执行状态读取协议向本地状态服务实例请求最新的状态摘要；并从操作系统获得重启应用程序实例的最新密封状态，将最新密封状态与所述本地状态服务实例的状态摘要进行匹配，如果这两个匹配，将应用程序实例的状态更新为最新状态并发布相关输出。
65.由上可见，本发明实施例提供的一种基于去中心化信任的公有云下tee状态连续性保护方法，所述基于去中心化信任的公有云下tee状态连续性保护包括：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取所述状态服务实例的最新状态；当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。与现有技术相比，本发明使用区块链消除了对中心化可信实体的依赖，且只依赖区块链进行初始化，提高了状态更新和读取的速度。
66.示例性设备如图9中所示，对应于所述基于去中心化信任的公有云下tee状态连续性保护方法，本发明实施例还提供一种基于去中心化信任的公有云下tee状态连续性保护系统，所述基于去中心化信任的公有云下tee状态连续性保护系统包括：初始化模块100，用于基于区块链对状态服务实例进行初始化处理；状态更新模块200，用于基于加密传输和会话密钥更新应用程序实例的状态请求；状态读取模块300，用于控制所述应用程序实例读取所述状态服务实例的最新状态；重启模块400，用于当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；还用于当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
67.如图10所示，所述系统包括：可信平台及区块链，所述应用程序实例（ae）和所述状态服务实例（se）运行在所述可信平台，所述应用程序实例处理客户的请求并返回相应的输出，所述状态服务实例为所述应用程序实例提高状态连续性保护。
68.具体地，本实施例中，所述基于去中心化信任的公有云下tee状态连续性保护系统
及其各个模块的具体功能还可以参照所述基于去中心化信任的公有云下tee状态连续性保护方法中的对应描述，在此不再赘述。
69.基于所述实施例，本发明还提供了一种智能终端，其原理框图可以如图11所示。所述智能终端包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的基于去中心化信任的公有云下tee状态连续性保护程序，所述基于去中心化信任的公有云下tee状态连续性保护程序被所述处理器执行时实现如上任意一项所述基于去中心化信任的公有云下tee状态连续性保护方法的步骤。
70.本领域技术人员可以理解，图11中示出的原理框图，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的智能终端的限定，具体地智能终端可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
71.在一个实施例中，所述基于去中心化信任的公有云下tee状态连续性保护程序被所述处理器执行时进行以下操作指令：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取所述状态服务实例的最新状态；当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
72.本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有基于去中心化信任的公有云下tee状态连续性保护程序，所述基于去中心化信任的公有云下tee状态连续性保护程序被处理器执行时实现如上任意一项所述基于去中心化信任的公有云下tee状态连续性保护方法的步骤。
73.应理解，所述实施例中各步骤的序号大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
74.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以所述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将所述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，所述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。所述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
75.在所述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
76.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各实例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟是以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
77.在本发明所提供的实施例中，应该理解到，所揭露的装置/终端设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/终端设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以由另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。
78.所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本发明实现所述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现所述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（rom，read-only memory）、随机存取存储器（ram，random access memory）、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读存储介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减。
79.以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解；其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不是相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。