A method and system for distributed state synchronization based on a trusted execution environment

Abstract

The specification provides a distributed state synchronization method based on a trusted execution environment, applied to a distributed system containing N TEE containers, at least including a first TEE container, the method comprising: the first TEE container determining a second TEE container from the N TEE containers based on a gossip protocol; the first TEE container and the second TEE container respectively confirming whether the other party is trusted based on a remote attestation mechanism; if both parties confirm that the other party is trusted, both parties determine a first session key based on a preset key agreement protocol; both parties determine first incremental data missing in first state data in the first TEE container relative to second state data in the second TEE container; the second TEE container encrypts the first incremental data through the first session key to obtain first encrypted data and sends the first encrypted data to the first TEE container; the first TEE container decrypts the first encrypted data through the first session key to restore the first incremental data, and updates the first state data through the first incremental data.

Description

Technical Field

[0001] This specification relates to the field of confidential container technology, and more particularly to a distributed state synchronization method and system based on a trusted execution environment. Background Technology

[0002] With the popularization and in-depth application of cloud computing technology, more and more mission-critical applications are being deployed in distributed systems composed of multiple independent computing nodes to leverage the elastic resources and scalability provided by the cloud environment. In distributed systems, distributed state synchronization schemes refer to the technical mechanisms that ensure the data state (state) on all nodes remains consistent or eventually consistent in a distributed system composed of multiple independent nodes (servers, containers, or processes), undertaking the task of efficiently and accurately propagating local state changes to the entire system. However, when distributed systems are used to store or process sensitive data (such as financial transaction records, key management information, etc.), existing state synchronization schemes have the following shortcomings.

[0003] On the one hand, existing solutions mainly rely on software-level encryption, lacking hardware-level security guarantees. This makes them vulnerable to malicious host administrators stealing sensitive state data from memory through memory dumping or side-channel attacks. On the other hand, while existing decentralized state synchronization mechanisms achieve a distributed architecture at the data propagation level, they often lack strict end-to-end encryption guarantees in the node authentication process, or they have to rely excessively on centralized certificate authorities. This architecture not only introduces single-point-of-failure risks—once the service is interrupted or compromised, the entire cluster's trust system will be paralyzed—but also leads to complex and cumbersome certificate management. In cloud-native environments, facing scenarios of frequent container creation and destruction and large-scale dynamic scaling, traditional certificate application, distribution, rotation, and revocation mechanisms are difficult to automate and are slow to respond. This delayed certificate management easily leads to expired certificates not being revoked in time or new nodes not being able to obtain legitimate identities immediately, leaving security vulnerabilities that allow malicious nodes to impersonate, infiltrate, and steal synchronization data. Summary of the Invention

[0004] The embodiments in this specification aim to provide a distributed state synchronization method based on a trusted execution environment (TEE). This method utilizes a dynamic node trust mechanism with remote proof, eliminating the need for a pre-defined list of trusted nodes and overcoming the problems of poor node scalability and high node management costs inherent in traditional distributed state synchronization schemes. Furthermore, by using the Gossip protocol combined with encrypted incremental state data transmission within the TEE from container to container, the confidentiality of container-to-container state data synchronization can be ensured while reducing state synchronization latency, thereby improving state synchronization efficiency and addressing the shortcomings of existing technologies.

[0005] According to the first aspect, a distributed state synchronization method based on a trusted execution environment is provided, applied to a distributed system containing N TEE containers, wherein the N TEE containers include at least a first TEE container; the method includes:

[0006] The first TEE container determines the second TEE container from the N TEE containers based on the rumor protocol;

[0007] The first TEE container and the second TEE container confirm whether the other is trustworthy based on a remote authentication mechanism. If both the first TEE container and the second TEE container confirm that the other is trustworthy, then the first TEE container and the second TEE container determine the first session key based on a preset key negotiation protocol.

[0008] The first TEE container and the second TEE container determine the first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container;

