CN116155484A - Block chain collective signature method and signature machine - Google Patents

Abstract

The application provides a blockchain collective signature method, which is applied to a signing machine, and comprises the following steps: receiving a call of a browser plug-in, and receiving a first signature request, wherein the first signature request comprises preset information; providing the preset information to a plurality of component holders for confirmation; acquiring multiple components of the multiple component holders, and recovering a secret value according to the multiple components; deriving a blockchain private key from the secret value; receiving the call of the browser plug-in again, and receiving a second signature request; and when the second signature request accords with the preset information, signing the second signature request by utilizing the blockchain private key. According to the technical scheme, the signature machine and the browser plug-in can be opened, and the browser plug-in is adapted to the safety design requirement of the signature machine through twice calling design, so that the signature machine and the browser plug-in are fused better.

Description

Block chain collective signature method and signature machine

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a blockchain collective signature method, a signing machine, 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. Therefore, security management of private keys is critical.

The signer manages the private keys of the important assets, and has security design requirements for securely managing the private keys (blockchain private keys).

Meanwhile, blockchain ecology widely applies browser plug-ins to authenticate identity.

However, the security design requirements of the signer are not well integrated with the browser plug-in.

Disclosure of Invention

The object of the present application is to provide a blockchain collective signature method, a signature machine, a computer device, and a computer-readable storage medium for solving the following technical problems: the security design requirements of the signer are not well integrated with the browser plug-in.

An aspect of an embodiment of the present application provides a blockchain collective signature method, applied to a signer, the method including: receiving a call of a browser plug-in, and receiving a first signature request, wherein the first signature request comprises preset information; providing the preset information to a plurality of component holders for confirmation; acquiring multiple components of the multiple component holders, and recovering a secret value according to the multiple components; deriving a blockchain private key from the secret value; receiving the call of the browser plug-in again, and receiving a second signature request; and when the second signature request accords with the preset information, signing the second signature request by utilizing the blockchain private key.

Optionally, the signer includes a service interface; the receiving the call of the browser plug-in, receiving a first signature request, including: and receiving the first signature request from the browser plug-in through the service interface, wherein the first signature request comprises the preset information, and the preset information is first information to be signed.

Optionally, the providing the preset information to the plurality of component holders for confirmation includes: displaying the preset information to the plurality of component holders for confirmation; and receiving confirmation information of the plurality of component holders for the preset information.

Optionally, the obtaining multiple components of the multiple component holders, recovering a secret value according to the multiple components, includes: if the preset information is legal, receiving a plurality of components input by the plurality of component holders; recovering a first level key from the plurality of components; and recovering a subsequent key according to the first-level key.

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, wherein the third-level key is the secret value.

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 the first encryption algorithm in combination with the first packet mode and the first additional information.

Optionally, recovering a third level key from the second level key includes: pre-storing the 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 a second ciphertext and second integrity protection additional information; and using the recovered second-level key as a key, and decrypting the third-level 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.

Optionally, the deriving the blockchain private key from the secret value includes: the blockchain private key is derived from the secret value using a hierarchical deterministic wallet specification.

Optionally, the receiving the call of the browser plug-in again, receiving a second signature request includes: a second signature request is received from the browser plug-in through the service interface, the second signature request including second information to be signed.

Optionally, when the second signature request matches the preset information, signing the second signature request with the blockchain private key includes: comparing whether the second information to be signed accords with the preset information or not; if the second information to be signed is consistent with the preset information and the preset information is valid, signing the second information to be signed by using the blockchain private key, and if the signing times reach a preset limit after the signing is completed, invalidating the preset information; and if the second information to be signed does not accord with the preset information or the preset information fails, rejecting the second signature request.

Optionally, the preset information and the second information to be signed both include a one-time secure random number or a timestamp, and the one-time secure random number or the timestamp is not in the comparison range.

Optionally, the blockchain collective signature method further includes: initializing the signer.

