Safety control method and system for remote control of Internet of Things

Abstract

The invention relates to the technical field of management of the Internet of Things, and discloses a security control method and system for remote control of the Internet of Things, and the system comprises a security remote control platform, a zero-trust gateway, an authentication module, a security policy engine, edge proxy equipment and an encryption communication module. And the authentication module is used for performing identity authentication on the equipment and the user. The security policy engine dynamic access control table comprises access rule entries and associated signature information, and is issued to the edge proxy device through the zero-trust gateway. And the edge proxy device stores the dynamic access control table, verifies the signature information based on the platform public key, and performs matching and verification according to the access rule entry when receiving the control instruction. And the encryption communication module is used for performing encryption transmission on the access control table, the control instruction and the execution result. According to the invention, the whole process of remote control of the Internet of Things is dynamic, secure and credible, and the anti-attack capability and operation reliability of the system are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) management technology, and more specifically, to a security control method and system for remote control of IoT. Background Technology

[0002] With the rapid proliferation of IoT devices in industrial production, energy management, smart homes, and public infrastructure, remote control and secure operation and maintenance have become core requirements for building smart IoT systems. Typical remote control platforms often need to simultaneously meet multiple functionalities, including large-scale device access, heterogeneous protocol compatibility, real-time status monitoring, and remote command issuance. However, in practical applications, due to the large number of devices, complex communication protocols, and diverse application scenarios, IoT remote control presents new challenges in terms of security and reliability. Therefore, building a remote control system with robust authentication mechanisms, fine-grained access control capabilities, and end-to-end encrypted transmission has become an urgent technical problem to be solved.

[0003] For example, invention patent CN114745409A, a method for remote control of smart IoT devices, proposes to achieve remote device control, batch APP management, and device operation and maintenance through an IoT management platform and edge agent, which can improve the efficiency of remote management to a certain extent. However, this solution mainly focuses on device access management, APP lifecycle management, and business process-oriented operation and maintenance. In terms of security protection, it still has the following shortcomings: device access mainly relies on traditional certificate verification and platform-side verification, lacking a two-way strong identity authentication mechanism that combines users and devices; access permissions are mostly statically set and cannot be dynamically adjusted according to task risk level or context environment, resulting in problems such as excessive permissions or delayed expiration; although data transmission is involved in the command issuance process, end-to-end encryption binding and digital signature mechanisms are not introduced, posing a risk of tampering or replay attacks; the execution of control commands on the edge side lacks one-time tokens and anti-replay control mechanisms, which cannot effectively resist forged requests and command reuse.

[0004] Therefore, it is necessary to design a security control method and system for remote control of the Internet of Things to solve the problems existing in the current technology. Summary of the Invention

[0005] In view of this, the present invention proposes a security control method and system for remote control of the Internet of Things, aiming to solve the problems of low reliability protection and poor system security in the current technology throughout the remote control process.

[0006] In one aspect, the present invention proposes a security control system for remote control of the Internet of Things, comprising: The system includes a secure remote control platform, a zero-trust gateway, an authentication module, a security policy engine, an edge proxy device, and an encrypted communication module; among which, The authentication module is used to authenticate devices and users when terminal devices access the network and users log in. The security policy engine generates a dynamic access control table based on the authentication result. The dynamic access control table includes access rule entries and associated signature information, and is distributed to the edge proxy device through the zero trust gateway. The edge proxy device is equipped with a rule storage unit, a rule verification unit, and a decision execution unit. The rule storage unit is used to store a dynamic access control table, the rule verification unit is used to verify the signature information based on the platform public key, and the decision execution unit is used to match and verify the access rule entries when receiving control instructions. Instructions that fail verification are rejected, and instructions that pass verification generate a one-time execution token and submit it for execution. The encrypted communication module is used to encrypt the access control table, control commands, and execution results between the secure remote control platform and the edge agent device.

[0007] Furthermore, when the authentication module verifies the identity of the device and the user during terminal device access and user login, it includes: During the initial access phase of the terminal device, the hardware security module within the terminal device is invoked to generate a device key pair to obtain a device public key and a device private key. The device public key is then written into the device digital certificate and bound to the device identifier. When the terminal device initiates access, a TLS 1.3 session is established through the encrypted communication module, and two-way certificate authentication is enabled. The authentication module performs certificate chain verification, validity period verification, and revocation status query based on OCSP or CRL on the device digital certificate, generates a random challenge value, and sends it along with session parameters to the terminal device. The terminal device uses the device private key to sign the random challenge value and the session parameters and returns the signature. The authentication module uses the device public key to complete the signature verification to confirm the identity of the terminal device. During user login, the authentication module performs a derived hash comparison based on PBKDF2 or Argon2 on the user password, and simultaneously verifies at least one of the following as a second factor: a time-synchronized one-time password (TOTP) or a hardware key-based FIDO2 / WebAuthn assertion. When biometrics are enabled, only biometric template hashes calculated by the local trusted execution environment are compared. After both the terminal device and the user pass verification, the authentication module generates the authentication result, which includes user identity information, device type information, device identifier, authentication strength level, and session identifier. Then, it issues an authentication token signed by the platform's private key to encapsulate the user identity information and the device identifier, and transmits it to the security policy engine via the zero-trust gateway to generate the dynamic access control table.

[0008] Furthermore, when the security policy engine generates a dynamic access control list based on the authentication result, it includes... The security policy engine receives the authentication token issued by the authentication module and parses it to obtain user identity information, device type information, device identifier, authentication strength level, and session identifier. It selects the least privilege template matching the device type information and authentication strength level from the policy template library and instantiates the least privilege template according to the task risk level, obtaining access rule entries containing subject identifier, object identifier, and action identifier. During instantiation, it configures context constraints for each access rule entry, including time window, geographical location range, device firmware version number, command parameter range, and call frequency threshold. For the same subject identifier... Conflict resolution is performed on multiple access rule entries with the object identifier, prioritizing the one with the higher priority field, and in the case of equal priorities, prioritizing the one with the newest sequence number. A sequence number, time-to-live (TTL), and revocation flag fields are generated for each access rule entry. A rule digest is calculated based on SHA-256, and the rule digest is signed using the platform's private key according to the ECDSA-P256 algorithm to form the signature information. All access rule entries and their corresponding signature information are combined to generate the dynamic access control table, and a table-level digest and version number are generated for differential update identification. The dynamic access control table and the table-level digest are output to the zero-trust gateway.

[0009] Furthermore, when the data is sent to the edge proxy device through the zero-trust gateway, it includes: The zero-trust gateway establishes a TLS 1.3 two-way authentication session through the encrypted communication module; during distribution, it appends a version number, table-level digest, and differential update identifier to the dynamic access control list, and calculates an SHA-256 digest of the table-level digest and generates a signature using the gateway's private key according to the ECDSA-P256 algorithm; after receiving the dynamic access control list, the edge proxy device verifies the signature and checks the version number and table-level digest based on the platform's public key to confirm the integrity and timeliness of the dynamic access control list.

[0010] Furthermore, when the rule storage unit saves the dynamic access control table, it includes: The rule storage unit sets up an active table area and a candidate table area; the dynamic access control table, which has passed the verification by the rule verification unit and carries a version number and table-level digest, is written to the candidate table area in an append-only manner, and the access rule entry, the signature information, and the sequence number are recorded one by one; the rule storage unit generates a rule index based on the subject identifier, object identifier, and action identifier and stores it synchronously with the candidate table area; the table-level digest of the candidate table area is recalculated and compared with the received table-level digest, and an atomic switch is performed after they are consistent, updating the active table pointer to the dynamic access control table corresponding to the version number, and persisting the current version number and sequence number water level; during differential updates, access rule entries are merged and deduplicated according to the sequence number range, and in case of conflicts, they are retained according to the priority field and the newer sequence number; access rule entries carrying a revocation flag field are marked for immediate expiration and access rule entries that have expired TTL are cleaned up in the periodic task; in case of switch failure, the active table area of ​​the previous version is rolled back according to the most recent checkpoint.

[0011] Furthermore, when the rule verification unit verifies the signature information based on the platform public key, it includes: The rule verification unit reads the platform public key set and corresponding key identifier from the trust anchor storage area, and selects a verification public key based on the key identifier in the signature information; it calculates the SHA-256 digest of the table-level digest of the dynamic access control table and verifies the table-level signature using the verification public key according to the ECDSA-P256 algorithm; simultaneously, it calculates the SHA-256 digest of the rule digest of each access rule entry and verifies the rule-level signature using the verification public key according to the ECDSA-P256 algorithm; under the condition that the signature verification is successful, it verifies that the version number is monotonically non-decreasing relative to the current version number, and rejects import if it is less than the current version number, and recalculates the table-level digest to be consistent with the signature payload; for each access rule entry, it verifies that the sequence number is greater than the persistent sequence number watermark, the validity period TTL has not expired, and the revocation flag field is not set; when the signature information carries a key rotation identifier, it allows the use of the previous version verification public key for verification within the key rotation window, and only accepts the current verification public key after the window expires; after completing the above verification, it outputs the verification result to drive the rule storage unit to perform candidate table area writing and atomic switching.

[0012] Furthermore, when the decision execution unit receives a control instruction and performs matching and verification according to the access rule entries, it includes: The decision execution unit parses the control command to obtain the subject identifier, object identifier, and action identifier, wherein the subject identifier is mapped from the session identifier, the object identifier is the target device identifier, and the action identifier is the command type; it performs matching according to the rule index in the rule storage unit. If multiple access rule entries are obtained, the one with the higher priority field is prioritized, and if the priorities are the same, the one with the newest sequence number is prioritized to determine the target access rule entry; the context constraints of the target access rule entry are verified, including: comparing the time window with the platform time, performing point-to-point judgment on the geographical location range based on the geographical location coordinates reported by the edge agent device, comparing the version requirements with the device firmware version number, verifying the unit normalization and value range of the command parameters, and comparing the call frequency threshold with the counter based on the sliding time window; if any of the verifications fails, a rejection result is output and the rejection reason code is recorded.

