CN116155483A

CN116155483A - Block chain signing machine safety design method and signing machine

Info

Publication number: CN116155483A
Application number: CN202210872265.5A
Authority: CN
Inventors: 郭伟基; 周晨程; 孙英男; 王炜煜
Original assignee: Shanghai Encryption Native Technology Co ltd
Current assignee: Shanghai Encryption Native Technology Co ltd
Priority date: 2022-07-20
Filing date: 2022-07-20
Publication date: 2023-05-23

Abstract

The application provides a safe design method of a block chain signature machine, which comprises the following steps: obtaining a plurality of shares of the first level key from a plurality of component holders in response to the signature request; recovering the first level key from the plurality of shares; and recovering a subsequent key according to the first-level key, wherein the subsequent key is used for deriving a blockchain private key. According to the technical scheme, a multistage key system is adopted, a step-by-step encryption mode is adopted, a component holder can only master the component of a first-stage key, and after the first-stage key is recovered, the first-stage key can only be used for recovering a subsequent key, so that the problem that the component holder can be separated from a signer to directly recover a blockchain private key is avoided, and the problem of safety design of the signer is solved.

Description

Block chain signing machine safety design method and signing machine

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to a blockchain signer security design method, a signer, a computer device, and a computer readable storage medium.

Background

Asymmetric encryption algorithms and public-private key pairs are widely used on blockchains, where the private key can be used to prove ownership of the address on the chain, and thus the asset with which the address is associated, etc. Therefore, security management of private keys is critical in blockchain applications. Even on some public chains, the private key is the only credential that proves ownership, unlike a bank account: if a user forgets the bank card password, the user can go to the bank by identity authentication to reset the password, and on the blockchain, particularly on some public chains, the related assets cannot be recovered once the private key is lost.

The signer manages the private keys of important assets, and the security design of the signer is very important in order to securely manage the private keys (blockchain private keys).

Disclosure of Invention

The invention aims to provide a safe design method of a blockchain signer, the signer, computer equipment and a computer readable storage medium, which are used for solving the problem of safe design of the signer.

An aspect of an embodiment of the present application provides a method for securely designing a blockchain signer, including: obtaining a plurality of shares of the first level key from a plurality of component holders in response to the signature request; recovering the first level key from the plurality of shares; and recovering a subsequent key according to the first-level key, wherein the subsequent key is used for deriving a blockchain private key.

Optionally, the first-level key is divided into n parts by using a secret division algorithm, any t parts of the first-level key is recovered, and any less than t parts of the first-level key cannot be recovered; said recovering said first level key from said plurality of shares comprises: recovering the first-stage secret key according to the t components by using a secret division algorithm; and comparing the first-level key with pre-stored integrity information to ensure that the first-level key is correctly recovered.

Optionally, the comparing the first-level key with pre-stored integrity information includes: pre-storing first check information as integrity information, wherein the first check information is obtained by combining a correct first-level key with preset parameters by using a check algorithm; obtaining second verification information by combining the preset parameters by using a verification algorithm through the recovered first-level secret key; comparing whether the first check information is completely identical to the second check information; if the first level key is completely identical, the first level key is correctly recovered; if not exactly equivalent, the first level key is not recovered correctly.

Optionally, the recovering a subsequent key according to the first-level key includes: recovering a second-level key according to the first-level key; and recovering a third-level key according to the second-level key.

Optionally, the recovering the second-level key according to the first-level key includes: pre-storing first pre-stored information, wherein the first pre-stored information is obtained by encrypting the second-stage key by using a first encryption algorithm in combination with a first grouping mode and first additional information, and the first pre-stored information comprises a first ciphertext and first integrity protection additional information; and using the recovered first-level key as a key, and decrypting the second-level key from the first pre-stored information by using a first encryption algorithm in combination with the first packet mode and the first additional information.

Optionally, the recovering the third-level key according to the second-level key includes: pre-storing second pre-stored information, wherein the second pre-stored information is obtained by encrypting the third-level key by using a second encryption algorithm in combination with a second grouping mode and second additional information, and the second pre-stored information comprises second ciphertext and second integrity protection additional information; and using the recovered second-level key as a key, and decrypting the third key from the second pre-stored information by using a second encryption algorithm in combination with the second packet mode and the second additional information.

Optionally, the block chain signer security design method further includes: receiving a first signature request, wherein the first signature request comprises preset information, and the preset information is information to be signed; providing the preset information to a plurality of component holders for confirmation; receiving a second signature request; if the second signature request accords with the preset information and the preset information is valid, signing the second signature request, and if the number of times of signing reaches a preset limit after the signing is finished, the preset information is invalid; and rejecting the second signature request if the second signature request does not coincide with the preset information or the preset information has been invalid.

Optionally, the block chain signer security design method further includes: setting a white list of information to be signed, wherein the filtering condition of the white list is one or more characteristics of the information to be signed; receiving a signature request; if the signature request accords with the white list, signing the signature request; and if the signature request does not accord with the white list, rejecting the signature request.

Optionally, the block chain signer security design method further includes: recording the preset information and the confirmation information of the preset information as audit basis; and/or reporting the preset information and the confirmation information of the preset information by sending a mail or calling a workflow, and taking the preset information and the confirmation information of the preset information as audit basis.

An aspect of an embodiment of the present application further provides a signing machine, including: an acquisition module for acquiring a plurality of components of the first-level key from a plurality of component holders in response to the signature request; and the recovery module is used for recovering the first-level key according to the multiple components and recovering the subsequent key according to the first-level key, wherein the subsequent key is used for deriving a blockchain private key.

