Blockchain signature machine security design method and signature machine

Abstract

The application provides a blockchain signature machine security design method, comprising: in response to a signature request, obtaining multiple components of a first-level key from multiple component holders; restoring the first-level key according to the multiple components; and restoring a subsequent key according to the restored first-level key, wherein the subsequent key is used to derive a blockchain private key. The technical solution provided by the application adopts a multi-level key system and a step-by-step encryption mode, and the component holders can only master the components of the first-level key. After the first-level key is restored, it can only be used to restore the subsequent key, thereby avoiding the problem that the component holders can directly restore the blockchain private key without the signature machine, and solving the security design problem of the signature machine.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a secure design method for a blockchain signature machine, a signature machine, a computer device, and a computer-readable storage medium. Background Technology

[0002] Asymmetric encryption algorithms and public-private key pairs are widely used on blockchains. The private key can be used to prove ownership of an on-chain address, and consequently, ownership of assets associated with that address. Therefore, secure management of private keys is crucial for blockchain applications. On some public blockchains, the private key is the sole credential of ownership. Unlike a bank account, where a user can reset their password at a bank with identification, on blockchains, especially certain public blockchains, the loss of a private key renders the associated assets irrecoverable.

[0003] Signature machines manage the private keys of important assets. In order to securely manage private keys (blockchain private keys), the security design of signature machines is very important. Summary of the Invention

[0004] The purpose of this application is to provide a secure design method for a blockchain signature machine, a signature machine, a computer device, and a computer-readable storage medium to solve the security design problem of a signature machine.

[0005] One aspect of this application provides a secure design method for a blockchain signature machine, characterized by comprising: in response to a signature request, obtaining multiple components of a first-level key from multiple component holders; recovering the first-level key based on the multiple components; and recovering a subsequent key based on the first-level key, wherein the subsequent key is used to derive a blockchain private key.

[0006] Optionally, the first-level key is divided into n components using a secret segmentation algorithm. The first-level key can be recovered from any t components, and the first-level key cannot be recovered from any fewer than t components. The step of recovering the first-level key from the multiple components includes: recovering the first-level key from more than or equal to t components using a secret segmentation algorithm; and comparing the first-level key with pre-stored integrity information to ensure that the first-level key is correctly recovered.

[0007] Optionally, comparing the first-level key with the pre-stored integrity information includes: pre-stored first verification information as integrity information, wherein the first verification information is obtained by using a verification algorithm and preset parameters to obtain a correct first-level key; using the recovered first-level key and the verification algorithm and the preset parameters to obtain second verification information; comparing whether the first verification information and the second verification information are completely identical; if they are completely identical, the first-level key is correctly recovered; if they are not completely identical, the first-level key is not correctly recovered.

[0008] Optionally, recovering subsequent keys based on the first-level key includes: recovering a second-level key based on the first-level key; and recovering a third-level key based on the second-level key.

[0009] Optionally, the step of recovering the second-level key based on the first-level key includes: pre-storing first pre-stored information, wherein the first pre-stored information is obtained by encrypting the second-level key using a first encryption algorithm combined with a first block pattern and first additional information, and the first pre-stored information includes a first ciphertext and first integrity protection additional information; using the recovered first-level key as the key, the second-level key is decrypted from the first pre-stored information using the first encryption algorithm combined with the first block pattern and the first additional information.

[0010] Optionally, the step of recovering the third-level key based on 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 using a second encryption algorithm combined with a second block pattern and second additional information, and the second pre-stored information includes a second ciphertext and second integrity protection additional information; using the recovered second-level key as the key, the third key is decrypted from the second pre-stored information using the second encryption algorithm combined with the second block pattern and the second additional information.

[0011] Optionally, the blockchain signature machine security design method further includes: receiving a first signature request, the first signature request including preset information, the preset information being information to be signed; providing the preset information to multiple component holders for confirmation; receiving a second signature request; if the second signature request matches the preset information and the preset information is valid, signing the second signature request; after signing, if the number of signatures has reached a preset limit, the preset information becomes invalid; if the second signature request does not match the preset information, or the preset information has become invalid, rejecting the second signature request.

[0012] Optionally, the blockchain signature machine security design method further includes: setting a whitelist of information to be signed, wherein the filtering condition of the whitelist is one or more characteristics of the information to be signed; receiving a signature request; if the signature request conforms to the whitelist, then signing the signature request; if the signature request does not conform to the whitelist, then rejecting the signature request.

[0013] Optionally, the blockchain signature machine security design method further includes: recording the preset information and confirmation information of the preset information as audit basis; and / or reporting the preset information and confirmation information of the preset information by sending emails or calling workflows as audit basis.

[0014] One aspect of this application provides a signature machine, comprising: an acquisition module, configured to acquire multiple components of a first-level key from multiple component holders in response to a signature request; and a recovery module, configured to recover the first-level key based on the multiple components and recover a subsequent key based on the first-level key, wherein the subsequent key is used to derive a blockchain private key.

[0015] One aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the blockchain signature machine security design method described above.

[0016] One aspect of this application provides a computer-readable storage medium, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the blockchain signature machine security design method described above.

[0017] The blockchain signature machine security design method, signature machine, computer equipment, and computer-readable storage medium provided in this application adopt a multi-level key system and a step-by-step encryption method. The component holder can only control the component of the first-level key. After the first-level key is recovered, it can only be used to recover subsequent keys, thereby avoiding the problem that the component holder can recover the blockchain private key directly without the signature machine, and solving the security design problem of the signature machine. Attached Figure Description

