Iot device control method, device, and storage medium

By combining edge gateways with smart cards through a blockchain interaction protocol, dynamic encrypted instructions are generated and executed, solving the problems of high latency, weak security, and offline unavailability in IoT device control, and realizing localized, secure and efficient device control.

CN122316795APending Publication Date: 2026-06-30SHENZHEN XINGHE POWER TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHENZHEN XINGHE POWER TECH CO LTD
Filing Date
2026-05-29
Publication Date
2026-06-30

Smart Images

  • Figure CN122316795A_ABST
    Figure CN122316795A_ABST
Patent Text Reader

Abstract

This application discloses an IoT device control method, device, and storage medium, relating to the field of IoT device management technology. The method includes: receiving an IoT device registration instruction transmitted from an edge gateway, generating first key information, and completing device binding processing; responding to a device control instruction and authentication information sent by a user, performing security verification processing based on the authentication information, and generating a dynamic encrypted instruction according to the first key information and the device control instruction; sending the dynamic encrypted instruction to the edge gateway, so that the edge gateway performs protocol conversion on the dynamic encrypted instruction and then distributes it to the bound IoT device, triggering the IoT device to receive the dynamic encrypted instruction, perform instruction verification on the dynamic encrypted instruction, and execute the device control operation corresponding to the dynamic encrypted instruction after successful verification. This application effectively eliminates reliance on cloud relay, reduces security risks associated with public network transmission, and improves the overall security of device control interaction.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) management and control technology, and in particular to an IoT device control method, device, and storage medium. Background Technology

[0002] Currently, most interactions between smart cards and IoT devices rely on centralized cloud servers for relaying commands. Control commands must be uploaded to the cloud via the public internet before being forwarded to the target device. This not only easily leads to interaction delays but also poses risks such as device control failure and unauthorized manipulation due to cloud outages or cyberattacks. Furthermore, the lack of a local, dedicated key binding mechanism between smart cards and IoT devices, the absence of dynamic encryption protection for control commands, and weak authentication mechanisms make the authentication process easily bypassable, posing significant security vulnerabilities and failing to meet the needs for localized, highly secure device control. Summary of the Invention

[0003] The main purpose of this application is to provide an IoT device control method, device, and storage medium, which aims to effectively eliminate reliance on cloud relay, reduce security risks caused by public network transmission, and improve the overall security of device control interaction.

[0004] To achieve the above objectives, this application proposes an Internet of Things (IoT) device control method, which is applied to a smart card and includes: The system receives an IoT device registration instruction transmitted from an edge gateway, generates first key information based on the IoT device registration instruction, and completes device binding processing. The IoT device registration instruction includes the device identification information of the IoT device. In response to the device control command and authentication information sent by the user, a security verification process is completed based on the authentication information, and a dynamic encryption command is generated according to the first key information and the device control command. The dynamic encryption command is sent to the edge gateway, so that the edge gateway performs protocol conversion on the dynamic encryption command and then sends it to the bound IoT device, thereby triggering the IoT device to receive the dynamic encryption command, perform command verification on the dynamic encryption command, and execute the device control operation corresponding to the dynamic encryption command after the verification is successful.

[0005] In one possible implementation, the step of generating first key information based on the IoT device registration instruction and completing the device binding process, wherein the IoT device registration instruction includes device identification information of the IoT device, including: In a preset hardware-level security element, an encryption algorithm is invoked to generate first key information that matches the IoT device. The first key information is then associated and bound with the device identification information. The first key information includes a first public key and a first private key. The binding completion information is stored in a one-time programmable memory, and a binding completion confirmation message is returned to the edge gateway through an encrypted channel.

[0006] In one possible implementation, the step of completing the security verification process based on the authentication information and generating dynamic encryption instructions according to the first key information and the device control instructions includes: Extract the user's identity authentication data and biometric data from the authentication information, and complete dual security verification in the hardware-level security element; After successful verification, based on the bound first key information, a dynamic encrypted instruction corresponding to the device control instruction is generated by combining random number and time information, so that the dynamic encrypted instruction has the security characteristics of single validity and time limitation.

[0007] To achieve the above objectives, this application proposes an IoT device control method, which is applied to an edge gateway and includes: Receive device identification information broadcast by an IoT device and generate an IoT device registration instruction corresponding to the IoT device. The IoT device registration instruction is sent to the smart card, so that after receiving the IoT device registration instruction, the smart card generates first key information based on the IoT device registration instruction and completes the device binding process; the smart card responds to the device control instruction and authentication information sent by the user, completes the security verification process based on the authentication information, and generates a dynamic encryption instruction according to the first key information and the device control instruction; the dynamic encryption instruction is sent to the edge gateway; The system receives the dynamic encryption command, performs protocol conversion processing on the dynamic encryption command, and sends the converted dynamic encryption command to the bound IoT device to trigger the IoT device to receive the dynamic encryption command, perform command verification on the dynamic encryption command, and execute the device control operation corresponding to the dynamic encryption command after the verification is successful.

[0008] In one possible implementation, the step of performing protocol conversion processing on the dynamic encryption command and sending the converted dynamic encryption command to the bound IoT device includes: Obtain a preset protocol conversion matching relationship, and adapt and convert the dynamic encryption command according to the communication type of the IoT device; The adapted dynamic encryption command is adjusted to a communication format recognizable by the IoT device, and the processed dynamic encryption command is sent to the IoT device.

[0009] To achieve the above objectives, this application proposes an Internet of Things (IoT) device control method, which is applied to IoT devices and includes: The device identification information is broadcast externally so that the edge gateway receives the device identification information and generates an IoT device registration instruction corresponding to the IoT device; the IoT device registration instruction is sent to the smart card so that the smart card generates first key information based on the IoT device registration instruction after receiving the IoT device registration instruction and completes the device binding process. The system receives a dynamically encrypted command after protocol conversion from the edge gateway, verifies the command, and executes the device control operation corresponding to the command after successful verification. The dynamically encrypted command is generated by the smart card in response to the device control command and authentication information sent by the user, after completing the security verification process based on the authentication information, according to the first key information and the device control command, and is sent to the edge gateway by the smart card.

[0010] In one possible implementation, the step of broadcasting device identification information to enable the edge gateway to receive the device identification information and generate an IoT device registration instruction corresponding to the IoT device; and sending the IoT device registration instruction to the smart card so that the smart card, after receiving the IoT device registration instruction, generates first key information based on the IoT device registration instruction and completes the device binding process, further includes: The device receives encrypted key information forwarded by the edge gateway, wherein the encrypted key information is obtained by the smart card encrypting the first private key of the first key information using the second public key corresponding to the IoT device. The encryption key information is decrypted using a pre-configured second private key to obtain the first private key, which is then stored in the secure area of ​​the device. After the decryption operation is completed, the second key information of the IoT device itself is destroyed, so that the IoT device can subsequently complete instruction verification only based on the first key information. The second key information includes a second public key and a second private key.

[0011] In one possible implementation, the step of verifying the dynamic encryption instruction and executing the device control operation corresponding to the dynamic encryption instruction after the verification passes includes: The dynamic temporary key is extracted from the dynamic encryption instruction, and its legality and timeliness are verified by combining it with the first private key stored locally. The dynamic temporary key is generated based on the first public key, time information and random number through the national cryptographic hash algorithm. If the dynamic temporary key is valid and its validity period is within the valid range, the dynamic encryption instruction is decrypted to obtain the original control instruction, the device control operation corresponding to the original control instruction is executed, and the dynamic temporary key used this time is destroyed after the operation is completed.

[0012] Furthermore, to achieve the above objectives, this application also proposes an Internet of Things (IoT) device control device, which includes: A smart card is used to receive an IoT device registration instruction transmitted by an edge gateway, generate first key information based on the IoT device registration instruction, and complete device binding processing. The IoT device registration instruction includes device identification information of the IoT device. In response to a device control instruction and authentication information sent by a user, a security verification process is completed based on the authentication information, and a dynamic encryption instruction is generated according to the first key information and the device control instruction. The dynamic encryption instruction is then sent to the edge gateway. An edge gateway is used to receive device identification information broadcast by IoT devices, generate IoT device registration instructions corresponding to the IoT devices, send the IoT device registration instructions to smart cards, receive dynamic encryption instructions, perform protocol conversion processing on the dynamic encryption instructions, and send the converted dynamic encryption instructions to the bound IoT devices. The Internet of Things (IoT) device is used to broadcast device identification information to the outside world; receive dynamic encryption instructions sent by the edge gateway after protocol conversion, verify the dynamic encryption instructions, and execute the device control operation corresponding to the dynamic encryption instructions after the verification is successful.

