A Trusted Source Tracing Method for Cloud Data Operation Behavior

Abstract

This invention discloses a trusted tracing method for cloud data operation behavior, comprising the following steps: setting hook points at the user's resource objects and critical paths of command execution to collect cloud data operation event information and obtain cloud data tracing logs; extracting log summaries and related metadata from the tracing logs, storing the log summaries and related metadata on a blockchain ledger, and proposing an on-chain data storage mechanism based on the Merkle mountain algorithm to support fine-grained and batch verification of the integrity of the tracing logs; constructing a cloud data tracing model, providing a tracing mechanism combining a super blockchain ledger and ELK Stack technology, and ensuring the trustworthiness of the tracing logs based on the Merkle mountain algorithm and the tracing log set while implementing identity verification services, and based on this, providing a DAG-based behavior accountability tracing method.

Description

Technical Field

[0001] This invention relates to the field of big data traceability, and in particular to a reliable traceability method for cloud data operation behavior. Background Technology

[0002] In the era of big data, the rapid development of cloud computing has solved the problem of limited local resources for users. More and more users and enterprises are choosing to store their data assets on cloud servers to fully enjoy the on-demand resource allocation services provided by cloud service providers. While massive amounts of data are uploaded from local storage to public cloud servers by users and enterprises, data security has become a major concern, especially in untrusted network environments where data leaks, tampering, and loss are frequent, compromising the authenticity and reliability of data. Data traceability is one of the effective solutions to these problems. Data traceability refers to the management of data processing flows, addressing the questions of why data is in a certain state (why), where it comes from (where), and how it was obtained (how). To ensure data security, researchers have proposed using access log recording, auditing, and tracing user behavior to guarantee accountability for security incidents. However, existing research has not focused on the reliability of traceability data. In real-world intrusions, "traceability" is a crucial means of concealment for attackers. Dishonest cloud service providers or hackers, after gaining control of a user's system, often target log files for tampering. Therefore, achieving reliable data traceability remains a significant challenge.

[0003] In cloud service scenarios, user data frequently flows between clients and server hosts. Data tracing technology faces three main challenges: 1) The data flow process is difficult to trace. Data sharing and usage often involve multiple parties, making the data transfer process complex and ownership difficult to define, leading to undetected security incidents such as information leaks and tampering; 2) Centralized data tracing mechanisms lack credibility. Most existing tracing technologies are based on centralized architectures, with a single cloud service provider responsible for log storage and analysis. This results in information asymmetry between the data owner and the service provider during the tracing process, creating trust issues; 3) The security of tracing logs cannot be guaranteed. As the source of information for tracing and evidence collection, log files are a primary target for intruders. When stored and transmitted in an untrusted network environment, they face the risk of malicious deletion and tampering, directly affecting the results of data tracing.

[0004] Blockchain, with its distributed, fault-tolerant, and immutable characteristics, along with its trustworthy mechanism that requires no third-party endorsement, holds immense application potential in the field of data traceability. Through its distributed ledger and consensus mechanism, blockchain ensures the integrity and immutability of traceability data. Furthermore, relying on transaction timestamps and endorsement signatures, it irrefutably records user actions. However, the data query and analysis functions currently provided by blockchain are relatively simple, and the retrieval of large-scale data is inefficient, making it unable to independently support trusted data traceability. Summary of the Invention

[0005] The purpose of this invention is to propose a highly efficient, consortium blockchain-based trusted cloud data traceability mechanism, CBCProv, aiming to provide users with secure and reliable data traceability services and achieve data supervision in an uncontrolled cloud environment. Consortium blockchains are the key technology behind CBCProv. As a branch of blockchain, consortium blockchains have an access control mechanism, where users' business permissions are bound to their identities, thus describing them as a decentralized permission-restricted environment. This invention proposes to address the three stages of data acquisition, storage, and reconstruction, using a consortium blockchain to ensure the trustworthiness of various participants in the cloud data traceability process, thereby providing trusted traceability services without the need for a central authority.

[0006] To achieve the above objectives, this invention provides a trusted tracing method for cloud data operation behavior, comprising the following steps:

[0007] Hook points are set based on user resource objects and critical paths of command execution to collect cloud data operation event information and obtain cloud data traceability logs.

[0008] Extract log summaries and related metadata from the traceability logs, and store the log summaries and related metadata on the blockchain ledger to support the integrity verification of the traceability log set;

[0009] By using a data storage mechanism based on the Merkle Mountains, log summaries are stored on-chain to support fine-grained and batch verification of the integrity of off-chain traceability logs.

[0010] A data traceability model for the cloud data is constructed to obtain a traceability mechanism that combines the super blockchain ledger and ELK Stack technology. This mechanism is used to ensure the credibility of the traceability logs through the Merkle mountain algorithm and traceability log set while implementing identity verification services, thereby obtaining a DAG-based behavior accountability and traceability method.

[0011] Optionally, based on the hook point, the parameters and environment of the system call function of the system event are extracted to obtain the source log. Through server listening and storage overhead, event reconstruction based on the source log is supported. The hook point is divided into three categories according to the resource object: file, process and communication.

[0012] Optionally, based on the LSM system event capture mechanism of the Linux security module and the hook point, the traceability log is constructed by focusing on three types of objects: user cloud storage data, communication network, and blockchain network configuration files.

[0013] Optionally, the blockchain ledger is controlled to conduct transactions, and the log summary and related metadata are recorded. The blockchain ledger includes multiple distributed blockchain ledgers, which are obtained based on the HLF channel mechanism, and the data between each distributed blockchain ledger is isolated.

