WO2024050869A1 - 基于去中心化信任的公有云下tee状态连续性保护方法 - Google Patents

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

Info

Publication number
WO2024050869A1
WO2024050869A1 PCT/CN2022/119945 CN2022119945W WO2024050869A1 WO 2024050869 A1 WO2024050869 A1 WO 2024050869A1 CN 2022119945 W CN2022119945 W CN 2022119945W WO 2024050869 A1 WO2024050869 A1 WO 2024050869A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
status
instance
service instance
local
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/119945
Other languages
English (en)
French (fr)
Inventor
张殷乾
彭维
牛健宇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Southern University of Science and Technology
Original Assignee
Southern University of Science and Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Southern University of Science and Technology filed Critical Southern University of Science and Technology
Publication of WO2024050869A1 publication Critical patent/WO2024050869A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries

Definitions

  • the present invention relates to the field of computer technology, and in particular to a decentralized trust-based TEE state continuity protection method, system, intelligent terminal and computer-readable storage medium under public cloud.
  • TEE Trusted Execution Environment
  • Amazon Cloud, Google Cloud, and Facebook Cloud Platform use TEE technology to provide users with confidential computing services.
  • TEE-protected applications will still be subject to Rollback attack or fork attack. Through these attacks, the attacker can roll back the state of TEE to an outdated version or fork it into multiple versions, causing the state continuity of TEE to be destroyed.
  • a hardware trusted counter is usually used to provide a secure container. Remote users upload code and data into the secure container. When performing calculations on the container, the secure container is used to protect the confidentiality and integrity of the data, but the hardware The status updating and reading speed of trusted counters is slow and cannot meet the requirements for updating status in the cloud environment.
  • the main purpose of the present invention is to provide a method for protecting TEE status continuity under public cloud based on decentralized trust, aiming to solve the problem that the status updating and reading speed of hardware trusted counters in the existing technology is slow and cannot satisfy the cloud environment. Issues with the requirement to update status.
  • the first aspect of the present invention provides a decentralized trust-based TEE state continuity protection method under the public cloud.
  • the decentralized trust-based TEE state continuity protection method under the public cloud includes: based on zone The blockchain initializes the state service instance; updates the state request of the application instance based on encrypted transmission and session key; controls the application instance to read the latest state stored in the state service instance; when the state service When the instance is restarted, the state of the state service instance is restored based on the session key; when the application instance is restarted, the state of the application instance is restored based on the sealed state data of the operating system.
  • the decentralized trust-based TEE state continuity protection method under the public cloud also includes: writing the identity number and public key of the state service instance to the first interface of the blockchain. on the blockchain and record the initialization information; query the initialization information on the blockchain according to the identity number and public key of the status service instance through the second interface of the blockchain; through the block When the application instance updates the status summary, the third interface of the chain requests the status service instance whether the update is legal; and obtains the status summary of the application instance through the fourth interface of the blockchain.
  • the initialization process of the status service instance based on the blockchain includes:
  • Control the local state service instance to place the public key list into the local memory of the local state service instance to generate a state service instance configuration table, and control the local state service instance to interact with other state services by running a verified key agreement Instance establishes pairwise session keys;
  • the status request for updating the application instance based on encrypted transmission and session key specifically includes:
  • the application instance When the application instance receives a user request, seal and store the state snapshot of the application instance on disk, update the state summary of the application instance, and send a state update request to the local state service instance;
  • control the local status service instance When processing the status update request, control the local status service instance to send the status update request to the local status service instance and other status service instances;
  • the local status service instance and other status service instances When the local status service instance and other status service instances receive the status update request, update the status summary of the local status service instance in the status memory of the local status service instance and other status service instances and send a reply message;
  • the local state service instance When the local state service instance receives more than f+1 of the reply messages, the local state service instance sends a decision message to other state service instances, where f is the fault tolerance number of the consensus node;
  • the local status service instance When the local status service instance receives more than f+1 of the confirmation characters, control the local status service instance to update the status summary of the application instance and reply to the application instance a confirmation character containing the status summary. ;
  • the application instance When the application instance receives the confirmation character, it updates its status to the latest status and publishes the relevant output.
  • controlling the application instance to read the latest status of the status service instance specifically includes:
  • the status digest with the largest index is selected as the status digest of the local status service instance.
  • restoring the status of the status service instance based on the session key specifically includes:
  • the state of the application instance is restored based on the sealed status data of the operating system, specifically including:
  • Control the application instance to obtain the sealed status data of the operating system, match the sealed status data with the latest status summary, and if the match is successful, update the status summary of the application instance after restarting and publish the output .
  • a second aspect of the present invention provides a decentralized trust-based TEE state continuity protection system under the public cloud, which is characterized in that the decentralized trust-based TEE state continuity protection system under the public cloud includes:
  • Initialization module used to initialize status service instances based on the blockchain
  • a status update module for updating status requests for application instances based on encrypted transport and session keys
  • a status reading module used to control the application instance to read the latest status of the status service instance
  • a restart module configured to restore the state of the state service instance based on the session key when the state service instance is restarted; and also used to restore the state of the state service instance based on the sealed state data of the operating system when the application instance is restarted. Describes the status of the application instance.
  • a third aspect of the present invention provides an intelligent terminal, which includes a memory, a processor, and decentralized trust-based TEE state continuity in a public cloud that is stored in the memory and can be run on the processor. Protection program, when the decentralized trust-based TEE state continuity protection program under the public cloud is executed by the processor, the method for implementing any of the above decentralized trust-based TEE state continuity protection methods under the public cloud is implemented. step.
  • a fourth aspect of the present invention provides a computer-readable storage medium.
  • the computer-readable storage medium stores a TEE state continuity protection program under a public cloud based on decentralized trust.
  • the public cloud based on decentralized trust When the TEE state continuity protection program is executed by the processor, the steps of implementing the TEE state continuity protection method under the public cloud based on decentralized trust as described in any one of the above are implemented.
  • the embodiment of the present invention provides a decentralized trust-based TEE state continuity protection method under the public cloud.
  • the decentralized trust-based TEE state continuity protection method under the public cloud includes: block-based The chain initializes the state service instance; updates the state request of the application instance based on encrypted transmission and session key; controls the application instance to read the latest state of the state service instance; when the state service instance restarts , restoring the state of the state service instance based on the session key; when the application instance is restarted, restoring the state of the application instance based on the sealed state data of the operating system.
  • the present invention uses the blockchain to eliminate dependence on a centralized trusted entity, and only relies on the blockchain for initialization, which improves the speed of status update and reading.
  • Figure 1 is a schematic flowchart of a method for protecting TEE state continuity in a public cloud based on decentralized trust provided by an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of step S10 provided by the embodiment of the present invention.
  • Figure 3 is an interactive schematic diagram of the system initialization protocol provided by the embodiment of the present invention.
  • Figure 4 is a schematic diagram of the memory layout of a local state service instance provided by an embodiment of the present invention.
  • FIG. 5 is a schematic flow chart of step S20 provided by the embodiment of the present invention.
  • Figure 6 is an interactive schematic diagram of the status update protocol provided by the embodiment of the present invention.
  • FIG. 7 is a schematic flowchart of step S30 provided by the embodiment of the present invention.
  • Figure 8 is an interactive schematic diagram of the status reading protocol provided by the embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of the TEE state continuity protection system under the public cloud based on decentralized trust provided by an embodiment of the present invention.
  • FIG. 10 is a schematic architectural diagram of the TEE state continuity protection system under the public cloud based on decentralized trust provided by an embodiment of the present invention
  • Figure 11 is a functional block diagram of the internal structure of a smart terminal provided by an embodiment of the present invention.
  • Intel's Software Guard Extension allows applications to perform calculations directly without leaking confidential data.
  • Intel SGX provides a secure isolation environment enclave for protected computing and stores code and data in the enclave.
  • the enclave is a protected content container used to store application sensitive data. and code; in existing technology, confidential computing services are usually provided to users through TEE, aiming to enhance the security and privacy of customer outsourced data or code.
  • stateful applications in TEE rely on an untrusted operating system to store state, and therefore are subject to rollback or fork attacks. Their state may be rolled back to a correct but outdated version or forked into multiple versions. , causing damage to state continuity.
  • the protected module should recover to the same state before the state continuity is interrupted.
  • the present invention provides a decentralized trust-based TEE state continuity protection method under the public cloud.
  • This method relies on blockchain (i.e., decentralized trust) and TEE-based distributed
  • the system can provide high-performance state continuity protection for protected TEE application instances of cloud users. For example, it can support unlimited and rapid state updates of applications in the cloud TEE environment.
  • an embodiment of the present invention provides a schematic flow chart of a method for protecting TEE state continuity under a public cloud based on decentralized trust.
  • the TEE state continuity protection method under a public cloud based on decentralized trust Protection methods include:
  • Step S10 Initialize the status service instance based on the blockchain
  • Step S20 Update the status request of the application instance based on the encrypted transmission and session key
  • Step S30 Control the application instance to read its latest status stored in the status service instance
  • Step S40 When the state service instance is restarted, restore the state of the state service instance based on the session key; when the application instance is restarted, restore the state of the application instance based on the sealed state data of the operating system state.
  • the blockchain is only used in the initialization process, which not only establishes decentralized trust, eliminates dependence on the central trusted entity, but also minimizes interaction with the blockchain, allowing the system to reduce costly Blockchain interaction overhead, reducing costs.
  • this embodiment can be applied to a trusted platform managed by a cloud service provider, for example, a platform that supports Intel SGX.
  • a trusted platform that supports Intel SGX runs multiple enclave instances.
  • the enclave instances can be divided into the following two types:
  • AE Application Enclave
  • AE is an application created and uploaded by an independent software vendor to process customer requests and return corresponding output.
  • State service instance (State Enclave, SE) is an enclave instance that provides state continuity services for AE.
  • Each AE can be linked to a local SE (i.e. target SE) on the same platform and have its state continuity protected according to the method described.
  • the state service instance interacts with the blockchain through the blockchain interface.
  • the blockchain uses Byzantine fault-tolerant consensus as the backbone protocol, further realizing key-value storage, allowing users to identify Number (Identity Document, ID) identification writes the tuple ⁇ key, blob> into the blockchain, where blob is any string mapped to the key.
  • ID Number
  • the customer's identity ID can be either a ledger identifier or a digital public number.
  • Key signature scheme only the key owner has the right to update the associated value, while any party can use the key to read the associated value, and the creator of the key can encrypt the associated value to protect data privacy.
  • the identity number and public key of the status service instance are written to the blockchain through the first interface of the blockchain, and the initialization information is recorded; through the third interface of the blockchain
  • the second interface queries the initialization information on the blockchain according to the identity number and public key of the status service instance; when the application instance updates the status summary through the third interface of the blockchain, Whether the status service instance request update is legal; obtain the status summary of the application instance through the fourth interface of the blockchain.
  • the first interface is Blockchain.write(ID, ⁇ key, blob ⁇ ): used by the status service instance to record the request in the blockchain.
  • ID is the identifier of the blockchain
  • key and blob are a pair of key-value stores. If the write is successful, a ⁇ will be returned.
  • the client can run the signature algorithm for verification.
  • the second interface is Blockchain.read(ID, key) ⁇ (blob, ⁇ ): the read algorithm returns the blob associated with key and validator ⁇ .
  • the status service instance can check the integrity of the return value through ⁇ .
  • the third interface is writeState(value): used when the application instance updates its own state, it is used to request the status service instance whether the update is legal. If it is legal, a confirmation character is returned to confirm the application instance.
  • the fourth interface is readState() ⁇ value: used to obtain the status summary of the application instance. It should be noted that if the application instance has not previously written any value, a null value will be returned.
  • the application instance in this embodiment can record first and then execute.
  • the application instance updates its state, it first seals and stores a state snapshot on the disk, and then calls the function writeState() to store the associated state summary.
  • the application instance receives the acknowledgment character, it can update its status and publish output.
  • each application instance needs to verify the freshness of data provided by the operating system after a restart, it calls the function readState() to obtain its latest state summary and checks whether the state summary matches the unsealed state snapshot data.
  • each application instance is linked to a local state service instance, and the local state service instance provides multiple interfaces to improve certification speed and state management flexibility.
  • the purpose of this embodiment is to implement an initialization protocol in which all state service instances complete configuration independently without involving any trusted administrator. It should be noted that during the initialization process, it should be ensured that only one The composition method's state service instance has a known identity running on a trusted platform that supports SGX. Without this guarantee, application instances can be linked to multiple groups, and each group can store different state, resulting in state continuity violations.
  • the leader mode is used for initialization, and any one of the state service instances is set as the leader.
  • the leader can be appointed by the cloud service provider, and the leader selection does not affect security.
  • the leader mutually verifies other state service instances through remote attestation, and establishes communication channels with other state service instances. After mutually proving each other's identities, the leader establishes a chain of trust. Then, the leader can collect and distribute other state service instances. public key.
  • this embodiment relies on interaction with the blockchain.
  • a state service instance must publish a record ⁇ uid, blob ⁇ on the ledger, where uid is the enclave program on the platform.
  • a unique identifier, and the blob can be configuration information; when another state service instance starts initialization on the same platform, it will also generate the same uid, find the previous record in the blockchain, and then abort the initialization. Therefore, in this embodiment, forked state service instances will not appear on the same platform.
  • the entire initialization is done autonomously without involving any trusted administrators.
  • Figure 2 is a schematic flow chart of initializing the status service instance based on the blockchain provided by the embodiment of the present invention.
  • the step S10 specifically includes:
  • Step S101 Set any one of the state service instances as a leader, mutually verify the identity of the leader and other state service instances through remote attestation, and establish a secure communication channel between the leader and other state service instances;
  • Step S102 Control the leader and other state service instances to generate an asymmetric key pair, and send the public key of the state service instance to the leader.
  • the leader will distribute the received public key list to Other status service instances;
  • Step S103 Control each state service instance to send a read request to the blockchain, where the read request includes the unique identifier of the state service instance; multiple application instances on the same trusted execution environment platform have same identifier;
  • Step S104 Control each state service instance to send a write request to the blockchain.
  • control each state service instance When receiving a confirmation character from the blockchain, control each state service instance to create a local memory.
  • the memory includes the state service instance state table of other state service instance state entries and the empty application instance state table;
  • Step S105 Control the local state service instance to place the public key list into the local memory of the local state service instance to generate a state service instance configuration table, and control the local state service instance to run the verified key agreement with Other state service instances establish pairwise session keys;
  • Step S106 Seal and store the key pair of the local state service instance, the state service instance configuration table and the application instance state table.
  • steps S101 to S104 are methods for initializing the protocol architecture.
  • Figure 3 is an interactive schematic diagram of the system initialization protocol provided by an embodiment of the present invention.
  • a secure protocol is established through step S101. communication channels.
  • the leader uses remote attestation to mutually attest each other state service instance while establishing a secure communication channel with all other state service instances.
  • each state service instance (including the leader) needs to calculate its enclave identity and compare its identity with others to verify the proven enclave. Whether it is a state service instance.
  • the leader uses remote attestation to mutually authenticate each other state service instance while establishing a secure communication channel with these state service instances.
  • each state service instance calculates its Enclave identity (i.e. MRENCLAVE) , and compares its identity with other Enclave's identities to verify that the proven Enclave is a state service instance.
  • MRENCLAVE Enclave identity
  • step S102 All state service instances (including the leader) generate an asymmetric key pair (pk, sk) and send their public keys to the leader.
  • the leader receives the public key and distributes it.
  • the first initialization check is performed through step S103.
  • Each status service instance sends a read request to the ledger of the second interface Blockchain.read(ID, uid), where ID is the ledger identifier of the status service instance (determined by its pk generated), and uid is the unique identifier of the state service instance on an SGX-enabled trusted platform.
  • ID is the ledger identifier of the status service instance (determined by its pk generated)
  • uid is the unique identifier of the state service instance on an SGX-enabled trusted platform.
  • the state service instance sends a read request to the blockchain, and the blockchain returns the blob according to the request. If the blob is empty, it indicates the status.
  • the service instance has not been initialized and is joining the group for the first time. If the returned blob is not empty, it means that another state service instance has been initialized, and the state service instance will abort initialization.
  • the status service instance After recording the initialization in step S104, the status service instance sends a write request through the first interface Blockchain.write(ID, ⁇ uid, H(Cert) ⁇ ).
  • ACK acknowledgment character
  • the status service When receiving an acknowledgment character (ACK) from the blockchain, the status service The instance creates a state service instance state table that contains state entries of other state service instances and an empty application instance state table.
  • the state service instance places the public key list pkSEi into the state service instance configuration table and establishes a pair of session keys keySEi.
  • Figure 4 is a schematic diagram of the memory layout of a local state service instance provided by an embodiment of the present invention, in which the data gray rectangle is sealed for state During the snapshot, the state service instance seals and stores its key pair, state service instance configuration table, and application instance state table. Finally, the state service instance completes initialization and serves the request of the application instance.
  • the identifier uid in step S103 is the Enclave identity, so that others can verify that the identity offer is issued by the same platform.
  • the state service instance should remain active during the execution of step S104. Because there is no way to distinguish a normal crash from a malicious act that created a fork group, a state service instance cannot initialize if it crashes before receiving the blob. However, because the initialization process only occurs once, the identity of the local state service instance can be hard-coded into the application instance implementation or provided by the ISV.
  • An application instance can run an authenticated key establishment protocol with a local state service instance and share key k through that protocol; the state service instance creates a state entry for the application instance, including the unique identity of the application instance (i.e. using hash of the application instance code), the shared secret key, and an empty state digest, see the application instance state table in Figure 4.
  • Step S20 includes the following steps:
  • Step S201 When the application instance receives a user request, seal and store the status snapshot of the application instance on the disk, update the status summary of the application instance, and send the status to the local status service instance. update request;
  • Step S202 When the local status service instance receives a status update request, store the status update request in the request queue;
  • Step S203 When processing the status update request, control the local status service instance to send the status update request to all status service instances (including local status service instances and other status service instances);
  • Step S204 When all state service instances (including local state service instances and other state service instances) receive the state update request, update all state service instances (including local state service instances and other state service instances) in the state memory. Describe the status summary of the local status service instance and send a reply message;
  • Step S205 When the local state service instance receives more than f+1 of the reply messages, the local state service instance sends a decision message to other state service instances, where f is the fault tolerance number of the consensus node;
  • Step S206 After other status service instances receive the decision message, check whether other status service instances have replied to the preparation message. If so, control the status service instance to send back a confirmation character containing a status summary;
  • Step S207 When the local status service instance receives more than f+1 of the confirmation characters, control the local status service instance to update the status summary of the application instance and reply to the application instance including the status summary. confirmation character;
  • Step S208 When the application instance receives the confirmation character, update its status to the latest status and publish relevant output.
  • FIG. 6 is an interaction diagram of the status update protocol provided by the embodiment of the present invention. That is to say, when the local state service instance is ready to process the state update request of the application instance, it follows the state update protocol shown in Figure 6.
  • the state update protocol is based on the echo broadcast protocol.
  • the messages of the application instance and the state service instance are transmitted in an encrypted manner and A state request that updates the application instance using a secret session key. Additionally, a random number can be added to each message to prevent message replay attacks.
  • the application instance when a user request I i is received, the application instance first seals and stores a snapshot ⁇ S i , I i , SD i -1 ⁇ on the state disk, where the state summary SD i -1 is H(S i - 1
  • the state service instance seals and stores its state snapshot on disk ⁇ S j , I j , SD j -1 ⁇ , where I j is the application Status summary SD i of the instance; the status service instance sends a prepare message ⁇ Prepare, SD j (j, seq)> to all status service instances (including the current status service instance and other status service instances); when receiving the Prepare message, each Each state service instance will update the summary of the local state service instance in the state memory and send a reply message.
  • the reply message contains the message of SD j ; after receiving more than f+1 reply messages, the local state service instance will send a reply message to all states in the group.
  • the service instance sends a decision message ⁇ Decide, SD j , (j, seq)>; when the status service instance receives the decision message, it checks whether the relevant preparation message has been echoed. If so, send back a confirmation character containing SD j . When more than f+1 confirmation characters are received, the local status service instance updates the status summary of the application instance and returns a confirmation character containing SD i . When the application instance receives the acknowledgment character, the application instance updates its status to S i +1 and publishes the associated output O i .
  • the state update protocol can be implemented in a smaller transmission control protocol.
  • the application instance when processing a request, the application instance must seal and store the state snapshot in the local disk. For some applications, such as payment, the entire state is large, so this operation will generate the heavy task of encrypting data and input and output;
  • the state service instance handles the state updates of the application instance in turn.
  • Serialization limits the ability of a state 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 for each update involved
  • the exchange of messages between two rounds of state service instances is the main factor affecting latency and throughput.
  • step S202 the status service instance obtains a batch of requests from the queue and treats these requests as one request. Then, the status service instance processes these requests following steps S203 to S207. After performing the above steps, the status service instance will process them one by one and send confirmation characters.
  • the overhead of batch processing is negligible for two reasons: first, the size of the sealed and stored data only slightly increases the execution time, and second, the size of the network messages transmitted by the protocol (i.e., prepare messages and decision messages) remains the same, Because the output size is regardless of the size of the input, the value of the hash function is fixed.
  • Step S30 includes the following steps:
  • Step S301 Control the application instance to call a function to send a status reading request to the local status service instance
  • Step S302 When the local status service instance receives the status read request, retrieve the latest status of all status service instances;
  • Step S303 Check the status service instance status table of each status service instance, and send the stored status summary back to the local status service instance;
  • Step S304 When receiving f+1 status digests, select the status digest with the largest index as the status digest of the local status service instance.
  • FIG. 8 is an interactive schematic diagram of the state reading protocol provided by the embodiment of the present invention.
  • the application instance calls the readState() function to send a state reading request to the target state service instance.
  • the local state service instance receives the state reading request, it retrieves the group The latest status of all state service instances in the state service instance.
  • Each state service instance checks its state service instance state table and sends the stored state summary back to the local state service instance.
  • the local state service instance After receiving at least f+1 replies, the local state service instance The status digest with the largest index and sequence number is selected; the local status service instance then compares the selected status digest with the previous status digest, and if its status is the latest, sends back the recorded status digest to the application instance , otherwise, no reply.
  • the session key serves as the identity of the state service instance. Only one working state service instance is allowed on the same platform.
  • the restart protocol in the existing technology has security issues, that is, an adversary can use the protocol to create two systems running in parallel, and then launch rollback and fork attacks on TEE applications.
  • the state service instance is restarted, the state of the state service instance is restored based on the session key; that is, the restarted state service instance must establish a new state with other state service instances. session key.
  • restoring the state of the state service instance based on the session key includes the following steps:
  • each state service instance (SE) will have a "ping" function to check whether it is still connected to other state service instances.
  • the restarted status service instance needs to restore memory data, so the latest status summary is selected;
  • Control the status service instance to obtain a sealed status summary from the operating system, match the status summary with status summaries obtained from other status service instances, and if they match, control the status service instance to restore the status corresponding to the status summary.
  • the restarted service instance needs to establish a new session key with other state service instances because it has lost all previous data.
  • other state service instances must check whether they still maintain links with other state service instances, that is, whether their session keys are still active. To do this, each state service instance sends a ping Request messages to other state service instances and wait for ACK. If they cannot receive ACKs from other state service instances, refuse to establish new session keys with the restarted state service instance; restart the state service instance to perform the state reading protocol. Steps S302 to S304 are used to obtain the latest status summary of it and other status service instances.
  • Steps S302 to S304 can be in a read request; restart the status service instance and select the status summary with the largest index, that is, the latest status summary as each The serial number of a state service instance (including restarted state service instances).
  • the sequence number is increased and steps S202 to S206 in the status update protocol are re-executed to update its latest status summary. In this way, it is guaranteed that the latest status summary is safely recorded on at least f+1 status service instances.
  • the sealed state data based on the operating system restores the state of the application instance, including the following steps:
  • Control the application instance to obtain the sealing status data of the operating system, match the sealing status data with the latest status summary, and if the match is successful, update the status summary of the application instance after restarting and publish the output .
  • the restarted application instance after restarting executes the status reading protocol to request the latest status summary from the local status service instance; and obtains the latest sealing status of the restarted application instance from the operating system, and compares the latest sealing status with the local status service The instance's status summary is matched, and if the two match, updates the application instance's status to the latest status and publishes the relevant output.
  • the embodiment of the present invention provides a method for protecting TEE state continuity under the public cloud based on decentralized trust.
  • the TEE state continuity protection under the public cloud based on decentralized trust includes: based on blockchain Initialize the state service instance; update the state request of the application instance based on encrypted transmission and session key; control the application instance to read the latest state of the state service instance; when the state service instance is restarted, The state of the state service instance is restored based on the session key; when the application instance is restarted, the state of the application instance is restored based on the sealed state data of the operating system.
  • the present invention uses the blockchain to eliminate dependence on a centralized trusted entity, and only relies on the blockchain for initialization, which improves the speed of status update and reading.
  • embodiments of the present invention also provide a decentralized trust-based TEE state continuity protection system under the public cloud.
  • the TEE state continuity protection system under the public cloud based on decentralized trust includes:
  • the initialization module 100 is used to initialize the status service instance based on the blockchain
  • the status update module 200 is used to update the status request of the application instance based on the encrypted transmission and session key;
  • the status reading module 300 is used to control the application instance to read the latest status of the status service instance
  • the restart module 400 is used to restore the state of the state service instance based on the session key when the state service instance is restarted; and is also used to restore the sealed state data based on the operating system when the application instance is restarted.
  • the state of the application instance is used to restore the state of the state service instance based on the session key when the state service instance is restarted; and is also used to restore the sealed state data based on the operating system when the application instance is restarted. The state of the application instance.
  • the system includes: a trusted platform and a blockchain, the application instance (AE) and the state service instance (SE) run on the trusted platform, and the application instance processes The client's request is returned with corresponding output, and the state service instance improves state continuity protection for the application instance.
  • AE application instance
  • SE state service instance
  • the TEE state continuity protection system and its various modules based on decentralized trust in the public cloud can also refer to the TEE state continuity protection system in the public cloud based on decentralized trust.
  • the corresponding descriptions in the protection methods will not be repeated here.
  • the present invention also provides an intelligent terminal, the functional block diagram of which can be shown in Figure 11.
  • the smart terminal includes a memory, a processor, and a decentralized trust-based TEE state continuity protection program in the public cloud that is stored on the memory and can run on the processor.
  • the TEE state continuity protection program under the public cloud is executed by the processor, the steps of any of the above decentralized trust-based TEE state continuity protection methods under the public cloud are implemented.
  • the state of the state service instance is restored based on the session key; when the application instance is restarted, the state of the application instance is restored based on the sealed state data of the operating system.
  • Embodiments of the present invention also provide a computer-readable storage medium.
  • the computer-readable storage medium stores a TEE state continuity protection program under a public cloud based on decentralized trust.
  • the public cloud based on decentralized trust When the TEE state continuity protection program is executed by the processor, the steps of implementing the TEE state continuity protection method under the public cloud based on decentralized trust as described in any one of the above are implemented.
  • sequence number of each step in the embodiment does not mean the order of execution.
  • the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present invention.
  • each functional unit and module in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.
  • the integrated unit can either use hardware. It can also be implemented in the form of software functional units.
  • the specific names of each functional unit and module are only for the convenience of distinguishing each other and are not used to limit the scope of the present invention.
  • the disclosed apparatus/terminal equipment and methods can be implemented in other ways.
  • the device/terminal equipment embodiments described above are only illustrative.
  • the division of modules or units is only a logical function division. In actual implementation, it may be implemented in other ways, such as multiple units. Or components can be combined or can be integrated into another system, or some features can be omitted, or not implemented.
  • the integrated module/unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium.
  • the present invention can implement all or part of the processes in the method of the embodiments, and can also be completed by instructing relevant hardware through a computer program.
  • the computer program can be stored in a computer-readable storage medium, and the computer can When the program is executed by the processor, the steps of the various method embodiments can be implemented.
  • the computer program includes computer program code, which may be in the form of source code, object code, executable file or some intermediate form.
  • the computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory) , random access memory (RAM, RandomAccess Memory), electrical carrier signals, telecommunications signals, and software distribution media, etc. It should be noted that the content contained in the computer-readable storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

