Cross-domain authentication method and server in secure multi-party computing

Abstract

The present application discloses a cross-domain identity authentication method and server in secure multi-party computing, the method being applied to a first server in a first domain, the method comprising: receiving a verification request sent by a first computing entity in the first domain, the verification request being used to instruct authentication of a second computing entity in a second domain; sending a public key query request to a second server in the second domain according to the verification request; receiving a first public key carrying a signature sent by the second server, the first public key being a secret key pre-generated by the first computing entity for an entity in the second domain; using the second public key to verify the signature carried by the first public key; the second public key being a secret key pre-generated by the second server for an entity in the first domain; and sending the first public key to the first computing entity when the signature carried by the first public key indicates that the second computing entity has passed the verification.

Description

Technical Field

[0001] The present application relates to the technical field of secure multi-party computing, and in particular to a cross-domain identity authentication method and server in secure multi-party computing. Background Art

[0002] Current distributed computing typically uses a PKI (Public Key Infrastructure)-based distributed computing solution. In this solution, the computing entities organized by the coordinator are all entities in the same domain, and private data is transmitted through public and private keys generated by the same trust root.

[0003] In this distributed computing solution, the same trust root is used to issue public and private keys within the same domain, which may lead to security issues such as the use of the trust root to decrypt data and cause privacy data leakage. Summary of the Invention

[0004] In view of this, this application provides a cross-domain identity authentication method and server in secure multi-party computing, as follows:

[0005] A cross-domain identity authentication method in secure multi-party computing is applied to a first server in a first domain, the method comprising:

[0006] receiving a verification request sent by a first computing entity in the first domain, wherein the verification request is used to instruct identity authentication of a second computing entity in the second domain;

[0007] Sending a public key query request to a second server in the second domain according to the verification request;

[0008] receiving a first public key carrying a signature sent by the second server, where the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain;

[0009] Verifying the signature carried by the first public key using a second public key; the second public key is a secret key pre-generated by the second server for an entity within the first domain;

[0010] In a case where the signature carried by the first public key indicates that the second computing entity has passed verification, the first public key is sent to the first computing entity.

[0011] In the above method, preferably, the verification request carries at least a request signature;

[0012] After receiving the verification request sent by the first computing entity in the first domain, the method further includes:

[0013] Verifying the request signature carried in the verification request;

[0014] If the verification request passes, executing the steps of: sending a public key query request to the second server in the second domain according to the verification request;

[0015] If the verification request fails, the current process ends.

[0016] In the above method, preferably, the request signature is obtained by the first computing entity signing the verification request using a third private key, and the third private key is a secret key generated by the first computing entity for an entity within the first domain;

[0017] The verification of the request signature carried in the verification request includes:

[0018] Verifying the request signature carried in the verification request using the third public key;

[0019] The third public key is a secret key generated by the first computing entity for the first server; or the third public key is a trust root of the first domain, and the trust root is used to generate the third private key.

[0020] The above method, preferably, further comprises:

[0021] receiving target data transmitted by the first computing entity;

[0022] The target data is transmitted to the second computing entity.

[0023] In the above method, preferably, after transmitting the target data to the second computing entity, the method further comprises:

[0024] A feedback message is sent to the first computing entity, where the feedback message at least indicates that the processing of the target data is completed.

[0025] In the above method, preferably, the verification request includes at least a domain identifier of the first computing entity and a domain identifier of the second computing entity, the domain identifier of the first computing entity is used to indicate that the first computing entity is in the first domain and uniquely indicates the first computing entity in the first domain, and the domain identifier of the second computing entity is used to indicate that the second computing entity is in the second domain and uniquely indicates the second computing entity in the second domain;

[0026] The public key query request at least includes the domain identifier of the first computing entity and the domain identifier of the second computing entity.

[0027] A cross-domain identity authentication method in secure multi-party computing is applied to a second server in a second domain, the method comprising:

[0028] receiving a public key query request sent by a first server in a first domain;

[0029] Obtaining a first public key according to the public key query request; the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain;

[0030] Signing the first public key using a second private key to obtain a first public key carrying the signature, where the second private key is a key pre-generated by the second server for an entity in the first domain;

[0031] A first public key carrying a signature is sent to the first server, where the signature carried by the first public key is used to verify the second computing entity in the second domain.

[0032] In the above method, preferably, the public key query request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity;

[0033] Obtaining the first public key according to the public key query request includes:

[0034] Retrieving target information that matches both the domain identifier of the first computing entity and the domain identifier of the second computing entity from the secret key information stored on the blockchain, the target information indicating that the first computing entity generates a public key for the second computing entity;

[0035] The first public key is obtained according to the target information.

[0036] A cross-domain identity authentication device in secure multi-party computing, applied to a first server in a first domain, comprising:

[0037] a request receiving unit, configured to receive a verification request sent by a first computing entity in the first domain, wherein the verification request is used to instruct to authenticate the identity of a second computing entity in the second domain;

