A method for joint verification storage system based on blockchain and TEE

Abstract

The present invention discloses a method for a joint verification storage system based on blockchain and TEE, which solves the problem that the existing storage technology uses pure blockchain and centralized cloud storage solutions with their own shortcomings. The method includes an account initiating a storage subject event request; querying the first node where the storage subject is located in the blockchain according to the request, and performing signature verification in the TEE environment; when the signature verification passes, obtaining the corresponding permission configuration information of the storage subject, and performing operation permission verification; when the operation permission verification passes, obtaining the corresponding storage subject data for event processing. The present invention performs joint verification of the storage system based on blockchain and TEE, solving the problem of the lack of hardware-level privacy protection in blockchain and the problem of traditional TEE solutions relying on centralized authentication. The present invention constructs a decentralized hardware trusted verification network, realizes hardware-level protection of the entire life cycle of the key, and establishes a flexible and dynamic storage verification solution based on the blockchain.

Description

Technical Field

[0001] The present invention relates to the field of data security technology, and in particular to a method for a joint verification storage system based on blockchain and TEE. Background Art

[0002] Existing storage systems fall into two categories: pure blockchain storage and verification solutions and centralized cloud storage solutions. Both approaches currently have their own shortcomings. Pure blockchain storage and verification solutions rely on full-node data backup and require linear verification, resulting in inefficient management. Blockchain functionality is limited, making it inadequate for flexible storage and verification solutions. Furthermore, blockchains lack hardware-level privacy protection. Centralized cloud storage solutions use TEEs (Tradable Execution Environments) for data encryption and rely on centralized authentication, leading to information loss and privacy leaks. To address these issues, research is needed on a joint verification storage system that combines the advantages of blockchain and TEEs. For example, patent application number CN202411106725.9, entitled "Blockchain-Based Decentralized Data Storage Method and System," utilizes blockchain technology to record and distribute metadata, while using a decentralized storage network to store and distribute actual data. Users authorize access using private keys. This patent exhibits these shortcomings. While it utilizes blockchain technology for data storage, it relies on secret keys for storage verification, resulting in a single storage verification method that cannot meet flexible storage verification requirements. Summary of the Invention

[0003] The present invention mainly solves the problem that pure blockchain and centralized cloud storage solutions in existing storage technologies have their own shortcomings, and provides a method for a joint verification storage system based on blockchain and TEE.

[0004] The above technical problems of the present invention are mainly solved by the following technical solutions: a method for a joint verification storage system based on blockchain and TEE, comprising:

[0005] The account initiates a request to store topic events;

[0006] The client queries the first node where the topic is stored in the blockchain according to the request, and the first node performs signature verification in the TEE environment;

[0007] When the signature verification passes, obtain the permission configuration information corresponding to the storage subject and perform operation permission verification according to the permission configuration information;

[0008] When the operation permission verification is passed, the corresponding storage topic data is obtained for event processing;

[0009] The first node performs synchronization operations on the backup node.

[0010] This invention uses blockchain and TEE to jointly verify storage systems, addressing the blockchain's lack of hardware-level privacy protection and the traditional TEE solution's reliance on centralized authentication. It builds a decentralized hardware-trusted verification network, enabling hardware-level protection of keys throughout their lifecycle and establishing a flexible and dynamic storage verification solution based on blockchain.

[0011] Storage topic event requests include data access, data addition, and data modification requests. Accounts submit storage topic events on the client side. Based on the storage topic the account wishes to access, the client side queries the blockchain for a list of storage nodes for the storage topic data. The account then submits a signed event request to a valid first node that stores the desired storage topic. The first node performs access signature and operation permission verification within the TEE environment. If the signature verification passes and the operation permission is verified, the first node authorizes the TEE to seal the data access, unseals the data the account wishes to access, and accesses, adds, or modifies the data as required by the event request. After the data is added or modified, the first node notifies the client of a successful operation and adds the requested operation to the pending synchronization queue. The node backup task then synchronizes the updated data to the backup nodes that back up the storage topic. When the backup node receives a data operation update request from another connected first node, it verifies the signature and operation permission of the account that made the initial event request. If verification passes, the local data is updated.