An aspect of the embodiments of the present application further provides a computer device including a memory, a processor, and a computer program stored on the memory and executable on the processor, which when executed implements the steps of the blockchain signer security design method as described above.

An aspect of the embodiments of the present application further provides a computer readable storage medium comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, which when executed implements the steps of the blockchain signer security design method as described above.

According to the block chain signing machine safety design method, the signing machine, the computer equipment and the computer readable storage medium, a multistage key system is adopted, a step-by-step encryption mode is adopted, a component holder can only master the component of a first-stage key, after the first-stage key is recovered, the first-stage key can only be used for recovering a subsequent key, and therefore the problem that the component holder can be separated from the signing machine to directly recover the block chain private key is avoided, and the safety design problem of the signing machine is solved.

Drawings

FIG. 1 schematically illustrates a schematic diagram of a multi-level key hierarchy in a blockchain signer security design method in accordance with an embodiment of the present application;

FIG. 2 schematically illustrates a flow chart of a multi-level key hierarchy in a blockchain signer security design method in accordance with an embodiment of the present application;

FIG. 3 is a sub-step diagram of step S202 in FIG. 2;

FIG. 4 is a sub-step diagram of step S302 in FIG. 3;

FIG. 5 is a sub-step diagram of step S204 in FIG. 2;

FIG. 6 is a sub-step diagram of step S500 in FIG. 5;

FIG. 7 is a sub-step diagram of step S502 in FIG. 5;

FIG. 8 schematically illustrates a flowchart of preset information validation and one-time signature design in a blockchain signer security design method in accordance with an embodiment of the present application;

FIG. 9 schematically illustrates a flow chart of a whitelist regimen in a blockchain signer security design method in accordance with an embodiment of the present application;

FIG. 10 schematically illustrates a flow chart of mail or flow records in a blockchain signer security design method in accordance with an embodiment of the present application;

FIG. 11 schematically illustrates one example diagram of a multi-level key hierarchy in the blockchain signer security design method of the present application;

FIG. 12 schematically illustrates one exemplary diagram of preset information validation and whitelist filtering in the blockchain signer security design method of the present application;

fig. 13 schematically shows a block diagram of a signer according to a second embodiment of the present application; a kind of electronic device with high-pressure air-conditioning system

Fig. 14 schematically illustrates a hardware architecture diagram of a computer device suitable for implementing a blockchain signer security design method in accordance with embodiment three of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

It should be noted that the descriptions of "first," "second," etc. in the embodiments of the present application are for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions of the embodiments may be combined with each other, but it is necessary to base that the technical solutions can be realized by those skilled in the art, and when the technical solutions are contradictory or cannot be realized, the combination of the technical solutions should be regarded as not exist and not within the protection scope of the present application.

In the description of the present application, it should be understood that the numerical references before the steps do not identify the order of performing the steps, but are only used for convenience in describing the present application and distinguishing each step, and thus should not be construed as limiting the present application.

The following is an explanation of terms involved in the present application:

shamir secret segmentation algorithm: shamir's Secret Sharing, SSS for short, is a cryptographic algorithm, typically with n and t as parameters (t is not greater than n). An SSS algorithm can be used for safely dividing a secret value s into n parts of components, and recovering the secret value by collecting any t parts of components; at the same time, any component less than t will not result in a partial or complete disclosure of the secret value s. One way to implement SSS is to split the secret value byte by byte over GF 256; for example, if the secret value has 128 bits, it is divided into 16 bytes, and each byte is divided; when recovering, each byte needs to be recovered, and then the recovered bytes are spliced into a secret value. There are also implementations in which the whole secret value is divided as a large integer; such implementations, if unnoticed, may have a certain security breach.

GF256: one type of galois field, having 256 elements, has a value between 0 and 255, which is just an unsigned integer range of one byte in a computer, is suitable for processing single byte data and is therefore often used in cryptography. Galois fields have their own unique addition and multiplication algorithms. GF256 is added as a bitwise exclusive or in a computer, and may be considered as binary addition without carry; the multiplication generally needs to interpret a byte as a seven-degree maximum unitary polynomial, each bit is a corresponding coefficient, and the multiplication on GF256 is the multiplication of two polynomials (bitwise exclusive or calculation is used when the same kind of polynomials are combined), the obtained polynomial is divided by a certain preset modular polynomial, and the remainder polynomial is taken as the multiplication result.

Seed: on a blockchain, it is sometimes not necessary to keep a corresponding private key for each encrypted asset or each public chain, but rather by using a "seed" in combination with certain rules to derive the corresponding private key for each encrypted asset or each public chain, the number of secrets that need to be kept is reduced while technically ensuring that in case a private key is compromised, the other private keys remain secure.

Signing machine: a technical facility for realizing a Shamir secret segmentation algorithm can safely receive components segmented by an SSS algorithm, complete recovery of secret values, and further derive private keys of a blockchain to complete needed signatures. It is often necessary to provide both hardened system and network security measures, and also to employ hardware-level secret computing capabilities as needed to maximize the security of secret values.

White list: a security mechanism that allows access to or manipulation of resources on a list to be exempted from certain security checks to increase convenience while maintaining security.

Component and component holder: the SSS algorithm divides the secret value into a plurality of components, distributes the components to designated personnel for management, and cooperates with a proper management system. These persons may be referred to as component holders.

The following generally describes the blockchain signer security design scheme of the present application in conjunction with the related art of the present application The technical effects that can be achieved are provided later for a plurality of embodiments for implementing a blockchain signer security design scheme.

The blockchain private key (simply referred to as the "private key") is very important, once lost or will not be remediable.

