A certificate issuing method, system, device and storage medium

Abstract

The application discloses a certificate issuing method, system, device and storage medium, and relates to the technical field of information security, and the method comprises the following steps: a server receives a certificate request from a device to be issued, wherein the certificate request carries a public key in a key encapsulation mechanism key pair of the device to be issued; a first random value is generated, and the first random value is key encapsulated by using the public key to obtain first ciphertext; first verification information is generated based on the first random value; second verification information from the device to be issued is received, wherein the second verification information is generated after the device to be issued obtains the first random value by using a private key in the key encapsulation mechanism key pair to disencapsulate the first ciphertext; whether the first verification information and the second verification information match is verified; and if yes, a certificate is issued for the public key of the device to be issued. An effective mechanism for safely issuing a certificate for a KEM public key without relying on a digital signature function and without introducing an additional signature key pair.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a certificate issuance method, system, device, and storage medium. Background Technology

[0002] With the rise of quantum computing technology, traditional public-key cryptography faces potential threats, making post-quantum cryptography (PQC) an inevitable choice. Key Encapsulation Mechanisms (KEMs), as a core component resistant to quantum attacks (such as the NIST-standardized CRYSTALS-Kyber), have attracted significant attention due to their advantages in secure key distribution. However, KEM algorithms have limited functionality; their key pairs cannot perform digital signature operations, fundamentally contradicting the certificate issuance process in traditional PKI systems. Currently, two main adaptation solutions exist: one is the traditional PKCS#10 certificate request mechanism, which mandates the use of a private key to sign the request, rendering unsignable KEM key pairs unusable; the other is a dual-certificate mechanism, which manages both a post-quantum signature key pair (for certificate request signing and authentication) and a KEM key pair (for key exchange) for the same applicant to circumvent the KEM's inability to sign.

[0003] While the aforementioned solutions attempt to address the integration of KEM and PKI, they all suffer from significant drawbacks. The traditional PKCS#10 mechanism is directly ineffective for KEM key pairs, and while the current mainstream dual-certificate mechanism achieves functionality, it introduces enormous complexity and resource overhead. This approach requires devices to store and manage two sets of post-quantum keys and certificates, whose storage, transmission, and computational energy consumption far exceeds that of a single KEM system, placing a heavy burden, especially on resource-constrained IoT devices. Summary of the Invention

[0004] The main objective of this invention is to provide a certificate issuance method, system, device, and storage medium. It provides an effective mechanism for securely issuing certificates for KEM public keys without relying on digital signature functionality or introducing additional signature key pairs, thus replacing traditional digital signature mechanisms. This application ensures that only the device truly holding the corresponding private key can successfully decapsulate the random value and generate matching verification information, thereby authenticating its ownership of the private key. Simultaneously, the verification information is strongly bound to the random value and the certificate request; any tampering with the request will result in verification failure, thereby ensuring the integrity and authenticity of the requested data. Based on this verification result, a legitimate certificate is issued for the device's public key, laying the foundation for subsequent secure key exchange and reliable identity authentication.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0006] According to a first aspect of the embodiments of this application, a certificate issuance method is provided, the method comprising:

[0007] The server receives a certificate request from a device to be signed, the certificate request carrying the public key from the key pair of the key encapsulation mechanism of the device to be signed.

[0008] A first random value is generated, and the first random value is key-encapsulated using the public key to obtain a first ciphertext. The first ciphertext is then sent to the device to be signed. First verification information is generated based on the first random value.

[0009] Receive second verification information from the device to be issued, wherein the second verification information is generated by the device to be issued after decapsulating the first ciphertext using the private key in the key pair of the key encapsulation mechanism to obtain the first random value;

[0010] Verify whether the first verification information matches the second verification information; if they match, then it is the public key signing certificate for the device to be signed.

[0011] Optionally, the first verification information and the second verification information are message authentication codes;

[0012] The step of generating the first verification information based on the first random value includes: calculating a message authentication code for the certificate request based on the first random value;

[0013] The second verification information is a message authentication code calculated by the device based on the first random value obtained from decapsulation of the certificate request.

[0014] Optionally, issuing a certificate for the public key of the device to be signed includes:

[0015] Using the server's own private key, and based on the information in the certificate request, issue a key encapsulation mechanism certificate in a preset standard format to the device to be issued;

[0016] The key encapsulation mechanism certificate is sent to the device to be issued.

[0017] Optionally, after receiving the certificate request and before generating the first random value, the method further includes:

[0018] The validity of the data structure and / or content of the certificate request is verified;

[0019] If the verification fails, the process terminates; if the verification passes, the step of generating the first random value continues.

[0020] Optionally, it also includes:

[0021] Receive an authentication request from a device to be authenticated, the authentication request carrying a key encapsulation mechanism certificate held by the device to be authenticated;

[0022] A second random value is generated, and the second random value is encapsulated using the public key in the key encapsulation mechanism certificate to obtain a second ciphertext. The second ciphertext is then sent to the device to be authenticated. A third verification message is generated based on the second random value.

[0023] Receive fourth verification information from the device to be authenticated; wherein, the fourth verification information is generated by the device to be authenticated after decapsulating the second ciphertext using the private key in the key pair of the key encapsulation mechanism to obtain the second random value;

[0024] Verify whether the third verification information matches the fourth verification information; if they match, confirm that the device to be certified has passed the certification.

[0025] Optionally, the third verification information and the fourth verification information are message authentication codes; the step of generating the third verification information based on the second random value includes: calculating the message authentication code based on the preset consensus information based on the second random value;

[0026] The fourth verification information is a message authentication code calculated by the device to be authenticated based on the second random value obtained from decapsulation and the preset consensus information; the preset consensus information is any one of the following: the public key in the key encapsulation mechanism certificate, the key encapsulation mechanism certificate, and the identifier of the device to be authenticated.

[0027] Optionally, before generating the second random value, the method further includes:

[0028] The validity of the key encapsulation mechanism certificate is verified, and the validity verification includes checking one or more of the following: certificate revocation status, certificate validity period, certificate signature validity, and certificate chain integrity.

[0029] If the validity verification fails, the process terminates; if the validity verification passes, the process continues to generate the second random value.

[0030] According to a second aspect of the embodiments of this application, a certificate issuance system is provided, the system comprising:

[0031] The message receiving module is used to receive a certificate request from a device to be signed, the certificate request carrying the public key in the key pair of the key encapsulation mechanism of the device to be signed;

[0032] The processing module is configured to generate a first random value, encapsulate the first random value using the public key to obtain a first ciphertext, send the first ciphertext to the device to be signed, and generate first verification information based on the first random value.

[0033] The message receiving module is further configured to receive second verification information from the device to be signed, wherein the second verification information is generated by the device to be signed after decapsulating the first ciphertext using the private key in the key pair of the key encapsulation mechanism to obtain the first random value;

[0034] The verification module is used to verify whether the first verification information matches the second verification information; if they match, it is the public key signing certificate for the device to be signed.

[0035] According to a third aspect of the present application, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0036] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided having computer-readable instructions stored thereon, the computer-readable instructions being executable by a processor to implement the method described in the first aspect above.

[0037] In summary, this application provides a certificate issuance method, system, device, and storage medium. The process involves a server receiving a certificate request from a device to be issued, the certificate request carrying the public key from the key pair of the key encapsulation mechanism of the device to be issued; generating a first random value and encapsulating the first random value using the public key to obtain first ciphertext, which is then sent to the device to be issued; generating first verification information based on the first random value; receiving second verification information from the device to be issued, the second verification information being generated by the device to be issued after decapsulating the first ciphertext using the private key from the key encapsulation mechanism key pair to obtain the first random value; verifying whether the first verification information matches the second verification information; if they match, issuing a certificate for the public key of the device to be issued. This is an effective mechanism for securely issuing certificates for KEM public keys without relying on digital signature functionality and without introducing additional signature key pairs, thus replacing traditional digital signature mechanisms. This application ensures that only the device that truly holds the corresponding private key can successfully decapsulate the random value and generate matching verification information, thereby completing the authentication of its private key ownership. Simultaneously, the verification information is strongly bound to the random value and certificate request. Any tampering with the request will result in verification failure, thus ensuring the integrity and authenticity of the requested data. Based on this verification result, a legitimate certificate is issued for the device's public key, laying the foundation for subsequent secure key exchange and reliable identity authentication. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0039] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0040] Figure 1 This application provides a schematic flowchart of a certificate issuance method.

[0041] Figure 2 A schematic diagram of the certificate request process provided in this application embodiment;

[0042] Figure 3 This is a schematic diagram of the certificate authentication process provided in an embodiment of this application;

[0043] Figure 4 This is a schematic diagram of a certificate issuance system provided in an embodiment of this application;

[0044] Figure 5 This paper shows a structural diagram of an electronic device provided in an embodiment of this application;

[0045] Figure 6 A diagram of a computer-readable storage medium provided in an embodiment of this application is shown.

