An Internet of Things device authentication method and system, an Internet of Things device, and a storage medium

Abstract

The application relates to the technical field of equipment manufacturing, in particular to an Internet of Things equipment authentication method and system, an Internet of Things equipment and a storage medium. The method is used for authenticating target equipment through triple data, and the triple data is stored in a cloud server. The method comprises the following steps: obtaining and saving a communication private key; a communication public key corresponding to the communication private key is stored in the cloud server; an authentication request signature is generated based on a device identifier of the target equipment and a key version number of a communication key, and the authentication request signature is sent to the cloud server; encrypted data and decryption information sent by the cloud server are received, the encrypted data is generated by encrypting the triple data through a key after the cloud server verifies the triple data, and the decryption information comprises temporary encrypted data used for generating the key; the encrypted data is decrypted based on the communication private key and the temporary encrypted data, and the triple data is obtained; and the target equipment is authenticated based on the triple data. The application can reduce production complexity and production cost.

Description

Technical Field

[0001] This invention relates to the field of equipment manufacturing technology, and in particular to an Internet of Things (IoT) device authentication method, system, IoT device, and storage medium. Background Technology

[0002] Currently, the mainstream IoT (Internet of Things) device authentication methods in the industry are mainly divided into two categories: triplet authentication and certificate authentication. Among them, triplet authentication is widely used in IoT devices in many fields such as consumer electronics, industrial control, and smart homes due to its simple technical implementation, low adaptation cost, and relaxed requirements on device hardware performance.

[0003] The triplet authentication primarily employs a one-device-one-secret scheme. This scheme assigns a unique productKey, deviceName, and deviceSecret triplet to each device. During the device manufacturing phase, the triplet and server address are burned into the chip's storage area. When the device is activated, it initiates authentication with the server using the pre-stored triplet, and the server verifies the device's legitimacy by comparing it with the ledger information. However, this traditional scheme of solidifying triplets during production has significant technical drawbacks. It not only increases the complexity and cost of the burning and verification processes on the production line, but also faces the maintenance challenge of not being able to remotely replace the triplet after it is leaked, requiring the device to be returned to the factory for repair. Furthermore, because the device is strongly bound to a specific IoT platform, switching between platforms requires re-burning the triplet or even modifying the software, severely restricting the device's operational flexibility and platform compatibility. Summary of the Invention

[0004] This invention provides an IoT device authentication method, system, IoT device, and storage medium to address the problems of high process complexity and cost, as well as poor flexibility and low compatibility.

[0005] This invention discloses an authentication method for Internet of Things (IoT) devices, used to perform triple data authentication on target devices, wherein the triple data is stored in a cloud server;

[0006] The authentication method for the IoT device includes: Acquire and save the communication private key of the communication key; the communication key is uniquely generated for the target device, and the communication public key of the communication key is bound to the device identifier of the target device and stored in the cloud server; An authentication request signature is generated based on the device identifier of the target device and the key version number of the communication key, and the authentication request signature is sent to the cloud server. The cloud server receives encrypted data and decryption information. The encrypted data is generated by the cloud server after verifying the authentication request signature and encrypting the triple data with a key. The decryption information includes temporary encrypted data used to generate the key. The encrypted data is decrypted based on the communication private key and the temporary encrypted data to obtain the triplet data; The target device is authenticated based on the triplet data.

[0007] Optionally, the step of generating an authentication request signature based on the device identifier of the target device and the key version number of the communication key includes: The device identifier, the key version number, and the dynamic random number are sorted in ASCII order and then concatenated to form the string to be signed. The SHA256withECDSA algorithm is used to sign the string to be signed using the communication private key to generate an authentication request signature; The device identifier, the key version number, the dynamic random number, and the authentication request signature are sent to the cloud server.

[0008] Optionally, the step of verifying the signature of the authentication request by the cloud server includes: The cloud server determines whether the dynamic random number is consistent with the previously received dynamic random number; If not, then the device identifier, the key version number, and the dynamic random number are sorted in ASCII order and concatenated to form the string to be verified; The communication public key is obtained based on the device identifier and the key version number, and the string to be verified and the string to be signed are determined based on the communication public key; If so, then the verification is considered to have generated the triplet data for the target device.

[0009] Optionally, the step of encrypting the triple data with a key includes: The cloud server generates temporary key pairs based on the secp256r1 elliptic curve. The ECDH key negotiation algorithm is used to generate a derived key based on the temporary public key of the temporary key pair and the communication public key; The encrypted data is obtained by encrypting the triplet data using the derived key.

[0010] Optionally, the decryption information includes the temporary public key; The step of decrypting the encrypted data based on the communication private key and the temporary encrypted data includes: A shared key is generated based on the communication private key and the temporary public key, and a decryption key for the derived key is generated based on the shared key using the HKDF algorithm; The encrypted data is decrypted using the decryption key.