[0012] As a preferred solution, all first nodes run in a TEE environment within a designated enclave. In this solution, the first node represents a node that has joined the network, and the backup node is a node selected from the first node for data backup. All first nodes run in the TEE environment of a designated enclave, and their operational logic is transparent and predictable. An enclave is an isolated, secure execution area within a TEE.

[0013] As a preferred option,

[0014] The storage topic event request initiated by the account includes a signature;

[0015] The first node verifies the signature in the TEE environment. If the verification passes, the operation permission verification is performed. If the verification fails, the signature error is fed back and the storage of the subject event is stopped.

[0016] The storage topic event initiated by the account carries the account signature. In this step, the first node verifies the legitimacy of the account through the account signature in the event request. The signature verification method adopts the existing technology.

[0017] As a preferred solution, obtaining the permission configuration information corresponding to the storage subject includes:

[0018] Determine whether the current first node stores the storage topic. If so, obtain the permission configuration file of the storage topic and read the permission configuration information of the storage topic. If not, feedback an error.

[0019] After the account signature is verified, the first node performs operation permission verification. It first determines whether the first node currently stores the storage topic. If it determines that the first node stores the storage topic, it reads the storage topic's permission configuration information from the corresponding permission configuration file. The storage topic database and the permission configuration file are jointly generated and stored on the first node.

[0020] As a preferred solution, operation permission verification is performed based on permission configuration information, including:

[0021] Determine whether the requesting account has the corresponding operation permission based on the permission configuration information. If so, perform corresponding operations on the stored subject data according to the request event, and the first node synchronizes the backup node. If not, return a permission error and stop storing the subject event.

[0022] The first node of this solution determines whether the event requesting account has the corresponding operation permission based on the obtained permission configuration information. If the requesting account has the operation permission, the first node authorizes the account to access TEE sealed data.

[0023] As a preferred solution, when the backup node obtains a synchronization operation request, it also obtains the signature of the requesting account, performs signature verification and operation authority verification on the requesting account, and updates local data after both verifications are passed.

[0024] When the backup node receives a data operation update request from another first node that has connected to the network, it verifies the signature and operation authority of the account of the initial event request, and updates the local data after the verification is passed.

[0025] As a preferred solution, the establishment of the first node is also included, including the following process:

[0026] The node to be connected initiates a connection request, and the TEE environment generates an identity. The connection request, including the identity and the node's remote identity certificate, is submitted to the blockchain smart contract.

[0027] After the smart contract verifies the identity and data of the node to be connected, it dispatches other first nodes that have already joined the network to conduct network verification on the node to be connected;

[0028] After the verification is passed, the node to be connected to the network will be connected to the network and become the first node.

[0029] The storage system joint verification of the present invention also includes access verification of network nodes, which ensures the trustworthiness of node identities through blockchain and TEE authentication, and implements decentralized authentication based on blockchain to effectively prevent witch attacks.

[0030] The establishment of a first node involves the node initiating a network access request. The node also runs in the TEE environment of a designated enclave. The node generates an identity identifier, or EnclaveID, within the TEE environment. The EnclaveID is the hardware identity of the enclave generated by the TEE environment. The node obtains remote identity proof through remote authentication, which cryptographically verifies the integrity of the TEE environment. The node submits the EnclaveID and remote identity proof to a blockchain smart contract. After the blockchain smart contract confirms the validity of the EnclaveID and the data submitted by the node, it registers the network access request and schedules other first nodes for network access verification.

[0031] As a preferred solution, network access verification for nodes to be connected to the network includes:

[0032] The smart contract registers the network access request of the node to be connected and sets a cooling period;

[0033] The first node that receives the schedule verifies the remote identity of the node to be connected within the cooling period to determine whether the node is running in the secure execution area associated with its identity. If not, it submits an exception report to the blockchain.

[0034] After the cooling-off period, the node to be networked submits its network access application to the smart contract again. If the smart contract verifies that the identity identifier is consistent with the first submission and no abnormality report from other first nodes is received during the cooling-off period, the network access verification is passed.