[0038] a request sending unit, configured to send a public key query request to the second server in the second domain according to the verification request;

[0039] a public key receiving unit, configured to receive a first public key carrying a signature sent by the second server, where the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain;

[0040] a signature verification unit, configured to verify the signature carried by the first public key using a second public key; the second public key being a secret key pre-generated by the second server for an entity within the first domain;

[0041] The public key sending unit is configured to send the first public key to the first computing entity when the signature carried by the first public key indicates that the second computing entity has passed verification.

[0042] A cross-domain identity authentication device in secure multi-party computing, applied to a second server in a second domain, comprising:

[0043] a request receiving unit, configured to receive a public key query request sent by a first server in a first domain;

[0044] a public key obtaining unit, configured to obtain a first public key according to the public key query request; the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain;

[0045] a public key signing unit, configured to sign the first public key using a second private key to obtain a first public key carrying the signature, where the second private key is a key pre-generated by the second server for an entity in the first domain;

[0046] A public key sending unit is used to send a first public key carrying a signature to the first server, where the signature carried by the first public key is used to verify the second computing entity in the second domain.

[0047] A server, serving as a first server in a first domain, includes:

[0048] A memory for storing computer programs and data generated by the execution of the computer programs;

[0049] A processor is used to execute the computer program to achieve: receiving a verification request sent by a first computing entity in the first domain, the verification request is used to instruct to authenticate the second computing entity in the second domain; sending a public key query request to a second server in the second domain according to the verification request; receiving a first public key carrying a signature sent by the second server, the first public key being a secret key generated in advance by the first computing entity for an entity in the second domain; using the second public key to verify the signature carried by the first public key; the second public key being a secret key generated in advance by the second server for an entity in the first domain; and sending the first public key to the first computing entity when the signature carried by the first public key indicates that the second computing entity has passed the verification.

[0050] A server, serving as a second server in a second domain, comprising:

[0051] A memory for storing computer programs and data generated by the execution of the computer programs;

[0052] A processor is used to execute the computer program to achieve: receiving a public key query request sent by a first server in a first domain; obtaining a first public key according to the public key query request; the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain; using a second private key to sign the first public key to obtain a first public key carrying the signature, the second private key is a secret key pre-generated by the second server for the entity in the first domain; sending the first public key carrying the signature to the first server, and the signature carried by the first public key is used to verify the second computing entity in the second domain.

[0053] It can be seen from the above technical solution that in a cross-domain identity authentication method and server in a secure multi-party computing disclosed in the present application, the computing entities in each domain generate public keys and private keys for entities in other domains, thereby realizing secure multi-party computing between multiple domains. When entities between different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to verify the signature sent by the entity in the other domain using the private key, thereby realizing cross-domain identity authentication and avoiding the problem of privacy data leakage caused by secure multi-party computing in the same domain. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0055] Figure 1 A flowchart of a cross-domain identity authentication method in secure multi-party computing provided in Example 1 of the present application;

[0056] Figure 2 An example diagram of interactions between different domains to implement secure multi-party computation;

[0057] Figure 3 and Figure 4 Another flowchart of a cross-domain identity authentication method in secure multi-party computing provided in the first embodiment of the present application;

[0058] Figure 5 A flowchart of a cross-domain identity authentication method in secure multi-party computing provided in Example 2 of the present application;

[0059] Figure 6 A schematic diagram of the structure of a server provided in Example 3 of the present application;

[0060] Figure 7A schematic diagram of the structure of a server provided in Example 4 of the present application;

[0061] Figure 8 Interaction diagram for implementing cross-domain authentication and data transmission for this application;

[0062] Figure 9 It is a schematic diagram of the composition of SMPC in the domain;

[0063] Figure 10 This is the deployment architecture diagram of SMPC;

[0064] Figure 11 This application is applicable to the data flow diagram for cross-domain authentication and data transmission between entities in different domains. DETAILED DESCRIPTION

[0065] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0066] refer to Figure 1 As shown in FIG, a flowchart of a cross-domain authentication method in a secure multi-party computing provided in the first embodiment of the present application is provided. The method can be applied to a first server in a first domain, such as a gateway server in the current domain. For example, Figure 2 As shown in , the multiple computing entities implementing secure multi-party computation originate from multiple domains. These computing entities can be peers, clients, and other entities. The method in this embodiment is applicable to a gateway server in domain 1. The technical solution in this embodiment is primarily used to implement identity authentication between the current domain and the counterpart domain, facilitating data exchange between different domains.

[0067] Specifically, the method in this embodiment may include the following steps:

[0068] Step 101: Receive a verification request sent by a first computing entity in a first domain.

[0069] The verification request is used to instruct to authenticate the identity of the second computing entity in the second domain, so as to send target data to the second computing entity.

