WO2020181427A1

WO2020181427A1 - Signing method, device, and system employing secure multi-party computation

Info

Publication number: WO2020181427A1
Application number: PCT/CN2019/077527
Authority: WO
Inventors: 唐虹刚; 谢翔; 孙立林
Original assignee: 云图有限公司
Priority date: 2019-03-08
Filing date: 2019-03-08
Publication date: 2020-09-17

Abstract

Embodiments of the description disclose a signing method, device, and system employing secure multi-party computation (SMPC). The method comprises: acquiring transaction data, and generating a transaction hash from the transaction data by using a pre-configured rule; determining a signing level of the transaction data according to a relationship between a transaction ceiling in the transaction data and a first threshold; determining a signing organization on the basis of the signing level, the signing organization being a trusted organization that signs the transaction data; and performing SMPC-based signature verification on the transaction hash on the basis of a private key slice stored by the determined signing organization and a private key slice stored by a client, wherein the trusted organization and the client respectively store the private key slices, and the private key slice consists of part of a child private key acquired by slicing an asymmetric key. The embodiments of the description eliminate security risks caused by a lost or stolen private key, and dramatically improves security of transaction.

Description

A signature method, device and system based on secure multi-party calculation

Technical field

The solution in the embodiments of this specification belongs to the field of information security technology, and in particular relates to a signature method, device and system based on secure multi-party computing.

Background technique

Secure Multi-Party Computation (MPC) is to solve the problem of collaborative computing that protects privacy between a group of untrusted parties. It can be abstractly understood as: each participant owns their own private data, and calculates the public function without leaking their private data, and when the entire function calculation is completed, each participant only knows the calculation result, and does not know the other Participants’ data and intermediate data in the calculation process. It can be seen that the application of secure multi-party computing to asset transaction security and future digital asset management has an important role.

At present, in digital asset management and asset transactions, the dynamic signature method based on secure multi-party computing is to divide the private key in the asymmetric key into two pieces. The organization keeps one piece and the user personally keeps one piece. Only the organization and the individual can sign together. Complete the transaction process. Although this scheme can largely alleviate the security problem of a single key being lost and stolen, in an extreme case: when the keys of individuals and institutions are both stolen, the security of assets cannot be guaranteed. It can be seen that the existing widely used asymmetric key scheme still has great security problems.

Therefore, the industry urgently needs a solution that can effectively solve the loss or theft of the private key.

Summary of the invention

The purpose of the embodiments of this specification is to provide a signature method, device, and system based on secure multi-party calculation, which can effectively solve the security risks of loss or theft of private keys, and greatly improve transaction security.

On the one hand, this application provides a signature method based on secure multi-party calculation, including:

Obtain transaction data, and generate transaction hash using preset rules for the transaction data;

Determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold;

Based on the signature level, determining a signature authority, which is a trusted authority that signs the transaction data;

Based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client, signature authentication based on secure multi-party calculation is performed on the transaction hash, wherein the trusted authority and the client are respectively Private key fragments are stored, and the private key fragments are composed of partial sub-private keys generated based on splitting the asymmetric key.

In another embodiment of the method provided in this specification, the trusted organization and the client respectively storing private key fragments, including:

Generate at least two pairs of asymmetric keys during the registration process;

Segmenting the private key in the asymmetric key to obtain the first segment of the private key and the second segment of the private key;

The first fragment of the private key is stored in the trusted authority, and the second fragment of the private key is stored in the client.

In another embodiment of the method provided in this specification, the storing the first fragment of the private key in the trusted authority and storing the second fragment of the private key in the client includes :

The first fragments of different private keys are stored in different trusted institutions, and the second fragments of different private keys are stored in different hardware areas of the client. Among them, the signature levels authorized by different trusted institutions are different.

In another embodiment of the method provided in this specification, the determining the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold includes:

When the transaction amount is greater than or equal to the first threshold, determining that the signature level of the transaction data is the first level;

When the transaction amount is less than the first threshold, it is determined that the signature level of the transaction data is the second level.

In another embodiment of the method provided in this specification, the determining the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold value further includes:

When the transaction amount is less than a second threshold, it is determined that the signature level of the transaction data is a third level, and the second threshold is less than the first threshold.

In another embodiment of the method provided in this specification, the determining a signature authority based on the signature level includes:

When it is determined that the signature level is the first level, it is determined that there are at least two signature agencies that authorize the signature level;

When it is determined that the signature level is the second level or the third level, it is determined that the signature authority authorized by the signature level includes one.

On the other hand, the embodiment of this specification also provides a signature device based on secure multi-party calculation, including:

The transaction data acquisition module is used to acquire transaction data, and generate a transaction hash using preset rules for the transaction data;

A signature level determination module, configured to determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold;

A signature authority determination module, configured to determine a signature authority based on the signature level, the signature authority being a trusted authority that signs the transaction data;

The signature verification module is configured to perform signature verification based on secure multi-party calculation on the transaction hash based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client, wherein the trusted authority A private key segment is stored separately with the client, and the private key segment is composed of partial sub-private keys generated based on splitting the asymmetric key.

In another embodiment of the device provided in this specification, the trusted organization and the client separately store private key fragments, including:

The key generation module is used to generate at least two pairs of asymmetric keys during the registration process;

The fragment obtaining module is used to split the private key in the asymmetric key to obtain the first fragment of the private key and the second fragment of the private key;

The fragment saving module is configured to save the first fragment of the private key in the trusted authority, and save the second fragment of the private key in the client.

In another embodiment of the device provided in this specification, the signature level determination module includes:

The first determining unit is configured to determine that the signature level of the transaction data is the first level when the transaction amount is greater than or equal to the first threshold;

The second determining unit is configured to determine that the signature level of the transaction data is the second level when the transaction amount is less than the first threshold.

In another embodiment of the device provided in this specification, the signature level determination module further includes:

The third determining unit is configured to determine that the signature level of the transaction data is a third level when the transaction amount is less than a second threshold, and the second threshold is less than the first threshold.

On the other hand, the embodiments of this specification provide a signature device based on secure multi-party computing, including a processor and a memory for storing processor-executable instructions. When the instructions are executed by the processor, the implementation includes the following steps:

On the other hand, the embodiments of this specification provide a signature system based on secure multi-party computing, including at least one processor and a memory storing computer-executable instructions. The processor implements the instructions described in any one of the foregoing embodiments when executing the instructions. Method steps.

The embodiment of this specification provides a signature method, device, and system based on secure multi-party computing. At least two pairs of asymmetric keys are generated when applying for registration, and then the private key in the key is segmented and saved to multiple trusted In the third-party organization and the user client, when the transaction is actually performed, the transaction amount is compared with a preset threshold to determine the signature level of the transaction and the signature organization, and then use the private key saved by the signature organization to slice and save on the client The private key sharding of the transaction data performs signature verification based on secure multi-party calculations, realizing dynamic multi-key simultaneous signing. In this way, since the possibility of multiple third-party institutions being compromised at the same time is very low, the implementation scheme provided in this manual can effectively solve the security risks of loss or theft of private keys while realizing dynamic multi-key signatures. Dadi improves transaction security.

Description of the drawings

In order to more clearly explain the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only These are some embodiments described in this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative labor.

FIG. 1 is a schematic flowchart of an embodiment of a signature method based on secure multi-party computing provided in this specification;

FIG. 2 is a schematic flowchart of an embodiment of key processing in the application registration process provided in this specification;

FIG. 3 is a schematic structural diagram of an embodiment in which a private key sharding party needs to be provided for a small amount signature based on secure multi-party calculation provided in this specification;

FIG. 4 is a schematic flow chart of an embodiment of small-amount signature authentication based on secure multi-party computing provided in this specification;

FIG. 5 is a schematic structural diagram of an embodiment of a private key sharding party that needs to provide a private key for a medium signature based on secure multi-party calculation provided in this specification;

FIG. 6 is a schematic structural diagram of an embodiment of a private key sharding party that needs to provide a private key for large-amount signature based on secure multi-party calculation provided in this specification;

FIG. 7 is a schematic diagram of the module structure of an embodiment of a signature device based on secure multi-party computing provided in this specification;

FIG. 8 is a schematic diagram of the module structure of an embodiment of a signature system based on secure multi-party computing provided in this specification.

detailed description

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described The embodiments are only a part of the embodiments in this specification, rather than all the embodiments. Based on one or more embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative work shall fall within the protection scope of the embodiments of this specification.

Correspondingly, in one or more implementations provided in this specification, at least two pairs of asymmetric keys are generated during the registration application, and then the private key in the key is segmented and saved to multiple trusted third-party institutions and users In the client, when the transaction is actually performed, the transaction amount is compared with a preset threshold to determine the signature level of the transaction and the signing authority, and then use the private key shards saved by the signature authority and the private key shards saved by the client Perform signature verification based on secure multi-party calculations on transaction data to achieve dynamic multi-key simultaneous signatures. In this way, since the possibility of multiple third-party institutions being compromised at the same time is very low, the implementation scheme provided in this manual can effectively solve the security risks of loss or theft of private keys while realizing dynamic multi-key signatures. Dadi improves transaction security.

The following takes a specific application scenario as an example to describe the implementation of this specification. Specifically, FIG. 1 is a schematic flowchart of an embodiment of a signature method based on secure multi-party computing provided in this specification. Although this specification provides method operation steps or device structures as shown in the following embodiments or drawings, the method or device may include more or fewer operation steps after partial combination based on conventional or no creative labor. Or modular unit. In steps or structures where there is no necessary causal relationship logically, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure shown in the embodiments of this specification or the drawings. When the described method or module structure is applied to an actual device, server or terminal product, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or drawings (for example, parallel processor or multi-threaded processing). Environment, even including distributed processing, server cluster implementation environment).

Of course, the description of the following embodiments does not limit other expandable technical solutions based on this specification.

A specific embodiment is shown in Fig. 1. In an embodiment of a signature method based on secure multi-party computation provided in this specification, the method may include:

S1: Obtain transaction data, and generate a transaction hash using preset rules for the transaction data.

