Data persistence storage system and method, terminal and medium

Abstract

The invention discloses a data persistence storage system and method, a terminal and a medium. The system comprises a secure virtual block device, an IDE module and a secure storage operation module. The secure virtual block device is located in a trusted execution environment, provides a standardized block storage interface for an upper-layer file system, is compatible with formatting and mounting use of a general file system, and stores exclusive secure metadata in a secure super block. And the IDE module is located in the trusted execution environment, is connected with the security virtual block device, and is used for realizing confidentiality and integrity protection of data through an encryption algorithm. And the secure storage operation module is located in the rich execution environment, is connected with the IDE module and is used for realizing specific storage operation. According to the method, data persistent storage can be realized, and the confidentiality, integrity, crash consistency and freshness of TEE persistent storage data can be ensured in combination with a TEE environment.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a persistent data storage system, method, terminal, and medium. Background Technology

[0002] With the rapid deployment of IoT, cloud computing, and confidential computing technologies, the demand for full lifecycle security protection of sensitive data such as key certificates, biometrics, healthcare, and financial transactions continues to escalate. Trusted Execution Environments (TEEs), as hardware-isolated secure execution spaces, can ensure that trusted applications (TAs) and sensitive data running within them are not stolen or tampered with by malicious programs or privileged attackers on the REE side through physical isolation from Rich Execution Environments (REEs). However, TEEs natively only provide security protection for volatile memory; memory data is completely lost after the device is powered off. This limitation severely restricts the application of TEEs in long-term data storage scenarios.

[0003] Currently, mainstream TEE architectures have all launched persistent storage solutions adapted to their own hardware characteristics, and have all achieved basic guarantees of the confidentiality and integrity of persistent data. However, they all have common shortcomings in the two core capabilities of crash consistency and prevention of malicious rollback. This is mainly because server-level TEE solutions do not provide native and systematic technical support, making it difficult to adapt to business scenarios such as financial transactions and database systems that have strong requirements for data security throughout the entire lifecycle. This has become the core bottleneck restricting the large-scale industrial deployment of TEE.

[0004] Therefore, existing technologies still have shortcomings. Summary of the Invention

[0005] To address the aforementioned deficiencies in the prior art, this invention provides a persistent data storage system, method, terminal, and medium. The technical solution adopted by this invention is as follows: In a first aspect, the present invention provides a persistent data storage system, the system comprising: A secure virtual block device, located in a trusted execution environment, provides a standardized block storage interface for upper-layer file systems and is compatible with the formatting and mounting of general file systems. The secure virtual block device stores exclusive security metadata in a secure superblock. An IDE module, located in a trusted execution environment and connected to the secure virtual block device, is used to protect the confidentiality and integrity of data through encryption algorithms. A secure storage operation module, which is located in a rich execution environment and connected to the IDE module, is used to implement specific storage operations.

[0006] In one implementation, the secure virtual block device sets up a private storage space that is not exposed to the upper-layer file system and is used only for storing private metadata. The private metadata includes a security superblock and a Merkle Tree. The security superblock includes a globally monotonically increasing count value obtained from a trusted counter, the value of the Merkle Tree root node, and the storage location of the Merkle Tree root node in the private storage space.

[0007] In one implementation, the secure virtual block device also aligns its own secure transaction boundaries with the transaction boundaries of the upper-layer file system and ensures the consistency of private metadata in case of crashes.

[0008] In one implementation, the secure storage operation module sets up a storage area in the rich execution environment, the storage area including a first area and a second area; wherein, the first area is exposed to the secure virtual block device for storing data of the secure virtual block device; the second area is a private area for storing additional information output by the IDE module.

