Cryptographic parameter control method and device in trusted blockchain and trusted blockchain system

Abstract

One or more embodiments of this specification disclose a method, apparatus, and trusted blockchain system for controlling cryptographic parameters in a trusted blockchain. This method implements encryption protection for transaction data using two-level cryptographic parameters and verifies the legitimacy of entities requesting transaction data based on configured behavioral permissions in the trusted blockchain system. This ensures that only legitimate entities that have passed the legitimacy verification can obtain the corresponding cryptographic parameters to encrypt or decrypt transaction data, thereby ensuring the trusted identity of the accessing entity and the confidentiality and security of transaction data.

Description

Technical Field

[0001] This document relates to the field of blockchain technology, and in particular to a method and device for controlling cryptographic parameters in a trusted blockchain and a trusted blockchain system. Background Art

[0002] Blockchain is a decentralized and innovative solution that uses distributed ledger technology to solve multi-party trust issues. It is a cutting-edge technology in today's society.

[0003] As the name suggests, blockchain is a decentralized, distributed ledger in which data is generated and stored in blocks, linked end-to-end in chronological order to form a chain structure. Cryptography ensures that data cannot be tampered with or forged, and that data transmission and access are secure. The so-called ledger in the blockchain functions much like a real-life ledger, recording transaction information and other information in a specific format.

[0004] The current blockchain can effectively guarantee the anonymity of transaction participants. However, the data on the blockchain is public and can be accessed by any node, and the privacy and security of the data itself cannot be guaranteed. Summary of the Invention

[0005] The purpose of one or more embodiments of this specification is to provide a method, device, and trusted blockchain system for controlling cryptographic parameters in a trusted blockchain, thereby encrypting transaction data through two-level cryptographic parameters and allowing only legitimate entities to access and obtain plaintext data, thereby ensuring the trustworthiness of the access subject's identity and the confidentiality and security of the data.

[0006] To solve the above technical problems, one or more embodiments of this specification are implemented as follows:

[0007] In a first aspect, a cryptographic parameter control method in a trusted blockchain is proposed, which is applied to a first client as an encryption party, and the method includes:

[0008] After generating the transaction data, encrypting the transaction data based on a second cryptographic parameter generated locally to obtain a ciphertext of the transaction data;

[0009] Encrypting the second cryptographic parameter based on the first cryptographic parameter obtained in the legitimacy verification method to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract;

[0010] A transaction is constructed using the transaction data ciphertext and the second cryptographic parameter ciphertext, and is sent to nodes participating in the trusted blockchain after being signed.

[0011] In a second aspect, a cryptographic parameter control method in a trusted blockchain is proposed, which is applied to a first client or node as a decryption party, and the method includes:

[0012] Receive the signed transaction;

[0013] After the transaction signature is verified, a first cryptographic parameter is obtained using a legitimacy verification method, wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract;

[0014] Decrypting the second cryptographic parameter ciphertext in the transaction using the first cryptographic parameter to obtain the second cryptographic parameter;

[0015] The transaction data ciphertext in the transaction is decrypted using the second cryptographic parameter to obtain the transaction data.

[0016] Thirdly, a cryptographic parameter control device in a trusted blockchain is proposed, comprising:

[0017] a first encryption module, configured to, after generating transaction data, encrypt the transaction data based on a second cryptographic parameter generated locally to obtain a ciphertext of the transaction data;

[0018] a second encryption module, configured to encrypt the second cryptographic parameter based on the first cryptographic parameter obtained in a legitimacy verification manner to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission within the trusted blockchain and encrypted and stored in a system-level smart contract;

[0019] A transaction construction module is used to construct a transaction using the transaction data ciphertext and the second cryptographic parameter ciphertext, and send the transaction to the nodes participating in the trusted blockchain after signing.

[0020] Fourthly, a cryptographic parameter control device in a trusted blockchain is proposed, comprising:

[0021] Receiving module, used to receive signed transactions;

[0022] A first acquisition module is configured to obtain a first cryptographic parameter using a legitimacy verification method after the transaction signature is verified, wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract;

[0023] a first decryption module, configured to decrypt the second cryptographic parameter ciphertext in the transaction using the first cryptographic parameter to obtain the second cryptographic parameter;

[0024] The second decryption module is used to decrypt the ciphertext of the transaction data in the transaction using the second cryptographic parameters to obtain the transaction data.

[0025] In a fifth aspect, an electronic device is provided, comprising:

[0026] processor; and

[0027] A memory arranged to store computer-executable instructions, wherein when the instructions are executed, the processor performs the method for controlling cryptographic parameters in a trusted blockchain according to the first aspect or the second aspect.

[0028] In the sixth aspect, a computer-readable storage medium is proposed, which stores one or more programs. When the one or more programs are executed by an electronic device including multiple applications, the electronic device executes the cryptographic parameter control method in the trusted blockchain described in the first aspect or the second aspect.

[0029] Seventhly, a trusted blockchain system is proposed, including:

[0030] At least one first client generating a transaction, at least one second client having permission to manage the transaction, and a plurality of ordinary nodes;

[0031] During the transaction encryption phase: after generating transaction data, the first client, acting as the encryption party, encrypts the transaction data based on a locally generated second cryptographic parameter to obtain a transaction data ciphertext; and encrypts the second cryptographic parameter based on the first cryptographic parameter obtained through a legitimacy verification method to obtain a second cryptographic parameter ciphertext; a transaction is constructed using the transaction data ciphertext and the second cryptographic parameter ciphertext, and is sent to nodes participating in the trusted blockchain after signing.