[0070] Specifically, the verification request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity, to indicate that the first computing entity needs to verify the second computing entity, so that the first computing entity can transmit target data to the second computing entity. Figure 2As shown in , the first computing entity in domain 1 sends an authentication request to the gateway server in domain 1 to indicate that the first computing entity needs to authenticate the second computing entity in domain 2.

[0071] The domain identifier of the first computing entity is used to indicate that the first computing entity is in the first domain and uniquely identifies the first computing entity in the first domain, and the domain identifier of the second computing entity is used to indicate that the second computing entity is in the second domain and uniquely identifies the second computing entity in the second domain. Based on this, the domain identifier of the first computing entity is the global identifier of the first computing entity in all domains, and the domain identifier of the second computing entity is the global identifier of the second computing entity in all domains.

[0072] It should be noted that the domain identifiers of computing entities in all domains are registered and recorded in the domain identifier list stored on the blockchain, and the domain identifiers of each computing entity are also stored in the local storage area. After the first computing entity is divided into a computing group for implementing secure multi-party computing by the coordination server, it receives the entity identifiers of other computing entities in the computing group sent by the coordination server. The entity identifier of a computing entity uniquely represents the computing entity in the domain where the computing entity is located and can also be understood as a local identifier. Based on this, the domain identifier of the first computing entity in the verification request is read by the first computing entity from its local storage area, and the domain identifier of the second computing entity in the verification request is obtained by the first computing entity by querying the domain identifier list stored on the blockchain based on the entity identifier of the second computing entity.

[0073] Specifically, the first computing entity can send an identification query request to the domain trust server in the first domain through the smart chain code configured in the first computing entity, which includes the entity identification of the second computing entity. As a result, the domain trust server in the first domain queries the domain identification corresponding to the entity identification of the second computing entity in the domain identification list stored on the blockchain, and then sends it to the first computing entity through the smart chain code in the first computing entity. As a result, the first computing entity can obtain the domain identification of the second computing entity. Furthermore, the first computing entity generates a verification request based on the domain identification of the first computing entity and the domain identification of the second computing entity through its smart chain code, and sends the verification request to the first server in the first domain, that is, the gateway server.

[0074] Step 102: Send a public key query request to the second server in the second domain according to the verification request.

[0075] The public key query request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity, indicating that the first server requires the second server in the second domain to return the public key generated by the first computing entity for the entity in the second domain.

[0076] Specifically, the second server in the second domain may be a domain-trusted server in the domain. Based on this, the second server in the second domain can retrieve target information that matches both the domain identifier of the first computing entity and the domain identifier of the second computing entity from the private key information stored on the blockchain according to the public key query request. The target information represents the public key generated by the first computing entity for the second computing entity. Based on this, the first public key is obtained according to the target information. For example, the public key information is extracted from the target information to obtain the first public key generated by the first computing entity for the entity in the second domain. Thereafter, the second server uses the second private key to sign the first public key to obtain the first public key carrying the signature and sends the first public key carrying the signature to the first server in the first domain.

[0077] Step 103: Receive the first public key carrying the signature sent by the second server.

[0078] Step 104: Use the second public key to verify the signature carried by the first public key.

[0079] The second public key is a secret key pre-generated by the second server for an entity in the first domain. The second public key can be pre-stored in a local storage area of the first server and sent directly by the second server to the first server to establish a trust relationship with the first server.

[0080] Specifically, the first server uses the second public key to decrypt the signature carried by the first public key, and compares the decrypted information with the first public key. If the comparison is consistent, it indicates that the first public key verification is successful, that is, the second computing entity verification is successful. If the comparison is inconsistent, it indicates that the first public key may have been tampered with or damaged. At this time, the first public key verification fails, that is, the second computing entity verification fails.

[0081] Step 105: When the signature carried by the first public key indicates that the second computing entity has passed the verification, the first public key is sent to the first computing entity.

[0082] Based on this, when the signature carried by the first public key represents that the second computing entity has passed verification, cross-domain identity authentication between the computing entities between the first domain and the second domain is completed. Thus, the first computing entity can transmit target data to the second computing entity based on the first public key sent by the first server.

[0083] When the signature carried by the first public key ensures that the second computing entity fails the verification, a message indicating that the second computing entity fails the verification is sent to the first computing entity, so that the first computing entity will not transmit the target data to the second computing entity.

[0084] Specifically, the first server can send a notification message containing a first public key to the first computing entity through a connector connected to the first computing entity. The first computing entity can obtain the first public key in the notification message, and then search for the corresponding first private key in the local storage area based on the first public key, and then use the first private key to encrypt the target data to be transmitted. After the first computing entity transmits the target data encrypted by the first private key to the second computing entity through the first server, the second computing entity can use the first public key to decrypt the target data.

[0085] It can be seen from the above scheme that in a cross-domain identity authentication method in a secure multi-party computing provided in Example 1 of the present application, the computing entities in each domain generate public keys and private keys for entities in other domains, thereby realizing secure multi-party computing between multiple domains. When entities between different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to verify the signature sent by the entity in the other domain using the private key, thereby realizing cross-domain identity authentication and avoiding the problem of privacy data leakage caused by secure multi-party computing in the same domain.

