Method and device for automatic life cycle management of digital certificate of internet of things equipment, terminal and storage medium

Abstract

The application discloses an automatic life cycle management method and device of an Internet of Things equipment digital certificate, a terminal and a storage medium, and relates to the technical field of Internet of Things security. The method comprises the following steps: in response to a certificate application request received through a target protocol, obtaining first state information and second state information of a target equipment; according to the first state information and the second state information, determining that a current application scenario is first application, certificate validity or reapplication; according to different current application scenarios, obtaining a certificate, binding the certificate with the equipment identity of the target equipment, and saving key materials of the certificate to cloud storage; in response to a material pulling request initiated by the target equipment successively, distributing the key materials to the target equipment by reusing the target protocol; and in response to a successful confirmation message returned by the target equipment, updating the application state of the target equipment to completed, and deleting the key materials in the cloud storage. The application realizes zero-contact automatic management of the Internet of Things equipment digital certificate.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security technology, and in particular to a method, apparatus, terminal, and storage medium for automatic lifecycle management of digital certificates for IoT devices. Background Technology

[0002] Currently, certificate management methods in large-scale IoT device deployments mainly include factory pre-programmed certificates, manual maintenance and certificate replacement, or centralized distribution relying on additional guidance channels.

[0003] In existing technologies, the method of relying on a dedicated boot link for certificate distribution requires the implementation of an independent communication protocol or interface on the device side, which increases the protocol complexity and system failure points on the device side.

[0004] In addition, when a device repeatedly requests a certificate due to network interruption, abnormal restart, or other reasons, the traditional method is prone to generating isolated certificates and binding residues. That is, the certificate issued and bound in the cloud is inconsistent with the certificate actually held by the device, resulting in wasted resources and abnormal access.

[0005] In addition, the certificate replacement process usually involves the associated operations of multiple cloud resource objects such as device identity objects and access policies. If the update operations of each resource object do not have atomicity or consistency guarantees, it is easy to have an inconsistent state where some resources have been updated and some resources have not been updated, which will cause the device to be unable to access the cloud normally during the replacement process.

[0006] Therefore, there is an urgent need for a method that can complete the entire lifecycle management of certificates without additional guidance links, so as to avoid resource residues and inconsistencies in status when the device applies for or replaces certificates repeatedly, and ensure the consistency of certificate status between the device and the cloud.

[0007] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0008] This invention provides an automatic lifecycle management method, device, terminal, and storage medium for digital certificates of Internet of Things (IoT) devices. It aims to solve the technical problems in the prior art, such as the complexity of the system caused by the reliance on additional bootstrapping links for certificate distribution, the tendency of repeated applications to generate isolated certificates and binding residues, and the inconsistency of state in cross-resource operations during the certificate replacement process.

[0009] A first aspect of the present invention provides an automatic lifecycle management method for digital certificates of Internet of Things (IoT) devices, comprising: In response to a certificate application request received via the target protocol, first status information and second status information of the target device are obtained; the first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials to be distributed corresponding to the target device in the cloud storage; Based on the first status information and the second status information, the current application scenario is determined to be either a first-time application, a certificate valid, or an application requiring reconstruction. If the current application scenario is the first application, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; If the current application scenario is the application that needs to be rebuilt, then the historical certificate of the target device is cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; In response to successive material retrieval requests initiated by the target device, the target protocol is reused to distribute the key material to the target device; In response to the success confirmation message returned by the target device, the application status of the target device is updated to completed, and the key material in the cloud storage is deleted.

[0010] A second aspect of the present invention provides a risk prediction device for primary Sjögren's syndrome complicated with interstitial lung disease, comprising: The status acquisition module is used to respond to a certificate application request received through the target protocol and acquire first status information and second status information of the target device; the first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials to be distributed corresponding to the target device in the cloud storage; The scenario confirmation module is used to determine, based on the first status information and the second status information, whether the current application scenario is a first-time application, a valid certificate, or an application that needs to be rebuilt. The scenario execution module is used to create a new certificate if the current application scenario is the first application, bind the new certificate to the device identity of the target device, and save the key material of the new certificate to cloud storage; If the current application scenario is the application that needs to be rebuilt, then the historical certificate of the target device is cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; The distribution module is used to respond to the material retrieval requests initiated by the target device one after another, and to distribute the key material to the target device by reusing the target protocol; The deletion module is used to update the application status of the target device to "completed" and delete the key material in the cloud storage in response to the successful confirmation message returned by the target device.

[0011] In a third aspect, embodiments of the present invention also provide a terminal device, wherein the terminal device includes a memory, a processor, and an automatic lifecycle management program for an IoT device digital certificate stored in the memory and executable on the processor. When the processor executes the automatic lifecycle management program for the IoT device digital certificate, it implements the steps of the automatic lifecycle management method for the IoT device digital certificate described in the above-described scheme.

[0012] In a fourth aspect, the present invention provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the automatic lifecycle management method for digital certificates of Internet of Things devices as described in any of the preceding claims.