[0014] Optionally, the traceability logs are stored using an Elasticsearch-based DLD. When verifying the integrity of the received log files, the DLD Client in the corresponding channel is used to query the on-chain blockchain ledger data and determine whether the off-chain log files have been tampered with based on the returned results.

[0015] Optionally, the source tracing log is converted to JSON format to obtain a source tracing log file;

[0016] Based on the collection time and incrementing sequence number of the source tracing log, a combined sequence number field is obtained;

[0017] The source tracing log set is constructed based on the source tracing log file and the combined sequence number field.

[0018] Optionally, the upload time, uploader identifier, uploader signature public key, and hash value of the source tracing log set are extracted to construct upload information;

[0019] Based on the upload time and the uploader identifier, chaincode and consensus algorithm are invoked to generate transaction blocks for transactions between the blockchain ledger and the traceability log. During the invocation of chaincode and consensus algorithm, at least timestamp information is added.

[0020] Optionally, based on the algorithm structure of the Merkle mountain algorithm, the source tracing log set is aggregated to construct a source tracing log summary storage model;

[0021] Based on the Merkle mountain algorithm update log summary data, Merkle root data, and SPV proof set, a proof verification model is constructed.

[0022] Based on the source tracing log summary storage model, a proof snapshot is constructed; based on the source tracing log summary storage model, the proof verification model, and the proof snapshot, the source tracing log verification model is constructed.

[0023] Optionally, the Merkle mountain algorithm is traversed to extract the node coordinates of the leaf nodes of the source log summary storage model, thereby obtaining the first sub-hash tree to the left of the leaf node, the second sub-hash tree where the leaf node is located, and the third sub-hash tree to the right of the leaf node.

[0024] The SPV proof set is constructed based on the first sub-hash tree, the second sub-hash tree, and the third sub-hash tree.

[0025] Optionally, the earliest time-series log of the cloud data can be extracted as vertex data;

[0026] Initialize the data tracing model and the cloud data;

[0027] Add the vertex data to the data tracing model and mark the vertex data as accessed;

[0028] Extract the flow events that connect the cloud data to the data tracing model, mark the system logs corresponding to the flow events as logs to be added, determine whether the flow events are the vertex data, and trace the source of the cloud data based on the determination result and the data tracing model.

[0029] The present invention has the following technical effects:

[0030] The method proposed in this invention provides users with a secure and reliable data traceability service, enabling data supervision in an uncontrolled cloud environment. This mechanism combines a super blockchain ledger with ELK Stack technology, providing identity verification services while simultaneously achieving decentralized traceability log integrity verification. Through the proposed on-chain data storage mechanism based on the Merkel Mountains, fine-grained and batch verification of off-chain log integrity is achieved. Experimental tests demonstrate that CBCProv can achieve efficient and reliable data traceability within the system's load-bearing capacity. Attached Figure Description

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

[0032] Figure 1 This is a flowchart illustrating the method described in this application;

[0033] Figure 2 This is a schematic diagram of the CBCProv system architecture described in this application;

[0034] Figure 3 This is a schematic diagram illustrating the CBCProv business process described in this application;

[0035] Figure 4 This is a schematic diagram of the LSM-based system event capture mechanism described in this application;

[0036] Figure 5 This is a schematic diagram of the log storage and retrieval mechanism that combines on-chain and off-chain operations as described in this application;

[0037] Figure 6 This is a schematic diagram of the traceability log upload process described in this application;

[0038] Figure 7 This is a schematic diagram of the log summary structure based on the Merkle tree described in this application;

[0039] Figure 8 This is a schematic diagram of the MMR-based log summary structure described in this application;

[0040] Figure 9 This is a schematic diagram of the user-oriented MMR structure described in this application;

[0041] Figure 10a This is a schematic diagram of the MMR-based log digest update algorithm described in this application;

[0042] Figure 10b This is a schematic diagram of the Merkle root generation algorithm based on MMR described in this application;

[0043] Figure 10c This is a schematic diagram of the SPV proof set generation algorithm based on MMR described in this application;

[0044] Figure 11 This is a schematic diagram of the data source map construction algorithm described in this application;

[0045] Figure 12 This is a schematic diagram illustrating the source of the Alice.txt leak incident described in this application. Detailed Implementation

[0046] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] Combination Figure 1-12 As shown, the technical solution provided by the present invention will be described in detail. (Reference) Figure 1 The diagram shows a flowchart of a trusted tracing method for cloud data operation behavior provided by the present invention. The present invention discloses a trusted tracing method for cloud data operation behavior, comprising the following steps:

[0048] Hook points are set based on the user's resource objects and the critical paths of executed commands to collect operation event information of cloud data and obtain traceability logs of cloud data.

[0049] Extract log summaries and related metadata from the traceability logs, and store the log summaries and related metadata on the blockchain ledger to support the integrity verification of the traceability log set.

[0050] By using a data storage mechanism based on the Merkle Mountains, log summaries are stored on-chain to support fine-grained and batch verification of the integrity of off-chain traceability logs.

[0051] A data traceability model for the cloud data is constructed to obtain a traceability mechanism that combines the super blockchain ledger and ELK Stack technology. This mechanism is used to ensure the credibility of the traceability logs through the Merkle mountain algorithm and traceability log set while implementing identity verification services, thereby obtaining a DAG-based behavior accountability traceability method.

[0052] It should be noted that ELK is an acronym for Elasticsearch, Logstash, and Kibana. In one embodiment of this invention, based on hook points, the parameters and environment of system call functions for system events are extracted to obtain source logs. With relatively low server listening and storage overhead, event reconstruction based on source logs is supported. Hook points are categorized into three types based on resource objects: files, processes, and communication.

