Log management method and device

Abstract

This application provides a log management method and apparatus, applicable to the field of blockchain technology. The log management method includes: querying the log types accessible to a transaction user based on the user's role; querying the access policy and key parameters of that log type on the blockchain based on the accessible log type; generating a first key based on the key parameters of that log type; obtaining a first random number generated by the application server of the transaction user; generating a first calculation factor and a second calculation factor based on the first random number and the key parameters; and sending the first calculation factor and the second calculation factor to the application server. This application provides a log management method and apparatus that solves the problems of existing log management methods failing to differentiate between all transaction users on the blockchain and failing to anonymize sensitive data.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a log management method and apparatus. Background Technology

[0002] The typical log management process in blockchain involves recording node operation logs, important transaction logs (time, transaction content, transaction IP, operation type), and error information. These logs are then archived offline or online and centrally managed in a log center for backup. All transaction users can obtain the complete transaction logs through the console or by calling interfaces provided by the blockchain itself.

[0003] As the construction of blockchain digital scenarios is gradually promoted, more and more scenarios need to be audited for security. However, the existing log management does not distinguish all transaction users on the blockchain, and sensitive data is not anonymized, especially personal information data, which is not encrypted as necessary. As a result, its logs do not meet the industry's data classification and processing rules and the legal requirements for personal information protection. Summary of the Invention

[0004] In view of the problems in the prior art, the embodiments of this application provide a log management method and apparatus, which can at least partially solve the problems existing in the prior art.

[0005] In a first aspect, embodiments of this application provide a log management method, including:

[0006] Based on the user's role, query the types of logs that the user can access;

[0007] Based on the log type that the transaction user can access, query the access policy and key parameters of that log type on the chain;

[0008] Generate a first key based on the key parameters of this type of log;

[0009] Obtain the first random number generated by the application server of the transaction user;

[0010] Based on the first random number and the key parameters, a first calculation factor and a second calculation factor are generated;

[0011] The first calculation factor and the second calculation factor are sent to the application server. The application server generates a second key based on the first calculation factor, the second calculation factor, and the first random number. It uses the second key to encrypt the access policy of the logs accessible to the transaction user, the first calculation factor, and the second calculation factor to obtain a log management key. The application server then uses the log management key to manage the logs. The second key is consistent with the first key.

[0012] In some embodiments, generating the first key based on the key parameters of the log type includes:

[0013] The first key is generated based on the random number from the requesting log access party, the random number from the log encryption party, the first common parameter, and the second common parameter.

[0014] In some embodiments, generating a first calculation factor and a second calculation factor based on the first random number and the key parameters includes:

[0015] The first calculation factor is generated based on the random number from the log encryptor, the first common parameter, and the second common parameter.

[0016] A second calculation factor is generated based on the first random number, the random number from the requesting log access party, the random number from the log encryption party, and the second common parameter.

[0017] In some embodiments, after obtaining the log management key, the method further includes:

[0018] The log management key is signed using the transaction user's private key to obtain an encryption key;

[0019] The encryption key is sent to the blockchain network for on-chain endorsement.

[0020] Secondly, embodiments of this application provide a log management method, including:

[0021] Execute transactions and generate transaction logs based on the transaction requests from users;

[0022] Obtain the access policy, encryption policy, and key parameters corresponding to the log type of the transaction log;

[0023] Generate a first key based on the key parameters;

[0024] According to the encryption strategy, the target field in the transaction log is encrypted using the first key to generate an encrypted log;

[0025] The first key, the encrypted log, and the attribute information corresponding to the access policy are sent to the log management server. The log management server is used to encrypt the attribute information using the first key to generate attribute ciphertext, and add the attribute ciphertext as an attribute of the encrypted log.

[0026] In some embodiments, the method further includes:

[0027] The transaction log type is sent to the log management server, which then saves the encrypted log as a log file conforming to the naming convention according to the log type.

[0028] Thirdly, embodiments of this application provide a log management method, including:

[0029] Retrieve encrypted logs of the target type from the log management server;

[0030] A second random number is generated and sent to a blockchain network, which is used to generate a first calculation factor and a third calculation factor based on the second random number and the key parameters of the log file of the target type.

[0031] A third key is generated based on the first calculation factor, the third calculation factor, and the second random number;

[0032] The locally stored log management key is decrypted using the third key to obtain the access policy, the first calculation factor, and the second calculation factor;

[0033] A first key is generated based on the first calculation factor, the second calculation factor, and the first random number stored locally.

[0034] If the first key and the third key are the same, the third key is used to decrypt the attribute ciphertext of the encrypted log to obtain the attribute information in the access policy of the encrypted log.

[0035] If the attribute information matches the access policy, the third key is used to decrypt the encrypted log content to obtain the plaintext log.

[0036] Fourthly, embodiments of this application provide a log management device, including:

[0037] The first query module is used to query the types of logs that a trading user can access based on the user's role.

[0038] The second query module is used to query the access policy and key parameters of the log type that the transaction user can access on the chain.

[0039] The first generation module is used to generate a first key based on the key parameters of this type of log.

[0040] The first acquisition module is used to acquire a first random number generated by the application server of the transaction user;

[0041] The second generation module is used to generate a first calculation factor and a second calculation factor based on the first random number and the key parameters.

[0042] The first sending module is used to send the first calculation factor and the second calculation factor to the application server. The application server is used to generate a second key based on the first calculation factor, the second calculation factor and the first random number, and use the second key to encrypt the access policy of the logs accessible to the transaction user, the first calculation factor and the second calculation factor to obtain a log management key, and use the log management key to perform log management, wherein the second key is consistent with the first key.

[0043] In some embodiments, the first generation module is specifically used for:

[0044] The first key is generated based on the random number from the requesting log access party, the random number from the log encryption party, the first common parameter, and the second common parameter.

[0045] In some embodiments, the second generation module is specifically used for:

[0046] The first calculation factor is generated based on the random number from the log encryptor, the first common parameter, and the second common parameter.

[0047] A second calculation factor is generated based on the first random number, the random number from the requesting log access party, the random number from the log encryption party, and the second common parameter.

[0048] In some embodiments, the apparatus further includes:

[0049] The signature module is used to sign the log management key using the transaction user's private key to obtain an encryption key;

[0050] The first sending module is also used to send the encryption key to the blockchain network for on-chain endorsement.

[0051] Fifthly, embodiments of this application provide a log management device, including:

[0052] The execution module is used to execute transactions and generate transaction logs based on the transaction requests from trading users.

[0053] The second acquisition module is used to acquire the access policy, encryption policy and key parameters corresponding to the log type of the transaction log;

[0054] The third generation module is used to generate the first key based on the key parameters;

[0055] An encryption module is used to encrypt target fields in the transaction log using the first key according to the encryption strategy, thereby generating an encrypted log;

[0056] The second sending module is used to send the first key, the encrypted log, and the attribute information corresponding to the access policy to the log management server. The log management server is used to encrypt the attribute information using the first key to generate attribute ciphertext and add the attribute ciphertext as an attribute of the encrypted log.

[0057] In some embodiments, the second sending module is further configured to:

[0058] The transaction log type is sent to the log management server, which then saves the encrypted log as a log file conforming to the naming convention according to the log type.

[0059] Sixthly, embodiments of this application provide a log management device, including:

[0060] The third acquisition module is used to obtain encrypted logs of the target type from the log management server;

[0061] The fourth generation module is used to generate a second random number and send it to the blockchain network. The blockchain network is used to generate a first calculation factor and a third calculation factor based on the second random number and the key parameters of the log file of the target type.

[0062] The fifth generation module is used to generate a third key based on the first calculation factor, the third calculation factor, and the second random number;

[0063] The first decryption module is used to decrypt the locally stored log management key using the third key to obtain the access policy, the first calculation factor, and the second calculation factor.

[0064] The sixth generation module is used to generate a first key based on the first calculation factor, the second calculation factor, and the first random number stored locally.

[0065] The second decryption module is used to decrypt the attribute ciphertext of the encrypted log using the third key if the first key and the third key are consistent, so as to obtain the attribute information in the access policy of the encrypted log.

[0066] The third decryption module is used to decrypt the log content of the encrypted log using the third key if the attribute information matches the access policy, thereby obtaining the plaintext log.

[0067] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the log management method described in any of the above embodiments.

[0068] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the log management method described in any of the above embodiments.

[0069] The log management method and apparatus provided in this application embodiment query the log types accessible to the trading user based on the trading user's user role; query the access policy and key parameters of the log type accessible to the trading user on the blockchain based on the log type accessible to the trading user; generate a first key based on the key parameters of the log type; obtain a first random number generated by the trading user's application server; generate a first calculation factor and a second calculation factor based on the first random number and the key parameters; send the first calculation factor and the second calculation factor to the application server, the application server is used to generate a second key based on the first calculation factor, the second calculation factor and the first random number, use the second key to encrypt the access policy of the log accessible to the trading user, the first calculation factor and the second calculation factor to obtain a log management key, and use the log management key to perform log management, wherein the second key is consistent with the first key. In this way, according to the requirements of the KP-ABE attribute encryption algorithm, the logs are first classified, the log attributes and access policies are defined, and then the access policies are written into the keys held by the transaction users. Multiple parameters are required to generate symmetric keys (first key and second key). The keys are kept by the encryption and decryption parties (nodes of the blockchain network and off-chain transaction users) respectively to support the subsequent log management process. Attached Figure Description

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

[0071] Figure 1 This is a schematic diagram of the structure of a log management system provided in an embodiment of this application.

[0072] Figure 2 This is a flowchart illustrating a log management method provided in an embodiment of this application.

[0073] Figure 3 This is a schematic diagram of the Diffie-Hellman algorithm provided in one embodiment of this application.

[0074] Figure 4 This is a partial flowchart of a log management method provided in an embodiment of this application.

[0075] Figure 5 This is a flowchart illustrating a log management method provided in an embodiment of this application.

[0076] Figure 6 This is a flowchart illustrating a log management method provided in an embodiment of this application.

[0077] Figure 7 This is a flowchart illustrating a log management method provided in an embodiment of this application.

[0078] Figure 8 This is a schematic diagram of the permission levels of various types of logs provided in an embodiment of this application.

[0079] Figure 9 This is a flowchart illustrating a log management method provided in an embodiment of this application.

[0080] Figure 10 This is a flowchart illustrating a log management method provided in an embodiment of this application.

[0081] Figure 11 This is a schematic diagram of the structure of a log management device provided in an embodiment of this application.

[0082] Figure 12 This is a schematic diagram of the structure of a log management device provided in an embodiment of this application.

[0083] Figure 13 This is a schematic diagram of the structure of a log management device provided in an embodiment of this application.

[0084] Figure 14 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0085] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily arranged.

[0086] The terms “first,” “second,” etc., used in this document are not intended to specifically refer to order or sequence, nor are they used to limit this application; they are merely used to distinguish elements or operations described using the same technical terms.

[0087] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0088] The term "and / or" as used in this document includes any or all of the items mentioned.

[0089] The execution subject of the log management method provided in this application embodiment includes, but is not limited to, a computer.

[0090] To better understand this application, the research background of this application will be introduced in detail below.

