CN115168872B

CN115168872B - Decentralized trust-based method for protecting TEE state continuity under public cloud

Info

Publication number: CN115168872B
Application number: CN202211087946.7A
Authority: CN
Inventors: 张殷乾; 彭维; 牛健宇
Original assignee: Southwest University of Science and Technology
Current assignee: Southwest University of Science and Technology
Priority date: 2022-09-07
Filing date: 2022-09-07
Publication date: 2023-01-10
Anticipated expiration: 2042-09-07
Also published as: WO2024050869A1; CN115168872A

Abstract

The invention discloses a decentralized trust-based method, a decentralized trust-based system, an intelligent terminal and a storage medium for protecting the continuity of a TEE state under a public cloud, wherein the method comprises the following steps: initializing the state service instance based on the block chain; updating a state request of the application instance based on the encrypted transport and the session key; controlling the application program instance to read the latest state stored in the state service instance; when the state service instance is restarted, recovering the state of the state service instance based on a session key; and when the application program instance is restarted, restoring the state of the application program instance based on the sealing state data of the operating system. In the invention, the dependence on a centralized trusted entity is eliminated by using the block chain, and only the block chain is relied for initialization, thereby improving the speed of state updating and reading.

Description

Decentralized trust-based TEE state continuity protection method under public cloud

Technical Field

The invention relates to the technical field of computers, in particular to a decentralized trust-based method and system for protecting TEE state continuity under a public cloud, an intelligent terminal and a computer readable storage medium.

Background

With the continuous development of science and technology, more and more manufacturers choose to deploy services to the public cloud, so that the privacy protection and data security problems are increasingly severe while convenience is brought, and due to the complexity of an operating system, security holes, security mechanisms and other problems, confidential data such as user fingerprints and certificates and common application data are stored on the public cloud, and confidentiality, integrity and availability of the confidential data and the common application data cannot be guaranteed. For this reason, the industry proposes design of a Trusted Execution Environment (TEE), for example, amazon cloud, google cloud, and arbiban cloud platforms use TEE technology to provide users with confidential computing services, but TEE-protected applications still suffer from rollback attacks or forking attacks, through which an attacker can rollback the state of the TEE to an outdated version or be forked into multiple versions, resulting in the state continuity of the TEE being broken.

In the prior art, a secure container is usually provided by using a hardware trusted counter, a remote user uploads codes and data into the secure container, and when computing is performed on the secure container, the secure container is used for protecting confidentiality and integrity of the data, but the state updating and reading speed of the hardware trusted counter is slow, and the requirement on the updated state in a cloud environment cannot be met.

Thus, there is still a need for improvement and development of the prior art.

Disclosure of Invention

The invention mainly aims to provide a decentralized trust-based method for protecting the continuity of a TEE state under a public cloud, and aims to solve the problems that in the prior art, the state updating and reading speed of a hardware trusted counter is low, and the requirement on the updating state in a cloud environment cannot be met.

In order to achieve the above object, a first aspect of the present invention provides a decentralized trust-based TEE state continuity protection method under a public cloud, where the decentralized trust-based TEE state continuity protection method under the public cloud includes: initializing the state service instance based on the block chain; updating a state request of the application instance based on the encrypted transport and the session key; controlling the application program instance to read the latest state stored in the state service instance; when the state service instance is restarted, recovering the state of the state service instance based on a session key; and when the application program instance is restarted, restoring the state of the application program instance based on the sealing state data of the operating system.

Optionally, the method for protecting TEE state continuity under public cloud based on decentralized trust further includes: writing the identity identification number and the public key of the state service instance to the block chain through a first interface of the block chain, and recording initialization information; inquiring initialization information on the block chain through a second interface of the block chain according to the identity identification number and the public key of the state service instance; when the application program instance updates the state abstract through a third interface of the block chain, requesting whether the update is legal or not from the state service instance; and acquiring the state abstract of the application program instance through a fourth interface of the block chain.

Optionally, the initializing the state service instance based on the block chain specifically includes:

setting any one of the state service instances as a leader, mutually verifying the identities of the leader and other state service instances through remote certification, and establishing a secure communication channel between the leader and other state service instances;

controlling the leader and other state service instances to generate asymmetric key pairs, and sending the public keys of the state service instances to the leader, wherein the leader distributes the received public key list to other state service instances;

controlling each of the state service instances to send a read request to the blockchain, the read request including a unique identifier of the state service instance;

controlling each state service instance to send a write request to the blockchain, and when receiving a confirmation character from the blockchain, controlling each state service instance to create a local memory, wherein the local memory comprises state service instance state tables of other state service instance state entries and an empty application program instance state table;

controlling a local state service instance to place the public key list into a local memory of the local state service instance to generate a state service instance configuration table, and controlling the local state service instance to establish a pairwise session key with other state service instances by running a verified key protocol;

and sealing and storing the key pair of the local state service instance, the state service instance configuration table and the application program instance state table.

Optionally, the updating the state request of the application instance based on the encrypted transmission and the session key specifically includes:

when the application program instance receives a user request, the state of the application program instance is sealed and stored and is quickly found on a disk, the state abstract of the application program instance is updated, and a state updating request is sent to the local state service instance;

