Log-structured secure data storage method and apparatus

Abstract

The embodiment of the present specification provides a log-structured secure data storage method and device, which is used for storing data to a hard disk via a trusted execution environment (TEE). The data operation is based on three logical data structures: a data block which can be written, read, searched and the like; a secure index; and a secure log. The data block is written to the hard disk in the form of ciphertext through an append write mode; the secure index is an index established in a log-merge tree structure for each index entry generated for each ciphertext data block; and the secure log is used to record operation information of writing the data block or the index entry to the hard disk in the append write mode. The data storage architecture can reduce the write amplification of the TEE to the hard disk on the basis of data security.

Description

Technical Field

[0001] This specification relates to the field of secure computing technology, and in particular to a secure data storage method and apparatus for log structures. Background Technology

[0002] With the development of computer technology, the protection of computer data privacy has become an important research direction. Trusted Execution Environments (TEEs) have become increasingly popular in recent years. Some major CPU architectures in the computer field have implemented corresponding TEE solutions (such as Intel SGX, AMD SEV, RISC-V Keystone, Power PEF, etc.) or announced corresponding TEE solutions (Intel TDX, Arm CCA). These TEE solutions enable TEE users (e.g., cloud tenants) to run their sensitive applications in private memory regions that cannot be spied on or tampered with by privileged attackers (e.g., cloud operators). The emergence of TEEs provides a new paradigm for confidential computing and can solve the trust issues that hinder many use cases (e.g., cloud computing).

[0003] While the memory of TEEs is protected by hardware, the hard drive data of TEEs (especially during TEE runtime) should be protected by software. In other words, the security of data written to a hard drive that is not hardware protected during TEE runtime is extremely important. Furthermore, write amplification during data writing is also a concern to ensure data security. Summary of the Invention

[0004] This specification describes one or more embodiments of a secure data storage method and apparatus for a log structure, which is used to solve one or more problems mentioned in the background art.

[0005] According to a first aspect, a secure data storage method with a log structure is provided for protecting user block I / O operations on an untrusted hard disk in a trusted execution environment. The method includes: encrypting several data blocks submitted by the user to obtain corresponding ciphertext data blocks, and persisting each ciphertext data block to the hard disk in an append-only manner; generating corresponding index entries for each ciphertext data block, wherein a single index entry is used to locate and protect one ciphertext data block; inserting each index entry into a secure index based on a log structure merge tree, wherein the secure index is persisted to the hard disk; generating several log entries for the ciphertext data blocks, wherein the log entries are used to locate and protect the corresponding ciphertext data blocks in the event of a system crash, and a single log entry corresponds to one or more ciphertext data blocks; and appending the several log entries to a security log on the hard disk, wherein the security log is persisted to the hard disk.

[0006] In one embodiment, the plurality of data blocks include a first data block, and the first data block is authenticated and encrypted using a first key key1 to obtain a first ciphertext data block and an authentication code MAC1. The first ciphertext data block is located and protected by a first index entry, which includes the logical address LBA1 of the first data block, the physical address HBA1 stored on the hard disk, the first key key1, and the authentication code MAC1.

[0007] In one embodiment, the plurality of data blocks are multiple data blocks of the current data segment recorded in memory in an append-only manner according to the order of user submission, and the plurality of data blocks submitted by the user are encrypted to obtain corresponding ciphertext data blocks.

[0008] In one embodiment, if a first condition for writing a data segment to a hard disk is met, each encrypted data block is persisted to the hard disk in an append-only manner, wherein the first condition includes at least one of the following: the current data segment is full, a refresh request is received, or the recording duration reaches a predetermined duration.

[0009] In one embodiment, the log structure merge tree corresponds to a first memory table, a second memory table, and multiple layers on the hard disk. The second memory table is used for persistence to the multiple layers. The block index tables of each layer can be merged into subsequent layers sequentially until the last layer. Inserting the plurality of index entries into the secure index based on the log structure merge tree includes: inserting the plurality of index entries into the current first memory table; and, if the second condition for index persistence is met, converting the first memory table into a second memory table, thereby writing the index entries in the second memory table into the first layer of the multiple layers.

[0010] In one embodiment, a single layer of the plurality of layers records index entries in units of a block index table (BIT). The leaf nodes of a single BIT correspond to one or more index entries, and a single non-leaf node stores the LBA range of the data blocks corresponding to each index entry in its child nodes, as well as the respective MAC authentication codes that are used for authentication and encryption protection for each child node.

[0011] In one embodiment, writing the index entries from the second memory table to the first layer of the plurality of layers includes: traversing the LBAs in the second memory table to generate each BIT, wherein a single BIT corresponds to a plurality of consecutive index entries in the second memory table, and the plurality of index entries in the BIT are arranged in ascending order; and writing each BIT to the first layer in an append-only manner according to the completion order of each BIT.

[0012] In one embodiment, a single BIT is generated as follows: based on a single LBA range corresponding to a single leaf node, an index entry satisfying the single LBA range is obtained and recorded in the single leaf node; for a single non-leaf node, after the corresponding leaf node is recorded, an authentication code (MAC) for authentication and encryption protection of the index entries within the corresponding LBA range is recorded in the non-leaf node.

[0013] In one embodiment, each log entry in the security log is stored in the form of a log block, and each log block is authenticated and encrypted by a corresponding MAC code, and the MAC of a single log block is embedded in the next log block.

[0014] In one embodiment, the hard disk also contains an inverted index table mapping HBA to LBA. When inserting the plurality of index entries into a secure index based on a log structure merge tree, the method further includes updating the inverted index table based on the plurality of index entries.

[0015] In one embodiment, the disk further records a first segment validity table (SVT) describing the validity of each data segment via a bitmap, and a data segment table (DST) describing the validity of each data block within a data segment. The method further includes updating the first segment validity table and the data segment table (DST) when each encrypted data block is persisted to the disk in an append-only manner.

[0016] In one embodiment, the disk also stores a second validity table SVT that describes the validity of each block index table (BIT) via a bitmap. The method further includes updating the second validity table when the block index tables of each layer can be merged into subsequent layers or when index entries in the second memory table are written to the first layer of the plurality of layers.

[0017] According to a second aspect, a secure data storage device with a log structure is provided for protecting user block I / O operations on untrusted hard disks in a trusted execution environment; the device is located in the trusted execution environment and includes:

[0018] The data storage unit is configured to encrypt several data blocks submitted by the user to obtain corresponding ciphertext data blocks, and persist each ciphertext data block to the hard disk in an append-only manner;

[0019] The index generation unit is configured to generate corresponding index entries for each ciphertext data block, wherein a single index entry is used to locate and protect a ciphertext data block;

[0020] An index storage unit is configured to insert each index entry into a security index based on a log structure merge tree, the security index being persisted on the hard disk;

[0021] The log generation unit is configured to generate several log entries for the encrypted data block. The log entries are used to locate and protect the corresponding encrypted data block in the event of a system crash. Each log entry corresponds to one or more encrypted data blocks.

[0022] The log storage unit is configured to append the plurality of log entries to the security log of the hard disk, and the security log is persisted on the hard disk.

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

[0024] According to a fourth aspect, a computing device is provided, including a memory and a processor, characterized in that the memory stores executable code, and when the processor executes the executable code, it implements the method of the first aspect.