[0018] Figure 1 The diagram illustrates a multi-level key system in the blockchain signature machine security design method according to Embodiment 1 of this application;

[0019] Figure 2 The flowchart illustrating the multi-level key system in the blockchain signature machine security design method according to Embodiment 1 of this application is shown in the schematic diagram.

[0020] Figure 3 for Figure 2 Sub-step diagram of step S202;

[0021] Figure 4 for Figure 3 Sub-step diagram of step S302;

[0022] Figure 5 for Figure 2 Sub-step diagram of step S204;

[0023] Figure 6 for Figure 5 A diagram of the sub-steps in step S500;

[0024] Figure 7 for Figure 5 Sub-step diagram of step S502;

[0025] Figure 8 The flowchart illustrating the preset information confirmation and one-time signature design in the blockchain signature machine security design method according to Embodiment 1 of this application is shown in the figure.

[0026] Figure 9 The flowchart illustrating the whitelist system in the blockchain signature machine security design method according to Embodiment 1 of this application is shown in the illustration.

[0027] Figure 10 The flowchart illustrating the secure design method for a blockchain signature machine according to Embodiment 1 of this application is shown in the form of a message or process record.

[0028] Figure 11 This diagram illustrates a specific example of a multi-level key system in the blockchain signature machine security design method of this application.

[0029] Figure 12 This illustration shows a specific example of the preset information confirmation and whitelist filtering in the blockchain signature machine security design method of this application;

[0030] Figure 13 A block diagram of a signature machine according to Embodiment 2 of this application is schematically shown; and

[0031] Figure 14 The illustration shows a schematic diagram of the hardware architecture of a computer device suitable for implementing a secure design method for a blockchain signature machine according to Embodiment 3 of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0033] It should be noted that the descriptions involving "first," "second," etc., in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0034] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0035] The following is an explanation of the terms used in this application:

[0036] Shamir's Secret Sharing (SSS) is a cryptographic algorithm that typically uses n and t as parameters (t not greater than n). Using SSS, a secret value s can be securely divided into n parts, and the secret value can be recovered by collecting any t parts; simultaneously, any number of parts less than t will not cause partial or complete disclosure of the secret value s. One method of implementing SSS is to divide the secret value byte-by-byte on a GF256; for example, if the secret value is 128 bits, it is divided into 16 bytes, and each byte is further divided. During recovery, each byte needs to be recovered, and the recovered data is then concatenated to form the secret value. There are also implementations that treat the entire secret value as a large integer and divide it into smaller parts; however, such implementations may have certain security vulnerabilities if not carefully managed.

[0037] GF256: A Galois field with 256 elements, ranging from 0 to 255. This range corresponds to the unsigned integer value of a single byte in a computer, making it suitable for processing single-byte data and thus frequently used in cryptography. Galois fields have their own unique addition and multiplication rules. In GF256, addition is performed using bitwise XOR, which can be considered binary addition without carry. Multiplication typically involves interpreting a byte as a univariate polynomial of degree 7, where each bit represents a coefficient. Multiplication in GF256 involves multiplying two polynomials (using bitwise XOR when combining like terms), then dividing the resulting polynomial by a predefined modulo polynomial, and taking the remainder as the multiplication result.

[0038] Seed: On the blockchain, sometimes it is not necessary to keep a corresponding private key for each crypto asset or each public chain. Instead, a "seed" is used in combination with certain rules to derive the corresponding private key for each crypto asset or each public chain, reducing the number of secrets that need to be kept. At the same time, it can technically ensure that if one private key is leaked, the other private keys are still safe.

[0039] A signature machine is a technological facility that implements the Shamir Secret Segmentation Algorithm (SSS). It can securely receive the components segmented by the SSS algorithm, recover the secret value, and then derive the blockchain's private key to complete the required signature. It typically requires both hardened systems and network security measures, and can also employ hardware-level confidential computing capabilities as needed to maximize the security of the secret value.

[0040] Whitelist: A security mechanism that allows access to or operation on resources on the list to be exempt from certain security checks, thereby increasing convenience while maintaining security.

[0041] Components and Component Holders: After the SSS algorithm divides the secret value into multiple components, it assigns them to designated personnel for management, along with appropriate management systems. These personnel can be called component holders.

[0042] The following section first provides an overview of the blockchain signature machine security design scheme of this application, based on the relevant technologies presented. The technical effects that can be achieved will be further illustrated with several embodiments below, which are used to implement the security design scheme of the blockchain signature machine.

[0043] Blockchain private keys (referred to as "private keys") are extremely important; once lost, they may be irrecoverable.

[0044] To securely manage private keys, numerous technological facilities have been developed. This list only includes a portion of these technologies, primarily those based on smart contracts and those based on the Shamir secret partitioning algorithm.

[0045] The smart contract-based technology involves registering relevant parameters and escrow assets on the blockchain; when assets need to be used, signature information that meets the share requirements is submitted to the smart contract, and once the requirements are met, the smart contract can perform asset operations as required.

[0046] The technology based on Shamir's secret splitting algorithm generally involves splitting the relevant secret value and distributing it to multiple people for safekeeping. When the asset needs to be used, the secret value is restored, the private key is exported, and a signature is completed.