when the local state service instance receives a state updating request, storing the state updating request to a request queue;

when the state updating request is processed, controlling the local state service instance to send the state updating request to the local state service instance and other state service instances;

when the local state service instance and other state service instances receive the state updating request, updating the state abstracts of the local state service instance in the state memories of the local state service instance and other state service instances and sending a reply message;

when the local state service instance receives more thanf+1 of said reply messages, said local state service instance sending a decision message to other state service instances, wherein,ffault tolerance number of the consensus node;

after other state service instances receive the decision message, checking whether the other state service instances reply the preparation message, if so, controlling the state service instances to send back confirmation characters containing state abstracts;

when the local state service instance receives more thanfWhen +1 confirm characters, controlling the local state service instance to update the state abstract of the application program instance and replying the confirm characters containing the state abstract to the application program instance;

when the application program instance receives the confirmation character, the state of the application program instance is updated to the latest state, and relevant output is issued.

Optionally, the controlling the application program instance to read the latest state of the state service instance specifically includes:

controlling the application program instance calling function to send a state reading request to the local state service instance;

when the local state service instance receives the state reading request, retrieving the latest state of all the state service instances;

checking a state service instance state table of each state service instance and sending a stored state abstract back to the local state service instance;

when receivingfAnd when +1 state digests exist, selecting the state digest with the largest index as the state digest of the local state service instance.

Optionally, when the stateful service instance is restarted, recovering the state of the stateful service instance based on the session key specifically includes:

controlling the restarted state service instance and other state service instances to establish a new session key;

controlling the restarted state service instance to acquire state abstracts of the state service instance and other state service instances;

selecting the state abstract with the largest index as the state abstract of the restarted state service instance;

and controlling the state service instance to acquire a sealed state abstract from an operating system, matching the state abstract with state abstracts acquired from other state service instances, and if the state abstract is matched with the state abstract, controlling the state service instance to recover the state abstract of the state service instance.

Optionally, when the application program instance is restarted, recovering the state of the application program instance based on the sealing state data of the operating system specifically includes:

controlling the restarted application program instance to request the latest state abstract from the local state service instance;

and controlling the application program instance to acquire the sealing state data of the operating system, matching the sealing state data with the latest state abstract, and if the matching is successful, updating, issuing and outputting the state abstract of the application program instance after restarting.

A second aspect of the present invention provides a decentralized trust-based TEE state continuity protection system under a public cloud, which is characterized in that the decentralized trust-based TEE state continuity protection system under the public cloud includes:

the initialization module is used for initializing the state service instance based on the block chain;

a status update module for updating a status request of the application instance based on the encrypted transmission and the session key;

the state reading module is used for controlling the application program instance to read the latest state of the state service instance;

the restarting module is used for recovering the state of the state service instance based on the session key when the state service instance is restarted; and the application program recovery module is also used for recovering the state of the application program instance based on the sealing state data of the operating system when the application program instance is restarted.

A third aspect of the present invention provides an intelligent terminal, where the intelligent terminal includes a memory, a processor, and a decentralized trust based TEE state continuity protection program stored in the memory and operable on the processor, and when the decentralized trust based TEE state continuity protection program is executed by the processor, the method for decentralized trust based TEE state continuity protection under public cloud is implemented.

A fourth aspect of the present invention provides a computer-readable storage medium, where a decentralized trust-based TEE state continuity protection program under a public cloud is stored on the computer-readable storage medium, and when executed by a processor, the decentralized trust-based TEE state continuity protection program under the public cloud implements the steps of the decentralized trust-based TEE state continuity protection method under the public cloud.

As can be seen from the above, the decentralized trust-based method for protecting continuity of TEE states under public clouds provided in the embodiment of the present invention includes: initializing the state service instance based on the block chain; updating a state request of the application instance based on the encrypted transport and the session key; controlling the application program instance to read the latest state of the state service instance; when the state service instance is restarted, recovering the state of the state service instance based on a session key; and when the application program instance is restarted, recovering the state of the application program instance based on the sealing state data of the operating system. Compared with the prior art, the method and the device have the advantages that the dependence on a centralized trusted entity is eliminated by using the block chain, and only the block chain is relied for initialization, so that the speed of updating and reading the state is increased.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required to be used in the embodiments or the prior art description will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without inventive labor.

Fig. 1 is a schematic flowchart of a method for TEE state continuity protection under a public cloud based on decentralized trust according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating step S10 according to an embodiment of the present invention;

FIG. 3 is an interaction diagram of a system initialization protocol provided by an embodiment of the invention;

fig. 4 is a schematic diagram of a memory layout of a local state service instance provided in the embodiment of the present invention;

fig. 5 is a schematic flowchart of step S20 according to an embodiment of the present invention;

FIG. 6 is an interaction diagram of a status update protocol provided by an embodiment of the invention;

FIG. 7 is a flowchart illustrating step S30 according to an embodiment of the present invention;

FIG. 8 is an interaction diagram of a status reading protocol provided by an embodiment of the invention;

fig. 9 is a schematic structural diagram of a cee state continuity protection system under a public cloud based on decentralized trust according to an embodiment of the present invention;