For secure management of private keys, many technical facilities have been developed. Only a part of the related technologies are listed here, and there are mainly technologies based on smart contracts, and technologies based on Shamir secret-segmentation algorithms.

Wherein the intelligent contract-based technology is that related parameters are registered on a chain and assets are hosted to the intelligent contract; when the asset is required to be used, signature information meeting the share requirement is submitted to the intelligent contract, and once the requirement is met, the intelligent contract can operate the asset according to the requirement.

In general, the technique based on Shamir secret division algorithm divides related secret values, gives them to a plurality of persons for storage, and when an asset is needed, recovers the secret values and derives a secret key to complete the signature.

The above-mentioned intelligent contract-based technology needs to directly send signature information to a chain to complete related operations, and its application occasions are limited to a certain extent. For example, it is sometimes necessary to complete an under-chain signature to authenticate an identity to a platform. The convenience is also insufficient, for example, one-time multi-person signature can only be used for authorizing one contract call in a chain and cannot be applied repeatedly.

The technology based on the SSS algorithm can be used for a signature scene under a chain, but is complex in operation, and is difficult to consider both safety and convenience. If the secret value needs to be recovered once for each signature, the convenience is greatly reduced; if the secret value is recovered first, the related device provides the service later, and after the service interface is controlled by an attacker, the attacker can sign any information by using the service, so that the asset loss is caused. In addition, if the secret value directly corresponds to the seed or private key of the asset, the secret value can also lead to the fact that the multi-component holder can separate from the signature machine to recover the private key of the asset by himself after collusion, and then the asset is operated.

The objects and technical effects achieved by the present invention will be described with respect to these drawbacks.

In order to break through the limitation, the application achieves the balance of safety and convenience through four safety mechanisms on the basis of an SSS algorithm:

first, a multi-level key, step-by-step encryption (multi-level key hierarchy). The method designs a plurality of keys, and a component holder only grasps the segmentation of the first-level key; after the first-level secret key is recovered by the component holder, the first-level secret key can only be used for recovering the next-level secret key, so that the problem that the component holder can directly recover the asset private key by separating from the signer is avoided. All keys carry integrity check information, so that ciphertext information cannot be replaced or tampered.

Secondly, the information confirmation and the one-time signature design are preset. The method comprises the steps that before a secret value is restored, information to be signed is fixed, and each component holder participating in restoring the secret value is required to confirm the fixed information clearly; the fixed information and the confirmation thereof are recorded at the same time and used as audit basis; before signing, the signing machine compares whether the signature information accords with preset information, and if not, the signing machine refuses to sign; after the signature is completed, the preset information is automatically disabled. This design can avoid that after the secret value is restored, an attacker can sign arbitrary information or sign preset information multiple times (e.g., multiple transfers to an address) after controlling the service interface.

Thirdly, a white list system. According to the method and the device, the white list of the content to be signed is set, so that the content (the specific intelligent contract interface call, the specific type of data signature, the content signature conforming to the specified filtering condition and the like) on the white list can be repeatedly called for multiple times, and the calling times are limited to be specified on the white list, so that the balance of safety and convenience is achieved.

Fourth, mail or flow records. The application requires that the signer send mail to a designated mail address after completing signing each time, or call related workflow of an office automation system, and report related information of the signature in summary, including but not limited to signature content, transfer amount, destination address or address and method of intelligent contract, parameters, etc. And ensuring that audit basis is left for each signature.

The method is proved to be effective through actual measurement. Compared with the background art, the scheme has the following advantages:

1. the personnel risk can be avoided to a certain extent, and the multistage key system ensures that the component holder cannot directly recover the asset private key; meanwhile, all asset operations have mail or flow records, and any cheating behavior can be found in time;

2. can give consideration to safety and convenience. The method not only allows the multi-time signature (such as contract call) of the specific content, but also does not need to repeatedly recover the secret value, and simultaneously ensures that all the signatures are confirmed in advance.

The block chain signer safety design method and the signer can select multi-level keys The system is one security mechanism, or one or more of the multi-level key system and the three security mechanisms can be selected simultaneously And each.

Various embodiments are provided below, which may be used to implement the above descriptionBlock chain Signature machine safety design method and signature machine. For ease of understanding, an exemplary description will be made below with the signer as an execution subject.

Example 1

Fig. 1 schematically illustrates a schematic diagram of a multi-level key hierarchy in a blockchain signer security design method according to an embodiment of the present application.

As an example, a multi-bit component holder that meets preset parameters may first co-recover a first level key within the signer that is not an asset seed or private key (blockchain private key), but is used to encrypt a secondary key (e.g., a second level key). The key of a subsequent level (e.g., a third level key) may be used as an asset seed. The integrity of the first-stage key is protected by the integrity information so as to avoid errors in the process of recovering the first-stage key by using an SSS algorithm, thereby causing errors in subsequent encryption and decryption calculation. The integrity of the subsequent keys (e.g., second level key, third level key) is ensured by the packet mode applied by the symmetric encryption algorithm.

It should be noted that, the key used to derive the blockchain private key may be a level of encryption subsequent to the first level of key Keys such as: second level key, third level key, fourth level key, fifth level key, etc., fig. 1 shows third level key as a representation The present application is not limited to this example.

Fig. 1 is an exemplary illustration of a multi-level key hierarchy in the signer of the present application, and details of the implementation may be found in fig. 2-7 below.

Fig. 2 schematically illustrates a flow chart of a multi-level key hierarchy in a blockchain signer security design method in accordance with an embodiment of the present application.

As shown in fig. 2, the block chain signer security design method of the present application is applied to a signer, and may include steps S200 to S204, wherein:

step S200, in response to the signature request, a plurality of components of the first-level key are acquired from the plurality of component holders.

By way of example, the signer may be a software service provided through a network interface. It is generally recommended to use special server hardware, deploy in an intranet security environment of a using organization, set strict access right control, and further adopt a firewall for protection. The signature request is typically transmitted through a network, typically an HTTPS interface, but other transmission protocols may be accepted, which belongs to the technical field of the surrounding and is not limited to the content of the application.

As an example, the identity of the component holder is not limited, and the component holder is arbitrarily specified by an organization using a signing machine, and is generally a member of a business team, and multiple teams can be allocated to jointly hold components in consideration of higher security, such as a business team windy team, an internal control team, a financial team, and the like, in this way, a single team can be avoided from hosting the first-level key. In addition, external personnel can be invited to participate. Everything is determined by the use mechanism itself.

It should be noted that, the manner of holding the component is not limited to the scope of the present invention, and the present invention is not limited to the manner of holding the component, and may be recommended to use some kind of secure password management software (including desktop software or mobile App) or hardware.

In the design of the embodiment of the application, after collusion of the multi-bit component holder or leakage of the component held by the component holder, the multi-bit component holder can only recover the first-level key and cannot recover the signature private key from the signer. Therefore, the embodiment of the present application is not limited to the component holder and the component holding manner. Of course, in practical use, confirmation is required in combination with specific situations, such as identity recognition of the component holder, system access restriction, use of password management software or hardware, and the like.

As an example, the first-stage Key1 is split into n components (e.g., key1part1, key1part2, key1part3, key1part4, key1part 5) by using a secret splitting algorithm, any t component (e.g., key1part1, key1part2, key1part 3) recovers the first-stage Key1, and any less than t component cannot recover the first-stage Key.

In an exemplary embodiment of the present application, the secret-segmentation algorithm may be a Shamir secret-segmentation algorithm (SSS algorithm). The embodiment of the application is based on an SSS algorithm. The SSS algorithm used in the embodiments of the present application is implemented based on GF256.SSS algorithms and GF256 please see the term interpretation section.

For example, the first-stage Key1 may be a 128-bit random number generated by a certain random number generator that is safe to use, and is decomposed into 16 bytes: byte1, byte2, …, byte16.

The SSS algorithm allows arbitrary partitioning schemes, the specific implementation needs to depend on the actual management needs, for example, a 5-3 partitioning scheme can be set, i.e. Key1 is safely partitioned into 5 parts, and Key1 can be recovered by using any three parts of the partitioning schemes. The segmented components can be further segmented by using an SSS algorithm, and a relatively complex segmentation scheme is constructed. The following is exemplified only with a 5-3 split scheme.

Using SSS algorithm and calculating on a certain GF256 field, dividing each byte into 5 parts, each part still being one byte, to obtain five corresponding bytes, which may be respectively numbered as byte_i_j, where i is the corresponding original byte number, values 1 to 16, and j is the component number divided by the byte { i }, values 1 to 5. Key1part1 consists of 16 bytes, in order: byte_1_1, byte_2_1, byte_3_1, … byte_16_1, and key1part2 are composed of another 16 bytes in sequence: byte_1_2, byte_2_2, byte_3_2, … byte_16_2, and so on. Five split components of Key1 are thus obtained: key1part1, key1part2, key1part3, key1part4, key1part5.

Key1part1, key1part2, key1part3, key1part4, key1part5 are assigned to the component holder. The embodiment of the present application is not limited to the specific embodiment provided, but in general, the public key may be provided by the component holder, encrypted based on the provided public key, and then transmitted to the component holder, which decrypts the public key using the private key and stores the encrypted public key.

Returning to fig. 2, step S202 restores the first-level key according to the multiple components.

As an example, as shown in fig. 3, the step S202 may include steps S300 to S302. Wherein: step S300, recovering the first-stage secret key according to the t-share component by using a secret division algorithm; step S302, the first-level key is compared with pre-stored integrity information to ensure that the first-level key is correctly recovered.

As an example, as shown in fig. 4, the step S302 may include steps S400 to S408. Wherein: step S400, pre-storing first check information as integrity information, wherein the first check information is obtained by combining a correct first-stage key with preset parameters by using a check algorithm (such as a PBKDF algorithm); step S402, a verification algorithm is used for combining the preset parameters by utilizing the recovered first-level secret key to obtain second verification information; step S404, comparing whether the first check information is completely identical with the second check information; step S406, if the first-level keys are completely identical, the first-level keys are correctly recovered; step S408, if not completely equivalent, the first level key is not recovered correctly.

In an exemplary embodiment of the present application, the PBKDF is a Password-Based Key Derivation Function, and the key derivation function based on the Password has two standards, namely PBKDF1 and PBKDF2, and it is recommended to use PBKDF2.PBKDF2 is specified in pkcs#5v2.0 and RFC 2898, and PBKDF2 is recommended in RFC8010 for message authentication (Message Authentication) purposes, i.e. for integrity checking as used in the embodiments of the present application.

It should be noted that the PBKDF is only an example, and other algorithms can only ensure that incorrect Key1 can be found with a high probability, and that Key1 cannot be back-pushed from the verification information. Such as: in addition to the PBKDF algorithm, the Argon2 algorithm, which is the HPC (Password Hashing Competition, cryptographic hash contest) winner, may also be used.

Returning to fig. 2, in step S204, a subsequent key is recovered according to the first-level key, where the subsequent key is used to derive a blockchain private key.

As an example, as shown in fig. 5, the step S204 may include steps S500 to S502. Wherein: step S500, recovering a second-stage Key Key2 according to the first-stage Key Key 1; step S502, recovering a third-level Key3 according to the second-level Key 2.