[0086] In one implementation, after generating the verification request, the first computing entity adds a request signature to the verification request before sending the verification request to the first server. Thus, the verification request received by the first server carries the request signature.

[0087] Based on this, after step 101, that is, after the first server receives the verification request sent by the first computing entity in the first domain, the following steps may also be included: Figure 3 As shown in:

[0088] Step 106: Verify the request signature carried in the verification request.

[0089] Among them, the request signature is obtained by the first computing entity using the third private key to sign the verification request, and the third private key is the secret key generated by the first computing entity for the entity in the first domain. That is to say, the public key and private key generated by the computing entity in each domain for the entity in the domain are different from the public key and private key generated for the entity in other domains. Based on this, the first server uses the third public key to verify the request signature carried in the verification request, and the third public key here is the secret key generated by the first computing entity for the entity in the first domain, such as the first server; or, the third public key is the trust root of the first domain, and the trust root is the basis for the common trust of each entity in the first domain. Based on this trust root, each entity in the first domain can use the trust root to generate a secret key, that is, the trust root is also used to generate the third private key. As a result, the first server obtains the verification result of the request signature of the verification request.

[0090] Based on this, if the verification request is verified successfully, step 102 is executed, that is, a public key query request is sent to the second server in the second domain according to the verification request. If the verification request is verified unsuccessful, the current process is terminated and no public key query request is sent to the second server.

[0091] In one implementation, after step 105, the method in this embodiment may further include the following steps: Figure 4 As shown in:

[0092] Step 107: Receive target data transmitted by the first computing entity.

[0093] The target data is data obtained by encrypting the first computing entity using the first private key corresponding to the first public key.

[0094] Step 108: Transmit the target data to the second computing entity.

[0095] Specifically, the first server can transmit the target data to the second server in the second domain, and the second server sends the target data to the second computing entity in the second domain. Thus, the second computing entity can use the first public key to decrypt the target data, thereby realizing the secure transmission of private data.

[0096] Furthermore, after step 108, that is, after the first server transmits the target data to the second computing entity, it also sends a feedback message to the first computing entity, which at least indicates that the processing of the target data is complete. Specifically, the first server sends the feedback message to the first computing entity via a connector connected to the first computing entity.

[0097] refer to Figure 5 , is a flow chart for implementing a cross-domain authentication method in a secure multi-party computation provided in the second embodiment of the present application. This method can be applied to a second server in a second domain, such as a domain trust server in a domain opposite to the current domain. For example, Figure 2 As shown in , the method in this embodiment is applicable to the domain trust server in domain 2. The technical solution in this embodiment is mainly used to implement identity authentication between the current domain and the other domain, so as to facilitate data between different domains.

[0098] Specifically, the method in this embodiment may include the following steps:

[0099] Step 501: Receive a public key query request sent by a first server in a first domain.

[0100] The public key query request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity, indicating that the first server requires the second server in the second domain to return the public key generated by the first computing entity for the entity in the second domain.

[0101] Step 502: Obtain a first public key according to the public key query request.

[0102] The first public key is a secret key generated in advance by the first computing entity for the entity in the second domain.

[0103] Specifically, the second server can retrieve target information that matches both the domain identifier of the first computing entity and the domain identifier of the second computing entity from the private key information stored on the blockchain based on the public key query request. The target information represents the public key generated by the first computing entity for the second computing entity. Based on this, the first public key is obtained according to the target information. For example, the public key information is extracted from the target information to obtain the first public key generated by the first computing entity for the entity in the second domain.

[0104] Step 503: Use the second private key to sign the first public key to obtain the first public key carrying the signature.

[0105] The second private key is a secret key generated in advance by the second server for the entity in the first domain.

[0106] Specifically, the second server may use the second private key to encrypt the first private key, and add the encrypted information as a signature to the first public key, thereby obtaining the first public key carrying the signature.

[0107] Step 504: Send the first public key carrying the signature to the first server.

[0108] The signature carried by the first public key is used to verify the second computing entity in the second domain.

[0109] Specifically, the first server uses the second public key to verify the signature carried by the first public key. If the first public key verification succeeds, it indicates that the second computing entity has passed the verification. If the second computing entity passes the verification, the first server sends the first public key to the first computing entity via a connector connected to the first computing entity. The first computing entity then uses the first private key corresponding to the first public key to encrypt the target data, thereby transmitting the encrypted target data to the second computing entity via the first server.

[0110] It can be seen from the above scheme that in a cross-domain identity authentication method in a secure multi-party computing provided in Example 2 of the present application, the computing entities in each domain generate public keys and private keys for entities in other domains, thereby realizing secure multi-party computing between multiple domains. When entities between different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to verify the signature sent by the entity in the other domain using the private key, thereby realizing cross-domain identity authentication and avoiding the problem of privacy data leakage caused by secure multi-party computing in the same domain.