[0009] Secondly, embodiments of the present invention also provide a data persistence storage method for a data persistence storage system based on any one of the above-described solutions, the method comprising: After the secure virtual block device reads its own secure superblock, it performs a security check. Once the security check passes, the secure virtual block device is activated, and the operating system completes the mount operation on the secure virtual block device, thus completing the mounting. The secure virtual block device writes a data page, and the written data page is encrypted by the IDE module to generate a combination of ciphertext and verification information. The secure storage operation module then writes the ciphertext and the verification information to their respective locations. The secure virtual block device initiates a read request, reads the ciphertext and the verification information through the secure storage operation module, and decrypts the read ciphertext and verification information through the IDE module and returns it to the secure virtual block device. The secure virtual block device sends a disk write command to the secure storage operation module, which then completes the disk write of the ciphertext and the verification information through the native file system interface of the rich execution environment, thereby achieving physical persistence of the data.

[0010] In one implementation, the secure virtual block device reads its own secure superblock and performs a security check. Upon successful security verification, the secure virtual block device is activated, including: The secure virtual block device reads its own secure superblock and completes basic verification; After the basic verification passes, verify the validity of the globally monotonically increasing count value in the security superblock; Verify the validity of the value of the root node of the Merkle Tree in the secure superblock; Once both the globally monotonically increasing counter value and the value of the Merkle Tree root node have passed verification, the secure virtual block device is activated.

[0011] In one implementation, the ciphertext and the verification information are written to corresponding locations via a secure storage operation module, including: The secure storage operation module maps the address given by the secure virtual block device to the location of the storage area, and writes the ciphertext into the location of the storage area. The secure storage operation module calculates the verification location based on the location of the storage area and writes the verification information into the verification location.

[0012] In one implementation, the read ciphertext and the verification information are decrypted by the IDE module and returned to the secure virtual block device, including: The secure storage operation module sends the encrypted text and the verification information back to the IDE module. The IDE module decrypts the ciphertext and the verification information to obtain the data page; The IDE module performs integrity verification on the data page and returns the data page that passes the integrity verification to the secure virtual block device.

[0013] Thirdly, embodiments of the present invention also provide a terminal, wherein the terminal includes a memory, a processor, and a data persistence storage program stored in the memory and executable on the processor, wherein when the processor executes the data persistence storage program, it implements the steps of the data persistence storage method of any of the above solutions.

[0014] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein a data persistence storage program is stored on the computer-readable storage medium, and the data persistence storage program implements the steps of the data persistence storage method described in any one of the above schemes on the computer-readable storage medium.

[0015] Beneficial Effects: Compared with existing technologies, this invention provides a persistent data storage system, including: a secure virtual block device, an IDE module, and a secure storage operation module. The secure virtual block device resides in a trusted execution environment (TEE), providing a standardized block storage interface for the upper-layer file system and being compatible with the formatting and mounting of general file systems. The secure virtual block device stores dedicated secure metadata in a secure superblock. The IDE module resides in the TEE and is connected to the secure virtual block device, used to achieve data confidentiality and integrity protection through encryption algorithms. The secure storage operation module resides in a rich execution environment (REA) and is connected to the IDE module, used to implement specific storage operations. This invention enables persistent data storage, and its combination with a TEE environment ensures the confidentiality, integrity, crash consistency, and freshness of data persistently stored in the TEE. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the data persistent storage system according to an embodiment of the present invention.

[0017] Figure 2 This is a flowchart of a preferred embodiment of the data persistence storage method according to an embodiment of the present invention.

[0018] Figure 3 A schematic diagram of the terminal provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0020] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0021] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0022] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, "first control information" and "second control information" are only used to distinguish different control information and do not limit their order.

[0023] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0024] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] The goal of TEE persistent storage is to achieve comprehensive security protection for the long-term storage of sensitive data while meeting the core security requirements of TEE. It must meet four indivisible core security requirements: confidentiality, integrity, crash consistency, and freshness (often also known as anti-rollback).

[0026] Confidentiality is a fundamental requirement for TEE persistent storage. Its core principle is to ensure that sensitive data is only visible in plaintext within the TEE throughout the entire storage and recovery process, remaining encrypted throughout the process on untrusted host machines and external storage media. Even if the storage media is directly accessed by an untrusted operating system (OS) or privileged administrators, the data content cannot be leaked. Its core implementation path consists of two points: first, key sealing, which derives a data encryption key based on the TEE hardware root key and strongly binds the key to the TEE instance's identity and metrics, allowing only authorized TEEs to decrypt the key; second, AEAD (Authenticated Encryption with Associated Data) authentication encryption, which simultaneously implements data encryption protection through algorithms such as SM4-GCM (a Chinese national cryptographic algorithm).

