Method for supporting concurrent execution of multiple trusted execution environments based on RISC-V

Abstract

The invention discloses a method for supporting concurrent execution of multiple trusted execution environments based on RISC-V. The method comprises the following steps of: 1, creating trusted execution environments, establishing Group and determining a master-slave relationship, and before each participated trusted execution environment is added into the Group, proving that a calculation process executed by the trusted execution environment is in accordance with expectation to a security monitor; the master Enclave calculates a Group Key in the security monitor through an HMAC security algorithm, and distributes the Group Key to the slave Enclave; 2, a master-slave trust architecture is established, a master trusted execution environment is responsible for coordinating data distribution, aggregation and access control strategy management, and other slave trusted execution environments serve as cooperative nodes to execute specific data processing tasks; and step 3, when data interaction is carried out between the master Enclave and the slave Enclave, a trusted shared memory mechanism supported by the Keystone-Enclave is used as a communication channel. The data processing performance and the system throughput are remarkably improved, and the method has the advantages of being high in performance, high in throughput, high in safety and high in expandability.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, and more specifically to a method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment. Background Technology

[0002] Keystone-Enclave is a framework based on the RISC-V (Reduced Instruction Set Computing) architecture for building trusted execution environments. It provides a highly trusted execution environment by segmenting, protecting, and controlling memory regions through hardware-supported isolation mechanisms. This ensures that applications running in the trusted execution environment have their own independent memory regions that external code cannot access, thereby preventing memory leaks and data tampering.

[0003] IPFS (InterPlanetary File System) is a content-addressable, peer-to-peer, distributed file system.

[0004] With the continuous development of computing technology, data security and privacy protection have become critical issues. Using a technology that integrates Keystone-Enclave with IPFS enhances the security of uploading / downloading files to the IPFS storage network, aiming to prevent tampering with uploaded source files or malicious modification of downloaded files. However, this method relies on the computing power of a trusted execution environment, which has relatively weak computing capabilities, leaving room for performance improvement.

[0005] From the perspectives of performance enhancement and security assurance, Keystone-Enclave's multi-trusted execution environment concurrency is used to improve its performance. Keystone-Enclave's trusted execution environment has the ability to support multi-trusted execution environment concurrency and data interaction. However, Keystone-Enclave's existing technology can only guarantee the trustworthiness of its own trusted environment, the security of data within the trusted environment, and the security of data interaction, but it does not have the ability to guarantee the security of data sources, the security of data throughout the entire process, or the mutual trust proof between trusted execution environments. Summary of the Invention

[0006] To overcome the shortcomings of the existing technology, the present invention provides a method for supporting concurrent execution of multiple trusted execution environments based on RISC-V. This method significantly improves data processing performance and system throughput by enabling concurrent execution of multiple trusted execution environments based on RISC-V, and features high performance, high throughput, strong security, and high scalability.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment includes the following steps; Step 1: Before initiating collaborative tasks among multiple Keystone-Enclave trusted execution environments, the security engine first creates trusted execution environments sequentially, establishes a Group, and establishes a master-slave relationship. Each Group has a unique creation engine identifier (engine id). Before joining a Group, each participating trusted execution environment must prove to the security monitor (SM) that the computation process it executes meets expectations. The master enclave calculates the group key using the HMAC security algorithm in the security monitor and distributes it to the slave enclaves. Only slave trusted execution environments that have passed authentication and hold a valid group key distributed by the master enclave during the creation phase can participate in subsequent data interactions, thereby ensuring that each enclave participating in IPFS data processing is legitimate and trustworthy. Step 2: After the security group is established, establish a master-slave trust architecture, in which the master trusted execution environment (Master Enclave) is responsible for coordinating data distribution, aggregation and access control policy management, and the other slave trusted execution environments (Slave Enclave) act as cooperative nodes to execute specific data processing tasks; In the IPFS data upload scenario, the main Enclave receives the raw plaintext data, performs encryption processing within the Keystone-Enclave, and sends the ciphertext data outward into inter-process shared memory. In the IPFS data download scenario, the main Enclave uniformly receives ciphertext data blocks from the IPFS network, distributes them to the slave Enclaves via trusted shared memory for parallel decryption to obtain plaintext data, and then, via trusted shared memory, the main Enclave finally completes secure plaintext data aggregation. Step 3: When data is exchanged between the master Enclave and the slave Enclave, the Shared Trusted Memory mechanism supported by Keystone-Enclave is used as the communication channel. All data transmitted across Enclaves is exchanged through the protected memory area, and the protected memory area can ensure secure plaintext data transmission.