[0111] refer to Figure 6 , is a structural diagram of a server provided in Example 3 of the present application, which serves as the first server in the first domain, such as the gateway server in the current domain. For example, Figure 2 The gateway server in domain 1 shown in FIG. The technical solution in this embodiment is mainly used to implement identity authentication between the current domain and the other domain, so as to facilitate data interaction between different domains.

[0112] Specifically, the first server in this embodiment may include the following structure:

[0113] Memory 601, used to store computer programs and data generated by the execution of the computer programs;

[0114] Processor 602 is used to execute a computer program to implement: receiving a verification request sent by a first computing entity in a first domain, the verification request is used to instruct identity authentication of a second computing entity in a second domain; sending a public key query request to a second server in the second domain according to the verification request; receiving a first public key carrying a signature sent by the second server, the first public key being a secret key pre-generated by the first computing entity for an entity in the second domain; using the second public key to verify the signature carried by the first public key; the second public key being a secret key pre-generated by the second server for an entity in the first domain; and sending the first public key to the first computing entity when the signature carried by the first public key indicates that the second computing entity has passed the verification.

[0115] In addition, the first server in this embodiment may further include a communication module and other structures for implementing interaction with the first computing entity and the second server. For example, the processor 602 triggers the communication module to receive a verification request sent by the first computing entity in the first domain, sends a public key query request to the second server in the second domain, receives the first public key with a signature sent by the second server, and sends the first public key to the first computing entity when the signature carried by the first public key indicates that the second computing entity has passed verification, etc.

[0116] It can be seen from the above scheme that in a server provided in Example 3 of the present application, the computing entities in each domain generate public keys and private keys for entities in other domains, thereby realizing secure multi-party computing between multiple domains. When entities between different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to verify the signature sent by the entity in the other domain using the private key, thereby realizing cross-domain identity authentication and avoiding the problem of privacy data leakage caused by secure multi-party computing in the same domain.

[0117] In one implementation, the verification request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity, the domain identifier of the first computing entity is used to represent that the first computing entity is in the first domain and uniquely represents the first computing entity in the first domain, and the domain identifier of the second computing entity is used to represent that the second computing entity is in the second domain and uniquely represents the second computing entity in the second domain; wherein, the public key query request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity.

[0118] In one implementation, the verification request carries at least a request signature. After receiving the verification request sent by the first computing entity in the first domain through the communication module, the processor 602 can also verify the request signature carried in the verification request; if the verification request is verified successfully, a public key query request is sent to the second server in the second domain through the communication module according to the verification request; if the verification request fails to be verified, the current process is terminated.

[0119] In one implementation, the request signature is obtained by the first computing entity using a third private key to sign the verification request, and the third private key is a secret key generated by the first computing entity for an entity within the first domain; when the processor 602 verifies the request signature carried in the verification request, it is specifically used to: use the third public key to verify the request signature carried in the verification request; wherein the third public key is the secret key generated by the first computing entity for the first server; or, the third public key is the trust root of the first domain, and the trust root is used to generate the third private key.

[0120] In one implementation, the processor 602 is further configured to: receive target data transmitted by the first computing entity through the communication module; and transmit the target data to the second computing entity through the communication module.

[0121] In one implementation, after transmitting the target data to the second computing entity, the processor 602 is further configured to: send a feedback message to the first computing entity through the communication module, where the feedback message at least indicates that the processing of the target data is completed.

[0122] It should be noted that the specific implementation of the processor in this embodiment can refer to the corresponding content in the previous text and will not be described in detail here.

[0123] Correspondingly, an embodiment of the present application further provides a cross-domain identity authentication device in secure multi-party computing, which is applied to a first server in a first domain, and includes:

[0124] a request receiving unit, configured to receive a verification request sent by a first computing entity in a first domain, the verification request being used to instruct identity authentication for a second computing entity in a second domain;

[0125] a request sending unit, configured to send a public key query request to a second server in the second domain according to the verification request;

[0126] a public key receiving unit, configured to receive a first public key carrying a signature sent by the second server, where the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain;

[0127] a signature verification unit, configured to verify the signature carried by the first public key using a second public key; the second public key being a secret key pre-generated by the second server for an entity within the first domain;

[0128] The public key sending unit is configured to send the first public key to the first computing entity when the signature carried by the first public key indicates that the second computing entity has verified the signature.

[0129] refer to Figure 7 , is a structural diagram of a server provided in the fourth embodiment of the present application, which serves as a second server in a second domain, such as a domain trust server in a domain opposite to the current domain. For example, Figure 2 The domain trust server in domain 2 shown in . The technical solution in this embodiment is mainly used to implement identity authentication between the current domain and the other domain, so as to facilitate data interaction between different domains.

[0130] Specifically, the server in this embodiment may include the following structure:

[0131] Memory 701, used to store computer programs and data generated by the execution of the computer programs;