本发明公开了一种基于去中心化信任的公有云下TEE状态连续性保护方法、系统、智能终端及存储介质，所述方法包括：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取自己存储在所述状态服务实例中的最新状态；当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。本发明中，使用区块链消除了对中心化可信实体的依赖，且只依赖区块链进行初始化，提高了状态更新和读取的速度。

Description

基于去中心化信任的公有云下TEE状态连续性保护方法 技术领域
本发明涉及计算机技术领域，尤其涉及的是一种基于去中心化信任的公有云下TEE状态连续性保护方法、系统、智能终端及计算机可读存储介质。
背景技术
随着科技不断发展，越来越多的厂商选择将业务部署到公有云上，在带来便利的同时，隐私保护和数据安全问题也日益严峻，由于操作系统的复杂性以及安全漏洞、安全机制容易被绕过等问题，把用户指纹、证书等机密数据和普通应用数据保存在公有云上无法保证其机密性、完整性和可用性。为此，业界提出了可信执行环境(Trusted Execution Environment，TEE)的设计，例如亚马逊云，谷歌云，阿里巴巴云平台使用TEE技术为用户提供机密计算服务，但TEE保护的应用程序仍然会受到回滚攻击或者分叉攻击，攻击者通过这些攻击可以将TEE的状态回滚到过时的版本或被分叉成多个版本，导致TEE的状态连续性被破坏。
现有技术中，通常利用硬件可信计数器提供一个安全容器，远程用户将代码和数据上载到安全容器中，在对容器执行计算时，安全容器用来保护数据的机密性和完整性，但硬件可信计数器的状态更新和读取的速度慢，不能满足云环境中对更新状态的要求。
因此，现有技术还有待改进和发展。
发明内容
本发明的主要目的在于提供一种基于去中心化信任的公有云下TEE状态连续性保护方法，旨在解决现有技术中硬件可信计数器的状态更新和读取的速度慢，不能满足云环境中对更新状态的要求的问题。
为了实现上述目的，本发明第一方面提供一种基于去中心化信任的公有云下TEE状态连续性保护方法，所述基于去中心化信任的公有云下TEE状态连续性保护方法包括：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取存储在所述状态服务实例中的最新状态；当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
可选的，所述基于去中心化信任的公有云下TEE状态连续性保护方法还包括：通过所述区块链的第一接口将所述状态服务实例的身份标识号码和公钥写到所述区块链上，并记录初始化信息；通过所述区块链的第二接口根据所述状态服务实例的身份标识号码和公钥在所述区块链上查询初始化信息；通过所述区块链的第三接口在所述应用程序实例更新状态摘要时，向所述状态服务实例请求更新是否合法；通过所述区块链的第四接口获取所述应用程序实例的状态摘要。
可选的，所述基于区块链对所述状态服务实例进行初始化处理，具体包括：
将任意一个所述状态服务实例设置为领导者，通过远程证明相互验证所述领导者和其他状态服务实例的身份，并建立所述领导者与其他状态服务实例的安全通信信道；
控制所述领导者和其他状态服务实例生成非对称密钥对，并将所述状态服务 实例的公钥发送给所述领导者，所述领导者将接收到的公钥列表分发给其他状态服务实例；
控制每个所述状态服务实例向所述区块链发送读请求，所述读请求包括所述状态服务实例的唯一标识符；
控制每个所述状态服务实例向所述区块链发送写请求，当收到来自所述区块链的确认字符时，控制每个所述状态服务实例创建本地内存，所述本地内存包括其他状态服务实例状态条目的状态服务实例状态表和空的应用程序实例状态表；
控制本地状态服务实例将所述公钥列表放置到所述本地状态服务实例的本地内存以生成状态服务实例配置表，并控制所述本地状态服务实例通过运行经过验证的密钥协议与其他状态服务实例建立成对会话密钥；
密封并存储所述本地状态服务实例的密钥对、所述状态服务实例配置表和所述应用程序实例状态表。
可选的，所述基于加密传输和会话密钥更新所述应用程序实例的状态请求，具体包括：
当所述应用程序实例接收到用户请求时，密封并存储所述应用程序实例的状态快照到磁盘上，并更新所述应用程序实例的状态摘要，向所述本地状态服务实例发送状态更新请求；
当所述本地状态服务实例接收到状态更新请求时，存储所述状态更新请求到请求队列；
当处理所述状态更新请求时，控制所述本地状态服务实例向所述本地状态服务实例和其他状态服务实例发送所述状态更新请求；
当所述本地状态服务实例和其他状态服务实例接收到所述状态更新请求时，更新所述本地状态服务实例和其他状态服务实例状态内存中所述本地状态服务实例的状态摘要并发送回复消息；
当所述本地状态服务实例收到超过f+1个所述回复消息时，所述本地状态服务实例向其他状态服务实例发送决定消息，其中，f为共识节点容错数；
当其他状态服务实例收到所述决定消息后，检查其他状态服务实例是否已回复所述准备消息，若是，则控制所述状态服务实例发回包含状态摘要的确认字符；
当所述本地状态服务实例收到超过f+1个所述确认字符时，控制所述本地状态服务实例更新所述应用程序实例的状态摘要并向所述应用程序实例回复包含状态摘要的确认字符；
当所述应用程序实例收到所述确认字符时，将其状态更新为最新状态并发布相关输出。
可选的，所述控制所述应用程序实例读取所述状态服务实例的最新状态，具体包括：
控制所述应用程序实例调用函数向所述本地状态服务实例发送状态读取请求；
当所述本地状态服务实例收到所述状态读取请求时，检索全部所述状态服务实例的最新状态；
检查每个所述状态服务实例的状态服务实例状态表，并将存储的状态摘要发回给所述本地状态服务实例；
当收到f+1个所述状态摘要时，选择索引最大的状态摘要作为所述本地状态服务实例的状态摘要。
可选的，所述当所述状态服务实例发生重启时，基于会话密钥恢复所述状态 服务实例的状态，具体包括：
控制重启后的所述状态服务实例与其他状态服务实例建立新的会话密钥；
控制重启后的所述状态服务实例获取所述状态服务实例和其他状态服务实例的状态摘要；
选择索引最大的状态摘要作为重启后的所述状态服务实例的状态摘要；
控制所述状态服务实例从操作系统获取密封的状态摘要，将所述状态摘要与从其他状态服务实例获取的状态摘要进行匹配，若匹配，则控制所述状态服务实例恢复所述状态服务实例的状态摘要。
可选的，所述当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态，具体包括：
控制重启后的所述应用程序实例向所述本地状态服务实例请求最新状态摘要；
控制所述应用程序实例获取所述操作系统的密封状态数据，将所述密封状态数据与所述最新状态摘要进行匹配，若匹配成功，则更新重启后所述应用程序实例的状态摘要并发布输出。
本发明第二方面提供一种基于去中心化信任的公有云下TEE状态连续性保护系统，其特征在于，所述基于去中心化信任的公有云下TEE状态连续性保护系统包括：
初始化模块，用于基于区块链对状态服务实例进行初始化处理；
状态更新模块，用于基于加密传输和会话密钥更新应用程序实例的状态请求；
状态读取模块，用于控制所述应用程序实例读取所述状态服务实例的最新状态；
重启模块，用于当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；还用于当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
本发明第三方面提供一种智能终端，所述智能终端包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的基于去中心化信任的公有云下TEE状态连续性保护程序，所述基于去中心化信任的公有云下TEE状态连续性保护程序被所述处理器执行时实现如上任意一项所述基于去中心化信任的公有云下TEE状态连续性保护方法的步骤。
本发明第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有基于去中心化信任的公有云下TEE状态连续性保护程序，所述基于去中心化信任的公有云下TEE状态连续性保护程序被处理器执行时实现如上任意一项所述基于去中心化信任的公有云下TEE状态连续性保护方法的步骤。
由上可见，本发明实施例提供的一种基于去中心化信任的公有云下TEE状态连续性保护方法，所述基于去中心化信任的公有云下TEE状态连续性保护方法包括：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取所述状态服务实例的最新状态；当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。与现有技术相比，本发明使用区块链消除了对中心化可信实体的依赖，且只依赖区块链进行初始化，提高了状态更新和读取的速度。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
图1是本本发明实施例提供一种基于去中心化信任的公有云下TEE状态连续性保护方法的流程示意图；
图2是本发明实施例提供的步骤S10的流程示意图；
图3是本发明实施例提供的系统初始化协议的交互示意图；
图4是本发明实施例提供的本地状态服务实例的内存布局示意图；
图5是本发明实施例提供的步骤S20的流程示意图；
图6是本发明实施例提供的状态更新协议的交互示意图；
图7是本发明实施例提供的步骤S30的流程示意图；
图8是本发明实施例提供的状态读取协议的交互示意图；
图9是本发明实施例提供的基于去中心化信任的公有云下TEE状态连续性保护系统的结构示意图；
图10是本发明实施例提供的基于去中心化信任的公有云下TEE状态连续性保护系统的架构示意图；
图11是本发明实施例提供的智能终端的内部结构原理框图。
具体实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况下，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。
应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
下面结合本发明实施例的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其它不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。
随着科技不断发展，越来越多的厂商选择将业务部署到公有云上，例如英 特尔软件保护扩展(Software Guard Extension，SGX)能够使应用程序直接计算，不会泄露机密数据。例如，英特尔SGX为受保护的计算提供安全的隔离环境飞地(Enclave)，并将代码和数据存储在飞地(Enclave)中，Enclave是一个被保护的内容容器，用于存放应用程序敏感数据和代码；现有技术中通常通过TEE为用户提供机密计算服务，旨在增强客户外包数据或代码的安全和隐私性。但TEE中的状态应用程序依赖于不受信任的操作系统来存储状态，因此会遭受回滚或分叉攻击，它们的状态可能回滚到正确但已经过时的版本或被分叉成多个版本，导致状态连续性造成破坏，另外，当系统发生重启、断电或崩溃时，受保护模块应在状态连续性中断之前恢复到相同的状态。
状态连续性一旦违规将会产生严重后果，例如支付、信用系统、可信存储、智能合约等都会受到影响，例如，在TEE中实现的支付系统中，状态连续性一旦违规，攻击者可以通过还原其账户余额的状态在多个支付中花费相同的硬币(即双花攻击)。
针对上述问题现有技术中有基于硬件的解决方案，例如，使用定时计数器做状态更新，不但只有有限次的写操作，且状态更新和读取的速度较慢，不能满足云环境中对更新状态的要求。基于软件的解决方案，例如，将可信计数器装载到单个可信服务器或分布式集合服务器，则依赖于可信的管理员做系统初始化，使得这类方案仍然存在依赖中心化信任的问题。
为了解决现有技术中的问题，本发明提供一种基于去中心化信任的公有云下TEE状态连续性保护方法，该方法依赖于区块链(即去中心化信任)和基于TEE的分布式系统，能够为云上用户的受保护TEE应用实例提供高性能的状态连续性保护，例如能够支持应用在云TEE环境下无限且快速的状态更新。
示例性方法
如图1所示，本发明实施例提供一种基于去中心化信任的公有云下TEE状态连续性保护方法的流程示意图，具体的，所述基于去中心化信任的公有云下TEE状态连续性保护方法包括：
步骤S10：基于区块链对状态服务实例进行初始化处理；
步骤S20：基于加密传输和会话密钥更新应用程序实例的状态请求；
步骤S30：控制所述应用程序实例读取自身存储在所述状态服务实例中的最新状态；
步骤S40：当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
本实施例中，仅在初始化处理中使用区块链，既奠定了去中心化的信任，消除了对中央可信实体的依赖，同时尽可能减少与区块链的互动，使得系统可以减少高昂的区块链交互开销，降低成本。
需要说明的是，本实施例可以应用在由云服务商管理可信平台上，例如，支持英特尔SGX的平台，其中，每个支持SGX的可信平台运行多个飞地(enclave)实例，具体的，所述飞地实例可以分为以下两种类型：
应用程序实例(Application Enclave，AE)，AE是由独立软件供应商创建和上传的应用程序，用于处理客户的请求并返回相应的输出。
状态服务实例(State Enclave，SE)，SE是为AE提供状态连续性服务的enclave实例。每个AE都可以链接到同一平台上的本地SE(即目标SE)，并根据所述方法保护其状态连续性。
本实施例中，所述状态服务实例通过区块链接口与所述区块链进行交互，所述区块链使用拜占庭容错共识作为骨干协议，进一步实现了键值存储，使用户能够通过身份标识号码(Identity Document，ID)识别将元组〈key，blob〉写入区块链，其中blob是任意与键映射的字符串，客户的身份ID既可以是账本标识符，也可以是数字的公钥签名方案，只有密钥所有者有权更新关联值，而任何一方都可以使用密钥读取关联的值，密钥的创建者可以加密关联的值以保护数据隐私。
本实施例中，通过所述区块链的第一接口将所述状态服务实例的身份标识号码和公钥写到所述区块链上，并记录初始化信息；通过所述区块链的第二接口根据所述状态服务实例的身份标识号码和公钥在所述区块链上查询初始化信息；通过所述区块链的第三接口在所述应用程序实例更新状态摘要时，向所述状态服务实例请求更新是否合法；通过所述区块链的第四接口获取所述应用程序实例的状态摘要。
具体的，所述第一接口为Blockchain.write(ID，〈key，blob〉)：用于状态服务实例把请求记录在区块链。ID是区块链的标识，key和blob是一对键值存储。如果写入成功，就会返回一个的σ。客户端可以运行签名算法进行验证。
所述第二接口为Blockchain.read(ID，key)→(blob，σ)：读取算法返回与key和验证器σ关联的blob。状态服务实例通过σ可以检查返回值的完整性。
所述第三接口为writeState(value)：用于在应用程序实例更新自身状态时，向状态服务实例请求更新是否合法，如果合法，返回一个确认字符以确认应用程序实例。
所述第四接口为readState()→value：用于获取所述应用程序实例的状态摘要。需要注意的是，若应用程序实例没有之前写入任何值，则返回一个空值。
通过以上接口，本实施例中应用程序实例可以实行先记录后执行，当应用程序实例更新其状态时，首先密封并存储一个状态快照在磁盘上，然后调用函数writeState()来存储关联的状态摘要，一旦应用程序实例收到确认字符，就可以更新其状态并发布输出。
当应用程序实例需要验证重新启动后操作系统提供的数据的新鲜度时，调用函数readState()获取其最新的状态摘要，检查状态摘要是否与未密封的状态快照数据匹配。本发明中，每个应用程序实例都与一个本地状态服务实例链接，本地状态服务实例提供多个接口提高证明速度和状态管理灵活性。
需要说明的是，本实施例的目的是实现一个初始化协议，其中，所有的状态服务实例自主完成配置，不涉及任何受信任的管理员，需要注意的是，在初始化的过程中应该确保只有一组合法的状态服务实例具有已知的在支持SGX的可信平台上运行的身份。如果没有此保证，应用程序实例可以链接到多个组，且每个组可以存储不同的状态，将导致违反状态连续性。
由于缺乏可信性，在初始化过程中存在两个挑战：第一、所有状态服务实例必须以分布式方式构建PKI方式，这通常会导致较高的消息复杂性。第二、对保证只有一个初始化组，一个集中式系统通常使用受信任的管理员来提供密钥配置。
为了应对第一个挑战，本实施例中采用领导者模式进行初始化，将任意一个所述状态服务实例设置为领导者，领导者可以由云服务商委派，且领导者选择不影响安全性。首先，领导者通过远程证明相互验证其他所述状态服务实例，并与其他所述状态服务实例建立通信通道，互相证明彼此的身份后建立信任链条，然 后，领导者可以收集和分发其他状态服务实例的公钥。
为了应对第二个挑战，本实施例依赖于与区块链的交互，在初始化期间，一个状态服务实例必须在账本上发布记录〈uid，blob〉，其中uid是平台上飞地(Enclave)程序唯一的标识符，且blob可以是配置信息；当另一个状态服务实例在同一个平台开始初始化，它也会生成相同的uid，在区块链中找到之前的记录，然后中止初始化。因此，本实施例中在同一个平台不会出现分叉状态服务实例。整个初始化是自主完成的不涉及任何受信任的管理员。
本实施例中，如图2所示，图2是本发明实施例提供的基于区块链对所述状态服务实例进行初始化处理的流程示意图，所述步骤S10具体包括：
步骤S101：将任意一个所述状态服务实例设置为领导者，通过远程证明相互验证所述领导者和其他状态服务实例的身份，并建立所述领导者与其他状态服务实例的安全通信通道；
步骤S102：控制所述领导者和其他状态服务实例生成非对称密钥对，并将所述状态服务实例的公钥发送给所述领导者，所述领导者将接收到的公钥列表分发给其他状态服务实例；
步骤S103：控制每个所述状态服务实例向所述区块链发送读请求，所述读请求包括所述状态服务实例的唯一标识符；在同一可信执行环境平台上的多个应用实例具有相同的标识符；
步骤S104：控制每个所述状态服务实例向所述区块链发送写请求，当收到来自所述区块链的确认字符时，控制每个所述状态服务实例创建本地内存，所述本地内存包括其他状态服务实例状态条目的状态服务实例状态表和空的应用程序实例状态表；
步骤S105：控制本地状态服务实例将所述公钥列表放置到所述本地状态服务实例的本地内存以生成状态服务实例配置表，并控制所述本地状态服务实例通过运行经过验证的密钥协议与其他状态服务实例建立成对会话密钥；
步骤S106：密封并存储所述本地状态服务实例的密钥对、所述状态服务实例配置表和所述应用程序实例状态表。
需要说明的是，所述步骤S101至步骤S104为初始化协议架构的方法，具体的，如图3所示，图3是本发明实施例提供的系统初始化协议的交互示意图，通过步骤S101建立安全的沟通渠道。领导者使用远程证明相互证明每个其他状态服务实例，同时与所有其他状态服务实例建立安全的通信通道。需要注意的是，在创建时，每个状态服务实例(包括领导者)都需要计算它的飞地(Enclave)身份，并比较其与其他人的身份，一起验证被证明的飞地(Enclave)是否是状态服务实例。领导者使用远程证明来相互验证其他每个状态服务实例，同时与这些状态服务实例建立安全的通信通道，在创建时，每个状态服务实例(包括领导者)都会计算其Enclave标识(即MRENCLAVE)，并将其标识与其他Enclave的身份进行比较，以验证已证明的Enclave是否为状态服务实例。
通过步骤S102进行身份建立，所有状态服务实例(包括领导者)生成一个非对称密钥对(pk，sk)，并将它们的公钥发送给领导者，领导者收到公钥后分发收到的公钥列表(由Cert表示)到其他状态服务实例，以便他们可以相互验证。
通过步骤S103进行第一次初始化检查，每个状态服务实例发送一个读请求到第二接口Blockchain.read(ID，uid)的分类帐，其中ID为状态服务实例的账本标识符(由它的pk生成)，而uid是状态服务实例在启用SGX的可信平台上的唯一标识符。当另一个状态服务实例在同一个平台开始初始化，它也会生成相同 的uid，状态服务实例向区块链发送读取请求，区块链根据请求来返回blob，如果blob为空，说明该状态服务实例没有被初始化，是第一次加入群组。如果返回的blob不为空，说明已经有另一个状态服务实例初始化，则状态服务实例将中止初始化。
通过步骤S104记录初始化，状态服务实例通过第一接口Blockchain.write(ID，〈uid，H(Cert)〉)发送写请求，当收到一个来自区块链的确认字符(ACK)时，状态服务实例创建一个包含其他状态服务实例的状态条目的状态服务实例状态表和一个空的应用程序实例状态表，状态服务实例将公钥列表pkSEi放到状态服务实例配置表并建立成对会话密钥keySEi与所有其他状态服务实例通过运行经过身份验证的密钥协议，如图4所示，图4是本发明实施例提供的本地状态服务实例的内存布局示意图，其中的数据灰色矩形被密封用于状态快照，状态服务实例密封并存储其密钥对、状态服务实例配置表和应用程序实例状态表，最终状态服务实例完成初始化并服务应用程序实例的请求。
需要说明的是，步骤S103中的标识符uid是Enclave身份标识，使其他人能够验证身份报价是由同一个平台发出。状态服务实例应在步骤S104执行期间保持活动状态。因为无法区分正常崩溃是否来自创建分叉组的恶意行为，如果状态服务实例在收到blob之前崩溃，则无法初始化。然而，因为初始化过程只会发生一次，本地状态服务实例的身份可以硬编码到应用程序实例实现或由独立软件开发商提供。应用程序实例可以与本地状态服务实例运行经过身份验证的密钥建立协议，并通过该协议共享密钥k；状态服务实例为应用程序实例创建一个状态条目，包括唯一的身份应用程序实例(即使用应用程序实例代码的哈希)、共享密钥和一个空的状态摘要，可参见图4中的应用程序实例状态表。
本实施例中，如图5所示，图5是本发明实施例提供的基于加密传输和会话密钥更新所述应用程序实例的状态请求的流程示意图，所述步骤S20包括以下步骤：
步骤S201：当所述应用程序实例接收到用户请求时，密封并存储所述应用程序实例的状态快照到磁盘上，并更新所述应用程序实例的状态摘要，向所述本地状态服务实例发送状态更新请求；
步骤S202：当所述本地状态服务实例接收到状态更新请求时，存储所述状态更新请求到请求列队；
步骤S203：当处理所述状态更新请求时，控制所述本地状态服务实例向全部状态服务实例(包括本地状态服务实例和其他状态服务实例)发送所述状态更新请求；
步骤S204：当全部状态服务实例(包括本地状态服务实例和其他状态服务实例)接收到所述状态更新请求时，更新全部状态服务实例(包括本地状态服务实例和其他状态服务实例)状态内存中所述本地状态服务实例的状态摘要并发送回复消息；
步骤S205：当所述本地状态服务实例收到超过f+1个所述回复消息时，所述本地状态服务实例向其他状态服务实例发送决定消息，其中，f为共识节点容错数；
步骤S206：当其他状态服务实例收到所述决定消息后，检查其他状态服务实例是否已回复所述准备消息，若是，则控制所述状态服务实例发回包含状态摘要的确认字符；
步骤S207：当所述本地状态服务实例收到超过f+1个所述确认字符时，控 制所述本地状态服务实例更新所述应用程序实例的状态摘要并向所述应用程序实例回复包含状态摘要的确认字符；
步骤S208：当所述应用程序实例收到所述确认字符时，将其状态更新为最新状态并发布相关输出。
需要说明的是，所述步骤S201至步骤S207为状态更新协议的架构方法，具体的，如图6所示，图6是本发明实施例提供的状态更新协议的交互示意图，也就是说，当本地状态服务实例准备好处理应用程序实例的状态更新请求时，遵循图6所示的状态更新协议，所述状态更新协议基于回声广播协议，应用程序实例和状态服务实例的消息通过加密方式传输和使用秘密会话密钥更新所述应用程序实例的状态请求。此外，可以为每条消息添加随机数以防止消息重播攻击。
举例说明，当接收到用户请求I i时，应用程序实例首先密封并存储状态磁盘上的快照〈S i，I i，SD i-1〉，其中状态摘要SD i-1为H(S i-1||I i-1)。然后，应用程序实例调用函数writeState(SD i)更新它的状态摘要，为了清楚起见，假设需要随机性R i附有S i；本地状态服务实例收到状态更新请求时，将其缓存在先进先出(FIFO)队列中，一旦请求在头部并且没有其他服务请求，状态服务实例密封并存储它在磁盘上的状态快照〈S j，I j，SD j-1〉，其中I j是应用程序实例的状态摘要SD i；状态服务实例向全部状态服务实例(包括当前状态服务实例和其他状态服务实例)发送准备消息〈Prepare，SD j(j，seq)〉；当接收到Prepare消息时，每个状态服务实例都会更新状态内存中本地状态服务实例的摘要并发送回复消息，所述回复消息包含SD j的消息；收到超过f+1个回复消息后，本地状态服务实例向组中所有状态服务实例发送决定消息〈Decide，SD j，(j，seq)〉；当状态服务实例收到决定消息后，检查是否已回显相关的准备消息。如果是，则发回包含SD j的确认字符。当接收到超过f+1个确认字符时，本地状态服务实例更新应用程序实例的状态摘要并返回包含SD i的确认字符。当应用程序实例接收到确认字符后，应用程序实例将其状态更新为S i+1并且发布相关的输出O i。
需要说明的是，所述状态更新协议可以在较小的传输控制协议中实现，首先，在处理请求时，应用程序实例必须进行密封和存储本地磁盘中的状态快照。对于某些应用程序，如支付，整个状态很大，因此此操作会产生加密数据和输入输出的繁重任务；其次，状态服务实例依次处理应用程序实例的状态更新。序列化会限制状态服务实例每秒处理请求的能力(即吞吐量)；此外，当支持的数量应用程序实例和关联请求很大，吞吐量低会导致到长时间的服务延迟，每次更新涉及两轮状态服务实例之间的消息交换，是影响的主要因素延迟和吞吐量。
为了解决上述问题，本实施例中，采用以下方式优化所述状态更新协议：
(1)利用检查点减少密封和存储数据的大小，此方式适用于应用程序实例和状态服务实例。为了清楚起见，我们从应用程序实例的角度描述优化，需要说明的是，由于程序是确定性的，可以恢复最新状态执行所有历史输入，也就是说，应用程序实例只需要密封并将输入请求存储在磁盘上，同时记录摘要状态服务实例中的输入历史，对于大多数应用程序，输入通常是远小于整个应用程序状态，因此可以减少密封和存储数据的大小。
(2)利用批处理处理提升系统处理请求的能力。使状态服务实例可以同时服务多个运行不同应用程序的应用程序实例，即不需要串行处理不同应用程序实例的状态更新请求。在步骤S202中状态服务实例获取一批来自队列的请求，并将这些请求作为一个请求。然后，状态服务实例遵循步骤S203至步骤S207处理这些请求。执行上述步骤后，状态服务实例会一一处理并发送确认字符。批处理的开销可以忽略不计，原因有以下两个：首先，密封和存储数据的大小仅略有增加执行时间，其次，协议传输的网络消息(即准备消息和决定消息)的大小保持不变，因为输出大小无论输入的大小如何，散列函数的值都是固定的。
当应用程序实例想要检查其状态或密封状态的新鲜度时。应用程序实例调用函数readState()获取最新的来自本地状态服务实例的状态摘要。当接收到状态读取请求时，本地状态服务实例无法直接返回应用程序实例的记录状态。主要是因为可能因为存在多个本地状态服务实例(即分叉攻击)，因此请求的状态服务实例保存的状态不是最新的。为了解决这个问题，应用程序实例必须检查它的状态是否是最新的，如果是，则安全地返回应用程序实例的状态摘要。所述控制所述应用程序实例读取所述状态服务实例的最新状态，如图7所示。图7是本发明实施提供的所述应用程序实例读取所述状态服务实例的最新状态的流程示意图，步骤S30包括以下步骤：
步骤S301：控制所述应用程序实例调用函数向所述本地状态服务实例发送状态读取请求；
步骤S302：当所述本地状态服务实例收到所述状态读取请求时，检索全部所述状态服务实例的最新状态；
步骤S303：检查每个所述状态服务实例的状态服务实例状态表，并将存储的状态摘要发回给所述本地状态服务实例；
步骤S304：当收到f+1个所述状态摘要时，选择索引最大的状态摘要作为所述本地状态服务实例的状态摘要。
需要说明的是，所述步骤S301至步骤S304为状态读取协议的架构方法，具体的，如图8所示。图8是本发明实施例提供的状态读取协议的交互示意图，应用程序实例调用readState()函数向目标状态服务实例发送状态读取请求，本地状态服务实例收到状态读取请求时，检索组中所有状态服务实例的最新状态，每个状态服务实例检查其状态服务实例状态表，并将存储的状态摘要发回本地状态服务实例，在收到至少f+1个回复后，本地状态服务实例选择具有最大索引和序列号的状态摘要；然后，本地状态服务实例将选择的状态摘要与前一次的状态摘要进行比较，如果它的状态是最新的，则发回记录的状态摘要给应用程序实例，否则，不回复。
会话密钥作为状态服务实例的身份，在同一平台上只允许有一个正在工作中的状态服务实例。然而，现有技术中的重启协议存在安全问题，即对手可以利用该协议创建两个并行运行的系统，然后启动对TEE应用程序的回滚和分叉攻击。为了解决上述问题，本实施例中当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；也就是说，重启后的状态服务实例必须与其他状态服务实例建立新的会话密钥。
当所述状态服务实例发生重启时，所述基于会话密钥恢复所述状态服务实例的状态包括以下步骤：
控制重启后的所述状态服务实例与其他状态服务实例建立新的会话密钥；
需要说明的是，当某一个状态服务实例(SE)被强制重启后，重启后的状 态服务实例(SE)会失去所有的内存数据，但是之前建立的会话控制(session)会保存在状态服务实例(SE)中，此时重启后的状态服务实例(SE)无法重新加入集群。本实施例中，每一个状态服务实例(SE)会存在一个“ping”的功能，检查自己是否仍与其他状态服务实例保持链接。
控制重启后的所述状态服务实例执行所述步骤S302至所述步骤S304以获取所述状态服务实例和其他状态服务实例的状态摘要；
选择索引最大的状态摘要作为重启后的所述状态服务实例的状态摘要，重启的状态服务实例(SE)需要恢复内存数据，因此选择最新的状态摘要；
控制所述状态服务实例从操作系统获取密封的状态摘要，将所述状态摘要与从其他状态服务实例获取的状态摘要进行匹配，若匹配，则控制所述状态服务实例恢复状态摘要对应的状态。
具体的，重启后的服务实例需要与其他状态服务实例建立新的会话密钥，因为它已经失去了以前的全部数据。其次，在会话密钥建立之前，其他状态服务实例必须检查他们是否仍维持与其他状态服务实例的链接，即他们的会话密钥是否仍处于活动状态，为此，每个状态服务实例发送一个ping请求向其他状态服务实例发送消息并等待ACK，如果他们无法收到来自其他状态服务实例的ACK，则拒绝与重启状态服务实例建立新的会话密钥；重启状态服务实例执行状态读取协议中的步骤S302至步骤S304以获取其和其他状态服务实例的最新状态摘要，步骤S302至步骤S304可以在一个读取请求中；重启状态服务实例选择索引最大的状态摘要，也就是最新的状态摘要作为每个状态服务实例(包括重启状态服务实例)的序列号。为了重启后的状态服务实例和群组保持同步，增加序列号并重新执行状态更新协议中步骤S202至步骤S206来更新其最新的状态摘要。如此，可以保证最新的状态摘要被安全地记录在至少f+1个状态服务实例上。
当所述应用程序实例发生重启时，所述基于操作系统的密封状态数据恢复所述应用程序实例的状态，包括以下步骤：
控制重启后的所述应用程序实例执行所述步骤S301至所述步骤S304向所述本地状态服务实例请求最新状态摘要；
控制所述应用程序实例获取所述操作系统的密封状态数据，将所述密封状态数据与所述最新状态摘要进行匹配，若匹配成功，则更新重启后所述应用程序实例的状态摘要并发布输出。
具体的，重启后的重启应用程序实例执行状态读取协议向本地状态服务实例请求最新的状态摘要；并从操作系统获得重启应用程序实例的最新密封状态，将最新密封状态与所述本地状态服务实例的状态摘要进行匹配，如果这两个匹配，将应用程序实例的状态更新为最新状态并发布相关输出。
由上可见，本发明实施例提供的一种基于去中心化信任的公有云下TEE状态连续性保护方法，所述基于去中心化信任的公有云下TEE状态连续性保护包括：基于区块链对状态服务实例进行初始化处理；基于加密传输和会话密钥更新应用程序实例的状态请求；控制所述应用程序实例读取所述状态服务实例的最新状态；当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。与现有技术相比，本发明使用区块链消除了对中心化可信实体的依赖，且只依赖区块链进行初始化，提高了状态更新和读取的速度。
示例性设备
如图9中所示，对应于所述基于去中心化信任的公有云下TEE状态连续性 保护方法，本发明实施例还提供一种基于去中心化信任的公有云下TEE状态连续性保护系统，所述基于去中心化信任的公有云下TEE状态连续性保护系统包括：
初始化模块100，用于基于区块链对状态服务实例进行初始化处理；
状态更新模块200，用于基于加密传输和会话密钥更新应用程序实例的状态请求；
状态读取模块300，用于控制所述应用程序实例读取所述状态服务实例的最新状态；
重启模块400，用于当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；还用于当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
如图10所示，所述系统包括：可信平台及区块链，所述应用程序实例(AE)和所述状态服务实例(SE)运行在所述可信平台，所述应用程序实例处理客户的请求并返回相应的输出，所述状态服务实例为所述应用程序实例提高状态连续性保护。
具体地，本实施例中，所述基于去中心化信任的公有云下TEE状态连续性保护系统及其各个模块的具体功能还可以参照所述基于去中心化信任的公有云下TEE状态连续性保护方法中的对应描述，在此不再赘述。
基于所述实施例，本发明还提供了一种智能终端，其原理框图可以如图11所示。所述智能终端包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的基于去中心化信任的公有云下TEE状态连续性保护程序，所述基于去中心化信任的公有云下TEE状态连续性保护程序被所述处理器执行时实现如上任意一项所述基于去中心化信任的公有云下TEE状态连续性保护方法的步骤。
本领域技术人员可以理解，图11中示出的原理框图，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的智能终端的限定，具体地智能终端可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，所述基于去中心化信任的公有云下TEE状态连续性保护程序被所述处理器执行时进行以下操作指令：
基于区块链对状态服务实例进行初始化处理；
基于加密传输和会话密钥更新应用程序实例的状态请求；
控制所述应用程序实例读取所述状态服务实例的最新状态；
当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有基于去中心化信任的公有云下TEE状态连续性保护程序，所述基于去中心化信任的公有云下TEE状态连续性保护程序被处理器执行时实现如上任意一项所述基于去中心化信任的公有云下TEE状态连续性保护方法的步骤。
应理解，所述实施例中各步骤的序号大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以所 述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将所述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，所述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。所述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在所述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各实例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟是以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
在本发明所提供的实施例中，应该理解到，所揭露的装置/终端设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/终端设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以由另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本发明实现所述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现所述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读存储介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减。
以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解；其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不是相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (10)

  1. 一种基于去中心化信任的公有云下TEE状态连续性保护方法，其特征在于，所述基于去中心化信任的公有云下TEE状态连续性保护方法包括：
    基于区块链对状态服务实例进行初始化处理；
    基于加密传输和会话密钥更新应用程序实例的状态请求；
    控制所述应用程序实例读取存储在所述状态服务实例中的最新状态；
    当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
  2. 根据权利要求1所述的基于去中心化信任的公有云下TEE状态连续性保护方法，其特征在于，所述基于去中心化信任的公有云下TEE状态连续性保护方法还包括：
    通过所述区块链的第一接口将所述状态服务实例的身份标识号码和公钥写到所述区块链上，并记录初始化信息；
    通过所述区块链的第二接口根据所述状态服务实例的身份标识号码和公钥在所述区块链上查询初始化信息；
    通过所述区块链的第三接口在所述应用程序实例更新状态摘要时，向所述状态服务实例请求更新是否合法；
    通过所述区块链的第四接口获取所述应用程序实例的状态摘要。
  3. 根据权利要求1所述的基于去中心化信任的公有云下TEE状态连续性保护方法，其特征在于，所述基于区块链对所述状态服务实例进行初始化处理，具体包括：
    将任意一个所述状态服务实例设置为领导者，通过远程证明相互验证所述领导者和其他状态服务实例的身份，并建立所述领导者与其他状态服务实例的安全通信信道；
    控制所述领导者和其他状态服务实例生成非对称密钥对，并将所述状态服务实例的公钥发送给所述领导者，所述领导者将接收到的公钥列表分发给其他状态服务实例；
    控制每个所述状态服务实例向所述区块链发送读请求，所述读请求包括所述状态服务实例的唯一标识符；
    控制每个所述状态服务实例向所述区块链发送写请求，当收到来自所述区块链的确认字符时，控制每个所述状态服务实例创建本地内存，所述本地内存包括其他状态服务实例状态条目的状态服务实例状态表和空的应用程序实例状态表；
    控制本地状态服务实例将所述公钥列表放置到所述本地状态服务实例的本地内存以生成状态服务实例配置表，并控制所述本地状态服务实例通过运行经过验证的密钥协议与其他状态服务实例建立成对会话密钥；
    密封并存储所述本地状态服务实例的密钥对、所述状态服务实例配置表和所述应用程序实例状态表。
  4. 根据权利要求3所述的基于去中心化信任的公有云下TEE状态连续性保护方法，其特征在于，所述基于加密传输和会话密钥更新所述应用程序实例的状态请求，具体包括：
    当所述应用程序实例接收到用户请求时，密封并存储所述应用程序实例的状态快照到磁盘上，并更新所述应用程序实例的状态摘要，向所述本地状态服务实例发送状态更新请求；
    当所述本地状态服务实例接收到状态更新请求时，存储所述状态更新请求到请求队列；
    当处理所述状态更新请求时，控制所述本地状态服务实例向所述本地状态服务实例和其他状态服务实例发送所述状态更新请求；
    当所述本地状态服务实例和其他状态服务实例接收到所述状态更新请求时，更新所述本地状态服务实例和其他状态服务实例状态内存中所述本地状态服务实例的状态摘要并发送回复消息；
    当所述本地状态服务实例收到超过f+1个所述回复消息时，所述本地状态服务实例向其他状态服务实例发送决定消息，其中，f为共识节点容错数；
    当其他状态服务实例收到所述决定消息后，检查其他状态服务实例是否已回复准备消息，若是，则控制所述状态服务实例发回包含状态摘要的确认字符；
    当所述本地状态服务实例收到超过f+1个所述确认字符时，控制所述本地状态服务实例更新所述应用程序实例的状态摘要并向所述应用程序实例回复包含状态摘要的确认字符；
    当所述应用程序实例收到所述确认字符时，将其状态更新为最新状态并发布相关输出。
  5. 根据权利要求4所述的基于去中心化信任的公有云下TEE状态连续性保护方法，其特征在于，所述控制所述应用程序实例读取所述状态服务实例的最新状态，具体包括：
    控制所述应用程序实例调用函数向所述本地状态服务实例发送状态读取请求；
    当所述本地状态服务实例收到所述状态读取请求时，检索全部所述状态服务实例的最新状态；
    检查每个所述状态服务实例的状态服务实例状态表，并将存储的状态摘要发回给所述本地状态服务实例；
    当收到f+1个所述状态摘要时，选择索引最大的状态摘要作为所述本地状态服务实例的状态摘要。
  6. 根据权利要求5所述的基于去中心化信任的公有云下TEE状态连续性保护方法，其特征在于，所述当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态，具体包括：
    控制重启后的所述状态服务实例与其他状态服务实例建立新的会话密钥；
    控制重启后的所述状态服务实例获取所述状态服务实例和其他状态服务实例的状态摘要；
    选择索引最大的状态摘要作为重启后的所述状态服务实例的状态摘要；
    控制所述状态服务实例从操作系统获取密封的状态摘要，将所述状态摘要与从其他状态服务实例获取的状态摘要进行匹配，若匹配，则控制所述状态服务实例恢复所述状态服务实例的状态摘要。
  7. 根据权利要求6所述的基于去中心化信任的公有云下TEE状态连续性保护方法，其特征在于，所述当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态，具体包括：
    控制重启后的所述应用程序实例向所述本地状态服务实例请求最新状态摘要；
    控制所述应用程序实例获取所述操作系统的密封状态数据，将所述密封状态数据与所述最新状态摘要进行匹配，若匹配成功，则更新重启后所述应用程 序实例的状态摘要并发布输出。
  8. 一种基于去中心化信任的公有云下TEE状态连续性保护系统，其特征在于，所述基于去中心化信任的公有云下TEE状态连续性保护系统包括：
    初始化模块，用于基于区块链对状态服务实例进行初始化处理；
    状态更新模块，用于基于加密传输和会话密钥更新应用程序实例的状态请求；
    状态读取模块，用于控制所述应用程序实例读取所述状态服务实例的最新状态；
    重启模块，用于当所述状态服务实例发生重启时，基于会话密钥恢复所述状态服务实例的状态；还用于当所述应用程序实例发生重启时，基于操作系统的密封状态数据恢复所述应用程序实例的状态。
  9. 一种智能终端，其特征在于，所述智能终端包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的基于去中心化信任的公有云下TEE状态连续性保护程序，所述基于去中心化信任的公有云下TEE状态连续性保护程序被所述处理器执行时实现如权利要求1-7任意一项所述基于去中心化信任的公有云下TEE状态连续性保护方法的步骤。
  10. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有基于去中心化信任的公有云下TEE状态连续性保护程序，所述基于去中心化信任的公有云下TEE状态连续性保护程序被处理器执行时实现如权利要求1-7任意一项所述基于去中心化信任的公有云下TEE状态连续性保护方法的步骤。