[0013] Beneficial Effects: Compared with existing technologies, this invention provides an automatic lifecycle management method, apparatus, terminal, and storage medium for digital certificates of IoT devices. In the automatic lifecycle management method for digital certificates of IoT devices provided by this invention, firstly, in response to a certificate application request received through a target protocol, first and second status information of the target device are obtained; the first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials corresponding to the target device to be distributed in the cloud storage. Then, based on the first and second status information, it is determined whether the current application scenario is a first-time application, a valid certificate, or an application requiring reconstruction. If the current application scenario is a first-time application, a new certificate is created, and the new certificate is associated with the target device. The device identity is bound, and the key material of the new certificate is saved to cloud storage. If the current application scenario is an application that needs to be rebuilt, the historical certificates of the target device are cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage. Then, in response to the material retrieval requests initiated by the target device, the key material is distributed to the target device using the target protocol. Finally, in response to the success confirmation message returned by the target device, the application status of the target device is updated to completed, and the key material in the cloud storage is deleted. This invention provides users with an automatic lifecycle management method for digital certificates of IoT devices. By jointly determining the dual status based on the device identity binding status and the existence of temporary materials stored in the cloud, idempotent cleanup of historical certificates, reuse and distribute existing MQTT channels of the device, and temporarily store and delete certificate materials after confirmation, it solves the technical problems in the prior art, such as the system complexity caused by the reliance on additional bootstrapping links for certificate distribution, the tendency of repeated applications to generate isolated certificates and binding residues, and the tendency of inconsistent statuses in cross-resource operations during the certificate replacement process. It achieves zero-contact automated management of the entire lifecycle of IoT device certificates, effectively avoids resource residues and inconsistent statuses, and reduces the complexity of device-side protocols and the security risks of long-term exposure of certificate materials in the cloud. Attached Figure Description

[0014] Figure 1 A flowchart illustrating an embodiment of the automatic lifecycle management method for digital certificates of IoT devices provided by the present invention; Figure 2 A personalized processing flowchart for an embodiment of the automatic lifecycle management method for digital certificates of IoT devices provided by the present invention; Figure 3 A schematic diagram of the operating environment of an embodiment of the terminal provided by the present invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0016] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0017] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0018] Example 1 The automatic lifecycle management method for digital certificates of IoT devices provided in this embodiment can be executed by a terminal, which can be, but is not limited to, a smart computer, a smart mobile device, or a cloud server. The following description uses a cloud server as an example.

[0019] like Figure 1 As shown, the automatic lifecycle management method for digital certificates of IoT devices provided in this embodiment includes the following steps: S100. In response to a certificate application request received through the target protocol, obtain first status information and second status information of the target device; the first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials to be distributed corresponding to the target device in the cloud storage.

[0020] In this embodiment, the cloud server includes at least the following functional modules: an event processing module, as the core execution unit, is responsible for handling certificate application requests initiated by the device, determining the execution status, coordinating the creation and binding of certificates, and performing cleanup and confirmation of certificates. This module can be implemented by a serverless computing service, supporting on-demand elastic scaling without the need to reserve long-term computing resources.

[0021] The message channel module acts as a communication bridge between the device and the cloud, carrying all interactive messages between them. This includes certificate application requests initiated by the device, certificate material retrieval requests, success confirmation messages, and certificate materials returned by the cloud. This module is implemented based on the MQTT protocol, allowing the device to reuse its existing MQTT channel to complete all interactions without establishing additional communication links.

[0022] The object storage module is used for short-term temporary storage of certificate materials, including certificate files and private key files. This module supports devices to retrieve the temporary materials in segments and deletes them immediately after the device confirms successful receipt, avoiding the security risks caused by long-term exposure of certificate materials in the cloud.

[0023] Through the coordinated operation of the three modules mentioned above, the cloud server can manage the entire lifecycle of certificates in a stateless and scalable manner.

[0024] Specifically, the cloud server receives the certificate application request initiated by the target device through the target protocol. The target protocol is the communication protocol currently used by the device to access the cloud. In this embodiment, the target protocol is the MQTT protocol, and the certificate application request is a message based on the MQTT protocol.

[0025] In one optional implementation, the device and the cloud server exchange messages via the MQTT protocol. All messages carry a preset type identifier, which indicates the specific type of the message so that the cloud server can execute the corresponding processing logic according to the message type.

[0026] The triggering scenarios for this request include, but are not limited to, various situations such as the device's first power-on registration, the device requesting a reissue due to a lost or corrupted local certificate, and the device re-initiating an application because the previous round of certificate distribution was not completed due to a network interruption. After receiving the application request, the system does not immediately perform the certificate creation operation, but first obtains two types of status information of the target device as the basis for subsequent scenario determination.

[0027] The first status information indicates whether the target device has been bound to a valid certificate in the cloud. The system queries the identity management service on the cloud server to check whether the target device is currently associated with a usable and valid certificate. If the target device has been bound to a valid certificate, it indicates that the target device has completed at least one certificate registration process on the cloud server; if it has not been bound to a valid certificate, it indicates that the target device has never successfully completed a certificate application before, or that historical certificates have been cleared. The query result of this status information provides a key basis for subsequently determining the validity of the certificate and the scenarios where a certificate re-application is required.

[0028] The second status information indicates whether there are any certificate materials corresponding to the target device in the cloud server's storage. The system queries the cloud temporary storage service to check whether there are any certificate materials corresponding to the target device's current application. These certificate materials include certificate files and private key files. These materials are temporarily stored in the cloud storage after the system creates the certificate but before it is successfully retrieved by the device. If there are certificate materials to be distributed in the cloud storage, it means that the system has previously created a certificate for the device but has not yet received a successful confirmation message from the device; if there are no certificate materials to be distributed, it means that the device currently has no incomplete distribution tasks.

[0029] S200. Based on the first status information and the second status information, determine whether the current application scenario is a first-time application, a valid certificate, or an application that needs to be rebuilt.

[0030] Determining the current application scenario based on the first status information and the second status information includes: S210. If the first status information indicates that the target device is not bound to a valid certificate, and the second status information indicates that there are no certificate materials to be distributed in the cloud storage, then it is determined to be the first application. S220. If the first status information indicates that the target device has been bound to a valid certificate, and the second status information indicates that there are no certificate materials to be distributed in the cloud storage, then the certificate is determined to be valid. S230. If the first status information indicates that the target device has been bound to a valid certificate, and the second status information indicates that there are certificate materials to be distributed in the cloud storage, then it is determined that the application needs to be rebuilt.

