A multi-institution, multi-chain, multi-currency, and multi-account private key management method and system

Abstract

The present invention discloses a method and system for managing the private key of multiple institutions, multiple chains, multiple currencies and multiple accounts. The method includes: adjusting the childPath structural rule, wherein, according to the childPath structural rule, the childPath is defined as multi-character data including the chain type and the institution code type; generating a master private key according to the protocol, generating a management private key according to the master private key and the childPath structural rule; entering the restarted hardware system according to the management private key, using the management private key as the parent private key, and the business party passing in the institution representative, currency type and user code according to the demand to generate the address and childPath of the sub-account; when the business party needs to use the sub-account private key for signing, the address of the sub-account, the childPath and the transaction body Hash are passed in, and the hardware system selects a preset algorithm according to the childPath for signature processing. The technical solution of the present invention can centrally manage the private keys of multiple chains and multiple signatures, and the enterprise no longer needs to disperse the management of the sub-account private keys. This solution can not only solve the risks brought by Keystore, but also solve the shortcomings brought by HD wallets.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a multi-institution, multi-chain, multi-currency, and multi-account private key management method and system. Background Art

[0002] Blockchain technology is a new distributed infrastructure and computing method that uses block chain data structures to verify and store data, distributed node consensus algorithms to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script codes to program and operate data.

[0003] For current enterprise project parties, private key management is a very important and very tricky thing. Currently, there are two types of private key management methods: keystore storage and HD wallet.

[0004] 1. Keystore storage.

[0005] Keystore storage is a file format (JSON) for Ethereum wallets to store private keys. It uses a user-defined password to encrypt the private key to achieve a certain degree of protection, and the degree of protection of the wallet depends on the strength of the password used by the user to encrypt the wallet. Keystore generally encrypts the private key using the scrypt algorithm. scrypt not only takes a long time to calculate, but also occupies a lot of memory. It is extremely difficult to use parallel calculations for multiple digests, so it is even more difficult to use rainbow tables for brute force attacks.

[0006] When using the keystore, the user needs to remember the keystore encryption password. Once the encryption password is forgotten, the user will lose the right to use the keystore.

[0007] In addition, since most enterprise projects require programmatic and automatic processing, keystores and passwords are usually stored in a suitable place. However, when keystores and passwords can be accessed at the same time, the private key can also be decrypted, which poses a certain risk.

[0008] For each project, each currency, and each user, a keystore and password are required. When there are a large number of keystores, access may be difficult, and if there is a device failure or other problems, if the keystore is lost, it cannot be recovered.

[0009] In summary, the shortcomings of the Keystore storage method are as follows:

[0010] (1) Keystore is stored on disk and key is stored on data. If there is a problem with the server disk, the keystore file will be lost and the account assets cannot be recovered.

[0011] (2) A database failure occurs, resulting in data loss and irrecoverable loss. Account assets cannot be recovered;

[0012] (3) The database is hacked and all data is taken away, resulting in the transfer of assets;

[0013] (4) The database is hacked and the data is cleared, making it impossible to recover the assets;

[0014] (5) Operations and maintenance personnel commit malicious acts and illegally take away the keystore and password, resulting in the transfer of assets that cannot be traced;

[0015] (6) With multiple projects and multiple users, it is necessary to maintain many useless keystores, resulting in a waste of maintenance resources.

[0016] 2. HD wallet.

[0017] An HD wallet is a wallet account generated based on the BIP protocol.

[0018] Ordinary private key generation generally generates a 256-bit private key at random. In order to facilitate the management of private keys, HD wallets use the BIP protocol to replace the random 256-bit private key.

[0019] The wallet can derive half of the child keys under the parent key. The generation of the child keys uses the irreversible HMAC-SHA512 encryption algorithm. The child password cannot derive the parent key upwards, nor can it derive the keys of the same level horizontally.

[0020] In addition, if you know the HD wallet's mnemonic and the path to the sub-private key, you can recover the sub-private key.

[0021] HD wallets are usually stored as follows: multiple sub-private keys are stored in a wallet object. The wallet is then encrypted with a password and written into a DAT file.

[0022] In HD wallets, sub-accounts directly store the child's private keys. If the outermost layer of encryption is cracked by brute force, all child private keys will be visible to the outside world.

[0023] In summary, the shortcomings of HD wallets are as follows:

[0024] (1) HD wallets exist with nodes and can only store the private key of a single currency; multiple currencies require multiple nodes to maintain;

[0025] (2) The private key of the account stored in the HD wallet. If the wallet password is cracked, all the sub-private keys will be exposed;

[0026] (3) There is a problem with the server disk, the HD wallet is lost, and the account assets cannot be recovered;

[0027] (4) Nodes can only sign a single signature and cannot sign multiple chains or multiple currencies;

[0028] (5) The server is attacked by hackers, and the HD wallet file is cleared, making it impossible to recover the assets;

[0029] (6) In the case of multiple projects, HD wallets cannot distinguish between project owners, which may lead to confusion in usage;

[0030] (7) The number of users is too large, and HD wallets need to maintain many useless private keys, resulting in a waste of resources;

[0031] Therefore, it is necessary to provide a new multi-institution, multi-chain, multi-currency, and multi-account private key management method and system to solve the above technical problems. Summary of the invention

[0032] The main purpose of the present invention is to provide a multi-institution, multi-chain, multi-currency, and multi-account private key management method and system, aiming to solve the technical problems of decentralized management of private keys and high security risks in related technologies.

[0033] To achieve the above object, the present invention provides a multi-institution, multi-chain, multi-currency, and multi-account private key management method, comprising the following steps:

[0034] S1, adjusting the childPath structure rule, wherein, according to the adjusted childPath structure rule, childPath is defined as multi-character data including a chain type and an organization code type;

[0035] S2, generating a master private key according to a preset protocol, and generating a management private key according to the master private key and the childPath structure rule;

[0036] S3, enter the restarted hardware system according to the management private key, use the management private key as the parent private key, and the business party inputs the institution representative, currency type and user code according to the needs to generate the address and childPath of the sub-account;

[0037] S4, when the business party needs to use the sub-account private key for signing, it inputs the sub-account address, the childPath and the transaction body Hash, and the hardware system selects a preset algorithm for signature processing according to the childPath.

[0038] Preferably, the multi-character data also includes a protocol type, a currency type, an account number, a change identifier and an address index.

[0039] Preferably, the step of generating a master private key according to a preset protocol and generating a management private key according to the master private key and the childPath structure rule specifically includes the following steps:

[0040] Generate a mnemonic according to the BIP39 protocol, and use the mnemonic to generate corresponding seed data;

[0041] Generate the master private key and its corresponding chainCode according to the BIP32 protocol and the seed data;

[0042] The master private key and its corresponding chainCode are processed in a basic manner and output as a string, wherein the output string is the management private key corresponding to the master private key.

[0043] Preferably, the hardware system refuses to store the private key, address and childPath of the sub-account; the business party only stores the address and childPath belonging to the account.

[0044] In order to solve the above technical problems, the present invention also provides a multi-institution, multi-chain, multi-currency, and multi-account private key management system, including:

[0045] An adjustment module, the adjustment module is used to adjust the childPath structure rule, wherein, according to the adjusted childPath structure rule, childPath is defined as multi-character data including a chain type and an organization code type;

[0046] A first generation module, the first generation module is used to generate a master private key according to a preset protocol, and generate a management private key according to the master private key and the childPath structure rule;

[0047] A second generation module, the second generation module is used to enter the restarted hardware system according to the management private key, use the management private key as the parent private key, and the business party inputs the institution representative, currency type and user code according to the demand to generate the address and childPath of the sub-account;

[0048] The signature module is used for the business party to pass in the address of the sub-account, the childPath and the transaction body Hash when the business party needs to use the sub-account private key for signing. The hardware system selects a preset algorithm according to the childPath for signature processing.

[0049] Preferably, the multi-character data also includes a protocol type, a currency type, an account number, a change identifier and an address index.

[0050] Preferably, the first generating module is specifically used for:

[0051] Generate a mnemonic according to the BIP39 protocol, and use the mnemonic to generate corresponding seed data;

[0052] Generate the master private key and its corresponding chainCode according to the BIP32 protocol and the seed data;

[0053] The master private key and its corresponding chainCode are processed in a basic manner and output as a string, wherein the output string is the management private key corresponding to the master private key.

[0054] Preferably, the hardware system refuses to store the private key, address and childPath of the sub-account; the business party only stores the address and childPath belonging to the account.