[0047] The aforementioned smart contract-based technology requires sending signature information directly to the blockchain to complete related operations, which limits its applicability. For example, sometimes off-chain signatures are needed to authenticate identity with a platform. Its convenience is also insufficient; for instance, a single signature from multiple parties can only authorize one contract call on the blockchain and cannot be used repeatedly.

[0048] The aforementioned SSS algorithm-based technology can be used in off-chain signature scenarios, but it is relatively cumbersome to operate and makes it difficult to balance security and convenience. If the secret value needs to be restored for each signature, the convenience is greatly reduced; if the secret value is restored first and the relevant device then provides services, it is possible that if the service interface is controlled by an attacker, the service could be used to sign arbitrary information, resulting in asset loss. In addition, if the secret value directly corresponds to the asset's seed or private key, multiple token holders could collude to restore the asset's private key independently of the signing machine, and then manipulate the asset.

[0049] In view of these shortcomings, the purpose of the present invention and the technical effects that can be achieved are explained.

[0050] To overcome the aforementioned limitations, this application achieves a balance between security and convenience by employing four security mechanisms based on the SSS algorithm:

[0051] Firstly, it employs a multi-level key system for progressive encryption. This application uses multiple keys, with each component holder possessing only a portion of the first-level key. Once recovered by the component holder, the first-level key can only be used to recover the next-level key, thus preventing the component holder from directly recovering the asset's private key without a signing machine. All keys carry integrity verification information, ensuring that the encrypted information cannot be replaced or tampered with.

[0052] Secondly, the application includes a pre-defined information confirmation and one-time signature design. Before restoring the secret value, the information to be signed must be fixed, and each holder of a component participating in the secret value restoration must explicitly confirm the fixed information. The fixed information and the confirmation are also recorded as audit evidence. Before signing, the signing machine compares the signed information with the pre-defined information; if they do not match, the signature is rejected. After signing, the pre-defined information automatically becomes invalid. This design prevents attackers from signing arbitrary information or multiple times signing pre-defined information (e.g., transferring funds to a specific address multiple times) after the secret value is restored and after controlling the service interface.

[0053] Third, the whitelist system. This application sets up a whitelist of content to be signed, allowing content on the whitelist (specific smart contract interface calls, specific types of data signatures, content signatures that meet specified filtering conditions, etc.) to be called repeatedly, and the limit on the number of calls can also be specified in the whitelist, achieving a balance between security and convenience.

[0054] Fourth, email or process logs. This application requires the signing machine to send an email to a designated email address or invoke the relevant workflow of the office automation system after each signing to summarize and report relevant information about the signing, including but not limited to the signature content, transfer amount, target address or smart contract address and method, parameters, etc. This ensures that audit evidence is left for each signing.

[0055] This method has been proven effective through practical testing. Compared with the prior art, this solution has the following advantages:

[0056] 1. It can mitigate personnel risks to a certain extent. The multi-level key system ensures that the asset holder cannot directly recover the asset's private key; at the same time, all asset operations are recorded by email or process logs, and any cheating behavior will be detected in a timely manner.

[0057] 2. It balances security and convenience. It allows for multiple signatures of specific content (such as contract calls) without requiring repeated secret value recovery, while ensuring that all signatures are confirmed in advance.

[0058] It should be noted that the blockchain signature machine security design method and signature machine in this application can select multi-level keys. This security mechanism can also simultaneously choose a multi-level key system and one or more of the remaining three security mechanisms. indivual.

[0059] Several embodiments will be provided below, which can be used to implement the above description. Blockchain Security design methods for signature machines and signature machines For ease of understanding, the following description will use a signature machine as the execution subject.

[0060] Example 1

[0061] Figure 1The diagram illustrates a multi-level key system in the blockchain signature machine security design method according to Embodiment 1 of this application.

[0062] As an example, multiple component holders meeting preset parameters can jointly recover the first-level key within the signing machine. This first-level key is not an asset seed or private key (blockchain private key), but is used to encrypt secondary keys (e.g., the second-level key). Subsequent levels of keys (e.g., the third-level key) can be used as asset seeds. The integrity of the first-level key is protected by integrity information to prevent errors during the recovery process using the SSS algorithm, which could lead to errors in subsequent encryption and decryption calculations. The integrity of subsequent keys (e.g., the second-level and third-level keys) is guaranteed by the block pattern applied by the symmetric encryption algorithm.

[0063] It should be noted that the key used to derive the blockchain private key can be any level of key following the first-level key. Keys, such as: second-level keys, third-level keys, fourth-level keys, fifth-level keys, etc. Figure 1 Using the third-level key as an example For example, but this application is not limited to this.

[0064] The multi-level key system in the signing machine of this application Figure 1 For illustrative purposes only, please refer to the following for specific implementation details. Figures 2-7 .

[0065] Figure 2 The flowchart illustrating the multi-level key system in the blockchain signature machine security design method according to Embodiment 1 of this application is shown.

[0066] like Figure 2 As shown, the blockchain signature machine security design method of this application is applied to a signature machine and may include steps S200 to S204, wherein:

[0067] Step S200: In response to the signature request, obtain multiple components of the first-level key from multiple component holders.