[0046] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0047] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0048] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0049] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0050] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0051] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0052] To address the aforementioned technical issues, this application proposes a quantum-resistant cryptographic KEM single-certificate issuance and authentication mechanism. This mechanism achieves secure certificate issuance for KEM public keys and identity authentication based on a single KEM certificate without relying on digital signature algorithms or generating signature-key pairs. By modifying the certificate request process and certificate authentication procedure, it enables secure management and authentication of KEM public key certificates in scenarios without signature algorithms or signature-key pairs.

[0053] Figure 1 This application illustrates a certificate issuance method provided by an embodiment of the present application, the method comprising:

[0054] Step 101: The server receives a certificate request from the device to be signed, the certificate request carrying the public key in the key pair of the key encapsulation mechanism of the device to be signed;

[0055] Step 102: Generate a first random value, and use the public key to encapsulate the first random value to obtain a first ciphertext, and send the first ciphertext to the device to be signed; and generate first verification information based on the first random value;

[0056] Step 103: Receive second verification information from the device to be issued, wherein the second verification information is generated by the device to be issued after decapsulating the first ciphertext using the private key in the key pair of the key encapsulation mechanism to obtain the first random value;

[0057] Step 104: Verify whether the first verification information matches the second verification information; if they match, then it is the public key signing certificate for the device to be signed.

[0058] The server uses the device's public key to encapsulate a random number to generate a challenge. The device then decapsulates the challenge and generates a response verification message, securely replacing the signature function. This ensures that only devices legitimately holding the KEM private key can pass verification. Simultaneously, this process strongly binds the verification information to the original certificate request; any tampering with the request will result in verification failure. Thus, even without a signature, both identity authentication and data integrity protection are achieved. A single certificate is securely issued for the KEM public key without introducing an additional signing key pair. This directly overcomes the high complexity and resource overhead of existing dual-certificate mechanisms, providing a crucial technical foundation for building a simplified, efficient, and easily deployable PKI system in the post-quantum era, particularly suitable for resource-constrained IoT scenarios.

[0059] In one possible implementation, before step 102, after receiving the certificate request and before generating the first random value, the method further includes: verifying the legality of the data structure and / or content of the certificate request; if the verification fails, terminating the process; if the verification passes, continuing to execute the step of generating the first random value.