fig. 10 is a schematic structural diagram of a te state continuity protection system under a public cloud based on decentralized trust according to an embodiment of the present invention;

fig. 11 is a schematic block diagram of an internal structure of an intelligent terminal according to an embodiment of the present invention.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also to be understood that the terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be further understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

The technical solutions in the embodiments of the present invention are clearly and completely described below with reference to the drawings of the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, however, the present invention may be practiced in other ways than those specifically described herein, and it will be appreciated by those skilled in the art that the present invention may be practiced without departing from the spirit and scope of the present invention, and therefore the present invention is not limited by the specific embodiments disclosed below.

With the development of technology, more and more manufacturers choose to deploy services to the public cloud, for example, the Software protection Extension (SGX) enables applications to compute directly without revealing confidential data. For example, intel SGX provides a secure isolated environment Enclave (Enclave) for protected computing and stores code and data in the Enclave (Enclave), which is a protected content container for storing application sensitive data and code; confidential computing services are typically provided to users in the prior art through TEEs, which are intended to enhance the security and privacy of customer outsourcing data or code. But the state applications in the TEE rely on the untrusted operating system to store state and therefore are subject to rollback or bifurcation attacks, their state may roll back to the correct but outdated version or be bifurcated into multiple versions, causing state continuity to be corrupted, and in addition, when the system reboots, powers off, or crashes, the protected module should recover to the same state before state continuity breaks.

State continuity, once violated, can have serious consequences, such as payment, credit systems, trusted storage, smart contracts, etc., all of which are affected, for example, in a payment system implemented in a TEE, an attacker can spend the same coin in multiple payments by restoring the state of his account balance (i.e., a double-spending attack).

For the above problems, in the prior art, there is a hardware-based solution, for example, a timer counter is used for status update, which has only limited write operations and slow status update and read speeds, and cannot meet the requirements for updating status in a cloud environment. Software-based solutions, such as loading trusted counters onto a single trusted server or a distributed aggregation server, rely on a trusted administrator for system initialization, such that such solutions still suffer from the problem of relying on centralized trust.

In order to solve the problems in the prior art, the invention provides a decentralized trust-based public under-cloud TEE state continuity protection method, which depends on a block chain (namely decentralized trust) and a TEE-based distributed system, can provide high-performance state continuity protection for a protected TEE application instance of a user on a cloud, and can support infinite and quick state updating applied in a cloud TEE environment.

Exemplary method

As shown in fig. 1, an embodiment of the present invention provides a flow diagram of a decentralized trust-based TEE state continuity protection method in a public cloud, and specifically, the decentralized trust-based TEE state continuity protection method in the public cloud includes:

step S10: initializing the state service instance based on the block chain;

step S20: updating a state request of the application instance based on the encrypted transmission and the session key;

step S30: controlling the application program instance to read the latest state stored in the state service instance;

step S40: when the state service instance is restarted, recovering the state of the state service instance based on a session key; and when the application program instance is restarted, recovering the state of the application program instance based on the sealing state data of the operating system.

In the embodiment, only the block chain is used in the initialization processing, so that decentralized trust is established, the dependence on a central trusted entity is eliminated, and the interaction with the block chain is reduced as much as possible, so that the system can reduce the high interactive overhead of the block chain and reduce the cost.

It should be noted that the present embodiment may be applied to a cloud service provider managing a trusted platform, for example, an intel SGX-enabled platform, where each SGX-enabled trusted platform runs multiple enclave (enclave) instances, and specifically, the enclave instances may be classified into the following two types:

an Application instance (AE), which is an Application created and uploaded by an independent software vendor, processes customer requests and returns corresponding output.

State instance (SE), which is an Enclave instance that provides State continuity services for AEs. Each AE may be linked to a local SE (i.e., target SE) on the same platform and its state continuity is protected according to the method.

In this embodiment, the state service instance interacts with the blockchain through a blockchain interface, and the blockchain uses a byzantine fault-tolerant consensus as a backbone protocol, thereby further realizing key value storage, so that a user can identify a tuple < i > through an Identity Document (ID)key，blobWrite block chain in whichblobThe client identity ID can be an account book identifier or a digital public key signature scheme, only the owner of the key has the right to update the associated value, any party can read the associated value by using the key, and the creator of the key can encrypt the associated value to protect data privacy.

In this embodiment, the id number and the public key of the state service instance are written to the blockchain through the first interface of the blockchain, and initialization information is recorded; inquiring initialization information on the block chain through a second interface of the block chain according to the identity identification number and the public key of the state service instance; when the application program instance updates the state abstract through a third interface of the block chain, requesting whether the update is legal or not from the state service instance; and acquiring the state abstract of the application program instance through a fourth interface of the block chain.

Specifically, the first interface is blockchainkey，blobSuch as): the request is recorded in the blockchain for the stateful service instance. The ID is the identification of the block chain,keyandblobis a pair of key value stores. If the write is successful, one is returnedσ. The client may run a signature algorithm for verification.

Read (ID,key)→(blob，σ): read algorithm return andkeyand a verifierσAssociated withblob. Stateful service instance passingσ canThe integrity of the return value is checked.