[0009] The second TEE container encrypts the first incremental data using the first session key to obtain the first encrypted data, and sends the first encrypted data to the first TEE container.

[0010] The first TEE container decrypts the first encrypted data using the first session key, restores the first incremental data, and updates the first state data using the first incremental data.

[0011] In one possible implementation, determining the second TEE container from the N TEE containers includes: determining the second TEE container from the N TEE containers using a peer node random selection algorithm.

[0012] In one possible implementation, the method further includes: the first TEE container and the second TEE container, determining second incremental data that is missing from the second state data stored in the second TEE container relative to the first state data stored in the first TEE container;

[0013] The first TEE container encrypts the second incremental data using the first session key to obtain the second encrypted data and sends it to the second TEE container;

[0014] The second TEE container decrypts the second encrypted data using the first session key, restores the second incremental data, and updates the second state data using the second incremental data.

[0015] In one possible implementation, the second TEE container encrypts the first incremental data using a first session key to obtain first encrypted data, including:

[0016] The second TEE container serializes the first incremental data to obtain the first serialized data;

[0017] The first serialized data is encrypted using the first session key to obtain the first encrypted data;

[0018] The first TEE container decrypts the first encrypted data using the first session key to restore the first incremental data, including:

[0019] The first TEE container decrypts the first encrypted data using the first session key to obtain the first serialized data, and then deserializes the first serialized data to restore the first incremental data.

[0020] In one possible implementation, sending the first encrypted data to the first TEE container includes:

[0021] The first encrypted data is sent to the first TEE container via Remote Procedure Call (RPC).

[0022] In one possible implementation, the first TEE container and the second TEE container determine a first incremental data point where the first state data stored in the first TEE container is missing relative to the second state data stored in the second TEE container, including:

[0023] The first TEE container sends the first digest corresponding to the first state data to the second TEE container;

[0024] The second TEE container determines the first incremental data based on the second digest corresponding to the first digest and the second state data.

[0025] In one possible implementation, the first TEE container and the second TEE container determine a first incremental data point where the first state data contained in the first TEE container is missing relative to the second state data contained in the second TEE container, including:

[0026] The first TEE container sends the first version corresponding to the first state data to the second TEE container;

[0027] The second TEE container determines the first incremental data based on the first version and the second version corresponding to the second state data.

[0028] In one possible implementation, the distributed system is a Kubernetes system.

[0029] The first TEE container, based on a rumor protocol, determines the second TEE container from the N TEE containers, including:

[0030] The first TEE container listens for container group events in the Kubernetes system through the Kubernetes system's API server;

[0031] The first peer container set is determined based on the container group event, and the first peer container set contains M TEE containers out of the N TEE containers;

[0032] Based on the rumor protocol, the second TEE container is determined from the M TEE containers.

[0033] In one possible implementation, the first TEE container and the second TEE container respectively verify each other's trustworthiness based on a remote authentication mechanism, including:

[0034] The first TEE container obtains the first remote authentication report sent by the second TEE container, and the first TEE container confirms whether the second TEE container is trustworthy based on the first remote authentication report.

[0035] The second TEE container obtains the second remote verification report sent by the first TEE container, and the second TEE container confirms whether the first TEE container is trustworthy based on the second remote verification report.

[0036] According to the second aspect, a distributed state synchronization system based on a Trusted Execution Environment (TEE) is provided, comprising N TEE containers, wherein at least one of the N TEE containers is a first TEE container, wherein...

[0037] The first TEE container is configured to determine the second TEE container from the N TEE containers based on a rumor protocol.

[0038] The first TEE container and the second TEE container are further configured to verify whether the other party is trustworthy based on a remote authentication mechanism; if both the first TEE container and the second TEE container verify that the other party is trustworthy, then the first TEE container and the second TEE container determine the first session key based on a preset key negotiation protocol.

[0039] The first TEE container and the second TEE container are further configured to determine a first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container;