[0031] Specifically, by jointly examining both the first and second state information, the system can accurately reconstruct the full picture of the target device's certificate status at the current moment. This dual-evidence determination method, based on the device identity binding status and the existence of temporary materials, effectively avoids potential misjudgments in distributed scenarios that may occur when relying on only a single information source, laying the foundation for subsequent accurate scenario classification.

[0032] The current application scenario is determined based on the first status information and the second status information, specifically including the following scenarios: If the first status information indicates that the target device is not bound to a valid certificate, and the second status information indicates that there are no certificate materials to be distributed in the cloud storage, then the current application scenario is determined to be the first application. This scenario indicates that the target device has never successfully completed certificate registration in the cloud, and there are currently no unfinished distribution tasks remaining. This usually corresponds to the scenario of the device being deployed for the first time upon power-on, that is, the device was not pre-programmed with any certificates when it left the factory, and the entire process of certificate application, issuance, binding, and distribution needs to be completed from scratch when it first connects to the cloud server.

[0033] If the first status information indicates that the target device has been bound to a valid certificate, and the second status information indicates that there are no certificate materials to be distributed in the cloud server's storage, then the current application scenario is determined to be a valid certificate. This scenario indicates that the target device already holds a valid certificate on the cloud server and is in a normal state, and there are no incomplete distribution tasks, meaning that the target device has previously successfully completed the entire certificate application process, and the current certificate is in an available state. The target device initiating a certificate application request in this scenario is usually due to a device-side mis-triggered request or a duplicate request caused by network jitter. After the system determines that the certificate is valid, it does not perform any certificate creation, cleanup, or distribution operations, and directly ends the current process, thereby avoiding unnecessary resource consumption and status changes.

[0034] If the first status information indicates that the target device has been bound to a valid certificate, and the second status information indicates that there are certificate materials to be distributed in the cloud storage, then the current application scenario is determined to be the application requiring reconstruction. This scenario indicates that although the target device has been bound to a valid certificate in the cloud, there is an incomplete certificate distribution task. That is, the system has previously created a new certificate for the device and stored the materials in the cloud storage, but has not yet received a successful confirmation message from the target device. This state may be caused by various abnormal situations, such as the target device experiencing a communication interruption during certificate distribution, the target device failing to successfully send back a confirmation message after receiving the certificate, or the target device failing to write the local certificate but the cloud status has been updated. In this scenario, if the materials to be distributed in the cloud storage are directly reused, it cannot be guaranteed that the materials are consistent with the currently bound certificate, and there may be a situation where the temporarily stored materials correspond to a historical certificate instead of the currently bound certificate. Therefore, the system directly determines the current application scenario as the application that needs to be rebuilt. That is, it first performs a cleanup operation on the historical certificate of the target device, including unbinding the device identity, unbinding the access policy, disabling the certificate, and deleting the certificate. Then, it creates a new certificate and re-executes the binding and distribution process to ensure that the certificate held by the target device is completely consistent with the certificate bound to the cloud.

[0035] The above three scenario classifications cover all possible state branches that the target device may encounter during the certificate lifecycle: the first application corresponds to the initial deployment scenario from scratch, the certificate being valid corresponds to the stable operation scenario where the status is normal and no operation is required, and the application requiring reconstruction corresponds to the fault recovery scenario where the status is abnormal and needs to be repaired. Through this refined scenario classification based on dual state information, the system can adopt differentiated processing strategies in different states, which avoids performing unnecessary certificate operations in the certificate being valid scenario, and ensures that the risk of state inconsistency is completely eliminated through a complete cleanup and reconstruction process in the reconstruction scenario.

[0036] S300. If the current application scenario is the first application, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage.

[0037] Specifically, when the current application scenario is determined to be the first application, it indicates that the target device has never been bound to a valid certificate in the cloud and there are no unfinished distribution tasks remaining. Therefore, the cloud server needs to create a completely new set of certificate materials for the target device from scratch.

[0038] Specifically, the cloud server first invokes the certificate issuance service to generate a new X.509 digital certificate for the target device. This certificate includes a certificate file, namely the public key certificate itself and the corresponding private key file. The certificate file contains the target device's identity information and the digital signature of the cloud certificate authority, which is used for identity verification when the target device accesses the cloud. The private key file is stored locally on the device and is used to prove that the target device owns the certificate.

[0039] Subsequently, the cloud server performs the binding operation between the certificate and the target device identity. In this embodiment, the device identity object of the cloud server is the Thing, which is a logical object in the cloud platform (such as AWS IoT Core) used to identify a physical device, and can be understood as the cloud-based digital twin identifier of the device. Each target device has its corresponding device identity object on the cloud server, which is used to associate all certificates and permission configurations of the target device. Specifically, the cloud server associates the newly created X.509 certificate with the Thing of the target device, making the certificate a valid credential recognized by the target device in the cloud. By binding the certificate to the Thing, when the device subsequently uses the certificate to connect to the cloud, the cloud can reverse look up the corresponding Thing through the certificate, thereby identifying the identity of the target device.

[0040] Furthermore, the cloud server also binds the certificate to a preset access policy. In this embodiment, the access policy defines the access permission scope corresponding to the certificate, specifically determining which MQTT topics the device can publish or subscribe to after accessing the cloud using the certificate. By binding the certificate to the policy, the cloud server completes both identity authentication and access control simultaneously when the target device accesses the cloud, without requiring additional authentication steps.