[0053] In one embodiment of the present invention, the LSM system event capture mechanism and hook points based on the Linux security module are used to construct a traceability log by focusing on three types of objects: user cloud storage data, communication network, and blockchain network configuration files.

[0054] In one embodiment of the present invention, the blockchain ledger is controlled to conduct transactions and record log summaries and related metadata. The blockchain ledger includes multiple distributed blockchain ledgers, which are obtained based on the HLF channel mechanism, and the data between each distributed blockchain ledger is isolated.

[0055] In one embodiment of the present invention, a DLD (Distributed Log Database) based on Elasticsearch (ES, Distributed Full-Text Search) stores traceability logs. When verifying the integrity of the received log files, the DLD Client in the corresponding channel queries the on-chain blockchain ledger data and determines whether the off-chain log files have been tampered with based on the returned results.

[0056] In one embodiment of the present invention, the source tracing log is converted to JSON (JavaScript Object Notation) format to obtain a source tracing log file; a combined sequence number field is obtained based on the collection time and incrementing sequence number of the source tracing log; and a source tracing log set is constructed based on the source tracing log file and the combined sequence number field.

[0057] In one embodiment of the present invention, the upload time, uploader identifier, uploader signature public key, and hash value of the traceability log set are extracted to construct upload information; based on the upload time and uploader identifier, chaincode and consensus algorithm are invoked to generate transaction blocks for transactions between the blockchain ledger and the traceability log, wherein at least timestamp information is added during the invocation of chaincode and consensus algorithm.

[0058] In one embodiment of the present invention, based on the algorithm structure of the Merkle mountain algorithm, the source log set is aggregated to construct a source log summary storage model; based on the Merkle mountain algorithm update log summary data, Merkle root data, and SPV (Simplified Payment Verification) proof set, a proof verification model is constructed; based on the source log summary storage model, a proof snapshot is constructed; and based on the source log summary storage model, the proof verification model, and the proof snapshot, a source log validation model is constructed.

[0059] In one embodiment of the present invention, the Merkle mountain algorithm is traversed to extract the node coordinates of the leaf nodes of the source log summary storage model, and the first sub-hash tree to the left of the leaf node, the second sub-hash tree where the leaf node is located, and the third sub-hash tree to the right of the leaf node are obtained; based on the first sub-hash tree, the second sub-hash tree, and the third sub-hash tree, the SPV proof set is constructed.

[0060] In one embodiment of the present invention, the earliest time-series log of cloud data is extracted as vertex data; the data tracing model and cloud data are initialized; the vertex data is added to the data tracing model and marked as accessed; the flow events connected to the cloud data and the data tracing model are extracted, the system logs corresponding to the flow events are marked as logs to be added, it is determined whether the flow events are vertex data, and the cloud data is traced based on the determination result and the data tracing model.

[0061] Data traceability mechanism for cloud data:

[0062] Log auditing, as one of the accountability and tracing mechanisms for various information systems, can analyze and discover system security issues and conduct source tracing and evidence collection. By capturing and recording operational events on servers and clients, it is an important way to understand the history of user data flow and analyze user behavior characteristics. Especially when security incidents such as tampering, loss, and leakage of critical data occur, source tracing and auditing through historical logs is an important means of discovering security risks, tracing attackers, and collecting evidence of illegal activities.

[0063] The CBCProv mechanism proposed in this invention connects four types of entities—users, cloud service providers, distributed log databases, and traceability auditors—to the blockchain network. Logstash, Elasticsearch, and Kibana components are deployed on the log collection end, distributed database end, and traceability audit end, respectively, building a data traceability platform with trusted entity identities, trusted log data, and trusted traceability results. The CBCProv architecture is as follows: Figure 2 As shown.

[0064] The blockchain component can be divided into four layers:

[0065] Client Layer: On the Fabric Client, users interact with the blockchain network using a Node.js-based SDK (Software Development Kit), enabling functions such as installing chaincode on nodes, submitting transaction proposals, and querying the blockchain ledger. Based on the type of entity on the client, it can be divided into user clients, cloud service provider clients, database clients, and provenance auditors. Logstash components are deployed on user clients and cloud service provider clients (CSP) to handle distributed log collection (Event capture) and preprocessing (Local log transfer); Elasticsearch components are deployed on the distributed log database to handle the retrieval of distributed log files; and Kibana components are deployed on the provenance auditor to handle log data analysis and visualization.

[0066] Network layer: The blockchain network layer reflects the topological relationship between the main entities of the system. It encapsulates the system's networking method, message propagation protocol, data synchronization and verification protocol, etc., and is the communication network of the entire system.

[0067] Blockchain ledger layer: Maintains the blockchain ledger information of the CBCProv system, and is responsible for collecting transaction data, generating data blocks, verifying the legality of transaction proposals, and sorting and adding verified transactions to the chain.

[0068] Database Layer (JSON Database): At the database layer, data from the distributed blockchain ledger is stored in the CouchDB state database in JSON format, supporting key-based storage. For indexing, via deployed chaincode functions , , Controls the updating, querying, and deletion of data within the database.

[0069] Examples of CBCProv business processes include Figure 3 As shown, User and CSP are the user client and cloud service provider, respectively; BN is the blockchain node; DLD is the database terminal; and PA is the traceability and auditing terminal.

[0070] LSM-based source tracing log collection module:

[0071] In cloud service scenarios, user data frequently flows between different terminals and server hosts, urgently requiring a secure and reliable log collection mechanism to support data operation and flow tracing. On user terminals such as Windows and Mac OS, the environment is relatively private, and system logs obtained through tools like syslog are sufficient for tracing needs. However, on the server side in open environments, the storage medium for user data is actually controlled by the cloud service provider, and the centralized public service model is more vulnerable to attacks and intrusions. Therefore, ensuring the integrity and reliability of server-side system logs is crucial. A reliable log collection module for tracing should possess the following three characteristics:

[0072] 1) Data-centric approach. Data-centric approach means that all captured event logs should be directly or indirectly related to user-managed data. In other words, they should be valuable for tracing and auditing. This collection method can not only reduce server listening and storage overhead, but also facilitate event reconstruction based on tracing logs.

[0073] 2) Real-time collection. As the name suggests, the collection of source logs should be real-time, and its working mechanism should be event-triggered. Real-time collection mechanisms offer higher security because attackers' smearing behavior is also recorded in real time.

[0074] 3) Difficult to tamper with. Ensuring the integrity and immutability of traceability data is crucial for obtaining accurate traceability results. Even if an attacker's intrusion is unavoidable, the monitoring logs recorded on the disk must be protected.

[0075] To address the aforementioned requirements, this invention proposes a system event capture mechanism based on the Linux security module (LSM), providing CBCProv with a reliable source of log data. LSM is a lightweight, general-purpose access control framework implemented in the Linux kernel. It provides a hook function interface for managing kernel resource objects by adding security domain fields to critical data structures in the kernel. LSM associates the global static structure `security_operations` with reserved hook function pointers. Before the system accesses critical resource objects, the hook function is called and executed to implement user-defined security policies. Currently, representative security systems based on the LSM framework include SELinux and AppArmor, and their security has been proven in practice.

[0076] like Figure 4 As shown, the underlying principle of the LSM-based system event capture mechanism is that, for any executable system command, its execution path and required resource objects are clearly defined. Therefore, by setting hook points on the critical execution paths of user-sensitive data, the parameters and environment of system function calls can be captured, and this source data can be output before the actual operation is executed. The LSM architecture pre-defines approximately 160 hook points, covering seven types of resource objects in the kernel; therefore, monitoring all execution paths is unnecessary. Based on the data-centric principle, the hook points set in this invention are shown in Table 1. Different event information is returned for different system functions, and can be categorized into three types based on the operation object: files, processes, and communication.

[0077]

[0078] Table 1

[0079] The goal of this invention, which introduces a system event capture mechanism based on LSM, is to provide end-to-end traceability support services in a cloud environment, focusing on three types of objects: critical user data, communication networks, and HLF network configuration files. The first two types record data operation behaviors and circulation networks, while monitoring the HLF network configuration files records attacks on the blockchain network. Specifically, the HLF's crypto-config directory stores information such as the current network organization's membership structure and certificates. After an attacker gains control of a user account, they can modify the configuration file to cause business anomalies on the blockchain. Therefore, by setting a hook point on the blockchain configuration file path, this attack behavior will also be monitored and recorded. All obtained traceability logs are stored in the / var / log / messages.log file in the user space, and write and delete permissions for all users are prohibited through mandatory access control (MAC), which is also implemented based on LSM.

[0080] It's important to note that ensuring the kernel's log collection module isn't tampered with or overwritten, and that log file access control permissions aren't altered, necessitates robust kernel security. Kernel security is closely linked to root privileges, as the system kernel can only be modified under root access. However, considering the uncontrollable nature of cloud service providers' actions, certain security vulnerabilities remain. These manifest in two ways: first, as server administrators, cloud service providers might collude with attackers to steal user data and disable the log collection module by leaking the root password to conceal malicious activity; second, cloud service providers might not adequately protect users' root privileges, leading to the theft of administrator identities. Therefore, the `sudo` command in the user's system also needs to be monitored.

[0081] Storage and retrieval mechanism of traceability logs:

[0082] After obtaining the traceability logs, ensuring the trustworthiness of the log files during storage, transmission, and traceability auditing becomes a crucial issue. Blockchain's trusted storage offers a viable technological path to address this problem. The trustworthiness of blockchain storage relies on its distributed ledger nature; all nodes collectively maintain a single transaction ledger through a consensus algorithm, ensuring data integrity and preventing data loss or tampering. However, this also results in a lack of scalability in blockchain storage. Existing blockchain technology still lags significantly in performance compared to traditional distributed databases; its throughput and response speed cannot meet the demands of large-scale data storage, and it lacks load balancing mechanisms. All nodes in a blockchain network must maintain the same ledger indiscriminately; increasing the number of server nodes does not improve data throughput but rather increases the time overhead of data state synchronization. This same problem exists in blockchain-based log storage systems. While blockchain can guarantee log integrity and reliability, it cannot be applied to dynamically growing, real-time analysis log management systems. To address this issue, and considering the need for distributed log uploading and retrieval, this invention proposes a combined on-chain and off-chain log storage and verification mechanism. By uploading log summaries and related metadata to HLF via transactions, the integrity of off-chain logs is verified. Meanwhile, the complete log file is uploaded to a distributed log database (DLD) based on an Elasticsearch cluster via Logstash, thus meeting the requirements for efficient storage and retrieval of log files.

[0083] like Figure 5 As shown, this invention achieves blockchain ledger segmentation through HLF's channel mechanism, where each channel maintains a separate distributed blockchain ledger, and the blockchain ledger data between channels is isolated. Log summaries and related metadata are stored on the HLF blockchain ledger in the form of transactions, while the complete log file is stored in an Elasticsearch-based DLD. When the DLD administrator wants to verify the integrity of the received log file, they query the on-chain blockchain ledger data through the DLD Client in the corresponding channel and determine whether the off-chain log file has been tampered with based on the returned results. This mechanism has two advantages: first, the on-chain and off-chain log storage method ensures the integrity of off-chain data while reducing the performance load on the blockchain caused by large-scale data storage and querying; second, segmenting the blockchain ledger through channels can improve the data throughput of the blockchain, and the decentralization of the blockchain ledger also reduces the query latency of log summaries.