[0091] KP-ABE (Key-Policy ABE) embeds the policy into the user's key and the attributes into the ciphertext. The key corresponds to an access structure, and the ciphertext corresponds to a set of attributes. Decryption occurs if and only if the attributes in the set satisfy the access policy. This design is closer to a static scenario, where the ciphertext is encrypted with its associated attributes and stored on the server. When a user is allowed to access certain messages, a specific access policy is assigned to the user. Its application scenarios are more inclined towards paid video websites, encrypted log management, etc. If a user wants to decrypt multiple files, they must possess multiple matching keys; otherwise, multiple files cannot be decrypted.

[0092] The Diffie-Hellman algorithm is a public-key algorithm in which two communicating parties calculate a shared key by exchanging some data without transmitting the key itself.

[0093] This application introduces the KP-ABE attribute encryption algorithm and the Diffie-Hellman algorithm to provide solutions for access control and content security of blockchain logs. The detailed technical solutions are as follows:

[0094] Please refer to Figure 1 As shown, the blockchain log management system can include the following four parts: application server 1, key creation server 2, log management server 3, and blockchain network 4. Application server 1 includes a transaction system that calls smart contracts to access blockchain network 4 and an authorization system for the blockchain node's affiliated institution to access log management server 3; key creation server 2 is a key creation service cluster that creates keys for various application systems to access blockchain network 4 and log management server 3; log management server 3 is a log management center cluster responsible for managing blockchain system operation logs, important transaction logs, transaction error logs, etc.

[0095] Figure 2 This is a flowchart illustrating a log management method provided in an embodiment of this application, as shown below. Figure 2 As shown in the embodiment of this application, the log management method can be applied to key creation server 2, and the method includes:

[0096] S101. Based on the user role of the trading user, query the log types that the trading user can access;

[0097] Before step S101, an organization applying to join blockchain network 4 can send its application to blockchain network 4; the affiliated users of each node in blockchain network 4 vote on the application to join, confirming the application of the applying organization; according to the application content of the applying organization, the organization's transaction users are assigned, and identity authentication certificates and corresponding public and private key pairs are issued to the transaction users through the blockchain's own CA node or the key generation server 2 that integrates CA certificate issuance SDK.

[0098] In step S101, the log types that the applicant can access are determined based on the applicant's transaction user role.

[0099] S102. Based on the log type that the transaction user can access, query the access policy and key parameters of that log type on the chain.

[0100] In step S102, the access policy for that type of log on the chain is queried based on the log type. If a new log type is added, the system administrator needs to pre-define the access policy, call the system smart contract, and endorse and store the policy on the chain.

[0101] For example, blockchain logs can be divided into system operation logs, important transaction logs, and error logs. Important transaction logs have high access permissions, system operation logs have medium access permissions, and error logs have low access permissions. The attributes of the three types of logs include attributes A, B, C, and D. The access policy can be formulated as shown in Table 1 below:

[0102] Table 1: Log Access Policy

[0103] Log types Log permission levels Related attributes Attribute threshold Important Transaction Log high A, B, C, D (AΛB)Λ(CVD) System operation log middle A, B AΛB Error Log Low C, D CVD

[0104] Where: AΛB means that the attributes of A and B are satisfied;

[0105] CVD indicates that either property C or D is satisfied;

[0106] (AΛB)Λ(CVD) means that both attributes A and B are satisfied, and either attribute C or D is also satisfied.

[0107] Similarly, based on the log type, query the key parameters used for encryption and decryption of logs of that type on the chain. If a new log type is added, all key parameters must be randomly generated in advance.

[0108] S103. Generate a first key based on the key parameters of this type of log;

[0109] S104. Obtain the first random number generated by the application server of the transaction user;

[0110] S105. Generate a first calculation factor and a second calculation factor based on the first random number and the key parameters;

[0111] S106. The first calculation factor and the second calculation factor are sent to the application server. The application server is used to generate a second key based on the first calculation factor, the second calculation factor and the first random number, and use the second key to encrypt the access policy of the logs accessible to the transaction user, the first calculation factor and the second calculation factor to obtain a log management key, and use the log management key to perform log management, wherein the second key is consistent with the first key.

[0112] In steps S103 to S106, the key generation server 2 generates a first key based on the key parameters of this type of log, and generates a first calculation factor and a second calculation factor based on the first random number generated by the application server of the transaction user and the key parameters, so that the application server generates a second key consistent with the first key on the chain based on the first calculation factor, the second calculation factor and the first random number, and uses the second key to encrypt the access policy of the logs accessible to the transaction user, the first calculation factor and the second calculation factor, to obtain a log management key that can be used for log access permissions and log content decryption.

[0113] The log management method provided in this application, according to the requirements of the KP-ABE attribute encryption algorithm, first classifies the logs, defines the log attributes and access policies, and then writes the access policies into the keys held by the transaction users. It also requires multiple parameters to generate symmetric keys (first key and second key). The keys are kept by the encryption and decryption parties (nodes of the blockchain network and off-chain transaction users) respectively to support the subsequent log management process.

[0114] In some embodiments, generating the first key based on the key parameters of the log type includes: generating the first key based on the random number of the requesting log access party, the random number of the log encrypting party, the first common parameter, and the second common parameter.

[0115] Specifically, for each log, if the log has multiple accessors, each accessor generates a random number A, and then the encryptor generates a random number B. The random numbers are all different, in order to enable both parties to calculate a common key using the random numbers, the common parameter prime number m, and the integer g.

[0116] This can be based on the principles of the Diffie-Hellman algorithm (see reference). Figure 3The Diffie-Hellman algorithm diagram shown uses a random number A from the requesting log access party, a random number B from the log encryptor, a common prime number m, and an integer g to generate the first key K, i.e.:

[0117] K = g AB modm.

[0118] like Figure 4 As shown, in some embodiments, generating a first calculation factor and a second calculation factor based on the first random number and the key parameters includes:

[0119] S1051. Generate a first calculation factor based on the random number from the log encryptor, the first common parameter, and the second common parameter;

[0120] S1052. Generate a second calculation factor based on the first random number, the random number from the requesting log access party, the random number from the log encryption party, and the second common parameter.

[0121] Specifically, to enhance the security of random numbers, the random number A requested by the log access party is regenerated by the application server, i.e., A1. A1 can be required to have one less bit than A. If the random number A1 is inconsistent with the pre-generated random number A, then the second calculation factor Y1 of the original key (i.e., the first key K) obtainable by the application server needs to be recalculated. The first calculation factor Y is calculated based on the pre-generated random number on the chain. The calculation formula is:

[0122] Y = g B modm;

[0123] Y1 = g (A-A1)B .

[0124] Accordingly, the application server is used to generate a second key based on the first calculation factor, the second calculation factor, and the first random number. Specifically, the application server 1 obtains the first calculation factor Y and the second calculation factor Y1 of the first key K, and simultaneously stores the previously generated first random number A1 locally. It can calculate and obtain the key K that is consistent with the one on the chain. The calculation formula is:

[0125] K = Y A1 *Y1=g A1B *g (A-A1)B modm = g (A1+A-A1)B modm = g AB modm

[0126] The first calculation factor Y and the second calculation factor Y1, as well as the attribute policy for log access, are encrypted using this key to form a new key K1 (i.e., the log management key).

[0127] In some embodiments, after obtaining the log management key, the method further includes: signing the log management key using the transaction user's private key to obtain an encryption key; and sending the encryption key to the blockchain network for on-chain endorsement.

[0128] Specifically, the log management key K1 is signed with the private key of the blockchain transaction user's identity authentication CA, and then stored on the blockchain with endorsement.

[0129] Figure 5 This is a flowchart illustrating a log management method provided in an embodiment of this application, as shown below. Figure 5 As shown in the embodiments of this application, the log management method can be applied to a 4-node blockchain network. The method includes:

[0130] S201. Execute the transaction and generate a transaction log based on the transaction user's transaction request;

[0131] In step S201, application server 1 can use the identity authentication certificate issued by the transaction user and CA to initiate the call to the on-chain smart contract and request the execution of the transaction; after receiving the request to call the smart contract, the node of blockchain network 4 performs the endorsement and block writing operations to complete the transaction process; during the transaction, relevant transaction logs will be generated, including detailed operation logs of important transactions, system logs of blockchain node operation, and error logs when transactions fail.

[0132] S202. Obtain the access policy, encryption policy, and key parameters corresponding to the log type of the transaction log;

[0133] In step S202, based on the log type, the system smart contract is queried to obtain the pre-defined log access policy and key parameters on the chain. The key parameters may include a random number A, a random number B, a common prime number m, and an integer g.

[0134] S203. Generate a first key according to the key parameters;

[0135] S204. According to the encryption strategy, the target field in the transaction log is encrypted using the first key to generate an encrypted log;

[0136] S205. The first key, the encrypted log, and the attribute information corresponding to the access policy are sent to the log management server. The log management server is used to encrypt the attribute information using the first key to generate attribute ciphertext and add the attribute ciphertext as an attribute of the encrypted log.

[0137] In steps S203 to S205, a first key is generated according to the key parameters. Based on the encryption policy corresponding to the log type, the first key is used to encrypt the fields that need to be encrypted in the transaction log, such as the ID card number, authentication password, name, and address in the personal information field. The first key, the encrypted log message, the log type, and the attributes corresponding to the log policy are transmitted to the log management server 3. The log management server 3 uses the first key to encrypt the attributes corresponding to the log policy into ciphertext M, modifies the attributes of the log file, and adds the M attribute.

[0138] The log management method provided in this application relies on log type, log access policy attributes, first key, etc. Different log types require hierarchical and classified encryption of different fields, which solves the problem that existing log management methods do not distinguish all transaction users of the blockchain and do not perform anonymization processing on sensitive data.

[0139] In some embodiments, the method further includes: sending the log type of the transaction log to a log management server, wherein the log management server is used to save the encrypted log as a log file conforming to a naming convention according to the log type. Specifically, each type of log can be generated according to the log naming convention, for example, the detailed operation log of important transactions is named app_xxxxxxxx.log, the system operation log is named sys_xxxxxxxx.log, and the error log is named error_xxxxxxxx.log.

[0140] Figure 6 This is a flowchart illustrating a log management method provided in an embodiment of this application, as shown below. Figure 6 As shown in the embodiments of this application, the log management method can be applied to application server 1, and the method includes:

[0141] S301. Obtain encrypted logs of the target type from the log management server;

[0142] In step S301, the application server 1 of an organization initiates a request to obtain logs, transmits the request parameters of the interface call, and signs the request with the private key of the CA certificate used for identity authentication. After receiving the request, the blockchain network 4 verifies the identity of the user who initiated the transaction. Once the identity is verified, it requests the log management server 3 to obtain the logs. According to the request, the log management server 3 can push the required logs to the file server specified by the application server 1.

[0143] S302. Generate a second random number and send it to the blockchain network, wherein the blockchain network is used to generate a first calculation factor and a third calculation factor based on the second random number and the key parameters of the log file of the target type;

[0144] In step S302, application server 1 generates a second random number A2 to calculate the third key; blockchain network 4 queries the key parameters of this type of log and calculates the first calculation factor Y and the third calculation factor Y2 based on the second random number and the key parameters.

