Cross-Domain Trust Identity Authentication Method and System Based on Consortium Blockchain

Abstract

The present invention relates to the field of information security technology, and discloses a cross-domain trust identity authentication method and system based on a consortium chain. The method comprises: upon receiving a registration request sent by a user from a first trust domain, generating a user blockchain certificate through a certificate issuing authority according to a preset blockchain certificate format and verified target user information, uploading the user blockchain certificate to a blockchain through a consortium chain server, and upon detecting that a user sends a cross-domain communication request to a service provider, the service provider verifies the legitimacy of the user signature, user blockchain certificate, and the issuing authority that generates the user blockchain certificate according to the cross-domain communication request and through the consortium chain server. When the legitimacy verification passes, it is determined that the service provider has successfully authenticated the user. It can be seen that the implementation of the present invention can help reduce the cost of digital certificate management and maintenance, and ensure that the certificate is trustworthy, controllable, and traceable throughout the entire process from source to storage and sharing.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a cross-domain trust identity authentication method and system based on an alliance chain. Background Art

[0002] In the field of Internet and blockchain technology, due to the current problems of long cross-domain authentication paths, difficult certificate path retrieval, and excessive CA authority, authentication complexity has increased, system paralysis or downtime has occurred, seriously affecting the security of PKI systems. Although existing cross-domain authentication technologies reduce the number of signature verifications, they require cumbersome operations and cannot circumvent problems such as lengthy certificate links and complicated revocation mechanisms, making practical applications cumbersome and lacking flexibility.

[0003] To address the shortcomings of existing technologies, blockchain technology is being leveraged to address the long cross-domain authentication paths, prevent single-point CA attacks, and simplify digital certificate management, aiming to enhance innovation in digital identity authentication. Leveraging blockchain technology for cross-domain authentication simplifies the authentication process, introduces multi-signature authentication and privacy protection, reduces complexity, and enhances the security of PKI systems. Furthermore, the use of smart contracts automates the management of digital certificates, reducing management costs. These measures are driving the development of digital identity authentication technology and laying the foundation for building a more secure and efficient digital identity authentication system.

[0004] Therefore, a cross-domain trust identity authentication method and system based on alliance chain is provided, which can simplify the identity authentication process, introduce multi-signature and privacy protection, reduce the complexity of cross-domain authentication, enhance the security of PKI system, and use smart contracts to automatically manage digital certificates, thereby helping to reduce the cost of digital certificate management and maintenance, and ensure that the certificates are trustworthy, controllable and traceable from the source to storage and sharing. Summary of the Invention

[0005] The present invention provides a method and system for cross-domain trust identity authentication based on alliance chain, which can help reduce the cost of digital certificate management and maintenance, improve authentication efficiency and simplify authentication operation procedures, enhance the flexibility of the authentication system, and ensure that the certificate is trustworthy, controllable and traceable throughout the entire process from source to storage sharing.

[0006] In order to solve the above technical problems, the first aspect of the present invention discloses a cross-domain trust identity authentication method based on a consortium chain, which is applied to a PKI system. The PKI system includes at least a first trust domain and a second trust domain. The method includes:

[0007] When receiving a registration request sent by a user from the first trust domain, sending the user information included in the registration request to the registration server;

[0008] Verify the user information through the registration server, obtain the verified target user information, and send the target user information to the certificate issuing authority;

[0009] Generate a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information;

[0010] Send the user blockchain certificate to the alliance chain server, upload the user blockchain certificate to the blockchain through the alliance chain server, and send the user blockchain certificate and the height ID of the user blockchain certificate on the blockchain to the user;

[0011] When it is detected that a user of the first trust domain sends a cross-domain communication request to a service provider of the second trust domain, the user signature of the user, the user blockchain certificate, and the issuing authority that generated the user blockchain certificate are verified according to the cross-domain communication request through the alliance chain server. If the legitimacy verification passes, it is determined that the service provider has successfully authenticated the user;

[0012] The cross-domain communication request includes the user's blockchain certificate, the height ID, the user's digital signature and timestamp.

[0013] As an optional implementation, in the first aspect of the present invention, the preset blockchain certificate format is determined as follows:

[0014] Determine the initial blockchain certificate format based on the X.509 standard certificate format;

[0015] Deleting the signature, basic constraints, name constraints, and certificate revocation list included in the initial blockchain certificate format to obtain the preset blockchain certificate format;

[0016] The preset blockchain certificate format includes: version number, certificate identifier, timestamp, issuer name, certificate validity period, subject name, subject public key, extension content, and certificate hash value.

[0017] As an optional implementation, in the first aspect of the present invention, the user information includes at least: the user's IP address, user identification information, and user email information;

[0018] The step of verifying the user information through the registration server, obtaining verified target user information, and sending the target user information to a certificate issuing authority includes:

[0019] Perform identity consistency verification on the user's signature through the registration server and according to the signature verification review mechanism. When the identity consistency verification passes, generate the verified target user information, and send the obtained target user information and the user's public key to the certificate authority;

[0020] The step of generating a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information includes:

[0021] According to the preset blockchain certificate format, the target user information and the user's public key, the user's blockchain certificate is generated locally by the certificate issuing authority, and the user's blockchain certificate is signed to obtain the user blockchain certificate.

[0022] As an optional implementation, in the first aspect of the present invention, sending the user blockchain certificate to the alliance chain server, and uploading the user blockchain certificate to the blockchain through the alliance chain server, includes:

[0023] Send the user blockchain certificate to a root certificate authority, and send the root blockchain certificate, timestamp, and user blockchain certificate of the root certificate authority to a non-consensus node in the alliance chain server through the root certificate authority;

[0024] When the non-consensus node receives the root blockchain certificate, timestamp, and user blockchain certificate of the root certificate authority, the non-consensus node verifies the root blockchain certificate sent by the root certificate authority;

[0025] When the root blockchain certificate passes verification, the user blockchain certificate and the issuance status of the user blockchain certificate are uploaded to the blockchain;

[0026] The method further comprises:

[0027] Storing the root blockchain certificate and the user blockchain certificate and their status in the block body through the non-consensus node;

[0028] When it is detected that the root blockchain certificate and the user blockchain certificate stored in the block body reach a preset number, assembling the block body including the plurality of root blockchain certificates and the user blockchain certificates into a block through a non-consensus node, and sending the block to a consensus node;

[0029] When the consensus node receives the block, it reaches a consensus on the block according to the built-in consensus algorithm. When the block consensus is completed, the block is stored in the blockchain.

[0030] As an optional implementation manner, in the first aspect of the present invention, the cross-domain communication request and the legitimacy verification of the user signature of the user, the user blockchain certificate and the issuing authority that generates the user blockchain certificate are performed through the alliance chain server, and when the legitimacy verification passes, it is determined that the service provider has authenticated the user, including:

[0031] Verifying the user's digital signature through the service provider;

[0032] When the user's digital signature is verified to be signed by the user, the user's blockchain certificate is sent to the non-consensus node of the alliance chain server through the service provider;

[0033] When the non-consensus node receives the user blockchain certificate, querying the blockchain via the non-consensus node whether the user blockchain certificate is valid;

[0034] When the user blockchain certificate is found to be valid, the number of illegal certificates issued by the target certificate issuing authority corresponding to the user blockchain certificate is queried through the certificate issuing authority behavior audit list;

[0035] Determining the credibility of the target certificate issuing authority based on the number of issued illegal certificates, and judging whether the credibility is greater than or equal to a preset credibility threshold;

[0036] When it is determined that the credibility is greater than or equal to a preset credibility threshold, the service provider verifies whether the root blockchain certificate of the root certificate authority is valid. When it is verified that the root blockchain certificate of the root certificate authority is valid, it is determined that the service provider has successfully authenticated the user.