[0013] In addition, to achieve the above objectives, this application also proposes an Internet of Things (IoT) device control device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the IoT device control method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the Internet of Things device control method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the Internet of Things device control method described above.

[0016] This application provides an IoT device control method, device, and storage medium. The IoT device control method receives an IoT device registration instruction transmitted by an edge gateway, generates first key information based on the IoT device registration instruction, and completes device binding processing. The IoT device registration instruction includes device identification information of the IoT device. Responding to device control instructions and authentication information sent by a user, the method performs security verification based on the authentication information and generates a dynamic encryption instruction according to the first key information and the device control instruction. This dynamic encryption instruction is then sent to the edge gateway, which performs protocol conversion on the dynamic encryption instruction and distributes it to the bound IoT device. This triggers the IoT device to receive the dynamic encryption instruction, verify the instruction, and execute the device control operation corresponding to the dynamic encryption instruction upon successful verification. By having the edge gateway handle instruction interaction, pre-completing device key binding, and locally generating and verifying the dynamic encryption instruction, the method eliminates the need for cloud forwarding, reduces public network data transmission, effectively avoids external network attack risks, and improves the security and stability of device control. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 One of the flowcharts for the IoT device control method of this application is a traditional scheme. Figure 2 The second flowchart illustrating a conventional approach for the IoT device control method of this application; Figure 3 A flowchart illustrating the solution of this application for the Internet of Things (IoT) device control method; Figure 4 This is a flowchart illustrating an embodiment of the IoT device control method of this application. Figure 5A timing diagram for the scene implementation of the IoT device control method of this application; Figure 6 A flowchart illustrating the scenario implementation for the IoT device control method of this application; Figure 7 A flowchart illustrating the offline scenario for the IoT device control method of this application; Figure 8 A schematic diagram of the key transmission process provided for the IoT device control method of this application; Figure 9 This is a schematic diagram of the hardware operating environment involved in the IoT device control method in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] Existing smart cards and IoT devices cannot directly interact; all control commands must be relayed through a cloud server. The overall architecture generally adopts a centralized model of "mobile app + cloud control." Taking turning on a light as an example... Figure 1 As shown. In this mode, device control commands initiated by the user through the app must be uploaded to the cloud via the public network, and then forwarded to the target IoT device by the cloud. This route around the public network can easily cause operational delays. If the cloud experiences a downtime, malfunction, or is subjected to a network attack, it will directly lead to a complete loss of control over all devices, posing serious reliability and security risks. (See reference...) Figure 2 Meanwhile, traditional smart cards only support single-device access, making it impossible to achieve unified management of multiple devices. They are also incompatible with devices using multiple protocols such as Bluetooth, Wi-Fi, and Zigbee, resulting in low device adaptability and management efficiency.

[0023] Furthermore, existing solutions have significant security shortcomings. Sensitive operations such as key calculations and authentication are typically performed on mobile devices, exposing key information and biometric templates to the device's memory, making them vulnerable to malware theft. Even with biometric authentication, hackers can still bypass the authentication interface by forging an app and directly and illegally control IoT devices. More critically, this centralized architecture is highly dependent on the network environment, failing to perform device control properly in scenarios such as network outages or weak networks, severely limiting its availability.

[0024] To address the aforementioned shortcomings, this application proposes a smart card security management scheme based on the Blockchain Interaction Protocol (BIP), which can be referenced. Figure 3Using smart cards as the root of trust, local command interaction and protocol conversion are achieved through edge gateways. Devices only respond to encrypted commands that are signed and forwarded by smart cards. This approach eliminates cloud dependence at the architectural level and strengthens security protection at the hardware level, effectively solving a series of problems in traditional solutions such as high latency, easy loss of control, weak security, inability to be used offline, and incompatibility with multiple devices.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, big data service platform, or IoT device control system capable of realizing the above functions. The following description uses an IoT device control system as an example to illustrate this embodiment and the subsequent embodiments.

[0027] Based on this, embodiments of this application provide an IoT device control method, referring to... Figure 4 , Figure 4 This is a flowchart illustrating an embodiment of the IoT device control method of this application.

[0028] In this embodiment, the method is applied to a smart card, and the IoT device control method includes steps S11-S13: Step S11: Receive the IoT device registration instruction transmitted by the edge gateway, generate first key information based on the IoT device registration instruction and complete the device binding process, wherein the IoT device registration instruction includes the device identification information of the IoT device; It should be noted that an edge gateway refers to an IoT edge access device that supports BIP (Blockchain Interaction Protocol) interaction and has the ability to access multiple protocols and forward local commands; IoT device registration commands refer to commands generated based on the extended command set of the blockchain interaction protocol, used to initiate the registration and binding process of IoT devices; the first key information refers to the key information generated by the smart card inside the SE (Secure Element), used to build a trusted identity for the device; device binding processing refers to the security process of associating and solidifying the first key information with the unique identity of the IoT device; and device identification information refers to the identification information such as the MAC (Media Access Control) address broadcast by the IoT device, used to uniquely distinguish the device.

[0029] Understandably, smart cards, by receiving IoT device registration instructions transmitted by edge gateways based on blockchain interaction protocols, can complete device registration in a local environment, independent of the cloud. By generating and binding the first key information within a hardware-level secure element, the generation and storage of the key can be completed entirely within the chip, building a trusted identity foundation from the hardware root and effectively avoiding risks such as key leakage, unauthorized binding, and device impersonation. In one possible implementation, the first key information is generated using SM2 (State Cryptography Standard 2), containing a first public key and a first private key, and the first public key can be securely stored in the smart card's OTP (One-Time Programmable) memory.

[0030] Specifically, the smart card receives the IoT device registration instruction sent by the edge gateway through the blockchain interaction protocol, extracts the device identification information of the IoT device from the instruction, calls the encryption algorithm inside the hardware-level security element to generate the first key information, establishes a unique binding relationship between the first key information and the device identification information, and completes the secure registration process of the IoT device.

[0031] For example, when a user places a Bluetooth door lock near an edge gateway, the Bluetooth door lock broadcasts its own Media Access Control address. After obtaining the Media Access Control address, the edge gateway generates an IoT device registration instruction based on a blockchain interaction protocol and sends it to the smart card. The smart card generates first key information using the national cryptographic standard algorithm 2 within the secure area of ​​the secure element, binds the first key information to the Bluetooth door lock's Media Access Control address, and stores the binding information in a one-time programmable memory.

[0032] Step S12: In response to the device control command and authentication information sent by the user, complete the security verification process based on the authentication information, and generate a dynamic encryption command according to the first key information and the device control command; It should be noted that "user" refers to the entity that initiates control of IoT devices through a smart card; "device control command" refers to the command initiated by the user via SMS or other means to trigger the IoT device to perform a target action; "authentication information" refers to dual authentication information including SIM (Subscriber Identity Module) authentication data and biometric data; "security verification processing" refers to the verification of user legitimacy and operation permissions completed within the smart card's hardware-level security element; and "dynamic encryption command" refers to an encryption command that is generated based on the first key information, time information, random number, and the State Cryptography Standard 3 (SM3) hash algorithm, and has the characteristics of being valid only once and having a time limit.

[0033] Understandably, smart cards can ensure that sensitive operations do not expose plaintext data by completing authentication and dynamic key generation within the secure element. By combining timestamps and random numbers to generate dynamic encrypted instructions, they can achieve one key per instruction, effectively resisting replay attacks, instruction hijacking, and forgery attacks.

[0034] In one possible implementation, the security verification process includes dual verification of user identification module authentication and fingerprint liveness detection, with the biometric template pre-stored in a one-time programmable area of ​​the security element.

[0035] Specifically, in one embodiment, the process is initiated by the user via SMS. The mobile phone baseband chip transmits the SMS to the smart card via APDU (Application Protocol Data Unit) instructions. Further, the smart card responds to the device control command sent by the user, obtains the corresponding authentication information, completes identity verification within the hardware-level security element, and after successful verification, reads the first public key from the first key information. Combining this with millisecond-level time information and a 16-bit random number, a dynamic temporary key is generated using the SM3 hash algorithm. The device control command is then encrypted based on this dynamic temporary key to form a dynamically encrypted command. (See reference...) Figure 5 .

