A knowledge graph secret state storage method based on secret computing and searchable encryption

Abstract

The application discloses a knowledge graph secret state storage method based on confidential calculation and searchable encryption, and the method comprises the following steps: taking a non-native attribute graph as a data model of a knowledge graph, and converting the attribute graph model into a KV model; based on the KV model, a dynamic searchable encryption algorithm is used to construct a secret state index of attributes; based on the confidential calculation, a LevelDB key value storage engine is safely optimized according to the constructed secret state index of the attributes, and the KV data storage engine service is provided through the optimized LevelDB key value storage engine. The application can effectively avoid the influence of the encryption operation on the functionality of the knowledge graph data, and can also make security guarantee on the confidentiality, integrity and freshness of the knowledge graph data, so as to guarantee the functionality and security of the knowledge graph data outsourced to a cloud service provider.

Description

Technical Field

[0001] This invention relates to the field of data encryption technology, and in particular to a method for storing encrypted knowledge graphs based on confidential computing and searchable encryption. Background Technology

[0002] In recent years, with the rapid development of cloud computing and cloud-native technologies, data migration to the cloud has gradually become a mainstream trend, and knowledge graph data is no exception. Cloud service providers offer storage infrastructure to store and manage user data on cloud platforms, thereby providing elastic, stable, and reliable data services. However, the fact that cloud service providers can transparently steal user data from cloud platforms has become a major concern for users migrating their data to the cloud. Many encrypted database solutions exist, employing algorithms such as nondeterministic encryption, searchable encryption, homomorphic encryption, and order-preserving encryption, and using corresponding model mechanisms to encrypt database data, while supporting corresponding data services within encrypted databases. However, encrypted storage solutions built using these encryption algorithms often require a trusted proxy server, as shown in the attached... Figure 1 The CryptDB encrypted database architecture shown here increases the system's Trusted Computing Base (TCB). Furthermore, since users and cloud servers need to transmit data to a proxy server for encryption and decryption, the network communication and encryption / decryption computations involved significantly impact system performance. Although homomorphic encryption, searchable encryption, and order-preserving encryption algorithms can retain some data functionality, they still cause encrypted data to lose much of its functionality. Therefore, existing encrypted storage solutions based solely on encryption schemes suffer from problems such as an excessively large Trusted Computing Base, weak data functionality, and low read / write efficiency.

[0003] Currently, there are two main knowledge graph data models: RDF graph models and attribute graph models. In an RDF graph, edges can act as attribute predicates pointing to attribute values, and all attribute values ​​are stored as nodes. This provides greater flexibility for graph computation on knowledge graphs. RDF graph models can be stored using relational databases or native RDF graph databases (such as gStore). While storing the graph using existing encrypted relational database solutions (such as CryptDB) is theoretically possible, the query operations of the graph itself require a large number of joins on the relational database. Encrypted relational storage solutions have poor performance in join operations, making the use of encrypted relational databases for storage impractical. Attribute graphs are represented by a set of nodes, edges, attributes, and labels. Data vertices and their edges are named with unique IDs and can store attributes represented by key-value (KV) pairs. In the previously disclosed patent "Storage Construction and Retrieval Method of Encrypted Knowledge Graph for Protecting Data Confidentiality", the encrypted storage of the knowledge graph is achieved solely based on searchable encryption. The data model used is a non-native attribute graph model, and a key-value storage engine is used to store the final encoded graph data. This scheme can perform one-hop subgraph queries and graph walks with a high efficiency of tens of milliseconds on average. However, it still has the problems of excessively large trusted computing base and weak data functionality described above.

[0004] Confidential computing is an important method for protecting the security of data in use and code running in memory. It utilizes a hardware-based trusted execution environment (TEE) to protect the data. A TEE is typically defined as a hardware environment that provides a certain level of data integrity, data confidentiality, and code integrity guarantees. Searchable encryption technology combines search and encryption techniques, enabling the construction of encrypted indexes that support retrieval based on provided encrypted index trapdoors. Summary of the Invention