[0132] Processor 702 is used to execute a computer program to implement: receiving a public key query request sent by a first server in a first domain; obtaining a first public key according to the public key query request; the first public key is a secret key pre-generated by a first computing entity for an entity in a second domain; signing the first public key with a second private key to obtain a first public key carrying the signature, where the second private key is a secret key pre-generated by a second server for the entity in the first domain; sending the first public key carrying the signature to the first server, where the signature carried by the first public key is used to verify the second computing entity in the second domain.

[0133] In addition, the second server in this embodiment may further include a communication module and other structures to implement interaction with the second computing entity and the first server. For example, the processor 702 triggers the communication module to receive a public key query request sent by the first server in the first domain and send the first public key carrying the signature to the first server.

[0134] It can be seen from the above scheme that in a server provided in Example 4 of the present application, the computing entities in each domain generate public keys and private keys for entities in other domains, thereby realizing secure multi-party computing between multiple domains. When entities between different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to verify the signature sent by the entity in the other domain using the private key, thereby realizing cross-domain identity authentication and avoiding the problem of privacy data leakage caused by secure multi-party computing in the same domain.

[0135] Correspondingly, an embodiment of the present application further provides a cross-domain identity authentication device in secure multi-party computing, which is applied to a second server in a second domain, and includes:

[0136] a request receiving unit, configured to receive a public key query request sent by a first server in a first domain;

[0137] A public key obtaining unit, configured to obtain a first public key according to a public key query request; the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain;

[0138] a public key signing unit, configured to sign the first public key using the second private key to obtain the first public key carrying the signature, where the second private key is a secret key pre-generated by the second server for the entity in the first domain;

[0139] The public key sending unit is used to send the first public key carrying the signature to the first server, where the signature carried by the first public key is used to verify the second computing entity in the second domain.

[0140] Take the computing entities in the first domain and the second domain, such as domain 1 and domain 2, participating in secure multi-party computing as an example. Figure 8 The following is a schematic diagram of the interaction between cross-domain authentication and data transmission for this application:

[0141] 1. After the first computing entity is assigned to the computing group by the coordination server, the first computing entity can obtain the entity identifiers of other computing entities, such as the second computing entity, sent by the coordination server. Based on this, the first computing entity sends an identifier query request to the smart chain code configured in the first computing entity. The identifier query request includes the entity identifier of the second computing entity. The entity identifier of the second computing entity is used to uniquely identify the second computing entity in the second domain.

[0142] 2. The smart chaincode in the first computing entity sends an identity query request to the domain trust server in domain 1;

[0143] 3. The domain trust server in domain 1 searches the domain identifier list stored on the blockchain for the domain identifier corresponding to the entity identifier of the second computing entity to obtain the domain identifier of the second computing entity, and returns the domain identifier of the second computing entity to the smart chain code in the first computing entity;

[0144] 4. The smart chain code in the first computing entity generates a verification request based on the domain identifier of the second computing entity and the domain identifier of the first computing entity. The verification request includes at least the domain identifier of the second computing entity and the domain identifier of the first computing entity. The smart chain code in the first computing entity signs the verification request using a third private key and sends the verification request carrying the signature to the gateway server in domain 1. The third private key is a private key issued by the first computing entity for entities in domain 1 using the trust root of domain 1, and has a corresponding third public key.

[0145] 5. The gateway server in domain 1 uses the third public key to verify the signature carried in the verification request;

[0146] 6. If the verification request passes, the gateway server in domain 1 obtains the domain identifier of the second computing entity and the domain identifier of the first computing entity included in the verification request, and sends a public key query request to the domain trust server in domain 2 based on the domain identifier of the second computing entity and the domain identifier of the first computing entity. The public key query request includes the domain identifier of the second computing entity and the domain identifier of the first computing entity.

[0147] 7. After receiving the public key query request, the domain trust server of domain 2 searches the private key information stored on the blockchain for a public key that matches both the domain identifier of the second computing entity and the domain identifier of the first computing entity, thereby obtaining the first public key generated by the first computing entity for the second computing entity. The domain trust server of domain 2 signs the first public key using the second private key and sends the signed first public key to the gateway server in domain 1.

[0148] 8. The gateway server in domain 1 uses the second public key sent in advance by the domain trust server in domain 2 to verify the signature carried by the first public key;

[0149] 9. When the signature carried by the first public key is verified successfully, the gateway server in domain 1 sends a notification message containing the first public key to the connector connected to the first computing entity;

[0150] 10. After receiving the notification message, the connector corresponding to the first computing entity sends the first public key to the first computing entity;

[0151] 11. The first computing entity uses the first public key to search for the corresponding first private key in the local storage area, encrypts the private data using the found first private key, and sends the encrypted private data to the connector corresponding to the first computing entity;

[0152] 12. The connector corresponding to the first computing entity sends the encrypted private data to the second computing entity in domain 2 through the gateway server of domain 1 and the gateway server of domain 2 or the domain trust server according to the domain identifier of the second computing entity;