[0035] In this solution, network access verification includes setting a cooling cycle and randomly scheduling other first-connected nodes to verify network access requests during the cooling cycle. The first-connected node that receives the schedule verifies the TEE remote identity certificate in the network access request of the node to be connected to the network to confirm whether the node to be connected to the network is running in the Enclave environment associated with the EnclaveID. If not, it directly submits an exception report to the blockchain. After the cooling cycle, the node to be connected to the network submits the network access request to the blockchain smart contract again. The blockchain smart contract verifies whether the submitted EnclaveID is consistent with the first submitted EnclaveID. If the submitted EnclaveID is consistent with the first submitted EnclaveID, and no exception report is received for the first network access request during the cooling cycle, the network access request of the node to be connected to the network passes the verification, and the node to be connected to the network becomes the first node to be connected to the network. The smart contract will add the node that has passed the network access verification to the whitelist.

[0036] First nodes that pass verification continuously perform self-checks and mutual checks. Mutual checks involve first nodes periodically and randomly issuing remote attestation challenges to other first nodes to confirm that the other first nodes' operating environments are consistent with the enclave specified on the blockchain. If not, the node anomaly is reported to the blockchain smart contract. Self-checks involve first nodes periodically and randomly checking the integrity of data sealed in the TEE environment and ensuring it has not been tampered with. If anomalies are found, the node anomaly is reported to the blockchain smart contract.

[0037] As a preferred solution, the first node to enter the network performs permission initialization, including:

[0038] To initialize permissions, the account sends a signature-based request to create a storage topic to the first node that joins the network.

[0039] After receiving the request to create a storage topic and verifying the signature, the first node establishes the database and permission configuration file corresponding to the storage topic in the TEE environment;

[0040] The established database and permission configuration files are sealed and stored in the TEE environment, achieving hardware-level protection of the secret key and resisting system-level software layer attacks.

[0041] The account that creates the storage topic automatically has the management permissions for the database and permission configuration file of the storage topic.

[0042] Select a backup node to back up the database and permission configuration files storing the subject and register them on the blockchain;

[0043] After the first node is established, its permissions are initialized. An account sends a request to create a storage topic to the first node through the client, carrying the account's signature. Upon receiving the request, the first node creates the corresponding database and permissions configuration file within the TEE environment. The account that created the storage topic automatically gains administrative rights to the storage topic database and permissions configuration file. The first node then backs up the created storage topic database and permissions configuration file across several backup nodes selected from the entire network and registers them on the blockchain. The backup nodes are selected from the first node.

[0044] As a preferred option,

[0045] The account initiates a permission configuration request;

[0046] The client queries the first node where the storage topic is located on the blockchain and initiates a permission configuration request. The first node performs signature verification in the TEE environment.

[0047] When the signature verification passes, obtain the permission configuration information corresponding to the storage subject and perform operation permission verification according to the permission configuration information;

[0048] When the operation permission verification is passed, the request permission configuration is updated to the storage subject permission configuration file and sealed and saved in the TEE environment;

[0049] Synchronize permission configuration between backup nodes.

[0050] An asynchronous request for synchronization between backup nodes is made for the updated permission configuration, that is, a synchronization task is created between backup nodes, processed asynchronously, and the permission configuration success is directly fed back to the client. Asynchronous processing improves the throughput of the storage system. The joint verification of the storage system of the present invention also includes permission configuration verification of the first node. The account initiates a permission configuration request through the client. The client queries the first node where the storage subject is located on the blockchain, selects a first node to initiate a permission configuration request with the account signature to it, and the first node that receives the request performs signature verification and operation permission verification on the account. When the account signature verification passes and the operation permission is obtained, the first node updates the requested permission configuration to the permission configuration file of the storage subject in the TEE environment and seals the permission configuration file. The first node submits the permission configuration for asynchronous request for synchronization between backup nodes, and feeds back permission configuration success information to the client.

[0051] Therefore, the advantages of this invention are: Joint verification of storage systems based on blockchain and TEE addresses the blockchain's lack of hardware-level privacy protection and the traditional TEE solution's reliance on centralized authentication. This invention builds a decentralized hardware trusted verification network, enabling hardware-level protection of keys throughout their lifecycle and establishing a flexible and dynamic storage verification solution based on blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a flow chart of the present invention.