[0041] After completing the Thing and Policy bindings, the cloud server also saves the key materials of the new certificate to cloud storage. These key materials include at least the certificate file and the private key file. Cloud storage is a temporary storage service; the certificate materials it stores are only used for subsequent device retrieval and will be deleted immediately after successful device confirmation. In this embodiment, the temporary storage materials can be set with an expiration period. If a successful confirmation message from the device is not received within the preset expiration period, the temporary storage materials will expire, and the device will need to re-initiate a certificate application to trigger a new certificate reconstruction process. In this embodiment, the preset expiration period is 5 to 10 minutes. In more embodiments, a shorter expiration period can be selected for high security requirements, and a longer expiration period can be selected for scenarios with poor network conditions.

[0042] By temporarily storing key materials in the cloud instead of pushing them directly through the message channel, the device can retrieve certificate materials in stages and steps even under unstable network conditions, improving the reliability and flexibility of certificate distribution. Meanwhile, cloud storage, as a temporary storage medium independent of core business services, also facilitates troubleshooting and recovery in case of distribution anomalies.

[0043] Furthermore, in more implementations, after the cloud server completes the binding of the new certificate to the Thing, it also records the application status of the target device as "bound". This application status flag is used to characterize the current stage of the certificate application process so as to accurately track the progress of the process in subsequent steps. The application status flag includes at least two states: "bound" and "completed". "Bound" indicates that the certificate has been successfully created and associated with the Thing, but a successful confirmation has not yet been received from the device; "completed" indicates that the device has sent back a successful confirmation message, and this round of certificate lifecycle management process has been completed.

[0044] Through the above steps, the target device obtains complete certificate materials in the first application scenario, and the binding relationship between the certificate and the Thing, as well as the permission association of the Policy, have been established in the cloud, which prepares the target device to use the certificate to access the cloud in the future.

[0045] S400. If the current application scenario is the application that needs to be rebuilt, then perform a cleanup operation on the historical certificate of the target device, create a new certificate, bind the new certificate to the device identity of the target device, and save the key material of the new certificate to cloud storage. The step of cleaning up the historical certificates of the target device includes: In reverse order of resource dependencies, the steps of unbinding the historical certificate from the device identity of the target device, unbinding the historical certificate from the access policy, disabling the historical certificate, and deleting the historical certificate are executed sequentially. Each step can be called repeatedly, and if a single step fails, the reason for the failure is recorded and a retry is initiated.

[0046] After creating the new certificate and binding the new certificate to the device identity of the target device, the process further includes: Mark the application status of the target device as "bound"; In response to the success confirmation message returned by the target device, the application status flag of the target device is updated from "bound" to "completed".

[0047] Specifically, when the current application scenario is determined to be an application requiring reconstruction, it indicates that the target device has already bound a valid certificate in the cloud, but there are incomplete distribution tasks, meaning that there are certificate materials to be distributed in the cloud storage. This state is usually caused by abnormal situations such as communication interruption during the certificate distribution process, failure of the device to successfully send back a confirmation message after receiving the certificate, or failure to write the local certificate on the device but the cloud status has been updated. In this scenario, if the materials to be distributed in the cloud storage are directly reused, it cannot be guaranteed that the materials are consistent with the currently bound certificate, and there may be a situation where the temporarily stored materials correspond to a historical certificate instead of the currently bound certificate. Therefore, the cloud server needs to first perform a complete cleanup operation on the historical certificates of the target device, then create a new certificate and re-execute the binding and distribution process to ensure that the certificate ultimately held by the device is completely consistent with the certificate bound in the cloud.

[0048] In this implementation, performing a cleanup operation on the historical certificates of the target device is one of the core mechanisms for achieving idempotency and zero resource residue. Specifically, the cleanup operation includes the following steps: First, the cloud server performs the step of unbinding the historical certificate from the target device's device identity. In this embodiment, the device identity, or Thing, is a logical object used in the cloud platform to identify a physical device. The binding relationship between the certificate and the Thing is a prerequisite for the device to use the certificate to access the cloud. After unbinding, the historical certificate will no longer serve as a valid credential for the device identity.

[0049] Secondly, the cloud server performs the step of unbinding historical certificates from access policies. In this embodiment, the access policy defines the scope of operational permissions that the device corresponding to the certificate can perform, such as which MQTT topics are allowed to be published or subscribed to. The binding relationship between the certificate and the policy is established synchronously after the certificate is bound to the Thing, so this permission association must be unbound first during cleanup.

[0050] Next, the cloud server performs the deactivation step for historical certificates. Deactivating a certificate means marking its status as unavailable in the cloud. After a certificate is deactivated, even if it is still associated with a device identity or access policy, the cloud will refuse connection requests established using that certificate. This two-step design of deactivating before deleting quickly blocks the certificate's access capabilities before the deletion operation is performed, improving the security of the cleanup process.

[0051] Finally, the cloud server performs the deletion of the historical certificate. This deletion operation permanently removes all records of the historical certificate from the cloud, completely releasing the resources occupied by the certificate.

[0052] By using the above reverse cleanup method, the cloud server ensures that the four steps of device identity unbinding, access policy unbinding, certificate deactivation, and certificate deletion are strictly executed in reverse order according to the resource dependency relationship, avoiding cleanup failure or resource residue due to improper order.

[0053] Furthermore, each step in the historical certificate cleanup operation for the target device is configured as an idempotent operation, meaning it allows repeated calls, with each repeated call returning a success status immediately. If a single step fails, the cloud server records the reason for the failure and initiates a retry, waiting for the target device to next request a certificate before re-entering the cleanup operation. This idempotent design ensures that even if network jitter or temporary service unavailability occurs during the cleanup process, repeated execution will not result in additional resource residues, invalid resources, redundant resources, invalid records, uncleaned residual resources, or error states.