[0005] In view of this, the present invention provides a knowledge graph encrypted storage method based on confidential computing and searchable encryption, which ensures the confidentiality and integrity of knowledge graph data, supports unique indexing for attributes, and does not disclose the content of the original encrypted data during the retrieval process, thus achieving a good data security protection effect.

[0006] This invention discloses a method for storing encrypted knowledge graphs based on confidential computation and searchable encryption, comprising the following steps:

[0007] Step 1: Use the non-native attribute graph as the data model for the knowledge graph, and transform the attribute graph model into a key-value (KV) model;

[0008] Step 2: Based on the KV model, construct the encrypted index of attributes using a dynamic searchable encryption algorithm;

[0009] Step 3: Based on the constructed attribute encrypted index, perform security optimization on the LevelDB key-value storage engine using confidential computation, and provide KV data storage engine services through the optimized LevelDB key-value storage engine.

[0010] Further, step 1 includes:

[0011] Each vertex is encoded as a key-value pair, and each edge is encoded as a key-value pair, separating the content of the edge attributes into a separate key-value pair;

[0012] In retrieving attribute graph data, prefix matching using type || vertexID allows us to read all outgoing and incoming edges corresponding to a vertex; using type || vertexID || edgeType allows us to read edges of any specific type and direction corresponding to a vertex. Here, type is an enumeration indicating the type of KV data; vertexID is the vertex ID; edgeType is an enumeration indicating the edge type, with the first byte indicating the edge direction.

[0013] Further, step 2 includes:

[0014] Within the trusted memory space provided by confidential computing, a cryptographic index is constructed based on a dynamic searchable encryption algorithm to support cryptographic retrieval of attributes.

[0015] The process of constructing the cryptographic index based on the dynamic searchable encryption algorithm is as follows:

[0016] Perform the following operations in the trusted memory space provided by the TEE:

[0017] The keyword and key are used as inputs to a pseudo-random function to generate keys K1 and K2. K1 and the count value c are used as inputs to a PRF to generate a tag l. K2 is used as the key to perform symmetric encryption on the id corresponding to the keyword to generate encrypted data d. Finally, (l, d) is treated as a KV pair and written to disk using the LevelDB key-value storage engine.

[0018] Furthermore, the process of dense-state retrieval of attributes is as follows:

[0019] In the trusted memory space provided by TEE, the following operations are performed: the key and key are used as input to PRF to generate a pair of trapdoors, and the generated trapdoors are sent to the index service running in untrusted memory;

[0020] The encrypted index service takes K1 and the count value c as input to the PRF, generates a label l, retrieves encrypted data d from the LevelDB key-value store engine, decrypts it using K2, and finally obtains the id corresponding to the keyword.

[0021] Further, step 3 includes:

[0022] After the non-native attribute graph is encoded into key-value data, all key-value data will be stored in the LevelDB storage engine, which is optimized for security based on confidential computing. Through the secure memory area provided by the TEE, the write cache, write-ahead log and metadata log, persistent storage file and read cache of the LevelDB storage engine are optimized for security.

[0023] Furthermore, the security-optimized write cache structure separates the Value portion of the KV into untrusted memory and performs symmetric encryption on each Value; while the SkipList structure stored in the trusted memory area uses hash pointers to perform integrity checks on the Value portion stored outside the trusted area; replay attacks on untrusted memory can be detected after hash verification.

[0024] Furthermore, the process of security optimization for the log entries in the write-ahead log is as follows:

[0025] The hash value of each log entry is generated by taking the hash value of the previous entry and the current log data content as input.

[0026] The hash value of the latest log entry is stored in a trusted memory area, thus forming a hash chain. The root hash value is then sent to a trusted backend service asynchronously for persistent storage.

[0027] For each log entry, in addition to calculating its hash value, the calculated hash value is also encrypted along with the log content.

[0028] The metadata log file stores the metadata of the LevelDB key-value storage engine. It records data in a full + incremental manner, with the first record being the full record and subsequent records being incremental records, in order to record the internal maintenance status of the LevelDB key-value storage engine.