[0068] As an example, the signing machine can be a software service provided via a network interface. It is generally recommended to use dedicated server hardware, deployed within the user organization's secure intranet environment, with strict access control and further protection via firewalls. Signing requests are typically transmitted over the network, usually via HTTPS, but other transport protocols are also acceptable; this is a peripheral technical facility and does not limit the scope of this application.

[0069] As an example, this application does not limit the identity of the component holder. The component holder can be arbitrarily designated by the organization using the signature machine, generally a member of a business team. For higher security, multiple teams can be assigned to jointly hold the component, such as a business team plus a risk control team, an internal control team, and a finance team. This avoids a single team controlling the first-level key. External personnel can also be invited to participate. Everything is determined by the user organization.

[0070] It should be noted that the method of holding the component does not limit the scope of this invention. This invention does not limit the method of holding the component, and it is recommended to use some kind of secure password management software (including desktop software or mobile app) or hardware.

[0071] In the design of this application embodiment, after multiple component holders collude or after the component held by a component holder is leaked, they can only recover the first-level key and cannot recover the signing private key itself without the signing machine. Therefore, this application embodiment does not limit the component holders and the method of component holding. Of course, in actual use, it needs to be confirmed in combination with specific circumstances, such as the identification of component holders, system access restrictions, and the use of password management software or hardware.

[0072] As an example, the first-level key Key1 is divided into n parts (e.g., Key1part1, Key1part2, Key1part3, Key1part4, Key1part5) using a secret splitting algorithm. Any t parts (e.g., Key1part1, Key1part2, Key1part3) can be used to recover the first-level key Key1, while any number of parts less than t cannot be used to recover the first-level key.

[0073] In an exemplary embodiment of this application, the secret partitioning algorithm may be the Shamir Secret Partitioning Algorithm (SSS algorithm). This embodiment is based on the SSS algorithm. The SSS algorithm used in this embodiment is implemented using GF256. Please refer to the terminology explanation section for SSS algorithm and GF256.

[0074] For example, the first-level key Key1 can be a 128-bit random number generated using a secure random number generator, which is then broken down into 16 bytes: byte1, byte2, ..., byte16.

[0075] The SSS algorithm allows for arbitrary partitioning schemes, and the specific implementation depends on the actual management needs. For example, a 5-3 partitioning scheme can be set, which securely partitions Key1 into 5 parts, and Key1 can be recovered using any three of these parts. The partitioned parts can then be further partitioned using the SSS algorithm to construct more complex partitioning schemes. The following example uses only the 5-3 partitioning scheme.

[0076] Using the SSS algorithm and calculating on a specific GF256 field, each byte is securely divided into 5 parts, each still being one byte, resulting in five corresponding bytes, which can be numbered byte_i_j, where i is the original byte number (value 1 to 16), and j is the component number (value 1 to 5) of that byte (byte{i}). Thus, Key1part1 consists of 16 bytes, in the following order: byte_1_1, byte_2_1, byte_3_1, ..., byte_16_1. Key1part2 consists of another 16 bytes, in the following order: byte_1_2, byte_2_2, byte_3_2, ..., byte_16_2, and so on. This yields the five components of Key1: Key1part1, Key1part2, Key1part3, Key1part4, and Key1part5.

[0077] Key1part1, Key1part2, Key1part3, Key1part4, and Key1part5 are assigned to the component holders. The specific method of assignment is not limited in this application embodiment, but generally, the component holder can provide a public key, encrypt the data using that public key, and send it to the component holder, who can then decrypt and store it using their private key.

[0078] Please return Figure 2 Step S202: Recover the first-level key based on the multiple components.

[0079] As an example, such as Figure 3 As shown, step S202 may include steps S300 to S302. Specifically: step S300 involves recovering the first-level key using a secret segmentation algorithm based on at least t components; step S302 involves comparing the first-level key with pre-stored integrity information to ensure that the first-level key is correctly recovered.

[0080] As an example, such as Figure 4As shown, step S302 may include steps S400 to S408. Specifically: Step S400: Pre-store first verification information as integrity information, wherein the first verification information is obtained by using a verification algorithm (e.g., PBKDF algorithm) combined with preset parameters to obtain a correct first-level key; Step S402: Use the recovered first-level key to obtain second verification information using the verification algorithm combined with the preset parameters; Step S404: Compare whether the first verification information and the second verification information are completely identical; Step S406: If they are completely identical, the first-level key has been correctly recovered; Step S408: If they are not completely identical, the first-level key has not been correctly recovered.

[0081] In an exemplary embodiment of this application, PBKDF stands for Password-Based Key Derivation Function, which is a key derivation function based on cryptography. There are two standards, PBKDF1 and PBKDF2, with PBKDF2 being the recommended choice. PBKDF2 is specified in both PKCS#5v2.0 and RFC 2898. RFC8010 recommends PBKDF2 for message authentication purposes, i.e., the integrity verification used in the embodiments of this application.

[0082] It should be noted that PBKDF is just an example. Other algorithms only need to ensure that an incorrect Key1 can be detected with a very high probability and that Key1 cannot be deduced from the verification information. For example, in addition to the PBKDF algorithm, the Argon2 algorithm can also be used, which is the winner of the HPC (Password Hashing Competition).

[0083] Please return Figure 2 Step S204: Recover the subsequent key based on the first-level key, wherein the subsequent key is used to derive the blockchain private key.