[0055] The multi-institution, multi-chain, multi-currency, and multi-account private key management method and system provided by the present invention can realize that the total private key in the enterprise project is kept by the general person in charge, and the sub-private keys are centrally managed. The sub-private keys are all generated in real time to avoid the exposure of the sub-private keys after the wallet is brute-force cracked. It can ensure that the sub-account private keys do not leave the system, and are all generated in real time when needed. Therefore, it can be guaranteed that even if the operation and maintenance or development is malicious, the private key of the sub-account cannot be obtained. In addition, the childPath of the account is saved by the business party, not the system, so that the business and private keys are separated, and security is upgraded.

[0056] Because all sub-accounts are derived from the manager, all sub-accounts can be recovered, and even if the disk or database fails, it will not affect account security. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 A workflow diagram of a preferred embodiment of the multi-institution, multi-chain, multi-currency, and multi-account private key management method provided by the present invention;

[0058] Figure 2 for Figure 1 An architectural diagram of a hardware system in which the method shown is executed;

[0059] Figure 3 for Figure 1 The address hierarchy diagram in step S4 shown;

[0060] Figure 4 An architectural diagram of a preferred embodiment of the multi-institution, multi-chain, multi-currency, and multi-account private key management system provided by the present invention.

[0061] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings in conjunction with the embodiments. DETAILED DESCRIPTION

[0062] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0063] The present invention provides a multi-institution, multi-chain, multi-currency, and multi-account private key management method.

[0064] Please refer to Figure 1-3 To achieve the above purpose, in one embodiment of the present invention, a method for managing private keys of multiple institutions, multiple chains, multiple currencies and multiple accounts includes the following steps:

[0065] S1, adjusting the childPath structure rule, wherein, according to the adjusted childPath structure rule, childPath is defined as multi-character data including a chain type and an organization code type;

[0066] S2, generating a master private key according to a preset protocol, and generating a management private key according to the master private key and the childPath structure rule;

[0067] S3, enter the restarted hardware system according to the management private key, use the management private key as the parent private key, and the business party inputs the institution representative, currency type and user code according to the needs to generate the address and childPath of the sub-account;

[0068] In this embodiment, when the hardware system is restarted, the owner of the management private key is allowed to directly input it into the system, which can prevent the wallet from being stolen.

[0069] S4, when the business party needs to use the sub-account private key for signing, it inputs the sub-account address, the childPath and the transaction body Hash, and the hardware system selects a preset algorithm for signature processing according to the childPath.

[0070] In this embodiment, the hardware system refuses to store the private key, address and childPath of the sub-account; the business party only stores the address and childPath belonging to the account.

[0071] Specifically, the multi-character data also includes a protocol type, a currency type, an account number, a change identifier, and an address index.

[0072] Specifically, the structure of the multi-character data is as follows:

[0073] purpose' / chain_type' / coin_type' / org' / account' / change / address_index. Among them, purpose' is the protocol type, usually 44, representing the BIP44 protocol; chain_type' is the currency type; account' is the account number, usually starting from 0 and increasing; change is the change flag, indicating whether it is a change account. In BTC, 1 represents change, and 0 is usually used; address_index is the address index, which represents multiple address indexes under the user, and increases from 0. chain_type is the chain type; org is the organization code type, which is used to indicate the organization code.

[0074] This multi-character data structure can distinguish different institutions; as well as multiple currencies (such as tokens) on the same chain.

[0075] Specifically, the step S2 specifically includes the following steps:

[0076] Generate a mnemonic according to the BIP39 protocol, and use the mnemonic to generate the corresponding seed data;

[0077] Generate the master private key and its corresponding chainCode according to the BIP32 protocol and the seed data;

[0078] The master private key and its corresponding chainCode are processed in a basic manner and output as a string, wherein the output string is the management private key corresponding to the master private key.

[0079] Specifically, the master private key + ChainCode + Index can form a new Hash value. Then the 256 bits on the right side of the Hash are used as the chainCode of the child private key, and then the 256 bits on the left side are calculated with the master private key to obtain the child private key (management private key).

