Cross-domain authentication methods, devices and storage media

Abstract

This application provides a cross-domain authentication method, device, and storage medium. The method includes: receiving a cross-domain authentication request triggered by a second client, the cross-domain authentication request including the identity identifier of the second client and a first target signature for cross-domain authentication of the second client; sending a verification request to the upper-level key generation center of the first client, so that the upper-level key generation center traverses the tree-like hierarchical structure downward from the root key generation center to determine the authentication path to the key generation center to which the second client belongs, and if it is determined based on the authentication path that the management domain to which the second client and the first client belong have a common trust anchor, then sending the master public key of the management domain to which the second client belongs to the first client; verifying the first target signature based on the master public key of the management domain to which the second client belongs and the identity identifier of the second client to confirm whether the second client belongs to its declared management domain, thereby achieving efficient and secure cross-domain authentication.

Description

Technical Field

[0001] This application relates to the field of identity authentication technology, and in particular to a cross-domain authentication method, device and storage medium. Background Technology

[0002] With the deepening of digital transformation, information systems are increasingly exhibiting characteristics of multi-entity, multi-organization, and multi-security domain collaboration. In key areas such as finance, healthcare, transportation, and the industrial internet, different entities typically belong to their own independently managed trust domains. Each domain has its own identity management system and exclusive trust anchors, such as independently deployed Certificate Authorities (CAs) or Key Generation Centers (KGCs).

[0003] In this environment, when entities from different trust domains (such as enterprise users and various service platforms, cross-regional medical institutions, heterogeneous IoT devices, etc.) need to interact securely, how to achieve efficient and secure cross-domain identity authentication without destroying the original trust boundaries and security management strategies of each domain has become a critical issue that urgently needs to be addressed. Summary of the Invention

[0004] This application provides a cross-domain authentication method, device, and storage medium to achieve efficient and secure cross-domain authentication.

[0005] In a first aspect, embodiments of this application provide a cross-domain authentication method applied to a first client in a tree-structured hierarchical key system. The tree-structured hierarchical key system includes a root key generation center, multiple sub-level key generation centers, and multiple clients, including the first client. The method includes:

[0006] Receive a cross-domain authentication request triggered by a second client, the cross-domain authentication request including the identity identifier of the second client and a first target signature for cross-domain authentication of the second client;

[0007] Based on the identity of the second client, a verification request is sent to the upper-level key generation center of the first client. This allows the upper-level key generation center to traverse the hierarchical tree structure downwards from the root key generation center based on the identity of the second client, determine the authentication path to the key generation center to which the second client belongs, and if the authentication path determines that the management domain of the second client and the first client have a common trust anchor, then the master public key of the management domain of the second client is sent to the first client.

[0008] Based on the master public key of the management domain where the second client resides and the identity identifier of the second client, the first target signature is verified to confirm whether the second client belongs to the management domain it has declared.

[0009] Secondly, embodiments of this application provide a cross-domain authentication device applied to a first client in a tree-structured hierarchical key system. The tree-structured hierarchical key system includes a root key generation center, multiple sub-level key generation centers, and multiple clients, including the first client. The device includes:

[0010] The receiving module is used to receive a cross-domain authentication request triggered by the second client, wherein the cross-domain authentication request includes the identity identifier of the second client and a first target signature for cross-domain authentication of the second client;

[0011] The sending module is used to send a verification request to the upper-level key generation center of the first client based on the identity identifier of the second client, so that the upper-level key generation center can traverse the tree-like hierarchical structure downward from the root key generation center based on the identity identifier of the second client to determine the authentication path to the key generation center to which the second client belongs, and if it is determined based on the authentication path that the management domain where the second client and the first client are located have a common trust anchor, then the master public key of the management domain where the second client is located is sent to the first client.

[0012] The verification module is used to verify the first target signature based on the master public key of the management domain where the second client is located and the identity identifier of the second client, so as to confirm whether the second client belongs to the management domain it has declared.

[0013] Thirdly, embodiments of this application provide an electronic device, applied to a first client in a tree-structured hierarchical key system, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the cross-domain authentication method as described in the first aspect.

[0014] Fourthly, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the cross-domain authentication method as described in the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product, including: a computer program or instructions, which, when executed by a processor of an electronic device, enable the processor to at least implement the cross-domain authentication method as described in the first aspect.

[0016] Sixthly, embodiments of this application provide a cross-domain authentication method applied to a second client in a tree-structured hierarchical key system. The tree-structured hierarchical key system includes a root key generation center, multiple sub-level key generation centers, and multiple clients, including the second client. The method includes:

[0017] In response to a cross-domain authentication request triggered by a user to the first client, obtain the master public key of the management domain to which the second client belongs;

[0018] Based on the identity of the second client, the master public key of the management domain to which the second client belongs is signed to generate the target signature;

[0019] The identity identifier of the second client and the target signature are sent to the first client, so that the first client can confirm with the first client’s superior key generation center whether the second client and the management domain of the first client have a common trust anchor, obtain the master public key of the management domain of the second client, and verify the target signature based on the master public key of the management domain of the second client and the identity identifier of the second client to confirm whether the second client belongs to the management domain it has declared.

[0020] Seventhly, embodiments of this application provide a cross-domain authentication device applied to a second client in a tree-structured hierarchical key system. The tree-structured hierarchical key system includes a root key generation center, multiple sub-level key generation centers, and multiple clients, including the second client. The device includes:

[0021] The acquisition module is used to obtain the master public key of the management domain to which the second client belongs in response to the cross-domain authentication request triggered by the user to the first client;

[0022] The signature module is used to sign the public key of the management domain to which the second client belongs, based on the identity identifier of the second client, and generate the target signature;

[0023] The sending module is used to send the identity identifier of the second client and the target signature to the first client, so that the first client can confirm whether the second client and the management domain where the first client is located have a common trust anchor through the upper-level key generation center of the first client, obtain the master public key of the management domain where the second client is located, and verify the target signature based on the master public key of the management domain where the second client is located and the identity identifier of the second client to confirm whether the second client belongs to the management domain it declared.

[0024] Eighthly, embodiments of this application provide an electronic device, a second client applied in a tree-structured hierarchical key system, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the cross-domain authentication method as described in the sixth aspect.

[0025] In a ninth aspect, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the cross-domain authentication method as described in the sixth aspect.

[0026] In a tenth aspect, embodiments of this application provide a computer program product, including: a computer program or instructions that, when executed by a processor of an electronic device, enable the processor to at least implement the cross-domain authentication method as described in the sixth aspect.

[0027] Eleventhly, embodiments of this application provide a cross-domain authentication method applied to a target sub-level key generation center in a tree-structured hierarchical key system. The tree-structured hierarchical key system includes a root key generation center, multiple sub-level key generation centers, and multiple clients. The multiple sub-level key generation centers include the target sub-level key generation center. The method includes:

[0028] Receive a verification request sent by a first client, the verification request including the identity identifier of the second client to be verified;

[0029] Based on the identity of the second client, the tree-like hierarchical structure is traversed downwards from the root key generation center to determine the authentication path to the key generation center to which the second client belongs;

[0030] If it is determined based on the authentication path that the second client and the first client share a common trust anchor in their respective management domains, then the master public key of the management domain of the second client is sent to the first client. This allows the first client to verify the first target signature sent by the second client based on the master public key of the management domain of the second client and the identity identifier of the second client, in order to confirm whether the second client belongs to its declared management domain.

[0031] In a twelfth aspect, embodiments of this application provide a cross-domain authentication device applied to a target sub-level key generation center in a tree-structured hierarchical key system. The tree-structured hierarchical key system includes a root key generation center, multiple sub-level key generation centers, and multiple clients. The multiple sub-level key generation centers include the target sub-level key generation center. The device includes:

[0032] A receiving module is used to receive a verification request sent by a first client, wherein the verification request includes the identity identifier of the second client to be verified;

[0033] The determination module is used to determine the authentication path to the key generation center of the second client by traversing the tree-like hierarchical structure downwards from the root key generation center based on the identity identifier of the second client.

[0034] The sending module is configured to send the master public key of the management domain where the second client is located to the first client if it is determined based on the authentication path that the second client and the first client have a common trust anchor, so that the first client can verify the first target signature sent by the second client based on the master public key of the management domain where the second client is located and the identity identifier of the second client, in order to confirm whether the second client belongs to the management domain it declared.

[0035] In a thirteenth aspect, embodiments of this application provide an electronic device applied to a target sub-level key generation center in a tree-structured hierarchical key system, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the cross-domain authentication method as described in the eleventh aspect.

[0036] In a fourteenth aspect, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the cross-domain authentication method as described in the eleventh aspect.

[0037] In a fifteenth aspect, embodiments of this application provide a computer program product, including: a computer program or instructions that, when executed by a processor of an electronic device, enable the processor to at least implement the cross-domain authentication method as described in the eleventh aspect.

[0038] The cross-domain authentication scheme provided in this application embodiment can be applied to a tree-structured hierarchical key system, which includes a root key generation center, multiple sub-level key generation centers, and multiple clients. Each Key Generation Center (KGC) in this tree-structured hierarchical key system adopts a tree-structured hierarchical structure, with each level representing a first-level KGC, and all leaf nodes in the tree representing terminal devices. Furthermore, the root KGC is trusted by all other sub-KGCs within the system, and each KGC must be authenticated by its superior KGC before it can be considered a valid KGC.

[0039] In other words, when using the cross-domain authentication scheme provided in this application to perform cross-domain authentication for clients in two different management domains, firstly, each KGC in the tree-structured layered key system needs to perform two-way authentication with its corresponding superior KGC, and each client needs to perform two-way authentication with its corresponding superior KGC, so as to form a traceable trust chain as a whole.

[0040] In practical applications, when the management domains of the first client and the second client are different, cross-domain authentication is required before the second client can communicate with the first client. Specifically, in response to a cross-domain authentication request triggered by the user to the first client, the second client obtains the master public key of its management domain and signs it based on its identity, generating a first target signature. A cross-domain authentication request is then generated based on the second client's identity and the first target signature and sent to the first client. The first client receives the cross-domain authentication request triggered by the second client, which includes the second client's identity and the first target signature used for cross-domain authentication. Finally, the first client sends a verification request to the parent key generation center of the second client based on the second client's identity. Upon receiving the verification request, the parent key generation center of the first client, based on the identity identifier of the second client in the verification request, traverses the hierarchical tree structure corresponding to the hierarchical key system from the root key generation center to determine the authentication path to the key generation center to which the second client belongs. If the authentication path determines that the management domains of the second client and the first client share a common trust anchor, then the master public key of the management domain of the second client is sent to the first client. After receiving the master public key of the management domain of the second client, the first client verifies the first target signature based on the master public key of the management domain of the second client and the identity identifier of the second client to confirm whether the second client belongs to the management domain it declared.

[0041] In the above scheme, a hierarchical key generation center (KGC) system is constructed. During the cross-domain authentication process, the second client actively provides a first target signature generated based on the master public key of its respective management domain in the cross-domain authentication request. The parent key generation center of the first client dynamically queries the hierarchical tree structure to discover the authentication path and verify the common trust anchor. That is, the common ancestor KGC of the two cross-domain clients is used as the top-level trust anchor, so that any two terminals belonging to different management domains can establish an indirect trust relationship by tracing back to the common ancestor, even if they do not have a direct trust relationship with each other. Furthermore, when it is determined that a trust relationship exists between two cross-domain clients, the master public key of the other domain can be issued as needed. This achieves lightweight cross-domain authentication that does not require a pre-set cross-domain master public key, does not rely on the full participation of a centralized root KGC, and supports automatic trust discovery. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a schematic diagram of a cross-domain authentication system provided in an embodiment of this application;

[0044] Figure 2 A flowchart illustrating a cross-domain authentication method provided in this application embodiment;

[0045] Figure 3 A flowchart illustrating another cross-domain authentication method provided in this application embodiment;

[0046] Figure 4 A flowchart illustrating yet another cross-domain authentication method provided in this application embodiment;

[0047] Figure 5 A schematic diagram of a tree-structured hierarchical key system provided in this application embodiment;

[0048] Figure 6 A schematic diagram of the structure of a cross-domain authentication device provided in an embodiment of this application;

[0049] Figure 7 To and Figure 6 A schematic diagram of the electronic device corresponding to the cross-domain authentication device provided in the illustrated embodiment;

[0050] Figure 8 A schematic diagram of another cross-domain authentication device provided in an embodiment of this application;

[0051] Figure 9 To and Figure 8 A schematic diagram of the electronic device corresponding to the cross-domain authentication device provided in the illustrated embodiment;

[0052] Figure 10 A schematic diagram of the structure of another cross-domain authentication device provided in an embodiment of this application;

[0053] Figure 11 To and Figure 9 The illustrated embodiment provides a schematic diagram of the electronic device corresponding to the cross-domain authentication device. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one. It should be understood that the term “and / or” as used herein is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character “ / ” in this document generally indicates that the preceding and following related objects are in an “or” relationship. Depending on the context, the words “if” or “when” as used herein can be interpreted as “when…” or “when…”.

[0056] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0057] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0058] Traditional cross-domain authentication schemes typically employ cross-authentication or bridging models to achieve mutual recognition between different trusted domains. In the cross-authentication model, each Key Management Center (KMC) establishes a direct trust relationship with each other in a peer-to-peer manner. Each KMC independently manages its master key and exchanges public keys or certificates with other KMCs when needed to complete cross-domain verification. In the bridging model, a centralized bridge KMC is introduced as a trusted third party. All participating domains establish a trust anchor with this bridge KMC, and cross-domain authentication is completed through the bridge KMC's relay or coordination.

[0059] However, the above solution has significant technical flaws:

[0060] On the one hand, although the cross-certification model has the ability to isolate local failures (i.e., the breach of a single KMC will not cause the entire network to collapse), when there are a large number of trust domains, it is necessary to maintain an independent trust link for each pair of domains, which leads to a quadratic increase in trust relationships, greatly increasing the complexity and operation and maintenance costs of key distribution, certificate management and policy configuration.

[0061] On the other hand, while the bridge connection model simplifies the trust topology between multiple domains, the bridge KMC becomes a single bottleneck for system performance and security. It must establish and maintain a large number of public parameters and key materials with all domains. As the access domains expand, the storage, computing and communication overhead of the bridge KMC increases sharply. Moreover, once the bridge KMC is attacked or fails, it will cause problems in the entire cross-domain authentication system.

[0062] In addition, these two types of solutions usually rely on pre-set master public keys or certificates of the other party's domain, which makes them difficult to adapt to scenarios such as the Internet of Things (IoT) where dynamic, large-scale, and heterogeneous terminals frequently join / leave. They also lack automated trust discovery and on-demand key acquisition mechanisms, thus limiting their application in highly scalable security architectures.

[0063] To address the aforementioned technical challenges, this application proposes a cross-domain authentication scheme. This scheme constructs a hierarchical, tree-structured KGC system, where each domain can autonomously manage its keys, forming a traceable trust chain as a whole. The KGC system uses a common ancestor KGC as the top-level trust anchor, enabling any two terminals belonging to different management domains, even without direct trust relationships, to establish indirect trust by tracing back to the common ancestor. Based on this structure, cross-domain terminals can securely and reliably identify and authenticate each other across domains. Furthermore, during cross-domain authentication, the client's parent KGC dynamically traverses the hierarchical structure based on the client's identity, automatically discovering the authentication path. Upon confirming the existence of a common trust anchor between the two management domains, it distributes the other domain's master public key as needed, allowing the client to complete identity-based signature verification locally. This achieves efficient and scalable cross-domain authentication without requiring pre-set cross-domain master public keys, without relying on centralized bridging nodes, and supports automatic trust discovery and lightweight terminal verification.