[0060] To ensure the robustness and security of the entire certificate issuance process, a pre-verification step is introduced before the core challenge-response mechanism begins. Specifically, before step 102 (generating and encapsulating the first random value), i.e., after the server receives the certificate request from the device and before generating the first random value, the method also includes a key verification step, including but not limited to the following two aspects: 1. Data structure verification: Verifying whether the format of the certificate request conforms to the expected specifications (e.g., whether it conforms to the syntax structure of standards such as PKCS#10), ensuring that all necessary fields exist and are correctly formatted, and avoiding anomalies in subsequent processing due to malformed data. 2. Content validity verification: Checking the basic logical compliance of the information contained in the request. For example, verifying whether the format of the certificate subject name is valid, or confirming that the public key information contained therein is a valid public key of its declared Key Encapsulation Mechanism (KEM).

[0061] If any issues are detected during the verification process, the server will immediately terminate the certificate issuance process and may optionally return an error message to the device. This fail-fast mechanism effectively prevents resource waste and avoids continuing subsequent cryptographic operations on requests with obvious problems. Only when the certificate request successfully passes all preset verification items will the server continue to generate the first random value and subsequent steps.

[0062] In one possible implementation, the first verification information and the second verification information are message authentication codes; in step 102, generating the first verification information based on the first random value includes: calculating a message authentication code for the certificate request based on the first random value; the second verification information is a message authentication code calculated by the device for the certificate request based on the first random value obtained from decapsulation.

[0063] The core verification mechanism of the certificate issuance method relies on Message Authentication Codes (MACs) to ensure data integrity and identity authentication. Specifically, both the first and second verification messages are defined as MACs, and their generation involves calculating the certificate request, thus achieving secure verification without the need for digital signatures. The first verification message is generated by the server in step 102. It calculates the MAC for the certificate request based on a first random value (generated by the server). This ensures that the verification message is bound to the content of the certificate request; any tampering with the request will result in a change in the MAC value. The second verification message is generated by the device to be issued. The device uses its private key (its key encapsulation mechanism) to decapsulate the received first ciphertext, obtaining a first random value, and then calculates the MAC for the certificate request based on this random value. This process proves that the device possesses the corresponding private key and can correctly handle the challenge.

[0064] After generating the first random value, the server performs two parallel operations: First, it encapsulates the first random value using the device's public key to generate the first ciphertext, which is then sent to the device. Second, it calculates the MAC address of the certificate request based on the first random value, generating the first verification message (which the server retains for subsequent verification). Third, after receiving the first ciphertext, the device decapsulates it using its private key to obtain the first random value, calculates the MAC address of the certificate request based on this random value, generates the second verification message, and then sends it back to the server.

[0065] In one possible implementation, in step 104, issuing a certificate for the public key of the device to be signed includes: using the server's own private key, based on the information in the certificate request, issuing a key encapsulation mechanism certificate in a preset standard format for the device to be signed; and sending the key encapsulation mechanism certificate to the device to be signed.

[0066] In step 104, once the server (as the certification authority) verifies that the first verification information matches the second verification information, it confirms the identity of the device to be certified and the integrity of the certificate request, and then proceeds to the formal certificate issuance stage. The server uses its own private key (which corresponds to a widely trusted root certificate) to generate a key encapsulation mechanism certificate in a preset standard format (such as X.509) based on the device identity information and KEM public key provided in the certificate request. The server then sends the issued certificate back to the device to be certified, completing the entire certificate issuance process.

[0067] In one possible implementation, the method further includes: receiving an authentication request from a device to be authenticated, the authentication request carrying a key encapsulation mechanism certificate held by the device to be authenticated; generating a second random value, and encapsulating the second random value with the public key in the key encapsulation mechanism certificate to obtain a second ciphertext, and sending the second ciphertext to the device to be authenticated; generating third verification information based on the second random value; receiving fourth verification information from the device to be authenticated; wherein the fourth verification information is generated by the device to be authenticated after decapsulating the second ciphertext with the private key in the key encapsulation mechanism key pair to obtain the second random value; verifying whether the third verification information matches the fourth verification information; if they match, confirming that the device to be authenticated has passed authentication.

[0068] The authenticator (server) uses the public key in the KEM certificate to verify whether the other party possesses the corresponding private key through a challenge-response mechanism, thereby completing identity authentication. The authenticator generates a one-time, high-entropy second random value and encapsulates this random value using the KEM public key in the certificate, generating a second ciphertext. The device to be authenticated uses its KEM private key to decapsulate the received second ciphertext, successfully restoring the second random value. Based on the decapsulated second random value, the device generates fourth verification information (e.g., calculates a message authentication code) and returns it to the authenticator. Returning verification information instead of directly returning the random value prevents the plaintext-ciphertext pair from being stolen and used for analysis. The authenticator independently generates third verification information based on its own generated second random value. The authenticator compares its calculated third verification information with the fourth verification information returned by the device. If they match, two conclusions are reached: a. The device successfully decrypted the ciphertext, proving that it indeed possesses the KEM private key bound to the certificate. b. The response, generated based on this challenge, effectively resists replay attacks. The authenticator can then confirm the authentication is successful and grant the device the corresponding access or operation permissions.

[0069] In one possible implementation, before generating the second random value, the method further includes: validating the key encapsulation mechanism certificate, the validity verification including checking one or more of the following: certificate revocation status, certificate validity period, certificate signature validity, and certificate chain integrity; if the validity verification fails, the process is terminated; if the validity verification passes, the step of generating the second random value continues.

[0070] The validity verification described above is a comprehensive check, typically including one or more of the following aspects, which together constitute the criteria for judging trustworthiness: 1. Certificate Revocation Status Check: Check the certificate revocation list or verify through an online certificate status protocol whether the certificate has been revoked in advance by the issuing authority (CA). This is a key line of defense against the use of leaked or invalid certificates. 2. Certificate Validity Check: Verify whether the current time is within the "effective time" to "expiration time" range stated in the certificate declaration. Expired certificates are automatically excluded to ensure the timeliness of authentication. 3. Certificate Signature Validity Verification: Use the public key of the CA that issued the certificate to verify whether the digital signature on the certificate is valid. This confirms that the certificate was indeed issued by a trusted CA and that the content has not been tampered with after issuance. 4. Certificate Chain Integrity Verification: Trace and verify that all certificates in the entire trust chain from the certificate to be authenticated to the root certificate are valid and trustworthy. This ensures the correct transmission of trust relationships.

[0071] The system only determines "validity verification passed" when all checked items pass. Only then will the process proceed to generate a second random value and the subsequent challenge-response steps. This ensures that subsequent computational resources are used to process valuable, trusted authentication requests. If any of the above checks fails (e.g., certificate expired or revoked), the process terminates immediately. The authentication server will directly reject the request and optionally return an error message to the client. This "fail-fast" mechanism greatly improves system efficiency and security, avoiding unnecessary resource waste.

[0072] In one possible implementation, the third and fourth verification information are message authentication codes; generating the third verification information based on the second random value includes: calculating a message authentication code on preset consensus information based on the second random value; the fourth verification information is a message authentication code calculated by the device to be authenticated based on the second random value obtained from decapsulation on the preset consensus information; the preset consensus information is any one of the following: the public key in the key encapsulation mechanism certificate, the key encapsulation mechanism certificate, and the identifier of the device to be authenticated.

[0073] After generating a second random value (challenge), the verifier uses this challenge as a key to calculate the MAC against selected preset consensus information (such as the certificate public key), obtaining the third verification information (H3). After successfully decrypting the second ciphertext and obtaining the challenge, the device uses this challenge as a key to calculate the MAC against the same preset consensus information, obtaining the fourth verification information (H4), and sends it to the verifier. The verifier compares H3 and H4. If they match, it proves that the device holds the correct private key (otherwise, the correct challenge cannot be decrypted). The device's response is based on specific credentials agreed upon by both parties (otherwise, the same MAC cannot be calculated). This ensures that the authentication result is not only based on key ownership but also bound to specific, important security credentials, greatly enhancing the security of the entire single KEM certificate authentication scheme.

[0074] This application addresses the inherent contradiction in post-quantum cryptography where key binding mechanism (KEM) key pairs, due to their functional limitations, cannot be directly used in traditional public key infrastructure (PKI) certificate issuance processes. Traditional certificate issuance relies on the applicant digitally signing the certificate request using their private key to prove ownership of the corresponding private key. However, KEM key pairs in post-quantum cryptography are designed for key binding and debinding, not for generating digital signatures. Therefore, when issuing certificates for KEM public keys, existing technologies either cannot achieve this directly or require an additional set of signing key pairs and certificates, significantly increasing system complexity and resource overhead, especially in resource-constrained IoT devices. This application provides a novel authentication and data integrity guarantee mechanism that does not rely on digital signature functionality, adapting to the inherent characteristics of KEM key pairs. It securely proves a device's ownership of the private key through a challenge-response protocol, utilizing the KEM operations themselves (binding and debinding), thereby enabling the secure issuance of a single KEM certificate without the need for a signing key pair. This directly achieves the fundamental goal of simplifying the key certificate management system and reducing resource consumption, removing key obstacles for the practical application of post-quantum cryptography in a wide range of scenarios.

[0075] To more intuitively and clearly illustrate the interactive steps and data flow of the above process, the following detailed explanation will be provided in conjunction with the accompanying diagrams.

[0076] This application provides a quantum-resistant cryptography KEM single certificate issuance and authentication mechanism, including a modified certificate request process and certificate authentication flow. The following roles are involved:

[0077] 1. Device: As the certificate applicant and the party whose identity is to be verified, it holds the KEM key pair (KEM private key, KEM public key) and the KEM certificate subsequently obtained. The core requirement is to prove the authenticity of its identity to the verifier.

[0078] 2. CA (Certification Authority): As the certificate issuing entity, it is responsible for receiving and verifying the KEM certificate requests submitted by the device. After successful verification, it issues a valid KEM certificate for the device's KEM public key.

[0079] 3. Verifier: As the identity verification subject, the verifier uses the KEM certificate provided by the device to verify whether the device holds the KEM private key corresponding to the certificate, thereby confirming the consistency between the device identity and the information claimed in the certificate.

[0080] Figure 2 This paper illustrates the certificate request process provided in an embodiment of this application, demonstrating the complete interaction between the device and the CA to issue a KEM single certificate based on a challenge-response mechanism. Through a combination of "key encapsulation + message authentication code," it proves that the device holds the KEM private key and ensures the integrity of the request without a digital signature. Specifically, it includes the following steps:

[0081] Step 1: The device holds a post-quantum KEM key pair (public key pk, private key sk) in advance, which can be generated internally by the device or imported externally.

[0082] Step 2: The device constructs an unsigned PKCS#10 certificate request R (following the standard format but omitting the signature algorithm identifier and signature value fields) and sends R to the CA.

[0083] Step 3: The CA performs data structure and content checks on R (such as format validity and identity information compliance), but does not verify the signature (because the KEM key pair cannot be used for signing); if the check fails, the process terminates. If the check passes, the CA generates a random value K (as the key for subsequent message authentication codes).

[0084] Step 4: The CA uses the KEM public key pk in R to perform a key encapsulation operation on K (such as the encapsulation logic of the Kyber algorithm), generating ciphertext C, and sends C back to the device. Simultaneously, the CA uses K to calculate the message authentication code H (using algorithms such as HMAC or CMAC) on the certificate request R for subsequent integrity verification.

[0085] Step 5: After receiving the ciphertext C, the device uses its own KEM private key sk to perform a key decapsulation operation on C to obtain K'.

[0086] Step 6: The device uses K' to calculate the message authentication code H' (which is consistent with the algorithm used by the CA) for the certificate request R, and sends H' to the CA.

[0087] Step 7: CA compares H and H': If they do not match, it means that the device does not hold the corresponding private key or the request has been tampered with, and the process terminates; if they match, it proves that the device does hold sk and R has not been tampered with.

[0088] Step 8: The CA uses its own private key (either a classical public key algorithm or a post-quantum signature algorithm) to issue a standard X.509 format KEM certificate for the device based on the information in R, and sends the certificate to the device.

[0089] Step 9: The device receives and stores the certificate, completing the certificate request process.

[0090] To adapt to the unsigned KEM certificate request process, this application embodiment has made targeted modifications to the PKCS#10 certificate request structure to ensure that its syntax is valid and meets the requirements of the unsigned scenario:

[0091] 1. The structure follows a standard framework.

[0092] The structure of the certificate request R still conforms to the SEQUENCE definition of CertificationRequest, containing three core fields:

[0093] CertificationRequest::=SEQUENCE{

[0094] The `certificationRequestInfo` is a core information file containing the subject, public key, etc.

[0095] signatureAlgorithmAlgorithmIdentifier, -- Signature algorithm identifier

[0096] signatureBITSTRING -- Signature value (signature of certificationRequestInfo)

[0097] }

[0098] Specifically: certificationRequestInfo is fully consistent with the standard PKCS#10 and contains all necessary information; signatureAlgorithm uses a private algorithm identifier (OID) that explicitly identifies "unsigned" rather than the actual signing algorithm; signature is set to an empty BITSTRING (length 0), indicating "no signature value".

[0099] The above method can implement a syntactically valid, parsable PKCS#10 certificate request structure that does not contain an actual signature. Through this construction, R becomes a syntactically valid, parsable PKCS#10 request that does not contain a digital signature, thus being compatible with existing PKI parsing processes and adapting to the unsigned nature of KEM key pairs.

[0100] Once the certificate request process is complete, the CA can trust the legitimacy of the device and the request based on the following two points:

[0101] 1. The device holds a KEM private key that matches the KEM public key in the certificate request R; otherwise, the device cannot decrypt the correct K' (K'==K), and therefore cannot calculate the correct H' (H'==H); The device holds the corresponding KEM private key: if the device does not hold the private key, it cannot decrypt the correct K' from the ciphertext C, and therefore cannot calculate H' that matches H.