[0145] For example, if the key parameters include: random number A, random number B, common parameter prime number m, and integer g, then:

[0146] Y = g B modm;

[0147] Y2 = g (A-A2)B .

[0148] S303. Generate a third key based on the first calculation factor, the third calculation factor, and the second random number;

[0149] In step S303, application server 1 calculates the third key based on Y and Y2, for example, the third key = Y A2 ×Y2.

[0150] S304. Use the third key to decrypt the locally stored log management key to obtain the access policy, the first calculation factor, and the second calculation factor.

[0151] In step S304, the log management key K1 stored by application server 1 is decrypted to obtain the encrypted access policy and the first calculation factor Y and the second calculation factor Y1 within K1.

[0152] S305. Generate a first key based on the first calculation factor, the second calculation factor, and the first random number stored locally;

[0153] In step S305, the first key K is calculated based on the first calculation factor Y, the second calculation factor Y1, and the locally stored first random number A1, for example, K = Y A1 ×Y1.

[0154] S306. If the first key and the third key are the same, the third key is used to decrypt the attribute ciphertext of the encrypted log to obtain the attribute information of the encrypted log.

[0155] S307. If the attribute information matches the access policy, the third key is used to decrypt the log content of the encrypted log to obtain the plaintext log.

[0156] In steps S306 to S307, it is verified whether the third key and the first key are consistent; if they are consistent, the third key is used to decrypt the ciphertext of the log attribute, obtain the attribute value corresponding to the ciphertext, and match it with the attribute policy in K1.

[0157] For example, the plaintext attributes after decrypting the log attributes are: A, B, C.

[0158] The log attribute strategy is: (AΛB)Λ(CVD).

[0159] This indicates that the attribute matches the attribute policy, therefore the attribute policy has permission to access this log.

[0160] Use key K to decrypt the log content and parse it to obtain the full log plaintext.

[0161] The log management method provided in this application generates a third key by interacting with a blockchain network to obtain multiple parameters. This third key is then used to decrypt the ciphertext of the encrypted log's attributes to obtain attribute information from the access policy of the encrypted log. If the attribute information matches the access policy, the third key is used to decrypt the log content of the encrypted log to obtain the plaintext log, thus managing the log access process. Furthermore, the consistency between the third key and the first key is verified. This verifies the integrity of the KP-ABE attribute encryption policy and avoids the risk of user-held keys being lost and stolen.

[0162] According to the requirements of the KP-ABE attribute encryption algorithm, logs are first classified, log attributes and access policies are defined, and then the access policies are written into the keys held by the transaction users. Multiple parameters are required to generate symmetric keys (first key and second key). The keys are kept by the encryption and decryption parties (nodes of the blockchain network and off-chain transaction users) respectively to support the subsequent log management process.

[0163] To better understand this application, the log management method provided in this application will be described in detail below through a specific embodiment.

[0164] This application introduces the KP-ABE attribute encryption algorithm and the Diffie-Hellman algorithm to provide solutions for access control and content security of blockchain logs.

[0165] Please refer to Figure 7 As shown, the generated keys include two types: one is the identity certificate of the transaction user issued by the blockchain CA, and the other is the key for decrypting log content and granting log access permissions based on the identity certificate and log attributes.

[0166] The key creation principle is based on the requirements of the KP-ABE attribute encryption algorithm. First, logs are categorized, log attributes and access policies are defined, and then the access policies are written into the user-held key. In this embodiment, the key is generated using the Diffie-Hellman algorithm, requiring multiple computational factors to generate the symmetric key. The key is kept by both the encryption and decryption parties (nodes in the blockchain network and off-chain transaction users). The detailed key creation process is as follows:

[0167] Step 1: An organization applies to join the blockchain network and sends the application to blockchain network 4;

[0168] Step 2: The affiliated institutions of each node in Blockchain Network 4 vote on the application to join, confirming the application of a certain institution to join;

[0169] Step 3: Based on the application of an institution, allocate the institution's transaction users and issue identity authentication certificates and corresponding public and private key pairs to the transaction users through the blockchain's own CA node or key generation server 2 that integrates CA certificate issuance SDK;

[0170] Step 4: Based on the institution's transaction user role, determine the log types that the user can access, and then query the on-chain access policy for that log type. If there are new log types, the system administrator needs to pre-define the access policy, call the system smart contract, and endorse and store the policy on the chain.

[0171] like Figure 8 As shown, for example, blockchain logs are divided into system operation logs, important transaction logs, and error logs. Important transaction logs have high access permissions, system operation logs have medium access permissions, and error logs have low access permissions. The attributes of the three types of logs include attributes A, B, C, and D. The access policy is formulated as shown in Table 1.

[0172] Step 5: Based on the established log access policy on the blockchain, and the key parameters used for encrypting and decrypting the log type (random number A from the requesting log access party, random number B from the log encryptor, common parameters m and integer g), if a new log type is added, all key parameters must be pre-generated randomly. This is based on the principles of the Diffie-Hellman algorithm (see reference). Figure 3 The diagram shown illustrates the Diffie-Hellman algorithm. The random number A from the requesting log reader, the random number B from the log encryptor, the common parameter prime number m, and the integer g can be used to generate the first key K, i.e.:

[0173] K = g AB modm.

[0174] Step 6: To enhance the security of the random number, the random number A requested by the log access party is regenerated by the application server, i.e., A1, and A1 is required to have one less bit than A.

[0175] Step 7: If the random number A1 is inconsistent with the pre-made random number A, the calculation factor Y1 of the original key obtainable by the application server needs to be recalculated. Y is calculated based on the pre-made random number on the chain. The calculation formula is:

[0176] Y = g B modm;

[0177] Y1 = g (A-A1)B .

[0178] Step 8: Application server 1 obtains the calculation factors Y and Y1 of key K, and also locally stores the previously generated random number A1. It can calculate and obtain key K that is consistent with the one on the chain. The calculation formula is:

[0179] K = Y A1 *Y1=g A1B *g (A-A1)B modm = g (A1+A-A1)B modm = g AB modm.

[0180] The key is used to encrypt the calculation factors Y and Y1, as well as the attribute policy for log access, to become the new key K1.

[0181] Step 9: Sign key K1 using the private key of the blockchain transaction user's identity authentication CA, and then store it on the blockchain with endorsement.

[0182] Figure 7 The process involves creating a single key. If access to multiple types of files is required, multiple keys need to be created.

[0183] Log encryption generation depends on log type, log access policy attributes, key K, etc. Different log types require hierarchical and categorized encryption of different fields, as shown in Table 2:

[0184] Table 2: Hierarchical and Classified Encryption Table

[0185]

[0186]

[0187] Please refer to Figure 9 The detailed log encryption process is as follows:

[0188] Step 1: Application server 1 uses the transaction user and the identity authentication certificate issued by the CA to initiate an on-chain smart contract call and request the execution of the transaction;

[0189] Step 2: After receiving the request to call the smart contract, the nodes of blockchain network 4 perform the endorsement and block creation operations to complete the transaction process;

[0190] Step 3: During the transaction process, relevant transaction logs will be generated, including detailed operation logs of important transactions, system logs of blockchain node operation, and error logs when transactions fail. Each type of log is generated according to the log naming convention. For example, detailed operation logs of important transactions are named app_xxxxxxxx.log, system operation logs are named sys_xxxxxxxx.log, and error logs are named error_xxxxxxxx.log.

[0191] Step 4: Based on the log type, query the system smart contract to obtain the pre-defined log strategy on the chain, as well as the calculation factors of key K: random number A, random number B, common parameter prime number m, and integer g;

[0192] Step 5: Calculate the key K = g AB modm encrypts the content of fields that need to be encrypted based on log type and hierarchical classification rules, such as ID card number, authentication password, name, address and other fields in personal information.

[0193] Step 6: Transmit the key K, the encrypted log message transmission, the log type, the attributes corresponding to the log policy, etc. to the log management server 3;

[0194] Step 7: Log management server 3 uses key K to encrypt the attributes corresponding to the log policy into ciphertext M, saves the log message according to the log type as a log conforming to the naming convention, and modifies the attributes of the log file by adding the M attribute.

[0195] All logs generated by blockchain network 4 are archived to log management server 3. Transaction users belonging to the institution to which a blockchain node belongs must first authenticate their identity with the blockchain node before performing log retrieval and decryption operations. Please refer to [link / reference]. Figure 10 The detailed log access process is as follows:

[0196] Step 1: Application server 1 of a certain organization initiates a request to retrieve logs, transmits the request parameters of the interface call, and signs it with the private key of the CA certificate used for identity authentication;

[0197] Step 2: After receiving the request, the blockchain network 4 verifies the identity of the user who initiated the transaction. Once the identity is verified, it requests the log management server 3 to obtain the log.

[0198] Step 3: Log management server 3 pushes the required logs to the file server specified by application server 1 according to the request;

[0199] Step 4: Application server 1 generates a random number A2, which is used to calculate the key K;

[0200] Step 5: Blockchain network 4 queries the key K of this type of log for the required computation factors random number A, random number B, common parameter prime number m and integer g, and calculates Y and Y2.

[0201] Y = g B modm;

[0202] Y2 = g (A-A2)B .

[0203] Step 6: Application server 1 calculates K based on Y and Y2, K = Y A2 *Y2.

[0204] Step 7: Decrypt the initial key K1 stored on application server 1 to obtain the encrypted attribute policy and calculation factors Y, A1, and Y1 within K1, and calculate the key = Y A1 *Y1;

[0205] Verify that the key is consistent with the key generated in step 6;

[0206] Step 8: If they match, use key K to decrypt the ciphertext of the log attribute, obtain the attribute value corresponding to the ciphertext, and match it with the attribute policy in K1 to check if they match completely.

[0207] For example, the plaintext attributes after decrypting the log attributes are: A, B, C;

[0208] The log attribute strategy is: (AΛB)Λ(CVD);

[0209] This indicates that the attribute matches the attribute policy, therefore the attribute policy has permission to access this log.

[0210] Step 9: Use key K to decrypt the log content and parse it to obtain the full log plaintext.

[0211] This application's embodiments, based on the KP-ABE attribute encryption algorithm and the Diffie-Hellman algorithm, address the access control of blockchain node log content according to transaction user roles, achieving at least the following technical effects: Based on the KP-ABE attribute encryption algorithm, log access strategies can be flexibly adjusted according to the blockchain's log attributes, and corresponding keys can be allocated; based on the Diffie-Hellman algorithm, sharing the encryption key for log content enhances log confidentiality and security, meeting the requirements of data classification and grading standards; keys issued based on the Diffie-Hellman algorithm can verify the integrity of the KP-ABE attribute encryption strategy, avoiding the risk of user-held keys being lost and stolen.

[0212] Figure 11 This is a schematic diagram of the structure of a log management device provided in an embodiment of this application, as shown below. Figure 11 As shown in the embodiment of this application, the log management device includes:

[0213] The first query module 41 is used to query the types of logs that a trading user can access based on the user role of that trading user.

[0214] The second query module 42 is used to query the access policy and key parameters of the log type that the transaction user can access on the chain.