[0054] After cleaning up historical certificates, the cloud server creates a new certificate and binds it to the Thing on the target device, while also associating it with the Policy. The cloud server also saves the key materials of the new certificate to cloud storage; these materials include the certificate file and the private key file, for subsequent retrieval by the target device.

[0055] Furthermore, after completing the binding of the new certificate with the Thing, the cloud server also records the application status of the target device as "bound". This application status flag is used to characterize the current stage of the certificate application process, so as to accurately track the progress of the process in subsequent steps. When the cloud server subsequently receives a success confirmation message from the target device, it updates the application status flag of the target device from "bound" to "completed". This status flag transition constitutes the two-stage binding mechanism in this embodiment: the first stage is the resource binding stage, that is, completing the binding of the certificate with the Thing and Policy, and writing the "bound" status flag; the second stage is the availability confirmation stage, that is, only when the device sends back a success confirmation message is the application marked as the final completed state. Through the above two-stage binding mechanism, the cloud server can clearly distinguish between the two states: the certificate has been created and bound but has not yet been distributed, and the certificate has been distributed and is available for normal use by the device. This facilitates accurate process recovery when the device re-enters, and avoids problems such as duplicate certificate creation or inconsistent status.

[0056] Through the above steps, the target device completes the idempotent cleanup of historical certificates, the creation and binding of new certificates, and the updating of application status markings in the scenario where application needs to be rebuilt, thus preparing for subsequent distribution steps.

[0057] S500: In response to the material retrieval requests initiated sequentially by the target device, the target protocol is reused to distribute the key material to the target device; The step of responding to successive material retrieval requests initiated by the target device by reusing the target protocol to distribute the key material to the target device specifically includes: In response to the certificate material retrieval request initiated by the target device, the certificate file in the key material is sent to the target device through the target protocol; In response to a private key material retrieval request initiated by the target device, the private key file in the key material is sent to the target device via the target protocol.

[0058] After the certificate is created and the key material is saved to the cloud storage, but before the target device returns the success confirmation message to the cloud, if the target device experiences a communication interruption and initiates a certificate application request again, then based on the first status information and the second status information, if it is determined that there is still key material to be distributed corresponding to the target device in the cloud storage, there is no need to repeat the creation of a new certificate and the binding with the device identity of the target device. Instead, the key material is directly obtained from the cloud storage and distributed to the target device.

[0059] The target protocol is the MQTT protocol. The certificate application request and the material retrieval request are both MQTT protocol-based messages. The key material is sent back to the target device via the MQTT protocol.

[0060] Specifically, after the cloud server completes the creation of the new certificate, the binding of its identity to the target device, and the storage of the key materials in the cloud, the cloud server waits for the target device to actively initiate a material retrieval request to obtain the certificate materials. After initiating a certificate application request, or after receiving a notification from the cloud server that the certificate is ready, the target device initiates material retrieval requests sequentially according to its actual needs. In response to the sequential material retrieval requests initiated by the target device, the cloud server reuses the target protocol as a distribution channel to distribute the key materials to the target device. The aforementioned target protocol is the communication protocol currently used by the target device to access the cloud, and it is also the same protocol used when the device previously initiated certificate application requests.

[0061] Specifically, the aforementioned material retrieval requests include at least two types: certificate material retrieval requests and private key material retrieval requests. In response to a certificate material retrieval request initiated by the target device, the cloud server sends the certificate file from the key material to the target device via the target protocol. After successfully receiving the certificate file, the target device initiates a private key material retrieval request. In response to this request, the cloud server sends the private key file from the key material to the target device via the target protocol. By separating the certificate file and private key file into two independent messages for retrieval and distribution, the device does not need to carry excessively large amounts of data in a single transmission, which is beneficial for reliably completing the distribution process in low-bandwidth or unstable network environments.

[0062] In this embodiment, the target protocol is the MQTT protocol. Both the certificate application request and the material retrieval request are MQTT-based messages, and the key materials are sent back to the target device via the MQTT protocol. The device can complete the entire process of certificate application, material retrieval, and confirmation return by reusing its existing MQTT channel, without the need to implement an additional HTTP interface or other dedicated bootstrap protocols, effectively reducing the protocol complexity on the device side.

[0063] Furthermore, during the distribution process, there may be scenarios where the device re-initiates the application after communication interruption. Specifically, after the certificate is created and the key materials are saved to cloud storage, but before the target device returns a success confirmation message to the cloud, if the target device experiences a communication interruption and re-initiates a certificate application request, the cloud server will make a determination based on the first and second status information. Since the key materials corresponding to the target device still exist in the cloud storage, it indicates that the device's certificate has been created but not yet successfully confirmed. Therefore, the cloud server does not need to repeat the creation of a new certificate and the binding of the device identity with the target device, but directly retrieves the key materials from the cloud storage and distributes them to the target device. Through the above-mentioned breakpoint resumption mechanism, when the device re-initiates the request after communication interruption, it does not need to start the complete certificate creation and binding process from scratch, but directly retrieves the existing key materials from the cloud storage and continues to complete the distribution, effectively shortening the anomaly recovery time and improving the fault tolerance of the certificate distribution process.

[0064] In one application example, the specific interaction information is shown in Table 1.

[0065] Table 1:

[0066] Referring to Table 1, the first type of message is a certificate request message. The device sets the message type identifier to the first preset value, 003 ask, and then sends it to the cloud server via the MQTT protocol to initiate a certificate request to the cloud. Upon receiving the message, the cloud server triggers the certificate lifecycle management process. In this embodiment, the certificate lifecycle management process refers to the complete process from the cloud server receiving the device's certificate request to the device successfully obtaining the certificate and completing the confirmation, and the cloud clearing temporary materials. This process covers the unified scheduling and management of all aspects of the device certificate, including creation, binding, distribution, and cleanup and reconstruction in abnormal scenarios.

[0067] Referring back to Table 1, the second type of message is the certificate file retrieval request message. The device sets the message type identifier to a second preset value, such as 004 crt, and then sends it to the cloud server via the MQTT protocol to request the certificate file from the cloud. This message is typically initiated by the device after the cloud server has completed certificate creation and notified the device that the certificate materials can be retrieved. Upon receiving this message, the cloud server sends the certificate file back to the device via the MQTT protocol.

[0068] The third type of message is the private key file retrieval request message. The device sets the message type identifier to a third preset value, such as 004 key, and then sends it to the cloud server via the MQTT protocol to request the private key file from the cloud. Similar to the certificate file retrieval request, this message is initiated by the device after the certificate is created. Upon receiving this message, the cloud server sends the private key file back to the device via the MQTT protocol.

[0069] It should be noted that the certificate file retrieval request and the private key file retrieval request share the same message type identifier, such as 004. The cloud server can distinguish them based on differences in message content or subtype identifiers within the message. The device can initiate the certificate file retrieval request first, and then initiate the private key file retrieval request after receiving the certificate file, or it can retrieve the two types of materials separately in other orders. By retrieving the certificate materials and private key materials in two separate steps, the device can complete the acquisition of certificate materials in stages, reducing the data volume of a single message transmission and facilitating reliable distribution in low-bandwidth or unstable network environments.

[0070] The fourth type of message is a success confirmation message. The device sets the message type identifier to the fourth preset value, such as 004success, and sends it to the cloud server via the MQTT protocol to notify the cloud server that the device has successfully received the complete certificate materials, including the certificate file and private key file. After receiving the success confirmation message, the cloud server updates the device's application status to "completed," deletes the temporarily stored certificate materials in the cloud storage, and ends this round of certificate lifecycle management process.

[0071] Based on the definitions of the four message types mentioned above, a complete and clear certificate application and distribution interaction protocol is formed between the device and the cloud server. The device only needs to reuse its existing MQTT channel to complete the entire process of certificate application, material retrieval, and confirmation return, without having to implement any additional communication protocols or bootstrap interfaces, effectively reducing the protocol complexity on the device side.

[0072] S600: In response to the success confirmation message returned by the target device, update the application status of the target device to "completed" and delete the key material in the cloud storage.

[0073] After the cloud server sends the certificate file and private key file to the target device via the target protocol, the target device receives and stores the certificate materials locally. Once the target device confirms that it has successfully received the complete certificate materials, it returns a success confirmation message to the cloud server via the target protocol.

[0074] In response to the received success confirmation message, the cloud server first updates the application status flag of the target device to "completed." Specifically, after completing the binding of the certificate with the device identity of the target device, the cloud server has recorded the application status flag as "bound," indicating that the certificate has been successfully created and associated with the device identity, but has not yet received successful confirmation from the device. In this step, the cloud server updates the application status flag from "bound" to "completed," indicating that this round of certificate lifecycle management process has been completed, the device has successfully obtained the certificate, and can use the certificate to access the cloud normally.

[0075] Simultaneously, in response to the received success confirmation message, the cloud server deletes the key materials from the cloud storage. Since the target device has successfully received the complete certificate materials, the temporarily stored certificate and private key files in the cloud storage are no longer needed, and the cloud server permanently deletes them from the cloud storage. By promptly deleting the temporarily stored materials, the security risks caused by the long-term exposure of certificate materials in cloud storage are avoided, while also freeing up storage resources.

[0076] This concludes the certificate lifecycle management process described in this round. The target device has successfully obtained the certificate, and the cloud has completed the status update and temporary storage cleanup. The target device can subsequently use this certificate to access the cloud. If the target device fails to return a success confirmation message during the distribution process, the cloud server will retain the key materials in cloud storage for the device to use when it re-initiates a retrieval request after communication is restored. If no success confirmation message is received after the preset validity period, the key materials in cloud storage will expire, and the device will need to re-trigger the complete certificate lifecycle management process on the next application.

[0077] The implementation process of this method is illustrated below with examples from three typical application scenarios.

[0078] In application example one, the registration is performed upon initial power-on.

[0079] Specifically, the device is not pre-programmed with any certificates at the factory. Upon initial power-on and connection to the cloud, it automatically initiates a certificate request. Upon receiving the request, the cloud server confirms it's the first application and then performs certificate creation, binding with the device's identity, and temporary storage of key materials, while waiting for the device to retrieve the certificate and private key files sequentially. After successfully receiving the complete certificate materials, the device sends back a success confirmation message, and the cloud server updates the application status to "completed" and deletes the temporary materials. The entire process requires no manual intervention; the device automatically completes the certificate acquisition and binding.

[0080] In application example two, the device is repeatedly requested.

[0081] Specifically, if a device initiates a certificate request again after successfully obtaining a certificate due to network jitter or software malfunction, the cloud server, upon receiving the request, checks that the device is already bound to a valid certificate and that there are no materials to be distributed in the cloud storage. Determining this as a valid certificate scenario, the server terminates the process directly without performing any certificate creation or distribution operations. However, if the certificate distribution process is interrupted, resulting in materials to be distributed in the cloud storage, the cloud server determines that a re-application scenario is required. It first performs idempotent cleanup of historical certificates, then recreates the new certificate and redistributes it, ensuring that no orphaned certificates or invalid bindings remain after each application.