[0036] For example, a user sends an unlock command via SMS. After receiving the command, the smart card extracts the authentication data from the user identification module and the fingerprint data, completes dual verification within the security element, and reads the first public key stored in the one-time programmable memory after successful verification. Combining the current UTC timestamp and a random number, a dynamic temporary key is obtained through SM3 hash calculation, which in turn generates a dynamic encrypted command.

[0037] Step S13: Send the dynamic encryption command to the edge gateway so that the edge gateway performs protocol conversion on the dynamic encryption command and then sends it to the bound IoT device, thereby triggering the IoT device to receive the dynamic encryption command, perform command verification on the dynamic encryption command, and execute the device control operation corresponding to the dynamic encryption command after the verification is successful.

[0038] It should be noted that protocol conversion refers to the edge gateway translating the dynamic encrypted instructions in the blockchain interaction protocol format into a format that IoT devices such as Bluetooth, Wi-Fi, and Zigbee can recognize; instruction verification refers to the process by which IoT devices use their locally stored first private key to verify the legality, integrity, and timeliness of the dynamic temporary key; and device control operation refers to the IoT device executing corresponding functions such as unlocking and data acquisition based on the decrypted original instructions.

[0039] Understandably, edge gateways achieve unified management and control of heterogeneous devices through local protocol conversion, eliminating the need for cloud relay, reducing latency and avoiding the risk of total loss of control due to cloud downtime; IoT devices, by verifying dynamic temporary keys and limiting the validity window to ±3 minutes, can ensure that instructions are executed only within the legal time frame, and destroy the dynamic temporary key after execution, further enhancing security.

[0040] Specifically, the smart card sends dynamically encrypted commands to the edge gateway via a blockchain interaction protocol. The edge gateway performs protocol conversion based on the communication type of the target IoT device and then sends the adapted commands to the bound devices. (See reference...) Figure 6 After receiving the instruction, the IoT device uses the first private key stored locally to verify the dynamic temporary key, calculates the local hash and compares it with the dynamic temporary key, and verifies whether the time is within the ±3 minute valid window. If all of them pass, the device decrypts and executes the corresponding device control operation, and immediately destroys the dynamic temporary key.

[0041] For example, the smart card sends a dynamic encryption command to the edge gateway via the blockchain interaction protocol. The edge gateway queries the protocol conversion table to convert the command into Bluetooth format and sends it to the Bluetooth door lock. The door lock uses the first private key to verify the dynamic temporary key, calculates the local hash and verifies the time window. After the verification is successful, it unlocks the door. After the operation is completed, the dynamic temporary key used this time is destroyed immediately.

[0042] This embodiment uses an edge gateway to handle command interaction, pre-completes device key binding and locally generates and verifies dynamically encrypted commands, abandons the cloud forwarding mode, reduces public network data transmission, effectively avoids the risk of external network attacks, and improves the security and stability of device control.

[0043] In addition, when the user is in an emergency situation where there is no network available, such as mobile network interruption, wireless gateway offline, or public network connection failure, the system can automatically enter the offline emergency control mode.

[0044] In this embodiment, the smart card pre-stores hardware-encrypted offline instruction generation code. This code is written into the smart card's secure storage area during the smart card's manufacturing or device registration phase. It can only be called and executed within the smart card and cannot be read, tampered with, or replaced externally.

[0045] Completely independent of edge gateways, cloud servers, and various network links, the smart card can directly call pre-stored offline command generation code. Combined with the bound first key information and device identification information, it generates an offline control command with valid verification attributes that can be recognized by the target IoT device. This offline control command serves as a backup key in this embodiment, possessing the security characteristics of single-use validity, time-limited validity, and device-specific matching. The user can place the smart card close to the near-field communication sensing area configured on the IoT device and transmit the offline control command (serving as the backup key) directly to the IoT device via the near-field communication link. Upon receiving the offline control command, the IoT device uses the first private key stored in its local secure area to verify the command's legality, integrity, and device compatibility. After successful verification, it directly executes the device control operation corresponding to the offline control command. (See reference...) Figure 7 This enables secure, reliable, and emergency control of IoT devices in a purely local offline environment without any network support, effectively avoiding the problem of devices being uncontrollable due to network disconnection, gateway abnormalities, or cloud failures, and significantly improving the overall availability and emergency support capabilities of the IoT device control system.

[0046] In one feasible implementation, the step of generating first key information based on the IoT device registration instruction and completing the device binding process, wherein the IoT device registration instruction includes device identification information of the IoT device, including: Step S21: In a preset hardware-level security element, an encryption algorithm is invoked to generate first key information that matches the IoT device, and the first key information is associated and bound with the device identification information. The first key information includes a first public key and a first private key. It should be noted that the hardware-level security element refers to the Secure Element (SE), which is a hardware-level security area integrated inside the smart card and has independent computing and storage capabilities; the encryption algorithm refers to the State Cryptography Standard 2 (SM2) algorithm, which is a national standard asymmetric encryption algorithm suitable for key pair generation; the first key information refers to the exclusive identity key information assigned by the smart card to IoT devices, wherein the first public key refers to the public key portion of the first key information that can be used for external verification and dynamic key calculation; the first private key refers to the private key portion of the first key information that needs to be securely transmitted to IoT devices and is only used for internal decryption and verification; IoT devices refer to heterogeneous terminal devices such as Bluetooth door locks, Wi-Fi cameras, and Zigbee sensors connected to the edge gateway.

[0047] Understandably, completing key generation and binding within a hardware-level secure element ensures that the entire key generation and computation process occurs within the chip, preventing the key from being exposed in plaintext. This builds a trusted identity system at the hardware level, effectively preventing key theft, device impersonation, and unauthorized binding. In one possible implementation, the hardware-level secure element possesses security capabilities against physical hacking and side-channel attacks, and the key generation process is executed independently of the smart card's external system.

[0048] Specifically, the smart card calls the national cryptographic standard algorithm 2 within its built-in security element to generate a first key information that uniquely matches the IoT device to be registered. The first key information includes a first public key and a first private key. The smart card associates and binds the first key information with the acquired device identification information one by one to form an immutable and trustworthy binding relationship.

[0049] For example, when a user places a newly purchased smart lock within 30 centimeters of an edge gateway, the lock automatically broadcasts its "identity card information (MAC address)" via Bluetooth. Upon receiving the broadcast, the edge gateway immediately sends a registration command to the smart card. Further, after receiving the registration command, the smart card's security chip (SE) uses the national cryptographic SM2 algorithm in its hardware encryption area to generate a 256-bit elliptic curve key pair Key_A (i.e., the first key information, including the private key Pri_Key_A + public key Pub_Key_A). The public key Pub_Key_A is then written into a one-time programmable memory (OTP) to prevent secondary reading. This binds the key pair to the lock's MAC address. Key_A is generated during registration, and the generation process is highly secure; throughout the entire process, Key_A remains within the secure area.

[0050] In one embodiment, when the first key information is generated inside the smart card hardware-level security element, a true random number generator with a built-in physical noise source is simultaneously connected to the chip. The generator outputs a 256-bit unreproducible entropy value as the basic seed for key generation. The entropy value is generated in real time by the chip's physical noise. It is irregular, unreproducible, and unpredictable. That is, the seed is generated based on the chip's thermal and electromagnetic noise, and has inherent unpredictability, thus ensuring the randomness and unbreakability of the key generation process from the root.

[0051] Step S22: Store the binding completion information into a one-time programmable memory, and return the binding completion confirmation information to the edge gateway through an encrypted channel.

[0052] It should be noted that the information related to the completion of binding refers to the first key information, device identification information, and the relationship between the two; the one-time programmable memory (OTP) is a secure storage area inside the smart card that supports one-time writing and cannot be modified or read a second time; the encrypted channel refers to a secure communication channel established based on hardware encryption mechanism for transmitting sensitive data; the confirmation information for the completion of binding refers to feedback information used to inform the edge gateway that the device registration and key binding process has been successfully executed.

[0053] Understandably, storing the binding information in a one-time programmable memory can prevent the binding data from being tampered with, deleted, or illegally read, ensuring the permanent validity of the correspondence between the device and the key; returning confirmation information through an encrypted channel can prevent the registration result from being hijacked or forged during transmission, improving the overall security of the registration process. In one possible implementation, the one-time programmable memory is located inside the secure element and is physically isolated from the ordinary storage area of ​​the smart card.