[0102] 2. The certificate request R has not been tampered with during transmission; otherwise, the client's calculation of H' based on R and the CA's calculation of H based on the tampered R will be different. The request data has not been tampered with: If R is tampered with during transmission, the device's calculation of H' based on the original R and the CA's calculation of H based on the tampered R will inevitably be inconsistent.

[0103] Meanwhile, the KEM certificate issued by the CA is in the standard X.509 format and can be directly integrated into the existing PKI system.

[0104] Figure 3 This paper illustrates the certificate authentication process provided in an embodiment of this application, demonstrating the complete interaction process between the verifier and the device to complete identity authentication based on a KEM single certificate. Through a mechanism of "key encapsulation + message authentication code," it proves that the device holds the KEM private key without the involvement of a digital signature. Specifically, it includes the following steps:

[0105] Step 1: The verifier checks the validity of the KEM certificate. The verifier receives the KEM certificate from the device and performs a validity check, including but not limited to: certificate revocation status (such as CRL and OCSP queries); certificate validity period (whether it is within the effective period); certificate signature (validity verification of the CA signature); and certificate chain integrity (verification of the trust chain from the device certificate to the root CA). If the check fails, authentication fails directly; if the check passes, the process continues.

[0106] Step 2: The verifier generates a random challenge value K (an independent random value is used for each authentication to prevent replay attacks).