[0037] As an optional implementation manner, in the first aspect of the present invention, determining the credibility of the target certificate authority based on the number of issued illegal certificates includes:

[0038] Determining the credibility of the target certificate authority based on a preset certificate authority credibility algorithm and the number of issued illegal certificates;

[0039] The calculation formula of the certificate authority credibility algorithm is:

[0040]

[0041] described Indicates the trustworthiness of the target certificate authority. It is represented as the time decay function of the target certificate authority under review in the current operation, Indicates the time period for issuing a certificate to the target certificate authority. represents the probability of issuing a legitimate certificate for the target certificate authority, Represented as the preset first weight, the Represented as the preset second weight, the Indicates the number of certificates issued;

[0042] described The calculation formula is:

[0043]

[0044] described Expressed as the attenuation factor, the Indicates the time period for the target certificate authority to issue the certificate. Represents the current moment;

[0045] described The calculation formula is:

[0046]

[0047] described Indicates the total number of certificates issued for the target certificate authority. Indicates the number of valid certificates issued by the target certificate authority.

[0048] As an optional embodiment, in the first aspect of the present invention, verifying by the service provider whether the root blockchain certificate of the root certificate authority is valid, and when the verification is valid, determining that the service provider has successfully authenticated the user, includes:

[0049] Parsing the user blockchain certificate through the service provider, confirming the root certificate authority of the first trust domain where the user is located through the user blockchain certificate, and sending an application request for a root blockchain certificate to the root certificate authority;

[0050] When the root certificate authority of the first trust domain receives the application request from the service provider, the root certificate authority determines whether the certificate authority of the user blockchain certificate is a certificate authority in the first trust domain where the user is located, and if it is determined that the certificate authority is a certificate authority in the first trust domain where the user is located, the root certificate authority is sent to the service provider;

[0051] Querying the non-consensus node of the alliance chain server through a service provider to determine whether the root blockchain certificate of the root certificate authority in the first trust domain exists;

[0052] When it is queried that the root blockchain certificate of the root certificate authority in the first trust domain exists, it is determined that the service provider has successfully authenticated the user.

[0053] A second aspect of the present invention discloses a cross-domain trust identity authentication system based on an alliance chain, which is applied to a PKI system. The PKI system includes at least a first trust domain and a second trust domain. The system includes:

[0054] a sending module, configured to, upon receiving a registration request sent by a user from the first trust domain, send the user information included in the registration request to a registration server;

[0055] A verification module, configured to verify the user information sent by the sending module through a registration server to obtain verified target user information;

[0056] The sending module is further configured to send the target user information to a certificate issuing authority;

[0057] A generating module, configured to generate a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information sent by the sending module;

[0058] The sending module is further configured to send the user blockchain certificate generated by the generating module to the alliance chain server;

[0059] An on-chain module, configured to upload the user blockchain certificate sent by the sending module to the blockchain through the alliance chain server;

[0060] The sending module is further configured to send the user blockchain certificate and the height ID of the user blockchain certificate on the blockchain to the user;

[0061] The verification module is further configured to, when detecting that a user of the first trust domain sends a cross-domain communication request to a service provider of the second trust domain, perform legitimacy verification on the user signature of the user, the user blockchain certificate uploaded by the uplink module, and the issuing authority that generated the user blockchain certificate according to the cross-domain communication request and through the alliance chain server; and when the legitimacy verification passes, determine that the service provider has authenticated the user;

[0062] The cross-domain communication request includes the user's blockchain certificate, the height ID, the user's random number signature and timestamp.

[0063] As an optional implementation, in the second aspect of the present invention, the preset blockchain certificate format is determined as follows:

[0064] Determine the initial blockchain certificate format based on the X.509 standard certificate format;

[0065] Deleting the signature, basic constraints, name constraints, and certificate revocation list included in the initial blockchain certificate format to obtain the preset blockchain certificate format;

[0066] The preset blockchain certificate format includes: version number, certificate identifier, timestamp, issuer name, certificate validity period, subject name, subject public key, extension content, and certificate hash value.

[0067] As an optional implementation, in the second aspect of the present invention, the user information includes at least: the user's IP address, user identification information, and user email information;

[0068] The verification module verifies the user information through the registration server, and obtains the verified target user information in the following specific manner:

[0069] Performing identity consistency verification on the user's signature through the registration server and according to the signature verification review mechanism, and generating verified target user information when the identity consistency verification passes;

[0070] The specific manner in which the sending module sends the target user information to the certificate issuing authority is as follows:

[0071] Sending the obtained target user information and the user's public key to a certificate authority;

[0072] The specific method in which the generation module generates a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information is as follows:

[0073] According to the preset blockchain certificate format, the target user information and the user's public key, the user's blockchain certificate is generated locally by the certificate issuing authority, and the user's blockchain certificate is signed to obtain the user blockchain certificate.

[0074] As an optional implementation, in the second aspect of the present invention, the specific manner in which the sending module sends the user blockchain certificate to the consortium chain server is:

[0075] Send the user blockchain certificate to a root certificate authority, and send the root blockchain certificate, timestamp, and user blockchain certificate of the root certificate authority to a non-consensus node in the alliance chain server through the root certificate authority;

[0076] The specific method in which the on-chain module uploads the user blockchain certificate to the blockchain through the alliance chain server is:

[0077] When the non-consensus node receives the root blockchain certificate, timestamp, and user blockchain certificate of the root certificate authority, the non-consensus node verifies the root blockchain certificate sent by the root certificate authority;

[0078] When the root blockchain certificate passes verification, the user blockchain certificate and the issuance status of the user blockchain certificate are uploaded to the blockchain;

[0079] The system further comprises:

[0080] A storage module, configured to store the root blockchain certificate and the user blockchain certificate sent by the sending module and their status in a block body through the non-consensus node;

[0081] an assembling module, configured to assemble the block bodies including the plurality of root blockchain certificates and the user blockchain certificates into a block through a non-consensus node when detecting that the number of the root blockchain certificates and the user blockchain certificates stored in the block body by the storage module reaches a preset number;

[0082] The sending module is further configured to send the block assembled by the assembling module to a consensus node;

[0083] A consensus module, configured to reach a consensus on the block through the consensus node and according to a built-in consensus algorithm when the consensus node receives the block sent by the sending module;

[0084] The storage module is further configured to store the block in the blockchain after the consensus module reaches consensus on the block.

[0085] As an optional embodiment, in the second aspect of the present invention, the verification module performs legitimacy verification on the user signature of the user, the user blockchain certificate, and the issuing authority that generates the user blockchain certificate according to the cross-domain communication request and through the alliance chain server. When the legitimacy verification passes, the specific method of determining whether the service provider has authenticated the user is as follows:

[0086] Verifying the user's digital signature through the service provider;

[0087] When the user's digital signature is verified to be signed by the user, the user's blockchain certificate is sent to the non-consensus node of the alliance chain server through the service provider;

[0088] When the non-consensus node receives the user blockchain certificate, querying the blockchain via the non-consensus node whether the user blockchain certificate is valid;

[0089] When the user blockchain certificate is found to be valid, the number of illegal certificates issued by the target certificate issuing authority corresponding to the user blockchain certificate is queried through the certificate issuing authority behavior audit list;

[0090] Determining the credibility of the target certificate issuing authority based on the number of issued illegal certificates, and judging whether the credibility is greater than or equal to a preset credibility threshold;

[0091] When it is determined that the credibility is greater than or equal to a preset credibility threshold, the service provider verifies whether the root blockchain certificate of the root certificate authority is valid. When it is verified that the root blockchain certificate of the root certificate authority is valid, it is determined that the service provider has successfully authenticated the user.

[0092] As an optional implementation, in the second aspect of the present invention, the verification module determines the credibility of the target certificate authority based on the number of issued illegal certificates in the following specific manner:

[0093] Determining the credibility of the target certificate authority based on a preset certificate authority credibility algorithm and the number of issued illegal certificates;

[0094] The calculation formula of the certificate authority credibility algorithm is:

[0095]

[0096] described Indicates the trustworthiness of the target certificate authority. It is represented as the time decay function of the target certificate authority under review in the current operation, Indicates the time period for issuing a certificate to the target certificate authority. represents the probability of issuing a legitimate certificate for the target certificate authority, Represented as the preset first weight, Represented as the preset second weight, the Indicates the number of certificates issued;

[0097] described The calculation formula is:

[0098]

[0099] described Expressed as the attenuation factor, the Indicates the time period for the target certificate authority to issue the certificate. Represents the current moment;

[0100] described The calculation formula is:

[0101]

[0102] described Indicates the total number of certificates issued for the target certificate authority. Indicates the number of valid certificates issued by the target certificate authority.

[0103] As an optional embodiment, in the second aspect of the present invention, the verification module verifies whether the root blockchain certificate of the root certificate authority is valid through the service provider. When the verification is valid, the specific manner of determining whether the service provider has authenticated the user is as follows:

[0104] Parsing the user blockchain certificate through the service provider, confirming the root certificate authority of the first trust domain where the user is located through the user blockchain certificate, and sending an application request for a root blockchain certificate to the root certificate authority;

[0105] When the root certificate authority of the first trust domain receives the application request from the service provider, the root certificate authority determines whether the certificate authority of the user blockchain certificate is a certificate authority in the first trust domain where the user is located, and if it is determined that the certificate authority is a certificate authority in the first trust domain where the user is located, the root certificate authority is sent to the service provider;

[0106] Querying the non-consensus node of the alliance chain server through a service provider to determine whether the root blockchain certificate of the root certificate authority in the first trust domain exists;

[0107] When it is queried that the root blockchain certificate of the root certificate authority in the first trust domain exists, it is determined that the service provider has successfully authenticated the user.

[0108] The third aspect of the present invention discloses another cross-domain trust identity authentication system based on the alliance chain, the system comprising:

[0109] a memory storing executable program code;

[0110] a processor coupled to the memory;

[0111] The processor calls the executable program code stored in the memory to execute the cross-domain trust identity authentication method based on the alliance chain disclosed in the first aspect of the present invention.

[0112] The fourth aspect of the present invention discloses a computer storage medium, which stores computer instructions. When the computer instructions are called, they are used to execute the cross-domain trust identity authentication method based on the alliance chain disclosed in the first aspect of the present invention.

[0113] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0114] The present invention provides a cross-domain trust identity authentication method and system based on alliance chain, which includes: when receiving a registration request sent by a user from a first trust domain, generating a user blockchain certificate through a certificate issuing authority according to a preset blockchain certificate format and target user information after verification, which can separate registration from auditing and utilize the inherent characteristics of blockchain to effectively reduce the possibility of data being tampered with during transmission; and sending the user blockchain certificate to an alliance chain server, reaching a consensus on the user blockchain certificate through the alliance chain server and uploading it to the blockchain, and sending the user blockchain certificate and the user blockchain certificate's height ID on the blockchain to the user; and when it is detected that the user sends a cross-domain communication request to the service provider, performing legitimacy verification on the user signature, user blockchain certificate and the issuing authority that generates the user blockchain certificate according to the cross-domain communication request and through the alliance chain server, when the legitimacy verification passes, determining that the service provider has authenticated the user, and by separating registration from auditing, it is possible to reduce the computer load of the server and thus avoid causing a single point failure of the server, and also to prevent malicious downtime of the server. It can be seen that the implementation of the present invention can reduce the complexity of cross-domain authentication, enhance the security of the PKI system, and utilize smart contracts to automatically manage digital certificates, thereby helping to reduce the cost of digital certificate management and maintenance, improve authentication efficiency and simplify authentication operation procedures, enhance the flexibility of the authentication system, and ensure that the certificates are trustworthy, controllable, and traceable from the source to storage and sharing. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0116] Figure 1 This is a flow chart of a cross-domain trust identity authentication method based on a consortium chain disclosed in an embodiment of the present invention;

[0117] Figure 2 This is a schematic diagram of an entity name description of a PKI system disclosed in an embodiment of the present invention;

[0118] Figure 3 This is a schematic diagram of a blockchain certificate description disclosed in an embodiment of the present invention;

[0119] Figure 4 This is an overall architecture diagram of a cross-domain trust method based on alliance chain disclosed in an embodiment of the present invention;

[0120] Figure 5 This is a timing diagram of alliance chain certificate registration disclosed in an embodiment of the present invention;

[0121] Figure 6 This is a timing diagram of a service provider verifying a user disclosed in an embodiment of the present invention;

[0122] Figure 7 This is a timing diagram for verifying a root certificate authority certificate disclosed in an embodiment of the present invention;

[0123] Figure 8 This is a flow chart of another cross-domain trust identity authentication method based on alliance chain disclosed in an embodiment of the present invention;

[0124] Figure 9 This is a schematic diagram of the structure of a cross-domain trust identity authentication system based on a consortium chain disclosed in an embodiment of the present invention;

[0125] Figure 10 This is a structural diagram of another cross-domain trust identity authentication system based on alliance chain disclosed in an embodiment of the present invention;

[0126] Figure 11 This is a structural diagram of another cross-domain trust identity authentication system based on alliance chain disclosed in an embodiment of the present invention. DETAILED DESCRIPTION

[0127] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0128] The terms "first," "second," and so on, in the description and claims of the present invention and the accompanying drawings are used to distinguish between different items, not to describe a specific order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or end comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or end.

[0129] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute a separate or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0130] The present invention discloses a cross-domain trust identity authentication method and system based on alliance chain, which can generate a user blockchain certificate through a certificate issuing authority according to a preset blockchain certificate format and the target user information after verification when receiving a registration request sent by a user from a first trust domain, and can separate registration from auditing, and effectively reduce the possibility of data being tampered with during transmission by utilizing the inherent characteristics of blockchain; and send the user blockchain certificate to the alliance chain server, reach a consensus on the user blockchain certificate through the alliance chain server and upload it to the blockchain, and send the user blockchain certificate and the height ID of the user blockchain certificate in the blockchain to the user, and when the user is detected When a user sends a cross-domain communication request to a service provider, the user's signature, user blockchain certificate, and the issuing authority that generated the user blockchain certificate are verified for legitimacy based on the cross-domain communication request through the consortium chain server. If the legitimacy verification passes, the service provider is deemed to have authenticated the user. By separating registration and auditing, the server's computer load can be reduced, thereby avoiding single points of failure on the server and preventing malicious server downtime. This helps reduce the cost of digital certificate management and maintenance, improves authentication efficiency, simplifies authentication operations, enhances the flexibility of the authentication system, and ensures that certificates are trustworthy, controllable, and traceable from source to storage and sharing. The following details each of these.

[0131] Example 1

[0132] See also Figure 1 , Figure 1 This is a flow chart of a cross-domain trust identity authentication method based on alliance chain disclosed in an embodiment of the present invention. Figure 1The described cross-domain trust identity authentication method based on alliance chain can be applied to a cross-domain trust identity authentication system based on alliance chain, and the system is applied to a PKI system, the PKI system includes at least a PKI entity domain and an alliance chain entity (alliance chain server), the PKI entity domain can include at least a first trust domain, a second trust domain, a root certificate authority, a certificate authority and a registration server, wherein the first trust domain can include at least one user holding a digital certificate, and the second trust domain can include at least one service provider, which is not limited in the embodiment of the present invention. Figure 1 As shown, the cross-domain trust identity authentication method based on the alliance chain may include the following operations:

[0133] 101. When receiving a registration request from a user in the first trust domain, send the user information included in the registration request to the registration server, verify the user information through the registration server, obtain the verified target user information, and send the target user information to the certificate authority.

[0134] In the embodiments of the present invention, the PKI system (Public Key Infrastructure) is optionally represented as a public key infrastructure (PKI). It is a collection of hardware, software, personnel, policies, and procedures that implements functions such as the generation, management, storage, distribution, and revocation of keys and certificates based on public key cryptography. A PKI system is a combination of computer hardware and software, authoritative organizations, and application systems. It provides basic security services for implementing e-commerce, e-government, and office automation, enabling users who are unfamiliar or geographically distant to communicate securely through a chain of trust.

[0135] In the embodiment of the present invention, optionally, Figure 2 As shown, the PKI entity domain may include: certificate users (users) of the first trust domain (A domain), service providers (SPs) of the second trust domain (S domain), root certificate authorities (RCAs), certificate authorities (CAs), and registration servers (RAs). Consortium chain entities (also known as consortium chain servers) may include: non-consensus nodes (NVPs), consensus nodes (VPs), and ordinary nodes (served by RCAs of each domain). Further, as Figure 4As shown, CAs can include second-level and third-level certificate authorities. The hierarchy of certificate authorities is related to the trust system within the PKI entity domain. CAs are typically responsible for generating user blockchain certificates. The RCA must join a consortium chain and upload its root certificate to the consortium chain. The RCA is responsible for storing user certificates generated by subordinate CAs in the blockchain ledger. The RCA can only issue subordinate CA certificates and cannot directly issue user blockchain certificates. All operations on certificates must be uploaded to the blockchain ledger. The RA is responsible for reviewing the registration information provided by the user and, upon approval, uploading the user information to the CA. Furthermore, user information can include at least one of the following: the user's IP address, user identification information, and user email information, though this is not limited in this embodiment of the present invention.

[0136] In the embodiment of the present invention, Figure 4 、 Figure 5 As shown, verifying the user information through the registration server, obtaining the verified target user information, and sending the target user information to the certificate authority may include:

[0137] The user's signature (sig) is verified for identity consistency through the registration server and the signature verification review mechanism. Once identity consistency verification passes, the target user information (info) and the user's public key (pk) are generated and sent to the certificate authority. This allows the required authentication certificates to be registered and generated with the CA, and certificate audits to be conducted within the consortium chain. This separation of registration and auditing leverages the inherent characteristics of blockchain to effectively reduce the possibility of data tampering during transmission.

[0138] 102. According to the preset blockchain certificate format and target user information, a user blockchain certificate is generated by a certificate issuing authority, and the user blockchain certificate is sent to the alliance chain server. The alliance chain server reaches a consensus on the user blockchain certificate and uploads it to the blockchain, and the user blockchain certificate and the height ID of the user blockchain certificate on the blockchain are sent to the user.

[0139] In an embodiment of the present invention, the preset blockchain certificate format is optionally determined as follows:

[0140] The initial blockchain certificate format is determined according to the X.509 standard certificate format.

[0141] The signature, basic constraints, name constraints, and certificate revocation list included in the initial blockchain certificate format are deleted to obtain the preset blockchain certificate format. The specific optimization is as follows.

[0142] The original main fields: certificate version number, certificate serial number, issuer name, certificate validity period, subject public key information, subject unique identifier, etc. are used to ensure the uniqueness and availability of digital certificates, so they are retained.

[0143] Signature and signature algorithm: Since the model uses the blockchain as a public ledger to record certificate operations, the hash value of the generated certificate is recorded in the blockchain ledger. As a multi-domain trust certificate, the blockchain supports public and verifiable search. Therefore, the authentication server of each domain can replace the signature verification process by checking the multi-domain trust certificate. Therefore, this part is deleted.

[0144] Basic and name constraints: Basic and name constraints prevent the scope of trust from expanding indefinitely, making the PKI system unmanageable. Since consortium blockchains set entry barriers for nodes joining the network and the node size is manageable, these constraints are unnecessary.

[0145] Certificate Revocation List (CRL) distribution points: Due to certain defects in CRL, it cannot synchronously display the latest status of the certificate. Therefore, this model does not use CRL to query the latest status of the certificate. Instead, it determines the latest status by querying the certificate status interface in the alliance blockchain system and its related historical block data, so this field is deleted.

[0146] Certificate hash value: The hash value obtained by hashing the content fields of a digital certificate can more conveniently calculate the validity of the certificate.

[0147] Previous block height: This field is used to record the specific location of the block storing the latest status of the digital certificate in the blockchain ledger, making it easier to trace the historical data of digital certificate operations.

[0148] This redesign of a more lightweight certificate allows the alliance blockchain system to store certificates with the lowest possible time and space complexity, thereby helping to reduce the cost of digital certificate management and maintenance, improve authentication efficiency, and simplify authentication operations.

[0149] In the embodiment of the present invention, Figure 3 As shown in the figure, the preset blockchain certificate format includes: version number (Version), certificate identifier (Serial), timestamp (Timestamp), issuer name (Issuer), certificate validity period (Validity), subject name (Subject), subject public key (Subject PK), extension content (Extension), and certificate hash value (CertHash).

[0150] In the embodiment of the present invention, Figure 4 、 Figure 5As shown, according to the preset blockchain certificate format and target user information, a user blockchain certificate (UCert) is generated by a certificate authority, which may include:

[0151] According to the preset blockchain certificate format, target user information and user's public key, the user's blockchain certificate is generated locally through the certificate authority, and the user's blockchain certificate is signed to obtain the user's blockchain certificate.

[0152] In the embodiment of the present invention, Figure 4 、 Figure 5 As shown, sending the user blockchain certificate to the alliance chain server, and uploading the user blockchain certificate to the blockchain through the alliance chain server may include:

[0153] The user blockchain certificate is sent to the root certificate authority, and the root blockchain certificate, timestamp and user blockchain certificate of the root certificate authority are sent to the non-consensus node in the alliance chain server through the root certificate authority.

[0154] When the non-consensus node receives the root blockchain certificate, timestamp and user blockchain certificate from the root certificate authority, the root blockchain certificate sent by the root certificate authority is verified by the non-consensus node.

[0155] When the root blockchain certificate passes verification, the user blockchain certificate and its issuance status are uploaded to the blockchain. This allows the required authentication certificates to be registered and generated with the CA, and certificate audits to be conducted within the consortium chain. This separates registration and auditing, leveraging the inherent characteristics of blockchain to effectively reduce the possibility of data tampering during transmission.

[0156] 103. When it is detected that a user of the first trust domain sends a cross-domain communication request to the service provider of the second trust domain, the user's user signature, user blockchain certificate and the issuing authority that generates the user blockchain certificate are verified for legitimacy based on the cross-domain communication request through the alliance chain server. When the legitimacy verification passes, it is determined that the service provider has successfully authenticated the user.

[0157] In the embodiment of the present invention, optionally, Figure 6 As shown, the cross-domain communication request may include: at least one of the user's user blockchain certificate, height ID, user's digital signature and timestamp, etc.

[0158] In the embodiment of the present invention, Figure 6 As shown, according to the cross-domain communication request, the user signature (sig) of the user (user in domain A), the user blockchain certificate (UCert) and the issuing authority that generated the user blockchain certificate are verified through the alliance chain server, which may include:

[0159] The user's digital signature is verified by the service provider (S domain server SP).

[0160] When the user's digital signature is verified to be signed by the user, the user's blockchain certificate is sent to the non-consensus node of the alliance chain server through the service provider.

[0161] When a non-consensus node receives a user blockchain certificate, it queries the blockchain to see if the user blockchain certificate is valid.

[0162] When the user blockchain certificate is found to be valid, the number of illegal certificates issued by the target certificate authority corresponding to the user blockchain certificate is queried through the certificate authority behavior audit list.

[0163] The credibility of the target certificate authority is determined based on the number of illegal certificates issued, and it is determined whether the credibility is greater than or equal to a preset credibility threshold.

[0164] When it is determined that the credibility is greater than or equal to the preset credibility threshold, the service provider verifies whether the root blockchain certificate of the root certificate authority is valid. When the root blockchain certificate of the root certificate authority is verified to be valid, it is determined that the service provider has successfully authenticated the user.

[0165] In an embodiment of the present invention, determining the credibility of a target certificate authority based on the number of issued illegal certificates may include:

[0166] The credibility of the target certificate authority is determined based on a preset certificate authority credibility algorithm and the number of illegal certificates issued.

[0167] The calculation formula of the certificate authority credibility algorithm is:

[0168]

[0169] Indicates the credibility of the target certificate authority, CA indicates the target certificate authority, It is expressed as the time decay function of the target certificate authority under review in the current operation, Indicates the time period during which a certificate is issued to the target certificate authority. represents the probability of issuing a legitimate certificate for the target certificate authority, Represented as the preset first weight, Represented as the preset second weight, It is the number of certificates issued. and is a non-negative number, and , and The weight value is determined by the actual situation. The initial value of is 0.5, indicating that the credibility is uncertain. As the number of audits increases, Distributed between (0, 1), the closer to 1, the higher the credibility, and vice versa, the lower the credibility. In this case, other verification methods are needed to determine whether to remove the CA.

[0170] The calculation formula is:

[0171]

[0172] Expressed as a decay factor to reflect the importance of historical CA behavior ( ), Indicates the time period for the target certificate authority to issue the certificate. It is represented as the current moment. Assume that the trust decay of the authentication information is reduced by one quarter every hour, that is, =0.75, assuming the current time is 15:00 and the time when the CA issued the last audited certificate is 13:00, then .

[0173] The calculation formula is:

[0174]

[0175] Indicates the total number of certificates issued for the target certificate authority. Indicates the number of valid certificates issued for the target certificate authority.

[0176] In this way, the credibility of a CA is judged by determining whether it has issued a legitimate certificate. A time decay factor is introduced into the credibility calculation model. Different weights are assigned to the behavior according to the time when the CA issues the certificate, so that the credibility of the CA can be calculated more accurately, thereby enhancing the security of the authentication system.

[0177] In the embodiment of the present invention, Figure 7 As shown, the service provider verifies whether the root blockchain certificate of the root certificate authority is valid. When the verification is valid, it is determined that the service provider has successfully authenticated the user, which may include:

[0178] The user blockchain certificate (UCert) is parsed by the service provider (S domain server SP), the root certificate authority of the first trust domain where the user is located (A domain RCA) is confirmed through the user blockchain certificate, and an application request for the root blockchain certificate is sent to the root certificate authority.

[0179] When the root certificate authority of the first trust domain receives the application request from the service provider, it determines through the root certificate authority whether the certificate authority of the user blockchain certificate is the certificate authority in the first trust domain where the user is located. When it is determined that the certificate authority is the certificate authority in the first trust domain where the user is located, the root certificate authority is sent to the service provider.

[0180] Through the service provider, query the non-consensus node of the alliance chain server whether the root blockchain certificate of the root certificate authority in the first trust domain exists.

[0181] When the root blockchain certificate of the root certificate authority in the first trust domain is found to exist, it is determined that the service provider has successfully authenticated the user (user in domain A).

[0182] In this way, only part of the authentication content is performed on the server to prevent the computer load of the cloud identity authentication center from being seriously loaded and causing a single point failure of the server. By separating registration and auditing, the computer load of the server can be reduced and malicious downtime of the server can be prevented, which is conducive to improving the stability and reliability of the authentication system.

[0183] In an optional embodiment, after performing the operation of reaching consensus on the user blockchain certificate through the alliance chain server and uploading it to the blockchain in step 102, the method further includes the following operations:

[0184] The root blockchain certificate and user blockchain certificate as well as their status are stored in the block body through non-consensus nodes.

[0185] When it is detected that the number of root blockchain certificates and user blockchain certificates stored in the block body reaches a preset number, the block body containing multiple root blockchain certificates and user blockchain certificates is assembled into a block through the non-consensus node, and the block is sent to the consensus node.

[0186] When a consensus node receives a block, it reaches consensus on the block according to the built-in consensus algorithm. When the block consensus is completed, the block is stored in the blockchain.

[0187] It can be seen that this optional embodiment can connect the PKI entity domain to the consortium blockchain. By setting the root CA of each entity domain as a distributed node of the blockchain, the root certificates, user certificates and certificate status operations in different entity domains are recorded in the blockchain ledger. The authenticity and reliability of the certificate are guaranteed by the tamper-proof nature of the blockchain, which is conducive to improving the flexibility and security of the authentication system and ensuring that the certificate is trustworthy, controllable and traceable from the source to storage and sharing.

[0188] Example 2

[0189] See also Figure 8 , Figure 8 This is a flow chart of a cross-domain trust identity authentication method based on alliance chain disclosed in an embodiment of the present invention. Figure 8 The described cross-domain trust identity authentication method based on alliance chain can be applied to a cross-domain trust identity authentication system based on alliance chain, and the system is applied to a PKI system, the PKI system includes at least a PKI entity domain and an alliance chain entity (alliance chain server), the PKI entity domain can include at least a first trust domain, a second trust domain, a root certificate authority, a certificate authority and a registration server, wherein the first trust domain can include at least one user holding a digital certificate, and the second trust domain can include at least one service provider, which is not limited in the embodiment of the present invention. Figure 8 As shown, the cross-domain trust identity authentication method based on the alliance chain may include the following operations:

[0190] 201. When receiving a registration request from a service provider in the second trust domain, the service provider information included in the registration request is sent to a registration server, the service provider information is verified by the registration server, and the verified target service provider information is obtained, and the target service provider information is sent to a certificate authority.

[0191] In the embodiment of the present invention, the target service provider information may include at least one of: identification information of the service provider, person-in-charge related information, and the type of information service provided.

[0192] 202. Generate a service provider blockchain certificate through a certificate authority according to the preset blockchain certificate format and target service provider information, and send the service provider blockchain certificate to the alliance chain server. The alliance chain server reaches a consensus on the service provider blockchain certificate and uploads it to the blockchain. The user blockchain certificate and the service provider blockchain certificate are sent to the service provider with their height ID on the blockchain.

[0193] 203. When it is detected that the service provider of the second trust domain receives a cross-domain communication request sent by a user from the first trust domain, the service provider's request confirmation information is fed back to the user, and based on the request confirmation information, the service provider's signature, the service provider's blockchain certificate and the issuing authority that generated the service provider's blockchain certificate are verified for legitimacy through the alliance chain server. When the legitimacy verification passes, it is determined that the user's authentication of the service provider is successful.

[0194] In this embodiment of the present invention, the confirmation request information may optionally include: the service provider's signature, the service provider's blockchain certificate and its status, and the root blockchain certificate issued by the CA that issued the service provider's certificate and the RCA in the service provider's second trust domain. Because this authentication process is a two-way authentication process, the user needs to verify the service provider's signature, blockchain certificate and its status, the normality of the CA that issued the certificate, and the root blockchain certificate and its status of the RCA in the second trust domain.

[0195] In the embodiment of the present invention, since the two-way authentication process of the user and the service provider is consistent, for other descriptions of steps 201 to 203, please refer to the detailed description of steps 101 to 103 in embodiment 1, which will not be repeated in this embodiment of the present invention.

[0196] It can be seen that the implementation of the embodiment of the present invention can reduce the complexity of cross-domain authentication and enhance the security of the PKI system by adopting a two-way authentication method for user-service provider cross-domain requests, while reducing the cost of digital certificate management and maintenance, improving authentication efficiency and simplifying the authentication operation process, further enhancing the flexibility and security of the authentication system, and ensuring that the certificate is trustworthy, controllable and traceable from the source to storage sharing.

[0197] visible, Figure 8 The cross-domain trust identity authentication method based on the alliance chain described can generate a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information after verification when receiving a registration request sent by a user from the first trust domain, which can separate registration from auditing and effectively reduce the possibility of data being tampered with during transmission by utilizing the inherent characteristics of the blockchain; and send the user blockchain certificate to the alliance chain server, reach a consensus on the user blockchain certificate through the alliance chain server and upload it to the blockchain, and send the user blockchain certificate and the height ID of the user blockchain certificate in the blockchain to the user, and when it is detected that the user sends a cross-domain communication to the service provider, When a request is made, the legitimacy of the user's signature, user blockchain certificate and the issuing authority that generates the user blockchain certificate is verified through the alliance chain server according to the cross-domain communication request. When the legitimacy verification is passed, it is determined that the service provider has passed the user authentication. By separating registration and auditing, the computer load of the server can be reduced to avoid causing a single point of failure of the server. By adopting a two-way authentication method for user-service provider cross-domain requests, it is beneficial to reduce the cost of digital certificate management and maintenance, improve authentication efficiency and simplify the authentication operation process, thereby enhancing the flexibility and security of the authentication system, and ensuring that the certificate is trustworthy, controllable and traceable from the source to storage sharing.

[0198] Example 3

[0199] See also Figure 9 , Figure 9 This is a schematic diagram of the structure of a cross-domain trust identity authentication system based on alliance chain disclosed in an embodiment of the present invention. Figure 9 The described cross-domain trust identity authentication system based on alliance chain can execute the above cross-domain trust identity authentication method based on alliance chain, and the system is applied to the PKI system, the PKI system includes at least a PKI entity domain and an alliance chain entity (alliance chain server), the PKI entity domain can include at least a first trust domain, a second trust domain, a root certificate authority, a certificate authority and a registration server, wherein the first trust domain can include at least one user holding a digital certificate, and the second trust domain can include at least one service provider, which is not limited in the embodiment of the present invention. Figure 9 As shown, the cross-domain trust identity authentication system based on the alliance chain may include: a sending module 301, a verification module 302, a generation module 303, and a chain module 304, wherein:

[0200] The sending module 301 is configured to send the user information included in the registration request to the registration server upon receiving the registration request from the user in the first trust domain.

[0201] The verification module 302 is used to verify the user information sent by the sending module 301 through the registration server to obtain the verified target user information.

[0202] The sending module 301 is further configured to send the target user information to a certificate issuing authority.

[0203] The generation module 303 is used to generate a user blockchain certificate through a certificate authority according to the preset blockchain certificate format and the target user information sent by the sending module 301.

[0204] The sending module 301 is also used to send the user blockchain certificate generated by the generating module 303 to the alliance chain server.

[0205] The uplink module 304 is used to uplink the user blockchain certificate sent by the sending module 301 to the blockchain through the alliance chain server.

[0206] The sending module 301 is also used to send the user blockchain certificate and the height ID of the user blockchain certificate in the blockchain to the user.

[0207] The verification module 302 is also used to verify the legitimacy of the user's user signature, the user blockchain certificate on the chain module 304, and the issuing authority that generates the user blockchain certificate based on the cross-domain communication request and through the alliance chain server when it is detected that a user in the first trust domain sends a cross-domain communication request to the service provider in the second trust domain. When the legitimacy verification passes, it is determined that the service provider has successfully authenticated the user.

[0208] Among them, the cross-domain communication request includes the user's user blockchain certificate, height ID, user's random number signature and timestamp.

[0209] It can be seen that implementation Figure 9 The described cross-domain trust identity authentication system based on a consortium chain can, upon receiving a registration request sent by a user from a first trust domain, generate a user blockchain certificate through a certificate authority based on a preset blockchain certificate format and verified target user information. This can separate registration from auditing and utilize the inherent characteristics of blockchain to effectively reduce the possibility of data tampering during transmission. The user blockchain certificate is then sent to a consortium chain server, which reaches a consensus on the user blockchain certificate and uploads it to the blockchain. The user blockchain certificate and the height ID of the user blockchain certificate on the blockchain are sent to the user. When it is detected that the user sends a cross-domain communication request to a service provider, the user signature, user blockchain certificate, and the issuing authority that generated the user blockchain certificate are verified for legitimacy based on the cross-domain communication request through the consortium chain server. When the legitimacy verification passes, it is determined that the service provider has successfully authenticated the user. This can reduce the server's computing capacity and avoid causing single points of failure in the server, thereby reducing the cost of digital certificate management and maintenance, improving authentication efficiency and simplifying the authentication operation process, enhancing the flexibility of the authentication system, and ensuring that the certificate is trustworthy, controllable, and traceable from source to storage and sharing.

[0210] In an optional embodiment, the preset blockchain certificate format is determined as follows:

[0211] The initial blockchain certificate format is determined according to the X.509 standard certificate format.

[0212] The signature, basic constraints, name constraints, and certificate revocation list included in the initial blockchain certificate format are deleted to obtain the preset blockchain certificate format.

[0213] Among them, the preset blockchain certificate format includes: version number, certificate identifier, timestamp, issuer name, certificate validity period, subject name, subject public key, extended content, and certificate hash value.

[0214] It can be seen that implementation Figure 10The described cross-domain trust identity authentication system based on alliance chain can redesign more lightweight certificates so that the alliance blockchain system can store certificates with the lowest possible time complexity and space complexity, which is conducive to reducing the cost of digital certificate management and maintenance, improving authentication efficiency and simplifying the authentication operation process.

[0215] In another optional embodiment, the user information includes at least: the user's IP address, user identification information, and user email information.

[0216] As well as Figure 10 As shown, the verification module 302 verifies the user information through the registration server, and obtains the verified target user information in the following specific manner:

[0217] The user's signature is verified for identity consistency through the registration server and according to the signature verification review mechanism. When the identity consistency verification passes, the target user information after verification is generated.

[0218] The specific method in which the sending module 301 sends the target user information to the certificate issuing authority is as follows:

[0219] The target user information and the user's public key are sent to the certificate authority.

[0220] The specific method in which the generation module 303 generates a user blockchain certificate through a certificate authority according to the preset blockchain certificate format and target user information is as follows:

[0221] According to the preset blockchain certificate format, target user information and user's public key, the user's blockchain certificate is generated locally through the certificate authority, and the user's blockchain certificate is signed to obtain the user's blockchain certificate.

[0222] It can be seen that implementation Figure 10 The described cross-domain trust identity authentication system based on the alliance chain can register and generate the required authentication certificates in the CA, conduct certificate audits in the alliance chain, separate registration and auditing, and utilize the inherent characteristics of the blockchain to effectively reduce the possibility of data tampering during transmission.

[0223] In another optional embodiment, Figure 10 As shown, the specific method in which the sending module 301 sends the user blockchain certificate to the alliance chain server is:

[0224] The user blockchain certificate is sent to the root certificate authority, and the root blockchain certificate, timestamp and user blockchain certificate of the root certificate authority are sent to the non-consensus node in the alliance chain server through the root certificate authority.

[0225] The specific method in which the on-chain module 304 uploads the user's blockchain certificate to the blockchain through the alliance chain server is as follows:

[0226] When the non-consensus node receives the root blockchain certificate, timestamp and user blockchain certificate from the root certificate authority, the root blockchain certificate sent by the root certificate authority is verified by the non-consensus node.

[0227] When the root blockchain certificate passes verification, the user blockchain certificate and the issuance status of the user blockchain certificate are uploaded to the blockchain.

[0228] The system also includes:

[0229] The storage module 305 is used to store the root blockchain certificate and user blockchain certificate sent by the sending module 301 and their status in the block body through a non-consensus node.

[0230] The assembly module 306 is used to assemble the block body containing multiple root blockchain certificates and user blockchain certificates into a block through a non-consensus node when it is detected that the root blockchain certificates and user blockchain certificates stored in the block body by the storage module 305 reach a preset number.

[0231] The sending module 301 is also used to send the blocks assembled by the assembling module 306 to the consensus node.

[0232] The consensus module 307 is used to reach a consensus on the block through the consensus node and according to the built-in consensus algorithm when the consensus node receives the block sent by the sending module 301.

[0233] The storage module 305 is also used to store the block in the blockchain after the consensus module 307 completes the block consensus.

[0234] It can be seen that implementation Figure 10 The described cross-domain trust identity authentication system based on consortium chain can connect the PKI entity domain to the consortium blockchain. By setting the root CA of each entity domain as a distributed node of the blockchain, the root certificates, user certificates and certificate status operations in different entity domains are recorded in the blockchain ledger. The authenticity and reliability of the certificates are guaranteed by the tamper-proof nature of the blockchain, which is conducive to improving the flexibility and security of the authentication system and ensuring that the certificates are trustworthy, controllable and traceable from the source to storage and sharing.

[0235] In another optional embodiment, Figure 10 As shown, the verification module 302 verifies the legitimacy of the user's user signature, user blockchain certificate, and the issuing authority that generates the user blockchain certificate based on the cross-domain communication request through the alliance chain server. When the legitimacy verification passes, the specific method for determining whether the service provider has authenticated the user is as follows:

[0236] The service provider verifies the user's digital signature.

[0237] When the user's digital signature is verified to be signed by the user, the user's blockchain certificate is sent to the non-consensus node of the alliance chain server through the service provider.

[0238] When a non-consensus node receives a user blockchain certificate, it queries the blockchain to see if the user blockchain certificate is valid.

[0239] When the user blockchain certificate is found to be valid, the number of illegal certificates issued by the target certificate authority corresponding to the user blockchain certificate is queried through the certificate authority behavior audit list.

[0240] The credibility of the target certificate authority is determined based on the number of illegal certificates issued, and it is determined whether the credibility is greater than or equal to a preset credibility threshold.

[0241] When it is determined that the credibility is greater than or equal to the preset credibility threshold, the service provider verifies whether the root blockchain certificate of the root certificate authority is valid. When the root blockchain certificate of the root certificate authority is verified to be valid, it is determined that the service provider has successfully authenticated the user.

[0242] It can be seen that implementation Figure 10 The described cross-domain trust identity authentication system based on the alliance chain can judge whether the CA is trustworthy by determining whether the CA has issued a legal certificate, so as to more accurately calculate the credibility of the CA, thereby enhancing the security and reliability of the authentication system.

[0243] In another optional embodiment, Figure 10 As shown, the specific manner in which the verification module 302 determines the credibility of the target certificate authority based on the number of illegal certificates issued is as follows:

[0244] The credibility of the target certificate authority is determined based on a preset certificate authority credibility algorithm and the number of illegal certificates issued.

[0245] The calculation formula of the certificate authority credibility algorithm is:

[0246]

[0247] Indicates the trustworthiness of the target certificate authority. It is expressed as the time decay function of the target certificate authority under review in the current operation, Indicates the time period during which a certificate is issued to the target certificate authority. represents the probability of issuing a legitimate certificate for the target certificate authority, Represented as the preset first weight, Represented as the preset second weight, Indicates the number of certificates issued.

[0248] The calculation formula is:

[0249]

[0250] Expressed as the attenuation factor, Indicates the time period for the target certificate authority to issue the certificate. Indicates the current moment.

[0251] The calculation formula is:

[0252]

[0253] Indicates the total number of certificates issued for the target certificate authority. Indicates the number of valid certificates issued for the target certificate authority.

[0254] It can be seen that implementation Figure 10 The described cross-domain trust identity authentication system based on consortium chain can judge whether the CA is trustworthy by determining whether the CA issues a valid certificate. It also introduces a time decay factor into the credibility calculation model, assigning different weights to the behavior according to the time when the CA issues the certificate, so as to more accurately calculate the credibility of the CA, thereby enhancing the security of the authentication system.

[0255] In another optional embodiment, Figure 10 As shown, the verification module 302 verifies whether the root blockchain certificate of the root certificate authority is valid through the service provider. When the verification is valid, the specific method of determining whether the service provider has passed the user authentication is as follows:

[0256] The service provider parses the user's blockchain certificate, confirms the root certificate authority of the first trust domain where the user is located through the user's blockchain certificate, and sends an application request for the root blockchain certificate to the root certificate authority.

[0257] When the root certificate authority of the first trust domain receives the application request from the service provider, it determines through the root certificate authority whether the certificate authority of the user blockchain certificate is the certificate authority in the first trust domain where the user is located. When it is determined that the certificate authority is the certificate authority in the first trust domain where the user is located, the root certificate authority is sent to the service provider.

[0258] Through the service provider, query the non-consensus node of the alliance chain server whether the root blockchain certificate of the root certificate authority in the first trust domain exists.

[0259] When the root blockchain certificate of the root certificate authority in the first trust domain is found to exist, it is determined that the service provider has successfully authenticated the user.

[0260] It can be seen that implementation Figure 10 The described cross-domain trust identity authentication system based on alliance chain can only perform part of the authentication content on the server, preventing the computer load of the cloud identity authentication center from being seriously loaded and causing a single point failure of the server. By separating registration and auditing, it can not only reduce the computer load of the server but also prevent malicious downtime of the server, which is conducive to improving the stability and reliability of the authentication system.

[0261] Example 4

[0262] See also Figure 11 , Figure 11 This is a schematic diagram of the structure of another cross-domain trust identity authentication system based on alliance chain disclosed in an embodiment of the present invention. Figure 11 As shown, the cross-domain trust identity authentication system based on the alliance chain may include:

[0263] A memory 401 storing executable program code;

[0264] a processor 402 coupled to the memory 401;

[0265] The processor 402 calls the executable program code stored in the memory 401 to execute the steps in the cross-domain trust identity authentication method based on the alliance chain described in the first embodiment of the present invention or the second embodiment of the present invention.

[0266] Example 5

[0267] An embodiment of the present invention discloses a computer storage medium, which stores computer instructions. When the computer instructions are called, they are used to execute the steps of the cross-domain trust identity authentication method based on the alliance chain described in Example 1 or Example 2 of the present invention.

[0268] Example 6

[0269] An embodiment of the present invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to enable a computer to execute the steps of the cross-domain trust identity authentication method based on the alliance chain described in Example 1 or Example 2.

[0270] The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, i.e., they may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present embodiment without inventive effort.

[0271] Through the detailed description of the above embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, or of course, by means of hardware. Based on this understanding, the above technical solution, in essence, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disk storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0272] Finally, it should be noted that the cross-domain trust identity authentication method and system based on the alliance chain disclosed in the embodiment of the present invention is only a preferred embodiment of the present invention, which is only used to illustrate the technical solution of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the aforementioned embodiments, ordinary technicians in this field should understand that it is still possible to modify the technical solutions recorded in the aforementioned embodiments, or to replace some of the technical features therein with equivalents; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A cross-domain trust identity authentication method based on a consortium chain, applied to a PKI system, wherein the PKI system includes at least a first trust domain and a second trust domain, characterized in that: The method comprises: When receiving a registration request sent by a user from the first trust domain, sending the user information included in the registration request to the registration server; Verify the user information through the registration server, obtain the verified target user information, and send the target user information to the certificate issuing authority; Generate a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information; Send the user blockchain certificate to the alliance chain server, upload the user blockchain certificate to the blockchain through the alliance chain server, and send the user blockchain certificate and the height ID of the user blockchain certificate on the blockchain to the user; When it is detected that a user of the first trust domain sends a cross-domain communication request to a service provider of the second trust domain, the user signature of the user, the user blockchain certificate, and the issuing authority that generated the user blockchain certificate are verified according to the cross-domain communication request through the alliance chain server. If the legitimacy verification passes, it is determined that the service provider has successfully authenticated the user; The cross-domain communication request includes the user's blockchain certificate, the height ID, the user's digital signature and timestamp.

2. The cross-domain trust identity authentication method based on alliance chain according to claim 1 is characterized in that: The preset blockchain certificate format is determined as follows: Determine the initial blockchain certificate format based on the X.509 standard certificate format; Deleting the signature, basic constraints, name constraints, and certificate revocation list included in the initial blockchain certificate format to obtain the preset blockchain certificate format; The preset blockchain certificate format includes: version number, certificate identifier, timestamp, issuer name, certificate validity period, subject name, subject public key, extension content, and certificate hash value.

3. The cross-domain trust identity authentication method based on alliance chain according to claim 1 is characterized in that: The user information includes at least: the user's IP address, user identification information, and user email information; The step of verifying the user information through the registration server, obtaining verified target user information, and sending the target user information to a certificate issuing authority includes: Perform identity consistency verification on the user's signature through the registration server and according to the signature verification review mechanism. When the identity consistency verification passes, generate the verified target user information, and send the obtained target user information and the user's public key to the certificate authority; The step of generating a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information includes: According to the preset blockchain certificate format, the target user information and the user's public key, the user's blockchain certificate is generated locally by the certificate issuing authority, and the user's blockchain certificate is signed to obtain the user blockchain certificate.

4. The cross-domain trust identity authentication method based on the alliance chain according to any one of claims 1 to 3 is characterized in that: The sending of the user blockchain certificate to the alliance chain server, and uploading the user blockchain certificate to the blockchain through the alliance chain server, includes: Send the user blockchain certificate to a root certificate authority, and send the root blockchain certificate, timestamp, and user blockchain certificate of the root certificate authority to a non-consensus node in the alliance chain server through the root certificate authority; When the non-consensus node receives the root blockchain certificate, timestamp, and user blockchain certificate of the root certificate authority, the non-consensus node verifies the root blockchain certificate sent by the root certificate authority; When the root blockchain certificate passes verification, the user blockchain certificate and the issuance status of the user blockchain certificate are uploaded to the blockchain; The method further comprises: Storing the root blockchain certificate and the user blockchain certificate and their status in the block body through the non-consensus node; When it is detected that the root blockchain certificate and the user blockchain certificate stored in the block body reach a preset number, assembling the block body including the plurality of root blockchain certificates and the user blockchain certificates into a block through a non-consensus node, and sending the block to a consensus node; When the consensus node receives the block, it reaches a consensus on the block according to the built-in consensus algorithm. When the block consensus is completed, the block is stored in the blockchain.

5. The cross-domain trust identity authentication method based on alliance chain according to claim 4 is characterized in that: The step of performing legitimacy verification on the user signature of the user, the user blockchain certificate, and the issuing authority that generated the user blockchain certificate according to the cross-domain communication request through the alliance chain server, and determining that the service provider has authenticated the user when the legitimacy verification passes, includes: Verifying the user's digital signature through the service provider; When the user's digital signature is verified to be signed by the user, the user's blockchain certificate is sent to the non-consensus node of the alliance chain server through the service provider; When the non-consensus node receives the user blockchain certificate, querying the blockchain via the non-consensus node whether the user blockchain certificate is valid; When the user blockchain certificate is found to be valid, the number of illegal certificates issued by the target certificate issuing authority corresponding to the user blockchain certificate is queried through the certificate issuing authority behavior audit list; Determining the credibility of the target certificate issuing authority based on the number of issued illegal certificates, and judging whether the credibility is greater than or equal to a preset credibility threshold; When it is determined that the credibility is greater than or equal to a preset credibility threshold, the service provider verifies whether the root blockchain certificate of the root certificate authority is valid. When it is verified that the root blockchain certificate of the root certificate authority is valid, it is determined that the service provider has successfully authenticated the user.

6. The cross-domain trust identity authentication method based on alliance chain according to claim 5 is characterized in that: The determining the credibility of the target certificate authority according to the number of issued illegal certificates includes: Determining the credibility of the target certificate authority based on a preset certificate authority credibility algorithm and the number of issued illegal certificates; The calculation formula of the certificate authority credibility algorithm is: described Indicates the trustworthiness of the target certificate authority. It is represented as the time decay function of the target certificate authority under review in the current operation, Indicates the time period for issuing a certificate to the target certificate authority. represents the probability of issuing a legitimate certificate for the target certificate authority, Represented as the preset first weight, Represented as a preset second weight, the Indicates the number of certificates issued; described The calculation formula is: described Expressed as the attenuation factor, the Indicates the time period for the target certificate authority to issue the certificate. Represents the current moment; described The calculation formula is: described Indicates the total number of certificates issued for the target certificate authority. Indicates the number of valid certificates issued by the target certificate authority.

7. The cross-domain trust identity authentication method based on alliance chain according to claim 5 is characterized in that: Verifying, by the service provider, whether the root blockchain certificate of the root certificate authority is valid, and when the verification is valid, determining that the service provider has successfully authenticated the user, includes: Parsing the user blockchain certificate through the service provider, confirming the root certificate authority of the first trust domain where the user is located through the user blockchain certificate, and sending an application request for a root blockchain certificate to the root certificate authority; When the root certificate authority of the first trust domain receives the application request from the service provider, the root certificate authority determines whether the certificate authority of the user blockchain certificate is a certificate authority in the first trust domain where the user is located, and if it is determined that the certificate authority is a certificate authority in the first trust domain where the user is located, the root certificate authority is sent to the service provider; Querying the non-consensus node of the alliance chain server through a service provider to determine whether the root blockchain certificate of the root certificate authority in the first trust domain exists; When it is queried that the root blockchain certificate of the root certificate authority in the first trust domain exists, it is determined that the service provider has successfully authenticated the user.

8. A cross-domain trust identity authentication system based on a consortium chain, applied to a PKI system, wherein the PKI system includes at least a first trust domain and a second trust domain, characterized in that: The system comprises: a sending module, configured to, upon receiving a registration request sent by a user from the first trust domain, send the user information included in the registration request to a registration server; A verification module, configured to verify the user information sent by the sending module through a registration server to obtain verified target user information; The sending module is further configured to send the target user information to a certificate issuing authority; A generating module, configured to generate a user blockchain certificate through a certificate authority according to a preset blockchain certificate format and the target user information sent by the sending module; The sending module is further configured to send the user blockchain certificate generated by the generating module to the alliance chain server; An on-chain module, configured to upload the user blockchain certificate sent by the sending module to the blockchain through the alliance chain server; The sending module is further configured to send the user blockchain certificate and the height ID of the user blockchain certificate on the blockchain to the user; The verification module is further configured to, when detecting that a user of the first trust domain sends a cross-domain communication request to a service provider of the second trust domain, perform legitimacy verification on the user signature of the user, the user blockchain certificate uploaded by the uplink module, and the issuing authority that generated the user blockchain certificate according to the cross-domain communication request and through the alliance chain server; and when the legitimacy verification passes, determine that the service provider has authenticated the user; The cross-domain communication request includes the user's blockchain certificate, the height ID, the user's digital signature and timestamp.

9. A cross-domain trust identity authentication system based on alliance chain, characterized in that: The system comprises: a memory storing executable program code; a processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the cross-domain trust identity authentication method based on the alliance chain as described in any one of claims 1-7.

10. A computer storage medium, characterized in that The computer storage medium stores computer instructions, which, when called, are used to execute the cross-domain trust identity authentication method based on the alliance chain as described in any one of claims 1 to 7.

Images