[0054] Specifically, the smart card writes the binding result of the first key information and the device identification information into a one-time programmable memory within the secure element. Simultaneously, it returns a confirmation message indicating successful binding to the edge gateway via a hardware encrypted channel, notifying the edge gateway that the IoT device has completed trusted registration. For example, after binding the first key information to the media access control address of a Bluetooth door lock, the smart card stores the relevant data in the one-time programmable memory and then returns a confirmation message of successful binding to the edge gateway via an encrypted channel. Based on this, the edge gateway confirms that the device can enter the normal control process.

[0055] In one embodiment, the binding relationship between the first key information and the device identification information is generated into a 32-byte hash value using the national cryptographic SM3 hash algorithm and then solidified into a one-time programmable memory. Once written, the hash value cannot be rewritten or erased, ensuring that the binding relationship between the key and the device cannot be tampered with throughout the process. This establishes a hardware-level trusted binding foundation and effectively avoids the risks of key leakage and illegal binding.

[0056] This embodiment achieves secure localized device registration without cloud involvement by generating national cryptographic algorithm keys, binding device identifiers, and securely storing them in a one-time programmable memory within the secure element of the smart card, and completing registration confirmation feedback through an encrypted channel. It ensures that the key and binding relationship are tamper-proof and undisclosed at the hardware level, effectively solving the problems of easy key exposure, untrustworthy binding relationships, and vulnerability to attacks in traditional solutions, and significantly improving the security and reliability of IoT device registration and binding.

[0057] In one feasible implementation, the step of completing the security verification process based on the authentication information and generating dynamic encryption instructions according to the first key information and the device control instructions includes: Step S31: Extract the user's identity authentication data and biometric data from the identity verification information, and complete dual security verification in the hardware-level security element; It should be noted that identity authentication data refers to legitimate network-side identity data generated based on the SIM (Subscriber Identity Module); biometric data refers to the user's fingerprint features, facial features, and other biometric information; and dual security verification refers to a security process that simultaneously verifies the legitimacy of the user identification module's authentication data and the biometric data.

[0058] Understandably, performing dual security verification within a hardware-level secure element can confine sensitive verification operations to a secure hardware environment, preventing verification data from being stolen, tampered with, or bypassed, and ensuring that only authorized users can initiate device control commands. In one possible implementation, a template of biometric data is pre-stored in a one-time programmable (OTP) area within the secure element, and the verification process, in conjunction with a liveness detection mechanism, prevents spoofing attacks.

[0059] Specifically, the smart card extracts the authentication data corresponding to the user identification module and the user's biometric data from the received authentication information. These two types of data are then transmitted to the hardware-level secure element to sequentially complete the dual verification of identity legitimacy and biometric consistency, confirming that the current operation is a legitimate operation by an authorized user. For example, when a user initiates an unlocking operation via their mobile phone, the smart card extracts the authentication data of the user identification module and fingerprint feature data from the authentication information. Within the secure element, it completes dual verification of user identification module authentication and fingerprint liveness detection. Only after successful verification can the subsequent dynamic encryption command generation process continue.

[0060] In one specific implementation, user identification module authentication completes legitimacy verification by sending an authentication request to the communication operator through the user identification module application toolkit STK (SIM Toolkit). Fingerprint verification is completed by comparing real-time collected fingerprint information with a fingerprint template pre-stored in a one-time programmable area within the secure element, combined with a liveness detection method combining capacitive sensing and blood flow imaging, effectively preventing spoofing attacks. The entire verification process is executed within the secure element, providing a high level of security. Specifically, when the smart card extracts identity authentication data and biometric data, it performs irreversible desensitization processing on the original data within the hardware secure element, retaining only the feature digest required for verification. The original identity information and biometric data never leave the secure element, are not transmitted externally, and are not temporarily cached. The biometric template is encrypted and stored in an isolated partition of the one-time programmable memory. This partition is physically isolated from the computing area to prevent unauthorized reading or tampering of the template data, ensuring that the user authentication process is completed only within the hardware secure environment, avoiding identity information leakage or malicious theft of biometric data.

[0061] Step S32: After the verification is passed, a dynamic encryption instruction corresponding to the device control instruction is generated based on the bound first key information, combined with random number and time information, so that the dynamic encryption instruction has the security characteristics of single validity and time limit.

[0062] It should be noted that the random number refers to the 16-bit random value generated by the smart card; the time information refers to the millisecond-level UTC timestamp; the dynamic encryption instruction refers to a single-use valid encryption control instruction generated based on the key, random number, and time information; single-use valid means that each dynamic encryption instruction can only be used once and cannot be executed repeatedly; the time limit means that the dynamic encryption instruction is only legally valid within a preset time window.

[0063] Understandably, generating dynamic encryption commands by combining first key information, random numbers, and time information can achieve one-command-one-key, effectively resisting command replay, hijacking, and forgery attacks, and improving the overall security of IoT control. In one possible implementation, the dynamic encryption command is generated using the State Cryptography Standard 3 (SM3) hash algorithm, with an effective time window set to ±3 minutes.

[0064] Specifically, after the dual security verification passes, the smart card reads the bound first key information within the hardware-level security element. Combining this with a real-time generated random number and the current time, it calculates a dynamic temporary key using the national cryptographic standard hash algorithm. This dynamic temporary key is then used to encrypt the device control commands, generating a dynamically encrypted command with single-use validity and time-limited validity. For example, after completing the dual verification, the smart card reads the bound first public key, combines it with a 16-bit random number and a millisecond-level UTC timestamp, and outputs a 32-byte dynamic temporary key, Temp_Key, using the national cryptographic standard algorithm 3. This generates the corresponding dynamically encrypted command for unlocking, which is valid only within ±3 minutes and can only be executed once.

[0065] In one embodiment, when generating dynamic encryption instructions within a hardware-level secure element, a hierarchical key derivation method is adopted. An initial root key is generated based on the first public key, and a session key is derived by combining it with a millisecond-level UTC timestamp. Finally, a 16-bit hardware random number is superimposed to generate the final dynamic temporary key. The entire key operation is completed within the secure element, and the key data is not exposed to the outside, achieving hierarchical isolation protection of the key. That is, the key derivation process is physically isolated from the external system, and the operation process is completely closed, thereby avoiding a chain of security risks caused by leakage in a single link. The secure element has built-in hardware protection circuits, and the entire key operation process is completed within the hardware secure zone and automatically triggers multi-layer physical protection mechanisms. The key operation is mainly divided into four core stages: key initialization, key derivation, hash operation, and result output. The protection circuits are effective independently in each stage.

[0066] In the key initialization phase, the circuit generates microsecond-level random delays through an on-chip independent true random number generator, inserting them into the clock cycle to make the initialization timing exhibit irregular jitter, eliminating fixed timing characteristics. In the key derivation phase, parallel redundant computing units are enabled to simultaneously perform random, unrelated operations while performing real key operations. The power consumption of random operations is superimposed and merged with the power consumption of real operations, masking the power consumption curve of the key derivation process. In the hash operation phase, an on-chip metal shielding layer, in conjunction with a random electromagnetic noise generator, randomly emits broadband electromagnetic signals, which are superimposed with the electromagnetic signals generated by the hash operation to interfere with external electromagnetic detection. In the result output phase, the clock edge of the output data and the electromagnetic signal are double-randomly offset to avoid leakage of operation traces in the output timing. By applying the above multi-layer protection to each stage of the key operation, the external system cannot reverse-engineer the key operation process through timing analysis, power consumption analysis, or electromagnetic detection, completely blocking the physical side-channel attack path, ensuring zero leakage of key operation traces, and significantly improving the physical security protection capability of the dynamic key generation process.

[0067] This embodiment implements dual security verification of user identification module authentication and biometric verification within a hardware-level secure element. It also generates a single-use, time-limited dynamic encryption command by combining the first key information, random number, and time information. All sensitive operations and key processing are confined to a hardware-secure environment, achieving proactive security protection with the entire command generation process remaining on the chip and each command having its own key. This effectively solves the security defects of traditional solutions, such as easy bypassing of identity authentication and easy forgery and replay of commands, and significantly improves the security and reliability of IoT device control.