[0011] Optionally, the authentication method for the IoT device further includes: The abnormal working status information of the target device is sent to the cloud server, so that the cloud server invalidates the triplet data, generates new triplet data, and generates corresponding new encrypted data and new decryption information based on the new triplet data; Receive and obtain the new triplet data based on the new encrypted data and the new decryption information.

[0012] The present invention also discloses an authentication method for Internet of Things (IoT) devices, which is applied to a device authentication system. The device authentication system includes factory-end devices, target devices, mobile devices with corresponding applications installed, cloud servers, and device servers. The cloud server and the target device interact with each other through the application. The authentication method for the IoT device includes: The target device acquires and stores the communication private key of the communication key, which is uniquely generated for the target device. The cloud server obtains the public key of the communication key and binds and stores the communication key with the device identifier of the target device; The target device generates an authentication request signature based on the device identifier of the target device and the key version number of the communication key, and sends the authentication request signature to the cloud server; The cloud server verifies the authentication request signature, generates triplet data for the target device when the verification is successful, generates a key through temporary encrypted data, encrypts the triplet data with the key to generate encrypted data, and sends the temporary encrypted data and the encrypted data to the target device. The target device receives encrypted data and temporary encrypted data sent by the cloud server; it decrypts the encrypted data based on the communication private key and the temporary encrypted data to obtain the triplet data; The target device initiates an authentication request to the device server based on the triplet data. When the verification is successful, the device server sends a pass certificate to the target device.

[0013] This invention also discloses an authentication system for Internet of Things (IoT) devices, comprising: The acquisition module is used to acquire and save the communication private key of the communication key; the communication key is uniquely generated for the target device, and the communication public key of the communication key is bound to the device identifier of the target device and stored in the cloud server; The generation module is used to generate an authentication request signature based on the device identifier of the target device and the key version number of the communication key, and send the authentication request signature to the cloud server; The receiving module is used to receive encrypted data and decryption information sent by the cloud server. The encrypted data is generated by the cloud server after verifying the authentication request signature and encrypting the triple data with a key. The decryption information includes temporary encrypted data used to generate the key. The decryption module is used to decrypt the encrypted data based on the communication private key and the temporary encrypted data to obtain the triplet data; An authentication module is used to authenticate the target device based on the triplet data.

[0014] The present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0015] The present invention also discloses an Internet of Things (IoT) device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps described above.

[0016] The beneficial effects of the IoT device authentication method, system, IoT device, and storage medium provided in this invention are as follows: through the coherent process of communication key generation and storage, signature authentication, encrypted data reception and decryption, and device server authentication, cost reduction, efficiency improvement, and security upgrade are achieved across the entire chain. A unique asymmetric communication key pair is generated for the target device. The communication private key is stored in a secure storage area and will never be leaked. The communication public key is bound to the device identifier and reported to the cloud server. This eliminates the complex processes of triple pre-installation and verification in traditional solutions, significantly reducing production line operating costs and technical barriers, while strengthening the security foundation of the device's core identity. A signature is generated based on the device identifier and key version number and verified in the cloud, decoupling the device's core identity from the platform access credentials. This simplifies the authentication logic and avoids the risk of identity forgery. The encrypted triple data dynamically generated after successful cloud verification is received and decrypted, completely solving the leakage risks in the production and transportation of traditional triples. The dynamic distribution feature of triples supports remote rapid replacement after leakage and seamless switching of devices across IoT platforms without requiring hardware modifications or software reinstallation, significantly reducing maintenance and migration costs. Finally, device and platform authentication is completed based on the triples. This not only conforms to IoT industry standard processes and ensures solution compatibility, but also forms a two-layer security protection with the identity verification of the preceding communication key, achieving a balance between security and efficiency throughout the entire process of production, transmission, authentication, and maintenance. Attached Figure Description

[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a flowchart illustrating an embodiment of the authentication method for IoT devices provided by the present invention; Figure 2 This is a schematic diagram illustrating an application scenario of the authentication method for IoT devices provided by this invention; Figure 3 This is a flowchart illustrating another embodiment of the authentication method for IoT devices provided by the present invention; Figure 4 This is a schematic diagram of the device authentication system provided by the present invention; Figure 5 This is a schematic diagram of an embodiment of the authentication system for IoT devices provided by the present invention; Figure 6 This is a schematic diagram of the internal structure of an IoT device in one embodiment of the present invention.

[0018] The labels for the attached figures are as follows: 10. Equipment authentication system; 11. Factory-side equipment; 12. Target equipment; 13. Mobile equipment; 14. Cloud server; 15. Equipment server; 20. Authentication system for IoT devices; 21. Acquisition module; 22. Generation module; 23. Receiving module; 24. Decryption module; 25. Authentication module. Detailed Implementation

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0020] Please refer to the following: Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating an embodiment of the authentication method for IoT devices provided by the present invention. Figure 2 This is a schematic diagram illustrating an application scenario of the authentication method for IoT devices provided by this invention. The target device 12 is an IoT (Internet of Things) device. The target device 12 and the mobile device 13 connect via a first wireless network (e.g., Bluetooth, WiFi). The first wireless network can flexibly select short-range communication networks such as Bluetooth (including classic Bluetooth and BLE Low Energy Bluetooth) or WiFi (such as mainstream protocols like WiFi 4 / 5 / 6) according to the actual application scenario requirements. Simultaneously, the mobile device 12 establishes a remote communication connection with the cloud server 14 via a second wireless network. The second wireless network is a public communication network with wide-area coverage capabilities, typically such as 4G, 5G mobile communication networks, or public WiFi networks. Leveraging the wide-area coverage characteristics of the second wireless network, the mobile device can overcome spatial limitations and achieve stable data interaction with the remote cloud server, building a reliable data transmission bridge for indirect communication between the target IoT device and the cloud server. The mobile device 13 is pre-installed with an application program compatible with the target device 12. This application, as the core interaction hub, not only initiates connection requests and completes connection pairing with the target device 12, but also handles subsequent data relay and interactive control.