[0013] Furthermore, after the decision execution unit completes the matching and verification, it also includes: The decision execution unit calculates a SHA-256 instruction digest for the normalized representation of the control command, the rule entry identifier, and the session identifier. It then assembles a one-time execution token containing the instruction digest, the rule entry identifier, a timestamp, a random number, a monotonic counter, and a token validity period (TTL). The token is then signed using the edge agent device's private key according to the ECDSA-P256 algorithm. The signed token, along with the control command, is submitted to the device driver. The monotonic counter and the random number are registered in the local token cache for replay verification and association with the execution result. Upon receiving the execution result, the decision execution unit verifies the one-time execution token identifier and reports the result.

[0014] Furthermore, the encrypted communication module, when performing encrypted transmission of the access control list, control commands, and execution results between the secure remote control platform and the edge agent device, includes: The encrypted communication module establishes a two-way certificate authentication session based on TLS 1.3. This session uses ECDHE key exchange and selects either TLS_AES_128_GCM_SHA256 or TLS_CHACHA20_POLY1305_SHA256 cipher suites. It derives the session key using HKDF and exports the channel binding value. The data to be transmitted is framed according to its content type identifier. The frame header includes the session identifier, message sequence number, and timestamp. The SHA-256 digest of the authentication token or the one-time execution token is injected as additional authentication data into the TLS record layer to be used together with the channel binding value for integrity verification and session binding. After TLS record layer verification is completed on the receiving side, the message sequence number is further verified to be monotonically increasing and not falling within the replay window. Based on the content type identifier, the message sequence number is assigned to the rule storage unit, the decision execution unit, or the result reporting process. During session recovery, a TLS 1.3 session ticket is used, with a limited validity period and binding to the device identifier. 0-RTT data is prohibited on the channel carrying the control commands.

[0015] Compared with existing technologies, the advantages of this invention are as follows: the authentication module achieves two-way strong authentication between the terminal device and the user, ensuring the legitimacy of the access subject; the security policy engine dynamically generates an access control table with signature information based on the authentication result and securely distributes it to the edge agent through a zero-trust gateway, avoiding the risk of unauthorized access caused by static permissions; the rule storage unit and rule verification unit within the edge agent device ensure the integrity and trustworthiness of the access control table during storage and use; the decision execution unit, based on strict matching and context constraint verification, only allows the execution of legitimate instructions and prevents replay attacks and forged instructions through one-time execution tokens; the encrypted communication module performs end-to-end encryption and integrity verification of the access control table, control instructions, and execution results between the platform and the edge, ensuring that the transmission process is not stolen or tampered with. Through the synergistic effect of the above technical means, the problems of lack of two-way strong authentication, rigid permission control, and insufficient anti-tampering and anti-replay mechanisms for instructions are overcome, realizing the dynamism, security, and trustworthiness of the entire process of IoT remote control, and improving the system's anti-attack capability and operational reliability.

[0016] On the other hand, this application also provides a security control method for IoT remote control, applied to the aforementioned security control system for IoT remote control, comprising: When a terminal device accesses and a user logs in, authentication is performed. The authentication includes generating a device key pair and writing it into a digital certificate, establishing a TLS 1.3 two-way authentication session, performing certificate chain verification, validity period verification and revocation status query on the device certificate, performing derived hash comparison on the user password, and performing multi-factor authentication in combination with one-time password or hardware key-based authentication methods. After the authentication is successful, an authentication result is generated and an authentication token is issued. Receive and parse the authentication token, instantiate access rule entries from the policy template library based on user identity information, device type information and task risk level, configure context constraints for the access rule entries and generate serial number, validity period TTL and revocation flag fields, calculate rule digest and sign, combine to generate dynamic access control table and attach version number and table-level digest; Establish a TLS 1.3 mutual authentication session, append a version number, table-level digest, and differential update identifier to the dynamic access control list, sign the table-level digest, and send it to the target end; After receiving the dynamic access control table, the signature, version number and table-level digest are verified. If the verification is successful, they are written into the candidate table and an atomic switch is performed to update the active table after the comparison is consistent. When receiving a control command, the system matches and verifies the access rules entries in the dynamic access control table, comparing the subject identifier, object identifier, action identifier, and context constraints. Control commands that fail the verification are rejected, while control commands that pass the verification generate a one-time execution token, sign it, and submit it for execution along with the control command. During remote control, the dynamic access control table, control commands, and execution results are encrypted and transmitted, and a message sequence number and channel binding value are attached during transmission to complete integrity verification and reverse playback control.

[0017] It is understandable that the aforementioned security control methods and systems for remote control of the Internet of Things have the same beneficial effects, and will not be elaborated further here. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A functional block diagram of a security control system for remote control via the Internet of Things provided in an embodiment of the present invention; Figure 2 A flowchart of a security control method for remote control of the Internet of Things provided in an embodiment of the present invention. Detailed Implementation

[0019] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] For example, in an Industrial Internet of Things (IIoT) scenario, a smart factory deploys hundreds of heterogeneous devices, including PLC controllers, sensors, and robotic arms. Maintenance engineers need to perform firmware upgrades or parameter adjustments on these devices at different times via a remote platform. Because the existing system uses fixed permission templates, engineers retain high-level operating privileges outside of working hours. Furthermore, access rules are not updated promptly after firmware upgrades, potentially allowing exploitation of vulnerabilities in older versions. Control commands are transmitted via traditional TLS (Transport Layer Security) channels but are not bound to device identifiers or session contexts. Attackers can intercept legitimate commands, modify the target device identifier, and redirect the start command for a high-temperature furnace to other devices. The edge proxy device only verifies the basic format of the received commands, failing to check if the command parameters exceed preset thresholds. This allows the robotic arm to execute commands even when its motion parameters exceed physical limits.

[0021] For this, please refer to Figure 1 As shown, this application proposes a security control system for IoT remote control, including: a secure remote control platform, a zero-trust gateway, an authentication module, a security policy engine, an edge agent device, and an encrypted communication module. The authentication module is used to authenticate devices and users when they access the network and log in. The security policy engine generates a dynamic access control list based on the authentication results. The dynamic access control list includes access rule entries and associated signature information, and is distributed to the edge agent device through the zero-trust gateway. The edge agent device is equipped with a rule storage unit, a rule verification unit, and a decision execution unit. The rule storage unit stores the dynamic access control list, the rule verification unit verifies the signature information based on the platform's public key, and the decision execution unit matches and verifies access rule entries when receiving control commands. Commands that fail verification are rejected, and commands that pass verification generate a one-time execution token and are submitted for execution. The encrypted communication module is used to encrypt the transmission of the access control list, control commands, and execution results between the secure remote control platform and the edge agent device.

[0022] The secure remote control platform can be implemented using a distributed microservice architecture to coordinate data interaction and policy execution between modules. The zero-trust gateway is a network access component implementing a zero-trust security model, specifically using two-way certificate authentication and dynamic policy distribution mechanisms to block unverified devices or users from accessing the network. The authentication module is the functional unit that performs identity verification, specifically using a hardware security module to generate device key pairs combined with a multi-factor authentication protocol to ensure two-way trusted verification of device and user identities. The security policy engine is the decision-making component that generates access control policies, specifically using a policy template library and a dynamic context constraint matching algorithm to generate fine-grained access rules based on real-time authentication results. The dynamic access control table is a policy set containing variable permission rules, specifically using an entry structure including subject identifiers, object identifiers, action identifiers, and context constraints to achieve adaptive permission adjustments based on environmental risks. The edge proxy device is an execution terminal deployed at the edge of the IoT network, specifically using an architecture that separates rule storage, verification, and execution units to implement real-time verification of access control policies locally. The rule storage unit is the database module that stores dynamic policies. It can be implemented using append-only writes and atomic switching mechanisms to ensure the integrity and consistency of policy updates. The rule verification unit is the functional module that verifies the legality of policies. It can be implemented using public key verification and digest comparison algorithms to prevent policy injection through tampering or forgery. The decision execution unit is the module that verifies and executes control instructions. It can be implemented using one-time token generation and anti-replay counter mechanisms to ensure the legality and uniqueness of instructions. The encrypted communication module is the channel component that ensures secure data transmission. It can be implemented using the TLS 1.3 protocol and end-to-end encryption algorithms to prevent data leakage or man-in-the-middle attacks.

[0023] This application achieves two-way strong authentication between devices and users through an authentication module, generates dynamic access rules with context constraints through a security policy engine, and relies on edge agent devices to perform real-time policy verification and one-time token control locally. At the same time, it adopts end-to-end encrypted communication to ensure data security throughout the entire link, forming a closed-loop protection system for the entire process from identity authentication and dynamic authorization to command execution. This effectively solves the technical defects of traditional IoT remote control, such as excessive static permissions, lagging policy updates, and weak transmission security.

[0024] As a preferred embodiment, the solution of this application is specifically implemented as follows: The secure remote control platform is deployed in a cloud data center and consists of a high-performance server cluster. Zero-trust gateways are deployed on edge computing nodes, responsible for terminal device access and data forwarding. The authentication module integrates multi-factor authentication, supporting various authentication methods such as certificates, passwords, and biometrics. The security policy engine adopts a role-based access control model, dynamically generating access rules based on risk assessment algorithms. The edge proxy device uses an embedded hardware design with local storage and computing capabilities. The encrypted communication module implements end-to-end encryption based on the TLS 1.3 protocol.