[0008] In step one, it is proven that the calculation process performed meets expectations. The specific process is as follows: First, those wishing to join the Group will generate a cryptographic proof report from the trusted execution environment (the prover); Secondly, the primary trusted execution environment in the Group is verified in the security monitor using the cryptographic proof report to confirm that the metric indeed originates from a real trusted execution environment and meets the requirements of a trusted execution environment; Finally, the security monitor will be added to the Group from the trusted execution environment to begin collaborative computation.

[0009] Specifically, the initial content for generating a cryptographic proof report includes a metric from the trusted execution environment, the security engine ID, and a random number. The core of the generated cryptographic proof report contains the hash metric of its initial code and data, and is signed by the underlying security hardware using the platform's private key. Subsequently, the Security Monitor (SM, the verifier) ​​verifies the report: it first verifies the authenticity of the signature using the platform's public key, then compares whether the metric in the generated cryptographic proof report fully matches a pre-registered, legitimate, and trusted benchmark value. Finally, only trusted execution environments that pass all the above verifications can be judged by the SM as running the correct code as expected, thus qualifying to join the Group.

[0010] The calculation formula for the HMAC security algorithm is as follows: HMAC(K, m) = H( (K ⊕ opad) || H( (K ⊕ ipad) || m ) ); Where H is the hash function (SHA-512), K is the key, m is the input message (containing engine id and random number), and ipad and opad are fixed padding constants.

[0011] In step two, the specific steps by which the primary trusted execution environment coordinates data distribution, aggregation, and access control policy management are as follows: The master enclave, acting as the coordination core, first performs data distribution, distributing ciphertext data blocks according to a preset strategy (load balancing), and then distributing the data to slave enclaves through a trusted memory buffer. After distributing data blocks to the slave trusted execution environments, the master trusted execution environment itself also processes (decrypts) a ciphertext block. During the data aggregation phase, the master trusted execution environment is responsible for collecting the intermediate processing results returned by each slave trusted execution environment and assembling and synthesizing these partial results. Finally, according to the pre-set plaintext usage method, the plaintext is cleared immediately after use; The specific tasks performed from the trusted execution environment are encryption / decryption calculations, ciphertext data block acquisition, and plaintext data block submission.

