WO2023116027A1 - 安全多方计算中的跨域身份验证方法及服务器 - Google Patents

安全多方计算中的跨域身份验证方法及服务器 Download PDF

Info

Publication number
WO2023116027A1
WO2023116027A1 PCT/CN2022/115785 CN2022115785W WO2023116027A1 WO 2023116027 A1 WO2023116027 A1 WO 2023116027A1 CN 2022115785 W CN2022115785 W CN 2022115785W WO 2023116027 A1 WO2023116027 A1 WO 2023116027A1
Authority
WO
WIPO (PCT)
Prior art keywords
domain
public key
computing entity
server
entity
Prior art date
Application number
PCT/CN2022/115785
Other languages
English (en)
French (fr)
Inventor
王云浩
郭青霄
Original Assignee
联想(北京)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 联想(北京)有限公司 filed Critical 联想(北京)有限公司
Publication of WO2023116027A1 publication Critical patent/WO2023116027A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the present application relates to the technical field of secure multi-party computing, in particular to a cross-domain authentication method and server in secure multi-party computing.
  • the distributed computing scheme based on the public key infrastructure PKI Public Key Infrastructure
  • PKI Public Key Infrastructure
  • the computing entities organized by the coordinator are all entities in the same domain, and the transmission of private data is realized through the public key and private key generated by the same root of trust.
  • the same root of trust is used to issue public and private keys in the same domain, and there may be a security problem of using the root of trust to decrypt data, resulting in leakage of private data.
  • this application provides a cross-domain authentication method and server in secure multi-party computing, as follows:
  • Verifying the signature carried by the first public key using a second public key is a secret key previously generated by the second server for entities in the first domain;
  • the first public key is sent to the first computing entity.
  • the verification request carries at least a request signature
  • the method further includes:
  • the verification request passes the verification, perform the step of: sending a public key query request to a second server in the second domain according to the verification request;
  • 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 obtained by the first computing entity being in the first domain The secret key generated by the entity;
  • verifying the request signature carried in the verification request includes:
  • 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 for generating the third private key.
  • the method also includes:
  • the target data is transmitted to the second computing entity.
  • the method further includes:
  • the verification request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity, and the domain identifier of the first computing entity is used to represent the domain identifier of the first computing entity.
  • the entity is in the first domain and uniquely characterizes 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 in the uniquely characterizing the second computing entity in the second domain;
  • 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.
  • the first public key is a secret key previously generated by the first computing entity for entities in the second domain;
  • the second private key is a secret key previously generated by the second server for entities in the first domain ;
  • 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;
  • obtaining the first public key includes:
  • the target information From the secret key information stored on the block chain, retrieve target information that matches both the domain identifier of the first computing entity and the domain identifier of the second computing entity, the target information characterizes the first computing entity an entity generating a public key for said second computing entity;
  • a request receiving unit configured to receive a verification request sent by the first computing entity in the first domain, where the verification request is used to indicate identity verification for a second computing entity in the second domain;
  • 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
  • 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 previously generated by the first computing entity for entities in the second domain;
  • a signature verification unit configured to use a second public key to verify the signature carried by the first public key;
  • the second public key is a secret key previously generated by the second server for entities in the first domain;
  • a public key sending unit 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 the verification.
  • a request receiving unit configured to receive a public key query request sent by the first server in the first domain
  • 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 previously generated by the first computing entity for entities in the second domain;
  • a public key signing unit configured to use a second private key to sign the first public key to obtain a first public key carrying a signature, the second private key is provided for the first public key by the second server in advance Keys generated by entities within the domain;
  • a public key sending unit configured to send 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.
  • a server, as the first server in the first domain, the server includes:
  • a processor configured to execute the computer program, so as to: receive a verification request sent by the first computing entity in the first domain, where the verification request is used to indicate identity verification for a second computing entity in the second domain; According to the verification request, send a public key query request to the second server in the second domain; receive the first public key carrying the signature sent by the second server, the first public key is the first public key for the first computer A secret key generated by the entity in advance for the entity in the second domain; using the second public key to verify the signature carried by the first public key; A secret key generated by an entity in a domain; 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.
  • a server as a second server in a second domain, the server includes:
  • a processor configured to execute the computer program to realize: receiving a public key query request sent by a first server in the first domain; obtaining a first public key according to the public key query request; the first public key A secret key pre-generated for the first computing entity for entities in the second domain; using a second private key to sign the first public key to obtain a first public key carrying a signature, and the second
  • the private key is a secret key previously generated by the second server for entities in the first domain; the first public key carrying the signature is sent to the first server, and the signature carried by the first public key is used for verification A second computing entity within the second domain.
  • the computing entities in each domain generate public keys and private keys for entities in other domains, thereby , when secure multi-party computing is implemented between multiple domains and entities in different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to use the private key for the entity in the other domain The sent signature is verified, thereby realizing cross-domain authentication and avoiding the problem of privacy data leakage caused by secure multi-party computation in the same domain.
  • FIG. 1 is a flow chart of a cross-domain authentication method in secure multi-party computing provided by Embodiment 1 of the present application;
  • Fig. 2 is an example diagram of interaction between different domains implementing secure multi-party computation
  • FIG. 3 and FIG. 4 are respectively another flow chart of a cross-domain authentication method in secure multi-party computing provided in Embodiment 1 of the present application;
  • FIG. 5 is a flow chart of a cross-domain authentication method in secure multi-party computing provided in Embodiment 2 of the present application;
  • FIG. 6 is a schematic structural diagram of a server provided in Embodiment 3 of the present application.
  • FIG. 7 is a schematic structural diagram of a server provided in Embodiment 4 of the present application.
  • FIG. 8 is a schematic diagram of the interaction of the application for cross-domain identity verification and data transmission
  • Figure 10 is a deployment architecture diagram of SMPC
  • FIG. 11 is a data flow diagram of this application applicable to cross-domain identity verification and data transmission between entities in different domains.
  • FIG. 1 it is a flow chart of implementing a cross-domain authentication method in secure multi-party computing provided by Embodiment 1 of the present application.
  • This method can be applied to the first server in the first domain, such as the gateway in the current domain. server.
  • the first server in the first domain such as the gateway in the current domain. server.
  • multiple computing entities that implement secure multi-party computing come from multiple domains, and the computing entities here may be entities such as peers and clients.
  • the method in this embodiment is applicable to the gateway server in domain 1.
  • the technical solution in this embodiment is mainly used to implement identity verification between the current domain and the opposite domain, so as to realize data interaction between different domains.
  • the method in this embodiment may include the following steps:
  • Step 101 Receive a verification request sent by a first computing entity in a first domain.
  • the verification request is used to indicate to perform identity verification on the second computing entity in the second domain, so as to send the target data to the second computing entity.
  • 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 the Target data, as shown in FIG. 2 , 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 .
  • the domain identifier of the first computing entity is used to indicate that the first computing entity is in the first domain and uniquely represents the first computing entity in the first domain
  • the domain identifier of the second computing entity is used to indicate that the second computing entity is in the first domain.
  • the second computational entity is uniquely represented in the second domain and within 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.
  • 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 stored in the local storage area respectively.
  • the first computing entity After the first computing entity is divided into a computing group that implements secure multi-party computing by the coordinating server, it receives the entity identifiers of other computing entities in the computing group sent by the coordinating server.
  • the entity identifiers of the computing entities uniquely represent the computing entity in the domain where the computing entity is located.
  • a computing entity can also be understood as a local identity.
  • the domain ID of the first computing entity in the verification request is read by the first computing entity from its local storage area
  • the domain ID of the second computing entity in the verification request is read by the first computing entity based on the second computing entity's
  • the entity ID of is queried from the list of domain IDs stored on the blockchain.
  • the first computing entity can send an ID query request to the domain trust server in the first domain through the smart chain code configured in the first computing entity, which contains the entity ID of the second computing entity, thus, the domain in the first domain
  • the trust server queries the domain identifier corresponding to the entity identifier of the second computing entity in the domain identifier list stored on the blockchain, and then sends it to the first computing entity through the smart chain code in the first computing entity, thus, the second A computing entity can obtain the domain identifier of the second computing entity.
  • the first computing entity generates a verification request based on the domain identifier of the first computing entity and the domain identifier of the second computing entity through its smart chain code, and sends the verification request to The request is sent to the first server in the first domain, the gateway server.
  • Step 102 Send a public key query request to the second server in the second domain according to the verification request.
  • 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, to indicate that the first server needs the second server in the second domain to return the first computing entity as an entity in the second domain The generated public key.
  • the second server in the second domain may be a domain trust server in the domain.
  • the second server in the second domain can search the private key information stored on the blockchain according to the public key query request, and retrieve the target that matches both the domain identifier of the first computing entity and the domain identifier of the second computing entity.
  • the target information represents the public key generated by the first computing entity for the second computing entity.
  • the first public key is obtained according to the target information.
  • the public key information is extracted from the target information to obtain the first computing entity.
  • the entity is the first public key generated by the entity in the second domain.
  • the second server uses the second private key to sign the first public key to obtain the first public key with the signature and the first public key with the signature The key is sent to the first server of the first domain.
  • Step 103 Receive the first public key carrying the signature sent by the second server.
  • Step 104 Use the second public key to verify the signature carried by the first public key.
  • the second public key is a secret key previously generated by the second server for entities in the first domain.
  • the second public key may be pre-stored in the local storage area of the first server, and sent directly to the first server by the second server, so as to establish a trust relationship with the first server.
  • 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 represents the first public key verification If the verification is passed, the second computing entity passes the verification. 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 fails the verification.
  • Step 105 When the signature carried by the first public key indicates that the second computing entity has passed the verification, send the first public key to the first computing entity.
  • the signature carried by the first public key indicates that the second computing entity has passed the verification
  • the cross-domain authentication between the computing entities between the first domain and the second domain is completed, thus, the first computing entity
  • the target data may be transmitted to the second computing entity according to the first public key sent by the first server.
  • Entity transfer object data In the case that the signature carried by the first public key guarantees that the second computing entity fails to pass the verification, send a message that the second computing entity fails to pass the verification to the first computing entity. Entity transfer object data.
  • the first server may send a notification message containing the first public key to the first computing entity through a connector connected to the first computing entity, and the first computing entity may obtain the first public key in the notification message, and then based on The first public key searches for the corresponding first private key in the local storage area, and then uses the first private key to encrypt the target data to be transmitted, and the first computing entity passes the target data encrypted by the first private key through the second After a server transmits to the second computing entity, the second computing entity can use the first public key to decrypt the target data.
  • the computing entities in each domain generate public keys and private keys for entities in other domains, thus, in When secure multi-party computing is implemented between multiple domains and entities in different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to send the private key to the entity in the other domain. The signature is verified, thereby realizing cross-domain authentication and avoiding the problem of privacy data leakage caused by secure multi-party computation in the same domain.
  • the first computing entity after generating the verification request, the first computing entity first adds a request signature to the verification request before sending the verification request to the first server.
  • the verification request received by the first server carries the request signature.
  • step 101 that is, after the first server receives the verification request sent by the first computing entity in the first domain, it may further include the following steps, as shown in FIG. 3:
  • Step 106 Verify the request signature carried in the verification request.
  • the request signature is obtained by the first computing entity signing the verification request with a third private key
  • the third private key is a secret key generated by the first computing entity for entities in the first domain. That is to say, the public key and private key generated by computing entities in each domain for entities in this domain are different from the public keys and private keys generated for entities in other domains.
  • the first server uses the third public key to verify the request signature carried in the verification request, where the third public key is a secret key generated by the first computing entity for an 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 mutual trust of each entity in the first domain.
  • each entity in the first domain can use the trust root to generate a secret key, that is, The root of trust is also used to generate a third private key.
  • the verification result of verifying the request signature of the verification request is obtained on the first server.
  • step 102 that is, send a public key query request to the second server in the second domain according to the verification request, and end the current process when the verification request fails the verification,
  • the public key query request is no longer sent to the second server.
  • the method in this embodiment may further include the following steps, as shown in FIG. 4:
  • Step 107 Receive the target data transmitted by the first computing entity.
  • the target data is data encrypted by the first computing entity using the first private key corresponding to the first public key.
  • Step 108 Transmit the target data to the second computing entity.
  • 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, so that the second computing entity can use the first
  • the public key decrypts the target data, thereby realizing the secure transmission of private data.
  • step 108 that is, after the first server transmits the target data to the second computing entity, it will also send a feedback message to the first computing entity, and the feedback message at least indicates that the processing of the target data is completed.
  • the first server sends the feedback message to the first computing entity through a connector connected to the first computing entity.
  • FIG. 5 it is a flow chart of implementing a cross-domain authentication method in secure multi-party computing provided in Embodiment 2 of the present application.
  • This method can be applied to the second server in the second domain, such as the opposite party relative to the current domain Domain trust servers in the domain.
  • 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 verification between the current domain and the opposite domain, so as to facilitate the realization of data between different domains.
  • the method in this embodiment may include the following steps:
  • Step 501 Receive a public key query request sent by the first server in the first domain.
  • 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, to indicate that the first server needs the second server in the second domain to return the first computing entity as an entity in the second domain The generated public key.
  • Step 502 Obtain the first public key according to the public key query request.
  • the first public key is a secret key previously generated by the first computing entity for entities in the second domain.
  • 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.
  • the information represents the public key generated by the first computing entity for the second computing entity.
  • the first public key is obtained according to the target information, for example, the public key information is extracted from the target information, so that the first computing entity is the second A first public key generated by an entity within the domain.
  • Step 503 Use the second private key to sign the first public key to obtain the first public key carrying the signature.
  • the second private key is a secret key previously generated by the second server for entities in the first domain.
  • the second server may use the second private key to encrypt the first private key, add the encrypted information as a signature to the first public key, and then obtain the first public key carrying the signature.
  • Step 504 Send the first public key carrying the signature to the first server.
  • the signature carried by the first public key is used to verify the second computing entity in the second domain.
  • the first server uses the second public key to verify the signature carried by the first public key, and if the verification of the first public key passes, it indicates that the verification of the second computing entity passes.
  • the first server sends the first public key to the first computing entity through the connector connected to the first computing entity, and the first computing entity uses the first public key corresponding to the first computing entity.
  • the private key encrypts the target data, so that the encrypted target data is transmitted to the second computing entity through the first server.
  • the computing entities in each domain generate public keys and private keys for entities in other domains, thus, in When secure multi-party computing is implemented between multiple domains and entities in different domains interact across domains, the server in the current domain uses the public key sent by the entity in the other domain to send the private key to the entity in the other domain. The signature is verified, thereby realizing cross-domain authentication and avoiding the problem of privacy data leakage caused by secure multi-party computation in the same domain.
  • FIG. 6 it is a schematic structural diagram of a server provided in Embodiment 3 of the present application.
  • the server serves as the first server in the first domain, such as the gateway server in the current domain.
  • a gateway server in domain 1 as shown in FIG. 2 .
  • the technical solution in this embodiment is mainly used to implement identity verification between the current domain and the opposite domain, so as to realize data interaction between different domains.
  • the first server in this embodiment may include the following structure:
  • Memory 601 used to store computer programs and data generated by running computer programs
  • the processor 602 is configured to execute a computer program, so as to: receive a verification request sent by a first computing entity in the first domain, where the verification request is used to indicate identity verification for a second computing entity in the second domain;
  • the second server in the second domain sends a public key query request; receives the first public key carrying the signature sent by the second server, and the first public key is a secret key previously generated by the first computing entity for entities in the second domain;
  • the second public key verifies the signature carried by the first public key; the second public key is the secret key generated by the second server in advance for entities in the first domain; the signature carried by the first public key indicates that the second computing entity has passed the verification In this case, the first public key is sent to the first computing entity.
  • the first server in this embodiment may also include structures such as a communication module to realize interaction with the first computing entity and the second server.
  • the processor 602 triggers the communication module to receive the verification request sent by the first computing entity in the first domain, send a public key query request to the second server in the second domain, and receive the first public key carrying the signature sent by the second server. And 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, and so on.
  • computing entities in each domain generate public keys and private keys for entities in other domains, thereby realizing secure multi-party computing among multiple 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. Domain authentication to avoid the problem of privacy data leakage caused by secure multi-party computation in the same domain.
  • the verification request includes at least the domain identifier of the first computing entity and the domain identifier of the second computing entity, and the domain identifier of the first computing entity is used to indicate that the first computing entity is in the first domain and is in the The first computing entity is uniquely represented in a 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 characterizes the second computing entity in the second domain; wherein, in the public key query request, at least Contains the domain identifier of the first computing entity and the domain identifier of the second computing entity.
  • the verification request carries at least a request signature
  • the processor 602 may also verify the request signature carried in the verification request after receiving the verification request sent by the first computing entity in the first domain through the communication module; If the verification request passes the verification, according to the verification request, the communication module sends a public key query request to the second server in the second domain; and if the verification request fails the verification, the current process ends.
  • the request signature is obtained by signing the verification request by the first computing entity using a third private key
  • the third private key is a secret key generated by the first computing entity for entities in the first domain
  • the processor 602 When verifying 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 a secret generated by the first computing entity for the first server. key; or, the third public key is the root of trust of the first domain, and the root of trust is used to generate the third private key.
  • the processor 602 is further configured to: receive the 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.
  • the processor 601 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.
  • the embodiment of the present application also provides a cross-domain authentication device in secure multi-party computing, which is applied to the first server in the first domain, and the device includes:
  • a request receiving unit configured to receive a verification request sent by the first computing entity in the first domain, where the verification request is used to indicate identity verification for the second computing entity in the second domain;
  • 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
  • the public key receiving unit is configured to receive the first public key carrying the signature sent by the second server, where the first public key is a secret key previously generated by the first computing entity for entities in the second domain;
  • the signature verification unit is configured to use the second public key to verify the signature carried by the first public key;
  • the second public key is a secret key previously generated by the second server for entities in the first domain;
  • 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 the verification.
  • FIG. 7 it is a schematic structural diagram of a server provided in Embodiment 4 of the present application.
  • the server serves as the second server in the second domain, such as a domain trust server in the opposite domain relative to the current domain.
  • a domain trust server in domain 2 as shown in FIG. 2 .
  • the technical solution in this embodiment is mainly used to implement identity verification between the current domain and the opposite domain, so as to realize data interaction between different domains.
  • the server in this embodiment may include the following structure:
  • Memory 701 used to store computer programs and data generated by running computer programs
  • the processor 702 is configured to execute a computer program to realize: receiving a public key query request sent by a first server in the first domain; obtaining a first public key according to the public key query request; the first public key is the first computing entity A secret key pre-generated for entities in the second domain; use the second private key to sign the first public key to obtain the first public key carrying the signature.
  • the generated secret key; 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.
  • the second server in this embodiment may also include structures such as a communication module to realize interaction with the second computing entity and the first server.
  • the processor 702 receives the public key query request sent by the first server in the first domain by triggering the communication module, and sends the first public key carrying the signature to the first server, and so on.
  • computing entities in each domain generate public keys and private keys for entities in other domains, thereby realizing secure multi-party computing among multiple 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. Domain authentication to avoid the problem of privacy data leakage caused by secure multi-party computation in the same domain.
  • the embodiment of the present application also provides a cross-domain authentication device in secure multi-party computing, which is applied to the second server in the second domain, and the device includes:
  • a request receiving unit configured to receive a public key query request sent by the first server in the first domain
  • 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 previously generated by the first computing entity for entities in the second domain;
  • the public key signature unit is configured to use the second private key to sign the first public key to obtain the first public key carrying the signature, and the second private key is a secret key previously generated by the second server for entities in the first domain;
  • the public key sending unit is configured to send 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.
  • the first computing entity can obtain the entity identifiers of other computing entities such as the second computing entity sent by the coordinating server. Based on this, the first computing entity sends
  • the configured smart chain code sends an identification query request, which contains the entity identification of the second computing entity, and the entity identification of the second computing entity is used to uniquely represent the second computing entity in the second domain;
  • the smart chaincode in the first computing entity sends an identity query request to the domain trust server in domain 1;
  • the domain trust server in domain 1 queries the domain identifier corresponding to the entity identifier of the second computing entity in the domain identifier list stored on the blockchain to obtain the domain identifier of the second computing entity, and sends the second computing entity the domain identification of the entity is returned to the smart chaincode in the first computing entity;
  • the smart chain code in the first computing entity generates a verification request according to the domain identifier of the second computing entity and the domain identifier of the first computing entity, and the verification request includes at least the domain identifier of the second computing entity and the domain identifier of the first computing entity.
  • Domain ID the smart chain code in the first computing entity signs the verification request with the third private key, and sends the signed verification request to the gateway server in domain 1;
  • the third private key is the domain 1 of the first computing entity Entities in the domain use the private key issued by the trust root of domain 1, and correspondingly have the corresponding third public key;
  • the gateway server in domain 1 uses the third public key to verify the signature carried in the verification request;
  • the gateway server in domain 1 obtains the domain ID of the second computing entity and the domain ID of the first computing entity contained in the verification request when the verification request passes the verification, and according to the domain ID of the second computing entity and the domain ID of the first computing entity, The domain identifier of the first computing entity sends a public key query request to the domain trust server in domain 2, and the public key query request includes the domain identifier of the second computing entity and the domain identifier of the first computing entity;
  • the domain trust server of domain 2 After the domain trust server of domain 2 receives the public key query request, it searches the private key information stored on the blockchain for the public key that matches both the domain identifier of the second computing entity and the domain identifier of the first computing entity , to obtain 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 with the second private key, and sends the first public key carrying the signature to domain 1 Gateway server in;
  • the gateway server in domain 1 uses the second public key pre-sent by the domain trust server in domain 2 to verify the signature carried by the first public key;
  • the gateway server in Domain 1 sends a notification message containing the first public key to the connector connected to the first computing entity if the signature carried by the first public key passes the verification;
  • the connector corresponding to the first computing entity After receiving the notification message, the connector corresponding to the first computing entity sends the first public key to the first computing entity;
  • the first computing entity uses the first public key to find the corresponding first private key in the local storage area, uses the found first private key to encrypt the private data, and sends the encrypted private data to the first computing entity
  • 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 or domain trust server of domain 2 according to the domain identifier of the second computing entity ;
  • gateway server in domain 1 After the gateway server in domain 1 finishes transmitting the 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.
  • each domain domain contains basic modules for running Secure Multi-Party Computation SMPC (Secure Multi-Party Computation), which can implement complete SMPC computing task calls.
  • SMPC Secure Multi-Party Computation
  • These include: electronic certification service CA (Certificate Authority), coordination server Coordinator (also called coordinator), Peer computing nodes, membership server (Membership service) and other modules.
  • CA Certificate Authority
  • coordination server Coordinator also called coordinator
  • Peer computing nodes Peer computing nodes
  • Membership server Membership server
  • the blockchain is used to store the public keys generated by entities in each domain using the trust root of their respective domains for other domains and the domain identifiers of entities in each domain.
  • SMPC includes at least the following modules:
  • the data provider module provides the data required for processing computing tasks through the data pre-processor
  • the coordination module as a coordinator, provides processing such as resource management service, task scheduling service, and preprocessing evaluation service, such as creating a computing group according to computing tasks, which contains computing nodes (ie, computing entities) from multiple domains;
  • the chaincode module as an algorithm provider, is used to provide the algorithm content used by the calculation task, including logical operation operators and arithmetic operation operators;
  • the data processing module as a provider of computing power, includes multiple computing nodes, which provide computing resources and storage resources. Each computing node has its own private storage area, that is, a local storage area, for storing information such as private keys;
  • the processing module and the coordination module communicate through the P2P network protocol;
  • the public key certificate corresponding to each computing node is stored in the blockchain ledger, so that the computing node can query and obtain the corresponding public key;
  • Anonymous identity module used to register domain identifiers for computing nodes
  • the ID owner includes but is not limited to client, peer and other computing entities that require identity.
  • the coordinator generates a computing group group according to the work task, that is, extracts computing entities in different domains to form a computing group, so that the group can include entities in different trust domains, including client and peer, and the ID owner generates public-private key pairs for the trust domains that need to communicate.
  • the ID owner sends an ID query request to the Smart chain code, and the ID query request includes the entity ID of the entity in domain 2;
  • the Smart chain code sends an identification query request to the Domain trust service in domain 1;
  • the Domain trust service in domain 1 queries the domain ID of the entity in domain 2 in the domain ID list stored on the blockchain, and returns the domain ID of the entity in domain 2 to the Smart chain code;
  • the Smart chain code generates a verification request according to the domain ID of the ID owner and the domain ID in Domain 2.
  • the Smart chain code signs the verification request with the third private key, and sends the verification request with the signature to the Domain gateway in Domain 1.
  • the third private key is the private key issued by the ID owner as the entity in domain 1 using the trust root of domain 1, and there is a corresponding third public key;
  • the Domain gateway in domain 1 uses the third public key to verify the signature carried in the verification request;
  • the Domain gateway in domain 1 obtains the domain ID of the entity in domain 2 and the domain ID of the ID owner contained in the verification request when the verification request is passed, and uses the domain ID of the ID owner and the entity in domain 2
  • the domain ID of domain 2 sends a public key query request to the Domain trust service in domain 2, and the public key query request includes the domain ID of the entity in domain 2 and the domain ID of the ID owner;
  • the Domain trust service of domain 2 After the Domain trust service of domain 2 receives the public key query request, it searches the private key information stored on the blockchain for the public key correspondence that matches both the domain identifier of the entity in domain 2 and the domain identifier of the ID owner , to obtain the first public key generated by the ID owner for the entity in domain 2; the domain trust service of domain 2 signs the first public key with the second private key, and sends the first public key with the signature to domain 1 Domain gateway;
  • the Domain gateway in Domain 1 uses the second public key pre-sent by the Domain trust service in Domain 2 to verify the signature carried by the first public key;
  • the Domain gateway in domain 1 sends a notification message containing the first public key to the Ledger connector connected to the ID owner when the signature verification carried by the first public key passes;
  • the Ledger connector After the Ledger connector receives the notification message, it sends the first public key to the ID owner;
  • the ID owner uses the first public key to find the corresponding first private key in the local storage area, uses the found first private key to encrypt the private data, and sends the encrypted private data to the Ledger connector;
  • 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 or domain trust service of domain 2 according to the domain identifier of the entity in domain 2;
  • the Domain gateway in domain 1 After the Domain gateway in domain 1 completes the transmission of private data for the ID owner, it sends a feedback message to the Smart chain code of the ID owner to indicate that the current data processing is complete.
  • each embodiment in this specification is described in a progressive manner, each embodiment focuses on the difference from other embodiments, and the same and similar parts of each embodiment can be referred to each other.
  • the description is relatively simple, and for relevant details, please refer to the description of the method part.
  • RAM random access memory
  • ROM read-only memory
  • EEPROM electrically programmable ROM
  • EEPROM electrically erasable programmable ROM
  • registers hard disk, removable disk, CD-ROM, or any other Any other known storage medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种安全多方计算中的跨域身份验证方法及服务器，方法应用于第一域中的第一服务器，方法包括：接收第一域内的第一计算实体发送的验证请求，验证请求用于指示对第二域内的第二计算实体进行身份验证；根据验证请求，向第二域内的第二服务器发送公钥查询请求；接收第二服务器发送的携带签名的第一公钥，第一公钥为第一计算实体预先为第二域内的实体生成的秘钥；使用第二公钥对第一公钥携带的签名进行验证；第二公钥为第二服务器预先为第一域内的实体生成的秘钥；在第一公钥携带的签名表征第二计算实体验证通过的情况下，将第一公钥发送给第一计算实体。