[0032] During the transaction decryption phase: another first client or node acts as the decryptor and receives the signed transaction. After verifying the transaction signature, the client obtains a first cryptographic parameter using a legitimacy verification method. The client uses the first cryptographic parameter to decrypt the ciphertext of the second cryptographic parameter in the transaction to obtain the second cryptographic parameter. The client also uses the second cryptographic parameter to decrypt the ciphertext of the transaction data in the transaction to obtain the transaction data.

[0033] The first cryptographic parameter is generated by a second client with management behavior permission within the trusted blockchain and is encrypted and stored in a system-level smart contract.

[0034] As can be seen from the technical solutions provided by one or more embodiments of this specification, transaction data is encrypted and protected using two-level cryptographic parameters. Furthermore, the legitimacy of the subject requesting transaction data is verified based on the configured behavior permissions in the trusted blockchain system. This ensures that only legitimate subjects who have passed the legitimacy verification can obtain the corresponding cryptographic parameters to encrypt or decrypt transaction data. This ensures the trustworthiness of the accessing subject and the confidentiality and security of transaction data. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate one or more embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the description of one or more embodiments or the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0036] Figure 1 This is a schematic diagram of the overall technical architecture of the trusted blockchain system provided in the embodiments of this specification.

[0037] Figure 2 This is a structural diagram of the relationship between the first cryptographic parameter and the second cryptographic parameter in the trusted blockchain cryptographic parameter control scheme provided in the embodiments of this specification.

[0038] Figure 3 This is one of the step diagrams of the trusted blockchain cryptographic parameter control method provided in the embodiments of this specification.

[0039] Figure 4 This is the second step diagram of the trusted blockchain cryptographic parameter control method provided in the embodiment of this specification.

[0040] Figure 5 This is a schematic diagram of the principle of forwarding the second distribution request of the cryptographic parameters among other nodes.

[0041] Figure 6 This is one of the structural diagrams of the trusted blockchain cryptographic parameter control device provided in the embodiments of this specification.

[0042] Figure 7 This is one of the structural diagrams of the trusted blockchain cryptographic parameter control device provided in the embodiments of this specification.

[0043] Figure 8 This is a schematic diagram of the structure of the trusted blockchain system provided in the embodiments of this specification.

[0044] Figure 9 This is a schematic diagram of the structure of an electronic device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0045] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below in conjunction with the drawings in one or more embodiments of this specification. Obviously, the one or more embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on one or more embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this document.

[0046] First, refer to Figure 1 The following describes the overall technical architecture of the trusted blockchain system provided by the embodiments of this specification. The trusted blockchain system may include multiple entities, which can be divided into three types based on their functional deployment: ordinary nodes, block-producing nodes, and clients. It should be understood that as the number of achievable functions increases or is further refined, the trusted blockchain system may define or divide entities into more functional types, and this embodiment of the specification is not limited to this.

[0047] The following is a brief introduction to the functions of each subject in the embodiments of this specification.

[0048] Ordinary nodes: They are the core nodes that constitute the blockchain network. They are mainly used to receive transactions generated by clients or transactions forwarded by other ordinary nodes, and cache or forward them to other ordinary nodes after verifying the transactions. At the same time, they can build pre-signed blocks and send them to the block-generating nodes, and receive complete blocks processed and signed by the block-generating nodes or complete blocks forwarded by other ordinary nodes, and store or forward them to other ordinary nodes after verifying the complete blocks. Furthermore, they provide clients with various interfaces for accessing the blockchain network, such as read-type interfaces and write-type interfaces.

[0049] Block generating node: It is also the core node of the blockchain network. It is mainly used to receive pre-signed blocks sent by ordinary nodes and verify them. At the same time, it performs consensus calculation on the verified pre-signed blocks, constructs a complete block and signs it. After that, it returns the complete block to the ordinary nodes.

[0050] Client: Mainly used to generate and sign transactions; send signed transactions to ordinary nodes; call the blockchain access interface provided by ordinary nodes according to business needs to achieve the required business capabilities.

[0051] The trusted blockchain system described in the embodiments of this specification may include system-level smart contracts and business-level smart contracts. System-level smart contracts refer to smart contracts built into the genesis block or nodes, rather than client-deployed smart contracts. System-level smart contracts are primarily used for managing the trusted blockchain system. Based on their scope of management, they can be categorized into at least three types: account management, cryptographic parameter management, and alliance management. Therefore, system-level smart contracts can be further subdivided into system-level account management smart contracts, system-level cryptographic parameter management smart contracts, and system-level alliance management smart contracts. Business-level smart contracts are client-deployed smart contracts that primarily address contract parameters related to business transactions.

[0052] Generally, one or more permitted actions can be configured for each entity through the system-level account management smart contract. In the embodiments of this specification, a "read" action permission can be configured for ordinary nodes to facilitate access to the blockchain network. In fact, ordinary nodes can also be configured with a "generate block" action permission. This allows ordinary nodes to function as block-generating nodes, and only then can the blocks they generate be verified as legitimate. Block-generating nodes can be configured with the "generate block" action permission; otherwise, the blocks they generate will be verified as invalid. Clients can be configured with "read," "call," "deploy," and "manage" action permissions based on their needs. The "read" action permission is essential, while the "call," "deploy," and "manage" action permissions can be flexibly configured based on user needs. For example, a client used by an administrative user can be configured with the "call," "deploy," and "manage" action permissions, enabling both the deployment and access of business-level smart contracts and system-level smart contracts. Clients used by ordinary users can be configured with the "call" and "deploy" action permissions, enabling the deployment and access of business-level smart contracts.

[0053] It should be understood that the above configuration process can be completed by calling the write interface of the system-level smart contract through a management client with management behavior permission. Reading or verifying whether the subject has the allowed behavior can be achieved by calling the read interface of the system-level smart contract.