Optionally, the blockchain collective signature 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 the embodiments of the present application further provides a blockchain collective signature method applied to a signer and a browser plug-in, the method including: the browser plug-in calls the signing machine and sends a first signing request to the signing machine, wherein the first signing request comprises preset information; the signer provides the preset information to a plurality of component holders for confirmation; the signer acquires multiple components of the multiple component holders, and recovers a secret value according to the multiple components; the signer derives a blockchain private key according to the secret value; the browser plug-in calls the signing machine again and sends a second signing request to the signing machine; and when the second signature request accords with the preset information, the signing machine signs the second signature request by utilizing the blockchain private key.

An aspect of an embodiment of the present application further provides a signing machine, including: the first calling module is used for receiving the call of the browser plug-in and receiving a first signature request, and the first signature request comprises preset information; the confirmation module is used for providing the preset information for a plurality of component holders to confirm; a recovery module, configured to obtain multiple components of the multiple component holders, and recover a secret value according to the multiple components; the deriving module is used for deriving a blockchain private key according to the secret value; the second calling module is used for receiving the call of the browser plug-in again and receiving a second signature request; and the signature module is used for signing the second signature request by utilizing the blockchain private key when the second signature request accords with the preset information.

An aspect of the embodiments of the present application further provides a computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the blockchain collective signature method as described above when executing the computer program.

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 collective signature method as described above.

According to the blockchain collective signature method, the signing machine, the computer equipment and the computer readable storage medium, the signing machine and the browser plug-in can be opened, and the browser plug-in is adapted to the safety design requirement of the signing machine through twice calling design, so that the signing machine and the browser plug-in are fused better.

Drawings

FIG. 1 schematically illustrates an overall architecture diagram of a blockchain collective signature method in accordance with an embodiment of the present application;

FIG. 2 schematically illustrates a flow chart of a blockchain collective signature method in accordance with an embodiment of the present application;

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

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

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

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

FIG. 7 is a sub-step diagram of step S600 in FIG. 6;

FIG. 8 is a sub-step diagram of step S602 in FIG. 6;

FIG. 9 is a sub-step diagram of step S206 in FIG. 2;

FIG. 10 is a sub-step diagram of step S208 in FIG. 2;

FIG. 11 is a sub-step diagram of step S210 in FIG. 2;

FIG. 12 schematically illustrates a flow chart of initialization in a blockchain collective signature method in accordance with the first embodiment of the present application;

FIG. 13 schematically illustrates a flow chart of mail or flow records in a blockchain collective signature method in accordance with an embodiment of the present application;

FIG. 14 schematically illustrates another flow diagram of a blockchain collective signature method in accordance with an embodiment of the present application;

FIG. 15 schematically illustrates one particular example diagram of a blockchain collective signature method of the present application;

FIG. 16 schematically illustrates another example diagram of a blockchain collective signature method of the present application;

fig. 17 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. 18 schematically illustrates a hardware architecture diagram of a computer device adapted to implement the blockchain collective signature method according to the third embodiment 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.

Plug-in and browser plug-in: a technical component can be called by a webpage program to complete specific functions by realizing an interface of a specific web browser.

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.

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 an appropriate management system. These persons may be referred to as component holders.

The blockchain collective signature scheme and capabilities of the present application are generally described in conjunction with the related art of the present application The technical effects achieved are provided hereinafter for implementing the block collective signature scheme described below.

The secure management of the private key is critical. One method is to divide a secret value by SSS, so that multiple people hold components, and a small amount of components are lost or leaked, so that the secret is not lost or leaked, and the purpose of protecting the private key is achieved.

Meanwhile, the blockchain ecology widely applies browser plug-ins to complete various interactions of accounts, wherein the browser plug-in links are used for signing specific messages to authenticate the identity of the user to some platforms, and the user usually proves to hold a private key corresponding to an address, so that after the identity is authenticated, certain services of the corresponding platform are used.