[0021] The authentication method for IoT devices provided by this invention includes the following steps: S101: Obtain and save the communication private key of the communication key; the communication key is uniquely generated for the target device, and the communication public key of the communication key is bound to the device identifier of the target device and stored on the cloud server.

[0022] In a specific implementation scenario, during the mass production of the target equipment, the production line employs an automated "one machine, one key" generation mechanism. After the core hardware assembly of each target device is completed, the generation process of a dedicated communication key is immediately triggered. This communication key uses an asymmetric encryption algorithm to generate a key pair, ensuring the uniqueness and anti-cracking capability of the communication key. After generation, the communication private key from the key pair is burned into the secure storage area built into the target device. Optional storage media include security chips, trusted platform modules, and security elements. Such storage areas possess core characteristics such as physical tamper-proofing, logical encryption isolation, and resistance to side-channel attacks. This hardware-level protection prevents the communication private key from being illegally read, tampered with, or exported, strictly ensuring that the communication private key never leaves the target device after its generation.

[0023] The communication public key corresponding to the communication private key and the unique device identifier of the target device (such as the factory serial number, hardware MAC address, chip unique ID, etc.) are directly reported to the cloud server through an encrypted transmission channel built within the factory. In order to realize subsequent device identity verification, full lifecycle tracking and management, after receiving the public key, the cloud server immediately binds and stores the communication public key and the device identifier.

[0024] Compared to the multiple cumbersome processes that factories need to undertake in traditional authentication schemes, such as generating triples (including device certificate, device key, and device ID), accurately burning each device, verifying burning results, and maintaining ledger associations, the factory in this embodiment only needs to complete the communication key generation process. It does not need to get involved in any complex triple-related processing procedures, which greatly shortens the production cycle of a single device, reduces the need for customized modification of production line equipment and the technical threshold for operators, and reduces production errors caused by improper triple processing, thus significantly improving the scale production efficiency and stability of the production line.

[0025] S102: Generate an authentication request signature based on the device identifier of the target device and the key version number of the communication key, and send the authentication request signature to the cloud server.

[0026] In a specific implementation scenario, the target device generates an authentication request signature based on its device identifier (such as the factory serial number, hardware MAC address, chip unique serial number, etc.) and the key version number of the communication key, according to preset rules. For example, the target device first converts the field contents of the device identifier and key version number into a unified character encoding format (such as ASCII encoding), and then sorts and concatenates them according to the lexicographical order of the field names to form a structured string to be signed. Subsequently, the target device calls the communication private key in the built-in secure storage area and uses a preset asymmetric encryption signature algorithm (such as the SHA256withECDSA algorithm adapted to the lightweight requirements of IoT devices) to encrypt the string to be signed, generating an authentication request signature with tamper-proof and anti-forgery characteristics. In this process, the communication private key never leaves the secure storage area and the signing operation is only performed inside the target device's chip, eliminating the risk of communication private key leakage at the source.

[0027] In one implementation scenario, the unique device identifier of the target device, the currently effective communication key version number, and the random number dynamically generated by the device in real time are obtained (the random number is used to prevent replay attacks on subsequent requests and has one-time validity); after converting the field names and field values ​​of the above three fields according to a unified character encoding format (ASCII encoding), only the field values ​​are extracted and sorted according to ASCII code order.

[0028] The sorted device identifier field value, key version number field value, and dynamic random number field value are concatenated sequentially to form a structured string to be signed without separators, ensuring that the concatenation rules are completely consistent with the signature verification rules preset by the cloud server. The target device calls the communication private key in the built-in secure storage area and uses the SHA256withECDSA asymmetric encryption signature algorithm to perform encryption signature operation on the string to be signed within the secure storage area, generating an authentication request signature with unique identity, tamper-proof, and anti-forgery characteristics. The original fields involved in the signing (device identifier, key version number, dynamic random number) and the generated authentication request signature are packaged into a unified format authentication request data packet, which is sent to the mobile device through the first wireless network between the target device and the mobile device, and then relayed by the mobile device to the cloud server through a second wireless network, for the cloud server to complete subsequent identity verification.