[0054] Considering that in this blockchain system, in order to ensure the security and confidentiality of transaction data (especially the plaintext transaction data), it is proposed to encrypt the transaction data through two-level cryptographic parameters, and to verify the legitimacy of the subject requesting the transaction data based on the configured behavior permission in the above-mentioned trusted blockchain system. In this way, it is ensured that only the legitimate subject who has passed the legitimacy verification can obtain the corresponding cryptographic parameters to encrypt the transaction data, or decrypt the transaction to obtain the transaction data.

[0055] The following is a detailed description of the cryptographic parameter control scheme in the trusted blockchain involved in this specification through specific embodiments.

[0056] It should be understood that the cryptographic parameter control scheme in the trusted blockchain mainly involves two processes. First, the encryption process of transaction data (transaction data plaintext); second, the decryption process of the transaction (transaction ciphertext). In the encryption process, the main subject involved is the first client as the encryption party. In the currently executed cryptographic parameter control scheme, the first client is not a management client, and the second client, as a management client with management behavior permission, can provide cryptographic parameters for the first client that generates the transaction. In the decryption process, the main subject involved is the first client or node as the decryption party (that is, the above-mentioned Figure 1 Therefore, the subject of the cryptographic parameter distribution request (or the first cryptographic parameter distribution request, the second cryptographic parameter distribution request) involved in the cryptographic parameter control scheme in the trusted blockchain can be the first client or the node.

[0057] Reference Figure 2 As shown, the cryptographic parameters used when encrypting or decrypting transaction data may include: a first cryptographic parameter and a second cryptographic parameter. The first cryptographic parameter is used to encrypt the second cryptographic parameter, and the second cryptographic parameter is used to encrypt the transaction data. The first cryptographic parameter is generated by a second client with management permission, while the second cryptographic parameter is generated by the first client that generates the transaction or transaction data. It should be understood that the embodiments of this specification do not limit the first client and the second client. The descriptions of "first" and "second" are provided here only to distinguish the management permissions enjoyed by management clients with management permission.

[0058] The first cryptographic parameter can be a symmetric key or an asymmetric key, and accordingly, the encryption and decryption algorithms implemented using the first cryptographic parameter can be symmetric or asymmetric. Similarly, the second cryptographic parameter can also be a symmetric or asymmetric key, and accordingly, the encryption and decryption algorithms implemented using the second cryptographic parameter can be symmetric or asymmetric. When implementing the encryption and decryption algorithms in the embodiments of this specification for any exchange, the first cryptographic parameter involved can be a symmetric key and the second cryptographic parameter can be an asymmetric key; alternatively, the first cryptographic parameter can be an asymmetric key and the second cryptographic parameter can be a symmetric key; alternatively, both the first and second cryptographic parameters can be symmetric or asymmetric keys.

[0059] The first cryptographic parameter can be generated in advance by a second client with management behavior permission, and then the first cryptographic parameter is encrypted using the cryptographic parameter of the second client's own blockchain account, and the write type interface of the system-level cryptographic parameter management smart contract is called to record the encrypted first cryptographic parameter into the system-level cryptographic parameter management smart contract. Any client in the trusted blockchain network can use the first cryptographic parameter uniformly when encrypting transactions. It is worth noting that when the trusted blockchain network contains multiple alliance chains, each alliance chain can generate the first cryptographic parameter separately by the second client with management behavior permission on its own chain. When encryption or decryption operations occur, the first cryptographic parameter of the alliance to which the first client that generated the transaction belongs can be called separately.

[0060] The second password parameter may be generated by the transaction generating entity, ie, the first client. The specific generation timing may be after the transaction data is generated or before the transaction data is about to be generated. This specification does not limit this.

[0061] The first cryptographic parameter and the second cryptographic parameter may be generated by a generating entity based on a cryptographic generator, wherein the cryptographic generator may be configured and implemented according to a cryptographic algorithm, and the cryptographic algorithms involved may include any one or a combination of cryptographic algorithms such as MD5 and SHA series algorithms in the hash algorithm, and RIPEMD series algorithms.

[0062] Table 1 below shows two interfaces and corresponding interface descriptions included in the system-level cryptographic parameter management smart contract involved in the embodiments of this specification.

[0063]

[0064] Table 1

[0065] The following describes in detail the cryptographic parameter control scheme involved in the embodiments of this specification through the encryption process of transaction data and the decryption process of transaction ciphertext.

[0066] Reference Figure 3 The figure shows a schematic diagram of the steps of the cryptographic parameter control method in a trusted blockchain provided by an embodiment of this specification. The cryptographic parameter control method uses the first client as the encryption party to encrypt the transaction data generated by it. Specifically, the following steps may be included:

[0067] Step 302: After the transaction data is generated, the transaction data is encrypted based on a second cryptographic parameter generated locally to obtain a ciphertext of the transaction data.

[0068] As mentioned above, the timing of generating the second password parameter is not limited.

[0069] Step 304: Encrypt the second cryptographic parameter based on the first cryptographic parameter obtained in the legitimacy verification method to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in the system-level smart contract.

[0070] Optionally, the first cryptographic parameter is obtained through the following direct distribution method: the encryption party, that is, the first client, sends a cryptographic parameter distribution request to the second client, where the cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and use the blockchain account parameters of the encryption party carried in the cryptographic parameter distribution request to encrypt the first cryptographic parameter and store it in the system-level smart contract; the encryption party searches for and obtains the first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract; the encryption party uses its own blockchain account parameters to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

[0071] The specific implementation may include the following steps:

[0072] a1: The first client sends a cryptographic parameter distribution request to the second client.

[0073] a2: After receiving the cryptographic parameter distribution request, the second client obtains the first cryptographic parameter ciphertext encrypted with the cryptographic parameters of the second client's blockchain account from the system-level cryptographic parameter smart contract.

[0074] a3: The second client uses the cryptographic parameters of its own blockchain account to decrypt the first cryptographic parameter ciphertext received in step a2 to obtain the first cryptographic parameter plaintext (i.e., the first cryptographic parameter).

[0075] a4: The second client uses the cryptographic parameters of the first client's blockchain account carried in the cryptographic parameter distribution request received in step a2 to encrypt the first cryptographic parameter plaintext in step a3, obtains a new first cryptographic parameter ciphertext, and stores it in the system-level cryptographic parameter smart contract.

[0076] It should be understood that, in conjunction with the write-type interface of the system-level cryptographic parameter smart contract, a cryptographic parameter ID corresponding to the current first cryptographic parameter ciphertext is generated each time a data is stored. The cryptographic parameter ID can be identification information that can be distinguished and identified by clients or nodes within the trusted blockchain network. For example, the blockchain account of the first client or second client that encrypted the first cryptographic parameter can be used as the cryptographic parameter ID.

[0077] At the same time, the second client may also send a distribution response to the first client to notify the first client that the first cryptographic parameters to be distributed have been stored in an encrypted manner in the system-level cryptographic parameter smart contract.

[0078] a5: The first client obtains the first cryptographic parameter ciphertext encrypted with the cryptographic parameters of its own blockchain account from the system-level cryptographic parameter smart contract.

[0079] a6: The first client uses the cryptographic parameters of its own blockchain account to decrypt the first cryptographic parameter ciphertext in step a5 to obtain the first cryptographic parameter plaintext.

[0080] In other words, the first cryptographic parameter ciphertext stored in the system-level smart contract during the password generation phase is encrypted based on the cryptographic parameters of the second client's blockchain account. Only the second client with management permission can obtain and parse the first cryptographic parameters. Furthermore, the first cryptographic parameter ciphertext stored in the system-level smart contract during the password distribution phase is encrypted based on the cryptographic parameters of the first client's blockchain account. Only the first client can obtain and parse the first cryptographic parameters from it. Therefore, the process of obtaining the first cryptographic parameters requires identity verification of the second client to determine whether it has read permission and successful decryption. This specific verification is actually hidden in the process of the second client obtaining and parsing the first cryptographic parameters. Similarly, the first client's identity must also be verified to successfully obtain and parse the first cryptographic parameters from the system-level cryptographic parameter smart contract.

[0081] In the above process of obtaining the first password parameter, only the legal subject can obtain the plain text of the first password parameter, thereby ensuring the credibility of the access subject's identity and the security of the plain text of the first password parameter, and further ensuring the credibility of the access subject's identity and the confidentiality and security of the data.

[0082] Step 306: Construct a transaction using the transaction data ciphertext and the second cryptographic parameter ciphertext, and send it to the nodes participating in the trusted blockchain after signing.

[0083] Since the second cryptographic parameter ciphertext is obtained by encrypting the above-mentioned first cryptographic parameters, and the access, acquisition and even parsing of the above-mentioned first cryptographic parameters implicitly verify the legitimacy of the accessing subject (the first client and the second client), the second cryptographic parameter ciphertext ensures partial security of the transaction. At the same time, the use of two-level cryptographic parameters to encrypt transaction data further ensures the trustworthy identity of the accessing subject and the confidentiality and security of the data.

[0084] Reference Figure 4The figure shows a schematic diagram of the steps of the cryptographic parameter control method in a trusted blockchain provided by an embodiment of this specification. The cryptographic parameter control method is a process in which a first client or node acts as a decryption party and decrypts a received transaction. Specifically, the following steps may be included:

[0085] Step 402: Receive the signed transaction.

[0086] Step 404: After the transaction is signed and verified, a first cryptographic parameter is obtained using a legitimacy verification method, wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract.

[0087] Different from the method of obtaining the first cryptographic parameters during the encryption process, in the decryption process, there may be multiple decrypting parties, for example, including: the first client (but the transaction targeted by the decryption process may be encrypted by other first clients) and / or nodes. Therefore, the first cryptographic parameters can be directly distributed similar to the encryption process, or indirectly distributed through other nodes that have obtained the first cryptographic parameters.

[0088] Direct distribution process: the decryption party sends a first cryptographic parameter distribution request to the second client, and the first cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and use the blockchain account parameter of the decryption party carried in the first cryptographic parameter distribution request to encrypt the first cryptographic parameter and store it in the system-level smart contract; the decryption party searches and obtains the first cryptographic parameter ciphertext encrypted with its own blockchain account parameter from the system-level smart contract; the decryption party uses its own blockchain account parameter to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

[0089] The specific implementation may include the following steps:

[0090] b1: The decryption party (first client or node) sends a first cryptographic parameter distribution request to the second client.

[0091] In fact, the first client and the node may also send the first cryptographic parameter distribution request to the second client simultaneously.

[0092] b2: After receiving the first cryptographic parameter distribution request, the second client obtains the first cryptographic parameter ciphertext encrypted with the cryptographic parameters of the second client's blockchain account from the system-level cryptographic parameter smart contract.

[0093] b3: The second client uses the cryptographic parameters of its own blockchain account to decrypt the first cryptographic parameter ciphertext received in step b2 to obtain the first cryptographic parameter plaintext (i.e., the first cryptographic parameter).

[0094] b4: The second client uses the cryptographic parameters of the decryption party's blockchain account carried in the first cryptographic parameter distribution request received in step b2 to encrypt the first cryptographic parameter plaintext in step b3, obtains a new first cryptographic parameter ciphertext, and stores it in the system-level cryptographic parameter smart contract.

[0095] At the same time, the second client may also send a distribution response to the decryption party to notify the decryption party that the first cryptographic parameters to be distributed have been stored in an encrypted manner in the system-level cryptographic parameter smart contract.

[0096] b5: The decryption party obtains the first cryptographic parameter ciphertext encrypted with the cryptographic parameters of its own blockchain account from the system-level cryptographic parameter smart contract.

[0097] b6: The decryption party uses the cryptographic parameters of its own blockchain account to decrypt the first cryptographic parameter ciphertext in step b5 to obtain the first cryptographic parameter plaintext.

[0098] Indirect distribution process: the decryption party sends a second cryptographic parameter distribution request to other nodes with which it has established a network connection. The second cryptographic parameter distribution request is used to instruct any other node to verify the second cryptographic parameter distribution request, and when the verification is legal and it is determined that the other node can obtain the first cryptographic parameter itself, the first cryptographic parameter obtained by the other node is encrypted using the blockchain account parameter of the decryption party; the decryption party receives the first cryptographic parameter ciphertext encrypted with its own blockchain account parameter returned by the other node; the decryption party uses its own blockchain account parameter to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

[0099] The specific implementation may include the following steps:

[0100] c1: The decryption node sends a second cryptographic parameter distribution request to other nodes with which it has established a network connection. This second cryptographic parameter distribution request may include the following fields: ① ChainID (alliance ID); ② CipherParaID (first cryptographic parameter ID); ③ AccountPara (the requester's blockchain account parameters); and ④ Signature (the requester's digital signature of all the above fields using its own blockchain account parameters).

[0101] Optionally, in the embodiment of this specification, other nodes having a network connection with the decryption party include: other nodes directly connected to the decryption party, and / or other nodes indirectly connected to the decryption party.

[0102] c2: Other nodes that receive the second cryptographic parameter distribution request determine the legitimacy of the request. If it is legitimate, they proceed to step c3. Otherwise, they discard the second cryptographic parameter distribution request, do not respond, and terminate subsequent processes. For example, identity verification can be performed through signature verification or alliance ID verification.

[0103] c3: The other nodes that receive the second cryptographic parameter distribution request determine whether the second cryptographic parameter distribution request has been processed; if it has been processed, no response is made and subsequent processes are stopped; otherwise, step c4 is executed.

[0104] c4: Other nodes that receive the second cryptographic parameter distribution request determine whether they can obtain the first cryptographic parameter plaintext corresponding to the CipherParaID carried in the second cryptographic parameter distribution request through direct distribution.

[0105] If yes, then step c5 is executed; if no, then the second cryptographic parameter distribution request is forwarded to other nodes that have established network connections with itself. It should be understood that at this time, other nodes will repeat steps c2-c4 until another node is found that can return the required first cryptographic parameters.

[0106] Reference Figure 5 As shown, this is the process of forwarding the second cryptographic parameter distribution request between other nodes to obtain the plaintext of the first cryptographic parameter in an embodiment of this specification. In the figure, nodes 1, 2, and 3 are unable to obtain the first cryptographic parameter through the direct distribution method, but node 4 can obtain the first cryptographic parameter through the direct distribution method. In this way, client 1 cannot obtain the first cryptographic parameter at node 1, so node 1 forwards the second cryptographic parameter distribution request to nodes 2 and 3. However, nodes 2 and 3 are also unable to obtain the first cryptographic parameter directly or indirectly. Next, nodes 2 and 3 continue to forward the second cryptographic parameter distribution request to node 4. Node 4 first receives the second cryptographic parameter distribution request forwarded by node 3, and then receives the second cryptographic parameter distribution request forwarded by node 2. In this way, node 4 returns the first cryptographic parameter to client 1 through the forwarding path of node 3.

[0107] c5: Encrypt the plaintext of the first cryptographic parameter using the cryptographic parameter of the requesting party's blockchain account and return it to the decryption party that sent the second cryptographic parameter distribution request.

[0108] This indirect distribution method requires the legitimacy of the requester of the first cryptographic parameter to be verified, and all nodes along the entire forwarding path need to perform this verification operation to ensure the security of the distribution of the first cryptographic parameter and the credibility of the identity of the requester.

[0109] Step 406: Use the first cryptographic parameter to decrypt the second cryptographic parameter ciphertext in the transaction to obtain the second cryptographic parameter.

[0110] Step 408: Decrypt the ciphertext of the transaction data in the transaction using the second cryptographic parameter to obtain the transaction data.

[0111] Thus, through the aforementioned legitimacy verification, the first cryptographic parameter is obtained through direct or indirect distribution, and the first cryptographic parameter is used to decrypt the ciphertext of the second cryptographic parameter in the transaction to obtain the second cryptographic parameter. The second cryptographic parameter is then used to decrypt the ciphertext of the transaction data to obtain the transaction data. This legitimacy verification method ensures the security of the first cryptographic parameter, the reliability of the acquisition process, and the trustworthiness of the decryption party. Furthermore, the use of two levels of cryptographic parameters in conjunction with decryption transactions further ensures the trustworthiness of the access subject's identity and the confidentiality and security of the data.

[0112] Example 2

[0113] Reference Figure 6 As shown, the cryptographic parameter control device in the trusted blockchain provided by the embodiment of this specification can include:

[0114] A first encryption module 602 is configured to encrypt the transaction data based on a second cryptographic parameter generated locally after the transaction data is generated to obtain a ciphertext of the transaction data;

[0115] A second encryption module 604 is configured to encrypt the second cryptographic parameter based on the first cryptographic parameter obtained in the legitimacy verification method to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract;

[0116] The transaction construction module 606 is used to construct a transaction using the transaction data ciphertext and the second cryptographic parameter ciphertext, and send it to the nodes participating in the trusted blockchain after signing.

[0117] Optionally, as an embodiment, the control device further includes:

[0118] a sending module, configured to send a first cryptographic parameter distribution request to the second client, wherein the first cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the encryption party carried in the first cryptographic parameter distribution request, and store the encrypted parameter in the system-level smart contract;

[0119] An acquisition module, configured to search and obtain, from the system-level smart contract, a first cryptographic parameter ciphertext encrypted with its own blockchain account parameters;

[0120] The decryption module is used to decrypt the obtained first cryptographic parameter ciphertext using its own blockchain account parameters to obtain the first cryptographic parameter.

[0121] Reference Figure 7 As shown, the cryptographic parameter control device in the trusted blockchain provided by the embodiment of this specification can include:

[0122] Receiving module 702, for receiving the signed transaction;

[0123] A first acquisition module 704 is configured to obtain a first cryptographic parameter using a legitimacy verification method after the transaction signature is verified, wherein the first cryptographic parameter is generated by a second client with management permission in the trusted blockchain and encrypted and stored in a system-level smart contract;

[0124] A first decryption module 706 is configured to decrypt the second cryptographic parameter ciphertext in the transaction using the first cryptographic parameter to obtain the second cryptographic parameter;

[0125] The second decryption module 708 is configured to decrypt the ciphertext of the transaction data in the transaction using the second cryptographic parameters to obtain the transaction data.

[0126] In a specific implementation of the embodiment of this specification, the control device further includes:

[0127] a sending module, configured to send a first cryptographic parameter distribution request to the second client, wherein the first cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the requesting party carried in the first cryptographic parameter distribution request, and store the encrypted data in the system-level smart contract;

[0128] A second acquisition module is used to search and obtain the first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract;

[0129] The third decryption module is used to decrypt the first cryptographic parameter ciphertext obtained by the second acquisition module using its own blockchain account parameters to obtain the first cryptographic parameter.

[0130] In another specific implementation of the embodiments of this specification, the sending module is further configured to send a second cryptographic parameter distribution request to other nodes with which the sending module has established a network connection, wherein the second cryptographic parameter distribution request is used to instruct any other node to verify the second cryptographic parameter distribution request, and when the verification is legal and it is determined that the other node itself can obtain the first cryptographic parameter, the sending module uses the blockchain account parameter of the decryption party to encrypt the first cryptographic parameter obtained by the other node;

[0131] The receiving module is further configured to receive a first cryptographic parameter ciphertext returned by another node and encrypted with its own blockchain account parameters;

[0132] The third decryption module is further used to use its own blockchain account parameters to decrypt the first cryptographic parameter ciphertext received by the receiving module to obtain the first cryptographic parameter.

[0133] It should be understood that in the second embodiment Figure 6 The cryptographic parameter control device 600 in the trusted blockchain can execute Figure 3 The method shown in FIG. 1 and the corresponding device are implemented in Figure 3 The functions of the embodiment shown. Figure 7 The cryptographic parameter control device 700 in the trusted blockchain can execute Figure 4 The method shown in FIG. 1 and the corresponding device are implemented in FIG. Figure 4 The functions of the illustrated embodiment will not be described in detail in this specification.

[0134] Example 3

[0135] Reference Figure 8 As shown, the embodiment of this specification also provides a trusted blockchain system 800, including:

[0136] At least one first client 802 generating a transaction, at least one second client 804 having management behavior permission, and a plurality of nodes 806; wherein the first client 802 and the second client 804 may be deployed with the second embodiment Figure 6 The cryptographic parameter control device 600 in the trusted blockchain is deployed with the second embodiment Figure 7 The cryptographic parameter control device 700 in the trusted blockchain is shown to achieve secure encryption and decryption of transaction data. Node 806 can be deployed with the second embodiment Figure 7 The cryptographic parameter control device 700 in the trusted blockchain is shown to achieve secure decryption of transaction data.

[0137] During the transaction encryption phase, the first client 802, as the encryption party, generates transaction data and encrypts the transaction data based on a locally generated second cryptographic parameter to obtain a transaction data ciphertext. Furthermore, the first cryptographic parameter obtained through a legitimacy verification method is used to encrypt the second cryptographic parameter to obtain a second cryptographic parameter ciphertext. A transaction is constructed using the transaction data ciphertext and the second cryptographic parameter ciphertext, and is signed and sent to a node 806 participating in the trusted blockchain.

[0138] During the transaction decryption phase, the other first client 802 or node 806 acts as the decryptor and receives the signed transaction. After verifying the transaction signature, the client obtains the first cryptographic parameter using a legitimacy verification method. The client uses the first cryptographic parameter to decrypt the ciphertext of the second cryptographic parameter in the transaction to obtain the second cryptographic parameter. The client also uses the second cryptographic parameter to decrypt the ciphertext of the transaction data in the transaction to obtain the transaction data.

[0139] The first cryptographic parameter is generated by a second client 804 with management behavior permission within the trusted blockchain and is encrypted and stored in a system-level smart contract.

[0140] Example 4

[0141] Figure 9 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 9 At the hardware level, the electronic device includes a processor and, optionally, an internal bus, a network interface, and memory. The memory may include internal memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for its services.

[0142] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 9 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0143] The memory is used to store programs. Specifically, the program may include program code, which includes computer operating instructions. The memory may include internal memory and non-volatile memory, and provides instructions and data to the processor.