[0084] The channel mechanism ensures data isolation between blockchain ledgers in different security domains. Furthermore, by sharding the blockchain ledger according to security domains, it improves the efficiency of on-chain data retrieval. Specifically, organizational members within the same security domain are grouped into the same channel. Under normal circumstances, the propagation of user data is restricted within defined security boundaries. Therefore, the log summaries stored on the blockchain ledger within a channel all originate from that domain. This improves on-chain data retrieval efficiency because, normally, only the blockchain ledger corresponding to the user's security domain needs to be monitored. Cross-domain access that violates security policies will also be detected because the DLD stores global log files, and its administrator has query permissions for all HLF channels, thus enabling global data tracing.

[0085] Before storing log data in the DLD, it must first be preprocessed, requiring the log files to be converted to JSON format for easy index building. This invention uses Logstash to configure a prospector and a harvester for the log files. The prospector is responsible for detecting the log directories specified in the configuration and determining the harvester's running status. The harvester is responsible for opening and closing files, continuously reading log content using a timer and sending it to the processing process. Then, predefined regular expressions are used to match fields in the logs, ultimately parsing the log records into JSON format and defining it as a source log entry. express.

[0086] Source tracing log set: Define the source tracing log set as Start time, time period Internally sent A collection of log entries, represented as Among them, the time variable This refers to the timing interval of the harvester, which operates at a set frequency. Generate log sets .

[0087] Each log entry was appended with a sequence number when converted to JSON format. , The logs in Arranged in ascending order of size. This invention is designed... Initial time of data collection The combined field with the incrementing sequence number, in The serial number is also recounted during the update, which ensures... Serial number The data is strictly incremented by time. Table 2 shows some fields of the processed logs.

[0088]

[0089] Table 2

[0090] On-chain log summary storage scheme:

[0091] like Figure 6 As shown, in the source log collection Simultaneously with the upload to the DLD, the user or cloud service provider also generates a Locator Upload Transaction (LUT) proposal on the client and sends it to the HLF network. The LUT contains a log summary, relevant metadata, and the name of the chaincode to be invoked. Figure 6 This diagram illustrates the entire accounting process of a LUT. The Ledger Nodes (LNs) in the diagram represent all LNs acting as both committers and endorsers, responsible for both committing and endorsing transactions. and The entire process, represented by the user's private and public keys for signing, can be described in the following four parts:

[0092] 1) The Fabric Client generates a LUT proposal, as shown in step 1 of the diagram. The upload information in the proposal can be represented as follows: ,in It includes upload time. Uploader Identifier Code and signing public key Transaction metadata, Obtained through a hash algorithm hash value, The publisher uses the private key The signing of the traceability log can be represented by equation (4):

[0093] (4)

[0094] 2) Blockchain ledger node endorsement, steps 2(a), 2(b), 2(c), and 3 in the diagram. After receiving the proposal, the LN in the blockchain network verifies the publisher's signature and... As the key of this log record ( (Indicates character concatenation), and simultaneously calls Confirmed Uniqueness is ensured to prevent duplicate log uploads. After verification, LN endorses the proposal, invokes the chaincode, and then appends the execution result to the proposal. This verification process can be represented by equation (5):

[0095] (5)

[0096] 3) The sorting nodes generate transaction blocks, as shown in steps 4(a), 4(b), 4(c), 5, and 6 in the diagram. After a proposal receives endorsements from more than half of the nodes, the uploader verifies the chaincode execution result and then submits the confirmed LUT proposal to the sorting nodes. The sorting nodes sort the proposals using a consensus algorithm, then add timestamps and other information to generate transaction blocks, which are then broadcast to the blockchain network.

[0097] 4) Blockchain ledger nodes update the blockchain ledger and database, as shown in steps 7, 8(a), 8(b), 8(c), and 8(d) in the diagram. After receiving the LUT, the LN in the blockchain network verifies the publisher's signature (endorsing nodes that have already been verified can be ignored) and the integrity of the transaction structure. After confirming that the local blockchain ledger and database are not the latest versions, it updates the local data according to the LUT.

[0098] The consensus algorithm for the ordering service is optional, and it is divided into two cases based on the trustworthiness of the ONs: Crash Tolerance (CFT) and Byzantine Fault Tolerance (BFT). In the CFT case, the ONs are considered to have high trustworthiness, and they are only likely to crash or go down. The Raft algorithm can ensure that the system continues to operate normally even if less than half of the ONs fail. In the BFT case, malicious nodes are considered to exist in the ONs, and their ordering service is unreliable. The BFT-SMaRt algorithm can tolerate betrayal by less than 1 / 3 of the ONs.

[0099] A fast log integrity verification algorithm based on MMR:

[0100] In on-chain log digest storage schemes, log digests are generated by analyzing log collections. Obtained through hashing, this is the simplest and most efficient method, but it has a drawback: log integrity verification can only be performed at the log set level. When log integrity is compromised, it's impossible to pinpoint the specific log entry. Storing log summaries line by line on the blockchain ledger is one solution, but this would mean that the integrity verification of the traceability logs could only be performed by comparing each line individually. This increases the query workload of the LN and the communication load of the HLF network. Therefore, it is necessary to design a fine-grained fast log integrity verification algorithm.