Transaction data is the data information generated when the transaction party conducts a transaction, and it can at least include the transaction amount. For example, it can be online shopping or offline bill payment, etc., all including at least the transaction amount. The preset rule is an algorithm that converts transaction data into transaction hash, which can be MD5 (Message-Digest Algorithm 5), SHA (Secure Hash Algorithm, secure hash algorithm), etc., or other algorithms. This manual does not limit this. Hash, or HASH, is called hash in mathematics. It is like a fingerprint of data. The form of expression can be expressed by a string of letters, numbers or other symbols. Transaction HASH is a character segment that can mark transaction data, which is generally a voucher for transaction.

In one embodiment of this specification, by acquiring transaction data, the transaction data is generated using a preset algorithm to generate a transaction hash, that is, the transaction data is converted into a character string marking the transaction data, which provides a basis for further signature verification.

In an embodiment of this specification, the trusted organization and the client separately store private key fragments, including: generating at least two pairs of asymmetric keys during the registration process, and combining the private key in the asymmetric key Key segmentation to obtain the first segment of the private key and the second segment of the private key, store the first segment of the private key in the trusted authority, and store the second segment of the private key in the Client. Wherein, storing the first fragment of the private key in the trusted authority and storing the second fragment of the private key in the client includes: storing the first fragment of different private keys in different In the trust organization, the second fragments of different private keys are stored in different hardware areas of the client, where the signature levels authorized by different trusted organizations may be different.

Specifically, taking the generation of two pairs of keys as an example, two pairs of asymmetric keys A and B are generated during the registration process, and the private keys SKA and SKB of the two pairs of keys are split to obtain SKA1 and SKB respectively. SKA2, SKB1 and SKB2, and then part of the split private key (SKA1, SKB1) is kept in the secure storage area inside the trusted organization, and the other part (SKA2, SKB2) is safely distributed to users. Put the private key fragments into different security areas of the client, such as the SIM (Subscriber Identity Module) card of the mobile phone and the TEE (Trust Execution Environment) of the mobile phone CPU. As shown in Fig. 2, Fig. 2 is a schematic flowchart of an embodiment of key processing in the registration application process provided in this specification. Among them, the arrow of private key A segment 1 pointing to trusted organization 1 means that private key A segment 1 is saved to trusted organization 1. Similarly, the arrow of private key B segment 1 pointing to trusted organization 2 means that the private key B segment 1 is saved to trusted institution 2. The arrow pointing to the SIM of the private key A segment 2 indicates that the private key A segment 2 is stored in the secure area of the SIM card on the mobile device (mobile phone); similarly, the private key B segment 2 is secured by the TEE in the mobile device (mobile phone) CPU Area to save. If the trusted institution 1 points to the SIM card, it means that the trusted institution 1 interacts with the SIM card; in the same way, the trusted institution 2 points to the TEE means that the trusted institution 2 interacts with the TEE. In this way, by storing the two private keys in different hardware security areas, it is more difficult for hackers to crack two different security hardware at the same time, which can increase security.

It should be noted that the application registration process can be completed by the user interacting with trusted institutions 1 and 2 through the mobile phone wallet APP agent. Among them, wallets are generally developed by third parties. In some embodiments, the wallet can be provided by a transaction institution or by one of the trusted institutions. Generally, the transaction function is also integrated in the wallet function to facilitate users to implement transactions.

In addition, the above-mentioned two pairs of asymmetric keys generated during the registration application process are merely illustrative. In specific implementation, more than two pairs of asymmetric keys can be generated during the registration process mentioned above. The processing method is similar to the processing method of generating two pairs of keys. The specific implementation method can refer to the method of generating two pairs of keys. The description of the processing embodiments will not be repeated here.

Further, in the subsequent processing of transaction data in response to user instructions, the trusted institution and the user client are required to provide the private key fragments they hold together to perform specific transaction data processing. For example, it is necessary to use the private key shards kept by two trusted institutions and the private key shards kept by the client at the same time to call the fund data in the user's account and complete the transaction. Since the possibility of two third-party trusted institutions being compromised at the same time is very low, by introducing two trusted third-party institutions at the same time, even if the third party steals the private key fragments kept by a trusted institution and the client respectively , It is also impossible to call the user's account, which can greatly improve the security of the user's transaction data processing.

The foregoing client can be specifically understood as a client device that stores the user's private key fragments. For example, it may be a mobile phone or tablet that was previously used by the user or previously bound to the user's account. The above-mentioned trusted organization can be understood as a system that stores user private key fragments. For example, it may be a banking system or management system that was previously used by the user or previously bound to the user's account. Of course, it should be noted that the clients and trusted institutions listed above are only schematic illustrations. In a specific implementation, the aforementioned client may also be other types of electronic equipment, or a software program running in the aforementioned electronic equipment, etc., and the aforementioned trusted institution may also be other transaction systems. This manual does not limit the specific forms and types of clients and trusted institutions.