[0068] In one feasible implementation, the method is applied to an edge gateway and includes: Step S41: Receive device identification information broadcast by the IoT device and generate an IoT device registration instruction corresponding to the IoT device; It should be noted that the edge gateway, by actively receiving device identification information broadcast by IoT devices, can discover and identify devices to be registered locally without relying on cloud intervention, thereby generating corresponding registration instructions and providing a foundation for subsequent device binding and key distribution. In one possible implementation, IoT devices automatically start broadcasting when they approach a preset distance from the edge gateway, and the edge gateway completes the reception and parsing of device identification information within its local area.

[0069] Specifically, the edge gateway listens in real time and receives device identification information broadcast by IoT devices. It then parses and verifies this information, generating an IoT device registration command based on a blockchain-based interaction protocol. For example, if a user places a Bluetooth door lock within 30 centimeters of the edge gateway, the lock automatically broadcasts its media access control address. Upon receiving this address, the edge gateway generates an IoT device registration command based on a blockchain-based interaction protocol.

[0070] Step S42: The IoT device registration instruction is sent to the smart card, so that after receiving the IoT device registration instruction, the smart card generates first key information based on the IoT device registration instruction and completes the device binding process; the smart card responds to the device control instruction and authentication information sent by the user, completes the security verification process based on the authentication information, and generates a dynamic encryption instruction according to the first key information and the device control instruction; the dynamic encryption instruction is sent to the edge gateway; It should be noted that a smart card refers to a user identification module card that integrates a secure element (SE) and a one-time programmable storage area and has hardware-level secure computing capabilities; security verification processing refers to the identity verification process completed within the secure element.

[0071] Understandably, the edge gateway sends registration commands to the smart card via a local link, enabling localized registration without cloud intermediaries. This, combined with the smart card, completes key generation, identity verification, and dynamic encryption command generation, establishing an end-to-end secure interaction link. In one possible implementation, the edge gateway and smart card exchange commands via a blockchain interaction protocol, without traversing the public network or cloud.

[0072] Specifically, the edge gateway sends the generated IoT device registration command to the smart card through a local secure channel. Upon receiving the command, the smart card generates a first key and completes device binding. When a user initiates a control operation, the smart card receives the device control command and authentication information, completes security verification, generates a dynamically encrypted command based on the first key, and then returns the dynamically encrypted command to the edge gateway. For example, the edge gateway sends the IoT device registration command to the smart card via the Blockchain Interaction Protocol (BIP). The smart card generates a first key within its secure element and completes device binding. After a user initiates an unlock command via SMS, the smart card performs dual verification using the user identification module and fingerprint liveness detection, generates a dynamically encrypted command, and sends it to the edge gateway.

[0073] Step S43: Receive the dynamic encryption instruction, perform protocol conversion processing on the dynamic encryption instruction, and send the converted dynamic encryption instruction to the bound IoT device to trigger the IoT device to receive the dynamic encryption instruction, perform instruction verification on the dynamic encryption instruction, and execute the device control operation corresponding to the dynamic encryption instruction after the verification is successful.

[0074] It should be noted that protocol conversion processing refers to the process by which the edge gateway converts the dynamically encrypted instructions in the blockchain interaction protocol format into a communication format that can be recognized by IoT devices such as Bluetooth, Wi-Fi, and Zigbee; device control operation refers to the functional actions performed by IoT devices, such as unlocking, data acquisition, and switch control.

[0075] Understandably, edge gateways achieve unified access and command issuance for heterogeneous devices through local protocol conversion, eliminating cloud dependency and reducing latency and single-point-of-failure risks. IoT devices ensure the legitimacy and validity of commands by verifying dynamic temporary keys and limiting their validity window to ±3 minutes, and destroy the dynamic temporary key after execution, further enhancing security. In one possible implementation, the edge gateway performs protocol format mapping and translation based on a built-in protocol conversion table.

[0076] Specifically, the edge gateway receives the dynamic encrypted command sent by the smart card, performs protocol conversion processing according to the communication type of the target IoT device, and sends the converted command to the bound IoT device. After receiving the command, the IoT device completes command verification. If the verification is successful, it executes the corresponding device control operation. For example, after receiving the dynamic encrypted command, the edge gateway queries the protocol conversion table to convert the blockchain interaction protocol command into Bluetooth format and sends it to the Bluetooth door lock. The Bluetooth door lock uses the first private key to verify the dynamic temporary key. After the verification time window is ±3 minutes, it unlocks the door and destroys the dynamic temporary key used this time.

[0077] This embodiment uses an edge gateway to achieve local discovery of IoT devices, generation of registration instructions, interaction of blockchain interaction protocols, and multi-protocol conversion and distribution. It works with smart cards to complete key generation, identity verification, and construction of dynamic encrypted instructions, forming a localized control architecture that is completely independent of centralized cloud relay. This effectively reduces the risks of public network transmission latency, cloud attacks, and single points of failure. At the same time, relying on hardware secure computing, one instruction one key, and timeliness verification mechanisms, it significantly improves the security, reliability, and availability of IoT device control.

[0078] In one feasible implementation, the step of performing protocol conversion processing on the dynamic encryption command and sending the converted dynamic encryption command to the bound IoT device includes: Step S51: Obtain a preset protocol conversion matching relationship, and adapt and convert the dynamic encryption command according to the communication type of the IoT device; It should be noted that the preset protocol conversion matching relationship refers to the rule table pre-configured inside the edge gateway to realize the corresponding protocol format mapping; the communication type of IoT devices refers to the wireless communication methods such as Bluetooth, Wi-Fi, and Zigbee supported by IoT devices; dynamic encryption instructions refer to the encrypted control instructions generated by the smart card based on the Blockchain Interaction Protocol (BIP); and adaptation conversion refers to the processing operation of converting the instructions in the blockchain interaction protocol format into a format compatible with the corresponding communication type.

[0079] Understandably, edge gateways achieve unified access and command translation for multi-protocol heterogeneous devices through protocol conversion matching relationships, completing local protocol adaptation without cloud intervention, effectively improving system compatibility and control real-time performance. In one possible implementation, the protocol conversion matching relationship is stored in the form of a command code mapping table, where different command codes correspond to different device types and target protocol formats, as shown in Table 1.

[0080] Table 1

[0081] Specifically, the edge gateway reads the locally preset protocol conversion matching relationship, identifies the communication type corresponding to the target IoT device, and converts the dynamic encrypted command from the original blockchain interaction protocol format to an intermediate format that is compatible with the communication type according to the matching relationship, thus completing the protocol adaptation processing of the command.

[0082] For example, after the edge gateway obtains the preset protocol conversion table and identifies the target device as a Bluetooth door lock, it adapts and converts the dynamic encryption command according to the Bluetooth communication protocol specification, converting the blockchain interaction protocol command code into a command format that the Bluetooth door lock can recognize.

[0083] Step S52: Adjust the adapted dynamic encryption command to a communication format recognizable by the IoT device, and send the processed dynamic encryption command to the IoT device.

[0084] It should be noted that the communication format recognizable by IoT devices refers to the data frame format that conforms to the underlying communication specifications of devices such as Bluetooth, Wi-Fi, and Zigbee; the adapted dynamic encryption command refers to the encrypted command data that has completed protocol type mapping and is waiting for frame format adjustment; the delivery refers to the transmission action of the edge gateway sending the processed command to the corresponding IoT device through the wireless communication link. In this way, by adjusting the command to the device's native recognizable format, it is ensured that the IoT device can correctly receive, parse, and execute control commands, thereby realizing end-to-end reliable interaction between smart cards and multiple types of devices.

[0085] In one possible implementation, the edge gateway adds a frame header, checksum, and end-of-frame character according to the corresponding communication standard when adjusting the communication format.

[0086] Specifically, the edge gateway adapts the dynamically encrypted command to a valid and parseable data format according to the communication standards of IoT devices. It then sends the processed command to the bound IoT device via the corresponding wireless communication channel, triggering the device to perform command verification and corresponding control operations. For example, the edge gateway adapts the dynamically encrypted command to a standard Bluetooth communication data frame format and sends it to a Bluetooth door lock via the Bluetooth channel. The Bluetooth door lock can directly receive and parse the command, thereby performing dynamic temporary key verification and unlocking operations.