PCT/CN2022/119945 2022-09-07 2022-09-20 基于去中心化信任的公有云下tee状态连续性保护方法 Ceased WO2024050869A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211087946.7 2022-09-07
CN202211087946.7A CN115168872B (zh) 2022-09-07 2022-09-07 基于去中心化信任的公有云下tee状态连续性保护方法

Publications (1)

Publication Number Publication Date
WO2024050869A1 true WO2024050869A1 (zh) 2024-03-14

Family

ID=83481903

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/119945 Ceased WO2024050869A1 (zh) 2022-09-07 2022-09-20 基于去中心化信任的公有云下tee状态连续性保护方法

Country Status (2)

Country Link
CN (1) CN115168872B (zh)
WO (1) WO2024050869A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018104326A1 (en) * 2016-12-06 2018-06-14 Eth Zurich Methods and systems for detecting rollback attacks
US20190220603A1 (en) * 2019-03-27 2019-07-18 Intel Corporation Fast and secure protocol to bootstrap a blockchain by restoring the blockchain state using trusted execution environment
CN114117522A (zh) * 2021-11-23 2022-03-01 上海交通大学 基于区块链和可信执行环境的车联网数据共享实现方法
CN114547656A (zh) * 2022-02-26 2022-05-27 北京工业大学 一种云环境下基于Intel SGX的两阶段远程证明方法
CN114826684A (zh) * 2022-03-31 2022-07-29 西安电子科技大学 支持高效隐私保护的去中心化众包方法、系统及终端

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110392888A (zh) * 2017-01-16 2019-10-29 E·马伊姆 用于在安全环境中执行智能合约的方法和系统
CN108306740B (zh) * 2018-01-22 2020-07-31 华中科技大学 一种Intel SGX状态一致保护方法和系统
US11126699B2 (en) * 2018-02-07 2021-09-21 Nec Corporation Replica trusted execution environment: enabling seamless replication of trusted execution environment (TEE)-based enclaves in the cloud
CN108418691B (zh) * 2018-03-08 2020-10-27 湖南大学 基于sgx的动态网络身份认证方法
US12470396B2 (en) * 2020-10-27 2025-11-11 Nec Corporation Rollback protection with ephemeral identities for tee-based consensus protocols
CN112380578A (zh) * 2020-11-20 2021-02-19 天翼电子商务有限公司 一种基于区块链和可信执行环境的边缘计算框架
CN113286300B (zh) * 2021-05-17 2023-01-17 中国联合网络通信集团有限公司 基于区块链的网络分片认证方法、系统、网元及存储介质
CN113326529A (zh) * 2021-06-24 2021-08-31 北京八分量信息科技有限公司 一种基于可信计算的去中心化架构统一方法
CN113489743B (zh) * 2021-07-26 2022-12-23 广东辰宜信息科技有限公司 应用于区块链系统的共识实现方法及装置
CN113849210A (zh) * 2021-09-26 2021-12-28 支付宝(杭州)信息技术有限公司 一种基于tee的固件升级方法及装置
CN114647487B (zh) * 2022-03-21 2026-03-24 蚂蚁金服（杭州）网络技术有限公司 用于提供基于amd sev的可信执行环境的装置及可信执行系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018104326A1 (en) * 2016-12-06 2018-06-14 Eth Zurich Methods and systems for detecting rollback attacks
US20190220603A1 (en) * 2019-03-27 2019-07-18 Intel Corporation Fast and secure protocol to bootstrap a blockchain by restoring the blockchain state using trusted execution environment
CN114117522A (zh) * 2021-11-23 2022-03-01 上海交通大学 基于区块链和可信执行环境的车联网数据共享实现方法
CN114547656A (zh) * 2022-02-26 2022-05-27 北京工业大学 一种云环境下基于Intel SGX的两阶段远程证明方法
CN114826684A (zh) * 2022-03-31 2022-07-29 西安电子科技大学 支持高效隐私保护的去中心化众包方法、系统及终端