[0101] Drawing inspiration from Bitcoin, aggregating log digest data using a Merkle tree structure is a viable approach. However, this solution has a drawback: the Merkle tree structure cannot effectively handle the dynamic addition of log digests. Figure 7 For example, from to Within the specified time period, a total of 6 log summaries (H1 to H6) were received on the LN, and the Merkle root has been obtained through iterative calculation. But Received the latest log set Later, during the process of updating the Merkle root, LN... and The values ​​all need to be recalculated, which incurs additional computational overhead. Furthermore, to ensure real-time verification, the HLF client should, based on the received values… Send the LUT proposal as soon as possible, but Too few log entries will reduce the Merkle tree height. Too low a value will also lead to a decrease in verification speed. This is because LN needs to generate a Merkle tree for each LUT, and the Merkle root is a pair. The log integrity constraint promises that, in the worst case, when the tree height is 1, the Merkle root degenerates into a hash of a single log entry. The log verification process degenerates into a line-by-line comparison, leading to a significant reduction in verification speed. Therefore, the problem of achieving real-time fast log verification can be summarized as: how to dynamically update the log digest without affecting the already generated Merkle tree, thereby providing a global LUT inclusion proof. Based on this, this invention proposes a fast log integrity verification algorithm based on the Merkle Mountain Range (MMR) [Peter Todd. Merkle mountain range.].

[0102] like Figure 8 As shown, the Merkle Mountain Range (MMR) is defined as a range of hash trees, possessing... The data structure of leaf nodes has a Merkle root that is a hash of all subtree roots from right to left, represented as: One example is The MMR structure has the following three properties:

[0103] MMR structures can be viewed as highly Binary hash tree.

[0104] when Number of leaf nodes , hour, It becomes a balanced binary hash tree, also known as a Merkle tree.

[0105] Will The number of leaf nodes is represented as ,when hour, ,but It can be divided into two parts: having The left subtree of the leaf nodes and have The right sub-mountain range of each leaf node .

[0106] The log summaries are re-aggregated using the MMR structure and divided into three groups according to the time period in which the log sets were generated: , and The requirement is that the Fabric Client immediately generates and uploads a LUT proposal each time it receives a log set. The hash values ​​of leaf nodes and intermediate nodes are stored in the LN as an array in a graph representation. .exist After being uploaded and confirmed, It will be recorded by LN, where , and It is the hash value of a single log entry generated using a hash algorithm. It involves aggregating its leaf nodes using a fast hash algorithm. After being uploaded, LN, based on the previous... The value will generate And save. Similarly, when When uploaded, This will be saved, thus enabling dynamic updates of the log summary without altering the original data. In this case, the Merkle root can be represented as... .

[0107] like Figure 9 As shown, this invention proposes a user-based MMR structure while ensuring dynamic updates of the log digest. Specifically, after receiving a packaged block, the LN verifies each LUT contained within it. After confirming the validity of the transaction, the LN maintains a global MMR for each user based on the transaction uploader's information. Compared to the traditional Merkle tree, this structure has two advantages: First, it effectively reduces the user's storage overhead, as the user no longer needs to save all block headers, only the root value of their own MMR. Second, it enables batch LUT existence verification, because users can calculate the correct Merkle root after the MMR update based on their own submitted LUT proposals. When it is updated with the Merkle root of the blockchain ledger If they are the same, it can be proven that all log summaries in the LUT have been stored on the blockchain.

[0108] This invention proposes a proof / verification protocol based on MMR. One party to the protocol is the LN on HLF, which stores the entire blockchain transaction ledger, maintains MMR-based log digest data, and is responsible for providing the SPV proof set to the queryer; this party is called the prover. The other party is the user or the administrator of the DLD, who records their own MMR Merkle root but does not store the complete transaction ledger. Therefore, they need to request the SPV proof set to confirm that the log digest is stored on the chain; this party is called the verifier.

[0109] SPV proof set: SPV proof set The index in MMR is The existence proof of leaf nodes (starting from 0), including the path from the leaf node to the Merkle root. All sibling nodes on the path.

[0110] Figure 10a A log digest update algorithm based on MMR is presented. Its core idea is to determine whether to generate an intermediate node during insertion based on whether the node's height is the same as its sibling node's height. Specifically, this can be achieved using an array... This represents any instance of an MMR, because it maps to a unique MMR structure; therefore, any update operation on a node can be viewed as an update to an MMR. The writing, Figure 10a Lines 4 to 9 in the code provide the pseudocode implementation of the write method.

[0111] Figure 10b A Merkle root generation algorithm based on MMR is presented. As defined in Definition 3, Merkle roots... It is a hash of all subtree roots, reflecting the integrity of all leaf nodes. (Compare) Figure 10a and Figure 10b It's worth noting that the Merkle root generation algorithm and the log digest update algorithm use similar decision-making methods, but their invocation conditions differ. The LN algorithm requires an MMR update every time new log data is obtained, but the Merkle root is only calculated once each time a new block is confirmed, serving as a record of the global log state.

[0112] Figure 10c An algorithm for generating SPV proof sets based on MMR is presented. The core idea of ​​the algorithm is MMR, finding the index with... leaf nodes The coordinates are then used to generate its SPV proof set. This process is divided into three parts: first, ... Merkle root of the left sub-hash tree is added from left to right. Secondly, construction Merkle proof set of the hash tree Thirdly, to acquire The Merkle root of all subtrees on the right. Lines 3 to 18 of the algorithm show the MMR traversal process from left to right, by comparing the number of leaf nodes in the largest subtree on the left. and Size, Determine If a node belongs to the subtree, add it to the Merkle root of the subtree if it does not. Then delete the subtree and continue traversing. When it belongs to the subtree, generate the Merkle proof set for that subtree using the classic Merkle tree-based proof set generation algorithm. And stop iterating. Finally, use Algorithm 2. Get Merkle roots of all subtrees on the right. Figure 8 For example, nodes are obtained using Algorithm 3. SPV proof set .

[0113] Based on the above algorithm, the following proof / verification protocol based on MMR is proposed:

[0114] Proof party:

[0115] 1) Upon receiving a new LUT, via Update array ;

[0116] 2) After the new block is confirmed, through Generate Merkle root And write it to the HLF status database;

[0117] 3) Receive logs sent by the verifier. Completeness inquiry;

[0118] 4) Through Generate SPV proof set And send it to the verifier.

[0119] Verifier:

[0120] 1) Send logs to the proving party Completeness inquiry;

[0121] 3) The SPV proof set sent by the receiving party. ;

[0122] 4) Insert the hash value of the log. Verification value is calculated through iterative hashing. ;

[0123] 5) Compare the publicly available Merkle roots on the chain. With verification value Are they the same?

[0124] 6) Verification successful, confirm. The integrity of.

[0125] The SPV proof protocol can be used to verify the integrity of a single log entry. The following is a proof / verification protocol for batch log integrity verification.

[0126] Proof Snapshot: A proof snapshot is a record of the state of a log at a specific point in time. express A snapshot of the log at a given moment, calculated Merkle root corresponding to user MMR at any given time get.

[0127] By generating proof snapshots using the MMR structure, global log verification can be achieved at any point in time. When an LN node receives a verification request, it will determine the time node from which the request is made. Return the corresponding ,by Figure 8 For example, , , The verifier maintains an off-chain traceability log set, including the log sequence number. It is strictly increasing according to the time series; he obtained... Then, iterative calculations can be performed based on the complete log set to obtain... and according to and The correctness of the log set is determined by whether they are equal.

[0128] Based on the above algorithm, a proof / verification protocol based on proof snapshots is proposed as follows:

[0129] Proof party:

[0130] 1) Upon receiving a new LUT, via Generate MMR update array ;

[0131] 2) Receive the given time node sent by the verification party. Inquiry;

[0132] 3) Generate Snapshot of the proof of time And send it to the verifier.

[0133] Verifier:

[0134] 1) Based on the log sequence number Determine its time node Send time parameters to the proving party Completeness inquiry;

[0135] 2) Receive the proof snapshot sent by the proving party ;

[0136] 3) Obtained through iterative calculation from the actual saved log set. ;

[0137] 5) Comparison and Are they the same?

[0138] 6) Verification successful, confirm the timeline. The previous logs have been correctly uploaded to DLD.

[0139] Data tracing methods based on DAG:

[0140] In the source tracing auditing process, the Source Tracing Auditor (PA) has access to all user logs, enabling them to provide end-to-end source tracing auditing services online. The PA accepts source tracing requests initiated by users, searches relevant logs for specified data, and constructs a data source tracing graph using a depth-first search strategy. This graph displays the flow and evolution of data, transforming the problem of tracing the source of given data into a connectivity problem of the source tracing graph, ultimately forming the source tracing results.

[0141] Data source traceability diagram: Data source traceability diagram Given a directed acyclic graph, where:

[0142]

[0143] in It is a collection of data entities. It is a set of users, represented by any node in the graph. For example, Indicated by user Controlled data entities . Represents the set of input data. A collection representing data results. It is a collection of operation types, assuming , Represents vertices In operation The lower part evolves into the upper part. This is referred to as an operation event within a user domain; assuming , Represents vertices Through transmission behavior Connect to vertices This is referred to as a user domain flow event.

[0144] Data traceability diagram Construction algorithms such as Figure 11 As shown ( Figure 11 In the diagram (where Y represents yes and N represents no), PA accepts the user-initiated source tracing request c, searches for the earliest relevant log in the DLD, and then uses this as the root node to traverse it using a depth-first search strategy. During the traversal, previously visited nodes are ignored, thus eliminating periodic file read / write loops and ensuring that the source tracing graph is directed acyclic. The specific steps are as follows:

[0145] 1) Locate the earliest relevant log in the DLD;

[0146] 2) Initialize the data traceability diagram and ;

[0147] 3) Represent the vertices of the target data Add to image and will Marked as visited;

[0148] 4) In Obtaining and Connected edges If it does not exist, proceed to step 7;

[0149] 5) Judgment Whether the represented log event is a transfer event, when data transmission to a new user domain is detected, all logs for that user domain are added to it. ;

[0150] 6) Obtain pass Connected vertices ,judge Whether it has been accessed, if not accessed, then Set as Proceed to step 3. If the edge has already been visited, retrieve the next edge.

[0151] 7) Return the data source diagram .

[0152] Network communication logs are obtained by monitoring the socket interface through LSM. These logs reflect the flow of target data. When the detected data is transmitted to a new user domain, that user domain has the right to operate on the target data, and may perform editing operations or retransmit it. Therefore, all logs recorded in that user domain also need to be detected. Step 5) describes this process.

[0153] Figure 12 The demonstration showcases data tracing results based on a Directed Acyclic Graph (DAG). The scenario is as follows: adminA, the administrator of a cloud server with root privileges, logs into Alice's virtual machine and accesses the file Alice.txt. He then sends the file to another virtual machine via email, renames it to Bob.txt, and sends it to yet another virtual machine. PA uses Alice.txt as the target data and constructs a data tracing graph using the aforementioned algorithm. This shows that the malicious access behavior by the administrator abusing privileges and the complete path of data leakage are reconstructed. Furthermore, due to the blockchain's log integrity protection mechanism, this tracing result is irrefutable.

[0154] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A trusted tracing method for cloud data operation behavior, characterized in that, Includes the following steps: Hook points are set based on the user's resource objects and the critical paths of executed commands to collect operation event information of cloud data and obtain the traceability log of the cloud data. Extract the log summary and related metadata of the traceability logs, and store the log summary and related metadata on the blockchain ledger to support the integrity verification of the traceability log set; The log summary is stored on-chain using a data storage mechanism based on the Merkle Mountains to support fine-grained and batch verification of the integrity of off-chain traceability logs. Construct a traceability model for cloud data, obtain a traceability mechanism that combines the super blockchain ledger and ELK Stack technology, and use it to ensure the credibility of traceability logs through the Merkle mountain algorithm and the traceability log set while implementing identity verification services, and obtain a DAG-based behavior accountability traceability method. ELK is an acronym for Elasticsearch, Logstash and Kibana. Based on the hook points, the parameters and environment of the system call functions of system events are extracted to obtain the source log. With relatively small server listening and storage overhead, event reconstruction based on the source log is supported. The hook points are divided into three categories according to resource objects: files, processes, and communication. Based on the LSM system event capture mechanism of the Linux security module and the hook point, the traceability log is constructed by focusing on three types of objects: user cloud storage data, communication network, and blockchain network configuration files. The system controls the blockchain ledger to conduct transactions, records the log summary and related metadata, wherein the blockchain ledger includes several distributed blockchain ledgers, the several distributed blockchain ledgers are obtained based on the HLF channel mechanism, and the data between each distributed blockchain ledger is isolated; A distributed log database based on Elasticsearch stores the traceability logs. When verifying the integrity of the received log files, it queries the on-chain blockchain ledger data through the distributed log database client in the corresponding channel, and determines whether the off-chain log files have been tampered with based on the returned results. Extract the upload time, uploader identifier, uploader signature public key, and hash value from the source tracing log set to construct the upload information; Based on the upload time and the uploader identifier, chaincode and consensus algorithm are invoked to generate transaction blocks for transactions between the blockchain ledger and the traceability log. In the process of invoking chaincode and consensus algorithm, at least timestamp information is added. Based on the algorithm structure of the Merkle mountain algorithm, the source tracing log set is aggregated to construct a source tracing log summary storage model; Based on the Merkle mountain algorithm update log summary data, Merkle root data, and SPV proof set, a proof verification model is constructed. Based on the log digest storage model, a proof snapshot is constructed; based on the log digest storage model, the proof verification model, and the proof snapshot, a source log verification model is constructed. The proof snapshot is a record of the state of the log storage at a specific moment. express A snapshot of the log at a given moment, calculated Merkle root corresponding to user MMR at any given time get; Extract the earliest time-series log of the cloud data as vertex data; Initialize the data tracing model and the cloud data; Add the vertex data to the data tracing model and mark the vertex data as accessed; Extract the flow events that connect the cloud data to the data tracing model, mark the system logs corresponding to the flow events as logs to be added, determine whether the flow events are the vertex data, and trace the source of the cloud data based on the determination result and the data tracing model. Among them, under the premise of satisfying the dynamic update of log digest, the algorithm structure of the Merkle mountain algorithm is a user-oriented MMR structure. After receiving the packaged block, the ledger node LN will verify the traceability log upload transaction LUT contained therein one by one. After confirming the validity of the transaction, the LN will maintain a global MMR for each user based on the information of the transaction uploader. Among them, the data tracing methods based on DAG include: In the source tracing auditing process, the source tracing auditor (PA) has the authority to read all user logs and provides users with end-to-end source tracing auditing services on the network. The PA accepts the source tracing request initiated by the user, searches for relevant logs of the specified data, and constructs a data source tracing graph through the source tracing logs using a depth-first search strategy to show the flow and evolution of the data. This transforms the source tracing problem of given data into a connectivity problem of the source tracing graph, and finally forms the source tracing result. The SPV proof set is updated based on the Merkle mountain algorithm, including: Traverse the Merkle mountain algorithm to extract the node coordinates of the leaf nodes of the source log summary storage model, and obtain the first sub-hash tree to the left of the leaf node, the second sub-hash tree where the leaf node is located, and the third sub-hash tree to the right of the leaf node; construct the SPV proof set based on the first sub-hash tree, the second sub-hash tree, and the third sub-hash tree; Based on the Merkle mountain algorithm update log summary data and Merkle root data, including: The MMR structure has a height of Binary hash tree, when an instance Number of leaf nodes , hour, It becomes a balanced binary hash tree, also known as a Merkle tree; Will The number of leaf nodes is represented as ,when hour, , Divided into two parts: having The left subtree of the leaf nodes and have The right sub-mountain range of each leaf node ; The log summaries are re-aggregated using the MMR structure and divided into three groups according to the time period in which the log sets were generated: , and Among them, time variable For the Harvester timer interval, the Fabric client is required to immediately generate a source log, upload the transaction LUT proposal, and upload it each time it receives a log set. The hash values ​​of leaf nodes and intermediate nodes are stored in an array on the LN, represented as... ,exist After being uploaded and confirmed, It will be recorded by LN, where , and It is the hash value of a single log entry generated using a hash algorithm. It is achieved by aggregating its leaf nodes using a fast hash algorithm. After being uploaded, LN, based on the previous... The value will generate And save, similarly, when When uploaded, It will be saved, Merkle root is .

2. The trusted tracing method for cloud data operation behavior according to claim 1, characterized in that: Convert the source tracing log to JSON format to obtain the source tracing log file; Based on the collection time and incrementing sequence number of the source tracing log, a combined sequence number field is obtained; The source tracing log set is constructed based on the source tracing log file and the combined sequence number field.

Images