[0084] As an example, such as Figure 5 As shown, step S204 may include steps S500 to S502. Specifically: step S500 involves recovering the second-level key Key2 based on the first-level key Key1; step S502 involves recovering the third-level key Key3 based on the second-level key Key2.

[0085] As an example, such as Figure 6As shown, step S500 may include steps S600 to S602. Specifically: Step S600 involves pre-saving first pre-stored information, which is obtained by encrypting the second-level key using a first encryption algorithm (e.g., symmetric encryption algorithm SM4 or AES) combined with a first block cipher (e.g., GCM) and first additional information (aad). The first pre-stored information includes first ciphertext and first integrity protection additional information. Step S602 involves using the recovered first-level key as the key, and decrypting the second-level key from the first pre-stored information using the first encryption algorithm combined with the first block cipher and the first additional information. Figure 6 This approach ensures the integrity of the second-level key.

[0086] In an exemplary embodiment of this application, the first encryption algorithm may be a symmetric encryption algorithm (such as AES or SM4); GCM, or Galois / Counter Mode, can perform integrity verification on encrypted messages.

[0087] In an exemplary embodiment of this application, Key2 itself is a 128-bit, 192-bit, or 256-bit random number generated using a secure random number generator (the length is not limited in this embodiment). It can be encrypted using a symmetric encryption algorithm (such as AES or SM4) combined with a block cipher mode (such as GCM) that provides ciphertext integrity protection, resulting in Key2Encrypted, which includes the encrypted ciphertext and integrity protection additional information (tag). Integrity protection involves calculating additional information (tag) (optionally, additional information (aad) can be introduced during encryption calculation) to verify that Key2Encrypted has not been tampered with during decryption (optionally, by providing the same additional information (aad)).

[0088] This Key2Encrypted is the pre-saved information. Using Key1 as the key, and employing the same symmetric encryption algorithm, block mode, and additional information (aad), Key2 can be decrypted from Key2Encrypted.

[0089] It should be noted that the above is only an example and does not limit the scope of this application. aad is optional, while tag is something that will be available when using GCM.

[0090] As an example, such as Figure 7As shown, step S502 may include steps S700 to S702. Specifically: Step S700 involves pre-saving second pre-stored information, wherein the second pre-stored information is obtained by encrypting the third-level key using a second encryption algorithm combined with a second block mode and second additional information; the second pre-stored information includes second ciphertext and second integrity protection additional information; Step S702 involves using the recovered second-level key as the key, and decrypting the third key from the second pre-stored information using the second encryption algorithm combined with the second block mode and the second additional information. Figure 7 This approach ensures the integrity of the third-level key.

[0091] Figure 8 The flowchart illustrating the preset information confirmation and one-time signature design in the blockchain signature machine security design method according to Embodiment 1 of this application is shown.

[0092] like Figure 8 As shown, the blockchain signature machine security design method of Embodiment 1 of this application may include steps S800 to S808, wherein:

[0093] Step S800: Receive a first signature request, the first signature request including preset information, the preset information being information to be signed.

[0094] Step S802: Provide the preset information to multiple component holders for confirmation.

[0095] Step S804: Receive the second signature request.

[0096] Step S806: If the second signature request matches the preset information and the preset information is valid, the second signature request is signed. After the signing is completed, if the number of signatures has reached the preset limit, the preset information becomes invalid.

[0097] Step S808: If the second signature request does not match the preset information, or the preset information has expired, then the second signature request is rejected.

[0098] For example, regarding the pre-set information confirmation, consider a pre-set message (pre-set information) authorizing the transfer of one million digital RMB to address A, which can only be invoked once by default. Each component holder must explicitly confirm this message (pre-set information) when providing their component. This ensures that after the private key is recovered / exported, it can only be signed and authorized to transfer one million digital RMB to address A, and only once. It prevents two transfers resulting in an actual transfer of two million RMB, transfers to other addresses, and transfers exceeding one million digital RMB at a time. This method ensures fund security.

[0099] Regarding the number of signatures, it depends on business needs. Generally, the default number is 1, meaning the pre-signed information becomes invalid after signing. However, there are special application scenarios that require signing similar information again or multiple times. In such cases, setting a higher limit on the number of signatures can achieve the result of one authorization for multiple signatures, improving convenience.

[0100] Figure 9 The flowchart illustrating the whitelist system in the blockchain signature machine security design method according to Embodiment 1 of this application is shown.

[0101] like Figure 9 As shown, the blockchain signature machine security design method of Embodiment 1 of this application may include steps S900 to S906, wherein:

[0102] Step S900: Set a whitelist of information to be signed, wherein the filtering conditions of the whitelist are one or more features of the information to be signed.

[0103] Step S902: Receive signature request.

[0104] Step S904: If the signature request matches the whitelist, then the signature request is signed.

[0105] Step S906: If the signature request does not conform to the whitelist, then the signature request is rejected.

[0106] As an example, this application embodiment sets a whitelist of content to be signed, so that content on the whitelist (such as specific smart contract interface calls, specific types of data signatures, content signatures that meet specified filtering conditions, etc.) can be called repeatedly, and the limit on the number of calls can also be specified in the whitelist, achieving a balance between security and convenience.

[0107] Examples of specific smart contract interface calls include, for instance, calling one or more methods of a contract located at a specified address. Whitelists can be applied at the address level, allowing all methods of the contract at that address to be called, or they can be further restricted to the method level, allowing only one or a few methods to be called.

