Certificate processing method, electronic device, and computer-readable storage medium

Abstract

The embodiment of the present application provides a certificate processing method, electronic device, and computer-readable storage medium. Relating to the field of information security, the method includes: obtaining a certificate file issued by a certificate authority; based on the certificate file, generating and sending a certificate upload application to a security authentication device; the security authentication device is used to generate a first device identity credential for the certificate upload application; the certificate upload application and the first device identity credential are sent to a cloud server; the cloud server is used to store the certificate file included in the certificate upload application; when the received upload result is a successful upload, the certificate identifier is stored in the security authentication device, and the certificate file is stored in the local cache of the middleware. The present application solves the technical problem in the related art that the storage resources of the security authentication device are limited and it is difficult to adapt to the growing demand for anti-quantum cryptography storage.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a certificate processing method, an electronic device, and a computer-readable storage medium. Background Art

[0002] Traditional cryptography relies on difficult mathematical problems like factoring large numbers or solving discrete logarithms. Quantum computers can crack these problems in polynomial time, threatening the security of existing encryption. Quantum-resistant cryptography is based on alternative mathematical structures that remain secure even when cracked by quantum computers.

[0003] For resource-constrained security authentication devices, migrating to quantum-resistant cryptography results in orders of magnitude increases in the length of public keys and signatures, and a significant increase in the size of keys and certificates, due to the inherent characteristics of the algorithm's mathematical construction. However, the secure storage space of security authentication devices is limited (typically only tens of KB), making certificate storage a technical bottleneck. The solutions provided in related technologies require modifications to upstream and downstream systems, extensive functional adjustments to existing verification logic, and the addition of additional authentication processes to accommodate the quantum-resistant cryptography requirements of resource-constrained security authentication devices. This makes direct compatibility with existing cryptographic authentication processes difficult, resulting in significant application limitations. Summary of the Invention

[0004] The embodiments of the present application provide a certificate processing method, an electronic device, and a computer-readable storage medium to alleviate or resolve the technical problem in related technologies that the storage resources of security authentication devices are limited and difficult to adapt to the growing demand for quantum-resistant cryptographic storage.

[0005] In a first aspect, an embodiment of the present application provides a certificate processing method, which is applied to middleware, including:

[0006] Obtain the certificate file issued by the certificate authority;

[0007] Based on the certificate file, generate and send a certificate upload application to the security authentication device; the security authentication device is used to generate a first device identity credential for the certificate upload application and send the first device identity credential to the middleware;

[0008] The certificate upload application and the first device identity credential are sent to the cloud server; the cloud server is used to store the certificate file included in the certificate upload application when the certificate upload application and the first device identity credential are verified, and send the upload result including the certificate identifier to the middleware, where the certificate identifier is extracted by the cloud server based on the certificate file;

[0009] When the received upload result indicates that the upload is successful, the certificate identifier is stored in the security authentication device, and the certificate file is stored in the local cache of the middleware.

[0010] In a second aspect, an embodiment of the present application provides a certificate processing method, which is applied to a security authentication device, including:

[0011] Upon receiving a certificate upload application, a first device identity credential is generated for the certificate upload application, and the first device identity credential is sent to the middleware; the certificate upload application is generated by the middleware based on the certificate file issued by the certificate authority, and the middleware is used to send the certificate upload application and the first device identity credential to the cloud server, and the cloud server is used to store the certificate file included in the certificate upload application when the certificate upload application and the first device identity credential are verified, and send an upload result including a certificate identifier to the middleware, the certificate identifier being extracted by the cloud server based on the certificate file, and the middleware is used to send the certificate identifier to the security authentication device when the upload result is successful, and store the certificate file in the local cache of the middleware;

[0012] Receive and store the certificate identification.

[0013] In a third aspect, an embodiment of the present application provides a certificate processing method, which is applied to a cloud service end, including:

[0014] Accept the certificate upload application and the first device identity credential sent by the middleware; the certificate upload application is generated by the middleware based on the certificate file issued by the certificate authority and sent to the security authentication device, and the first device identity credential is generated by the security authentication device for the certificate upload application and sent to the middleware;

[0015] If the certificate upload application and the first device identity credential are verified to be successful, extract the certificate identifier based on the certificate file included in the certificate upload application and store the certificate file;

[0016] The upload result including the certificate identifier is sent to the middleware; when the upload result is received and the upload is successful, the middleware is used to store the certificate identifier in the security authentication device and store the certificate file in the local cache of the middleware.

[0017] In a fourth aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor implements any method of the embodiments of the present application when executing the computer program.

[0018] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the method of any one of the embodiments of the present application is implemented.

[0019] Based on the certificate processing methods of the first, second, and third aspects above, this application has at least the following beneficial effects or advantages:

[0020] Security authentication devices no longer need to store certificate files, but instead manage the certificate identifiers that reflect the binding relationship. Cloud servers are used to distribute and transfer certificates with the device, alleviating the storage resource constraints faced by resource-constrained devices during quantum-resistant cryptography migration. This improvement allows for seamless upgrades for existing frameworks, such as applications and certificate authorities, while remaining transparent to upper-layer applications. Applications do not need to adjust their functional logic or add additional authentication processes.

[0021] The above description is only an overview of the technical solution of this application. In order to more clearly understand the technical means of this application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of this application more obvious and easy to understand, the specific implementation methods of this application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the multiple drawings represent the same or similar components or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments according to the present application and should not be regarded as limiting the scope of the present application.

[0023] Figure 1 A first flow chart of the certificate processing method according to an embodiment of the present application is shown;

[0024] Figure 2 A first schematic block diagram in the related art is shown;

[0025] Figure 3 A second schematic block diagram of the certificate processing method according to an embodiment of the present application is shown;

[0026] Figure 4 A second flow chart of the certificate processing method according to an embodiment of the present application is shown;

[0027] Figure 5 A third flow chart of the certificate processing method according to an embodiment of the present application is shown;

[0028] Figure 6 A first timing diagram of the certificate processing method according to an embodiment of the present application is shown;

[0029] Figure 7 A second timing diagram of the certificate processing method according to an embodiment of the present application is shown;

[0030] Figure 8 A third timing diagram of the certificate processing method according to an embodiment of the present application is shown;

[0031] Figure 9 A first schematic diagram of a certificate processing device according to an embodiment of the present application is shown;

[0032] Figure 10 A second schematic diagram of the certificate processing device according to an embodiment of the present application is shown;

[0033] Figure 11 A third schematic diagram of the certificate processing apparatus according to an embodiment of the present application is shown;

[0034] Figure 12 A block diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0035] Hereinafter, only certain exemplary embodiments are briefly described. As will be appreciated by those skilled in the art, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and description are to be regarded as illustrative in nature and not restrictive.

[0036] To facilitate understanding of the technical solutions of the embodiments of the present application, the following describes the related technologies of the embodiments of the present application. The following related technologies can be combined with the technical solutions of the embodiments of the present application as optional solutions, and all of them fall within the scope of protection of the embodiments of the present application.

[0037] The following terms will be used in the following text:

[0038] Post-quantum cryptography (PQC) refers to encryption algorithms that are resistant to attacks by quantum computers. Traditional cryptography relies on difficult mathematical problems such as factoring large numbers or solving discrete logarithms. Quantum computers can crack these problems in polynomial time, threatening the security of existing encryption. Quantum-resistant cryptography, however, relies on alternative mathematical structures that can maintain their security even after quantum computers mature.

[0039] X.509 is a widely used digital certificate standard used to verify identity, encrypt communications, and ensure data integrity on the Internet and in various security systems. It is a core component of the Public Key Infrastructure (PKI).