[0029] S103: Receives encrypted data and decryption information sent by the cloud server. The encrypted data is generated by the cloud server after verifying the authentication request signature and encrypting the triple data with a key. The decryption information includes temporary encrypted data used to generate the key.

[0030] In a specific implementation scenario, after receiving a data packet including the authentication request signature, the cloud server first extracts the dynamic random number from the data packet; it then retrieves the recently stored random number verification ledger (which records all dynamic random numbers received within a preset time window) to determine if the currently received dynamic random number exists in the ledger. If it exists, the request is determined to be a duplicate submission attack request, and the authentication process is directly rejected, terminating subsequent operations. If it does not exist, the dynamic random number is stored in the verification ledger and timestamped, and the next step is executed.

[0031] The cloud server converts the received device identifier, key version number, and dynamic random number field values ​​into ASCII encoding format according to rules that are completely consistent with those of the target device. Then, it sorts them in ASCII code order and concatenates them without separators to generate the string to be verified.

[0032] Because the signature is one-way and irreversible, the cloud server cannot obtain the string to be signed from the device; it can only complete the verification by reproducing the same source string according to rules. The cloud server matches and queries a pre-established device identifier-communication public key association ledger based on the received device identifier and key version number. The key version number is used to adapt to scenarios where the device's communication key is iteratively updated, ensuring that the retrieved key is the unique communication public key currently in effect for the target device, avoiding verification failure due to public key version mismatch. The cloud server uses the SHA256withECDSA verification algorithm, taking the string to be verified, the authentication request signature, and the retrieved communication public key as input parameters to perform the verification operation. Specifically, first, the string to be verified is hashed using SHA256 to generate a string hash value. Then, the communication public key is used to perform elliptic curve reverse verification on the authentication request signature to determine whether the signature is generated by the hash value of the string to be verified and the communication private key paired with the current communication public key.

[0033] If the signature verification operation succeeds, it means that the string to be verified and the string to be signed on the device are from the same source, and the signature was generated using a valid private key. The cloud server then confirms the target device's legitimate identity. Based on this legitimate identity, the cloud server generates a unique triplet (productKey, deviceName, deviceSecret) for the target device and stores it in association with the device identifier for subsequent device authentication.

[0034] If the signature verification fails, the device is determined to be an illegal counterfeit device or the requested data has been tampered with. The authentication process is terminated directly, and the abnormal information is recorded in the security log.

[0035] The cloud server uses a combination of ECDH key negotiation, HKDF key derivation, and symmetric encryption to encrypt and protect the triplet data. Specifically, the cloud server generates a one-time temporary public-private key pair based on the elliptic curve secp256r1 algorithm. This temporary key pair is exclusive to this encryption operation and expires after a single use, avoiding security risks caused by key reuse. The cloud server then uses the pre-stored communication public key of the target device, combined with the temporary private key of the temporary key pair, to calculate a shared key exclusively for both parties using the ECDH key negotiation algorithm. This shared key does not need to be transmitted over the network; it is calculated and generated independently by both the cloud and the device.

[0036] The cloud server employs the HKDF key derivation algorithm, using the cloud-based temporary public key as the salt value and the device communication public key as the info context information. It performs extraction and expansion operations on the shared key to derive a derived key with high randomness and uniqueness. The cloud server then uses a lightweight and efficient symmetric encryption algorithm (such as AES-256-GCM, balancing encryption efficiency and security) to encrypt the triplet data using the derived key, generating encrypted data that cannot be cracked by a third party.

[0037] The cloud server packages the encrypted encrypted data and the temporary public key of the temporary key pair into a unified data packet for distribution; the temporary public key is the core basis for the device to subsequently calculate the shared key and decrypt the ciphertext, and it needs to be distributed synchronously with the ciphertext.

[0038] The target device receives encrypted data and decryption information sent by a cloud server through a mobile device with which it has established a short-range communication connection. The decryption information is temporary encrypted data used to generate a key. This temporary encrypted data may be a temporary public key, which is a core parameter used to generate the decryption key, rather than the direct decryption key itself.

[0039] S104: Decrypt the encrypted data based on the communication private key and temporary encrypted data to obtain the triple data.

[0040] In a specific implementation scenario, after receiving data, the target device first performs integrity verification (such as CRC cyclic redundancy check) on the encrypted data and decrypted information to confirm that the data packet has not been tampered with or lost during transmission, and then initiates the subsequent decryption process.

[0041] Specifically, the target device extracts the temporary public key from the received decryption information, calls the communication private key in the built-in secure storage area, and executes the ECDH key negotiation algorithm based on the elliptic curve secp256r1; using the communication private key and the cloud temporary public key as algorithm input parameters, it calculates a shared key that is completely consistent with the cloud server.