[0025] During device access, the terminal device first initiates a TLS connection request to the zero-trust gateway. The zero-trust gateway verifies the validity of the device certificate and forwards the authentication request to the authentication module. The authentication module generates a random challenge value, requiring the device to sign it using its private key. Upon successful verification, the authentication module generates a unique device identifier for the device.

[0026] When a user logs in, the authentication module first verifies the username and password. Then, it prompts the user to provide a second factor, such as a one-time password or a hardware key. After successful multi-factor authentication, the authentication module generates an authentication result containing user identity information, device identifier, authentication strength, and other details.

[0027] The security policy engine receives the authentication result and selects a suitable base template from the policy template library. Based on the user role, device type, and current task risk level, it instantiates the template to generate specific access rule entries. Each rule includes a subject, object, operation type, and corresponding constraints. The policy engine generates a unique sequence number and validity period for each rule and signs the rule digest using the platform's private key.

[0028] The zero-trust gateway distributes the dynamic access control list to the corresponding edge agent devices. The rule verification unit of the edge agent device first verifies the table-level signature, and then verifies the rule-level signature one by one. After successful verification, the rule storage unit writes the new access control list to the candidate area, and switches it to the active table after confirming its integrity.

[0029] When a user sends control commands through a remote control platform, the commands are first encrypted by the encrypted communication module before being sent to the edge agent device. Upon receiving the command, the decision execution unit parses out the subject identifier, object identifier, and operation type, and performs rule matching in the activity table. If a match is successful, it further checks whether contextual constraints, such as time windows and geographical locations, are met.

[0030] For commands that pass verification, the decision execution unit generates a one-time execution token containing information such as command digest, rule identifier, and timestamp, and signs it using the device's private key. The execution token is submitted to the device driver along with the command for execution. After execution, the result is transmitted back to the secure remote control platform via an encrypted communication module.

[0031] Through the above scheme, this application achieves end-to-end security protection for the IoT remote control system. Multi-factor authentication and dynamic challenge response mechanisms effectively prevent identity forgery and man-in-the-middle attacks. Risk-assessment-based dynamic access control policies provide fine-grained permission management, avoiding the abuse of static permissions. End-to-end encrypted transmission combined with channel binding technology ensures the confidentiality and integrity of control commands. Real-time rule matching and context constraint verification at the edge effectively intercept unauthorized commands and abnormal parameter requests. The introduction of one-time execution tokens prevents command replay attacks.

[0032] This application further proposes a method where, during the initial access phase of the terminal device, the hardware security module within the terminal device generates a device key pair to obtain the device public key and device private key, and writes the device public key into the device digital certificate and binds it to the device identifier. When the terminal device initiates access, a TLS 1.3 session is established through the encrypted communication module, and two-way certificate authentication is enabled. The authentication module performs certificate chain verification, validity period verification, and revocation status query based on OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List) on the device digital certificate, generates a random challenge value, and sends it along with session parameters to the terminal device. The terminal device uses its private key to sign the random challenge value and session parameters and returns the signature. The authentication module uses the device public key to complete the signature verification to confirm the identity of the terminal device. During user login, the authentication module performs a derived hash comparison based on PBKDF2 or Argon2 on the user's password, and simultaneously verifies at least one of the following as a second factor: a time-synchronized one-time password (TOTP) or a hardware key-based FIDO2 / WebAuthn assertion. When biometrics are enabled, only biometric template hashes calculated by the local trusted execution environment are compared. After both the terminal device and the user pass verification, the authentication module generates an authentication result containing user identity information, device type information, device identifier, authentication strength level, and session identifier. It then issues an authentication token signed by the platform's private key to encapsulate the user identity information and device identifier, which is transmitted via a zero-trust gateway to the security policy engine for generating a dynamic access control list.

[0033] In the hardware security module, when generating device key pairs, an asymmetric key pair can be generated using an encryption chip conforming to the FIPS 140-2 standard to ensure that the private key cannot be exported. During the two-way certificate authentication process, the platform and the terminal device exchange digital certificates and verify each other's identities through a pre-set trust chain. For example, the platform certificate is issued by an authoritative CA, and the terminal device certificate is issued by the platform and associated with a unique device identifier. The random challenge value is generated by the authentication module based on a hardware random number generator, with a length of no less than 128 bits. Session parameters include a session identifier and a timestamp, and the signature algorithm used is ECDSA-P256. When using PBKDF2 for user password hash comparison, the iteration count is no less than 10,000 times, and the salt value is randomly generated by the platform and bound to the user identifier. In the second-factor authentication, TOTP generates a 6-bit dynamic code based on the HMAC-SHA1 algorithm, and the FIDO2 / WebAuthn assertion is generated by the hardware security key and includes a challenge value signature. The biometric template hash is calculated using SHA-256 in a local trusted execution environment, ensuring that the original biometric data does not leave the device.

[0034] Specifically, upon initial connection of a terminal device, the hardware security module generates a device key pair. The platform writes the device's public key into the certificate and binds it to the device identifier, ensuring traceability of the device's identity in subsequent communications. During the access phase, two-way certificate authentication forces the platform and device to exchange certificates, verifying the legitimacy of both parties' identities through certificate chain verification. OCSP or CRL queries are used to exclude revoked certificates, preventing unauthorized device access. Random challenge values ​​and session parameters are returned after signing, ensuring the device holds the corresponding private key and responds in real-time, preventing replay attacks. During user login, multi-factor authentication combines password hashes with dynamic tokens or hardware keys to enhance authentication strength. Biometric features are processed only in a local trusted environment, preventing the leakage of sensitive information. The authentication result encapsulates the user's identity and device identifier, generating an authentication token through platform private key signing, ensuring token integrity and credible origin. Thus, the two-way strong authentication mechanism between devices and users effectively solves the security deficiencies of one-way verification and single-factor authentication in traditional solutions, providing a reliable identity foundation for dynamic access control.

[0035] For example, when the authentication module verifies the identity of the device and user during terminal device access and user login, it includes: During the initial access phase of the terminal device, the hardware security module within the terminal device is invoked to generate a device key pair to obtain the device public key and device private key. The device public key is then written into the device digital certificate and bound to the device identifier. Specifically, the hardware security module can be an embedded secure element (eSE) or a trusted platform module (TPM). It generates a random seed through an internal random number generator and generates an asymmetric key pair based on an elliptic curve cryptography algorithm (such as ECDSA-P256). The device public key, along with the device's unique identifier (such as MAC address, serial number, etc.), is written into the device digital certificate in X.509 format.

[0036] When a terminal device initiates access, a TLS 1.3 session is established through the encrypted communication module and two-way certificate authentication is enabled. The authentication module performs certificate chain verification, validity period verification, and revocation status query based on OCSP or CRL on the device's digital certificate, generates a random challenge value, and sends it to the terminal device along with the session parameters. The terminal device uses its private key to sign the random challenge value and session parameters and returns the signature. The authentication module uses the device's public key to complete the signature verification to confirm the identity of the terminal device.

[0037] During user login, the authentication module performs a derived hash comparison based on PBKDF2 or Argon2 on the user's password, and simultaneously verifies at least one of the following as a second factor: a time-synchronized one-time password (TOTP) or a hardware key-based FIDO2 / WebAuthn assertion. When biometrics are enabled, only biometric template hashes calculated by the local trusted execution environment are compared. After both the terminal device and the user pass verification, the authentication module generates an authentication result containing user identity information, device type information, device identifier, authentication strength level, and session identifier. It then issues an authentication token signed by the platform's private key to encapsulate the user identity information and device identifier, which is transmitted via a zero-trust gateway to the security policy engine for generating a dynamic access control list.

[0038] The above technical solutions enhance the credibility of device identities by generating device key pairs through hardware security modules. The adoption of TLS 1.3 two-way authentication and certificate verification mechanisms strengthens the security of device access. The introduction of multi-factor authentication and biometric recognition improves the reliability of user authentication. This multi-layered, multi-dimensional authentication mechanism effectively prevents device impersonation and identity spoofing, thereby improving the security and credibility of the IoT remote control system.

[0039] This application further proposes a security policy engine that receives authentication tokens and parses user identity information, device type information, device identifier, authentication strength level, and session identifier. It selects the least privilege template matching the device type information and authentication strength level from the policy template library and instantiates the least privilege template according to the task risk level, resulting in access rule entries containing subject identifier, object identifier, and action identifier. During instantiation, context constraints are configured for each access rule entry, including time window, geographical location range, device firmware version number, command parameter range, and call frequency threshold. Conflict resolution is performed on multiple access rule entries with the same subject identifier and object identifier, prioritizing the one with the higher priority field, and in the case of equal priorities, prioritizing the one with the newest sequence number. A sequence number, time-to-live (TTL), and revocation flag fields are generated for each access rule entry. A rule digest is calculated based on SHA-256, and the rule digest is signed using the platform's private key according to the ECDSA-P256 algorithm to form signature information. All access rule entries and their corresponding signature information are combined to generate a dynamic access control table, and a table-level digest and version number are generated for differential update identifiers. Output the dynamic access control list and table-level summary to the zero-trust gateway.

[0040] The strategy template library stores minimum permission templates for different device types. For example, the industrial sensor device template only includes data read permissions, while the intelligent control device template includes parameter adjustment permissions. Task risk levels are divided into low, medium, and high. High-risk tasks are instantiated with additional geographical location constraints and call frequency limits on top of the template. Command parameter ranges in context constraints are defined by numerical intervals; for example, temperature control command parameters are limited to 0-100 degrees Celsius. During conflict resolution, a priority field distinguishes between emergency and routine operations, and the sequence number is generated using a 64-bit incrementing counter. The rule digest calculation includes the concatenated values ​​of the subject identifier, object identifier, action identifier, and context constraint fields. The signature process uses the ECDSA-P256 algorithm to generate a 64-byte signature value. The differential update flag is set as a binary flag, with 0 indicating a full update and 1 indicating a differential update.