[0107] Step 3: The verifier uses K to calculate the message authentication code H (the algorithm can be HMAC, CMAC, etc.) using the public key pk in the device's KEM certificate (or other information known to both parties, such as the device ID, the verifier's certificate, etc.).

[0108] Step 4: The verifier uses pk to perform a key encapsulation operation on K (such as the encapsulation logic of the Kyber algorithm), generates ciphertext C, and sends C to the device.

[0109] Step 5: After receiving the ciphertext C, the device uses its own KEM private key sk to perform a key decapsulation operation on C to obtain K'.

[0110] Step 6: The device uses K' to calculate the message authentication code H' (consistent with the algorithm used by the verifier) ​​on pk (or agreed common information), and sends H' to the verifier.

[0111] Step 7: The verifier verifies and outputs the authentication result. The verifier compares H and H': if they do not match, it means the device does not hold the corresponding private key, and authentication fails; if they match, it proves that the device does hold sk, and authentication passes.

[0112] If the device does not possess sk, it cannot decapsulate the correct K' (K' == K) from C, and therefore cannot calculate H' that matches H, thus failing to prove the device's control over the private key. Requiring the device to return H' instead of directly returning K' prevents attackers from collecting a large number of plaintext-ciphertext pairs to analyze the KEM key pair, improving its resistance to attacks.