[0144] The processor reads the corresponding computer program from the non-volatile memory into the internal memory and then runs it, forming a cryptographic parameter control device in the trusted blockchain at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0145] After generating transaction data, the transaction data is encrypted based on a second cryptographic parameter generated locally to obtain a transaction data ciphertext; the second cryptographic parameter is encrypted based on a first cryptographic parameter obtained in a legitimacy verification manner to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission within the trusted blockchain and encrypted and stored in a system-level smart contract; a transaction is constructed using the transaction data ciphertext and the second cryptographic parameter ciphertext, and is sent to nodes participating in the trusted blockchain after being signed.

[0146] or,

[0147] Receiving the signed transaction; after the transaction is signed and verified, obtaining a first cryptographic parameter using a legitimacy verification method, wherein the first cryptographic parameter is generated by a second client with management behavior permission within the trusted blockchain and encrypted and stored in a system-level smart contract; using the first cryptographic parameter to decrypt the ciphertext of the second cryptographic parameter in the transaction to obtain the second cryptographic parameter; using the second cryptographic parameter to decrypt the ciphertext of transaction data in the transaction to obtain the transaction data.

[0148] The above is as in this manual Figure 3 and Figure 4The methods performed by the apparatus disclosed in the illustrated embodiments can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be performed by hardware integrated logic circuits in the processor or by software instructions. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in one or more embodiments of this specification can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in conjunction with one or more embodiments of this specification can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0149] The electronic device may also perform Figure 3 and Figure 4 method, and implement the corresponding device in Figure 3 and Figure 4 The functions of the embodiments shown in this specification will not be described in detail here.