[0215] The first generation module 43 is used to generate a first key based on the key parameters of this type of log;

[0216] The first acquisition module 44 is used to acquire the first random number generated by the application server of the transaction user;

[0217] The second generation module 45 is used to generate a first calculation factor and a second calculation factor based on the first random number and the key parameters.

[0218] The first sending module 46 is used to send the first calculation factor and the second calculation factor to the application server. The application server is used to generate a second key based on the first calculation factor, the second calculation factor and the first random number, and use the second key to encrypt the access policy of the logs accessible to the transaction user, the first calculation factor and the second calculation factor to obtain a log management key, and use the log management key to perform log management, wherein the second key is consistent with the first key.

[0219] The log management device provided in this application embodiment first classifies logs according to the requirements of the KP-ABE attribute encryption algorithm, defines log attributes and access policies, and then writes the access policies into the keys held by the transaction users. Multiple parameters are required to generate symmetric keys (first key and second key). The keys are kept by the encryption and decryption parties (nodes of the blockchain network and off-chain transaction users) respectively to support the subsequent log management process.

[0220] In some embodiments, the first generation module is specifically used for:

[0221] The first key is generated based on the random number from the requesting log access party, the random number from the log encryption party, the first common parameter, and the second common parameter.

[0222] In some embodiments, the second generation module is specifically used for:

[0223] The first calculation factor is generated based on the random number from the log encryptor, the first common parameter, and the second common parameter.

[0224] A second calculation factor is generated based on the first random number, the random number from the requesting log access party, the random number from the log encryption party, and the second common parameter.

[0225] In some embodiments, the apparatus further includes:

[0226] The signature module is used to sign the log management key using the transaction user's private key to obtain an encryption key;

[0227] The first sending module is also used to send the encryption key to the blockchain network for on-chain endorsement.

[0228] Figure 12 This is a schematic diagram of the structure of a log management device provided in an embodiment of this application, as shown below. Figure 12 As shown in the embodiment of this application, the log management device includes:

[0229] Execution module 51 is used to execute transactions and generate transaction logs based on the transaction requests of trading users;

[0230] The second acquisition module 52 is used to acquire the access policy, encryption policy and key parameters corresponding to the log type of the transaction log;

[0231] The third generation module 53 is used to generate a first key based on the key parameters;

[0232] Encryption module 54 is used to encrypt the target field in the transaction log using the first key according to the encryption strategy, and generate an encrypted log;

[0233] The second sending module 55 is used to send the first key, the encrypted log, and the attribute information corresponding to the access policy to the log management server. The log management server is used to encrypt the attribute information using the first key to generate attribute ciphertext and add the attribute ciphertext as an attribute of the encrypted log.

[0234] In some embodiments, the second sending module is further configured to:

[0235] The transaction log type is sent to the log management server, which then saves the encrypted log as a log file conforming to the naming convention according to the log type.

[0236] The log management device provided in this application embodiment encrypts logs based on log type, log access policy attributes, first key, etc. Different log types require hierarchical and classified encryption of different fields, which solves the problem that existing log management methods do not distinguish all transaction users of the blockchain and do not perform anonymization processing on sensitive data.

[0237] Figure 13 This is a schematic diagram of the structure of a log management device provided in an embodiment of this application, as shown below. Figure 13 As shown in the embodiment of this application, the log management device includes:

[0238] The third acquisition module 61 is used to acquire encrypted logs of the target type from the log management server;

[0239] The fourth generation module 62 is used to generate a second random number and send it to the blockchain network, wherein the blockchain network is used to generate a first calculation factor and a third calculation factor based on the second random number and the key parameters of the log file of the target type;

[0240] The fifth generation module 63 is used to generate a third key based on the first calculation factor, the third calculation factor, and the second random number;

[0241] The first decryption module 64 is used to decrypt the locally stored log management key using the third key to obtain the access policy, the first calculation factor, and the second calculation factor.

[0242] The sixth generation module 65 is used to generate a first key based on the first calculation factor, the second calculation factor, and the first random number stored locally.

[0243] The second decryption module 66 is used to decrypt the attribute ciphertext of the encrypted log using the third key if the first key and the third key are the same, so as to obtain the attribute information of the encrypted log.

[0244] The third decryption module 67 is used to decrypt the log content of the encrypted log using the third key if the attribute information matches the access policy, thereby obtaining the plaintext log.

[0245] The log management device provided in this application embodiment generates a third key by interacting with a blockchain network to obtain multiple parameters. This third key is then used to decrypt the ciphertext of the encrypted log's attributes to obtain the attribute information of the encrypted log. If the attribute information matches the access policy, the third key is used to decrypt the log content of the encrypted log to obtain the plaintext log, thus managing the log access process. Furthermore, the consistency between the third key and the first key is verified. This verifies the integrity of the KP-ABE attribute encryption policy and avoids the risk of user-held keys being lost and stolen.

[0246] The embodiments of the apparatus provided in this application can be used to execute the processing flow of the above method embodiments. Its functions will not be repeated here, but can be referred to the detailed description of the above method embodiments.

[0247] It should be noted that the log management method and apparatus provided in this application can be used in the financial field, or in any technical field other than the financial field. This application does not limit the application field of the log management method and apparatus.

[0248] Figure 14 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application, as shown below. Figure 14 As shown, the electronic device may include a processor 701, a communications interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communications interface 702, and the memory 703 communicate with each other via the communication bus 704. The processor 701 may call logical instructions in the memory 703 to execute the methods described in any of the above embodiments.

[0249] Furthermore, the logical instructions in the aforementioned memory 703 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0250] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments.