[0027] Integrity is the core prerequisite for data trustworthiness. The core is to ensure that when a TEE (Trusted Execution Environment) recovers data, it can accurately detect unauthorized tampering, partial modification, or forgery and replacement of data, preventing attackers from bypassing confidentiality protections by altering encrypted data to carry out malicious attacks. This is achieved through two main methods: first, Tag verification using the AEAD algorithm to identify forgery and tampering of the entire data set; and second, a Merkle hash tree structure to prevent partial data modification.

[0028] Crash consistency is the foundation of persistent storage reliability. Its core principle is to ensure that data does not become partially written, corrupted, or inconsistent in abnormal scenarios such as power outages or crashes. After recovery, only the complete old or new version can be read, and an illegal state of mixed old and new data will never occur. Unlike traditional file systems that only need to ensure the consistency of the file system's own structure, TEE persistent storage also needs to guarantee the consistency of the root of trust, the global version snapshot, and user data. This is achieved through atomic metadata updates, alignment of transaction boundaries and security boundaries, and recovery logic based on valid version verification.

[0029] Freshness, also known as anti-rollback, is the core security capability that distinguishes TEE persistent storage from traditional encrypted storage, and it is also a key technical challenge in the current industry. Its core purpose is to prevent attackers from rolling back persistent data to a historical, legitimate version with security vulnerabilities, bypassing current security mechanisms and triggering logical vulnerabilities. While such attacks do not constitute data tampering at the cryptographic level, they can still pose serious business security risks. Its core implementation relies on three fundamental capabilities: first, a hardware-level trusted monotonically increasing counter for the TEE; second, a version anchoring mechanism that anchors the latest state of data through hardware or external trusted services; and third, a strong binding of the version number to the Merkle root and metadata to ensure that version rollbacks can be accurately identified.

[0030] Current mainstream TEE solutions have achieved basic guarantees of confidentiality and integrity of persistent data, but they generally have shortcomings in the two core capabilities of crash consistency and prevention of malicious rollback. Except for TrustZone for mobile devices, server-level TEE solutions do not provide native and systematic technical support, making it difficult to adapt to business scenarios such as financial transactions and database systems that have strong requirements for data security throughout the entire lifecycle. This has become the core bottleneck restricting the large-scale industrial deployment of TEE.

[0031] To address the problems of existing technologies, this invention provides a persistent data storage system, such as... Figure 1 As shown, the system includes: a secure virtual block device, an IDE (Integrity Data Encryption) module, and a secure storage operation module. The secure virtual block device, the IDE module, and the secure storage operation module form a secure storage module.

[0032] Specifically, the secure virtual block device resides in a Trusted Execution Environment (TEE), providing a standardized block storage interface for the upper-layer file system and is compatible with the formatting and mounting of general-purpose file systems such as EXT4 (Fourth Extended File System) and Btrfs (B-tree File System). The secure virtual block device stores its proprietary security metadata in a secure superblock. The secure virtual block device sets up a private storage space, which is not exposed to the upper-layer file system and is used only to store private metadata. This private metadata includes the secure superblock and a Merkle Tree. The secure superblock includes a globally monotonically increasing count value obtained from a trusted counter, the value of the Merkle Tree root node, and the storage location of the Merkle Tree root node in the private storage space. The secure virtual block device also aligns its own security transaction boundaries with the transaction boundaries of the upper-layer file system, ensuring that activating its own security functions will not cause file system crashes or affect the file system's native capabilities. Furthermore, the secure virtual block device achieves crash consistency assurance for private metadata through a copy-on-write (CoW) mechanism. In addition, in other implementations, this embodiment can also use technologies such as Journaling, Log-structured, and Shadow paging to ensure the consistency of private metadata in the event of a crash.