[0108] Regarding instances of specific types of data signatures, possible data types include: transfer messages. Whitelists can be applied to specific parameters of data types, such as allowing transfers to certain addresses unconditionally, or allowing transfers below a certain amount on a limited number of occasions, thereby improving convenience.

[0109] An example of signing content that meets specified filtering criteria is that many platforms require users to sign messages that conform to a certain template using their private key. This template often includes the platform's name, which can then be used as a filtering criterion. For instance, assuming a platform is named OpenSky (this is purely hypothetical), the platform could require users to sign a text containing "OpenSky" when authenticating their identity. Therefore, "OpenSky" can be used as a whitelist filter, allowing messages containing "OpenSky" to be signed.

[0110] It should be noted that any characteristic of the message to be signed can be used as a whitelist filtering condition, depending entirely on business needs.

[0111] Figure 10 The illustration shows a flowchart of an email or process record in a blockchain signature machine security design method according to Embodiment 1 of this application.

[0112] like Figure 10 As shown, the blockchain signature machine security design method of Embodiment 1 of this application may include steps S1002 to S1004, wherein:

[0113] Step S1002: Record the preset information and the confirmation information of the preset information as the basis for auditing.

[0114] Step S1004: Report the preset information and confirmation information of the preset information by sending an email or calling a workflow, as an audit basis.

[0115] As an example, this application embodiment requires the signature machine to send an email to a designated email address or invoke the relevant workflow of an office automation system after each signature is completed, summarizing and reporting relevant information about the signature, including but not limited to the signature content, transfer amount, target address or smart contract address and method, parameters, etc., to ensure that audit evidence is left for each signature.

[0116] Figure 11 The diagram illustrates a specific example of a multi-level key system in the blockchain signature machine security design method of this application.

[0117] As an example, when the signing machine receives a signing request through the service interface, it obtains the segmented components key1part1, key1part2, and key1part3 of the first-level key from component holder 1, component holder 2, and component holder 3 (for example only) respectively. Based on these components, it recovers the first-level key key1. To ensure no errors occur during the recovery process (e.g., an incorrect input of a component, or its replacement by an attacker), the recovered key1 needs to be compared with pre-stored integrity information. One comparison method is to use the PBKDF algorithm on the correct key1 key, combined with certain parameters, to calculate a verification information V1, which is pre-stored in the system. The recovered key1 is then used to calculate a verification information V2 using the same algorithm, and the results are compared to see if V1 and V2 are completely identical. If they are completely identical, key1 has been correctly recovered; otherwise, it has not been correctly recovered. The PBKDF algorithm is only an example here; other algorithms are acceptable as long as they can guarantee that an incorrect key1 can be detected with a high probability and that key1 cannot be deduced from the verification information.

[0118] After recovering the first-level key (key1), decrypting pre-saved information using key1 will recover the second-level key (key2). This pre-saved information is obtained by encrypting key2 using key1. The encryption algorithm uses a symmetric encryption algorithm combined with a block cipher mode that verifies ciphertext integrity, such as GCM mode. This verifies the integrity of the ciphertext during decryption, preventing attackers from tampering with or replacing the pre-saved information. Recovering the third-level key (key3) from the second-level key (key2) is similar.

[0119] In an exemplary embodiment of this application, within the blockchain system, the third-level key key3 is a seed. The seed can be further derived into private keys for different blockchains (Bitcoin, Ethereum, or a consortium blockchain, etc.), different networks (mainnet, testnet), and different paths through a hierarchical deterministic wallet (for example, on the Ethereum mainnet, multiple private key derivation paths can be further subdivided to achieve the purpose of managing multiple addresses on the Ethereum mainnet), thereby achieving the purpose of controlling multiple asset addresses using a single secret value (seed).

[0120] Figure 12 The diagram illustrates a specific example of the preset information confirmation and whitelist filtering in the blockchain signature machine security design method of this application.

[0121] It should be noted that, Figure 12 The preset information confirmation and whitelist filtering design of the present invention are illustrated by way of example. The decision order shown is only exemplary and can be changed without affecting the protection points of the embodiments of this application.

[0122] Step 1200: Receive a signature request through the service interface and determine whether the signature request conforms to the preset information.

[0123] Step 1202: If the signature request meets the preset information, then check if it meets the limit on the number of attempts.

[0124] Step 1204: If the number of attempts is within the limit, sign and return.

[0125] Step S1208: If the number of attempts does not meet the limit, reject the signature and return.

[0126] Step 1206: If the signature request does not conform to the preset information, determine whether it passes the whitelist screening.

[0127] Step 1204: If the whitelist screening passes, sign and return.

[0128] Step S1208: If the whitelist screening fails, the signature is rejected and the process is returned.

[0129] Compared with the prior art, the embodiments of this application have the following advantages:

[0130] (1) Multi-level keys and step-by-step encryption methods ensure that the administrator does not directly control the asset seed or private key, nor can he recover the asset seed or private key on his own without the signature machine.

[0131] (2) The security design of confirming before signing and limiting the information to be signed and the number of signatures is to prevent the operator from providing other information to be signed after the secret value is collectively recovered, bypassing the collective confirmation process to sign any information, causing asset loss, or repeatedly signing the same information, causing asset loss.

[0132] (3) The whitelist design balances convenience and security;