[0025] The secure data storage method and apparatus based on log-structured architecture provided in the embodiments of this specification enable secure data operations on the hard disk via a secure zone trusted execution environment. These data operations are based on the following three logical data structures: data blocks capable of being written, read, and retrieved; a secure index; and a secure log. Specifically, data blocks are written to the hard disk in encrypted form via append-only writing; the secure index is an index built using a log-merged tree structure, generating index entries for each encrypted data block; and the secure log is used to record operation information for writing data blocks or index entries to the hard disk via append-only writing.

[0026] On one hand, the TEE receives data blocks to be written to the hard disk and appends them to the disk. On the other hand, it generates index entries for each ciphertext data block in the ciphertext data segment and inserts these index entries into a secure index based on a log structure merge tree. This secure index is persistently stored on the hard disk in an encrypted manner. Furthermore, it generates log entries for the ciphertext data blocks written to the hard disk and appends these log entries to the secure log on the hard disk. This secure log is persistently stored on the hard disk in an encrypted manner to facilitate the recovery of relevant index entries in case of crashes or other unforeseen circumstances. This method uses append-only writing for data block records (as opposed to modifying or overwriting older versions of data). The log structure merge tree used prioritizes retrieving index entries corresponding to the new version of the data (without needing to modify historical index entries), thereby reducing write amplification while maintaining data confidentiality and improving the effectiveness of the TEE in storing data on a non-secure hard disk. Attached Figure Description

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

[0028] Figure 1 This document illustrates one implementation scenario.

[0029] Figure 2 This diagram illustrates a real-time architecture for writing data from a TEE to a hard drive, representing a specific example of conventional technology.

[0030] Figure 3 A schematic diagram illustrating an implementation architecture for writing data from a TEE to a hard disk, based on a specific example of the technical concept in this specification.

[0031] Figure 4 This diagram illustrates the architecture of an LSM-tree in conventional technologies.

[0032] Figure 5 This diagram illustrates the architecture of the improved LSM-tree as described in the technical concept of this specification.

[0033] Figure 6 A schematic diagram illustrating a specific example of the BIT logical architecture provided in this specification is shown.

[0034] Figure 7 A flowchart illustrating a secure data storage method for a log structure according to one embodiment is shown.

[0035] Figure 8 Showing according to Figure 6The illustration shows a schematic diagram of the BIT structure stored on the hard disk in an append-only manner, as shown in a specific example.

[0036] Figure 9 A schematic diagram of a hard disk partitioning architecture that implements the technical concepts of this specification is shown in a specific example.

[0037] Figure 10 A schematic block diagram of a secure data storage device with a log structure according to one embodiment is shown. Detailed Implementation

[0038] The technical solutions provided in this specification are described below with reference to the accompanying drawings.

[0039] First, let's introduce some technical terms that may be used in this manual:

[0040] TEE: an abbreviation for Trusted Execution Environments, also known as TEEs. It provides a trusted environment isolated from the REE (Rich Execution Environment, device general environment), providing a more secure space for the execution of data and code and ensuring their confidentiality and integrity. Typically, information from other areas of the device can be directly obtained through the TEE, while other areas cannot obtain information from the TEE.

[0041] LSM-trees: an abbreviation for Log-Structured Merge Trees, in which data is recorded in an append-only manner to store persistent data and its index in the log. Each entry is added to the end of the log, making most accesses to the file system sequential, thereby improving disk bandwidth utilization and enabling faster fault recovery.

[0042] MHT: Merkle Hash Trees, or MHTs, Merkle hash trees. In a Merkle hash tree, the data in each parent node is a hash function of the data in its child nodes, and the data in the leaf nodes is the hash value of the atomic data blocks.

[0043] MAC: Abbreviation for Message Authentication Code. In this manual, it may also be referred to simply as authentication code. It is usually used for authentication and encryption protection. It can be a short fixed-length data block that maps arbitrarily long messages to under the control of a key and can be appended to the corresponding message.

[0044] Figure 1 This illustrates a specific application scenario of this specification. Figure 1The scenario illustrated involves a Trusted Execution Environment (TEE) and an untrusted hard drive. One or more applications (APPs) run within the TEE, generating various file data during operation. This file data needs to be recorded in real-time. However, since the TEE typically uses limited memory space, a Secure Block Device within the TEE is required to record the data generated by the APPs on an untrusted hard drive outside the TEE.

[0045] Secure block devices are software or hardware devices integrated into a TEE (Trusted Executable Environment) to protect the TEE's file I / O during runtime. Secure block devices can transparently protect all block I / O from the file I / O stack. In this way, other parts of the TEE can maintain a legacy file I / O stack (including existing file systems used internally with little or no modification) without requiring additional attention to file I / O security.

[0046] Safety block device in Figure 1 The text is represented by a bolded frame and serves as the main body for implementing the technical solutions discussed in this specification. It can achieve the following three functions:

[0047] The read function, such as read(LBA, nblocks, buf), means reading data from the hard disk into the buffer buf, starting from the LBA address of the nblocks block.

[0048] Write, such as write(LBA, nblocks, buf), means writing data from the buffer buf to the hard disk, starting from the LBA address of the nblocks block;

[0049] Refreshing, such as using flush(), ensures that all updated data is saved to disk.

[0050] Specifically, applications can use the file I / O interface to transfer file I / O blocks (hereinafter also referred to as data blocks) generated during their operation to the secure block device in the TEE, and then the secure block device will transfer them to the untrusted hard drive. Applications can use the file I / O interface to read from the hard drive via the secure block device and return the data.

[0051] All data written to or read from a secure block device is in plaintext. The secure block device is responsible for properly encrypting / decrypting data transmitted to or from the hard drive. To distinguish between trusted secure block devices and untrusted hard drives, the data identifier carried by applications when submitting data to a secure block device is called the Logical Block Address (LBA), and the storage address where the secure block device stores the data on the hard drive is called the Host Block Address (HBA), or physical address.

[0052] Since hard drives are untrusted, suppose an attacker has privileges to control any hardware and software on the host machine outside of the TEE, and can launch an attack at any time during the TEE's entire lifecycle, possessing the ability to tamper with (not just monitor) any I / O requests and responses from the hard drive. Specifically, the types of attacks this attacker might perform include, but are not limited to: snooping attacks (monitoring I / O), tampering attacks (forging blocks), rollback attacks (replaying old blocks), and so on.

[0053] To combat such attackers, secure block devices must provide at least the following security guarantees for their block interfaces: confidentiality, meaning that user data committed by any write operation is not disclosed; integrity, ensuring that user data returned from any read is truly generated by the user; freshness, ensuring that user data returned from any read is the latest updated; and consistency (or crash consistency), meaning that all security guarantees remain effective regardless of any accidental or malicious crashes.

[0054] To achieve these security goals, conventional technologies include Intel SGX Protected File System (SGX-PFS), Asylo, Graphene-SGX, Occlum, SecureFS, and other solutions for securely writing data to the hard drive.

[0055] Taking SGX-PFS as an example, it is based on the concept of a file, treating each file as a secure block device, and employs a combination of in-place update and Merkle Hash Tree (MHT) methods. The following section will combine... Figure 2 The diagram illustrates how an open file in SGX PFS works. An SGX PFS file can be composed of three key components: MHT (for security), cache (for efficiency), and recovery log (for consistency). In the MHT, each node stored on disk is protected by authenticated encryption, which is based on an encryption key and an authentication code (MAC). Leaf nodes contain the file data, while non-leaf nodes maintain the encryption keys and MACs of their child nodes. The MHT ensures the confidentiality, integrity, and freshness of the file data. To avoid disk I / O on every read or write, the file provides a fixed-size memory cache for recently used nodes. Before flushing dirty nodes to disk, the latest valid version of the dirty node is kept in the recovery log. Thus, if any crash occurs during flushing, the file can be restored to its last valid and consistent state via the recovery log.