[0064] The cross-domain authentication scheme will be illustrated below with reference to the following embodiments.

[0065] The cross-domain authentication scheme provided in this application embodiment can be applied to a tree-structured hierarchical key system, which includes a root key generation center, multiple sub-level key generation centers, and multiple clients.

[0066] Before introducing the embodiments of this application, the tree-structured hierarchical key system will be described first. In this system, each KGC adopts a tree-structured hierarchical structure, with each level representing a first-level KGC and each level potentially including at least one KGC. All leaf nodes in the tree represent terminal devices. Furthermore, the root node in this tree-structured hierarchical structure is called the root KGC, which is trusted by all other child KGCs within the system. Each KGC must be authenticated by its parent KGC before it can be considered a valid KGC.

[0067] In other words, when using the cross-domain authentication scheme provided in this application to perform cross-domain authentication for clients in two different management domains, firstly, each KGC in the tree-structured layered key system needs to perform two-way authentication with its corresponding superior KGC, and each client needs to perform two-way authentication with its corresponding superior KGC, so as to form a traceable trust chain as a whole.

[0068] Since the specific implementation process of the two-way authentication process between each KGC and its corresponding superior KGC is roughly the same, this paper takes the target sub-level key generation center as an example to illustrate the specific implementation process of the two-way authentication between each KGC and its corresponding superior KGC in the tree-structured capping key system.

[0069] First, the target sub-level key generation center initiates an access authentication request to its corresponding parent key generation center. The parent key generation center then verifies the identity of the target sub-level key generation center to determine whether it can be added to the hierarchical tree structure.

[0070] Specifically, the target sub-level key generation center generates a master signature key and a master encryption key corresponding to itself, and generates a signature private key corresponding to itself based on its identity. Based on the signature private key, it signs the identity, master signature key, and master encryption key of the target sub-level key generation center to generate a second target signature. It then generates first authentication information containing the identity, master signature key, and master encryption key of the target sub-level key generation center. Based on the second target signature and the first authentication information, it generates an access authentication request and sends it to the parent key generation center of the target sub-level key generation center.

[0071] Specifically, the SM9 algorithm can be used to generate the master signature key and master encryption key corresponding to the target sub-level key generation center. This employs a dual-key mechanism. The master signature key is primarily used to issue identity-bound digital signature private keys for terminals or lower-level entities under the jurisdiction of this sub-level key generation center. The master encryption key is primarily used to derive identity-based encryption private keys for terminals or lower-level entities under the jurisdiction of this sub-level key generation center to support services such as key negotiation and data encryption / decryption in secure communication.

[0072] By separating signature and encryption functions, the dual-key mechanism can achieve separation of responsibilities, enhance security, and meet the independent authentication requirements of different application scenarios. In the tree-structured hierarchical KGC architecture of this application, each sub-level KGC can independently hold its own master signature key and master encryption key (securely derived or authorized by the superior KGC), thereby ensuring cross-domain interoperability while maintaining key autonomy and security boundaries of each management domain.

[0073] In practical implementation, the SM9 signature algorithm can be used to sign the identity of the target sub-level key generation center, the corresponding master signature key, and the master encryption key based on the signature private key, thereby generating a second target signature. That is, the second target signature is an SM9 signature.

[0074] Next, when the upper-level key generation center of the target sub-level key generation center receives the access authentication request sent by the target sub-level key generation center, the upper-level key generation center verifies whether the identity identifier in the first authentication information is consistent with the identity identifier when the target sub-level key generation center registered. If the verification is consistent, the second target signature is verified to confirm the identity information of the target sub-level key generation center.

[0075] Among them, the SM9 signature verification algorithm can be used to verify the second target signature based on the master key (master signature key) of the target sub-level key generation center and the identity identifier of the target sub-level key generation center, so as to confirm the identity information of the target sub-level key generation center.

[0076] After the parent key generation center of the target sub-level key generation center completes the identity verification of the target sub-level key generation center, the target sub-level key generation center then verifies the identity information of the parent key generation center of the target sub-level key generation center.

[0077] Specifically, the parent key generation center of the target sub-level key generation center generates its own (i.e., the parent key generation center of the target sub-level key generation center) master signature key and master encryption key, and generates a signature private key corresponding to the target sub-level key generation center based on its own (the parent key generation center of the target sub-level key generation center) identity. Based on the signature private key, it signs the identity of the parent key generation center of the target sub-level key generation center, the master signature key, and the master encryption key corresponding to the parent key generation center of the target sub-level key generation center, generating a third target signature. Second authentication information containing the identity of the parent key generation center of the target sub-level key generation center, the master signature key, and the master encryption key corresponding to the parent key generation center of the target sub-level key generation center is generated.

[0078] Specifically, the SM9 algorithm can be used to generate the master signature key and master encryption key corresponding to the parent key generation center of the target sub-level key generation center. This employs a dual-key mechanism. The master signature key is primarily used to issue identity-bound digital signature private keys for terminals or lower-level entities under the jurisdiction of this sub-level key generation center. The master encryption key is primarily used to derive identity-based encryption private keys for terminals or lower-level entities under the jurisdiction of this sub-level key generation center to support services such as key negotiation and data encryption / decryption in secure communication.

[0079] In practical implementation, the SM9 signature algorithm can be used to sign the identity of the parent key generation center of the target sub-level key generation center, the master signature key, and the master encryption key corresponding to the parent key generation center of the target sub-level key generation center, based on the signature private key, to generate a third target signature. That is, the third target signature is an SM9 signature.

[0080] Next, the target sub-level key generation center receives the third target signature and second authentication information sent by its superior key generation center. The second authentication information includes the identity identifier of the superior key generation center, the master signature key, and the master encryption key corresponding to the superior key generation center.

[0081] Then, the target sub-level key generation center verifies whether the identity identifier in the second authentication information is consistent with the identity identifier registered by the target sub-level key generation center's superior key generation center; if they are consistent, the third target signature is verified to confirm the identity information of the target sub-level key generation center's superior key generation center.

[0082] Among them, the SM9 signature verification algorithm can be used to verify the second target signature based on the master key (master signature key) of the upper-level key generation center of the target sub-level key generation center and the identity identifier of the upper-level key generation center of the target sub-level key generation center, so as to confirm the identity information of the upper-level key generation center of the target sub-level key generation center.

[0083] As described above, in a tree-structured hierarchical key system, each level of KGC generates a master signature and a master encryption key pair, and derives a signature private key bound to its identity identifier based on the SM9 algorithm. The lower-level KGC uses its SM9 signature private key to sign its identity information, master public key, and random number and sends an authentication token. The upper-level KGC verifies the legality of the signature and identity identifier to authenticate the lower-level KGC. At the same time, the upper-level KGC can also use a similar mechanism to prove its own identity to the lower-level KGC, realizing two-way identity authentication between each KGC and the upper-level KGC, ensuring that the upper and lower-level KGCs are mutually trustworthy.

[0084] Since the specific implementation process of two-way authentication between each client and its corresponding parent KGC is roughly the same, the following uses the first client as an example to illustrate the specific implementation process of two-way authentication between each client and its corresponding parent KGC.

[0085] First, the first client sends an access authentication request to its superior key generation center. The first client then verifies the identity information of its superior key generation center.

[0086] Specifically, the first client sends an access authentication request to the first client's superior key generation center.