[0029] Furthermore, the process of obtaining the structure of the security-optimized persistent storage file is as follows:

[0030] The contents of each Data Block and Index Block are hashed, and the resulting hash value is appended to the original file structure. The persistent storage file is then encrypted using a symmetric encryption algorithm, and the encrypted content is stored on disk. Finally, the entire persistent storage file that needs to be written to disk is hashed, and the generated hash value is persistently stored in a security-optimized metadata log file.

[0031] Furthermore, the optimized hash value of each of the persistent storage files is cached in memory;

[0032] Persistent storage files use incrementally increasing numerical numbers as filenames. A prefix tree is constructed for the filenames of each level of persistent storage files. In Ethereum, the Merkle Patricia Tree structure of its state tree is a combination of a hash tree and a prefix tree.

[0033] For each layer of persistent storage file, a Merkle Patricia Tree is constructed in untrusted memory, the root hash value is stored in a trusted memory area, and the integrity of the persistent storage file is checked by using the hash value of the persistent storage file cached by the Merkle Patricia Tree.

[0034] Furthermore, the security-optimized read cache structure is divided into a first-level cache and a second-level cache; the second-level cache is an SSTable cache, where each Data Block is encrypted and stored in untrusted memory, while the trusted memory stores pointers to the encrypted Data Blocks, Bloom filters, Index Blocks, and hashes of each Data Block;

[0035] The first-level cache is a cache for plaintext data blocks, stored in a trusted memory area. Both the first-level and second-level caches are organized in an LRU-Cache manner. The second-level cache uses the filename as the key, while the first-level cache uses the hash value of the data block as the key.

[0036] Due to the adoption of the above technical solution, the present invention has the following advantages: The encrypted knowledge graph solution of the present invention effectively avoids the impact of encryption operations on the functionality of knowledge graph data, and can also provide security guarantees for the confidentiality, integrity and freshness of knowledge graph data, thereby ensuring the functionality and security of knowledge graph data outsourced to cloud service providers. Attached Figure Description

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

[0038] Figure 1 This is a schematic diagram of a CryptDB encrypted database architecture in the prior art;

[0039] Figure 2 This is a schematic diagram illustrating the workflow of a secure routing table query method based on secure multi-party computation according to an embodiment of the present invention.

[0040] Figure 3 This is a schematic diagram of a key-value representation of a non-native attribute graph according to an embodiment of the present invention;

[0041] Figure 4 This is a schematic diagram of a process for constructing and retrieving a unique index based on dynamic searchable encryption, according to an embodiment of the present invention.

[0042] Figure 5 This is a schematic diagram of a security-optimized Memtable structure according to an embodiment of the present invention;

[0043] Figure 6 This is a schematic diagram of a security-optimized WAL or MANIFEST log entry structure according to an embodiment of the present invention;

[0044] Figure 7 This is a schematic diagram of a security-optimized SSTable file structure according to an embodiment of the present invention;

[0045] Figure 8 This is a schematic diagram illustrating an example of constructing a prefix tree for SSTable filenames according to an embodiment of the present invention;

[0046] Figure 9 This is a schematic diagram of a Merkle Patricia tree hierarchy for caching SSTable hash values ​​according to an embodiment of the present invention.

[0047] Figure 10 This is a schematic diagram of a security-optimized LevelDB read cache structure according to an embodiment of the present invention;

[0048] Figure 11 This is a schematic diagram of an integrity verification chain for an SSTable and a Data Block according to an embodiment of the present invention;

[0049] Figure 12 This is a flowchart illustrating a method for storing a knowledge graph in a confidential state based on confidential computing and searchable encryption, according to an embodiment of the present invention. Detailed Implementation

[0050] The present invention will be further described in conjunction with the accompanying drawings and embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art should fall within the protection scope of the present invention.