[0087] In one embodiment, before completing the protocol conversion, the edge gateway temporarily stores the encrypted dynamic encrypted instruction digest in a local secure cache. Only short-term caches are retained and stored in hardware isolation to prevent the instructions from being tampered with or stolen during forwarding. Simultaneously, the gateway employs differentiated protocol hardening strategies for different communication types of devices, embedding lightweight verification fields and frame integrity checks for protocols such as Bluetooth, Wi-Fi, and Zigbee. This ensures that the instruction frame format is legal and the data is complete after protocol conversion, avoiding data errors or security vulnerabilities introduced during heterogeneous protocol adaptation and improving the stability and security of instruction transmission across protocols.

[0088] This embodiment obtains the protocol conversion matching relationship locally through the edge gateway and completes the adaptation, conversion and format adjustment of dynamic encryption commands. It realizes the local translation of blockchain interaction protocols and communication protocols of various devices such as Bluetooth, Wi-Fi, and Zigbee. It can achieve unified control of heterogeneous IoT devices without cloud relay, effectively reducing command latency, cloud dependence and network attack risks, while improving the system's compatibility with multiple types of devices and overall control reliability.

[0089] In one feasible implementation, the method is applied to an Internet of Things (IoT) device, comprising: Step S61: Broadcast device identification information to the outside world so that the edge gateway receives the device identification information and generates an IoT device registration instruction corresponding to the IoT device; send the IoT device registration instruction to the smart card so that after receiving the IoT device registration instruction, the smart card generates first key information based on the IoT device registration instruction and completes the device binding process. It should be noted that IoT devices can be discovered by edge gateways in a local environment without cloud involvement by actively broadcasting their device identification information. This triggers the registration and key binding process, establishing a hardware-level trusted identity foundation for subsequent security control. In one possible implementation, IoT devices automatically initiate broadcasting when they enter the edge gateway's preset communication range, without requiring manual configuration by the user.

[0090] Specifically, IoT devices broadcast their device identification information at preset intervals. The edge gateway listens for and receives this information, generates a corresponding IoT device registration command, and sends it to the smart card. Upon receiving the registration command, the smart card generates a first key within its secure element, completing the device binding process with the IoT device. For example, if a user places a Bluetooth door lock within 30 centimeters of the edge gateway, the door lock automatically broadcasts its media access control address. The edge gateway receives this address, generates a registration command in blockchain interaction protocol format, and sends it to the smart card. The smart card then generates a first key within its secure element and completes the binding with the Bluetooth door lock.

[0091] Step S62: Receive the dynamic encryption command after protocol conversion issued by the edge gateway, verify the dynamic encryption command, and execute the device control operation corresponding to the dynamic encryption command after the verification is successful. The dynamic encryption command is generated by the smart card in response to the device control command and authentication information sent by the user, after completing the security verification process based on the authentication information, according to the first key information and the device control command, and the smart card sends the dynamic encryption command to the edge gateway.

[0092] It should be noted that instruction verification refers to the process by which IoT devices use their locally stored first private key to verify the legitimacy, integrity, and timeliness of the dynamic temporary key.

[0093] Understandably, IoT devices only execute verified, legitimate commands, effectively resisting command forgery, hijacking, and replay attacks, ensuring secure and reliable device control throughout the entire process. In one possible implementation, command verification includes local hash calculation, dynamic temporary key comparison, and ±3-minute time window verification; decryption and execution are only permitted after successful verification.

[0094] Specifically, the IoT device receives a dynamically encrypted instruction from the edge gateway and completes the protocol conversion. It uses the first private key stored locally to verify the legality and timeliness of the dynamic temporary key in the instruction. After the verification is successful, it decrypts the original control instruction and executes the corresponding device control operation. The dynamic encrypted instruction is generated by the smart card after verifying the user's identity, based on the first key information and the device control instruction, and then sent to the edge gateway.

[0095] For example, a Bluetooth door lock receives a Bluetooth-formatted dynamic encryption command from an edge gateway, verifies the dynamic temporary key using the locally stored first private key, calculates the local hash and verifies that the time window is within ±3 minutes, performs the unlocking operation after the verification is successful, and immediately destroys the dynamic temporary key used in this operation after the operation is completed.

[0096] This embodiment achieves local registration and discovery by actively broadcasting device identification information by IoT devices. It works with edge gateways and smart cards to complete key generation and secure binding. During the control phase, it receives dynamically encrypted commands converted by the protocol, completes hardware-level key verification and trusted action execution, and builds a localized security control system that is cloud-free, with keys not leaving the chip and one key per command. This effectively solves the problems of easy attack on commands, easy bypass of authentication, and single point of failure in the cloud in traditional solutions, and significantly improves the security, reliability and offline availability of IoT device control.

[0097] In one feasible implementation, the step of broadcasting device identification information to enable the edge gateway to receive the device identification information and generate an IoT device registration instruction corresponding to the IoT device; and sending the IoT device registration instruction to the smart card so that the smart card, after receiving the IoT device registration instruction, generates first key information based on the IoT device registration instruction and completes the device binding process, further includes: Step S71: Receive encryption key information forwarded by the edge gateway, wherein the encryption key information is obtained by the smart card encrypting the first private key of the first key information using the second public key corresponding to the IoT device; It should be noted that the encryption key information refers to the ciphertext key data formed after the smart card is encrypted using the second public key corresponding to the IoT device; the second public key refers to the asymmetric encryption public key data pre-configured in the IoT device and pre-burned into the smart card firmware; the first key information refers to the key information generated by the smart card inside the secure element for trusted identity authentication of the IoT device; and the first private key refers to the private key portion of the first key information used for instruction decryption and verification.

[0098] Understandably, the smart card uses a second public key to encrypt the first private key during transmission. This ensures that the first private key exists in ciphertext form during network transmission, preventing the plaintext key from being intercepted, stolen, or tampered with, and ensuring the security and reliability of the key distribution process. In one possible implementation, the encrypted key information is forwarded locally via an edge gateway through a blockchain interaction protocol, without passing through the cloud or the public network.

[0099] Specifically, the IoT device receives encryption key information forwarded from the local link by the edge gateway. This encryption key information is generated by the smart card using the second public key corresponding to the IoT device to encrypt the first private key in the first key information. For example, the smart card uses Pub_Key_B (i.e., the second public key), which is obtained in advance from the door lock and pre-programmed into the smart card device firmware, to encrypt Pri_Key_A (the first private key) to generate Enncypted_Key (encryption key information). After receiving Enncypted_Key, the door lock decrypts it using Pri_Key_B (the second private key) to obtain Pri_Key_A and stores it in the door lock's secure area. After Pri_Key_B is decrypted, the key pair Key_B (the second key information) is immediately destroyed.

[0100] Step S72: Decrypt the encryption key information using the pre-configured second private key to obtain the first private key and store it in the device's secure area; It should be noted that the second private key refers to the asymmetric encryption private key data that is pre-configured locally on the IoT device and used in conjunction with the second public key; decryption refers to the cryptographic operation process of using the second private key to restore the encrypted key information to the plaintext of the first private key; and the device security area refers to the independent, isolated, and inaccessible hardware-level secure storage area inside the IoT chip.

[0101] Understandably, by decrypting the encrypted data locally and storing the first private key in the device's secure area, IoT devices can ensure that the first private key exists only in plaintext form within the device and never leaves the hardware secure area, thus preventing key leakage at the physical level.

[0102] In one possible implementation, the device's secure area has anti-read, anti-cracking, and anti-tampering features, and is physically isolated from the ordinary storage area of ​​the IoT device.

[0103] Specifically, IoT devices use a locally pre-configured second private key to decrypt the encrypted key information, recover the first private key from the ciphertext data, and securely store the first private key in the device's secure area for subsequent verification and decryption of dynamic encryption commands. For example, a Bluetooth door lock uses its own pre-programmed second private key to decrypt the received encrypted key information, obtain the first private key, and store the first private key in the hardware secure area inside the door lock, without exposing any plaintext keys. (See reference...) Figure 8 .

[0104] Step S73: After completing the decryption operation, the second key information of the IoT device itself is destroyed, so that the IoT device can subsequently complete instruction verification only based on the first key information. The second key information includes a second public key and a second private key.

[0105] It should be noted that destruction refers to the permanent and unrecoverable deletion of the second key information from the storage area of ​​the IoT device; the second key information refers to a temporary asymmetric key pair containing the second public key and the second private key; and instruction verification refers to the process by which the IoT device uses the first private key to verify the legality, integrity, and validity of the dynamic temporary key.