[0087] Upon receiving the access authentication request, the upstream key generation center of the first client signs its own identity, its corresponding master signing key, and its master encryption key based on its own signing private key, generating a fourth target signature and third authentication information containing its own identity, master signing key, and master encryption key. It then sends the fourth target signature and the third authentication information to the first client.

[0088] After receiving the fourth target signature and the third authentication information, the first client verifies whether the identity identifier in the third authentication information matches the identity identifier registered by the first client's superior key generation center. If they match, the third target signature is verified based on the master signature key and the identity identifier corresponding to the first client's superior key generation center to confirm the identity information of the first client's superior key generation center.

[0089] After the first client completes the authentication of the identity information of the first client's parent key generation center, the parent key generation center authenticates the identity information of the first client to determine whether the first client can be added to the hierarchical tree structure.

[0090] Specifically, the first client generates its own private and public keys. Based on these, it generates an auxiliary public key. This auxiliary public key is a unique value that can only be generated using the private key, and it is used by the higher-level KGC for bilinear pairing equality verification. Then, based on its identity, the first client generates a commitment value. It generates a first random number and uses this random number to blind the commitment value, resulting in a blinded commitment.

[0091] Next, the first client sends its identity identifier, public key, auxiliary public key, and blinding commitment to its parent key generation center. Upon receiving the information from the first client, the parent key generation center generates a second random number and sends it back to the first client.

[0092] After receiving the second random number, the first client calculates the response information based on its private key, the first random number, the second random number, and the commitment value, and sends the response information to its upstream key generation center. Upon receiving the response information, the upstream key generation center calculates the common point bound to the first client's identity identifier, and verifies the first client's identity information based on this common point, the response information, the first client's public key, the auxiliary public key, and the blinded commitment.

[0093] As described above, SM9 signatures are used to prove the identity of the terminal to its superior KGC, and zero-knowledge proofs are used to prove the identity of the terminal to its superior KGC. This completes two-way authentication without revealing the private key. Furthermore, the zero-knowledge proof interaction method verifies the identity information of the terminal device, which has low computational load and low communication cost.

[0094] When each KGC within a hierarchical key system needs to perform two-way authentication with its corresponding superior KGC, and each client needs to perform two-way authentication with its corresponding superior KGC, a traceable trust chain is formed as a whole. Subsequently, any two terminal devices in different management domains can use this trust chain, with a common ancestor KGC as the root of trust, and relying on the trust anchoring mechanism that traces the legitimacy of each management domain back to the common ancestor KGC, combined with the SM9 identifier signature verification process, to generate a signature using their own identifier private key. The receiving party obtains the public key of the other party's domain through the hierarchical trust chain and verifies the validity of the signature, thus realizing cross-domain authentication between terminal devices in two different management domains.

[0095] The following is combined Figure 1 This section explains the specific implementation process of cross-domain authentication between terminal devices in two different management domains.

[0096] Figure 1 This is a schematic diagram of a cross-domain authentication system provided in an embodiment of this application; as shown. Figure 1 As shown, the cross-domain authentication system includes a first client, a second client, and a parent key generation center of the first client. The management domains of the first client and the second client are different management domains.

[0097] For example, the first client is located in the medical IoT device domain of hospital A (such as a remote electrocardiogram monitor), and the second client is located in the health data platform domain of disease control center B (such as an epidemic monitoring terminal). When the second client wants to legally collect patient physiological data for public health analysis, it can trigger a cross-domain authentication request to the first client.

[0098] In practice, in response to a cross-domain authentication request triggered by a user to the first client, the second client obtains the master public key of its management domain and, based on its identity, signs the master public key to generate a first target signature. A cross-domain authentication request is then generated based on the second client's identity and the first target signature and sent to the first client. The first client receives the cross-domain authentication request triggered by the second client, which includes the second client's identity and the first target signature used for cross-domain authentication. The first client sends a verification request to its parent key generation center based on the second client's identity. Upon receiving the verification request, the parent key generation center, based on the second client's identity in the verification request, traverses the hierarchical tree structure corresponding to the hierarchical key system from the root key generation center to determine the authentication path to the second client's key generation center. If the authentication path determines that the second client and the first client's management domains share a common trust anchor, the parent key generation center sends the master public key of the second client's management domain to the first client. After receiving the master public key of the management domain where the second client is located, the first client verifies the first target signature based on the master public key of the management domain where the second client is located and the identity identifier of the second client, in order to confirm whether the second client belongs to the management domain it declared.

[0099] In the above scheme, a hierarchical key generation center (KGC) system is constructed. During the cross-domain authentication process, the second client actively provides a first target signature generated based on the master public key of its respective management domain in the cross-domain authentication request. The parent key generation center of the first client dynamically queries the hierarchical tree structure to discover the authentication path and verify the common trust anchor. That is, the common ancestor KGC of the two cross-domain clients is used as the top-level trust anchor, so that any two terminals belonging to different management domains can establish an indirect trust relationship by tracing back to the common ancestor, even if they do not have a direct trust relationship with each other. Furthermore, when it is determined that a trust relationship exists between two cross-domain clients, the master public key of the other domain can be issued as needed. This achieves lightweight cross-domain authentication that does not require a pre-set cross-domain master public key, does not rely on the full participation of a centralized root KGC, and supports automatic trust discovery.

[0100] In practical applications, after the first client authenticates the second client's identity, if the second client then needs to authenticate the first client's identity, the first client obtains the master public key of the management domain to which it belongs. Based on the first client's identity identifier, it signs the master public key of the management domain to generate a fifth target signature. Finally, the first client sends its own identity identifier and the fifth target signature to the second client, so that the second client can verify the second target signature based on the first client's identity identifier to confirm whether the first client belongs to its declared management domain.

[0101] The above embodiments describe the specific implementation process of cross-domain authentication from a system perspective. The following describes the specific implementation process of cross-domain authentication from various execution perspectives.

[0102] Figure 2 A flowchart illustrating a cross-domain authentication method provided in this application embodiment; as follows: Figure 2 As shown, this method is applied to the first client in a tree-structured hierarchical key system. Specifically, the method may include the following steps:

[0103] 201. Receive the cross-domain authentication request triggered by the second client. The cross-domain authentication request includes the identity identifier of the second client and the first target signature used to perform cross-domain authentication on the second client.

[0104] 202. Based on the identity identifier of the second client, send a verification request to the upper-level key generation center of the first client, so that the upper-level key generation center can traverse the tree-like hierarchical structure from the root key generation center downwards based on the identity identifier of the second client to determine the authentication path to the key generation center to which the second client belongs. If it is determined based on the authentication path that the management domains where the second client and the first client are located have a common trust anchor, then send the master public key of the management domain where the second client is located to the first client.

[0105] 203. Based on the public key of the management domain where the second client is located and the identity identifier of the second client, verify the first target signature to confirm whether the second client belongs to the management domain it has declared.

[0106] In this embodiment, the second client and the first client belong to different management domains (for example, the first client belongs to the smart meter management domain of power company A, and the second client belongs to the remote meter reading terminal domain of water company B). When the second client needs to establish secure communication with the first client, it first performs SM9 signing on the master signature key of its management domain based on its own identity ID to generate the first target signature.

[0107] Subsequently, the second client constructs a cross-domain authentication request, which includes at least the identity identifier of the second client and a first target signature used for cross-domain authentication of the second client.

[0108] Next, after receiving the cross-domain authentication request, the first client extracts the identity identifier ID from it, constructs a verification request, and sends it to its directly subordinate parent key generation center (i.e., the KGC to which the first client belongs). This verification request must contain at least the extracted identity identifier ID.

[0109] After receiving the verification request, the upstream key generation center of the first client performs the following operations:

[0110] Starting from the root KGC, traverse the hierarchical tree structure downwards to locate the leaf KGC to which the second client belongs. Construct an authentication path from the root KGC to that leaf KGC (i.e., a trust chain composed of a series of KGC nodes); further determine whether this authentication path and the authentication path of the management domain where the first client is located have a common ancestor KGC (i.e., a common trust anchor).

[0111] If all the above conditions are met, the primary key generation center of the first client obtains the master public key (specifically the master signature key and master encryption key across domains) of the management domain where the second client is located from its key system, and returns the master public key to the first client.

[0112] After receiving the master public key of the management domain of the second client, the first client, combined with the known ID of the second client, invokes the SM9 signature verification algorithm to locally verify the first target signature. If the verification passes, it confirms that the second client was indeed legitimately registered by its declared management domain, and that the first target signature was genuinely generated and has not been tampered with. In other words, both parties are within the same trust system and can establish a trusted session.

[0113] At this point, the first client can continue to engage in subsequent secure data interactions with the second client (such as key negotiation, service calls, etc.).

[0114] In practical applications, if two-way authentication is required, the first client can also send its own identity credentials to the second client, and the second client can confirm the identity information of the second client locally.

[0115] Specifically, in one optional embodiment, the master public key of the management domain to which the first client belongs is obtained. Based on the identity identifier of the first client, the master public key of the management domain to which the first client belongs is signed to generate a second target signature. The identity identifier of the first client and the second target signature are sent to the second client so that the second client can verify the second target signature based on the identity identifier of the first client to confirm whether the first client belongs to its declared management domain.

[0116] Furthermore, in practical applications, before receiving the cross-domain authentication request triggered by the second client, the first client needs to send an access authentication request to its parent key generation center so that the first client and its parent key generation center can perform two-way authentication.

[0117] Specifically, an access authentication request is sent to the upstream key generation center of the first client. This prompts the upstream key generation center to sign its own identity, master signing key, and master encryption key based on its signing private key, generating a third target signature and authentication information containing its own identity, master signing key, and master encryption key. The third target signature and authentication information are then sent to the first client. The identity in the authentication information is verified against the identity registered by the upstream key generation center of the first client. If they match, the third target signature is verified based on the master signing key and the identity corresponding to the upstream key generation center of the first client, thus confirming the identity information of the upstream key generation center of the first client.

[0118] Once the first client confirms the identity information of its superior key generation center, the superior key generation center authenticates the first client's identity. Specifically, it generates the first client's private and public keys; generates an auxiliary public key based on the private and public keys; generates a commitment value based on the first client's identity identifier; generates a first random number; uses the first random number to blind the commitment value, obtaining a blinded commitment; sends the first client's identity identifier, public key, auxiliary public key, and blinded commitment to the first client's superior key generation center, enabling the superior key generation center to generate a second random number; calculates response information based on the private key, the first random number, the second random number, and the commitment value; and sends the response information to the first client's superior key generation center, enabling the superior key generation center to calculate the common point bound to the first client's identity identifier, and verifies the first client's identity information based on the common point, response information, public key, auxiliary public key, and blinded commitment.

[0119] It should be noted that the first target signature, the second target signature, and the third target signature in this application embodiment are not the same as the first target signature, the second target signature, and the third target signature in the above embodiment. Only the terms first, second, etc. are used to represent different signatures.

[0120] In summary, this embodiment constructs a hierarchical key generation center (KGC) system. During cross-domain authentication, the second client proactively provides a first target signature generated based on its own management domain's master public key in the cross-domain authentication request. The first client's parent key generation center dynamically queries the hierarchical tree structure to discover the authentication path and verify the common trust anchor. That is, the common ancestor KGC of the two cross-domain clients is used as the top-level trust anchor, enabling any two terminals belonging to different management domains to establish an indirect trust relationship even if they have no direct trust relationship with each other, by tracing back to the common ancestor. Furthermore, once a trust relationship is determined between the two cross-domain clients, the other party's domain master public key can be issued as needed. This achieves lightweight cross-domain authentication that does not require a pre-set cross-domain master public key, does not rely on the full participation of a centralized root KGC, and supports automatic trust discovery.

[0121] The specific implementation process involved in the embodiments of this application can be referred to the content of the above embodiments, and will not be repeated here.

[0122] Figure 3 A flowchart illustrating another cross-domain authentication method provided in this application embodiment; see attached diagram. Figure 3 As shown, the second client applied to the tree-structured hierarchical key system can specifically include the following steps:

[0123] 301. In response to a cross-domain authentication request triggered by a user to the first client, obtain the master public key of the management domain to which the second client belongs.

[0124] 302. Based on the identity of the second client, sign the public key of the management domain to which the second client belongs to generate the target signature.

[0125] 303. Send the identity identifier and target signature of the second client to the first client so that the first client can confirm with the first client’s superior key generation center whether the second client and the first client’s management domain have a common trust anchor, obtain the master public key of the management domain where the second client is located, and verify the target signature based on the master public key of the management domain where the second client is located and the identity identifier of the second client to confirm whether the second client belongs to the management domain it has declared.

[0126] When a user wishes to initiate an access request to the first client from the second client, the second client first needs to prepare the credentials required for secure communication with the first client. This includes obtaining the master public key (i.e., the master signature public key) of the second client's own management domain. Typically, this master public key is obtained directly or indirectly by the second client from its key generation center, and its consistency and immutability are guaranteed throughout the entire trust chain.

[0127] To prove the identity of the second client and its relationship to the declared management domain, the second client uses its private key to sign information containing its identity identifier and the acquired master public key. The signature algorithm used must meet security requirements, such as SM9 or another suitable identity-based cryptosystem. The generated target signature will serve as crucial evidence for verifying the identity of the second client.