[0056] refer to Figure 2The data storage architecture shown in SGX-PFS introduces write amplification, which may lead to poor random write performance. Write amplification can be determined by comparing the amount of data to be written with the actual amount of data written, for example, the ratio of the actual amount of data written to the amount of data to be written. SGX-PFS write amplification primarily comes from two sources: the MHT and the recovery log. In the MHT, updates to leaf nodes trigger cascading updates in all their parent nodes. This means that for sufficiently large files, the amplification factor for random writes can be as high as H, where H is the depth of the MHT. Furthermore, to ensure crash consistency, data is typically written twice: after the old version is saved to the recovery log, the new version is written to the MHT leaf nodes. Figure 2 The shaded area represents the content written to data D2. Therefore, in the worst case, SGX-PFS can result in a maximum amplification factor of 2×H.

[0057] To address the write amplification problem in conventional technologies, this specification proposes a novel structured scheme for secure block devices (such as SwornDisk) to reduce write amplification and improve random write performance. As mentioned earlier, the secure block device within this Trusted Execution Environment (TEE) can securely perform operations such as writing, reading, and querying data to the hard drive. The TEE can also be replaced by other secure zones or environments, which will not be elaborated upon here.

[0058] Figure 3 This document illustrates a specific implementation architecture. Based on the technical concept outlined in this document, a log-structured data storage method based on append-only data structures is proposed. For example... Figure 3 As shown, the data storage method proposed in this specification is divided into three levels: encrypted data blocks, secure indexes, and secure logs.

[0059] First, encrypted user data blocks protected by MAC-authenticated encryption are written to the hard drive using an append-only (log) method. Generally, sequential writes are more media-friendly for both hard drives and solid-state drives (SSDs). Therefore, append-only writes maximize the raw performance of the underlying hard drive. Furthermore, because append-only writes allow new and old versions of logical data blocks to coexist, data recorded in this way can aid in crash recovery.

[0060] Secondly, a secure index is maintained, mapping the LBA to the HBA (Host Block Address, or Physical Address, representing the actual address where the data block is stored on the hard drive), the encryption key, and the Message Authentication Code (MAC) to locate and protect encrypted data blocks. This index is implemented as a specially designed, secure variant of the Log Merge Tree (LSM-tree). It can be specially designed based on the traditional LSM-tree to facilitate more secure and efficient index updates and queries.

[0061] Third, a security journal is introduced to record all recent disk updates, including updates to data, indexes, and other disk data structures. Log entries in the security journal are written to disk in an append-only manner. The security journal is crucial for ensuring consistency, atomicity, and other security properties.

[0062] in, Figure 3 The structure shown uses a variant of the Log Structure Merged Tree (LSM) to reduce write amplification and ensure index safety. The principles of the LSM-tree are described below.

[0063] The basic logic of an LSM-tree is a multi-level structure, smaller at the top and larger at the bottom, resembling a tree. The basic structure of an LSM-tree begins with the first level in memory, which typically stores all recently written key-value pairs (Kv). This data structure in memory is ordered and can be updated in-place at any time (e.g., adding data in log format), while also supporting querying at any time. Other levels can be stored on disk, with data in each level ordered based on the key (K) in the key-value pairs. When writing data, a write request for a key-value pair can be appended to the previous key-value pair record (Write Ahead Log) and then added to the first level in memory. When the data in the first level reaches a certain size (e.g., 4 megabytes), the first level is merged into the second level on disk, similar to merge sort, merging identical keys—this process is called compaction. This continues until the last level. The merged new level is sequentially written to disk, replacing the old levels. Each level, when it reaches a certain size, will continue to be merged with the levels below it. After merging, all old files can be deleted, leaving only the new ones. The writing process mainly uses the memory structure, and compaction can be completed asynchronously in the background without blocking the write.

[0064] Here, because data writing may be duplicated, new versions need to overwrite old versions. For example, if (a=1) is written first, and then (a=233) is written next, then 233 represents the new version of record 'a'. If the old version 1 of record 'a' has already been written to the last level, and the first level receives the new version, then it doesn't matter whether the old version exists in the files of lower levels. Cleaning up the old versions in lower levels can occur during the merge. During the query process, since the latest data is in the earlier levels and the oldest data is in the later levels, the query process first checks the first level; if the key K is not found, it checks the second level, and so on, querying layer by layer. Of course, if the key is found, it is usually the latest version, and the query can end.

[0065] Figure 4 This illustrates an LSM-tree structure that improves upon the basic structure of conventional techniques. (Reference) Figure 4 As shown, Figure 4 The LSM-tree shown is divided into three types of files: a first memory table (memtable) that normally receives write requests (in memory); a second memory table (immutable memtable) that is not modifiable (in memory); and an SStable (Sorted String Table, or SST for short) on disk. The ordered strings in the SST are the data keys K. It's worth noting that the first and second memory tables are named according to their different functions; the first memory table can be switched to function as the second memory table when it acts as an immutable memtable. For example... Figure 4 The SST shown has k layers (k is a positive integer), and the total space allocated to the next layer can be N times that of the previous layer (e.g., N=10). The layers can be sequentially labeled as layer 1, layer 2, ..., layer k.

[0066] Figure 4In the illustrated architecture, when writing data, index entries in the form of key-value pairs (K, v) of the data block can be inserted into the first memory table. When the first memory table is full, it can be switched to an immutable memtable, i.e., the second memory table. Alternatively, a new first memory table (memtable) can be created to receive new written data. The index entries in the converted immutable memtable second memory table can then be persisted to disk. This persistence can be done by directly flushing the data to the first-level SSTable file, without directly merging it with other files in that level. When the size of a file in the first level exceeds a certain threshold (e.g., 8 megabytes), a file can be selected to be merged into the next lower level. Furthermore, the merged files maintain overall order within each level. In this way, each level can maintain a specified number of files while ensuring that K values ​​do not overlap. That is, identical K values ​​are merged into the same file. Therefore, searching for a K value in a level only requires searching one file.

[0067] Figure 4 The illustrated architecture organizes data through files and queries data in units of files. However, the implementation architecture in this specification only uses data blocks and lacks a file structure. Therefore, to utilize the LSM-tree architecture, a hard disk component system without file system assistance needs to be constructed. In this specification, based on the special nature of data blocks, index information is organized through a new structural unit without the concept of a file.

[0068] Considering that data blocks differ from the "flat" structure of files, and that the structural units organizing index information in this specification serve three functions simultaneously—disk management, retrieval (query), and security protection—this specification proposes a structural unit adapted to data blocks, incorporating the concepts of B+ trees, such as a Block Index Table (BIT). In this way, [the following can be done / contained]. Figure 4 The SST File in the code is replaced with a new structural unit, BIT. For example... Figure 5 As shown. This improved LSM-tree can be called, for example, Disk-Oriented Secure LSM-tree (dsLSM-tree for short).