[0033] Furthermore, the secure virtual block device in this embodiment can perform functions such as mounting, writing data pages, and reading data pages. Specifically, mounting includes: the secure virtual block device reading and verifying the secure superblock; verifying the globally monotonically increasing counter value; verifying the value of the Merkle Tree root node; if both the globally monotonically increasing counter value and the Merkle Tree root node value are successful, the secure virtual block device is activated; and the operating system completes the mount operation on the secure virtual block device to complete the mounting. The mount operation is used to load a specified file system from a specified device into a Linux directory.

[0034] Writing data pages includes: updating the cached Merkle Tree; writing to the Merkle Tree, incrementing the global monotonic counter, and writing to the Secure Super block at appropriate times, such as during FLUSH / FUA (write-to-disk) operations. Retrieving data pages includes: reading Merkle Tree nodes and performing integrity checks on the data pages.

[0035] In one implementation, the copy-on-write mechanism in this embodiment only copies the modified data blocks or data pages, rather than copying the entire superblock or a large storage area. At the same time, a CoW fragmentation reclamation submodule is added to complete fragment scanning and merging within the TEE (the reclamation operation does not expose plaintext data), reducing storage fragmentation and IO (input / output) overhead caused by CoW.

[0036] Furthermore, in other implementations, this embodiment can also add identity-based access control submodules and attribute-based access control submodules to the secure virtual block device within the TEE. This assigns unique TEE identity identifiers to different services and users, allowing only authorized entities to initiate mounting, read / write, and disk write operations. Additionally, it can simultaneously tier operation permissions (read-only / read / write / administrator) and write permission information into the extended security metadata of the Secure Super block, binding it to a global counter. When permissions change, the counter is updated synchronously to prevent malicious tampering of permissions.

[0037] Furthermore, the IDE module is located in a trusted execution environment and connected to the secure virtual block device, thus enabling the connection between the secure virtual block device and the secure storage operation module. The IDE module can implement AEAD (Authentication Encryption with Associated Data) cryptographic algorithms (such as SM4-GCM and other national cryptographic algorithms) to achieve data confidentiality and integrity protection through encryption algorithms.

[0038] In one implementation, this embodiment can also introduce a hierarchical key management system in the IDE module, generating three levels of keys within the TEE: root key, data key, and session key. Specifically, the root key is securely generated by the TEE hardware and permanently stored in the TEE's secure area, and cannot be exported; the data key is generated at the data page granularity, derived from the root key, and used for encryption and decryption of specific data; the session key is temporarily generated, used for encrypting interactive data between the TEE and REE, and is destroyed immediately after the session ends. Furthermore, an automatic key rotation mechanism can be added, supporting data key rotation triggered by time or data volume. The rotation operation is completed within the TEE, without the business being aware of it.

[0039] Furthermore, the secure storage operation module is located in the rich execution environment and connected to the IDE module to implement specific storage operations. In this embodiment, the secure storage operation module sets up a storage area in the rich execution environment, which can be a file. Specifically, the storage area includes a first area and a second area; wherein, the first area is exposed to the secure virtual block device and is used to store the data of the secure virtual block device; the second area is a private area used to store additional information output by the IDE module.

[0040] The secure storage operation module in this embodiment can perform write operations, read operations, and FLUSH / FUA (Forcecache flush / Force unit access, i.e., data persistence) operations. Specifically, the write operation includes: when the secure virtual block device issues a data write operation, the data is encrypted by the IDE module to form a combination of ciphertext and verification information; the secure storage operation module maps the address given by the secure virtual block device to the location of the storage area and writes the ciphertext to the location of the storage area; the verification location is calculated based on the location of the storage area, and the verification information is written to the verification location.

[0041] Read operations include: when the secure virtual block device issues a data read operation, the secure storage operation module maps the address given by the secure virtual block device to the location of the storage area, reads the ciphertext; calculates the check location using the location of the storage area, reads the check information; and returns the combined data of the ciphertext and check information to the IDE module. FLUSH / FUA (Forcecache flush / Force unit access, used to implement data persistence) operations include: when the secure virtual block device issues FLUSH / FUA or other persistence commands, the secure storage operation module implements data persistence to disk through the REE file system interface.