[0106] Understandably, after receiving and storing the first private key, IoT devices destroy the second key information, which can clear the traces of temporary key usage, prevent the second key information from being illegally used, and enable the device to rely only on the securely stored first key information to complete instruction verification, thereby further improving the overall security level.

[0107] In one possible implementation, the second key information is a one-time temporary key, used only for the secure transmission of the first private key during the registration phase, and destroyed immediately after use.

[0108] Specifically, after successfully decrypting and securely storing the first private key, the IoT device permanently destroys its locally stored second key information, including the second public key and the second private key. This allows the IoT device to use only the first key information within its secure area to verify and execute dynamic encryption commands in subsequent control processes. For example, after successfully decrypting and saving the first private key, a Bluetooth door lock immediately clears its stored second public key and second private key, subsequently using only the first private key to verify the dynamic temporary key, without relying on any temporary key information.

[0109] This embodiment achieves secure transmission and decryption of the first private key through the second key information. The first private key is stored in the hardware security area of ​​the IoT device, and the second key information is destroyed immediately after use, forming a one-time, closed-loop, hardware-level key distribution mechanism. It ensures that the key does not leave the security area, the transmission does not expose plaintext, and the temporary key leaves no trace throughout the process. It effectively solves the security defects of traditional IoT device key distribution, which is easy to be intercepted, cracked, and abused, and greatly improves the security and reliability of key management and command verification.

[0110] In one feasible implementation, the step of verifying the dynamic encryption command and executing the device control operation corresponding to the dynamic encryption command after the verification passes includes: Step S81: Extract the dynamic temporary key from the dynamic encryption instruction, and verify the legality and timeliness of the dynamic temporary key by combining it with the first private key stored locally. The dynamic temporary key is generated based on the first public key, time information and random number through the national cryptographic hash algorithm. It should be noted that the dynamic temporary key refers to a single-use valid temporary key generated by the smart card within the secure element based on the first public key, time information, and a random number using State Cryptography Standard 3 (SM3). Legitimacy verification refers to the process by which the IoT device uses the first private key to verify the integrity, authenticity, and source credibility of the dynamic temporary key. Timeliness verification refers to the process by which the IoT device checks the time information carried by the dynamic temporary key to determine whether it is within a preset valid time window. The national cryptographic hash algorithm refers to State Cryptography Standard 3 (SM3). Time information refers to the millisecond-level UTC timestamp at the time the dynamic temporary key is generated. The random number refers to the 16-bit random value generated by the smart card.

[0111] Understandably, by simultaneously verifying the legitimacy and timeliness of the dynamic temporary key, it can be ensured that control commands originate from a legitimate smart card and have not been tampered with or replayed, thus guaranteeing the security of device control. In one possible implementation, the IoT device performs legitimacy verification by calculating its own local hash value and comparing it with the dynamic temporary key.

[0112] Specifically, IoT devices parse and extract the dynamic temporary key (Temp_Key) from the dynamic encryption commands issued by the edge gateway. They then use the first private key stored in the local device's secure area to verify the validity of the dynamic temporary key, and simultaneously verify the time information corresponding to the dynamic temporary key to determine its authenticity and validity. For example, after receiving a command from the gateway, a door lock first calculates its local hash (Local_Hash), compares it with the Temp_Key, and if the time error is within ±3 minutes, the lock is successfully unlocked. After verification, the Temp_Key is immediately destroyed.

[0113] Step S82: If the dynamic temporary key is valid and its validity period is within the valid range, then decrypt the dynamic encryption instruction to obtain the original control instruction, execute the device control operation corresponding to the original control instruction, and destroy the dynamic temporary key used this time after the operation is completed.

[0114] It should be noted that the effective range refers to a legal range in which the difference between the dynamic temporary key generation time and the local time of the IoT device is within ±3 minutes; decryption refers to the process by which the IoT device uses the first private key to restore the dynamically encrypted command to the original control command; the original control command refers to the unencrypted basic device control command that the user actually needs to execute; device control operation refers to the functional actions such as unlocking, starting, shutting down, and data acquisition performed by the IoT device according to the original control command; destruction refers to the complete and unrecoverable removal of the used dynamic temporary key from the running memory and storage area of ​​the IoT device.

[0115] Understandably, IoT devices destroy dynamic temporary keys immediately after command execution to prevent reuse, illegal theft, or malicious replay, further strengthening the one-command-one-key security mechanism. In one possible implementation, the dynamic temporary key is a one-time key, with a new dynamic temporary key generated for each device control operation. In one embodiment, the device's secure area integrates a hardware-triggered data erasure circuit. After the device completes its control operation, it automatically triggers a physical-level zeroing process for the dynamic temporary key and intermediate computation data. This completely erases key-related data without software intervention, leaving no computational residue, achieving immediate destruction of the single-command key and eliminating the risk of key leakage due to residual data.

[0116] Specifically, when a dynamic temporary key passes validity verification and is within its valid timeframe, the IoT device uses its first private key to decrypt the dynamically encrypted command to obtain the original control command, executes the corresponding device control operation, and immediately destroys the dynamic temporary key used in this operation after completion. For example, after a Bluetooth door lock confirms that the dynamic temporary key is valid and within a ±3 minute validity window, it decrypts the command to obtain the unlocking instruction and executes the unlocking action. After the operation is completed, the dynamic temporary key used in this operation is completely cleared, and no temporary key data is retained.

[0117] This embodiment uses IoT devices to perform dual verification of the legality and timeliness of dynamic temporary keys, and adopts a security mechanism of one key per instruction and immediate destruction of the temporary key after execution. Combined with national cryptographic hash algorithms and hardware-level key security storage capabilities, it achieves closed-loop security control with reliable instruction verification, secure execution process, and zero usage traces. It effectively resists instruction replay, tampering, forgery, and hijacking attacks, and significantly improves the security, reliability, and anti-attack capability of IoT device control.

[0118] In summary, this application is the first to deeply integrate the hardware security capabilities of smart cards with the Blockchain Interaction Protocol (BIP), constructing a localized IoT device collaborative management system with smart cards as the trusted root and no cloud relay required, achieving comprehensive innovation at the architectural, security, and control levels.

[0119] In terms of architecture, this application adopts a decentralized local protocol conversion mechanism based on the extended instruction set of blockchain interaction protocol. Through the lightweight protocol conversion engine built into the edge gateway, it realizes direct real-time interaction between smart cards and various heterogeneous IoT devices such as Bluetooth, Wi-Fi, and Zigbee. It abandons the traditional cloud forwarding mode, reduces instruction transmission latency from the source, and avoids the risk of overall control failure caused by cloud single point of failure and network attacks.

[0120] In terms of security, this application relies on the smart card hardware security element to build an integrated management system of national cryptographic algorithms and dynamic keys. The generation, storage and operation of keys are all performed within the hardware security zone, and key data is not exposed to the outside. At the same time, combined with time information and random numbers, a dynamic key that is valid only once and has limited time validity is generated, forming an end-to-end active security protection mechanism of "one instruction, one key", which significantly improves the anti-forgery, anti-hijacking and anti-replay capabilities of instruction interaction.

[0121] In terms of control mode, this application adopts an offline-online hybrid control mechanism. The smart card pre-stores encrypted instruction generation logic. When the network is normal, remote security control is achieved through the edge gateway. In offline emergency scenarios without network, trusted operation of the device can be completed directly through the near-field communication link, taking into account both the convenience of regular use and the availability in extreme scenarios.

[0122] Therefore, this application takes the hardware security capabilities of smart cards as the core trust foundation, combines blockchain interaction protocols to achieve full-process local secure interaction, and reconstructs the management and control process of IoT devices. Without relying on the cloud, it simultaneously improves the security, real-time performance, compatibility and reliability of the system, and is applicable to various IoT application scenarios such as smart homes, industrial IoT, and smart healthcare.

[0123] For example, in the smart home field, smart cards can be used to manage devices such as door locks and cameras in a unified manner, and the elderly can control smart home appliances via SMS without having to learn complicated apps; in the industrial Internet of Things field, remote authorization and firmware upgrades for factory equipment can be achieved, reducing operation and maintenance costs; in the healthcare field, secure access and privacy protection for medical devices can be guaranteed.