[0041] Specifically, upon receiving the authentication token, the security policy engine first extracts the device type information and authentication strength level, then filters the minimum permission template from the policy template library. For example, when the device type is a smart lock and the authentication strength is two-factor authentication, a template that allows remote unlocking but limits the number of operations is selected. Templates are instantiated based on the task risk level. For high-risk tasks, geographical location constraints are added to the template, limiting operations to the user-preset geofence area. During instantiation, time window constraints are added to each access rule entry, such as allowing control commands to be executed only on weekdays from 9:00 AM to 6:00 PM. For multiple access rules for the same device, conflict resolution is achieved by comparing the priority field and the serial number; for example, a high-priority emergency unlock command overrides a regular lock command. Each access rule entry generates an independent serial number and validity period, automatically expiring after the expiration date. The rule digest is hashed using SHA-256 and signed with the platform's private key to ensure the rule entry is tamper-proof. The dynamic access control list includes a version number and a table-level digest. The version number uses a monotonically increasing mechanism, and the table-level digest is generated by XORing all rule digests for quick data integrity verification. During differential updates, only the version number difference is transmitted, reducing data transmission volume through a deduplication mechanism.

[0042] For example, the security policy engine receives the authentication token issued by the authentication module and parses it to obtain user identity information, device type information, device identifier, authentication strength level, and session identifier. It selects the least privilege template from the policy template library that matches the device type information and authentication strength level, and instantiates the least privilege template according to the task risk level, resulting in access rule entries containing subject identifier, object identifier, and action identifier.

[0043] During instantiation, context constraints are configured for each access rule entry. These constraints include time window, geographic location range, device firmware version number, command parameter range, and call frequency threshold. Conflict resolution is performed on multiple access rule entries with the same subject and object identifiers, prioritizing the rule with the higher priority field, and in cases where priorities are equal, prioritizing the rule with the newest serial number.

[0044] For each access rule entry, a sequence number, time-to-live (TTL), and revocation flag fields are generated. A rule digest is calculated based on SHA-256, and the rule digest is signed using the platform's private key according to the ECDSA-P256 algorithm to form a signature. All access rule entries and their corresponding signatures are combined to generate a dynamic access control table, and a table-level digest and version number are generated for differential update identification. The dynamic access control table and table-level digest are then output to the zero-trust gateway.

[0045] For example, after receiving the authentication token, the security policy engine parses it to obtain the user identity as "administrator," the device type as "industrial controller," the device identifier as "PLC-001," the authentication strength level as "high," and the session identifier as "SESSION-12345." Based on the device type and authentication strength level, it selects the "Industrial Controller Advanced Permission Template" from the policy template library. Considering that the current task risk level is "medium," the template is instantiated, and access rule entries are generated: Subject Identifier: Administrator; Object Identifier: PLC-001; Action Identifier: Read Status, Modify Parameters, Start Device.

[0046] Configure context constraints for this entry: Time window: Weekdays 9:00-18:00; Geographical location range: Within the factory area; Equipment firmware version: ≥V2.0; Command parameter range: Temperature setting [20℃, 30℃]; Call frequency threshold: No more than 10 times per minute.

[0047] Generate a serial number "001", a validity period TTL of "24 hours", and a revocation flag of "false". Calculate a rule digest and sign it using the platform's private key. Add this entry and its signature information to the dynamic access control table, generate a table-level digest and version number "V1.0", and finally output it to the zero-trust gateway.

[0048] Through the above technical solutions, this application achieves dynamic access control list generation based on authentication results and task risk levels. By selecting and instantiating the least privilege template, precise control of access permissions is ensured. Configured context constraints further refine the applicable conditions of access rules, enhancing the flexibility and security of access control. Lifecycle management of access rules is achieved by generating serial numbers, expiration dates, and revocation flags. The use of a digital signature mechanism guarantees the integrity and immutability of access rules. Generating table-level digests and version numbers facilitates subsequent differential updates, improving the efficiency of access control list distribution. These measures collectively construct a dynamic, fine-grained, and secure access control mechanism, effectively solving problems such as inflexible static permission settings, excessively broad permission scope, or untimely updates, thus improving the security of IoT remote control systems.

[0049] In some of the solutions described above in this application, the dynamic access control list may be subject to tampering during transmission, and the edge agent device cannot effectively identify the policy table version update status, resulting in chaotic policy synchronization or insufficient integrity verification, which in turn affects the reliable execution of access control policies.

[0050] This application further proposes to establish a two-way authentication session through an encrypted communication module, and to attach a version number, table-level digest and differential update identifier when distributing dynamic access control lists. After calculating the digest of the table-level digest, a signature is generated using the gateway's private key. After receiving the signature, the edge agent device verifies the signature and checks the version number and table-level digest based on the platform's public key.

[0051] The two-way authentication session is established based on the TLS 1.3 protocol, ensuring the confidentiality and trustworthiness of the transmission channel. The version number identifies the update sequence of the policy table; the table-level digest is generated through hash calculation, and the differential update identifier indicates whether it is an incremental update. The signature generated by the gateway's private key binds the table-level digest to the version number, preventing data tampering during transmission. The edge proxy device verifies the signature using the platform's public key to confirm the legitimacy of the policy table's source and data integrity, while simultaneously verifying the version number to ensure that the received policy table version is not lower than the current version, preventing version rollback attacks.

[0052] Specifically, when establishing a two-way authentication session, the encrypted communication module uses the TLS 1.3 protocol to negotiate the session key and verifies the legitimacy of both communicating parties through certificate verification. When distributing the dynamic access control table, the zero-trust gateway appends the version number and table-level digest to the policy table header, and the differential update flag indicates whether only changed entries are transmitted. After performing SHA-256 hash calculation on the table-level digest, a digital signature is generated using the ECDSA-P256 algorithm combined with the gateway's private key, forming an unforgeable integrity credential. After receiving the data, the edge agent device first verifies the signature validity using the platform's public key to confirm that the policy table has not been tampered with and its source is trustworthy. Subsequently, it verifies whether the version number is greater than or equal to the current stored version to prevent malicious injection of old version policies. The secondary calculation and comparison of the table-level digest further ensures data integrity. When the differential update flag is activated, the edge agent device merges new entries according to the sequence number range, avoiding the bandwidth consumption caused by full transmission. This process, through cryptographic means and version control mechanisms, achieves secure transmission and reliable synchronization of the policy table, eliminating the risk of tampering and version confusion during transmission.

[0053] For example, a zero-trust gateway establishes a TLS 1.3 two-way authentication session through an encrypted communication module. When distributing dynamic access control lists (MAC lists), a version number, table-level digest, and differential update identifier are appended to the MAC list. After calculating the SHA-256 digest of the table-level digest, a signature is generated using the gateway's private key according to the ECDSA-P256 algorithm. Upon receiving the MAC list, the edge agent device verifies the signature and checks the version number and table-level digest based on the platform's public key to confirm the integrity and timeliness of the MAC list.

[0054] Specifically, the zero-trust gateway first establishes a TLS 1.3 two-way authentication session with the edge proxy device through an encrypted communication module. During the session establishment process, both parties exchange and verify their respective digital certificates to ensure the authenticity of their identities. Next, the zero-trust gateway appends a version number, a table-level digest, and a differential update identifier to the dynamic access control list to be distributed. The version number identifies the current version of the access control list, the table-level digest is a summary calculation of the entire access control list content, and the differential update identifier indicates whether it is an incremental update.

[0055] Furthermore, the zero-trust gateway performs a SHA-256 hash calculation on the table-level digest to obtain a fixed-length digest value. Then, it uses the gateway's private key to digitally sign this digest value using the ECDSA-P256 algorithm. This step ensures the authenticity and integrity of the access control table's origin.

[0056] Therefore, upon receiving a dynamic access control list, the edge proxy device first verifies the validity of the digital signature using a pre-configured platform public key. If verification is successful, the edge proxy device further verifies the continuity of the version number to ensure that it receives the latest version of the access control list. Simultaneously, the edge proxy device recalculates the table-level digest and compares it with the received table-level digest to confirm that the access control list has not been tampered with during transmission.

[0057] Through the above technical solutions, this application achieves secure distribution and verification of dynamic access control lists (ACLs). The security of the communication channel is ensured through TLS 1.3 two-way authentication sessions. The introduction of version numbers and differential update identifiers supports incremental updates of the ACLs, improving distribution efficiency. The use of table-level digests and digital signatures ensures the integrity and authenticity of the ACL's origin, effectively preventing man-in-the-middle attacks and tampering risks. The verification mechanism of the edge agent device further enhances system security, ensuring that only ACLs that have undergone authentication and integrity verification can be applied, thereby improving the reliability and security of the entire remote control system.

[0058] This application further proposes a rule storage unit that sets up an active table area and a candidate table area. The dynamic access control table, verified by the rule verification unit and carrying a version number and table-level digest, is written to the candidate table area in an append-only manner, recording each access rule entry, signature information, and sequence number. The rule storage unit generates a rule index based on the subject identifier, object identifier, and action identifier and stores it synchronously with the candidate table area. After recalculating the table-level digest of the candidate table area and comparing it with the received table-level digest, an atomic switch is performed, updating the active table pointer to the dynamic access control table corresponding to the version number, and persisting the current version number and sequence number watermark. During differential updates, access rule entries are merged and deduplicated according to the sequence number range, and in case of conflicts, the newer one based on the priority field and sequence number is retained. Access rule entries carrying a revocation flag field are marked for immediate expiration, and access rule entries with expired TTLs are cleaned up in periodic tasks. In case of a switch failure, a rollback to the previous version's active table area is performed based on the most recent checkpoint.