[0082] In Application Example 3, a retry is performed to address a distribution interruption. A communication interruption occurs during the device's retrieval of certificate materials, resulting in some materials not being successfully received. After reconnecting to the cloud, the device initiates another certificate request. The cloud server, after status assessment, finds that the device is already bound to a valid certificate and that the materials to be distributed exist in cloud storage. It determines that the application scenario needs to be rebuilt, performs historical certificate cleanup, creates a new certificate, and redistributes it, ensuring that the device ultimately obtains a complete and valid certificate consistent with the one in the cloud.

[0083] As can be seen, this embodiment achieves zero-contact deployment of IoT device certificates. After the device is powered on, the entire process of certificate application, acquisition, and installation can be automatically completed without any manual intervention, significantly reducing operation and maintenance costs and on-site maintenance workload in large-scale device deployment scenarios. Simultaneously, through end-to-end idempotent design, isolated certificates and resource residues are effectively avoided. In various abnormal scenarios such as duplicate device applications, distribution interruption re-entry, and cleanup operation failure retries, the system can ensure the consistency of the final state through idempotent operations, preventing the accumulation of redundant certificates or invalid binding relationships due to repeated requests. Furthermore, the distribution of certificate materials is completed by reusing the device's existing MQTT channel, eliminating the need to establish additional HTTP bootstrap interfaces or other dedicated communication links for certificate management. This effectively reduces the protocol complexity on the device side and reduces the overall system failure points, making it particularly suitable for resource-constrained IoT devices. Even further, by temporarily storing certificate materials in cloud storage and immediately deleting them after successful device confirmation of receipt, the exposure time of the certificate private key in the cloud is effectively shortened, reducing the security risk of private key interception or leakage and improving the security and compliance of the certificate management process.

[0084] In summary, this embodiment provides an automatic lifecycle management method for digital certificates of IoT devices. First, in response to a certificate application request received via a target protocol, first and second status information of the target device are obtained. The first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials corresponding to the target device in the cloud storage. Then, based on the first and second status information, it is determined whether the current application scenario is a first-time application, a valid certificate, or an application requiring reconstruction. If the current application scenario is a first-time application, a new certificate is created, and the new certificate is associated with the target device. The device identity of the target device is bound, and the key material of the new certificate is saved to cloud storage. If the current application scenario is an application that needs to be rebuilt, the historical certificate of the target device is cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage. Then, in response to the material retrieval requests initiated by the target device one after another, the target protocol is reused to distribute the key material to the target device. Finally, in response to the success confirmation message returned by the target device, the application status of the target device is updated to completed, and the key material in the cloud storage is deleted. This embodiment provides users with an automatic lifecycle management method for digital certificates of IoT devices. By jointly determining the dual status based on the device identity binding status and the existence of temporary materials stored in the cloud, idempotent cleanup of historical certificates, reuse and distribute existing MQTT channels of the device, and temporarily store and delete certificate materials after confirmation, it solves the technical problems in the prior art, such as the system complexity caused by the reliance on additional bootstrapping links for certificate distribution, the tendency of repeated applications to generate isolated certificates and binding residues, and the tendency of inconsistent statuses in cross-resource operations during the certificate replacement process. It realizes zero-contact automated management of the entire lifecycle of IoT device certificates, effectively avoids resource residues and inconsistent statuses, and reduces the complexity of device-side protocols and the security risks of long-term exposure of certificate materials in the cloud.

[0085] It should be understood that although the steps in the flowcharts shown in the accompanying drawings are displayed sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of the steps in this invention, and these steps can be executed in other orders. Moreover, at least a portion of the steps in this invention may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0086] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program using signal-related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0087] Example 2 Based on the above embodiments, the present invention also provides a risk prediction device for primary Sjögren's syndrome complicated with interstitial lung disease, such as... Figure 2 As shown, the risk prediction device for primary Sjögren's syndrome complicated with interstitial lung disease includes: The status acquisition module is used to respond to a certificate application request received through the target protocol and acquire first status information and second status information of the target device; the first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials to be distributed corresponding to the target device in the cloud storage, as described in Embodiment 1. The scenario confirmation module is used to determine, based on the first status information and the second status information, whether the current application scenario is a first-time application, a valid certificate, or an application that needs to be rebuilt, as described in Embodiment 1. The scenario execution module is used to create a new certificate if the current application scenario is the first application, bind the new certificate to the device identity of the target device, and save the key material of the new certificate to cloud storage; If the current application scenario is the application that needs to be rebuilt, then the historical certificate of the target device is cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage, as described in Embodiment 1; The distribution module is used to respond to the material retrieval requests initiated by the target device one after another, and to distribute the key material to the target device by reusing the target protocol, as specifically described in Embodiment 1; The deletion module is used to update the application status of the target device to "completed" in response to the successful confirmation message returned by the target device, and delete the key material in the cloud storage, as specifically described in Embodiment 1.

[0088] Example 3 like Figure 3 As shown, based on the above-mentioned automatic lifecycle management method for digital certificates of IoT devices, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 3 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0089] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard drive or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard drive, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores an automatic lifecycle management program 40 for IoT device digital certificates, which can be executed by the processor 10 to implement the automatic lifecycle management method for IoT device digital certificates in this application.

[0090] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing an automatic lifecycle management method for the digital certificate of the Internet of Things device.

[0091] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The components 10-30 of the terminal communicate with each other via a system bus.