[0080] The multi-institution, multi-chain, multi-currency, and multi-account private key management method provided by the present invention can realize that the total private key in the enterprise project is kept by the general person in charge, and the sub-private keys are centrally managed. The sub-private keys are all generated in real time to avoid the exposure of the sub-private keys after the wallet is brute-force cracked. It can ensure that the sub-account private keys do not leave the system, and are all generated in real time when needed. Therefore, it can be guaranteed that even if the operation and maintenance or development is malicious, the private key of the sub-account cannot be obtained. In addition, the childPath of the account is saved by the business party, not the system, so that the business and private keys are separated, and the security is upgraded.

[0081] Because all sub-accounts are derived from the manager, all sub-accounts can be recovered, and even if the disk or database fails, it will not affect account security.

[0082] The present invention also provides a multi-institution, multi-chain, multi-currency, and multi-account private key management system.

[0083] See also Figure 4 , a private key management system for multiple institutions, multiple chains, multiple currencies and multiple accounts, including:

[0084] An adjustment module, the adjustment module is used to adjust the childPath structure rule, wherein, according to the adjusted childPath structure rule, childPath is defined as multi-character data including a chain type and an organization code type;

[0085] A first generation module, the first generation module is used to generate a master private key according to a preset protocol, and generate a management private key according to the master private key and the childPath structure rule;

[0086] A second generation module, the second generation module is used to enter the restarted hardware system according to the management private key, use the management private key as the parent private key, and the business party inputs the institution representative, currency type and user code according to the demand to generate the address and childPath of the sub-account;

[0087] In this embodiment, when the hardware system is restarted, the owner of the management private key is allowed to directly input it into the system, which can prevent the wallet from being stolen.

[0088] The signature module is used for the business party to pass in the address of the sub-account, the childPath and the transaction body Hash when the business party needs to use the sub-account private key for signing. The hardware system selects a preset algorithm according to the childPath for signature processing.

[0089] In this embodiment, the hardware system refuses to store the private key, address and childPath of the sub-account; the business party only stores the address and childPath belonging to the account.

[0090] Specifically, the multi-character data also includes a protocol type, a currency type, an account number, a change identifier, and an address index.

[0091] Specifically, the structure of the multi-character data is as follows:

[0092] purpose' / chain_type' / coin_type' / org' / account' / change / address_index. Among them, purpose' is the protocol type, usually 44, representing the BIP44 protocol; chain_type' is the currency type; account' is the account number, usually starting from 0 and increasing; change is the change flag, indicating whether it is a change account. In BTC, 1 represents change, and 0 is usually used; address_index is the address index, which represents multiple address indexes under the user, and increases from 0. chain_type is the chain type; org is the organization code type, which is used to indicate the organization code.

[0093] This multi-character data structure can distinguish different institutions; as well as multiple currencies (such as tokens) on the same chain.

[0094] Specifically, the first generating module is specifically used for:

[0095] Generate a mnemonic according to the BIP39 protocol, and use the mnemonic to generate the corresponding seed data;

[0096] Generate the master private key and its corresponding chainCode according to the BIP32 protocol and the seed data;

[0097] The master private key and its corresponding chainCode are processed in a basic manner and output as a string, wherein the output string is the management private key corresponding to the master private key.

[0098] Specifically, the master private key + ChainCode + Index can form a new Hash value. Then the 256 bits on the right side of the Hash are used as the chainCode of the child private key, and then the 256 bits on the left side are calculated with the master private key to obtain the child private key (management private key).

[0099] The hardware system refuses to store the private key, address and childPath of the sub-account; the business party only stores the address and childPath belonging to the account.

[0100] The multi-institution, multi-chain, multi-currency, and multi-account private key management system provided by the present invention can realize that the total private key in the enterprise project is kept by the general person in charge, and the sub-private keys are centrally managed. The sub-private keys are all generated in real time to avoid the exposure of the sub-private keys after the wallet is brute-force cracked. It can ensure that the sub-account private keys do not leave the system, and are all generated in real time when needed. Therefore, it can be guaranteed that even if the operation and maintenance or development is malicious, the private key of the sub-account cannot be obtained. In addition, the childPath of the account is saved by the business party, not the system, so that the business and private keys are separated, and the security is upgraded.

[0101] Because all sub-accounts are derived from the manager, all sub-accounts can be recovered, and even if the disk or database fails, it will not affect account security.

[0102] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a computer-readable storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device to enter the method described in each embodiment of the present invention.

[0103] In the description of this specification, the description with reference to the terms "an embodiment", "another embodiment", "other embodiments", or "first embodiment to Xth embodiment" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, method steps or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0104] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including the element.

[0105] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0106] The above are only preferred embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for managing private keys of multiple institutions, multiple chains, multiple currencies and multiple accounts, characterized in that: The steps include: S1, adjusting the childPath structure rule, wherein, according to the adjusted childPath structure rule, childPath is defined as multi-character data including a chain type and an organization code type; S2, generating a master private key according to a preset protocol, and generating a management private key according to the master private key and the childPath structure rule; S3, enter the restarted hardware system according to the management private key, use the management private key as the parent private key, and the business party inputs the institution representative, currency type and user code according to the needs to generate the address and childPath of the sub-account; S4, when the business party needs to use the sub-account private key for signing, it inputs the sub-account address, the childPath and the transaction body Hash, and the hardware system selects a preset algorithm according to the childPath for signature processing; The hardware system refuses to store the private key, address and childPath of the sub-account; the business party only stores the address and childPath belonging to the account; The multi-character data also includes a protocol type, a currency type, an account number, a change identifier, and an address index; Specifically, the structure of the multi-character data is as follows: purpose' / chain_type' / coin_type' / org' / account' / change / address_index; purpose' is the protocol type, which is 44, representing the BIP44 protocol; chain_type' is the currency type; account' is the account number, which increases from 0; change is the change flag, indicating whether it is a change account; address_index is the address index, which represents multiple address indexes under the user, which increases from 0; chain_type is the chain type; org is the organization code type, which is used to indicate the organization code; The structure of the multi-character data can distinguish different institutions; and there are multiple currencies on the same chain; The step of generating a master private key according to a preset protocol and generating a management private key according to the master private key and the childPath structure rule specifically includes the following steps: Generate a mnemonic according to the BIP39 protocol, and use the mnemonic to generate the corresponding seed data; Generate the master private key and its corresponding chainCode according to the BIP32 protocol and the seed data; Perform basic processing on the master private key and its corresponding chainCode, and output a string, wherein the output string is the management private key corresponding to the master private key; The master private key + ChainCode + Index forms a new Hash value, and then the 256 bits on the right side of the Hash are used as the chainCode of the sub-private key, and then the 256 bits on the left side and the master private key are calculated to obtain the sub-private key, which is the management private key.

2. A multi-institution, multi-chain, multi-currency, multi-account private key management system, characterized in that: include: An adjustment module, the adjustment module is used to adjust the childPath structure rule, wherein, according to the adjusted childPath structure rule, childPath is defined as multi-character data including a chain type and an organization code type; A first generation module, the first generation module is used to generate a master private key according to a preset protocol, and generate a management private key according to the master private key and the childPath structure rule; A second generation module, which is used to enter the restarted hardware system according to the management private key, use the management private key as the parent private key, and the business party inputs the institution representative, currency type and user code according to the needs to generate the address and childPath of the sub-account; The signature module is used for the business party to input the sub-account address, the childPath and the transaction body Hash when the business party needs to use the sub-account private key for signing, and the hardware system selects a preset algorithm according to the childPath for signature processing; The hardware system refuses to store the private key, address and childPath of the sub-account; the business party only stores the address and childPath belonging to the account; The multi-character data also includes a protocol type, a currency type, an account number, a change identifier, and an address index; Specifically, the structure of the multi-character data is as follows: purpose' / chain_type' / coin_type' / org' / account' / change / address_index; purpose' is the protocol type, which is 44, representing the BIP44 protocol; chain_type' is the currency type; account' is the account number, which increases from 0; change is the change flag, indicating whether it is a change account; address_index is the address index, which represents multiple address indexes under the user, which increases from 0; chain_type is the chain type; org is the organization code type, which is used to indicate the organization code; The structure of the multi-character data can distinguish different institutions; and there are multiple currencies on the same chain; The first generating module is specifically used for: Generate a mnemonic according to the BIP39 protocol, and use the mnemonic to generate the corresponding seed data; Generate the master private key and its corresponding chainCode according to the BIP32 protocol and the seed data; Perform basic processing on the master private key and its corresponding chainCode, and output a string, wherein the output string is the management private key corresponding to the master private key; The master private key + ChainCode + Index forms a new Hash value, and then the 256 bits on the right side of the Hash are used as the chainCode of the sub-private key, and then the 256 bits on the left side and the master private key are calculated to obtain the sub-private key, which is the management private key.

Images