[0040] SN (Serial Number) is a unique identifier that is embedded in the security chip by the manufacturer during production.

[0041] Public and private keys are a pair of keys in an asymmetric encryption system. The public key can be used to encrypt data and verify digital signatures. Only the user with the corresponding private key can decrypt the data. The private key is used to decrypt data encrypted by the corresponding public key and to generate digital signatures.

[0042] A Certificate Authority (CA) is a trusted third-party organization responsible for issuing, managing, and revoking digital certificates.

[0043] Resource-constrained security authentication devices, such as USBKey (also known as smart cryptographic keys), face a technical challenge in quantum-resistant cryptographic migration: the difficulty of storing quantum-resistant cryptographic algorithm certificates due to limited secure storage resources. USBKey is a widely used security authentication device in finance, government affairs, the Internet of Things, and other fields, and its security capabilities rely on the physical security characteristics of the security chip.

[0044] On the one hand, compared to general-purpose storage devices, security chips typically have a unit storage cost over 25 times higher due to factors such as physical attack resistance and process technology. Due to cost constraints, the security chips used in USB keys typically have relatively small internal storage space, with a common specification of 320KB. Taking into account the space reserved for firmware and algorithm libraries, the space left for storing keys, certificates, and user data is typically less than 90KB.

[0045] Certificates using quantum-resistant cryptographic algorithms require significantly more storage space than certificates using classical algorithms. This is because widely used certificate formats like X.509 and PGP require both a public key and a signature. However, the mathematical structure of quantum-resistant cryptographic algorithms increases the length of these public keys and signatures by orders of magnitude.

[0046] The classic RSA-2048 algorithm has a public key length of 256 bytes and a signature length of 256 bytes. The FIPS 204 ML-DSA Dilithium5 algorithm, based on lattice cryptography, has a public key length of 2.5KB and a signature length of 4.5KB. The corresponding X.509 certificate is nearly six times the size of the RSA-2048 algorithm. SM2 is an elliptic curve cryptography algorithm, and RSA-2048 is a public key cryptography algorithm based on the large integer factorization problem. SM2 and RSA-2048 are not quantum-resistant algorithms. Falcon-1024 is a lattice-based digital signature algorithm, Dilithium5 is a lattice-based digital signature algorithm, SPHINCS+-128 is a hash-based digital signature algorithm, and SPHINCS+-25 is a hash-based digital signature algorithm. These four algorithms are quantum-resistant.

[0047] Table 1 Comparison of parameters and certificate sizes of quantum-resistant signature algorithms

[0048]

[0049] This geometric growth of key parameters and verification data directly leads to a corresponding expansion in the size of digital certificates containing the above data. For example, an X.509 certificate embedded with a SPHINCS+-256 public key and signature can be up to 51KB in size; in comparison, a traditional ECC certificate is usually less than 1KB. Depending on the business scenario, USBKey usually needs to manage and store multiple key pairs and corresponding certificates, including: key pairs and certificates of different algorithms, such as RSA2048 certificates, SM2 certificates, and certificates of quantum-resistant cryptographic algorithms that are expected to be added; key pairs and certificates for different purposes, such as SSL login certificates, transaction certificates, batch signature certificates, etc. This feature of quantum-resistant cryptographic algorithms poses a severe challenge to USBKey products with limited storage resources. The existing storage space may not meet the number of certificates required by the application.

[0050] It should be noted that the above-mentioned application scenarios or application examples provided in the embodiments of this application are for ease of understanding, and the embodiments of this application do not specifically limit the application of the technical solution. In addition, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation portals for users to choose to authorize or refuse.

[0051] The following describes in detail the technical solution of this application and how it solves the aforementioned technical problems using specific embodiments. The several specific embodiments listed can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. The following describes the embodiments of this application in detail with reference to the accompanying drawings.

[0052] Figure 1 The first flow chart of the certificate processing method of the embodiment of the present application is shown, which is applied to middleware, such as Figure 1 As shown, the method may include steps S101 to S104.

[0053] Step S101: Obtain a certificate file issued by a certificate authority;

[0054] Step S102: Based on the certificate file, generate and send a certificate upload application to the security authentication device; the security authentication device is used to generate a first device identity credential for the certificate upload application and send the first device identity credential to the middleware;

[0055] Step S103: Sending the certificate upload application and the first device identity credential to the cloud server; the cloud server is configured to, upon verification of the certificate upload application and the first device identity credential, store the certificate file included in the certificate upload application and send an upload result including a certificate identifier to the middleware, where the certificate identifier is extracted by the cloud server based on the certificate file;

[0056] Step S104: When the received upload result indicates that the upload is successful, the certificate identifier is stored in the security authentication device, and the certificate file is stored in the local cache of the middleware.

[0057] Exemplarily, the cloud service end may be of various types, for example, it may be a public cloud service deployed on the Internet, or it may be a private cloud service deployed within an enterprise or organization.

[0058] This embodiment of the present application demonstrates the certificate upload process. The middleware obtains a signed certificate file from a certificate authority (CA). The certificate file is a crucial credential for identity authentication and encrypted communication. Based on the obtained certificate file, the middleware generates a certificate upload request and sends it to a secure authentication device (e.g., a USB key). The certificate upload request contains relevant information about the certificate file and is used to request permission to upload the certificate from the secure authentication device. Upon receiving the certificate upload request, the secure authentication device generates a first device identity credential for the request. This credential is used to verify the device's identity, ensuring that only authorized devices can upload certificates and preventing unauthorized certificate uploads, thereby enhancing system security. The secure authentication device then sends the first device identity credential to the middleware. The middleware then sends the certificate upload request and the first device identity credential together to the cloud server. Upon receiving this information, the cloud server verifies the validity of the certificate upload request and the device identity credential. If verification is successful, the cloud server stores the certificate file included in the certificate upload request and extracts the certificate identifier from it. The certificate identifier is a unique identifier generated by the cloud server based on the certificate file and is used for subsequent certificate management and verification. The cloud server then sends the upload result, including the certificate identifier, to the middleware. Upon receiving the upload result, if the result indicates a successful upload, the middleware stores the certificate identifier on the security authentication device and stores the certificate file in a local cache for quick access. This reduces reliance on the cloud server and improves system responsiveness and user experience. The certificate file is stored on the cloud server, while the certificate identifier is stored on the security authentication device. This distributed storage approach decouples the storage requirements of the security authentication device from those of the certificate file itself, ensuring data security while increasing storage flexibility.

[0059] Through the above processing, under the premise of ensuring the correct association between the certificate and key pair, the certificate file is not stored in the device, and the certificate file is distributed online through the cloud server. This can overcome the challenges brought by device storage limitations during the quantum cryptography migration process. Only users with legitimate USB keys holding the certificate private key are allowed to upload the certificate to the certificate distribution cloud service, and only users holding the corresponding USB keys are allowed to distribute the certificate to the local device, avoiding potential security attacks and privacy leakage risks.

[0060] There can be many types of security authentication products, such as USBKey, U-Shield, smart card, hardware token, etc. For the convenience of description below, in the case where the security authentication device is USBKey, the above-mentioned execution subject is the middleware, namely USBKey middleware. USBKey is a hardware device with a USB interface, a built-in single-chip microcomputer or smart card chip, and a certain amount of storage space. It can store the user's private key and digital certificate, and use the built-in public key algorithm to realize the authentication of the user's identity. The above-mentioned USBKey and USBKey middleware are existing parts of the existing authentication process. The embodiment of the present application improves the interaction between USBKey middleware, USBKey, and cloud service end, and there is no need to modify the interaction logic between the application side and USBKey. The key pair and certificate file are both stored inside the USBKey. USBKey is the carrier of the certificate file, and the certificate file is distributed and migrated with the USBKey.

