WO2023216783A1 - 日志结构的安全数据存储方法及装置 - Google Patents
日志结构的安全数据存储方法及装置 Download PDFInfo
- Publication number
- WO2023216783A1 WO2023216783A1 PCT/CN2023/087004 CN2023087004W WO2023216783A1 WO 2023216783 A1 WO2023216783 A1 WO 2023216783A1 CN 2023087004 W CN2023087004 W CN 2023087004W WO 2023216783 A1 WO2023216783 A1 WO 2023216783A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- index
- log
- data
- hard disk
- block
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 76
- 238000013500 data storage Methods 0.000 title claims abstract description 25
- 238000003860 storage Methods 0.000 claims abstract description 21
- 239000010410 layer Substances 0.000 claims description 63
- 238000004590 computer program Methods 0.000 claims description 6
- 238000013507 mapping Methods 0.000 claims description 5
- 230000002688 persistence Effects 0.000 claims description 4
- 230000001174 ascending effect Effects 0.000 claims description 3
- 239000002356 single layer Substances 0.000 claims description 2
- 230000003321 amplification Effects 0.000 abstract description 13
- 238000003199 nucleic acid amplification method Methods 0.000 abstract description 13
- 230000008569 process Effects 0.000 description 26
- 208000003734 Supraventricular Tachycardia Diseases 0.000 description 12
- 238000011084 recovery Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 11
- 238000004140 cleaning Methods 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 9
- 238000012795 verification Methods 0.000 description 9
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000005056 compaction Methods 0.000 description 3
- 238000009795 derivation Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 239000000872 buffer Substances 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000005242 forging Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000001680 brushing effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000007727 cost benefit analysis Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001627 detrimental effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000002657 hormone replacement therapy Methods 0.000 description 1
- 239000012464 large buffer Substances 0.000 description 1
- 238000012005 ligant binding assay Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
Definitions
- One or more embodiments of this specification relate to the field of secure computing technology, and in particular, to a log-structured secure data storage method and device.
- TEEs Trusted execution environments
- 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).
- TEE solutions can enable users of TEEs (e.g., cloud tenants) to run their sensitive applications in private memory areas that cannot be snooped or tampered with by privileged attackers (e.g., cloud operators).
- privileged attackers e.g., cloud operators
- the emergence of TEEs provides a new model for confidential computing and can solve the trust issues that hinder many usage scenarios (e.g., cloud computing).
- TEEs Although the memory of TEEs is protected by hardware, the hard disk data of TEEs (especially when TEEs are running) should be protected by software. In other words, the security issue of data written to a hard disk that is not protected by hardware when TEE is running is very important. In order to ensure data security, the write amplification generated when writing data is also a problem worthy of attention.
- One or more embodiments of this specification describe a log-structured secure data storage method and device to solve one or more problems mentioned in the background technology.
- a log-structured secure data storage method for protecting block I/O operations of users on untrusted hard disks in a trusted execution environment; the method includes: separately storing several data blocks submitted by the user. Encrypt to obtain corresponding ciphertext data blocks, and persist each ciphertext data block to the hard disk in an append writing manner; generate corresponding index entries for each ciphertext data block, where a single index entry is used for positioning and protect a ciphertext data block; insert each index entry into a secure index based on a log structure merge tree, and the secure index is persistent On the hard disk; generate several log entries for the ciphertext data block.
- the log entries are used to locate and protect the corresponding ciphertext data block in the event of a system crash.
- a single log entry corresponds to one or more ciphertexts.
- the plurality of data blocks include a first data block.
- the first data block is authenticated and encrypted with the first key key 1 to obtain the first ciphertext data block and the authentication code MAC 1 .
- a ciphertext data block is located and protected by a first index entry, which includes the logical address LBA 1 of the first data block, the physical address HBA 1 stored in the hard disk, and the first key key 1 and the authentication code MAC 1 .
- the plurality of data blocks are multiple data blocks of the current data segment recorded in the memory in an append writing manner in the order submitted by the user.
- the plurality of data blocks submitted by the user are respectively encrypted to obtain the corresponding respective data blocks.
- each ciphertext data block is persisted to the hard disk in an append writing mode, and the first condition includes at least one of the following: Item: The current data segment is full, a refresh request is received, and the recording duration reaches the predetermined duration.
- the log structure merge tree corresponds to a first memory table, a second memory table, and multiple layers in the hard disk, and the second memory table is used to persist the multiple layers
- the block index tables of each layer can be merged into subsequent layers in turn, until the last layer; inserting the several index entries into the secure index based on the log structure merge tree includes: inserting the several index entries into the current first Memory table; when the second condition for index persistence is met, convert the first memory table into a second memory table, thereby writing the index entries in the second memory table into the first memory table among the plurality of layers. layer.
- a single layer among 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 saves each index in its child node.
- the entry corresponds to the LBA range of the data block and each MAC authentication code for authentication and encryption protection of each sub-node.
- writing the index entry in the second memory table to the first layer among the multiple layers includes: traversing the LBA in the second memory table and generating each BIT, where a single BIT Corresponding to multiple consecutive index entries in the second memory table, and the multiple index entries in the BIT are arranged in ascending order; each BIT is written to the first layer in an append writing manner according to the completion order of each BIT.
- a single BIT is generated in the following manner: according to a single LBA range corresponding to a single leaf node, obtain an index entry that satisfies the single LBA range and record it in the single leaf node; for a single non-leaf node, in its corresponding After the 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.
- each log entry in the security log is stored in the form of a log block.
- Each log block is authenticated and encrypted by a corresponding authentication code MAC, and the MAC of a single log block is embedded in the subsequent log block. .
- the hard disk also records a reverse index table mapping HBA to LBA.
- the method further includes: The reverse index table is updated based on the number of index entries.
- the disk is also recorded with a first segment validity table SVT that describes whether each data segment is valid through a bitmap, and a data segment table DST that describes whether each data block in the data segment is valid.
- the method also records The method includes: updating the first segment validity table and the data segment table DST when each ciphertext data block is persisted on the hard disk in an append writing mode.
- the disk is also stored with a second segment validity table SVT that uses a bitmap to describe whether each block index table BIT is valid.
- the method also includes: the block index tables at each layer can be sequentially When the subsequent layers are merged or the index entries in the second memory table are written to the first layer among the plurality of layers, the second segment validity table is updated.
- a log-structured secure data storage device for protecting block I/O operations of users on untrusted hard disks in a trusted execution environment; the device is provided in the trusted execution environment and includes:
- a data storage unit configured to respectively encrypt several data blocks submitted by the user to obtain corresponding ciphertext data blocks, and to persist each ciphertext data block to the hard disk in an append writing manner;
- An index generation unit 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 configured to insert each index entry into a secure index based on a log structure merge tree, and the secure index is persisted in the hard disk;
- a log generation unit configured to generate several log entries for the ciphertext data block.
- the log entries are used to locate and protect the corresponding ciphertext data block in the event of a system crash.
- a single log entry corresponds to one or more ciphertext data blocks. text data block;
- a log storage unit configured to additionally write the plurality of log entries into a security log of the hard disk, and the security log is persisted on the hard disk.
- a computer-readable storage medium on which a computer program is stored.
- the computer program is executed in a computer, the computer is caused to perform the method of the first aspect.
- a computing device including a memory and a processor, wherein the storage
- the executable code is stored in the processor, and when the processor executes the executable code, the method of the first aspect is implemented.
- log-structured (log-structured) secure data storage method and device provided by the embodiments of this specification, secure data operations can be performed on the hard disk through the secure zone trusted execution environment.
- This data operation is based on the following three logical data structures: data blocks that can be written/read/retrieved; security index; security log.
- the data blocks are written to the hard disk in the form of ciphertext through append writing;
- the security index is an index established by generating index entries for each ciphertext data block in a log merge tree structure;
- the security log is used to record writes to the hard disk in the append writing manner. Operation information for entering data blocks or index entries.
- the TEE receives the data blocks to be written to the hard disk, and writes the data blocks to the hard disk in an append-write manner.
- index entries are generated for each ciphertext data block in the ciphertext data segment, and the index entries are inserted into the hard disk into a secure index based on the log structure merge tree, and the secure index can be persisted on the hard disk in an encrypted manner.
- log entries are generated for the ciphertext data blocks written to the hard disk, and the log entries are appended to the security log of the hard disk. The security log is persisted on the hard disk in an encrypted manner so that relevant index entries can be recovered in the event of a crash. harddisk.
- This method uses append writing for data block records (different from modifying or overwriting old version data).
- the log structure merge tree used can prioritize index entries corresponding to the new version of data (without modifying historical index entries), so that it can On the basis of data confidentiality, write amplification is reduced and the effectiveness of TEE using non-security protected hard disks to store data is improved.
- Figure 1 shows a schematic diagram of an implementation scenario of this specification
- Figure 2 shows a schematic diagram of the real-time architecture of writing data from a TEE to a hard disk in a specific example of conventional technology
- Figure 3 shows a schematic diagram of the implementation architecture of writing data to a hard disk by a TEE according to a specific example of the technical concept of this specification;
- Figure 4 shows a schematic diagram of the architecture of LSM-tree in conventional technology
- Figure 5 shows a schematic architectural diagram of the improved LSM-tree in the technical concept of this specification
- Figure 6 shows a schematic diagram of a specific example of the BIT logical architecture provided in this specification
- Figure 7 shows a flow chart of a log-structured secure data storage method according to one embodiment
- Figure 8 shows a schematic diagram of the storage of the BIT structure in the hard disk in the append writing mode according to the specific example shown in Figure 6 picture;
- Figure 9 shows a schematic diagram of the hard disk partition architecture that implements the technical concept of this specification in a specific example
- Figure 10 shows a schematic block diagram of a log-structured secure data storage device according to one embodiment.
- TEE The abbreviation of Trusted Execution Environment, also known as TEEs, provides a trusted environment isolated from REE (Rich Execution Environment, device common environment), providing a safer space for the execution of data and code. , and ensure their confidentiality and integrity. Generally, information in other areas of the device can be directly obtained through TEE, but other areas cannot obtain information in TEE;
- LSM-trees The abbreviation of Log-Structured Merge Trees, in which the data is recorded in the form of append writing to store permanent data and its index in the log, and is added to the end of the log each time, so that for the file Most of the system's accesses are sequential, thereby improving hard disk bandwidth utilization and fast fault recovery (for details, please refer to https://www.cnblogs.com/êtfang/archive/2013/01/12/lsm-tree. html, etc.);
- MHT Merkle Hash Trees
- MHTs Merkle hash trees
- the data in each parent node is the hash function of the data in its child nodes, and the data in the leaf nodes is atomic data.
- the hash value of the block (for details, please refer to the records at https://zhuanlan.zhihu.com/p/474938589, etc.);
- FIG. 1 shows a specific application scenario of this specification.
- a trusted execution environment and an untrusted hard disk are involved.
- One or more applications (APPs) run in the Trusted Execution Environment TEE, and various file data are generated during the running of the application. These file data need to be recorded in real time.
- TEE usually uses memory space and the space is limited, the data generated by APPs needs to be recorded in an untrusted hard disk outside the TEE through the Secure Block Device in the TEE.
- the security block device is a software or hardware device integrated into the TEE to protect the file I/O module of the TEE when the TEE is running.
- Secure block devices transparently protect all block I/O from the file I/O stack. In this way, other parts of the TEE can be used while allowing the legacy file I/O stack (including for use within the TEE) Under the premise of modifying or only making minor modifications to the existing file system), there is no need to pay extra attention to the security of file I/O.
- the security block device is represented by a bold line frame in Figure 1.
- the execution subject of the technical solution discussed in this manual it can realize the following three functions:
- Read such as read(LBA, nblocks, buf), means starting from the LBA address of the nblocks block, reading data from the hard disk into the buffer buf;
- Write such as write(LBA, nblocks, buf), means starting from the LBA address of the nblocks block, writing data from the buffer buf to the hard disk;
- Flushes such as flush(), ensure that all updated data is saved to disk.
- APPs can call the file I/O interface to transfer the file I/O blocks (hereinafter also referred to as data blocks) generated during its operation to the secure block device in the TEE, and the secure block device transfers them to Untrustworthy hard drives. If APPs require file I/O, they can call the file I/O interface to read from the hard disk and return it through the secure block device.
- file I/O blocks hereinafter also referred to as data blocks
- All data written to or read from a secure block device is clear text. It is the responsibility of the secure block device to appropriately encrypt/decrypt data transferred to or from the hard drive.
- the data identifier carried by APPs when submitting data to the secure block device can be called the logical block address (LBA).
- LBA logical block address
- the secure block device stores the data in the storage address of the hard disk. This is called the host block address (HBA), or physical address.
- the hard disk Since the hard disk is untrustworthy, suppose there is an attacker who has the privilege to control any hardware and software other than the TEE on the host, and can attack at any time he chooses during the entire life cycle of the TEE, all with the ability to tamper (not just It is the ability to monitor and respond to any I/O requests from the hard disk.
- the types of attacks that the attacker may carry out include but are not limited to: snooping attacks (monitoring I/O), tampering attacks (forging blocks), rollback attacks (replaying old blocks), etc.
- a secure block device must provide at least the following security guarantees for its block interface: Confidentiality, which means that user data submitted by any write operation is not leaked; Integrity, which guarantees that user data returned from any read operation is not leaked; is truly generated by the user; freshness, which ensures that user data returned from any read is up to date; consistency (or crash consistency), where all safety guarantees remain in effect regardless of any accidental or malicious crashes.
- SGX-PFS a method combining in-place update and Merkle hash tree
- MHT Merkle hash tree
- MHT Merkle hash tree
- each node stored on the hard disk is protected by authenticated encryption.
- the authenticated encryption protection is based on the encryption key and the authentication-based encryption protection.
- the authentication code MAC is protected.
- Leaf nodes contain file data, while non-leaf nodes maintain the encryption keys Key and authentication codes MAC of their child nodes.
- MHT ensures the confidentiality, integrity and freshness of file data.
- this file provides a fixed-size memory cache for the most recently used nodes. The latest valid version of the dirty node is saved in the recovery log before the dirty node is flushed to disk. This way, if any crash occurs during the refresh, the file can be restored to its last valid and consistent state via the recovery log.
- SGX-PFS introduces a certain write amplification, which may cause poor random write performance.
- the write amplification can be determined by comparing the amount of data to be written by the user with the actual amount of data to be written, for example, the ratio of the actual amount of data to be written to the amount of data to be written.
- MHT maps the number of data to be written to the amount of data to be written.
- recovery log There are two main sources of SGX-PFS write amplification: MHT and recovery log.
- MHT updates to a leaf node trigger cascading updates in all its parent nodes. This means that, for sufficiently large files, random writes can be amplified by a factor of up to H, where H is the depth of the MHT.
- this specification proposes a new secure block device (such as SwornDisk) structured scheme to reduce write amplification and improve random writing performance.
- the secure block device in the trusted execution environment can safely write data, read data, query data and other operations to the hard disk.
- the trusted execution environment TEE can also be replaced by other security areas or security environments, which will not be described again here.
- Figure 3 shows a specific implementation architecture of this specification. Under the technical concept of this specification, a (log-structured) data storage method based on append-write data structure is proposed. As shown in Figure 3, the data storage method proposed in this manual is divided into three levels: encrypted data blocks, security indexes, and security logs.
- the encrypted user data blocks protected by MAC authentication encryption are written to the hard disk in append writing (log) mode.
- append writing Generally, sequential writing is more friendly to storage media, whether it is a hard disk or an SSD. Therefore, append-writing data blocks can maximize the raw performance of the underlying hard drive.
- the append write method allows new and old versions of logical data blocks to coexist, the data recorded in this way can also help with crash recovery.
- LSM-tree log-structured merge-tree
- the structure shown in Figure 3 uses a variant of the log structure merge tree LSM to reduce the write amplification of data writing and ensure index security.
- LSM-tree The principle of LSM-tree is first described below.
- LSM-tree The basic logic of LSM-tree is a multi-layer structure, with small top and large bottom, shaped like a tree.
- the basic structure of LSM-tree is that the first layer of memory usually stores all recently written key-value pairs (K-v).
- K-v key-value pairs
- the data structure in memory is ordered and can be updated in place at any time (such as in log mode). Add data) and support query at any time. All other layers can be saved on the hard disk, and the data in each layer can be arranged in an orderly manner based on the key K in the key-value pair.
- a write operation 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 layer of the memory.
- the first layer of data When the space occupied by the first layer of data reaches a certain size (such as 4 megabytes, etc.), the first layer is merged to the second layer of the hard disk. Similar to merge sort, the same keys are merged. This process is Compaction. . And so on until the last layer. The merged new layers will be written to the hard disk sequentially, replacing the original old layers. When each layer occupies a certain amount of space, it will continue to merge with the lower layer. After merging, all old files can be deleted, leaving new ones. The writing process basically only uses the memory structure. Compaction can be completed asynchronously in the background without blocking writing.
- a certain size such as 4 megabytes, etc.
- the query process since the latest data is in the front layer and the oldest data is in the back layer, the query process is to check the first layer first. If there is no key K to be checked, then check the second layer.
- query layer by layer Of course, when found, the latest version is usually found, and the query can be ended.
- Figure 4 shows an LSM-tree structure improved on the basic structure in conventional technology.
- the LSM-tree shown in Figure 4 is divided into the following three types of files: (in memory) the first memory table (memtable) that normally receives write requests; (in memory) the second memory that cannot be modified Table (immutable memtable, immutable memory table); SStable (Sorted String Table, ordered string table, which can be referred to as SST) on the hard disk.
- the ordered string in SST is the key K of the data.
- the first memory table and the second memory table here are named according to their different functions.
- Each layer can be recorded as the first layer, the second layer...the kth layer in order.
- an index entry in the form of a key-value pair (K, v) of the data block can be inserted into the first memory table.
- the first memory table that is full can be switched to not
- the changeable immutable memtable is the second memory table.
- the converted index entries in the second memory table of immutable memtable can be persisted to the hard disk.
- persistence to the hard disk can be done by directly brushing the SSTable file of the first layer, and not directly merging it with the files of this layer.
- each layer is kept in overall order after merging. In this way, each layer can maintain the specified number of files while ensuring that K does not overlap. That is to say, merge the same K into the same file. So to find a K at one level, you only need to find one file.
- a limited threshold such as 8 megabytes
- the architecture shown in Figure 4 organizes data through files and queries data in units of files.
- index information is organized through a new structural unit without the concept of file (File).
- the structural unit that organizes index information in this manual has three functions at the same time: hard disk management, retrieval (query), and security protection.
- this manual it can be combined with the B+ tree
- the idea is to propose a structural unit adapted to data blocks, such as a block index table (BIT).
- BIT block index table
- the SST File in Figure 4 can be replaced with the new structural unit BIT.
- This improved LSM-tree can be called, for example, Disk-Oriented Secure LSM-tree (dsLSM-tree for short).
- Figure 6 shows a logical view of the BIT of a specific example.
- a single leaf node such as L 0 , L 1 , L 2 , L 3, etc.
- can include one or more arrays of block index records such as LBA—HBA, Key, MAC , which can be called an index entry
- the block index records in this array can be sorted by the size of the LBA.
- the root node represented as R in Figure 6) or other internal nodes (represented as I 0 , I 1, etc. in Figure 6) can also be collectively referred to as non-leaf nodes.
- Non-leaf nodes locate their child nodes through the HBA that saves them. child node, and uses the saved encryption key and MAC of its child node to protect the security of the child node.
- each node as a whole corresponds to the authentication and encryption key key and authentication code MAC, and this information can be stored in its superior node.
- a single node in non-leaf nodes can divide the interval based on the LBA size of the ciphertext data block.
- the R node is divided into three intervals through two LBA (such as 200 and 400) dividing points, for example: less than or equal to 200; 201 to 400; greater than 400.
- node I 0 corresponds to an interval less than or equal to 200, which in turn corresponds to three leaf nodes L 0 , L 1 , and L 2 through two LBA dividing points (such as 20, 100, etc.).
- the MAC of a single leaf node can be stored in all its superior nodes.
- multiple index entries can be written to a leaf node.
- the size of a leaf node can be consistent with the size of a data block (such as 4kb), and up to the number of index entries that fill one data block can be written.
- the structural unit in the architectural form of Figure 6 serves as the index structural unit of the improved LSM-tree (ie dsLSM-tree).
- This design can meet the needs of secure block devices, is conducive to in-place updates, and has higher retrieval efficiency. .
- FIG 7 shows the secure data storage process of a log structure according to one embodiment of this specification.
- This process can be used to store data to the hard disk in a trusted execution environment and keep the data safe from attackers. That is, to protect users’ block I/O operations on untrusted hard disks in a trusted execution environment.
- the trusted execution environment TEE can be replaced by other security areas or trusted areas other than TEE, and this specification does not limit this.
- the execution subject of this process can be set in a trusted execution environment, such as the secure block device shown in Figure 1 .
- the trusted execution environment can be located on any computer, device or server with certain data processing capabilities.
- Step 701 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 writing mode;
- Step 702. Generate corresponding index entries for the above-mentioned ciphertext data block, where a single index entry is used to locate and protect a ciphertext data block;
- Step 703 insert the above-mentioned index entries into a secure index based on the log structure merge tree, The security index is persisted on the hard disk;
- step 704 generate several log entries for the above ciphertext data blocks.
- the log entries are used to locate and protect the corresponding ciphertext data blocks in the event of a system crash.
- a single log entry corresponds to one or more Ciphertext data block;
- step 705 append the above log entries to the security log of the hard disk, and the security log is persisted on the hard disk.
- FIG. 7 The process shown in Figure 7 can be applied to the specific business scenario of writing application data in the TEE to an external hard disk.
- applications (APPs) in TEE can package files to be written into data blocks and write them to the hard disk in ciphertext through the secure block device.
- step 701 several data blocks submitted by the user are respectively encrypted to obtain corresponding ciphertext data blocks, and each ciphertext data block is persisted to the hard disk in an append writing manner.
- the user here can represent the application in TEE.
- Users can submit one or more data blocks at a time. Users can submit these data blocks in the form of write requests, for example.
- a write request submitted by the user is: write(LBA, nblocks, buf), LBA represents the logical address of the starting data block of several currently submitted data blocks, nblocks represents the number of currently submitted data blocks, and buf can represent memory. cache.
- data blocks can exist in clear text.
- Several data blocks submitted by the user can be encrypted before being written to the hard disk. Specifically, first, for each plaintext data block, an encryption key is generated and encrypted to obtain a corresponding ciphertext data block, and then the ciphertext data block is written to the hard disk in an append writing (log) manner.
- data blocks can be managed in the form of data segments (Segments), and segments can be used as units for additional writing.
- a segment can be a contiguous set of blocks.
- the log-structured file system allocates hard disk space in the form of segments, allowing almost all hard disk writes, including log records, to be sequential, thereby maximizing the hard disk's raw I/O throughput. quantity.
- the default size of the data block is, for example, 4 kilobytes (4kb)
- the default size of the data segment is, for example, 4 megabytes (4Mb).
- the current data segment in the memory cache can be written to the current data segment in the memory cache in an append write manner.
- TEE can use memory to cache data, and the data at this time is still in a trusted protection state.
- the entire data segment can be written to the hard disk to ensure that the data blocks in the data segment are written sequentially. Therefore, the current data block can be written sequentially to the current data segment in the cache first.
- the current data segment in the cache may be a data segment that has not yet been filled. For example, the current data segment is [B0, B1], which only contains 2 data segments B0 and B1.
- the data block can be written to B2, B3, B4, B5 in append writing mode.
- the current data segment Update to [B0, B1, B2, B3, B4, B5] and continue to wait for new data blocks to be written. Assume that the current data segment is nearly full. For example, after writing the two data segments B2 and B3, they will be filled. Then the subsequent data segments B4 and B5 will be written into the new current data segment.
- information that the writing is successful can be fed back to reduce the waiting time of users (Apps). Since the data blocks in the data segment are recorded in an append-write manner, for the current segment, its internal data is stored in the order in which the user submits the data blocks.
- the data segment can write the entire data segment to the hard disk when the first condition for writing the data segment to the hard disk is met.
- the secure block device in the TEE can encrypt each data block in the data segment and write it to the hard disk in sequence.
- the first condition may be, for example, that the current data segment is full, such as 1024 data segments have been written, or the number of remaining bytes that can be accommodated is less than the size of one data block, etc. It is understandable that in order not to occupy too much space in the TEE, when the current data segment is full, the entire segment of data can be written to the hard disk in a timely manner.
- the data recording condition is, for example, receiving a refresh request, and then the current data segment can be written to the hard disk when the refresh request is received. Since the refresh of the TEE may clear the data content in the cache, when receiving any refresh request from the device where the TEE is located that may refresh the cache of the safe area, the current data segment can be written to the hard disk to avoid data loss.
- the current data segment can also be written to the hard disk regularly to avoid data loss or failure to be written to the disk in time.
- the first condition can be, for example Is the current data segment reaches the predetermined length of time in the cache.
- the data recording condition may also be other conditions, which will not be described again here.
- Encryption keys and data blocks can have a one-to-one correspondence. For example, assuming that a data segment includes 8 data blocks [B0, B1, B2, B3, B4, B5, B6, B7], when the data segment is written to the hard disk, a one-to-one correspondence with each data block can be generated. Each key is key0, key1, key2, key3, key4, key5, key6, key7. Use each key to encrypt each data block in one-to-one correspondence.
- the obtained ciphertext data segment can be [E0, E1, E2, E3, E4, E5, E6, E7].
- the ciphertext data segment can be written to the hard disk to protect data security.
- the key generation and encryption process of each data block can be performed before the data block is written into the current data segment, or when the current data segment is written into the hard disk. This specification does not limit this.
- step 702 corresponding index entries are generated for the above-mentioned ciphertext data blocks.
- index information required for querying each data block.
- data is usually recorded using key-value pairs (which can be recorded as K-v in this manual), and one index entry can correspond to one K-v.
- the index is usually built by the key K, and the corresponding value (value or v) can be obtained via the key as the retrieved data.
- 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 protected by authentication encryption can be used as the value value.
- a K-v pair can be LBA-(HBA, key, MAC).
- LBA is the known logical address when receiving the data block
- key is the encryption key generated when encrypting the data
- HBA is the host block address (also called physical address) actually stored in the hard disk
- MAC is used to store the data block.
- the MAC can be, for example, a hash value determined for the encrypted data block by a hashing method.
- a piece of index information may include Kv data of a ciphertext data block, and such a piece of index information may be called an index entry.
- the data block currently written to the disk includes the first data block, and the first data block is authenticated by the first key key 1 , the first ciphertext data block and the authentication code MAC 1 .
- the first ciphertext data block can be located and protected by the first index entry, and the first index entry can include the logical address LBA 1 of the first data block and the physical address HBA 1 stored in the hard disk, the first key key 1 , Authentication code MAC 1 .
- each of the above index entries is inserted into a secure index based on the log structure merge tree, and the secure index is persisted on the hard disk.
- the indexing mechanism in this specification is a variant of LSM, and an implementation using BIT as the LSM index unit is specially designed.
- the index entry generated for the ciphertext data block can be inserted into the first memory table memtable.
- individual index entries can be arranged in the order of data blocks written to the hard disk.
- the memtable can be switched to an immutable memtable that cannot be changed, such as a second memory table, to persist the index entries in it to the hard disk.
- the index entries in order to avoid the system crashing before the index entries in the first memory table are persisted into BIT, the index entries can be appended to the log when writing the data to the first memory table. The results are merged into the log corresponding to the tree (the log in the hard disk as shown in Figure 5). Index entries in this Log can be cleared when persisted to disk. In this way, it can be ensured that the hard disk can record the latest index entries in order for the Log log of dsLSM-tree. If the system crashes before the index entries in the first memory table are persisted into BITs, the first memory table can be restored based on the Log in the hard disk.
- a BIT logically has the architecture shown in Figure 6, and can exist in the form of append writing in the hard disk.
- Index entries in the hard disk can be written in BIT units.
- the unchangeable second memory table that is, the immutable memtable
- the unchangeable second memory table can be traversed, so that each index entry is recorded in the leaf nodes of the corresponding range one by one according to the corresponding LBA size, until the leaf nodes are filled. If all leaf nodes of an intermediate node are filled, the intermediate node can be recorded, and finally the root node can be recorded.
- the node size of the BIT can be set to be consistent with the size of the data block, for example, both are 4kB.
- indexes can also be managed in segments. As shown in Figure 8, one BIT can correspond to multiple index segments.
- An index segment (Index Segment) can contain a preset number of nodes (four is shown in Figure 8, but it can be other numbers in practice).
- the size of a BIT can be consistent with the size of a data segment.
- Figure 8 is the hard disk data that records the BIT logical structure in Figure 6.
- One leaf node can record 2 index entries. Assume that the leaf node L 1 is filled with 2 index entries first, then the L 1 node and its contents are first recorded in the index segment. Index entries, and then the leaf node L 3 is filled with 2 index entries, then the L 3 node and its index entries are recorded in the index segment. At this time, since all the leaf nodes of the intermediate node I 1 are filled, the relevant information of the I 1 node and its leaf nodes can also be recorded in the index segment, such as the MAC and LBA range split points of its leaf nodes.
- each index entry is recorded in ascending order of LBA.
- the index information of each node is recorded in the index segment by append writing in the order in which each node is filled. After an index segment is full, the entire index segment can be written to the first level of the dsLSM-tree on the disk until the index segment where the root node is located is written to the hard disk, and a BIT generation process ends.
- a single BIT is stored on the hard disk, it can also be encrypted and protected by key and MAC authentication, which will not be described again here.
- the aforementioned second condition may be receiving a flush request. In another embodiment, the aforementioned second condition may be receiving a compaction request.
- LBA key
- Each key (LBA) is partitioned into different BITs. The same BIT does not exist in the same BIT. K, and the same K may exist in different BITs.
- the essence of the merge operation is to merge the same key K in different BITs, so the BITs written to the hard disk can be effectively constructed and persisted through merge compression. It is worth mentioning that the merge and compression of dsLSMtree can be performed when certain conditions are met, for example, the BITs of a layer occupy the preset space of the layer, etc.
- the corresponding range is searched sequentially according to the size of the LBA value from the root node to the leaf node, and passed MAC verification. For example, in the previous example, if you want to find the data block with LBA of 100, you first search for the corresponding range less than or equal to 200 in the root node R, and determine that it exists in the corresponding lower-level node through MAC verification in the root node R. Then continue to search for node I 0 , and through range search and MAC verification in I 0 , obtain the array of block index records in leaf node L 1 such as (HBA 1 , Key 1 , MAC 1 ). After verification by MAC 1 , from The corresponding data block is fetched from the host block address HBA 1 . The corresponding data block can be decrypted with Key 1 .
- a block index table directory (BITC) can also be introduced to record BITs.
- BITC consists of multiple BIT entries. Each BIT entry contains metadata of a BIT.
- the metadata of a BIT may include, for example, the ID of the BIT, the HBA of the hierarchy and its root node, key and MAC, etc.
- the LSM-tree described above can be composed of a dynamic number of BITs, and the number of BITs that BITC can maintain changes with the BITs.
- step 704 several log entries are generated for the above-mentioned ciphertext data block.
- the log entry can be a record of information written to the security log.
- a single log entry can correspond to one or more ciphertext blocks.
- the security log (Journal) can record the write information of the data segments written to the hard disk for use in the event of a system crash (crash, which can include various states in which the system cannot operate normally, such as downtime, power outage, etc.) Data recovery.
- the log entry is used to locate and protect the corresponding ciphertext data block in the event of a system crash, which may include, for example, updated cryptographic information about its corresponding hard disk (key, verification of the data block). Data MAC, etc.) and the written data block address HBA, etc.
- the log entries generated for the ciphertext data block may include the data block address HBA, key, verification data MAC, etc. of the ciphertext data block.
- a log entry can be generated for a single ciphertext data block, or log entries can be generated for multiple ciphertext data blocks. This manual does not limit this.
- step 705 the above-mentioned several log entries are additionally written into the security log of the hard disk.
- Log entries can also record disk update data in an append-write manner. Because log entries in the Security Journal can include encrypted information about their corresponding updates on the hard drive, the confidentiality, integrity, and freshness of updates are guaranteed. freshness.
- log entries may be stored in blocks (e.g., a block is 4KB), e.g., called log blocks.
- log blocks may be persisted on the hard disk as a chained sequence of blocks protected by authenticated cryptography. Specifically, the authentication code MAC of a single log block is embedded in the subsequent log block, thereby ensuring that the individual blocks in the log record are associated in the order in which they are stored. In this way, the possibility of being misled by attackers forging false operation history can be eliminated.
- a single log block can have two MAC copies.
- the first copy is stored on the hard disk in clear text along with encrypted log blocks.
- the size of the log block can be set smaller than the size of the regular block (such as the 4KB ordinary data block mentioned above), so that the log block and its MAC can be accommodated in the same regular block.
- the second copy of a log block's MAC can be stored by its next log block, as in the chain storage described previously. This scheme can verify the integrity of each log block and, more importantly, the integrity of the entire secure log.
- the security log can also be set through the checkpointing pack to cooperate with recovery and submission to achieve data consistency and atomicity.
- the checkpoint package is to reclaim the hard disk space in the log area and speed up the recovery process. It regularly converts the log records into a more compact format, that is, checkpointing, thus saving more space.
- the checkpoint package (emphasis added) may include a timestamp, the head and tail positions of the security log, and may store the BIT's metadata (e.g., block index table category BITC, etc.).
- BIT's metadata e.g., block index table category BITC, etc.
- the hard disk can be initialized during the initial connection of a new hard disk or a system crash.
- the security log is scanned to start the recovery process to find the last checkpoint packet, and the memory data structure in the TEE is initialized based on the checkpoint packet record.
- the memory data structure in the TEE is initialized based on the checkpoint packet record.
- the checkpoint package can record an inverse index table of HBA to LBA mappings.
- the reverse index table RIT can establish HBA to LBA mapping, as opposed to the security index maintained by BIT (which establishes LBA to HBA mapping).
- the RIT can contain an LBA for each valid block. In this way, querying the RIT can retrieve the LBA of the cleaned data block. Query the RIT to clean up invalid data blocks. In cases where data is managed in segments, the RIT can contain LBAs of valid blocks in each data segment, and invalid blocks in it can be cleaned given the data segment to be cleaned.
- the reverse index table RIT is protected by encryption (via the key generated for it Encrypted) hard disk data (can be without MAC). RIT needs to be encrypted because it contains sensitive information of LBA. If sensitive information is leaked, it will be detrimental to privacy protection.
- the inverted index provided by RIT can be easily verified with a secure index, so it is safe to store RIT without integrity protection.
- each block or node can be protected with a unique encryption key.
- the key key can be generated by a random key generator, for example, a random 16-byte value.
- the keys of data blocks, BIT blocks and BIT nodes can be randomly generated. For nodes, their keys can be saved by their "parent" nodes for subsequent retrieval.
- the key may be a deterministic key.
- the key for a log block or RIT block can be determined by a deterministic key derivation function. Inputs to the key derivation function may be, for example, a key derivation key (KDK), a serial number, etc.
- KDK key derivation key
- the KDK of a log block can be a trusted root key securely owned by the TEE (which can be obtained securely and trustfully in advance), and the sequence number is the ever-increasing logical ID of the log block.
- TEE trusted root key securely owned by the TEE
- sequence number is the ever-increasing logical ID of the log block.
- the checkpoint package can also record information such as segment validity table (Segment Validity Table, SVT), data segment table (Data Segment Table, DST), etc. Segment metadata.
- SVT Segment Validity Table
- DST data segment table
- Segment metadata can be a data structure used to allocate, release, clean up, etc. the segment.
- segment allocation and release are usually based on the usage of the entire data segment (for example, corresponding to 4MB of space)
- segment cleaning is the process of processing part of the segment data, such as migrating the valid blocks of the dirty segment to a new one. location, while discarding invalid blocks to reclaim dirty segment space.
- the dirty segment can represent a segment in which some data blocks are valid and some data blocks are invalid.
- the aforementioned Reverse Index Table (RIT) can also be used as the metadata of the segment.
- SVT is a bitmap, each bit corresponds to a segment, and the value on this bit indicates whether a segment is valid. For example, 1 means valid, 0 means invalid, etc.
- a segment that contains some valid chunk of data (whose content is useful or updated to a certain date) is valid.
- a valid data block is referred to as a valid block, and an invalid data block is referred to as an invalid block.
- a segment is considered partially valid if it contains both valid and invalid blocks.
- two SVTs may be set, one for managing data segments and one for managing index segments (BIT).
- Data segments and index segments can be allocated through their respective SVTs.
- An entire valid or invalid segment can be released by simply updating the corresponding value in the SVT.
- an index segment is usually used in its entirety and therefore can be freed by updating the SVT of the index segment.
- the data segment may be partially valid, so additional data structures (such as DST, RIT) may be needed to clean it.
- segment cleaning performance has an important impact on the performance of log-structured storage systems.
- segment cleaning can be performed by combining foreground and background cleaning.
- the two cleaning methods of the foreground (current thread) and background (another thread) respectively adopt two cleaning selection strategies: greedy strategy and cost-effective strategy.
- Foreground cleanup uses a greedy strategy to minimize cleanup delay through local optimization, while background cleanup emphasizes global efficiency through a cost-benefit strategy.
- when hard disk utilization is high you can switch from normal logs to thread logs to reduce user-visible delays. Thread logging writes new data into "holes" in partially valid data segments (such as replacing invalid data blocks) without cleaning these data segments beforehand.
- multiple logging heads may be supported, that is, multiple write operations occur simultaneously.
- hot data and cold data can also be separated into different data segments.
- hot data is written to memory and cold data is written to hard disk.
- hot data and cold data are determined based on data heat (such as I/O repetition rate).
- Data heat can be determined by the heat parameters attached to the write request.
- the heat parameters are determined through user data to estimate the heat.
- a file system can estimate a block's popularity from file system-level metadata.
- the above optimization strategies can also be combined with each other, thereby effectively reducing the cost of segment cleaning.
- DST can contain metadata for each data block in a single data segment, such as block validity bitmap (block validity bitmap), modification timestamp, etc.
- block validity bitmap can be used to describe the validity of each data block in the data segment.
- the modification timestamp can be the time information when the data segment was modified.
- dirty data segments can be selected for cleaning by using greedy heuristics or cost-benefit analysis. For example, if the interval between the recording time and the current time is greater than a predetermined time period based on the timestamp, the corresponding data block is considered dirty data.
- the following describes the process of reading (reading, retrieving) data from the hard disk.
- a data read request for a specified number of blocks starting from a user-specified LBA
- it can be retrieved from the secure index.
- you can search one by one according to the structural units (such as BIT) in the security index until the corresponding LBA is retrieved.
- the structural units such as BIT
- you can start from the root node and obtain the MAC information from the root node based on the corresponding LBA division range recorded by the root node.
- the verified MAC determines that the LBA to be retrieved is included in the BIT, further retrieve the subordinate nodes of the root node, and so on, until the corresponding leaf node is retrieved, and retrieve the HBA, encryption key and other information corresponding to the LBA. Otherwise, if the verified MAC at a certain node determines that the LBA to be retrieved is not included in the corresponding LBA range of the corresponding node, the next BIT will be retrieved. Then, the encrypted ciphertext data blocks are read and decrypted from the data on the hard disk through the HBA. After verifying the integrity by MAC, the corresponding plaintext data block can be obtained. In turn, plaintext data blocks can be fed back to the user securely.
- the LBA to be retrieved is 200
- the left node corresponds to an LBA range less than 100
- the right node corresponds to an LBA range greater than 100
- the right node pair can be obtained The corresponding key and MAC information.
- the left node corresponds to an LBA range less than 300
- the right node corresponds to an LBA range greater than 300.
- step 702 the process of generating index entries in step 702, step 703 and the process of generating log entries in step 704 and step 705 in the above process, as different operations on the ciphertext data block, can be executed in parallel or in an alternate order.
- the execution subject of the above process can be set in the TEE (such as the so-called security block device in Figure 1). Therefore, in the description process of Figure 7, the so-called TEE execution part (except Apps or users in the TEE) are all It can be executed by the execution subject located in the TEE.
- the technical solution in the embodiment of Figure 7 is based on the append write method (when new data is written, it is recorded in the append write method without replacing the old data), and utilizes a safe index based on the log structure merge tree (the index is new when the index is written). version retrieved before the old version without modifying the historical index entries) and the security log, when writing a single ciphertext data block to the hard disk, the additional data is only a single index entry and at most one log entry (one log entry can correspond to one or Multiple ciphertext data blocks). It can be understood that the data size of index entries and log entries is much smaller compared to the data size of ciphertext data blocks.
- D represents the amount of data
- this manual provides a log-structured secure data storage process that writes data to a hard disk in a non-secure environment through the Secure Block Device in the TEE.
- the data storage process is based on append writing, combined with the data recording mechanism of memory cache and hard disk security index and security log, fully considering the protection of data confidentiality, integrity, freshness and consistency, and also taking into account the data security.
- Anonymity and atomicity and effectively reduce the write amplification of data, thereby improving the effectiveness of writing data to the hard disk in the safe area.
- FIG. 9 shows a schematic diagram of implementing the technical solution in FIG. 7 by dividing the hard disk into multiple storage areas in a specific example.
- the hard disk can be initialized and divided into 5 storage areas, for example: the first area, where For example, it can be called the Superblock Region, which is used to store the basic parameters of the hard disk, such as the block size of various data, the size of the segments, and the location information of other areas on the hard disk.
- the Superblock Region which is used to store the basic parameters of the hard disk, such as the block size of various data, the size of the segments, and the location information of other areas on the hard disk.
- the information recorded in this area is usually Relatively fixed; the second area, which can be called the data region (Data Region) here, is used to record the user's ciphertext data block in the append writing mode; the third area, which can be called the index region (Index Region) , used to record the index information of the encrypted data block of the data area in append writing mode; the fourth area, for example, can be called the journal area (Journal Region), which serves as a large buffer and usually has a large storage space. Used to store security logs; the fifth area, here for example called the Checkpoint Region, is used to store information that can describe various data states in the hard disk, such as the head and tail positions of the security log, SVT, DST, RIT, etc. wait.
- the TEE (such as the secure block device, the same below) can initialize the hard disk to format the hard disk into the above five areas.
- the index area (the third area) can be initialized according to the structure of the LSM tree.
- the TEE When the TEE receives a write request for data, it can first write the received data block in the current data segment of the cache in an append write mode, and feedback the successful write request to the user. Until the data segment recording conditions are met, the current data segment is written into the second area in Figure 9.
- index entries can be generated for each ciphertext data block in the ciphertext data segment.
- a single index entry may include, for example, the LBA-(HBA, Key, MAC) corresponding to a single ciphertext data block.
- Index entries can be written to the current index table (such as the memtable cache index table) in append write mode.
- the security log of the fourth area the information of each data block written to the hard disk is recorded.
- the information related to the data segment (Data Segment) in the SVT and DST of the fifth area can be modified.
- the validity information in SVT and DST can also be queried, so that the corresponding ciphertext data block can be written into the holes of the invalid segment or part of the valid segment.
- the index entries recorded in the current index table can be written to the third area of the hard disk.
- second memory table such as immutable memtable
- the information written by the BIT unit to the hard disk can be recorded in the log record of the fourth area.
- the block can also be recorded in the fifth area.
- Index table category BITC modify related content in SVT and DST related to retrieval, and record RIT and other information.
- log blocks When recording data in the security log of the fourth area, log blocks may be used as data units for recording.
- a single log block can contain one or more data blocks and index entries waiting to be recorded, and should have a log block authentication mark.
- Know MAC In this way, log blocks can be embedded in the chain structure through MAC embedding between adjacent blocks to avoid order disorder, data replacement by attackers, or crashed data recovery.
- the uncommitted data may be discarded, thereby maintaining the consistency of the data records. If the index table crashes before it is submitted to the hard disk, the safe area can restore the current index table (such as the memtable table) through the log records in the fourth area.
- 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 the consistency of the security area and hard disk data. and atomicity, and the encryption mechanism of RIT in the fifth area can ensure the anonymity of user data.
- the technical solutions provided in this manual can also greatly reduce write amplification problems.
- a log-structured secure data storage device provided on the computing side is also provided. This device can be used to protect users' block I/O operations on untrusted hard disks in a trusted execution environment.
- FIG. 10 shows a log-structured secure data storage device 1000 according to an embodiment, which may be provided in a TEE, such as the secure block device in FIG. 1 .
- device 1000 includes:
- the 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-write mode;
- the index generation unit 1002 is configured to generate corresponding index entries for each ciphertext data block, where a single index entry is used to locate and protect a ciphertext data block;
- the index storage unit 1003 is configured to insert each index entry into a secure index based on the log structure merge tree, and the secure index is persisted on the hard disk;
- the log generation unit 1004 is configured to generate several log entries for the ciphertext data block.
- the log entries are used to locate and protect the corresponding ciphertext data block in the event of a system crash.
- a single log entry corresponds to one or more ciphertext data blocks. ;
- the log storage unit 1005 is configured to append several log entries to the security log of the hard disk, and the security log is persisted on the hard disk.
- the device 1000 shown in FIG. 10 corresponds to the method described in FIG. 7 , and the corresponding descriptions in the method embodiment of FIG. 7 are also applicable to the device 1000 and will not be described again here.
- a computer-readable storage medium on which a computer program is stored.
- the computer program is executed in a computer, the computer is caused to perform the method described in connection with FIG. 7 and the like.
- a computing device including a memory and a processor, executable code is stored in the memory, and when the processor executes the executable code, the implementation described in conjunction with FIG. 7 and the like is implemented. Methods.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Databases & Information Systems (AREA)
- Storage Device Security (AREA)
Abstract
本说明书实施例提供一种日志结构的安全数据存储方法及装置,用于经由可信执行环境TEE向硬盘安全存储数据。该数据操作基于以下三种逻辑数据结构进行:可进行写/读/检索等操作的数据块;安全索引;安全日志。其中,数据块以密文形式通过追加写方式写入硬盘;安全索引是针对为各个密文数据块生成的各个索引条目以日志合并树结构建立的索引;安全日志用于以追加写方式记录向硬盘写入数据块或索引条目的操作信息。这种数据存储架构可以在数据保密的基础上减少TEE向硬盘存储数据的写放大。
Description
本申请要求于2022年05月13日提交中国国家知识产权局专利局、申请号为CN202210520607.7、发明名称为“日志结构的安全数据存储方法及装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本说明书一个或多个实施例涉及安全计算技术领域,尤其涉及日志结构的安全数据存储方法及装置。
随着计算机技术的发展,计算机数据的隐私保护成为较为重要的研究方向。可信执行环境(Trusted execution environment,TEEs)近年来越来越受欢迎。计算机领域一些主要的CPU架构已经实施了相应的TEE解决方案(如英特尔SGX、AMD SEV、RISC-V Keystone、Power PEF等),或宣布了相应的TEE解决方案(英特尔TDX、Arm CCA)。这些TEE解决方案可以使得TEEs用户(例如,云租户)能够在私有内存区域中运行他们的敏感应用,这些私有内存区域不能被特权攻击者(例如,云操作员)窥探或篡改。TEEs的出现为机密计算提供了新模式,并可以解决阻碍许多使用场景(例如,云计算)的信任问题。
虽然TEEs的内存受硬件保护,但TEEs(尤其是TEEs运行时)的硬盘数据,应该受到软件的保护。也就是说,TEE运行时向不受硬件保护的硬盘写入的数据的安全问题非常重要。而为了保证数据安全,在写入数据时产生的写放大,也是值得关注的问题。
发明内容
本说明书一个或多个实施例描述了一种日志结构的安全数据存储方法及装置,用以解决背景技术提到的一个或多个问题。
根据第一方面,提供一种日志结构的安全数据存储方法,用于保护可信执行环境中用户对不可信硬盘的块I/O操作;所述方法包括:将用户提交的若干数据块分别进行加密得到相应的各个密文数据块,并将各个密文数据块以追加写方式持久化于所述硬盘;为各个密文数据块分别生成相应的各个索引条目,其中,单个索引条目用于定位和保护一个密文数据块;将各个索引条目分别***基于日志结构合并树的安全索引,所述安全索引持久化
在所述硬盘;为所述密文数据块生成若干日志条目,所述日志条目用于在发生***崩溃的情况下定位和保护对应的密文数据块,单个日志条目对应一个或多个密文数据块;将所述若干日志条目追加写入所述硬盘的安全日志中,所述安全日志持久化在所述硬盘。
在一个实施例中,所述若干数据块包括第一数据块,针对所述第一数据块由第一密钥key1进行认证加密得到第一密文数据块及认证码MAC1,所述第一密文数据块由第一索引条目定位和保护,所述第一索引条目包括所述第一数据块的逻辑地址LBA1以及在硬盘中存储的物理地址HBA1、所述第一密钥key1和所述认证码MAC1。
在一个实施例中,所述若干数据块是按用户提交顺序以追加写方式记录在内存中的当前数据段的多个数据块,所述将用户提交的若干数据块分别进行加密得到相应的各个密文数据块。
在一个实施例中,在满足将数据段写入硬盘的第一条件的情况下,将各个密文数据块以追加写方式持久化于所述硬盘,所述第一条件包括以下中的至少一项:当前数据段被写满、接收到刷新请求、记录时长达到预定时长。
在一个实施例中,所述日志结构合并树对应有第一内存表、第二内存表,以及硬盘中的多个层,所述第二内存表用于向所述多个层进行持久化,各个层的块索引表可依次向后面的层中合并,直至最后一层;所述将所述若干索引条目***基于日志结构合并树的安全索引包括:将所述若干索引条目***当前的第一内存表;在满足索引持久化的第二条件的情况下,将所述第一内存表转化为第二内存表,从而将第二内存表中的索引条目写入所述多个层中的第一层。
在一个实施例中,所述多个层中的单个层以块索引表BIT为单位记录索引条目,单个BIT的叶节点对应一个或多个索引条目,单个非叶节点保存其子节点中各个索引条目对应数据块的LBA范围及分别针对各个子节点进行认证加密保护的各个MAC认证码。
在一个实施例中,所述将第二内存表中的索引条目写入所述多个层中的第一层包括:遍历所述第二内存表中的LBA,生成各个BIT,其中,单个BIT对应所述第二内存表中连续的多个索引条目,且在BIT中所述多个索引条目按升序排列;按照各个BIT的完成顺序将其以追加写方式写入所述第一层。
在一个实施例中,单个BIT通过以下方式生成:根据单个叶节点对应的单个LBA范围,获取满足所述单个LBA范围的索引条目记录在所述单个叶节点;针对单个非叶节点,在其对应的叶节点记录完毕后,根据相应叶节点的LBA范围以及针对相应LBA范围内的索引条目进行认证加密保护的认证码MAC记录在该非叶节点。
在一个实施例中,所述安全日志中的各个日志条目以日志块的形式存储,各个日志块分别由相应的各个认证码MAC进行认证加密保护,且单个日志块的MAC被后一个日志块嵌入。
在一个实施例中,所述硬盘中还记载有HBA到LBA的映射的反向索引表,在将所述若干索引条目***基于日志结构合并树的安全索引的情况下,所述方法还包括:基于所述若干索引条目更新所述反向索引表。
在一个实施例中,所述磁盘还记录有通过位图描述各个数据段是否有效的第一段有效性表SVT,以及描述数据段中各个数据块是否有效的数据段表DST,所述方法还包括:在将各个密文数据块以追加写方式持久化于所述硬盘的情况下,更新所述第一段有效性表和所述数据段表DST。
在一个实施例中,在所述磁盘中还存储有通过位图描述各个块索引表BIT是否有效的第二段有效性表SVT,所述方法还包括:在各个层的块索引表可依次向后面的层中合并或者将第二内存表中的索引条目写入所述多个层中的第一层的情况下,更新所述第二段有效性表。
根据第二方面,提供一种日志结构的安全数据存储装置,用于保护可信执行环境中用户对不可信硬盘的块I/O操作;所述装置设于可信执行环境,包括:
数据存储单元,配置为将用户提交的若干数据块分别进行加密得到相应的各个密文数据块,并将各个密文数据块以追加写方式持久化于所述硬盘;
索引生成单元,配置为为各个密文数据块分别生成相应的各个索引条目,其中,单个索引条目用于定位和保护一个密文数据块;
索引存储单元,配置为将各个索引条目分别***基于日志结构合并树的安全索引,所述安全索引持久化在所述硬盘;
日志生成单元,配置为为所述密文数据块生成若干日志条目,所述日志条目用于在发生***崩溃的情况下定位和保护对应的密文数据块,单个日志条目对应一个或多个密文数据块;
日志存储单元,配置为将所述若干日志条目追加写入所述硬盘的安全日志中,所述安全日志持久化在所述硬盘。
根据第三方面,提供了一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行第一方面的方法。
根据第四方面,提供了一种计算设备,包括存储器和处理器,其特征在于,所述存储
器中存储有可执行代码,所述处理器执行所述可执行代码时,实现第一方面的方法。
通过本说明书实施例提供的基于日志结构(log-structured)的安全数据存储方法和装置,可以经由安全区域可信执行环境针对硬盘进行数据的安全操作。该数据操作基于以下三种逻辑数据结构进行:可进行写/读/检索等操作的数据块;安全索引;安全日志。其中,数据块以密文形式通过追加写方式写入硬盘;安全索引为针对各个密文数据块生成各个索引条目以日志合并树结构建立的索引;安全日志用于以追加写方式记录向硬盘写入数据块或索引条目的操作信息。
一方面,通过TEE接收待写入硬盘的数据块,将数据块以追加写的方式写入硬盘。另一方面,为密文数据段中的各个密文数据块生成索引条目,并将索引条目硬盘***基于日志结构合并树的安全索引,且安全索引可以以加密方式持久化在硬盘。再一方面,为写入硬盘的密文数据块生成日志条目,并将日志条目追加写入硬盘的安全日志中,安全日志以加密方式持久化在硬盘,以便在崩溃等情形下恢复相关索引条目硬盘。该方式对数据块的记录采用追加写方式(区别于修改或覆盖旧版本数据),使用的日志结构合并树可以优先检索到新版本数据对应的索引条目(无需修改历史索引条目),从而可以在数据保密的基础上减少写放大,提高TEE利用非安全保护的硬盘存储数据的有效性。
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1示出本说明书一个实施场景示意图;
图2示出常规技术中一个具体例子的由TEE向硬盘写入数据的实时架构示意图;
图3示出根据本说明书技术构思的一个具体例子的由TEE向硬盘写入数据的实施架构示意图;
图4示出常规技术中LSM-tree的架构示意图;
图5示出本说明书技术构思中改进的LSM-tree的架构示意图;
图6示出本说明书提供的BIT逻辑架构一个具体例子的示意图;
图7示出根据一个实施例的日志结构的安全数据存储方法流程图;
图8示出根据图6示出的具体例子中的BIT结构以追加写方式在硬盘中的存储示意
图;
图9示出一个具体例子中实现本说明书技术构思的硬盘分区架构示意图;
图10示出根据一个实施例的日志结构的安全数据存储装置的示意性框图。
下面结合附图,对本说明书提供的技术方案进行描述。
首先介绍本说明书可能涉及的几个专业术语:
TEE:可信执行环境Trusted Execution Environments的缩写,也可以记为TEEs,提供了一个与REE(Rich Execution Environment,设备通用环境)隔离的可信环境,给数据和代码的执行提供一个更安全的空间,并保证它们的机密性和完整性,通常,通过TEE可以直接获取设备其他区域的信息,而其他区域不能获取TEE中的信息;
LSM-trees:日志结构合并树Log-Structured Merge Trees的缩写,其中的数据以追加写形式进行记录,以在日志中存放永久性数据及其索引,每次都添加到日志的末尾,使得对于文件***的大多数存取都是顺序性的,从而提高硬盘带宽利用率,故障恢复速度快(详细参考https://www.cnblogs.com/siegfang/archive/2013/01/12/lsm-tree.html等的记载);
MHT:Merkle Hash Trees,或记为MHTs,Merkle散列树,在Merkle散列树中,每个父节点中的数据都是其子节点中数据的哈希函数,叶节点中的数据是原子数据块的哈希值(详细参考https://zhuanlan.zhihu.com/p/474938589等的记载);
MAC:Message Authentication Code的缩写,信息认证码,本说明书也可以将其简称为认证码,通常用于认证加密保护,其可以是在密钥的控制下将任意长的消息映射到的简短的定长数据分组,并可以附加在相应消息后(如可以参考https://blog.csdn.net/feierxiaoyezi/article/details/51132063?locationNum=12等的记载)。
图1示出了本说明书的一个具体的适用场景。在图1示出的场景中,涉及可信执行环境,以及非可信硬盘。在可信执行环境TEE中运行有一个或多个应用(APPs),应用运行过程中产生各种文件数据。这些文件数据需要实时记录。但由于TEE通常使用的是内存空间,且空间有限,因此需要通过TEE中的安全块设备(Secure Block Device)将APPs产生的数据记录在TEE外部不可信的硬盘中。
其中,安全块设备是通过集成到TEE中的软件或硬件设备,以在TEE运行时来保护TEE的文件I/O的模块。安全块设备可以透明地保护来自文件I/O堆栈的所有块I/O。通过这种方式,TEE的其他部分可以在允许遗留文件I/O堆栈(包括为了在TEE内部使用不做
修改或只做少量修改的现有的文件***)的前提下,无需额外关注文件I/O的安全性。
安全块设备在图1中通过加粗的线框表示,其作为本说明书讨论的技术方案的执行主体,可以实现以下三种功能:
读,如read(LBA,nblocks,buf),表示从nblocks块的LBA地址开始,将数据从硬盘读入缓冲区buf;
写,如write(LBA,nblocks,buf),表示从nblocks块的LBA地址开始,将数据从缓冲区buf写入硬盘;
刷新,如flush(),确保所有更新的数据都保存到硬盘中。
具体而言,APPs可以调用文件I/O接口将其运行过程中产生的文件I/O块(以下也可以称为数据块)转给TEE中的安全块设备,并由安全块设备转存到不可信的硬盘。APPs需要的文件I/O,可以调用文件I/O接口经由安全块设备从硬盘读取并返回。
所有写入安全块设备或从安全块设备读取的数据都是明文。安全块设备的责任是适当地加密/解密传输到硬盘或从硬盘传输的数据。为了区分可信安全块设备和不可信硬盘上的块地址,可以将APPs向安全块设备提交数据时携带的数据标识称为逻辑块地址(LBA),安全块设备将数据存入硬盘的存储地址称为主机块地址(HBA),或称为物理地址。
由于硬盘是不可信的,假设有一个攻击者,拥有控制主机上TEE之外的任何硬件和软件的特权,并可以在TEE的整个生命周期中选择的任何时间进行攻击,切具有篡改(不仅仅是监测)硬盘的任何I/O请求和响应的能力。则具体来说,该攻击者可能进行的攻击类别包括但不限于:窥探攻击(监测I/O)、篡改攻击(伪造块)、回滚攻击(重放旧块)等等。
为了对抗这样的攻击者,安全块设备必须至少为其块接口提供以下安全保证:机密性,是指任何写操作提交的用户数据不被泄露;完整性,保证从任何读取返回的用户数据都是由用户真正生成的;新鲜度,确保从任何读取返回的用户数据是最新更新的;一致性(或崩溃一致性),无论有任何意外或恶意的崩溃,所有的安全保证仍然有效。
为了实现这些安全目标,常规技术例如有英特尔SGX的保护文件***(SGX-PFS)、Asylo、Graphene-SGX、Occlum、SecureFs等等将数据安全写入硬盘的技术方案。
以SGX-PFS为例,其基于file的概念,将每个file视为一个安全块设备,并采用就地更新(inplace update)和Merkle散列树(MHT)相结合的方法。下面结合图2的示意描述一个SGX PFS的开放文件是如何工作的。SGX PFS文件可以由三个关键组件组成:MHT(实现安全性)、缓存(实现高效率)和恢复日志(实现一致性)。在MHT中,存储在硬盘上的每个节点都受到经过认证加密的保护,认证加密保护即基于加密密钥key和基于认证加密保护
的认证码MAC的保护。叶节点包含文件数据,而非叶节点维护其子节点的加密密钥Key和认证码MAC。MHT确保文件数据的机密性、完整性和新鲜度。为了避免每次读取或写入都进行硬盘I/O,该文件可为最近使用的节点提供固定大小的内存缓存。在将脏节点刷新到硬盘之前,脏节点的最新有效版本保存在恢复日志中。这样,如果在刷新期间发生任何崩溃,通过恢复日志可以将文件恢复到其最后的有效且一致的状态。
参考图2所示的数据存储架构,SGX-PFS引入了一定的写入放大,进而可能引起随机写性能较差。其中,写入放大可以通过用户待写入的数据量与实际写数据量的比较确定,例如为实际写数据量与待写入数据量的比值。SGX-PFS写入放大主要有两个来源:MHT和恢复日志。在MHT中,对叶节点的更新会触发其所有父节点中的级联更新。这意味着,对于足够大的文件,随机写入的放大系数高达H,其中H是MHT的深度。此外,为了保证崩溃一致性,数据通常被写入两次:在旧版本被保存到恢复日志之后,新版本被写入MHT叶节点。如图2中阴影部分表示写入数据D2涉及的写入内容。因此,在最坏的情况下,SGX-PFS最大可导致2×H的放大系数。
针对常规技术中的写放大问题,本说明书提出一种新的安全块设备(如称为SwornDisk)结构化方案,以减少写入放大,提高随机写入的性能。如前所述,该可信执行环境中的安全块设备可以向硬盘安全地进行写入数据、读数据、查询数据等操作。其中,可信执行环境TEE也可以经由其他安全区域或安全环境代替,在此不再赘述。
图3示出了本说明书的一个具体实施架构。在本说明书的技术构思下,提出一种基于追加写数据结构的(log-structured)数据存储方式。如图3所示,本说明书提出的数据存储方式分为三个层次:加密数据块、安全索引、安全日志。
首先,以追加写(log)方式将加密的、受MAC认证加密保护的用户数据块写入硬盘。通常,不管是硬盘和还是固态硬盘,顺序写入对存储介质更友好。因此,追加写方式写入的数据块可以最大限度地提高底层硬盘的原始性能。另外,由于追加写方式允许新旧版本的逻辑数据块共存,因此这种方式记录的数据还有助于崩溃恢复。
其次,维护一个安全索引,将LBA映射到HBA(主机块地址,或称为物理地址,表示数据块在硬盘中实际存储的地址)、加密密钥key和信息认证码MAC,以便定位和保护加密的数据块。该索引被实现为一个特殊设计的、日志结构合并树(LSM-tree)的安全变体。其可以在传统LSM-tree基础上进行特殊的设计,以便于更安全有效地更新和查询索引。
第三,引入一个安全日志(Journal),记录所有最近的硬盘更新,包括对数据、索引以及其他硬盘数据结构方面的更新。安全日志中的日志条目以追加写的方式(log-structured)
写入硬盘。安全日志是确保一致性和原子性以及其他安全属性的关键。
其中,图3示出的结构中使用了日志结构合并树LSM的变体,使数据写入的写放大减小,并确保索引安全性。下面先对LSM-tree的原理进行描述。
LSM-tree的基本逻辑是一个多层结构,且上小下大,形似一棵树。LSM-tree的基本结构首先是内存的第一层通常保存所有最近写入的键值对(K-v),同时,内存中的数据结构是有序的,并可以随时原地更新(如以log方式增加数据),同时支持随时查询。其他各层都可以保存在硬盘上,每一层的数据都可以基于键值对中的键K有序排列的。在写入数据时,针对一个键值对的写入操作请求,可以追加写到之前的键值对记录(Write Ahead Log)中,然后添加到内存的第一层。当第一层的数据占据空间达到一定大小(如4兆字节等),就把第一层向硬盘的第二层合并,类似归并排序,将相同的键合并,这个过程就是Compaction(合并)。以此类推,直到最后一层。合并出来的新的层会顺序写硬盘,替换掉原来的旧的层。每一层占据空间达到一定大小,会继续和下层合并。合并之后所有旧文件都可以删掉,留下新的。写入过程基本只用到了内存结构,Compaction可以后台异步完成,不阻塞写入。
这里,由于数据的写入可能重复,因此,新版本需要覆盖老版本。例如先写了(a=1),再写(a=233),那么233就意味着a记录的新版本。假如a记录的老版本1已经写入到最后一层,而第一层接收到新版本,则不管下面各层的文件是否存在老版本。下面各层的老版本的清理可以在合并的时候发生。在查询过程中,由于最新的数据在靠前的层,最旧的数据在靠后的层,所以查询过程是先查第一层,如果没有要查的键K,再查第二层,以此类推,逐层查询。当然,在查到的情况下,通常查到的是最新版本,可以结束查询。
图4示出了常规技术中在基本结构上改进的LSM-tree结构。参考图4所示,图4示出的LSM-tree被分成以下三种文件:(内存中)正常的接收写入请求的第一内存表(memtable);(内存中)不可修改的第二内存表(immutable memtable,不可变内存表);硬盘上的SStable(Sorted String Table,有序字符串表,可以简称SST)。其中,SST中有序的字符串就是数据的键K。值得说明的是,这里的第一内存表、第二内存表通过功能的不同进行命名,在第一内存表作为immutable memtable实现第二内存表功能的情况下可以切换为第二内存表。如图4所示SST共有k(k为大于0的整数)层,为下一层分配的总空间大小可以是上一层的N(如N=10)倍。各个分层按顺序依次可以记为第一层、第二层……第k层。
图4示出的架构中,在写入数据时,可以将数据块的键值对(K,v)形式的索引条目***到第一内存表中,在第一内存表写满的情况下,可以将该写满的第一内存表切换为不
可更改的immutable memtable,即第二内存表。另外,还可以新建一个第一内存表memtable接收新的写入数据。而转换后的immutable memtable第二内存表中的索引条目就可以被持久化到硬盘。这里持久化到硬盘可以是直接刷成第一层的SSTable文件,并不直接跟该层的文件合并。而当第一层的文件大小超过限定阈值(如8兆字节)的情况下,可以选择一个文件向下一层合并。并且,合并后保持每层都是总体有序。如此,每一层可以维护指定的文件个数,同时保证不让K重叠。也就是说把相同的K合并到同一个文件。因此在一层查找一个K,只需查找一个文件。
图4示出的架构通过文件组织数据,并以文件为单位查询数据,而在本说明书的实施架构下,只有数据块,而没有文件结构。因此,为了能够利用LSM-tree架构,需要构建没有文件***辅助的硬盘组件***。在本说明书中,基于数据块的特殊性,通过没有文件(File)的概念的新的结构单元组织索引信息。
考虑到数据块区别于File的“平面”结构,而本说明书中组织索引信息的结构单元则同时具有3种作用:硬盘管理、检索(query)以及安全保护,在本说明书中可以结合B+树的思想提出适应于数据块的结构单元,例如称为块索引表(Block Index Table,简称BIT)。如此,可以将图4中的SST File用新的结构单元BIT替换。如图5所示。该改进的LSM-tree例如可以称为Disk-Oriented Secure LSM-tree(面向硬盘的安全LSM树,简称dsLSM-tree)。
为了说明BIT的具体结构,图6示出了一个具体例子的BIT的逻辑视图。如图6所示,在一个BIT中,单个叶节点(如L0、L1、L2、L3等)可以包括一个或多个块索引记录的数组(如LBA——HBA,Key,MAC,其可以称为索引条目),该数组里的块索引记录可以按LBA的大小进行排序。根节点(如图6中表示为R)或其他内部节点(如图6中表示为I0、I1等),也可以统称为非叶节点,非叶节点通过保存其子节点的HBA定位其子节点,并利用所保存的其子节点的加密密钥和MAC保护子节点的安全。也就是说,各个节点整体对应有认证加密的密钥key和认证码MAC,且这些信息可以保存在其上级节点中。
具体而言,由于叶节点中的块索引数组按LBA大小顺序排序,因此非叶节点中的单个节点可以基于密文数据块的LBA大小划分区间。例如图6中,假设R节点通过2个LBA(如200、400)分割点划分出三个区间,例如分别为:小于等于200;201至400;大于400。节点I0例如对应区间小于等于200,其又通过2个LBA分割点(如20、100等)例对应3个叶节点L0、L1、L2。同时,单个叶节点的MAC可以存储在其所有上级节点中。可选地,一个叶节点可以写入多个索引条目。例如,一个叶节点的大小可以与一个数据块的大小一致(如为4kb),至多可以写入占满一个数据块数量的索引条目。
如图6的架构形式的结构单元作为改进的LSM-tree(即dsLSM-tree)的索引结构单元,这种设计可以满足安全块设备的需求,且利于就地更新,并具有更高的检索效率。
下面结合TEE中的用户数据经由安全块设备写入硬盘的过程,详细描述本说明书的技术构思。
图7示出本说明书一个实施例的日志结构的安全数据存储流程。该流程可以用于可信执行环境中向硬盘存储数据,并针对攻击者保障数据的安全。亦即,保护可信执行环境中用户对不可信硬盘的块I/O操作。其中,可信执行环境TEE可以替换为TEE之外的其他安全区域或可信区域,本说明书对此不做限定。该流程的执行主体可以设于可信执行环境中,如为图1中示出的安全块设备。该可信执行环境可以设于具有一定数据处理能力的任意计算机、设备或服务器。
图7示出的流程可以包括以下步骤:步骤701,将用户提交的若干数据块分别进行加密得到相应的各个密文数据块,并将各个密文数据块以追加写方式持久化于硬盘;步骤702,为上述密文数据块分别生成相应的各个索引条目,其中,单个索引条目用于定位和保护一个密文数据块;步骤703,将上述各个索引条目***基于日志结构合并树的安全索引,安全索引持久化在硬盘;步骤704,为上述密文数据块生成若干日志条目,日志条目用于在发生***崩溃的情况下定位和保护对应的密文数据块,单个日志条目对应一个或多个密文数据块;步骤705,将上述若干日志条目追加写入硬盘的安全日志中,安全日志持久化在硬盘。
图7示出的流程可以应用于将TEE中的应用数据写入外部硬盘的具体业务场景。在该场景下,TEE中的应用(APPs)可以将待写入的文件等打包成数据块的形式,并通过安全块设备以密文形式写入硬盘。
首先,在步骤701中,将用户提交的若干数据块分别进行加密得到相应的各个密文数据块,并将各个密文数据块以追加写方式持久化于硬盘。
其中,这里的用户可以表示TEE中的应用。用户一次可以提交一个或多个数据块。用户例如可以以写请求的方式提交这些数据块。如,用户提交的一个写请求为:write(LBA,nblocks,buf),LBA表示当前提交的若干个数据块的起始数据块的逻辑地址,nblocks表示当前提交的数据块数量,buf可以表示内存缓存。
在TEE中,数据块可以以明文形式存在。对于用户提交的若干数据块,可以在写入硬盘之前进行加密。具体地,首先针对各个明文数据块,分别生成加密密钥key并加密得到相应的密文数据块,然后将密文数据块以追加写(log)的方式写入硬盘。
根据一个可能的设计,可以对数据块采用数据段(Segment)的形式进行管理,并使用段作为追加写的单元。段可以是一组连续的块(blocks)。日志结构(log-structured)文件***以段的形式分配硬盘空间,可以使得包括日志记录(log)在内的几乎所有硬盘写入都是顺序的,从而最大限度地提高硬盘的原始I/O吞吐量。在本说明书的实施例中,数据块的默认大小例如是4千字节(4kb),数据段的默认大小例如是4兆字节(4Mb)
此时,接收到用户的数据块写请求后,可以按照追加写的方式将其写入内存缓存中的当前数据段。可以理解,TEE可以使用内存缓存数据,此时的数据仍处于可信保护状态。为了确保各个数据块按照追加写的方式顺序记录,可以采用整个数据段写入硬盘的方式,从而保证数据段中的数据块都是顺序写入的。因此,当前数据块可以先按顺序写入缓存中的当前数据段。缓存中的当前数据段可以是尚未被写满的数据段。例如当前数据段为[B0,B1],仅包含2个数据段B0和B1,在接收到以上写请求后,可以将数据块以追加写方式写入B2,B3,B4,B5,当前数据段更新为[B0,B1,B2,B3,B4,B5],并继续等待新的数据块写入。假设当前数据段已接近写满,例如写入B2,B3两个数据段后即写满,则后续数据段B4,B5写入新的当前数据段中。在可选的实施例中,数据块被写入缓存中的当前数据段,即可反馈已写入成功的信息,以减少用户(Apps)的等待时间。由于数据段中的数据块以追加写的方式记录,因此,对于当前段来说,其内部数据是按用户提交数据块的顺序存储的。
在以数据段为单位对写入硬盘的数据块进行管理的情况下,数据段可以在满足将数据段写入硬盘的第一条件的情况下,将整个数据段写入硬盘。在当前数据段满足将数据写入硬盘的第一条件时,TEE中的安全块设备可以将数据段中的各个数据块分别加密并按顺序写入硬盘。
在一个实施例中,第一条件例如可以是当前数据段被写满,如已写入1024个数据段,或剩余可容纳字节数小于一个数据块的大小等。可以理解,为了不占用TEE过多空间,在当前数据段被写满的情况下,可以及时将整段数据统一写入硬盘。
在另一个实施例中,数据记录条件例如是接收到刷新请求,则可以在收到刷新请求的情况下,将当前数据段写入硬盘。由于TEE的刷新可能清空缓存中的数据内容,因此,在接收到TEE所在设备的任何可能刷新安全区域的缓存的刷新请求时,都可以将当前数据段写入硬盘,避免数据丢失。
在又一个实施例中,业务数据更新频次不够频繁,比如业务数据量不太大,则还可以定时将当前数据段写入硬盘,以避免数据丢失或不能及时落盘。此时,第一条件例如可以
是与当前数据段达到在缓存中的预定时长。在其他实施例中,数据记录条件还可以是其他条件,在此不再赘述。
加密密钥和数据块可以是一一对应的。举例而言,假设一个数据段包括8个数据块[B0,B1,B2,B3,B4,B5,B6,B7],则在将数据段写入硬盘时,可以生成与各个数据块一一对应的各个密钥key0,key1,key2,key3,key4,key5,key6,key7。使用各个密钥对各个数据块一一对应加密,例如得到密文数据段可以为[E0,E1,E2,E3,E4,E5,E6,E7]。该密文数据段可以被写入硬盘,从而保护数据安全。各个数据块的密钥生成及加密过程可以在将数据块写入当前数据段之前进行,也可以在将当前数据段写入硬盘时进行,本说明书对此不做限定。
接着,经由步骤702,为上述密文数据块分别生成相应的各个索引条目。
可以理解,将数据块写入硬盘的目的是后续业务处理过程中使用。因此,在向硬盘写入密文数据段时,还需要考虑各个数据块查询所需的索引信息。在索引领域,通常采用键值对(本说明书可以记为K-v)方式记录数据,则一个索引条目可以对应一个K-v。索引通常通过键K构建,并可经由键获取相应的值(value或v)作为所检索到的数据。
在以数据块为单位的数据存储过程中,可以将数据块的逻辑地址LBA作为键K,而将主机块地址HBA、加密密钥key和认证加密保护的认证码MAC作为值value。如此,一个K-v对可以为LBA-(HBA,key,MAC)。其中,LBA是接收数据块时已知的逻辑地址,key是加密数据时生成的加密密钥,HBA是实际存储于硬盘中的主机块地址(也称为物理地址),MAC用于对数据块基于key进行认证加密进行验证的认证码。MAC例如可以是通过哈希方法针对加密的数据块确定的散列值。
在本说明书中,一条索引信息可以包括一个密文数据块的K-v数据,这样的一条索引信息可以称为索引条目。作为示例,假设当前写入磁盘的数据块包括第一数据块,第一数据块由第一密钥key1进行认证第一密文数据块及认证码MAC1。第一密文数据块可以由第一索引条目定位和保护,则第一索引条目可以包括第一数据块的逻辑地址LBA1以及在硬盘中存储的物理地址HBA1、第一密钥key1、认证码MAC1。
进一步地,通过步骤703,将上述各个索引条目分别***基于日志结构合并树的安全索引,安全索引持久化在硬盘。
可以理解,根据前文的描述,本说明书的索引机制是LSM的变体,并特别设计了以BIT为LSM索引单元的实施方案。在本说明书的技术构思下,在向硬盘写入密文数据块时,可以将针对密文数据块生成的索引条目***到第一内存表memtable中。其中,在memtable
中,各个索引条目可以按照写入硬盘的数据块的顺序进行排列。在memtable满足索引持久化的第二条件的情况下,可以将memtable切换为不可更改的immutable memtable,如记为第二内存表,以将其中的索引条目持久化到硬盘。
在可选的实施例中,为避免第一内存表中的索引条目还未持久化为BIT时***就崩溃,可在将数据写入到第一内存表时同时将索引条目追加写入到日志结果合并树对应的Log日志(如图5示出的硬盘中的Log日志)中。该Log日志中的索引条目可以在被持久化到硬盘时被清空。如此,可以保证硬盘针对dsLSM-tree的Log日志可以按顺序记录最新的索引条目。在第一内存表中的索引条目还未持久化为BIT时***就崩溃的情况下,可以根据硬盘中的Log日志恢复第一内存表。
根据本说明书的一些实现方式,一个BIT在逻辑上是图6示出的架构,而在硬盘中可以追加写的形式存在。硬盘中的索引条目可以以BIT为单位写入。在索引条目写入硬盘时,可以遍历不可更改的第二内存表,即immutable memtable,从而将各个索引条目按照对应的LBA大小,逐个对应记录在相应范围的叶节点,直至叶节点被写满。而一个中间节点的所有叶节点被写满,则可以记录该中间节点,最后记录根节点。在一些实施例中,为了认证加密的需求,可以设置BIT的节点大小与数据块的大小一致,例如均为4kB。
在可选的实现方式中,索引也可以以段的形式进行管理。如图8所示,一个BIT可以对应多个索引段。一个索引段(Index Segment)可以包含预设数量(图8示出的为4个,实践中可以是其他数量)的节点。在一个具体例子中,一个BIT的大小可以与一个数据段的大小一致。
假设图8是记录图6中的BIT逻辑结构的硬盘数据,一个叶节点可以记录2个索引条目,假设叶节点L1先被写满2个索引条目,则在索引段中先记录L1节点及其索引条目,然后叶节点L3被写满2个索引条目,则在索引段中记录L3节点及其索引条目。此时,由于中间节点I1的全部叶节点被写满,还可以在索引段中记录I1节点及其叶节点的相关信息,如其叶节点的MAC和LBA范围分割点等信息。之后,叶节点L0、L2依次被写满2个索引条目,则依次记录叶节点L0、L2、中间节点I0、根节点R中的相关索引信息。对索引分段有助于索引信息的管理。如图6所示,在BIT内部,各个索引条目按照LBA升序记录。而各个节点的索引信息按照各个节点被写满的顺序,以追加写的方式记录在索引段。一个索引段写满之后,可以将整个索引段写入磁盘中dsLSM-tree的第一层,直至根节点所在索引段被写入硬盘,一个BIT生成过程结束。单个BIT存储在硬盘上时同样可以由key和MAC认证加密保护,在此不再赘述。
在一个实施例中,前述的第二条件可以是接收到刷新(flush)请求。在另一个实施例中,前述的第二条件可以是接收到合并(compaction)请求。在将LSM-tree在内存中的索引条目写入硬盘时,可以创建BIT写入LSM-tree的第一层,各个键(LBA)被分区到不同的BIT中,同一个BIT中不存在相同的K,而不同的BIT可能存在相同的K。合并操作的本质是将不同BIT中相同的键K进行合并,因此BIT写入硬盘可以通过合并压缩被有效地构造和持久化。值得说明的是,dsLSMtree的合并压缩可以在满足一定条件的情况下进行,例如一层的BIT占满该层的预设空间等。
这种写入方式,可供检索时,从根节点到叶子节点,根据LBA值的大小依次查找相应范围,并通过MAC验证。举例而言,前文的例子中,要查找LBA为100的数据块,则首先在根节点R中查找相应范围小于等于200,通过根节点R中的MAC验证,确定其存在于相应的下级节点,则继续查找节点I0,通过对I0中的范围查找和MAC验证,得到叶节点L1中的块索引记录的数组如(HBA1,Key1,MAC1),经MAC1验证后,从主机块地址HBA1中取出相应数据块。相应数据块可以通过Key1解密。
在可选的实施例中,为了管理BIT,还可以引入块索引表目录(BITC)来记录BIT。BITC由多个BIT条目组成,每个BIT条目包含一个BIT的元数据,BIT的元数据例如可以包括BIT的ID、层级及其根节点的HBA、key和MAC,等等。此时,以上描述的LSM-tree可以由动态数量的BIT组成,BITC可以维护的BIT的数量随BIT变化。
另一方面,在步骤704中,为上述密文数据块生成若干日志条目。
这里,日志条目可以是写入安全日志的一条信息记录。单个日志条目可以对应一个或多个密文数据块。安全日志(Journal)可以对写入硬盘的数据段的写入信息进行记录,以供在***崩溃(crash,可包括***无法正常运作的各种状态,如宕机、掉电等情形)情况下恢复数据。具体地,日志条目用于在发生***崩溃的情况下仍可以定位和保护对应的密文数据块,其例如可以包括有关其相应的硬盘上更新的密码学信息(数据块的密钥key、验证数据MAC等)以及写入的数据块地址HBA等。也就是说,为密文数据块生成的日志条目,可以包括密文数据块的数据块地址HBA、密钥key、验证数据MAC等。生成日志条目过程中,可以针对单个密文数据块生成一个日志条目,也可以针对多个密文数据块生成日志条目,本说明书对此不做限定。
接着,在步骤705中,将上述若干日志条目追加写入硬盘的安全日志中。
日志条目同样可以以追加写的方式记录硬盘更新数据。由于安全日志Journal中的日志条目可以包括有关其相应的硬盘上更新的加密信息,从而保证更新的机密性、完整性和新
鲜度。
在可选的实现方式中,日志条目可以以块(如一个块为4KB)的形式存储,例如称为日志块。根据一些实施例,日志块在硬盘上可以被持久化为认证加密保护的链式块序列。具体而言,单个日志块的认证码MAC被后一个日志块嵌入,从而确保日志记录中各个块按存储顺序关联。这样,可以排除被攻击者伪造虚假操作历史误导的可能性。
根据一个实施例,单个日志块可以有两个MAC副本。第一个副本以明文形式和加密的日志块一起存储在硬盘上。为了提高I/O效率,日志块的大小可以被设置为小于常规块(如前文提到的4KB的普通数据块)的大小,以便日志块及其MAC可以容置于同一个常规块中。日志块的MAC的第二个副本可以由其下一个日志块存储,如前文描述的链式存储。这种方案可以验证每个日志块的完整性,更重要的是,验证整个安全日志的完整性。
根据一个可能的设计,在以上日志记录的基础上,安全日志还可以通过检查点包(checkpointing pack)设置,配合恢复(recovery)和提交(commitment),实现数据的一致性和原子性。其中,检查点包是为了回收日志区域的硬盘空间并加快恢复过程,定期将日志记录转换成的更紧凑的格式,即检查点checkpointing,从而更省空间。举例而言,检查点包(强调内容)可以包括时间戳、安全日志的头部和尾部位置,并可以存储BIT的元数据(如,块索引表类别BITC等)。为了保证崩溃一致性,可以在硬盘中保留两个检查点包,且都在检查点区域,以便其中至少有一个是有效的。在硬盘上保存检查点包后,可以在安全日志中写入一个检查点包记录,该记录引用新的检查点包。
通常,在针对新的硬盘初始连接或者***崩溃等情形下,可以进行硬盘的初始化。在初始化期间,可以从两个检查点包中挑选最近的一个,并从中读取安全日志的头、尾游标。进而,扫描安全日志开始恢复过程,以找到最后一个检查点包,并根据检查点包记录初始化TEE中的内存数据结构。从该最后一个检查点包开始,读取安全日志的其余部分,一次重现(redo)一条记录(对应一个日志条目),以便将TEE中的内存数据恢复到与硬盘中的安全日志的记录一致的状态。
在可选的实现方式中,检查点包可以记录HBA到LBA的映射的反向索引表。反向索引表RIT可以建立HBA到LBA的映射,与由BIT维护的安全索引(建立由LBA到HBA的映射)相反。RIT可以包含每个有效块的LBA。如此,查询RIT可以检索清理掉的数据块的LBA。查询RIT,就可以清理掉无效数据块。在数据以段的形式管理的情况下,RIT可以包含每个数据段中有效块的LBA,给定要清理的数据段,可以清理其中的无效块。
进一步地,在一个实施例中,反向索引表RIT是受加密保护(通过针对其生成的key
加密)的硬盘数据(可以没有MAC)。RIT需要加密,是因为其包含LBA的敏感信息,如果泄露敏感信息泄露,将不利于隐私保护。RIT提供的反向索引可以容易地用安全索引来验证,因此在没有完整性保护的情况下存储RIT是安全的。
其中,每个块或节点都可以用一个唯一的加密密钥key保护。在一个可选的实施例中,密钥key可以通过随机密钥生成器生成,例如为随机的16字节上的数值。数据块、BIT块及BIT节点(包括叶节点和非叶节点)的密钥可以是随机生成的,对于节点而言,其密钥可以由其“父”节点保存以供后续检索。在另一个实施例中,密钥key可以是确定性密钥。例如,日志块或RIT块的密钥可以通过确定性密钥导出函数来确定。该密钥导出函数的输入例如可以是密钥导出密钥(KDK)、序列号等。例如,日志块的KDK可以是TEE安全拥有的可信根密钥(可以预先安全可信地获取),序列号是日志块不断增加的逻辑ID。使用确定性密钥导出方式可以简化密钥管理,因为只需要保存KDK。
在I/O模式是日志记录的情况下,包含LBA的所有数据结构都在硬盘上加密,则可以确保LBA不会泄漏到安全区域(TEE)之外。这样可以满足安全区域向硬盘写数据的匿名性(Anonymity)。
在可选的实现方式中,以段的形式管理数据的情况下,检查点包还可以记录诸如段有效性表(Segment Validity Table,SVT)、数据段表(Data Segment Table,DST)之类的段的元数据。所谓段的元数据,可以是用来进行段的分配、释放、清理等的数据结构。其中,段的分配、释放通常是针对整个数据段(如对应4MB的空间)的使用情况,而段的清理是通过对段的部分数据进行处理的过程,例如将脏段的有效块迁移到新位置,同时丢弃无效块来回收脏段空间的过程。其中,脏段可以表示部分数据块有效,部分数据块无效的段。前文的反向索引表(Reverse Index Table,RIT)也可以作为段的元数据。
其中,SVT是一个位图,每一位对应一个段,该位上的数值表示一个段是否有效,例如1表示有效0表示无效等。通常,包含一些有效的数据块(其内容是有用的或更新到某个日期)的段是有效的。有效数据块简称有效块,无效数据块简称无效块。如果一个段既包含有效块又包含无效块,则可以认为该段是部分有效的。在可选的实施例中,可以设置两个SVT,一个用于管理数据段,一个用于管理索引段(BIT)。
数据段和索引段可以通过各自的SVT来分配。对于整个有效或无效的段而言,可以通过简单地更新SVT中的相应数值来释放。例如,索引段通常是整体使用的,因此可以通过更新索引段的SVT来释放。而数据段可能部分有效,因此,可能需要借助额外的数据结构(如DST、RIT)来清理。
可以理解,段清洗性能对于日志结构存储***的性能具有重要影响。在一个实施例中,为了最小化开销,可以采用前台和后台清理结合的方式进行段清理。前台(当前线程)和后台(另一个线程)两种清理方式分别采用两种清理选择策略:贪婪策略和成本-收益策略(cost-effective)。前台清理采用贪婪策略通过局部最优的方式可以将清理延迟降至最低,而后台清理则通过成本-收益策略强调全局效率。在另一个实施例中,当硬盘利用率较高时,可以从普通日志切换到线程日志,以减少用户可见的延迟。线程日志记录将新数据写入部分有效数据段的“孔”(例如替换无效数据块)中,而无需预先清理这些数据段。在又一个实施例中,可以支持多个日志记录头,也就是说,多个写操作同时进行。这样,不仅可以提高I/O并行性,还能够将热数据和冷数据分离到不同的数据段中。例如,热数据写入内存,冷数据写入硬盘。其中,热数据和冷数据基于数据热度(如I/O重复率)确定,数据热度可以通过写请求中附带的热度参数确定,通过用户数据确定热度参数从而进行热度估计。例如,文件***可以从文件***级元数据中估计块的热度。在可选的实施例中,以上优化策略还可以相互组合,从而可以有效地降低段清洗的成本。
DST可以包含单个数据段中每个数据块的元数据,例如块有效性位图(block validity bitmap)、修改时间戳等。其中,块有效性位图可以用于描述数据段中各个数据块的有效性。修改时间戳可以是数据段被修改的时间信息。利用DST提供的信息,可以通过使用贪婪试探法或成本效益分析(cost-benefit)来选择要清理的脏数据段。例如,根据时间戳确定记录时间与当前时间的间隔大于预定时间段,则认为相应数据块为脏数据。
下面描述从硬盘读(Read,检索)数据的过程。概括而言,为了满足从用户指定的LBA开始的指定块数的数据读取请求,可以从安全索引中检索。检索过程中,可以按照安全索引中的结构单元(如BIT)逐个进行检索,直到检索到相应的LBA停止。其中,在BIT中检索时,可以从根节点开始,基于根节点记录的相应LBA分割范围,从根节点获取其中的MAC信息,经验证MAC确定所要检索的LBA包含在该BIT的情况下,进一步检索根节点的下级节点,依次类推,直至检索到相应叶节点,取出该LBA对应的HBA、加密密钥key等信息。否则,在某个节点经验证MAC确定相应所要检索的LBA不包含在相应节点相应LBA范围内,则检索下一个BIT。然后,通过HBA从硬盘上的数据中读取并解密加密的密文数据块。在经过MAC验证完整性之后,可以得到相应的明文数据块。进而,可以将明文数据块安全地反馈给用户。
作为示例,假设要检索的LBA为200,第一个BIT的根节点记录的子节点数据中,左节点对应小于100的LBA范围,右节点对应大于100的LBA范围,则可以获取右节点对
应的key及MAC信息。经MAC验证,确定右节点对应的子节点不包含要检索的LBA=200。则可以接着检索第二个BIT。假设第二个BIT的根节点记录的子节点数据中,左节点对应小于300的LBA范围,右节点对应大于300的LBA范围。经MAC验证,所要检索的LBA可以匹配到根节点的子节点中的左节点,进一步经左节点中的子节点的MAC验证,匹配到叶节点C,则可以从叶节点C读取LBA=200对应的HBA等信息,从而通过该HBA信息从硬盘中的相应位置读取相应LBA=200对应的密文数据块,并经由相应加密密钥解密密文数据块得到相应的明文数据块。
值得说明的是,以上过程中的步骤702、步骤703中生成索引条目的过程和步骤704步骤705中生成日志条目的过程,作为针对密文数据块的不同操作,可以并行执行、调换顺序执行,本说明书对此不做限定。以上过程的执行主体可以设于TEE中(例如图1所称的安全块设备),因此在针对图7的描述过程中,所称的TEE执行的部分(除TEE中的Apps或用户外)均可以由该设于TEE中的执行主体执行。
图7实施例中的技术方案,由于基于追加写方式进行(新的数据写入时是以追加写方式记录而无需替换旧数据),并利用了基于日志结构合并树的安全索引(索引时新版本在旧版本之前检索到且无需修改历史索引条目)和安全日志,在向硬盘写入单个密文数据块时,附加数据仅为单个索引条目和至多一个日志条目(一个日志条目可以对应一个或多个密文数据块)。可以理解,索引条目和日志条目的数据量与密文数据块的数据量相比要小得多。因此,密文数据块的存储过程中,向硬盘安全写入数据块的大约I/O成本是单个数据块所包含数据量的(1+ε)倍:D(密文数据块+索引条目+日志条目)/D(密文数据块)=1+ε。其中,D表示数据量,ε为远小于1的数。与常规技术中的2×H(H>=2,如图2所示)小得多,也就是说,本说明书提供的通过安全区域向硬盘写入数据的方法,可以大大减少写入的数据量,即减少写放大。
综上,本说明书提供了一种日志结构的安全数据存储流程,通过TEE中的安全块设备(Secure Block Device)将数据写入非安全环境的硬盘。该数据存储流程基于追加写的方式进行,结合内存缓存和硬盘中安全索引、安全日志的数据记录机制,充分考虑对数据机密性、完整性、新鲜度和一致性的保护,还可以兼顾数据的匿名性和原子性,并有效降低数据的写放大,从而提高安全区域向硬盘写入数据的有效性。
为了更加明确本说明书提供的技术方案的具体应用,图9示出了一个具体例子中通过将硬盘划分多个存储区间实现图7的技术方案的示意图。
如图9所示,硬盘可以被初始化划分为5个存储区域,例如分别是:第一区域,在此
例如可以称为超级块区域(Superblock Region),用于存储硬盘的基本参数,例如各种数据的块的大小、段的大小以及其他区域在硬盘上的位置信息等,该区域所记载的信息通常较固定;第二区域,在此例如可以称为数据区(Data Region),用于以追加写方式记录用户的密文数据块;第三区域,在此例如可以称为索引区(Index Region),用于以追加写方式记录数据区域的加密数据块的索引信息;第四区域,在此例如可以称为日志区(Journal Region),其作为一个大型缓冲区,通常具有较大存储空间,用于存储安全日志;第五区域,在此例如称为检查点区(Checkpoint Region),用于存储可描述硬盘中各种数据状态的信息,例如安全日志的头尾位置、SVT、DST、RIT等等。
在向硬盘写入数据之前,TEE(如其中的安全块设备,下同)可以先对硬盘进行初始化,以将硬盘格式化为以上5个区域。可选地,针对索引区(第三区域),可以按照LSM树的结构进行初始化。
在TEE接收到数据的写请求的情况下,可以先在缓存的当前数据段中以追加写方式写入接收到的数据块,并向用户反馈写入成功的请求。直至满足数据段记录条件,将当前数据段写入图9中的第二区域。同时,一方面,可以为密文数据段中的各个密文数据块生成索引条目,单个索引条目例如可以包括单个密文数据块对应的LBA-(HBA,Key,MAC)。索引条目可以以追加写方式写入当前索引表(如memtable缓存索引表)中。另一方面,在第四区域的安全日志中,记录写入硬盘的各个数据块信息。必要时,可以修改第五区域的SVT、DST中与数据段(Data Segment)相关的信息。可选地,在将密文数据块写入硬盘的过程中,还可以查询SVT、DST中的有效性信息,从而可以向无效段或部分有效段的孔中,写入相应密文数据块。
在当前索引块满足索引记录条件的情况下,可以将当前索引表记录的索引条目写入硬盘的第三区域。其中,可以先将当前索引表memtable转换成不可修改的索引表(第二内存表),如immutable memtable,用于向硬盘第三区域的LSM树中合并。在不可修改的索引表中的数据项LSM树中合并时,先依次遍历不可修改的索引表中的索引条目,构建各个BIT单元,然后将BIT单元写入LSM树的第一层级。此时,一方面,可以在第四区域的日志记录中记录BIT单元写入硬盘的信息(如数据块对应的索引信息、BIT结构信息等),另一方面,还可以在第五区域记录块索引表类别BITC、修改与检索相关的SVT和DST中的相关内容,以及记录RIT等信息。
其中,向第四区域的安全日志中记录数据时,可以以日志块为数据单元进行记录。单个日志块可以包含一条或多条数据块、索引条目等待记录的信息,并对应有日志块认证标
识MAC。如此,日志块之间可以通过相邻块之间的MAC嵌入,保持链式结构,以免顺序错乱、攻击者对数据进行替换或者崩溃的数据恢复等。
在一些实施例中,如果数据块向硬盘提交之前发生崩溃,则未提交的数据可以被丢弃,从而保持数据记录的一致性。而索引表向硬盘提交之前发生崩溃,则安全区域可以通过第四区域的日志记录恢复当前索引表(如memtable表)。
图9示出的具体例子中,可以通过第三区域的LSM树的构建,确保用户数据的机密性、完整性和新鲜度,而第四区域的安全日志可以实现安全区域以及硬盘数据的一致性和原子性,而第五区域的RIT的加密机制,可以保障用户数据的匿名性。另外,在确保以上各种安全性能的基础上,本说明书提供的技术方案还可以大大减少写放大问题。
根据另一方面的实施例,还提供一种设于计算方的日志结构的安全数据存储装置。该装置可以用于保护可信执行环境中用户对不可信硬盘的块I/O操作。图10示出了一个实施例的日志结构的安全数据存储装置1000,可以设于TEE中,如为图1中的安全块设备。
如图10所示,装置1000包括:
数据存储单元1001,配置为将用户提交的若干数据块分别进行加密得到相应的各个密文数据块,并将各个密文数据块以追加写方式持久化于硬盘;
索引生成单元1002,配置为为各个密文数据块分别生成相应的各个索引条目,其中,单个索引条目用于定位和保护一个密文数据块;
索引存储单元1003,配置为将各个索引条目分别***基于日志结构合并树的安全索引,安全索引持久化在硬盘;
日志生成单元1004,配置为为密文数据块生成若干日志条目,日志条目用于在发生***崩溃的情况下定位和保护对应的密文数据块,单个日志条目对应一个或多个密文数据块;
日志存储单元1005,配置为将若干日志条目追加写入硬盘的安全日志中,安全日志持久化在硬盘。
值得说明的是,图10所示的装置1000是与图7描述的方法相对应,图7的方法实施例中的相应描述同样适用于装置1000,在此不再赘述。
根据另一方面的实施例,还提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行结合图7等所描述的方法。
根据再一方面的实施例,还提供一种计算设备,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现结合图7等所描述的方法。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本说明书实施例所描
述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
以上所描述的具体实施方式,对本说明书的技术构思的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所描述的仅为本说明书的技术构思的具体实施方式而已,并不用于限定本说明书的技术构思的保护范围,凡在本说明书实施例的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本说明书的技术构思的保护范围之内。
Claims (15)
- 一种日志结构的安全数据存储方法,用于保护可信执行环境中用户对不可信硬盘的块I/O操作;所述方法包括:将用户提交的若干数据块分别进行加密得到相应的各个密文数据块,并将各个密文数据块以追加写方式持久化于所述硬盘;为各个密文数据块分别生成相应的各个索引条目,其中,单个索引条目用于定位和保护一个密文数据块;将各个索引条目分别***基于日志结构合并树的安全索引,所述安全索引持久化在所述硬盘;为所述密文数据块生成若干日志条目,所述日志条目用于在发生***崩溃的情况下定位和保护对应的密文数据块,单个日志条目对应一个或多个密文数据块;将所述若干日志条目追加写入所述硬盘的安全日志中,所述安全日志持久化在所述硬盘。
- 如权利要求1所述的方法,其中,所述若干数据块包括第一数据块,针对所述第一数据块由第一密钥key1进行认证加密得到第一密文数据块及认证码MAC1,所述第一密文数据块由第一索引条目定位和保护,所述第一索引条目包括所述第一数据块的逻辑地址LBA1以及在硬盘中存储的物理地址HBA1、所述第一密钥key1和所述认证码MAC1。
- 如权利要求1所述的方法,其中,所述若干数据块是按用户提交顺序以追加写方式记录在内存中的当前数据段的多个数据块,所述将用户提交的若干数据块分别进行加密得到相应的各个密文数据块。
- 如权利要求3所述的方法,其中,在满足将数据段写入硬盘的第一条件的情况下,将各个密文数据块以追加写方式持久化于所述硬盘,所述第一条件包括以下中的至少一项:当前数据段被写满、接收到刷新请求、记录时长达到预定时长。
- 如权利要求1所述的方法,其中,所述日志结构合并树对应有第一内存表、第二内存表,以及硬盘中的多个层,所述第二内存表用于向所述多个层进行持久化,各个层的块索引表可依次向后面的层中合并,直至最后一层;所述将所述若干索引条目***基于日志结构合并树的安全索引包括:将所述若干索引条目***当前的第一内存表;在满足索引持久化的第二条件的情况下,将所述第一内存表转化为第二内存表,从而将第二内存表中的索引条目写入所述多个层中的第一层。
- 如权利要求5所述的方法,其中,所述多个层中的单个层以块索引表BIT为单位记录索引条目,单个BIT的叶节点对应一个或多个索引条目,单个非叶节点保存其子节点中各个索引条目对应数据块的LBA范围及分别针对各个子节点进行认证加密保护的各个MAC认证码。
- 如权利要求5所述的方法,其中,所述将第二内存表中的索引条目写入所述多个层中的第一层包括:遍历所述第二内存表中的LBA,生成各个BIT,其中,单个BIT对应所述第二内存表中连续的多个索引条目,且在BIT中所述多个索引条目按升序排列;按照各个BIT的完成顺序将其以追加写方式写入所述第一层。
- 如权利要求7所述的方法,其中,单个BIT通过以下方式生成:根据单个叶节点对应的单个LBA范围,获取满足所述单个LBA范围的索引条目记录在所述单个叶节点;针对单个非叶节点,在其对应的叶节点记录完毕后,根据相应叶节点的LBA范围以及针对相应LBA范围内的索引条目进行认证加密保护的认证码MAC记录在该非叶节点。
- 如权利要求1所述的方法,其中,所述安全日志中的各个日志条目以日志块的形式存储,各个日志块分别由相应的各个认证码MAC进行认证加密保护,且单个日志块的MAC被后一个日志块嵌入。
- 如权利要求1所述的方法,其中,所述硬盘中还记载有HBA到LBA的映射的反向索引表,在将所述若干索引条目***基于日志结构合并树的安全索引的情况下,所述方法还包括:基于所述若干索引条目更新所述反向索引表。
- 如权利要求3所述的方法,其中,所述磁盘还记录有通过位图描述各个数据段是否有效的第一段有效性表SVT,以及描述数据段中各个数据块是否有效的数据段表DST,所述方法还包括:在将各个密文数据块以追加写方式持久化于所述硬盘的情况下,更新所述第一段有效性表和所述数据段表DST。
- 如权利要求6所述的方法,其中,在所述磁盘中还存储有通过位图描述各个块索引表BIT是否有效的第二段有效性表SVT,所述方法还包括:在各个层的块索引表可依次向后面的层中合并或者将第二内存表中的索引条目写入所述多个层中的第一层的情况下,更新所述第二段有效性表。
- 一种日志结构的安全数据存储装置,用于保护可信执行环境中用户对不可信硬盘的块I/O操作;所述装置设于可信执行环境,包括:数据存储单元,配置为将用户提交的若干数据块分别进行加密得到相应的各个密文数据块,并将各个密文数据块以追加写方式持久化于所述硬盘;索引生成单元,配置为为各个密文数据块分别生成相应的各个索引条目,其中,单个索引条目用于定位和保护一个密文数据块;索引存储单元,配置为将各个索引条目分别***基于日志结构合并树的安全索引,所述安全索引持久化在所述硬盘;日志生成单元,配置为为所述密文数据块生成若干日志条目,所述日志条目用于在发生***崩溃的情况下定位和保护对应的密文数据块,单个日志条目对应一个或多个密文数据块;日志存储单元,配置为将所述若干日志条目追加写入所述硬盘的安全日志中,所述安全日志持久化在所述硬盘。
- 一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行权利要求1-12所述的方法。
- 一种计算设备,包括存储器和处理器,其特征在于,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现权利要求1-12所述的方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210520607.7 | 2022-05-13 | ||
CN202210520607.7A CN114817994A (zh) | 2022-05-13 | 2022-05-13 | 日志结构的安全数据存储方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023216783A1 true WO2023216783A1 (zh) | 2023-11-16 |
Family
ID=82516295
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2023/087004 WO2023216783A1 (zh) | 2022-05-13 | 2023-04-07 | 日志结构的安全数据存储方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN114817994A (zh) |
WO (1) | WO2023216783A1 (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114817994A (zh) * | 2022-05-13 | 2022-07-29 | 支付宝(杭州)信息技术有限公司 | 日志结构的安全数据存储方法及装置 |
CN115374127B (zh) * | 2022-10-21 | 2023-04-28 | 北京奥星贝斯科技有限公司 | 数据存储方法及装置 |
CN117056245B (zh) * | 2023-08-18 | 2024-02-23 | 武汉麓谷科技有限公司 | 一种基于zns固态硬盘的面向日志记录应用的数据组织方法 |
CN118069069B (zh) * | 2024-04-17 | 2024-06-21 | 联想凌拓科技有限公司 | 一种数据存储方法及装置、存储介质、计算机程序产品 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160378653A1 (en) * | 2015-06-25 | 2016-12-29 | Vmware, Inc. | Log-structured b-tree for handling random writes |
CN111295649A (zh) * | 2019-09-12 | 2020-06-16 | 阿里巴巴集团控股有限公司 | 日志结构存储*** |
CN111886591A (zh) * | 2019-09-12 | 2020-11-03 | 创新先进技术有限公司 | 日志结构存储*** |
CN114356877A (zh) * | 2021-12-30 | 2022-04-15 | 山东浪潮科学研究院有限公司 | 一种基于持久内存的日志结构合并树分级存储方法及*** |
CN114817994A (zh) * | 2022-05-13 | 2022-07-29 | 支付宝(杭州)信息技术有限公司 | 日志结构的安全数据存储方法及装置 |
-
2022
- 2022-05-13 CN CN202210520607.7A patent/CN114817994A/zh active Pending
-
2023
- 2023-04-07 WO PCT/CN2023/087004 patent/WO2023216783A1/zh unknown
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160378653A1 (en) * | 2015-06-25 | 2016-12-29 | Vmware, Inc. | Log-structured b-tree for handling random writes |
CN111295649A (zh) * | 2019-09-12 | 2020-06-16 | 阿里巴巴集团控股有限公司 | 日志结构存储*** |
CN111886591A (zh) * | 2019-09-12 | 2020-11-03 | 创新先进技术有限公司 | 日志结构存储*** |
CN114356877A (zh) * | 2021-12-30 | 2022-04-15 | 山东浪潮科学研究院有限公司 | 一种基于持久内存的日志结构合并树分级存储方法及*** |
CN114817994A (zh) * | 2022-05-13 | 2022-07-29 | 支付宝(杭州)信息技术有限公司 | 日志结构的安全数据存储方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN114817994A (zh) | 2022-07-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2023216783A1 (zh) | 日志结构的安全数据存储方法及装置 | |
US11139959B2 (en) | Stream ciphers for digital storage encryption | |
US10129222B2 (en) | Trusted storage systems and methods | |
Huang et al. | Flashguard: Leveraging intrinsic flash properties to defend against encryption ransomware | |
Gibson et al. | Filesystem for Network-attached Secure Disks | |
TWI737395B (zh) | 日誌結構儲存系統及方法 | |
US9619160B2 (en) | NVRAM data organization using self-describing entities for predictable recovery after power-loss | |
US7152165B1 (en) | Trusted storage systems and methods | |
TWI733514B (zh) | 儲存系統、區塊鏈網路的網路節點以及基於區塊鏈的日誌結構儲存系統 | |
US8086585B1 (en) | Access control to block storage devices for a shared disk based file system | |
US8892905B2 (en) | Method and apparatus for performing selective encryption/decryption in a data storage system | |
TW202117529A (zh) | 日誌結構儲存系統 | |
TW202111585A (zh) | 日誌結構儲存系統 | |
TW202113580A (zh) | 日誌結構儲存系統 | |
US20110283113A1 (en) | Method and system for encrypting data | |
CN112889054A (zh) | 多租户数据库管理***中数据库加密的***和方法 | |
Sinha et al. | Veritasdb: High throughput key-value store with integrity | |
Allalouf et al. | Block storage listener for detecting file-level intrusions | |
KR102668409B1 (ko) | 로그 구조 병합 트리를 이용하는 키 밸류 스토어를 위한 보안 컴퓨터 장치 및 방법 | |
Tian et al. | Loco-store: Locality-based oblivious data storage | |
Mullen | CapsuleDB: A Secure Key-Value Store for the Global Data Plane | |
Zhang et al. | Scalable crash consistency for secure persistent memory | |
Tian et al. | LETUS: A Log-Structured Efficient Trusted Universal BlockChain Storage | |
CN117763636A (zh) | 数据写入方法,恢复方法,读取方法以及对应装置 | |
Gibson et al. | Filesystems for Network-Attached Secure Disks (CMU-CS-97-118) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 23802559 Country of ref document: EP Kind code of ref document: A1 |