[0042] The target device uses the exact same HKDF key derivation parameters and procedures as the cloud server to perform key derivation operations. It uses the shared key as the original key, the temporary public key as the salt value, and its own communication public key as the info context information. It performs a two-step HKDF extraction and expansion operation to generate a decryption key that matches the derived key.

[0043] The target device uses the same symmetric encryption algorithm as the cloud encryption algorithm, and uses the derived decryption key as the key to decrypt the received encrypted data; after decryption, the plaintext triple data is extracted.

[0044] S105: Authenticate the target device based on triplet data.

[0045] In a specific implementation scenario, the device server address is obtained from the triple data. The target device establishes a stable transmission link with the device server based on the device server address. The target device generates a verification request data packet based on the triple data. The verification request data packet includes the product identifier (productKey), the device identifier (deviceName), and the identity verification signature (deviceSecret). After receiving the verification request data packet, the device server performs a verification operation. It retrieves the device management ledger for the corresponding product using the productKey, and then queries the ledger using the deviceName as an index to see if there is a registration record for the device and the bound deviceSecret. Using the same signature algorithm as the device, it performs a signature operation on the random challenge factor using the deviceSecret stored in the ledger, and compares the operation result with the signature value sent by the device; if the two are completely consistent, it is determined that the device holds a valid deviceSecret.

[0046] If the verification server confirms that the target device is a legitimate and authorized device, it sends a pass certificate, assigns a temporary session key and business operation permissions, establishes an end-to-cloud encrypted communication channel, and the device can enter the normal business interaction state. If the verification fails, the device server immediately disconnects the communication link, records the abnormal verification request in the security log, and limits the number of times the device can repeat the verification within a preset time window to prevent brute-force attacks.

[0047] When equipment malfunctions and requires revocation or update of credentials, traditional solutions often require the equipment to be returned to the factory to rewrite the triplet, or to complete the update through a complex local configuration process, resulting in high maintenance costs and operational complexity.

[0048] In this solution, the core identity credential of the target device is the communication key (not the triplet). The communication private key is permanently stored in the device's secure storage area and will never be leaked. The cloud server can verify the legitimacy of the target device through the device identifier and the communication public key, which is unrelated to the triplet data. Therefore, the triplet data is only a temporary credential for the device to obtain platform access permissions, not the identity identifier of the target device.

[0049] In one embodiment, when a triplet leak is detected, the leaked old triplet is invalidated in the device ledger on the original device server, and access permissions for the old credentials are restricted. This triggers the generation process of a new triplet. The target device does not need to return to the factory or perform local operations; it only needs to re-initiate the authentication request (signing the device identifier and key version number with the communication private key), i.e., re-execute step S102. After the cloud server verifies the signature, it generates new triplet data, encrypts it, and sends it to the target device. The target device decrypts the new triplet data and directly replaces the old triplet with the new triplet data, then executes step S103 and subsequent steps to restore secure communication with the device server.

[0050] In one embodiment, when an abnormal working state is detected in the target device (e.g., unauthorized login attempts, data transmission tampering, abnormal interruption of the communication link with the device server, parameter fluctuations exceeding a preset threshold, etc.), the target device immediately sends abnormal working state information, including the abnormal type, the timestamp of the abnormal occurrence, and the device's current operating parameters, to the cloud server via the mobile device. After receiving and verifying the authenticity and validity of the abnormal information, the cloud server first marks the original triplet data corresponding to the target device as invalid in the device management ledger, restricts all access permissions of the original triplet, and eliminates the risk of it being illegally used. The cloud server then generates a unique new triplet for the target device and uses the same encryption mechanism as described above to generate corresponding new encrypted data based on the new triplet. Simultaneously, it generates a temporary public key for decryption (i.e., new decryption information). The cloud server then relays the new encrypted data and decryption information to the target device via a mobile device relay. Upon receiving the new encrypted data and decryption information, the target device calls the communication private key stored in the secure storage area and, following the same decryption process as when the triplet was first obtained, calculates the shared key and derived key, decrypts the encrypted data, and obtains the new triplet. It then overwrites the original triplet data stored locally, completing the secure update of the triplet.

[0051] In another embodiment, when the cloud server needs to switch, the target device's communication public key and device identifier are entered into the new cloud server's management ledger to complete device identity registration. The target device initiates an authentication request to the new platform, signing it with its communication private key based on a dynamically random number of the device identifier key version number, and sends it to the new cloud server. That is, step S102 and subsequent steps are executed for the new cloud server. The new cloud server verifies the signature according to the rules, confirms the device's legitimacy, generates a unique triplet for the new platform, and encrypts and distributes it; the target device decrypts the new triplet to obtain it, and can then access the device server based on the new credentials, achieving seamless migration of business data.