In addition, in the embodiments of this specification, when multiple pairs of asymmetric keys are generated during the registration application process, multiple trusted institutions can be introduced, and when the client saves multiple private key fragments, they can be stored through software processing. To different security areas; for different trusted institutions, different signature levels can be granted according to the actual situation. For example, in some embodiments, two trusted institutions are introduced. Trusted institution 1 can be preset to authenticate transactions with a smaller amount, and trusted institution 2 to authenticate signatures with a larger amount. However, two trusted institutions are required for large transactions. At the same time signature authentication. In other embodiments, two trusted institutions are introduced, and the two trusted institutions can be set to have the same signature level. In the case of small transactions, one trusted institution is randomly selected for authentication. When the transaction amount is large, two are required. At the same time, the trusted organization signs and authenticates.

S2: Determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold.

The first threshold may be preset according to actual transactions, or may be preset according to customer needs. The signature level can be understood as the security level of the transaction amount.

In an embodiment of this specification, the signature level can be divided into two levels according to actual scenarios, that is, when the transaction amount is greater than or equal to the first threshold, it is determined that the signature level of the transaction data is the first level, and when the transaction When the amount is less than the first threshold, it is determined that the signature level of the transaction data is the second level. Specifically, a limit can be set in advance. When the transaction limit is greater than or equal to the limit, it can be determined that the signature level of the transaction belongs to the first level, that is, a large amount signature; when the transaction limit is less than the limit, the signature level of the transaction can be determined Belongs to the second level, that is, small signatures. For example, the user presets the bank's transaction limit as 1000. When the transaction amount exceeds 1000, it is a large-value signature and requires multiple parties to perform signature verification; when the transaction amount is less than 1000, it is a small-value signature and only one institution is required. The signature verification is sufficient.

In another embodiment of this specification, the signature level can be divided into three levels according to actual scenarios, that is, when the transaction amount is greater than or equal to the first threshold, it is determined that the signature level of the transaction data is the first level, and when the When the transaction amount is less than the first threshold, the signature level of the transaction data is determined to be the second level, and when the transaction amount is less than the second threshold, the signature level of the transaction data is determined to be the third level, and the first The second threshold is less than the first threshold. Specifically, two quotas can be set in advance (the first quota is greater than the second quota). When the transaction quota is greater than or equal to the first quota, it can be determined that the signature level of the transaction belongs to the first level, that is, a large amount signature; when the transaction quota is greater than When it is equal to the second amount and less than the first amount, it can be determined that the signature level of the transaction belongs to the second level, that is, the middle amount signature; when the transaction amount is less than the second amount, it can be determined that the signature level of the transaction belongs to the third level, that is Sign a small amount. For example, the user presets the bank’s transaction limits as 1000 and 500. When the transaction amount exceeds 1000, it is a large-value signature and requires multiple parties to perform signature verification; when the transaction amount is greater than or equal to 500 and less than 1000, it belongs to A medium-value signature requires an institution to perform signature verification; when the transaction amount is less than 500, it is a small-value signature and requires an institution to perform signature verification. In this way, when large-value transactions are carried out, even if the key fragments of individuals and an organization are stolen, the security of assets can be effectively protected.

It should be noted that the transaction quota corresponding to the first level is greater than the transaction quota corresponding to the second level, and the transaction quota corresponding to the second level is greater than the transaction quota corresponding to the third level. In addition, the above-mentioned signature levels of two or three levels are merely illustrative. In specific implementation, the above-mentioned signature levels can also be divided into other levels according to actual needs, and this specification does not limit this.

S3: Based on the signature level, a signature authority is determined, and the signature authority is a trusted authority that signs the transaction data.

Since the signature agency is a trusted agency that signs the transaction data, and the signature levels authorized by different trusted agencies can be different, when the transaction data is determined according to the relationship between the transaction amount and the first threshold in the transaction data In the signature level, the signature authority required for signature verification of the current transaction can be determined according to the signature levels authorized by different trusted institutions.

In the following embodiment of this specification, when the signature level is divided into two levels, and the signature level is determined to be the first level, it can be determined that the signature authority authorized by the signature level includes at least two; when it is determined that the signature level is In the second level, it can be determined that the signature authority authorized by the signature level includes one. Specifically, in the transaction process, assuming that the signature level is preset to two levels, when the signature level is a large-value signature, at least two trusted institutions authorized to perform large-value signatures are required to perform signature verification at the same time; In the case of small-value signatures, only a trusted organization authorized to perform small-value signatures can perform signature verification.

In another embodiment of this specification, when the signature level is divided into three levels, and the signature level is determined to be the first level, it is determined that the signature authority authorized by the signature level includes at least two; when it is determined that the signature level is In the second level, it is determined that the signature level authorized to include one signature authority; when the signature level is determined to be the third level, it is determined that the signature level authorized includes one signature authority. Specifically, assuming that the signature level is preset to three levels, when the signature level is a large-value signature, at least two trusted institutions authorized to perform large-value signatures are required to perform signature authentication; when the signature level is a medium-value signature, only A trusted organization authorized to perform medium-value signatures can perform signature verification; when the signature level is a small-value signature, only a trusted organization authorized to perform small-value signatures can perform signature verification. In this way, by determining the signature level according to the transaction amount during the transaction, and then using the corresponding relationship between the signature level and the signature authority to determine the final signature authority required, the security of the asset can be effectively guaranteed.