[0113] In one possible implementation, when calculating the message authentication code, the pk can be replaced with other information mutually known to both parties (such as device ID, verifier certificate, etc.) to adapt to the authentication requirements of different scenarios. The core value of this process is that identity authentication is achieved using only a single KEM certificate, without relying on digital signatures, which reduces device resource overhead and ensures the reliability of identity authentication in the era of quantum security.

[0114] In summary, this application provides a certificate issuance method. A server receives a certificate request from a device to be issued, the certificate request carrying the public key from the key pair of the key encapsulation mechanism of the device to be issued; a first random value is generated, and the first random value is encapsulated using the public key to obtain first ciphertext, which is then sent to the device to be issued; first verification information is generated based on the first random value; second verification information is received from the device to be issued, the second verification information being generated by the device to be issued after decapsulating the first ciphertext using the private key from the key encapsulation mechanism key pair to obtain the first random value; the first verification information and the second verification information are verified to see if they match; if they match, a certificate is issued for the public key of the device to be issued. This is an effective mechanism that can securely issue certificates for KEM public keys without relying on digital signature functionality and without introducing additional signature key pairs, thus replacing traditional digital signature mechanisms. This application ensures that only the device that truly holds the corresponding private key can successfully decapsulate the random value and generate matching verification information, thereby completing the authentication of its private key ownership. Simultaneously, the verification information is strongly bound to the random value and certificate request. Any tampering with the request will result in verification failure, thus ensuring the integrity and authenticity of the requested data. Based on this verification result, a legitimate certificate is issued for the device's public key, laying the foundation for subsequent secure key exchange and reliable identity authentication.

[0115] Based on the same technical concept, embodiments of this application also provide a certificate issuance system, such as... Figure 4 As shown, the system includes:

[0116] Message receiving module 401 is used to receive a certificate request from a device to be signed, the certificate request carrying the public key in the key pair of the key encapsulation mechanism of the device to be signed;

[0117] Processing module 402 is used to generate a first random value, encapsulate the first random value using the public key to obtain a first ciphertext, send the first ciphertext to the device to be signed, and generate first verification information based on the first random value.

[0118] The message receiving module 401 is further configured to receive second verification information from the device to be signed, wherein the second verification information is generated by the device to be signed after decapsulating the first ciphertext using the private key in the key pair of the key encapsulation mechanism to obtain the first random value;

[0119] The verification module 403 is used to verify whether the first verification information matches the second verification information; if they match, it is a public key signing certificate for the device to be signed.

[0120] This application also provides an electronic device corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 5 The diagram illustrates an electronic device provided by some embodiments of this application. The electronic device 20 may include: a processor 200, a memory 201, a bus 202, and a communication interface 203, wherein the processor 200, the communication interface 203, and the memory 201 are connected via the bus 202; the memory 201 stores a computer program that can run on the processor 200, and when the processor 200 runs the computer program, it executes the method provided by any of the foregoing embodiments of this application.

[0121] The memory 201 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one physical port (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0122] Bus 202 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 201 is used to store programs. After receiving an execution instruction, the processor 200 executes the program. The method disclosed in any of the foregoing embodiments of this application can be applied to the processor 200, or implemented by the processor 200.

[0123] The processor 200 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 200 or by instructions in software form. The processor 200 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 201. The processor 200 reads the information in memory 201 and, in conjunction with its hardware, completes the steps of the above method.

[0124] The electronic devices and methods provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods they employ, operate, or implement.

[0125] This application also provides a computer-readable storage medium corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 6 The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored, which, when run by a processor, executes the methods provided in any of the foregoing embodiments.

