A blockchain-based log security storage and efficient query method

Abstract

The application discloses a kind of based on blockchain's log security storage and efficient query method, belong to information security technical field.First, a kind of based on blockchain's on-chain off-chain collaborative tamper-proof log storage framework is designed, wherein log server receives the log uploaded by log generator through secure channel and encrypts storage, while extracting the key word in log constructs reverse order index table, and the index table is saved to blockchain in the form of transaction.The framework is tamper-proof by the non-tamperable nature of on-chain data, and the effective mapping of on-chain and off-chain data, guarantees the tamper-proof and integrity of log.Based on the above framework, a kind of safe and efficient log query method is designed: through role-based access control strategy, the identity authentication of log searcher is carried out, uses smart contract to efficiently handle the request of legal log searcher, uses adaptive prefix tree as data structure to save index item, realizes the efficient retrieval to log.

Description

Technical Field

[0001] This invention relates to a blockchain-based method for secure log storage and efficient querying, belonging to the field of blockchain log secure storage and querying technology. Background Technology

[0002] The effective operation, secure maintenance, and performance monitoring of smart IoT platforms are crucial. These platforms generate a large amount of log data, including operational information from devices, systems, and applications. Analyzing these logs allows for rapid problem-solving. Smart IoT has permeated all aspects of life, becoming an indispensable part. These systems generate vast amounts of log data containing critical information about system status and user actions. Analyzing this data allows for understanding system status and improving user experience.

[0003] However, due to the critical information contained in logs, malicious attacks often target them. Malicious individuals may tamper with logs, misleading log-based system analysis and thus impacting system security. More seriously, some malicious attackers can even erase traces of their modifications to log data, making it difficult to trace them, and the resulting losses can be substantial. Furthermore, the rapidly growing log data leads to inefficient querying, making it impossible to quickly retrieve the required logs.

[0004] Therefore, existing technologies need to prevent log tampering to ensure the reliability and integrity of data storage, and provide access mechanisms that meet user query needs. Summary of the Invention

[0005] This invention provides a blockchain-based method for secure log storage and efficient querying, addressing the issues of easily tampered log data and low query efficiency. It improves the security of log data storage and enhances query efficiency. Users can quickly and accurately obtain the data they need, meeting the high demands of real-world log data querying.

[0006] The technical solution adopted in this invention is: a blockchain-based method for secure log storage and efficient querying, the specific steps of which are as follows:

[0007] S1: Encryption and Keyword Extraction of Log Data: Log Generator LogGen sends the collected log data DataLD to Log Server LogSer. The two parties use DH key negotiation to establish a secure data transmission communication channel and obtain the negotiation key NK. After receiving the log data, LogSer uses SM4 to encrypt and save it. Then, it uses TF-IDF extraction technology to calculate the weight W of each word in the file. Finally, the extracted keywords are used to build an inverted index table and saved to the blockchain. The timestamp, data hash fingerprint, and resource-permission mapping table are also uploaded to the chain.

[0008] S2: Log Data Query Processing: Data requesters, i.e., users, publish query requests to the blockchain in the form of transactions. The system calls the access control contract to verify the user's identity. After verification by the access control contract, an authorization token (AuthToken) is obtained. Then, the system calls the query smart contract (ESMC) to process the query request. The adaptive prefix tree (ART) is used as the data structure to store index items. Each keyword and information in the inverted index table is traversed. The query methods include multi-keyword query and time range query, thus providing efficient query functions. Finally, when the system queries, it also needs to check the permission-resource mapping table to check whether the user has access permissions. The contract records the user's address, query request, and timestamp in the query array for subsequent record comparison.

[0009] S3: Creation and Deployment of Smart Contracts: First, deploy the Attribute Information Management Contract (AIMC), which includes user attributes and resource attributes. Then, deploy the Policy Management Contract (PMC) to effectively manage access policies. Different users have different permissions. Finally, deploy the Access Control Contract (ACMC) to verify the matching between user attributes and policies, and then decide whether to grant access permissions. When a user publishes an access request, the access control contract is called to query the resource-permission mapping table on the chain to verify the user's identity. All access behaviors are recorded, and these records can be used for auditing and traceability to ensure data compliance and security.

[0010] Specifically, the steps of S1 are as follows:

[0011] S1.1: LogGen collects all log data and saves the aggregated log data to the log server, establishing a secure communication channel.

[0012] (1) First, calculate the negotiation key between LogGen and LogSer:

[0013] NK gen =(Y b ) A mod p = (g B mod p) A =g (B×A) mod p (5)

[0014] NK ser =(Y a ) B mod p = (g A mod p) B =g A×B mod p (6)

[0015] The log generator obtains the negotiation key NK by calculating formula (1). genSimilarly, the log server obtains the negotiation key NK through formula (2). ser And it must satisfy the condition NK gen =NK ser Therefore, both parties obtained the same key through negotiation, achieving the purpose of key negotiation, where p is a prime number, g is the primitive root of the prime number p, A is the private random number of the log generator, B is the private random number of the log server, and Y... a =g A mod p, Y b =g B mod p;