[0042] Furthermore, the Merkle Tree of the secure virtual block device can employ double hash verification, performing double-layer hash calculations on data pages to further reduce the risk of integrity verification failures caused by hash collisions. A media-aware submodule is added to the secure storage operation module, which can automatically identify the underlying storage media (including SSDs, HDDs, and distributed storage) and adjust IO strategies accordingly. Specifically, it performs IO-aligned writes and disables unnecessary disk flushing operations for SSDs; optimizes sequential IO for HDDs to reduce random seek time; and performs fragmented writes for distributed storage to adapt to the block size of distributed storage. Furthermore, this embodiment can also perform multi-replica off-site storage of the Secure Superblock (dividing the TEE private storage space into 2-3 independent areas to store Superblock replicas) to prevent metadata loss due to the failure of a single area.

[0043] This embodiment can also add a security audit submodule within the TEE to generate structured logs for all core operations (including mount verification, data read and write, counter increment, FLUSH / FUA disk write, permission changes, and abnormal events). The log content includes the operation subject, time, data page address, operation result, etc. The logs are encrypted within the TEE before being synchronized to the dedicated encrypted log area on the REE side. The logs are appended and cannot be modified or deleted, supporting post-event security tracing and anomaly investigation.

[0044] To achieve sensitive data desensitization, this embodiment can also add a lightweight data desensitization submodule before the encryption and decryption process of the IDE module. It supports static desensitization (using masking or replacement) or dynamic desensitization (using on-demand hiding) of sensitive fields (such as financial information and device identification) in the data page. The desensitization operation is completed within the TEE, ensuring that sensitive fields will not be leaked even after decryption, which is suitable for highly sensitive scenarios such as finance and government affairs.

[0045] The secure virtual block device in this embodiment supports parallel verification of multiple data pages, performing Merkle Tree node verification on multiple data pages read in batches simultaneously, leveraging the multi-core hardware capabilities of the TEE to improve verification efficiency. The IDE module enables parallel encryption and decryption, allocating independent encryption and decryption threads to different data pages, supporting parallel processing of batch data and avoiding single-thread bottlenecks. The secure storage operation module supports parallel mapping and reading / writing of multiple addresses, performing mapping and I / O (input / output) operations on multiple non-contiguous data page addresses simultaneously, improving the throughput of batch data processing.

[0046] Therefore, this embodiment provides a persistent data storage system that, when combined with a TEE environment, can ensure the confidentiality, integrity, crash consistency, and freshness of persistent data stored in the TEE.

[0047] Based on the above embodiments, the present invention also provides a data persistent storage method, which is implemented based on the data persistent storage system of the above embodiments. The method of this embodiment can be applied to a terminal, which can be an intelligent product device such as a computer. Specifically, as... Figure 2 As shown, the system includes the following steps: Step S100: After the secure virtual block device reads its own secure superblock, it performs a security check. After the security check passes, the secure virtual block device is activated, and the operating system completes the mount operation on the secure virtual block device to complete the mounting. Step S200: The secure virtual block device writes a data page. The written data page is encrypted by the IDE module to generate a combination of ciphertext and verification information. The secure storage operation module writes the ciphertext and the verification information to the corresponding locations respectively. Step S300: The secure virtual block device initiates a read request, reads the ciphertext and the verification information through the secure storage operation module, and decrypts the read ciphertext and the verification information through the IDE module and returns it to the secure virtual block device. Step S400: The secure virtual block device sends a disk write command to the secure storage operation module. The secure storage operation module completes the disk storage of the ciphertext and the verification information through the native file system interface of the rich execution environment, thereby realizing the physical persistence of the data.