[0133] (4) The signature machine integrates internal workflow or email sending capabilities, ensuring that each asset use is accompanied by an auditable record and notifies relevant personnel, maximizing the timely detection of illegal asset operations. For signature requests that do not conform to preset information or are not on the whitelist, they can also be sent to relevant personnel via email or workflow records to serve as an early warning.

[0134] Example 2

[0135] Figure 13A block diagram of a signature machine according to Embodiment 2 of this application is illustrated schematically. This signature machine can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiments of this application. The program modules referred to in the embodiments of this application are a series of computer program instruction segments capable of performing specific functions. The following description will specifically introduce the functions of each program module in this embodiment.

[0136] like Figure 13 As shown, the signature machine may include an acquisition module 1301 and a recovery module 1303.

[0137] The acquisition module 1301 is used to acquire multiple components of the first-level key from multiple component holders in response to a signature request.

[0138] The recovery module 1303 is used to recover the first-level key based on the multiple components, and to recover subsequent keys based on the first-level key, wherein the subsequent keys are used to derive the blockchain private key.

[0139] As an example, the first-level key is divided into n components using a secret segmentation algorithm. The first-level key can be recovered from any t components, but the first-level key cannot be recovered from any fewer than t components. The recovery module 1303 is also used to: recover the first-level key from the first-level key using the secret segmentation algorithm based on more than or equal to t components; and compare the first-level key with pre-stored integrity information.

[0140] As an example, the recovery module 1303 is further configured to: pre-store first verification information as integrity information, wherein the first verification information is obtained by using a verification algorithm (e.g., PBKDF) and preset parameters to obtain a correct first-level key; use the recovered first-level key and the verification algorithm and the preset parameters to obtain second verification information; compare whether the first verification information and the second verification information are completely identical; if they are completely identical, the first-level key is correctly recovered; if they are not completely identical, the first-level key is not correctly recovered.

[0141] As an example, the recovery module 1303 is also used to: recover a second-level key based on the first-level key; and recover a third-level key based on the second-level key.

[0142] As an example, the recovery module 1303 is further configured to: pre-store first pre-stored information, wherein the first pre-stored information is obtained by encrypting the second level key using a first encryption algorithm combined with a first block pattern and first additional information, the first pre-stored information including a first ciphertext and first integrity protection additional information; and decrypt the second level key from the first pre-stored information using the recovered first level key as the key, using the first encryption algorithm combined with the first block pattern and the first additional information.

[0143] As an example, the recovery module 1303 is also used to: pre-store second pre-stored information, wherein the second pre-stored information is obtained by encrypting the third-level key using a second encryption algorithm combined with a second block mode and second additional information, and the second pre-stored information includes a second ciphertext and second integrity protection additional information; using the recovered second-level key as the key, using the second encryption algorithm combined with the second block mode and the second additional information, decrypting the third key from the second pre-stored information.

[0144] like Figure 13 As shown, the signature machine may also include a confirmation module 1305.

[0145] As an example, the confirmation module 1305 is configured to: receive a first signature request, the first signature request including preset information, the preset information being information to be signed; provide the preset information to multiple component holders for confirmation; receive a second signature request; if the second signature request matches the preset information and the preset information is valid, sign the second signature request; after signing, if the number of signatures has reached a preset limit, the preset information becomes invalid; if the second signature request does not match the preset information, or the preset information has become invalid, reject the second signature request.

[0146] like Figure 13 As shown, the signature machine may also include a filtering module 1307.

[0147] As an example, the filtering module 1307 is used to: set a whitelist of information to be signed, wherein the filtering conditions of the whitelist are one or more features of the information to be signed; receive a signing request; if the signing request conforms to the whitelist, then sign the signing request; if the signing request does not conform to the whitelist, then reject the signing request.

[0148] like Figure 13 As shown, the signature machine may also include a recording module 1309.

[0149] As an example, the recording module 1309 is used to: record the preset information and the confirmation information of the preset information as an audit basis; and / or report the preset information and the confirmation information of the preset information by sending emails or calling workflows as an audit basis.

[0150] Example 3

[0151] Figure 14 This illustration schematically shows a hardware architecture diagram of a computer device 1000 suitable for implementing a secure design method for a blockchain signature machine according to Embodiment 3 of this application. In an exemplary embodiment of this application, the computer device 1000 can be a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. For example, it can be a smartphone, tablet computer, laptop computer, desktop computer, rack server, blade server, tower server, or cabinet server (including independent servers or server clusters composed of multiple servers), gateway, etc. Figure 14 As shown, the computer device 1000 includes, but is not limited to, at least: a memory 1010, a processor 1020, and a network interface 1030 that can communicate and be linked to each other via a system bus. Wherein:

[0152] The memory 1010 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), 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 the 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, smart media card (SMC), secure digital (SD) card, flash card, etc. Of course, the memory 1010 may also include both the internal storage module and the external storage device of the computer device 1000. In this embodiment, the memory 1010 is typically used to store the operating system and various application software installed on the computer device 1000, such as the program code for the blockchain signature machine security design method. In addition, the memory 1010 can also be used to temporarily store various types of data that have been output or will be output.

[0153] In some embodiments, processor 1020 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. Processor 1020 is typically used to control the overall operation of computer device 1000, such as performing control and processing related to data interaction or communication with computer device 1000. In this embodiment, processor 1020 is used to run program code stored in memory 1010 or process data.