[0052] This invention decouples basic identity credentials (communication keys) and platform access credentials (triples), upgrading the static credentials embedded in the device in traditional solutions to replaceable credentials that are dynamically generated in the cloud. This not only solves the problem of emergency handling of credential leakage, but also enables flexible switching of cloud servers, significantly reducing the complexity of the entire system from an operational perspective.

[0053] As described above, this embodiment generates a unique asymmetric communication key pair for each device, stores the private key in a secure storage area and never leaks it, and binds the public key to the device identifier and reports it to the cloud server. This eliminates all production operations related to triples, eliminates the need for customized programming equipment, and removes the need to manage the storage and transmission of triples, significantly reducing the technical threshold and operating costs of the production line. Signatures are generated based on the device identifier and key version number, rather than relying on triples. The private key never leaves the secure storage area during the signing process, ensuring that the signature cannot be forged. The cloud server can verify the signature and confirm the device's legitimacy using the bound public key. This avoids the limitations of traditional solutions where triples are pre-installed and bound to the platform, and simplifies the verification logic, eliminating the need to handle multi-layered key nesting and reducing the development and debugging complexity of the cloud server and the device. The system receives encrypted and decrypted information from the cloud server, decrypts the encrypted data based on the communication private key and temporary encrypted data, and obtains triplet data. The triplet data is upgraded from a production-fixed certificate to a dynamically issued certificate in the cloud. If the triplet is leaked, it can be quickly replaced remotely without the need for equipment to be returned to the factory or on-site operation. Only the triplet needs to be regenerated and encrypted in the cloud and issued. After the device decrypts it, it can replace the old certificate. Secondly, it supports dynamic switching of cloud servers for devices. As long as the new cloud server enters the device identifier-communication public key ledger, the device can initiate signature authentication to the new platform to obtain new triplet data. The entire process does not require modification of device hardware or software, reducing cross-platform migration costs.

[0054] Please refer to the following: Figure 3 and Figure 4 , Figure 3 This is a flowchart illustrating another embodiment of the authentication method for IoT devices provided by the present invention. Figure 4This is a schematic diagram of the device authentication system provided by the present invention. The device authentication system 10 is used to authenticate target devices. The device authentication system includes a factory-side device 11, a target device 12, a mobile device 13 with a corresponding application installed, a cloud server 14, and a device server 15. The factory-side device 11 and the target device 12 are connected. The target device 12 is connected to the mobile device 13 through a first wireless network. The mobile device 13 is connected to the cloud server 14 through a second wireless network. The target device 12 is connected to the device server 15 through a third wireless network.

[0055] Factory-side device 11 is a dedicated configuration device deployed on the production line. It connects to target device 12 via wired or dedicated short-range wireless connection, and the connection is limited to the configuration phase before the device leaves the production line. Target device 12 and mobile device 13 with a dedicated application installed establish a point-to-point communication connection via a first wireless network (e.g., a low-power short-range wireless network). Mobile device 13 with a dedicated application installed establishes a remote communication connection with cloud server 14 via a second wireless network (e.g., a wide-area public wireless network). After completing activation authentication and acquiring and storing triplet data, target device 12 establishes a stable business communication connection with device server 15 via a third wireless network (e.g., a dedicated wide-area network for IoT).

[0056] The authentication method for IoT devices provided by this invention includes: S201: The factory-side equipment generates a unique communication key for the target device.

[0057] S202: The target device obtains and saves the communication private key of the communication key.

[0058] S203: The public key for obtaining the communication key from the cloud server.

[0059] S204: The cloud server binds and stores the communication key with the device identifier of the target device.

[0060] S205: The target device generates an authentication request signature based on the target device's device identifier and the key version number of the communication key.

[0061] S206: The target device sends the authentication request signature to the cloud server.

[0062] S207: The cloud server verifies the authentication request signature, generates triplet data for the target device when the verification is successful, generates a key through temporary encrypted data, and encrypts the triplet data with the key to generate encrypted data.

[0063] S208: The cloud server sends temporary encrypted data and encrypted data to the target device.

[0064] S209: The target device receives encrypted data and temporary encrypted data sent by the cloud server; it decrypts the encrypted data based on the communication private key and the temporary encrypted data to obtain the triple data.

[0065] S210: The target device initiates an authentication request to the device server based on the triple data.

[0066] S211: The device server sends a pass certificate to the target device when the verification is successful.

[0067] The contents of steps S201-S211 have been described in detail above and will not be repeated here.

[0068] As described above, the entire device authentication system, through a multi-level and differentiated network connection design, achieves full-process control of localized production configuration, relayed activation authentication, and dedicated business interaction, which not only ensures the security of device identity authentication but also improves the system's deployment flexibility and ease of operation and maintenance.

[0069] Please see Figure 5 , Figure 5 This is a schematic diagram of an embodiment of the authentication system for IoT devices provided by the present invention. The authentication system 20 for IoT devices includes: an acquisition module 21, a generation module 22, a receiving module 23, a decryption module 24, and an authentication module 25.