A method of managing secret values using a secret segmentation algorithm (e.g., SSS algorithm) is not well integrated with a use scenario of authenticating identities using browser plug-ins. The browser plug-in cannot directly support a plurality of people to commonly manage the secret value through an SSS algorithm; besides, even if the browser plug-in can be technically modified to support the SSS algorithm, a series of other security problems need to be solved, and other problems such as audit records, internal personnel prevention, malicious plug-in protection and the like are solved.

This deficiency leads to the following consequences: or the security is sacrificed, the private key is imported into the browser plug-in, and the signature required by the platform is completed; or sacrifice convenience or functionality, freeing up related functional incompleteness.

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

In order to break through the limitations, the embodiment of the application opens up the browser plug-in and the signer platform supporting the secret segmentation algorithm, so that the collective confirmation of multiple persons is required for each signing, the integrity of audit records is ensured, and the application scenario of the browser plug-in can be adapted. In particular, to adapt to the security requirement of the signing machine, the invention creatively proposes a security scheme of two signature calls: for the information requiring signature by the browser plug-in, the first call is only submitted to the signing machine as preset information, and all component holders confirm the preset information one by one and then recover the secret value together, so as to derive the private key required by the signature; after this step, the expected time of the browser is often exceeded, so that the browser plug-in is required to send out a signature request again; the signing machine can directly compare the signing request with preset information, and if the signing request is matched with the preset information, the signing is completed. Thus, all signature information can be guaranteed to be commonly confirmed by a plurality of people.

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

(1) The security performance of the signature machine technology can be maintained, namely, the private key is managed by multiple persons together, the asset use needs to be confirmed by the multiple persons together, and audit records can be left. The related security techniques are not background;

(2) The universal interface (namely browser plug-in) in the docking industry can be connected without excessive technical development;

(3) The invention can ensure that team assets are always in a collective management state because the adopted technology does not need to sacrifice security performance for adapting to the universal interfaces in the industry, so that no one needs to bear the burden of managing large assets and the loss caused by possible loss or leakage of private keys for adapting to the universal interfaces in the industry, thereby greatly reducing psychological stress of team members, reliably ensuring the safety of the assets and achieving extremely beneficial technical and social effects.

Various embodiments are provided below, which may be used to implement the above descriptionBlock chain Collective signature scheme. For ease of understanding, the signer and browser plugins will be used as followsThe execution body is exemplarily described.

Example 1

Fig. 1 schematically shows an overall architecture diagram of a blockchain collective signature method according to an embodiment of the present application.

As shown in fig. 1, the overall architecture of the embodiment of the present application includes a signer 10, a browser 20, a plug-in 21 (browser plug-in 21) running in the browser, and a multi-bit component holder.

In the following, by way of example, a description will be given of what scenario, which is merely exemplary and not intended to limit embodiments of the present application, a blockchain collective signature method using a browser plug-in is required.

In an exemplary embodiment of the present application, if it is desired to sign an authentication identity using a private key (blockchain private key) managed in the signer 10, a platform named OpenSky is registered. The OpenSky platform requires the user to sign the following piece of text:

this is the OpenSky platform, who signs the message text to authenticate himself as a. Secure random number: b (B)

Wherein A is the block chain address corresponding to the private key managed by the signing machine. B is a random number generated by the platform side (OpenSky), and the platform side will also check the aging of B after verifying the signature, so as to prevent someone from replaying the signature information of other people to impersonate the identity (i.e. Replay Attack).

The reason for the need to use a signer is that the private key involved is already managed in the signer and cannot be exported outside the signer for security reasons.

The signer manages the private keys of the important assets, which cannot be remedied once lost or stolen. To prevent loss of the private key or to protect against ethical risks (e.g., piracy of assets), it is necessary to ensure that the private key is commonly managed by multiple persons. For example, a signer may be set to be commonly managed by five administrators, and any three of them may recover the private key and sign transaction information or other information through the signer.

Fig. 2 schematically illustrates a flowchart of a blockchain collective signature method according to an embodiment of the present application.