[0040] The second TEE container is further configured to encrypt the first incremental data using the first session key to obtain first encrypted data, and send the first encrypted data to the first TEE container.

[0041] The first TEE container is further configured to decrypt the first encrypted data using the first session key, restore the first incremental data, and update the first state data using the first incremental data.

[0042] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0043] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0044] By utilizing one or more of the methods, systems, computing devices, and storage media mentioned above, a dynamic node trust mechanism based on remote proof can overcome the problems of poor node scalability and high node management costs associated with traditional distributed state synchronization schemes, without the need for a pre-defined list of trusted nodes. Furthermore, by using the Gossip protocol combined with encrypted incremental state data transmission within the TEE from container to container, the confidentiality of container-to-container state data synchronization can be ensured while reducing state synchronization latency, thereby improving state synchronization efficiency. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1A flowchart illustrating a distributed state synchronization method based on a trusted execution environment according to an embodiment of this specification is shown.

[0047] Figure 2 This diagram illustrates the confirmation of a second TEE container in a Kubernetes system according to an embodiment of this specification.

[0048] Figure 3 A schematic diagram showing the synchronization state data of the first TEE container and the second TEE container according to an embodiment of this specification;

[0049] Figure 4 This diagram illustrates the determination of incremental data according to an embodiment of this specification.

[0050] Figure 5 A schematic diagram showing the synchronization state data of the first TEE container and the second TEE container according to another embodiment of this specification is provided.

[0051] Figure 6 This diagram illustrates a structure of a distributed state synchronization system based on a trusted execution environment, according to an embodiment of this specification. Detailed Implementation

[0052] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0053] In this specification, a Trusted Execution Environment (TEE) refers to a hardware-provided secure zone isolated from the main operating system, offering integrity protection for code execution and confidentiality protection for data. Common TEE implementation technologies include Software Guard Extensions (SGX), Trust Domain Extensions (TDX), and Trust Zones. A core characteristic of TEEs is that even if the host's hypervisor, operating system (OS), or even the cloud service provider is untrusted, the code and data within the TEE remain confidential and intact. Containers deployed within a TEE are called TEE containers or Confidential Containers. The Gossip Protocol is a decentralized communication protocol where nodes periodically exchange information with randomly selected other nodes, allowing information to spread rapidly through the network like a virus, providing high availability and resistance to network partitioning. Remote attestation refers to the TEE container generating a cryptographically signed report to a remote party, proving that it runs on real hardware and that the loaded software image has not been tampered with. A session key is a temporary cryptographic key established between two communicating entities through secure negotiation, used to protect data transmission security during a single session. Delta state refers to the portion of data that has changed since the last synchronization, not the entire dataset.

[0054] Currently, there are several typical distributed state synchronization schemes. One type is a state synchronization scheme based on traditional distributed consensus algorithms, such as those based on Raft or Paxos. These schemes use a majority voting mechanism to replicate state logs or state changes across multiple nodes to achieve consistent state information synchronization. However, their operation typically relies on software-level logical protection and lacks hardware-level security guarantees. In cloud computing environments, attackers with host machine privileges can directly read sensitive state data from node memory through memory dumping, leading to data leaks. More importantly, these schemes usually require pre-configured static lists of trusted nodes, making them ill-suited to the frequent dynamic creation (expansion) and destruction (shrinkage) of containers in cloud computing environments. Whenever a container expands or shrinks, manual intervention is required to update the global configuration file, increasing operational costs and potentially causing container service interruptions or delays due to delayed configuration updates.

[0055] Another approach is a distributed state synchronization scheme based on the traditional gossip protocol. This type of scheme utilizes a mechanism where nodes periodically and randomly exchange state information (such as version vectors and data digests) to achieve rapid dissemination of state data and eventual consistency synchronization within the network. However, traditional gossip-based distributed state synchronization schemes often lack strict authentication mechanisms. Malicious nodes can easily impersonate legitimate nodes, illegally access the network, and spread false state updates, thereby contaminating the data throughout the distributed system.

[0056] Another approach is a distributed state synchronization scheme based on Public Key Infrastructure (PKI) to build secure channels, such as state synchronization schemes based on TLS / SSL certificate systems or the Kerberos protocol. These schemes rely on a centralized Certificate Authority (CA) to distribute identity certificates and session keys to participating nodes to establish an encrypted transmission channel and synchronize state data through this channel. This approach also has the following problems: a single point of failure risk exists; if the CA is attacked or crashes, node authentication in the entire state synchronization network may be paralyzed, leading to synchronization interruption. Furthermore, in large-scale dynamic clusters, centralized certificate management incurs significant operational overhead, and its cumbersome rotation and revocation processes are difficult to adapt to the high-frequency node changes in cloud computing environments in real time. This response lag can cause node certificates to expire before updates are completed, resulting in synchronization failure. Furthermore, this approach can only protect the security of state data during in-transit, but cannot protect the data during in-use processing in node memory. Therefore, it cannot prevent attackers with host privileges from obtaining plaintext state information through memory attacks or side-channel attacks.

[0057] Another approach is state synchronization based on a distributed configuration management system, such as a Kubernetes ConfigMap-based scheme. This typically relies on a persistent storage database (e.g., etcd) for state storage and distribution. This type of solution stores state data in the persistent storage database and uses a data push mechanism (e.g., the watch mechanism) to push it to each node for synchronization. However, this approach also has the following problems: state data is often stored in plaintext during persistent storage and transmission, and there is a lack of hardware-based node authentication mechanisms. Any node connected to the cluster can pull the state, easily leading to state data leakage. Furthermore, users with administrator privileges can usually access all state data, making it impossible to prevent state information leakage due to abuse of administrator privileges.

[0058] In summary, existing distributed state synchronization solutions have the following drawbacks: Distributed state synchronization solutions based on traditional consensus algorithms or the Gossip protocol lack hardware-level isolation mechanisms, making them vulnerable to memory attacks and suffering from poor node authentication security. Distributed state synchronization solutions based on public key infrastructure are overly reliant on centralized institutions and are unsuitable for the high-frequency node changes in cloud computing environments. Furthermore, they only protect data during transmission, not during data usage. Cloud-native configuration solutions, due to their centralized plaintext storage architecture, are susceptible to global state data leaks caused by attacks on the storage service side, and they also fail to protect "data in use."

[0059] To address the aforementioned issues, this specification provides a distributed state synchronization method based on a Trusted Execution Environment (TEE). This method is built upon a distributed system containing multiple TEE containers. The communicating parties utilize the remote authentication technology of the TEE for decentralized authentication based on a hardware root of trust, avoiding the reliance on static node lists or centralized certificate authorities found in traditional solutions. Furthermore, after both parties have confirmed that the other is a trusted node, they can negotiate and generate a session key, determine the incremental portion of their respective state data, and encrypt only the incremental portion required for the other party's state data before transmitting it to the other party for use in updating their state data.

[0060] This scheme has the following advantages: First, the dynamic node trust mechanism based on remote proof eliminates the need for a pre-defined list of trusted nodes, making it more effective in adapting to scenarios where nodes frequently expand and shrink in distributed systems. It overcomes the problems of poor node scalability and high node management costs associated with traditional distributed state synchronization schemes based on consensus algorithms and public key infrastructure. Second, by using encrypted data propagation based on the Gossip protocol combined with incremental synchronization, it can reduce state synchronization latency and improve state synchronization efficiency while ensuring the confidentiality of container-to-container data transmission. Third, the TEE environment prevents host administrators from stealing or tampering with sensitive state data in memory, effectively resisting memory dumps and side-channel attacks, and solving the problem that distributed state synchronization schemes cannot protect the security of synchronized "data in use."