[0053] Figure 2 It is a flow chart of establishing the first node in the present invention.

[0054] Figure 3 This is a flow chart of the first node authority initialization in the present invention.

[0055] Figure 4 This is a flow chart of the first node authority configuration in the present invention.

[0056] Figure 5 This is a flowchart of the permission configuration synchronization in the present invention. DETAILED DESCRIPTION

[0057] The technical solution of the present invention will be further specifically described below through embodiments and in conjunction with the accompanying drawings.

[0058] Example 1:

[0059] The present invention provides a method for jointly verifying a storage system based on blockchain and TEE, such as Figure 1 As shown, the following steps are included:

[0060] The account initiates a request to store topic events.

[0061] The client queries the first node where the topic is stored in the blockchain according to the request, and the first node performs signature verification in the TEE environment;

[0062] When the signature verification passes, obtain the permission configuration information corresponding to the storage subject and perform operation permission verification according to the permission configuration information;

[0063] When the operation permission verification is passed, the corresponding storage topic data is obtained for event processing;

[0064] The first node performs synchronization operations on the backup node.

[0065] This invention uses blockchain and TEE to jointly verify storage systems, addressing the blockchain's lack of hardware-level privacy protection and the traditional TEE solution's reliance on centralized authentication. It builds a decentralized hardware-trusted verification network, enabling hardware-level protection of keys throughout their lifecycle and establishing a flexible and dynamic storage verification solution based on blockchain.

[0066] In this invention, all connected nodes run in a designated enclave's TEE environment, with fully transparent and predictable operational logic. An enclave is an isolated, secure execution area within a TEE. The first node mentioned is the connected node, and the backup node is a node selected from the first node for data backup. All first nodes run in a designated enclave's TEE environment.

[0067] As a preferred solution of this embodiment, the subject events include data access, data addition, and data modification requests. The account initiates a storage subject event through the client, the account generates a signature, and the initiated storage subject event request carries the account signature.

[0068] As a preferred solution of this embodiment, the client queries the first node where the storage topic is located on the blockchain based on the request. The first node then performs signature verification in the TEE environment. Specifically, the client queries the blockchain for a list of storage nodes storing the topic data based on the storage topic the account wishes to access. The account then submits a signed event request through the client to a valid first node that stores the topic to be accessed. The first node that receives the topic event request obtains the signature in the request and verifies the signature in the TEE environment. The signature verification method uses existing techniques to determine whether the signature is legitimate. If so, the next step is to verify the operation permissions. If not, a signature error is reported, and the storage of the topic event is stopped.

[0069] As a preferred solution of this embodiment, when signature verification passes, the corresponding permission configuration information of the storage theme is obtained, and operation permission verification is performed based on the permission configuration information. Specifically, after signature verification passes, it is determined whether the current first node stores the storage theme. If so, the permission configuration file of the storage theme is obtained and the permission configuration information of the storage theme is read. The database of the storage theme and the permission configuration file are jointly created and stored on the corresponding first node. If not, an error is returned. After the first node obtains the permission configuration information, it determines whether the requesting account has the corresponding operation permission based on the permission configuration information. If so, the data to be accessed by the account is unsealed according to the requirements of the event request, and the corresponding operation is performed on the storage theme data. The first node synchronizes the backup node. If not, a permission error is returned and the storage theme event is terminated. The synchronization operation includes the first node querying the backup node that has backed up the storage theme through the blockchain and sending a synchronization operation request to the backup node. When the backup node obtains the synchronization operation request, the synchronization operation request carries the signature of the account. The backup node obtains the signature of the requesting account, verifies the signature and operation permission of the requesting account, and updates the local data after both verifications are successful.

[0070] This invention uses blockchain and TEE to jointly verify storage systems, addressing the blockchain's lack of hardware-level privacy protection and the traditional TEE solution's reliance on centralized authentication. It builds a decentralized hardware-trusted verification network, enabling hardware-level protection of keys throughout their lifecycle and establishing a flexible and dynamic storage verification solution based on blockchain.

[0071] Example 2:

[0072] The present invention discloses a second implementation of a method for jointly verifying a storage system based on blockchain and TEE, including verification of requests for storing subject events in the storage system, access verification of network nodes, and verification of permission configuration.