[0251] This embodiment provides a computer-readable storage medium storing a computer program that causes the computer to perform the methods provided in the above-described method embodiments.

[0252] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0253] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0254] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0255] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0256] In the description of this specification, the references to terms such as "an embodiment," "a specific embodiment," "some embodiments," "for example," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0257] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A log management method, characterized in that, include: Based on the user's role, query the types of logs that the user can access; Based on the log type that the transaction user can access, query the access policy and key parameters of that log type on the chain; Generate a first key based on the key parameters of this type of log; Obtain the first random number generated by the application server of the transaction user; Based on the first random number and the key parameters, a first calculation factor and a second calculation factor are generated; The first calculation factor and the second calculation factor are sent to the application server. The application server generates a second key based on the first calculation factor, the second calculation factor, and the first random number. It uses the second key to encrypt the access policy of the logs accessible to the transaction user, the first calculation factor, and the second calculation factor to obtain a log management key. The application server then uses the log management key to manage the logs. The second key is consistent with the first key.

2. The method according to claim 1, characterized in that, The step of generating the first key based on the key parameters of this type of log includes: The first key is generated based on the random number from the requesting log access party, the random number from the log encryption party, the first common parameter, and the second common parameter.

3. The method according to claim 2, characterized in that, The step of generating a first calculation factor and a second calculation factor based on the first random number and the key parameters includes: The first calculation factor is generated based on the random number from the log encryptor, the first common parameter, and the second common parameter. A second calculation factor is generated based on the first random number, the random number from the requesting log access party, the random number from the log encryption party, and the second common parameter.

4. The method according to any one of claims 1 to 3, characterized in that, After obtaining the log management key, the method further includes: The log management key is signed using the transaction user's private key to obtain an encryption key; The encryption key is sent to the blockchain network for on-chain endorsement.

5. A log management method, characterized in that, include: Execute transactions and generate transaction logs based on the transaction requests from users; Obtain the access policy, encryption policy, and key parameters corresponding to the log type of the transaction log; Generate a first key based on the key parameters; According to the encryption strategy, the target field in the transaction log is encrypted using the first key to generate an encrypted log; The first key, the encrypted log, and the attribute information corresponding to the access policy are sent to the log management server. The log management server is used to encrypt the attribute information using the first key to generate attribute ciphertext, and add the attribute ciphertext as an attribute of the encrypted log.

6. The method according to claim 5, characterized in that, The method further includes: The transaction log type is sent to the log management server, which then saves the encrypted log as a log file conforming to the naming convention according to the log type.

7. A log management method, characterized in that, include: Retrieve encrypted logs of the target type from the log management server; A second random number is generated and sent to a blockchain network, which is used to generate a first calculation factor and a third calculation factor based on the second random number and the key parameters of the log file of the target type. A third key is generated based on the first calculation factor, the third calculation factor, and the second random number; The locally stored log management key is decrypted using the third key to obtain the access policy, the first calculation factor, and the second calculation factor; A first key is generated based on the first calculation factor, the second calculation factor, and the first random number stored locally. If the first key and the third key are the same, the third key is used to decrypt the attribute ciphertext of the encrypted log to obtain the attribute information in the access policy of the encrypted log. If the attribute information matches the access policy, the third key is used to decrypt the encrypted log content to obtain the plaintext log.

8. A key generation device, characterized in that, include: The first query module is used to query the types of logs that a trading user can access based on the user's role. The second query module is used to query the access policy and key parameters of the log type that the transaction user can access on the chain. The first generation module is used to generate a first key based on the key parameters of this type of log. The first acquisition module is used to acquire a first random number generated by the application server of the transaction user; The second generation module is used to generate a first calculation factor and a second calculation factor based on the first random number and the key parameters. The first sending module is used to send the first calculation factor and the second calculation factor to the application server. The application server is used to generate a second key based on the first calculation factor, the second calculation factor and the first random number, and use the second key to encrypt the access policy of the logs accessible to the transaction user, the first calculation factor and the second calculation factor to obtain a log management key, and use the log management key to perform log management, wherein the second key is consistent with the first key.

9. A log management device, characterized in that, include: The execution module is used to execute transactions and generate transaction logs based on the transaction requests from trading users. The second acquisition module is used to acquire the access policy, encryption policy and key parameters corresponding to the log type of the transaction log; The third generation module is used to generate the first key based on the key parameters; An encryption module is used to encrypt target fields in the transaction log using the first key according to the encryption strategy, thereby generating an encrypted log; The second sending module is used to send the first key, the encrypted log, and the attribute information corresponding to the access policy to the log management server. The log management server is used to encrypt the attribute information using the first key to generate attribute ciphertext and add the attribute ciphertext as an attribute of the encrypted log.

10. A log management device, characterized in that, include: The third acquisition module is used to obtain encrypted logs of the target type from the log management server; The fourth generation module is used to generate a second random number and send it to the blockchain network. The blockchain network is used to generate a first calculation factor and a third calculation factor based on the second random number and the key parameters of the log file of the target type. The fifth generation module is used to generate a third key based on the first calculation factor, the third calculation factor, and the second random number; The first decryption module is used to decrypt the locally stored log management key using the third key to obtain the access policy, the first calculation factor, and the second calculation factor. The sixth generation module is used to generate a first key based on the first calculation factor, the second calculation factor, and the first random number stored locally. The second decryption module is used to decrypt the attribute ciphertext of the encrypted log using the third key if the first key and the third key are consistent, so as to obtain the attribute information in the access policy of the encrypted log. The third decryption module is used to decrypt the log content of the encrypted log using the third key if the attribute information matches the access policy, thereby obtaining the plaintext log.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4, 5 to 6 or 7.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4, 5 to 6 or 7.

Images