An instruction security reinforcement system and verification method for intelligent unmanned equipment

Abstract

The application relates to the technical field of intelligent terminal security control, and discloses an instruction security reinforcement system and a verification method for intelligent unmanned equipment, the system comprising an instruction receiving and computing power self-adaptive identification module, which is used for generating a safe execution context and a standardized verification data set; a communication security verification module, which is used for performing bidirectional identity authentication and confidentiality and integrity verification of instruction load; an instruction legality verification module, which is used for verifying instruction legality; an execution constraint and strategy verification module, which is used for performing strategy matching, ternary strong binding and multi-terminal priority arbitration; and a safe execution and exception handling module, which is used for outputting execution permission and hierarchical exception handling. The application provides an endogenous security base for intelligent unmanned equipment, solves the cryptographic security core problem under complex working conditions such as offline / weak network and multi-terminal cooperation, and takes into account the national cryptographic compliance and international deployment requirements.

Description

Technical Field

[0001] This invention relates to the field of intelligent terminal security control technology, and more specifically to an instruction security hardening system and verification method for intelligent unmanned devices. Background Technology

[0002] With the rapid development of artificial intelligence and embodied intelligence technologies, intelligent unmanned equipment has been widely applied in industrial manufacturing, logistics warehousing, energy inspection, smart cities, and other fields. However, the security protection of control commands has become a core bottleneck restricting its large-scale deployment and commercialization. Existing protection solutions mainly use general cryptographic security technologies, but these solutions generally cannot adapt to the actual needs of intelligent unmanned equipment in typical operating conditions such as offline operation, weak network environments, low power consumption operation, and strong electromagnetic interference, resulting in fundamental problems such as insufficient protection capabilities and poor engineering feasibility.

[0003] Currently, the industry mainstream adopts two main technical approaches, both of which have significant drawbacks. The first is a centralized cloud-based management solution, which relies on the cloud for command verification and key management, with devices passively executing commands. This leads to complete security failure in offline or weak network scenarios, and poses risks of high latency and data privacy leaks. The second is fragmented device-side security verification, which embeds non-standardized security logic into business systems, resulting in deep coupling between security and business operations. This lack of independent cryptographic security boundaries makes it vulnerable to bypassing and shows weaknesses in policy control, multi-terminal arbitration, and adaptability to various operating conditions. Furthermore, general-purpose cryptographic solutions are not customized for differences in device computing power and complex operating environments, making direct application prone to computational errors, excessive resource consumption, or functional interruptions.

[0004] In summary, existing solutions generally suffer from six common defects: lack of an independent cryptographic security diagnostic layer, failing to block illegal commands at the source; heavy reliance on the cloud, resulting in zero protection capabilities in offline / weak network scenarios; mismatch between computing power and cryptographic security, affecting device performance and battery life; insufficient compliance and long-term security, making it difficult to meet the requirements of multiple algorithm standards and quantum computing resistance; lack of local arbitration mechanisms at multiple control terminals, resulting in weak policy control; and a serious disconnect between cryptographic security capabilities and device operating conditions, leading to poor reliability in complex environments and difficulties in engineering implementation. Summary of the Invention

[0005] In view of the above problems, this invention is proposed to provide an instruction security hardening system and verification method for intelligent unmanned equipment that overcomes or at least partially solves the above problems. It provides a standardized cryptographic security intrinsic security foundation for downstream intelligent unmanned equipment manufacturers and industry customers, solves the core cryptographic security problems of equipment in offline / weak network operation, multi-terminal collaborative control, high real-time control, and complex industrial / field working conditions, and takes into account the requirements of domestic national cryptographic compliance and international deployment.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] Firstly, embodiments of the present invention provide a command security hardening system for intelligent unmanned devices, including a security decision component independent of the business control system. The security decision component is deployed on the only access path for control commands to enter the device execution unit. Each module is executed according to rigid serial rules: if the preceding verification fails, it is directly blocked and does not enter the subsequent module; all verification and decision are completed locally on the device in a closed loop and do not depend on the cloud. The security decision component includes: Command receiving and computing power adaptive identification module: used to receive control commands from the control terminal, parse the control commands and identify the current computing power level and operating conditions of the device, and generate safe execution context parameters and standardized security verification dataset; Communication security verification module: used to perform communication security verification on the control command locally on the device side, including matching the corresponding security policy template based on the standardized security verification dataset and the security execution context parameters, calling the cryptographic algorithm suite to perform two-way authentication between the control end and the device side, and performing confidentiality and integrity verification on the command payload; Command validity verification module: used to perform command validity verification on the control command after the communication security verification is passed; The execution constraint and policy verification module is used to load the currently effective policy from the local policy storage area and perform policy validity verification after the instruction legality verification is passed. Based on the trusted policy, it performs multi-dimensional policy constraint matching on the control instruction, uses a joint hash chain algorithm to construct a three-element strong binding relationship between instruction content, policy identifier and device status code and performs binding factor comparison, and performs local priority arbitration for concurrent instructions from multiple control terminals based on cryptographic identity authentication. Security Execution and Anomaly Handling Module: After the policy verification is passed, it outputs the instruction execution permission to the device execution unit and performs graded handling of security anomalies during the execution process. The graded handling includes blocking and alarming when identity or signature verification is abnormal, blocking and recording when anti-replay or binding is abnormal, switching to local security mode when communication is interrupted, and entering security degradation mode when hardware is abnormal.

[0008] Secondly, embodiments of the present invention provide a method for verifying the security of instructions for intelligent unmanned devices, comprising the following steps: S1. Receive control commands through a security decision component independent of the business system, parse the control commands and identify the current computing power level and operating conditions of the device, and generate security execution context parameters and standardized security verification datasets. S2. Perform communication security verification on the control command locally on the device side, including matching the corresponding security policy template based on the standardized security verification dataset and the security execution context parameters, calling the cryptographic algorithm suite to perform two-way authentication between the control end and the device side, and performing confidentiality and integrity verification on the command payload; if the verification fails, block the control command and terminate the process; S3. After the communication security verification is passed, the legality verification of the control command is performed, including performing multi-algorithm combination signature verification based on the switchable cryptographic algorithm suite, matching and verifying the device identifier carried in the command with the unique hardware identifier locally embedded in the device, and performing triple anti-replay verification based on the timestamp, one-time random number and command sequence number; if any verification item fails, the control command is blocked and the process is terminated. S4. After the instruction's legality verification passes, load the currently effective policy from the local policy storage area and perform policy legality verification. Based on the trusted policy, perform multi-dimensional policy constraint matching on the control instruction. Use a joint hash chain algorithm to construct a ternary strong binding relationship between the instruction content, policy identifier, and device status code, and compare binding factors. Perform local priority arbitration on concurrent instructions from multiple control terminals based on cryptographic authentication. If the verification fails, block the control instruction and terminate the process. S5. After the policy verification is passed, the instruction execution permission is output to the device execution unit, and the security anomaly is handled in a graded manner during the execution process. The graded handling includes blocking and alarming when identity or signature verification is abnormal, blocking and recording when anti-replay or binding is abnormal, switching to local security mode when communication is interrupted, and entering security degradation mode when hardware is abnormal.

[0009] Preferably, S1 includes: It supports receiving control commands using multiple communication protocols and extracts key data fields for authentication, integrity verification, anti-replay verification, policy association, control terminal identification, and permission determination. Automatically identify the device's computing power level and generate the security execution context parameters based on the computing power level; The key data fields are standardized. If the control command is missing the random number or sequence number required for anti-replay, the security decision component generates and completes it based on the local security random number generator to form the standardized security verification dataset.

[0010] Preferably, S2 includes: Based on the communication protocol identification information in the standardized security verification dataset, the communication protocol type to which the control command belongs is identified, and the corresponding security policy template is matched. Based on the security policy template and the security execution context parameters, a cryptographic algorithm suite is invoked to perform two-way authentication between the control terminal and the device terminal. Based on the security policy template, the control command payload is decrypted and its integrity is verified. Based on the above verification results, abnormal behavior detection is performed. If unauthorized access, message tampering, or high-frequency abnormal requests are detected, the malicious terminal access blocking mechanism is triggered. Based on the aforementioned secure execution context parameters, the communication security verification process is dynamically adapted.

[0011] Preferably, the communication security verification process is dynamically adapted based on the secure execution context parameters, including: On low-computing-power devices, cut out non-core verification logic and retain only identity authentication and basic payload protection; In scenarios with weak networks or communication interruptions, a local caching strategy is used to complete the necessary verifications. Under conditions of strong electromagnetic interference or abnormal operation, the verification process is simplified, retaining only the basic safety verification of emergency commands.

[0012] Preferably, S3 includes: Based on a switchable cryptographic algorithm suite, the device-side cryptographic hardware carrier is invoked to perform a signature verification operation on the control command, verifying the legality of the command source, and binding the verification result to the standardized security verification dataset; The device identifier field carried in the control command is matched and verified with the unique hardware identifier that is locally embedded in the device. Perform triple anti-replay checks, including: determining whether the instruction timestamp is within the valid window, checking whether the random number is unique in the local record set, and determining whether the instruction sequence number meets the preset incrementing rules; If the verification of signature, device identification matching, and anti-replay verification all pass, the legality of the instruction is deemed to have passed.

[0013] Preferably, S4 includes: Based on the control command and the current security status of the device, the currently effective policy is loaded from the local policy storage area, and the corresponding policy decryption key is obtained. The policy decryption and integrity verification are completed, and the policy dataset is output. The signature verification and integrity verification are performed on the policy dataset. After the verification is passed, the trusted policy dataset is output. Based on the trusted policy dataset and the device operating status, multi-dimensional policy constraint matching is performed on the control command, and the policy constraint determination result is output. Based on the standardized security verification dataset and trusted policy dataset, the instruction-policy strong binding verification is performed. A joint hash chain algorithm is used to calculate the binding factor. The real-time calculated binding factor is compared with the pre-stored binding factor in local secure storage. If they match, the binding verification is deemed to have passed, and the instruction-policy binding verification result is output. If multiple control terminals issue concurrent control commands, local arbitration is performed based on cryptographic identity verification. Only the highest priority command is allowed according to the preset permission level priority, and the multi-terminal arbitration decision result is output. The policy verification logic is dynamically adjusted based on the security execution context parameters, and the adjusted policy decision result is output.

[0014] Preferably, dynamically adjusting the policy verification logic based on the security execution context parameters includes: In the event of a communication interruption, only the locally fixed strategy is used; Remove non-core strategy verification items under conditions of strong interference or low computing power. In emergency scenarios, only the ability to execute emergency commands is retained.

[0015] Preferably, S5 includes: The system determines the current safe execution state of the device based on the safe execution state machine, including normal execution state, abnormal blocking state, safe degradation state, or emergency execution state; in the normal execution state or emergency execution state, it outputs an instruction execution permission to the device execution unit; in the abnormal blocking state or when the execution conditions are not met, it refuses to execute and outputs the reason for refusal. Generate end-to-end encrypted audit logs, digitally sign and hash-protect the logs before storing them locally, and then encrypt and upload them to the control terminal after the network is restored; If a hardware or communication anomaly is detected during the verification process, switch to a security downgrade state, enable the pre-set emergency key and basic policies, retain only the core verification capabilities and restrict the types of instructions.

[0016] Preferably, the security policy template defines verification rules for identity authentication, payload protection, and anomaly detection.

[0017] As can be seen from the above technical solution, compared with the prior art, the present invention discloses a command security hardening system and verification method for intelligent unmanned devices, which has the following advantages: 1) Solved the problem of "lack of an independent security diagnostic layer": Construct a cryptographic security component independent of the business control system as the only access path for control commands to enter the execution unit, realize the complete decoupling of security diagnostics and business execution, and block bypass risks from the architecture. 2) Solves the problem of "strong dependence on the cloud": Constructs a device-side autonomous closed-loop password security verification system. All password operations, command verification, and policy control are completed locally without relying on real-time cloud computing, ensuring password security and controllability under offline / weak network / communication interruption conditions. 3) Solved the problem of "imbalance between computing power and security": dynamically adjust the complexity of the verification logic according to the real-time computing power of the equipment, taking into account both the strength of security protection and the real-time control performance of the equipment; 4) Solved the problem of "insufficient compliance and long-term cryptographic security": Established a key lifecycle security management mechanism, adapted to lightweight switching and superposition of multiple algorithm suites such as national cryptography / international cryptography / quantum-resistant cryptography, and met the needs of domestic national cryptography compliance, international deployment and long-term security in the quantum era; 5) Solved the derivative problems of "multi-terminal conflict and weak policy control": Designed a multi-terminal local arbitration mechanism based on cryptographic evidence, supports custom permission roles and temporary permission granting, and a strong binding verification mechanism for instructions and policies to prevent multi-terminal instruction confusion and unauthorized execution risks. 6) Solved the problem of "disconnect between cryptographic security capabilities and equipment operating conditions": At the cryptographic security component level, it achieves adaptation and protection for typical operating conditions such as weak network, communication interruption, partial hardware damage, low power sleep, and strong electromagnetic interference, ensuring that the core cryptographic security capabilities are not interrupted, invalidated, or degraded under complex operating conditions, thereby improving the project's feasibility. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of an instruction security hardening system for intelligent unmanned devices provided in an embodiment of the present invention; Figure 2 This is a schematic flowchart of an instruction security verification method for intelligent unmanned devices provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of integrated verification of communication security and command security provided in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] This invention discloses a command security hardening system for intelligent unmanned devices, such as... Figure 1 As shown, it includes: Command receiving and computing power adaptive identification module: used to receive control commands from the control terminal, parse the control commands and identify the current computing power level and operating conditions of the device, and generate safe execution context parameters and standardized security verification dataset; The communication security verification module is used to perform communication security verification on the control commands locally on the device side. This includes matching the corresponding security policy template based on the standardized security verification dataset and security execution context parameters, calling the cryptographic algorithm suite to perform two-way authentication between the control end and the device end, and performing confidentiality and integrity verification on the command payload. Command validity verification module: Used to perform command validity verification on control commands after the communication security verification has passed; The execution constraint and policy verification module is used to load the currently effective policy from the local policy storage area and perform policy validity verification after the legality verification of the instruction passes. Based on the trusted policy, it performs multi-dimensional policy constraint matching on the control instruction, uses a joint hash chain algorithm to construct a three-element strong binding relationship between the instruction content, policy identifier and device status code and performs binding factor comparison, and performs local priority arbitration on concurrent instructions from multiple control terminals based on cryptographic identity authentication. Security Execution and Anomaly Handling Module: After policy verification is passed, it outputs instruction execution permission to the device execution unit and performs graded handling of security anomalies during execution. Graded handling includes blocking and alarming when identity or signature verification is abnormal, blocking and recording when replay or binding is abnormal, switching to local security mode when communication is interrupted, and entering security degradation mode when hardware is abnormal.

[0022] The core of this invention is to construct a "security decision component independent of the business system" as a "unique and unbypassable access path" for control instructions to enter the execution unit, thereby achieving physical or logical isolation between security logic and business logic. The security decision component does not simply connect the regular verification modules in series, but forms a rigid serial decision chain based on the "control instruction risk propagation path": if the verification of the preceding module fails, it will be directly blocked, and no bypass or skipping is allowed. All verification, judgment, arbitration, and anomaly degradation logic are completed locally on the device in a closed loop, "without relying on the cloud and without being coupled with business logic," thus solving the common industry defects of "cloud dependence, easy bypassing, and security coupling" from the architectural level.

[0023] In this embodiment, the instruction receiving and computing power adaptive identification module serves as the entry point for the entire secure execution process. It is responsible for receiving instructions compatible with multiple protocols, parsing multi-dimensional data, and adaptively identifying computing power / carrier / scenario / operating conditions. This provides basic data and adaptation criteria for subsequent verification steps. It does not participate in the underlying protocol parsing or hardware detection on the device side. The relevant basic data is provided by the device manufacturer. The specific execution steps are as follows: Step 101: Multiprotocol Command Reception and Parsing It supports the reception and parsing of control commands for various wired and wireless communication protocols, including but not limited to MQTT, Bluetooth, WebSocket, WebRTC, HTTP / HTTPS, and cellular communication protocols; and it adapts and parses the message structures of different protocols to extract the core data required for security verification. Step 102: Comprehensive Data Analysis and Standardization The received control commands are parsed to extract key data fields for security verification, thereby constructing a standardized security verification dataset. The key data fields include at least one or more of the following types of information: data fields for authentication, data fields for integrity verification, data fields for anti-replay verification, data fields for policy association, and data fields for control terminal identification and permission determination. The data fields may include, but are not limited to, instruction content, device identifier, instruction signature, timestamp, random number, serial number, policy identifier, and control terminal identifier; Step 103: Adaptive Attribute Recognition and Context Generation Automatically identify the device's computing power level and generate secure execution context parameters as the basis for global verification and adjustment: Low-performance computing devices (MCUs): Automatically cut 70% of non-core verifications, retaining only identity verification and instruction-policy binding; Medium-power computing devices (ARM / ordinary SOC): retain complete verification; High-performance computing devices (X86 / high-end ARM): Enable full auditing + multi-algorithm overlay signature verification; Weak network / offline status: Automatically switches to "local fixed policy mode" and does not initiate any network requests.

[0024] Step 104: Data Preprocessing Lightweight preprocessing is performed on the standardized security verification dataset, including field normalization, redundant field removal and sensitive field encryption, and a preprocessed security verification dataset is generated to ensure data integrity and confidentiality when transmitted between modules within the security component, and to prevent data from being tampered with or leaked during transmission within the device. Step 105: Security Field Generation and Completion For one-time random numbers or instruction sequence numbers not carried in the control instructions, the security component generates and completes them into the standardized security verification dataset based on the local security random number generator, which is then used by the subsequent instruction legality verification module to perform anti-replay verification.

[0025] In this embodiment, as Figure 3 As shown, the communication security verification module serves as the first security decision-making step in the control command execution process. This module performs a unified judgment on the communication link security of the control command locally on the device, realizing the shift from "transport layer encryption" to "control entry security judgment." Only when the communication security verification passes can the control command enter the subsequent command legitimacy verification module; otherwise, it is directly blocked and a security anomaly handling is triggered (corresponding to the "anomaly detection + graded handling" stage of the "anomaly tolerance closed loop"). The specific execution steps and internal mechanisms are as follows: Step 201: Protocol Identification and Security Policy Matching Based on standardized security verification datasets and secure execution context parameters, a protocol-independent communication security decision mechanism is constructed: To address the security differences between different communication protocols, a unified security policy abstract model is constructed, mapping communication security requirements into the following three basic capabilities: Authentication policies: used to verify the legitimacy of the identities of the control end and the device end; Load protection strategies: used to ensure the confidentiality and integrity of command data; Anomaly detection strategies: used to identify malicious access behavior and abnormal communication patterns; The security policy abstract model decouples itself from specific communication protocols through a policy template mechanism, enabling the security processing of different protocols to be uniformly mapped to the above three types of capabilities, thus achieving unified security decision-making in a multi-protocol environment.

[0026] Based on the communication protocol identification information in the standardized security verification dataset, the communication protocol type of the current control command is identified, and the corresponding security policy template is matched. Security policy templates serve as protocol instantiation carriers for the security policy abstract model, uniformly mapping multi-protocol security requirements into three types of capabilities: identity authentication, payload protection, and anomaly detection.

[0027] Communication protocols include, but are not limited to, protocols based on message queues, short-range wireless communication, real-time streaming media communication, and cellular communication networks.

[0028] Step 202: Link Identity Authentication Verification Based on the matched security policy template and security execution context parameters, the cryptographic algorithm suite is invoked to perform two-way authentication between the control end and the device end, verifying the consistency of the control end's identity signature, the device identifier, and the validity of the permission level.

[0029] Step 203: Payload confidentiality and integrity verification Based on the matching security policy template, the control command payload is decrypted and its integrity is verified to ensure that the command content has not been tampered with during transmission and to ensure the confidentiality of data transmission.

[0030] Step 204: Enhanced Session and Message Security Verification (Optional Step) Based on the communication protocol type and security execution context parameters, selectively perform at least one of the following checks: Anti-replay verification (based on timestamp / random number); Session binding verification (ensuring the command belongs to a legitimate session context); Separate verification of command stream and data stream (suitable for scenarios involving mixed transmission of audio, video and control data). Step 205: Abnormal Behavior Detection and Malicious Terminal Blocking Based on the verification results of Steps 201-204 above, perform abnormal behavior detection and access decision: perform abnormal detection on communication behavior, including but not limited to: unauthorized access, message tampering behavior, and high-frequency abnormal request behavior; Based on the identity authentication results and abnormal behavior detection results, a malicious terminal access blocking mechanism is implemented: Terminals without valid identity or whose signature verification fails will be directly denied access; Terminals with invalid or excessive permissions will be denied command execution; Temporary link blocking is implemented for terminals whose abnormal communication behavior reaches a threshold, and security event logs are recorded. When abnormal behavior is detected and meets the preset threshold conditions, an access blocking policy is triggered, including temporary link blocking and security alarm reporting.

[0031] Step 206: Adaptive Verification and Adjustment of Computing Power and Operating Conditions Based on secure execution context parameters, the communication security verification process is dynamically adapted, including: On low-computing-power devices, cut out non-core verification logic and retain only identity authentication and basic payload protection; In scenarios with weak networks or communication interruptions, a local caching strategy is used to complete the necessary verifications. Under strong electromagnetic interference or abnormal operating conditions, simplify the verification process and retain only the basic safety verification of emergency commands; To achieve dynamic matching between communication security capabilities and equipment operating status.

[0032] The above Steps 201 to 206 are executed sequentially in a preset order, satisfying the serial decision mechanism and blocking rules: if the verification of the preceding step fails, the subsequent verification process is immediately terminated; the access blocking process is directly executed for the control command that fails the verification. When the communication security verification passes, the verified control command and the updated security verification status information are output and passed as input to the command legality verification module; when the verification fails, the blocking result and the reason for the abnormality are output, and the subsequent abnormal handling process is triggered (corresponding to the "abnormality detection + graded handling" link of the "abnormality fault tolerance closed loop").

[0033] In this embodiment, the instruction validity verification module serves as the second line of defense, implementing combined instruction validity verification, multi-algorithm signature verification, and triple replay protection. It is a core component ensuring the legality of the instruction source, the integrity of its content, and the uniqueness of its execution. Failure of any verification item directly blocks the process. Specific functions include: Step 301: Multi-algorithm combined signature verification Based on a switchable cryptographic algorithm suite, signature verification operations are performed on control commands; The signature verification process is completed by calling a secure interface through the device's hardware cryptographic carrier, specifically including: The security component transmits the data to be verified (including the instruction content digest and signature value) to the cryptographic hardware carrier through a secure call interface; The corresponding algorithm implementation (national cryptographic / international / quantum-resistant) is loaded inside the cryptographic hardware carrier, and the internal key or public key is called to complete the signature verification operation; During the signature verification process, the key or sensitive parameters do not leave the security boundary, and the calculation result is only returned to the security component in the form of "pass / fail". The signature verification results are linked to a standardized security verification dataset, which serves as the input for subsequent verification steps. In the multi-algorithm overlay mode, multiple rounds of signature verification are executed according to the preset algorithm sequence. If any algorithm fails to verify the signature, the instruction is deemed invalid.

[0034] Step 302: Precise Matching of Equipment Identifiers The device identifier field carried in the control command (derived from the standardized security verification dataset built by the command receiving and computing power adaptive identification module) is matched and verified with the unique hardware identifier locally embedded in the device. Only when the two match is the control command allowed to enter the subsequent processing flow, thereby preventing cross-device command hijacking and erroneous execution.

[0035] Step 303: Triple replay protection check executed The control commands are subjected to anti-replay verification based on timestamps, one-time random numbers, and command sequence numbers, where: Timestamps, random numbers, and sequence numbers are primarily obtained by parsing control commands (derived from standardized security verification datasets). When the control command does not carry the above fields or the fields are incomplete, the security component generates a random number based on the local security random number generator and generates a sequence number based on the local counter to complete the dataset; Replay protection checks include: Timestamp validity check: Determines whether the instruction is within the valid time window; Random number uniqueness check: Detects whether there are duplicate random number records; Serial number continuity check: Determines whether the serial number meets the preset increment rule; If any verification fails, it is considered a replay attack and execution is blocked.

[0036] Step 304: Verification of the closed-loop anti-replay decision mechanism at the device end Unlike methods that rely on the cloud or central nodes for replay detection, this invention builds an anti-replay decision mechanism locally on the device side, and independently completes replay detection and decision by caching historical random number sets and serial number status information locally. The uniqueness of random numbers is verified by comparing them with the locally recorded set of random numbers, while the continuity of serial numbers is verified based on the serial number window maintained on the device. Even in scenarios involving communication interruptions or weak networks, it can still independently perform replay attack protection without relying on external systems.

[0037] Step 305: Verify Result Recording and Binding The execution results of each security verification step are recorded, and verification result data associated with control commands is generated; The verification result data includes verification step identifiers, verification results, and anomaly information, and is associated with corresponding control commands for subsequent security decisions, anomaly handling, and audit analysis. Verification results data can be stored locally using encryption or integrity protection methods to prevent data from being tampered with or forged.

[0038] In this embodiment, the execution constraint and policy verification module serves as the third line of defense, implementing multi-dimensional policy constraints, full lifecycle security protection of policies, strong binding verification of instructions and policies, and arbitration of instruction conflicts across multiple control terminals. It also completes standardized management of the entire key lifecycle. This is a core component in preventing unauthorized operations, unauthorized execution, and multi-terminal instruction chaos. The specific implementation process includes: Step 401: Policy Loading and Key Preparation Based on the control commands and the current security status of the device, the currently effective policy is loaded from the local policy storage area, and the corresponding policy decryption key is obtained by calling the key management module. The policy decryption and integrity verification are completed, and the policy dataset (including: policy ID, permission level rules, environmental constraints, and policy summary) is output. Step 402: Strategy Legality and Integrity Verification Perform signature and integrity checks on the policy dataset to verify the legality of the policy source and whether it has been tampered with. If the checks pass, output a trusted policy dataset; otherwise, terminate the process and refuse to execute. Step 403: Multi-dimensional strategy constraint matching Based on the trusted policy dataset and device operating status, multi-dimensional constraint verification is performed on control commands, including: control terminal permission level matching, device operating status matching, command time window validity verification, and spatial / environmental constraint verification. The output is the policy constraint judgment result. Step 404: Command-Policy Strong Binding Verification Based on standardized security verification datasets and trusted policy datasets, a ternary strong binding relationship is constructed using the "joint hash chain algorithm": binding factor = SM3(instruction content + policy ID + policy version number + device current status code); The binding factor calculated in real time is compared with the pre-stored binding factor in the device's local secure storage. Even if the instruction and policy are legal, if the device state changes / the instruction is tampered with / the policy is replaced, the binding factor will immediately become inconsistent and be directly judged as illegal execution. This mechanism ensures that an instruction can only be executed when all three conditions are met: "instruction is legal + policy is legal + device state matches".

[0039] Output the command policy binding verification result; Step 405: Arbitration of Command Conflicts Between Multiple Control Terminals Local arbitration is based on cryptographic authentication, without relying on the cloud: Each control terminal command is verified using a public key signature to confirm the identity of the user. Prioritize according to preset levels: Local emergency control terminal > Cloud management terminal > Regular APP terminal; Only allow the highest priority instructions that have passed verification; block all other instructions. The arbitration result is encrypted and recorded locally on the device, and cannot be tampered with or revoked; Output multi-party arbitration decision results; Step 406: Adjustment of Adaptive Operating Condition Strategy Based on the security execution context parameters, the policy verification logic is dynamically adjusted, including: In the event of a communication interruption, only the local hardening strategy is used. Prune non-core strategy verification items under conditions of strong interference or low computing power. In emergency scenarios, only the ability to execute emergency commands is retained. After the operating conditions are adaptively adjusted, the adjusted strategy decision result is output for the final decision in step 407.

[0040] Step 407: Final Execution Judgment Output The final execution decision is generated by combining the comprehensive strategy constraint judgment results, instruction strategy binding verification results, arbitration decision results, and adjusted strategy judgment results: If all conditions are met, output the "Execute Allowed" command; If any condition is not met, "Execution Refusal" will be output and the reason for the exception will be recorded. This will trigger the security exception handling and terminate the process (corresponding to the "Exception Detection + Hierarchical Handling" step of the "Exception Fault Tolerance Closed Loop"). S401-S407 will be executed sequentially. Each step must be executed after the preceding verification is passed. If the verification fails, the process will be directly blocked.

[0041] In this embodiment, the security execution and anomaly handling module serves as the final decision and execution control link in the security control process. Based on the verification results of the preceding modules, it constructs a security execution state machine to uniformly manage the control command execution decision, anomaly handling, security degradation, and recovery process, thereby achieving closed-loop control of the execution process.

[0042] Step 501: Execution Condition Determination Based on the communication security verification results, command legality verification results, and policy verification results, a comprehensive judgment of execution conditions is made, and the execution judgment result is output (including: allow execution / deny execution, and reason for the exception): All passed → Enter execution state; Any failure → Proceed to the exception handling process; Step 502: Safe Execution State Machine Determination Based on the execution judgment results and the current operating status of the equipment, determine the safe execution status of the equipment, including: normal execution status, abnormal blocking status, security degradation status, and emergency execution status; Step 503: Instruction Execution Control In normal or emergency execution mode, output instruction execution permission to the device execution unit; If execution is interrupted due to an abnormal state or if the execution conditions are not met, execution will be refused and the reason for refusal will be output. Step 504: Tiered Anomaly Handling Mechanism When a security anomaly is detected, a tiered handling procedure is performed based on the anomaly type, and the anomaly handling result is output: Identity / signature verification error → Block + Alert; Anti-replay / binding anomaly → Block + Log; Communication interrupted → Switch to local security mode; Security hardware malfunction → Entering downgrade mode; Specifically, each module identifies anomalies in real time (such as the communication module detecting link interruption, the verification module identifying signature failure, and the operating condition identification module detecting hardware failure) → the instruction security execution and anomaly handling module triggers tiered handling (rejecting instructions / reporting alarms) → the security degradation mode is activated (pure software encryption / temporary encrypted memory area / emergency strategy) → after the anomaly is resolved, all functions are automatically restored and cached data is synchronized.

[0043] Step 505: Security Degradation and Recovery Mechanism When a hardware, communication, or operating environment anomaly is detected, switch to a security degradation state: Enable pre-configured emergency keys and basic policies; Retain core verification capabilities; Restrict instruction types; After recovering from the anomaly, it will automatically switch back to the normal execution state.

[0044] Step 506: Execution Result Feedback and Status Synchronization The execution result or rejection reason is encrypted and then fed back to the control terminal, and the current security status is synchronized to achieve consistency of the control terminal status.

[0045] Step 507: Audit Data Generation and Status Binding Structured security data is generated for critical states during execution and bound to instructions for auditing and tracing.

[0046] Specifically, each module generates structured logs at key nodes in instruction processing → the instruction security execution and exception handling module performs SM2 signature + SM3 hash encryption on the logs and stores them locally (local storage is prioritized during weak network / network outage) → incremental encrypted upload after network recovery, or supports offline encrypted export → logs can only be operated by whitelisted operation and maintenance terminals to achieve audit traceability.

[0047] Furthermore, when all checks pass, S502→S503→S506→S507 are executed sequentially; when it is an exception handling process, S502→S505→S506→S507 are executed sequentially. The five closed loops of this invention are not independent functional modules, but control logic embedded in each security verification step. The entire process is closed-loop through the serial linkage of the five core modules.

[0048] The device-side autonomous password verification closed loop is not simply executed locally. Instead, it forms a complete decision-making capability closed loop through local anti-replay state caching (random number set + serial number window), strong binding verification of local commands and policies, and local multi-control terminal cryptographic arbitration decision-making. It is not a downgraded replacement of cloud security capabilities.

[0049] This solution forms a closed loop of five core modules through serial linkage and functional complementarity, namely "core business, fault tolerance, data traceability, working condition adaptation, and security management". This ensures that the solution has a complete logical closed loop and is feasible to implement in both normal scenarios and abnormal working conditions.

[0050] This invention provides a method for verifying the security of instructions for intelligent unmanned devices, such as... Figure 2 As shown, it includes the following steps: S1. Receive control commands through a security decision component independent of the business system, parse the control commands and identify the current computing power level and operating conditions of the device, and generate security execution context parameters and standardized security verification datasets. S2. Perform communication security verification on the control command locally on the device side, including matching the corresponding security policy template based on the standardized security verification dataset and security execution context parameters, calling the cryptographic algorithm suite to perform two-way authentication between the control end and the device side, and performing confidentiality and integrity verification on the command payload; if the verification fails, block the control command and terminate the process. S3. After the communication security verification is passed, the legality verification of the control command is performed, including multi-algorithm combination signature verification based on the switchable cryptographic algorithm suite, matching and verifying the device identifier carried in the command with the unique hardware identifier locally embedded in the device, and performing triple anti-replay verification based on the timestamp, one-time random number and command sequence number; if any verification item fails, the control command is blocked and the process is terminated. S4. After the command's legality verification passes, load the currently effective policy from the local policy storage area and perform policy legality verification. Based on the trusted policy, perform multi-dimensional policy constraint matching on the control command. Use a joint hash chain algorithm to construct a three-element strong binding relationship between the command content, policy identifier, and device status code, and compare the binding factors. Perform local priority arbitration on concurrent commands from multiple control terminals based on cryptographic authentication. If the verification fails, block the control command and terminate the process. S5. After the policy verification is passed, the instruction execution permission is output to the device execution unit, and the security anomaly is handled in a graded manner during the execution process. The graded handling includes blocking and alarming when identity or signature verification is abnormal, blocking and recording when anti-replay or binding is abnormal, switching to local security mode when communication is interrupted, and entering security degradation mode when hardware is abnormal.

[0051] Since the principle behind the problem solved by this method is similar to that of the aforementioned system, please refer to the implementation of the aforementioned system; repeated details will not be repeated here.

[0052] This invention focuses on providing core security capabilities that are adaptable to all working conditions for intelligent unmanned devices. It is applicable to all intelligent terminal devices with autonomous / remote / local control capabilities. The core solution is to address the high-reliability cryptographic security requirements of "preventing hijacking, tampering, and unauthorized execution of control commands". At the same time, it ensures that cryptographic security capabilities are not interrupted or invalidated under typical working conditions such as weak network, communication interruption, partial hardware damage, low-power sleep mode, and strong electromagnetic interference.

[0053] Typical application scenarios include, but are not limited to: Industrial manufacturing: industrial robots, robotic arms, unmanned production line equipment; Logistics and Services: AGVs, unmanned vehicles, humanoid / quadruped service robots; Energy and Inspection: Drones, unmanned inspection devices, and field operation terminals; Smart Cities and Mobility: Intelligent Connected Vehicles, Security Unmanned Equipment.

[0054] This solution targets low, medium, and high computing power levels for intelligent unmanned equipment, and designs specific implementation examples based on domestic / cross-border and routine / complex working conditions. All implementation examples adhere to the principle of "independent operation of security components and implementation of basic equipment functions by the manufacturer," fully verifying the engineering feasibility and adaptability of this solution to all working conditions.

[0055] Example 1: Embossed Intelligent Robot (Medium Computing Power, TEE Secure Carrier, WebRTC Protocol, Domestic Industrial Scenarios) The embodied intelligent robot is a medium-power computing device equipped with an ARM TrustZone TEE security carrier. It uses the WEBRTC protocol to achieve real-time audio / video and motion control command synchronization from the cloud-based visual debugging terminal. Deployed in domestic industrial workshops, it is free from strong electromagnetic interference, enjoys a stable network environment, and utilizes national cryptographic algorithms (SM2 / SM3 / SM4). The specific secure execution process is as follows: Command reception and parsing: The robot receives arm movement control commands sent by the cloud vision debugging terminal via the WEBRTC protocol. The safety component parses the core data of the command, identifies the device as having medium computing power, TEE carrier, online status, normal operating scenario, and no abnormal working conditions, and synchronizes it to subsequent modules. Communication security verification: Security hardening is performed on the WEBRTC protocol, SM2 two-way authentication is completed between the robot and the cloud debugging terminal, command frames and audio / video streams are separated and protected, command frames are encrypted with SM4, and the verification is successful; Command validity verification: SM2 signature verification is completed based on TEE. The device SN code matches the local unique identifier. The triple anti-replay verification of timestamp, random number and serial number all pass. The verification result is encrypted and fixed. Execution constraint and policy verification: The effective policy stored locally is "industrial scenario routine operation policy". The verification shows that the control terminal has administrator privileges, the robot is in normal operation, the instruction policy ID is consistent with the local policy ID, the instruction and policy joint hash verification passes, and there are no multi-control terminal instruction conflicts. Command secure execution and exception handling: After all verifications pass, an execution license is output to the execution unit, a full-link encrypted audit log is generated and solidified through SM2 signature, and the successful execution result is encrypted and synchronized to the cloud debugging terminal.

[0056] Abnormal scenario triggering: If the robot detects a communication link interruption during command execution (WEBRTC connection disconnection, detected by the equipment manufacturer), the safety component immediately triggers the local autonomous safety mode, switches to the preset emergency strategy, and only accepts emergency stop / return commands from the on-site Bluetooth remote controller. After the link is restored, it automatically switches back to normal mode, and the logs are encrypted and fixed locally during the interruption.

[0057] Example 2: Small unmanned vehicle (low computing power, pure software encryption, MQTT+4G protocol, cross-border logistics scenario) The small unmanned vehicle uses a low-computing-power MCU device without dedicated security hardware. It employs pure software encryption and remote path control via the cloud platform through the MQTT+4G protocol. Deployed in cross-border logistics scenarios, it operates under weak network conditions and uses a dual-algorithm mode (Chinese cryptographic SM2 / SM3 / SM4 + international ECC / AES / SHA-256). The specific security execution process is as follows: Command reception and parsing: The unmanned vehicle receives the path driving control command issued by the cloud logistics platform through the MQTT+4G protocol. The security component parses out the core data of the command, identifies the device as having low computing power, pure software encryption, weak network status, and a conventional logistics scenario, and synchronizes it to subsequent modules. Communication security verification: Lightweight security hardening is performed on the MQTT+4G protocol, SM2+ECC two-way identity authentication is completed between the unmanned vehicle and the cloud platform, SM4+AES dual encryption is performed on the MQTT command payload, non-core message details are removed for verification, and the verification is successful; Command legality verification: Based on a lightweight national cryptographic + international algorithm library, SM2+ECC dual signature verification is completed, the device IMEI code is matched with the local unique identifier, and the triple anti-replay verification is simplified to "timestamp + random number" dual verification, all of which pass; Execution constraint and policy verification: Non-core environmental parameter verification is removed, and only control terminal permissions and basic device status verification are retained. The logistics operation policy stored locally in encrypted form shows that ordinary users in the cloud have path driving permissions, the unmanned vehicle is in normal operation, the instruction policy ID matches the local policy ID, and there is no conflict between multiple control terminal instructions. Command security execution and exception handling: After all core verifications pass, the execution license is output to the execution unit, a lightweight encrypted audit log is generated and protected by SM3+SHA-256 dual hash, the log is locally solidified (not uploaded in weak network conditions), and the successful execution result is encrypted and synchronized to the cloud platform.

[0058] Abnormal scenario triggering: If the on-site remote controller (emergency control terminal) issues an "emergency stop" command at this time, the constraint and strategy verification module will trigger multi-control terminal command conflict arbitration. According to the priority rule of "local remote controller (emergency) > cloud platform (ordinary user)", the cloud path driving command will be rejected, the emergency stop command will be verified, and the arbitration result will be encrypted and synchronized to the cloud platform.

[0059] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0060] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A command security hardening system for intelligent unmanned devices, characterized in that, It includes a security decision component that is independent of the business control system. The security decision component is deployed on the only access path for control commands to enter the device execution unit. Each module is executed according to a rigid serial rule: if the preceding verification fails, it is directly blocked and does not enter the subsequent module; all verification and decision are completed locally on the device in a closed loop and do not depend on the cloud. The security decision component includes: Command receiving and computing power adaptive identification module: used to receive control commands from the control terminal, parse the control commands and identify the current computing power level and operating conditions of the device, and generate safe execution context parameters and standardized security verification dataset; Communication security verification module: used to perform communication security verification on the control command locally on the device side, including matching the corresponding security policy template based on the standardized security verification dataset and the security execution context parameters, calling the cryptographic algorithm suite to perform two-way authentication between the control end and the device side, and performing confidentiality and integrity verification on the command payload; Command validity verification module: used to perform command validity verification on the control command after the communication security verification is passed; The execution constraint and policy verification module is used to load the currently effective policy from the local policy storage area and perform policy validity verification after the instruction legality verification is passed. Based on the trusted policy, it performs multi-dimensional policy constraint matching on the control instruction, uses a joint hash chain algorithm to construct a three-element strong binding relationship between instruction content, policy identifier and device status code and performs binding factor comparison, and performs local priority arbitration for concurrent instructions from multiple control terminals based on cryptographic identity authentication. Security Execution and Anomaly Handling Module: After the policy verification is passed, it outputs the instruction execution permission to the device execution unit and performs graded handling of security anomalies during the execution process. The graded handling includes blocking and alarming when identity or signature verification is abnormal, blocking and recording when anti-replay or binding is abnormal, switching to local security mode when communication is interrupted, and entering security degradation mode when hardware is abnormal.