[0070] The acquisition module 21 is used to acquire and save the communication private key of the communication key; the communication key is uniquely generated for the target device, and the communication public key of the communication key is bound to the device identifier of the target device and stored on the cloud server; the generation module 22 is used to generate an authentication request signature based on the device identifier of the target device and the key version number of the communication key, and send the authentication request signature to the cloud server; the receiving module 23 is used to receive encrypted data and decryption information sent by the cloud server, the encrypted data is generated by the cloud server after verifying the authentication request signature and encrypting the triple data with the key, and the decryption information includes temporary encrypted data used to generate the key; the decryption module 24 is used to decrypt the encrypted data based on the communication private key and the temporary encrypted data to obtain the triple data; the authentication module 25 is used to authenticate the target device based on the triple data.

[0071] The generation module 22 is used to sort the device identifier, key version number and dynamic random number in ASCII order and then concatenate them into a string to be signed; it uses the SHA256withECDSA algorithm and the communication private key to sign the string to be signed to generate an authentication request signature; and it sends the device identifier, key version number and dynamic random number and authentication request signature to the cloud server.

[0072] The cloud server determines whether the dynamic random number is consistent with the previously received dynamic random number. If not, it concatenates the device identifier, key version number, and dynamic random number in ASCII order to form the string to be verified. It obtains the communication public key based on the device identifier and key version number, and determines whether the string to be verified and the string to be signed match based on the communication public key. If they match, it is considered that the verification generates triplet data for the target device.

[0073] The cloud server generates temporary key pairs based on the secp256r1 elliptic curve; it uses the ECDH key negotiation algorithm to generate derived keys based on the temporary public key and the communication public key of the temporary key pairs; and it encrypts the triple data using the derived key to obtain the encrypted data.

[0074] The decrypted information includes a temporary public key; the decryption module 24 is used to generate a shared key based on the communication private key and the temporary public key, and to generate a decryption key based on the derived key using the HKDF algorithm; the encrypted data is decrypted using the decryption key.

[0075] The authentication module 25 is used to send abnormal working status information of the target device to the cloud server, so that the cloud server invalidates the triplet data and generates new triplet data, and generates corresponding new encrypted data and new decryption information based on the new triplet data; and receives and obtains new triplet data based on the new encrypted data and new decryption information.

[0076] As described above, this embodiment generates a unique asymmetric communication key pair for each device, stores the private key in a secure storage area and never leaks it, and binds the public key to the device identifier and reports it to the cloud server. This eliminates all production operations related to triples, eliminates the need for customized programming equipment, and removes the need to manage the storage and transmission of triples, significantly reducing the technical threshold and operating costs of the production line. Signatures are generated based on the device identifier and key version number, rather than relying on triples. The private key never leaves the secure storage area during the signing process, ensuring that the signature cannot be forged. The cloud server can verify the signature and confirm the device's legitimacy using the bound public key. This avoids the limitations of traditional solutions where triples are pre-installed and bound to the platform, and simplifies the verification logic, eliminating the need to handle multi-layered key nesting and reducing the development and debugging complexity of the cloud server and the device. The system receives encrypted and decrypted information from the cloud server, decrypts the encrypted data based on the communication private key and temporary encrypted data, and obtains triplet data. The triplet data is upgraded from a production-fixed certificate to a dynamically issued certificate in the cloud. If the triplet is leaked, it can be quickly replaced remotely without the need for equipment to be returned to the factory or on-site operation. Only the triplet needs to be regenerated and encrypted in the cloud and issued. After the device decrypts it, it can replace the old certificate. Secondly, it supports dynamic switching of cloud servers for devices. As long as the new cloud server enters the device identifier-communication public key ledger, the device can initiate signature authentication to the new platform to obtain new triplet data. The entire process does not require modification of device hardware or software, reducing cross-platform migration costs.

[0077] Figure 6 A schematic diagram of the internal structure of an IoT device in one embodiment is shown. This IoT device can specifically be a terminal or a server. Figure 6 As shown, the IoT device includes a processor, memory, and network interface connected via a system bus. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and may also store a computer program. When executed by the processor, this computer program enables the processor to implement the IoT device authentication method. The internal memory may also store a computer program, which, when executed by the processor, enables the processor to implement the IoT device authentication method. Those skilled in the art will understand that… Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0078] In one embodiment, an Internet of Things (IoT) device is provided, including a memory and a processor. The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps described above.

[0079] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, causes the processor to perform the steps described above.

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

[0081] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0082] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Those skilled in the art can modify the technical solutions described in the above embodiments, or make equivalent substitutions for some of the technical features; and all such modifications and substitutions should fall within the protection scope of the appended claims of the present invention.

[0083] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Those skilled in the art can modify the technical solutions described in the above embodiments, or make equivalent substitutions for some of the technical features; and all such modifications and substitutions should fall within the protection scope of the appended claims of the present invention.

Claims

1. An authentication method for Internet of Things (IoT) devices, characterized in that, Used for triple data authentication of target devices, wherein the triple data is stored in a cloud server; The authentication method for the IoT device includes: Acquire and save the communication private key of the communication key; the communication key is uniquely generated for the target device, and the communication public key of the communication key is bound to the device identifier of the target device and stored in the cloud server; An authentication request signature is generated based on the device identifier of the target device and the key version number of the communication key, and the authentication request signature is sent to the cloud server. The cloud server receives encrypted data and decryption information. The encrypted data is generated by the cloud server after verifying the authentication request signature and encrypting the triple data with a key. The decryption information includes temporary encrypted data used to generate the key. The encrypted data is decrypted based on the communication private key and the temporary encrypted data to obtain the triplet data; The target device is authenticated based on the triplet data.

2. The authentication method for IoT devices according to claim 1, characterized in that, The step of generating an authentication request signature based on the device identifier of the target device and the key version number of the communication key includes: The device identifier, the key version number, and the dynamic random number are sorted in ASCII order and then concatenated to form the string to be signed. The SHA256withECDSA algorithm is used to sign the string to be signed using the communication private key to generate an authentication request signature; The device identifier, the key version number, the dynamic random number, and the authentication request signature are sent to the cloud server.

3. The authentication method for IoT devices according to claim 2, characterized in that, The cloud server verifies the signature of the authentication request, including: The cloud server determines whether the dynamic random number is consistent with the previously received dynamic random number; If not, then the device identifier, the key version number, and the dynamic random number are sorted in ASCII order and concatenated to form the string to be verified; The communication public key is obtained based on the device identifier and the key version number, and the string to be verified and the string to be signed are determined based on the communication public key; If so, then the verification is considered to have generated the triplet data for the target device.

4. The authentication method for IoT devices according to claim 1, characterized in that, The step of encrypting the triplet data using a key includes: The cloud server generates temporary key pairs based on the secp256r1 elliptic curve. The ECDH key negotiation algorithm is used to generate a derived key based on the temporary public key of the temporary key pair and the communication public key; The encrypted data is obtained by encrypting the triplet data using the derived key.

5. The authentication method for IoT devices according to claim 4, characterized in that, The decryption information includes the temporary public key; The step of decrypting the encrypted data based on the communication private key and the temporary encrypted data includes: A shared key is generated based on the communication private key and the temporary public key, and a decryption key for the derived key is generated based on the shared key using the HKDF algorithm; The encrypted data is decrypted using the decryption key.

6. The authentication method for IoT devices according to any one of claims 1-5, characterized in that, The authentication method for the IoT device also includes: The abnormal working status information of the target device is sent to the cloud server, so that the cloud server invalidates the triplet data, generates new triplet data, and generates corresponding new encrypted data and new decryption information based on the new triplet data; Receive and obtain the new triplet data based on the new encrypted data and the new decryption information.

7. An authentication method for Internet of Things (IoT) devices, characterized in that, The system is applied to an equipment authentication system, which includes factory-side equipment, a target device, a mobile device with a corresponding application installed, a cloud server, and a device server. The cloud server and the target device interact with each other through the application on the mobile device. The authentication method for the IoT device includes: The target device acquires and stores the communication private key of the communication key, which is uniquely generated for the target device. The cloud server obtains the public key of the communication key and binds and stores the communication key with the device identifier of the target device; The target device generates an authentication request signature based on the device identifier of the target device and the key version number of the communication key, and sends the authentication request signature to the cloud server; The cloud server verifies the authentication request signature, generates triplet data for the target device when the verification is successful, generates a key through temporary encrypted data, encrypts the triplet data with the key to generate encrypted data, and sends the temporary encrypted data and the encrypted data to the target device. The target device receives encrypted data and temporary encrypted data sent by the cloud server; it decrypts the encrypted data based on the communication private key and the temporary encrypted data to obtain the triplet data; The target device initiates an authentication request to the device server based on the triplet data. When the verification is successful, the device server sends a pass certificate to the target device.

8. An authentication system for Internet of Things (IoT) devices, characterized in that, include: The acquisition module is used to acquire and save the communication private key of the communication key; The communication key is uniquely generated for the target device, and the communication public key of the communication key is bound to the device identifier of the target device and stored in the cloud server; The generation module is used to generate an authentication request signature based on the device identifier of the target device and the key version number of the communication key, and send the authentication request signature to the cloud server; The receiving module is used to receive encrypted data and decryption information sent by the cloud server. The encrypted data is generated by the cloud server after verifying the authentication request signature and encrypting the triple data with a key. The decryption information includes temporary encrypted data used to generate the key. The decryption module is used to decrypt the encrypted data based on the communication private key and the temporary encrypted data to obtain the triplet data; An authentication module is used to authenticate the target device based on the triplet data.

9. A computer-readable storage medium, characterized in that, The device stores a computer program that, when executed by a processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 7.

10. An Internet of Things (IoT) device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 7.

Images