[0059] The dual-area partitioning of the active and candidate tables ensures the atomicity of rule updates through physical isolation, while the candidate table uses an append-only write mode to avoid data loss caused by overwrite operations. The rule index is built based on subject, object, and action identifiers, supporting fast matching and conflict detection. Atomic switching achieves version switching through pointer updates rather than data copying, reducing storage overhead and improving switching efficiency. During differential updates, duplicate entries are merged based on sequence number ranges, and rule conflicts are resolved by combining priority and sequence number age. Periodic cleanup tasks automatically remove expired entries based on the time-to-live (TTL) to prevent rule bloat. The checkpoint rollback mechanism enables fault recovery through persistent version state.

[0060] Specifically, when the edge agent device receives a new version of the dynamic access control table, it first writes it completely into the candidate table area and generates a rule index for each entry. The candidate table area records rule entries using an append-only method to ensure the writing process is irreversible and avoids data overwriting. After writing is complete, the table-level digest of the candidate table area is recalculated and compared with the received table-level digest. If they match, the active table pointer is switched to point to the new version via an atomic operation, and the version number and sequence number watermark are updated simultaneously. In differential update scenarios, the system filters newly added or modified rule entries based on the sequence number range and merges them with existing entries. When multiple rules with the same subject, object, and action identifier are detected, the entry with the higher priority is retained first; if the priorities are the same, the entry with the larger sequence number is selected. For rules marked as revoked, they are immediately marked as invalid in the index and automatically skipped during subsequent matching. Periodic tasks scan the active table area and clean up rule entries that have exceeded their validity period (TTL) to free up storage space. If an anomaly occurs during the atomic switch, the system rolls back the active table pointer to the previous valid version based on the version number and sequence number watermark recorded at the most recent checkpoint, ensuring the integrity and consistency of rule storage.

[0061] As a preferred embodiment, the solution of this application is specifically implemented as follows: The rule storage unit sets up an active table area and a candidate table area. The dynamic access control table, verified by the rule validation unit and carrying a version number and table-level digest, is written to the candidate table area in an append-only manner, recording each access rule entry, signature information, and sequence number. The rule storage unit generates a rule index based on the subject identifier, object identifier, and action identifier and stores it synchronously with the candidate table area. After recalculating the table-level digest of the candidate table area and comparing it with the received table-level digest, an atomic switch is performed, updating the active table pointer to the dynamic access control table corresponding to the version number, and persisting the current version number and sequence number watermark. During differential updates, access rule entries are merged and deduplicated according to the sequence number range, and in case of conflicts, the newer one based on the priority field and sequence number is retained. Access rule entries carrying a revocation flag field are marked for immediate expiration, and access rule entries with expired TTLs are cleaned up in periodic tasks. In case of a switch failure, a rollback to the previous version's active table area is performed based on the most recent checkpoint.

[0062] Specifically, the rule storage unit can be implemented using a key-value database, where the active table area and the candidate table area each correspond to two independent database instances. Each database instance contains three sub-tables: an access rule table, a signature information table, and an index table. The access rule table uses the sequence number as the primary key and stores the specific content of the access rule entries. The signature information table uses the rule entry identifier as the primary key and stores the corresponding signature information. The index table uses a combination of subject identifier, object identifier, and action identifier as the primary key and stores a list of corresponding rule entry identifiers.

[0063] Furthermore, upon receiving a new dynamic access control table, it is first written to the access rule table and signature information table of the candidate table area. Then, an index is generated based on the rule entries, and the index table is updated. Next, the SHA-256 digest of all contents of the candidate table area is calculated and compared with the received table-level digest. If they match, an atomic switch operation is performed: the active table pointer is switched from the current active table area to the candidate table area, and the new version number and maximum sequence number are persisted to the metadata store.

[0064] Therefore, in differential update scenarios, the system first obtains the current sequence number level and only processes new rule entries with larger sequence numbers. For multiple rules with the same subject, object, and action combination, entries with higher priority or newer sequence numbers are retained. Rule entries carrying a cancellation flag are immediately marked as invalid, but are not immediately deleted; instead, they are cleaned up according to TTL during periodic cleanup tasks.

[0065] For example, when a failover operation fails due to a system crash or other reasons, the system reads the checkpoint information recorded during the most recent successful failover, including the version number and sequence number watermark. Then, the active table pointer is rolled back to the table area corresponding to that checkpoint, and entries in the candidate table area with sequence numbers greater than the watermark are cleaned up to restore a consistent state.

[0066] Through the above technical solutions, this application achieves secure and reliable storage and updating of dynamic access control lists. The dual-zone design and atomic switching mechanism ensure data consistency and integrity, avoiding the risk of data corruption during the update process. Differential updates and conflict handling mechanisms improve update efficiency and reduce data transmission and storage overhead. Instant expiration marking and periodic cleanup mechanisms enable flexible rule lifecycle management, enhancing system security and maintainability. The rollback mechanism further improves the system's fault tolerance and reliability. These technical measures collectively construct a robust and efficient rule storage and management system, providing a solid security foundation for IoT remote control systems.

[0067] This application further proposes that when the rule verification unit verifies signature information based on the platform public key, it includes: the rule verification unit reads the platform public key set and corresponding key identifier from the trust anchor storage area, and selects the verification public key according to the key identifier in the signature information. It calculates the SHA-256 digest of the table-level digest of the dynamic access control table and verifies the table-level signature using the verification public key according to the ECDSA-P256 algorithm. Simultaneously, it calculates the SHA-256 digest of the rule digest for each access rule entry and verifies the rule-level signature using the verification public key according to the ECDSA-P256 algorithm. Under the condition that the signature verification passes, the verification version number is monotonically non-decreasing relative to the current version number, and if it is less than the current version number, import is rejected. The table-level digest is recalculated to be consistent with the signature payload. For each access rule entry, it verifies that the sequence number is greater than the persisted sequence number watermark, the validity period (TTL) has not expired, and the revocation flag field is not set. When the signature information carries a key rotation identifier, it allows verification using the previous version's verification public key within the key rotation window, and only accepts the current verification public key after the window expires. After completing the above verification, the verification result is output to drive the rule storage unit to perform candidate table area writing and atomic switching.

[0068] The rule verification unit obtains the platform's public key set through the trust anchor storage area to ensure the public key source is trustworthy. It matches public keys based on key identifiers to avoid key confusion. Double signature verification is performed on table-level digests and rule digests to prevent overall or partial data tampering. Version number verification ensures the dynamic access control table version increments, preventing version rollback attacks. Sequence number watermark verification ensures the sequential execution of rule entries, preventing old rules from overwriting new ones. Expiration and revocation flag verification prevents expired or invalid rules from being enabled. The key rotation window mechanism supports smooth key transition, preventing verification interruptions during key updates. For example, when the platform's public key needs to be changed periodically due to security policies, the rule verification unit is compatible with both old and new public keys within the key rotation window; after the window closes, the new public key is enforced, balancing security and availability.

[0069] Specifically, upon receiving the dynamic access control list, the rule verification unit first matches the corresponding platform public key from the trust anchor storage area based on the key identifier in the signature information. After performing SHA-256 hash calculation on the table-level digest, the table-level signature is verified using the ECDSA-P256 algorithm to confirm the overall integrity of the dynamic access control list. Simultaneously, a rule digest is independently calculated and the rule-level signature is verified for each access rule entry to prevent tampering with individual rules. Version number verification requires the new version number to be no lower than the current active version, preventing malicious import of old version rules that could lead to permission rollback. Sequence number watermark verification ensures that the sequence number of the new rule entry is higher than the highest stored value, preventing the duplicate insertion of historical rules. Expiration and revocation flag verification filters expired or manually revoked rule entries in real time. When a key rotation flag is detected, the rule verification unit allows the use of the old public key to verify historical signatures within a preset time window; after the window expires, only the new public key is accepted, achieving seamless key rotation. After all verifications pass, the rule verification unit triggers the rule storage unit to write the dynamic access control list into the candidate table area, completing an atomic switch to update the active table and ensuring uninterrupted rule activation.

[0070] As a preferred embodiment, the solution of this application is specifically implemented as follows: The rule verification unit reads the platform public key set and corresponding key identifiers from the trust anchor storage area, and selects a verification public key based on the key identifier in the signature information. It calculates the SHA-256 digest of the table-level digest of the dynamic access control table and verifies the table-level signature using the verification public key and the ECDSA-P256 algorithm. Simultaneously, it calculates the SHA-256 digest of the rule digest for each access rule entry and verifies the rule-level signature using the verification public key and the ECDSA-P256 algorithm. If the signature verification passes, the verification version number remains monotonically constant relative to the current version number, and import is rejected if it is less than the current version number. The table-level digest is recalculated to be consistent with the signature payload. For each access rule entry, it verifies that the sequence number is greater than the persisted sequence number watermark, the validity period (TTL) has not expired, and the revocation flag field is not set. When the signature information carries a key rotation identifier, verification using the previous version's verification public key is allowed within the key rotation window, and only the current verification public key is accepted after the window expires. After completing the above verifications, the verification result is output to drive the rule storage unit to perform candidate table area writing and atomic switching.

[0071] Specifically, the rule verification unit first reads the platform's public key set from the trust anchor storage area. This set contains multiple public keys and their corresponding key identifiers. For example, the storage area may contain three public keys: PK1, PK2, and PK3, corresponding to key identifiers KID1, KID2, and KID3, respectively. Based on the key identifiers contained in the received signature information, the rule verification unit selects the corresponding verification public key from the public key set.