[0016] (2) Then encrypt the negotiation key NK with the DataLD to be sent to obtain the ciphertext C = Enc(NK, DataLD);

[0017] S1.2: After receiving the log data sent by LogGen, LogServer first decrypts the ciphertext Den(NK, DataLD) to obtain the plaintext. Then, it encrypts the data by generating a random key using a pseudo-random number generator PRNG and using the original data as input, then encrypts it using SM4 to obtain the ciphertext C, expressed by the formula:

[0018] C = SM4 - Enc(P, K) (7)

[0019] Where C represents ciphertext, P is plaintext log data, and K is a random key;

[0020] S1.3: First, the collected log data is preprocessed, including assigning appropriate permission tags to the data and removing irrelevant information such as stop words and punctuation marks. Then, the TF-IDF keyword extraction algorithm is used to extract keywords from the documents. The TF-IDF model finds words that appear frequently in a document but rarely in the entire document collection, expressed by the formula:

[0021]

[0022] Where f i，j df represents the frequency of keyword i in document j. i The number of times the document containing the keyword i appears in corpus document D;

[0023] S1.4: Construct an inverted index table using the keywords extracted by the TF-IDF algorithm. Each word has an associated list containing all documents containing that word, the start time StartT and end time EndT of each document, and the list is sorted in descending order of TF-IDF values.

[0024] S1.5: Upload the inverted index table to the blockchain storage. The index table and blocks are generated together. The blocks contain metadata inverted index table, log record start time, data hash fingerprint, and resource permission mapping table.

[0025] Specifically, the steps of S2 include:

[0026] S2.1: The user first publishes an access request AR, which is uploaded to the blockchain in the form of a transaction. The access control contract is called to query the resource-permission table to verify the user's identity and permissions. After successful verification, an authorization token is returned.

[0027] S2.2: Call ESMC, uploading AR and AuthToken as parameters. ESMC executes the query based on the user's query request. The user's query method can be multi-keyword query or query based on time range. The KMP fuzzy matching algorithm is used for fuzzy search, which can match abbreviations and word roots.

[0028] (1) Multi-keyword query: Adaptive prefix tree is used as the data structure. During the query, the query contract automatically constructs an adaptive prefix tree (ART) based on the inverted index table to realize multi-keyword query.

[0029] (2) Time range query: To find out the log records that occurred within a certain time period, you can select to query the log records by time range. After the query requester publishes the query request, the system calls ESMC to automatically build ART to execute the query. After executing the query request, it returns all relevant log records within the range and then filters out records that the user does not have permission to access based on the user's identity.

[0030] S2.3: After the query is completed, the contract will record the requester's address, query request, and timestamp in the query array for subsequent record comparison.

[0031] Specifically, the steps in S2.2(1) to automatically construct an adaptive prefix tree (ART) based on the inverted index table to implement multi-keyword queries include:

[0032] (1) Initialize the ART tree: Create a root node Root, which is usually an empty node;

[0033] (2) Insert keywords: Insert keywords one by one, starting from the root node. For each keyword character, check if a child node with the same character already exists. If it does, move to that child node; otherwise, create a new child node and move to that child node.

[0034] (3) Mark the end of the keyword: After inserting the complete keyword, mark the end of the keyword on the node of the last character, using a special flag is_end_of_word=True;

[0035] (4) Search keywords: When searching for keywords, start from the root node and check each character one by one; if the character is in a child node of the current node, move to that child node; otherwise, the keyword does not exist;

[0036] (5) Traverse the ART tree: Use depth-first search to traverse the ART tree to obtain all relevant keywords. Specifically, in step (2) of S2.2, the specific steps for finding log files within a specific time range are as follows:

[0037] (1) Use the timestamp of each log file as the key and store the relevant information of the log file as the value in the ART tree. Whenever a new log file is generated, insert its timestamp and relevant information into the ART tree.

[0038] (2) Starting from the root node of the ART tree, traverse the nodes of the tree level by level according to the time range of the query and the comparison rules of the timestamp.

[0039] (3) When a node is reached, further determine whether it is necessary to continue traversing the child nodes downwards based on the range of timestamps;

[0040] (4) If the condition is not met, continue to traverse the left or right child nodes until a log file that meets the time range condition is found.

[0041] (5) Repeat this process until all log files that meet the conditions are found. The time complexity of the query is usually O(logN+M), where N is the height of the tree and M is the number of log files that meet the time range conditions.

[0042] Specifically, in S2, the specific steps for the system to call the access control contract to verify the user's identity are as follows:

[0043] S3.1: Define user, environment, and resource attributes

[0044] User attributes: Regular user, Administrator, Auditor;

[0045] Resource attributes: Device type, sensitivity level, timestamp;

[0046] Environmental conditions: based on contextual information, such as time and geographical information;

[0047] S3.2: Define access policies: Match user attributes and environmental conditions with log data attributes to determine whether access permissions are granted;

[0048] S3.3: Smart Contract Creation: Based on the user and resource attribute verification conditions and according to policies for authorizing or denying access, a smart contract was written and then deployed to the blockchain network. To build an attribute-based access control system, several key contract modules were used, including the Attribute Information Management Contract (AIMC), the Access Control Management Contract (ACMC), and the Policy Management Contract (PMC).

