Certificate processing method, electronic equipment and computer readable storage medium
Through the certificate processing method, the coordinated work of middleware, security authentication equipment and cloud servers is used to solve the problem of insufficient certificate storage space in quantum password migration by resource-constrained security authentication equipment, and a sensing-free improvement storage solution is achieved.
Patent Information
- Application Number
- CN202510586971.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-08
- Publication Date
- 2025-06-06
- Estimated Expiration
- 2045-05-08
AI Technical Summary
After migrating to quantum-resistant passwords, resource-constrained security authentication devices face the problem of insufficient certificate storage space. The existing solutions need to transform upstream and downstream systems and add additional authentication processes, making it difficult to be compatible with the existing password authentication process.
Through a certificate processing method, the middleware, security authentication device and cloud server work together to generate certificate upload application and device identity credentials, store certificate files on the cloud server, and store certificate identifiers in security authentication devices and middleware to avoid the storage of the certificate files themselves.
It has realized that the problem of limited storage resources of secure authentication devices is alleviated without adding additional authentication processes, supports the storage needs of quantum cryptographic certificates, and has no sense-free improvements to existing systems.
Smart Images

Figure CN120110686A_ABST
Abstract
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 cryptographic systems rely on mathematical problems such as large number factorization or discrete logarithms, which can be cracked by quantum computers in polynomial time, threatening the security of existing encryption. Quantum-resistant cryptography is based on other mathematical structures that can remain secure even if cracked by quantum computers.
[0003] For resource-constrained security authentication devices, after migrating to quantum-resistant cryptography, due to the inherent characteristics of the algorithm's mathematical structure, the length of the public key and signature increases by orders of magnitude, and the size of the key and certificate increases significantly. However, the secure storage space of the security authentication device is limited (usually only tens of KB), making certificate storage a technical bottleneck. The solutions provided in the relevant technologies require the transformation of the upstream and downstream docking systems, a large number of functional adjustments to the existing verification logic, and reliance on the addition of additional authentication processes to adapt to the quantum-resistant cryptography requirements of resource-constrained security authentication devices. It is difficult to be directly compatible with the existing cryptographic authentication process, and there are technical problems with large 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 solve 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 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: Obtain the certificate file issued by the certificate authority; 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; 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; When the received upload result 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.
[0006] In a second aspect, an embodiment of the present application provides a certificate processing method, which is applied to a security authentication device, 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 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 is 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 received that the upload is successful, and store the certificate file in the local cache of the middleware; Receive and store the certificate identification.
[0007] In a third aspect, an embodiment of the present application provides a certificate processing method, which is applied to a cloud service end, including: 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; In the case of verifying that the certificate upload application and the first device identity credential are passed, 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 identification is sent to the middleware; when the middleware receives the upload result indicating that the upload is successful, the certificate identification is stored in the security authentication device and the certificate file is stored in the local cache of the middleware.
[0008] In a fourth aspect, an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory, and the processor implements any method of the embodiment of the present application when executing the computer program.
[0009] 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.
[0010] Based on the certificate processing methods of the first, second and third aspects above, the present application has at least the following beneficial effects or advantages: Security authentication devices do not need to save certificate files, but only manage certificate identifiers that reflect binding relationships, and use cloud servers to distribute certificates and transfer them with devices to alleviate the storage resource constraints faced by similar resource-constrained devices in anti-quantum cryptographic migration. The above improvements can achieve seamless upgrades for existing frameworks such as application terminals and certificate issuing authorities, remain transparent to upper-level applications, and applications do not need to make functional logic adjustments for this, and do not add additional authentication processes.
[0011] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present 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 the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the multiple drawings represent the same or similar parts 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.
[0013] Figure 1 A first flow chart of the certificate processing method according to an embodiment of the present application is shown; Figure 2 A first schematic block diagram in the related art is shown; Figure 3 A second schematic block diagram of the certificate processing method according to an embodiment of the present application is shown; Figure 4 A second flow chart of the certificate processing method according to an embodiment of the present application is shown; Figure 5 A third flow chart of the certificate processing method according to an embodiment of the present application is shown; Figure 6 A first timing diagram of the certificate processing method according to an embodiment of the present application is shown; Figure 7 A second timing diagram of the certificate processing method according to an embodiment of the present application is shown; Figure 8 A third timing diagram of the certificate processing method according to an embodiment of the present application is shown; Fig. 9 A first schematic diagram of a certificate processing device according to an embodiment of the present application is shown; Fig.10 A second schematic diagram of the certificate processing device according to an embodiment of the present application is shown; Fig.11 A third schematic diagram of the certificate processing device according to an embodiment of the present application is shown; Fig.12A block diagram of an electronic device provided by an embodiment of the present application is shown. DETAILED DESCRIPTION
[0014] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the concept or scope of the present application. Therefore, the drawings and descriptions are considered to be exemplary in nature and not restrictive.
[0015] 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 they all belong to the protection scope of the embodiments of the present application.
[0016] The following terms will be used in the following text: Post-Quantum Cryptography (PQC) refers to encryption algorithms that can resist attacks by quantum computers. Traditional cryptographic systems rely on mathematical problems such as large number factorization or discrete logarithms, which can be cracked by quantum computers in polynomial time, threatening the security of existing encryption. Quantum-resistant cryptography is based on other mathematical structures that can maintain security even when quantum computers mature.
[0017] 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).
[0018] SN (Serial Number) is a unique identifier that is fixed into the security chip by the manufacturer during production.
[0019] The public key and private key are a pair of keys in an asymmetric encryption system. The public key can be used to encrypt data and verify digital signatures. Only users 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.
[0020] A Certificate Authority (CA) is a trusted third-party organization responsible for issuing, managing, and revoking digital certificates.
[0021] For resource-constrained security authentication devices, such as USBKey (also known as smart password key), a technical challenge faced in anti-quantum cryptographic migration is the difficulty of storing certificates for anti-quantum cryptographic algorithms due to security storage resource constraints. USBKey is a security authentication device widely used in finance, government affairs, the Internet of Things and other fields, and its security capabilities rely on the physical security characteristics of security chips.
[0022] On the one hand, compared with general storage devices, the unit storage cost of security chips is usually more than 25 times higher due to factors such as anti-physical attack security requirements and process technology. Due to cost constraints, the internal storage space of the security chip used by USBKey is usually small, with common specifications such as 320KB. Considering the space reserved for firmware and algorithm libraries, the space left for storing keys, certificates and user data is usually less than 90KB.
[0023] The storage space requirements for certificates of quantum-resistant cryptographic algorithms are significantly higher than those of certificates of classical algorithms. The core reason is that in widely used document formats such as X.509 certificates and PGP certificates, the certificate public key and certificate signature are both necessary elements, while the mathematical construction characteristics of quantum-resistant cryptographic algorithms cause the length of public keys and signatures to increase by orders of magnitude.
[0024] The public key length of classic RSA-2048 is 256 bytes, and the signature length is 256 bytes; the public key length of the FIPS 204 ML-DSA Dilithium5 algorithm based on lattice cryptography reaches 2.5KB, and the signature is extended to 4.5KB. The corresponding X.509 certificate size is nearly 6 times that 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 non-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. The above four algorithms are quantum-resistant algorithms.
[0025] Table 1 Comparison of parameters and certificate sizes of quantum-resistant signature algorithms
[0026] 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 contrast, traditional ECC certificates are 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.
[0027] It should be noted that the above application scenarios or application examples provided in the embodiments of the present application are for ease of understanding, and the embodiments of the present 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 need to comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.
[0028] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The several specific embodiments listed can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described in detail below with reference to the accompanying drawings.
[0029] Figure 1 A first flow chart of the certificate processing method according to an 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.
[0030] Step S101: Obtain a certificate file issued by a certificate authority; Step S102: 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; Step S103: 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 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; Step S104: When the received upload result is 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.
[0031] Exemplarily, the cloud service end may be of multiple 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.
[0032] In the embodiment of the present application, the certificate upload process is shown. The middleware obtains the certificate file issued by the certificate authority (CA). The certificate file is an important credential for identity authentication and encrypted communication. Based on the obtained certificate file, the middleware generates a certificate upload application and sends the application to a security authentication device (such as a USBKey). The certificate upload application contains relevant information about the certificate file, which is used to request the security authentication device to upload the certificate. After receiving the certificate upload application, the security authentication device will generate a first device identity credential for the application, which is used to verify the device identity, ensure that only legal devices can perform certificate upload operations, and prevent unauthorized certificate uploads, thereby enhancing the security of the system. The security authentication device then sends the first device identity credential to the middleware. The middleware sends the certificate upload application and the first device identity credential to the cloud service end. After receiving this information, the cloud service end will verify to ensure the validity of the certificate upload application and the device identity credential. If the verification is successful, the cloud service end will store the certificate file contained in the certificate upload application and extract the certificate identifier from it. The certificate identifier is a unique identifier generated by the cloud service end based on the certificate file, which is used for subsequent certificate management and verification. The cloud server then sends the upload result including the certificate identifier to the middleware. After receiving the upload result, if the result shows that the upload is successful, the middleware will store the certificate identifier in the security authentication device and store the certificate file in the local cache for fast access to the certificate file, reducing the dependence on the cloud server and improving the system's response speed and user experience. The certificate file is stored on the cloud server, and the certificate identifier is stored in the security authentication device. The above distributed storage method decouples the storage requirements of the security authentication device and the certificate file itself, which not only ensures data security but also improves storage flexibility.
[0033] Through the above processing, under the premise of ensuring the correct association between the certificate and the key pair, the certificate file is not stored in the device, and the certificate file is distributed online through the cloud server. The challenges brought by the device storage limitation during the quantum cryptography migration process should be overcome. Only the user end holding the legitimate USBKey of the certificate private key is allowed to upload the certificate to the certificate distribution cloud service, and only the user end holding the corresponding USBKey is allowed to distribute the certificate to the local device, avoiding potential security attacks and privacy leakage risks; There can be many types of security authentication products, such as USBKey, U shield, smart card, hardware token, etc. For the convenience of description in the following text, for the case where the security authentication device is USBKey, the above-mentioned execution subject is the middleware, that is, USBKey middleware. USBKey is a hardware device with a USB interface, a built-in single-chip microcomputer or smart card chip, and a certain 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 in the existing authentication process. The embodiment of the present application improves the interaction between USBKey middleware, USBKey, and the 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.
[0034] 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.
[0035] In the embodiment provided in the present 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, without specific limitation.
[0036] In an optional embodiment provided in the present application, the method further includes: determining the 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.
[0037] The above certificate identifier refers to the unique identification data of the certificate. Different identifiers can be selected according to different certificate standards. Taking X.509 certificate as an example, in actual application, which data to choose as the certificate identifier can be determined according to the business needs of the application system. Optional certificate identifiers include: Certificate Serial Number, a unique integer assigned by the certificate authority (CA), which is unique under the same CA; Subject Name, the identification information of the certificate holder, also known as "certificate DN"; Certificate Fingerprint, a unique value obtained by hashing the certificate content (usually DER encoding); Public Key Hash, a value obtained by hashing the public key data in the certificate. For example, the business system distinguishes certificates by certificate DN. When calling the password application interface to request USBKey signature, if the parameter passed in for selecting the certificate is certificate DN, then certificate DN should be selected as the certificate identifier.
[0038] According to the embodiment provided by the present application, the security authentication device also stores a key pair of a public key and a private key. Before executing step S101, the method further includes: Assemble the certificate request to be signed based on the public key; Sending a certificate request to a security authentication device; the security authentication device is used to sign the certificate request using a private key; Send the signed certificate request to the certificate authority for verification; if the certificate request is verified, the certificate authority will issue a certificate file.
[0039] In the embodiment provided in the present application, an improvement is made based on the original process framework with certificate authentication requirements. A pair of asymmetric keys is generated internally by a security authentication device (such as a USBKey), in which the public key will be used to construct a certificate request, and the private key is securely stored in the USBKey. According to the information security standard, the private key is not transmitted externally. The middleware uses the public key and other necessary identity information to assemble a certificate request (CSR) to be signed for applying for a certificate from a certificate authority (CA). The certificate request is sent to the security authentication device, and the certificate request is digitally signed using the private key stored internally to generate a signed certificate request to ensure that the request is indeed initiated by a legitimate USBKey. After the signature is completed, the signed certificate request is sent to the certificate authority for verification. After the certificate authority receives the request, a series of verification operations can be performed, including verifying the validity of the signature, confirming the legitimacy of the applicant's identity information, and checking the validity of the public key. Only when all verifications are passed will the certificate authority issue a digital certificate file and return it to the middleware.
[0040] According to the embodiment provided by the present application, in step S104: storing the certificate file in the local cache of the middleware may include any of the following methods: Store the certificate file in the local disk in the form of a file; Store certificate files in the local database; Store the certificate file in the Windows system registry; Use the certificate management mechanism or certificate library provided by the operating system to store certificate files; Use sandbox technology to store certificate files; Develop secure storage software to protect certificate files.
[0041] In the embodiment of the present application, the middleware protects the locally cached certificate files from being tampered with, accidentally or maliciously deleted by means of file permission protection, account access control, or protection mechanisms implemented by third-party technologies through the operating system, thereby reducing the number of interactions between the user end and the cloud server end and alleviating the request pressure on the cloud server end. The storage method can adopt one or a combination of the above methods.
[0042] Figure 2 The first schematic block diagram in the related art is shown, and the application system architecture based on USBKey is as follows Figure 2 As shown, it is mainly composed of a host computer (i.e., the interface for user interaction) and a USBKey (security authentication device). The application or browser (i.e., the user end) implements key management, certificate management, cryptographic operations and other functions by calling the "cryptographic application interface" (API) provided by the USBKey middleware. The USBKey middleware is responsible for processing the command communication and interaction logic with the USBKey (i.e., the above-mentioned security authentication device). It should be noted that the USBKey product provides manufacturers with two parts, namely, the USBKey middleware and the USBKey. For ease of understanding, the security authentication device may be referred to as the USBKey below, the middleware may be referred to as the USBKey middleware, the certificate authority may be referred to as the CA service, the application end may be referred to as the application, and the cloud service end may be referred to as the certificate distribution cloud service.
[0043] In the existing process, the process of downloading the signature certificate to USBKey can be expressed as follows: a) [USBKey] Verify user permissions; b)[USBKey] Create a key container; c)[USBKey] Generate a key pair in the key container; d) [USBKey middleware] is used to assemble the certificate request to be signed using the generated public key; e) [USBKey] Sign the certificate request with the generated private key; f) [CA service] (i.e., certificate authority) verifies the signed certificate request and issues the certificate file after verification; g) [Application] (i.e. application end) calls the import certificate interface of [USBKey middleware]; h)[USBKey] Store certificate files in key containers.
[0044] In order to show that the embodiments provided by this application do not require changing 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 3 As shown, the "Cryptographic Application Interface" API remains unchanged. The USBKey device no longer stores certificate files, and stores the "certificate identifier" 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. The key file may contain information such as symmetric keys and asymmetric key pairs (public keys and private keys), and is stored in a security authentication device to prevent unauthorized access and tampering. The "certificate distribution cloud service" is responsible for storing and distributing certificate files. In the embodiment provided in this application, the USBKey manufacturer provides a USBKey product including three parts: USBKey middleware, USBKey device, and certificate distribution cloud service (i.e., cloud service end). It should be noted that although the cloud service end is added as an interactive subject, for the application end and the certificate issuing authority in the existing process, the interaction with the USBKey product has not changed. What has changed is the interaction method inside the USBKey, which can achieve a non-sensing improvement method for the original process. In other words, the internal architecture has been adjusted, but the application or browser on the client side still interacts with the USBKey middleware through the same cryptographic application interface API. This means that the application side can seamlessly connect to the new certificate processing method without any modification, achieving a seamless improvement to the original process.
[0045] For example, the communication between the USBKey middleware and the certificate cloud distribution service (i.e., the cloud service end) can adopt a variety of secure communication methods, such as: TLS (Transport Layer Security), HTTPS (Secure Hypertext Transfer Protocol), VPN (Virtual Private Network), IPsec (Internet Protocol Security), SSH (Secure Shell) tunnel, etc. TLS is an encryption protocol used to provide secure communication on the Internet. By encrypting data packets, it ensures that data is not stolen or tampered with during transmission. HTTPS is a secure version of the HTTP protocol, which encrypts data through the TLS protocol. Not only does it encrypt data, but it also verifies the identities of both parties in communication through digital certificates to prevent man-in-the-middle attacks. VPN creates an encrypted virtual tunnel to securely transmit data to the target server, and can establish a secure communication channel on a public network (such as the Internet) to ensure the confidentiality and integrity of data during transmission. IPsec is a network layer security protocol that ensures the security and integrity of data during transmission by encrypting and authenticating IP data packets, and provides end-to-end security protection at the IP layer. SSH is a protocol for secure remote login and server management. Through the SSH tunnel, data from other protocols (such as HTTP, FTP, etc.) can be encapsulated in the SSH connection to achieve encrypted data transmission. The above communication methods are only examples of secure communication methods and are not specifically limited.
[0046] The above embodiment implements the first distribution and download of the certificate. In the subsequent interaction with the application end, the certificate needs to be read for security authentication. The certificate reading process is described below. After step S104, the method further includes the following specific steps: In response to receiving a read instruction to read a certificate file, obtaining key container information of a security authentication device; According to the read instruction, the certificate identifier is retrieved from the key container information; Search 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, which is used to call the middleware for human-computer interaction.
[0047] In the embodiment provided in 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 whose index is the retrieved certificate identifier, indicating that the local cache stores the certificate file that was previously downloaded and successfully stored from the cloud service side. 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.
[0048] 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.
[0049] In the embodiment provided in the present application, the method further comprises the following steps: If the certificate file fails the integrity verification, the certificate file is deleted from the local cache; Based on the certificate identification, a certificate distribution application is generated and sent to a security authentication device; the security authentication device is used to generate and send a second device identity credential to the middleware for the certificate distribution application; The certificate distribution application and the second device identity credential are sent to the cloud server; 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; Store the certificate file in the local cache and send the certificate file to the application.
[0050] In the embodiment provided by the present application, if the certificate file fails the integrity verification, it indicates that the certificate file may be tampered with or damaged during storage or transmission. In the case where the certificate file fails the integrity verification, the middleware deletes the certificate file in the local cache to prevent the use of damaged or unsafe certificates for subsequent operations. Based on the certificate identifier, the middleware generates a certificate distribution application, which includes a certificate identifier and is used to request the cloud server to re-acquire the certificate file. Before sending 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, and generates and sends the second device identity credential to the middleware. The middleware sends the certificate distribution application and the second device identity credential to the cloud server together, and the cloud server verifies the received application and credentials. If the verification is successful, the cloud server returns the certificate file to the middleware, the middleware stores the certificate file re-acquired from the cloud server in the local cache, and sends the certificate file to the application end, which then uses the certificate file for security authentication.
[0051] 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, which not only guarantees the authenticity and integrity of the certificate file, but also improves the security and reliability of the entire system.
[0052] 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.
[0053] In the embodiment provided in the present application, the certificate distribution application is also accompanied by a second device identity credential generated by a security authentication device. The certificate distribution application provided by the middleware can select a specific encoding format according to a specific application scenario, without specific limitation.
[0054] According to the embodiments provided in this application, Figure 5 A third flow chart of the certificate processing method of an embodiment of the present application is shown, Figure 5 As shown, in addition to the initial distribution download, reading and re-acquisition mechanism of the certificate, a certificate deletion mechanism is also provided, and 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: 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; Delete the certificate file with the index of the certificate identifier in the local cache; 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; Send the certificate deletion application 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; When the received deletion result indicates that the deletion is completed, the certificate identifier is deleted in the security authentication device.
[0055] In an embodiment of the present application, when the application needs to delete a certificate file, a deletion instruction for deleting the certificate file is sent to the middleware. After the middleware receives the deletion instruction, the certificate deletion process is triggered. According to the deletion instruction, the middleware retrieves the certificate identifier corresponding to the instruction in the key container information. The middleware searches for the certificate file whose index is the retrieved certificate identifier in the local cache and deletes it. Based on the certificate identifier, the middleware generates a certificate deletion application. The certificate deletion application includes the certificate identifier, which is used to request the cloud service end to delete the certificate file. Before sending it to the cloud service end, the middleware sends the certificate deletion application to the security authentication device, and the security authentication device uses its internal device identity key to sign the certificate deletion application, generate and send the third device identity credential to the middleware. The middleware sends the certificate deletion application and the third device identity credential together to the cloud service end, and the cloud service end verifies the received certificate deletion application and the third device identity credential. The cloud service end verifies the certificate deletion application and the third device identity credential. If the verification is successful, the cloud service end deletes the certificate file on the cloud service end 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, thus completing the entire deletion process.
[0056] 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.
[0057] In the embodiment provided in the present application, the certificate deletion application is also accompanied by a third device identity credential generated by a security authentication device. The certificate deletion application provided by the middleware can select a specific encoding format according to a specific application scenario, and is not specifically limited.
[0058] 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.
[0059] 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 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, 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 is 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 received that the upload is successful, and store the certificate file in the local cache of the middleware; Step S202: Receive and store the certificate identification.
[0060] In the embodiment provided in the present application, the security authentication device uses its internally stored device identity key to sign the certificate upload application and generate a first device identity credential to prove that the application is 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 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.
[0061] 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: Using the device identity key, based on the certificate upload application, a calculation is performed to obtain the first device identity credential; 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 dispersedly obtained by a seed key and a serial number of the security authentication device.
[0062] In the embodiment provided in this application, the security authentication device (USBKey device) uses the device identity key to calculate the certificate upload application to obtain the first device identity credential. During the production process of the USBKey product, the device identity key is generated by the KMS (key management system) and written into the device; the device identity key can also be dispersed from the seed key and the SN (unique serial number) of the USBKey. The device identity key is preferably a symmetric key stored inside the USBKey. Considering the storage capacity constraint of the USBKey and the security principle of anti-quantum cryptographic migration, it is not suitable to select a traditional public key cryptographic algorithm or a certain anti-quantum cryptographic algorithm.
[0063] According to an optional embodiment provided by the present application, in step S202: receiving and storing a certificate identification includes: creating a certificate identification file for storing a certificate file in a key container; or, In the attributes of the key container or the key container information, an attribute or field for storing the certificate identifier is added.
[0064] In the embodiments provided in this application, a key container is a security structure for storing and managing keys and related information. The certificate identification file is stored in a secure storage area of a security authentication device, or the attributes or fields of a key container are stored in a secure storage area of a security authentication device to ensure its security and confidentiality.
[0065] 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, and the same association method can be used for processing, which is all within the protection scope of the present application.
[0066] The device identity credential can be a message authentication code (MAC) generated by calculating the input message (i.e., the certificate upload application mentioned above) using the device identity key of the USBKey device. The message authentication code is a form of the first device identity credential. The calculation of the above message authentication code (MAC) is used to prove that the message is authorized by a legitimate USBKey device. There are many ways to use it, for example: use a symmetric encryption algorithm (such as AES-CMAC) to encrypt the input message and generate a MAC. Use a hash function (such as HMAC-SHA256) in combination with the device identity key to process the input message and generate a MAC.
[0067] Exemplarily, when the security authentication device (USBKey device) generates the first device identity credential for the certificate upload 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 public key carried 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: in order to use the cloud service end to distribute root certificates, intermediate certificates, or certificates whose key pairs are not inside the security authentication device.
[0068] For the execution subject security authentication device, the following steps can be used for certificate distribution: 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 to pass the integrity verification; 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.
[0069] Specifically, there may be many reasons why the certificate file fails the integrity verification, such as the certificate file as a whole is not cached, or the cached data of the certificate file is missing and the cached data fails the integrity verification. Regardless of the above reasons, once the middleware detects that there is an integrity problem with the certificate file, it will generate a certificate distribution application, triggering the subsequent certificate resend process.
[0070] 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.
[0071] For a security authentication device, the following steps can be used to delete the certificate: In response to the middleware receiving a deletion instruction to delete the certificate file, the key container information is sent to the middleware; the middleware is used to retrieve the certificate identifier in the key container information according to the deletion instruction; and delete the certificate file indexed as the certificate identifier in the local cache; Receive a certificate deletion application; the certificate deletion application is generated and sent by the middleware based on the certificate identifier; In response to the certificate deletion application, generate and send the third device identity credentials to the middleware; the middleware is used to send the certificate deletion application 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; When the deletion result received by the middleware indicates that the deletion is completed, the certificate identifier is deleted.
[0072] 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.
[0073] Figure 5 A third flow chart of the certificate processing method of an embodiment of the present application is shown, which is applied to a cloud service end, such as Figure 5 As shown, the method may include steps S301 to S303.
[0074] Step S301: receiving 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; Step S302: when the certificate upload application and the first device identity credential are verified to be passed, extracting a certificate identifier based on the certificate file included in the certificate upload application, and storing the certificate file; Step S303: sending the upload result including the certificate identifier to the middleware; when receiving the upload result indicating that the upload is successful, the middleware is configured to store the certificate identifier in the security authentication device and store the certificate file in the local cache of the middleware.
[0075] In the embodiment provided in the present application, the cloud service end receives 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 (CA) and sent to the security authentication device. The first device identity credential is generated by the security authentication device for the certificate upload application and sent to the middleware. The cloud service end verifies the received certificate upload application and the first device identity credential. If the verification passes, the cloud service end 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 service end based on the certificate file, which is used for subsequent certificate management and verification. The cloud service end 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.
[0076] 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.
[0077] According to the embodiment provided by the present application, the certificate upload application also includes a serial number and a first data generation time, and the method also includes: Refuse to store the certificate file if any of the following conditions are met: The conditions include: the first data generation time exceeds the predetermined time range; The serial number segment does not belong to the scheduled service range; The certificate file fails to pass the root file verification; The first device identity key generated by the key management system is called according to the serial number to verify the first device identity credential, and a verification result is obtained that the first device identity credential has not been verified; The first device identity credential is verified according to the second device identity key dispersed from the predetermined seed key and the serial number, and the verification result obtained is that the first device identity credential has not been verified.
[0078] In the embodiment provided in the present application, the method for the cloud service end to verify the certificate upload application and the first device identity credentials includes at least: verifying whether the "time of generating the data" is within the preset time range with the current time, and refusing the service if it does not meet the requirements; 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 refusing the service if it does not meet the requirements; using the root certificate of the certificate issuing authority (such as CA) (it can also be an intermediate certificate) to verify the legitimacy of the "certificate file", and refusing the service if it fails; calling the device identity key in the key management system KMS according to the serial number of the security authentication device, or dispersing the device identity key to verify the first device identity credentials, and refusing the service if it fails.
[0079] Among them, in the digital certificate system, the root certificate (Root Certificate) and the intermediate certificate (Intermediate Certificate) are the components of the certificate chain. The root certificate is the top-level certificate of the certificate chain, issued by the certificate authority (CA) itself, and is the basis of the entire trust chain. The intermediate certificate (Intermediate Certificate) is a certificate issued by the root certificate and is used to issue end-user certificates. The existence of intermediate certificates can reduce the burden of the root certificate and increase the flexibility of certificate issuance.
[0080] Exemplarily, after the cloud server receives a message containing the first device identity credential, the cloud server needs to retrieve the device identity key to verify the validity of the credential. The cloud server can obtain the device identity key in a variety of ways, and call the device identity key in the KMS (key management system) according to the SN (serial number) of the USBKey device. If the device identity key is not directly stored in the KMS, the cloud server can generate the device identity key through a key dispersion algorithm based on the seed key and the SN of the USBKey device.
[0081] For cloud servers, the following steps can be used to distribute certificates: 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; When the certificate distribution application and the identity credentials of the second device 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.
[0082] Exemplarily, the certificate distribution application further includes a serial number and a second data generation time, and the method further includes: Refuse to distribute the certificate file if any of the following conditions are met: The conditions include: the second data generation time exceeds the predetermined time range; The serial number segment does not belong to the scheduled service range; 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 the verification result is that the second device identity credential has not been verified; The second device identity credential is verified according to the second device identity key dispersed from the predetermined seed key and the serial number, and the verification result obtained is that the second device identity credential has not been verified.
[0083] 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 a preset time range with the current time, and refusing service if it does not match; 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 refusing service if it does not match; calling the device identity key in the key management system KMS according to the serial number of the security authentication device, or dispersing the device identity key, verifying the second device identity credentials, and refusing service if it fails.
[0084] If the execution subject is a cloud server, the following steps can be used to delete the certificate: 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; Deleting the certificate file when the certificate deletion request and the identity credentials of the third device are verified; The deletion result is sent 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.
[0085] 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 6 The 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 referred to as 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: a) [USBKey] Verify user permissions; b)[USBKey] Create a key container; c)[USBKey] Generate a key pair in the key container; d) [USBKey middleware] is used to assemble the certificate request to be signed using the generated public key; e) [USBKey] Sign the certificate request with the generated private key; f) [CA service] Verify the signed certificate request and issue the certificate file after verification; g) [Application] calls the import certificate interface of [USBKey middleware]; The following are targeted improvements to the optional implementation methods of this application: h) [USBKey middleware] generates a "certificate upload application" to be signed after receiving the certificate file; i) [USBKey] uses the "Device Identity Key" (i.e. the first Device Identity Key) to generate the "Device Identity Credentials" (i.e. the first Device Identity Credentials during the import process) for the "Certificate Upload Request"; j) [Certificate Distribution Cloud Service] Verify the "certificate upload application" and "device identity credentials"; if the verification is successful, extract the "certificate identifier" from the "certificate file" and store the "certificate file"; return a result response containing the "certificate identifier"; k) [USBKey middleware] receives and determines the result of certificate upload; if the operation is successful, stores the certificate file in the client's local cache and executes the next step; otherwise, the certificate distribution process fails; l)[USBKey] Store the certificate identity in the key container.
[0086] It can be understood that the above process is generally divided into three stages: Phase 1: Generate "certificate upload application" and "device identity credentials". [USBKey middleware] generates "certificate upload application" and calls [USBKey] to generate "device identity credentials". Phase 2: Certificate upload, [Certificate Cloud Distribution Service] verifies the "certificate upload application", stores the certificate file after verification, and returns the certificate identifier; The third stage: storing the certificate identifier, [USBKey] stores the certificate identifier in the key container in the device (rather than directly storing the certificate file in the prior art); [USBKey middleware] stores the certificate file in the local cache.
[0087] The above is the process of importing the signed certificate. For the process of importing the certificate file, after the application obtains the certificate file from the certificate authority, that is, after the above step g), for the application, the interactive interface (import certificate interface) with the USBKey middleware remains unchanged, the interactive logic remains unchanged, and the input and output remain unchanged. The security authentication device no longer stores the certificate file, and only manages the binding relationship between the certificate and the key pair.
[0088] Figure 7 A second timing 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.
[0089] a1) [Application] calls [USBKey middleware] to read the certificate interface; b1) [USBKey middleware] reads the key container information from [USBKey] and retrieves the “certificate identifier” of the target certificate; 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 (verifies the signature of the certificate file with the CA certificate); if the verification fails, deletes the local cache; if the verification passes, returns the certificate file to the [application], and the process ends; otherwise, continues; d1) [USBKey middleware] generates a "certificate distribution application"; and calls [USBKey] to use the "device identity key" to generate a "device identity credential" for the "certificate distribution application" (i.e., the second device identity credential during the reading and reissuing process); e1) [Certificate Distribution Cloud Service] Verify the "Certificate Distribution Application" and "Device Identity Credentials"; after verification, retrieve and return the corresponding "Certificate File"; f1) [USBKey middleware] stores the "certificate file" in the local cache with the "certificate identifier" as the index; g1) [USBKey middleware] returns the "certificate file" to [application].
[0090] The above is the process of reading and redistributing certificate files. For the application side, the interactive interface (certificate reading interface) with [USBKey middleware] remains unchanged, the interactive logic remains unchanged, and the input and output remain unchanged. It is possible to distribute certificate files online without going through USBKey. The certificate distribution cloud service only accepts certificate upload requests from legitimate USBKeys, and only accepts the distribution of the certificate by clients holding the USBKey used to upload the certificate. Implement the local certificate cache mechanism and certificate verification mechanism in the USBKey middleware to reduce the network interaction between the USBKey middleware and the certificate distribution cloud service while ensuring that the certificate is correctly available.
[0091] Figure 8 A third timing diagram of the certificate processing method of an embodiment of the present application is shown, Figure 8 As shown, a method for deleting a certificate from a USBKey is provided.
[0092] a2) [Application] calls [USBKey middleware] to delete the certificate interface; b2) [USBKey middleware] reads the key container information from [USBKey] and retrieves the “certificate identifier” of the target certificate; c2) [USBKey middleware] Search the local cache for the target certificate file using the "certificate identifier" as the index; if found, delete the certificate file in the local cache; d2) [USBKey middleware] generates a "certificate deletion application"; and calls [USBKey] to use the "device identity key" to generate a "device identity credential" (i.e., the third device identity credential in the deletion process) for the "certificate deletion application"; e2) [Certificate Distribution Cloud Service] Verify the "Certificate Deletion Request" and "Device Identity Credentials"; after verification, retrieve and delete the corresponding "Certificate File"; f2) [USBKey middleware] requests [USBKey] to delete the “certificate identifier” from the key container; g2) [USBKey middleware] returns the certificate deletion result to [application].
[0093] The above is the process of deleting the certificate file. For the application side, the interaction interface with [USBKey middleware] (certificate deletion interface) remains unchanged, the interaction logic remains unchanged, and the input and output remain unchanged.
[0094] In view of the large size of the anti-quantum cryptographic algorithm certificate, the optional implementation method provided by this application reduces the storage space required for the security authentication device to store the certificate under the premise of 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. After adopting the above processing method, only a dozen or dozens of bytes are required in the security authentication device (only the certificate DN is stored); it can alleviate the storage resource bottleneck of storage resource-constrained security authentication devices in anti-quantum cryptographic migration; Through any of the above processing methods, the certificate processing method provided by this optional implementation is transparent to the upper-layer application, and does not require the upper-layer application to make interface, data or process modifications. The certificate management interface of the USBKey middleware remains unchanged to the outside world, achieving backward compatibility. Only legitimate USBKey clients holding certificate private keys are allowed to upload certificates, and only clients holding corresponding USBKeys are allowed to distribute certificates, avoiding potential security attacks and privacy leakage risks; optimizing interface response performance and alleviating cloud service request pressure through local caching methods.
[0095] Fig. 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, which is applied to middleware, such as Fig. 9 As shown, including: The acquisition module 901 is used to obtain the certificate file issued by the certificate authority; The first processing module 902 is used to generate and send a certificate upload application to a 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; The first sending module 903 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 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; The first storage module 904 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 received upload result is that the upload is successful.
[0096] The functions of each module in each device in the embodiments of the present application can be found in the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.
[0097] Fig.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 also provides a certificate processing device, which is applied to a security authentication device, such as Fig.10 As shown, including: 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, 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 is 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 received that the upload is successful, and store the certificate file in the local cache of the middleware; The second storage module 1002 is used to receive and store the certificate identification.
[0098] Fig.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, which is applied to a cloud service end, such as Fig.11 As shown, including: The receiving module 1101 is used to receive 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; The third processing module 1102 is used to extract the certificate identifier based on the certificate file included in the certificate upload application and store the certificate file when the certificate upload application and the first device identity credential are verified to be passed; The second sending module 1103 is used to send the upload result including the certificate identifier to the middleware; when the upload result received 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.
[0099] Fig.12 FIG. 1 is a block diagram of an electronic device used to implement an embodiment of the present application. Fig.12 As shown, the electronic device includes: a memory 1201 and a processor 1202, and the memory 1201 stores a computer program that can be run on the processor 1202. When the processor 1202 executes the computer program, the method in the above embodiment is implemented. The number of the memory 1201 and the processor 1202 can be one or more. In a specific implementation, the electronic device may also include a communication interface 1203 for communicating with an external device and performing data exchange transmission.
[0100] In specific implementation, if the memory 1201, the processor 1202 and the communication interface 1203 are implemented independently, the memory 1201, the processor 1202 and the communication interface 1203 can be connected to each other through 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, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.12 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.
[0101] 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 can communicate with each other through an internal interface.
[0102] 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.
[0103] 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.
[0104] 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 by the embodiment of the present application.
[0105] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and 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.
[0106] It should be understood that the above processor 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, etc. It is worth noting that the processor may be a processor that supports the Advanced RISC Machines (ARM) architecture.
[0107] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of exemplary but not limiting description, 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 dynamic random access memory (SLDRAM) and direct memory bus random access memory (DR RAM).
[0108] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.
[0109] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means 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 one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.
[0110] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.
[0111] Any process or method described in the flow chart or otherwise described herein can be understood as a module, fragment or portion of a code representing one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiment of the present application includes other implementations, in which the functions may not be performed in the order shown or discussed, including in a substantially simultaneous manner or in a reverse order according to the functions involved.
[0112] The logic and / or steps described in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, which 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 an instruction execution system, apparatus or device and execute instructions), or used in combination with these instruction execution systems, apparatuses or devices.
[0113] It should be understood that the various parts of the present application can be implemented with hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented with 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, and when the program is executed, it includes one of the steps of the method embodiment or a combination thereof.
[0114] In addition, each functional unit in each embodiment of the present application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a disk or an optical disk, etc.
[0115] The above are only exemplary embodiments of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various changes or substitutions within the technical scope recorded in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope 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 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; When the received upload result is 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 to read the certificate file, acquiring 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; In the case where 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 in the local cache; 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 a second device identity credential to the middleware for the certificate distribution application; Sending the certificate distribution application and the second device identity credential to the cloud service end; the cloud service end is used to return the certificate file to the middleware when 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, characterized in that: 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 in the local cache; 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 a third device identity credential to the middleware for the certificate deletion application; Sending the certificate deletion application and the third device identity credential 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 credential are verified, and send the 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, 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, the middleware is used to send the certificate upload application and the first device identity credential to a 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, 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 received that the upload 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; In the case where the certificate upload application and the first device identity credential are verified to be passed, 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 receiving the upload result indicating that 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: If any of the following conditions are met, the storage of the certificate file is refused; The conditions include: the first data generation time exceeds a predetermined time range; The serial number segment does not belong to the scheduled service scope; 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 to verify the first device identity credential, and obtaining a verification result that the first device identity credential has not been verified; The first device identity credential is verified according to a second device identity key dispersed from a predetermined seed key and the serial number, and a verification result is obtained 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 any one of claims 1 to 8 is implemented.
Citation Information
Patent Citations
Digital-certificate-based cryptographic operation method and device
CN103152344A
Storing and downloading methods and system of third-party cloud storing platform
CN107872532A
Communication method and device, computer equipment and storage medium
CN114238916A
Security information storage method and device, electronic equipment and medium
CN116418501A
Decentralized Access Control for Cloud Services
US20190140848A1