Description

安全多方计算中的跨域身份验证方法及服务器
本申请要求于2021年12月21日提交中国专利局、申请号为CN202111573518.0、发明名称为“安全多方计算中的跨域身份验证方法及服务器”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及安全多方计算技术领域，尤其涉及一种安全多方计算中的跨域身份验证方法及服务器。
背景技术
目前的分布式计算中，通常采用基于公钥基础设施PKI(Public Key Infrastructure)的分布式计算方案。该方案中，协调者所组织的计算实体均为同一个域中的实体，通过同一个信任根所生成的公钥和私钥实现隐私数据的传输。
这种分布式计算方案中，同一个域内使用同一个信任根签发公钥和私钥，可能会存在使用信任根进行解密数据导致隐私数据泄露的安全问题。
发明内容
有鉴于此，本申请提供一种安全多方计算中的跨域身份验证方法及服务器，如下：
一种安全多方计算中的跨域身份验证方法，应用于第一域中的第一服务器，所述方法包括：
接收所述第一域内的第一计算实体发送的验证请求，所述验证请求用于指示对第二域内的第二计算实体进行身份验证；
根据所述验证请求，向所述第二域内的第二服务器发送公钥查询请求；
接收所述第二服务器发送的携带签名的第一公钥，所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；
使用第二公钥对所述第一公钥携带的签名进行验证；所述第二公钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；
在所述第一公钥携带的签名表征所述第二计算实体验证通过的情况下，将所述第一公钥发送给所述第一计算实体。
上述方法，优选的，所述验证请求中至少携带请求签名；
其中，在接收所述第一域内的第一计算实体发送的验证请求之后，所述方法还包括：
对所述验证请求中携带的请求签名进行验证；
在所述验证请求验证通过的情况下，执行所述步骤：根据所述验证请求，向所述第二域内的第二服务器发送公钥查询请求；
在所述验证请求验证不通过的情况下，结束当前流程。
上述方法，优选的，所述请求签名为所述第一计算实体使用第三私钥对所述验证 请求进行签名得到，所述第三私钥为所述第一计算实体为所述第一域内的实体生成的秘钥；
其中，对所述验证请求中携带的请求签名进行验证，包括：
使用第三公钥对所述验证请求中携带的请求签名进行验证；
其中，所述第三公钥为所述第一计算实体为所述第一服务器生成的秘钥；或者，所述第三公钥为所述第一域的信任根，所述信任根用于生成所述第三私钥。
上述方法，优选的，所述方法还包括：
接收所述第一计算实体传输的目标数据；
将所述目标数据传输给所述第二计算实体。
上述方法，优选的，在将所述目标数据传输给所述第二计算实体之后，所述方法还包括：
向所述第一计算实体发送反馈消息，所述反馈消息至少表征所述目标数据处理完成。
上述方法，优选的，所述验证请求中至少包含所述第一计算实体的域标识和所述第二计算实体的域标识，所述第一计算实体的域标识用于表征所述第一计算实体处于所述第一域中且在所述第一域中唯一表征所述第一计算实体，所述第二计算实体的域标识用于表征所述第二计算实体处于第二域中且在所述第二域中唯一表征所述第二计算实体；
其中，所述公钥查询请求中至少包含所述第一计算实体的域标识和所述第二计算实体的域标识。
一种安全多方计算中的跨域身份验证方法，应用于第二域中的第二服务器，所述方法包括：
接收第一域中的第一服务器发送的公钥查询请求；
根据所述公钥查询请求，获得第一公钥；所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；
使用第二私钥对所述第一公钥进行签名，以得到携带签名的第一公钥，所述第二私钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；
将携带签名的第一公钥发送给所述第一服务器，所述第一公钥携带的签名用于验证所述第二域内的第二计算实体。
上述方法，优选的，所述公钥查询请求中至少包含所述第一计算实体的域标识和所述第二计算实体的域标识；
其中，根据所述公钥查询请求，获得第一公钥，包括：
在区块链上存储的秘钥信息中，检索与所述第一计算实体的域标识和所述第二计算实体的域标识均相匹配的目标信息，所述目标信息表征所述第一计算实体为所述第二计算实体生成公钥；
根据所述目标信息，获得所述第一公钥。
一种安全多方计算中的跨域身份验证装置，应用于第一域中的第一服务器，所述 装置包括：
请求接收单元，用于接收所述第一域内的第一计算实体发送的验证请求，所述验证请求用于指示对第二域内的第二计算实体进行身份验证；
请求发送单元，用于根据所述验证请求，向所述第二域内的第二服务器发送公钥查询请求；
公钥接收单元，用于接收所述第二服务器发送的携带签名的第一公钥，所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；
签名验证单元，用于使用第二公钥对所述第一公钥携带的签名进行验证；所述第二公钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；
公钥发送单元，用于在所述第一公钥携带的签名表征所述第二计算实体验证通过的情况下，将所述第一公钥发送给所述第一计算实体。
一种安全多方计算中的跨域身份验证装置，应用于第二域中的第二服务器，所述装置包括：
请求接收单元，用于接收第一域中的第一服务器发送的公钥查询请求；
公钥获得单元，用于根据所述公钥查询请求，获得第一公钥；所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；
公钥签名单元，用于使用第二私钥对所述第一公钥进行签名，以得到携带签名的第一公钥，所述第二私钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；
公钥发送单元，用于将携带签名的第一公钥发送给所述第一服务器，所述第一公钥携带的签名用于验证所述第二域内的第二计算实体。
一种服务器，作为第一域中的第一服务器，所述服务器包括：
存储器，用于存储计算机程序和所述计算机程序运行所产生的数据；
处理器，用于执行所述计算机程序，以实现：接收所述第一域内的第一计算实体发送的验证请求，所述验证请求用于指示对第二域内的第二计算实体进行身份验证；根据所述验证请求，向所述第二域内的第二服务器发送公钥查询请求；接收所述第二服务器发送的携带签名的第一公钥，所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；使用第二公钥对所述第一公钥携带的签名进行验证；所述第二公钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；在所述第一公钥携带的签名表征所述第二计算实体验证通过的情况下，将所述第一公钥发送给所述第一计算实体。
一种服务器，作为第二域中的第二服务器，所述服务器包括：
存储器，用于存储计算机程序和所述计算机程序运行所产生的数据；
处理器，用于执行所述计算机程序，以实现：接收第一域中的第一服务器发送的公钥查询请求；根据所述公钥查询请求，获得第一公钥；所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；使用第二私钥对所述第一公钥进行签名，以得到携带签名的第一公钥，所述第二私钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；将携带签名的第一公钥发送给所述第一服务器，所述第一公钥 携带的签名用于验证所述第二域内的第二计算实体。
从上述技术方案可以看出，本申请公开的一种安全多方计算中的跨域身份验证方法及服务器中，通过由各个域中的计算实体为其他域内的实体生成公钥和私钥，由此，在多个域之间实现安全多方计算而不同域之间的实体进行跨域交互时，由当前域中的服务器使用对方域的实体所发来的公钥对对方域中的实体使用私钥发来的签名进行验证，由此实现跨域身份验证，避免在同一域中进行安全多方计算时所导致的隐私数据泄露的问题。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例一提供的一种安全多方计算中的跨域身份验证方法的流程图；
图2为实现安全多方计算的不同域之间进行交互的示例图；
图3和图4分别为本申请实施例一提供的一种安全多方计算中的跨域身份验证方法的另一流程图；
图5为本申请实施例二提供的一种安全多方计算中的跨域身份验证方法的流程图；
图6为本申请实施例三提供的一种服务器的结构示意图；
图7为本申请实施例四提供的一种服务器的结构示意图；
图8为本申请实现跨域身份验证以及数据传输的交互示意图；
图9为域内SMPC的组成示意图；
图10为SMPC的部署架构图；
图11为本申请适用于不同域的实体之间进行跨域身份验证以及数据传输的数据流向图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
参考图1所示，为本申请实施例一提供的一种安全多方计算中的跨域身份验证方法的实现流程图，该方法可以适用于第一域的第一服务器，如当前域中的网关服务器。例如，如图2中所示，实现安全多方计算的多个计算实体来源于多个域，这里的计算实体可以为peer、client等实体。本实施例中的方法适用于域1中的网关服务器。本实施例中的技术方案主要用于实现当前域与对方域之间的身份验证，以便于实现不同域之间的数据交互。
具体的，本实施例中的方法可以包含如下步骤：
步骤101：接收第一域内的第一计算实体发送的验证请求。
其中，验证请求用于指示对第二域内的第二计算实体进行身份验证，以便于向第二计算实体发送目标数据。
具体的，验证请求中至少包含有第一计算实体的域标识和第二计算实体的域标识，以表征第一计算实体需要验证第二计算实体，以便于第一计算实体向第二计算实体传输目标数据，如图2中所示，域1中的第一计算实体向域1中的网关服务器发送验证请求，以表征第一计算实体需要验证域2中的第二计算实体。
其中，第一计算实体的域标识用于表征第一计算实体处于第一域中且在第一域中唯一表征第一计算实体，第二计算实体的域标识用于表征第二计算实体处于第二域中且在第二域中唯一表征第二计算实体。基于此，第一计算实体的域标识为第一计算实体在所有域中的全局标识，第二计算实体的域标识为第二计算实体在所有域中的全局标识。
需要说明的是，所有域中的计算实体的域标识均注册并记录在区块链上存储的域标识列表中，各个计算实体的域标识同时分别存储在本地存储区域中。第一计算实体在被协调服务器划分到实现安全多方计算的计算组后，接收协调服务器发送的计算组中的其他计算实体的实体标识，计算实体的实体标识在该计算实体所在域中唯一表征该计算实体，也可以理解为本地标识。基于此，验证请求中的第一计算实体的域标识由第一计算实体从其本地存储区域中读取，而验证请求中的第二计算实体的域标识由第一计算实体基于第二计算实体的实体标识在区块链上存储的域标识列表中查询得到。
具体的，第一计算实体可以通过第一计算实体中配置的智能链代码向第一域内的域信任服务器发送标识查询请求，其中包含第二计算实体的实体标识，由此，第一域内的域信任服务器在区块链上存储的域标识列表中查询与第二计算实体的实体标识相对应的域标识，再通过第一计算实体中的智能链代码发送给第一计算实体，由此，第一计算实体可以获得到第二计算实体的域标识，进一步的，第一计算实体通过其智能链代码基于第一计算实体的域标识和第二计算实体的域标识生成验证请求，并将该验证请求发送给第一域中的第一服务器，即网关服务器。
步骤102：根据验证请求，向第二域内的第二服务器发送公钥查询请求。
其中，公钥查询请求中至少包含有第一计算实体的域标识和第二计算实体的域标识，以表征第一服务器需要第二域内的第二服务器返回第一计算实体为第二域内的实体所生成的公钥。
具体的，第二域内的第二服务器可以为域内的域信任服务器。基于此，第二域内的第二服务器可以根据公钥查询请求在区块链上存储的私钥信息中，检索与第一计算实体的域标识和第二计算实体的域标识均相匹配的目标信息，该目标信息表征第一计算实体为第二计算实体生成的公钥，基于此，根据该目标信息，获得第一公钥，例如，在目标信息中提取公钥信息，从而得到第一计算实体为第二域内的实体所生成的第一 公钥，之后，第二服务器使用第二私钥对第一公钥进行签名，以得到携带签名的第一公钥并将携带签名的第一公钥发送给第一域的第一服务器。
步骤103：接收第二服务器发送的携带签名的第一公钥。
步骤104：使用第二公钥对第一公钥携带的签名进行验证。
其中，第二公钥为第二服务器预先为第一域内的实体生成的秘钥。第二公钥可以预先存储在第一服务器的本地存储区域中，由第二服务器直接发送给第一服务器，以建立与第一服务器之间的信任关系。
具体的，第一服务器使用第二公钥对第一公钥所携带的签名进行解密，并将解密得到的信息与第一公钥进行比对，如果比对一致，则表征第一公钥验证通过，即第二计算实体验证通过，如果比对不一致，则表征第一公钥可能存在被篡改或损坏的情况，此时第一公钥验证不通过，即第二计算实体验证不通过。
步骤105：在第一公钥携带的签名表征第二计算实体验证通过的情况下，将第一公钥发送给第一计算实体。
基于此，在第一公钥携带的签名表征第二计算实体验证通过的情况下，完成第一域和第二域之间的计算实体之间的跨域身份验证，由此，第一计算实体可以根据第一服务器发送的第一公钥向第二计算实体传输目标数据。
而在第一公钥携带的签名保证第二计算实体验证不通过的情况下，发送第二计算实体验证不通过的消息给第一计算实体，由此，第一计算实体不会向第二计算实体传输目标数据。
具体的，第一服务器可以通过连接到第一计算实体的连接器将包含第一公钥的通知消息发送给第一计算实体，第一计算实体可以在通知消息中获得第一公钥，进而基于该第一公钥在本地存储区域中查找对应的第一私钥，再使用第一私钥对需要传输的目标数据进行加密，在第一计算实体将被第一私钥加密的目标数据通过第一服务器传输给第二计算实体之后，第二计算实体可以使用第一公钥对目标数据进行解密。
由上述方案可知，本申请实施例一提供的一种安全多方计算中的跨域身份验证方法中，通过由各个域中的计算实体为其他域内的实体生成公钥和私钥，由此，在多个域之间实现安全多方计算而不同域之间的实体进行跨域交互时，由当前域中的服务器使用对方域的实体所发来的公钥对对方域中的实体使用私钥发来的签名进行验证，由此实现跨域身份验证，避免在同一域中进行安全多方计算时所导致的隐私数据泄露的问题。
在一种实现方式中，第一计算实体在生成验证请求之后，在将验证请求发送给第一服务器之前，先为验证请求添加请求签名。由此，第一服务器接收到的验证请求中携带有请求签名。
基于此，在步骤101之后，即第一服务器在接收到第一域内的第一计算实体发送的验证请求之后，还可以包含如下步骤，如图3中所示：
步骤106：对验证请求中携带的请求签名进行验证。
其中，请求签名为第一计算实体使用第三私钥对验证请求进行签名得到，第三私钥为第一计算实体为第一域内的实体生成的秘钥。也就是说，各个域中的计算实体为本域内的实体所生成的公钥和私钥与为其他域内的实体生成的公钥和私钥是不同的。基于此，第一服务器使用第三公钥对验证请求中携带的请求签名进行验证，而这里的第三公钥为第一计算实体为第一域内的实体如第一服务器生成的秘钥；或者，第三公钥为第一域的信任根，信任根为第一域内各个实体所共同信任的依据，基于该信任根，第一域内的各个实体可以使用信任根生成秘钥，也就是说，信任根也用于生成第三私钥。由此，第一服务器上得到对验证请求的请求签名进行验证的验证结果。
基于此，在验证请求验证通过的情况下，执行步骤102，即根据验证请求，向第二域内的第二服务器发送公钥查询请求，而在验证请求验证不通过的情况下，结束当前流程，不再向第二服务器发送公钥查询请求。
在一种实现方式中，在步骤105之后，本实施例中的方法还可以包含如下步骤，如图4中所示：
步骤107：接收第一计算实体传输的目标数据。
其中，目标数据为第一计算实体使用第一公钥对应的第一私钥经过加密所得到的数据。
步骤108：将目标数据传输给第二计算实体。
具体的，第一服务器可以将目标数据传输第二域中的第二服务器，由第二服务器将目标数据发送给第二域中的第二计算实体，由此，第二计算实体可以使用第一公钥对目标数据进行解密，从而实现隐私数据的安全传输。
进一步的，在步骤108之后，即第一服务器将目标数据传输给第二计算实体之后，还会向第一计算实体发送反馈消息，该反馈消息至少表征目标数据处理完成。具体的，第一服务器将反馈消息通过连接到第一计算实体的连接器发送给第一计算实体。
参考图5，为本申请实施例二提供的一种安全多方计算中的跨域身份验证方法的实现流程图，该方法可以适用于第二域中的第二服务器，如相对于当前域的对方域中的域信任服务器。例如，如图2中所示，本实施例中的方法适用于域2中的域信任服务器。本实施例中的技术方案主要用于实现当前域与对方域之间的身份验证，以便于实现不同域之间的数据。
具体的，本实施例中的方法可以包括如下步骤：
步骤501：接收第一域中的第一服务器发送的公钥查询请求。
其中，公钥查询请求中至少包含有第一计算实体的域标识和第二计算实体的域标识，以表征第一服务器需要第二域内的第二服务器返回第一计算实体为第二域内的实体所生成的公钥。
步骤502：根据公钥查询请求，获得第一公钥。
其中，第一公钥为第一计算实体预先为第二域内的实体生成的秘钥。
具体的，第二服务器可以根据公钥查询请求在区块链上存储的私钥信息中，检索与第一计算实体的域标识和第二计算实体的域标识均相匹配的目标信息，该目标信息表征第一计算实体为第二计算实体生成的公钥，基于此，根据该目标信息，获得第一公钥，例如，在目标信息中提取公钥信息，从而得到第一计算实体为第二域内的实体所生成的第一公钥。
步骤503：使用第二私钥对第一公钥进行签名，以得到携带签名的第一公钥。
其中，第二私钥为第二服务器预先为第一域内的实体生成的秘钥。
具体的，第二服务器可以使用第二私钥对第一私钥进行加密，将加密得到的信息作为签名添加到第一公钥中，进而得到携带签名的第一公钥。
步骤504：将携带签名的第一公钥发送给第一服务器。
其中，第一公钥携带的签名用于验证第二域内的第二计算实体。
具体的，第一服务器使用第二公钥对第一公钥携带的签名进行验证，如果第一公钥验证通过，则表明第二计算实体验证通过。在第二计算实体验证通过的情况下，第一服务器将第一公钥通过连接到第一计算实体的连接器发送给第一计算实体，由第一计算实体使用第一公钥对应的第一私钥对目标数据进行加密，从而将被加密的目标数据通过第一服务器传输给第二计算实体。
由上述方案可知，本申请实施例二提供的一种安全多方计算中的跨域身份验证方法中，通过由各个域中的计算实体为其他域内的实体生成公钥和私钥，由此，在多个域之间实现安全多方计算而不同域之间的实体进行跨域交互时，由当前域中的服务器使用对方域的实体所发来的公钥对对方域中的实体使用私钥发来的签名进行验证，由此实现跨域身份验证，避免在同一域中进行安全多方计算时所导致的隐私数据泄露的问题。
参考图6，为本申请实施例三提供的一种服务器的结构示意图，该服务器作为第一域中的第一服务器，如当前域中的网关服务器。例如，如图2中所示的域1中的网关服务器。本实施例中的技术方案主要用于实现当前域与对方域之间的身份验证，以便于实现不同域之间的数据交互。
具体的，本实施例中的第一服务器可以包括如下结构：
存储器601，用于存储计算机程序和计算机程序运行所产生的数据；
处理器602，用于执行计算机程序，以实现：接收第一域内的第一计算实体发送的验证请求，验证请求用于指示对第二域内的第二计算实体进行身份验证；根据验证请求，向第二域内的第二服务器发送公钥查询请求；接收第二服务器发送的携带签名的第一公钥，第一公钥为第一计算实体预先为第二域内的实体生成的秘钥；使用第二公钥对第一公钥携带的签名进行验证；第二公钥为第二服务器预先为第一域内的实体生成的秘钥；在第一公钥携带的签名表征第二计算实体验证通过的情况下，将第一公钥发送给第一计算实体。
另外，本实施例中的第一服务器中还可以包含有通信模块等结构，用以实现与第 一计算实体和第二服务器之间的交互。例如，处理器602通过触发通信模块接收第一域内的第一计算实体发送的验证请求、向第二域内的第二服务器发送公钥查询请求、接收第二服务器发送的携带签名的第一公钥以及在第一公钥携带的签名表征第二计算实体验证通过的情况下，将第一公钥发送给第一计算实体，等等。
由上述方案可知，本申请实施例三提供的一种服务器中，通过由各个域中的计算实体为其他域内的实体生成公钥和私钥，由此，在多个域之间实现安全多方计算而不同域之间的实体进行跨域交互时，由当前域中的服务器使用对方域的实体所发来的公钥对对方域中的实体使用私钥发来的签名进行验证，由此实现跨域身份验证，避免在同一域中进行安全多方计算时所导致的隐私数据泄露的问题。
在一种实现方式中，验证请求中至少包含第一计算实体的域标识和第二计算实体的域标识，第一计算实体的域标识用于表征第一计算实体处于第一域中且在第一域中唯一表征第一计算实体，第二计算实体的域标识用于表征第二计算实体处于第二域中且在第二域中唯一表征第二计算实体；其中，公钥查询请求中至少包含第一计算实体的域标识和第二计算实体的域标识。
在一种实现方式中，验证请求中至少携带请求签名，处理器602在通过通信模块接收第一域内的第一计算实体发送的验证请求之后，还可以对验证请求中携带的请求签名进行验证；在验证请求验证通过的情况下，根据验证请求，通过通信模块向第二域内的第二服务器发送公钥查询请求；而如果验证请求验证不通过，那么结束当前流程。
在一种实现方式中，请求签名为第一计算实体使用第三私钥对验证请求进行签名得到，第三私钥为第一计算实体为第一域内的实体生成的秘钥；处理器602在对验证请求中携带的请求签名进行验证时，具体用于：使用第三公钥对验证请求中携带的请求签名进行验证；其中，第三公钥为第一计算实体为第一服务器生成的秘钥；或者，第三公钥为第一域的信任根，信任根用于生成第三私钥。
在一种实现方式中，处理器602还用于：通过通信模块接收第一计算实体传输的目标数据；将目标数据通过通信模块传输给第二计算实体。
在一种实现方式中，在将目标数据传输给第二计算实体之后，处理器601还用于：通过通信模块向第一计算实体发送反馈消息，反馈消息至少表征目标数据处理完成。
需要说明的是，本实施例中处理器的具体实现可以参考前文中的相应内容，此处不再详述。
相对应的，本申请实施例还提供了一种安全多方计算中的跨域身份验证装置，应用于第一域中的第一服务器，装置包括：
请求接收单元，用于接收第一域内的第一计算实体发送的验证请求，验证请求用于指示对第二域内的第二计算实体进行身份验证；
请求发送单元，用于根据验证请求，向第二域内的第二服务器发送公钥查询请求；
公钥接收单元，用于接收第二服务器发送的携带签名的第一公钥，第一公钥为第一计算实体预先为第二域内的实体生成的秘钥；
签名验证单元，用于使用第二公钥对第一公钥携带的签名进行验证；第二公钥为第二服务器预先为第一域内的实体生成的秘钥；
公钥发送单元，用于在第一公钥携带的签名表征第二计算实体验证通过的情况下，将第一公钥发送给第一计算实体。
参考图7，为本申请实施例四提供的一种服务器的结构示意图，该服务器作为第二域中的第二服务器，如相对于当前域的对方域中的域信任服务器。例如，如图2中所示的域2中的域信任服务器。本实施例中的技术方案主要用于实现当前域与对方域之间的身份验证，以便于实现不同域之间的数据交互。
具体的，本实施例中的服务器可以包括以下结构：
存储器701，用于存储计算机程序和计算机程序运行所产生的数据；
处理器702，用于执行计算机程序，以实现：接收第一域中的第一服务器发送的公钥查询请求；根据公钥查询请求，获得第一公钥；第一公钥为第一计算实体预先为第二域内的实体生成的秘钥；使用第二私钥对第一公钥进行签名，以得到携带签名的第一公钥，第二私钥为第二服务器预先为第一域内的实体生成的秘钥；将携带签名的第一公钥发送给第一服务器，第一公钥携带的签名用于验证第二域内的第二计算实体。
另外，本实施例中的第二服务器中还可以包含有通信模块等结构，用以实现与第二计算实体和第一服务器之间的交互。例如，处理器702通过触发通信模块接收第一域中的第一服务器发送的公钥查询请求以及将携带签名的第一公钥发送给第一服务器，等等。
由上述方案可知，本申请实施例四提供的一种服务器中，通过由各个域中的计算实体为其他域内的实体生成公钥和私钥，由此，在多个域之间实现安全多方计算而不同域之间的实体进行跨域交互时，由当前域中的服务器使用对方域的实体所发来的公钥对对方域中的实体使用私钥发来的签名进行验证，由此实现跨域身份验证，避免在同一域中进行安全多方计算时所导致的隐私数据泄露的问题。
相对应的，本申请实施例还提供了一种安全多方计算中的跨域身份验证装置，应用于第二域中的第二服务器，装置包括：
请求接收单元，用于接收第一域中的第一服务器发送的公钥查询请求；
公钥获得单元，用于根据公钥查询请求，获得第一公钥；第一公钥为第一计算实体预先为第二域内的实体生成的秘钥；
公钥签名单元，用于使用第二私钥对第一公钥进行签名，以得到携带签名的第一公钥，第二私钥为第二服务器预先为第一域内的实体生成的秘钥；
公钥发送单元，用于将携带签名的第一公钥发送给第一服务器，第一公钥携带的签名用于验证第二域内的第二计算实体。
以第一域和第二域如域1和域2中的计算实体参与安全多方计算为例，如图8所示，为本申请实现跨域身份验证以及数据传输的交互示意图，具体如下：
1、第一计算实体被协调服务器划分到计算组之后，第一计算实体可以得到协调服 务器发送的其他计算实体如第二计算实体的实体标识，基于此，第一计算实体向第一计算实体中配置的智能链代码发送标识查询请求，标识查询请求中包含有第二计算实体的实体标识，第二计算实体的实体标识用于在第二域中唯一表征第二计算实体；
2、第一计算实体中的智能链代码向域1中的域信任服务器发送标识查询请求；
3、域1中的域信任服务器在区块链上存储的域标识列表中查询与第二计算实体的实体标识相对应的域标识，以得到第二计算实体的域标识，并将第二计算实体的域标识返回给第一计算实体中的智能链代码；
4、第一计算实体中的智能链代码按照第二计算实体的域标识和第一计算实体的域标识生成验证请求，该验证请求中至少包含第二计算实体的域标识和第一计算实体的域标识，第一计算实体中的智能链代码对验证请求使用第三私钥进行签名，将携带签名的验证请求发送给域1中的网关服务器；第三私钥为第一计算实体为域1内的实体使用域1的信任根所签发的私钥，相应有对应的第三公钥；
5、域1中的网关服务器使用第三公钥对验证请求所携带的签名进行验证；
6、域1中的网关服务器在验证请求验证通过的情况下，获得验证请求中所包含的第二计算实体的域标识和第一计算实体的域标识，并根据第二计算实体的域标识和第一计算实体的域标识向域2中的域信任服务器发送公钥查询请求，公钥查询请求中包含有第二计算实体的域标识和第一计算实体的域标识；
7、域2的域信任服务器接收到公钥查询请求之后，在区块链上存储的私钥信息中查找与第二计算实体的域标识和第一计算实体的域标识均相匹配的公钥，以得到第一计算实体为第二计算实体生成的第一公钥；域2的域信任服务器将第一公钥使用第二私钥进行签名，将携带签名的第一公钥发送给域1中的网关服务器；
8、域1中的网关服务器使用域2中的域信任服务器预先发来的第二公钥对第一公钥携带的签名进行验证；
9、域1中的网关服务器在第一公钥携带的签名验证通过的情况下，发送包含第一公钥的通知消息给连接到第一计算实体的连接器；
10、第一计算实体对应的连接器接收到通知消息之后，将第一公钥发送给第一计算实体；
11、第一计算实体使用第一公钥在本地存储区域中查找对应的第一私钥，使用查找到的第一私钥对隐私数据进行加密，并将被加密的隐私数据发送到第一计算实体对应的连接器；
12、第一计算实体对应的连接器将被加密的隐私数据通过域1的网关服务器和域2的网关服务器或域信任服务器按照第二计算实体的域标识发送给域2中的第二计算实体；
13、域1中的网关服务器在为第一计算实体传输完成隐私数据之后，给第一计算实体的智能链代码发送反馈消息，以表征当前数据处理完成。
具体的，如图9中所示，每个域domain包含运行安全多方计算SMPC(Secure Multi-Party Computation)的基本模块，可以实现完整SMPC计算任务调用。其中包括： 电子认证服务CA(Certificate Authority)、协调服务器Coordinator(也可以称为协调者)、Peer计算节点、成员资格服务器(Membership service)等模块。而区块链上用于存储各个域中的实体使用各自域的信任根为其他域所生成的公钥以及各个域中的实体的域标识。
如图10所示，为SMPC的部署架构图，SMPC至少包含如下模块：
数据提供者模块，通过数据前置处理器提供处理计算任务所需要的数据；
协调模块，作为协调者，提供资源管理服务、任务调度服务和预处理评估服务等处理，例如，根据计算任务创建计算组，其中包含来自多个域中的计算节点(即计算实体)；
链码模块，作为算法提供者，用于提供计算任务所使用的算法内容，其中包含逻辑运算算子和算术运算算子；
数据处理模块，作为算力提供者，包含多个计算节点，计算节点提供计算资源和存储资源，各个计算节点中具有各自的私有存储区域即本地存储区域，用于存储私钥等信息；而数据处理模块与协调模块之间通过P2P网络协议进行通信；
区块链账本上存储各个计算节点对应的公钥证书，以便于计算节点查询得到相应的公钥；
匿名身份模块，用于为计算节点注册域标识；
如图11中所示，为不同域的实体之间进行跨域身份验证以及数据传输的数据流向图。其中，ID owner包括但不限于client、peer等需要身份的计算实体。coordinator根据工作任务job生成计算组group，即抽取不同域内的计算实体组成一个计算组，使得group可以包括不同信任域的实体，包括client和peer，ID owner针对需要通信的信任域生成公私钥对，把公钥发送到所有交互的信任域的CA或者秘钥生成中心KGC(Key Generation Center)，并生成公钥证书，并把ID对应的公钥证书通过区块链blockchain共识协议，加入到区块中，作为全网可公开验证的公开参数。而在实际运行计算job的时候，所有实体都需要验证身份信息，通过区块链中的智能合约查询到ID对应的公钥信息，进行身份验证。因为针对所有的域，每个ID owner会生成不同的公私钥对，这样就完全避免了跨域的认证过程，使得SMPC的计算job是可以完全去中心化。
具体如下：
1、ID owner向智能链代码Smart chain code发送标识查询请求，标识查询请求中包含有域2中实体的实体标识；
2、Smart chain code向域1中的Domain trust service发送标识查询请求；
3、域1中的Domain trust service在区块链上存储的域标识列表中查询域2中实体的域标识，并将域2中实体的域标识返回给Smart chain code；
4、Smart chain code按照ID owner的域标识和域2中的域标识生成验证请求，Smart chain code对验证请求使用第三私钥进行签名，将携带签名的验证请求发送给域1中的Domain gateway；第三私钥为ID owner为域1内的实体使用域1的信任根所签发的私钥，相应有对应的第三公钥；
5、域1中的Domain gateway使用第三公钥对验证请求所携带的签名进行验证；
6、域1中的Domain gateway在验证请求验证通过的情况下，获得验证请求中所包含的域2中实体的域标识和ID owner的域标识，并根据ID owner的域标识和域2中实体的域标识向域2中的Domain trust service发送公钥查询请求，公钥查询请求中包含有域2中实体的域标识和ID owner的域标识；
7、域2的Domain trust service接收到公钥查询请求之后，在区块链上存储的私钥信息中查找与域2中实体的域标识和ID owner的域标识均相匹配的公钥对应关系，以得到ID owner为域2中实体生成的第一公钥；域2的Domain trust service将第一公钥使用第二私钥进行签名，将携带签名的第一公钥发送给域1中的Domain gateway；
8、域1中的Domain gateway使用域2中的Domain trust service预先发来的第二公钥对第一公钥携带的签名进行验证；
9、域1中的Domain gateway在第一公钥携带的签名验证通过的情况下，发送包含第一公钥的通知消息给连接到ID owner的连接器Ledger connector；
10、Ledger connector接收到通知消息之后，将第一公钥发送给ID owner；
11、ID owner使用第一公钥在本地存储区域中查找对应的第一私钥，使用查找到的第一私钥对隐私数据进行加密，并将被加密的隐私数据发送到Ledger connector；
12、Ledger connector将被加密的隐私数据通过域1的Domain gateway和域2的Domain gateway或Domain trust service按照域2中实体的域标识发送给域2中的实体；
13、域1中的Domain gateway在为ID owner传输完成隐私数据之后，给ID owner的Smart chain code发送反馈消息，以表征当前数据处理完成。
由此，在实现安全多方计算中，在不同域之间实现跨域身份验证以及数据传输。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定 义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

  1. 一种安全多方计算中的跨域身份验证方法，应用于第一域中的第一服务器，所述方法包括：
    接收所述第一域内的第一计算实体发送的验证请求，所述验证请求用于指示对第二域内的第二计算实体进行身份验证；
    根据所述验证请求，向所述第二域内的第二服务器发送公钥查询请求；
    接收所述第二服务器发送的携带签名的第一公钥，所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；
    使用第二公钥对所述第一公钥携带的签名进行验证；所述第二公钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；
    在所述第一公钥携带的签名表征所述第二计算实体验证通过的情况下，将所述第一公钥发送给所述第一计算实体。
  2. 根据权利要求1所述的方法，所述验证请求中至少携带请求签名；
    其中，在接收所述第一域内的第一计算实体发送的验证请求之后，所述方法还包括：
    对所述验证请求中携带的请求签名进行验证；
    在所述验证请求验证通过的情况下，执行所述步骤：根据所述验证请求，向所述第二域内的第二服务器发送公钥查询请求；
    在所述验证请求验证不通过的情况下，结束当前流程。
  3. 根据权利要求2所述的方法，所述请求签名为所述第一计算实体使用第三私钥对所述验证请求进行签名得到，所述第三私钥为所述第一计算实体为所述第一域内的实体生成的秘钥；
    其中，对所述验证请求中携带的请求签名进行验证，包括：
    使用第三公钥对所述验证请求中携带的请求签名进行验证；
    其中，所述第三公钥为所述第一计算实体为所述第一服务器生成的秘钥；或者，所述第三公钥为所述第一域的信任根，所述信任根用于生成所述第三私钥。
  4. 根据权利要求1、2或3所述的方法，所述方法还包括：
    接收所述第一计算实体传输的目标数据；
    将所述目标数据传输给所述第二计算实体。
  5. 根据权利要求4所述的方法，在将所述目标数据传输给所述第二计算实体之后，所述方法还包括：
    向所述第一计算实体发送反馈消息，所述反馈消息至少表征所述目标数据处理完成。
  6. 根据权利要求1、2或3所述的方法，所述验证请求中至少包含所述第一计算实体的域标识和所述第二计算实体的域标识，所述第一计算实体的域标识用于表征所述第一计算实体处于所述第一域中且在所述第一域中唯一表征所述第一计算实体，所述第二计算实体的域标识用于表征所述第二计算实体处于第二域中且在所述第二域中 唯一表征所述第二计算实体；
    其中，所述公钥查询请求中至少包含所述第一计算实体的域标识和所述第二计算实体的域标识。
  7. 一种安全多方计算中的跨域身份验证方法，应用于第二域中的第二服务器，所述方法包括：
    接收第一域中的第一服务器发送的公钥查询请求；
    根据所述公钥查询请求，获得第一公钥；所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；
    使用第二私钥对所述第一公钥进行签名，以得到携带签名的第一公钥，所述第二私钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；
    将携带签名的第一公钥发送给所述第一服务器，所述第一公钥携带的签名用于验证所述第二域内的第二计算实体。
  8. 根据权利要求7所述的方法，所述公钥查询请求中至少包含所述第一计算实体的域标识和所述第二计算实体的域标识；
    其中，根据所述公钥查询请求，获得第一公钥，包括：
    在区块链上存储的秘钥信息中，检索与所述第一计算实体的域标识和所述第二计算实体的域标识均相匹配的目标信息，所述目标信息表征所述第一计算实体为所述第二计算实体生成公钥；
    根据所述目标信息，获得所述第一公钥。
  9. 一种服务器，作为第一域中的第一服务器，所述服务器包括：
    存储器，用于存储计算机程序和所述计算机程序运行所产生的数据；
    处理器，用于执行所述计算机程序，以实现：接收所述第一域内的第一计算实体发送的验证请求，所述验证请求用于指示对第二域内的第二计算实体进行身份验证；根据所述验证请求，向所述第二域内的第二服务器发送公钥查询请求；接收所述第二服务器发送的携带签名的第一公钥，所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；使用第二公钥对所述第一公钥携带的签名进行验证；所述第二公钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；在所述第一公钥携带的签名表征所述第二计算实体验证通过的情况下，将所述第一公钥发送给所述第一计算实体。
  10. 一种服务器，作为第二域中的第二服务器，所述服务器包括：
    存储器，用于存储计算机程序和所述计算机程序运行所产生的数据；
    处理器，用于执行所述计算机程序，以实现：接收第一域中的第一服务器发送的公钥查询请求；根据所述公钥查询请求，获得第一公钥；所述第一公钥为所述第一计算实体预先为所述第二域内的实体生成的秘钥；使用第二私钥对所述第一公钥进行签名，以得到携带签名的第一公钥，所述第二私钥为所述第二服务器预先为所述第一域内的实体生成的秘钥；将携带签名的第一公钥发送给所述第一服务器，所述第一公钥携带的签名用于验证所述第二域内的第二计算实体。