[0072] Furthermore, the rule verification unit performs a SHA-256 hash calculation on the table-level digest of the dynamic access control list to obtain a 256-bit hash value. Then, it uses the selected verification public key and the ECDSA-P256 algorithm to perform signature verification on this hash value to confirm the validity of the table-level signature. Simultaneously, the rule digest of each access rule entry is also hashed using SHA-256, and the rule-level signature is verified using the same verification public key and the ECDSA-P256 algorithm.

[0073] Therefore, after signature verification is completed, the rule verification unit checks the version number. It compares the version number of the received dynamic access control list with the version number in the current system. If the new version number is less than the current version number, the import of the table is rejected. If the version number is valid, the table-level digest is recalculated, ensuring that the calculated result matches the digest in the signature payload.

[0074] For each access rule entry, the rule verification unit performs the following checks: Ensure that the serial number is greater than the serial number level that has been persisted in the system.

[0075] The verification TTL has not expired.

[0076] The undo flag field was not set.

[0077] As a preferred implementation, when the signature information contains a key rotation identifier, the system allows verification using the previous version's verification public key within a predefined key rotation window. For example, if PK2 is currently being used, and the signature information indicates a key rotation to PK3 is underway, the system will accept signatures using either PK2 or PK3 during the rotation window. However, once the rotation window ends, the system will only accept signatures verified using PK3.

[0078] Finally, after completing all the above verification steps, the rule verification unit outputs a verification result. This result will drive the rule storage unit to perform subsequent operations, including writing the verified rules into the candidate table area, and performing an atomic switch at an appropriate time to promote the candidate table to the active table.

[0079] Through the above technical solutions, this application achieves multi-layered security verification of dynamic access control lists. First, by using public-key cryptography and digital signature technology, the authenticity and integrity of the control list's origin are ensured. Second, version number and serial number checks prevent rollback and replay attacks. Third, the verification mechanism for expiration and revocation markers guarantees the timeliness and controllability of the rules. Finally, the introduction of a key rotation mechanism enhances the system's long-term security, allowing keys to be updated without service interruption. These measures collectively construct a robust security framework, effectively improving the ability of IoT remote control systems to resist various potential security threats.

[0080] This application further proposes that when the decision execution unit receives control commands and performs matching and verification based on access rule entries, it includes parsing the control commands to obtain the subject identifier, object identifier, and action identifier, where the subject identifier is mapped from the session identifier, the object identifier is the target device identifier, and the action identifier is the command type. Matching is performed based on the rule index in the rule storage unit. If multiple access rule entries are obtained, the one with the higher priority field is prioritized; if the priorities are the same, the one with the newest sequence number is prioritized to determine the target access rule entry. The context constraints of the target access rule entry are verified, including comparing the platform time against the time window, performing point-to-point judgment based on the geographical coordinates reported by the edge agent device, comparing the device firmware version number against version requirements, verifying the unit normalization and value range of command parameters, and comparing the call frequency threshold based on a sliding time window counter. If any verification fails, a rejection result is output and the rejection reason code is recorded.

[0081] The rule index is generated based on subject, object, and action identifiers, and uses a hash table or B+ tree structure for fast retrieval. The priority field is dynamically assigned by the security policy engine based on the task risk level when generating access rule entries, and the sequence number is generated in a globally incrementing manner. The time window is defined using a start and end timestamp, and the geographical location range is described by the vertex coordinates or radius distance parameters of a geofence polygon. Device firmware version number comparison uses a semantic version number parsing algorithm, and command parameter range verification incorporates a unit conversion module to unify different unit parameters into a standard unit. Call frequency threshold verification compares the command count within the sliding time window with a preset threshold; if the count exceeds the threshold, a frequency limit is triggered.

[0082] Specifically, when a control command reaches the decision-making execution unit, the subject identifier, object identifier, and action identifier are first extracted. A matching set of access rule entries is then quickly retrieved using a rule index. If multiple entries exist, they are sorted from highest to lowest priority; if priorities are the same, the entry with the larger sequence number is selected to ensure the latest policy takes effect. Subsequently, multi-dimensional context constraint checks are performed on the selected entry: time window checks ensure the command is executed within the allowed time period; geolocation checks determine legitimacy by comparing the coordinates with a preset fenced area; firmware version checks prevent commands from being sent to incompatible devices; command parameter checks prevent parameters from exceeding limits through normalization and range comparison; and call frequency checks dynamically adjust based on counts within the time window to prevent high-frequency malicious commands. If any check fails, the process is immediately terminated and the reason is recorded; if all checks pass, a one-time execution token is generated. Thus, by overlaying multi-dimensional real-time checks on top of dynamic access control, the security and accuracy of command execution are effectively improved.

[0083] As a preferred embodiment, the solution of this application is specifically implemented as follows: The decision execution unit parses control commands to obtain the subject identifier, object identifier, and action identifier. The subject identifier is mapped from the session identifier, the object identifier is the target device identifier, and the action identifier is the command type. Matching is performed based on the rule index in the rule storage unit. If multiple access rule entries are obtained, the one with the higher priority field is prioritized; if priorities are the same, the one with the newest sequence number is prioritized to determine the target access rule entry. The context constraints of the target access rule entry are validated, including: comparing the time window with the platform time, performing point-to-point judgment based on the geographic location coordinates reported by the edge agent device, comparing the version requirement with the device firmware version number, validating the unit normalization and value range of command parameters, and comparing the call frequency threshold with a counter based on a sliding time window. If any validation fails, a rejection result is output and the rejection reason code is recorded.

[0084] Specifically, the decision execution unit first extracts the subject identifier, object identifier, and action identifier from the received control instructions. For example, the subject identifier might be "user123", the object identifier might be "device456", and the action identifier might be "restart". Then, the decision execution unit queries the rule index in the rule storage unit to find access rule entries that match these identifiers. If multiple matching rules are found, the most applicable rule is selected based on priority and sequence number.

[0085] Next, the decision execution unit performs context constraint validation on the selected rule entries. For example, it checks if the current time is within the permitted time window for executing the operation, such as 9:00-18:00 on weekdays. It verifies if the edge agent device's geographical location is within a predefined security area, such as an office area. It confirms if the device firmware version meets the minimum requirement, such as v2.0 or higher. It checks if the command parameters are within the allowed range, such as a reboot interval of at least 30 minutes. Finally, it verifies if the number of times this type of command has been executed in the past hour exceeds a preset threshold, such as no more than 5 times.

[0086] If any of the above checks fails, the decision execution unit will refuse to execute the control command and record the specific reason for the rejection, such as "operation attempt outside the time window" or "device firmware version too low." The control command will only be allowed to be executed when all constraints are met.

[0087] Through the above technical solution, this application achieves fine-grained access control and dynamic verification of IoT remote control commands. Multi-dimensional context constraint verification effectively prevents unauthorized operations and potential security risks. This method not only improves system security but also enhances the ability to detect abnormal behavior. By recording the reasons for denial, system administrators can better analyze and respond to potential security threats, thereby continuously optimizing access control policies. Furthermore, call frequency control based on a sliding time window effectively prevents possible DoS attacks, ensuring stable system operation.

[0088] This application further proposes that after the decision execution unit completes matching and verification, it calculates a SHA-256 instruction digest for the normalized representation of the control command, the rule entry identifier, and the session identifier. It then assembles a one-time execution token containing the instruction digest, rule entry identifier, timestamp, random number, monotonic counter, and token validity period (TTL). The one-time execution token is then signed using the edge agent device's private key according to the ECDSA-P256 algorithm. The signed one-time execution token is submitted to the device driver along with the control command, and the monotonic counter and random number are registered in the local token cache for replay verification and association with the execution result. Upon receiving the execution result, the one-time execution token identifier is included for verification before the execution result is reported.

[0089] The SHA-256 instruction digest generation process takes the normalized representation of the control instruction, rule entry identifier, and session identifier as input, and generates a fixed-length unique identifier through hashing to ensure the immutability of the instruction content and authorization rules. The assembly of the one-time execution token includes a timestamp, a random number, and a monotonic counter. The timestamp limits the token's validity period, the random number prevents prediction attacks, and the monotonic counter generates an increasing sequence to resist replay attacks. The signing operation of the edge agent device's private key uses the ECDSA-P256 algorithm, achieving efficient signature verification and quantum-resistant characteristics within the elliptic curve cryptography framework. The local token cache uses a key-value storage structure, with the monotonic counter and random number as index keys, recording the token state and associated session information. When reporting the execution result, the token identifier must be included; the token validity is verified by querying the cache, and the counter state is updated.

[0090] Specifically, after the control command passes the access rule verification, the decision execution unit first extracts the normalized binary format of the command and generates a 256-bit hash value as the command digest by combining the rule entry identifier and the session identifier. This digest is embedded in the header of the one-time execution token, forming the token payload together with the timestamp, random number, and monotonic counter. The timestamp uses Coordinated Universal Time (UTC) format, accurate to the millisecond level, ensuring the accuracy of the token's Time To Live (TTL) calculation. The random number is generated by a cryptographically secure pseudo-random number generator, with a length of no less than 128 bits. The monotonic counter uses atomic operations to increment, automatically incrementing by one each time a token is generated. After the token is assembled, it is digitally signed using the edge agent device's private key, and the signature result is appended to the end of the token to form a complete token structure. The signed token is transmitted to the device driver module through the encrypted communication module. Before execution, the driver module uses the edge agent device's public key to verify the signature validity and check the legality of the timestamp and TTL. The local token cache uses an in-memory database to store currently active tokens, using a monotonic counter and a random array as the primary key, recording the token's creation time, associated session identifier, and execution status. When the execution result is returned, the driver module sends the token identifier back to the decision execution unit. It then verifies whether the token has been used by querying the cache and checks if the counter matches the current sequence. If the verification passes, the cache status is updated to "executed" and result reporting is allowed. If reuse or a counter anomaly is detected, a security alarm is triggered and the execution result is discarded.