[0051] The overall framework diagram of the knowledge graph-based encrypted storage method proposed in this embodiment, which is based on confidential computing and searchable encrypted storage, is attached. Figure 2 As shown, the entire system has three parties: the user, the backend service, and the cloud server. The user and backend service are trusted parties, while the cloud server is untrusted. However, the trusted memory area provided by the TEE within the cloud service is secure and reliable. Some interfaces providing backend services to the user will call the graph interface layer, thereby triggering updates or reads of the graph.

[0052] As attached Figure 12 As shown, the method for storing encrypted knowledge graphs based on confidential computation and searchable encryption includes the following steps:

[0053] S1. Use non-native attribute graphs as the data model for the knowledge graph, and transform the attribute graph model into a key-value (KV) model.

[0054] Non-native attribute graphs are stored as non-graph models during data storage organization. The attribute graph model can be transformed into a key-value (KV) model representation before actual persistent storage. An attribute graph is represented by a set of nodes, edges, attributes, and labels. Data vertices and their edges are named with unique IDs, and each vertex and edge can store attributes represented by key-value pairs. This paper proposes a novel KV representation scheme for non-native attribute graphs, as shown in the appendix. Figure 3As shown, in each key-value pair, the first field of the key is the `type` field, which is an enumeration representing all possible data types in the scheme. The meaning of each field in the key of the attribute graph data is shown in Table 1. Each vertex is encoded as a key-value pair, and its vertex ID is rendered meaningless. Having a meaningful vertex ID would cause several problems. A meaningful field indicates the possibility of being updated, and updating the vertex ID would require updating the corresponding vertex edge data, and even the index data, simultaneously. Furthermore, meaningful fields are usually of variable length, and storing multiple copies of the vertex ID in its corresponding edge data would waste space. Each edge is encoded as three key-value pairs. In this design, the content of the edge attributes is separated into an independent key-value pair, alleviating the storage space waste caused by each edge needing to be encoded as two key-value pairs. In retrieving attribute graph data, prefix matching using type || vertexID can retrieve all outgoing and incoming edges corresponding to a vertex, while edge matching using type || vertexID || edgeType can retrieve edges of a specific type and direction corresponding to a vertex.

[0055] Table 1. Meaning of each field in the Key field of a non-native attribute graph KV representation.

[0056]

[0057] S2. Based on the KV model, a dynamic searchable encryption algorithm is used to construct a cryptographic index of attributes.

[0058] To support the construction of unique indexes for attributes in non-native attribute graphs while ensuring data confidentiality, this solution constructs a encrypted index based on a dynamically searchable encryption algorithm within the trusted memory space provided by confidential computing. This index supports encrypted retrieval of attributes, and the construction and retrieval process is detailed in the appendix. Figure 4 As shown.

[0059] During the index construction process, the following operations are first performed in the trusted memory space provided by the TEE (such as the enclave memory space of SGX): the key and key are used as inputs to a pseudo-random function to generate keys K1 and K2, and K1 and the count value c are used as inputs to the PRF to generate a tag l. K2 is used as the key to perform symmetric encryption on the id corresponding to the key to generate encrypted data d. Finally, (l, d) is treated as a KV pair and written to disk through the LevelDB key-value storage engine (non-security optimized LevelDB).

[0060] During the retrieval process, the following operations are first performed in the trusted memory space provided by the TEE (such as the enclave memory space of SGX): The keyword and key are used as inputs to the PRF to generate a trapdoor pair, which is then sent to the index service running in untrusted memory. The encrypted index service uses K1 and the count value c as inputs to the PRF to generate a tag l, retrieves encrypted data d from LevelDB, decrypts it using K2, and finally obtains the ID corresponding to the keyword. Since this project uses meaningless IDs, no information about the encrypted knowledge graph data is leaked.

[0061] S3. Based on the encrypted index of the constructed attributes, perform security optimization on the LevelDB key-value storage engine using confidential computation, and provide KV data storage engine services through the optimized LevelDB key-value storage engine.