[0073] like Figure 1As shown, the verification of storage topic event request, the specific steps are as follows:

[0074] The account initiates a request to store topic events.

[0075] The client queries the first node where the topic is stored in the blockchain according to the request, and the first node performs signature verification in the TEE environment;

[0076] When the signature verification passes, obtain the permission configuration information corresponding to the storage subject and perform operation permission verification according to the permission configuration information;

[0077] When the operation permission verification is passed, the corresponding storage topic data is obtained for event processing;

[0078] The first node performs synchronization operations on the backup node.

[0079] This invention uses blockchain and TEE to jointly verify storage systems, addressing the blockchain's lack of hardware-level privacy protection and the traditional TEE solution's reliance on centralized authentication. It builds a decentralized hardware-trusted verification network, enabling hardware-level protection of keys throughout their lifecycle and establishing a flexible and dynamic storage verification solution based on blockchain.

[0080] In the present invention, all networked nodes run in the TEE environment of the specified Enclave, and the operating logic is transparent and predictable. The first node mentioned is the networked node, and the first node runs in the TEE environment of the specified Enclave.

[0081] As a preferred solution of this embodiment, the subject events include data access, data addition, and data modification requests. The account initiates a storage subject event through the client, the account generates a signature, and the initiated storage subject event request carries the account signature.

[0082] As a preferred solution of this embodiment, the client queries the first node where the storage topic is located on the blockchain based on the request. The first node then performs signature verification in the TEE environment. Specifically, the client queries the blockchain for a list of storage nodes storing the topic data based on the storage topic the account wishes to access. The account then submits a signed event request through the client to a valid first node that stores the topic to be accessed. The first node that receives the topic event request obtains the signature in the request and verifies the signature in the TEE environment. The signature verification method uses existing techniques to determine whether the signature is legitimate. If so, the next step is to verify the operation permissions. If not, a signature error is reported, and the storage of the topic event is stopped.

[0083] As a preferred solution of this embodiment, when signature verification passes, the corresponding permission configuration information of the storage theme is obtained, and operation permission verification is performed based on the permission configuration information. Specifically, after signature verification passes, it is determined whether the current first node stores the storage theme. If so, the permission configuration file of the storage theme is obtained and the permission configuration information of the storage theme is read. The database of the storage theme and the permission configuration file are jointly created and stored on the corresponding first node. If not, an error is returned. After the first node obtains the permission configuration information, it determines whether the requesting account has the corresponding operation permission based on the permission configuration information. If so, the data to be accessed by the account is unsealed according to the requirements of the event request, and the corresponding operation is performed on the storage theme data. The first node synchronizes the backup node. If not, a permission error is returned and the storage theme event is terminated. The synchronization operation includes the first node querying the backup node that has backed up the storage theme through the blockchain and sending a synchronization operation request to the backup node. When the backup node obtains the synchronization operation request, the synchronization operation request carries the signature of the account. The backup node obtains the signature of the requesting account, verifies the signature and operation permission of the requesting account, and updates the local data after both verifications are successful.

[0084] The method of the present invention also includes the establishment of the first node to enter the network, that is, the access verification of the node to enter the network, such as Figure 2 As shown, the specific steps include:

[0085] The node to be connected initiates a connection request, and the TEE environment generates an identity identifier to obtain remote identity proof.

[0086] Specifically, the establishment of the first node begins with the node to join the network initiating a network access request. The node also runs in the TEE environment of the specified enclave. The node generates an identity identifier, namely the EnclaveID, in the TEE environment. The EnclaveID is the hardware identity identifier of the enclave generated by the TEE environment. The node to join the network obtains remote identity proof, which is obtained through remote authentication. Remote authentication verifies the integrity of the TEE environment through cryptographic proof.

[0087] The node to be connected will submit a connection request including identity identification and node remote identity proof to the blockchain smart contract.

[0088] After the smart contract verifies the identity and data of the node to be connected, it dispatches other first nodes that have already connected to the network to perform network verification on the node to be connected.

