An internet of things device communication method and electronic device

Abstract

The application relates to an Internet of Things device communication method and an electronic device. The method comprises the following steps: in response to a communication request sent by an edge communication device, extracting a local credential in the communication request, and obtaining a collaborative authentication credential stored in a cloud server; the communication request is generated by an Internet of Things device; based on the collaborative authentication credential, the local credential is verified to obtain a verification result; in the case that the verification result is verified, a request response signal is generated, and the request response signal is sent to the edge communication device; wherein the request response signal is used to generate a communication channel between the Internet of Things device and the cloud server. Compared with a traditional scheme, the above method can improve the security and reliability of access authentication between the Internet of Things device and the server to a certain extent.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, specifically to an IoT device communication method and electronic device. Background Technology

[0002] With the rapid popularization of smart cockpit scenarios in vehicles, in-vehicle IoT devices exhibit core characteristics such as distributed deployment, high requirements for low latency, complex network environments (network fluctuations due to high-speed movement, offline scenarios such as tunnels / underground parking garages), and limited device power consumption. These characteristics place stringent demands on the real-time performance, offline availability, security, and lightweight adaptability of the authentication system. Traditional IoT device access authentication primarily relies on the communication channel established at the factory between the IoT device and the server. When unauthorized devices steal the device identifiers of legitimate IoT devices, it can lead to risks such as server data leakage, unstable communication of legitimate IoT devices, or even forced deregistration. This makes the current access authentication between IoT devices and servers inherently unsecured and unreliable. Summary of the Invention

[0003] This application provides an IoT device communication method, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0004] In a first aspect, embodiments of this application provide a communication method for Internet of Things (IoT) devices, the method comprising: In response to a communication request sent by an edge communication device, the local credentials in the communication request are extracted, and the collaborative authentication credentials stored in the cloud server are obtained; the communication request is generated by the IoT device. Based on collaborative authentication credentials, the local credentials are verified to obtain the verification result; If the verification result is successful, a request-response signal is generated and sent to the edge communication device. The request-response signal is used to generate a communication channel between IoT devices and cloud servers.

[0005] Based on the aforementioned technical means, the cloud server can verify the local credentials in the communication requests generated by IoT devices based on the collaborative authentication credentials stored internally. After successful verification, it can generate a request-response signal, enabling the edge communication device directly connected to the IoT device to establish a communication channel between the IoT device and the cloud server. This allows the cloud server to verify the IoT device when it generates a communication request, and to establish a communication channel between the IoT device and the cloud server after successful verification. Since the communication channel is not always present but is only generated after successful verification, this method can improve the security and reliability of access authentication between IoT devices and servers to a certain extent compared to traditional solutions.

[0006] Furthermore, based on the collaborative authentication credentials, the local credentials are verified to obtain the verification results, including: Retrieve the local verification credential and derived credential from the collaborative authentication credentials; Perform expiration verification on derived documents and local documents to obtain the expiration verification results; If the deadline verification result indicates that the deadline verification has passed, the validity of the local verification certificate is verified based on the local verification certificate to obtain the verification result.

[0007] Based on the aforementioned technical means, the local credentials can be validated for both their expiration and validity based on the local and derived credentials stored in the collaborative authentication credentials on the cloud server. This results in a two-tiered validation path consisting of expiration and validity validation, which can improve the accuracy and reliability of the final validation results to some extent.

[0008] Furthermore, the derived documents and local documents are subjected to expiration verification to obtain the expiration verification results, including: Determine the first remaining validity period of the local document and the second remaining validity period of the derived document; If both the first remaining valid duration and the second remaining valid duration are greater than or equal to the preset duration threshold, the duration verification result is determined to be passed. Based on the locally verified credentials, the validity of the local credentials is validated, and the validation results are obtained, including: The local verification credentials are matched and verified to obtain the matching results. If the matching result indicates that there is a target credential identical to the local credential in the local verification credentials, and there is no historical verification success information for the local credential in the cloud server, then the verification result is determined to be successful.

[0009] Based on the aforementioned technical means, the expiration verification result of the local certificate can be determined according to the remaining validity period of the derived certificate and the local certificate. After the expiration verification passes, the corresponding verification result can be obtained based on the matching result of the local verification certificate and the local certificate. Since the remaining validity period of the derived certificate stored on the cloud server is used, the local certificate is considered valid only when the remaining validity period indicates that the derived certificate has not expired, which can improve the accuracy of the expiration verification result to a certain extent. At the same time, by matching the local verification certificate with the local certificate, a matching result is obtained. When the matching result is successful, it indicates that the local certificate is a valid certificate issued by the cloud server. When the matching result is unsuccessful, it indicates that the local certificate is a forged certificate generated by the IoT device itself. That is, the matching result can determine whether the local certificate is issued by the cloud server or generated by the IoT device itself, which can improve the accuracy and reliability of the final verification result to a certain extent.

[0010] Furthermore, the method also includes: If the matching result indicates that there is no target credential identical to the local credential in the local verification credential, or if there is historical verification success information in the cloud server, then the verification result is determined to be unsuccessful. Send a credential revocation command to the edge communication device; The edge communication device is also used to delete local credentials in the IoT device in response to a credential revocation command, thereby rejecting the communication request.

[0011] Based on the aforementioned technical means, when verification fails, the cloud server can send an instruction to the edge communication device, which will then delete the local credentials in the corresponding IoT device to block connection requests from unauthorized IoT devices. This can improve the security and stability of the communication channel between legitimate IoT devices and the cloud server, and to some extent reduce the occurrence of communication anomalies between the cloud server and legitimate IoT devices.

[0012] Furthermore, collaborative authentication credentials include local verification credentials and derived credentials; the method also includes: In response to the encrypted registration command sent by the edge communication device, the encrypted registration command is decrypted based on the first key stored in the cloud server to obtain the registration command for the IoT device; the encrypted registration command is obtained by the IoT device in the registration-allowed state by encrypting the original device identification code and a random number based on the second key; both the second key and the original device identification code are stored in the IoT device, and the second key is the same as the first key; In response to the registration instruction, a local credential containing the first root key and the communication node identifier of the edge communication device is generated, as well as a derived credential containing the first root key and the authentication status of the IoT device. Send local credentials to edge communication devices and store local credentials in the cloud server as locally verified credentials; Edge communication devices are also used to store local credentials in the form of temporary local verification credentials and to send local credentials to IoT devices; IoT devices are also used to store local credentials to confirm successful registration; after successful registration, IoT devices can generate communication requests based on local credentials.

[0013] Based on the aforementioned technical means, legitimate IoT devices can complete the registration process normally and send communication requests to the cloud server after successful registration. In contrast, illegitimate devices will not complete the registration process or will fail to register. Therefore, this can improve the security and stability of the communication channel between legitimate IoT devices and the cloud server to a certain extent.

[0014] Furthermore, the method also includes: In response to the encrypted activation command sent by the edge communication device, the encrypted activation command is decrypted based on the first key to obtain the device identification code of the IoT device; the encrypted activation command is obtained by the IoT device encrypting the original device identification code based on the second key. Based on the verification database in the cloud server, the device identification code is matched and verified to obtain the matching and verification results; If the matching verification results show that a verification code with the same device identifier exists in the verification database, an encrypted release activation instruction is generated based on the first key, and an encrypted release activation instruction is sent to the edge communication device. Edge communication devices are also used to forward encrypted release activation commands to IoT devices; The IoT device is also used to decrypt the encrypted release activation command based on the second root key to obtain the release activation command, and, in response to the release activation command, to adjust the device state of the IoT device to an allowed registration state.

[0015] Based on the aforementioned technical means, the cloud server can respond to activation requests from legitimate IoT devices and enable successful activation of the IoT devices by encrypting and releasing activation instructions, thus entering a registration-allowed state and preparing for the subsequent registration process. For illegitimate IoT devices, since their device identification codes are not pre-stored in the cloud server, illegitimate IoT devices cannot be successfully activated. Therefore, this can improve the reliability and security of activation of legitimate IoT devices to a certain extent, and also improve the security and reliability of subsequent registration.

[0016] Furthermore, the method also includes: In response to a renewal request sent by an edge communication device, a local certificate is regenerated. The renewal request is generated and sent to the edge communication device when the remaining validity period of the local certificate stored in the IoT device is less than a preset duration threshold. Re-execute the step of sending local credentials to the edge communication device to update the remaining validity period of the local credentials stored in the edge communication device and the IoT device.

[0017] Based on the aforementioned technical means, cloud servers can quickly renew local credentials that are about to expire in IoT devices. This enables legitimate IoT devices to continue communicating with the cloud server using valid local credentials, thereby improving the security and stability of communication between legitimate IoT devices and the cloud server.

[0018] Secondly, embodiments of this application provide an IoT device communication method applied to an edge communication device, the method comprising: In response to communication requests generated and sent by IoT devices, a communication request is sent to the cloud server; In response to the request response signal sent by the cloud server, a communication channel is generated between the IoT device and the cloud server; The cloud server is used to respond to communication requests, verify the local credentials in the communication request, obtain the verification result, and, if the verification result is successful, generate a request response signal and send the request response signal to the edge communication device.

[0019] According to the above technical solution, edge communication devices can act as communication relay nodes between IoT devices and cloud servers. Upon successful verification of the IoT device's communication request by the cloud server, a communication channel is generated between the IoT device and the cloud server. Since this communication channel is not always present but only generated after verification, this method can improve the security and reliability of access authentication between IoT devices and servers to a certain extent compared to traditional solutions. Furthermore, using edge communication devices as communication relay nodes can reduce the possibility of unauthorized IoT devices directly intruding into and damaging the cloud server, further enhancing the security and reliability of access authentication between IoT devices and servers.

[0020] Furthermore, the method also includes: When the communication connection between the edge communication device and the cloud server is unavailable, the local credentials are verified based on the temporary local verification credentials stored in the edge communication device to obtain the verification result. If the verification result is successful, a temporary communication channel is generated with the IoT device. Among them, IoT devices are used to perform temporary communication with edge communication devices through temporary communication channels.

[0021] Based on the aforementioned technical means, when edge communication devices are used as communication relay nodes between IoT devices and cloud servers, edge communication devices can provide temporary verification paths when communication connections with cloud servers are unavailable, and establish temporary communication channels between IoT devices and edge communication devices. This can reduce the unavailability of IoT device services or businesses due to unstable cloud server communication to a certain extent, and can improve the service stability or business stability of IoT devices to some extent.

[0022] Thirdly, embodiments of this application provide an Internet of Things (IoT) device communication apparatus, characterized in that it is applied to a cloud server, and the apparatus includes: The first acquisition module is used to respond to a communication request sent by an edge communication device, extract the local credentials from the communication request, and obtain the collaborative authentication credentials stored in the cloud server; the communication request is generated by the IoT device. The verification module is used to verify local credentials based on collaborative authentication credentials and obtain the verification result; The first generation module is used to generate a request-response signal and send the request-response signal to the edge communication device when the verification result is successful. The request-response signal is used to generate a communication channel between IoT devices and cloud servers.

[0023] Fourthly, embodiments of this application provide an IoT device communication apparatus, characterized in that it is applied to an edge communication device, and the apparatus includes: The request sending module is used to send communication requests to the cloud server in response to communication requests generated and sent by IoT devices. The second generation module is used to generate a communication channel between the IoT device and the cloud server in response to the request response signal sent by the cloud server. The cloud server is used to respond to communication requests, verify the local credentials in the communication request, obtain the verification result, and, if the verification result is successful, generate a request response signal and send the request response signal to the edge communication device.

[0024] Fifthly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores a computer program executable on the processor, and the processor executes the computer program to implement the Internet of Things device communication method as described in any of the preceding claims.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a vehicle controller, implements the aforementioned Internet of Things (IoT) device communication method.

[0026] Fifthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a vehicle controller in a vehicle, implement the aforementioned Internet of Things (IoT) device communication method.

[0027] The beneficial effects of this application are: In the embodiments of this application, in response to a communication request sent by an edge communication device, local credentials are extracted from the communication request, and collaborative authentication credentials stored in the cloud server are obtained; the communication request is generated by the IoT device; based on the collaborative authentication credentials, the local credentials are verified to obtain a verification result; if the verification result is successful, a request response signal is generated and sent to the edge communication device; wherein, the request response signal is used to generate a communication channel between the IoT device and the cloud server, the cloud server can verify the local credentials in the communication request generated by the IoT device according to the collaborative authentication credentials stored internally, and can generate a request response signal after successful verification, so that the edge communication device directly connected to the IoT device can generate a communication channel between the IoT device and the cloud server, enabling the cloud server to verify the IoT device when the IoT device generates a communication request, and generate a communication channel between the IoT device and the cloud server after successful verification. Since the above communication channel does not exist all the time, but is only generated after successful verification, compared with traditional solutions, the above method can improve the security and reliability of access authentication between the IoT device and the server to a certain extent. Attached Figure Description

[0028] Figure 1 A flowchart illustrating an IoT device communication method provided in an embodiment of this application; Figure 2 A flowchart illustrating another IoT device communication method provided in an embodiment of this application; Figure 3 A system architecture diagram of an IoT device communication method provided in this application embodiment; Figure 4 A timing diagram of an IoT device communication method provided in an embodiment of this application; Figure 5 A credential management logic diagram for an IoT device communication method provided in this application embodiment; Figure 6 A logic block diagram of a security protection mechanism for an IoT device communication method provided in this application embodiment; Figure 7 A logic block diagram of an IoT device communication device applied to a cloud server, provided in an embodiment of this application; Figure 8 A logic block diagram of an IoT device communication device applied to an edge communication device provided in this application embodiment. Figure 9 This is a schematic diagram of the hardware entity of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0030] As smart cockpit scenarios in vehicles rapidly become more widespread, in-vehicle IoT devices exhibit core characteristics such as distributed deployment, high requirements for low latency, complex network environments (network fluctuations due to high-speed movement, offline scenarios in tunnels / underground parking garages, etc.), and limited device power consumption. These characteristics place stringent demands on the real-time performance, offline availability, security, and lightweight adaptability of authentication systems. Existing cloud-edge collaborative authentication technologies mostly adopt general IoT authentication architectures without specific optimizations for in-vehicle IoT scenarios, generally suffering from fragmented authentication logic, failure of dual-end collaboration, and poor adaptability to extreme scenarios.

[0031] For example, in some related technologies, the cloud uniformly generates identity authentication information for clients corresponding to multiple edge nodes, packages it into an authentication list, and distributes it to each edge node. The edge nodes complete client identity matching and authentication through the locally stored authentication list. This technical solution has a fundamental flaw in its credential management logic: it adopts a single static credential batch distribution mode, lacks a hierarchical derivation and graded control mechanism, only generates authentication list data in a uniform format, and there is no strong binding relationship between credentials and edge nodes or device hardware. It cannot achieve differentiated validity period configuration, targeted renewal, and individual revocation of credentials, and only supports full list updates, resulting in large update latency and extremely high redundancy. Furthermore, it lacks credential emergency derivation and offline cache reuse mechanisms, and the credential lifecycle is entirely controlled unidirectionally by the cloud. In other embodiments, the cloud generates device certificates based on device identification codes through edge device file management and activation modules, distributes them to edge devices, and achieves device access control through certificate authentication and whitelist verification, while also being compatible with end device perception authentication. The technical solution has a rigid credential management logic and lacks local operation and maintenance capabilities: it adopts a single certificate centralized issuance mode, generates a fixed-term certificate in the cloud once, and has no local credential derivation or temporary emergency credential generation mechanism. Edge nodes only have certificate forwarding and storage functions and have no local certificate verification, renewal, or temporary authorization permissions. After the certificate is lost, expired, or the network is interrupted, it cannot generate temporary credentials to maintain business. Moreover, certificate revocation depends on the full broadcast in the cloud and has no targeted revocation or local real-time interception capabilities. Credential control response is lagging and the authentication process is completely dependent on the cloud.

[0032] To address the aforementioned technical problems, this application provides an IoT device communication method applied to a cloud server. Figure 1This is a flowchart illustrating an IoT device communication method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps S101 to S103: Step S101: In response to the communication request sent by the edge communication device, extract the local credentials from the communication request and obtain the collaborative authentication credentials stored in the cloud server; the communication request is generated by the IoT device.

[0033] In the embodiments of this application, the edge communication device can be a communication device capable of providing communication relay services, such as a mobile phone, computer, switch, edge processor, etc. In the vehicle scenario, the edge communication device can be an in-vehicle terminal, a vehicle domain controller, or a dedicated communication relay device for the Internet of Things.

[0034] Internet of Things (IoT) devices refer to intelligent hardware equipped with sensors, communication modules, and microcontrollers, capable of collecting data and performing network uploads and / or remote control. They are the terminal nodes of the IoT. In automotive scenarios, IoT devices can include smart door locks, smart windows or door drive motors, cameras, vehicle control assemblies, in-vehicle GPS terminals, and OBD vehicle networking (an IoT service platform built on an on-board diagnostics (OBD) system), etc.

[0035] The aforementioned IoT devices can be equipped with independent control chips to enable various functions. Some of these functions require network connectivity. In such cases, the IoT device can generate communication requests through its control chip and send these requests to the edge communication device connected to it. The connection between the IoT device and the edge communication device refers to their physical connection, such as a CAN bus connection or an I2C bus connection.

[0036] The communication request can be generated based on local credentials stored in the IoT device. For example, the local credentials can be packaged into a communication request or a copy of the local credentials can be used directly as the communication request. Local credentials refer to communication credentials that enable IoT devices to use the network resources of the cloud server. These credentials are typically issued to the IoT device by the cloud server during registration and stored in the IoT device's security chip. The security chip usually carries a device-bound key, preventing the local credentials from being stolen and used by other devices.

[0037] For example, suppose another illegal IoT device steals the local credentials of a legitimate IoT device. It can only steal the local credentials encrypted with the legitimate IoT device's key. When the illegal IoT device tries to use the stolen local credentials, it needs to encrypt them again with its internal key. This prevents the cloud server from obtaining a local credential that can be recognized by the cloud server through a single decryption, thereby protecting the communication rights of the legitimate IoT device.

[0038] Collaborative authentication credentials in cloud servers refer to cloud-derived credentials used for verification when completing the registration of IoT devices. Collaborative authentication credentials can include at least a local credential stub (also called a local verification credential) identical to the local credential, allowing verification of the local credential carried in the communication request using the collaborative authentication credentials.

[0039] For communication security reasons, IoT devices will always communicate with cloud servers through edge communication devices. Since the communication channel between edge communication devices and cloud servers is usually a dedicated channel, and edge communication devices can forward communication data between multiple IoT devices and cloud servers at the same time, it can avoid the problem of communication being easily cracked and intercepted caused by direct communication to a certain extent.

[0040] In addition, when generating communication requests, IoT devices can encrypt local credentials in advance to prevent the local credentials from being intercepted and stolen during IoT communication.

[0041] Step S102: Based on the collaborative authentication credentials, verify the local credentials to obtain the verification result.

[0042] In the embodiments of this application, since the collaborative authentication credential can contain at least a local credential stub identical to the local credential, the cloud server can verify the local credential sent by the IoT device based on the collaborative authentication credential to obtain the verification result. The cloud server can pre-store the encryption key of the legitimate IoT device (preferably the SM4 national cryptographic algorithm, using a 128-bit key), and can also pre-decrypt the local credential during the verification process.

[0043] In addition, the local credential can carry the device identification code (such as SN code or machine code) of the IoT device. The verification process can be a matching verification between the device identification code in the local credential and the device identification code pre-saved in the collaborative authentication credential. If the device identification code pre-saved in the collaborative authentication credential contains the same identification code as the device identification code in the local credential, it indicates a successful match, and the cloud server can determine that the verification is successful and generate a successful verification result; otherwise, it indicates a failed match, and the cloud server can determine that the verification is failed and generate a failed verification result.

[0044] Step S103: If the verification result is successful, generate a request response signal and send the request response signal to the edge communication device. The request-response signal is used to generate a communication channel between IoT devices and cloud servers.

[0045] In the embodiments of this application, if the verification result is successful, the cloud server can generate a request-response signal and send it to the edge communication device. The request-response signal can be a handshake signal or a handshake confirmation signal. Upon receiving the request-response signal, the edge communication device can establish a communication channel between the IoT device and the cloud server. This communication channel is in the form of "IoT device—edge communication device—cloud server," and the communication channel between the edge communication device and the cloud server can be a wireless channel.

[0046] For example, in a vehicle-mounted scenario, the vehicle terminal can establish a wireless communication channel with the cloud server, enabling IoT devices in the vehicle (such as cameras, smart door locks, smart drive motors, etc.) to use the network resources of the cloud server, such as achieving intelligent recognition, intelligent anti-pinch, and remote unlocking in emergency situations.

[0047] Based on the embodiments disclosed in this application, the cloud server can verify the local credentials in the communication request generated by the IoT device according to the collaborative authentication credentials stored internally, and can generate a request response signal after the verification is successful, so that the edge communication device directly connected to the IoT device can generate a communication channel between the IoT device and the cloud server. This enables the cloud server to verify the IoT device when it generates a communication request, and generate a communication channel between the IoT device and the cloud server after the verification is successful. Since the above communication channel does not exist all the time, but is only generated after the verification is successful, the above method can improve the security and reliability of access authentication between the IoT device and the server to a certain extent compared with the traditional solution.

[0048] In some embodiments, step S102 can be implemented by steps S121 to S123: Step S121: Obtain the local verification credential and derived credential from the collaborative authentication credentials.

[0049] In the embodiments of this application, the local verification credential and the derived credential can have different data addresses or data information in the collaborative authentication credential. For example, the local verification credential and the derived credential can be read by different pointers, or the local verification credential can store the device identification information of the IoT device, while the derived credential can store the IoT device's registration status information (including unregistered and successfully registered) in addition to the device identification information. Therefore, the local verification credential and the derived credential in the collaborative authentication credential can be obtained separately through different pointers or data analysis methods.

[0050] Step S122: Perform expiration verification on the derived document and the local document to obtain the expiration verification result; In the embodiments of this application, to ensure the activity of local credentials and derived credentials and to avoid the risk of permanent credentials being stolen and misused, the cloud server can assign a validity period (e.g., 7 days, 10 days, or 15 days) to the local credentials when issuing them to legitimate IoT devices. Furthermore, the cloud server can also assign a validity period to derived credentials when generating them. In addition, the validity period of derived credentials can typically be longer than that of local credentials (e.g., 15 days, 30 days, or 45 days).

[0051] In this way, the validity periods of local and derived documents can be used to verify their validity. When both local and derived documents are within their validity periods, a validity period verification result of "valid" is obtained, and the validity period of the derived document is reset to the preset validity period. When at least one of the local and derived documents is not within its validity period, a validity period verification result of "failed" is obtained.

[0052] Step S123: If the deadline verification result indicates that the deadline verification has passed, perform validity verification on the local certificate based on the local verification certificate to obtain the verification result.

[0053] In the embodiments of this application, if the expiration verification result indicates that the expiration verification has passed, it means that the local credential and the derived credential are available. At this time, the validity of the local credential can be verified based on the local verification credential, that is, by comparing the information of the local verification credential with that of the local credential. Since the cloud server stores the local verification credentials of multiple IoT devices, when a verification credential identical to the local credential can be found among the local verification credentials, a verification result of passing the verification can be obtained; otherwise, a verification result of failing the verification can be obtained.

[0054] In some embodiments, when a validity period verification result fails, or a verification result fails, the following process can be executed depending on the situation: 1) If the local certificate has expired, it is assumed that the IoT device expired under power failure conditions. In this case, regardless of whether the derived certificate is within its validity period, the IoT device will be re-registered so that the cloud server can reissue a valid local certificate to the IoT device; 2) If the local certificate has not expired, but the derived certificate has expired, it is assumed that the local certificate has been maliciously stolen and copied. In this case, the cloud server can mark the IoT device as a suspected malicious device and issue a deregistration command to the IoT device through the edge communication device. When the IoT device receives the deregistration command, it needs to re-execute the activation process. If the activation fails, the cloud server can mark the IoT device as a malicious device and prohibit the device from requesting activation or registration from the cloud server again.

[0055] Based on the above embodiments disclosed in this application, the local credentials can be validated for both validity and validity based on the local verification credentials and derived credentials stored in the collaborative authentication credentials stored in the cloud server, and the validation results can be obtained. The two-level validation path consisting of validity and validity validation can improve the accuracy and reliability of the final validation results to a certain extent.

[0056] In some embodiments, step S122 can be implemented by steps S1221 and S1222: Step S1221: Determine the first remaining validity period of the local voucher and the second remaining validity period of the derived voucher.

[0057] In the embodiments of this application, the remaining validity period can be calculated by the expiration date of the voucher and the current time. For example, if the expiration date of the local voucher is 202103031104 (its format is YYYYMMDDHHMM, that is, the first four digits are the year, the next two are the month, the next two are the day, the next two are the hour, and the last two are the minute), and the current time is 202103011104, then the first remaining validity period is 2 days.

[0058] Step S1222: If both the first remaining valid duration and the second remaining valid duration are greater than or equal to the preset duration threshold, determine that the duration verification result has passed.

[0059] In the embodiments of this application, the preset duration threshold can be set to a duration that is proportional to the difference between the validity period and the validity period, such as 1 day or 0.5 days. When both the first remaining validity period and the second remaining validity period are greater than or equal to the preset duration threshold, it can be considered that the local certificate does not need to be renewed, and at this time the validity period verification result can be obtained.

[0060] Furthermore, step S123 can be achieved through steps S1231 and S1232: Step S1231: Match and verify the local verification credential and the local credential to obtain the matching result.

[0061] In the embodiments of this application, matching verification refers to matching each verification credential contained in the local verification credential with the local credential. When one verification credential is the same as the local credential, the match is considered successful; when all verification credentials are different from the local credential, the match is considered unsuccessful.

[0062] Since the local verification certificate is stored on the cloud server in a verification manner before being issued, it does not contain an expiration date. Therefore, "the verification certificate is the same as the local certificate" means that all information in the verification certificate and the local certificate is the same except for the validity information (such as device identification code, device model, device code, etc.).

[0063] Step S1232: If the matching result indicates that there is a target credential that is the same as the local credential in the local verification credential, and there is no historical verification success information for the local credential in the cloud server, then the verification result that has been successfully verified is determined.

[0064] In the embodiments of this application, in addition to matching the local credential and the local verification credential based on information other than the expiration date, it can also be confirmed whether there is historical verification success information for the local credential in the cloud server. Typically, in a replay attack, because the malicious IoT device needs to intercept and obtain the corresponding local credential based on the legitimate IoT device's normal communication request, the replay attack's use of the local credential will be later than the legitimate IoT device's use of the local credential. Therefore, when there is no historical verification success information for the local credential in the cloud server, it is considered a normal communication request from a legitimate IoT device. If the matching result indicates that the local verification credential contains a target credential identical to the local credential, then a successful verification result can be determined.

[0065] In one possible embodiment, upon receiving a successful verification result, the validity period of the derived certificate can be reset to a preset validity period. For example, if the preset validity period is 30 days and the current time is 202103011104, then the validity period of the reset derived certificate will be 202103301104.

[0066] Based on the embodiments disclosed in this application, the expiration verification result of the local certificate can be determined according to the remaining validity period of the derived certificate and the local certificate. After the expiration verification is passed, the corresponding verification result can be obtained according to the matching result of the local verification certificate and the local certificate. Since the remaining validity period of the derived certificate stored on the cloud server is used, the local certificate is considered to be valid only when the remaining validity period indicates that the derived certificate has not expired, which can improve the accuracy of the expiration verification result to a certain extent. At the same time, by matching the local verification certificate with the local certificate, a matching result is obtained. When the matching result is successful, it indicates that the local certificate is a valid certificate issued by the cloud server. When the matching result is unsuccessful, it indicates that the local certificate is a forged certificate generated by the IoT device itself. That is, the matching result can be used to determine whether the local certificate is issued by the cloud server or generated by the IoT device itself, which can improve the accuracy and reliability of the final verification result to a certain extent.

[0067] In some embodiments, the above-described IoT device communication method may further include steps S104 and S105: Step S104: If the matching result indicates that there is no target credential identical to the local credential in the local verification credential, or if there is historical verification success information in the cloud server, then the verification result of failure is determined. In the embodiments of this application, when the matching result indicates that there is no target credential identical to the local credential in the local verification credentials, it can be assumed that the local credential of the IoT device is generated by itself rather than issued by the cloud server. In this case, it can be determined that the verification result fails.

[0068] Furthermore, if historical verification success information exists in the cloud server, the communication request from the IoT device can be considered a replay attack, and a verification failure result can be obtained.

[0069] Step S105: Send a credential revocation command to the edge communication device; The edge communication device is also used to delete local credentials in the IoT device in response to a credential revocation command, thereby rejecting the communication request.

[0070] In the embodiments of this application, whether the target credential identical to the local credential does not exist in the local verification credentials, or historical verification success information exists in the cloud server, it indicates that the current communication request is an illegal request. In this case, the cloud server can send a credential revocation instruction to the edge communication device, which will then forcibly delete the local credential from the IoT device. When the IoT device does not have a local credential, it cannot generate or send a communication request. Thus, the cloud server can reject and block communication requests from illegal IoT devices.

[0071] Based on the above embodiments disclosed in this application, when the verification fails, the cloud server can send an instruction to the edge communication device, which will then delete the local credentials in the corresponding IoT device to block connection requests from illegal IoT devices. This can improve the security and stability of the communication channel between legitimate IoT devices and the cloud server, and reduce the occurrence of communication anomalies between the cloud server and legitimate IoT devices to a certain extent.

[0072] In some embodiments, the collaborative authentication credential includes a local authentication credential and a derived credential; the above-described IoT device communication method may further include steps S106 to S108: Step S106: In response to the encrypted registration instruction sent by the edge communication device, the encrypted registration instruction is decrypted based on the first key stored in the cloud server to obtain a registration instruction for the IoT device. The encrypted registration instruction is obtained by encrypting the original device identifier code and a random number based on the second key when the IoT device is in a registration-allowed state. Both the second key and the original device identifier code are stored in the IoT device, and the second key is the same as the first key.

[0073] In the embodiments of this application, in the communication system of "IoT device - edge communication device - cloud server", the IoT device can usually be produced together with the edge communication device, such as the smart IoT in the vehicle scenario. Therefore, during the production stage, the root key of the legitimate IoT device can be pre-stored in the cloud server. Here, the first root key refers to the root key of the legitimate IoT device stored in the cloud server, and the second key refers to the root key stored in the security chip of the legitimate IoT device itself. Moreover, the root keys of different legitimate IoT devices are different (here, "different" refers to different device entities, such as two identical smart cameras belonging to different IoT devices).

[0074] When an IoT device registers under the allowed registration state, it first generates a random number and encrypts the original device identifier and the random number using the second key stored internally to obtain an encrypted registration instruction. When the cloud server receives the encrypted registration instruction, it decrypts it using the first key stored on the cloud server. When decryption is successful, the encrypted registration instruction is considered a valid registration instruction, and the combination of the decrypted random number and the device identifier can be used as the registration instruction.

[0075] The device identification code may include the MAC address or SN code of the IoT device. Similar to the root key mentioned above, different legitimate IoT devices have different device identification codes (that is, there is a one-to-one binding relationship between the device identification code, the root key and the device itself).

[0076] In addition, random numbers generated by the same IoT device are usually not repeated. When the random number contained in the local certificate received by the cloud server is the same as the random number in the historical local certificate, the communication request can be judged as a replay attack and the communication request will no longer be responded to.

[0077] Step S107: In response to the registration instruction, generate a local credential containing the first root key and the communication node identifier of the edge communication device, and a derived credential containing the first root key and the authentication status of the IoT device.

[0078] In the embodiments of this application, after responding to the registration instruction obtained after decryption, the communication node identifier (e.g., node serial number or device serial number or device code of the edge communication device that sent the communication request) and the first key can be integrated and packaged to obtain a local credential. Furthermore, since successful decryption confirms that the IoT device is a legitimate IoT device, the cloud server can also integrate and package the first root key and the authentication status of the IoT device to obtain a derived credential.

[0079] The authentication status can be represented using two binary codes. For example, "00" indicates an inactive status and / or an authentication failure status, "01" indicates an allowed registration status, "10" indicates a successful registration status, and "11" indicates a successful connection status.

[0080] Step S108: Send local credentials to the edge communication device and store the local credentials in the cloud server as local verification credentials; Edge communication devices are also used to store local credentials in the form of temporary local verification credentials and to send local credentials to IoT devices; IoT devices are also used to store local credentials to confirm successful registration; after successful registration, IoT devices can generate communication requests based on local credentials.

[0081] In the embodiments of this application, the local credentials sent by the cloud server to the edge communication device may include an expiration date, while storing local credentials in the form of local verification credentials means that the local verification credentials may not include an expiration date.

[0082] After receiving a local credential, the edge communication device can store the local credential as a temporary local verification credential. During the storage process, the validity period of the local credential does not need to be deleted.

[0083] After receiving the local credentials, IoT devices can confirm successful registration. For example, they can modify the device's internal status code to indicate that the device can be used for normal communication.

[0084] Based on the above embodiments disclosed in this application, legitimate IoT devices can execute the registration process normally and send communication requests to the cloud server after successful registration, while illegal devices will not execute the registration process or will fail to register. Therefore, the security and stability of the communication channel between legitimate IoT devices and the cloud server can be improved to a certain extent.

[0085] Based on the above embodiments, the above IoT device communication method may further include steps S109 to S111: Step S109: In response to the encrypted activation command sent by the edge communication device, the encrypted activation command is decrypted based on the first key to obtain the device identification code of the IoT device; the encrypted activation command is obtained by the IoT device encrypting the original device identification code based on the second key.

[0086] In the embodiments of this application, since different IoT devices store different root keys, the method of IoT device encryption and cloud server decryption is adopted. Unauthorized devices will not be able to decrypt various instructions and local credentials encrypted by the cloud server, which can prevent other unauthorized IoT devices from illegally using the device identification code, local credentials and other data of legitimate IoT devices to a certain extent.

[0087] For example, both encryption and decryption can be performed using the SM4 national cryptographic algorithm, with a 128-bit encryption key. For example, the key can be "0x0123456789ABCDEF", "0xFEDCBA9876543210", or one of other 128-bit keys.

[0088] It should be noted that IoT devices can encrypt the original device identification code using a second key when first powered on or in an inactive state, in order to generate an encrypted activation command. The original device identification code refers to the identification code stored in the IoT device.

[0089] Step S110: Based on the verification database in the cloud server, the device identification code is matched and verified to obtain the matching verification result.

[0090] In the embodiments of this application, the device identification code of a legitimate IoT device can be pre-stored in a verification database on a cloud server. The verification database can be of type such as "HBase", "Cassandra", or "Redis".

[0091] Step S111: If the matching verification result shows that there is a verification code in the verification database that is the same as the device identification code, an encrypted release activation instruction is generated based on the first key, and the encrypted release activation instruction is sent to the edge communication device. Edge communication devices are also used to forward encrypted release activation commands to IoT devices; The IoT device is also used to decrypt the encrypted release activation command based on the second root key to obtain the release activation command, and, in response to the release activation command, to adjust the device state of the IoT device to an allowed registration state.

[0092] In the embodiments of this application, if a verification code identical to the device identifier exists in the verification database, the cloud server can confirm that the activation request is valid and encrypt the specified activation response string using the first key to generate an encrypted release activation instruction.

[0093] After encrypting the activation command using the second key pair, the IoT device receives a specified activation response string as the activation command itself. The IoT device then responds to this activation command by adjusting its device state to a registration-allowed state, preparing for the registration process. Throughout the activation process, the edge communication device can simply act as a command forwarder.

[0094] Based on the above embodiments disclosed in this application, the cloud server can respond to activation requests from legitimate IoT devices and enable successful activation of the IoT devices by encrypting and releasing activation instructions, thereby entering the registration-allowed state and preparing for the subsequent registration process. For illegitimate IoT devices, since their device identification codes are not pre-stored in the cloud server, illegitimate IoT devices cannot be successfully activated. Therefore, the activation reliability and security of legitimate IoT devices can be improved to a certain extent, and the security and reliability of subsequent registration can also be improved at the same time.

[0095] In some embodiments, the above-described IoT device communication method may further include steps S112 and S113: Step S112: In response to the renewal request sent by the edge communication device, a local certificate is regenerated; the renewal request is generated and sent to the edge communication device by the IoT device when the remaining validity period of the local certificate stored in the IoT device is less than a preset duration threshold.

[0096] In the embodiments of this application, if the remaining validity period of the local certificate stored in the IoT device is less than a preset validity period threshold, the IoT device can automatically initiate a renewal request so that the cloud server can regenerate the local certificate. However, it should be noted that, in order to prevent the illegal use of certificates due to leakage of local certificates, when the local certificate expires, that is, when the remaining validity period is 0, a renewal request may not be generated, and the registration process of steps S106 to S108 may be re-executed.

[0097] Step S113: Re-execute the step of sending local credentials to the edge communication device to update the remaining validity period of the local credentials stored in the edge communication device and the IoT device.

[0098] In the embodiments of this application, after the edge communication device and the IoT device receive the local credentials regenerated and issued by the cloud server, they can delete the original credentials and store the newly received local credentials in the storage space of the original credentials, so as to update the remaining validity period of the local credentials stored in the edge communication device and the IoT device.

[0099] Based on the embodiments disclosed in this application, the cloud server can quickly renew the local credentials of IoT devices that are about to expire. This enables legitimate IoT devices to continue communicating with the cloud server using valid local credentials, thereby improving the security and stability of communication between legitimate IoT devices and the cloud server.

[0100] Figure 2 This is a flowchart illustrating another IoT device communication method provided in an embodiment of this application, applied to an edge communication device, such as... Figure 2 As shown, the method may include: Step S201: In response to the communication request generated and sent by the IoT device, a communication request is sent to the cloud server.

[0101] In embodiments of this application, the edge communication device can receive communication requests from IoT devices before establishing a communication channel with the cloud server via a wired communication connection. After recognizing the request identifier, the edge communication device can directly forward the communication request to the cloud server.

[0102] Step S202: In response to the request response signal sent by the cloud server, a communication channel is generated between the IoT device and the cloud server. The cloud server is used to respond to communication requests, verify the local credentials in the communication request, obtain the verification result, and, if the verification result is successful, generate a request response signal and send the request response signal to the edge communication device.

[0103] In the embodiments of this application, since there is a wired communication connection between the edge communication device and the IoT device, when the IoT device establishes a communication connection with the cloud server, only a communication channel needs to be established between the edge communication device and the cloud server. For legitimate IoT devices, the wired communication connection between them and the edge communication device remains continuously available. When the cloud server determines that an IoT device is a malicious device, the edge communication device can block all requests from that device.

[0104] Based on the embodiments disclosed in this application, the edge communication device can act as a communication relay node between IoT devices and cloud servers. It generates a communication channel between the IoT device and the cloud server upon successful verification of the IoT device's communication request by the cloud server. Since this communication channel is not always present but is only generated after successful verification, compared to traditional solutions, this method can improve the security and reliability of access authentication between IoT devices and servers to a certain extent. Furthermore, using the edge communication device as a communication relay node can reduce the possibility of unauthorized IoT devices directly intruding into and damaging the cloud server, further enhancing the security and reliability of access authentication between IoT devices and servers.

[0105] In some embodiments, the above-described IoT device communication method may further include steps S203 and S204: Step S203: If the communication connection between the edge communication device and the cloud server is unavailable, the local credential is verified based on the temporary local verification credential stored in the edge communication device to obtain the verification result.

[0106] In the embodiments of this application, if the cloud server is under maintenance or the edge communication device is outside the effective communication area (e.g., in a vehicle scenario, when the vehicle is driving into a tunnel), the communication connection between the edge communication device and the cloud server will be unavailable. Since the communication request of the IoT device cannot be verified through the cloud server at this time, offline authentication can be performed through the edge communication device, and the local credentials can be verified using the temporary local verification credentials stored in the edge communication device.

[0107] For example, in this case, the edge communication device can activate the local credential backup stored inside the edge communication device and set the temporary validity period of the local credential backup to 24 hours to form a temporary local verification credential, which can then be used to verify the local credential.

[0108] The verification content of local credentials by edge communication devices may include at least the device identification code contained in the local credential. It may also include the validity period and / or the root key. It should be noted that when the edge communication device verifies the validity period of a local credential, it can directly compare the validity period of the local credential with that of the temporary local verification credential. If the validity period of the local credential is the same as that of the temporary local verification credential, the validity period verification passes.

[0109] Step S204: If the verification result is successful, a temporary communication channel is generated between the device and the IoT device. Among them, IoT devices are used to perform temporary communication with edge communication devices through temporary communication channels.

[0110] In the embodiments of this application, the temporary communication channel may rely on the wired communication connection between the edge communication device and the IoT device; after the temporary communication channel is established, the edge communication device may no longer verify the communication data sent by the IoT device before the network service of the cloud server is restored.

[0111] Based on the above embodiments disclosed in this application, when an edge communication device is used as a communication relay node between an IoT device and a cloud server, the edge communication device can provide a temporary verification path when the communication connection with the cloud server is unavailable, and establish a temporary communication channel between the IoT device and the edge communication device. This can reduce the situation where the IoT device's service or business is unavailable due to unstable communication with the cloud server to a certain extent, and can improve the service stability or business stability of the IoT device to a certain extent.

[0112] The following describes the application of the IoT device communication method provided in the embodiments of this application in a real-world scenario.

[0113] With the rapid popularization of smart cockpit scenarios in vehicles, in-vehicle Internet of Things (IoT) devices exhibit core characteristics such as distributed deployment, high requirements for low latency, complex network environments (network fluctuations due to high-speed movement, offline scenarios such as tunnels / underground parking garages), and limited device power consumption. These characteristics place stringent demands on the real-time performance, offline availability, security, and lightweight adaptability of authentication systems. Existing cloud-edge collaborative authentication technologies mostly adopt general IoT authentication architectures without specific optimizations for in-vehicle IoT scenarios, generally suffering from fragmented authentication logic, failure of dual-end collaboration, and poor adaptability to extreme scenarios.

[0114] Traditional technical solutions all adopt a centralized authentication architecture with centralized cloud management. In terms of technical principles, they lack the underlying design of dual-end collaboration between local and cloud, lack a layered credential derivation mechanism, local self-authentication capability, and dynamic scenario adaptation logic. They cannot meet the low latency, offline availability, low power consumption, and high reliability requirements of in-vehicle IoT devices in scenarios such as offline edge nodes and network fluctuations.

[0115] To address the aforementioned issues, this application discloses a method and system for local and cloud-based collaborative authentication of in-vehicle IoT devices. The core mechanism of "one-time registration, dual derivation" integrates optimized designs such as root credential activation, emergency authentication, and dynamic policy adaptation to generate a set of root credentials and derive dual-end authentication credentials. This enables collaborative linkage between rapid local access and unified cloud management, effectively solving the offline availability and high reliability requirements of in-vehicle IoT devices in scenarios such as offline edge nodes and network fluctuations.

[0116] The specific technical solution is as follows: 1) System architecture design; This application comprises three core modules, which work together to achieve a closed-loop process for collaborative authentication. The specific functions of each module are as follows: The IoT device-side module, deployed within the IoT device, is primarily responsible for reading the root credential, activating it, constructing registration / authentication / activation requests, parsing and installing the collaborative credential package, performing local authentication and data encryption, and collecting device operating status. It adapts to the resource limitations of low-power devices and supports switching between lightweight and standard credentials. It adds a root credential activation submodule and a status awareness submodule (including a network status acquisition interface) to support the activation process, dynamic policy adaptation, and cockpit device linkage requirements, ensuring stable device operation under network fluctuation scenarios.

[0117] Edge Node (Gateway) Module: Deployed on the local edge, its core responsibilities include receiving device registration / authentication / renewal / activation requests, forwarding them to the cloud authentication center, performing local fast authentication (verifying local credentials), caching device credentials, status information, and emergency authentication policies, synchronizing authentication logs to the cloud, receiving and executing credential revocation commands, and handling emergency authentication requests, supporting concurrent access from multiple devices. An emergency authentication submodule (generating temporary credentials) and a network status synchronization submodule are added to cover extreme scenarios and network fluctuation scenarios, improving system stability under unstable network conditions and adapting to high concurrency and anti-interference requirements.

[0118] The cloud-based authentication center module, deployed on a cloud platform, is primarily responsible for root credential management, activation command generation, collaborative credential package generation, device identity verification, issuing global synchronization policies and dynamically adjusting policies, storing authentication logs and ensuring immutable evidence preservation, and performing credential renewal and revocation operations. It adds an activation command generation submodule (generating device activation commands), a dynamic policy adjustment submodule (adjusting authentication parameters based on device and network status), and a device-specific management submodule (hierarchical access control and encrypted storage of privacy data), thus enhancing its comprehensive control capabilities across all scenarios.

[0119] 2) Collaborative authentication process; This application achieves collaborative authentication between local and cloud platforms through five key steps: "root credential activation, one-time registration, dual derivation, two-way collaboration, and dynamic management." It also integrates emergency authentication processes for edge nodes, covering extreme scenarios such as network fluctuations and offline conditions. The specific process is as follows: Identity and Root Certification Configuration: When IoT devices leave the factory, a unique device identity (Device ID, preferably MAC address) and root key are pre-configured. These two are bound one-to-one with the device hardware serial number to form the root credential, which serves as the basis for dual-end derived credentials. The root key is generated as a 128-bit key using the national cryptographic SM4 algorithm, burned into the device's security chip and stored in encrypted form [PAT1.1] to prevent key leakage at the hardware level. The cloud authentication center synchronously stores the Device ID, root key, and device hardware serial number of all devices to establish a root credential management ledger, ensuring the uniqueness and security of the root credential.

[0120] Root credential activation phase: Upon first power-on, the device automatically reads the encrypted root credential stored in the security chip, generates an activation request (including Device ID and device hardware serial number), and sends it to the local edge node [PAT2.1]. The edge node forwards the activation request to the cloud authentication center, which verifies the binding relationship between the hardware serial number and the Device ID. After confirming its legitimacy, the cloud generates an activation command (encrypted using SM4) and sends it to the device through the edge node. The device decrypts the activation command using the root key, completes the root credential decryption and activation, and enters the registration process. Unactivated devices cannot initiate registration, thus blocking unauthorized device access from the source.

[0121] Device registration phase: After device activation, the root credentials (Device ID + RootKey) in the security chip are automatically read, the first random number is generated and encrypted with the root key, and a registration request containing the Device ID and the encrypted random number is constructed to initiate a registration application to the local edge node; the addition of the random number can effectively resist replay attacks [PAT3.1] and improve the security of the registration process.

[0122] Collaborative credential generation phase: After receiving the registration request, the edge node directly forwards the request to the cloud authentication center without additional verification, reducing the computing power consumption of the edge node. The cloud authentication center verifies the legality of the Device ID and the validity of the encrypted random number (verified by decryption using the root key). After confirming the device identity is correct, it generates a "collaborative authentication credential package" based on the device type, network conditions, and application scenario. This credential package contains three core contents: ① Local credential: A short-term token (such as JWT, with a default validity of 7 days, automatically extended to 14 days during network fluctuations) generated using the SM3 hash algorithm based on RootKey + edge node ID + timestamp, used for rapid local access; ② Cloud-derived certificate: A short-term encrypted certificate (valid for 30 days) generated using the SM2 algorithm based on RootKey + device current status code + validity period, used for direct communication between the device and the cloud; ③ Synchronization strategy: Includes parameters such as local authentication validity period, cloud session timeout, log synchronization cycle, credential renewal threshold (remaining 1 day), and emergency authentication rules (emergency credential generation rules, valid for 24 hours). The cloud distributes the credential packet to the edge node via an encrypted channel (preferably using the national cryptographic SM4 algorithm, 128-bit key, and ECB encryption mode), and the edge node then forwards it to the device to ensure the secure transmission of the credential packet.

[0123] Local and cloud-based collaborative authentication phase: After receiving the credential packet, the device decrypts it using the root key, installs the local credentials and the cloud-derived certificate, and completes the authentication initialization. Among these steps: ① Local access: When the device communicates with the edge node locally, it can directly use local credentials for quick authentication without having to access the cloud in real time. Even if the network is interrupted, local services can still operate normally.

[0124] ② Cloud Synchronization: Edge nodes, in accordance with the synchronization strategy, periodically (by default every hour) or during major events such as device status changes, authentication anomalies, and network status switching, encrypt the authentication logs and status information of the local device using cloud-derived certificates (SM2 algorithm) and synchronize them to the cloud authentication center. The cloud performs consistency verification on the synchronized information and stores it using an immutable evidence storage method (such as blockchain evidence storage or hash chain evidence storage) to form a complete audit evidence chain, which facilitates the tracing of security incidents.

[0125] ③ Edge Node Offline Emergency Authentication: When an edge node loses connection with the cloud, it initiates an emergency authentication strategy (cloud-deployed rules cached locally). If the IoT device has not previously performed access authentication, the edge node can generate a temporary local credential (valid for 24 hours, generated using the SM3 hash algorithm) for the IoT device based on the root credential information cached locally and the emergency rules. If the IoT device has previously performed access authentication, the edge node can obtain a temporary local credential by activating the local cached backup and assigning an expiration date, ensuring the continuous operation of the IoT device's core functions. After the edge node regains network connectivity, it automatically synchronizes the emergency authentication logs and device interaction data during the network outage to the cloud. The cloud verifies the legality of the temporary credential and updates the device credential information, achieving seamless integration between offline business and cloud management.

[0126] Dynamic update and undo phase: ①Certificate Renewal: When a local certificate or cloud-derived certificate is nearing its expiration date (1 day remaining), the device automatically initiates a renewal request to the cloud through the edge node. The cloud regenerates the derived certificate / certificate based on the root certificate and the device's network status, and distributes it to the device without having to re-execute the registration process. When the network fluctuates (signal strength ≤ -80dBm), the renewal request can be delayed until the network stabilizes to avoid renewal failure due to network fluctuations and ensure authentication continuity.

[0127] ② Credential Revocation: If a device is marked as a malicious device (such as an illegally connected external device) or is deregistered, the cloud authentication center generates a "credential revocation list" and broadcasts it to all relevant devices through the edge nodes. The edge nodes immediately reject the device's local authentication request, and the cloud simultaneously rejects the device's cloud communication request, achieving "one-stop revocation, two-way invalidation" to ensure the uniformity of access control. For vehicle smart cockpit scenarios, credential revocation can be manually initiated through the vehicle central control or cloud backend to quickly block unauthorized device access and improve emergency response capabilities.

[0128] ③ Dynamic policy adaptation: The device collects its own operating status (battery power, network quality, computing load) in real time and synchronizes it to the edge node and the cloud; the cloud dynamically adjusts the authentication policy according to the device status and network status. When the battery power is low (e.g., ≤20%), the validity period of the certificate is extended to 14 days and the log synchronization frequency is reduced to every 6 hours. When the network fluctuates (signal strength ≤-80dBm), a lightweight encryption method is adopted (simplifying the SM4 encryption process and reducing computing power consumption), which improves the device's battery life and authentication stability and adapts to complex operating environments.

[0129] 3) Security protection mechanisms; This application constructs a comprehensive security protection system, integrating and optimizing security enhancement measures in the design, taking into account credential security, transmission security, and data security, forming a multi-layered protection system of "hardware storage + algorithm encryption + process verification + log storage," as detailed below: Credential Security: The root key is stored in the device's security chip, encrypted and pre-configured, and requires activation before use, preventing key leakage at the hardware level. Derived credentials are generated using a combination algorithm of "root key + dynamic parameters." Specific SM3 hash details are as follows: The national standard SM3 cryptographic hash algorithm is used, with a fixed hash value output length of 256 bits. The calculation logic is "SM3(root key||dynamic parameters|| device unique identifier fragment)", where "||" represents byte concatenation. The dynamic parameters contain three core elements: a timestamp accurate to the second (format YYYYMMDDHHMMSS, e.g., 20260305143025), and an edge node network status code (0 = network normal, 1 = network fluctuation (i.e., unstable network signal strength), 2 = network interruption). The device unique identifier fragment is the first 8 bytes (hexadecimal) of the Device ID (MAC address), further enhancing the uniqueness and anti-counterfeiting capabilities of the derived credentials. Derived credentials are valid for a short period of time. Local credentials have a default validity period of 7 days, which is extended to 14 days when there is network fluctuation at the edge node (signal strength ≤ -80dBm). Cloud-derived certificates have a validity period of 30 days, and emergency credentials have a validity period of 24 hours. The short validity period design reduces the security risk after credential leakage; strengthens the binding verification between credentials and devices to prevent credential misuse.

[0130] Transmission Security: Registration requests, activation commands, credential packages, log synchronization, and other data are all transmitted through an encrypted channel, using the national standard SM4 algorithm (128-bit key, ECB encryption mode) and digital signatures (preferably using the SM2 elliptic curve cryptography algorithm, 256-bit key length, suitable for low-power scenarios; alternatively, the RSA asymmetric encryption algorithm, 2048-bit key length, for high-security scenarios) to prevent data tampering and theft. The device's private data is encrypted using a cloud-derived certificate (SM2 algorithm) to ensure it is not leaked during transmission, meeting user privacy protection requirements.

[0131] Behavioral security: It prevents replay attacks through timestamps (each authentication request carries a unique timestamp, and requests that time out are rejected directly), prevents credential misuse through device status binding, and prevents identity forgery through hardware serial number verification, thus providing comprehensive protection against malicious attacks.

[0132] Audit security: Authentication logs and emergency authentication records are stored immutably in the cloud, forming a complete chain of evidence from device activation, registration, authentication to revocation, which facilitates security auditing and security incident tracing.

[0133] Emergency Security: The emergency credentials for edge nodes adopt a short-term validity design (valid for 24 hours). The emergency credentials are generated using the SM3 hash algorithm, and the calculation logic is "SM3(root key cache value|| edge node ID|| emergency identifier|| timestamp)". The emergency identifier is fixed as "00" (occupying 1 byte) and is only used for local business. It is immediately verified and updated after the network is restored to avoid security risks in emergency mode.

[0134] The beneficial effects are as follows: 1) Improved authentication efficiency: The existing authentication process requires authentication from the device to the edge node, and then from the edge node to the cloud. The authentication process depends on network stability. This application uses locally derived credentials to directly connect to the edge node to complete the authentication, reducing the steps to cloud authentication, improving authentication efficiency, and adapting to the low-latency linkage requirements of smart cockpits.

[0135] 2) Improved business continuity and zero interruption in extreme scenarios: Existing technologies completely fail in offline scenarios such as network outages, tunnels, and underground parking garages, resulting in direct interruption of local services; This application relies on the offline emergency authentication mechanism of edge nodes to ensure the continuous operation of core cockpit services and solve the pain point of business interruption in vehicle scenarios.

[0136] 3) Improved security control precision and efficiency in blocking unauthorized access: Existing technologies rely on single credentials and lack hierarchical control, making it difficult to quickly trace and intercept unauthorized devices after they have accessed the network. This application achieves "one-stop revocation, two-way invalidation". After the revocation command is issued by the cloud, the edge node and the cloud simultaneously block the device access. The response to unauthorized access is fast, and the blocking efficiency is improved compared to existing technologies. Combined with full-process log storage, it improves the efficiency of security audit and traceability.

[0137] The following is combined Figures 3 to 6 This paper elaborates on the specific implementation of the local and cloud collaborative authentication method and system for in-vehicle IoT devices of this application. This implementation takes the smart cockpit scenario of a vehicle as the application scenario (adapting to the core needs of network fluctuations, network offline, and multi-device linkage of in-vehicle devices), clearly presents the specific execution process, parameter settings, and module interaction logic of each link, making the technical solution of this application more feasible. At the same time, it covers key scenarios such as low power consumption adaptation and emergency authentication, ensuring that those skilled in the art can completely reproduce the technical solution of this application based on this implementation.

[0138] In this embodiment, the IoT devices selected are in-vehicle terminals (Device ID uses the MAC address of the in-vehicle terminal: 58:8B:25:7A:3C:1E) and in-vehicle sensors (Device ID: 58:8B:25:7A:3C:1F). The edge nodes are in-vehicle edge gateways (edge ​​node ID: GW-CAR-001). The cloud authentication center is deployed on the car manufacturer's private cloud platform. The root key is generated using the national cryptographic SM4 algorithm to create a 128-bit key (key value: 0x1234567890ABCDEF1234567890ABCDEF), which is burned into the in-vehicle device security chip (using the SLB9670 security chip), encrypted and stored, and bound one-to-one with the device hardware serial number (in-vehicle terminal serial number: CAR-TERM-0001, in-vehicle sensor serial number: CAR-SENSOR-0001) to form the root credential. The cloud authentication center simultaneously establishes a root credential management ledger to record the correspondence between Device ID, root key, and hardware serial number to ensure the uniqueness of the root credential.

[0139] (I) System Module Implementation: Combination Figure 3 The system architecture diagram is shown below. The specific implementation of the three core modules is as follows, ensuring stable system operation and adaptability to multiple scenarios and devices. The implementation details of each module are as follows: (1) IoT device module 301: that is, the IoT device in the above embodiment, including root credential activation module 3012, credential parsing and storage module 3013, status perception module 3014 and data encryption module 3015. By calling the root key and device identification code inside the security chip 3011, it is used to realize root credential activation, credential parsing and storage, status perception and data encryption. It is deployed inside the vehicle terminal and vehicle sensor, and adopts embedded development (based on Linux system). The root credential activation submodule is responsible for the execution of the root credential activation process. The status perception submodule collects status data such as network signal strength, power, and computing load through the built-in network interface, supports automatic switching between lightweight credentials and standard credentials; adapts to low power consumption requirements, optimizes credential parsing and storage logic, and reduces CPU and memory usage. (2) Edge node (vehicle edge gateway) 302: that is, the edge communication device in the above embodiment, including network status acquisition module 3021, data relay module 3022, emergency authentication module 3023, credential caching module 3024, log recording module 3025, root credential verification module 3026, and illegal connection interception module 3027, which are used to acquire network status, data relay, emergency authentication, credential caching, log recording, root credential verification, and illegal connection interception. It is deployed inside the vehicle and adopts industrial-grade gateway hardware. The emergency authentication submodule is responsible for the generation and management of temporary credentials when offline. The network status synchronization submodule collects the network status in real time and synchronizes it to the cloud. It supports concurrent access of multiple devices, can cache credentials, logs and other data, and adapts to the high concurrency and anti-interference requirements of vehicles. (3) Cloud Authentication Center 303: namely the cloud server in the aforementioned embodiments, including device management module 3031, root credential management module 3032, activation instruction generation module 3033, integrated credential package generation module 3034, credential renewal / revocation module 3035, dynamic policy adjustment module 3036, and log storage module 3037, used for device management, root credential management, activation instruction generation, integrated credential package generation, credential renewal / revocation, dynamic policy adjustment, and log storage. It is deployed on the car company's private cloud platform and adopts a distributed architecture. The activation instruction generation submodule is responsible for the generation and encryption of activation instructions. The dynamic policy adjustment submodule adjusts the authentication parameters in real time according to the device status and network status. The device-specific management submodule realizes the hierarchical device permission (administrator, ordinary user) and encrypted storage of privacy data. Device management, log query, credential revocation and other operations can be realized through the cloud backend.

[0140] (II) Implementation Process of Collaborative Authentication Combination Figure 3 System architecture diagram, Figure 4 Timing diagram and Figure 5 The credential management logic diagram shows that the collaborative authentication process includes five stages: registration, credential generation, collaborative authentication, dynamic update, and revocation. Figure 4 Steps S405 to S431 in the sequence diagram are implemented as follows, highlighting the core mechanism of "one-time registration, dual derivation" and adaptation to scenarios such as network fluctuations and offline edge nodes. Specific steps: 1. Equipment activation and registration implementation (1) Upon initial power-on, the vehicle terminal (IoT device) automatically initiates the root credential activation submodule, reads the encrypted root credential (Device ID: 58:8B:25:7A:3C:1E + root key: 0x1234567890ABCDEF) stored in the security chip, constructs an activation request, and carries the Device ID and device hardware serial number (CAR-TERM-0001). After encryption using the SM4 algorithm, the request is sent to the local edge node (vehicle edge gateway GW-CAR-001); (corresponding to Figure 4 Step S401: Send activation request (Device ID + hardware serial number) (2) After receiving the activation request, the edge node forwards the activation request to the cloud authentication center through its built-in protocol conversion module, while caching the request data (caching time is 10 minutes for retransmission during network fluctuations); (corresponding to) Figure 4 Step S402: Forward the activation request and verify the device identity. (3) After receiving the activation request, the cloud authentication center starts the activation instruction generation submodule, verifies the binding relationship between the hardware serial number (CAR-TERM-0001) and the Device ID (58:8B:25:7A:3C:1E), queries the root certificate management ledger, and after confirming that the hardware serial number is a valid factory serial number, generates an activation instruction (activation instruction content: activation identifier 0x01 + activation validity period of 1 hour), which is encrypted using the SM4 algorithm (128-bit key, ECB encryption mode), and the encryption key is the root key of the device; (4) The cloud authentication center sends the activation command to the edge node through an encrypted channel (SM4 encryption). After receiving the command, the edge node forwards it to the corresponding vehicle terminal; (corresponding to Figure 4 Step S403: Issue activation command (SM4 encrypted); Step S404: Forward activation command to complete root credential activation. (5) After receiving the activation command, the vehicle terminal decrypts the root key, verifies the legality of the activation identifier, and completes the root credential decryption and activation after confirming that there is no error. After successful activation, it generates activation success feedback (carrying the activation timestamp: 20260305143025) and sends it to the edge node. The edge node synchronizes with the cloud authentication center, and the cloud updates the root credential management ledger and marks the device as "activated". If the activation command decryption fails or the activation identifier is invalid, the device refuses to enter the registration process and sends activation failure feedback to the edge node. The edge node records the failure log and synchronizes it to the cloud for easy troubleshooting.

[0141] (6) The vehicle terminal reads the root credential in the security chip, generates a first random number (random number: 0x9876543210FEDCBA) through the built-in random number generation module, encrypts the random number using the root key (SM4 algorithm), and constructs a registration request. The registration request includes the Device ID (58:8B:25:7A:3C:1E), the encrypted random number, and the device type identifier (vehicle terminal: TYPE-TERM); (corresponding to) Figure 4 Step S405: Send registration request (encrypted random number) (7) The vehicle terminal sends the registration request to the edge node (vehicle edge gateway). After receiving the request, the edge node records the request timestamp and transmits it directly to the cloud authentication center without additional verification; (corresponding to) Figure 4 Step S406: Forward the registration request and perform preliminary verification. (8) After receiving the registration request, the cloud authentication center verifies the legality of the Device ID (queries the root credential management ledger to confirm that the device has been activated), decrypts the encrypted random number through the root key, verifies the validity of the random number (to prevent replay attacks), and after confirming that the device identity is correct, proceeds to the collaborative credential package generation stage.

[0142] 2. Implementation of Collaborative Voucher Package Generation The cloud-based authentication center generates a collaborative credential package based on the device type of the vehicle terminal and the current network status (signal strength: -70dBm, network normal, network status code 0). Specific implementation details are as follows: (1) Local Derived Credential Generation: Based on the root key (0x1234567890ABCDEF1234567890ABCDEF) + edge node ID (GW-CAR-001) + timestamp (20260305143520), a short-term JWT token is generated using the national cryptographic SM3 algorithm (following GB / T32905-2016). The calculation logic is "SM3(root key|| edge node ID || timestamp|| first 8 bits of device ID: 58:8B:25:7A)", and the hash value output is 256 bits. The validity period of the generated local derived credential is set to 7 days (default value). The credential content includes device identity information, validity period, and edge node ID. (2) Cloud-derived certificate generation: Based on the root key + device current status code (normal: 0x00) + validity period (30 days), a short-term encryption certificate is generated using the SM2 algorithm. The key length is 256 bits. The certificate contains the device identity identifier, encryption public key, and validity period, and is used for direct communication between the device and the cloud. (3) Synchronization strategy configuration: Based on the requirements of the vehicle scenario, configure the synchronization strategy parameters: local authentication validity period of 7 days, cloud session timeout of 30 minutes, log synchronization cycle of 1 hour, credential renewal threshold (remaining 1 day), emergency authentication rules (emergency credential validity period of 24 hours, generation logic is SM3 (root key cache value || edge node ID || emergency identifier 00 || timestamp)). (4) Credential Packet Distribution: The cloud authentication center uses the SM4 algorithm (128-bit key, ECB encryption mode) to encrypt the collaborative credential packet and distributes it to the edge node through the encrypted channel. After receiving the packet, the edge node caches it (caching time is 30 days) and forwards it to the vehicle terminal. After receiving the packet, the vehicle terminal decrypts it using the root key, installs the local derived credential and the cloud derived certificate, completes the authentication initialization, and sends an initialization success feedback to the edge node. The edge node synchronizes with the cloud, and the cloud marks the device as "authenticated". (Corresponding to) Figure 4 Step S407: Generate collaborative credentials (local credentials + derived certificate + synchronization strategy); Step S408: Distribute credential packets (SM4 encrypted); Step S409: Forward credential packets and cache credential information; Step S410: Parse credentials and complete authentication initialization. 3. Implementation of Collaborative Authentication between Local and Cloud Platforms After authentication initialization is complete, the vehicle terminal enables rapid local access and synchronous collaboration with the cloud. The two core implementation scenarios are as follows: (1) Normal network scenario (network status code 0): ① Local Access: When the vehicle terminal and vehicle sensors (already certified) interact locally, the vehicle terminal sends a local authentication request to the edge node, carrying a local derived credential. Upon receiving the request, the edge node verifies the validity of the local derived credential (checking the validity period, device identity, and edge node ID). If the verification is successful, local interaction is allowed, enabling real-time data exchange between the vehicle's central control screen and the sensors. (Corresponding to...) Figure 4 Step S411: Send local derived credentials; Step S412: Verification passed, local linkage allowed. ② Cloud Synchronization: Edge nodes, following a synchronization strategy (once per hour), encrypt the authentication logs (including authentication time, device status, and authentication result) and device operating status of local devices using cloud-derived certificates (SM2 algorithm) and synchronize them to the cloud authentication center. The cloud performs consistency verification on the synchronized information (using the SM3 algorithm to verify data integrity) and stores the logs using a secure evidence storage method, forming a complete audit evidence chain. (Corresponding to...) Figure 4 Step S413: Send encrypted data (encrypted with cloud-derived certificate); Step S414: Relay data and synchronize authentication logs; Step S415: Verify data and issue feedback / policy; Step S416: Forward feedback / policy. (2) Network fluctuations and offline edge node scenarios (corresponding to) Figure 4 (Steps S417 to S424) ① Network fluctuation scenario (network status code 1): The vehicle terminal collects network status in real time and synchronizes it to the edge node and the cloud; the cloud dynamically adjusts the authentication strategy, extending the validity period of locally derived credentials to 14 days and adopting a lightweight SM4 encryption method (simplifying the encryption process and reducing computing power consumption); the edge node reduces the log synchronization frequency to once every 3 hours, while caching the synchronization data, and synchronizing it to the cloud in batches after the network stabilizes; at this time, the local authentication of the vehicle terminal and the edge node proceeds normally, ensuring uninterrupted linkage of the cockpit devices; (corresponding to Figure 4 Step S417: Report network fluctuation status; Step S418: Issue dynamic policy (extend certificate validity period); Step S419: Synchronize dynamic policy and optimize authentication parameters. ② Offline Edge Node Scenario (Network Status Code 2): After detecting a disconnection from the cloud, the edge node immediately activates the emergency authentication submodule. Based on the locally cached root credential information and emergency authentication rules, it generates a temporary local credential for the vehicle terminal (generated using the SM3 algorithm, valid for 24 hours, calculated as "SM3(root key cache value || GW-CAR-001 || 00 || 20260305154010)") and sends it to the vehicle terminal. The vehicle terminal uses the temporary local credential for local authentication to maintain the normal operation of core services. After the edge node restores network connectivity, it automatically synchronizes the emergency authentication logs and device interaction data during the network interruption to the cloud. The cloud verifies the legality of the temporary credential, generates a new collaborative credential package, and sends it to the edge node. The edge node forwards it to the vehicle device, updates the credential information, and invalidates the temporary credential, achieving seamless integration between offline services and cloud management. (Corresponding to...) Figure 4 Step S420: Detect network interruption and activate emergency policy; Step S421: Generate emergency credentials (SM3 hash, valid for 24 hours); Step S422: Use emergency credentials to maintain local core functions; Step S423: Network recovery and synchronize emergency logs; Step S424: Verify emergency credentials and issue new credentials; Step S425: Synchronize new credentials and invalidate emergency credentials. 4. Dynamic updates and revocation of implementation Combination Figure 5 The document provides a logic diagram for managing vouchers, enabling voucher renewal, cancellation, and dynamic strategy adaptation. Figure 5 In total, it includes: Step S501: Root certificate generation; Step S502, root credential activation; Step S503: One-time registration, dual derivation; Step S503 includes two sub-steps, S5031 and S5032, which are as follows: Step S5031, Local Derived Certificate (SM3); Step S5032, Cloud-derived certificate (SM2); Step S504, credential storage and caching device; Step S505: Renew the certificate; Step S506: Bidirectional cancellation of the voucher; Step S507, emergency credential generation; Step S508: The credential lifecycle ends.

[0143] The specific implementation is as follows: (1) Certificate Renewal: When the remaining validity period of the local derived certificate is 1 day (renewal threshold), the vehicle terminal automatically initiates a renewal request to the cloud through the edge node, carrying the Device ID and the current local derived certificate; the cloud, based on the root certificate and the device's current network status (signal strength -75dBm, normal), regenerates the local derived certificate (valid for 7 days) and the cloud derived certificate (valid for 30 days), and sends them to the device without re-registration; if the network is fluctuating when the renewal is initiated, the renewal request will be delayed until the network stabilizes and then automatically executed to ensure successful renewal; (corresponding to Figure 4 Step S426: The voucher is about to expire, send a renewal request; Step S427: Forward the renewal request; Step S428: Generate a new voucher and issue the renewal result; Step S429: Forward the new voucher and update the cache. (2) Credential Revocation: When an unauthorized external device (Device ID: 58:8B:25:7A:3C:20) is detected to have illegally accessed the system, the cloud authentication center generates a credential revocation list (containing the Device ID and root credential identifier of the unauthorized device) and broadcasts it to all in-vehicle devices through the edge nodes. Upon receiving the list, the edge nodes immediately reject the local authentication request of the unauthorized device, and the cloud simultaneously rejects its cloud communication request, achieving "one-time revocation, two-way invalidation". For in-vehicle scenarios, a credential revocation command can be manually initiated through the vehicle's central control system to quickly block the access of unauthorized devices. (Corresponding to...) Figure 4 Step S430: Issue a credential revocation list (illegal devices); Step S431: Deny connection, block illegal devices. (3) Dynamic strategy adaptation: The vehicle terminal collects its own operating status in real time (when the battery level is ≤20%) and synchronizes it to the edge node and the cloud. The cloud dynamically adjusts the strategy, extending the validity period of the local derived certificate to 14 days and reducing the log synchronization frequency to once every 6 hours, reducing the device's computing power consumption and improving battery life. When the device's battery level recovers to ≥20%, the cloud automatically adjusts back to the default strategy.

[0144] (III) Details of the Implementation of the Safety Protection Mechanism Combination Figure 6 The security protection mechanism logic diagram in this embodiment shows that a multi-layer protection system of "hardware storage + algorithm encryption + process verification + log evidence storage" is constructed, which can form a closed loop of multiple security protection systems, covering scenarios such as activation, transmission, verification, blocking, evidence storage, and emergency response, and can ensure the security of credentials, transmission, and data.

[0145] The specific implementation details are as follows: 1. Secure credential implementation (including root key security protection and storage 601, activation verification protection core 602): The root key is stored in the vehicle-mounted device's security chip, encrypted and pre-configured, requiring activation before use, thus preventing key leakage at the hardware level; derived credentials are generated using "root key + dynamic parameters," with the SM3 hash algorithm implemented as follows: the hash value output is 256 bits, the timestamp format is YYYYMMDDHHMMSS, the edge node network status code is assigned according to the actual network situation (0=normal, 1=fluctuating, 2=offline), and the first 8 digits of the Device ID are taken as a hexadecimal fragment to ensure the uniqueness of the derived credentials; local derived credentials, cloud-based derived certificates, and emergency credentials all adopt a short-term validity design to reduce the risk of leakage; 2. Transmission security implementation (including data transmission encryption protection 603, credential verification protection 604, and data integrity protection algorithm 605): All data, including registration requests, activation instructions, and credential packages, are transmitted through an encrypted channel, with the SM4 algorithm (128-bit key, ECB encryption mode) as the preferred choice and AES_128_ECB encryption as an alternative; digital signatures use the SM2 elliptic curve cryptography algorithm (256-bit key), suitable for low-power automotive scenarios; privacy data of automotive devices is encrypted and transmitted through cloud-derived certificates (SM2 algorithm) to ensure privacy is not leaked; 3. Behavioral security implementation (including 606 protection against unauthorized devices): Each authentication request carries a unique timestamp (accurate to the second), and timeout thresholds (30 seconds) are set at the cloud and edge nodes. Timeout requests are directly rejected to prevent replay attacks; identity forgery is prevented through binding verification between Device ID and hardware serial number; and credential misuse is prevented through binding verification between credentials and devices. 4. Audit security implementation (including log storage and protection 607): All authentication logs, emergency authentication records, and device status information are synchronized to the cloud and stored in an immutable manner, forming a complete chain of evidence from activation, registration, authentication to revocation. Logs can be queried and exported through the cloud backend to meet security audit and supervision needs. 5. Emergency security implementation (including emergency security protection 608): The validity period of the emergency certificate for edge nodes is strictly controlled to 24 hours, and the emergency identifier is fixed as "00" (1 byte). It is only used for local core business and does not have cloud communication permissions. After the edge node restores network connection, the emergency log is immediately synchronized to the cloud. After the cloud verifies the legality of the temporary certificate, a new certificate is issued and the invalid emergency certificate is removed to avoid security risks in emergency mode.

[0146] like Figure 7 As shown, Figure 7 A logical block diagram of an IoT device communication device applied to a cloud server, provided in an embodiment of this application, is included in the device 700, comprising: The first acquisition module 701 is used to respond to a communication request sent by an edge communication device, extract the local credentials in the communication request, and obtain the collaborative authentication credentials stored in the cloud server; the communication request is generated by the IoT device. The verification module 702 is used to verify the local credentials based on the collaborative authentication credentials and obtain the verification result; The first generation module 703 is used to generate a request response signal and send the request response signal to the edge communication device when the verification result is that the verification is passed. The request-response signal is used to generate a communication channel between IoT devices and cloud servers.

[0147] Furthermore, the verification module 702 includes: The acquisition submodule is used to retrieve the local verification credential and derived credential from the collaborative authentication credentials; The expiration verification submodule is used to verify the expiration dates of derived and local vouchers and obtain the expiration verification results. The validity verification submodule is used to perform validity verification on the local credential based on the local verification credential, and obtain the verification result, if the deadline verification result indicates that the deadline verification has passed.

[0148] Furthermore, the deadline verification submodule includes: The first determining unit is used to determine the first remaining validity period of the local voucher and the second remaining validity period of the derived voucher; The second determining unit is used to determine the duration verification result that has passed the duration verification when both the first remaining valid duration and the second remaining valid duration are greater than or equal to a preset duration threshold. The validity verification submodule includes: The matching and verification unit is used to match and verify local verification credentials with local credentials to obtain matching results; The third determining unit is used to determine the verification result that has been verified when the matching result indicates that there is a target credential that is the same as the local credential in the local verification credential and there is no historical verification success information for the local credential in the cloud server.

[0149] Furthermore, the device 700 also includes: The first determining module is used to determine the verification result of failure when the matching result indicates that there is no target credential identical to the local credential in the local verification credential, or that there is historical verification success information in the cloud server. The cancellation sending module is used to send credential cancellation commands to edge communication devices; The edge communication device is also used to delete local credentials in the IoT device in response to a credential revocation command, thereby rejecting the communication request.

[0150] Furthermore, the collaborative authentication credentials include local verification credentials and derived credentials; device 700 also includes: The first decryption module is used to respond to the encrypted registration command sent by the edge communication device, and decrypt the encrypted registration command based on the first key stored in the cloud server to obtain the registration command for the IoT device. The encrypted registration command is obtained by the IoT device in the registration allowed state by encrypting the original device identification code and a random number based on the second key. The second key and the original device identification code are both stored in the IoT device, and the second key is the same as the first key. The credential generation module is used to generate, in response to the registration instruction, a local credential containing the first root key and the communication node identifier of the edge communication device, and a derived credential containing the first root key and the authentication status of the IoT device. The credential sending module is used to send local credentials to edge communication devices and store local credentials in the cloud server in the form of local verification credentials; Edge communication devices are also used to store local credentials in the form of temporary local verification credentials and to send local credentials to IoT devices; IoT devices are also used to store local credentials to confirm successful registration; after successful registration, IoT devices can generate communication requests based on local credentials.

[0151] Furthermore, the device 700 also includes: The second decryption module is used to respond to the encrypted activation command sent by the edge communication device, and decrypt the encrypted activation command based on the first key to obtain the device identification code of the IoT device; the encrypted activation command is obtained by the IoT device encrypting the original device identification code based on the second key; The matching and verification module is used to match and verify the device identification code based on the verification database in the cloud server, and obtain the matching and verification result. The release generation module is used to generate an encrypted release activation command based on the first key, and to send the encrypted release activation command to the edge communication device, when the matching verification result shows that a verification code with the same device identification code exists in the verification database. Edge communication devices are also used to forward encrypted release activation commands to IoT devices; The IoT device is also used to decrypt the encrypted release activation command based on the second root key to obtain the release activation command, and, in response to the release activation command, to adjust the device state of the IoT device to an allowed registration state.

[0152] Furthermore, the device 700 also includes: The regeneration module is used to regenerate local credentials in response to a renewal request sent by the edge communication device. The renewal request is generated and sent to the edge communication device when the remaining validity period of the local credentials stored in the IoT device is less than a preset duration threshold. Re-execute the step of sending local credentials to the edge communication device to update the remaining validity period of the local credentials stored in the edge communication device and the IoT device.

[0153] like Figure 8 As shown, Figure 8 A logical block diagram of an IoT device communication device applied to an edge communication device is provided in an embodiment of this application. The IoT device communication device 800 applied to the edge communication device includes: The request sending module 801 is used to send a communication request to the cloud server in response to a communication request generated and sent by an IoT device. The second generation module 802 is used to generate a communication channel between the IoT device and the cloud server in response to the request response signal sent by the cloud server. The cloud server is used to respond to communication requests, verify the local credentials in the communication request, obtain the verification result, and, if the verification result is successful, generate a request response signal and send the request response signal to the edge communication device.

[0154] Furthermore, the IoT device communication device 800 applied to edge communication devices also includes: The temporary verification module is used to verify local credentials based on temporary local verification credentials stored in the edge communication device when the communication connection between the edge communication device and the cloud server is unavailable, and obtain the verification result. The temporary generation module is used to generate a temporary communication channel with IoT devices when the verification result is successful. Among them, IoT devices are used to perform temporary communication with edge communication devices through temporary communication channels.

[0155] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0156] It should be noted that, in the embodiments of this application, if the above-described system monitoring method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-accessible storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0157] Figure 9 This is a hardware entity diagram of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, the hardware entity of the electronic device 900 includes a processor 901 and a memory 902, wherein the memory 902 stores a computer program that can run on the processor 901, and the processor 901 executes the program to implement the steps in the method of any of the above embodiments.

[0158] The memory 902 stores computer programs that can run on the processor. The memory 902 is configured to store instructions and applications that can be executed by the processor 901. It can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data and video communication data) in the processor 901 and various modules in the electronic device 900. It can be implemented by flash memory or random access memory (RAM).

[0159] When the processor 901 executes the program, it implements the steps of the IoT device communication method provided in any of the above embodiments. The processor 901 typically controls the overall operation of the electronic device 900.

[0160] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0161] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0162] This application provides a computer-readable storage medium storing a computer program thereon. The computer-readable storage medium stores one or more programs, which can be executed by one or more processors. The computer program implements the IoT device communication method described above.

[0163] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the IoT device communication method described above.

[0164] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, devices, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0165] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable electronic device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable electronic device, generate instructions for implementing the process in the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0166] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable electronic device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0167] These computer program instructions may also be loaded onto a computer or other programmable electronic device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

Claims

1. A communication method for Internet of Things (IoT) devices, characterized in that, Applied to cloud servers; the method includes: In response to a communication request sent by an edge communication device, the local credentials in the communication request are extracted, and the collaborative authentication credentials stored in the cloud server are obtained; the communication request is generated by an IoT device. Based on the collaborative authentication credential, the local credential is verified to obtain the verification result; If the verification result is successful, a request response signal is generated and sent to the edge communication device. The request-response signal is used to generate a communication channel between the IoT device and the cloud server.

2. The method according to claim 1, characterized in that, The step of verifying the local credential based on the collaborative authentication credential to obtain a verification result includes: Obtain the local verification credential and derived credential from the collaborative authentication credential; The derived certificate and the local certificate are subjected to expiration verification to obtain the expiration verification result; If the deadline verification result indicates that the deadline verification is successful, the validity of the local verification credential is verified based on the local verification credential to obtain the verification result.

3. The method according to claim 2, characterized in that, The process of validating the validity period of the derived certificate and the local certificate to obtain the validity period verification result includes: Determine the first remaining validity period of the local certificate and the second remaining validity period of the derived certificate; If both the first remaining valid duration and the second remaining valid duration are greater than or equal to a preset duration threshold, a duration verification result indicating that the duration verification has passed is determined. The step of validating the local verification credential based on the local verification credential to obtain a verification result includes: The local verification credential and the local credential are matched and verified to obtain a matching result; If the matching result indicates that there is a target credential identical to the local credential among the local verification credentials, and there is no historical verification success information for the local credential in the cloud server, then a verification success result is determined.

4. The method according to claim 3, characterized in that, The method further includes: If the matching result indicates that there is no target credential identical to the local credential among the local verification credentials, or if the historical verification success information exists in the cloud server, a verification failure result is determined. Send a credential revocation command to the edge communication device; The edge communication device is further configured to delete the local credential in the IoT device in response to the credential revocation instruction, thereby rejecting the communication request.

5. The method according to any one of claims 1 to 4, characterized in that, The collaborative authentication credentials include local verification credentials and the derived credentials; the method further includes: In response to the encrypted registration instruction sent by the edge communication device, the encrypted registration instruction is decrypted based on the first key stored in the cloud server to obtain a registration instruction for the IoT device; the encrypted registration instruction is obtained by the IoT device in a registration-allowed state by encrypting the original device identifier code and a random number based on the second key; both the second key and the original device identifier code are stored in the IoT device, and the second key is the same as the first key; In response to the registration instruction, a local credential containing the first root key and the communication node identifier of the edge communication device is generated, as well as a derived credential containing the first root key and the authentication status of the IoT device. Send the local credentials to the edge communication device and store the local credentials in the cloud server as local verification credentials; The edge communication device is also used to store the local credential in the form of a temporary local verification credential and send the local credential to the IoT device; The IoT device is also used to store the local credentials to confirm successful registration; after successful registration, the IoT device can generate the communication request based on the local credentials.

6. The method according to claim 5, characterized in that, The method further includes: In response to the encrypted activation command sent by the edge communication device, the encrypted activation command is decrypted based on the first key to obtain the device identification code of the IoT device; the encrypted activation command is obtained by the IoT device encrypting the original device identification code based on the second key; Based on the verification database in the cloud server, the device identification code is matched and verified to obtain the matching and verification result; If the matching verification result indicates that a verification code identical to the device identifier exists in the verification database, an encrypted release activation instruction is generated based on the first root key, and the encrypted release activation instruction is sent to the edge communication device. The edge communication device is also used to forward the encrypted release activation command to the IoT device; The IoT device is further configured to decrypt the encrypted release activation instruction based on the second root key to obtain a release activation instruction, and, in response to the release activation instruction, adjust the device state of the IoT device to the allowed registration state.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: In response to a renewal request sent by the edge communication device, the local credential is regenerated; the renewal request is generated by the IoT device when the remaining validity period of the local credential stored in the IoT device is less than a preset duration threshold and sent to the edge communication device. The step of sending the local credential to the edge communication device is re-executed to update the remaining validity period of the local credential stored in the edge communication device and the IoT device.

8. A communication method for Internet of Things (IoT) devices, characterized in that, Applied to edge communication devices, the method includes: In response to a communication request generated and sent by an IoT device, the communication request is sent to the cloud server; In response to a request response signal sent by the cloud server, a communication channel is generated between the IoT device and the cloud server; The cloud server is configured to respond to the communication request by verifying the local credentials in the communication request, obtaining a verification result, and, if the verification result is successful, generating a request response signal and sending the request response signal to the edge communication device.

9. The method according to claim 8, characterized in that, The method further includes: If the communication connection between the edge communication device and the cloud server is unavailable, the local credential is verified based on the temporary local verification credential stored in the edge communication device to obtain the verification result. If the verification result is successful, a temporary communication channel is generated between the device and the IoT device. The IoT device is used to perform temporary communication with the edge communication device through the temporary communication channel.

10. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing a computer program that can run on the processor, the processor executing the computer program to implement the IoT device communication method according to any one of claims 1 to 7, or the IoT device communication method according to any one of claims 8 to 9.

Images