[0049] S3.4: Smart Contract Deployment: Deploy the attribute information management contract, access control contract, and policy management contract to the blockchain network;

[0050] S3.5: Smart Contract Trigger: When a user publishes an access request to the access control module, the execution of the access control contract is triggered. The access request published by the user includes the user's identity and query requirements. During this process, the access control contract interacts with the attribute information management contract and the policy management contract. The access control contract calls the attribute information management contract to obtain relevant information about user attributes, resource attributes, and environment attributes. At the same time, it also interacts with the policy management contract to obtain the corresponding access policy. Through these interactions, the access control contract can make accurate access control decisions based on user attributes, resource attributes, and environment attributes, combined with predefined policies.

[0051] S3.6: Smart Contract Verification: The smart contract first verifies the user's identity and attributes, as well as the attributes of the resource, to ensure the legality of the request. Then, based on the user's attributes and the requested resource attributes, it verifies whether the access request conforms to the access policy and checks whether there are dynamic access policies, such as access time ranges or access under specific conditions.

[0052] S3.7: Access Authorization and Access Record Creation: If the verification is successful, the smart contract will grant the user access rights and create an access record on the blockchain. The access record will include the user ID, resource ID, timestamp, and access result information. This record is added to a new block of the blockchain to ensure its immutability.

[0053] S3.8: Dynamic access policy update: When user attributes or resource attributes change, the access policy can be dynamically updated as needed;

[0054] S3.9: Resource Access: After obtaining access rights, the user invokes the query contract to request data access based on the obtained authorization token.

[0055] Specifically, the steps in S3.2 are as follows:

[0056] S3.2.1: Non-sensitive logs: All user types can use non-sensitive logs. These logs do not contain sensitive information, are accessible to all users, and have no specific environmental requirements.

[0057] S3.2.2: Sensitive Logs: Ordinary users can access parts of sensitive logs, such as records of their logins and data accesses. Due to the sensitivity of the logs, ordinary users can only log in and access them within a specific time. Administrators and auditors can access sensitive logs in their entirety in order to monitor and audit user behavior. Highly sensitive logs involve user login records, data access records, and file operation records. There are no specific environmental requirements for ordinary users and administrators.

[0058] S3.2.3: Highly Sensitive Logs: Only administrators can access highly sensitive logs. These logs contain sensitive information, so access restrictions need to be imposed to ensure that only authorized personnel can view them. Highly sensitive logs include user operations on sensitive data, authentication information, and payment data. There are no specific environmental requirements.

[0059] Specifically, the attribute information management contract AIMC, access control management contract ACMC, and policy management contract PMC in S3.3 are as follows:

[0060] S3.3.1: Attribute Information Management Contract AIMC: The AIMC attribute contract covers three important functions: user attribute management, resource attribute management, and environment attribute management. Through the interaction interface with access control, this contract can not only effectively manage attribute values, but also realize the continuous updating of attribute information. The AIMC interface provides key data for access control, enabling it to retrieve various attribute values ​​and keep the attribute information updated in real time as the context changes.

[0061] S3.3.2: Access Control Contract ACMC: The ACMC access control contract performs three key functions: collecting access requests, initiating the decision-making process, and implementing policies. In the policy execution phase, the contract receives the policy, access request, and current attribute value as input, evaluates them, and generates a corresponding access decision, which is to allow, deny, or handle it in an indeterminate manner.

[0062] S3.3.3: Strategy Management Contract (PMC): The PMC strategy management contract acts as the key implementer of strategy management and strategy storage. In terms of strategy management, since the inherent immutability of smart contracts once deployed to the blockchain makes it impossible to directly modify the contract, an upgrade mechanism is introduced when designing the contract. This mechanism is contained in the contract code and is specifically manifested as an upgrade function. When the contract needs to be updated, this function is called to replace the original version with a brand-new contract code. Thus, the deployed contract is refreshed and smoothly migrates to the updated version. For strategy storage, each access strategy is compiled into an access strategy table to achieve orderly storage and convenient management of strategies.

[0063] The beneficial effects of this invention are as follows: This invention discloses a blockchain-based method for secure log storage and efficient querying. It deploys smart contracts to establish attribute-based access control, utilizing the automatic execution and immutability of smart contracts to implement access control judgments. The data is then encrypted off-chain using SM4 and stored locally, achieving data tamper-proofing. TF-IDF keyword extraction technology is used to extract keywords, constructing an inverted index table and establishing a mapping relationship between off-chain and on-chain data, enabling efficient querying of log data. This solution can achieve dynamic, distributed, and reliable access control in open smart IoT environments. Compared with existing technologies, this invention primarily solves the problems of easily tampered log data and low query efficiency, improving the secure storage and efficient querying of log data. Attached Figure Description

[0064] Figure 1 This is the overall flowchart of the present invention;

[0065] Figure 2 Detailed flowchart of log query;

[0066] Figure 3 It is an attribute-based access control flowchart. Detailed Implementation