[0061] According to an optional embodiment provided by the present application, in step S102, the certificate upload application generated by the middleware includes: the first data generation time of the certificate upload application generated by the middleware, the serial number of the security authentication device, and the certificate file.

[0062] In the embodiment provided in this application, the certificate upload application is also accompanied by the first device identity credential generated by the security authentication device. The certificate upload application provided by the middleware can select a specific encoding format according to the specific application scenario and is not specifically limited.

[0063] In an optional embodiment provided in the present application, the method further includes: determining the above-mentioned certificate identifier from the following multiple candidate identifiers based on the certificate standard type and the application system's requirement information: certificate serial number, subject name, certificate fingerprint, and public key hash.

[0064] The certificate identifier mentioned above refers to the unique identification data of a certificate. Different identifiers can be selected according to different certificate standards. Taking X.509 certificates as an example, in actual applications, the data selected as the certificate identifier can be determined based on the business needs of the application system. Optional certificate identifiers include: Certificate Serial Number (Certificate Serial Number), a unique integer assigned by the Certificate Authority (CA) and unique within the same CA; Subject Name (Subject Name), the identification information of the certificate holder, also known as the "Certificate DN"; Certificate Fingerprint (Certificate Fingerprint), a unique value obtained by hashing the certificate content (usually DER encoded); and Public Key Hash (Public Key Hash), a value obtained by hashing the public key data in the certificate. For example, a business system uses the Certificate DN to distinguish certificates. When calling the cryptographic application interface to request a USBKey signature, if the parameter passed in for selecting the certificate is the Certificate DN, the Certificate DN should be selected as the certificate identifier.

[0065] According to the embodiment provided by the present application, the security authentication device further stores a key pair of a public key and a private key. Before executing step S101, the method further includes:

[0066] Assemble the certificate request to be signed based on the public key;

[0067] Send the certificate request to the security authentication device; the security authentication device is used to sign the certificate request using the private key;

[0068] Send the signed certificate request to the certificate authority for verification; if the certificate request is verified, the certificate authority will issue the certificate file.

[0069] The embodiments provided herein are improvements based on the existing process framework requiring certificate authentication. A secure authentication device (such as a USB key) internally generates a pair of asymmetric keys: the public key is used to construct the certificate request, while the private key is securely stored within the USB key. In accordance with information security standards, the private key is not transmitted externally. The middleware uses this public key and other necessary identity information to assemble a signed certificate request (CSR) for requesting a certificate from a certificate authority (CA). The certificate request is sent to the secure authentication device, which digitally signs it using its internally stored private key to generate a signed certificate request, confirming that the request originated from a legitimate USB key. After signing, the signed certificate request is sent to the certificate authority for verification. Upon receiving the request, the certificate authority can perform a series of verification operations, including verifying the validity of the signature, confirming the legitimacy of the applicant's identity, and checking the validity of the public key. Only when all verifications pass will the certificate authority issue a digital certificate file and return it to the middleware.

[0070] According to the embodiment provided by this application, in step S104: storing the certificate file in the local cache of the middleware may include any of the following methods:

[0071] Store the certificate file in the local disk in the form of a file;

[0072] Store certificate files in the local database;

[0073] Store the certificate file in the Windows system registry;

[0074] Use the certificate management mechanism or certificate library provided by the operating system to store certificate files;

[0075] Use sandbox technology to store certificate files;

[0076] Develop secure storage software to protect certificate files.

[0077] In the embodiments of the present application, the middleware protects the locally cached certificate files from tampering, accidental or malicious deletion, by leveraging file permission protection, account access control, or third-party technology implemented by the operating system, thereby reducing the number of interactions between the user end and the cloud server and alleviating the request pressure on the cloud server. The storage method can adopt one or a combination of the above methods.

[0078] Figure 2 Shows the first schematic block diagram of the related art, based on the application system architecture of USBKey Figure 2As shown, the system primarily consists of a host computer (i.e., the user interface) and a USBKey (a secure authentication device). Applications or browsers (i.e., the user end) implement key management, certificate management, cryptographic operations, and other functions by calling the "Cryptographic Application Programming Interface" (API) provided by the USBKey middleware. The USBKey middleware is responsible for handling command communication and interaction logic with the USBKey (i.e., the aforementioned secure authentication device). It should be noted that the USBKey product provided to manufacturers includes both the USBKey middleware and the USBKey. For ease of understanding, the secure authentication device will be referred to as the USBKey, the middleware as the USBKey middleware, the certificate authority as the CA service, the application end as the application, and the cloud service end as the certificate distribution cloud service.

[0079] In the existing process, the process of downloading the signature certificate to USBKey can be expressed as follows:

[0080] a) [USBKey] Verify user permissions;

[0081] b)[USBKey] Create a key container;

[0082] c) [USBKey] Generate a key pair in the key container;

[0083] d) [USBKey middleware] is used to assemble the certificate request to be signed using the generated public key;

[0084] e) [USBKey] Sign the certificate request with the generated private key;

[0085] f) [CA service] (i.e., certificate authority) verifies the signed certificate request and issues the certificate file after verification;

[0086] g) [Application] (i.e. application side) calls the import certificate interface of [USBKey middleware];

[0087] h)[USBKey] Store certificate files in a key container.

[0088] In order to show that the embodiments provided by this application do not require changes to the original authentication framework, Figure 3 A second schematic block diagram of the certificate processing method according to an embodiment of the present application is shown. Figure 3As shown, the "Cryptographic Application Interface" API remains unchanged. The USBKey device no longer stores certificate files internally. Instead, the "certificate identifier" is stored in association with the key container and key file corresponding to the certificate. A key file is a file that stores key data and is used for security operations such as encryption, decryption, and signature verification. Key files can contain information such as symmetric keys and asymmetric key pairs (public and private keys). They are stored in the security authentication device to prevent unauthorized access and tampering. The "Certificate Distribution Cloud Service" is responsible for storing and distributing certificate files. In the embodiments provided in this application, the USBKey product provided by the USBKey manufacturer includes three components: the USBKey middleware, the USBKey device, and the certificate distribution cloud service (i.e., the cloud server). It should be noted that while the cloud server has been added as an interactive entity, the interaction between the application and the certificate authority in the existing process and the USBKey product remains unchanged. What has changed is the internal interaction method within the USBKey, enabling a seamless improvement to the existing process. In other words, while the internal architecture has been adjusted, the client-side application or browser still interacts with the USBKey middleware through the same Cryptographic Application Interface API. This means that the application side can seamlessly integrate with the new certificate processing method without any modifications, achieving a seamless improvement to the original process.

[0089] For example, communication between the USBKey middleware and the certificate cloud distribution service (i.e., the cloud server) can utilize various secure communication methods, such as TLS (Transport Layer Security), HTTPS (Hypertext Transfer Protocol Secure), VPN (Virtual Private Network), IPsec (Internet Protocol Security), and SSH (Secure Shell) tunnels. TLS is a cryptographic protocol used to provide secure communication over the internet. By encrypting data packets, it prevents data from being eavesdropped or tampered with during transmission. HTTPS, a secure version of HTTP, encrypts data using the TLS protocol. This not only encrypts data but also verifies the identities of both communicating parties through digital certificates, preventing man-in-the-middle attacks. VPNs create an encrypted virtual tunnel to securely transmit data to the target server, establishing a secure communication channel over public networks (such as the internet) and ensuring the confidentiality and integrity of data during transmission. IPsec is a network-layer security protocol that encrypts and authenticates IP packets to ensure the security and integrity of data during transmission, providing end-to-end security protection at the IP layer. SSH is a protocol used for secure remote login and server management. Through SSH tunneling, data from other protocols (such as HTTP and FTP) can be encapsulated within an SSH connection, enabling encrypted data transmission. The above communication methods are only examples of secure communication methods and are not intended to be limiting.

[0090] The above embodiment implements the initial distribution and download of the certificate. In the subsequent interaction with the application end, the certificate needs to be read for security authentication. The following describes the certificate reading process. After step S104, the method further includes the following specific steps:

[0091] In response to receiving a read instruction for reading a certificate file, obtaining key container information of a security authentication device;

[0092] According to the read instruction, the certificate identifier is retrieved from the key container information;

[0093] Search the local cache for the certificate file whose index is the certificate identifier;

[0094] If the certificate file passes the integrity verification, the certificate file is sent to the application side, which is used to call the middleware for human-computer interaction.

[0095] In the embodiment provided by the present application, when the application side needs to perform security authentication, an instruction to read the certificate file will be sent to the middleware. After receiving the read instruction, the middleware triggers the certificate reading process. The key container information is obtained from the security authentication device (such as a USBKey device). The key container information contains relevant information such as the certificate identifier stored in the security authentication device, and the certificate identifier corresponding to the instruction is retrieved in the key container information. The middleware searches the local cache for a certificate file with an index of the retrieved certificate identifier, indicating that the local cache stores the certificate file that was previously downloaded and successfully stored from the cloud server. After finding the certificate file, the middleware verifies the integrity of the certificate file. If the certificate file passes the integrity verification, the middleware sends the certificate file to the application side. The application side then calls the middleware for human-computer interaction to complete the subsequent security authentication process.

[0096] Exemplarily, the read instruction is sent when the application calls the middleware to read the certificate from the security authentication device. The above read instruction can indicate a variety of contents, such as using enumeration to indicate the return of all stored certificate identifiers; specifying the certificate type in the predetermined key container in the security authentication device to return the certificate identifier of the corresponding certificate type; specifying the subject name DN to retrieve the certificate identifier in the key information container.

[0097] In the embodiment provided in this application, the method further includes the following steps:

[0098] If the certificate file fails the integrity verification, the certificate file is deleted from the local cache;

[0099] Based on the certificate identification, a certificate distribution application is generated and sent to the security authentication device; the security authentication device is used to generate and send the second device identity credentials for the certificate distribution application to the middleware;

[0100] Send the certificate distribution application and the second device identity credential to the cloud server; the cloud server is used to return the certificate file to the middleware if the certificate distribution application and the second device identity credential are verified;

[0101] Store the certificate file in the local cache and send the certificate file to the application.

[0102] In the embodiment provided in the present application, if the certificate file fails the integrity verification, it indicates that the certificate file may have been tampered with or damaged during storage or transmission. If the certificate file fails the integrity verification, the middleware will delete the certificate file in the local cache to prevent the use of damaged or insecure certificates for subsequent operations. Based on the certificate identifier, the middleware generates a certificate distribution application, which includes the certificate identifier and is used to request the cloud server to re-obtain the certificate file. Before sending it to the cloud server, the middleware sends the certificate distribution application to the security authentication device. After receiving the application, the security authentication device uses its internal device identity key to sign the certificate distribution application, generates and sends the second device identity credential to the middleware. The middleware sends the certificate distribution application and the second device identity credential together to the cloud server, and the cloud server verifies the received application and credentials. If the verification passes, the cloud server returns the certificate file to the middleware, the middleware stores the certificate file re-obtained from the cloud server in the local cache, and sends the certificate file to the application, which then uses the certificate file for security authentication.

[0103] Through the above steps, when the integrity verification of the certificate file fails, a mechanism is provided to re-acquire and verify the certificate file, ensuring that the application end can use a valid certificate for security authentication. This not only guarantees the authenticity and integrity of the certificate file, but also improves the security and reliability of the entire system.

[0104] According to the embodiment provided by the present application, the certificate distribution application generated by the middleware includes: the second data generation time when the middleware generates the certificate distribution application, the serial number of the security authentication device, and the certificate identifier.

[0105] In the embodiment provided in this application, the certificate distribution application is also accompanied by a second device identity credential generated by the security authentication device. The certificate distribution application provided by the middleware can select a specific encoding format according to the specific application scenario and is not specifically limited.

[0106] According to the embodiments provided in this application, Figure 5 A third flow chart of the certificate processing method according to an embodiment of the present application is shown. Figure 5As shown, in addition to the initial distribution, downloading, reading and re-acquisition mechanism of the certificate, a certificate deletion mechanism is also provided, so that the certificate file can be safely deleted from the local cache and the cloud server when it is no longer needed. After step S104, the method further includes:

[0107] In response to receiving a deletion instruction to delete the certificate file, obtaining key container information of the security authentication device;

[0108] According to the deletion instruction, the certificate identifier is retrieved from the key container information;

[0109] Delete the certificate file with the index of certificate identifier from the local cache;

[0110] Based on the certificate identification, a certificate deletion application is generated and sent to the security authentication device; the security authentication device is used to generate and send the third device identity credentials for the certificate deletion application to the middleware;

[0111] Send the certificate deletion request and the third device identity credentials to the cloud server; the cloud server is used to delete the certificate file on the cloud server if the certificate deletion request and the third device identity credentials are verified, and send the deletion result to the middleware;

[0112] When the received deletion result indicates that the deletion is complete, the certificate identifier is deleted in the security authentication device.

[0113] In an embodiment of the present application, when the application needs to delete a certificate file, it sends a deletion instruction to the middleware. After receiving the deletion instruction, the middleware triggers the certificate deletion process. Based on the deletion instruction, the middleware retrieves the certificate identifier corresponding to the instruction from the key container information. The middleware searches the local cache for the certificate file whose index is the retrieved certificate identifier and deletes it. Based on the certificate identifier, the middleware generates a certificate deletion request. The certificate deletion request includes the certificate identifier and is used to request the cloud server to delete the certificate file. Before sending it to the cloud server, the middleware sends the certificate deletion request to the security authentication device. The security authentication device uses its internal device identity key to sign the certificate deletion request, generate a third device identity credential, and send it to the middleware. The middleware sends the certificate deletion request and the third device identity credential together to the cloud server. The cloud server verifies the received certificate deletion request and the third device identity credential. The cloud server verifies the certificate deletion request and the third device identity credential. If the verification is successful, the cloud server deletes the certificate file on the cloud server and sends the deletion result to the middleware. If the result shows that the deletion is complete, the middleware sends the certificate identifier to the security authentication device for deleting the certificate identifier in the key container, completing the entire deletion process.

[0114] According to the embodiment provided by the present application, the certificate deletion application generated by the middleware includes: the third data generation time when the middleware generates the certificate deletion application, the serial number of the security authentication device, and the certificate identifier.

[0115] In the embodiment provided in this application, the certificate deletion application is also accompanied by a third device identity credential generated by the security authentication device. The certificate deletion application provided by the middleware can select a specific encoding format according to the specific application scenario and is not specifically limited.

[0116] Figure 4 A second flow chart of the certificate processing method according to an embodiment of the present application is shown, which is applied to a security authentication device, such as Figure 4 As shown, the method may include steps S201 to S202.

[0117] Step S201: upon receiving a certificate upload application, generating a first device identity credential for the certificate upload application, and sending the first device identity credential to the middleware; the certificate upload application is generated by the middleware based on the certificate file issued by the certificate authority, and the middleware is used to send the certificate upload application and the first device identity credential to the cloud server, and the cloud server is used to store the certificate file included in the certificate upload application when the certificate upload application and the first device identity credential are verified, and send an upload result including a certificate identifier to the middleware, the certificate identifier being extracted by the cloud server based on the certificate file, and the middleware is used to send the certificate identifier to the security authentication device when the upload result is successful, and store the certificate file in the local cache of the middleware;

[0118] Step S202: Receive and store the certificate identification.

[0119] In the embodiment provided by the present application, the security authentication device uses its internally stored device identity key to sign the certificate upload application and generates a first device identity credential to prove that the application was initiated by a legitimate security authentication device. The security authentication device sends the generated first device identity credential back to the middleware, and the middleware then sends the certificate upload application and the first device identity credential together to the cloud server. After receiving the certificate upload application and the first device identity credential, the cloud server performs verification. After the verification is passed, the cloud server stores the certificate file, generates a certificate identifier, and sends the upload result containing the certificate identifier back to the middleware. After the middleware receives the upload result returned by the cloud server, if the result shows that the upload is successful, the middleware sends the certificate identifier to the security authentication device and stores the certificate file in the local cache. The security authentication device receives and stores the certificate identifier.

[0120] According to the embodiment provided by the present application, in step S201: when a certificate upload application is received, generating a first device identity credential for the certificate upload application includes:

[0121] Using the device identity key, a calculation is performed based on the certificate upload application to obtain the first device identity credential;

[0122] The device identity key is obtained in any of the following ways: generated by a key relationship system and stored inside the security authentication device; or obtained by dispersing a seed key and a serial number of the security authentication device.

[0123] In the embodiments provided herein, the security authentication device (USBKey device) uses the device identity key to calculate the certificate upload request and obtain the first device identity credential. During the USBKey product production process, the device identity key is generated by the KMS (Key Management System) and written to the device. Alternatively, the device identity key can be derived from a seed key and the USBKey's SN (unique serial number). The device identity key is preferably a symmetric key stored within the USBKey. However, given the storage capacity constraints of the USBKey and the security principle of quantum-resistant cryptographic migration, traditional public key cryptographic algorithms or certain quantum-resistant cryptographic algorithms are not suitable.

[0124] According to an optional embodiment provided by the present application, in step S202: receiving and storing the certificate identification includes: creating a certificate identification file for storing the certificate file in a key container; or,

[0125] In the attributes of the key container or the key container information, an attribute or field for storing the certificate identifier is added.

[0126] In the embodiments provided herein, a key container is a secure structure used to store and manage keys and related information. The key container stores certificate identification files, or key container attributes or fields, in a secure storage area of ​​a security authentication device to ensure security and confidentiality.

[0127] It should be noted that the binding relationship between the certificate file and the key file in the key container in the related technology, in the embodiment of the present application, the certificate file is no longer stored in the security authentication device, and the certificate identifier is used instead of the certificate file. The same association method can be used for processing, which is all within the scope of protection of this application.

[0128] The device identity credential can be a message authentication code (MAC) generated by the USBKey device using the device identity key on the input message (i.e., the certificate upload application mentioned above). The message authentication code is a form of the first device identity credential. The calculation of the message authentication code (MAC) is used to prove that the message is authorized by the legitimate USBKey device. There are many ways to do this, such as: encrypting the input message using a symmetric encryption algorithm (such as AES-CMAC) to generate a MAC. Using a hash function (such as HMAC-SHA256) combined with the device identity key to process the input message to generate a MAC.

[0129] For example, when the security authentication device (USBKey device) generates the first device identity credential for a certificate upload request, it needs to verify whether the serial number SN included in the certificate upload request matches the actual serial number of the security authentication device. It can also verify whether the public key included in the certificate file is consistent with the public key in the key file. It should be noted that the above public key verification method is not applicable to the following situations: using a cloud server to distribute root certificates, intermediate certificates, or certificates whose key pairs are not located in the security authentication device.

[0130] For the execution entity security authentication device, the following steps can be used for certificate distribution:

[0131] Receive the certificate distribution application sent by the middleware; the certificate distribution application is generated and sent by the middleware based on the certificate identifier when the certificate file fails the integrity verification;

[0132] In response to the certificate distribution application, a second device identity credential is generated and sent to the middleware; the certificate distribution application and the second device identity credential are sent by the middleware to the cloud server, and the cloud server is used to return the certificate file to the middleware when the certificate distribution application and the second device identity credential are verified; the middleware stores the certificate file in the local cache and sends the certificate file to the application end.

[0133] Specifically, there are various reasons why the certificate file might fail integrity verification, such as the entire certificate file not being cached, or cached data missing from the certificate file, resulting in the cached data failing integrity verification. Regardless of the reason, once the middleware detects an integrity issue with the certificate file, it will generate a certificate distribution request, triggering the subsequent certificate reissue process.

[0134] Exemplarily, when the security authentication device (USBKey device) generates a second device identity credential for a certificate distribution application, it is necessary to verify whether the serial code SN carried in the certificate upload application matches the actual serial code of the security authentication device, and it can also verify whether the certificate identifier is consistent with at least one certificate identifier in the key container in the security authentication device.

[0135] For a security authentication device, the following steps can be used to delete the certificate:

[0136] In response to the middleware receiving a deletion instruction to delete the certificate file, the middleware sends key container information to the middleware; the middleware is configured to retrieve the certificate identifier from the key container information according to the deletion instruction; and delete the certificate file indexed as the certificate identifier from the local cache;

[0137] Receive a certificate deletion request; the certificate deletion request is generated and sent by the middleware based on the certificate identifier;

[0138] In response to the certificate deletion request, generate and send the third device identity credentials to the middleware; the middleware is used to send the certificate deletion request and the third device identity credentials to the cloud server; the cloud server is used to delete the certificate file on the cloud server when the certificate deletion request and the third device identity credentials are verified, and send the deletion result to the middleware;

[0139] When the deletion result received by the middleware indicates that the deletion is completed, the certificate identifier is deleted.

[0140] Exemplarily, when the security authentication device (USBKey device) generates a third device identity credential for a certificate deletion application, it is necessary to verify whether the serial code SN carried in the certificate upload application matches the actual serial code of the security authentication device, and it can also verify whether the certificate identifier is consistent with at least one certificate identifier in the key container in the security authentication device.

[0141] Figure 5 The third flow chart of the certificate processing method of the embodiment of the present application is shown, which is applied to the cloud service end, such as Figure 5 As shown, the method may include steps S301 to S303.

[0142] Step S301: Receive a certificate upload application and a first device identity credential sent by the middleware; the certificate upload application is generated by the middleware based on a certificate file issued by a certificate authority and sent to the security authentication device, and the first device identity credential is generated by the security authentication device in response to the certificate upload application and sent to the middleware;

[0143] Step S302: if the certificate upload application and the first device identity credential are verified to be successful, extract the certificate identifier based on the certificate file included in the certificate upload application and store the certificate file;

[0144] Step S303: Send the upload result including the certificate identifier to the middleware; when the upload result is received and the upload is successful, the middleware is used to store the certificate identifier in the security authentication device and store the certificate file in the local cache of the middleware.

[0145] In the embodiment provided in the present application, the cloud server receives the certificate upload application and the first device identity credentials sent by the middleware. The certificate upload application is generated by the middleware based on the certificate file issued by the certificate authority (CA) and sent to the security authentication device. The first device identity credentials are generated by the security authentication device for the certificate upload application and sent to the middleware. The cloud server verifies the received certificate upload application and the first device identity credentials. If the verification is successful, the cloud server extracts the certificate identifier based on the certificate file contained in the certificate upload application. The certificate identifier is a unique identifier generated by the cloud server based on the certificate file, which is used for subsequent certificate management and verification. The cloud server sends the upload result containing the certificate identifier to the middleware, indicating whether the certificate file is successfully uploaded and stored. If the upload is successful, the middleware stores the certificate identifier in the security authentication device and stores the certificate file in the local cache for subsequent use.

[0146] Exemplarily, the cloud server uses the certificate identifier as an index to store the certificate file and the serial number SN of the corresponding security authentication device.

[0147] According to the embodiment provided by this application, the certificate upload application also includes a serial number and a first data generation time, and the method further includes:

[0148] Refuse to store the certificate file if any of the following conditions are met:

[0149] The conditions include: the first data generation time is outside the predetermined time range;

[0150] The serial number segment does not fall within the scope of the scheduled service;

[0151] The certificate file fails the root file verification;

[0152] calling the first device identity key generated by the key management system according to the serial number, verifying the first device identity credential, and obtaining a verification result that the first device identity credential has not been verified;

[0153] The first device identity credential is verified based on the second device identity key derived from the predetermined seed key and the serial number, and a verification result is obtained that the first device identity credential has not been verified.

[0154] In the embodiment provided in the present application, the method for the cloud server to verify the certificate upload application and the first device identity credentials includes at least: verifying whether the "time when the data was generated" is within the preset time range with the current time, and if it does not meet the requirements, the service will be rejected; verifying whether the serial number SN of the security authentication device (such as a USBKey device) is compliant and whether the number segment is within the service range, and if it does not meet the requirements, the service will be rejected; using the root certificate of the certificate authority (such as CA) (it can also be an intermediate certificate) to verify the legitimacy of the "certificate file", and if it fails, the service will be rejected; according to the serial number of the security authentication device, calling the device identity key in the key management system KMS, or dispersing the device identity key, verifying the first device identity credentials, and if it fails, the service will be rejected.

[0155] In the digital certificate system, root certificates and intermediate certificates are components of the certificate chain. The root certificate is the top-level certificate in the chain, issued by the certificate authority (CA) itself and serves as the foundation of the entire trust chain. Intermediate certificates are certificates signed by the root certificate and are used to issue end-user certificates. Intermediate certificates reduce the burden on the root certificate and increase the flexibility of certificate issuance.

[0156] For example, after receiving a message containing the first device's identity credentials, the cloud server needs to retrieve the device identity key to verify the validity of the credentials. The cloud server can obtain the device identity key in various ways, including calling the device identity key from the KMS (Key Management System) based on the USBKey device's SN (serial number). If the KMS doesn't directly store the device identity key, the cloud server can generate the device identity key using a key diversification algorithm based on the seed key and the USBKey device's SN.

[0157] For cloud servers, the following steps can be used to distribute certificates:

[0158] Receive a certificate distribution application and a second device identity credential; the certificate distribution application is generated by the middleware based on the certificate identifier and sent to the security authentication device when the certificate file fails integrity verification; the second device identity credential is generated by the security authentication device for the certificate distribution application and sent to the middleware;

[0159] When the certificate distribution application and the second device identity credentials are verified, the certificate file is returned to the middleware; the middleware is used to store the certificate file in the local cache and send the certificate file to the application end.

[0160] Exemplarily, the certificate distribution application further includes a serial number and a second data generation time, and the method further includes:

[0161] Refuse to distribute the certificate file if any of the following conditions are met:

[0162] The conditions include: the second data generation time is outside the predetermined time range;

[0163] The serial number segment does not fall within the scope of the scheduled service;

[0164] The second device identity key generated by the key management system is called according to the serial number to verify the second device identity credential, and a verification result is obtained that the second device identity credential has not been verified;

[0165] The second device identity credential is verified based on the second device identity key derived from the predetermined seed key and the serial number, and a verification result is obtained that the second device identity credential has not been verified.

[0166] In the embodiment provided in the present application, the method for the cloud service end to verify the certificate distribution application and the second device identity credentials includes at least: verifying whether the "time when the data was generated" is within the preset time range with the current time, and if it does not meet the requirements, the service will be rejected; verifying whether the serial number SN of the security authentication device (such as a USBKey device) is compliant and whether the number segment is within the service range, and if it does not meet the requirements, the service will be rejected; based on the serial number of the security authentication device, calling the device identity key in the key management system KMS, or dispersing the device identity key, verifying the second device identity credentials, and rejecting the service if it fails.

[0167] For cloud servers, the following steps can be used to delete certificates:

[0168] Receive a certificate deletion application and a third device identity credential; the certificate deletion application is generated by the intermediate based on the certificate identifier and sent to the security authentication device, and the third device identity credential is generated by the security authentication device for the certificate deletion application and sent to the middleware;

[0169] Deleting the certificate file when the certificate deletion request and the third device identity credentials are verified;

[0170] Sending a deletion result to the middleware; the middleware is used to delete the certificate identifier in the security authentication device when the received deletion result indicates that the deletion is completed.

[0171] According to the above embodiments and optional embodiments, the present application provides an optional implementation method for improving the USBKey certificate management method for resource-constrained security authentication devices, such as providing an improved solution for the USBKey certificate management function. Figure 6The first timing diagram of the certificate processing method of the embodiment of the present application is shown. In the embodiment of the present application, the middleware can be called USBKey middleware, the certificate issuing authority can be called CA service, the application end can be simply called application, and the cloud service end can be called certificate distribution cloud service. Steps a) to g) of the existing process remain unchanged, such as Figure 6 As shown, starting from step h), a new method is adopted:

[0172] a) [USBKey] Verify user permissions;

[0173] b)[USBKey] Create a key container;

[0174] c) [USBKey] Generate a key pair in the key container;

[0175] d) [USBKey middleware] is used to assemble the certificate request to be signed using the generated public key;

[0176] e) [USBKey] Sign the certificate request with the generated private key;

[0177] f) [CA service] Verify the signed certificate request and issue the certificate file after verification;

[0178] g) [Application] calls the import certificate interface of [USBKey middleware];

[0179] The following are targeted improvements to the optional implementation methods of this application:

[0180] h) [USBKey Middleware] After receiving the certificate file, it generates a "certificate upload request" to be signed;

[0181] i) [USBKey] uses the "Device Identity Key" (i.e. the first Device Identity Key) to generate the "Device Identity Credential" (i.e. the first Device Identity Credential during the import process) for the "Certificate Upload Request";

[0182] j) [Certificate Distribution Cloud Service] Verify the "Certificate Upload Request" and "Device Identity Credentials"; if verification is successful, extract the "Certificate Identifier" from the "Certificate File" and store the "Certificate File"; return a result response containing the "Certificate Identifier";

[0183] k) [USBKey middleware] receives and determines the result of the certificate upload; if the operation is successful, it stores the certificate file in the client's local cache and executes the next step; otherwise, the certificate distribution process fails;

[0184] l)[USBKey] Store the certificate identity in the key container.

[0185] It can be understood that the above process is generally divided into three stages:

[0186] Phase 1: Generate "Certificate Upload Application" and "Device Identity Credentials". [USBKey Middleware] generates "Certificate Upload Application" and calls [USBKey] to generate "Device Identity Credentials".

[0187] Phase 2: Certificate upload. The [Certificate Cloud Distribution Service] verifies the "certificate upload application," stores the certificate file after verification, and returns the certificate identifier.

[0188] Phase 3: Storing the certificate identifier: [USBKey] stores the certificate identifier in the key container within the device (instead of directly storing the certificate file as in the prior art); [USBKey middleware] stores the certificate file in the local cache.

[0189] The above is the process of importing a signed certificate. Regarding the import process, once the application obtains the certificate file from the certificate authority (i.e., after step g) above), the application's interaction interface with the USBKey middleware (the certificate import interface) remains unchanged, along with the interaction logic and input and output. The secure authentication device no longer stores the certificate file; it only manages the binding relationship between the certificate and key pair.

[0190] Figure 7 A second sequence diagram of the certificate processing method according to an embodiment of the present application is shown. Figure 7 As shown, a method for reading a certificate from a USBKey is provided.

[0191] a1) [Application] calls [USBKey middleware] to read the certificate interface;

[0192] b1) [USBKey middleware] reads the key container information from [USBKey] and retrieves the "certificate identifier" of the target certificate;

[0193] c1) [USBKey Middleware] searches for the target certificate file in the local cache using the "certificate identifier" as the index; if found, verifies the integrity of the certificate file (using the CA certificate to verify the signature of the certificate file). If the verification fails, delete the local cache; if the verification passes, return the certificate file to the [application], and the process ends; otherwise, continue;

[0194] d1) [USBKey middleware] generates a "certificate distribution request" and calls [USBKey] to use the "device identity key" to generate a "device identity credential" (the second device identity credential during the reading and reissuance process) for the "certificate distribution request";

[0195] e1) [Certificate Distribution Cloud Service] Verify the "Certificate Distribution Application" and "Device Identity Credentials"; if verification is successful, retrieve and return the corresponding "Certificate File";

[0196] f1) [USBKey middleware] stores the "certificate file" in the local cache using the "certificate identifier" as the index;

[0197] g1) [USBKey middleware] returns the "certificate file" to [application].

[0198] The above describes the process of reading and redistributing certificate files. For the application, the interaction interface (certificate reading interface) with the USBKey middleware remains unchanged, as does the interaction logic and input and output. Certificate files can be distributed online without using a USBKey. The certificate distribution cloud service only accepts certificate upload requests from valid USBKeys and will only distribute certificates to clients that hold the USBKey used to upload the certificate. A local certificate caching and certificate verification mechanism is implemented in the USBKey middleware to minimize network interaction between the USBKey middleware and the certificate distribution cloud service while ensuring the correct and usable certificates.

[0199] Figure 8 The third sequence diagram of the certificate processing method of the embodiment of the present application is shown as follows: Figure 8 As shown, a method for deleting a certificate from a USBKey is provided.

[0200] a2) [Application] calls [USBKey middleware] to delete the certificate interface;

[0201] b2) [USBKey middleware] reads the key container information from [USBKey] and retrieves the "certificate identifier" of the target certificate;

[0202] c2) [USBKey middleware] searches for the target certificate file in the local cache using the "certificate identifier" as the index; if found, deletes the certificate file in the local cache;

[0203] d2) [USBKey middleware] generates a "certificate deletion request" and calls [USBKey] to use the "device identity key" to generate a "device identity credential" (the third device identity credential in the deletion process) for the "certificate deletion request";

[0204] e2) [Certificate Distribution Cloud Service] Verify the "Certificate Deletion Request" and "Device Identity Credentials"; if verification is successful, retrieve and delete the corresponding "Certificate File";

[0205] f2) [USBKey middleware] requests [USBKey] to delete the "certificate identifier" from the key container;

[0206] g2) [USBKey middleware] returns the certificate deletion result to [application].

[0207] The above is the process of deleting the certificate file. For the application side, the interaction interface with the [USBKey middleware] (certificate deletion interface) remains unchanged, the interaction logic remains unchanged, and the input and output remain unchanged.

[0208] Given the large size of quantum-resistant cryptographic algorithm certificates, the optional implementation provided in this application reduces the storage space required for storing certificates on a security authentication device while still being able to restore the complete certificate. For example, an X.509 certificate embedded with a Dilithium5 public key and signature can be up to 8KB in size. Using the above processing approach, only a dozen or dozens of bytes are required on the security authentication device (only the certificate DN is stored). This can alleviate the storage resource bottleneck of storage-resource-constrained security authentication devices during quantum-resistant cryptography migration.

[0209] Through any of the above processing methods, the certificate processing method provided by this optional implementation is transparent to upper-layer applications, and does not require upper-layer applications to make any changes to the interface, data, or process. The certificate management interface of the USBKey middleware remains unchanged to the outside world, achieving backward compatibility. Only legitimate USBKey clients holding the certificate private key are allowed to upload certificates, and only clients holding the corresponding USBKey are allowed to distribute certificates, avoiding potential security attacks and privacy leaks. The local caching method is used to optimize interface response performance and alleviate the pressure of cloud service requests.

[0210] Figure 9 A first schematic diagram of a certificate processing device according to an embodiment of the present application is shown. Corresponding to the application scenario and method of the method provided in the embodiment of the present application, the embodiment of the present application also provides a certificate processing device applied to middleware, such as Figure 9 Shown, including:

[0211] Acquisition module 901, used to obtain the certificate file issued by the certificate authority;

[0212] The first processing module 902 is used to generate and send a certificate upload application to the security authentication device based on the certificate file; the security authentication device is used to generate a first device identity credential for the certificate upload application and send the first device identity credential to the middleware;

[0213] A first sending module 903 is configured to send the certificate upload application and the first device identity credential to the cloud server. The cloud server is configured to, upon verification of the certificate upload application and the first device identity credential, store the certificate file included in the certificate upload application and send an upload result including a certificate identifier to the middleware. The certificate identifier is extracted by the cloud server based on the certificate file.

[0214] The first storage module 904 is configured to store the certificate identifier in the security authentication device and store the certificate file in the local cache of the middleware when the received upload result indicates that the upload is successful.

[0215] The functions of each module in each device in the embodiment of the present application can be referred to the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.

[0216] Figure 10 A second schematic diagram of a certificate processing device according to an embodiment of the present application is shown. Corresponding to the application scenario and method of the method provided in the embodiment of the present application, the embodiment of the present application further provides a certificate processing device applied to a security authentication device, such as Figure 10 Shown, including:

[0217] The second processing module 1001 is used to generate a first device identity credential for the certificate upload application when a certificate upload application is received, and send the first device identity credential to the middleware; the certificate upload application is generated by the middleware based on the certificate file issued by the certificate authority, and the middleware is used to send the certificate upload application and the first device identity credential to the cloud server. The cloud server is used to store the certificate file included in the certificate upload application when the certificate upload application and the first device identity credential are verified, and send an upload result including a certificate identifier to the middleware, where the certificate identifier is extracted by the cloud server based on the certificate file. The middleware is used to send the certificate identifier to the security authentication device when the upload result is successful, and store the certificate file in the local cache of the middleware;

[0218] The second storage module 1002 is configured to receive and store the certificate identifier.

[0219] Figure 11 A third schematic diagram of a certificate processing device according to an embodiment of the present application is shown. Corresponding to the application scenario and method of the method provided in the embodiment of the present application, the embodiment of the present application further provides a certificate processing device applied to a cloud service end, such as Figure 11 Shown, including:

[0220] Receiving module 1101, configured to receive a certificate upload application and a first device identity credential sent by the middleware; the certificate upload application is generated by the middleware based on a certificate file issued by a certificate authority and sent to the security authentication device; the first device identity credential is generated by the security authentication device in response to the certificate upload application and sent to the middleware;

[0221] The third processing module 1102 is configured to extract a certificate identifier based on the certificate file included in the certificate upload application and store the certificate file if the certificate upload application and the first device identity credential are verified to be successful.

[0222] The second sending module 1103 is used to send the upload result including the certificate identifier to the middleware; when the upload result is received and the upload is successful, the middleware is used to store the certificate identifier in the security authentication device and store the certificate file in the local cache of the middleware.

[0223] Figure 12 FIG. 1 is a block diagram of an electronic device for implementing an embodiment of the present application. Figure 12 As shown, the electronic device includes: a memory 1201 and a processor 1202. The memory 1201 stores a computer program that can be executed on the processor 1202. When the processor 1202 executes the computer program, the method of the above embodiment is implemented. The number of memory 1201 and processor 1202 can be one or more. In a specific implementation, the electronic device may also include a communication interface 1203 for communicating with external devices and exchanging data.