[0048] In practical applications, the data persistence storage method in this embodiment revolves around four core operations: mounting, writing data pages, reading data pages, and FLUSH / FUA disk persistence. These operations are completed collaboratively by the system's three main modules, with each step embedding multiple security verification and mechanisms to ensure the four security attributes of the data throughout the process. Specifically, in the mounting phase, security verification and device activation are primarily performed to ensure the security of the storage system startup. The secure virtual block device first reads its own secure superblock and completes basic verification. After the basic verification passes, the validity of the globally monotonically increasing counter value in the secure superblock is verified. Then, the validity of the value of the Merkle Tree root node in the secure superblock is verified. After all the above verifications are successful, the secure virtual block device is activated, and the operating system completes the mount operation on the secure virtual block device, thus completing the mounting.

[0049] During the data page writing phase, the primary function is to ensure secure data writing and synchronized updates of secure metadata. The secure virtual block device writes a new data page and updates the Merkle Tree in the cache in real time. At appropriate times, such as during FLUSH / FUA operations, the secure virtual block device performs Merkle Tree updates, global monotonic counter increments, and Secure Superblock writes. The written data page is encrypted using the AEAD algorithm by the IDE module, generating a combination of ciphertext and verification information. Next, the secure storage operation module maps the address provided by the secure virtual block device to a storage region location and writes the ciphertext to that location. Then, the secure storage operation module calculates the verification location based on the storage region location and writes the verification information to that location.

[0050] During the data page reading phase, the primary function is to ensure secure data reading and integrity verification, guaranteeing that the read data has not been tampered with. Specifically, the secure virtual block device first initiates a data page read request, reading the data page and simultaneously reading the corresponding Merkle Tree node to perform integrity verification on the data page. Next, the secure storage operation module maps the address provided by the secure virtual block device to the location of a storage region, reading the ciphertext of that storage region's location; the secure storage operation module calculates the verification location based on the storage region's location and reads the verification information at that location. Then, the secure storage operation module feeds back the ciphertext and the verification information to the IDE module, which decrypts the ciphertext and the verification information to obtain the data page, performs integrity verification on the data page, and returns the data page that passes the integrity verification to the secure virtual block device.

[0051] Furthermore, in one implementation, this embodiment can also design a three-level cache architecture for the secure virtual block device within the TEE: L1 is a register-level cache (storing core metadata such as global counters and Merkle Tree root nodes), L2 is a TEE memory cache (storing hot data pages and high-frequency Merkle Tree nodes), and L3 is a TEE private high-speed storage cache (storing less frequently accessed data). A hot data identification module can also be added to classify data based on the access frequency or time of data pages, automatically flushing cold data to the REE-side storage while keeping hot data resident in the TEE cache, reducing IO interactions between the TEE and REE.

[0052] This invention provides a data persistent storage method that, when combined with a TEE environment, can ensure the confidentiality, integrity, crash consistency, and freshness of data persistently stored in the TEE.

[0053] The principle of each step in the data persistence storage method embodiment is the same as the principle of each module in the system, and will not be elaborated further here.

[0054] Based on the above embodiments, the present invention also provides a terminal, the principle block diagram of which can be as follows: Figure 3 As shown. The terminal may include one or more processors 100 ( Figure 3 (Only one is shown in the diagram), memory 101, and computer program 102 stored in memory 101 and executable on one or more processors 100. For example, a data persistence storage program. When one or more processors 100 execute computer program 102, they can implement the various steps in the data persistence storage method embodiment. Alternatively, when one or more processors 100 execute computer program 102, they can implement the functions of various modules / units in the data persistence storage system embodiment, which is not limited here.

[0055] In one embodiment, the processor 100 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0056] In one embodiment, memory 101 can be an internal storage unit of the terminal, such as a hard disk or RAM. Memory 101 can also be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SM), secure digital card (SD), flash card, etc. Furthermore, memory 101 can include both internal and external storage units. Memory 101 is used to store computer programs and other programs and data required by the terminal. Memory 101 can also be used to temporarily store data that has been output or will be output.