[0067] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0068] Example 1: Refer to Appendix Figure 1 As shown, consider, for example, an IoT system for a smart city, where hundreds of sensors—loggers—are distributed throughout the city, collecting data on traffic, environment, energy, and other aspects. This data needs to be securely collected, stored, and retrieved. The specific steps for secure log storage and efficient retrieval based on blockchain are as follows:

[0069] S1: Encryption and Keyword Extraction of Log Data: For example, in an IoT system, a log generator LogGen_A is responsible for collecting environmental monitoring data DataLD. A secure communication channel is established between LogGen_A and the log server LogSer_B. This channel is established through the DH key negotiation protocol. The two parties negotiate and obtain a negotiation key NK. LogGen_A encrypts NK and DataLD and sends it to LogSer_B. After receiving the ciphertext, LogSer_B decrypts it to obtain the original data. On LogSer_B, TF-IDF extraction technology is used to process the decrypted log data, calculate the weight W of each word in the file, and finally construct an inverted index table of extracted keywords and save it to the blockchain. The timestamp, data hash fingerprint, and resource-permission mapping table are also uploaded to the blockchain.

[0070] S2: Log Data Query Processing: Data requesters, i.e., users, publish query requests to the blockchain in the form of transactions. The system calls the access control contract to verify the user's identity. After verification by the access control contract, an authorization token (AuthToken) is obtained. Then, the system calls the query smart contract (ESMC) to process the query request. The adaptive prefix tree (ART) is used as the data structure to store index items. Each keyword and information in the inverted index table is traversed. The query methods include multi-keyword query and time range query, thus providing efficient query functions. Finally, when the system queries, it also needs to check the permission-resource mapping table to check whether the user has access permissions. The contract records the user's address, query request, and timestamp in the query array for subsequent record comparison.

[0071] S3: Creation and Deployment of Smart Contracts: First, deploy the Attribute Information Management Contract (AIMC), which includes user attributes and resource attributes. Then, deploy the Policy Management Contract (PMC) to effectively manage access policies. Different users have different permissions. Finally, deploy the Access Control Contract (ACMC) to verify the matching between user attributes and policies, and then decide whether to grant access permissions. When a user publishes an access request, the access control contract is called to query the resource-permission mapping table on the chain to verify the user's identity. All access behaviors are recorded, and these records can be used for auditing and traceability to ensure data compliance and security.

[0072] Furthermore, the specific steps of S1 are as follows:

[0073] S1.1: LogGen collects all traffic log data and saves the aggregated log data to the log server. To prevent data from being tampered with during transmission, a secure communication channel needs to be established.

[0074] (1) Assume that LogGen_A and LogSer_B share p and g respectively, where p = 13 and g = 3. Then, LogGen_A chooses a private number A = 15, and LogSer_B also chooses a private number B = 13. The negotiated key is calculated using the following equation:

[0075] NK gen =(Y b ) A mod p = (g B mod p) A =g (B×A) mod p = 8 (9)

[0076] NK ser =(Y a ) B mod p = (g A mod p) B =g A×B mod p = 8 (10)

[0077] The log generator obtains the negotiation key NK by calculating formula (1). gen Similarly, the log server obtains the negotiation key NK through formula (2). ser And it must satisfy the condition NK gen =NK ser =8, therefore, both parties obtained the same key through negotiation, achieving the purpose of key negotiation. Where p is a prime number, g is the primitive root of prime p, A is the private random number of the log generator, B is the private random number of the log server, and Y... a =g A mod p, Y b =g B mod p.

[0078] (2) After the above calculation, the negotiation key between the two parties is NK=8. Encrypt 8 with the DataLD to be sent to obtain the ciphertext C=Enc(NK, DataLD).

[0079] S1.2: After receiving the log data sent by LogGen_A, LogSer_B first decrypts the ciphertext Den(NK, DataLD) to obtain the plaintext. Then, it encrypts the data by generating a random key using a pseudo-random number generator (PRNG) and using the original data as input, encrypting it with SM4 to obtain the ciphertext C, expressed by the formula:

[0080] C = SM4 - Enc(P, K) (11)

[0081] Where C represents ciphertext, P represents plaintext log data, and K represents a random key.

[0082] S1.3: After LogSer_B obtains the data, it first preprocesses the log data, including assigning corresponding permission labels to the data, and removing irrelevant information such as stop words (words that are not helpful for searching in most cases, such as "de", "he", etc.) and punctuation marks. For example, assume the log data includes two records as follows: 1. Timestamp: 2023-09-20 9:10:00 Location: C Air Quality Index: 95 Weather Condition: Cloudy 2. Timestamp: 2023-09-25 10:00:00 Location: A Air Quality Index: 80 Weather Condition: Sunny. Then the TF-IDF keyword extraction algorithm is used to extract and calculate the keywords in the document: Timestamp, Location, Air Quality Index, Weather Condition. The TF-IDF model is mainly used to find words that appear frequently in a single document but rarely appear in the entire document collection, which can be expressed by the formula:

[0083]

[0084] Where f i，j is the frequency of keyword i appearing in document j, df i is the number of documents containing keyword i in the corpus document set D.