[0062] After the non-native attribute graph is encoded into key-value (KV) data, all KV data will be stored in the LevelDB storage engine, which is optimized for security based on confidential computing. This invention utilizes the secure memory area provided by the TEE to perform security optimizations on LevelDB's write cache (Memtable), write-ahead log (WAL), metadata log (MANIFEST), persistent storage file (SSTable), and read cache (LRU-Cache) to ensure data confidentiality, integrity, and freshness. In the following scheme description, all encryption and decryption operations are performed in the trusted memory space, which by default uses the enclave memory area provided by SGX.

[0063] (1) Security optimization of LevelDB's write cache (Memtable)

[0064] Memtable is essentially a SkipList structure that supports querying and adding data in log(n) time complexity. Its functionality is similar to a red-black tree, but its implementation is simpler. (See attached image) Figure 5 The diagram shows the security-optimized Memtable structure. It separates the Value portion of the key-value pair into untrusted memory and performs symmetric encryption on each Value to ensure the confidentiality of the Value data. The SkipList structure stored in the trusted memory area uses hash pointers to perform integrity checks on the Value portion stored outside the trusted area. Since attackers cannot enter the trusted memory area to modify the hash value, a replay attack on the untrusted memory can actually be detected after hash verification, thus ensuring the freshness of the data.

[0065] (2) Security optimization of LevelDB's WAL and MANIFEST files

[0066] Write-Ahead Log (WAL) is a common technique in database systems used to ensure the atomicity and durability of data operations. In LevelDB, the MANIFEST file stores LevelDB metadata, recording data using a full + incremental approach. The first entry is a full entry, and subsequent entries are incremental entries, thus recording the internal maintenance status of LevelDB. The data organization in the MANIFEST file is the same as that in the WAL, meaning that the same methods used to optimize the WAL can be applied to ensure data security. The security optimizations for WAL log entries in this invention are attached. Figure 6 As shown, the hash value of each log entry is generated by taking the hash value of the previous entry and the current log data content as input. The hash value of the latest log entry is stored in a trusted memory area (such as the enclave memory of SGX), thus forming a hash chain. The root hash value is sent asynchronously to a trusted backend service for persistent storage. Since the hash value stored in the trusted memory area is secure, it can be used to verify the integrity of all log entries. Because attackers cannot tamper with the root hash value in the enclave memory, it can be used to prevent replay attacks on WAL content, thereby ensuring the freshness of WAL. For each log entry, in addition to calculating its hash value, the calculated hash value is also encrypted along with the log content to ensure data confidentiality when log entries are stored in untrusted disk space.

[0067] (3) Security optimization of LevelDB's SSTable files

[0068] SSTable files are used to store persistent LevelDB data. Internally, they consist of multiple blocks. The Data Block contains ordered key-value data. The Filter Block contains a Bloom filter that quickly determines if a searched key is not present in the current SSTable file. The Meta Index Block stores the BlockHandle of the Filter Block; the BlockHandle is equivalent to a file pointer, consisting of the block size and file offset. The Index Block stores the BlockHandle of the Data Block, and the Footer stores the BlockHandles of the Meta Index Block and the Filter Block. (See attached file.) Figure 7The diagram shows the security-optimized SSTable file structure. First, the content of each DataBlock and Index Block is hashed, and the resulting hash value is appended to the original file structure. Since the SSTable is stored in untrusted disk space, the Data Block and Index Block will display the stored data; therefore, they need to be encrypted using a symmetric encryption algorithm before being stored on disk. Finally, the entire SSTable file that needs to be written to disk is hashed, and the generated hash value is persistently stored in the security-optimized MANIFEST file to protect its confidentiality, integrity, and freshness.

[0069] Because reading the security-optimized SSTable files requires a complete integrity check of the entire file, the hash value of each file needs to be cached in memory to speed up this process. However, when the number of SSTable files is large, directly storing this cache in trusted memory would put pressure on trusted memory, potentially leading to insufficient trusted memory. Therefore, it was decided to store this part of the data in an untrusted memory area, which necessitates a special mechanism to ensure the security of this data. Since it stores hash values, the stored knowledge graph data will not be leaked, so only the integrity and freshness of this data need to be guaranteed. (See attached image) Figure 8 As shown, since SSTable files use incrementally increasing numerical filenames, a prefix tree can be constructed for each level of SSTable filenames. In Ethereum, its state tree Merkle Patricia Tree structure is a combination of a hash tree and a prefix tree. (See attached image.) Figure 9 As shown, this invention constructs a Merkle Patricia Tree in untrusted memory for each level of SSTable file, and stores the root hash value in a trusted memory area. This allows the integrity and freshness of the Merkle Patricia Tree in untrusted memory to be verified. Then, the integrity of the SSTable file is verified by using the hash value of the SSTable file cached by the Merkle Patricia Tree.