PCT/CN2022/115785 2021-12-21 2022-08-30 安全多方计算中的跨域身份验证方法及服务器 WO2023116027A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111573518.0 2021-12-21
CN202111573518.0A CN114218558A (zh) 2021-12-21 2021-12-21 安全多方计算中的跨域身份验证方法及服务器

Publications (1)

Publication Number Publication Date
WO2023116027A1 true WO2023116027A1 (zh) 2023-06-29

Family

ID=80704772

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/115785 WO2023116027A1 (zh) 2021-12-21 2022-08-30 安全多方计算中的跨域身份验证方法及服务器

Country Status (2)

Country Link
CN (1) CN114218558A (zh)
WO (1) WO2023116027A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114218558A (zh) * 2021-12-21 2022-03-22 联想(北京)有限公司 安全多方计算中的跨域身份验证方法及服务器

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085633A1 (en) * 2004-10-14 2006-04-20 Dirk Balfanz Using a portable security token to facilitate cross-certification between ceritification authorities
CN101453476A (zh) * 2009-01-06 2009-06-10 中国人民解放军信息工程大学 一种跨域认证方法和系统
CN112654042A (zh) * 2020-12-24 2021-04-13 中国电子科技集团公司第三十研究所 基于轻量级ca的双向身份认证方法、计算机程序及存储介质
CN113672942A (zh) * 2021-04-29 2021-11-19 中国电子科技集团公司第三十研究所 一种基于区块链的pki证书跨域认证方法
CN114218558A (zh) * 2021-12-21 2022-03-22 联想(北京)有限公司 安全多方计算中的跨域身份验证方法及服务器

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085633A1 (en) * 2004-10-14 2006-04-20 Dirk Balfanz Using a portable security token to facilitate cross-certification between ceritification authorities
CN101453476A (zh) * 2009-01-06 2009-06-10 中国人民解放军信息工程大学 一种跨域认证方法和系统
CN112654042A (zh) * 2020-12-24 2021-04-13 中国电子科技集团公司第三十研究所 基于轻量级ca的双向身份认证方法、计算机程序及存储介质
CN113672942A (zh) * 2021-04-29 2021-11-19 中国电子科技集团公司第三十研究所 一种基于区块链的pki证书跨域认证方法
CN114218558A (zh) * 2021-12-21 2022-03-22 联想(北京)有限公司 安全多方计算中的跨域身份验证方法及服务器