It should be noted that the signature levels authorized by different trusted institutions can be different or the same, and this specification does not limit this. For example, in some embodiments, two trusted institutions are introduced. Trusted institution 1 can be preset to authenticate transactions with a smaller amount, and trusted institution 2 to authenticate signatures with a larger amount. However, two trusted institutions are required for large transactions. At the same time signature authentication. In other embodiments, two trusted institutions are introduced, and the two trusted institutions can be set to have the same signature level. In the case of small transactions, one trusted institution is randomly selected for authentication. When the transaction amount is large, two are required. At the same time, the trusted organization signs and authenticates.

S4: Perform signature verification based on secure multi-party calculation on the transaction hash based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client, wherein the trusted authority and the client The terminals respectively store private key fragments, and the private key fragments are composed of partial sub-private keys generated based on splitting the asymmetric key.

Secure Multi-Party Computation (MPC) is a collaborative computing problem that solves the privacy protection of a group of untrusted parties. It can be abstractly understood as: multiple parties holding their own private data to execute together A function (such as calculating the maximum value), and obtain the calculation result, but in the process, each party participating in the process will not leak their own data. Signature verification can also be understood as transaction signature. Transaction signature is to digitally sign the transaction, that is, to digitally sign the transaction data packet (block) composed of transaction information, including transaction information such as the trader, amount, time, etc., generally initiated by the transaction (Usually the transferer of the asset) signature, and digital signature (also known as public key digital signature, electronic signature, etc.) is a kind of ordinary physical signature similar to that written on paper, but it uses technology in the field of public key encryption Implementation, a method used to identify digital information. In addition, digital signatures use public and private keys, the private key is used for signature, and the public key is used for verification. Generally, the algorithms that can be used for signatures are RSA (Rivest-Shamir-Adleman, an asymmetric encryption algorithm), DSA (Digital Signature Algorithm, digital signature algorithm), ECDSA (Elliptic Curve Digital Signature Algorithm, elliptic curve digital signature) Encryption algorithm) There are three types, but ECDSA is mainly used in the blockchain. This manual can also use other signature algorithms to sign, which is not limited.

In the embodiment of this specification, since at least two pairs of asymmetric keys are generated during the registration process, the private key in the asymmetric key is then divided to obtain the first segment of the private key and the second segment of the private key. Save the first fragment of the private key in a trusted institution, and save the second fragment of the private key in the client. Among them, the first shards of different private keys are stored in different trusted institutions, and the second shards of different private keys are stored in different hardware areas of the client, so according to the relationship between the transaction amount and the first threshold in the transaction data , After determining the signature level of the transaction data, and determining the final signature authority required according to the corresponding relationship between the signature level and the signature authority, it can be based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client , Perform signature verification based on secure multi-party calculation on the transaction hash.

Specifically, when the signature level is preset to three levels, and two different trusted institutions (institution 1, institution 2) have different authorization levels, it is assumed that institution 1 is pre-set to perform small signature authentication, and institution 2 is Medium-value signature verification. Large-value transactions require two institutions to sign and verify at the same time. When the current transaction amount is a small-value signature, the required signature agency is determined to be agency 1, and then the private key saved by agency 1 is used to split and The private key saved by the client is sharded to perform signature verification based on secure multi-party calculation on the transaction hash; when the current transaction amount belongs to a medium signature, it is determined that the required signature institution is institution 2, and the institution 2 is used The saved private key shards and the private key shards saved on the client side are used to perform signature verification based on secure multi-party calculation on the transaction hash; when the current transaction amount belongs to a large-value signature, the required signature agency is determined to be an agency 1 and Institution 2, use the private key fragments saved by institution 1, the private key fragments saved by institution 2, and the private key fragments saved by the client, and simultaneously sign the transaction hash based on secure multi-party calculations Certification. Wherein, the private key segment is composed of partial sub-private keys generated based on segmenting the asymmetric key.