[0069] To illustrate the specific structure of BIT, Figure 6 A logical view of a specific example BIT is shown. Figure 6As shown, in a BIT, a single leaf node (such as L0, L1, L2, L3, etc.) can include an array of one or more block index records (such as LBA—HBA, Key, MAC, which can be called index entries), and the block index records in this array can be sorted by the size of the LBA. The root node (such as...) Figure 6 (represented as R) or other internal nodes (such as Figure 6 These are denoted as I0, I1, etc., and can also be collectively referred to as non-leaf nodes. Non-leaf nodes locate their child nodes by storing their child node HBAs and protect the security of their child nodes using the stored encryption keys and MACs of their child nodes. In other words, each node as a whole has an authentication encryption key and an authentication code (MAC), and this information can be stored in its parent node.

[0070] Specifically, since the block index arrays in the leaf nodes are sorted by LBA size, individual nodes in non-leaf nodes can be divided into intervals based on the LBA size of the ciphertext data blocks. For example... Figure 6 In this example, assume node R is divided into three intervals by two LBA (e.g., 200, 400) split points: less than or equal to 200; 201 to 400; and greater than 400. Node I0, for example, corresponds to the interval less than or equal to 200, and it is further divided by two LBA split points (e.g., 20, 100), corresponding to three leaf nodes L0, L1, and L2. Simultaneously, the MAC of a single leaf node can be stored in all its parent nodes. Optionally, a leaf node can contain multiple index entries. For example, the size of a leaf node can be the same as the size of a data block (e.g., 4KB), and it can contain at most the number of index entries required for a data block.

[0071] like Figure 6 The structural unit of the architecture is used as the index structure unit of the improved LSM-tree (i.e., dsLSM-tree). This design can meet the requirements of secure block devices, facilitate in-situ updates, and have higher retrieval efficiency.

[0072] The technical concept of this manual will be described in detail below, taking into account the process of writing user data in the TEE to the hard disk via a secure block device.

[0073] Figure 7 This specification illustrates a secure data storage process for a log structure according to one embodiment. This process can be used to store data to a hard disk within a Trusted Execution Environment (TEE) and ensure data security against attackers. Specifically, it protects users within the TEE from block I / O operations on untrusted hard disks. The TEE can be replaced with other secure or trusted areas outside the TEE; this specification does not limit this. The execution entity of this process can be located within the TEE, such as... Figure 1The secure block device shown is described above. This trusted execution environment can be set up on any computer, device, or server with a certain data processing capability.

[0074] Figure 7 The illustrated process may include the following steps: Step 701, encrypting the user-submitted data blocks to obtain corresponding ciphertext data blocks, and persisting each ciphertext data block to the hard disk in an append-only manner; Step 702, generating corresponding index entries for each of the ciphertext data blocks, wherein a single index entry is used to locate and protect one ciphertext data block; Step 703, inserting the index entries into a security index based on a log structure merge tree, and persisting the security index to the hard disk; Step 704, generating several log entries for the ciphertext data blocks, wherein the log entries are used to locate and protect the corresponding ciphertext data blocks in the event of a system crash, and a single log entry corresponds to one or more ciphertext data blocks; Step 705, appending the log entries to a security log on the hard disk, and persisting the security log to the hard disk.

[0075] Figure 7 The illustrated process can be applied to specific business scenarios where application data in a TEE is written to an external hard drive. In this scenario, applications (APPs) in the TEE can package files to be written into data blocks and write them to the hard drive in encrypted form using a secure block device.

[0076] First, in step 701, the data blocks submitted by the user are encrypted to obtain corresponding ciphertext data blocks, and each ciphertext data block is persisted to the hard disk in an append-only manner.

[0077] Here, "user" refers to an application within the TEE. A user can submit one or more data blocks at a time. For example, a user can submit these data blocks as a write request. A write request submitted by a user could be: `write(LBA, nblocks, buf)`, where `LBA` represents the logical address of the starting data block of the currently submitted data blocks, `nblocks` represents the number of data blocks submitted, and `buf` can represent a memory cache.

[0078] In a TEE (Time-Based Environment), data blocks can exist in plaintext. For several data blocks submitted by a user, they can be encrypted before being written to the hard drive. Specifically, firstly, an encryption key is generated for each plaintext data block, and then the corresponding ciphertext data block is encrypted. Finally, the ciphertext data block is written to the hard drive in an append-only (log) manner.

[0079] According to one possible design, data blocks can be managed in the form of segments, with segments serving as the unit for appending writes. A segment can be a group of contiguous blocks. Log-structured file systems allocate disk space in segments, ensuring that almost all disk writes, including log entries, are sequential, thereby maximizing the disk's raw I / O throughput. In the embodiments described in this specification, the default size for a data block is, for example, 4 kilobytes (4kb), and the default size for a data segment is, for example, 4 megabytes (4Mb).

[0080] Upon receiving a user's data block write request, the data can be appended to the current data segment in the memory cache. It's understood that the TEE can use the memory cached data, which remains under trusted protection. To ensure that each data block is recorded sequentially using the append-only method, the entire data segment can be written to disk, guaranteeing that the data blocks within the segment are written sequentially. Therefore, the current data block can first be written sequentially to the current data segment in the cache. The current data segment in the cache can be a segment that is not yet full. For example, if the current data segment is [B0, B1], containing only two segments B0 and B1, after receiving the above write request, data blocks can be appended to B2, B3, B4, and B5, updating the current data segment to [B0, B1, B2, B3, B4, B5], and it continues to wait for new data blocks to be written. If the current data segment is nearly full, for example, after writing B2 and B3, the subsequent data segments B4 and B5 are written to a new current data segment. In an optional embodiment, data blocks are written to the current data segment in the cache, and a message indicating successful writing is provided to reduce user (App) waiting time. Since data blocks in a data segment are recorded in an append-only manner, the internal data of the current segment is stored in the order in which the user submitted the data blocks.

[0081] When data blocks are managed on a segment-by-segment basis, a data segment can be written to the hard drive entirely if the first condition for writing the data segment to the hard drive is met. When the current data segment meets the first condition for writing data to the hard drive, the secure block device in the TEE can encrypt each data block within the data segment separately and write them to the hard drive sequentially.

[0082] In one embodiment, the first condition could be, for example, that the current data segment is full, such as 1024 data segments have been written, or that the remaining number of bytes that can be accommodated is less than the size of a data block. It is understood that, in order to avoid occupying too much space on the TEE, the entire data segment can be written to the hard disk in a timely manner when the current data segment is full.

[0083] In another embodiment, if the data recording condition is, for example, receiving a refresh request, the current data segment can be written to the hard disk upon receiving the refresh request. Since refreshing the TEE may clear the data content in the cache, the current data segment can be written to the hard disk upon receiving a refresh request from any device where the TEE resides that may refresh the cache of a secure area, thus avoiding data loss.

[0084] In another embodiment, if the business data update frequency is not frequent enough, such as when the business data volume is not large, the current data segment can be written to the hard disk periodically to avoid data loss or failure to be written to disk in a timely manner. In this case, the first condition could be, for example, reaching a predetermined duration in the cache for the current data segment. In other embodiments, the data recording condition can also be other conditions, which will not be elaborated here.

[0085] Encryption keys and data blocks can be in a one-to-one correspondence. For example, suppose a data segment includes 8 data blocks [B0, B1, B2, B3, B4, B5, B6, B7]. When writing the data segment to the hard disk, keys key0, key1, key2, key3, key4, key5, key6, and key7 can be generated, each corresponding to one of the data blocks. Each data block is then encrypted using these keys, resulting in a ciphertext data segment [E0, E1, E2, E3, E4, E5, E6, E7]. This ciphertext data segment can be written to the hard disk, thus protecting data security. The key generation and encryption process for each data block can be performed before or during the writing of the current data segment; this specification does not limit this process.

[0086] Next, in step 702, corresponding index entries are generated for each of the aforementioned ciphertext data blocks.

[0087] It's understandable that writing data blocks to the hard drive is for use in subsequent business processing. Therefore, when writing encrypted data segments to the hard drive, it's also necessary to consider the index information required for querying each data block. In the field of indexing, data is typically recorded using key-value pairs (which can be denoted as Kv in this specification), so one index entry can correspond to one Kv. Indexes are usually built using the key K, and the corresponding value (value or v) can be retrieved via the key as the retrieved data.

[0088] In data storage at the data block level, the logical address (LBA) of the data block can be used as the key (K), and the host block address (HBA), encryption key (key), and authentication code (MAC) used for encryption protection can be used as the value. Thus, a key-value pair can be LBA-(HBA, key, MAC). Here, LBA is the logical address known when the data block is received, key is the encryption key generated when encrypting the data, HBA is the actual host block address (also called the physical address) stored on the hard drive, and MAC is the authentication code used to verify the encryption of the data block based on key. MAC can be, for example, a hash value determined for the encrypted data block using a hash method.

[0089] In this specification, an index entry may include the key-value data of a ciphertext data block. Such an index entry may be called an index entry. For example, suppose the data block currently written to the disk includes a first data block, which is authenticated by a first key (key1) as a first ciphertext data block and an authentication code (MAC1). The first ciphertext data block can be located and protected by a first index entry. Therefore, the first index entry may include the logical address LBA1 of the first data block, its physical address HBA1 stored on the hard disk, the first key (key1), and the authentication code (MAC1).

[0090] Furthermore, in step 703, each of the above index entries is inserted into a security index based on a log structure merge tree, and the security index is persisted on the hard disk.

[0091] As can be understood from the preceding description, the indexing mechanism in this specification is a variant of LSM, and a specific implementation scheme using bits as the LSM index unit is designed. Under the technical concept of this specification, when writing encrypted data blocks to the hard disk, index entries generated for the encrypted data blocks can be inserted into a first memory table (memtable). Within the memtable, the index entries can be arranged according to the order in which the data blocks are written to the hard disk. If the memtable satisfies the second condition for index persistence, it can be switched to an immutable memtable, such as the second memory table, to persist the index entries therein to the hard disk.

[0092] In an optional embodiment, to avoid system crashes before the index entries in the first memory table are persisted as bits, the index entries can be appended to the Log log corresponding to the log result merge tree (e.g., ...) when writing data to the first memory table. Figure 5The index entries in the log (shown on the hard drive) can be cleared when persisted to the hard drive. This ensures that the hard drive's log for the dsLSM-tree records the latest index entries in sequence. If the system crashes before the index entries in the first memory table are persisted to bits, the first memory table can be recovered from the log on the hard drive.

[0093] According to some implementation methods in this specification, a BIT is logically... Figure 6 The architecture shown exists in an append-only format on the hard drive. Index entries on the hard drive can be written in units of bits. When writing index entries to the hard drive, the immutable second memory table can be traversed, recording each index entry one by one in the corresponding range of leaf nodes according to its LBA size, until the leaf nodes are full. When all leaf nodes of an intermediate node are full, the intermediate node can be recorded, and finally the root node is recorded. In some embodiments, for authentication and encryption requirements, the node size of a bit can be set to be the same as the data block size, for example, both are 4kB.

[0094] In optional implementations, indexes can also be managed as segments. For example... Figure 8 As shown, one BIT can correspond to multiple index segments. An index segment can contain a preset number of (…). Figure 8 The diagram shows four nodes (in practice, there could be other numbers). In a specific example, the size of a bit can be the same as the size of a data segment.

[0095] Assumption Figure 8 It is a record Figure 6 In a BIT logical structure for hard disk data, a leaf node can record two index entries. Assuming leaf node L1 is filled with two index entries first, the index segment first records node L1 and its index entries. Then, leaf node L3 is filled with two index entries, and the index segment records node L3 and its index entries. At this point, since all leaf nodes of intermediate node I1 are filled, the index segment can still record relevant information about node I1 and its leaf nodes, such as the MAC and LBA range split points of its leaf nodes. Subsequently, leaf nodes L0 and L2 are filled with two index entries in sequence, and the relevant index information in leaf nodes L0 and L2, intermediate node I0, and root node R is recorded sequentially. Segmenting the index helps in managing index information. Figure 6As shown, within a BIT, each index entry is recorded in ascending LBA order. The index information for each node is recorded in the index segment in an append-only manner, following the order in which each node is filled. Once an index segment is full, the entire segment can be written to the first level of the dsLSM-tree on disk, continuing until the index segment containing the root node is written to disk, thus completing the BIT generation process. When a single BIT is stored on disk, it can also be protected by key and MAC authentication encryption, which will not be elaborated upon here.

[0096] In one embodiment, the aforementioned second condition may be receiving a flush request. In another embodiment, the aforementioned second condition may be receiving a compaction request. When writing the index entries of the LSM-tree in memory to disk, a BIT can be created to write the first layer of the LSM-tree. Each key (LBA) is partitioned into different BITs. No two keys (K) exist within the same BIT, while different BITs may contain the same key (K). The essence of the compaction operation is to merge the identical key (K) in different BITs. Therefore, writing BITs to disk can be efficiently constructed and persisted through compaction. It is worth noting that compaction of the dsLSMtree can be performed under certain conditions, such as when the BITs of a layer fill a preset space for that layer.

[0097] This writing method allows for searching from the root node to the leaf node, sequentially searching the corresponding range based on the LBA value and verifying it via MAC. For example, in the previous example, to find a data block with an LBA of 100, the search first looks for a range less than or equal to 200 in the root node R. MAC verification in root node R confirms its existence in the corresponding lower-level node. The search continues in node I0. Through range searching and MAC verification in I0, an array of block index records in leaf node L1 is obtained, such as (HBA1, Key1, MAC1). After verification via MAC1, the corresponding data block is retrieved from the host block address HBA1. The corresponding data block can be decrypted using Key1.

[0098] In an optional embodiment, a Block Index Table Directory (BITC) can be introduced to record BITs for management. The BITC consists of multiple BIT entries, each containing metadata for a BIT. This metadata may include, for example, the BIT's ID, hierarchy, and the HBA, key, and MAC of its root node, etc. In this case, the LSM-tree described above can consist of a dynamically increasing number of BITs, and the number of BITs that the BITC can maintain varies with the number of BITs.

[0099] On the other hand, in step 704, several log entries are generated for the aforementioned encrypted data block.

[0100] Here, a log entry can be a record of information written to the security log. A single log entry can correspond to one or more ciphertext data blocks. The security log records write information to data segments written to the hard disk for data recovery in the event of a system crash (which can include various states where the system cannot function normally, such as system downtime, power failure, etc.). Specifically, log entries are used to locate and protect the corresponding ciphertext data blocks in the event of a system crash. These entries may include, for example, cryptographic information updated on the corresponding hard disk (the data block's key, authentication data MAC, etc.) and the written data block address HBA, etc. In other words, a log entry generated for a ciphertext data block may include the ciphertext data block's data block address HBA, key, authentication data MAC, etc. During the log entry generation process, a single log entry can be generated for a single ciphertext data block, or log entries can be generated for multiple ciphertext data blocks; this specification does not limit this.

[0101] Next, in step 705, the aforementioned log entries are appended to the security log of the hard disk.

[0102] Log entries can also record disk update data in an append-only manner. Because log entries in the security journal can include encrypted information about their corresponding disk updates, the confidentiality, integrity, and freshness of updates are guaranteed.

[0103] In alternative implementations, log entries can be stored in blocks (e.g., a 4KB block), referred to as log blocks. According to some embodiments, log blocks can be persisted on disk as a chained sequence of authenticated, cryptographically protected blocks. Specifically, the MAC authentication code of a single log block is embedded in the subsequent log block, ensuring that the blocks in the log record are associated in storage order. This eliminates the possibility of attackers forging false operation histories to mislead users.

[0104] In one embodiment, a single log block can have two MAC copies. The first copy is stored on the hard drive in plaintext along with the encrypted log block. To improve I / O efficiency, the log block size can be set smaller than a regular block (such as the 4KB ordinary data block mentioned earlier) so that the log block and its MAC can be contained within the same regular block. The second copy of the log block's MAC can be stored by its next log block, as described in the chained storage above. This scheme can verify the integrity of each log block, and more importantly, the integrity of the entire security log.

[0105] According to a possible design, based on the above log records, the security log can also be configured with checkpointing packs to achieve data consistency and atomicity in conjunction with recovery and commit. Checkpointing packs are used to reclaim disk space in the log area and speed up the recovery process by periodically converting log records into a more compact format, i.e., checkpointing, thus saving space. For example, a checkpointing pack (emphasizing content) can include a timestamp, the header and tail positions of the security log, and can store BIT metadata (e.g., block index table category BITC). To ensure crash consistency, two checkpointing packs can be maintained on disk, both in the checkpoint area, so that at least one is valid. After saving the checkpointing pack on disk, a checkpointing pack record can be written to the security log, referencing the new checkpointing pack.

[0106] Typically, hard drive initialization is performed in situations such as initial connection of a new hard drive or system crash. During initialization, the most recent of two checkpoint packets is selected, and the head and tail cursors of the security log are read from it. Then, the security log is scanned to begin the recovery process, locating the last checkpoint packet and initializing the memory data structures in the TEE based on the checkpoint packet record. Starting from this last checkpoint packet, the remaining portion of the security log is read, redoing one record (corresponding to one log entry) at a time, to restore the memory data in the TEE to a state consistent with the security log records on the hard drive.

[0107] In an optional implementation, the checkpoint packet can record an inverted index table (RIT) mapping from HBA to LBA. The RIT establishes the HBA-to-LBA mapping, the opposite of the security index maintained by the BIT (which establishes the LBA-to-HBA mapping). The RIT can contain the LBA for each valid block. Thus, querying the RIT retrieves the LBA of the data blocks to be cleaned up. Querying the RIT cleans up invalid data blocks. When data is managed in segments, the RIT can contain the LBAs of the valid blocks within each segment; given a segment to be cleaned up, invalid blocks within it can be cleaned up.

[0108] Furthermore, in one embodiment, the reverse index table (RIT) is encrypted (encrypted via a key generated for it) disk data (which may not have a MAC). The RIT needs encryption because it contains sensitive LBA information; leakage of this sensitive information would compromise privacy. The reverse index provided by the RIT can be easily verified using a secure index, therefore storing the RIT without integrity protection is secure.

[0109] Each block or node can be protected with a unique encryption key. In one alternative embodiment, the key can be generated by a random key generator, for example, as a random 16-byte value. The keys for data blocks, BIT blocks, and BIT nodes (including leaf nodes and non-leaf nodes) can be randomly generated, and for a node, its key can be stored by its "parent" node for later retrieval. In another embodiment, the key can be a deterministic key. For example, the key for a log block or RIT block can be determined using a deterministic key derivation function. The input to this key derivation function can be, for example, a Key Derivation Key (KDK), a sequence number, etc. For example, the KDK of a log block can be a trusted root key owned by the TEE (which can be obtained securely and reliably in advance), and the sequence number is the continuously incrementing logical ID of the log block. Using a deterministic key derivation method simplifies key management because only the KDK needs to be stored.

[0110] When I / O mode is logged, all data structures containing LBAs are encrypted on disk, ensuring that LBAs do not leak outside the secure area (TEE). This maintains anonymity for data written from the secure area to disk.

[0111] In optional implementations, when data is managed in segments, the checkpoint package can also record segment metadata such as the Segment Validity Table (SVT) and the Data Segment Table (DST). Segment metadata can be data structures used for segment allocation, release, and cleanup. Segment allocation and release typically pertain to the usage of the entire data segment (e.g., corresponding to 4MB of space), while segment cleanup involves processing a portion of the segment's data, such as migrating valid blocks from dirty segments to a new location while discarding invalid blocks to reclaim space from the dirty segment. A dirty segment can represent a segment where some data blocks are valid and others are invalid. The Reverse Index Table (RIT) mentioned earlier can also serve as segment metadata.

[0112] In this context, the SVT is a bitmap where each bit corresponds to a segment. The value of the bit indicates whether a segment is valid; for example, 1 indicates valid, 0 indicates invalid, and so on. Typically, a segment containing some valid data blocks (whose content is useful or updated to a certain date) is considered valid. Valid data blocks are simply called valid blocks, and invalid data blocks are simply called invalid blocks. If a segment contains both valid and invalid blocks, it can be considered partially valid. In an optional embodiment, two SVTs can be set up: one for managing data segments and one for managing index segments (BITs).

[0113] Data segments and index segments can be allocated using their respective SVTs. For a segment that is entirely valid or invalid, it can be freed by simply updating the corresponding value in its SVT. For example, index segments are typically used as a whole, so they can be freed by updating their SVT. Data segments, however, may be partially valid, and therefore may require additional data structures (such as DSTs or RITs) for cleanup.

[0114] It is understandable that segment cleaning performance has a significant impact on the performance of log-structured storage systems. In one embodiment, to minimize overhead, a combination of foreground and background cleaning can be used for segment cleaning. The foreground (current thread) and background (another thread) cleaning methods employ two cleaning selection strategies: a greedy strategy and a cost-effective strategy. Foreground cleaning, using a greedy strategy, minimizes cleaning latency through local optima, while background cleaning, using a cost-effective strategy, emphasizes global efficiency. In another embodiment, when disk utilization is high, switching from a regular log to a thread log can reduce user-visible latency. The thread log records new data written to "holes" (e.g., replacing invalid data blocks) in partially valid data segments without pre-cleaning these segments. In yet another embodiment, multiple log headers can be supported, meaning multiple write operations can occur simultaneously. This not only improves I / O parallelism but also allows hot and cold data to be separated into different data segments. For example, hot data is written to memory, and cold data is written to disk. In this model, hot and cold data are determined based on data popularity (such as I / O repetition rate). Data popularity can be determined by popularity parameters attached to write requests, and popularity estimation is performed by determining popularity parameters through user data. For example, a file system can estimate block popularity from file system-level metadata. In optional embodiments, the above optimization strategies can also be combined to effectively reduce the cost of segment cleaning.

[0115] A Data Segment (DST) can contain metadata for each data block within a single data segment, such as a block validity bitmap and modification timestamps. The block validity bitmap describes the validity of each data block within the segment. Modification timestamps provide information about when the data segment was modified. Using the information provided by the DST, dirty data segments to be cleaned can be selected using a greedy heuristic or cost-benefit analysis. For example, if the interval between the recorded time and the current time is greater than a predetermined time period, the corresponding data block is considered dirty data.

[0116] The following describes the process of reading (retrieve) data from the hard drive. In summary, to fulfill a data read request for a specified number of blocks starting from a user-specified LBA, a search can be performed from the secure index. During the search, the search proceeds sequentially according to the structural units (such as BITs) in the secure index until the corresponding LBA is found. When searching within a BIT, the search begins at the root node. Based on the LBA segmentation range recorded at the root node, the MAC information is retrieved from the root node. If the MAC verification confirms that the LBA to be retrieved is included in that BIT, the search continues to the lower-level nodes of the root node, and so on, until the corresponding leaf node is found. The corresponding HBA, encryption key, and other information are then retrieved. Otherwise, if the MAC verification at a node determines that the LBA to be retrieved is not included in the corresponding LBA range of that node, the search moves to the next BIT. Then, the encrypted ciphertext data block is read from the hard drive and decrypted using the HBA. After MAC verification of integrity, the corresponding plaintext data block is obtained. This plaintext data block can then be securely returned to the user.

[0117] As an example, suppose the LBA to be retrieved is 200. In the child node data recorded by the root node of the first BIT, the left node corresponds to an LBA range less than 100, and the right node corresponds to an LBA range greater than 100. Therefore, the key and MAC information corresponding to the right node can be obtained. MAC verification confirms that the child node corresponding to the right node does not contain the LBA=200 to be retrieved. Then, the second BIT can be retrieved. Suppose that in the child node data recorded by the root node of the second BIT, the left node corresponds to an LBA range less than 300, and the right node corresponds to an LBA range greater than 300. MAC verification confirms that the LBA to be retrieved can be matched with the left node among the child nodes of the root node. Further MAC verification of the child nodes of the left node matches leaf node C. The HBA information corresponding to LBA=200 can then be read from leaf node C. Using this HBA information, the corresponding ciphertext data block corresponding to LBA=200 can be read from the corresponding location on the hard drive, and the ciphertext data block can be decrypted using the corresponding encryption key to obtain the corresponding plaintext data block.

[0118] It is worth noting that the processes of generating index entries in steps 702 and 703, and generating log entries in steps 704 and 705, are different operations performed on the encrypted data block and can be executed in parallel or in reverse order. This specification does not limit this. The execution entity of the above processes can be set in a TEE (e.g., Figure 1 The so-called security block device), therefore, in response to Figure 7 In the description process, the parts executed by the TEE (except for the Apps or users in the TEE) can all be executed by the execution entity set in the TEE.

[0119] Figure 7 The technical solution in this embodiment, based on an append-only write method (new data is recorded append-only without replacing old data), and utilizing a secure index based on a log structure merging tree (the new version is retrieved before the old version during indexing and historical index entries do not need to be modified) and a secure log, means that when writing a single encrypted data block to the hard disk, the appended data consists of only a single index entry and at most one log entry (one log entry can correspond to one or more encrypted data blocks). It is understood that the data volume of the index entry and log entry is much smaller than the data volume of the encrypted data block. Therefore, during the storage of encrypted data blocks, the approximate I / O cost of securely writing the data block to the hard disk is 1 + ε times the data volume contained in a single data block: D(encrypted data block + index entry + log entry) / D(encrypted data block) = 1 + ε. Here, D represents the data volume, and ε is a number much less than 1. This is significantly less than the 2 × H (H >= 2, such as...) in conventional techniques. Figure 2 (As shown) much smaller, which means that the method of writing data to the hard drive through the secure area provided in this manual can greatly reduce the amount of data written, i.e., reduce write amplification.

[0120] In summary, this specification provides a secure data storage process with a log structure, which writes data to a hard drive in a non-secure environment through a Secure Block Device (TEE). This data storage process is based on append-only writes, combining memory caching and the data recording mechanisms of secure indexes and secure logs on the hard drive. It fully considers the protection of data confidentiality, integrity, freshness, and consistency, while also ensuring data anonymity and atomicity, and effectively reducing write amplification, thereby improving the effectiveness of writing data from the secure area to the hard drive.

[0121] To further clarify the specific application of the technical solutions provided in this specification Figure 9 This example illustrates implementation by dividing the hard drive into multiple storage regions. Figure 7 A schematic diagram of the technical solution.

[0122] like Figure 9As shown, a hard drive can be initialized and divided into five storage regions, for example: the first region, which can be called the Superblock Region, is used to store basic parameters of the hard drive, such as the size of various data blocks, the size of segments, and the location information of other regions on the hard drive. The information recorded in this region is usually relatively fixed; the second region, which can be called the Data Region, is used to record the user's encrypted data blocks in append mode; the third region, which can be called the Index Region, is used to record the index information of the encrypted data blocks of the Data Region in append mode; the fourth region, which can be called the Journal Region, is a large buffer with a large storage space and is used to store the security log; and the fifth region, which can be called the Checkpoint Region, is used to store information that describes the various data states on the hard drive, such as the beginning and end positions of the security log, SVT, DST, RIT, etc.

[0123] Before writing data to the hard drive, the TEE (such as the secure block device within it, hereinafter the same) can first initialize the hard drive to format it into the five regions mentioned above. Optionally, for the index region (the third region), it can be initialized according to the LSM tree structure.

[0124] When the TEE receives a write request for data, it can first append the received data block to the current data segment in the cache and send a successful write request to the user. This continues until the data segment recording condition is met, at which point the current data segment is written. Figure 9 The second area is defined in the system. Simultaneously, on one hand, index entries can be generated for each ciphertext data block within the ciphertext data segment. A single index entry can, for example, include the LBA-(HBA, Key, MAC) corresponding to a single ciphertext data block. Index entries can be appended to the current index table (such as the memtable cache index table). On the other hand, the security log in the fourth area records information about each data block written to the hard disk. If necessary, the information related to the data segment in the SVT and DST of the fifth area can be modified. Optionally, during the process of writing ciphertext data blocks to the hard disk, the validity information in the SVT and DST can be queried, allowing the writing of corresponding ciphertext data blocks into invalid segments or partially valid segments.

[0125] If the current index block meets the index record conditions, the index entries recorded in the current index table can be written to the third area of ​​the hard disk. First, the current index table (memtable) can be converted into an immutable index table (second memory table), such as an immutable memtable, for merging into the LSM tree in the third area of ​​the hard disk. When merging data items in the immutable index table into the LSM tree, the index entries in the immutable index table are traversed sequentially to construct each BIT unit, and then the BIT unit is written to the first level of the LSM tree. At this point, on the one hand, information about the BIT unit being written to the hard disk (such as the index information corresponding to the data block, BIT structure information, etc.) can be recorded in the log records of the fourth area; on the other hand, information such as the block index table category (BITC), relevant content in the modification and retrieval related SVT and DST, and RIT information can also be recorded in the fifth area.

[0126] When recording data into the security log of the fourth area, log blocks can be used as the data unit. A single log block can contain one or more data blocks, index entries, and other information to be recorded, and corresponds to a log block authentication identifier (MAC). In this way, log blocks can maintain a chained structure through MAC embedding between adjacent blocks to prevent disordered order, attackers from replacing data, or data recovery from crashes.

[0127] In some embodiments, if a crash occurs before a data block is committed to disk, the uncommitted data can be discarded, thus maintaining data record consistency. However, if a crash occurs before an index table is committed to disk, the safe zone can recover the current index table (such as a memtable table) from the log records of the fourth zone.

[0128] Figure 9 In the specific example shown, the confidentiality, integrity, and freshness of user data can be ensured through the construction of the LSM tree in the third area, while the security log in the fourth area can achieve consistency and atomicity of data in the security area and on the hard drive, and the RIT encryption mechanism in the fifth area can guarantee the anonymity of user data. Furthermore, in addition to ensuring the above-mentioned security features, the technical solution provided in this specification can also significantly reduce write amplification problems.

[0129] According to another embodiment, a secure data storage device with a log structure located on the computing side is also provided. This device can be used to protect user block I / O operations on untrusted hard disks in a trusted execution environment. Figure 10 A secure data storage device 1000 with a log structure according to one embodiment is shown, which can be located in a TEE, such as... Figure 1 The security block device in the system.

[0130] like Figure 10As shown, the device 1000 includes:

[0131] Data storage unit 1001 is configured to encrypt several data blocks submitted by the user to obtain corresponding ciphertext data blocks, and persist each ciphertext data block to the hard disk in an append-only manner.

[0132] The index generation unit 1002 is configured to generate corresponding index entries for each ciphertext data block, wherein a single index entry is used to locate and protect a ciphertext data block;

[0133] The index storage unit 1003 is configured to insert each index entry into a security index based on a log structure merge tree, and the security index is persisted on the hard disk.

[0134] Log generation unit 1004 is configured to generate several log entries for encrypted data blocks. The log entries are used to locate and protect the corresponding encrypted data blocks in the event of a system crash. Each log entry corresponds to one or more encrypted data blocks.

[0135] Log storage unit 1005 is configured to append several log entries to a security log on the hard disk, and the security log is persisted on the hard disk.

[0136] It is worth noting that, Figure 10 The device 1000 shown is with Figure 7 The methods described correspond to, Figure 7 The corresponding descriptions in the method embodiments also apply to the device 1000, and will not be repeated here.

[0137] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 7 The methods described above.

[0138] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, it implements a combination... Figure 7 The methods described above.

[0139] Those skilled in the art will recognize that the functions described in the embodiments of this specification in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0140] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the technical concept in this specification. It should be understood that the above description is only a specific embodiment of the technical concept in this specification and is not intended to limit the scope of protection of the technical concept in this specification. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments in this specification should be included within the scope of protection of the technical concept in this specification.

Claims

1. A secure data storage method with a log structure, used to protect user block I / O operations on untrusted hard disks in a trusted execution environment; the method includes: The user-submitted data blocks are encrypted to obtain corresponding ciphertext data blocks, and each ciphertext data block is persisted to the hard disk in an append-only manner. Each encrypted data block is assigned a corresponding index entry, where a single index entry is used to locate and protect a single encrypted data block. Each index entry is inserted into a secure index based on a log structure merge tree, and the secure index is persisted on the hard disk. A number of log entries are generated for the encrypted data block. The log entries are used to locate and protect the corresponding encrypted data block in the event of a system crash. Each log entry corresponds to one or more encrypted data blocks. The aforementioned log entries are appended to the security log of the hard disk, and the security log is persisted on the hard disk.

2. The method of claim 1, wherein, The plurality of data blocks include a first data block, which is authenticated and encrypted using a first key key1 to obtain a first ciphertext data block and an authentication code MAC1. The first ciphertext data block is located and protected by a first index entry, which includes the logical address LBA1 of the first data block, the physical address HBA1 stored on the hard disk, the first key key1, and the authentication code MAC1.

3. The method of claim 1, wherein, The aforementioned data blocks are multiple data blocks of the current data segment recorded in memory in the order of user submission using an append-only write method. The process involves encrypting the user-submitted data blocks to obtain corresponding ciphertext data blocks.

4. The method of claim 3, wherein, Under the condition that the data segment is written to the hard disk is met, each encrypted data block is persisted to the hard disk in an append-only manner. The first condition includes at least one of the following: the current data segment is full, a refresh request is received, or the recording duration reaches a predetermined duration.

5. The method of claim 1, wherein, The log structure merging tree corresponds to a first memory table, a second memory table, and multiple layers in the hard disk. The second memory table is used to persist the data to the multiple layers. The block index tables of each layer can be merged into the subsequent layers in sequence until the last layer. The process of inserting each index entry into a secure index based on a log structure merge tree includes: Insert each index entry into the current first memory table; If the second condition for index persistence is met, the first memory table is converted into a second memory table, thereby writing the index entries in the second memory table into the first of the plurality of layers.

6. The method of claim 5, wherein, Each of the multiple layers records index entries in units of a block index table (BIT). The leaf nodes of a single BIT correspond to one or more index entries, and a single non-leaf node stores the LBA range of the data blocks corresponding to each index entry in its child nodes, as well as the MAC authentication codes that are used for authentication and encryption protection for each child node.

7. The method of claim 5, wherein, The step of writing the index entry from the second memory table into the first of the plurality of layers includes: Traverse the LBAs in the second memory table to generate each BIT, wherein a single BIT corresponds to multiple consecutive index entries in the second memory table, and the multiple index entries in the BIT are arranged in ascending order; Write each bit to the first layer in append mode according to the completion order of each bit.

8. The method of claim 7, wherein, A single BIT is generated in the following way: Based on the single LBA range corresponding to a single leaf node, obtain the index entries that satisfy the single LBA range recorded in the single leaf node; For a single non-leaf node, after the corresponding leaf node is recorded, the authentication code (MAC) for authentication and encryption protection based on the LBA range of the corresponding leaf node and the index entries within the corresponding LBA range is recorded in the non-leaf node.

9. The method of claim 1, wherein, Each log entry in the security log is stored in the form of a log block. Each log block is authenticated and encrypted by its corresponding MAC address, and the MAC address of a single log block is embedded in the next log block.

10. The method of claim 1, wherein, The hard disk also contains a reverse index table mapping HBA to LBA. When inserting each index entry into a safe index based on a log structure merge tree, the method further includes: The inverted index table is updated based on each index entry.

11. The method of claim 3, wherein, The hard disk also records a first segment validity table (SVT) describing the validity of each data segment using bitmaps, and a data segment table (DST) describing the validity of each data block within a data segment. The method further includes: When each encrypted data block is persisted to the hard disk in an append-only manner, the first segment validity table and the data segment table DST are updated.

12. The method of claim 6, wherein, The hard disk also stores a second validity table SVT, which describes the validity of each block index table (BIT) using a bitmap. The method further includes: The second segment validity table is updated when the block index tables of each layer can be merged into subsequent layers or when the index entries in the second memory table are written into the first layer of the multiple layers.

13. A secure data storage device with a log structure, used to protect user block I / O operations on untrusted hard disks in a trusted execution environment; The device is located in a trusted execution environment and includes: The data storage unit is configured to encrypt several data blocks submitted by the user to obtain corresponding ciphertext data blocks, and persist each ciphertext data block to the hard disk in an append-only manner; The index generation unit is configured to generate corresponding index entries for each ciphertext data block, wherein a single index entry is used to locate and protect a ciphertext data block; An index storage unit is configured to insert each index entry into a security index based on a log structure merge tree, the security index being persisted on the hard disk; The log generation unit is configured to generate several log entries for the encrypted data block. The log entries are used to locate and protect the corresponding encrypted data block in the event of a system crash. Each log entry corresponds to one or more encrypted data blocks. The log storage unit is configured to append the plurality of log entries to the security log of the hard disk, and the security log is persisted on the hard disk.

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

15. A computing device, comprising a memory and a processor, characterized in that, The memory stores executable code, and when the processor executes the executable code, it implements the method described in claims 1-12.

Images