[0153] 13. After the gateway server in domain 1 completes the transmission of private data for the first computing entity, it sends a feedback message to the smart chain code of the first computing entity to indicate that the current data processing is completed.

[0154] Specifically, such as Figure 9 As shown in the figure, each domain contains the basic modules for running Secure Multi-Party Computation (SMPC), enabling the invocation of complete SMPC computing tasks. These modules include: Certificate Authority (CA), Coordinator (also called coordinator), Peer Computing Node, Membership Service, and other modules. The blockchain stores the public keys generated by entities in each domain for other domains using their own root of trust, as well as the domain identifiers of entities in each domain.

[0155] like Figure 10 The following is a diagram of the SMPC deployment architecture. SMPC includes at least the following modules:

[0156] The data provider module provides the data required for processing computing tasks through the data preprocessor;

[0157] The coordination module, as a coordinator, provides resource management services, task scheduling services, and pre-processing evaluation services. For example, it creates a computing group based on computing tasks, which includes computing nodes (i.e., computing entities) from multiple domains.

[0158] The chain code module, as an algorithm provider, is used to provide the algorithm content used by the computing task, including logical operators and arithmetic operators;

[0159] The data processing module, as a computing power provider, includes multiple computing nodes. The computing nodes provide computing resources and storage resources. Each computing node has its own private storage area, namely the local storage area, for storing information such as private keys. The data processing module and the coordination module communicate through the P2P network protocol.

[0160] The blockchain account book stores the public key certificates corresponding to each computing node, so that the computing node can query and obtain the corresponding public key;

[0161] Anonymous identity module, used to register domain identities for computing nodes;

[0162] like Figure 11 Figure 1 shows the data flow diagram for cross-domain authentication and data transfer between entities in different domains. ID owners include, but are not limited to, clients, peers, and other computing entities requiring identity. The coordinator generates a computing group based on the job. This group is composed of computing entities from different domains, including clients and peers. The ID owner generates a public-private key pair for the trust domain with which communication is required. The public key is sent to the CA or Key Generation Center (KGC) of all interacting trust domains. A public key certificate is generated and then, through the blockchain consensus protocol, the public key certificate corresponding to the ID is added to the block as a publicly verifiable parameter across the entire network. During the actual execution of the computing job, all entities need to verify their identity. The public key information corresponding to the ID is retrieved through a smart contract in the blockchain for authentication. Because each ID owner generates a unique public-private key pair for all domains, this completely avoids cross-domain authentication, making SMPC computing jobs fully decentralized.

[0163] The details are as follows:

[0164] 1. The ID owner sends an identity query request to the smart chain code, which contains the entity identifier of the entity in domain 2;

[0165] 2. Smart chain code sends an identity query request to the Domain trust service in Domain 1;

[0166] 3. The Domain Trust Service in Domain 1 queries the domain identifier of the entity in Domain 2 in the domain identifier list stored on the blockchain, and returns the domain identifier of the entity in Domain 2 to the Smart Chain Code;

[0167] 4. Smart chain code generates a verification request according to the domain identifier of the ID owner and the domain identifier in domain 2. Smart chain code signs the verification request with the third private key and sends the verification request carrying the signature to the Domain gateway in domain 1. The third private key is the private key issued by the ID owner for the entity in domain 1 using the trust root of domain 1, and there is a corresponding third public key.

[0168] 5. The domain gateway in domain 1 uses the third public key to verify the signature carried in the verification request;

[0169] 6. If the verification request passes, the Domain Gateway in Domain 1 obtains the domain identifier of the entity in Domain 2 and the domain identifier of the ID owner contained in the verification request. Based on the domain identifier of the ID owner and the domain identifier of the entity in Domain 2, the Domain Gateway sends a public key query request to the Domain Trust Service in Domain 2. The public key query request includes the domain identifier of the entity in Domain 2 and the domain identifier of the ID owner.

[0170] 7. After receiving the public key query request, the Domain Trust Service in Domain 2 searches the private key information stored on the blockchain for a public key that matches both the domain identifier of the entity in Domain 2 and the domain identifier of the ID owner, obtaining the first public key generated by the ID owner for the entity in Domain 2. The Domain Trust Service in Domain 2 signs the first public key using the second private key and sends the signed first public key to the Domain Gateway in Domain 1.

[0171] 8. The Domain Gateway in Domain 1 verifies the signature of the first public key using the second public key sent in advance by the Domain Trust Service in Domain 2.

[0172] 9. When the signature carried by the first public key is verified successfully, the Domain Gateway in Domain 1 sends a notification message containing the first public key to the Ledger connector connected to the ID owner.

[0173] 10. After receiving the notification message, the Ledger connector sends the first public key to the ID owner;

[0174] 11. The ID owner uses the first public key to search for the corresponding first private key in the local storage area, encrypts the private data using the found first private key, and sends the encrypted private data to the Ledger connector;