[0012] Within Keystone-Enclave, the specific steps for decrypting encrypted data blocks within the trusted execution environment are described below: When the system retrieves all corresponding encrypted data blocks {C1, C2, ..., C} from the IPFS network based on the target root CID_root, n After being transferred to the Keystone-Enclave trusted execution environment, the securely stored key k is used in the trusted execution environment via P. i = Decrypt(k, C i The data is decrypted (using the AES-128 cryptographic algorithm), reassembled into the original plaintext file, and used immediately. After use, all plaintext data and temporary keys are immediately securely erased to ensure no information remains.

[0013] In step three, the specific data interaction process is as follows: When the master enclave obtains the ciphertext data, it distributes the data blocks from the Trusted Shared Buffer (STM) to the slave enclaves according to load balancing. After decryption, the slave enclaves return the plaintext data from the Trusted Shared Buffer to the master enclave, which then obtains and aggregates the plaintext data.

[0014] Specifically, the master enclave places the ciphertext data block into the STM using SET_STM_EN(BLOCK_ID,EN_BLOCK_CONTENT) and simultaneously notifies the slave enclave to retrieve the ciphertext data. The slave enclave retrieves the ciphertext data block from the STM using GET_STM_EN() and notifies the master enclave that the ciphertext data has been taken. After decryption to obtain the plaintext, the master enclave places the plaintext into the STM using SET_STM_DE(BLOCK_ID,DE_BLOCK_CONTENT) and notifies the master enclave that the plaintext data is ready. The master enclave then retrieves the plaintext data block using GET_STM_DE(BLOCK_ID).

[0015] The beneficial effects of this invention are: Keystone-Enclave ensures data security by enabling data interaction between trusted environments through the creation of trusted shared memory, preventing data from being tampered with or stolen by external parties.

[0016] This invention establishes groups and uses group keys to ensure the identity of trusted execution environments using trusted shared memory, enabling malicious trusted execution environments to access data within trusted shared memory. This allows trusted execution environments to mutually verify each other and establish trust.

[0017] This invention ensures data security throughout the entire process by establishing a master-slave relationship within a group and distributing and aggregating data in a master-trusted execution environment, thereby improving performance while guaranteeing data security. This is because concurrent use of multiple enclaves increases computing power by increasing concurrency, while authentication between multiple enclaves ensures enclave reliability. Finally, a trusted shared buffer accessible only between authenticated enclaves ensures the security of plaintext data aggregation and transmission. Attached Figure Description

[0018] Figure 1 This is a schematic diagram illustrating the concurrent data upload process in the IPFS security engine's multi-trusted execution environment.

[0019] Figure 2 This is a schematic diagram illustrating the strategy for scheduling and distributing encrypted data.

[0020] Figure 3 This is a schematic diagram illustrating the creation and use of a trusted shared buffer. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings.

[0022] A method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment includes the following steps; Step 1: Before initiating collaborative tasks among multiple Keystone-Enclave trusted execution environments, the security engine first creates trusted execution environments sequentially, establishes a Group, and establishes a master-slave relationship. Each Group has a unique creation engine identifier (engine id). Before joining a Group, each participating trusted execution environment must prove to the secure monitor (SM) that its execution process meets expectations. The master Enclave calculates the Group Key using the HMAC security algorithm in the secure monitor and distributes it to the slave Enclaves. Only slave trusted execution environments that have passed authentication and hold a valid Group Key distributed by the master Enclave during the creation phase can participate in subsequent data interactions, thereby ensuring that each Enclave participating in IPFS data processing is legitimate and trustworthy. Step 2: After the security group is established, establish a master-slave trust architecture, in which the master trusted execution environment (Master Enclave) is responsible for coordinating data distribution, aggregation and access control policy management, and the other slave trusted execution environments (Slave Enclave) act as cooperative nodes to execute specific data processing tasks; In the IPFS data upload scenario, the main Enclave receives the raw plaintext data, performs encryption processing within the Keystone-Enclave, and sends the ciphertext data outward into inter-process shared memory. In the IPFS data download scenario, the main Enclave uniformly receives ciphertext data blocks from the IPFS network, distributes them to the slave Enclaves via trusted shared memory for parallel decryption to obtain plaintext data, and then, via trusted shared memory, the main Enclave finally completes secure plaintext data aggregation. This architecture ensures that all data sources are consistent and the processing flow is controllable, achieving security and consistency throughout the entire data processing process.

[0023] Step 3: When data is exchanged between the master Enclave and the slave Enclave, the Shared Trusted Memory mechanism supported by Keystone-Enclave is used as the communication channel. All data transmitted across Enclaves is exchanged through this protected memory area, and this area can guarantee secure plaintext data transmission.

[0024] In step one, it is proven that the calculation process performed meets expectations. The specific process is as follows: First, those wishing to join the Group will generate a cryptographic proof report from the trusted execution environment (the prover); Secondly, the primary trusted execution environment in the Group is verified in a security monitor using the aforementioned cryptographic proof report to confirm that the metric indeed originates from a real trusted execution environment and meets the requirements of a trusted execution environment; Finally, the security monitor will be added to the Group from the trusted execution environment to begin collaborative computation.

[0025] Specifically, the initial content of generating a cryptographic proof report includes a metric from the trusted execution environment, the security engine ID, and a random number. The core of the generated cryptographic proof report contains the hash metric of its initial code and data, and is signed by the underlying security hardware using the platform's private key. Subsequently, the Security Monitor (SM, the verifier) ​​verifies this report: it first verifies the authenticity of the signature using the platform's public key, and then compares whether the metric in the generated cryptographic proof report completely matches a pre-registered, legitimate, and trusted benchmark value. Finally, only trusted execution environments that pass all the above verifications can be determined by the SM to be running the correct code as expected, thereby gaining the qualification to join the Group.

[0026] The calculation formula for the HMAC security algorithm is as follows: HMAC(K, m) = H( (K ⊕ opad) || H( (K ⊕ ipad) || m ) ); Where H is the hash function (SHA-512), K is the key, m is the input message (containing the engine ID and a random number), and ipad and opad are fixed padding constants. The HMAC algorithm is commonly used for authentication and is an internet security standard. Here, it is used to ensure that the generated unique Group Key is strongly bound to the master trusted execution environment of the unique Group and cannot be predicted or forged by a third party without the key.

[0027] In step two, the specific steps by which the primary trusted execution environment coordinates data distribution, aggregation, and access control policy management are as follows: The master enclave, acting as the coordination core, first performs data distribution, distributing ciphertext data blocks according to a preset strategy (load balancing) and then distributing the data to slave enclaves via a trusted memory buffer. After distributing data blocks to the slave trusted execution environments in this round, the master trusted execution environment itself also processes (decrypts) a ciphertext block. During the data aggregation phase, the master trusted execution environment is responsible for collecting the intermediate processing results returned by each slave trusted execution environment and assembling and synthesizing these partial results. Finally, after using the plaintext according to the pre-defined plaintext usage method, it must be cleared immediately to reduce data retention time and ensure security. The specific tasks performed from the trusted execution environment are encryption / decryption calculations, ciphertext data block acquisition, and plaintext data block submission.

[0028] Within Keystone-Enclave, the specific steps for decrypting encrypted data blocks within the trusted execution environment are described below: When the system retrieves all corresponding encrypted data blocks {C1, C2, ..., C} from the IPFS network based on the target root CID_root, n After being transferred to the Keystone-Enclave trusted execution environment, the securely stored key k is used in the trusted execution environment via P. i = Decrypt(k, C i The data is decrypted (using the AES-128 cryptographic algorithm), reassembled into the original plaintext file, and used immediately. After use, all plaintext data and temporary keys are immediately securely erased to ensure no information remains.

[0029] In step three, the specific data interaction process is as follows: When the master enclave obtains the ciphertext data, it distributes the data blocks from the Trusted Shared Buffer (STM) to the slave enclaves according to load balancing. After decryption, the slave enclaves return the plaintext data from the Trusted Shared Buffer to the master enclave, which then obtains and aggregates the plaintext data.

[0030] Specifically, the master enclave places the ciphertext data block into the STM using SET_STM_EN(BLOCK_ID,EN_BLOCK_CONTENT) and simultaneously notifies the slave enclave to retrieve the ciphertext data. The slave enclave retrieves the ciphertext data block from the STM using GET_STM_EN() and notifies the master enclave that the ciphertext data has been taken. After decryption to obtain the plaintext, the master enclave places the plaintext into the STM using SET_STM_DE(BLOCK_ID,DE_BLOCK_CONTENT) and notifies the master enclave that the plaintext data is ready. The master enclave then retrieves the plaintext data block using GET_STM_DE(BLOCK_ID).

[0031] A method for supporting concurrent execution of multiple trusted execution environments based on RISC-V includes a computing device running IPFS nodes. The computing device deploys a Keystone-Enclave trusted execution environment module based on RISC-V. The Keystone-Enclave provides a securely isolated execution space to protect the confidentiality and integrity of plaintext data during processing. The method is applied to hardware devices equipped with the Keystone-Enclave trusted execution environment. By constructing secure communication groups, establishing a master-slave trust architecture, and combining trusted shared memory with encrypted access control mechanisms, it achieves security assurance for the entire process of data upload, download, and multi-node collaborative processing in the IPFS network.

[0032] To enhance the security of IPFS during data upload and download, a security engine has been added to the IPFS upload process. Every operation on a data file must first pass through the security engine.

[0033] Before initiating collaborative tasks among multiple Keystone Enclaves, the security engine first initializes and creates each trusted execution environment (Enclave), and then establishes a Group with a unique identifier. This Group is managed by the Security Monitor (SM), and all participating nodes must prove to the SM that their running programs meet expectations and complete remote verification before joining the Group. The master Enclave acts as the coordinator, using the HMAC algorithm in the SM to generate a unique Group Key, which is then distributed to the slave Enclaves through a secure data exchange channel (i.e., STM), ensuring that only authenticated Enclaves with valid keys can participate in subsequent data interactions.

[0034] To ensure the security of cross-Enclave communication, a Trusted Shared Memory (STM) mechanism is introduced. For example... Figure 3 As shown, the master enclave initializes the STM and configures the Physical Memory Protection Policy (PMP) in the SM, defining the protected shared memory region. The slave enclave synchronizes the PMP protection configuration and obtains access permissions after verification by the SM. Then, the slave enclave requests the SM to add the shared memory to its own PMP configuration and maps the region in its respective virtual address space through a map operation, thus realizing a secure data exchange channel.

[0035] This process implements hardware-level security monitoring for identity authentication and memory isolation. SM (Smart Memory) monitors all memory access behavior throughout the process, preventing unauthorized or malicious code from reading and writing to shared memory. Simultaneously, the Group Key distribution and verification mechanism ensures that only legitimate Enclaves can participate in the collaboration, thereby building a highly reliable and tamper-proof collaborative computing environment, providing security for subsequent IPFS data processing.

[0036] Example 1: File Upload During data upload, the primary Enclave receives raw plaintext data from the user or local disk, serving as the starting point for the entire security process, and then receives data blocks sent by the primary Enclave from the secondary Enclave. For example... Figure 1 As shown, the master / slave enclave uses a strong encryption algorithm (AES) to encrypt plaintext data in its internal operating environment, generating corresponding ciphertext data blocks.

[0037] The encrypted data blocks are divided into CIDs by the original IPFS processing flow and stored in the IPFS network.

[0038] Example 2: File Download During the data download phase, when a user requests access to a piece of data, the IPFS network returns the corresponding encrypted ciphertext data block (BLOCK0 to BLOCK). n+1 This data may originate from historical upload records of the main Enclave or multiple Slave Enclaves. For example... Figure 2 As shown, the master enclave receives all ciphertext blocks and loads them into its internal space, ready for parallel decryption. The master enclave then distributes different ciphertext blocks to multiple slave enclaves according to a load balancing strategy.

[0039] Each slave enclave verifies its identity using a pre-distributed Group Key, performs AES decryption on the assigned data block using a pre-set decryption key, and obtains the corresponding plaintext data block. After decryption, the slave enclave returns the result to the master enclave via STM, ensuring data integrity and security during transmission. The main Enclave collects all plaintext blocks returned from the Enclave, reassembles and aggregates them in their original order, and recovers the complete original data. This aggregation process is completed internally within the main Enclave, avoiding the risk of leakage in intermediate stages. Finally, the plaintext data is output to local storage or an application programming interface, completing a secure data download loop. The entire process achieves efficient, controllable, and reliable parallel decryption and data reconstruction, ensuring the consistency and security of data processing in the IPFS environment.

[0040] In IPFS upload or download applications, this invention creates a secure group and introduces a Group Key mechanism to achieve identity authentication and mutual trust proof between multiple Keystone-Enclave trusted execution environments, ensuring that all entities participating in shared memory communication are legitimate and trusted Enclaves.

[0041] A master-slave trust architecture is established within the group, with the master trusted execution environment uniformly managing data distribution and aggregation, ensuring the consistency of data sources during IPFS uploads or downloads and the security of the entire data processing process.

[0042] By combining trusted shared memory and Group Key encrypted access control, the confidentiality and integrity of data interactions among multiple Enclaves are ensured, while unauthorized Enclaves are prevented from accessing shared data, thus enhancing the overall security and collaborative trustworthiness of the IPFS network system. Taking handwritten characters, similar to EMNIST, as an example, in a bank's handwritten check processing system, the handwritten character dataset undergoes the following secure processing flow: First, the collected check image samples are encrypted in a TEE environment and organized into blocks according to character category and sample type; then, a verification identifier is generated for each data block and a data association is established; finally, the encrypted data blocks are stored in the IPFS distributed network. When the bank needs to train a handwriting recognition model, specific training samples are decrypted as needed in the TEE environment. After using the decrypted data to complete model optimization, all original handwritten image data is immediately destroyed, effectively protecting the customer's handwriting characteristics and account information.

Claims

1. A method for supporting concurrent execution in multiple trusted execution environments based on RISC-V, characterized in that, Includes the following steps; Step 1: Before initiating collaborative tasks among multiple Keystone-Enclave trusted execution environments, the security engine first creates trusted execution environments sequentially, establishes groups, and establishes master-slave relationships. Each group has a unique creation engine identifier (engine id). Before joining a group, each participating trusted execution environment must prove to the security monitor that its execution computation process meets expectations. The master enclave calculates the group key using the HMAC security algorithm in the security monitor and distributes it to the slave enclaves; only slave trusted execution environments that have passed authentication and hold a valid group key distributed by the master enclave during the creation phase can participate in subsequent data interactions. Step 2: After the security group is established, establish a master-slave trust architecture, in which the master trusted execution environment is responsible for coordinating data distribution, aggregation and access control policy management, and the other slave trusted execution environments act as collaborative nodes to execute specific data processing tasks; Step 3: When data is exchanged between the master Enclave and the slave Enclave, a trusted shared memory mechanism supported by Keystone-Enclave is used as the communication channel. All data transmitted across Enclaves is exchanged through memory regions.

2. The method for supporting concurrent execution in multiple trusted execution environments based on RISC-V according to claim 1, characterized in that, In step one, it is proven that the calculation process performed meets expectations. The specific process is as follows: First, those wishing to join the Group will generate a cryptographic proof report from the trusted execution environment; Secondly, the primary trusted execution environment in the Group is verified in the security monitor using the cryptographic proof report to confirm that the metric indeed originates from a real trusted execution environment and meets the requirements of a trusted execution environment; Finally, the security monitor will be added from the trusted execution environment to the group.

3. The method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment according to claim 2, characterized in that, The initial content for generating a cryptographic proof report includes a metric from the trusted execution environment, the security engine ID, and a random number. The generated cryptographic proof report contains the hash metric of its initial code and data, and is signed by the underlying security hardware using the platform's private key. The security monitor verifies this report using the following method: First, the authenticity of the signature is verified using the platform's public key. Then, the metric in the generated cryptographic proof report is compared to a pre-registered, legitimate, and trusted benchmark value. Finally, only trusted execution environments that pass all the above verifications can be deemed by the SM to be running the correct code as expected, thus qualifying them to join the Group.

4. The method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment according to claim 3, characterized in that, The calculation formula for the HMAC security algorithm is as follows: HMAC(K, m) = H( (K ⊕ opad) || H( (K ⊕ ipad) || m ) ); Where H is the hash function, K is the key, m is the input message, and ipad and opad are fixed padding constants.

5. According to claim 4, a method for supporting concurrent execution in multiple trusted execution environments based on RISC-V, in the IPFS data upload scenario, the main Enclave receives the original plaintext data, performs encryption processing within the Keystone-Enclave, and sends the ciphertext data outward into inter-process shared memory; in the IPFS data download scenario, the main Enclave uniformly receives ciphertext data blocks from the IPFS network, distributes them to the slave Enclaves via trusted shared memory for parallel decryption to obtain plaintext data, and then, via trusted shared memory, finally completes secure plaintext data aggregation by the main Enclave.

6. A method for supporting concurrent execution in multiple trusted execution environments based on RISC-V according to claim 5, characterized in that, In step two, the specific steps by which the primary trusted execution environment coordinates data distribution, aggregation, and access control policy management are as follows: The master enclave acts as the coordination core, first performing data distribution. It distributes ciphertext data blocks according to a preset strategy and distributes the data to the slave enclaves through a trusted memory buffer. After distributing the data blocks to the slave trusted execution environments, the master trusted execution environment itself also processes a ciphertext block. During the data aggregation phase, the master trusted execution environment is responsible for collecting the intermediate processing results returned by each slave trusted execution environment. These partial results are then assembled and synthesized. Finally, according to the pre-set plaintext usage method, the plaintext is cleared immediately after use; The specific tasks performed from the trusted execution environment are encryption / decryption calculations, ciphertext data block acquisition, and plaintext data block submission.

7. A method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment according to claim 6, characterized in that, Within Keystone-Enclave, the specific steps for decrypting encrypted data blocks within the trusted execution environment are described below: When the system retrieves all corresponding ciphertext data blocks {C1, C2, ..., C...} from the IPFS network based on the target root CID_root, n After being transferred to the Keystone-Enclave trusted execution environment, the securely stored key k is used in the trusted execution environment via P. i = Decrypt(k, C i The data is decrypted and reassembled into the original plaintext file for immediate use. After use, all plaintext data and temporary keys are immediately securely erased to ensure no information remains.

8. A method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment according to claim 7, characterized in that, In step three, the specific data interaction process is as follows: When the master enclave obtains the ciphertext data, it distributes the data blocks from the trusted shared buffer to the slave enclaves according to the load balancer. After decryption, the slave enclaves return the plaintext data from the trusted shared buffer to the master enclave, which then obtains and aggregates the plaintext data.

9. A method for supporting concurrent execution in a RISC-V-based multi-trusted execution environment according to claim 8, characterized in that, The master enclave places the ciphertext data block into the STM using SET_STM_EN(BLOCK_ID,EN_BLOCK_CONTENT) and simultaneously notifies the slave enclave to retrieve the ciphertext data. The slave enclave retrieves the ciphertext data block from the STM using GET_STM_EN() and notifies the master enclave that the ciphertext data has been taken. After decryption to obtain the plaintext, the master enclave places the plaintext into the STM using SET_STM_DE(BLOCK_ID,DE_BLOCK_CONTENT) and notifies the master enclave that the plaintext data is ready. The master enclave then retrieves the plaintext data block using GET_STM_DE(BLOCK_ID).

Images