[0092] In one embodiment, when the processor 10 executes the automatic lifecycle management program 40 for the digital certificate of the Internet of Things device in the memory 20, the following steps are performed: In response to a certificate application request received via the target protocol, first status information and second status information of the target device are obtained; the first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials to be distributed corresponding to the target device in the cloud storage; Based on the first status information and the second status information, the current application scenario is determined to be either a first-time application, a certificate valid, or an application requiring reconstruction. If the current application scenario is the first application, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; If the current application scenario is the application that needs to be rebuilt, then the historical certificate of the target device is cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; In response to successive material retrieval requests initiated by the target device, the target protocol is reused to distribute the key material to the target device; In response to the success confirmation message returned by the target device, the application status of the target device is updated to completed, and the key material in the cloud storage is deleted.

[0093] Example 4 The present invention also provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the automatic lifecycle management method for digital certificates of Internet of Things devices as described above.

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

Claims

1. A method for automatic lifecycle management of digital certificates for Internet of Things (IoT) devices, characterized in that, include: In response to a certificate request received via the target protocol, the first and second status information of the target device are obtained. The first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials to be distributed corresponding to the target device in the cloud storage; Based on the first status information and the second status information, the current application scenario is determined to be either a first-time application, a certificate valid, or an application requiring reconstruction. If the current application scenario is the first application, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; If the current application scenario is the application that needs to be rebuilt, then the historical certificate of the target device is cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; In response to successive material retrieval requests initiated by the target device, the target protocol is reused to distribute the key material to the target device; In response to the success confirmation message returned by the target device, the application status of the target device is updated to completed, and the key material in the cloud storage is deleted.

2. The automatic lifecycle management method for digital certificates of IoT devices according to claim 1, characterized in that, Determining the current application scenario based on the first status information and the second status information includes: If the first status information indicates that the target device is not bound to a valid certificate, and the second status information indicates that there are no certificate materials to be distributed in the cloud storage, then it is determined to be the first application; If the first status information indicates that the target device has been bound to a valid certificate, and the second status information indicates that there are no certificate materials to be distributed in the cloud storage, then the certificate is determined to be valid. If the first status information indicates that the target device has been bound to a valid certificate, and the second status information indicates that there are certificate materials to be distributed in the cloud storage, then it is determined that the application needs to be rebuilt.

3. The automatic lifecycle management method for digital certificates of IoT devices according to claim 1, characterized in that, The step of cleaning up the historical certificates of the target device includes: In reverse order of resource dependencies, the steps of unbinding the historical certificate from the device identity of the target device, unbinding the historical certificate from the access policy, disabling the historical certificate, and deleting the historical certificate are executed sequentially. Each step can be called repeatedly, and if a single step fails, the reason for the failure is recorded and a retry is initiated.

4. The automatic lifecycle management method for digital certificates of IoT devices according to claim 1, characterized in that, After creating the new certificate and binding the new certificate to the device identity of the target device, the process further includes: Mark the application status of the target device as "bound"; In response to the success confirmation message returned by the target device, the application status flag of the target device is updated from "bound" to "completed".

5. The automatic lifecycle management method for digital certificates of IoT devices according to claim 1, characterized in that, The step of responding to successive material retrieval requests initiated by the target device by reusing the target protocol to distribute the key material to the target device specifically includes: In response to the certificate material retrieval request initiated by the target device, the certificate file in the key material is sent to the target device through the target protocol; In response to a private key material retrieval request initiated by the target device, the private key file in the key material is sent to the target device via the target protocol.

6. The automatic lifecycle management method for digital certificates of IoT devices according to claim 1, characterized in that, After the certificate is created and the key material is saved to the cloud storage, but before the target device returns the success confirmation message to the cloud, if the target device experiences a communication interruption and initiates a certificate application request again, then based on the first status information and the second status information, if it is determined that there is still key material to be distributed corresponding to the target device in the cloud storage, there is no need to repeat the creation of a new certificate and the binding with the device identity of the target device. Instead, the key material is directly obtained from the cloud storage and distributed to the target device.

7. The automatic lifecycle management method for digital certificates of IoT devices according to claim 1, characterized in that, The target protocol is the MQTT protocol. The certificate application request and the material retrieval request are both MQTT protocol-based messages. The key material is sent back to the target device via the MQTT protocol.

8. An automatic lifecycle management device for digital certificates of Internet of Things (IoT) devices, characterized in that, include: The status acquisition module is used to acquire the first status information and the second status information of the target device in response to a certificate application request received through the target protocol. The first status information indicates whether the target device has been bound to a valid certificate in the cloud, and the second status information indicates whether there are certificate materials to be distributed corresponding to the target device in the cloud storage; The scenario confirmation module is used to determine, based on the first status information and the second status information, whether the current application scenario is a first-time application, a valid certificate, or an application that needs to be rebuilt. The scenario execution module is used to create a new certificate if the current application scenario is the first application, bind the new certificate to the device identity of the target device, and save the key material of the new certificate to cloud storage; If the current application scenario is the application that needs to be rebuilt, then the historical certificate of the target device is cleaned up, a new certificate is created, the new certificate is bound to the device identity of the target device, and the key material of the new certificate is saved to cloud storage; The distribution module is used to respond to the material retrieval requests initiated by the target device one after another, and to distribute the key material to the target device by reusing the target protocol; The deletion module is used to update the application status of the target device to "completed" and delete the key material in the cloud storage in response to the successful confirmation message returned by the target device.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and an automatic lifecycle management program for IoT device digital certificates stored in the memory and executable on the processor. When the automatic lifecycle management program for IoT device digital certificates is executed by the processor, it implements the steps of the automatic lifecycle management method for IoT device digital certificates as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps of the automatic lifecycle management method for digital certificates of Internet of Things devices as described in any one of claims 1-7.

Images