The third interface is writeState (C)value): when the application program instance updates the state of the application program instance, the state service instance is requested to update whether the update is legal or not, and if the update is legal, a confirmation character is returned to confirm the application program instance.

The fourth interface is readState () →value: for obtaining a status digest of the application instance. It should be noted that if no value was previously written by the application instance, a null value is returned.

Through the above interface, the application program instance in this embodiment may implement recording before execution, when the application program instance updates its state, first seal and store a state snapshot on the disk, then call function writeState () to store the associated state digest, and once the application program instance receives the confirmation character, it may update its state and issue an output.

When the application program needs to verify the freshness of the data provided by the operating system after restarting, a function readState () is called to obtain the latest state digest thereof, and whether the state digest matches with the unsealed state snapshot data is checked. In the invention, each application program instance is linked with one local state service instance, and the local state service instance provides a plurality of interfaces to improve the proving speed and the state management flexibility.

It should be noted that the purpose of this embodiment is to implement an initialization protocol in which all stateful service instances autonomously complete configuration without involving any trusted administrator, and it should be noted that, during the initialization process, it should be ensured that only a set of legitimate stateful service instances have a known identity running on a trusted platform supporting SGX. Without this guarantee, the application instance may be linked to multiple groups, and each group may store a different state, resulting in a violation of state continuity.

Due to lack of trustworthiness, there are two challenges in the initialization process: the first, all stateful service instances must build the PKI approach in a distributed fashion, which typically results in higher message complexity. Second, a centralized system typically uses a trusted administrator to provide key provisioning, ensuring that there is only one initialization group.

In order to meet the first challenge, a leader mode is adopted for initialization in the embodiment, any one of the state service instances is set as a leader, the leader can be delegated by a cloud service provider, and the leader chooses not to influence security. Firstly, the leader mutually authenticates other state service instances through remote certification, establishes a communication channel with the other state service instances, establishes a trust chain after mutually certifying the identities of each other, and then can collect and distribute public keys of the other state service instances.

To address the second challenge, the embodiment relies on interaction with blockchains, during initialization, a stateful service instance must publish a record on the ledger @uid，blobTherein, whereinuidIs an identifier unique to the Enclave (Enclave) program on the platform, andblobmay be configuration information; when another stateful service instance starts to initialize on the same platform, it will also generate the sameuidThe previous record is found in the blockchain and then the initialization is aborted. Therefore, the same level is used in this embodimentA station will not have a forked state service instance. The entire initialization is done autonomously without involving any trusted administrator.

In this embodiment, as shown in fig. 2, fig. 2 is a schematic flowchart of a process of initializing the state service instance based on a block chain according to an embodiment of the present invention, where the step S10 specifically includes:

step S101: setting any one of the state service instances as a leader, mutually verifying the identities of the leader and other state service instances through remote certification, and establishing a secure communication channel between the leader and other state service instances;

step S102: controlling the leader and other state service instances to generate asymmetric key pairs, and sending the public keys of the state service instances to the leader, wherein the leader distributes the received public key list to other state service instances;

step S103: controlling each of the state service instances to send a read request to the blockchain, the read request including a unique identifier of the state service instance; multiple application instances on the same trusted execution environment platform have the same identifier;

step S104: controlling each state service instance to send a write request to the blockchain, and when receiving a confirmation character from the blockchain, controlling each state service instance to create a local memory, wherein the local memory comprises state service instance state tables of other state service instance state entries and an empty application program instance state table;

step S105: controlling a local state service instance to place the public key list into a local memory of the local state service instance to generate a state service instance configuration table, and controlling the local state service instance to establish a pairwise session key with other state service instances by running a verified key protocol;

step S106: and sealing and storing the key pair of the local state service instance, the state service instance configuration table and the application program instance state table.

It should be noted that the steps S101 to S104 are methods for initializing a protocol architecture, specifically, as shown in fig. 3, fig. 3 is an interaction diagram of a system initialization protocol provided in the embodiment of the present invention, and a secure communication channel is established through the step S101. The leader uses the remote attestation to mutually attest to each other stateful service instance while establishing a secure communication channel with all other stateful service instances. It should be noted that at creation time, each stateful service instance (including the leader) needs to compute its Enclave (Enclave) identity and compare it with the identities of the other people to verify that the certified Enclave (Enclave) is a stateful service instance. The leader uses remote attestation to mutually authenticate each other stateful service instance, and at the same time establishes a secure communication channel with these stateful service instances, and at the time of creation, each stateful service instance (including the leader) calculates its Enclave identifier (i.e., mrencolave) and compares its identifier with the identities of the other enclaves to verify whether the certified Enclave is a stateful service instance.

Identity establishment is performed through step S102, and all stateful service instances (including the leader) generate an asymmetric key pair (S) ((r))pk，sk) And send their public keys to the leader, which, upon receipt of the public key, distributes a list of the received public keys (e.g., of the client's name)

Presentation) to other stateful service instances so that they can authenticate each other.