[0150] Of course, in addition to software implementation, the electronic device of the embodiments of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0151] Example 5

[0152] The embodiment of this specification also proposes a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including multiple application programs, can enable the portable electronic device to execute Figure 3 and Figure 4 The method of the embodiment shown is specifically used to perform the following method:

[0153] After generating transaction data, the transaction data is encrypted based on a second cryptographic parameter generated locally to obtain a transaction data ciphertext; the second cryptographic parameter is encrypted based on a first cryptographic parameter obtained in a legitimacy verification manner to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission within the trusted blockchain and encrypted and stored in a system-level smart contract; a transaction is constructed using the transaction data ciphertext and the second cryptographic parameter ciphertext, and is sent to nodes participating in the trusted blockchain after being signed.

[0154] or,

[0155] Receiving the signed transaction; after the transaction is signed and verified, obtaining a first cryptographic parameter using a legitimacy verification method, wherein the first cryptographic parameter is generated by a second client with management behavior permission within the trusted blockchain and encrypted and stored in a system-level smart contract; using the first cryptographic parameter to decrypt the ciphertext of the second cryptographic parameter in the transaction to obtain the second cryptographic parameter; using the second cryptographic parameter to decrypt the ciphertext of transaction data in the transaction to obtain the transaction data.

[0156] In short, the above description is only a preferred embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of protection of this specification.