[0085] S1.4: Construct an inverted index table from the keywords extracted by the TF-IDF algorithm. Each word has an associated list containing all documents that contain the word, the start recording time StartT and end recording time end_Time of each document. The list is sorted in descending order of TF-IDF values.

[0086] S1.5: Upload the inverted index table to the blockchain for storage. The index table is generated together with the block, and the block includes metadata, the inverted index table, the start time of log records, data hash fingerprint, and resource permission mapping table.

[0087] Further, with reference to the accompanying Figure 2 as shown, the specific steps of S2 include:

[0088] S2.1: Bob, a city resident, wants to query the air quality data for Area A over the past week. Bob first issues an access request AR: Query the air quality index and weather conditions for Area A, uploads it to the blockchain in the form of a transaction, calls the access control contract to query the resource-permission table to verify his identity and permissions, and returns an authorization token AuthToken to Bob after successful verification.

[0089] S2.2: The system calls ESMC, uploading Bob's AR and AuthToken as parameters. ESMC executes the query based on Bob's query request. The query method can be multi-keyword query or query based on time range. The KMP fuzzy matching algorithm is used for fuzzy search, which can match abbreviations (e.g., searching for "abbr" will return results containing "abbreviation") and root words (e.g., searching for "Fail" will match "Failed").

[0090] I1) Multi-keyword query: To speed up data retrieval, an inverted index table is built off-chain for the keywords of the data. However, only one keyword can be queried at a time. To enable multi-keyword queries, an adaptive prefix tree (ART) is used as the data structure. During a query, the query contract automatically constructs an ART based on the inverted index table to achieve multi-keyword queries. For example, based on Bob's query request keywords:<Identity number,{Location:A,Air Quality Index,Weather Condition}> First, query all documents containing Location: A, Air Quality Index, and Weather Condition in sequence. Then, take the intersection of these documents to get the documents containing the three keywords. Finally, filter out records that Bob does not have permission to access based on Bob's identity.

[0091] (2) Time Range Query: If Bob wants to know the log records that occurred within a specific time period, he can choose to query records by time range based on the time when the log records occurred. For example, the query request would be:<Identitynumber{2017-5-23,2017-5-25}> The system calls ESMC to automatically build ART to execute queries. After executing the query request, it returns all relevant log records within the scope and then filters out records that Bob does not have permission to access based on Bob's identity.

[0092] In S2.2(1), the specific steps for automatically constructing an adaptive prefix tree (ART) based on the inverted index table to implement multi-keyword queries include:

[0093] (1) Initialize the ART tree: Create a root node Root, which is usually an empty node.

[0094] (2) Insert keywords: Insert keywords one by one, starting from the root node. For each keyword character, check if a child node with the same character already exists. If it does, move to that child node; otherwise, create a new child node and move to that child node.

[0095] (3) Mark the end of the keyword: After inserting the complete keyword, mark the end of the keyword on the node of the last character using a special flag is_end_of_word=True.

[0096] (4) Searching for keywords: When searching for keywords, start from the root node and check each character one by one. If the character is in a child node of the current node, move to that child node; otherwise, the keyword does not exist.

[0097] (5) Traverse the ART tree: Use depth-first search to traverse the ART tree to obtain all relevant keywords.

[0098] In S2.2(2), the specific steps for finding log files within a specific time range are as follows:

[0099] (1) Store the timestamp of each log file as the key and the relevant information of the log file (filename, storage path) as the value in the ART tree. Whenever a new log file is generated, insert its timestamp and relevant information into the ART tree.

[0100] (2) Starting from the root node of the ART tree, traverse the nodes of the tree level by level according to the time range of the query (start time and end time) and the comparison rules of the timestamp.

[0101] (3) When a node is reached, further determine whether it is necessary to continue traversing the child nodes based on the range of timestamps.

[0102] (4) If the condition is not met, continue to traverse the left or right child nodes until a log file that meets the time range condition is found.

[0103] (5) Repeat this process until all log files that meet the conditions are found. The time complexity of the query is usually O(logN+M), where N is the height of the tree and M is the number of log files that meet the time range conditions.

[0104] S2.3: After the query is completed, the contract will record the requester's address, query request, and timestamp in the query array for subsequent record comparison.

[0105] See attached document Figure 3 As shown, in step S2, the specific steps for the system to call the access control contract to verify the user's identity are as follows:

[0106] S3.1: Define user, environment, and resource attributes

[0107] User attributes: Regular user, Administrator, Auditor.

[0108] Resource attributes: device type, sensitivity level, timestamp.

[0109] Environmental conditions: based on contextual information, such as time and geographical information.

[0110] S3.2: Define access policies: Match user attributes, environmental conditions, and log data attributes to determine whether access permissions are granted.

[0111] S3.2.1: Non-sensitive logs: All user types (regular users, administrators, auditors) can use non-sensitive logs. These logs typically do not contain sensitive information, such as system startup and shutdown logs, routine activity records, and general errors. They are helpful for troubleshooting and understanding the system's operating status, therefore all users can access them without specific environmental requirements.