[0128] After receiving the aforementioned information, the first client verifies the identity of the second client through its superior key generation center, following the previously described method (see the description of the first client's processing flow in the Detailed Implementation section). This involves finding a common trust anchor, determining the true identity of the second client, and ultimately verifying the target signature using the master public key of the second client's management domain. If all checks pass, the second client is considered to indeed belong to its declared management domain, and further secure interaction is permitted.

[0129] In this embodiment, a hierarchical key generation center (KGC) system is constructed. During the cross-domain authentication process, the second client actively provides a first target signature generated based on the master public key of its respective management domain in the cross-domain authentication request. The parent key generation center of the first client dynamically queries the hierarchical tree structure to discover the authentication path and verify the common trust anchor. That is, the common ancestor KGC of the two cross-domain clients is used as the top-level trust anchor, so that any two terminals belonging to different management domains can establish an indirect trust relationship by tracing back to the common ancestor, even if they do not have a direct trust relationship with each other. Furthermore, when it is determined that a trust relationship exists between the two cross-domain clients, the master public key of the other domain can be issued as needed. This achieves lightweight cross-domain authentication that does not require a pre-set cross-domain master public key, does not rely on the full participation of a centralized root KGC, and supports automatic trust discovery.

[0130] The specific implementation process involved in the embodiments of this application can be referred to the content of the above embodiments, and will not be repeated here.

[0131] Figure 4 A flowchart illustrating another cross-domain authentication method provided in this application embodiment; see attached document. Figure 4 As shown, the target sub-level key generation center is applied in a tree-structured hierarchical key system. Specifically, the method may include the following steps:

[0132] 401. Receive a verification request sent by the first client. The verification request includes the identity identifier of the second client to be verified.

[0133] 402. Based on the identity of the second client, traverse the tree-like hierarchical structure downwards from the root key generation center to determine the authentication path to the key generation center to which the second client belongs.

[0134] 403. If the authentication path determines that the second client and the first client share a common trust anchor in their respective management domains, then the master public key of the management domain where the second client resides is sent to the first client. This allows the first client to verify the first target signature sent by the second client based on the master public key of the management domain where the second client resides and the identity identifier of the second client, in order to confirm whether the second client belongs to the management domain it has declared.

[0135] When the first client receives a cross-domain authentication request initiated by the second client, in order to verify the authenticity of the second client's identity, it sends a verification request to its parent key generation center or a specific target sub-level key generation center. This request must contain at least the second client's identity identifier ID, so as to facilitate subsequent lookup of the corresponding public key and other necessary authentication information.

[0136] Upon receiving a verification request, the target sub-level key generation center begins its traversal from the root key generation center, descending the hierarchical key hierarchy until it finds the key generation center responsible for managing the second client's identity ID. During this process, the system constructs an authentication path that includes not only information about each level of key generation center but may also include data such as intermediate certificates or master public keys used to establish trust relationships.

[0137] Once it's established that the second client and the first client share a common trust anchor—that is, they both trust a common authority—the target sub-level key generation center will return the master public key of the second client's management domain to the first client. Next, the first client uses the obtained master public key and the second client's identity ID to verify the previously received first target signature. If the signature verification is successful, it indicates that the second client indeed belongs to its declared management domain and its identity is trustworthy.

[0138] In an optional embodiment, before responding to a cross-domain authentication request triggered by a user to a first client, the method further includes: generating a master signature key and a master encryption key corresponding to the target sub-level key generation center; generating a signature private key corresponding to the target sub-level key generation center based on the identity identifier of the target sub-level key generation center; signing the identity identifier of the target sub-level key generation center, the master signature key, and the master encryption key based on the signature private key to generate a second target signature; generating first authentication information containing the identity identifier of the target sub-level key generation center, the master signature key, and the master encryption key; generating an access authentication request based on the second target signature and the first authentication information; and sending the access authentication request to the parent key generation center of the target sub-level key generation center so that the parent key generation center of the target sub-level key generation center can verify whether the identity identifier in the first authentication information is consistent with the identity identifier when the target sub-level key generation center was registered. If the verification is consistent, the second target signature is verified to confirm the identity information of the target sub-level key generation center.

[0139] In an optional embodiment, the method further includes: receiving a third target signature and second authentication information sent by the parent key generation center of the target sub-level key generation center; the second authentication information includes the identity identifier of the parent key generation center of the target sub-level key generation center, the master signature key and the master encryption key corresponding to the parent key generation center of the target sub-level key generation center; verifying whether the identity identifier in the second authentication information is consistent with the identity identifier of the parent key generation center of the target sub-level key generation center during registration; if the verification is consistent, verifying the third target signature to confirm the identity information of the parent key generation center of the target sub-level key generation center.

[0140] In this embodiment, a hierarchical key generation center (KGC) system is constructed. During the cross-domain authentication process, the second client actively provides a first target signature generated based on the master public key of its respective management domain in the cross-domain authentication request. The parent key generation center of the first client dynamically queries the hierarchical tree structure to discover the authentication path and verify the common trust anchor. That is, the common ancestor KGC of the two cross-domain clients is used as the top-level trust anchor, so that any two terminals belonging to different management domains can establish an indirect trust relationship by tracing back to the common ancestor, even if they do not have a direct trust relationship with each other. Furthermore, when it is determined that a trust relationship exists between the two cross-domain clients, the master public key of the other domain can be issued as needed. This achieves lightweight cross-domain authentication that does not require a pre-set cross-domain master public key, does not rely on the full participation of a centralized root KGC, and supports automatic trust discovery.

[0141] The specific implementation process involved in the embodiments of this application can be referred to the content of the above embodiments, and will not be repeated here.

[0142] Furthermore, this tree-structured hierarchical key system utilizes multiple Key Management Centers (KMCs) to achieve cross-domain authentication.

[0143] To facilitate understanding of the cross-domain authentication implementation process described above, examples of cross-domain authentication processes in specific application scenarios will be provided.

[0144] In practical applications, assume that entity A belongs to the smart meter management domain of power company A, and entity B belongs to the remote meter reading terminal domain of water company B. For example... Figure 5 Entity A belongs to KGC7, and entity B belongs to KGC4. When entity B needs to establish secure communication with entity A, entity A and entity B perform two-way cross-domain authentication. In specific implementation:

[0145] Step 1: Build a hierarchical key management system.

[0146] Based on the device authentication environment, a hierarchical tree-structured key system is constructed. This system comprises a root key GC, multiple levels of sub-KGCs, and multiple physical devices. The root KGC is trusted by all other sub-KGCs within the system. Each level represents a first-level KGC, and all leaf nodes in the tree represent terminal devices. Furthermore, each sub-KGC must be authenticated by its parent KGC before it can be considered a valid KGC.

[0147] Step 2: Perform two-way authentication between each sub-KGC in the tree-structured hierarchical key system and its parent KGC.

[0148] Specifically, taking the root KGC and its subordinate KGC1 as an example, we can illustrate the implementation process of two-way authentication between each of its child KGCs and its superior KGC.

[0149] First, the root KGC and the subordinate KGC1 generate their respective master signature and master encryption key pairs.

[0150] Specifically, the generated root KGC master signature key pair is The master encryption key pair is The primary signature key pair for the lower-level KGC1 is... The master encryption key pair is .

[0151] Next, the root KGC and the subordinate KGC1 each generate their own decryption and signing keys based on their own IDs using the SM9 algorithm.

[0152] Specifically, the decryption and signing keys for the root KGC are as follows: , Its subordinate KGC1's decryption private key and signing private key are as follows: , .

[0153] Then, the lower-level KGC1 performs identity verification on the root KGC.

[0154] Specifically, the lower-level KGC1 sends an identifier. Master Signature Public Key Master encryption public key And generate a signature by signing it using your own signing private key. || || , It's a random sequence number. The lower-level KGC1 sends authentication information. || || Give the root KGC.

[0155] Finally, the root KGC identifies the lower-level KGC1.

[0156] Specifically, the value of the ID segment in the Token is checked to see if it is equal to the entity's identifier (the identifier recorded in the database) at the time of registration. The SM9 verification algorithm is then used to verify the correctness of the signature based on the master signature public key and the identity identifier corresponding to KGC1. If the verification is successful, the lower-level KGC1 can authenticate the root KGC.

[0157] Furthermore, the identification of the lower-level KGC by the root KGC is the same as the identification of the root KGC by the lower-level KGC, and can be referred to the specific implementation process described above, which will not be repeated here.

[0158] Step 3: Entity A and Entity B perform two-way authentication with their respective parent KGCs.

[0159] Specifically, taking Entity A as an example, its two-way authentication process will be explained. The authentication process of Terminal A with its superior KGC is as follows:

[0160] First, entity A sends an authentication request to the next higher level, KGC7, and KGC7 sends an identifier. , , And by using their own signing private key to sign it, a corresponding signature is generated. || || , It's the serial number; send authentication information. || || Give it to entity B.

[0161] Entity B checks whether the value of the ID segment in the Token is equal to the entity's identifier and verifies the correctness of the signature. If the verification is successful, the terminal has achieved identity authentication of the upper-level KGC.

[0162] Then, using an interactive zero-knowledge proof method, the authentication process between the superior KGC7 and entity A is as follows:

[0163] Entity A generates a key pair: ,calculate It will be sent to the superior KGC7.

[0164] upper-level KGC7 generation and send Give entity A.

[0165] Entity A calculation And send it to the superior KGC7.

[0166] Upper-level KGC7 calculation ,verify The authentication is successful.

[0167] Step 4: Entity A and Entity B perform cross-domain authentication.

[0168] Specifically, entity A uses its own identifier private key to sign the master public key of the security domain in which entity A resides, generating an SM9 digital signature sigA, and sends the identifier IDA and signature data sigA corresponding to entity A to entity B.

[0169] Entity B requests the authentication path of entity A and the master public keys of each KGC on the authentication path from its superior KGC4. If, based on the authentication path, it is determined that entity A and entity B have a common ancestor KGC1, then it is determined that the security domains KGC4 and KGC7 of entities A and B have established a trust relationship, and the master public key of the security domain of entity A is directly sent to entity B. If the security domains of the two entities have not yet established a trust relationship, then the trust can be established through the above-mentioned inter-security domain authentication method.

[0170] After entity B obtains the master public key of the security domain where entity A is located, it verifies sigA based on the master public key and the identifier corresponding to entity A. Once the verification is successful, it means that entity B has successfully authenticated entity A.

[0171] The process of identifying entity B by entity A is similar to that described above, and will not be repeated here.

[0172] In summary, the authentication process does not require complex calculations and can achieve mutual authentication and key negotiation within the domain with low overhead. This can reduce the computational burden on terminal devices and lower communication costs. At the same time, KGC uses zero-knowledge proof for terminal authentication, which has low computational load and low communication costs.

[0173] The following describes in detail one or more embodiments of the cross-domain authentication apparatus of this application. Those skilled in the art will understand that these apparatuses can all be configured using commercially available hardware components through the steps taught in this solution.

[0174] Figure 6 This is a schematic diagram of a cross-domain authentication device provided in an embodiment of this application, applied to a first client, such as... Figure 6 As shown, the device includes: a receiving module 11, a sending module 12, and a verification module 13.

[0175] The receiving module 11 is used to receive a cross-domain authentication request triggered by the second client. The cross-domain authentication request includes the identity identifier of the second client and a first target signature used to perform cross-domain authentication on the second client.

[0176] The sending module 12 is used to send a verification request to the upper-level key generation center of the first client based on the identity identifier of the second client, so that the upper-level key generation center can traverse the tree-like hierarchical structure downward from the root key generation center based on the identity identifier of the second client to determine the authentication path to the key generation center to which the second client belongs, and if it is determined based on the authentication path that the management domain where the second client and the first client are located have a common trust anchor, then the master public key of the management domain where the second client is located is sent to the first client.

[0177] The verification module 13 is used to verify the first target signature based on the master public key of the management domain where the second client is located and the identity identifier of the second client, so as to confirm whether the second client belongs to the management domain it has declared.

[0178] Optionally, the receiving module 11 is further configured to: obtain the master public key of the management domain to which the first client belongs; sign the master public key of the management domain to which the first client belongs based on the identity identifier of the first client to generate a second target signature; send the identity identifier of the first client and the second target signature to the second client, so that the second client verifies the second target signature based on the identity identifier of the first client to confirm whether the first client belongs to the management domain it has declared.

[0179] Optionally, before receiving the cross-domain authentication request triggered by the second client, the receiving module 11 is further configured to: send an access authentication request to the upper-level key generation center of the first client, so that the upper-level key generation center of the first client signs its own identity identifier, master signing key, and master encryption key based on the signing private key, generates a third target signature, and generates authentication information containing its own identity identifier, master signing key, and master encryption key, and sends the third target signature and the authentication information to the first client; verify whether the identity identifier in the authentication information is consistent with the identity identifier registered by the upper-level key generation center of the first client; if the verification is consistent, verify the third target signature based on the master signing key corresponding to the upper-level key generation center of the first client and the identity identifier corresponding to the upper-level key generation center of the first client, so as to confirm the identity information of the upper-level key generation center of the first client.

[0180] Optionally, the receiving module 11 is further configured to: generate a private key and a public key of the first client; generate an auxiliary public key based on the private key and the public key; generate a commitment value based on the identity identifier of the first client; generate a first random number, and use the first random number to blind the commitment value to obtain a blinded commitment; send the identity identifier of the first client, the public key, the auxiliary public key, and the blinded commitment to the upper-level key generation center of the first client, so that the upper-level key generation center of the first client generates a second random number; calculate response information based on the private key, the first random number, the second random number, and the commitment value; send the response information to the upper-level key generation center of the first client, so that the upper-level key generation center of the first client calculates a common point bound to the identity identifier of the first client, and verifies the identity information of the first client based on the common point, the response information, the public key, the auxiliary public key, and the blinded commitment. Figure 6 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0181] In one possible design, the above Figure 6 The cross-domain authentication device shown can be implemented as an electronic device, such as... Figure 7 As shown, the electronic device may include: a memory 21, a processor 22, and a communication interface 23. The memory 21 stores executable code, which, when executed by the processor 22, enables the processor 22 to at least implement the cross-domain authentication method provided in the foregoing embodiments.