[0157] The systems, devices, modules, or units described in one or more of the above embodiments may be implemented by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0158] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0159] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0160] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0161] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A method for controlling cryptographic parameters in a trusted blockchain, characterized in that: Applied to a first client serving as an encryption party, the method includes: After generating the transaction data, encrypting the transaction data based on a second cryptographic parameter generated locally to obtain a ciphertext of the transaction data; Encrypting the second cryptographic parameter based on the first cryptographic parameter obtained in the legitimacy verification method to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract; Constructing a transaction using the transaction data ciphertext and the second cryptographic parameter ciphertext, and sending it to nodes participating in the trusted blockchain after signing; The first password parameter is obtained in the following way: The encrypting party sends a cryptographic parameter distribution request to the second client, where the cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the encrypting party carried in the first cryptographic parameter distribution request, and store the encrypted parameter in the system-level smart contract. The encryption party searches for and obtains a first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract; The encryption party uses its own blockchain account parameters to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

2. A method for controlling cryptographic parameters in a trusted blockchain, characterized in that: Applied to a first client or node serving as a decryption party, the method includes: Receive the signed transaction; After the transaction signature is verified, a first cryptographic parameter is obtained using a legitimacy verification method, wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract; Decrypting the second cryptographic parameter ciphertext in the transaction using the first cryptographic parameter to obtain the second cryptographic parameter; decrypting the ciphertext of the transaction data in the transaction using the second cryptographic parameter to obtain the transaction data; The first password parameter is obtained in the following way: The decryption party sends a first cryptographic parameter distribution request to the second client, where the first cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the decryption party carried in the first cryptographic parameter distribution request, and store the encrypted data in the system-level smart contract. The decryption party searches and obtains the first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract; The decryption party uses its own blockchain account parameters to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