[0112] S3.2.2: Sensitive Logs: Regular users can access portions of sensitive logs, such as records of their logins and data accesses. Due to the sensitivity of these logs, regular users can only access them during specific time periods. Administrators and auditors have full access to sensitive logs for monitoring and auditing user behavior. Highly sensitive logs may include user login records, data access records, and file operation records, and have no specific environmental requirements for regular users and administrators.

[0113] S3.2.3: Highly Sensitive Logs: Only administrators can access highly sensitive logs. These logs may contain sensitive information, therefore access restrictions need to be imposed to ensure that only authorized personnel can view them. Highly sensitive logs may include user actions on sensitive data, authentication information, and have no specific environmental requirements.

[0114] S3.3: Smart Contract Creation: A smart contract was written based on user and resource attribute verification conditions and to authorize or deny access permissions according to policies. This smart contract was then deployed to the blockchain network. To build an attribute-based access control system, several key contract modules were utilized, including the Attribute Information Management Contract (AIMC), the Access Control Management Contract (ACMC), and the Policy Management Contract (PMC).

[0115] S3.3.1: Attribute Information Management Contract: The AIMC attribute contract encompasses three important functions: user attribute management, resource attribute management, and environment attribute management. Through its interaction interface with access control, this contract not only effectively manages attribute values ​​but also enables continuous updates to attribute information. The AIMC interface provides access control with crucial data, allowing it to retrieve various attribute values ​​and maintain real-time updates to attribute information as the context changes.

[0116] S3.3.2: Access Control Contract: The ACMC access control contract fulfills three key functions: collecting access requests, initiating the decision-making process, and implementing policies. During policy execution, the contract receives the policy, access request, and current attribute values ​​as input, evaluates them, and generates a corresponding access decision, which may be to allow, deny, or handle the situation in an indeterminate manner.

[0117] S3.3.3: Strategy Management Contract: The PMC strategy management contract acts as the key implementer of strategy management and strategy storage. Regarding strategy management, the inherent immutability of smart contracts once deployed to the blockchain prevents direct modification. Therefore, an upgrade mechanism is introduced in the contract design. This mechanism is embedded in the contract code and manifests as an upgrade function. When an update is needed, this function can be called to replace the original version with entirely new contract code. Thus, deployed contracts are refreshed and smoothly migrated to the updated version. For strategy storage, each access strategy is compiled into an access strategy table to achieve orderly storage and convenient management of strategies.

[0118] S3.4: Smart Contract Deployment: Deploy attribute information management contracts, access control contracts, and policy management contracts to the blockchain network.

[0119] S3.5: Smart Contract Trigger: A user issues an access request to the access control module, triggering the execution of the access control contract. The user's access request includes user identity and query requirements (such as keywords and time). During this process, the access control contract interacts with the attribute information management contract and the policy management contract. The access control contract calls the attribute information management contract to obtain information about user attributes, resource attributes, and environment attributes. Simultaneously, it interacts with the policy management contract to obtain the corresponding access policies. Through these interactions, the access control contract can make accurate access control decisions based on user attributes, resource attributes, and environment attributes, combined with predefined policies.

[0120] S3.6: Smart Contract Verification: The smart contract first verifies the user's identity and attributes, as well as the attributes of the resource, to ensure the legitimacy of the request. Then, based on the user's attributes and the requested resource attributes, it verifies whether the access request conforms to the access policy and checks whether there are dynamic access policies, such as access time ranges or access under specific conditions.

[0121] S3.7: Access Authorization and Access Record Creation: If verification is successful, the smart contract will grant the user access rights and create an access record on the blockchain. The access record will include the user ID, resource ID, timestamp, and access result information. This record is added to a new block on the blockchain to ensure its immutability.

[0122] S3.8: Dynamic access policy update: When user attributes or resource attributes change, the access policy can be dynamically updated as needed.

[0123] S3.9: Resource Access: After obtaining access rights, the user invokes the query contract to request data access based on the obtained authorization token.