[0182] Figure 8This is a schematic diagram of another cross-domain authentication device provided in an embodiment of this application, applied to a second client, such as... Figure 8 As shown, the device includes: an acquisition module 31, a signature module 32, and a sending module 33.

[0183] The acquisition module 31 is used to obtain the master public key of the management domain to which the second client belongs in response to the cross-domain authentication request triggered by the user to the first client.

[0184] The signature module 32 is used to sign the public key of the management domain to which the second client belongs based on the identity identifier of the second client, and generate the target signature.

[0185] The sending module 33 is used to send the identity identifier of the second client and the target signature to the first client, so that the first client can confirm whether the second client and the management domain where the first client is located have a common trust anchor through the upper-level key generation center of the first client, obtain the master public key of the management domain where the second client is located, and verify the target signature based on the master public key of the management domain where the second client is located and the identity identifier of the second client to confirm whether the second client belongs to the management domain it declared.

[0186] Figure 8 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0187] In one possible design, the above Figure 8 The cross-domain authentication device shown can be implemented as an electronic device, such as... Figure 9 As shown, the electronic device may include: a memory 41, a processor 42, and a communication interface 43. The memory 41 stores executable code, which, when executed by the processor 42, enables the processor 42 to at least implement the cross-domain authentication method provided in the foregoing embodiments.

[0188] Figure 10 This is a schematic diagram of another cross-domain authentication device provided in an embodiment of this application, applied at the verification end, such as... Figure 9 As shown, the device includes: a receiving module 51, a determining module 52, and a sending module 53.

[0189] The receiving module 51 is used to receive a verification request sent by the first client, the verification request including the identity identifier of the second client to be verified.

[0190] The determination module 52 is used to determine the authentication path to the key generation center of the second client by traversing the tree-like hierarchical structure downward from the root key generation center based on the identity identifier of the second client.

[0191] The sending module 53 is configured to send the master public key of the management domain where the second client is located to the first client if it is determined based on the authentication path that the second client and the management domain where the first client is located have a common trust anchor, so that the first client can verify the first target signature sent by the second client based on the master public key of the management domain where the second client is located and the identity identifier of the second client, so as to confirm whether the second client belongs to the management domain it declared.

[0192] Optionally, before receiving the verification request sent by the first client, the receiving module 51 is further configured to: generate a master signature key and a master encryption key corresponding to the target sub-level key generation center; generate a signature private key corresponding to the target sub-level key generation center based on the identity identifier of the target sub-level key generation center; sign the identity identifier of the target sub-level key generation center, the master signature key, and the master encryption key corresponding to the target sub-level key generation center based on the signature private key to generate a second target signature; generate first authentication information containing the identity identifier of the target sub-level key generation center, the master signature key, and the master encryption key corresponding to the target sub-level key generation center; generate an access authentication request based on the second target signature and the first authentication information; and send the access authentication request to the upper-level key generation center of the target sub-level key generation center so that the upper-level key generation center of the target sub-level key generation center can verify whether the identity identifier in the first authentication information is consistent with the identity identifier when the target sub-level key generation center is registered. If the verification is consistent, the second target signature is verified to confirm the identity information of the target sub-level key generation center.