3. The cryptographic parameter control method in a trusted blockchain according to claim 2, wherein: The first password parameter is also obtained in the following manner: The decryption party sends a second cryptographic parameter distribution request to other nodes with which it has established a network connection. The second cryptographic parameter distribution request is used to instruct any other node to verify the second cryptographic parameter distribution request, and when the verification is legal and it is determined that the other node can obtain the first cryptographic parameter, the blockchain account parameter of the decryption party is used to encrypt the first cryptographic parameter obtained by the other node; The decryption party receives the first cryptographic parameter ciphertext returned by the other node, which is encrypted with its own blockchain account parameter; The decryption party uses its own blockchain account parameters to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

4. The method for controlling cryptographic parameters in a trusted blockchain according to claim 3, wherein: Other nodes that have established network connections with the decryption party include: Other nodes directly connected to the decryption party, and / or other nodes indirectly connected to the decryption party.

5. A cryptographic parameter control device in a trusted blockchain, characterized in that: include: a first encryption module, configured to, after generating transaction data, encrypt the transaction data based on a second cryptographic parameter generated locally to obtain a ciphertext of the transaction data; a second encryption module, configured to encrypt the second cryptographic parameter based on the first cryptographic parameter obtained in a legitimacy verification manner to obtain a second cryptographic parameter ciphertext; wherein the first cryptographic parameter is generated by a second client with management behavior permission within the trusted blockchain and encrypted and stored in a system-level smart contract; a transaction construction module, configured to construct a transaction using the transaction data ciphertext and the second cryptographic parameter ciphertext, and send the transaction to nodes participating in the trusted blockchain after signing; The second encryption module obtains the first password parameter in the following manner: The encrypting party sends a cryptographic parameter distribution request to the second client, where the cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the encrypting party carried in the first cryptographic parameter distribution request, and store the encrypted parameter in the system-level smart contract. The encryption party searches for and obtains a first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract; The encryption party uses its own blockchain account parameters to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