[0124] According to data from multiple authoritative institutions, this application creates high verifiable value in the above three major areas. When smart home technology achieves a 5% penetration rate among the 280 million elderly population, the annual market size will reach 21 billion yuan. When used in the Industrial Internet of Things, it can save cloud and labor costs, reducing the maintenance cost of a single device from $50 to $17, a reduction of 66%. A factory of tens of thousands of square meters can save $830,000 in accident losses annually. In the field of healthcare, the medical device safety solution based on this application has lower costs and higher security, reducing the lifetime compliance cost of a single device by $2,300 (Juniper model).

[0125] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0126] This application also provides an Internet of Things (IoT) device control device, the IoT device control device comprising: A smart card is used to receive an IoT device registration instruction transmitted by an edge gateway, generate first key information based on the IoT device registration instruction, and complete device binding processing. The IoT device registration instruction includes device identification information of the IoT device. In response to a device control instruction and authentication information sent by a user, a security verification process is completed based on the authentication information, and a dynamic encryption instruction is generated according to the first key information and the device control instruction. The dynamic encryption instruction is then sent to the edge gateway. An edge gateway is used to receive device identification information broadcast by IoT devices, generate IoT device registration instructions corresponding to the IoT devices, send the IoT device registration instructions to smart cards, receive dynamic encryption instructions, perform protocol conversion processing on the dynamic encryption instructions, and send the converted dynamic encryption instructions to the bound IoT devices. The Internet of Things (IoT) device is used to broadcast device identification information to the outside world; receive dynamic encryption instructions sent by the edge gateway after protocol conversion, verify the dynamic encryption instructions, and execute the device control operation corresponding to the dynamic encryption instructions after the verification is successful.

[0127] The IoT device control device provided in this application, employing the IoT device control method in the above embodiments, can solve the technical problems in the background art. Compared with the prior art, the beneficial effects of the IoT device control device provided in this application are the same as the beneficial effects of the IoT device control method provided in the above embodiments, and other technical features in the IoT device control device are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0128] This application provides an Internet of Things (IoT) device control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the IoT device control method in Embodiment 1 described above.

[0129] The following is for reference. Figure 9 This document illustrates a structural schematic diagram of an IoT device control device suitable for implementing embodiments of this application. The IoT device control device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The IoT device control device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0130] like Figure 9As shown, the IoT device control device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the IoT device control device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows IoT device control devices to communicate wirelessly or wiredly with other devices to exchange data. While the figures show IoT device control devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0131] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0132] 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 scope of the technology 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.

[0133] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the Internet of Things device control methods provided by the above methods.

[0134] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0135] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0136] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for controlling an Internet of Things (IoT) device, characterized in that, The method is applied to smart cards and includes: The device receives an IoT device registration instruction transmitted from an edge gateway, generates first key information based on the IoT device registration instruction, and completes device binding processing. The IoT device registration instruction includes the device identification information of the IoT device. The edge gateway refers to an IoT edge access device that supports blockchain interaction protocol interaction and has multi-protocol access and local instruction forwarding capabilities. In response to the device control command and authentication information sent by the user, a security verification process is completed based on the authentication information, and a dynamic encryption command is generated according to the first key information and the device control command. The dynamic encryption command is sent to the edge gateway, so that the edge gateway performs protocol conversion on the dynamic encryption command and then sends it to the bound IoT device, thereby triggering the IoT device to receive the dynamic encryption command, perform command verification on the dynamic encryption command, and execute the device control operation corresponding to the dynamic encryption command after the verification is successful.

2. The IoT device control method as described in claim 1, characterized in that, The process of generating first key information based on the IoT device registration instruction and completing device binding, wherein the IoT device registration instruction includes device identification information of the IoT device, including: In a preset hardware-level security element, an encryption algorithm is invoked to generate first key information that matches the IoT device. The first key information is then associated and bound with the device identification information. The first key information includes a first public key and a first private key. The binding completion information is stored in a one-time programmable memory, and a binding completion confirmation message is returned to the edge gateway through an encrypted channel.

3. The IoT device control method as described in claim 1, characterized in that, The step of completing the security verification process based on the authentication information and generating dynamic encryption instructions according to the first key information and the device control instructions includes: Extract the user's identity authentication data and biometric data from the authentication information, and complete dual security verification in the hardware-level security element; After successful verification, based on the bound first key information, a dynamic encrypted instruction corresponding to the device control instruction is generated by combining random number and time information, so that the dynamic encrypted instruction has the security characteristics of single validity and time limitation.

4. A method for controlling an Internet of Things (IoT) device, characterized in that, The method is applied to an edge gateway, which is an IoT edge access device that supports blockchain interaction protocol interaction and has multi-protocol access and local command forwarding capabilities, including: Receive device identification information broadcast by an IoT device and generate an IoT device registration instruction corresponding to the IoT device. The IoT device registration instruction is sent to the smart card, so that after receiving the IoT device registration instruction, the smart card generates first key information based on the IoT device registration instruction and completes the device binding process; the smart card responds to the device control instruction and authentication information sent by the user, completes the security verification process based on the authentication information, and generates a dynamic encryption instruction according to the first key information and the device control instruction; the dynamic encryption instruction is sent to the edge gateway; The system receives the dynamic encryption command, performs protocol conversion processing on the dynamic encryption command, and sends the converted dynamic encryption command to the bound IoT device to trigger the IoT device to receive the dynamic encryption command, perform command verification on the dynamic encryption command, and execute the device control operation corresponding to the dynamic encryption command after the verification is successful.

5. The IoT device control method as described in claim 4, characterized in that, The step of performing protocol conversion processing on the dynamic encryption command and sending the converted dynamic encryption command to the bound IoT device includes: Obtain a preset protocol conversion matching relationship, and adapt and convert the dynamic encryption command according to the communication type of the IoT device; The adapted dynamic encryption command is adjusted to a communication format recognizable by the IoT device, and the processed dynamic encryption command is sent to the IoT device.

6. A method for controlling an Internet of Things (IoT) device, characterized in that, The method is applied to Internet of Things (IoT) devices, including: The device identification information is broadcast to the outside world so that the edge gateway receives the device identification information and generates an IoT device registration instruction corresponding to the IoT device; the IoT device registration instruction is sent to the smart card so that the smart card generates first key information based on the IoT device registration instruction and completes the device binding process after receiving the IoT device registration instruction. The edge gateway is an IoT edge access device that supports blockchain interaction protocol interaction and has multi-protocol access and local instruction forwarding capabilities. The system receives a dynamically encrypted command after protocol conversion from the edge gateway, verifies the command, and executes the device control operation corresponding to the command after successful verification. The dynamically encrypted command is generated by the smart card in response to the device control command and authentication information sent by the user, after completing the security verification process based on the authentication information, according to the first key information and the device control command, and is sent to the edge gateway by the smart card.

7. The IoT device control method as described in claim 6, characterized in that, The process of broadcasting device identification information to enable the edge gateway to receive the device identification information and generate an IoT device registration instruction corresponding to the IoT device; and sending the IoT device registration instruction to the smart card so that the smart card, after receiving the IoT device registration instruction, generates first key information based on the IoT device registration instruction and completes the device binding process, further includes: The device receives encrypted key information forwarded by the edge gateway, wherein the encrypted key information is obtained by the smart card encrypting the first private key of the first key information using the second public key corresponding to the IoT device. The encryption key information is decrypted using a pre-configured second private key to obtain the first private key, which is then stored in the secure area of ​​the device. After the decryption operation is completed, the second key information of the IoT device itself is destroyed, so that the IoT device can subsequently complete instruction verification only based on the first key information. The second key information includes a second public key and a second private key.

8. The IoT device control method as described in claim 7, characterized in that, The step of verifying the dynamic encryption command and executing the device control operation corresponding to the dynamic encryption command after the verification is successful includes: The dynamic temporary key is extracted from the dynamic encryption instruction, and its legality and timeliness are verified by combining it with the first private key stored locally. The dynamic temporary key is generated based on the first public key, time information and random number through the national cryptographic hash algorithm. If the dynamic temporary key is valid and its validity period is within the valid range, the dynamic encryption instruction is decrypted to obtain the original control instruction, the device control operation corresponding to the original control instruction is executed, and the dynamic temporary key used this time is destroyed after the operation is completed.

9. An Internet of Things (IoT) device control device, characterized in that, The IoT device control device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the IoT device control method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the Internet of Things device control method as described in any one of claims 1 to 8.