A first initialization check is performed, per state service instance, by step S103, sending a read request to the second interface blockchain.uid) Wherein the ID is the ledger identifier of the stateful service instance (by which it is formed)pkGeneration) ofuidIs a unique identifier of a stateful service instance on a SGX-enabled trusted platform. When another stateful service instance starts to initialize on the same platform, it will also generate the sameuidThe state service instance sends a read request to the blockchain, which returns according to the requestblobIf, ifblobNull, state serviceThe instance is not initialized and is the first time it joins the group. If it returnsblobIf not, indicating that another stateful service instance has been initialized, the stateful service instance will abort the initialization.

The record initialization, the state service instance, through the first interface blockchain.write (ID,

) Sending a write request, when receiving an Acknowledgement Character (ACK) from a block chain, a state service instance creates a state service instance state table containing state entries of other state service instances and an empty application instance state table, the state service instance places a public key list pkSEi in the state service instance configuration table and establishes a pairwise session key keySEi, and a key protocol which is authenticated by running with all other state service instances is established by the state service instance, as shown in fig. 4, fig. 4 is a schematic memory layout diagram of a local state service instance provided by the embodiment of the present invention, wherein a data gray rectangle is sealed for a state snapshot, the state service instance seals and stores a key pair, the state service instance configuration table and the application instance state table, and finally the state service instance completes initialization and services the request of the application instance.

Note that the identifier in step S103

Is an envelope identity, so that other people can verify that the identity quoted is sent by the same platform. The state service instance should remain in the active state during the execution of step S104. Because it is not possible to distinguish whether a normal crash is from a malicious activity that created a fork group, if a state service instance is receivingblobBefore crashing, initialization is not possible. However, because the initialization process may occur only once, the identity of the local state service instance may be hard coded into the application instance implementation or provided by an independent software developer. The application program instance can run an authenticated key establishment protocol with the local state service instance and share the key through the protocolk(ii) a Status serviceThe instance creates a state entry for the application instance, including the unique identity application instance (i.e., the hash of the application instance code used), the shared secret key, and an empty state digest, as seen in the application instance state table of FIG. 4.

In this embodiment, as shown in fig. 5, fig. 5 is a schematic flowchart of a status request for updating the application program instance based on encrypted transmission and a session key provided in the embodiment of the present invention, where the step S20 includes the following steps:

step S201: when the application program instance receives a user request, the state of the application program instance is sealed and stored and is quickly found on a disk, the state abstract of the application program instance is updated, and a state updating request is sent to the local state service instance;

step S202: when the local state service instance receives a state updating request, storing the state updating request to a request queue;

step S203: when the status update request is processed, controlling the local status service instance to send the status update request to all status service instances (including the local status service instance and other status service instances);

step S204: when all state service instances (including a local state service instance and other state service instances) receive the state updating request, updating state abstracts of the local state service instances in state memories of all state service instances (including the local state service instance and other state service instances) and sending a reply message;

step S205: when the local state service instance receives more thanf+1 of said reply messages, said local state service instance sending a decision message to other state service instances, wherein,ffault tolerance number of the consensus node;

step S206: after other state service instances receive the decision message, checking whether the other state service instances reply the preparation message, if so, controlling the state service instances to send back confirmation characters containing state abstracts;

step S207: when the local state service instance receives more thanfWhen +1 confirm characters, controlling the local state service instance to update the state abstract of the application program instance and replying the confirm characters containing the state abstract to the application program instance;

step S208: when the application program instance receives the confirmation character, the state of the application program instance is updated to the latest state, and relevant output is issued.

It should be noted that, step S201 to step S207 are architectural methods of a status update protocol, specifically, as shown in fig. 6, fig. 6 is an interaction schematic diagram of the status update protocol provided in the embodiment of the present invention, that is, when a local status service instance is ready to process a status update request of an application instance, the status update protocol shown in fig. 6 is followed, the status update protocol is based on an echo broadcast protocol, and messages of the application instance and the status service instance are transmitted in an encrypted manner and update the status request of the application instance by using a secret session key. In addition, a random number may be added to each message to prevent message replay attacks.

For example, when a user request is received

In time, an application instance first seals and stores a snapshot on a state disk

Wherein the status abstract

Is composed of

. The application instance then calls a function

Update its status summary, assuming for clarity randomness is required

Is attached with

(ii) a When a local state service instance receives a state update request, it buffers it in a first-in-first-out (FIFO) queue, and once the request is at the head and there are no other service requests, the state service instance seals and stores its state snapshot on disk

Wherein

Is a state summary of an application instance

(ii) a The state service instance sends a prepare message to all state service instances (including the current state service instance and other state service instances)

(ii) a When the Prepare message is received, each state service instance updates the abstract of the local state service instance in the state memory and sends a reply message, wherein the reply message comprises

The message of (2); receive excessfAfter +1 reply messages, the local stateful service instance sends a decision message to all stateful service instances in the group

(ii) a When the state service instance receives the decision message, it checks whether the relevant prepare message has been echoed. If so, sending back the message containing

The confirmation character of (1). When receiving the excessf+1 character confirmation periodThe local stateful service instance updates the state digest of the application instance and returns a message containing the updated state digest

The confirmation character of (1). When the application instance receives the confirmation character, the application instance updates its state to

And issues relevant output

。