6. A cryptographic parameter control device in a trusted blockchain as claimed in claim 5, characterized in that: Also includes: a sending module, configured to send a first cryptographic parameter distribution request to the second client, wherein the first cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the encryption party carried in the first cryptographic parameter distribution request, and store the encrypted parameter in the system-level smart contract; An acquisition module, configured to search and obtain, from the system-level smart contract, a first cryptographic parameter ciphertext encrypted with its own blockchain account parameters; The decryption module is used to decrypt the obtained first cryptographic parameter ciphertext using its own blockchain account parameters to obtain the first cryptographic parameter.

7. A cryptographic parameter control device in a trusted blockchain, characterized in that: include: Receiving module, used to receive signed transactions; A first acquisition module is configured to obtain a first cryptographic parameter using a legitimacy verification method after the transaction signature is verified, wherein the first cryptographic parameter is generated by a second client with management behavior permission in the trusted blockchain and encrypted and stored in a system-level smart contract; a first decryption module, configured to decrypt the second cryptographic parameter ciphertext in the transaction using the first cryptographic parameter to obtain the second cryptographic parameter; a second decryption module, configured to decrypt the ciphertext of the transaction data in the transaction using the second cryptographic parameters to obtain the transaction data; The first acquiring module acquires the first password parameter in the following manner: The encrypting party sends a cryptographic parameter distribution request to the second client, where the cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the encrypting party carried in the first cryptographic parameter distribution request, and store the encrypted parameter in the system-level smart contract. The encryption party searches for and obtains a first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract; The encryption party uses its own blockchain account parameters to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

8. The cryptographic parameter control device in a trusted blockchain according to claim 7, wherein: Also includes: a sending module, configured to send a first cryptographic parameter distribution request to the second client, wherein the first cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the requesting party carried in the first cryptographic parameter distribution request, and store the encrypted data in the system-level smart contract; A second acquisition module is used to search and obtain the first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract; The third decryption module is used to decrypt the first cryptographic parameter ciphertext obtained by the second acquisition module using its own blockchain account parameters to obtain the first cryptographic parameter.

9. The cryptographic parameter control device in a trusted blockchain according to claim 8, characterized in that: The sending module is further configured to send a second cryptographic parameter distribution request to other nodes with which it has established a network connection, wherein the second cryptographic parameter distribution request is used to instruct any other node to verify the second cryptographic parameter distribution request, and when the verification is legal and it is determined that the other node itself can obtain the first cryptographic parameter, encrypt the first cryptographic parameter obtained by the other node using the blockchain account parameter of the decryptor; The receiving module is further configured to receive a first cryptographic parameter ciphertext returned by another node and encrypted with its own blockchain account parameters; The third decryption module is further used to use its own blockchain account parameters to decrypt the first cryptographic parameter ciphertext received by the receiving module to obtain the first cryptographic parameter.

10. A trusted blockchain system, characterized in that: include: at least one first client generating a transaction, at least one second client having permission to manage the transaction, and a plurality of nodes; During the transaction encryption phase: after generating transaction data, the first client, acting as the encryption party, encrypts the transaction data based on a locally generated second cryptographic parameter to obtain a transaction data ciphertext; and encrypts the second cryptographic parameter based on the first cryptographic parameter obtained through a legitimacy verification method to obtain a second cryptographic parameter ciphertext; a transaction is constructed using the transaction data ciphertext and the second cryptographic parameter ciphertext, and is sent to nodes participating in the trusted blockchain after signing. During the transaction decryption phase, another first client or node acts as a decryption party and receives the signed transaction. After verifying the transaction signature, the first cryptographic parameter is obtained using a legitimacy verification method. Decrypting the second cryptographic parameter ciphertext in the transaction using the first cryptographic parameter to obtain the second cryptographic parameter; decrypting the ciphertext of the transaction data in the transaction using the second cryptographic parameter to obtain the transaction data; The first cryptographic parameter is generated by a second client with management permission in the trusted blockchain and encrypted and stored in a system-level smart contract; The first password parameter is obtained in the following way: The encrypting party sends a cryptographic parameter distribution request to the second client, where the cryptographic parameter distribution request is used to instruct the second client to obtain and decrypt the first cryptographic parameter from the system-level smart contract, and to encrypt the first cryptographic parameter using the blockchain account parameter of the encrypting party carried in the first cryptographic parameter distribution request, and store the encrypted parameter in the system-level smart contract. The encryption party searches for and obtains a first cryptographic parameter ciphertext encrypted with its own blockchain account parameters from the system-level smart contract; The encryption party uses its own blockchain account parameters to decrypt the obtained first cryptographic parameter ciphertext to obtain the first cryptographic parameter.

11. An electronic device, characterized in that: include: processor; as well as A memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the method for controlling cryptographic parameters in a trusted blockchain as described in any one of claims 1 or 2-4.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores one or more programs, which, when executed by an electronic device including multiple application programs, enable the electronic device to execute the cryptographic parameter control method in the trusted blockchain as described in any one of claims 1 or 2-4.

Images