[0224] In a specific implementation, if the memory 1201, processor 1202, and communication interface 1203 are implemented independently, the memory 1201, processor 1202, and communication interface 1203 can be connected to each other via a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 12 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0225] Optionally, in a specific implementation, if the memory 1201 , the processor 1202 , and the communication interface 1203 are integrated on a chip, the memory 1201 , the processor 1202 , and the communication interface 1203 may communicate with each other through an internal interface.

[0226] An embodiment of the present application provides a computer-readable storage medium storing a computer program, which implements the method provided in the embodiment of the present application when the program is executed by a processor.

[0227] An embodiment of the present application provides a computer program product, including a computer program, which implements the method provided in the embodiment of the present application when executed by a processor.

[0228] An embodiment of the present application also provides a chip, which includes a processor for calling and executing instructions stored in the memory from the memory, so that a communication device equipped with the chip executes the method provided in the embodiment of the present application.

[0229] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory. The input interface, the output interface, the processor and the memory are connected through an internal connection path. The processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method provided in the embodiment of the application.

[0230] It should be understood that the processor described above may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor. It is worth noting that the processor may be a processor that supports the Advanced RISC Machines (ARM) architecture.

[0231] Furthermore, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache memory. By way of example and not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM) and direct memory bus random access memory (DR RAM).

[0232] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0233] In the description of this specification, the reference terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" mean that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials, or characteristics described may be combined in any appropriate manner in any one or more embodiments or examples. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification, as well as features of different embodiments or examples, unless they are mutually inconsistent.

[0234] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0235] Any process or method described in the flowchart or otherwise described herein can be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process. The scope of the preferred embodiments of the present application includes other implementations in which the functions may be performed in a different order than shown or discussed, including performing the functions substantially simultaneously or in reverse order depending on the functions involved.

[0236] The logic and / or steps described in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processor, or other system that can fetch instructions from and execute instructions on an instruction execution system, apparatus or device), or used in conjunction with such instruction execution systems, apparatuses or devices.

[0237] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above embodiment method can be completed by instructing the relevant hardware through a program, which can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0238] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing module, or each unit may exist physically separately, or two or more units may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or in the form of software functional modules. If the aforementioned integrated modules are implemented in the form of software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk, or an optical disk, etc.

[0239] The above are merely exemplary embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily conceive of various modifications or substitutions within the technical scope described in this application, and such modifications or substitutions should be included within the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A certificate processing method, characterized in that: Applicable to middleware, including: Obtain the certificate file issued by the certificate authority; Based on the certificate file, generate and send a certificate upload application to a security authentication device; the security authentication device is used to generate a first device identity credential for the certificate upload application and send the first device identity credential to the middleware; The certificate upload application and the first device identity credential are sent to a cloud server; the cloud server is configured to, upon verification of the certificate upload application and the first device identity credential, store the certificate file included in the certificate upload application, and send an upload result including a certificate identifier to the middleware, the certificate identifier being extracted by the cloud server based on the certificate file; When the received upload result indicates that the upload is successful, the certificate identifier is stored in the security authentication device, and the certificate file is stored in the local cache of the middleware.

2. The method according to claim 1, characterized in that After storing the certificate identifier in the security authentication device and storing the certificate file in the local cache of the middleware, the method further includes: In response to receiving a read instruction for reading the certificate file, obtaining key container information of the security authentication device; According to the read instruction, the certificate identifier is retrieved from the key container information; Searching the local cache for the certificate file whose index is the certificate identifier; When the certificate file passes the integrity verification, the certificate file is sent to the application end, and the application end is used to call the middleware for human-computer interaction.

3. The method according to claim 2, characterized in that The method further comprises: If the certificate file fails the integrity verification, deleting the certificate file from the local cache; Based on the certificate identifier, a certificate distribution application is generated and sent to the security authentication device; the security authentication device is used to generate and send a second device identity credential for the certificate distribution application to the middleware; Sending the certificate distribution application and the second device identity credential to the cloud service end; the cloud service end is configured to return the certificate file to the middleware if the certificate distribution application and the second device identity credential are verified; The certificate file is stored in the local cache, and the certificate file is sent to the application end.

4. The method according to claim 1, wherein After storing the certificate identifier in the security authentication device and caching the certificate file locally in the middleware, the method further includes: In response to receiving a deletion instruction to delete the certificate file, obtaining key container information of the security authentication device; According to the deletion instruction, the certificate identifier is retrieved from the key container information; Deleting the certificate file whose index is the certificate identifier from the local cache; Based on the certificate identifier, a certificate deletion application is generated and sent to the security authentication device; the security authentication device is used to generate and send a third device identity credential to the middleware for the certificate deletion application; Sending the certificate deletion request and the third device identity credential to the cloud server; the cloud server is configured to delete the certificate file on the cloud server if the certificate deletion request and the third device identity credential are verified, and send a deletion result to the middleware; When the received deletion result indicates that the deletion is completed, the certificate identifier is deleted in the security authentication device.

5. The method according to any one of claims 1 to 4, characterized in that The security authentication device includes a key pair of a public key and a private key. Before obtaining the certificate file issued by the certificate authority, the method further includes: Assembling a certificate request to be signed based on the public key; Sending the certificate request to the security authentication device; the security authentication device is used to sign the certificate request using the private key; The signed certificate request is sent to a certificate authority for verification; if the certificate request is verified to be successful, the certificate authority issues the certificate file.

6. A certificate processing method, characterized in that: Applied to security authentication equipment, including: Upon receiving a certificate upload application, a first device identity credential is generated for the certificate upload application, and the first device identity credential is sent to the middleware; the certificate upload application is generated by the middleware based on a certificate file issued by a certificate authority, and the middleware is used to send the certificate upload application and the first device identity credential to the cloud server; the cloud server is used to store the certificate file included in the certificate upload application upon verification of the certificate upload application and the first device identity credential, and send an upload result including a certificate identifier to the middleware, the certificate identifier being extracted by the cloud server based on the certificate file; the middleware is used to send the certificate identifier to the security authentication device upon receiving that the upload result is successful, and store the certificate file in the local cache of the middleware; The certificate identification is received and stored.

7. A certificate processing method, characterized in that: Applied to cloud servers, including: Receive a certificate upload application and a first device identity credential sent by the middleware; the certificate upload application is generated by the middleware based on a certificate file issued by a certificate authority and sent to the security authentication device, and the first device identity credential is generated by the security authentication device for the certificate upload application and sent to the middleware; If the certificate upload application and the first device identity credential are verified to be successful, extracting a certificate identifier based on the certificate file included in the certificate upload application, and storing the certificate file; The upload result including the certificate identifier is sent to the middleware; the middleware is used to store the certificate identifier in the security authentication device and store the certificate file in the local cache of the middleware when the upload result is received and the upload is successful.

8. The method according to claim 7, characterized in that The certificate upload application also includes a serial number and a first data generation time, and the method further includes: Refuse to store the certificate file if any of the following conditions are met: The conditions include: the first data generation time is beyond a predetermined time range; The serial number segment does not fall within the scope of the scheduled service; The certificate file fails to pass the root file verification; calling a first device identity key generated by a key management system according to the serial number, verifying the first device identity credential, and obtaining a verification result that the first device identity credential has failed verification; The first device identity credential is verified based on a second device identity key derived from a predetermined seed key and the serial number, and a verification result is that the first device identity credential has not been verified.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 8 when executing the computer program. 10 . A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method according to claim 1 is implemented.

Images