[0070] (4) Security optimization of LevelDB's LRU-Cache

[0071] LevelDB's cache uses an LRU-Cache mechanism, which is essentially a hash linked list. The cache unit is the entire SSTable file, and a multi-sharding mechanism is used to reduce cache contention. Due to the limited trusted memory space, the original caching mechanism cannot be used; that is, the cache stored in trusted memory cannot be the entire SSTable file. This invention optimizes the read cache of LevelDB for security. The optimized structure is shown in the attached figure. Figure 10 As shown, this scheme divides the cache into two layers. The second-level cache is an SSTable cache. Each Data Block is encrypted and stored in untrusted memory, while the trusted memory stores pointers to the encrypted Data Blocks, Bloom filters, Index Blocks, and hashes of each Data Block. To avoid frequent encryption and decryption during data reads, a first-level cache is designed. The first-level cache is a cache of plaintext Data Blocks, stored in the trusted memory area. Each Data Block in LevelDB is approximately 4KB, much smaller than an SSTable (2MB). All caches are organized using an LRU-Cache approach. The second-level cache uses the filename as the key, and the first-level cache uses the Data Block's hash value as the key.

[0072] The verification chain for the SSTable file and its internal Data Blocks is now complete, as shown in the appendix. Figure 11 As shown, based on the trusted memory region and trusted backend service provided by TEE, integrity checks are performed on each data type downwards.

[0073] In terms of functionality, this invention decentralizes encrypted operations to the underlying LevelDB storage engine, while the security-optimized LevelDB provides a complete set of interfaces. Therefore, all the functions achievable by existing non-native attribute graph databases based on KV storage can be implemented in this invention. In terms of security, this invention, through the security-optimized LevelDB key-value storage engine, ensures the confidentiality, integrity, and freshness of knowledge graph data. Regarding confidentiality, it ensures that data in untrusted memory and disk will not appear in plaintext, preventing knowledge graph data leakage. Regarding integrity, it uses trusted memory provided by TEE and trusted backend services as trusted bases to verify the integrity of data stored in untrusted memory and disk space, thus verifying whether the data has been tampered with. Regarding freshness, by storing the latest hash value in a trusted memory area or on a trusted backend service server, it prevents hash value tampering. If an attacker replays the original data, the hash value can be used to verify the integrity of the replayed data, thereby ensuring data freshness.

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for storing encrypted knowledge graphs based on confidential computing and searchable encryption, characterized in that, Includes the following steps: Step 1: Use the non-native attribute graph as the data model for the knowledge graph, and transform the attribute graph model into a key-value (KV) model; Step 2: Based on the KV model, construct the encrypted index of attributes using a dynamic searchable encryption algorithm; Step 3: Based on the encrypted index of the constructed attributes, perform security optimization on the LevelDB key-value storage engine using confidential computation, and provide KV data storage engine services through the optimized LevelDB key-value storage engine; Step 2 includes: Within the trusted memory space provided by confidential computing, a cryptographic index is constructed based on a dynamic searchable encryption algorithm to support cryptographic retrieval of attributes. The process of constructing the cryptographic index based on the dynamic searchable encryption algorithm is as follows: Perform the following operations in the trusted memory space provided by the TEE: The keyword and key are used as inputs to a pseudo-random function to generate keys K1 and K2. K1 and the count value c are used as inputs to the PRF to generate a tag l. K2 is used as the key to perform symmetric encryption on the id corresponding to the keyword to generate encrypted data d. Finally, (l, d) is treated as a KV pair and written to disk through the LevelDB key-value storage engine. The process of dense-state retrieval of attributes is as follows: In the trusted memory space provided by TEE, the following operations are performed: the key and key are used as input to PRF to generate a pair of trapdoors, and the generated trapdoors are sent to the index service running in untrusted memory; The encrypted index service takes K1 and the count value c as input to the PRF, generates a label l, retrieves encrypted data d from the LevelDB key-value store engine, decrypts it using K2, and finally obtains the id corresponding to the keyword.