Also Published As

Publication number Publication date
CN114218558A (zh) 2022-03-22

Similar Documents

Publication Publication Date Title
CN109768988B (zh) 去中心化物联网安全认证系统、设备注册和身份认证方法
US20230023857A1 (en) Data processing method and apparatus, intelligent device, and storage medium
CN109922077B (zh) 一种基于区块链的身份认证方法及其系统
US11196573B2 (en) Secure de-centralized domain name system
WO2021036183A1 (zh) 通过证书签发进行多方安全计算的方法及装置
CN110709875B (zh) 在区块链网络中节点间建立可信点对点通信的方法和系统
Bonnah et al. DecChain: A decentralized security approach in Edge Computing based on Blockchain
EP1376976B1 (en) Methods for authenticating potential members invited to join a group
Chai et al. CyberChain: Cybertwin empowered blockchain for lightweight and privacy-preserving authentication in Internet of Vehicles
CN113553574A (zh) 一种基于区块链技术的物联网可信数据管理方法
Zhang et al. Efficient and privacy-preserving blockchain-based multifactor device authentication protocol for cross-domain IIoT
Oktian et al. BorderChain: Blockchain-based access control framework for the Internet of Things endpoint
Velliangiri et al. An efficient lightweight privacy-preserving mechanism for industry 4.0 based on elliptic curve cryptography
US20210250183A1 (en) Method and apparatus for performing multi-party secure computing based-on issuing certificate
Hoang et al. Privacy-preserving blockchain-based data sharing platform for decentralized storage systems
US20130080768A1 (en) Systems and methods for secure communications using an open peer protocol
Tong et al. CCAP: a complete cross-domain authentication based on blockchain for Internet of Things
CN116684093B (zh) 身份认证与密钥交换方法及系统
CN114710275A (zh) 物联网环境下基于区块链的跨域认证和密钥协商方法
CN115834067A (zh) 一种边云协同场景中密文数据共享方法
WO2023116027A1 (zh) 安全多方计算中的跨域身份验证方法及服务器
Pippal et al. CTES based Secure approach for Authentication and Authorization of Resource and Service in Clouds
CN107104804A (zh) 一种平台完整性验证方法和装置
Duan et al. Design of anonymous authentication scheme for vehicle fog services using blockchain
Liang Enabling privacy preservation and decentralization for attribute-based task assignment in crowdsourcing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22909352

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE