Multi-ca cross-domain certificate authentication method and device, equipment and storage medium

Abstract

The application provides a multi-CA cross-domain certificate authentication method, device, equipment and storage medium, the method comprises the following steps: access configuration is carried out to a plurality of CA centers and key negotiation is carried out, and a CA interconversion key set is obtained; a user equipment generates a key pair and requests a certificate from a first CA center, and a first domain certificate is obtained; service data is signed and sent to a verification end; the verification end carries out domain determination on the first domain certificate, when the determination is cross-domain, the first domain certificate is converted into a second domain certificate according to the conversion key set, and the second domain certificate and the user signature are verified. The application realizes the interoperability of cross-domain certificates through the certificate conversion mechanism, so that the user only needs to hold one digital certificate to use in multiple CA authentication domains, and solves the technical problem of certificate mutual recognition between multiple CA authentication domains.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, device, and storage medium for multi-CA cross-domain certificate authentication. Background Technology

[0002] With the rapid development of e-government and e-commerce, PKI (Public Key Infrastructure) systems have been widely used in identity authentication and digital signatures. Currently, my country has established multiple independently operating CA (Certificate Authority) centers, with different regional and industry-specific CA centers issuing digital certificates to users. These CA centers are relatively independent in terms of technical standards and management systems, and the digital certificates issued by each CA center are only valid within its own authentication domain.

[0003] When users need to conduct business operations across multiple CA authentication domains, existing technical solutions require users to apply for and hold multiple digital certificates from different CA centers. For example, when an enterprise bids across regions, it needs to obtain digital certificates from multiple certification centers, which forces users to manage and carry multiple physical key devices. This makes it impossible for a single certificate to be universally applicable across multiple CA authentication domains, severely impacting the interoperability of cross-domain certificate authentication. Summary of the Invention

[0004] The main objective of this invention is to solve the single point of failure problem caused by the centralized architecture of existing cross-domain authentication schemes; This invention provides a multi-CA cross-domain certificate authentication method, characterized in that the multi-CA cross-domain certificate authentication method includes: Access configuration is performed on multiple CA centers to obtain a set of CA identifiers, and key negotiation is performed on the CA centers in the set of CA identifiers to obtain a set of inter-CA conversion keys; The user equipment is processed to obtain a user key pair, and a certificate is requested from the first CA center based on the user key pair to obtain a first domain certificate; The business data and the user key pair are signed to obtain the user signature. The first domain certificate and the user signature are then sent to the verification end to request authentication. The verification terminal performs domain determination on the first domain certificate. When the determination result is cross-domain, the first domain certificate is converted according to the CA inter-conversion key set to obtain the second domain certificate. The second domain certificate and the user signature are then verified to obtain the authentication result.

[0005] The present invention also provides a multi-CA cross-domain certificate authentication device, characterized in that the multi-CA cross-domain certificate authentication device comprises: The key negotiation module is used to configure access to multiple CA centers, obtain a set of CA identifiers, and perform key negotiation on the CA centers in the set of CA identifiers to obtain a set of inter-CA conversion keys. The certificate application module is used to perform key processing on the user equipment to obtain a user key pair, and to request a certificate from the first CA center based on the user key pair to obtain a first domain certificate. The signature sending module is used to sign the business data and the user key pair to obtain the user signature, and send the first domain certificate and the user signature to the verification end to make an authentication request. The cross-domain authentication module is used to determine the domain of the first domain certificate through the verification terminal. When the determination result is cross-domain, the first domain certificate is converted according to the CA conversion key set to obtain the second domain certificate. The second domain certificate and the user signature are then verified to obtain the authentication result.

[0006] The present invention also provides a multi-CA cross-domain certificate authentication device, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; the at least one processor invokes the instructions in the memory to cause the multi-CA cross-domain certificate authentication device to perform the steps of the multi-CA cross-domain certificate authentication method described above.

[0007] The present invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the above-described multi-CA cross-domain certificate authentication method.

[0008] The aforementioned multi-CA cross-domain certificate authentication method, apparatus, device, and storage medium, through access configuration and key negotiation with multiple CA centers, obtains a set of inter-CA conversion keys; the user equipment generates a key pair and requests a certificate from the first CA center to obtain a first domain certificate; the business data is signed and sent to the verification end; the verification end performs domain determination on the first domain certificate, and when it is determined to be cross-domain, it converts the first domain certificate according to the conversion key set to obtain a second domain certificate, and verifies the second domain certificate and the user signature. This invention, through a certificate conversion mechanism, allows users to use only one digital certificate in multiple CA authentication domains, achieving cross-domain certificate interoperability and solving the technical problem of certificate mutual recognition between multiple CA authentication domains.

[0009] Beneficial Effects: By establishing a set of conversion keys among CA centers, the verification end can convert a first-domain certificate into a second-domain certificate using the conversion keys, thereby achieving certificate interoperability between different CA authentication domains. Compared to existing technologies that require users to apply for certificates separately from each CA center, the certificate conversion mechanism of this invention allows users to obtain a second-domain certificate for verification without reapplying when their first-domain certificate is determined to be cross-domain by the verification end. This solves the technical problem that a single certificate cannot be used universally across multiple CA authentication domains, achieving interoperability of cross-domain certificate authentication. Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0010] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the first embodiment of the multi-CA cross-domain certificate authentication method in this invention; Figure 2 This is a schematic diagram of the second embodiment of the multi-CA cross-domain certificate authentication method in this invention; Figure 3 This is a schematic diagram of one embodiment of the multi-CA cross-domain certificate authentication device in this invention; Figure 4 This is a schematic diagram of one embodiment of a multi-CA cross-domain certificate authentication device according to the present invention. Detailed Implementation

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

[0013] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0014] To facilitate understanding of this embodiment, a multi-CA cross-domain certificate authentication method disclosed in this invention will first be described in detail. For example... Figure 1 As shown, this method includes the following steps: 101. Configure access for multiple CA centers to obtain a set of CA identifiers, and negotiate keys with the CA centers in the set of CA identifiers to obtain a set of inter-CA conversion keys; In this embodiment, before the multi-CA cross-domain certificate authentication system can run, the access configuration of each CA center needs to be completed. Specifically, the system administrator can authenticate the CA centers to be connected and register their basic information, including the CA center's name, region, contact information, and other basic attributes. After authentication, the system assigns a unique CA identifier to each CA center, which is used to uniquely identify the CA center in the system.

[0015] After configuring access for multiple CA centers, a set of CA identifiers containing the identifiers of all connected CA centers can be obtained. For example, if three CA centers are connected to the system, the set of CA identifiers can be represented as a set containing the identifiers of these three CA centers.

[0016] After completing the access configuration of the CA centers, the system needs to establish a key negotiation mechanism between different CA centers to generate inter-CA conversion keys for certificate conversion. It should be noted that traditional cross-CA mutual recognition schemes typically employ cross-certification or bridge CA methods, where CA centers mutually issue certificates or establish a trust chain through an intermediate bridge CA. This application, however, adopts a conversion key-based scheme. Its core idea is to negotiate and generate specific conversion keys between CA centers, enabling a certificate issued by one CA center to be converted into a certificate in a format issued by another CA center using this conversion key.

[0017] Specifically, for any two CA centers in the CA identifier set, such as the first CA center and the second CA center, the system can initiate a key negotiation process. During the key negotiation process, the first CA center and the second CA center each hold their own private keys and generate a conversion key through the negotiation mechanism. The purpose of this conversion key is to convert the certificate signature issued by the first CA center into a certificate signature in the format issued by the second CA center.

[0018] Understandably, the conversion key generation process needs to meet two basic security requirements. The first is confidentiality: during the conversion key generation process, the private key of the first CA center must not be disclosed to the second CA center, and vice versa. This is because the private key of the CA center is the foundation of the entire PKI system's security; once disclosed, all certificates issued by that CA center will lose their credibility. The second is correctness: the generated conversion key must be able to correctly convert the certificate signature of the first CA center into the certificate signature format of the second CA center, and the converted signature must be verifiable by the public key of the second CA center.

[0019] After completing key negotiations between all CA pairs, a set of inter-CA conversion keys is obtained. This set contains the conversion keys between any two CAs. In practical applications, the system can store these conversion keys in a secure key management server and call them as needed for actual certificate conversion.

[0020] It's important to note that the generation and management of the conversion key involves the problem of secure multi-party computation in cryptography. In traditional key exchange protocols, such as the Diffie-Hellman key exchange protocol, two parties can negotiate a shared key over an insecure channel. However, in the scenario described in this application, the generation of the conversion key not only needs to ensure the security of the negotiation process but also needs to ensure that the generated conversion key has a specific algebraic structure, enabling it to correctly perform the certificate signing conversion function. This is fundamentally different from traditional key exchange protocols.

[0021] 102. Perform key processing on the user equipment to obtain a user key pair, and request a certificate from the first CA center based on the user key pair to obtain a first domain certificate; In this embodiment, the step of performing key processing on the user equipment to obtain a user key pair, and requesting a certificate from the first CA center based on the user key pair to obtain a first domain certificate includes: generating a private key vector for the user equipment to obtain a user private key vector; performing matrix operations on the user private key vector and the lattice base matrix to obtain a user public key, wherein the user private key vector and the user public key constitute the user key pair; generating a certificate request based on the user public key and user identification information in the user key pair, and sending the certificate request to the first CA center; performing matrix operations on the signature random vector and the lattice base matrix through the first CA center to obtain auxiliary parameters; performing hash operations on the auxiliary parameters and information in the certificate request to obtain a hash value; performing a linear combination operation on the private key vector of the first CA center, the product of the hash value and the signature random vector, and the random number corresponding to the first CA center to obtain a certificate signature; and encapsulating the certificate signature, the auxiliary parameters, and the user public key to obtain the first domain certificate.

[0022] Specifically, when users need to use digital certificates for identity authentication or business signatures, they first need to apply for a certificate from a CA (Certificate Authority). Unlike traditional certificate application processes based on RSA or elliptic curves, this application uses a lattice-based certificate system; therefore, user equipment uses a lattice-based cipher algorithm when generating key pairs. It's important to note that the private key in a lattice-based cipher algorithm is not a large integer in the traditional sense, but rather a vector where each element is an integer. When generating a private key, the user equipment can randomly generate an integer vector that meets a specific length and value range, serving as the user's private key vector. For example, if the system's security parameters require the private key vector to have a dimension of m, then the user's private key vector can be represented as a vector containing m integers.

[0023] After generating the user's private key vector, the user equipment (PAI) needs to calculate the corresponding public key based on this vector. In lattice cryptography, the generation of the public key depends on the system's lattice base matrix. The lattice base matrix is ​​a public parameter generated during the initialization of the entire PKI system, accessible to all users and CA centers. The PAI can perform matrix multiplication between the user's private key vector and the lattice base matrix to obtain the user's public key. Specifically, if the user's private key vector is a row vector and the lattice base matrix is ​​a matrix, then multiplying the row vector by the matrix yields a new row vector, which is the user's public key.

[0024] Understandably, deriving a user's private key vector from their public key is mathematically difficult; this problem is known as the non-homogeneous small integer solution problem on a lattice. Even if an attacker obtains the user's public key and the lattice basis matrix, they cannot compute the user's private key vector in an acceptable amount of time. This guarantees the security of lattice cryptography, and this security remains even against quantum computers.

[0025] After generating the user key pair, the user equipment can construct a certificate request. The certificate request must include the user's public key and the user's identification information, which may include the user's name, organization, email address, and other identity attributes. The user equipment sends the certificate request to the first Certificate Authority (CA), requesting that CA issue a digital certificate for it.

[0026] Upon receiving a certificate request, the first CA center verifies the user's identity information. After successful verification, the first CA center signs the certificate content to confirm that the certificate was indeed issued by the first CA center. It should be noted that the CA center's signing process in this application differs significantly from traditional signing processes. Traditional digital signatures typically involve encrypting the hash value of the message, while the signature in this application is based on a lattice-based signature algorithm.

[0027] Specifically, when the first CA center performs certificate signing, it first needs to generate a signature random vector. The purpose of this random vector is to introduce randomness into the signature, preventing forgery. The first CA center then performs matrix operations on the signature random vector and the lattice basis matrix to obtain an auxiliary parameter. This auxiliary parameter is essentially the mapping result of the signature random vector under the lattice basis matrix.

[0028] Next, the first CA (Certificate Authority) performs a hash operation on this auxiliary parameter along with the information in the certificate request. The inputs to the hash operation include the auxiliary parameter, the user's public key, user identification information, and the certificate's validity period. The hash function produces a fixed-length hash value. This hash value acts as a binding agent in the signature algorithm, ensuring that the signature is associated with specific certificate content.

[0029] After obtaining the hash value, the first Certificate Authority (CA) can calculate the certificate signature. The calculation involves the product of the first CA's private key vector, the hash value, and the signature random vector, as well as a random number corresponding to the first CA. It's important to note that the random number corresponding to the first CA is generated during the aforementioned key negotiation phase and is embedded in the certificate signature, giving it a special algebraic structure. This special structure is crucial for certificate conversion, because the conversion process requires algebraic operations on the certificate signature using the conversion key, and the success of these operations depends on the presence of a specific random number component in the certificate signature.

[0030] The calculation of a certificate signature is essentially a linear combination of the aforementioned vectors. A linear combination refers to the weighted sum of multiple vectors according to certain coefficients. The first Certificate Authority (CA) combines the product of the private key vector, the hash value, and the signature random vector, along with the corresponding random number, according to a specific algebraic relationship to obtain the final certificate signature vector.

[0031] After calculating the certificate signature, the first CA center encapsulates the certificate signature, auxiliary parameters, and user public key to form a complete first-domain certificate. This certificate contains the user's public key information, identity information, certificate validity period, issuer information (i.e., the identifier of the first CA center), and certificate signature. Upon receiving this certificate, the user device can store it locally for subsequent business operations.

[0032] Understandably, the signature in the first domain certificate can be verified using the public key of the first CA (Certificate Authority). The verification process is also based on lattice cryptography; the verifier performs matrix operations on the certificate signature and the lattice base matrix, and compares the result with the expected value calculated using the first CA's public key. If they match, the certificate signature is valid, and the certificate was indeed issued by the first CA and has not been tampered with.

[0033] 103. Sign the business data and the user key pair to obtain the user signature, and send the first domain certificate and the user signature to the verification end to make an authentication request; In this embodiment, the step of signing the business data and the user key pair to obtain a user signature, and sending the first domain certificate and the user signature to the verification end for authentication request includes: performing matrix operations on the signature random vector and the lattice base matrix to obtain signature auxiliary parameters; performing hash operations on the business data, the signature auxiliary parameters, and the timestamp to obtain a signature hash value; performing combination operations on the user private key vector in the user key pair, the signature hash value, and the signature random vector to obtain the user signature; encapsulating the first domain certificate, the user signature, the signature auxiliary parameters, and the business data into an authentication request message, and sending the authentication request message to the verification end.

[0034] Specifically, after obtaining the first domain certificate, users can use it for business operations. When a user needs to submit business data to the verification end, providing only the certificate is insufficient; the business data also needs to be digitally signed to prove that the data was indeed submitted by the user holding the certificate and that the data has not been tampered with during transmission.

[0035] When a user signs business data, they first need to generate a random signature vector. This random vector is generated in a similar way to the random signature vector generated when a CA (Certificate Authority) issues certificates, both aimed at introducing randomness into the signing process. It's important to note that each signature should use a different random vector. This ensures that even if the same business data is signed multiple times, the generated signatures will be different, thus preventing replay attacks.

[0036] The user equipment performs matrix operations on the signature random vector and the lattice basis matrix to obtain signature auxiliary parameters. These auxiliary parameters essentially map the signature random vector to a public space, allowing the verifier to verify the signature's validity without knowing the signature random vector itself. This design follows the idea of ​​zero-knowledge proofs, where the prover can prove to the verifier that they possess certain secret information without revealing its specific content.

[0037] After obtaining the signature auxiliary parameters, the user equipment needs to perform a hash operation on the business data, signature auxiliary parameters, and timestamp. The timestamp is introduced to prevent replay attacks, because timestamps change over time, and even if an attacker intercepts a historical signature, they cannot use it for current business operations. The hash operation maps these input data into a fixed-length hash value, which plays a binding role in subsequent signature calculations, ensuring that the signature is associated with specific business data and a specific point in time.

[0038] Understandably, hash functions possess one-wayness and collision resistance. One-wayness means that the original input cannot be deduced from the hash value, while collision resistance means that it is difficult to find two different inputs that produce the same hash value. Therefore, by incorporating business data into the hash operation, it can be ensured that the signature is tightly bound to the business data. Any tampering with the business data will cause the hash value to change, thus leading to signature verification failure.

[0039] After obtaining the signature hash value, the user equipment can calculate the user signature. The calculation process for the user signature is structurally similar to the process by which a CA (Certificate Authority) generates a certificate signature; both involve combining several vectors. Specifically, the user equipment uses its own private key vector, signature hash value, and signature random vector to perform a combination operation. This combination operation refers to performing a calculation on the product of the user's private key vector, signature hash value, and signature random vector according to a specific algebraic relationship to obtain the final user signature vector.

[0040] It's important to note that the security of user signatures is based on the difficulty of lattice cryptography. Even if an attacker knows the user's public key, business data, signature auxiliary parameters, and the final user signature, they cannot forge a new signature without knowing the user's private key vector. This is because it is computationally infeasible to deduce the user's private key vector from this publicly available information.

[0041] After calculating the user signature, the user device needs to encapsulate the relevant information into an authentication request message. This message contains the first domain certificate, the user signature, signature auxiliary parameters, and the business data itself. These elements together constitute a complete authentication request. Upon receiving this message, the verification end can use this information to verify the user's identity and the integrity of the business data.

[0042] The user equipment then sends an authentication request message to the verification end. Upon receiving the message, the verification end can extract various information for verification. The verification process typically includes two aspects: first, verifying the validity of the first domain certificate, i.e., whether the certificate was issued by a trusted CA center and whether the certificate is within its validity period; second, verifying the validity of the user signature, i.e., whether the signature was indeed generated by the user holding the private key of the certificate and whether the business data has been tampered with. Only when both aspects of verification pass will the verification end accept the business request.

[0043] 104. The first domain certificate is determined by the verification terminal. When the determination result is cross-domain, the first domain certificate is converted according to the CA conversion key set to obtain the second domain certificate. The second domain certificate and the user signature are verified to obtain the authentication result.

[0044] In this embodiment, the domain determination of the first domain certificate through the verification terminal includes: extracting the issuer identifier from the first domain certificate through the verification terminal to obtain a first CA identifier; comparing the first CA identifier with the second CA identifier to which the verification terminal belongs; and determining that the domain determination result is cross-domain when the first CA identifier and the second CA identifier are inconsistent.

[0045] Specifically, after receiving an authentication request message, the verification end first needs to determine whether the certificate submitted by the user belongs to the current authentication domain. This determination process is called domain determination, and its purpose is to determine whether the certificate was issued by this CA center or by another CA center.

[0046] The authenticator can extract the issuer identification information from the first domain certificate. Digital certificates typically contain multiple fields, among which the issuer field identifies which Certificate Authority (CA) issued the certificate. By parsing the issuer field of the certificate, the authenticator can obtain the first CA identifier, which uniquely corresponds to the certificate's issuing authority.

[0047] After obtaining the first CA identifier, the authenticator can compare it with its own CA identifier. Each authenticator belongs to a specific CA authentication domain. For example, an authenticator might belong to the authentication domain of a second CA center, and the CA identifier of that authenticator is the second CA identifier. The authenticator compares the first CA identifier with the second CA identifier. If they are the same, it means that the certificate was issued by the CA center of this authentication domain and is a same-domain certificate; if they are different, it means that the certificate was issued by the CA center of another authentication domain and is a cross-domain certificate.

[0048] It's important to note that in traditional PKI systems, when the verification end detects a certificate as cross-domain, it typically rejects the certificate or requires the user to resubmit a certificate from the user's own domain. This is the fundamental reason why users need to hold multiple certificates. The innovation of this application lies in the fact that, upon determining a certificate to be cross-domain, the verification end does not directly reject it, but instead uses a certificate conversion mechanism to convert the cross-domain certificate into a certificate in the user's own domain format.

[0049] Specifically, when the domain determination result is cross-domain, the verification end can initiate the certificate conversion process. The verification end searches for the corresponding conversion key from the inter-CA conversion key set based on the first CA identifier and the second CA identifier. This conversion key is generated by the first and second CA centers through key negotiation during the system initialization phase, and is specifically used to convert the certificate issued by the first CA center into a certificate in the format issued by the second CA center.

[0050] Then, the verification end uses this conversion key to convert the first domain certificate. The core of this conversion process is performing algebraic operations on the signature portion of the certificate, using the conversion key to transform the signature of the first CA center into the signature of the second CA center. It should be noted that this conversion is not a simple signature replacement, but a mathematical transformation based on proxy re-signature technology. The resulting second domain certificate conforms to the second CA center's issuance specifications in terms of signature format and can be verified using the second CA center's public key.

[0051] Understandably, the certificate conversion process maintains the consistency of the certificate content; that is, the user's public key, user identifier, and other information in the certificate remain unchanged before and after the conversion, with only the certificate signature changing. This ensures that the converted certificate still represents the same user identity, only the signature format is adapted to the authentication domain of the verification end.

[0052] After obtaining the second domain certificate, the verification end can verify the certificate and the user signature. The certificate verification process includes checking the validity of the second domain certificate's signature, specifically by using the public key of the second CA center to verify the certificate signature and confirm that the certificate was indeed issued by the second CA center and has not been tampered with. The user signature verification process includes using the user's public key in the certificate to verify the user signature, confirming that the signature of the business data was generated by the user holding the private key of the certificate.

[0053] The verification end obtains the final authentication result based on the certificate verification result and the user signature verification result. If both verifications pass, the authentication result is successful, and the verification end accepts the business request; if either verification fails, the authentication result is unsuccessful, and the verification end rejects the business request.

[0054] In this embodiment, the process of converting the first domain certificate according to the inter-CA conversion key set to obtain a second domain certificate, and verifying the second domain certificate and the user signature to obtain an authentication result includes: searching for a conversion key from the inter-CA conversion key set based on the first CA identifier and the second CA identifier; performing calculations on the first certificate signature in the first domain certificate, the conversion key, and the random number corresponding to the second CA center to obtain a second certificate signature; updating the first domain certificate with the second certificate signature to obtain the second domain certificate; performing matrix operations on the second certificate signature and the lattice base matrix to obtain a first verification value; performing calculations based on the second CA public key, the system master public key, and certificate parameters to obtain a second verification value; comparing and verifying the first verification value and the second verification value to obtain a certificate verification result; and performing verification operations on the user signature and the user public key, and obtaining the authentication result based on the certificate verification result and the signature verification result.

[0055] Specifically, after determining that certificate conversion is required, the verification end can look up the corresponding conversion key from the inter-CA conversion key set based on the first CA identifier and the second CA identifier. The inter-CA conversion key set stores the conversion keys between various CA pairs, and each conversion key is associated with a pair of CA identifiers. By constructing an index composed of the first CA identifier and the second CA identifier, the verification end can accurately locate the required conversion key.

[0056] After obtaining the conversion key, the verification end can perform conversion operations on the first certificate signature in the first domain certificate. This conversion operation involves the first certificate signature, the conversion key, and the random number corresponding to the second CA center. It should be noted that the random number corresponding to the second CA center is generated during the key negotiation phase and embedded in the conversion key. During the conversion process, this random number needs to be separated from or compensated for in the signature to ensure that the converted signature conforms to the signature format of the second CA center. Through this series of operations, the second certificate signature can be obtained.

[0057] The verification end updates the first domain certificate with the second certificate signature, replacing the original first certificate signature, thus obtaining the second domain certificate. It's understandable that compared to the first domain certificate, only the certificate signature changes in the second domain certificate; other fields such as the user's public key, user identification information, and certificate validity period remain unchanged. This design ensures that certificate conversion does not change the user identity represented by the certificate; it simply adapts the signature format to the authentication domain of the verification end.

[0058] After obtaining the second domain certificate, the verification end needs to verify its validity. The core of certificate verification is checking the correctness of the certificate signature, that is, verifying whether the second certificate signature can indeed be verified using the public key of the second CA center. The verification end first performs matrix operations on the second certificate signature and the lattice basis matrix to obtain the first verification value. This matrix operation essentially maps the signature vector to a point in the lattice space; the position of this point reflects the mathematical properties of the signature.

[0059] Next, the verification end needs to calculate the expected verification value, i.e., the second verification value. Calculating the second verification value requires the second CA public key, the system master public key, and certificate parameters. These certificate parameters include the user's public key, user identification information, and auxiliary parameters generated during the aforementioned signing process. The verification end performs calculations based on these parameters using specific algebraic formulas to obtain the second verification value that should appear if the signature is correct.

[0060] It's important to note that the system master public key is a public parameter generated during the initialization of the entire PKI system. A specific mathematical relationship exists between the public keys of all Certificate Authority (CA) centers and the system master public key. Introducing the system master public key into the certificate verification process ensures that the verification algorithm can correctly process the converted certificate signature. This is because although the converted signature conforms to the signature specifications of the second CA center in format, its internal structure still retains information related to the first CA center. The participation of the system master public key allows the verification algorithm to correctly extract and verify this information.

[0061] The verification end compares the first verification value and the second verification value. If the two verification values ​​are equal or consistent within the allowable error range, it means that the second certificate signature is valid and the certificate verification result is passed; if the two verification values ​​are not equal, it means that the certificate signature is invalid or the certificate content has been tampered with and the certificate verification result is failed.

[0062] Understandably, this verification method is based on the mathematical structure of lattice cryptography. In lattice cryptography, the validity of a signature can be determined by checking whether a certain equation holds true. The first and second verification values ​​represent the left and right sides of this equation, respectively; if the equation holds true, the signature is valid. Even if the certificate is transformed, this equation remains intact, which is the core characteristic of proxy re-signature technology.

[0063] After certificate verification, the authenticating end also needs to verify the user signature. The purpose of user signature verification is to confirm that the business data was indeed signed by the user holding the private key of the certificate. The authenticating end uses the user's public key from the certificate to perform a verification operation on the user signature. This operation is also based on lattice cryptography, determining the validity of the signature by checking whether a specific mathematical equation holds true. If the user signature verification passes, it means that the business data was indeed submitted by the user and has not been tampered with. The authenticating end determines the authentication result based on the certificate verification result and the signature verification result. Only when both certificate verification and user signature verification pass will the authenticating end output an authentication success result and accept the user's business request. If either verification fails, an authentication failure result is output, and the business request is rejected. This dual verification mechanism ensures the security and reliability of cross-domain authentication.

[0064] Furthermore, the step of searching for a conversion key from the inter-CA conversion key set based on the first CA identifier and the second CA identifier, and performing operations on the first certificate signature in the first domain certificate, the conversion key, and the random number corresponding to the second CA center to obtain the second certificate signature includes: constructing a key index based on the first CA identifier and the second CA identifier; retrieving the corresponding conversion key from the inter-CA conversion key set based on the key index; performing vector addition on the vector representation of the first certificate signature and the vector representation of the conversion key to obtain an intermediate signature vector; and performing vector subtraction on the intermediate signature vector and the random number corresponding to the second CA center to obtain the second certificate signature.

[0065] Specifically, the verification end can perform a transformation operation on the first certificate signature in the first domain certificate. This transformation operation involves the first certificate signature, the transformation key, and the random number corresponding to the second CA center. Through this series of operations, the second certificate signature can be obtained. The verification end updates the first domain certificate with the second certificate signature, replacing the original first certificate signature, thereby obtaining the second domain certificate.

[0066] It should be noted that, compared to the first domain certificate, only the certificate signature changes in the second domain certificate; other fields, such as the user's public key and user identification information, remain unchanged. This ensures that certificate conversion does not alter the user identity represented by the certificate. After obtaining the second domain certificate, the verification end needs to verify its validity. The verification end first performs matrix operations on the second certificate signature and the lattice basis matrix to obtain the first verification value. This matrix operation essentially maps the signature vector to a point in the lattice space.

[0067] Next, the verification end needs to calculate the expected verification value, i.e., the second verification value. Calculating the second verification value requires the second CA public key, the system master public key, and certificate parameters. The verification end performs calculations based on these parameters according to specific algebraic formulas to obtain the second verification value. The participation of the system master public key enables the verification algorithm to correctly process the transformed certificate signature. The verification end compares the first and second verification values. If the two verification values ​​are equal, the certificate verification result is successful; if they are not equal, the certificate verification result is unsuccessful. This verification method is based on the mathematical structure of lattice cryptography, ensuring that the verification equation remains intact even after the certificate has been transformed. After completing certificate verification, the verification end also needs to verify the user signature. The verification end uses the user's public key from the certificate to perform verification calculations on the user signature, determining the validity of the signature by checking whether a specific mathematical equation holds true.

[0068] In this embodiment, by configuring access to multiple CA centers and negotiating keys, a set of inter-CA conversion keys is obtained. The user equipment generates a key pair and requests a certificate from the first CA center to obtain a first domain certificate. The business data is signed and sent to the verification end. The verification end performs domain determination on the first domain certificate. When it is determined to be cross-domain, the first domain certificate is converted according to the conversion key set to obtain a second domain certificate, and the second domain certificate and the user signature are verified. This invention, through a certificate conversion mechanism, enables users to use only one digital certificate in multiple CA authentication domains, achieving cross-domain certificate interoperability and solving the technical problem of certificate mutual recognition between multiple CA authentication domains.

[0069] Please see Figure 2 Another embodiment of the multi-CA cross-domain certificate authentication method in this application includes: 201. Configure access for multiple CA centers to obtain a set of CA identifiers. Select a first CA identifier and a second CA identifier from the set of CA identifiers, generate negotiation parameters, and send the negotiation parameters to the first CA center corresponding to the first CA identifier and the second CA center corresponding to the second CA identifier, respectively. In this embodiment, after receiving a key negotiation request, the proxy server needs to select two CA centers from the CA identifier set to establish a conversion key. For example, if the system needs to establish a conversion key between a first CA center and a second CA center, the proxy server can select the first CA identifier and the second CA identifier from the CA identifier set.

[0070] After determining the CA (Center) pairs to be negotiated, the proxy server needs to generate negotiation parameters. Generating these parameters is a crucial step in the secure multi-party computation scheme based on the Chinese Remainder Theorem. Specifically, the proxy server needs to select two coprime integers as the negotiation modulo. The coprimeness of these two moduloes is a prerequisite for the application of the Chinese Remainder Theorem. If the two moduloes have a common divisor, the subsequent inverse operation will not yield a unique solution.

[0071] It's important to note that the selection of the negotiation modulus requires a balance between security and computational efficiency. A modulus that is too small will result in insufficient security, allowing attackers to potentially break the negotiation process through brute-force attacks; a modulus that is too large will increase the computational burden. In practical applications, an appropriate modulus can be selected based on the system's security requirements.

[0072] After generating the negotiation parameters, the proxy server sends these parameters to the first and second CA centers respectively. Each CA center receives the same negotiation parameters, allowing them to perform subsequent modular decomposition operations on the same mathematical foundation. This design ensures the symmetry of the negotiation process, meaning that the two CA centers have equal status during the negotiation process.

[0073] 202. The first CA center and the second CA center respectively perform modulo decomposition on the negotiation parameters based on the first CA private key and the second CA private key and the corresponding random number, and combine the decomposition results to obtain the combined result; In this embodiment, after receiving the negotiation parameters, the first CA center and the second CA center perform modular decomposition operations respectively. It should be noted that the operation processes of the two CA centers are carried out independently, and they are unaware of each other's private keys and random numbers. This is the core characteristic of secure multi-party computation.

[0074] The first CA center calculates the difference between its private key and the corresponding random number. This difference reflects the negative component that the first CA center needs to contribute in the key conversion. Then, the first CA center performs a first modulo operation and a second modulo operation on this difference, obtaining two modulo decomposition results. These two results reflect the remainders of the difference under two different moduli, forming part of the "system of congruence equations" in the Chinese Remainder Theorem.

[0075] The operation process of the second CA center is similar to that of the first CA center, but it calculates the sum of the second CA private key and the corresponding random number. This sum reflects the positive component that the second CA center needs to contribute to the key conversion. The second CA center also performs the first modulo operation and the second modulo operation on this sum to obtain the second modulo factorization result.

[0076] Understandably, the asymmetric design—where the first CA calculates the difference and the second CA calculates the sum—is the algebraic basis for the successful conversion of certificate signatures using the conversion key. When these two sets of decomposition results are recombinated using the Chinese Remainder Theorem, the difference and sum are synthesized into the final conversion key according to a specific algebraic relationship.

[0077] After the two CA centers complete their modular decomposition operations, they send their respective decomposition results to the proxy server. Upon receiving the first and second modular decomposition results, the proxy server combines them. This combination process involves summing the results for corresponding moduli in the first and second modular decomposition results to obtain two combined values. These two combined values ​​form a new system of congruence equations, preparing for subsequent inverse modular decomposition operations.

[0078] It's important to note that throughout the entire modular decomposition and combination process, the private key of the first CA center never leaves its own center, and the private key of the second CA center also never leaves its own center. The proxy server can only obtain the results of the modular decomposition and cannot deduce the private keys of the CA centers from these results. This is because the modular decomposition operation introduces random numbers, and the modular operation itself has the characteristic of information hiding.

[0079] 203. Perform inverse modular operation based on the combination result and the negotiation parameters to obtain the conversion key between the first CA identifier and the second CA identifier, and store the conversion key in the CA inter-conversion key set; In this embodiment, after obtaining the combination result, the proxy server needs to recover the conversion key through the inverse operation of the Chinese Remainder Theorem. The Chinese Remainder Theorem states that if the remainders of a number under multiple coprime moduli are known, then the value of that number under the product of these moduli can be uniquely determined.

[0080] Specifically, the proxy server constructs a system of congruence equations based on the combination results. This system contains two congruence equations, corresponding to the first and second negotiated moduli, respectively. Using the algorithm based on the Chinese Remainder Theorem, the proxy server can calculate a unique solution from this system of equations; this solution is the conversion key.

[0081] It should be noted that the algebraic structure of the conversion key enables it to correctly perform the certificate signature conversion function. Mathematically, the conversion key equals the sum of the second CA's private key and its random number, minus the first CA's private key, plus the first CA's random number. This structure ensures that when the conversion key is used in conjunction with the first CA's signature, the influence of the first CA's private key is eliminated, and the influence of the second CA's private key is introduced, thus achieving the conversion of the signature from the first CA format to the second CA format.

[0082] After calculating the conversion key, the proxy server associates and stores it with the corresponding CA identifier pair. This conversion key is marked as the conversion key from the first CA identifier to the second CA identifier and stored in the inter-CA conversion key set. In subsequent certificate conversion processes, the verifier can quickly retrieve the required conversion key from this set based on the certificate issuer identifier and the CA identifier to which the verifier belongs.

[0083] 204. Perform key processing on the user equipment to obtain a user key pair, and request a certificate from the first CA center based on the user key pair to obtain a first domain certificate; 205. Sign the business data and the user key pair to obtain the user signature, and send the first domain certificate and the user signature to the verification terminal to make an authentication request; 206. The first domain certificate is determined by the verification terminal. When the determination result is cross-domain, the first domain certificate is converted according to the CA conversion key set to obtain the second domain certificate. The second domain certificate and the user signature are verified to obtain the authentication result.

[0084] In this embodiment, steps 204-206 are similar to steps 102-104 in the first embodiment, and will not be described again here.

[0085] In this embodiment, by configuring access to multiple CA centers and negotiating keys, a set of inter-CA conversion keys is obtained. The user equipment generates a key pair and requests a certificate from the first CA center to obtain a first domain certificate. The business data is signed and sent to the verification end. The verification end performs domain determination on the first domain certificate. When it is determined to be cross-domain, the first domain certificate is converted according to the conversion key set to obtain a second domain certificate, and the second domain certificate and the user signature are verified. This invention, through a certificate conversion mechanism, enables users to use only one digital certificate in multiple CA authentication domains, achieving cross-domain certificate interoperability and solving the technical problem of certificate mutual recognition between multiple CA authentication domains.

[0086] The multi-CA cross-domain certificate authentication method in the embodiments of the present invention has been described above. The multi-CA cross-domain certificate authentication device in the embodiments of the present invention is described below. Please refer to [link to relevant documentation] for details on this multi-CA cross-domain certificate authentication device. Figure 3 One embodiment of the multi-CA cross-domain certificate authentication device in this invention includes: The key negotiation module 301 is used to configure access to multiple CA centers, obtain a set of CA identifiers, and perform key negotiation on the CA centers in the set of CA identifiers to obtain a set of inter-CA conversion keys; The certificate application module 302 is used to process the key of the user equipment to obtain a user key pair, and to request a certificate from the first CA center based on the user key pair to obtain a first domain certificate. The signature sending module 303 is used to perform signature processing on the business data and the user key pair to obtain the user signature, and send the first domain certificate and the user signature to the verification end to make an authentication request. The cross-domain authentication module 304 is used to determine the domain of the first domain certificate through the verification terminal. When the determination result is cross-domain, the first domain certificate is converted according to the CA conversion key set to obtain the second domain certificate. The second domain certificate and the user signature are verified to obtain the authentication result.

[0087] In this embodiment of the invention, the multi-CA cross-domain certificate authentication device operates the aforementioned multi-CA cross-domain certificate authentication method. The device obtains an inter-CA conversion key set by configuring access to multiple CA centers and negotiating keys. The user equipment generates a key pair and requests a certificate from the first CA center to obtain a first domain certificate. Business data is signed and sent to the verification end. The verification end performs domain determination on the first domain certificate. If it determines that the certificate is cross-domain, it converts the first domain certificate according to the conversion key set to obtain a second domain certificate, and then verifies the second domain certificate and the user's signature. This invention, through a certificate conversion mechanism, allows users to use only one digital certificate across multiple CA authentication domains, achieving cross-domain certificate interoperability and solving the technical problem of certificate mutual recognition between multiple CA authentication domains. above Figure 3 The multi-CA cross-domain certificate authentication device in the embodiments of the present invention will be described in detail from the perspective of unitized functional entities. The multi-CA cross-domain certificate authentication device in the embodiments of the present invention will be described in detail from the perspective of hardware processing.

[0088] Figure 4This is a schematic diagram of the structure of a multi-CA cross-domain certificate authentication device 400 provided in an embodiment of the present invention. The multi-CA cross-domain certificate authentication device 400 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 410 (e.g., one or more processors) and a memory 420, and one or more storage media 430 (e.g., one or more mass storage devices) for storing application programs 433 or data 432. The memory 420 and storage media 430 can be temporary or persistent storage. The program stored in the storage media 430 may include one or more units (not shown in the diagram), each unit may include a series of instruction operations on the multi-CA cross-domain certificate authentication device 400. Furthermore, the processor 410 may be configured to communicate with the storage media 430 and execute the series of instruction operations in the storage media 430 on the multi-CA cross-domain certificate authentication device 400 to implement the steps of the above-described multi-CA cross-domain certificate authentication method.

[0089] The multi-CA cross-domain certificate authentication device 400 may also include one or more power supplies 440, one or more wired or wireless network interfaces 450, one or more input / output interfaces 460, and / or one or more operating systems 431, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 4 The multi-CA cross-domain certificate authentication device structure shown does not constitute a limitation on the multi-CA cross-domain certificate authentication device provided by the present invention. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0090] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the multi-CA cross-domain certificate authentication method.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system, device, or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0092] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A multi-CA cross-domain certificate authentication method, characterized in that, The multi-CA cross-domain certificate authentication method includes: Access configuration is performed on multiple CA centers to obtain a set of CA identifiers, and key negotiation is performed on the CA centers in the set of CA identifiers to obtain a set of inter-CA conversion keys; The user equipment is processed to obtain a user key pair, and a certificate is requested from the first CA center based on the user key pair to obtain a first domain certificate; The business data and the user key pair are signed to obtain the user signature. The first domain certificate and the user signature are then sent to the verification end to request authentication. The verification terminal performs domain determination on the first domain certificate. When the determination result is cross-domain, the first domain certificate is converted according to the CA inter-conversion key set to obtain the second domain certificate. The second domain certificate and the user signature are then verified to obtain the authentication result.