[0061] Figure 1 A flowchart illustrating a distributed state synchronization method based on a Trusted Execution Environment (TEE) according to an embodiment of this specification is shown. As shown in Figure 1, the method is applied to a distributed system containing N TEE containers, wherein at least a first TEE container is included. Figure 1 As shown, the method includes at least the following steps:

[0062] Step S101: The first TEE container determines the second TEE container from N TEE containers based on the rumor protocol;

[0063] Step S103: The first TEE container and the second TEE container confirm whether the other is trustworthy based on the remote authentication mechanism; if both the first TEE container and the second TEE container confirm that the other is trustworthy, then the first TEE container and the second TEE container determine the first session key based on the preset key negotiation protocol.

[0064] Step S105: For the first TEE container and the second TEE container, determine the first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container.

[0065] Step S107: The second TEE container encrypts the first incremental data using the first session key to obtain the first encrypted data, and sends the first encrypted data to the first TEE container.

[0066] In step S109, the first TEE container decrypts the first encrypted data using the first session key, restores the first incremental data, and updates the first state data using the first incremental data.

[0067] First, in step S101, the first TEE container can determine the second TEE container from N TEE containers based on the gossip protocol. As mentioned above,

[0068] In different embodiments, the specific method for determining the second TEE container from N TEE containers can vary. In one embodiment, the distributed system can be a Kubernetes system. Kubernetes (K8s) is a distributed container orchestration system used for automating the deployment, scaling, and management of containerized applications. Furthermore, the first TEE container can listen to container group events in the Kubernetes system through the Kubernetes system's API server; determine a first peer container set based on the container group events, the first peer container set containing M TEE containers out of the N TEE containers; and determine the second TEE container from the M TEE containers based on a rumor protocol.

[0069] Figure 2 This diagram illustrates the confirmation of a second TEE container in a Kubernetes system according to an embodiment of this specification. Figure 2In the example shown, N TEE containers can be deployed on the Kubernetes system. The first TEE container can then listen to the Kubernetes API server's Pod events to obtain a set of running TEE containers in the current cluster, thus creating a peer container set. This set can contain M running TEE containers out of the N TEE containers, where M ≤ N. Subsequently, the first TEE container, for example, can use a peer node random selection algorithm to randomly select a second TEE container from these M TEE containers as the synchronization target. In this way, even when a new node is added or some nodes fail, the TEE node initiating synchronization can still adaptively determine a valid synchronization node to maintain the consistency of state data, solving the problems of traditional solutions that rely on statically configured node lists for synchronization and struggle with dynamic scaling of node size.

[0070] After the second TEE container is determined, the first TEE container and the second TEE container can, in step S103, verify each other's trustworthiness based on a remote authentication mechanism. If both the first TEE container and the second TEE container verify each other's trustworthiness, then the first TEE container and the second TEE container can determine the first session key based on a preset key negotiation protocol.

[0071] In different embodiments, the specific methods by which the first TEE container and the second TEE container verify each other's trustworthiness based on the remote authentication mechanism can differ. In one embodiment, the first TEE container obtains a first remote authentication report sent by the second TEE container, and the first TEE container verifies the trustworthiness of the second TEE container based on the first remote authentication report; the second TEE container obtains a second remote authentication report sent by the first TEE container, and the second TEE container verifies the trustworthiness of the first TEE container based on the second remote authentication report.

[0072] Figure 3 A schematic diagram illustrating the synchronization state data of the first TEE container and the second TEE container according to an embodiment of this specification is shown. Figure 3As shown, the first TEE container can send a proof request to the second TEE container. Within its TEE environment, the second TEE container generates a proof report containing its hardware fingerprint, software image hash, and runtime environment metrics. It then signs the report using the hardware's built-in private key, generating a first remote proof report, which it sends to the first TEE container. In different specific examples, depending on the specific type of TEE environment, this proof report can be generated using different specific CPU hardware instructions. In a specific example, such as in an SGX-based TEE environment, the EREPORT instruction can be called to generate the proof report. After receiving the report, the first TEE container can determine whether the second TEE container is trustworthy, i.e., whether the second TEE container is running on real, trusted hardware and whether the software has been tampered with. In one example, the first TEE container can, for instance, verify the validity of the signature using the public key corresponding to the second TEE container, and confirm whether the hardware fingerprint, hash value, and metric value in the report match their respective expected trusted values. If the signature is valid and the hardware fingerprint, hash value, and metric value all match their respective expected trusted values, then the second TEE container is confirmed to be running on real trusted hardware and its software has not been tampered with; that is, the second TEE container is trusted. Similarly, the second TEE container can also obtain and verify the second remote proof report sent by the first TEE container. Its verification method is similar to that of the first TEE container for the second remote proof report, and will not be described in detail here.

[0073] Once both parties have verified each other's reports and confirmed that the other is a trusted container, they can proceed to the key negotiation phase. During this phase, the first TEE container and the second TEE container can negotiate a first session key. The specific method by which the first and second TEE containers negotiate the first session key can vary depending on the example. In one example, the first and second TEE containers can negotiate a symmetric session key based on a preset key exchange protocol, which serves as the first session key. The preset key exchange protocol can be different in different examples. In one example, the preset key exchange protocol could be, for example, the Diffie-Hellman key exchange protocol. This approach solves the problem of malicious nodes masquerading as legitimate nodes to infiltrate the network. Furthermore, this verification method is based on the hardware root of trust of each TEE environment, eliminating the need for any external centralized certification authority and resolving the problem of traditional verification methods relying on centralized CAs.

[0074] Next, in step S105, the first TEE container and the second TEE container can determine the first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container.

[0075] In different embodiments, the specific methods by which the first TEE container and the second TEE container determine the first incremental data can differ. In one embodiment, the first TEE container can send a first digest corresponding to the first state data to the second TEE container. The second TEE container determines the first incremental data based on the first digest and the second digest corresponding to the second state data, such as... Figure 4 As shown. In a specific example, the second TEE container can locally store a version state tree to store historical state data and its corresponding summaries (e.g., a version state index structure built based on a Merkle tree). The second TEE container can retrieve the difference branches or difference data blocks between the first and second state data from the version state tree using the first and second summaries, and determine the first incremental data (the missing or outdated data portion in the first TEE container) based on these difference data blocks. In this way, only the data summary needs to be transmitted to determine the incremental data of the second state data relative to the first state data.

[0076] In another embodiment, the first TEE container sends the first version corresponding to the first state data to the second TEE container. Then, the second TEE container determines the first incremental data based on the first version and the second version corresponding to the second state data. Specifically, the second TEE container can locally store a multi-version state log chain. Then, based on the first and second versions, it determines the state operation records between the first and second versions from the multi-version state log chain. Based on these state operation records, it determines the incremental data of the second version relative to the second version.

[0077] After obtaining the first incremental data, the second TEE container can, in step S107, encrypt the first incremental data using the first session key to obtain first encrypted data, and send it to the first TEE container. In one embodiment, the second TEE container can also serialize the first incremental data to obtain first serialized data. Then, the first serialized data is encrypted using the first session key to obtain first encrypted data.

[0078] In different implementations, the specific method by which the second TEE container sends the first encrypted data to the first TEE container can vary. In one embodiment, the second TEE container sends the first encrypted data to the first TEE container via a remote procedure call (RPC).

[0079] For example Figure 3As shown, after determining the first incremental data, the second TEE container first serializes the data within the TEE, converting it into a standard byte stream format to ensure the consistency of the data structure during transmission between different TEE containers. Then, using the first session key negotiated in step S102, it performs encryption operations on the serialized data to generate the first encrypted data. Since the encryption operation is completed within the memory area protected by the TEE, the key and plaintext data are never exposed in the unprotected host memory. After encryption, the second TEE container can send the first encrypted data to the first TEE container via Remote Procedure Call (RPC). Because the data is encrypted before leaving the TEE, even if the data packet is intercepted by a malicious node or man-in-the-middle during network transmission, the attacker cannot obtain the plaintext information.

[0080] After receiving the first encrypted data, the first TEE container can decrypt the first encrypted data using the first session key in step S109, restore the first incremental data, and update the first state data using the first incremental data.

[0081] In the embodiment described above where the second TEE container serializes incremental data, the first TEE container can decrypt the first encrypted data using the first session key to obtain the first serialized data, and then deserialize the first serialized data to restore the first incremental data. That is, after receiving the first encrypted data, the first TEE container decrypts it using the first session key to obtain the serialized incremental data. Subsequently, the data is deserialized to restore the original first incremental data. Then, the local first state data is updated using the restored first incremental data.

[0082] This method of transmitting incremental data not only synchronizes state data between different TEE containers, but also significantly reduces the amount of data that needs to be transmitted. Especially in scenarios with large amounts of state data that change frequently, it greatly reduces bandwidth consumption during data transmission and significantly improves synchronization efficiency. Furthermore, during transmission, data exists only in plaintext within the TEE, while always remaining in encrypted form outside the TEE, effectively resisting memory dump attacks and side-channel attacks.

[0083] In practical applications, this process is usually bidirectional. The first TEE container also calculates the missing incremental data in the second TEE container, encrypts it, and sends it to the second TEE container, thus achieving eventual consistency between the two states. Therefore, in one embodiment, the first and second TEE containers can also determine the missing second incremental data relative to the first state data stored in the first TEE container. Furthermore, the first TEE container can encrypt the second incremental data using a first session key to obtain second encrypted data and send it to the second TEE container. The second TEE container decrypts the second encrypted data using the first session key, restores the second incremental data, and updates the second state data using the second incremental data, such as... Figure 5 As shown.

[0084] According to another embodiment, a distributed state synchronization system based on a trusted execution environment is also provided. Figure 6 shows an architecture diagram of a distributed state synchronization system based on a trusted execution environment according to an embodiment of this specification. Figure 6 As shown, the system 600 contains N TEE containers, and at least one of the N TEE containers is a first TEE container.

[0085] The first TEE container 601 is configured to determine the second TEE container 602 from the N TEE containers based on a rumor protocol.

[0086] The first TEE container 601 and the second TEE container 602 are further configured to verify whether the other party is trustworthy based on a remote authentication mechanism; if both the first TEE container and the second TEE container verify that the other party is trustworthy, then the first TEE container and the second TEE container determine the first session key based on a preset key negotiation protocol.

[0087] The first TEE container 601 and the second TEE container 602 are further configured to determine the first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container.

[0088] The second TEE container 602 is further configured to encrypt the first incremental data using the first session key to obtain first encrypted data, and send the first encrypted data to the first TEE container.

[0089] The first TEE container 601 is further configured to decrypt the first encrypted data using the first session key, restore the first incremental data, and update the first state data using the first incremental data.

[0090] In another aspect, embodiments of this specification provide a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any of the methods described above.

[0091] In another aspect, embodiments of this specification provide a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement any of the methods described above.

[0092] It should be understood that the descriptions such as "first" and "second" in this article are merely for the sake of simplicity in description and to distinguish similar concepts, and do not have any other limiting function.

[0093] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0094] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0095] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0096] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0097] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0098] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0099] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0100] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0101] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0102] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0103] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0104] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0105] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0106] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0107] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A distributed state synchronization method based on a trusted execution environment, applied to a distributed system containing N TEE containers, wherein, The N TEE containers include at least a first TEE container; the method includes: The first TEE container determines the second TEE container from the N TEE containers based on the rumor protocol; The first TEE container and the second TEE container confirm whether the other is trustworthy based on a remote authentication mechanism. If both the first TEE container and the second TEE container confirm that the other is trustworthy, then the first TEE container and the second TEE container determine the first session key based on a preset key negotiation protocol. The first TEE container and the second TEE container determine the first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container; The second TEE container encrypts the first incremental data using the first session key to obtain the first encrypted data, and then sends the first encrypted data to the first TEE container. The first TEE container decrypts the first encrypted data using the first session key, restores the first incremental data, and updates the first state data using the first incremental data.

2. The method according to claim 1, wherein, Determining the second TEE container from the N TEE containers includes: determining the second TEE container from the N TEE containers using a peer node random selection algorithm.

3. The method according to claim 1, further comprising: The first TEE container and the second TEE container determine the second incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the first TEE container. The first TEE container encrypts the second incremental data using the first session key to obtain the second encrypted data and sends it to the second TEE container; The second TEE container decrypts the second encrypted data using the first session key, restores the second incremental data, and updates the second state data using the second incremental data.

4. The method according to claim 1, wherein, The second TEE container encrypts the first incremental data using the first session key to obtain the first encrypted data, including: The second TEE container serializes the first incremental data to obtain the first serialized data; The first serialized data is encrypted using the first session key to obtain the first encrypted data; The first TEE container decrypts the first encrypted data using the first session key to restore the first incremental data, including: The first TEE container decrypts the first encrypted data using the first session key to obtain the first serialized data, and then deserializes the first serialized data to restore the first incremental data.

5. The method according to claim 1, wherein, Sending the first encrypted data to the first TEE container includes: The first encrypted data is sent to the first TEE container via Remote Procedure Call (RPC).

6. The method according to claim 1, wherein, The first TEE container and the second TEE container determine the first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container, including: The first TEE container sends the first digest corresponding to the first state data to the second TEE container; The second TEE container determines the first incremental data based on the second digest corresponding to the first digest and the second state data.

7. The method according to claim 1, wherein, The first TEE container and the second TEE container determine the first incremental data that is missing from the first state data contained in the first TEE container relative to the second state data contained in the second TEE container, including: The first TEE container sends the first version corresponding to the first state data to the second TEE container; The second TEE container determines the first incremental data based on the first version and the second version corresponding to the second state data.

8. The method according to claim 1, wherein, The distributed system is the Kubernetes system. The first TEE container, based on a rumor protocol, determines the second TEE container from the N TEE containers, including: The first TEE container listens for container group events in the Kubernetes system through the Kubernetes system's API server; The first peer container set is determined based on the container group event, and the first peer container set contains M TEE containers out of the N TEE containers; Based on the rumor protocol, the second TEE container is determined from the M TEE containers.

9. The method according to claim 1, wherein, The first TEE container and the second TEE container respectively verify each other's trustworthiness based on a remote authentication mechanism, including: The first TEE container obtains the first remote authentication report sent by the second TEE container, and the first TEE container confirms whether the second TEE container is trustworthy based on the first remote authentication report. The second TEE container obtains the second remote verification report sent by the first TEE container, and the second TEE container confirms whether the first TEE container is trustworthy based on the second remote verification report.

10. A distributed state synchronization system based on a Trusted Execution Environment (TEE), comprising N TEE containers, wherein at least one of the N TEE containers is a first TEE container, wherein... The first TEE container is configured to determine the second TEE container from the N TEE containers based on a rumor protocol. The first TEE container and the second TEE container are further configured to verify whether the other party is trustworthy based on a remote authentication mechanism; if both the first TEE container and the second TEE container verify that the other party is trustworthy, then the first TEE container and the second TEE container determine the first session key based on a preset key negotiation protocol. The first TEE container and the second TEE container are further configured to determine a first incremental data that is missing from the first state data stored in the first TEE container relative to the second state data stored in the second TEE container; The second TEE container is further configured to encrypt the first incremental data using the first session key to obtain first encrypted data, and send the first encrypted data to the first TEE container. The first TEE container is further configured to decrypt the first encrypted data using the first session key, restore the first incremental data, and update the first state data using the first incremental data.

11. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-9.

12. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-9.

Images