[0175] 12. The Ledger connector sends the encrypted private data to the entity in Domain 2 through the Domain Gateway of Domain 1 and the Domain Gateway of Domain 2 or the Domain Trust Service according to the domain identifier of the entity in Domain 2;

[0176] 13. After the Domain Gateway in Domain 1 completes the transmission of private data for the ID owner, it sends a feedback message to the ID owner's Smart Chain Code to indicate that the current data processing is completed.

[0177] Thus, in implementing secure multi-party computing, cross-domain authentication and data transmission are achieved between different domains.

[0178] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0179] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0180] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0181] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A cross-domain identity authentication method in secure multi-party computing, applied to a first server in a first domain, the method comprising: receiving a verification request sent by a first computing entity in the first domain, wherein the verification request is used to instruct identity authentication of a second computing entity in the second domain; Sending a public key query request to a second server in the second domain according to the verification request; receiving a first public key carrying a signature sent by the second server, where the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain; Verifying the signature carried by the first public key using a second public key; the second public key is a secret key pre-generated by the second server for an entity within the first domain; In a case where the signature carried by the first public key indicates that the second computing entity has passed verification, the first public key is sent to the first computing entity.

2. The method according to claim 1, wherein the verification request carries at least a request signature; in, After receiving the verification request sent by the first computing entity in the first domain, the method further includes: Verifying the request signature carried in the verification request; If the verification request passes, sending a public key query request to the second server in the second domain according to the verification request; If the verification request fails, the current process ends.

3. The method according to claim 2, wherein the request signature is obtained by the first computing entity signing the verification request using a third private key, and the third private key is a secret key generated by the first computing entity for an entity within the first domain; in, Verifying the request signature carried in the verification request includes: Verifying the request signature carried in the verification request using the third public key; The third public key is a secret key generated by the first computing entity for the first server; or the third public key is a trust root of the first domain, and the trust root is used to generate the third private key.

4. The method according to claim 1, 2 or 3, further comprising: receiving target data transmitted by the first computing entity; The target data is transmitted to the second computing entity.

5. The method according to claim 4, further comprising, after transmitting the target data to the second computing entity: A feedback message is sent to the first computing entity, where the feedback message at least indicates that the processing of the target data is completed.

6. The method according to claim 1, 2 or 3, wherein the verification request includes at least a domain identifier of the first computing entity and a domain identifier of the second computing entity, the domain identifier of the first computing entity being used to indicate that the first computing entity is in the first domain and uniquely identifies the first computing entity in the first domain, and the domain identifier of the second computing entity being used to indicate that the second computing entity is in the second domain and uniquely identifies the second computing entity in the second domain; in, The public key query request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity.

7. A cross-domain identity authentication method in secure multi-party computing, applied to a second server in a second domain, the method comprising: receiving a public key query request sent by a first server in a first domain; Obtaining a first public key according to the public key query request; The first public key is a secret key pre-generated by a first computing entity in the first domain for an entity in the second domain; Signing the first public key using a second private key to obtain a first public key carrying the signature, where the second private key is a key pre-generated by the second server for an entity in the first domain; A first public key carrying a signature is sent to the first server, where the signature carried by the first public key is used to verify the second computing entity in the second domain.

8. The method according to claim 7, wherein the public key query request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity; in, Obtaining a first public key according to the public key query request includes: Retrieving target information that matches both the domain identifier of the first computing entity and the domain identifier of the second computing entity from the key information stored on the blockchain, the target information representing a public key generated by the first computing entity for the second computing entity; The first public key is obtained according to the target information.

9. A server, serving as a first server in a first domain, comprising: A memory for storing computer programs and data generated by the execution of the computer programs; A processor, configured to execute the computer program to implement: receiving a verification request sent by a first computing entity in the first domain, the verification request being used to instruct identity authentication of a second computing entity in the second domain; and sending a public key query request to a second server in the second domain based on the verification request; receiving a first public key carrying a signature sent by the second server, where the first public key is a secret key pre-generated by the first computing entity for an entity in the second domain; Verifying the signature carried by the first public key using a second public key; the second public key is a secret key pre-generated by the second server for an entity within the first domain; In a case where the signature carried by the first public key indicates that the second computing entity has passed verification, the first public key is sent to the first computing entity.

10. A server, serving as a second server in a second domain, comprising: A memory for storing computer programs and data generated by the execution of the computer programs; A processor is configured to execute the computer program to implement: receiving a public key query request sent by a first server in a first domain; obtaining a first public key according to the public key query request; The first public key is a secret key pre-generated by a first computing entity in the first domain for an entity in the second domain; Signing the first public key using a second private key to obtain a first public key carrying the signature, where the second private key is a key pre-generated by the second server for an entity in the first domain; A first public key carrying a signature is sent to the first server, where the signature carried by the first public key is used to verify the second computing entity in the second domain.

Images