[0154] Network interface 1030 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 1000 and other computer devices. For example, network interface 1030 is used to connect computer device 1000 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 1000 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0155] It should be pointed out that, Figure 14 Only computer devices with components 1010-1030 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0156] In this embodiment, the blockchain signature machine security design method stored in memory 1010 can be further divided into one or more program modules and executed by one or more processors (processor 1020 in this embodiment) to complete the embodiment of this application.

[0157] Example 4

[0158] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the blockchain signature machine security design method in the embodiments.

[0159] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), 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 computer-readable storage medium can be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Of course, the computer-readable storage medium can also include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the blockchain signature machine security design method in this embodiment. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0160] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0161] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for a blockchain signing machine security design, characterized in that, include: In response to a signature request, obtain multiple components of the first-level key from multiple component holders; The first-level key is recovered based on the multiple components; The subsequent key is recovered based on the first-level key, wherein the subsequent key is used to derive the blockchain private key; The first-level key is divided into n components using a secret splitting algorithm. Any t components can be used to recover the first-level key, while any number of components less than t cannot be used to recover the first-level key. The step of recovering the first-level key based on the multiple components includes: The first-level key is recovered from t or more components using a secret segmentation algorithm. The first-level key is compared with the pre-stored integrity information to ensure that the first-level key is correctly recovered. The method further includes: Receive a first signature request, the first signature request including preset information, the preset information being information to be signed; The preset information is provided to multiple component holders for confirmation; Receive second signature request; If the second signature request matches the preset information and the preset information is valid, the second signature request is signed. After the signing is completed, if the number of signatures has reached the preset limit, the preset information becomes invalid. If the second signature request does not match the preset information, or if the preset information has expired, the second signature request is rejected.

2. The method of claim 1, wherein, The step of comparing the first-level key with the pre-stored integrity information includes: The first verification information is pre-stored as integrity information, wherein the first verification information is obtained by using a verification algorithm and preset parameters to obtain the correct first-level key; The recovered first-level key is used in conjunction with a verification algorithm and the preset parameters to obtain second verification information. Compare whether the first verification information and the second verification information are completely identical; If they are completely identical, then the first-level key has been correctly recovered; If they are not completely identical, then the first-level key has not been correctly recovered.

3. The blockchain signature machine security design method according to claim 1, characterized in that, The step of recovering subsequent keys based on the first-level key includes: Recover the second-level key based on the first-level key; The third-level key is recovered based on the second-level key.

4. The blockchain signature machine security design method according to claim 3, characterized in that, The step of recovering the second-level key based on the first-level key includes: First pre-stored information is stored in advance, wherein the first pre-stored information is obtained by encrypting the second-level key using a first encryption algorithm combined with a first block pattern and first additional information, and the first pre-stored information includes first ciphertext and first integrity protection additional information; Using the recovered first-level key as the key, the second-level key is decrypted from the first pre-stored information by using the first encryption algorithm in combination with the first block pattern and the first additional information.

5. The blockchain signature machine security design method according to claim 4, characterized in that, The step of recovering the third-level key based on the second-level key includes: The second pre-stored information is obtained by encrypting the third-level key using a second encryption algorithm combined with a second block mode and second additional information. The second pre-stored information includes a second ciphertext and second integrity protection additional information. Using the recovered second-level key as the key, the third-level key is decrypted from the second pre-stored information by using the second encryption algorithm in combination with the second block pattern and the second additional information.

6. The blockchain signature machine security design method according to any one of claims 1-5, characterized in that, Also includes: Set a whitelist of information to be signed, wherein the filtering conditions of the whitelist are one or more features of the information to be signed; Receive signature request; If the signature request matches the whitelist, then the signature request is signed; If the signature request does not conform to the whitelist, the signature request is rejected.

7. The blockchain signature machine security design method according to claim 1, characterized in that, Also includes: Record the preset information and the confirmation information of the preset information as audit basis; and / or The preset information and confirmation information of the preset information are reported by sending emails or calling workflows, serving as the basis for auditing.

8. A signature machine, characterized in that, include: The acquisition module is used to obtain multiple components of the first-level key from multiple component holders in response to a signature request; The recovery module is used to recover the first-level key based on the multiple components, and to recover subsequent keys based on the first-level key, wherein the subsequent keys are used to derive the blockchain private key; The first-level key is divided into n components using a secret splitting algorithm. Any t components can be used to recover the first-level key, while any number of components less than t cannot be used to recover the first-level key. The recovery module is also used for: The first-level key is recovered from t or more components using a secret segmentation algorithm. The first-level key is compared with the pre-stored integrity information to ensure that the first-level key is correctly recovered. The signature machine is also used for: Receive a first signature request, the first signature request including preset information, the preset information being information to be signed; The preset information is provided to multiple component holders for confirmation; Receive second signature request; If the second signature request matches the preset information and the preset information is valid, the second signature request is signed. After the signing is completed, if the number of signatures has reached the preset limit, the preset information becomes invalid. If the second signature request does not match the preset information, or if the preset information has expired, the second signature request is rejected.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the blockchain signature machine security design method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that can be executed by at least one processor to cause the at least one processor to perform the steps of the blockchain signature machine security design method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the blockchain signature machine security design method according to any one of claims 1 to 7.

Images