2. The method of claim 1, wherein, Step 1 includes: Each vertex is encoded as a key-value pair, and each edge is encoded as a key-value pair, separating the content of the edge attributes into a separate key-value pair; In retrieving attribute graph data, prefix matching using type || vertexID allows us to read all outgoing and incoming edges corresponding to a vertex; using type || vertexID || edgeType allows us to read edges of any specific type and direction corresponding to a vertex. Here, type is an enumeration indicating the type of KV data; vertexID is the vertex ID; edgeType is an enumeration indicating the edge type, with the first byte indicating the edge direction.

3. The method of claim 1, wherein, Step 3 includes: After the non-native attribute graph is encoded into key-value data, all key-value data will be stored in the LevelDB storage engine, which is optimized for security based on confidential computing. Through the secure memory area provided by the TEE, the write cache, write-ahead log and metadata log files, persistent storage files, and read cache of the LevelDB storage engine are optimized for security.

4. The method of claim 3, wherein, The security-optimized write cache structure separates the Value portion of the KV data from untrusted memory and performs symmetric encryption on each Value. The SkipList structure stored in the trusted memory region uses hash pointers, which can perform integrity checks on the Value part stored outside the trusted region; A replay attack on untrusted memory can be detected by hash verification.

5. The method of claim 3, wherein, The process of security optimization for the log entries in the write-ahead log is as follows: The hash value of each log entry is generated by taking the hash value of the previous entry and the current log data content as input. The hash value of the latest log entry is stored in a trusted memory area, thus forming a hash chain. The root hash value is then sent to a trusted backend service asynchronously for persistent storage. For each log entry, in addition to calculating its hash value, the calculated hash value is also encrypted along with the log content. The metadata log file stores the metadata of the LevelDB key-value storage engine. It records data in a full + incremental manner, with the first record being the full record and subsequent records being incremental records, in order to record the internal maintenance status of the LevelDB key-value storage engine.

6. The method of claim 3, wherein, The process of obtaining the security-optimized persistent storage file structure is as follows: The contents of each Data Block and Index Block are hashed, and the resulting hash value is appended to the original file structure. The persistent storage file is then encrypted using a symmetric encryption algorithm, and the encrypted content is stored on disk. Finally, the entire persistent storage file that needs to be written to disk is hashed, and the generated hash value is persistently stored in a security-optimized metadata log file.

7. The method of claim 6, wherein, The optimized hash value of each of the persistent storage files is cached in memory; Persistent storage files use incrementally increasing numerical numbers as filenames. A prefix tree is constructed for the filenames of each level of persistent storage files. In Ethereum, the Merkle Patricia Tree structure of its state tree is a combination of a hash tree and a prefix tree. For each layer of persistent storage file, a Merkle Patricia Tree is constructed in untrusted memory, the root hash value is stored in a trusted memory area, and the integrity of the persistent storage file is checked by using the hash value of the persistent storage file cached by the Merkle Patricia Tree.

8. The method of claim 3, wherein, The security-optimized read cache structure is divided into a first-level cache and a second-level cache. The second-level cache is an SSTable cache. Each Data Block is encrypted and stored in untrusted memory, while the trusted memory stores pointers to the encrypted Data Blocks, Bloom filters, Index Blocks, and hashes of each Data Block. The first-level cache is a cache for plaintext data blocks, stored in a trusted memory area. Both the first-level and second-level caches are organized in an LRU-Cache manner. The second-level cache uses the filename as the key, while the first-level cache uses the hash value of the data block as the key.

Images