[0089] As a preferred solution of this embodiment, after receiving the network access request, the smart contract verifies the validity of the EnclaveID of the network access request and the data submitted by the node to be networked. After confirming the validity of the EnclaveID and the data submitted by the node to be networked, it schedules other first nodes to perform network access verification.

[0090] Network access verification includes registering the access request of the node to be connected to the network through the smart contract and setting a cooling-off period.

[0091] The first node that receives the schedule verifies the remote identity of the node to be connected within the cooling period to determine whether the node is running in the secure execution area associated with its identity. If not, it submits an exception report to the blockchain.

[0092] After the cooling-off period, the node to be networked submits its network access application to the smart contract again. If the smart contract verifies that the identity identifier is consistent with the first submission and no abnormality report from other first nodes is received during the cooling-off period, the network access verification is passed.

[0093] Specifically, the network access verification process begins with a cooldown period set by the smart contract. It then randomly schedules other existing first-connected nodes to verify the candidate node's network access request during the cooldown period. The first-connected node that receives the schedule verifies the TEE remote identity certificate in the candidate node's network access request to confirm whether the candidate node is running in the enclave environment associated with its enclaveID. If so, it waits until the cooldown period ends; otherwise, it directly submits an exception report to the blockchain. After the cooldown period, the candidate node submits another network access request to the blockchain smart contract. The blockchain smart contract verifies whether the submitted enclaveID matches the first-submitted enclaveID. If not, the network access request is rejected. If the submitted enclaveID matches the first-submitted enclaveID, it determines whether any exception report for the candidate node's first request has been received during the cooldown period. If so, the network access request is rejected. If not, the candidate node's network access request has passed verification, becoming the first-connected node. The smart contract then adds the node that passed network access verification to the whitelist.

[0094] The first node that has passed the verification also includes continuous self-checking and mutual checking.

[0095] Mutual inspection involves the first node randomly initiating remote proof challenges to other first nodes at regular intervals to confirm whether the operating environment of other first nodes is consistent with the Enclave specified on the blockchain. If they are consistent, the mutual inspection ends; if they are inconsistent, the node abnormality is reported to the blockchain smart contract.

[0096] Self-inspection includes the first node regularly and randomly checking whether the data sealed in the TEE environment is complete and has not been tampered with. If no abnormality is found, the self-inspection ends. If an abnormality is found, the node's own abnormality is reported to the blockchain intelligence.

[0097] The method of the present invention also includes verification of the authority configuration. Before configuring the authority, the authority of the first node entering the network is initialized. Figure 3As shown, permission initialization includes the following steps:

[0098] The account sends a signature-based request to create a storage topic to the first node that joins the network.

[0099] The first node receives the request to create a storage topic, verifies the signature, and establishes a database and permission configuration file corresponding to the storage topic in the TEE environment. The database and permission configuration file are sealed and stored in the TEE environment to ensure privacy and anti-tampering;

[0100] Select a backup node to back up the database and permission configuration files storing the subject and register them on the blockchain.

[0101] As a preferred solution of this embodiment, the account sends a creation storage topic request including a signature to the first node that has entered the network. Specifically, the account initiates the creation storage topic request through the client, generates an account signature at the same time, and sends the creation storage topic request carrying the signature to the first node that has entered the network.

[0102] As a preferred solution of this embodiment, the first node receives a request to create a storage topic, and after verifying the signature, it establishes a database and permission configuration file corresponding to the storage topic in the TEE environment, and seals and saves them in the TEE environment. After the specific first node that has entered the network receives the request to create a storage topic, it obtains the account signature and verifies whether the signature is legal. If not, the request to create the storage topic is rejected; if so, the next step is carried out. The first node simultaneously creates a database and permission configuration file corresponding to the storage topic in the TEE environment, and seals and saves them in the TEE environment. The account sets management permissions, including granting management permissions to other accounts. The account that creates the storage topic automatically has management permissions for the storage topic database and permission configuration file.

[0103] As a preferred solution of this embodiment, a backup node is selected to back up the database and permission configuration file of the storage subject and register them on the blockchain. Specifically, the first node selects several backup nodes in the entire network. The backup nodes are selected from the first nodes that have been connected to the network. Preferably, 5 backup nodes are selected. The first node will establish a backup of the storage subject database and permission configuration file on these backup nodes, verify the integrity of the backup, and register it on the blockchain, including generating a storage subject record, recording the backup information, and updating the status on the chain.