It should be noted that the state update protocol can be implemented in a smaller transmission control protocol, and first, when processing a request, an application instance must perform sealing and storing a state snapshot in a local disk. For some applications, such as payment, the overall state is large, and therefore this operation can create a heavy task of encrypting data and input and output; second, the state service instance in turn handles the state updates of the application instance. Serialization limits the ability of a stateful service instance to handle requests per second (i.e., throughput); furthermore, when the number of supported application instances and associated requests is large, low throughput can result in long service delays, and each update involves message exchanges between two rounds of stateful service instances, which are the main factors of latency and throughput.

In order to solve the above problem, in this embodiment, the status update protocol is optimized in the following manner:

(1) This approach is applicable to application instances and state service instances, with checkpoints reducing the size of the sealed and stored data. For clarity, we describe the optimization from the application instance perspective, it should be noted that since the program is deterministic, all historical inputs can be executed in the recovered up-to-date state, i.e., the application instance only needs to seal and store the input request on disk, while recording the input history in the summary state service instance, which is typically much less than the entire application state for most applications, thus reducing the size of the sealed and stored data.

(2) The ability of the system to process requests is enhanced with batch processing. The state service instance can simultaneously serve a plurality of application program instances running different application programs, namely, the state update requests of different application program instances are not required to be processed in series. The stateful service instance obtains a batch of requests from the queue and treats these requests as one request in step S202. The stateful service instance then processes these requests following steps S203-S207. After the above steps are executed, the state service instances process and send the confirmation characters one by one. The overhead of batch processing is negligible for two reasons: firstly, the size of the sealed and stored data only slightly increases the execution time, and secondly, the size of the network messages (i.e. the prepare message and the decide message) transmitted by the protocol remains unchanged, since the value of the hash function is fixed for the output size regardless of the input size.

When an application instance wants to check the freshness of its state or sealed state. The application instance calls the function readState () to get the latest state digest from the local state service instance. When a state read request is received, the local state service instance cannot directly return the logging state of the application instance. Primarily because the state saved by the requesting state service instance is not up-to-date, possibly because there are multiple local state service instances (i.e., a bifurcated attack). To address this problem, the application instance must check whether its state is up-to-date and, if so, securely return a state digest for the application instance. The control reads the latest state of the state service instance by the application instance, as shown in fig. 7. Fig. 7 is a schematic flow chart of the application program instance reading the latest state of the state service instance provided by the implementation of the present invention, and step S30 includes the following steps:

step S301: controlling the application program instance calling function to send a state reading request to the local state service instance;

step S302: when the local state service instance receives the state reading request, retrieving the latest state of all the state service instances;

step S303: checking a state service instance state table of each state service instance and sending back a stored state abstract to the local state service instance;

step S304: when receivingf And when +1 state digests exist, selecting the state digest with the largest index as the state digest of the local state service instance.

It should be noted that steps S301 to S304 are architecture methods of a status reading protocol, and specifically, as shown in fig. 8. Fig. 8 is an interaction diagram of a status reading protocol according to an embodiment of the present invention, where an application instance calls a readState () function to send a status reading request to a target status service instance, a local status service instance receives the status reading request, retrieves the latest status of all status service instances in a group, each status service instance checks its status service instance status table and sends a stored status summary back to the local status service instance, and when at least one status summary is receivedfAfter +1 replies, the local state service instance selects the state abstract with the maximum index and sequence number; the local state service instance then compares the selected state digest with the previous state digest, and sends back the recorded state digest to the application instance if its state is up-to-date, otherwise, does not reply.

The session key serves as the identity of the stateful service instance, and only one working stateful service instance is allowed on the same platform. However, the restart protocol in the prior art has a security problem in that an adversary can create two systems running in parallel using the protocol and then initiate rollback and forking attacks on the TEE application. In order to solve the above problem, in this embodiment, when the stateful service instance is restarted, the state of the stateful service instance is recovered based on the session key; that is, the restarted stateful service instance must establish new session keys with other stateful service instances.

When the state service instance is restarted, the recovering the state of the state service instance based on the session key comprises the following steps:

it should be noted that, when a state service instance (SE) is forcibly restarted, the restarted state service instance (SE) loses all memory data, but the previously established session control (session) is stored in the state service instance (SE), and at this time, the restarted state service instance (SE) cannot join the cluster again. In this embodiment, each stateful service instance (SE) will have a "ping" function that checks whether it is still linked to other stateful service instances.

Controlling the restarted stateful service instance to execute the step S302 to the step S304 to obtain stateful abstracts of the stateful service instance and other stateful service instances;

selecting the state abstract with the largest index as the state abstract of the restarted state service instance, wherein the restarted state service instance (SE) needs to recover memory data, so that the latest state abstract is selected;

and controlling the state service instance to acquire a sealed state abstract from an operating system, matching the state abstract with state abstracts acquired from other state service instances, and if the state abstracts are matched, controlling the state service instance to recover the state corresponding to the state abstract.