2. The multi-CA cross-domain certificate authentication method according to claim 1, characterized in that, The process of configuring access to multiple CA centers to obtain a set of CA identifiers, and then negotiating keys among the CA centers in the set of CA identifiers to obtain a set of inter-CA conversion keys, includes: Multiple CA centers are configured for access to obtain a set of CA identifiers. A first CA identifier and a second CA identifier are selected from the set of CA identifiers to generate negotiation parameters. The negotiation parameters are then sent to the first CA center corresponding to the first CA identifier and the second CA center corresponding to the second CA identifier, respectively. The first CA center and the second CA center respectively perform modulo decomposition on the negotiation parameters based on the first CA private key and the second CA private key and the corresponding random number, and combine the decomposition results to obtain the combined result; Based on the combination result and the negotiation parameters, perform inverse modular operation to obtain the conversion key between the first CA identifier and the second CA identifier, and store the conversion key in the CA inter-conversion key set.

3. The multi-CA cross-domain certificate authentication method according to claim 1, characterized in that, The step of performing key processing on the user equipment to obtain a user key pair, and requesting a certificate from the first CA center based on the user key pair to obtain a first domain certificate includes: A private key vector is generated for the user equipment to obtain a user private key vector. Matrix operations are performed on the user private key vector and the lattice basis matrix to obtain a user public key. The user private key vector and the user public key constitute the user key pair. A certificate request is generated based on the user's public key and user identification information in the user key pair, and the certificate request is sent to the first CA center; The first CA center performs matrix operations on the signature random vector and the lattice base matrix to obtain auxiliary parameters. Based on the auxiliary parameters and the information in the certificate request, a hash operation is performed to obtain a hash value. A certificate signature is obtained by performing a linear combination operation on the private key vector of the first CA center, the product of the hash value and the signature random vector, and the random number corresponding to the first CA center. The certificate signature, the auxiliary parameters, and the user public key are then encapsulated to obtain the first domain certificate.

4. The multi-CA cross-domain certificate authentication method according to claim 3, characterized in that, The step of signing the business data and the user key pair to obtain a user signature, and then sending the first domain certificate and the user signature to the verification end to make an authentication request, includes: Matrix operations are performed on the signature random vector and the lattice base matrix to obtain signature auxiliary parameters. A hash operation is then performed on the business data, the signature auxiliary parameters, and the timestamp to obtain the signature hash value. The user signature is obtained by combining the user private key vector, the signature hash value, and the signature random vector in the user key pair. The first domain certificate, the user signature, the signature auxiliary parameters, and the business data are encapsulated into an authentication request message, and the authentication request message is sent to the verification terminal.

5. The multi-CA cross-domain certificate authentication method according to claim 1, characterized in that, The step of performing domain determination on the first domain certificate through the verification terminal includes: The first CA identifier is obtained by extracting the issuer identifier from the first domain certificate through the verification terminal; The first CA identifier and the second CA identifier to which the verification terminal belongs are compared. When the first CA identifier and the second CA identifier are inconsistent, the domain determination result is determined to be cross-domain.

6. The multi-CA cross-domain certificate authentication method according to claim 3, characterized in that, The process of converting the first domain certificate according to the inter-CA conversion key set to obtain a second domain certificate, and verifying the second domain certificate and the user signature to obtain the authentication result includes: Based on the first CA identifier and the second CA identifier, the conversion key is searched from the set of inter-CA conversion keys. The first certificate signature in the first domain certificate, the conversion key, and the random number corresponding to the second CA center are calculated to obtain the second certificate signature. The second certificate signature is then updated in the first domain certificate to obtain the second domain certificate. Matrix operations are performed on the second certificate signature and the lattice base matrix to obtain the first verification value. Calculations are then performed based on the second CA public key, the system master public key, and the certificate parameters to obtain the second verification value. The first verification value and the second verification value are compared and verified to obtain the certificate verification result. The user signature and the user public key are verified, and the authentication result is obtained based on the certificate verification result and the signature verification result.

7. The multi-CA cross-domain certificate authentication method according to claim 6, characterized in that, The step of searching for a conversion key from the inter-CA conversion key set based on the first CA identifier and the second CA identifier, and performing calculations on the first certificate signature in the first domain certificate, the conversion key, and the random number corresponding to the second CA center to obtain the second certificate signature includes: A key index is constructed based on the first CA identifier and the second CA identifier, and the corresponding conversion key is retrieved from the inter-CA conversion key set based on the key index; Perform vector addition on the vector representation of the first certificate signature and the vector representation of the conversion key to obtain an intermediate signature vector; The intermediate signature vector and the random number corresponding to the second CA center are subtracted by a vector operation to obtain the second certificate signature.

8. A multi-CA cross-domain certificate authentication device, characterized in that, The multi-CA cross-domain certificate authentication device includes: The key negotiation module is used to configure access to multiple CA centers, obtain a set of CA identifiers, and perform key negotiation on the CA centers in the set of CA identifiers to obtain a set of inter-CA conversion keys. The certificate application module is used to perform key processing on the user equipment to obtain a user key pair, and to request a certificate from the first CA center based on the user key pair to obtain a first domain certificate. The signature sending module is used to sign the business data and the user key pair to obtain the user signature, and send the first domain certificate and the user signature to the verification end to make an authentication request. The cross-domain authentication module is used to determine the domain of the first domain certificate through the verification terminal. When the determination result is cross-domain, the first domain certificate is converted according to the CA conversion key set to obtain the second domain certificate. The second domain certificate and the user signature are then verified to obtain the authentication result.

9. A multi-CA cross-domain certificate authentication device, characterized in that, The multi-CA cross-domain certificate authentication device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the multi-CA cross-domain certificate authentication device to perform the steps of the multi-CA cross-domain certificate authentication method as described in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instruction is executed by the processor, it implements the steps of the multi-CA cross-domain certificate authentication method as described in any one of claims 1-7.

Images