Also Published As

Publication number Publication date
CN115168872B (zh) 2023-01-10
CN115168872A (zh) 2022-10-11

Similar Documents

Publication Publication Date Title
TWI707245B (zh) 使用高可用性的可信執行環境檢索區塊鏈網路的存取資料
US20230026873A1 (en) Secure and trustworthy bridge for transferring assets across different networks
CN111090874B (zh) 调用合约的方法及装置
US11893577B2 (en) Cryptographic key storage system and method
CN111541785A (zh) 基于云计算的区块链数据处理方法及装置
JP7000491B2 (ja) バイパス不可能なゲートウェイを使用するｔｐｍベースの安全なマルチパーティ・コンピュータシステム
US20090106549A1 (en) Method and system for extending encrypting file system
US12445415B2 (en) Verifiable identity map maintaining identities and associated public keys
US9729321B2 (en) Autonomous private key recovery
KR20160129852A (ko) 장치 간 신뢰 애플리케이션을 위한 보안 하드웨어
US10887085B2 (en) System and method for controlling usage of cryptographic keys
WO2020042822A1 (zh) 密码运算、创建工作密钥的方法、密码服务平台及设备
CN202663444U (zh) 一种云安全数据迁移模型
CN111949602A (zh) 一种支持完整性验证的外包数据安全迁移方法与系统
Soriente et al. Replicatee: Enabling seamless replication of sgx enclaves in the cloud
CN117157623A (zh) 结合容器化应用程序使用时保护秘密的系统和方法
Ren et al. Restricting the number of times that data can be accessed in cloud storage using trustzone
CN115168872B (zh) 基于去中心化信任的公有云下tee状态连续性保护方法
US12184789B2 (en) Blockchain based certificate pinning
US20260074917A1 (en) Fine-grained control for client access to network services
CN118802319A (zh) 一种基于可信执行环境的容器安全迁移方法
CN121145264A (zh) 基于可信执行环境的全密态数据库文件调用方法、全密态数据库服务器及存储介质
CN119906536A (zh) 一种基于智能合约的在移动应用间建立安全通信渠道的方法
HK40072512A (zh) 基於云分发的网络访问方法及其系统、介质、设备
HK40093113B (zh) 可信数据处理方法及相关装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22957837

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22957837

Country of ref document: EP

Kind code of ref document: A1