2. A method for verifying the security of instructions for intelligent unmanned devices, characterized in that, Includes the following steps: S1. Receive control commands through a security decision component independent of the business system, parse the control commands and identify the current computing power level and operating conditions of the device, and generate security execution context parameters and standardized security verification datasets. S2. Perform communication security verification on the control command locally on the device side, including matching the corresponding security policy template based on the standardized security verification dataset and the security execution context parameters, calling the cryptographic algorithm suite to perform two-way authentication between the control end and the device side, and performing confidentiality and integrity verification on the command payload; If the verification fails, the control command will be blocked and the process will be terminated; S3. After the communication security verification is passed, the legality verification of the control command is performed, including performing multi-algorithm combination signature verification based on the switchable cryptographic algorithm suite, matching and verifying the device identifier carried in the command with the unique hardware identifier locally embedded in the device, and performing triple anti-replay verification based on the timestamp, one-time random number and command sequence number; if any verification item fails, the control command is blocked and the process is terminated. S4. After the instruction legality verification is passed, load the currently effective policy from the local policy storage area and perform policy legality verification. Perform multi-dimensional policy constraint matching on the control instruction based on the trusted policy. Use the joint hash chain algorithm to construct a three-element strong binding relationship between the instruction content, policy identifier and device status code and perform binding factor comparison. Perform local priority arbitration on concurrent instructions from multiple control terminals based on cryptographic identity authentication. If the verification fails, the control command will be blocked and the process will be terminated; S5. After the policy verification is passed, the instruction execution permission is output to the device execution unit, and the security anomaly is handled in a graded manner during the execution process. The graded handling includes blocking and alarming when identity or signature verification is abnormal, blocking and recording when anti-replay or binding is abnormal, switching to local security mode when communication is interrupted, and entering security degradation mode when hardware is abnormal.

3. The method as described in claim 2, characterized in that, S1 includes: It supports receiving control commands using multiple communication protocols and extracts key data fields for authentication, integrity verification, anti-replay verification, policy association, control terminal identification, and permission determination. Automatically identify the device's computing power level and generate the security execution context parameters based on the computing power level; The key data fields are standardized. If the control command is missing the random number or sequence number required for anti-replay, the security decision component generates and completes it based on the local security random number generator to form the standardized security verification dataset.

4. The method as described in claim 2, characterized in that, S2 include: Based on the communication protocol identification information in the standardized security verification dataset, the communication protocol type to which the control command belongs is identified, and the corresponding security policy template is matched. Based on the security policy template and the security execution context parameters, a cryptographic algorithm suite is invoked to perform two-way authentication between the control terminal and the device terminal. Based on the security policy template, the control command payload is decrypted and its integrity is verified. Based on the above verification results, abnormal behavior detection is performed. If unauthorized access, message tampering, or high-frequency abnormal requests are detected, the malicious terminal access blocking mechanism is triggered. Based on the aforementioned secure execution context parameters, the communication security verification process is dynamically adapted.

5. The method as described in claim 4, characterized in that, Based on the aforementioned secure execution context parameters, the communication security verification process is dynamically adapted, including: On low-computing-power devices, cut out non-core verification logic and retain only identity authentication and basic payload protection; In scenarios with weak networks or communication interruptions, a local caching strategy is used to complete the necessary verifications. Under conditions of strong electromagnetic interference or abnormal operation, the verification process is simplified, retaining only the basic safety verification of emergency commands.

6. The method as described in claim 2, characterized in that, S3 include: Based on a switchable cryptographic algorithm suite, the device-side cryptographic hardware carrier is invoked to perform a signature verification operation on the control command, verifying the legality of the command source, and binding the verification result to the standardized security verification dataset; The device identifier field carried in the control command is matched and verified with the unique hardware identifier that is locally embedded in the device. Perform triple anti-replay checks, including: determining whether the instruction timestamp is within the valid window, checking whether the random number is unique in the local record set, and determining whether the instruction sequence number meets the preset incrementing rules; If the verification of signature, device identification matching, and anti-replay verification all pass, the legality of the instruction is deemed to have passed.

7. The method as described in claim 2, characterized in that, S4 includes: Based on the control command and the current security status of the device, the currently effective policy is loaded from the local policy storage area, and the corresponding policy decryption key is obtained. The policy decryption and integrity verification are completed, and the policy dataset is output. The signature verification and integrity verification are performed on the policy dataset. After the verification is passed, the trusted policy dataset is output. Based on the trusted policy dataset and the device operating status, multi-dimensional policy constraint matching is performed on the control command, and the policy constraint determination result is output. Based on the standardized security verification dataset and trusted policy dataset, the instruction-policy strong binding verification is performed. A joint hash chain algorithm is used to calculate the binding factor. The real-time calculated binding factor is compared with the pre-stored binding factor in local secure storage. If they match, the binding verification is deemed to have passed, and the instruction-policy binding verification result is output. If multiple control terminals issue concurrent control commands, local arbitration is performed based on cryptographic identity verification. Only the highest priority command is allowed according to the preset permission level priority, and the multi-terminal arbitration decision result is output. The policy verification logic is dynamically adjusted based on the security execution context parameters, and the adjusted policy decision result is output.

8. The method as described in claim 7, characterized in that, Dynamically adjusting the policy verification logic based on the aforementioned secure execution context parameters includes: In the event of a communication interruption, only the locally fixed strategy is used; Remove non-core strategy verification items under conditions of strong interference or low computing power. In emergency scenarios, only the ability to execute emergency commands is retained.

9. The method as described in claim 2, characterized in that, S5 include: The current safe execution state of the device is determined based on the safe execution state machine, including normal execution state, abnormal blocking state, safe degradation state or emergency execution state; In normal or emergency execution mode, the instruction execution permission is sent to the device execution unit; in abnormal blocking mode or when the execution conditions are not met, execution is rejected and the reason for rejection is output. Generate end-to-end encrypted audit logs, digitally sign and hash-protect the logs before storing them locally, and then encrypt and upload them to the control terminal after the network is restored; If a hardware or communication anomaly is detected during the verification process, switch to a security downgrade state, enable the pre-set emergency key and basic policies, retain only the core verification capabilities and restrict the types of instructions.

10. The method as described in claim 4, characterized in that, The security policy template defines the verification rules for identity authentication, payload protection, and anomaly detection.

Images