[0091] As a preferred embodiment, the specific implementation of this application's solution is as follows: After the control command passes matching and verification, the standardized control command is converted into JSON format and encoded in UTF-8. The rule entry identifier is concatenated with the session identifier in hexadecimal string form to form input data. A 128-bit instruction digest value is calculated using the SHA-256 hash algorithm. This digest value, together with the current UTC timestamp, a 128-bit random number, a monotonically increasing counter, and a preset token validity period, constitutes the token payload. The token payload is encapsulated as an ASN.1 structure and signed using the edge agent device's private key using the ECDSA-P256 algorithm to generate a 256-bit signature value. The signature result and the payload together constitute a one-time execution token. The signed token is converted into a string format using Base64URL encoding and encapsulated into a Protobuf message body along with the original control command, and submitted to the device driver module. The token cache is implemented using a Redis database, storing the random number, timestamp, and token status with a monotonically increasing counter as the primary key. When the execution result is returned, the validity of the token is verified by querying the cache record and the usage status is marked to prevent the same token from being submitted repeatedly.

[0092] Through the above technical solutions, this application achieves end-to-end integrity and resistance to replay attacks in the control command execution process. The one-time execution token ensures the legitimacy and tamper-proof nature of the command source through cryptographic signature, and effectively resists replay attacks by combining a random number and monotonic counter mechanism. Token validity limits and cache state management further constrain the time window for command execution, preventing the malicious reuse of historical tokens, thereby ensuring the security and reliability of remote control operations in complex network environments.

[0093] This application further proposes an encrypted communication module for encrypted transmission of access control lists, control commands, and execution results between a secure remote control platform and an edge agent device. This includes: establishing a two-way certificate authentication session based on TLS 1.3; the two-way certificate authentication session is based on ECDHE key exchange and uses either TLS_AES_128_GCM_SHA256 or TLS_CHACHA20_POLY1305_SHA256 cipher suites; deriving the session key via HKDF and exporting the channel binding value; framing the data to be transmitted according to content type identifiers; the frame header includes a session identifier, message sequence number, and timestamp; and injecting the SHA-256 digest of the authentication token or one-time execution token as additional authentication data into the TLS record layer to be used together with the channel binding value for integrity verification and session binding; after TLS record layer verification is completed on the receiving side, further verification is performed to ensure the message sequence number is monotonically increasing and does not fall within the replay window, and the data is then assigned to the rule storage unit, decision execution unit, or result reporting process according to the content type identifier. When resuming a session, use a TLS 1.3 session ticket with a limited validity period and a device identifier, and prohibit 0-RTT data from being enabled on channels carrying control commands.

[0094] The two-way certificate authentication session uses ECDHE key exchange for forward confidentiality, deriving a 128-bit session key through the HKDF algorithm to ensure that each session key is independent. The message sequence number in the frame header uses a monotonically increasing 32-bit unsigned integer, with timestamp accuracy at the millisecond level and synchronized with the platform time. Additional authentication data achieves dual verification at both the application and session layers by binding the token digest to the TLS record layer payload. The session ticket validity period is set to 24 hours and bound to the device identifier to prevent ticket reuse across devices.

[0095] Specifically, when establishing a TLS 1.3 connection, the edge proxy device and the secure remote control platform exchange ECDSA certificates and complete mutual authentication. A temporary session key is generated through ECDHE key exchange to ensure the key is irreversible. Transmitted data is divided into three categories: control commands, access control lists, and execution results. Each category is marked with a content type identifier in the frame header, and the receiving end routes the data to the corresponding processing unit based on the identifier. The message sequence number increments with each transmission, and the receiving end maintains a sliding window to detect replay attacks, rejecting packets with duplicate or delayed sequence numbers. Additional authentication data is added by writing the token digest into the TLS record extension field, requiring verification of both token integrity and channel binding value after decryption. Upon session recovery, only session tickets with the bound device identifier are allowed to re-establish the connection, and the control command channel disables 0-RTT mode to avoid replay attack risks. Thus, through multi-layered encryption and verification mechanisms, the confidentiality, integrity, and replay resistance of transmitted data are achieved.

[0096] As a preferred embodiment, the solution of this application is implemented as follows: When the encrypted communication module establishes a two-way authentication session between the secure remote control platform and the edge agent device, it adopts the TLS 1.3 protocol and selects the TLS_AES_128_GCM_SHA256 cipher suite. During the handshake phase, the platform and the edge agent device exchange X.509 certificates, which contain a device identification field and an extended key usage identifier. After generating a shared key through ECDHE key exchange, a session key is derived based on the HKDF algorithm, and a channel binding value used for integrity verification is exported. During data transmission, control commands are divided into fixed-length data frames, with each frame header embedding a message sequence number and a nanosecond-level timestamp. Simultaneously, the SHA-256 digest of the authentication token is injected as additional authentication data into the TLS record layer. When processing data, the receiving end first verifies whether the message sequence number satisfies the monotonically increasing characteristic and does not fall within a preset replay window of 1,000 sequence numbers. Then, it performs joint verification of the channel binding value and the additional authentication data. In the session recovery scenario, a session ticket mechanism with bound device identifier is adopted. The ticket validity period is limited to 300 seconds and the use of 0-RTT early data mode is prohibited in the command transmission channel.

[0097] Through the above technical solutions, this application achieves end-to-end encrypted transmission session binding and anti-replay attack capabilities. Two-way certificate authentication combined with channel binding value verification effectively prevents man-in-the-middle attacks and data tampering. A joint verification mechanism based on message sequence numbers and timestamps ensures the timeliness and uniqueness of command transmission. Device identifier binding of session tickets and a 0-RTT disabling policy eliminate the risks of session hijacking and replay attacks. Thus, a complete security protection system is constructed at the encrypted communication level, ensuring the confidentiality and integrity of remote control commands and execution results throughout the entire chain.

[0098] In another preferred embodiment based on the above embodiments, see [reference] Figure 2 As shown, this embodiment provides a security control method for IoT remote control, applied to the aforementioned security control system for IoT remote control, including: S100: Performs authentication when terminal devices access and users log in. Authentication includes generating a device key pair and writing it into a digital certificate, establishing a TLS 1.3 two-way authentication session, performing certificate chain verification, validity period verification and revocation status query on the device certificate, performing derived hash comparison on the user password, and performing multi-factor authentication in combination with one-time password or hardware key-based authentication methods. After successful authentication, an authentication result is generated and an authentication token is issued.

[0099] S200: Receives and parses the authentication token, instantiates access rule entries from the policy template library based on user identity information, device type information, and task risk level, configures context constraints for the access rule entries and generates serial number, validity period TTL, and revocation flag fields, calculates the rule digest and signs it, and combines them to generate a dynamic access control table with a version number and table-level digest.

[0100] S300: Establishes a TLS 1.3 mutual authentication session, appends a version number, table-level digest, and differential update identifier to the dynamic access control list, signs the table-level digest, and sends it to the target end.

[0101] S400: After receiving the dynamic access control list, the signature, version number and table-level digest are verified. If the verification is successful, the data is written to the candidate table and an atomic switch is performed to update the active table after the comparison is consistent.

[0102] S500: When receiving control commands, it matches and verifies the access rules entries in the dynamic access control list, compares the subject identifier, object identifier, action identifier and context constraints, rejects control commands that fail the verification, and generates a one-time execution token for control commands that pass the verification, signs it and submits it for execution along with the control command.

[0103] S600: During remote control, the dynamic access control table, control commands and execution results are transmitted in encrypted form, and the message sequence number and channel binding value are attached to the transmission to complete integrity verification and reverse playback control.

[0104] Through the above technical solutions, this application achieves dynamic access control based on multi-factor authentication. By instantiating the least privilege template and configuring context constraints, it effectively avoids the over-authorization problem caused by static permission allocation. The use of a one-time execution token combined with an anti-replay counter mechanism blocks the path for command tampering and replay attacks. Through TLS 1.3 two-way authentication and session binding technology, end-to-end encryption and integrity verification are ensured during control command transmission, enhancing the security protection capabilities of the IoT remote control system.

[0105] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A safety control system for remote control via the Internet of Things, characterized in that, include: The system includes a secure remote control platform, a zero-trust gateway, an authentication module, a security policy engine, an edge proxy device, and an encrypted communication module; among which, The authentication module is used to authenticate devices and users when terminal devices access the network and users log in. The security policy engine generates a dynamic access control table based on the authentication result. The dynamic access control table includes access rule entries and associated signature information, and is distributed to the edge proxy device through the zero trust gateway. The edge proxy device is equipped with a rule storage unit, a rule verification unit, and a decision execution unit. The rule storage unit is used to store a dynamic access control table, the rule verification unit is used to verify the signature information based on the platform public key, and the decision execution unit is used to match and verify the access rule entries when receiving control instructions. Instructions that fail verification are rejected, and instructions that pass verification generate a one-time execution token and submit it for execution. The encrypted communication module is used to encrypt the access control table, control commands, and execution results between the secure remote control platform and the edge agent device.