Further, suppose that the signature level is preset to three levels: small-value signature, medium-value signature, and large-value signature. Institution 1 performs small-value signature verification, and institution 2 performs medium-value signature verification. Large-value transactions require two institutions to sign and verify at the same time. , And two pairs of asymmetric keys A and B are generated during the registration process, and the private keys in the two pairs of keys are split to obtain private key A segment 1 and private key A segment 2, respectively. B segment 1 and private key B segment 2, then save the split private key A segment 1 in organization 1, private key B segment 1 in organization 2, private key A segment 2 and The private key B segment 2 is stored in the user's mobile phone, and the organization that chooses to sign the transaction may be different depending on the transaction amount. For example, as shown in Figure 3, Figure 4, Figure 5, and Figure 6, Figure 3 is a schematic diagram of an embodiment provided in this specification in which a private key sharding party needs to be provided for a small signature based on secure multi-party computing. The manual provides a schematic flow diagram of an embodiment of small-amount signature authentication based on secure multi-party computing. FIG. 5 is a schematic structural diagram of an embodiment of the private key sharding party that needs to provide a private key for a small-value signature based on secure multi-party computing provided in this specification. Fig. 6 is a schematic structural diagram of an embodiment provided in this specification in which a private key sharding party needs to be provided for a large-value signature based on secure multi-party calculation. Among them, in Figure 4, the function Sign = F (A1, A2) can represent the private key A segment 1 (A1) saved by the organization 1 and the private key A segment 2 (A2) saved by the user's mobile phone as the function F Input and get the output result Sign process, that is, each participant (institution 1 and user's mobile phone) has their own private data (A1, A2), and can calculate the public function ( The result of F), and when the entire function calculation is completed, each participant only knows the calculation result (Sign).

In addition, in the above embodiment, it is also possible to set two institutions to have the same signature level. In the case of small-value signatures and medium-value signatures, one agency can be randomly selected for signature verification, and when large-value signatures are signed, both agencies simultaneously sign and verify .

It should be noted that for the implementation process of the medium signature and the large signature, refer to the flowchart in FIG. 4, which will not be repeated in this specification. For embodiments where the signature level is preset to other levels, a method similar to the above or other methods can be used to implement the signature, which is not limited. This manual only uses two pairs of asymmetric keys to be generated during the registration application, and there are two corresponding institutions as an example, which is only a schematic illustration. During specific implementation, multiple pairs of asymmetric keys and multiple institutions can be applied, and this specification does not limit it.

The embodiment of this specification provides a signature method based on secure multi-party calculation, which generates at least two pairs of asymmetric keys during registration application, and then divides the private key in the key and saves it to multiple trusted third-party institutions and In different hardware areas of the user client, when the transaction is actually performed, the transaction amount is compared with the preset threshold to determine the signature level of the transaction and the signature authority, and then use the private key saved by the signature authority to shard and the client save Private key sharding performs signature verification based on secure multi-party calculations on transaction data, realizing dynamic multi-key simultaneous signing. In this way, since the possibility of multiple third-party institutions being compromised at the same time is very low, the implementation scheme provided in this manual can effectively solve the security risks of loss or theft of private keys while realizing dynamic multi-key signatures. Dadi improves transaction security.

Based on the aforementioned signature method based on secure multi-party computing, one or more embodiments of this specification also provide a signature device based on secure multi-party computing. The described devices may include systems (including distributed systems), software (applications), modules, components, servers, clients, etc., which use the methods described in the embodiments of this specification, combined with necessary implementation hardware devices. Based on the same innovative concept, the devices in one or more embodiments provided in the embodiments of this specification are as described in the following embodiments. Since the implementation scheme of the device to solve the problem is similar to the method, the implementation of the specific device in the embodiment of this specification can refer to the implementation of the foregoing method, and the repetition will not be repeated. As used below, the term "unit" or "module" can be a combination of software and/or hardware that implements predetermined functions. Although the devices described in the following embodiments are preferably implemented by software, hardware or a combination of software and hardware is also possible and conceived.

Specifically, FIG. 7 is a schematic diagram of the module structure of an embodiment of a signature device based on secure multi-party computing provided in this specification. As shown in FIG. 7, a signature device based on secure multi-party computing provided in this specification may include: Transaction data acquisition module 121, signature level determination module 122, signature authority determination module 123, signature verification module 124. Wherein, the transaction data obtaining module 121 may be used to obtain transaction data, and generate a transaction hash using preset rules for the transaction data;

The signature level determining module 122 may be used to determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold;

The signature authority determining module 123 may be used to determine a signature authority based on the signature level, where the signature authority is a trusted authority that signs the transaction data;

The signature verification module 124 can be used to perform signature verification based on secure multi-party calculation on the transaction hash based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client. The trust agency and the client respectively store private key fragments, and the private key fragments are composed of partial sub-private keys generated based on splitting the asymmetric key.

In another embodiment of the device, the trusted organization and the client separately store private key fragments, which may include:

The key generation module can be used to generate at least two pairs of asymmetric keys during the registration process;

The fragment obtaining module can be used to split the private key in the asymmetric key to obtain the first fragment of the private key and the second fragment of the private key;

The fragment saving module may be used to save the first fragment of the private key in the trusted authority, and save the second fragment of the private key in the client.

In another embodiment of the apparatus, the signature level determining module 122 may include:

The first determining unit may be configured to determine that the signature level of the transaction data is the first level when the transaction amount is greater than or equal to the first threshold;

The second determining unit may be configured to determine that the signature level of the transaction data is the second level when the transaction amount is less than the first threshold.

In another embodiment of the apparatus, the signature level determining module 122 may further include:

The third determining unit may be configured to determine that the signature level of the transaction data is a third level when the transaction amount is less than a second threshold, and the second threshold is less than the first threshold.

It should be noted that the above-mentioned device may also include other implementation manners according to the description of the method embodiment, and for the specific implementation manner, refer to the description of the related method embodiment, which is not repeated here.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

The methods described in the foregoing embodiments provided in this specification can implement business logic through a computer program and be recorded on a storage medium, and the storage medium can be read and executed by a computer to achieve the effects of the solutions described in the embodiments of this specification. Therefore, this specification also provides a signature device based on secure multi-party computing, which includes a processor and a memory for storing processor-executable instructions. When the instructions are executed by the processor, the implementation includes the following steps:

Based on the signature level, determine a signature authority, where the signature authority is a trusted authority that signs the transaction data;

The storage medium may include a physical device for storing information, and the information is usually digitized and then stored in an electric, magnetic, or optical medium. The storage medium may include: devices that use electrical energy to store information, such as various types of memory, such as RAM, ROM, etc.; devices that use magnetic energy to store information, such as hard disks, floppy disks, magnetic tapes, magnetic core memory, bubble memory, U disk; a device that uses optical means to store information, such as CD or DVD. Of course, there are other ways of readable storage media, such as quantum memory, graphene memory, and so on.

It should be noted that the above-mentioned device may also include other implementation manners according to the description of the method embodiment. For specific implementation manners, reference may be made to the description of the related method embodiments, which will not be repeated here.

The above-mentioned signature method, device, and device based on secure multi-party computing provided by the embodiments of this specification can be implemented in a computer by a processor executing corresponding program instructions, such as using the c++ language of the windows operating system to implement on the PC side, and the linux system Implementation, or other implementations such as using android and iOS system programming languages in smart terminals, and implementation of processing logic based on quantum computers. This specification provides an embodiment of a signature system based on secure multi-party computing. FIG. 8 is a schematic diagram of the module structure of an embodiment of a signature system based on secure multi-party computing provided in this specification. As shown in FIG. 8, this A signature system based on secure multi-party computing provided in the specification may include a processor 131 and a memory 132 for storing executable instructions of the processor. The processor 131 and the memory 132 communicate with each other through a bus 133;

The processor 131 is configured to call the program instructions in the memory 132 to execute the method provided in the above-mentioned signature method based on secure multi-party computing. For example, the processor 131 includes: obtaining transaction data and using preset rules for the transaction data. Generate a transaction hash; determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold; determine the signature authority based on the signature level, and the signature authority performs the transaction data The trusted authority of the signature; based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client, signature verification based on secure multi-party calculation is performed on the transaction hash, wherein the trusted authority A private key segment is stored separately with the client, and the private key segment is composed of partial sub-private keys generated based on splitting the asymmetric key.

It should be noted that the system described above in the specification may also include other implementation manners based on the description of the related method embodiments. For specific implementation manners, refer to the description of the method embodiments, which will not be repeated here. The various embodiments in the present application are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the difference from other embodiments. In particular, for the hardware+program embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment.

The embodiment of this specification provides a signature device or device or system based on secure multi-party computing, which generates at least two pairs of asymmetric keys when applying for registration, and then splits the private key in the key and saves it to multiple trusted In the third-party organization and the user client, when the transaction is actually performed, the transaction amount is compared with a preset threshold to determine the signature level of the transaction and the signature organization, and then use the private key saved by the signature organization to slice and save on the client The private key sharding of the transaction data performs signature verification based on secure multi-party calculations, realizing dynamic multi-key simultaneous signing. In this way, since the possibility of multiple third-party institutions being compromised at the same time is very low, the implementation scheme provided in this manual can effectively solve the security risks of loss or theft of private keys while realizing dynamic multi-key signatures. Dadi improves transaction security.

The embodiments of this specification are not limited to the conditions described in one or more embodiments of this specification that must comply with industry communication standards, standard computer data processing and data storage rules. Certain industry standards or implementations described in custom methods or examples with slight modifications can also achieve the same, equivalent or similar implementation effects of the foregoing examples, or predictable implementation effects after modification. Examples obtained by applying these modified or deformed data acquisition, storage, judgment, processing methods, etc., may still fall within the scope of the optional implementation solutions of the examples of this specification.

In the 1990s, the improvement of a technology can be clearly distinguished between hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) and software improvements (improvements in method flow). However, with the development of technology, the improvement of many methods and processes of today can be regarded as a direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware entity modules. For example, a programmable logic device (Programmable Logic Device, PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user's programming of the device. It is programmed by the designer to "integrate" a digital system on a PLD without requiring the chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly realized by "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and there is not only one type of HDL, but many types, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description), etc., currently most commonly used It is VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logic programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain the hardware circuit that implements the logic method flow.

The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program codes (such as software or firmware) executable by the (micro)processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as a part of the memory control logic. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, it is entirely possible to program the method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded The same function can be realized in the form of a microcontroller, etc. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for implementing various functions can also be regarded as a structure within the hardware component. Or even, the device for realizing various functions can be regarded as both a software module for realizing the method and a structure within a hardware component.

The systems, devices, modules, or units illustrated in the above embodiments may be specifically implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, and a tablet. Computers, wearable devices, or any combination of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, conventional or non-inventive means may include more or fewer operation steps. The sequence of steps listed in the embodiment is only one way of the execution sequence of the steps, and does not represent the only execution sequence. When an actual device or terminal product is executed, it can be executed sequentially or in parallel according to the methods shown in the embodiments or drawings (for example, a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product, or device that includes a series of elements includes not only those elements, but also other elements that are not explicitly listed. Elements, or also include elements inherent to such processes, methods, products, or equipment. If there are no more restrictions, it does not exclude that there are other identical or equivalent elements in the process, method, product, or device including the elements. Words such as first and second are used to denote names, but do not denote any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the function of each module can be realized in the same one or more software and/or hardware, or the module that realizes the same function can be realized by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are merely illustrative, for example, the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or integrated To another system, or some features can be ignored, or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

The present invention is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.

In a typical configuration, the computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent memory in computer readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.

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

Those skilled in the art should understand that one or more embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, one or more embodiments of this specification may adopt a computer program implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. The form of the product.

The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment. In the description of this specification, descriptions with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" etc. mean specific features described in conjunction with the embodiment or example , Structure, materials or features are included in at least one embodiment or example in this specification. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the described specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples and the characteristics of the different embodiments or examples described in this specification without contradicting each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not used to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included in the scope of the claims.

Claims

A signature method based on secure multi-party calculation, characterized in that it includes:

Obtain transaction data, and generate transaction hash using preset rules for the transaction data;

Determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold;

Based on the signature level, determining a signature authority, which is a trusted authority that signs the transaction data;

Based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client, signature authentication based on secure multi-party calculation is performed on the transaction hash, wherein the trusted authority and the client are respectively Private key fragments are stored, and the private key fragments are composed of partial sub-private keys generated based on splitting the asymmetric key.
The signature method based on secure multi-party computing according to claim 1, wherein the trusted organization and the client respectively store private key fragments, comprising:

Generate at least two pairs of asymmetric keys during the registration process;

Segmenting the private key in the asymmetric key to obtain the first segment of the private key and the second segment of the private key;

The first fragment of the private key is stored in the trusted authority, and the second fragment of the private key is stored in the client.
The signature method based on secure multi-party computing according to claim 2, wherein the first fragment of the private key is stored in the trusted authority, and the second fragment of the private key is stored The client includes:

The first fragments of different private keys are stored in different trusted institutions, and the second fragments of different private keys are stored in different hardware areas of the client. Among them, the signature levels authorized by different trusted institutions are different.
The signature method based on secure multi-party computing according to claim 1, wherein the determining the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold includes:

When the transaction amount is greater than or equal to the first threshold, determining that the signature level of the transaction data is the first level;

When the transaction amount is less than the first threshold, it is determined that the signature level of the transaction data is the second level.
A signature method based on secure multi-party computing according to claim 1 or 4, wherein the signature level of the transaction data is determined according to the relationship between the transaction amount in the transaction data and the first threshold, and include:

When the transaction amount is less than a second threshold, it is determined that the signature level of the transaction data is a third level, and the second threshold is less than the first threshold.
The signature method based on secure multi-party computing according to claim 1, wherein said determining a signature authority based on said signature level comprises:

When it is determined that the signature level is the first level, it is determined that there are at least two signature agencies that authorize the signature level;

When it is determined that the signature level is the second level or the third level, it is determined that the signature authority authorized by the signature level includes one.
A signature device based on secure multi-party computing, characterized in that it comprises:

The transaction data acquisition module is used to acquire transaction data, and generate a transaction hash using preset rules for the transaction data;

A signature level determination module, configured to determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold;

A signature authority determination module, configured to determine a signature authority based on the signature level, the signature authority being a trusted authority that signs the transaction data;

The signature verification module is configured to perform signature verification based on secure multi-party calculation on the transaction hash based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client, wherein the trusted authority A private key segment is stored separately with the client, and the private key segment is composed of partial sub-private keys generated based on splitting the asymmetric key.
The signature device based on secure multi-party computing according to claim 7, wherein the trusted organization and the client respectively store private key fragments, comprising:

The key generation module is used to generate at least two pairs of asymmetric keys during the registration process;

The fragment obtaining module is used to split the private key in the asymmetric key to obtain the first fragment of the private key and the second fragment of the private key;

The fragment saving module is configured to save the first fragment of the private key in the trusted authority, and save the second fragment of the private key in the client.
8. The signature device based on secure multi-party calculation according to claim 7, wherein the signature level determination module comprises:

The first determining unit is configured to determine that the signature level of the transaction data is the first level when the transaction amount is greater than or equal to the first threshold;

The second determining unit is configured to determine that the signature level of the transaction data is the second level when the transaction amount is less than the first threshold.
The signature device based on secure multi-party computing according to claim 7 or 9, wherein the signature level determination module further comprises:

The third determining unit is configured to determine that the signature level of the transaction data is a third level when the transaction amount is less than a second threshold, and the second threshold is less than the first threshold.
A signature device based on secure multi-party computing, which is characterized by comprising a processor and a memory for storing executable instructions of the processor, the instructions being executed by the processor including the following steps:

Obtain transaction data, and generate transaction hash using preset rules for the transaction data;

Determine the signature level of the transaction data according to the relationship between the transaction amount in the transaction data and the first threshold;

Based on the signature level, determining a signature authority, which is a trusted authority that signs the transaction data;

Based on the private key fragments saved by the determined signature authority and the private key fragments saved by the client, signature authentication based on secure multi-party calculation is performed on the transaction hash, wherein the trusted authority and the client are respectively Private key fragments are stored, and the private key fragments are composed of partial sub-private keys generated based on splitting the asymmetric key.
A signature system based on secure multi-party computing, which is characterized by comprising at least one processor and a memory storing computer-executable instructions, and the processor implements the method described in any one of claims 1-6 when executing the instructions A step of.