[0124] The specific embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A blockchain-based method for secure log storage and efficient querying, characterized in that: The specific steps of the method are as follows: S1: Encryption and Keyword Extraction of Log Data: Log Generator LogGen sends the collected log data DataLD to Log Server LogSer. The two parties use DH key negotiation to establish a secure data transmission communication channel and obtain the negotiation key NK. After receiving the log data, LogSer uses SM4 to encrypt and save it. Then, it uses TF-IDF extraction technology to calculate the weight W of each word in the file. Finally, the extracted keywords are used to build an inverted index table and saved to the blockchain. The timestamp, data hash fingerprint, and resource-permission mapping table are also uploaded to the chain. S2: Log Data Query Processing: Data requesters, i.e., users, publish query requests to the blockchain in the form of transactions. The system calls the access control contract to verify the user's identity. After verification by the access control contract, an authorization token (AuthToken) is obtained. Then, the system calls the query smart contract (ESMC) to process the query request. The adaptive prefix tree (ART) is used as the data structure to store index items. Each keyword and information in the inverted index table is traversed. The query methods include multi-keyword query and time range query, thus providing efficient query functions. Finally, when the system queries, it also needs to check the permission-resource mapping table to check whether the user has access permissions. The contract records the user's address, query request, and timestamp in the query array for subsequent record comparison. S3: Creation and Deployment of Smart Contracts: First, deploy the Attribute Information Management Contract (AIMC), which includes user attributes and resource attributes. Then, deploy the Policy Management Contract (PMC) to effectively manage access policies. Different users have different permissions. Finally, deploy the Access Control Contract (ACMC) to verify the matching between user attributes and policies, and then decide whether to grant access permissions. When a user publishes an access request, the access control contract is called to query the resource-permission mapping table on the chain to verify the user's identity. All access behaviors are recorded, and these records are used for auditing and tracing. The specific steps for multi-keyword query include: (1) Initialize the ART tree: Create a root node, which is usually an empty node; (2) Insert keywords: Insert keywords one by one, starting from the root node. For each keyword character, check if a child node with the same character already exists. If it does, move to that child node; otherwise, create a new child node and move to that child node. (3) Mark the end of the keyword: After inserting the complete keyword, mark the end of the keyword on the node of the last character, using a special flag is_end_of_word=True; (4) Search keywords: When searching for keywords, start from the root node and check each character one by one; if the character is in a child node of the current node, move to that child node; otherwise, the keyword does not exist; (5) Traverse the ART tree: Use depth-first search to traverse the ART tree to obtain all relevant keywords; The specific steps for querying the time range are as follows: (1) Use the timestamp of each log file as the key and store the relevant information of the log file as the value in the ART tree. Whenever a new log file is generated, insert its timestamp and relevant information into the ART tree. (2) Starting from the root node of the ART tree, traverse the nodes of the tree level by level according to the time range of the query and the comparison rules of the timestamp; (3) When a node is reached, further determine whether it is necessary to continue traversing the child nodes based on the range of timestamps; (4) If the condition is not met, continue to traverse the left or right child nodes until a log file that meets the time range condition is found; (5) Repeat this process until all log files that meet the conditions are found. The time complexity of the query is usually O(logN+M), where N is the height of the tree and M is the number of log files that meet the time range conditions.

2. The method for secure storage and efficient querying of logs based on blockchain according to claim 1, characterized in that, The specific steps of S1 are as follows: S1.1: LogGen collects all log data and saves the aggregated log data to the log server, establishing a secure communication channel. (1) First, calculate the negotiation key between LogGen and LogSer: (1) (2) The log generator obtains the negotiation key through formula (1). Similarly, the log server obtains the negotiation key through formula (2). And the conditions must be met. Therefore, both parties obtained the same key through negotiation, thus achieving the purpose of key negotiation. It is a prime number. It is a prime number The root of the random number generator is A, which is the private random number generator of the log generator, and B is the private random number generator of the log server. , ; (2) Then encrypt the negotiation key NK with the DataLD to be sent to obtain the ciphertext C=Enc(NK, DataLD); S1.2: After receiving the log data sent by LogGen, LogServer first decrypts the ciphertext Den(NK, DataLD) to obtain the plaintext. Then, it encrypts the data by generating a random key using a pseudo-random number generator PRNG and using the original data as input, then encrypts it using SM4 to obtain the ciphertext C, expressed by the formula: (3) in, Indicates ciphertext, It is plaintext log data, and K is a random key; S1.3: First, the collected log data is preprocessed, including assigning appropriate permission tags to the data and removing irrelevant information such as stop words and punctuation marks. Then, the TF-IDF keyword extraction algorithm is used to extract keywords from the documents. The TF-IDF model finds words that appear frequently in a document but rarely in the entire document collection, expressed by the formula: (4) in For keywords In the document Frequency of occurrence in For containing keywords The document in the corpus document The number of times it appears in; S1.4: Construct an inverted index table using the keywords extracted by the TF-IDF algorithm. Each word has an associated list containing all documents containing that word, the start time StartT and end time EndT of each document, and the list is sorted in descending order of TF-IDF values. S1.5: Upload the inverted index table to the blockchain storage. The index table and blocks are generated together. The blocks contain metadata inverted index table, log record start time, data hash fingerprint, and resource permission mapping table.

3. The method for secure storage and efficient querying of logs based on blockchain according to claim 2, characterized in that, The specific steps of S2 include: S2.1: The user first publishes an access request AR, which is uploaded to the blockchain in the form of a transaction. The access control contract is called to query the resource-permission table to verify the user's identity and permissions. After successful verification, an authorization token is returned. S2.2: Call ESMC, uploading AR and AuthToken as parameters. ESMC executes the query based on the user's query request. The user's query methods include multi-keyword query and time range query. The KMP fuzzy matching algorithm is used for fuzzy search, which can match abbreviations and word roots. (1) Multi-keyword query: Adaptive prefix tree is used as the data structure. When querying, the query contract automatically constructs an adaptive prefix tree ART based on the inverted index table to realize multi-keyword query; (2) Time range query: If you want to know the log records that occurred within a certain time period, you can select to query the log records by time range according to the time you need to query the log records. After the query requester publishes the query request, the system calls ESMC to automatically build ART to execute the query. After executing the query request, all relevant log records within the range are returned, and then records that are not authorized to be accessed are filtered according to the user's identity. S2.3: After the query is completed, the contract will record the requester's address, query request, and timestamp in the query array for subsequent record comparison.