2. The security control system for remote control of the Internet of Things according to claim 1, characterized in that, When the authentication module verifies the identity of the device and the user during terminal device access and user login, it includes: During the initial access phase of the terminal device, the hardware security module within the terminal device is invoked to generate a device key pair to obtain a device public key and a device private key. The device public key is then written into the device digital certificate and bound to the device identifier. When the terminal device initiates access, a TLS 1.3 session is established through the encrypted communication module, and two-way certificate authentication is enabled. The authentication module performs certificate chain verification, validity period verification, and revocation status query based on OCSP or CRL on the device digital certificate, generates a random challenge value, and sends it along with session parameters to the terminal device. The terminal device uses the device private key to sign the random challenge value and the session parameters and returns the signature. The authentication module uses the device public key to complete the signature verification to confirm the identity of the terminal device. During user login, the authentication module performs a derived hash comparison based on PBKDF2 or Argon2 on the user password, and simultaneously verifies at least one of the following as a second factor: a time-synchronized one-time password (TOTP) or a hardware key-based FIDO2 / WebAuthn assertion. When biometrics are enabled, only biometric template hashes calculated by the local trusted execution environment are compared. After both the terminal device and the user pass verification, the authentication module generates the authentication result, which includes user identity information, device type information, device identifier, authentication strength level, and session identifier. Then, it issues an authentication token signed by the platform's private key to encapsulate the user identity information and the device identifier, and transmits it to the security policy engine via the zero-trust gateway to generate the dynamic access control table.

3. The security control system for remote control of the Internet of Things according to claim 2, characterized in that, When the security policy engine generates a dynamic access control list based on the authentication result, it includes... The security policy engine receives the authentication token issued by the authentication module and parses it to obtain user identity information, device type information, device identifier, authentication strength level and session identifier; Select the least privilege template that matches the device type information and the authentication strength level from the policy template library, and instantiate the least privilege template according to the task risk level to obtain access rule entries containing subject identifier, object identifier and action identifier. During instantiation, context constraints are configured for each access rule entry. These context constraints include time window, geographic location range, device firmware version number, command parameter range, and call frequency threshold. For multiple access rule entries with the same subject identifier and object identifier, conflict resolution is performed, with the one with the higher priority field taking precedence, and in the case of the same priority, the one with the newest sequence number taking precedence. For each access rule entry, a sequence number, a time-to-live (TTL) period, and a revocation flag field are generated. A rule digest is calculated based on SHA-256, and the rule digest is signed using the platform's private key according to the ECDSA-P256 algorithm to form the signature information. All access rule entries are combined with the corresponding signature information to generate the dynamic access control table, and a table-level summary and version number are generated for differential update identification. The dynamic access control list and the table-level summary are output to the zero-trust gateway.

4. The security control system for remote control of the Internet of Things according to claim 3, characterized in that, When the data is sent to the edge proxy device through the zero-trust gateway, it includes: The zero-trust gateway establishes a TLS 1.3 two-way authentication session through the encrypted communication module; during distribution, it appends a version number, table-level digest, and differential update identifier to the dynamic access control list, and calculates an SHA-256 digest of the table-level digest and generates a signature using the gateway's private key according to the ECDSA-P256 algorithm; after receiving the dynamic access control list, the edge proxy device verifies the signature and checks the version number and table-level digest based on the platform's public key to confirm the integrity and timeliness of the dynamic access control list.

5. The security control system for remote control of the Internet of Things according to claim 4, characterized in that, When the rule storage unit saves the dynamic access control table, it includes: The rule storage unit sets up an active table area and a candidate table area; the dynamic access control table, which has passed the verification by the rule verification unit and carries a version number and table-level digest, is written to the candidate table area in an append-only manner, and the access rule entry, the signature information, and the sequence number are recorded one by one; the rule storage unit generates a rule index based on the subject identifier, object identifier, and action identifier and stores it synchronously with the candidate table area; the table-level digest of the candidate table area is recalculated and compared with the received table-level digest, and an atomic switch is performed after they are consistent, updating the active table pointer to the dynamic access control table corresponding to the version number, and persisting the current version number and sequence number water level; during differential updates, access rule entries are merged and deduplicated according to the sequence number range, and in case of conflicts, they are retained according to the priority field and the newer sequence number; access rule entries carrying a revocation flag field are marked for immediate expiration and access rule entries that have expired TTL are cleaned up in the periodic task; in case of switch failure, the active table area of ​​the previous version is rolled back according to the most recent checkpoint.

6. The security control system for remote control of the Internet of Things according to claim 5, characterized in that, When the rule verification unit verifies the signature information based on the platform's public key, it includes: The rule verification unit reads the platform public key set and corresponding key identifier from the trust anchor storage area, and selects a verification public key based on the key identifier in the signature information; it calculates the SHA-256 digest of the table-level digest of the dynamic access control table and verifies the table-level signature using the verification public key according to the ECDSA-P256 algorithm; simultaneously, it calculates the SHA-256 digest of the rule digest of each access rule entry and verifies the rule-level signature using the verification public key according to the ECDSA-P256 algorithm; under the condition that the signature verification is successful, it verifies that the version number is monotonically non-decreasing relative to the current version number, and rejects import if it is less than the current version number, and recalculates the table-level digest to be consistent with the signature payload; for each access rule entry, it verifies that the sequence number is greater than the persistent sequence number watermark, the validity period TTL has not expired, and the revocation flag field is not set; when the signature information carries a key rotation identifier, it allows the use of the previous version verification public key for verification within the key rotation window, and only accepts the current verification public key after the window expires; after completing the above verification, it outputs the verification result to drive the rule storage unit to perform candidate table area writing and atomic switching.

7. The security control system for remote control of the Internet of Things according to claim 6, characterized in that, When the decision execution unit receives a control command and performs matching and verification according to the access rule entries, it includes: The decision execution unit parses the control command to obtain the subject identifier, object identifier, and action identifier, wherein the subject identifier is mapped from the session identifier, the object identifier is the target device identifier, and the action identifier is the command type; it performs matching according to the rule index in the rule storage unit. If multiple access rule entries are obtained, the one with the higher priority field is prioritized, and if the priorities are the same, the one with the newest sequence number is prioritized to determine the target access rule entry; the context constraints of the target access rule entry are verified, including: comparing the time window with the platform time, performing point-to-point judgment on the geographical location range based on the geographical location coordinates reported by the edge agent device, comparing the version requirements with the device firmware version number, verifying the unit normalization and value range of the command parameters, and comparing the call frequency threshold with the counter based on the sliding time window; if any of the verifications fails, a rejection result is output and the rejection reason code is recorded.

8. The security control system for remote control of the Internet of Things according to claim 7, characterized in that, After the decision execution unit completes the matching and verification, it also includes: The decision execution unit calculates a SHA-256 instruction digest for the normalized representation of the control command, the rule entry identifier, and the session identifier. It then assembles a one-time execution token containing the instruction digest, the rule entry identifier, a timestamp, a random number, a monotonic counter, and a token validity period (TTL). The token is then signed using the edge agent device's private key according to the ECDSA-P256 algorithm. The signed token, along with the control command, is submitted to the device driver. The monotonic counter and the random number are registered in the local token cache for replay verification and association with the execution result. Upon receiving the execution result, the decision execution unit verifies the one-time execution token identifier and reports the result.

9. The security control system for remote control of the Internet of Things according to claim 8, characterized in that, The encrypted communication module is used to perform encrypted transmission of the access control table, control commands, and execution results between the secure remote control platform and the edge agent device, including: The encrypted communication module establishes a two-way certificate authentication session based on TLS 1.

3. This session uses ECDHE key exchange and selects either TLS_AES_128_GCM_SHA256 or TLS_CHACHA20_POLY1305_SHA256 cipher suites. It derives the session key using HKDF and exports the channel binding value. The data to be transmitted is framed according to its content type identifier. The frame header includes the session identifier, message sequence number, and timestamp. The SHA-256 digest of the authentication token or the one-time execution token is injected as additional authentication data into the TLS record layer to be used together with the channel binding value for integrity verification and session binding. After TLS record layer verification is completed on the receiving side, the message sequence number is further verified to be monotonically increasing and not falling within the replay window. Based on the content type identifier, the message sequence number is assigned to the rule storage unit, the decision execution unit, or the result reporting process. During session recovery, a TLS 1.3 session ticket is used, with a limited validity period and binding to the device identifier. 0-RTT data is prohibited on the channel carrying the control commands.

10. A security control method for remote control of the Internet of Things (IoT), applied to the security control system for remote control of the Internet of Things as described in any one of claims 1-9, characterized in that, include: When a terminal device accesses and a user logs in, authentication is performed. The authentication includes generating a device key pair and writing it into a digital certificate, establishing a TLS 1.3 two-way authentication session, performing certificate chain verification, validity period verification and revocation status query on the device certificate, performing derived hash comparison on the user password, and performing multi-factor authentication in combination with one-time password or hardware key-based authentication methods. After the authentication is successful, an authentication result is generated and an authentication token is issued. Receive and parse the authentication token, instantiate access rule entries from the policy template library based on user identity information, device type information and task risk level, configure context constraints for the access rule entries and generate serial number, validity period TTL and revocation flag fields, calculate rule digest and sign, combine to generate dynamic access control table and attach version number and table-level digest; Establish a TLS 1.3 mutual authentication session, append a version number, table-level digest, and differential update identifier to the dynamic access control list, sign the table-level digest, and send it to the target end; After receiving the dynamic access control table, the signature, version number and table-level digest are verified. If the verification is successful, they are written into the candidate table and an atomic switch is performed to update the active table after the comparison is consistent. When receiving a control command, the system matches and verifies the access rules entries in the dynamic access control table, comparing the subject identifier, object identifier, action identifier, and context constraints. Control commands that fail the verification are rejected, while control commands that pass the verification generate a one-time execution token, sign it, and submit it for execution along with the control command. During remote control, the dynamic access control table, control commands, and execution results are encrypted and transmitted, and a message sequence number and channel binding value are attached during transmission to complete integrity verification and reverse playback control.

Images