As shown in fig. 2, the blockchain signer security design method in the embodiment of the present application is applied to a signer, and may include steps S200 to S210, where:

step S200, receiving a first signature request by receiving a call of a browser plug-in, wherein the first signature request comprises preset information.

By way of example, the signer 10 may be a software service provided through a service interface (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 over a network, typically an HTTPS interface, but other transmission protocols may be accepted, which is not part of the present disclosure.

As an example, as shown in fig. 3, the step S200 may include a step S300. Wherein: step S300, a first signature request is received from a browser plug-in through a service interface, wherein the first signature request comprises preset information, and the preset information is first information to be signed.

As an example, the first signature request mainly takes a message requiring a signature as preset information. The preset information may be a piece of text (for example, the above-mentioned "this is the OpenSky platform, the person signs the message text to authenticate the person's blockchain address as a. Security random number: B"), or a transfer message, or an intelligent contract call message, etc.; whatever the type of traffic, it is the data to be signed (the first to be signed information) for the signer.

Referring back to fig. 2, step S202 provides the preset information to the plurality of component holders for confirmation.

As an example, as shown in fig. 4, the step S202 may include steps S400 to S402. Wherein: step S400, displaying the preset information to the plurality of component holders for confirmation; step S402, receiving confirmation information of the plurality of component holders for the preset information.

In the embodiment of the application, the purpose of the preset information confirmation is to ensure the safety of the asset. Therefore, the specific manner in which the preset information is presented to the component holder, or details of how the component holder confirms, etc., the present invention is not limited. But for example, the preset information may simply be displayed to the component holder; in the case of transfer messages or smart contract invoicing messages, appropriate formatting may be performed to highlight key information such as transfer amount, payee address, contract invocation methods and parameters, etc. to facilitate the component holder in confirming the business significance of the operation.

The identity of the component holder is not limited, the component holder is arbitrarily specified by an organization using a signature machine, and is generally a member of a certain business team, and a plurality of teams can be allocated to jointly hold the component in consideration of higher security, such as a business team windy team, an internal control team, a financial team and the like, so that a single team can be prevented from mastering a first-level key. In addition, external personnel can be invited to participate. Everything is determined by the use mechanism itself.

The manner in which the components are held is not limited by the embodiments of the present application, and some secure password management software (including desktop software or cell phone App) or hardware may be used and recommended.

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.

Returning to fig. 2, in step S204, a plurality of components of the plurality of component holders are acquired, and a secret value is recovered according to the plurality of components.

As an example, as shown in fig. 5, the step S204 may include steps S500 to S504. Wherein: step S500, if the preset information is legal, receiving a plurality of components input by the plurality of component holders; step S502, recovering a first-stage key according to the components; step S504, recovering the subsequent key according to the first-level key.

As an example, a first-level key is split into n parts by using a secret splitting algorithm, any t parts of the first-level key are 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.

As an example, as shown in fig. 6, the step S504 may include steps S600 to S602. Wherein: step S600, recovering a second-level key according to the first-level key; step S602, recovering a third-level key according to the second-level key, where the third-level key is the secret value and is used to derive a blockchain private key.

It should be noted that, the secret value may be a certain level of key subsequent to the first level of key, for example: a second-level key, Third level keys, fourth level keys, etc., the third level keys are exemplified in fig. 6, but the present application is not limited thereto.

Fig. 5 and 6 depict a multi-level key hierarchy in the signer, which may be a two-level key hierarchy, a three-level key hierarchy, a four-level key hierarchy, etc., that ensures that the component holder cannot directly recover the blockchain private key, ensuring asset security.

As an example, as shown in fig. 7, the step S600 may include steps S700 to S702. Wherein: step S700, 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 S702, 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 a key.

The approach of fig. 7 ensures 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, the second level 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 random number generator that is secure in use. 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. Using the first level Key1 as a Key, the second level Key2 can be decrypted from Key2Encrypted 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. 8, the step S602 may include steps S800 to S802. Wherein: step S800, pre-storing the 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 a second ciphertext and second integrity protection additional information; and step S802, using the recovered second-level key as a key, and decrypting the third-level 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.

The implementation of fig. 8 ensures the integrity of the third level key.

Returning to fig. 2, step S206 derives a blockchain private key from the secret value.

As an example, as shown in fig. 9, the step S206 may include a step S900 of deriving the blockchain private key from the secret value using a hierarchical deterministic wallet specification.

As an example, the component may be 128 bits (16 bytes) of data and presented in HEX or Base64 encoded fashion. The private key used on the blockchain is typically a large integer of 256 bits. It is also possible that some blockchains have different specifications. The blockchain private key may be derived by calculation from some seed (e.g., a secret value, a level of key subsequent to the first level key) in some way, using a so-called hierarchical deterministic wallet specification, or in other ways.

Returning to fig. 2, step S208 accepts the call of the browser plug-in again, and receives a second signature request.

As an example, as shown in fig. 10, the step S208 may include a step S1002 of receiving, through the service interface, a second signature request from the browser plug-in, the second signature request including second information to be signed.

In an exemplary embodiment of the present application, the second signature request may be that the modified browser plug-in re-initiates the signature flow to the platform (signer). The message to be signed (to-be-signed information) it obtains from the platform (signer) may be different from the first time, mainly the one-time random number or time stamp contained therein for preventing replay attacks may be changed. If (by way of example only) the first signature request is a request to sign the following text:

this is the OpenSky platform, who signs the message text to authenticate himself as a. Secure random number: b (B)

The second signed request may be a request to sign the text as follows:

this is the OpenSky platform, who signs the message text to authenticate himself as a. Secure random number: c (C)

Referring back to fig. 2, step S210 is performed to sign the second signature request by using the blockchain private key when the second signature request matches the preset information.

As an example, as shown in fig. 11, the step S210 may include steps S1102 to S1106. Wherein: step S1102, comparing whether the second information to be signed matches the preset information; step S1104, if the second information to be signed matches the preset information and the preset information is valid, signing the second signature information by using the blockchain private key, and if the number of signatures reaches a preset limit after the signing is completed, the preset information is invalid; in step S1106, if the second to-be-signed information does not match the preset information, or the preset information has failed, the second signature request is rejected. Matching, as used herein, refers to the complete match of information other than a nonce or a timestamp. In the above example, the second signature request is required to have the following form:

this is the OpenSky platform, who signs the message text to authenticate himself as a. Secure random number:

this portion of the content can be perfectly matched with the content of the first signature request other than the nonce or the timestamp.

As an example, the preset information and the second information to be signed each include a one-time security random number or a time stamp, and the one-time security random number or the time stamp is not in the comparison range.

In an exemplary embodiment of the present application, the number of signatures depends on the traffic demand. Typically, the default number is 1, i.e. the pre-set information after signing is stale. 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. 12 schematically illustrates a flowchart of initialization in the blockchain collective signature method according to the first embodiment of the present application.

As shown in fig. 12, the blockchain collective signature method according to the first embodiment of the present application may further include step S1202, initializing the signer.

As an example, initializing the signer includes: and setting the signing machine to a default state.

Fig. 13 schematically shows a flowchart of mail or flow records in the blockchain collective signature method according to the embodiment one of the present application.

As shown in fig. 13, the blockchain collective signature method according to the first embodiment of the present application may further include: step S1302, recording the preset information and the confirmation information of the preset information as audit basis; and/or step S1304, reporting the preset information and the confirmation information of the preset information by sending a mail or calling a workflow, as an audit basis.

Fig. 14 schematically illustrates another flowchart of a blockchain collective signature method in accordance with an embodiment of the present application. As an example, the blockchain collective signature method according to the embodiment of the present application is applied to a signer and a browser plug-in, and includes steps S1400 to S1410.

In step S1400, the browser plug-in invokes the signer and sends a first signing request to the signer, where the first signing request includes preset information.

In step S1402, the signer provides the preset information to the plurality of component holders for confirmation.

In step S1404, the signer obtains a plurality of components of the plurality of component holders, and recovers a secret value based on the plurality of components.

In step S1406, the signer derives a blockchain private key from the secret value.

In step S1408, the browser plug-in invokes the signer again, sending a second signing request to the signer.

In step S1410, when the second signature request matches the preset information, the signer signs the second signature request using the blockchain private key.

FIG. 15 schematically illustrates one example diagram of a blockchain collective signature method of the present application.

As an example, the blockchain collective signature method of the embodiment of the present application is applied to a signer and a browser plug-in, and includes steps S1500 to S1514.

Step S1500, initializing a signing machine and a browser plug-in.

As an example, the signer, browser plug-in initialization includes: and setting the signing machine and the browser plug-in as default states.

In step S1502, the browser plug-in sends a first signing request to the signer (first invoking the service interface of the signer) through the service interface of the signer, where the first signing request includes preset information.

Step S1504, the signer receives the first signature request through the service interface and provides the preset information in the first signature request to the component holder for confirmation

In step S1506, the signer receives the explicit confirmation information of the component holder for the preset information and receives the component input by the component holder.

In step S1508, the signer recovers the secret value from the component and derives the blockchain private key from the secret value.

In step S1510, the browser plug-in sends a second signing request to the signer (second invocation of the signer 'S service interface) through the signer' S service interface.

In step S1512, the signer compares whether the information contained in the second signature request is consistent with the preset information, if so, the signature is completed by using the blockchain private key, and if not, the signature is refused.

In step S1504, the signer records necessary information or transmits necessary mail as audit basis, and notifies the related personnel.

For example, if a component holder is a member of a business segment team, the relevant personnel may include: finance, compliance, wind control, internal control, and the like. The necessary information may be determined according to the management needs, and may include, for example, the address of the money transfer operation, the amount; address, method, parameters of contract call; text signature, and so forth. These examples are merely examples and do not limit the scope of the present application. Generally, the personnel involved, the information necessary, the mail involved, and the like are dependent upon the administrative specifications and measures of the institution in which the application is deployed, as well as the flow and compliance requirements.

FIG. 16 schematically illustrates another example diagram of a blockchain collective signature method of the present application.

As an example, the blockchain collective signature method of the embodiment of the present application is applied to a signer and a browser plug-in, and includes the following steps S1 to S7. Wherein:

s1: initializing a signing machine and a browser plug-in;

s2: the browser plug-in calls a signature machine to provide required preset information;

s3: the multi-bit component holder confirms preset information one by one; if the preset information is legal, the held component is input;

S4: after collecting the components of the sufficient share, the signer recovers the secret value, and then derives the private key;

s5: the browser plug-in calls the signing machine again to request signing;

s6: the signing machine compares whether the signing request is consistent with the preset information or not, if so, the signing is completed, and if not, the signing is refused;

s7: the signer records necessary information or sends necessary mails as audit basis and notifies related personnel.

These steps are merely exemplary.

And the S3 step, the S4 step and the S7 step are all safety designs of the signing machine.

Wherein in step S2 and step S6, the preset and signature request may contain time stamp information or other nonce information (nonce) at the time, and is specified for a signer (platform) or browser plug-in to prevent replay attack (an attack means for achieving illegal purposes by reusing past or other legal information). This time stamp or one-time random information is not within the alignment range.

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

(1) Breaking through the conventional technology, creatively proposes that a signing machine and a browser plug-in can be opened, so that the security of a private key commonly managed by a plurality of persons provided by the signing machine can be obtained, the browser plug-in can be used for completing the operation required by a specific platform, and meanwhile, the required development workload is minimized;

(2) The design is invoked twice. The core is that the security design requirement of the signing machine can only sign white list information or preset information which is commonly confirmed by a plurality of people, so that malicious information is prevented from being submitted to signature (for example, other plug-ins in a browser interfere with normal operation, and tampering with the information to be signed can lead to the malicious information being signed if no confirmation link exists). The design of two calls ensures that signature information can be signed after being jointly confirmed by multiple people, and can effectively prevent attacks from various malicious software and malicious behaviors.

Example two

Fig. 17 schematically shows a block diagram of a signer according to a second embodiment of the present application, which may be divided into one or more program modules, which are stored in a storage medium and executed by one or more processors to complete 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. 17, the signer may include a first invocation module 1701, a validation module 1703, a recovery module 1705, an export module 1707, a second invocation module 1709, and a signature module 1711.

The first invoking module 1701 is configured to accept invocation of a browser plug-in, and receive a first signature request, where the first signature request includes preset information;

as an example, the signer includes a service interface. The first invocation module 1701 is further configured to: and receiving the first signature request from the browser plug-in through the service interface, wherein the first signature request comprises the preset information, and the preset information is first information to be signed.

The confirmation module 1703 is configured to provide the preset information to a plurality of component holders for confirmation.

As an example, the validation module 1703 is also configured to: displaying the preset information to the plurality of component holders for confirmation; and receiving confirmation information of the plurality of component holders for the preset information.

The recovery module 1705 is configured to obtain multiple components of the multiple component holders, and recover a secret value according to the multiple components.

As an example, the recovery module 1705 is also configured to: if the preset information is legal, receiving a plurality of components input by the plurality of component holders; recovering a first level key from the plurality of components; and recovering a subsequent key according to the first-level key.

As an example, the recovery module 1705 is also 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, wherein the third-level key is the secret value.

As an example, the recovery module 1705 is also 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 recovery module 1705 is also configured to: pre-storing the 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 a second ciphertext and second integrity protection additional information; and using the recovered second-level key as a key, and decrypting the third-level 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.

The export module 1707 is configured to export a blockchain private key based on the secret value.

As an example, the export module 1707 is also configured to: the blockchain private key is derived from the secret value using a hierarchical deterministic wallet specification.

The second invoking module 1709 is configured to accept the invocation of the browser plug-in again, and receive a second signature request.

As an example, the second invocation module 1709 is further configured to: a second signature request is received from the browser plug-in through the service interface, the second signature request including second information to be signed.

The signature module 1711 is configured to sign the second signature request with the blockchain private key when the second signature request matches the preset information.

As an example, the signature module 1711 is further configured to: comparing whether the second information to be signed accords with the preset information or not; if the second information to be signed is consistent with the preset information and the preset information is valid, signing the second information to be signed by using the blockchain private key, and if the number of signing times reaches a preset limit after signing is completed, invalidating the preset information; and if the second information to be signed does not accord with the preset information or the preset information fails, rejecting the second signature request.

As an example, the preset information and the second information to be signed each include a one-time security random number or a time stamp, and the one-time security random number or the time stamp is not in the comparison range.

As shown in fig. 17, the signer may also include an initialization module 1713.

As an example, an initialization module 1713 is used to initialize the signer.

As shown in fig. 17, the signer may also include a logging module 1715.

As an example, the recording module 1715 is 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. 18 schematically illustrates a hardware architecture diagram of a computer device 1000 adapted to implement a blockchain collective signature method according to the third embodiment 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. 18, 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 collective signature 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. 8 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 collective signature method stored in the memory 1010 may also be divided into one or more program modules and executed by one or more processors (the 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 collective signature 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 collective signature method in the embodiment, and the like. 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 (17)

1. A blockchain collective signature method, characterized by being applied to a signer, the method comprising:

Receiving a call of a browser plug-in, and receiving a first signature request, wherein the first signature request comprises preset information;

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

acquiring multiple components of the multiple component holders, and recovering a secret value according to the multiple components;

deriving a blockchain private key from the secret value;

receiving the call of the browser plug-in again, and receiving a second signature request;

and when the second signature request accords with the preset information, signing the second signature request by utilizing the blockchain private key.

2. The blockchain collective signature method of claim 1, wherein the signer includes a service interface;

the receiving the call of the browser plug-in, receiving a first signature request, including:

and receiving the first signature request from the browser plug-in through the service interface, wherein the first signature request comprises the preset information, and the preset information is first information to be signed.

3. The blockchain collective signature method of claim 2, wherein the providing the preset information to a plurality of component holders for validation comprises:

Displaying the preset information to the plurality of component holders for confirmation;

and receiving confirmation information of the plurality of component holders for the preset information.

4. The blockchain collective signature method of claim 3, wherein the obtaining the multiple components of the multiple component holders, recovering the secret value from the multiple components, comprises:

if the preset information is legal, receiving a plurality of components input by the plurality of component holders;

recovering a first level key from the plurality of components;

and recovering a subsequent key according to the first-level key.

5. The blockchain collective signature method of claim 4, 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, wherein the third-level key is the secret value.

6. The blockchain collective signature method of claim 5, 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 the first encryption algorithm in combination with the first packet mode and the first additional information.

7. The blockchain collective signature method of claim 6, wherein recovering a third level key from the second level key comprises:

pre-storing the 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 a second ciphertext and second integrity protection additional information;

and using the recovered second-level key as a key, and decrypting the third-level 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.

8. The blockchain collective signature method of any of claims 5-7, wherein the deriving a blockchain private key from the secret value comprises:

the blockchain private key is derived from the secret value using a hierarchical deterministic wallet specification.

9. The blockchain collective signature method of claim 2, wherein the re-accepting the browser plug-in call, receiving a second signature request, comprises:

a second signature request is received from the browser plug-in through the service interface, the second signature request including second information to be signed.

10. The blockchain collective signature method of claim 9, wherein signing the second signature request with the blockchain private key when the second signature request matches the preset information comprises:

comparing whether the second information to be signed accords with the preset information or not;

if the second information to be signed is consistent with the preset information and the preset information is valid, signing the second information to be signed by using the blockchain private key, and if the signing times reach a preset limit after the signing is completed, invalidating the preset information;

and rejecting the second signature request if the second information to be signed does not accord with the preset information or the preset information is invalid.

11. The blockchain collective signature method of claim 10, wherein the preset information and the second to-be-signed information each include a one-time secure random number or a timestamp that is not within a comparison range.

12. The blockchain collective signature method as defined in any of claims 1-11, further comprising: initializing the signer.

13. The blockchain collective signature method as defined in any of claims 1-11, 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.

14. A blockchain collective signature method, characterized by being applied to a signer and a browser plug-in, the method comprising:

the browser plug-in calls the signing machine and sends a first signing request to the signing machine, wherein the first signing request comprises preset information;

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

the signer acquires multiple components of the multiple component holders, and recovers a secret value according to the multiple components;

the signer derives a blockchain private key according to the secret value;

the browser plug-in calls the signing machine again and sends a second signing request to the signing machine;

And when the second signature request accords with the preset information, the signing machine signs the second signature request by utilizing the blockchain private key.

15. A signing machine, comprising:

the first calling module is used for receiving the call of the browser plug-in and receiving a first signature request, and the first signature request comprises preset information;

the confirmation module is used for providing the preset information for a plurality of component holders to confirm;

a recovery module, configured to obtain multiple components of the multiple component holders, and recover a secret value according to the multiple components;

the deriving module is used for deriving a blockchain private key according to the secret value;

the second calling module is used for receiving the call of the browser plug-in again and receiving a second signature request;

and the signature module is used for signing the second signature request by utilizing the blockchain private key when the second signature request accords with the preset information.

16. 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 collective signature method of any of claims 1-14.

17. A computer readable storage medium having stored therein a computer program executable by at least one processor to cause the at least one processor to perform the steps of the blockchain collective signature method of any of claims 1-14.

Images