[0104] The method of the present invention further includes configuring the authority of the first node, that is, verifying the authority configuration, such as Figure 4 As shown, the following steps are included:

[0105] The account initiates a permission configuration request;

[0106] The client queries the first node where the storage topic is located on the blockchain and initiates a permission configuration request. The first node performs signature verification in the TEE environment.

[0107] When the signature verification passes, obtain the permission configuration information corresponding to the storage subject and perform operation permission verification according to the permission configuration information;

[0108] When the operation permission verification is passed, the request permission configuration is updated to the storage subject permission configuration file and sealed to the TEE environment;

[0109] Synchronize permission configuration between backup nodes.

[0110] As a preferred solution of this embodiment, the account initiates a permission configuration request, the client queries the first node where the storage subject is located on the blockchain and initiates a permission configuration request, and the first node performs signature verification in the TEE environment. Specifically, the account initiates a permission configuration request through the client, the client queries the first node where the storage subject is located on the blockchain, selects a first node and initiates a permission configuration request carrying the account signature to it. After receiving the permission configuration request, the first node obtains the account signature and verifies whether the account signature is legal. If not, it feedbacks a signature error and rejects the permission configuration request. If so, it performs account operation permission verification.

[0111] As a preferred solution of this embodiment, when signature verification passes, the corresponding permission configuration information of the storage subject is obtained, and operation permission verification is performed based on the permission configuration information. Specifically, after signature verification passes, the first node determines whether the storage subject is stored. If not, an error message is returned. If so, the permission configuration information of the storage subject is read from the permission configuration file of the storage subject. Then, based on the permission configuration information, it is determined whether the requesting account has operation permission. If the account does not have operation permission, a permission error message is returned, and the permission configuration request is rejected. If the account has operation permission, the permission configuration is allowed.

[0112] As a preferred solution of this embodiment, when the operation permission verification is passed, the requested permission configuration is updated to the storage subject permission configuration file. Specifically, after the operation permission verification is passed, the first node updates the requested permission configuration to the storage subject permission configuration file in the TEE environment and seals the permission configuration file.

[0113] As a preferred solution for this embodiment, the permission configuration is synchronized between backup nodes. Specifically, the first node submits an asynchronous request for permission configuration synchronization between backup nodes and feedbacks the client with a successful permission configuration. When the first node that backs up the storage topic receives a permission configuration update request from another first node, it verifies the account signature and operation permissions of the original request before updating the permission configuration.

[0114] like Figure 5 As shown, the permission configuration is synchronized between backup nodes, which specifically includes the following steps:

[0115] The first node queries the backup node that backs up the storage topic from the blockchain, obtains the backup node list, creates a permission configuration synchronization task, and sends a synchronization request to the backup node in parallel. The synchronization request carries the signature of the account that originally requested the permission configuration.

[0116] When the backup node receives a synchronization request, it verifies the signature carried in it to verify whether the account signature is legal. If not, it will feedback a signature error and reject the synchronization request. If so, it will verify the account operation permissions.

[0117] The backup node reads the permission configuration information of the storage topic from the permission configuration file of the storage topic, and determines whether the requesting account has the operation permission based on the permission configuration information. If the account does not have the operation permission, it will feedback a permission error and reject the synchronization request; if the account has the operation permission, it will update the local configuration.

[0118] The specific embodiments described herein are merely illustrative of the spirit of the present invention. Persons skilled in the art may make various modifications, additions, or substitutions to the described specific embodiments without departing from the spirit of the present invention or exceeding the scope of the appended claims.

[0119] Although this document frequently uses terms such as storage topic, first node, backup node, node to be added to the network, rights profile, identity, remote identity verification, and smart contract, the use of other terms is not excluded. These terms are used solely to more conveniently describe and explain the essence of the present invention; interpreting them as any additional limitations is contrary to the spirit of the present invention.

Claims

1. A method for a joint verification storage system based on blockchain and TEE, characterized in that: include: The account initiates a request to store topic events; The client queries the first node where the topic is stored in the blockchain according to the request, and the first node performs signature verification in the TEE environment; When the signature verification passes, obtain the permission configuration information corresponding to the storage subject and perform operation permission verification according to the permission configuration information; When the operation permission verification is passed, the corresponding storage topic data is obtained for event processing; The first node performs synchronization operations on the backup node; The first node establishment includes: The node to be connected initiates a connection request, and the TEE environment generates an identity. The connection request, including the identity and the node's remote identity certificate, is submitted to the blockchain smart contract. After the smart contract verification is passed, other first nodes that have joined the network are randomly scheduled to verify the network access request within the cooling period. After the cooling period, the node to be joined will submit the network access application again. The smart contract verifies that the identity is consistent with the first time and no abnormal report is received during the cooling period. After the network access verification is passed, the node to be joined will join the network and become the first node.

2. The method of a joint verification storage system based on blockchain and TEE according to claim 1 is characterized by: The first node runs in the TEE environment of the specified Enclave.

3. The method of a joint verification storage system based on blockchain and TEE according to claim 1 is characterized by: The storage topic event request initiated by the account includes a signature; The first node verifies the signature in the TEE environment. If the verification passes, the operation permission verification is performed. If the verification fails, the signature error is fed back and the storage of the subject event is stopped.

4. A method for a joint verification storage system based on blockchain and TEE according to claim 3, characterized in that: Obtaining the corresponding permission configuration information of the storage topic includes: Determine whether the current first node stores the storage topic. If so, obtain the permission configuration file of the storage topic and read the permission configuration information of the storage topic. If not, feedback an error.

5. A method for a joint verification storage system based on blockchain and TEE according to claim 3 or 4, characterized in that: Verify operation permissions based on permission configuration information, including: Determine whether the requesting account has the corresponding operation permission based on the permission configuration information. If so, perform corresponding operations on the stored subject data according to the request event, and the first node synchronizes the backup node. If not, return a permission error and stop storing the subject event.

6. The method of a joint verification storage system based on blockchain and TEE according to claim 5 is characterized by: When the backup node receives a synchronization operation request, it also obtains the signature of the requesting account, performs signature verification and operation permission verification on the requesting account, and updates the local data after both verifications are passed.

7. A method for a joint verification storage system based on blockchain and TEE according to claim 1, 2, 3 or 4, characterized in that: The establishment of the first node also includes the following process: After the smart contract verifies the identity and data of the node to be connected, it dispatches other first nodes that have already connected to the network to perform network verification on the node to be connected.

8. A method for a joint verification storage system based on blockchain and TEE according to claim 7, characterized in that: The network access verification for the node to be connected to the network includes: The smart contract registers the network access request of the node to be connected and sets a cooling period; The first node that receives the schedule verifies the remote identity of the node to be connected within the cooling period to determine whether the node is running in the secure execution area associated with its identity. If not, it submits an exception report to the blockchain. After the cooling-off period, the node to be networked submits its network access application to the smart contract again. If the smart contract verifies that the identity identifier is consistent with the first submission and no abnormality report from other first nodes is received during the cooling-off period, the network access verification is passed.

9. A method for a joint verification storage system based on blockchain and TEE according to claim 8, characterized in that: The first node to enter the network performs permission initialization, including: To initialize permissions, the account sends a signature-based request to create a storage topic to the first node that joins the network. The first node receives the request to create a storage topic, verifies the signature, and establishes the database and permission configuration file corresponding to the storage topic in the TEE environment, and seals and saves them in the TEE environment; Select a backup node to back up the database and permission configuration files storing the subject and register them on the blockchain.

10. A method for a joint verification storage system based on blockchain and TEE according to claim 9, characterized in that: It also includes configuring permissions for the first node, including: The account initiates a permission configuration request; The client queries the first node where the storage topic is located on the blockchain and initiates a permission configuration request. The first node performs signature verification in the TEE environment. When the signature verification passes, obtain the permission configuration information corresponding to the storage subject and perform operation permission verification according to the permission configuration information; When the operation permission verification is passed, the request permission configuration is updated to the storage subject permission configuration file and sealed to the TEE environment; Synchronize permission configuration between backup nodes.

Images