[0057] Those skilled in the art will understand that Figure 3 The block diagram shown is merely a partial structural diagram related to the present invention and does not constitute a limitation on the terminal to which the present invention is applied. A specific terminal may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0058] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), direct memory bus RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0059] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A persistent data storage system, characterized in that, The system includes: A secure virtual block device, located in a trusted execution environment, provides a standardized block storage interface for upper-layer file systems and is compatible with the formatting and mounting of general file systems. The secure virtual block device stores exclusive security metadata in a secure superblock. An IDE module, located in a trusted execution environment and connected to the secure virtual block device, is used to protect the confidentiality and integrity of data through encryption algorithms. A secure storage operation module, which is located in a rich execution environment and connected to the IDE module, is used to implement specific storage operations.

2. The data persistent storage system according to claim 1, characterized in that, The secure virtual block device is configured with a private storage space, which is not exposed to the upper-layer file system and is used only to store private metadata. The private metadata includes a security superblock and a Merkle Tree. The security superblock includes a globally monotonically increasing count value obtained from a trusted counter, the value of the Merkle Tree root node, and the storage location of the Merkle Tree root node in the private storage space.

3. The data persistent storage system according to claim 2, characterized in that, The secure virtual block device also aligns its own secure transaction boundaries with the transaction boundaries of the upper-layer file system and ensures the consistency of private metadata in case of crashes.

4. The data persistent storage system according to claim 1, characterized in that, The secure storage operation module sets up a storage area in the rich execution environment. The storage area includes a first area and a second area. The first area is exposed to the secure virtual block device and is used to store the data of the secure virtual block device. The second area is a private area and is used to store additional information output by the IDE module.

5. A data persistence storage method based on the data persistence storage system according to any one of claims 1-4, characterized in that, The method includes: After the secure virtual block device reads its own secure superblock, it performs a security check. Once the security check passes, the secure virtual block device is activated, and the operating system completes the mount operation on the secure virtual block device to complete the mounting. The secure virtual block device writes a data page, and the written data page is encrypted by the IDE module to generate a combination of ciphertext and verification information. The secure storage operation module then writes the ciphertext and the verification information to their respective locations. The secure virtual block device initiates a read request, reads the ciphertext and the verification information through the secure storage operation module, and decrypts the read ciphertext and verification information through the IDE module and returns it to the secure virtual block device. The secure virtual block device sends a disk write command to the secure storage operation module, which then completes the disk write of the ciphertext and the verification information through the native file system interface of the rich execution environment, thereby achieving physical persistence of the data.

6. The data persistent storage method according to claim 5, characterized in that, The secure virtual block device reads its own secure superblock and performs a security check. Upon successful security verification, the secure virtual block device is activated, including: The secure virtual block device reads its own secure superblock and completes basic verification; After the basic verification passes, verify the validity of the globally monotonically increasing count value in the security superblock; Verify the validity of the value of the root node of the Merkle Tree in the secure superblock; Once both the globally monotonically increasing counter value and the value of the Merkle Tree root node have passed verification, the secure virtual block device is activated.

7. The data persistent storage method according to claim 5, characterized in that, The secure storage operation module writes the ciphertext and the verification information to their respective locations, including: The secure storage operation module maps the address given by the secure virtual block device to the location of the storage area, and writes the ciphertext into the location of the storage area. The secure storage operation module calculates the verification location based on the location of the storage area and writes the verification information into the verification location.

8. The data persistent storage method according to claim 5, characterized in that, The read ciphertext and the verification information are decrypted by the IDE module and returned to the secure virtual block device, including: The secure storage operation module sends the encrypted text and the verification information back to the IDE module. The IDE module decrypts the ciphertext and the verification information to obtain the data page; The IDE module performs integrity verification on the data page and returns the data page that passes the integrity verification to the secure virtual block device.

9. A terminal, characterized in that, The terminal includes a memory, a processor, and a data persistence storage program stored in the memory and executable on the processor. When the processor executes the data persistence storage program, it implements the steps of the data persistence storage method as described in any one of claims 5-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a data persistence storage program, which implements the steps of the data persistence storage method as described in any one of claims 5-8 on the computer-readable storage medium.

Images