4. The method for secure storage and efficient querying of logs based on blockchain according to claim 1, characterized in that, In step S2, the specific steps for the system to call the access control contract to verify the user's identity are as follows: S3.1: Define user, environment, and resource attributes User attributes: Regular user, Administrator, Auditor; Resource attributes: Device type, sensitivity level, timestamp; Environmental conditions: based on contextual information, including time and geographical information; S3.2: Define access policies: Match user attributes and environmental conditions with log data attributes to determine whether access permissions are granted; S3.3: Smart Contract Creation: Based on the user and resource attribute verification conditions and according to policies for authorizing or denying access, a smart contract was written and then deployed to the blockchain network. To build an attribute-based access control system, several key contract modules were used, including the Attribute Information Management Contract (AIMC), the Access Control Management Contract (ACMC), and the Policy Management Contract (PMC). S3.4: Smart Contract Deployment: Deploy the attribute information management contract, access control contract, and policy management contract to the blockchain network; S3.5: Smart Contract Trigger: When a user publishes an access request to the access control module, the execution of the access control contract is triggered. The access request published by the user includes the user's identity and query requirements. During this process, the access control contract interacts with the attribute information management contract and the policy management contract. The access control contract calls the attribute information management contract to obtain relevant information about user attributes, resource attributes, and environment attributes. At the same time, it also interacts with the policy management contract to obtain the corresponding access policy. Through these interactions, the access control contract can make accurate access control decisions based on user attributes, resource attributes, and environment attributes, combined with predefined policies. S3.6: Smart Contract Verification: The smart contract first verifies the user's identity and attributes, as well as the attributes of the resource, to ensure the legality of the request. Then, based on the user's attributes and the requested resource attributes, it verifies whether the access request conforms to the access policy and checks whether there are dynamic access policies, such as access time ranges or access under specific conditions. S3.7: Access Authorization and Access Record Creation: If the verification is successful, the smart contract will grant the user access rights and create an access record on the blockchain. The access record will include the user ID, resource ID, timestamp, and access result information. This record is added to a new block of the blockchain to ensure its immutability. S3.8: Dynamic access policy update: When user attributes or resource attributes change, the access policy can be dynamically updated as needed; S3.9: Resource Access: After obtaining access rights, the user invokes the query contract to request data access based on the obtained authorization token.

5. The method for secure storage and efficient querying of logs based on blockchain according to claim 4, characterized in that, The specific steps of S3.2 are as follows: S3.2.1: Non-sensitive logs: All user types can use non-sensitive logs. These logs do not contain sensitive information, are accessible to all users, and have no specific environmental requirements. S3.2.2: Sensitive Logs: Ordinary users can access a portion of the sensitive logs, including their own login and access data. Due to the sensitivity of the logs, ordinary users can only log in and access them within a specific time period. Administrators and auditors can access the sensitive logs in their entirety in order to monitor and audit user behavior. Highly sensitive logs involve user login records, data access records, and file operation records. There are no specific environmental requirements for ordinary users and administrators. S3.2.3: Highly Sensitive Logs: Only administrators can access highly sensitive logs. These logs contain sensitive information, so access restrictions need to be imposed to ensure that only authorized personnel can view them. Highly sensitive logs include user operations on sensitive data, authentication information, and payment data. There are no specific environmental requirements.

6. The method for secure storage and efficient querying of logs based on blockchain according to claim 4, characterized in that, The specific details of the attribute information management contract AIMC, access control management contract ACMC, and policy management contract PMC in S3.3 are as follows: S3.3.1: Attribute Information Management Contract AIMC: The AIMC attribute contract covers three important functions: user attribute management, resource attribute management, and environment attribute management. Through the interaction interface with access control, this contract can not only effectively manage attribute values, but also realize the continuous updating of attribute information. The AIMC interface provides key data for access control, enabling it to retrieve various attribute values ​​and keep the attribute information updated in real time as the context changes. S3.3.2: Access Control Contract ACMC: The ACMC access control contract performs three key functions: collecting access requests, initiating the decision-making process, and implementing policies. In the policy execution phase, the contract receives the policy, access request, and current attribute value as input, and after evaluation, generates a corresponding access decision, which is to allow, deny, or handle in an indeterminate manner. S3.3.3: Strategy Management Contract (PMC): The PMC strategy management contract acts as the key implementer of strategy management and strategy storage. In terms of strategy management, since the inherent immutability of smart contracts once deployed to the blockchain makes it impossible to directly modify the contract, an upgrade mechanism is introduced when designing the contract. This mechanism is contained in the contract code and is specifically manifested as an upgrade function. When the contract needs to be updated, this function is called to replace the original version with a brand-new contract code. Thus, the deployed contract is refreshed and smoothly migrates to the updated version. For strategy storage, each access strategy is compiled into an access strategy table to achieve orderly storage and convenient management of strategies.

Images