[0126] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0127] The computer-readable storage medium provided in the above embodiments of this application and the method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0128] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0129] The above description is merely a preferred embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0130] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. All equivalent structural transformations made under the concept of the present invention using the contents of the present invention specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A certificate issuing method characterized by, The method comprises: The server receives a certificate request from a device to be issued, the certificate request carrying a public key in a key encapsulation mechanism key pair of the device to be issued; A first random value is generated, and the first random value is key encapsulated using the public key to obtain first ciphertext, which is sent to the device to be issued; and first verification information is generated based on the first random value; Second verification information is received from the device to be issued, the second verification information being generated by the device to be issued after the first ciphertext is de-encapsulated using a private key in the key encapsulation mechanism key pair to obtain the first random value; It is verified whether the first verification information matches the second verification information; if yes, a certificate is issued for the public key of the device to be issued; the first verification information and the second verification information are message authentication codes; the first verification information is generated based on the first random value, comprising calculating a message authentication code based on the certificate request; the second verification information is a message authentication code calculated by the device based on the first random value obtained by de-encapsulation and based on the certificate request; The method further comprises: An authentication request is received from a device to be authenticated, the authentication request carrying a key encapsulation mechanism certificate held by the device to be authenticated; A second random value is generated, and the second random value is key encapsulated using a public key in the key encapsulation mechanism certificate to obtain second ciphertext, which is sent to the device to be authenticated; and third verification information is generated based on the second random value; Fourth verification information is received from the device to be authenticated; wherein the fourth verification information is generated by the device to be authenticated after the second ciphertext is de-encapsulated using a private key in the key encapsulation mechanism key pair to obtain the second random value; It is verified whether the third verification information matches the fourth verification information; if yes, it is confirmed that the device to be authenticated passes the authentication; the third verification information and the fourth verification information are message authentication codes; the third verification information is generated based on the second random value, comprising calculating a message authentication code based on preset consensus information; the fourth verification information is a message authentication code calculated by the device to be authenticated based on the second random value obtained by de-encapsulation and based on the preset consensus information.

2. The method of claim 1, wherein, A certificate is issued for the public key of the device to be issued, comprising: A key encapsulation mechanism certificate in a preset standard format is issued for the device to be issued based on information in the certificate request using a private key of the server itself; The key encapsulation mechanism certificate is sent to the device to be issued.

3. The method of claim 1, wherein, After the certificate request is received and before the first random value is generated, the method further comprises: The data structure and / or content legality of the certificate request is checked; If the check fails, the process is terminated; if the check passes, the step of generating the first random value is continued.

4. The method of claim 1, wherein, The preset consensus information is any one of the following information: a public key in the key encapsulation mechanism certificate, the key encapsulation mechanism certificate, and an identifier of the device to be authenticated.

5. The method of claim 1, wherein, Before generating the second random value, the method further comprises: validating the key encapsulation mechanism certificate, the validation comprising one or more of checking certificate revocation status, certificate validity period, certificate signature validity, and certificate chain integrity; if the validation fails, terminating the procedure; if the validation passes, continuing with the step of generating the second random value.

6. A certificate issuing system characterized by comprising: The system comprises: a message receiving module configured to receive a certificate request from a device to be issued, the certificate request carrying a public key of a key encapsulation mechanism key pair of the device to be issued; a processing module configured to generate a first random value, encapsulate the first random value using the public key to obtain a first ciphertext, send the first ciphertext to the device to be issued, and generate first verification information based on the first random value; the message receiving module is further configured to receive second verification information from the device to be issued, the second verification information being generated by the device to be issued after the device to be issued decapsulates the first ciphertext using a private key of the key encapsulation mechanism key pair to obtain the first random value; a verification module configured to verify whether the first verification information matches the second verification information; if the first verification information matches the second verification information, issuing a certificate for the public key of the device to be issued; the first verification information and the second verification information are message authentication codes; the generation of the first verification information based on the first random value comprises calculating a message authentication code based on the certificate request and the first random value; the second verification information is a message authentication code calculated by the device based on the first random value obtained after decapsulation and the certificate request; the message receiving module is further configured to receive an authentication request from a device to be authenticated, the authentication request carrying a key encapsulation mechanism certificate held by the device to be authenticated; the processing module is configured to generate a second random value, encapsulate the second random value using a public key in the key encapsulation mechanism certificate to obtain a second ciphertext, send the second ciphertext to the device to be authenticated, and generate third verification information based on the second random value; the message receiving module is further configured to receive fourth verification information from the device to be authenticated; wherein the fourth verification information is generated by the device to be authenticated after the device to be authenticated decapsulates the second ciphertext using a private key of the key encapsulation mechanism key pair to obtain the second random value; the verification module is further configured to verify whether the third verification information matches the fourth verification information; if the third verification information matches the fourth verification information, confirming that the device to be authenticated passes the authentication; the third verification information and the fourth verification information are message authentication codes; the generation of the third verification information based on the second random value comprises calculating a message authentication code based on preset consensus information and the second random value; the fourth verification information is a message authentication code calculated by the device to be authenticated based on the second random value obtained after decapsulation and the preset consensus information.

7. An electronic device comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that the processor, when executing the computer program, performs to implement the method of any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, A computer program product having stored thereon computer readable instructions executable by a processor to implement the method of any one of claims 1-5.

Images