In particular, the restarted service instance needs to establish a new session key with other stateful service instances because it has lost all previous data. Secondly, before the session key is established, other state service instances must check whether they still maintain the link with other state service instances, i.e. whether their session key is still in an active state, for this purpose, each state service instance sends a ping request to send a message to other state service instances and waits for an ACK, and if they cannot receive ACKs from other state service instances, they refuse to establish a new session key with the restart state service instance; restarting the stateful service instance performs steps S302-S304 in the stateful read protocol to obtainThe latest status summary of the status service instance and other status service instances, steps S302 to S304 may be in a read request; the restart stateful service instance selects the most indexed state digest, i.e., the latest state digest, as the sequence number for each stateful service instance (including the restart stateful service instance). In order to keep the restarted state service instance and the group synchronized, the sequence number is increased and the steps S202 to S206 in the state updating protocol are executed again to update the latest state digest thereof. In this way, it is ensured that the latest status digest is securely recorded at least inf+1 stateful service instances.

When the application program instance is restarted, the operating system-based sealing state data restores the state of the application program instance, and the method comprises the following steps:

controlling the restarted application program instance to execute the step S301 to the step S304 to request the latest state abstract from the local state service instance;

Specifically, the restarted restart application program instance executes a state reading protocol to request the latest state abstract from the local state service instance; and obtaining the latest sealing state of the restarting application program instance from the operating system, matching the latest sealing state with the state abstract of the local state service instance, and if the latest sealing state and the state abstract of the local state service instance are matched, updating the state of the application program instance to the latest state and issuing related output.

As can be seen from the above, the method for protecting continuity of a TEE state under a public cloud based on decentralized trust provided in the embodiment of the present invention includes: initializing the state service instance based on the block chain; updating a state request of the application instance based on the encrypted transport and the session key; controlling the application program instance to read the latest state of the state service instance; when the state service instance is restarted, recovering the state of the state service instance based on a session key; and when the application program instance is restarted, restoring the state of the application program instance based on the sealing state data of the operating system. Compared with the prior art, the method and the device have the advantages that the dependence on the centralized trusted entity is eliminated by using the block chain, and the initialization is carried out only by depending on the block chain, so that the speed of updating and reading the state is increased.

Exemplary device

As shown in fig. 9, in correspondence to the decentralized trust-based TEE state continuity protection method under the public cloud, an embodiment of the present invention further provides a decentralized trust-based TEE state continuity protection system under the public cloud, where the decentralized trust-based TEE state continuity protection system under the public cloud includes:

an initialization module 100, configured to perform initialization processing on a stateful service instance based on a block chain;

a status update module 200 for updating the status request of the application instance based on the encrypted transport and the session key;

a state reading module 300, configured to control the application program instance to read the latest state of the state service instance;

a restarting module 400, configured to, when the stateful service instance is restarted, recover the state of the stateful service instance based on the session key; and the application program recovery module is also used for recovering the state of the application program instance based on the sealing state data of the operating system when the application program instance is restarted.

As shown in fig. 10, the system includes: the system comprises a trusted platform and a blockchain, wherein the application program instance (AE) and the state service instance (SE) run on the trusted platform, the application program instance processes a request of a client and returns corresponding output, and the state service instance improves state continuity protection for the application program instance.

Specifically, in this embodiment, the specific functions of the decentralized trust based TEE state continuity protection system under the public cloud and the modules thereof may also refer to corresponding descriptions in the decentralized trust based TEE state continuity protection method under the public cloud, which are not described herein again.

Based on the embodiment, the invention also provides an intelligent terminal, and a schematic block diagram of the intelligent terminal can be shown in fig. 11. The intelligent terminal comprises a memory, a processor and a decentralized trust-based TEE state continuity protection program under the public cloud, wherein the decentralized trust-based TEE state continuity protection program is stored in the memory and can run on the processor, and when being executed by the processor, the decentralized trust-based TEE state continuity protection program under the public cloud realizes the steps of the decentralized trust-based TEE state continuity protection method under the public cloud.

It will be understood by those skilled in the art that the block diagram shown in fig. 11 is only a block diagram of a part of the structure related to the solution of the present invention, and does not constitute a limitation of the intelligent terminal to which the solution of the present invention is applied, and in particular, the intelligent terminal may include more or less components than those shown in the figure, or combine some components, or have a different arrangement of components.

In one embodiment, the decentralized trust based under-public-cloud TEE state continuity protection program when executed by the processor performs the following operations:

initializing the state service instance based on the block chain;

updating a state request of the application instance based on the encrypted transport and the session key;

controlling the application program instance to read the latest state of the state service instance;

when the state service instance is restarted, recovering the state of the state service instance based on a session key; and when the application program instance is restarted, restoring the state of the application program instance based on the sealing state data of the operating system.

The embodiment of the invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a decentralized trust-based TEE state continuity protection program under the public cloud, and when the decentralized trust-based TEE state continuity protection program under the public cloud is executed by a processor, the steps of the decentralized trust-based TEE state continuity protection method under the public cloud are realized.

It should be understood that, the sequence numbers of the steps in the embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the functional units and modules are described as examples, and in practical applications, the functions may be distributed as required by different functional units and modules, that is, the internal structure of the apparatus may be divided into different functional units or modules to implement all or part of the functions described above. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only used for distinguishing one functional unit from another, and are not used for limiting the protection scope of the present invention. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the embodiments, the description of each embodiment has its own emphasis, and reference may be made to the related description of other embodiments for parts that are not described or recited in any embodiment.

Those of ordinary skill in the art would appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

In the embodiments provided in the present invention, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other ways. For example, the above-described embodiments of the apparatus/terminal device are merely illustrative, and for example, the division of the modules or units is only one logical division, and the actual implementation may be implemented by another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed.

The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow in the method according to the embodiments of the present invention may also be implemented by a computer program, which may be stored in a computer-readable storage medium and used for instructing related hardware, and when the computer program is executed by a processor, the steps of the embodiments of the method may be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U.S. disk, removable hard disk, magnetic diskette, optical disk, computer Memory, read-Only Memory (ROM), random Access Memory (RAM), electrical carrier wave signal, telecommunications signal, and software distribution medium, etc. It should be noted that the contents contained in the computer-readable storage medium can be increased or decreased as appropriate according to the requirements of legislation and patent practice in the jurisdiction.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art; the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit and scope of the embodiments of the present invention, and they should be construed as being included therein.

Claims

1. A decentralized trust-based TEE state continuity protection method under a public cloud is characterized by comprising the following steps:

initializing the state service instance based on the block chain;

controlling the application program instance to read the latest state stored in the state service instance;

when the state service instance is restarted, recovering the state of the state service instance based on a session key; when the application program instance is restarted, recovering the state of the application program instance based on the sealing state data of the operating system;

the initializing the state service instance based on the block chain specifically includes:

controlling each state service instance to send a write request to the blockchain, and when a confirmation character from the blockchain is received, controlling each state service instance to create a local memory, wherein the local memory comprises state service instance state tables of other state service instance state entries and an empty application program instance state table;

controlling a local state service instance to place the public key list in a local memory of the local state service instance to generate a state service instance configuration table, and controlling the local state service instance to establish a pairwise session key with other state service instances by running a verified key protocol;

sealing and storing the key pair of the local state service instance, the state service instance configuration table and the application program instance state table;

the updating the state request of the application program instance based on the encrypted transmission and the session key specifically includes:

when the local state service instance receives more than f +1 reply messages, the local state service instance sends a decision message to other state service instances, wherein f is a fault tolerance number of a common node;

after other state service instances receive the decision message, checking whether the other state service instances reply the preparation message or not, and if so, controlling the state service instances to send back a confirmation character containing the state abstract;

when the local state service instance receives more than f +1 confirmation characters, controlling the local state service instance to update the state abstract of the application program instance and reply the confirmation characters containing the state abstract to the application program instance;

2. The decentralized trust based public under-cloud TEE state continuity protection method according to claim 1, wherein the decentralized trust based public under-cloud TEE state continuity protection method further comprises:

writing the identity identification number and the public key of the state service instance to the block chain through a first interface of the block chain, and recording initialization information;

inquiring initialization information on the block chain through a second interface of the block chain according to the identity identification number and the public key of the state service instance;

when the application program instance updates the state abstract through a third interface of the block chain, requesting whether the update is legal or not from the state service instance;

and acquiring the state abstract of the application program instance through a fourth interface of the block chain.

3. The decentralized trust based TEE state continuity protection method under public cloud according to claim 1, wherein the controlling the application instance to read the latest state of the state service instance specifically comprises:

and when f +1 state digests are received, selecting the state digest with the largest index as the state digest of the local state service instance.

4. The method according to claim 3, wherein recovering the state of the stateful service instance based on the session key when the stateful service instance is restarted comprises:

controlling the restarted state service instance to acquire state digests of the state service instance and other state service instances;

5. The decentralized trust based TEE state continuity protection method under public cloud according to claim 4, wherein when the application instance is restarted, recovering the state of the application instance based on the sealing state data of the operating system specifically comprises:

6. A decentralized trust based TEE state continuity protection system under a public cloud, the decentralized trust based TEE state continuity protection system under the public cloud comprising:

the restarting module is used for recovering the state of the state service instance based on the session key when the state service instance is restarted; the application program instance is also used for recovering the state of the application program instance based on the sealing state data of the operating system when the application program instance is restarted;

when the local state service instance receives more than f +1 reply messages, the local state service instance sends a decision message to other state service instances, wherein f is the fault tolerance number of the common node;

after other state service instances receive the decision message, checking whether the other state service instances reply to the preparation message or not, and if so, controlling the state service instances to send back confirmation characters containing state abstracts;

7. An intelligent terminal, comprising a memory, a processor, and a decentralized trust based public under-cloud TEE state continuity protection program stored on the memory and executable on the processor, wherein the decentralized trust based public under-cloud TEE state continuity protection program when executed by the processor implements the steps of the decentralized trust based public under-cloud TEE state continuity protection method according to any one of claims 1-5.

8. A computer-readable storage medium, wherein the computer-readable storage medium has stored thereon a decentralized trust based TEE state continuity protection program under a public cloud, and wherein the decentralized trust based TEE state continuity protection program, when executed by a processor, implements the steps of the decentralized trust based TEE state continuity protection method under a public cloud according to any one of claims 1 to 5.