[0193] Optionally, the receiving module 51 is further configured to: receive a third target signature and second authentication information sent by the upper-level key generation center of the target sub-level key generation center; the second authentication information includes the identity identifier of the upper-level key generation center of the target sub-level key generation center, the master signature key and the master encryption key corresponding to the upper-level key generation center of the target sub-level key generation center; verify whether the identity identifier in the second authentication information is consistent with the identity identifier of the upper-level key generation center of the target sub-level key generation center during registration; if the verification is consistent, verify the third target signature to confirm the identity information of the upper-level key generation center of the target sub-level key generation center.

[0194] Figure 10The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0195] In one possible design, the above Figure 10 The cross-domain authentication device shown can be implemented as an electronic device, such as... Figure 11 As shown, the electronic device may include: a memory 61, a processor 62, and a communication interface 63. The memory 61 stores executable code, which, when executed by the processor 62, enables the processor 62 to at least implement the cross-domain authentication method provided in the foregoing embodiments.

[0196] Furthermore, this application embodiment also provides a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the cross-domain authentication method provided in the foregoing embodiments.

[0197] In addition, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, enable the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by a computer program or instructions.

[0198] In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0199] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0200] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. This application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0201] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A cross-domain authentication method, characterized in that, A first client applied to a tree-structured hierarchical key system, the tree-structured hierarchical key system including a root key generation center, multiple sub-level key generation centers, and multiple clients, the multiple clients including the first client; the method includes: Receive a cross-domain authentication request triggered by a second client, the cross-domain authentication request including the identity identifier of the second client and a first target signature for cross-domain authentication of the second client; Based on the identity identifier of the second client, a verification request is sent to the upper-level key generation center of the first client. This allows the upper-level key generation center to traverse the hierarchical tree structure downwards from the root key generation center based on the identity identifier of the second client, determine the authentication path to the key generation center to which the second client belongs, and if the authentication path determines that the management domains of the second client and the first client share a common trust anchor, then the master public key of the management domain of the second client is sent to the first client. The common trust anchor is the ancestral key generation center shared by the first client and the second client when tracing their respective authentication paths upwards in the hierarchical key system. Based on the master public key of the management domain where the second client resides and the identity identifier of the second client, the first target signature is verified to confirm whether the second client belongs to the management domain it has declared.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the master public key of the management domain to which the first client belongs; Based on the identity identifier of the first client, the master public key of the management domain to which the first client belongs is signed to generate a second target signature; The identity identifier of the first client and the second target signature are sent to the second client so that the second client can verify the second target signature based on the identity identifier of the first client to confirm whether the first client belongs to its declared management domain.

3. The method according to claim 1, characterized in that, Before receiving the cross-domain authentication request triggered by the second client, the method further includes: Send an access authentication request to the upper-level key generation center of the first client, so that the upper-level key generation center of the first client signs its own identity, master signing key and master encryption key based on the signing private key, generates a third target signature and generates authentication information containing its own identity, master signing key and master encryption key, and sends the third target signature and the authentication information to the first client; Verify whether the identity identifier in the authentication information is consistent with the identity identifier registered by the first client's superior key generation center; If the verification matches, the third target signature is verified based on the master signature key corresponding to the first client's superior key generation center and the identity identifier corresponding to the first client's superior key generation center, in order to confirm the identity information of the first client's superior key generation center.

4. The method according to claim 3, characterized in that, The method further includes: Generate the private and public keys for the first client; Generate an auxiliary public key based on the private key and the public key; A commitment value is generated based on the identity identifier of the first client; Generate a first random number, and use the first random number to blind the commitment value to obtain a blinded commitment; The identity identifier of the first client, the public key, the auxiliary public key, and the blinding commitment are sent to the upper-level key generation center of the first client, so that the upper-level key generation center of the first client generates a second random number; Calculate the response information based on the private key, the first random number, the second random number, and the commitment value; The response information is sent to the upper-level key generation center of the first client, so that the upper-level key generation center of the first client calculates the common point bound to the identity identifier of the first client, and verifies the identity information of the first client based on the common point, the response information, the public key, the auxiliary public key, and the blind commitment.

5. A cross-domain authentication method, characterized in that, A second client is applied to a tree-structured hierarchical key system, the tree-structured hierarchical key system including a root key generation center, multiple sub-level key generation centers, and multiple clients, the multiple clients including the second client; the method includes: In response to a cross-domain authentication request triggered by a user to the first client, obtain the master public key of the management domain to which the second client belongs; Based on the identity of the second client, the master public key of the management domain to which the second client belongs is signed to generate the target signature; The identity identifier of the second client and the target signature are sent to the first client, so that the first client can confirm whether the second client and the management domain of the first client have a common trust anchor through the first client's superior key generation center, obtain the master public key of the management domain of the second client, and verify the target signature based on the master public key of the management domain of the second client and the identity identifier of the second client to confirm whether the second client belongs to the management domain it declared. The common trust anchor is the ancestor key generation center shared by the first client and the second client when tracing their respective authentication paths upwards in the tree-structured hierarchical key system.

6. A cross-domain authentication method, characterized in that, A target sub-level key generation center is applied to a tree-structured hierarchical key system, wherein the tree-structured hierarchical key system includes a root key generation center, multiple sub-level key generation centers, and multiple clients, wherein the multiple sub-level key generation centers include the target sub-level key generation center; the method includes: Receive a verification request sent by a first client, the verification request including the identity identifier of the second client to be verified; Based on the identity of the second client, the tree-like hierarchical structure is traversed downwards from the root key generation center to determine the authentication path to the key generation center to which the second client belongs; If it is determined based on the authentication path that the second client and the first client share a common trust anchor in their respective management domains, then the master public key of the management domain where the second client is located is sent to the first client, so that the first client can verify the first target signature sent by the second client based on the master public key of the management domain where the second client is located and the identity identifier of the second client, in order to confirm whether the second client belongs to the management domain it has declared. The common trust anchor is the ancestor key generation center shared by the first client and the second client when tracing their respective authentication paths upwards in the tree-structured hierarchical key system.

7. The method according to claim 6, characterized in that, Before receiving the verification request sent by the first client, the method further includes: Generate the master signature key and master encryption key corresponding to the target sub-level key generation center; Generate a signature private key corresponding to the target sub-level key generation center based on the identity identifier of the target sub-level key generation center; Based on the signature private key, the identity identifier of the target sub-level key generation center, the master signature key and the master encryption key corresponding to the target sub-level key generation center are signed to generate a second target signature; Generate first authentication information that includes the identity identifier of the target sub-level key generation center, the master signature key and the master encryption key corresponding to the target sub-level key generation center; An access authentication request is generated based on the second target signature and the first authentication information; The access authentication request is sent to the parent key generation center of the target sub-level key generation center, so that the parent key generation center of the target sub-level key generation center can verify whether the identity identifier in the first authentication information is consistent with the identity identifier when the target sub-level key generation center is registered. If the verification is consistent, the second target signature is verified to confirm the identity information of the target sub-level key generation center.

8. The method according to claim 7, characterized in that, The method further includes: The system receives a third target signature and a second authentication information sent by the upper-level key generation center of the target sub-level key generation center; the second authentication information includes the identity identifier of the upper-level key generation center of the target sub-level key generation center, the master signature key and the master encryption key corresponding to the upper-level key generation center of the target sub-level key generation center; Verify whether the identity identifier in the second authentication information is consistent with the identity identifier registered with the upper-level key generation center of the target sub-level key generation center; If the verification matches, then the third target signature is verified to confirm the identity information of the upper-level key generation center of the target sub-level key generation center.

9. An electronic device, characterized in that, include: The system includes a memory, a processor, and a communication interface; wherein the memory stores executable code, which, when executed by the processor, causes the processor to perform the cross-domain authentication method as described in any one of claims 1 to 4, 5, or 6-8.

10. A non-transitory machine-readable storage medium, characterized in that, The non-transitory machine-readable storage medium stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the cross-domain authentication method as claimed in any one of claims 1 to 4, 5, or 6-8.

Images