As an example, as shown in fig. 6, the step S500 may include steps S600 to S602. Wherein: step S600, pre-storing first pre-stored information, wherein the first pre-stored information is obtained by encrypting the second-level key by using a first encryption algorithm (such as a symmetric encryption algorithm SM4 or AES) and combining a first grouping mode (such as GCM) and first additional information (aad), and the first pre-stored information comprises a first ciphertext and first integrity protection additional information; in step S602, the second level key is decrypted from the first pre-stored information by using the first encryption algorithm in combination with the first packet mode and the first additional information with the restored first level key as the key. The approach of fig. 6 may guarantee the integrity of the second level key.

In an exemplary embodiment of the present application, the first encryption algorithm may be a symmetric encryption algorithm (such as AES or SM 4); the GCM, galois/Counter Mode (Galois Counter Mode), can perform integrity checking on the encrypted message.

In an exemplary embodiment of the present application, key2 itself is a 128-bit or 192-bit, or 256-bit random number (the length of which is not limited by the embodiments of the present application) generated by some use-safe random number generator. A symmetric encryption algorithm (such as AES or SM 4) may be used to encrypt a packet mode with ciphertext integrity protection (such as GCM) to obtain Key2Encrypted, which includes the ciphertext (cipher) obtained by encryption and the integrity protection additional information (tag). So-called integrity protection, i.e. the calculation of an additional information (tag), optionally some additional information (aad) may be introduced at the time of the encryption calculation, in order to verify that Key2Encrypted has not been tampered with at the time of decryption, optionally by providing the same additional information (aad).

The Key2Encrypted is the pre-stored information. Key2 can be decrypted from Key2Encrypted using Key1 as the Key using the same symmetric encryption algorithm, packet mode, and additional information (aad).

It should be noted that the foregoing is merely illustrative, and not limiting the scope of the present application, aad is optional, and tag may be obtained by using GCM.

As an example, as shown in fig. 7, the step S502 may include steps S700 to S702. Wherein: step S700, pre-storing second pre-stored information, wherein the second pre-stored information is obtained by encrypting the third-level key by using a second encryption algorithm in combination with a second grouping mode and second additional information, and the second pre-stored information comprises second ciphertext and second integrity protection additional information; in step S702, the second encryption algorithm is used to combine the second packet mode and the second additional information with the recovered second-level key as a key, and the third key is decrypted from the second pre-stored information. The implementation of fig. 7 may ensure the integrity of the third level key.

Fig. 8 schematically illustrates a flowchart of preset information validation and one-time signature design in a blockchain signer security design method according to an embodiment of the present application.

As shown in fig. 8, the blockchain signer security design method according to the first embodiment of the present application may include steps S800 to S808, wherein:

Step S800, a first signature request is received, wherein the first signature request comprises preset information, and the preset information is information to be signed.

Step S802, providing the preset information to a plurality of component holders for confirmation.

Step S804, a second signature request is received.

Step S806, if the second signature request matches the preset information and the preset information is valid, signing the second signature request, and if the number of signatures has reached the preset limit after the signing is completed, the preset information is invalid.

Step S808, if the second signature request does not match the preset information, or the preset information has been invalidated, rejecting the second signature request.

Regarding an example of confirmation of the preset information, for example, a message (preset information) that one million-element digital rmb is transferred to the address a and that can be called only once by default is preset, each component holder needs to confirm the message (preset information) definitely when providing its own component, so that after the private key is recovered/derived, only one million-element digital rmb is transferred to the address a and only one million-element digital rmb is transferred, and the two million-element digital rmb cannot be transferred to other addresses, or more than one million-element digital rmb cannot be transferred at a time. By this means, funds are secured.

Regarding the number of signatures, depending on the traffic demand, in general, the default number is 1, i.e., the pre-set information after signature is invalidated. The special application scene is not excluded from needing to initiate the signature of similar information again or for multiple times, and the result of one-time authorization and multiple-time signature can be achieved by setting higher time limit, so that convenience is improved.

Fig. 9 schematically illustrates a flowchart of a whitelist system in a blockchain signer security design method according to an embodiment of the present application.

As shown in fig. 9, the blockchain signer security design method of the first embodiment of the present application may include steps S900 to S906, wherein:

step S900, a white list of the information to be signed is set, and the filtering condition of the white list is one or more characteristics of the information to be signed.

Step S902, a signature request is received.

Step S904, if the signature request conforms to the white list, signing the signature request.

Step S906, if the signature request does not conform to the white list, rejecting the signature request.

By way of example, the embodiment of the application enables the content on the white list (such as a specific intelligent contract interface call, a specific type of data signature, a content signature conforming to a specified filtering condition, etc.) to be repeatedly called for a plurality of times by setting the white list of the content to be signed, and the call times limit can be specified on the white list, so that the balance between safety and convenience is achieved.

With respect to examples of specific smart contract interface calls, for example, invoking a certain method or methods of a contract located at a specified address. The white list may be applied to the address level, i.e. all methods of the address contract may be called, or may be further limited to the method level of the contract, i.e. only a certain method or methods may be called.

With respect to instances of particular types of data signatures, possible data types include: and (5) transferring the message. The whitelist may be imposed on specific parameters of the data type, for example, transfers to several addresses may be released unconditionally, or transfers below a certain amount may be released a limited number of times, thereby improving convenience.

With respect to instances of content signatures that meet specified filtering criteria, many platforms, for example, require a user to sign a message that meets a particular template using a private key, often with the name of the platform, which can be used as the filtering criteria. Assuming that a certain platform name is OpenSky (pure assumption), the platform may require the user to sign a piece of text containing OpenSky when authenticating the user's identity. Therefore, openSky can be used as a white list filtering condition, and a message containing OpenSky can be signed by release.

It should be noted that any feature of the message to be signed can be used as a white list filtering condition, which is completely dependent on the service requirement.

Fig. 10 schematically illustrates a flowchart of mail or flow records in a blockchain signer security design method according to an embodiment of the present application.

As shown in fig. 10, the blockchain signer security design method according to the first embodiment of the present application may include steps S1002 to S1004, wherein:

step S1002, recording the preset information and the confirmation information of the preset information as audit basis.

Step S1004, reporting the preset information and the confirmation information of the preset information by sending a mail or calling a workflow, and taking the preset information and the confirmation information of the preset information as audit basis.

As an example, the embodiments of the present application require that the signer send mail to a designated mail address after each completion of signing, or invoke a related workflow of an office automation system, summarize and report related information for the signature, including but not limited to signature content, transfer amount, address and method of a destination address or smart contract, parameters, etc. And ensuring that audit basis is left for each signature.

FIG. 11 schematically illustrates one example diagram of a multi-level key hierarchy in the blockchain signer security design method of the present application.

As an example, when the signing machine receives a signing request through the service interface, the signing machine obtains the split components key1part1, key1part2, key1part3 of the first-level key from the component holder one, the component holder two, and the component holder three (only as an example here), and recovers the first-level key1 according to the first-level key split components key1part1, key1part2, and key1part 3. In order to ensure that there is no error (e.g., a component is input in error or is replaced by an attacker in the dark) in the recovery process, the recovered key1 needs to be compared with the pre-stored integrity information. The comparison method is that a correct key1 key is calculated as a verification information V1 by using a PBKDF algorithm and combining with a certain parameter, and the verification information V1 is pre-stored in a system. The restored key1 uses the same algorithm to calculate a piece of check information V2, and then compares whether V1 is completely identical with V2; if the key1 is completely equivalent, the key1 is correctly restored, otherwise, the key1 is not correctly restored. The PBKDF algorithm is only an example, and other algorithms can ensure that incorrect key1 can be found with a high probability, and key1 cannot be reversely deduced from the verification information.

After the first-level key1 is recovered, the key1 is used for decrypting certain pre-stored information, and then the second-level key2 can be recovered. The pre-stored information is obtained by encrypting key2 using key1 as a key. The encryption algorithm uses a symmetric encryption algorithm in combination with a grouping mode with ciphertext integrity verification, such as a GCM mode, to verify the integrity of the ciphertext while decrypting and prevent pre-stored information from being tampered or replaced by an attacker. The third level key3 is recovered from the second level key2 similarly.

In an exemplary embodiment of the present application, the third level key3 is a seed within the blockchain hierarchy. Seeds can be exported into private keys for different blockchains (bitcoin, ethernet or a certain alliance chain, etc.), different networks (main network, test network) and different paths through a hierarchical deterministic wallet (for example, a plurality of private key export paths can be further subdivided on the ethernet main network, so as to achieve the aim of managing a plurality of addresses for the ethernet main network), thereby achieving the aim of controlling a plurality of asset addresses by using one secret value (seed).

FIG. 12 schematically illustrates one exemplary diagram of default information validation and whitelist filtering in the blockchain signer security design method of the present application.

It should be noted that fig. 12 illustrates exemplary preset information validation and whitelist filtering designs of the present invention, wherein the embodied decision sequences are exemplary only, and the relative sequences may be altered without affecting the protection points of the embodiments of the present application.

Step 1200, receiving a signature request through a service interface, and determining whether the signature request accords with preset information.

Step 1202, if the signature request meets the preset information, whether the number of times limit is met.

In step 1204, if the count limit is met, the signature is signed and returned.

Step S1208, if the number of times limit is not met, the signature is rejected and returned.

In step 1206, if the signature request does not meet the preset information, it is determined whether the white list screening is passed.

At step 1204, if the white list is screened, the signature is signed and returned.

Step S1208, if the white list screening is not passed, the signature is rejected and returned.

Compared with the background technology, the embodiment of the application has the following advantages:

(1) The multi-level secret key and the step-by-step encryption mode enable an administrator not to directly master the asset seeds or the private keys and not to separate from the signature machine to recover the asset seeds or the private keys by themselves;

(2) Firstly, confirming and re-signing, and limiting the safety design of the information to be signed and the number of signing times, so that the problem that after a secret value is recovered collectively, an operator provides other information to be signed, signs any information by bypassing a collective confirmation link to cause asset loss, or repeatedly signs the same information for a plurality of times to cause asset loss is avoided;

(3) The white list design gives consideration to convenience and safety;

(4) The signing machine integrates internal workflow or mail sending capability, so that auditable records are attached to each asset utilization and are notified to related personnel, and illegal asset operation can be found out in time to the greatest extent. For signature requests which do not accord with preset information and are not on the white list, the signature requests can be sent to related responsible persons through mails or workflow records to play a role in early warning.

Example two

Fig. 13 schematically shows a block diagram of a signer according to a second embodiment of the present application. The signer may be partitioned into one or more program modules, which are stored in a storage medium and executed by one or more processors to accomplish the embodiments of the present application. Program modules in the embodiments of the present application refer to a series of computer program instruction segments capable of implementing specific functions, and the following description specifically describes the functions of each program module in the embodiment.

As shown in fig. 13, the signer may include an acquisition module 1301 and a recovery module 1303.

The acquisition module 1301 is configured to acquire multiple shares of the first-level key from multiple component holders in response to a signature request.

The recovering module 1303 is configured to recover the first-level key according to the multiple components, and recover a subsequent key according to the first-level key, where the subsequent key is used to derive a blockchain private key.

As an example, the first-level key is split into n shares by using a secret splitting algorithm, any t shares of the components recover the first-level key, and any less than t shares of the components cannot recover the first-level key. The recovery module 1303 is further configured to: recovering the first-stage secret key according to the t components by using a secret division algorithm; and comparing the first-level key with pre-stored integrity information.

As an example, the restoration module 1303 is further configured to: pre-storing first check information as integrity information, wherein the first check information is obtained by combining a correct first-level key with preset parameters by using a check algorithm (such as PBKDF); obtaining second verification information by combining the preset parameters by using a verification algorithm through the recovered first-level secret key; comparing whether the first check information is completely identical to the second check information; if the first level key is completely identical, the first level key is correctly recovered; if not exactly equivalent, the first level key is not recovered correctly.

As an example, the restoration module 1303 is further configured to: recovering a second-level key according to the first-level key; and recovering a third-level key according to the second-level key.

As an example, the restoration module 1303 is further configured to: pre-storing first pre-stored information, wherein the first pre-stored information is obtained by encrypting the second-stage key by using a first encryption algorithm in combination with a first grouping mode and first additional information, and the first pre-stored information comprises a first ciphertext and first integrity protection additional information; and using the recovered first-level key as a key, and decrypting the second-level key from the first pre-stored information by using the first encryption algorithm in combination with the first packet mode and the first additional information.

As an example, the restoration module 1303 is further configured to: pre-storing second pre-stored information, wherein the second pre-stored information is obtained by encrypting the third-level key by using a second encryption algorithm in combination with a second grouping mode and second additional information, and the second pre-stored information comprises second ciphertext and second integrity protection additional information; and using the recovered second-level key as a key, and decrypting the third key from the second pre-stored information by using the second encryption algorithm in combination with the second packet mode and the second additional information.

As shown in fig. 13, the signer may also include a validation module 1305.

As an example, the validation module 1305 is to: receiving a first signature request, wherein the first signature request comprises preset information, and the preset information is information to be signed; providing the preset information to a plurality of component holders for confirmation; receiving a second signature request; if the second signature request accords with the preset information and the preset information is valid, signing the second signature request, and if the number of times of signing reaches a preset limit after signing is finished, the preset information is invalid; and rejecting the second signature request if the second signature request does not coincide with the preset information or the preset information has been invalid.

As shown in fig. 13, the signer may also include a filter module 1307.

As an example, the filtering module 1307 is for: setting a white list of information to be signed, wherein the filtering condition of the white list is one or more characteristics of the information to be signed; receiving a signature request; if the signature request accords with the white list, signing the signature request; and if the signature request does not accord with the white list, rejecting the signature request.

As shown in fig. 13, the signer may also include a logging module 1309.

As an example, the recording module 1309 is configured to: recording the preset information and the confirmation information of the preset information as audit basis; and/or reporting the preset information and the confirmation information of the preset information by sending a mail or calling a workflow, and taking the preset information and the confirmation information of the preset information as audit basis.

Example III

Fig. 14 schematically illustrates a hardware architecture diagram of a computer device 1000 suitable for implementing a blockchain signer security design method in accordance with embodiment three of the present application. In an exemplary embodiment of the present application, the computer apparatus 1000 may be an apparatus capable of automatically performing numerical calculation and/or information processing according to a preset or stored instruction. For example, it may be a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server, or a rack server (including a stand-alone server, or a server cluster composed of a plurality of servers), a gateway, or the like. As shown in fig. 14, the computer device 1000 includes at least, but is not limited to: the memory 1010, processor 1020, and network interface 1030 may be communicatively linked together by a system bus. Wherein:

Memory 1010 includes at least one type of computer-readable storage medium including flash memory, hard disk, multimedia card, card memory (e.g., SD or DX memory, etc.), random Access Memory (RAM), static Random Access Memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 1010 may be an internal storage module of the computer device 1000, such as a hard disk or memory of the computer device 1000. In other embodiments, the memory 1010 may also be an external storage device of the computer device 1000, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like, which are provided on the computer device 1000. Of course, the memory 1010 may also include both internal memory modules of the computer device 1000 and external memory devices. In this embodiment, the memory 1010 is typically used to store an operating system installed on the computer device 1000 and various types of application software, such as program code for a blockchain signer security design method. In addition, the memory 1010 can also be used to temporarily store various types of data that have been output or are to be output.

The processor 1020 may be a central processing unit (Central Processing Unit, simply CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 1020 is generally used to control the overall operation of the computer device 1000, such as performing control and processing related to data interaction or communication with the computer device 1000, and the like. In this embodiment, processor 1020 is used to execute program code or process data stored in memory 1010.

The network interface 1030 may include a wireless network interface or a wired network interface, with the network interface 1030 typically being used to establish a communications link between the computer device 1000 and other computer devices. For example, the network interface 1030 is used to connect the computer device 1000 to an external terminal through a network, establish a data transmission channel and a communication link between the computer device 1000 and the external terminal, and the like. The network may be a wireless or wired network such as an Intranet (Intranet), the Internet (Internet), a global system for mobile communications (Global System of Mobile communication, abbreviated as GSM), wideband code division multiple access (Wideband Code Division Multiple Access, abbreviated as WCDMA), a 4G network, a 5G network, bluetooth (Bluetooth), wi-Fi, etc.

It should be noted that fig. 14 only shows a computer device having components 1010-1030, but it should be understood that not all of the illustrated components are required to be implemented and that more or fewer components may be implemented instead.

In this embodiment, the blockchain signer security design method stored in the memory 1010 may also be partitioned into one or more program modules and executed by one or more processors (processor 1020 in this embodiment) to complete the embodiments of the present application.

Example IV

The present application also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the blockchain signer security design method in an embodiment.

In this embodiment, the computer-readable storage medium includes a flash memory, a hard disk, a multimedia card, a card memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the computer readable storage medium may be an internal storage unit of a computer device, such as a hard disk or a memory of the computer device. In other embodiments, the computer readable storage medium may also be an external storage device of a computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card), etc. that are provided on the computer device. Of course, the computer-readable storage medium may also include both internal storage units of a computer device and external storage devices. In this embodiment, the computer readable storage medium is typically used to store an operating system and various types of application software installed on a computer device, such as program code for a block chain signer security design method in the embodiment. Furthermore, the computer-readable storage medium may also be used to temporarily store various types of data that have been output or are to be output.

It will be apparent to those skilled in the art that the modules or steps of the embodiments of the application described above may be implemented in a general purpose computing device, they may be concentrated on a single computing device, or distributed across a network of computing devices, they may alternatively be implemented in program code executable by computing devices, so that they may be stored in a storage device for execution by computing devices, and in some cases, the steps shown or described may be performed in a different order than what is shown or described, or they may be separately fabricated into individual integrated circuit modules, or multiple modules or steps of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the claims, and all equivalent structures or equivalent processes using the descriptions and drawings of the present application, or direct or indirect application in other related technical fields are included in the scope of the claims of the present application.

Claims

1. A method for securely designing a blockchain signer, comprising:

Obtaining a plurality of shares of the first level key from a plurality of component holders in response to the signature request;

recovering the first level key from the plurality of shares;

and recovering a subsequent key according to the first-level key, wherein the subsequent key is used for deriving a blockchain private key.

2. The blockchain signer security design method of claim 1, wherein the first level key is partitioned into n shares by a secret partitioning algorithm, any t shares of the first level key is recovered, and any less than t shares of the first level key cannot be recovered;

said recovering said first level key from said plurality of shares comprises:

recovering the first-stage secret key according to the t components by using a secret division algorithm;

and comparing the first-level key with pre-stored integrity information to ensure that the first-level key is correctly recovered.

3. The blockchain signer security design method of claim 2, wherein the comparing the first level key with pre-stored integrity information includes:

pre-storing first check information as integrity information, wherein the first check information is obtained by combining a correct first-level key with preset parameters by using a check algorithm;

Obtaining second verification information by combining the preset parameters by using a verification algorithm through the recovered first-level secret key;

comparing whether the first check information is completely identical to the second check information;

if the first level key is completely identical, the first level key is correctly recovered;

if not exactly equivalent, the first level key is not recovered correctly.

4. The blockchain signer security design method of claim 1, wherein the recovering a subsequent key from the first level key comprises:

recovering a second-level key according to the first-level key;

and recovering a third-level key according to the second-level key.

5. The blockchain signer security design method of claim 4, wherein the recovering a second level key from the first level key comprises:

pre-storing first pre-stored information, wherein the first pre-stored information is obtained by encrypting the second-stage key by using a first encryption algorithm in combination with a first grouping mode and first additional information, and the first pre-stored information comprises a first ciphertext and first integrity protection additional information;

and using the recovered first-level key as a key, and decrypting the second-level key from the first pre-stored information by using a first encryption algorithm in combination with the first packet mode and the first additional information.

6. The blockchain signer security design method of claim 5, wherein the recovering a third level key from the second level key comprises:

pre-storing second pre-stored information, wherein the second pre-stored information is obtained by encrypting the third-level key by using a second encryption algorithm in combination with a second grouping mode and second additional information, and the second pre-stored information comprises second ciphertext and second integrity protection additional information;

and using the recovered second-level key as a key, and decrypting the third key from the second pre-stored information by using a second encryption algorithm in combination with the second packet mode and the second additional information.

7. The blockchain signer security design method of any of claims 1-6, further comprising:

receiving a first signature request, wherein the first signature request comprises preset information, and the preset information is information to be signed;

providing the preset information to a plurality of component holders for confirmation;

receiving a second signature request;

if the second signature request accords with the preset information and the preset information is valid, signing the second signature request, and if the number of times of signing reaches a preset limit after signing is finished, the preset information is invalid;

And rejecting the second signature request if the second signature request does not coincide with the preset information or the preset information has been invalid.

8. The blockchain signer security design method of any of claims 1-6, further comprising:

setting a white list of information to be signed, wherein the filtering condition of the white list is one or more characteristics of the information to be signed;

receiving a signature request;

if the signature request accords with the white list, signing the signature request;

and if the signature request does not accord with the white list, rejecting the signature request.

9. The blockchain signer security design method of any of claims 1-6, further comprising:

recording the preset information and the confirmation information of the preset information as audit basis; and/or

Reporting the preset information and the confirmation information of the preset information by sending mails or calling a workflow, and taking the preset information and the confirmation information of the preset information as audit basis.

10. A signing machine, comprising:

an acquisition module for acquiring a plurality of components of the first-level key from a plurality of component holders in response to the signature request;

And the recovery module is used for recovering the first-level key according to the multiple components and recovering the subsequent key according to the first-level key, wherein the subsequent key is used for deriving a blockchain private key.

11. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor, when executing the computer program, is operative to implement the steps of the blockchain signer security design method of any of claims 1-9.

12. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, the computer program being executable by at least one processor to cause the at least one processor to perform the steps of the blockchain signer security design method of any of claims 1-9.