Firmware program loading protection method based on key cryptographic algorithm

Abstract

The invention relates to the technical field of firmware loading protection, and discloses a firmware program loading protection method based on a key cryptographic algorithm. The method comprises the following steps: starting a firmware loading process, and calling a dynamic verification protocol to perform integrity scanning on a firmware image; when the integrity scanning finds an exception, triggering a security event recording mechanism, generating a security event log, storing the security event log in an isolation memory, and activating a remote verification proxy service at the same time; the remote verification proxy service takes over the control right, and reads the security event log and the firmware metadata set from the isolated memory; transmitting the security event log and the firmware metadata set to a distributed verification network through an encryption tunnel; after the distributed verification network receives the security event log and the firmware metadata set, the risk assessment model is operated, and a self-adaptive verification strategy set is output; and the remote verification proxy service receives the self-adaptive verification strategy set, executes a multi-stage verification process and determines a firmware loading permission according to a verification result.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of firmware loading protection, and particularly to a firmware program loading protection method based on a key cryptographic algorithm. BACKGROUND

[0002] As the basic software of embedded devices, Internet of Things terminals and other computing devices, the secure loading of firmware is the cornerstone of the safe startup and operation of the device. Traditional firmware loading protection mechanisms rely heavily on static verification strategies, such as using a fixed digital signature algorithm to verify firmware images once during the boot process. If the signature verification is passed, the loading is allowed; otherwise, the startup process is terminated. Although this static method is simple to implement, its security largely depends on the secrecy of the private key and the strength of the signature algorithm itself. Once the private key is compromised or the algorithm is cracked, the entire verification mechanism fails. In addition, static verification lacks adaptability to runtime context and potential new attacks, and cannot respond to possible partial tampering during transmission and storage or complex attacks on the verification logic itself.

[0003] With the evolution of attack methods, such as supply chain attacks and man-in-the-middle attacks, traditional static signature verification may be bypassed or compromised. For example, an attacker may exploit vulnerabilities in the verification logic or implant carefully crafted malicious code in the firmware update package, allowing it to pass the signature verification but trigger malicious behavior at runtime. Existing technologies lack the ability to initiate more in-depth, multi-dimensional risk assessment and dynamically adjust the verification strength when the initial verification fails or suspicious situations occur. Typically, a single verification failure results in the termination of loading, which may affect device availability due to false positives or miss advanced threats due to insufficient verification strength.

[0004] The verification resources of a single device are limited and difficult to independently respond to increasingly complex attacks. Securely transmitting relevant information about suspicious events to an external network with more computing and intelligence resources for collaborative analysis is a potential way to improve detection capabilities, but how to securely implement this process and ensure the confidentiality, integrity of the transmitted data, and the credibility of the external analysis results is a challenge in practical applications. Existing solutions are mostly limited to local processing and fail to effectively leverage external resources to enhance security.

[0005] Existing firmware loading protection methods have deficiencies in dealing with complex attacks, reducing false positives, and utilizing external resources for collaborative security analysis. A more flexible, adaptive and collaborative dynamic protection mechanism is needed. SUMMARY

[0006] The purpose of the present application is to provide a firmware program loading protection method based on a key cryptographic algorithm to solve the problems raised in the background.

[0007] To achieve the above object, the application provides a firmware program loading protection method based on a key cryptographic algorithm, which comprises the following steps: starting a firmware loading process, and calling a dynamic verification protocol to perform an integrity scan on a firmware image; when the integrity scan finds an anomaly, triggering a security event recording mechanism to generate a security event log and store it in an isolated memory, and activating a remote verification agent service; the remote verification agent service takes over the control, reads the security event log and a firmware metadata set from the isolated memory; transmits the security event log and the firmware metadata set to a distributed verification network through an encrypted tunnel; after receiving the security event log and the firmware metadata set, the distributed verification network runs a risk assessment model to output an adaptive verification strategy set; the remote verification agent service receives the adaptive verification strategy set, executes a multi-stage verification process, and decides the firmware loading permission according to the verification result.

[0008] Preferably, the integrity scan on the firmware image by calling the dynamic verification protocol comprises the following steps: loading a binary data stream of the firmware image, and calculating a hash digest value of the firmware image by using a hash algorithm; obtaining a pre-stored standard hash value from a secure storage area, wherein the standard hash value corresponds to a legal version of the firmware image; comparing the calculated hash digest value with the pre-stored standard hash value to obtain an integrity check result; when the integrity check result indicates that the hash digest value does not match the standard hash value, it is determined that the integrity scan finds an anomaly.

[0009] Preferably, the generation of the security event log comprises the following steps: when the integrity check result indicates an anomaly, capturing a loading timestamp and a running environment parameter of the firmware image; combining the integrity check result, the loading timestamp and the running environment parameter to construct a security event record; digitally signing the security event record to generate the security event log, and writing the security event log into the isolated memory.

[0010] Preferably, the reading of the security event log and the firmware metadata set from the isolated memory comprises the following steps: the remote verification agent service sends a reading request to the isolated memory, wherein the reading request contains an access token; after verifying the validity of the access token, the isolated memory returns the security event log and the firmware metadata set; the firmware metadata set comprises a firmware version number, a developer identifier and a loading address range.

[0011] Preferably, the operation risk assessment model outputs an adaptive verification policy set, which includes: Parsing the security event log and the firmware metadata set to extract a risk feature vector; Inputting the risk feature vector into a pre-trained risk classifier to obtain a risk level score; Querying a strategy template library according to the risk level score to match a corresponding verification rule group; Prioritizing the verification rule group to generate the adaptive verification policy set.

[0012] Preferably, the extraction of the risk feature vector includes: Parsing an exception type code and an event severity level from the security event log; Obtaining a firmware version number and a developer identifier from the firmware metadata set; Encoding the exception type code, the event severity level, the firmware version number, and the developer identifier into a feature array; Normalizing the feature array to generate the risk feature vector.

[0013] Preferably, the prioritizing of the verification rule group includes: Calculating an execution weight of each verification rule according to the risk level score; Arranging the verification rules in descending order of the execution weight to form an initial strategy sequence; Detecting rule conflicts in the initial strategy sequence and performing conflict resolution operations to output a resolved strategy sequence as the adaptive verification policy set.

[0014] Preferably, the execution of the multi-stage verification process includes: A remote verification agent service parses the adaptive verification policy set to determine the number of verification stages; For each verification stage, loading corresponding verification rules and performing firmware attribute checking; Cumulating the checking results of each verification stage to generate an overall verification score, comparing the overall verification score with a preset threshold, and determining firmware loading permission.

[0015] Preferably, the execution of the firmware attribute checking includes: Reading code segments and data segments of the firmware image to calculate memory distribution features; Verifying whether the memory distribution features conform to predefined security specifications, checking whether an import table of the firmware image contains unauthorized function calls, and outputting the checking results.

[0016] Preferably, the determination of the firmware loading permission according to the verification results includes: When the verification results pass, the remote verification agent service issues a loading token to allow the firmware loading to continue; When the verification result fails, the remote verification agent service sends an abort signal to terminate the firmware loading process.

[0017] Compared with the prior art, the present application has the following beneficial effects: The present application sets up an initial security checkpoint for firmware loading by initiating a dynamic verification protocol for integrity scanning at startup. When an anomaly is found during the initial scan, instead of simply aborting the process, a security incident logging mechanism is triggered and the logs are stored in isolated memory. This approach preserves forensic information about the abnormal state, and the isolated storage helps prevent tampering with the logs. Activating the remote verification agent service means transferring the verification task from the local environment, which may have been affected, to an external intervention, introducing the possibility of external intervention.

[0018] The remote verification agent service reads the security incident logs and firmware metadata and transmits them to the distributed verification network through an encrypted tunnel. This process takes into account the security of data transmission to prevent information from being stolen or tampered with during transmission. The distributed verification network uses its possibly more powerful computing resources and richer threat intelligence library to run a risk assessment model, which can conduct more in-depth and comprehensive analysis of abnormal incidents. The adaptive verification strategy set output by the distributed verification network is more targeted and may dynamically adjust the strictness of verification according to the risk level.

[0019] The remote verification agent service receives and executes this adaptive strategy set for multi-stage verification, which may be more complex and comprehensive than the initial local verification, thereby improving the detection capability of potential threats. Finally, the loading permission is determined according to the multi-stage verification result, making the decision-making basis more sufficient. This method builds a closed-loop process from local preliminary detection, security incident logging, remote collaborative risk assessment, adaptive verification to final permission decision. It changes the traditional static and one-time verification mode and provides a dynamic, scalable and collaborative response mechanism that can initiate more in-depth analysis instead of simply rejecting when an anomaly occurs, which helps to reduce the impact of false positives on device usability and may improve the detection capability of complex or new attacks, enhancing the security and resilience of the firmware loading process. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 The working principle diagram of the firmware program loading protection method based on key cryptographic algorithms described in the present application; Figure 2 The flowchart for calling a dynamic verification protocol to perform integrity scanning on a firmware image; Figure 3 The flowchart for generating a security incident log; Figure 4 The timing analysis diagram of the number of firmware security incidents; Figure 5A multi-stage firmware verification performance index comparison chart. DETAILED DESCRIPTION

[0021] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work are within the scope of protection of the present application.

[0022] Referring to Figure 1 The present application provides a firmware program loading protection method based on a key cryptographic algorithm, which comprises: after a firmware loading process is started, a system automatically calls a dynamic verification protocol to perform integrity scanning on a firmware image, and the scanning process detects any abnormal change of firmware data based on a predefined verification rule. When the integrity scanning finds an abnormal condition, the system immediately triggers a security event recording mechanism, which generates a detailed security event log and stores it in an isolated memory, and the isolated memory uses a hardware isolation technology to ensure that the log data is not tampered with; at the same time, the system activates a remote verification agent service, which takes over the subsequent control as an independent process. The remote verification agent service first reads the security event log and a firmware metadata set from the isolated memory, wherein the metadata set includes firmware version information, developer identification and other key attributes; then, the above data is securely transmitted to a distributed verification network through an encrypted tunnel, and the encrypted tunnel uses an asymmetric encryption algorithm to guarantee the confidentiality of the transmission. The distributed verification network is composed of multiple verification nodes, which run a risk assessment model after receiving the data, and the model analyzes risk features based on a machine learning algorithm and outputs an adaptive verification strategy set, which contains a series of verification rules and their execution order. After receiving the adaptive verification strategy set, the remote verification agent service executes a multi-stage verification process, which gradually checks firmware attributes by stages, and dynamically decides firmware loading permissions according to the verification results, so as to ensure that only legal firmware can be loaded and run.

[0023] Embodiment 1: Referring to Figure 2In an embodiment where the dynamic verification protocol is invoked to perform an integrity scan of the firmware image, the system enters a scan flow after initialization, a binary data stream of the firmware image is read from a storage medium, which includes a flash memory or an EEPROM, the binary data stream is transferred to a protected memory buffer through a direct memory access controller, the protected memory buffer has access permission restrictions set by a memory protection unit to prevent unauthorized modification or reading. In a specific implementation, a hash digest value of the firmware image is calculated using a hash algorithm, the hash algorithm adopts the SHA-256 standard, the calculation process is performed by a hardware encryption module, which is independent of the main processor, to ensure calculation efficiency and avoid software layer interference, the hash calculation is initialized with a block of the binary data stream of the firmware image, the data is processed in a streaming manner to reduce memory occupancy, and a fixed-length hash digest value is output after the calculation is completed. The pre-stored standard hash value is obtained from a secure storage area, which is an embedded secure element or a root of trust module, the pre-stored standard hash value is generated by an authorized entity before the firmware is released and written, the secure storage area needs to be accessed by verifying a digital certificate, the digital certificate is managed by a public key infrastructure to ensure that only a legal process can read the pre-stored standard hash value. The calculated hash digest value is compared with the pre-stored standard hash value, the comparison operation is performed in a secure execution environment, the secure execution environment prevents data leakage through isolation technology, and the comparison logic uses bit-level bitwise comparison to output a Boolean result as an integrity check result. When the integrity check result indicates that the hash digest value does not match the standard hash value, the system determines that the integrity scan has found an anomaly and sets an exception flag, the exception flag triggers an interrupt service routine to enter an exception handling flow. In some embodiments, the binary data stream loading stage of the firmware image can include data checksum and verification, which uses a cyclic redundancy check code as an auxiliary measure to enhance data transmission reliability. Optionally, the hash algorithm can select a SHA-3 variant, which provides different output lengths to adapt to resource-constrained environments. In a specific implementation, the implementation of the secure storage area can include a multiple backup mechanism that stores multiple versions of the standard hash value to support firmware rollback scenarios. After the comparison process is completed, the system records the comparison timestamp and the operation status, which are used for audit tracking. It can be understood that the integrity scan flow is a basic link of the dynamic verification protocol, which is repeatedly executed by the dynamic verification protocol through periodic or event-driven methods to ensure runtime security. In a specific implementation, the hash calculation module can integrate error detection code to correct temporary hardware faults and avoid calculation errors. When reading the pre-stored standard hash value from the secure storage area, the system verifies the integrity signature of the storage medium to prevent data tampering. In some embodiments, the comparison operation can use a fuzzy matching threshold, which handles slight data variations but mainly relies on exact matching to ensure security.Optionally, the integrity check result can be encoded as a multi-level status, including a warning level and a serious level, for refining the exception handling. It can be understood that the entire scanning process is embedded in the firmware loading bootloader, which runs in the early stage of system startup, minimizing the attack surface.

[0024] In practical implementation, the specific steps for loading the binary data stream of the firmware image involve address mapping and size verification. Address mapping converts the logical address of the firmware image into a physical address, and size verification checks whether the data stream length meets the expected range to prevent buffer overflow attacks. When calculating the hash digest value of the firmware image using a hash algorithm, the algorithm initialization parameters are loaded from the configuration register, which stores the hash seed and round constant. The calculation process processes data in blocks, with each data block iteratively processed by a compression function to finally generate a digest value. The process of retrieving the pre-stored standard hash value from the secure storage area includes sending a read command to the secure storage area controller. The secure storage area controller verifies the identity of the requesting source, based on a challenge-response protocol, ensuring that only authorized components can access the pre-stored standard hash value. In the implementation of comparing the calculated hash digest value with the pre-stored standard hash value, the system uses a hardware comparator circuit. The hardware comparator circuit compares all bits in parallel and outputs the comparison result to the status register, which is read by the monitoring software via polling or interrupt drive. When the integrity verification result indicates an anomaly, the system records the anomaly context information, including the firmware image loading path and system mode, for subsequent analysis. In practical implementation, hash algorithm calculations can support incremental updates, allowing hashes to be recalculated when parts of the firmware image are modified, without having to process the entire data stream. Optionally, the secure storage area can be implemented as a tamper-proof memory, which physically resists probing attacks. After the comparison operation, the system can perform redundant comparisons, which reduce the probability of false alarms through secondary verification. It is understood that performance optimization of the integrity scan process includes cache prefetching and pipelined processing; cache prefetching reduces memory latency, and pipelined processing overlaps data loading and computation stages. In practical implementation, when loading the binary data stream, the system checks data integrity markers, which indicate whether the data has been encrypted or compressed, and preprocesses it if necessary. When using hash algorithms, the algorithm library is linked to a static version, avoiding the risk of dynamic link library dependencies. When reading data from the secure storage area, access logs are maintained and used for security auditing. Processing of comparison results includes generating reports, which are transmitted to the management entity via a secure channel. In some embodiments, hash calculations can be parallelized, leveraging multi-core processors to accelerate the processing of large firmware images. Optionally, the storage format of the standard hash value can include version metadata, which supports multi-firmware version management. It is understandable that the anomaly detection logic can integrate a machine learning model, which analyzes historical data to adjust the detection threshold, but the core remains based on precise hash matching.

[0025] In practical implementation, the details of loading the binary data stream of the firmware image include memory alignment checks. Memory alignment checks ensure that the data stream addresses conform to processor requirements, avoiding performance degradation or errors caused by misaligned access. During the process of calculating the hash digest value using a hash algorithm, the algorithm execution includes initial hash value setting, message grouping processing, and final digest generation. The initial hash value is based on algorithm standard constants, message groups are padded to a fixed length, and the final digest is stored in a temporary buffer after generation. In the step of retrieving the pre-stored standard hash value from secure storage, the system calls a secure application programming interface (API). The secure API encapsulates underlying hardware access and provides atomic operations to ensure data consistency. When comparing the hash digest value with the standard hash value, the comparison function is implemented as an assembly language routine. The assembly language routine optimizes speed and prevents compiler-introduced vulnerabilities. When an exception occurs, the system triggers a global event flag, which synchronizes the response actions of multiple processing cores. In practical implementation, data stream loading can support flow control mechanisms to handle slow storage media and prevent data loss. Hash algorithm calculation can be configured to use hardware-accelerated instruction sets, such as AES-NI, to improve throughput. Access to the secure storage area may require temperature monitoring to prevent data corruption caused by physical attacks. The results of comparison operations can be logged to a non-volatile log, which is persistently stored after a system reboot. Optionally, the integrity scan process can dynamically adjust the scan frequency, adapting to changes in system load. It is understood that the entire implementation relies on hardware security extensions, such as TrustZone technology, to isolate critical resources. In some embodiments, the binary data stream loading phase may include data source authentication, verifying the signer's identity for the firmware image. The hash calculation module can support switching between multiple algorithms, selected via configuration registers. When reading data from the secure storage area, error correction code detects and repairs bit errors. The comparison logic can be implemented asynchronously, without blocking the system startup process. Optionally, after an anomaly is detected, the system can enter a safe mode, restricting functionality until the problem is resolved. It is understood that the implementation design considers real-time constraints, which are met by optimizing the critical path to meet startup time requirements.

[0026] In practical implementation, the method for loading the binary data stream of the firmware image involves DMA configuration. DMA configuration sets the transfer size and source / destination addresses. An interrupt signal is generated upon completion of the transfer, and the interrupt signal handler verifies data integrity. When using a hash algorithm, the algorithm context is stored in a secure stack, which prevents context switching from interfering with the calculation. The process of retrieving the pre-stored standard hash value from the secure storage area includes a cryptographic challenge, which ensures the requester possesses a legitimate key. The comparison operation uses a constant-time algorithm, which avoids timing side-channel attacks. When an anomaly is detected, the system notifies the monitoring daemon, which takes corrective measures. In practical implementation, data stream loading can integrate compression / decompression logic, reducing storage space requirements. Hash algorithm initialization parameters can be passed from the secure bootloader, which provides the root of the trust chain. The secure storage area can be implemented as distributed storage, which improves availability through redundancy. Comparison results can be used to update system policies, which dynamically adjust security levels. Optionally, integrity scanning can be extended to multiple firmware components, with parallel scanning of multiple firmware components improving efficiency. It is understood that the robustness of the implementation is enhanced through error handling, which retrys failed operations or degrades the operation. In some embodiments, the loading process may verify the data stream checksum, which serves as an initial integrity check. Hash calculations may record performance metrics, which are used for system optimization. Secure storage area access requires Secure Boot to be enabled, which ensures the initial state is trustworthy. Comparison functions may output difference reports, which help diagnose the root cause of problems. Optionally, exception handling logic may be integrated into an interrupt handler, which prioritizes security events.

[0027] Example 2: See Figure 3The process of generating a security event log is initiated immediately when the integrity verification result indicates an anomaly. The system captures the firmware image's load timestamp and runtime environment parameters. The load timestamp is generated by a high-precision real-time clock circuit, and the runtime environment parameters include processor register states, memory mapping table contents, and the current execution privilege level. A security event record is constructed by combining the integrity verification result, load timestamp, and runtime environment parameters. The security event record uses a standardized data sequence format and includes an event identifier, time metadata, and environment snapshot information. The security event record is digitally signed to generate the security event log. The digital signature operation uses an elliptic curve digital signature algorithm and the device's unique private key. The security event log is written to isolated storage, which achieves hardware-level isolation through a dedicated address space set by the memory management unit. In practice, the process of capturing the load timestamp is synchronized with the interrupt service routine to ensure the accuracy of the time record. The runtime environment parameters are obtained by accessing kernel data structures through system call interfaces. These kernel data structures include the process control block and the memory descriptor table. When constructing the security event log, the data serializer encodes multiple fields into a binary large object, which is appended with a length prefix and a version identifier. The digital signature generation module invokes the cryptographic coprocessor to calculate the hash value of the security event record and performs the signature calculation using the private key stored in the secure element. Writing to isolated memory requires elevated memory access permissions, granted by the system management mode. In some embodiments, the loading timestamp can include nanosecond precision and time zone information, which is used for cross-regional log correlation analysis. Optionally, runtime parameters can be extended to include peripheral device status register values, which reflect the health status of hardware components. The digital signature algorithm can be a variant of EdDSA, which provides deterministic signature generation characteristics. It is understood that the security event log generation process is a core component of the security event recording mechanism, which provides tamper-proof audit trails for subsequent analysis.

[0028] The process of the remote authentication agent service sending a read request to the isolated storage begins with the authentication phase. The read request includes an access token, which is a JSONWeb token format data structure issued by a certification authority. The isolated storage verifies the validity of the access token, including token signature verification and validity period checks. Upon successful verification, it returns a security event log and a firmware metadata set. The firmware metadata set includes the firmware version number, developer identifier, and load address range. The firmware version number is encoded using the Semantic Versioning Specification, the developer identifier is the SHA-256 hash value of the digital certificate, and the load address range specifies the legal loading region of the firmware in memory. In practice, the remote authentication agent service constructs a read request message containing command code and a transaction identifier, which is sent to the isolated storage controller via the system bus. The isolated storage controller parses the signature portion of the access token, verifies the signature's validity using a pre-configured public key certificate, and checks whether the timestamp in the token is within a valid time window. When returning data, the isolated storage controller performs data scrambling to prevent bus eavesdropping attacks. The firmware metadata set is parsed from a specific offset in the firmware header, and the parser verifies the magic word and checksum of the metadata structure. In some embodiments, the access token may contain fine-grained access permission claims that restrict the range of readable data fields. Optionally, the isolated memory may be implemented as a battery-powered static random access memory (SRAM) that maintains data persistence in the event of mains power failure. The process of verifying token validity may integrate a token revocation list check, which prevents access attempts with revoked tokens. It is understood that the transmission channel for read requests needs to be protected, and the transmission channel achieves end-to-end confidentiality through a memory encryption engine.

[0029] In practical implementation, the specific method for capturing runtime environment parameters involves directly accessing the processor's special function registers, which contain program status words and control register contents. When constructing security event logs, the serialization engine converts heterogeneous data into a unified format, which uses a TLV encoding scheme to ensure scalability. During digital signature generation, the system first calculates the cryptographic hash value of the security event log, which is then input into the signature algorithm module to generate a digital signature. Write operations to isolated memory need to bypass the conventional cache hierarchy, which is configured as non-cacheable via the memory type range register. Before sending a read request, the remote verification agent service needs to obtain an access token, which is derived from the hardware root of trust through the secure boot process. The logic for verifying the validity of the access token in isolated memory includes checking the token issuer's digital certificate chain, which verifies the root certificate authority. When returning security event logs and firmware metadata sets, data transmission uses a scatter-cluster pattern, which reduces memory copy overhead. The load address range field of the firmware metadata set needs to be verified in conjunction with the memory management unit, which checks whether the address range conflicts with existing memory mappings. In practical implementation, runtime environment parameter capture can include performance monitoring counter values, which provide side-channel information about system behavior. Security event logging can include event severity ratings, dynamically calculated based on a predefined rule table. Digital signature generation can utilize white-box cryptography, preventing key extraction in untrusted environments. Isolated memory write operations require atomicity guarantees, implemented through transactional memory mechanisms. Optionally, the remote authentication proxy service can be implemented in a microkernel architecture, reducing the attack surface. Access token authentication can rely on a hardware security module, providing tamper-proof key storage. The entire data retrieval process is integrated with a system error handling mechanism, which retrys failed storage access operations.

[0030] In practice, the complete pipeline for generating security event logs comprises multiple processing stages. The timestamp capture unit synchronizes with the system clock source, which employs a temperature-compensated crystal oscillator to maintain time accuracy. The runtime parameter acquisition module scans the processor status registers, memory management unit table, and input / output memory mapping areas to generate a system status snapshot. The security event log builder packages discrete data elements into a continuous byte stream, adding type identifiers and length prefixes for parsing. The digital signature engine processes the security event logs using asymmetric cryptographic algorithms, generating digital signature data blocks appended to the original logs. The isolated memory controller manages access to the physical storage media, including magnetic random access memory or phase-change memory, providing non-volatile storage capabilities. The remote authentication agent service initialization stage establishes a secure session with the isolated memory, establishing an encrypted channel through a two-way authentication protocol. The read request formatter generates command frames conforming to the storage protocol, containing a target address field and a data length field. The access token validator checks whether the permission scope in the token claim matches the request operation type. The firmware metadata set parser extracts structured information from the firmware image file header, including segment table entry points and relocation table addresses. In some embodiments, the timestamp may contain a monotonically increasing sequence number, which addresses the clock back-off issue. Runtime environment parameter acquisition may include interrupt descriptor table base address register values, reflecting exception handling configurations. Security event logging may include compression preprocessing, reducing storage space usage. Digital signature generation can use a threshold signature scheme, requiring collaboration from multiple signers. Isolated memory writes can be implemented as a log structure, improving write durability. Optionally, the remote verification agent service can support hot backup redundancy, improving service availability. Access token verification can be integrated with a risk assessment engine, which dynamically adjusts access policies. It is understood that implementation methods need to consider real-time performance constraints, which are met by optimizing critical code paths to satisfy response time requirements.

[0031] In practical implementation, the security event log generation subsystem includes the following details: a buffer management strategy that uses double buffering to prevent data loss; a timestamp counter synchronized with a network time protocol server providing an external time reference; a runtime parameter collector using direct memory access channels to read large blocks of data, reducing processor load; a security event log serialization format incorporating backward compatibility, allowing newer system versions to parse older formats; digital signature algorithm configuration parameters stored in a circuit breaker array to prevent runtime modification; isolated memory address mapping using page tables to prevent access in normal mode; a communication protocol between the remote verification agent service and the isolated memory defining a retransmission mechanism to handle temporary transmission errors; and access token encoding using a Base64URL encoding scheme to avoid protocol character conflicts. Firmware metadata verification includes cyclic redundancy check (CRUD) to detect metadata corruption. In practice, timestamp generation can be integrated with a trusted platform module, providing a tamper-proof time source. Runtime environment parameter collection can include cache consistency status information reflecting multi-core synchronization status. Security event logs can be watermarked to track log propagation paths. The digital signature generation process can be parallelized across multiple records, improving throughput. The isolated memory access interface can be implemented as memory-mapped I / O, simplifying driver design. Optionally, a remote authentication broker service can support load balancing, distributing requests across multiple processing cores. The access token update policy can be based on a rolling key mechanism, which periodically changes the token signing key.

[0032] See Figure 4The data presents the distribution of four types of security events (hash mismatch, unauthorized access, firmware version anomaly, and runtime environment anomaly) over time. From a professional perspective, hash mismatch events (blue line) exhibit high-frequency fluctuations, repeatedly reaching peak numbers above 17, reflecting frequent firmware image integrity verification failures. This is closely related to the hash-based integrity scanning mechanism in the project background, indicating frequent attempts to illegally tamper with or compromise the firmware image during the firmware loading process. While the overall number of unauthorized access events (red line) is lower than that of hash mismatch events, they show concentrated outbreaks at multiple time points (such as 01-0109 and 01-0200), demonstrating that unauthorized attempts to gain firmware loading permissions have a phased characteristic. Further analysis is needed, considering the remote verification proxy service and distributed verification network's permission control logic within the project, to determine if there are vulnerabilities or potential for bypassing the permission verification strategies during these periods. The relatively low number and large fluctuations of firmware version anomaly events (yellow line) with multiple zero or extremely low value nodes indicate that firmware version anomalies are not continuous and may be related to the release and update cycle of specific firmware versions. This can be investigated by combining the version verification mechanism of the firmware metadata set in the project to explore whether the root cause of the version anomalies is a firmware upgrade management oversight or malicious version injection. The changes in the number of runtime environment anomaly events (green line) are related to hash mismatches. Peak periods of hash mismatches are often accompanied by an increase in runtime environment anomalies. This corresponds to the anomalies in runtime environment parameters (such as processor status and memory mapping) captured by the project's security event logging mechanism, indicating that when the firmware runtime environment is tampered with or damaged, it easily leads to firmware integrity verification failure. There is a causal or concurrent security correlation between the two. In summary, the occurrence patterns and correlations of the four types of security events are intuitively presented from a temporal perspective, providing data support for the optimization of risk assessment models and the adjustment of adaptive verification strategies in subsequent firmware program loading protection methods based on dynamic security protocols. Further improvement in the accuracy of security defenses in the firmware loading process can be achieved by analyzing the temporal distribution density and peak correlation of each event.

[0033] Example 3: The implementation of running the risk assessment model and outputting an adaptive verification strategy set begins after the distributed verification network receives security event logs and firmware metadata sets. The risk assessment model parsing process is then initiated. Parsing the security event logs and firmware metadata sets is completed by a data parsing engine, which identifies the log format and metadata structure, extracting key fields for subsequent processing. In the risk feature vector extraction stage, numerical features are extracted from the parsed data. These features include event type codes, time attributes, and firmware attribute indicators, forming a multi-dimensional vector representation. The risk feature vector is input into a pre-trained risk classifier. The risk classifier performs classification reasoning based on machine learning algorithms, obtaining a risk level score. The risk level score is a numerical output representing the degree of risk. Based on the risk level score, a strategy template library is queried. The strategy template library stores verification rule sets corresponding to different risk levels. The matching process uses a search algorithm to find the most suitable verification rule group. The verification rule groups are prioritized and scheduled. The scheduler calculates the execution order based on rule attributes, resolves potential conflicts, and finally generates an adaptive verification strategy set. The adaptive verification strategy set is output in a machine-readable format for use by the remote verification agent service. In practical implementation, parsing security event logs requires processing semi-structured data, which contains key-value pairs and nested fields. The parser uses a recursive descent parsing algorithm to extract event codes and timestamps. Parsing the firmware metadata set involves binary structure deserialization, and the deserialization process verifies data integrity checksums. When extracting risk feature vectors, the feature engineering module converts categorical variables into one-hot encodings, and continuous variables are standardized to ensure consistent vector element scale. The inference process of the risk classifier is computed in a forward propagation network, with network weights loaded from persistent storage, and the score output mapped to a predetermined range through an activation function. The query strategy template library uses an index to accelerate access; the index is built based on risk score intervals, and the matching algorithm calculates similarity scores to select the best rule group. Priority scheduling is implemented as a directed acyclic graph traversal, where the directed acyclic graph represents rule dependencies, and the scheduling algorithm considers execution cost constraints. In some embodiments, parsing security event logs can support multiple log standard formats, which are processed uniformly through an adapter pattern. Extracting risk feature vectors may include a feature selection step, which uses mutual information to reduce dimensionality. The risk classifier can integrate ensemble learning methods, such as random forests, to improve robustness. The query strategy template library can be implemented as a distributed database, providing highly available access. Priority scheduling can introduce a dynamic adjustment mechanism that responds to changes in system load.

[0034] In practice, the detailed steps for parsing security event logs and firmware metadata sets include a syntax analysis phase, which verifies that log entries conform to a predefined pattern. The predefined pattern is defined using JSONSchema or XSD. Parsing of the firmware metadata set begins with a magic word in the file header, which confirms the data format version. When extracting risk feature vectors, the vector constructor connects multiple feature sources, including log event counts and metadata statistics, generating a fixed-length array. Before inputting the risk feature vectors into a pre-trained risk classifier, vector normalization is required. Normalization uses a min-max scaling method to transform the values ​​to the [0,1] interval. The reasoning process of the risk classifier can be represented by a mathematical formula used to calculate the risk level score S: in: Indicates the risk level score. This represents the Sigmoid activation function. This represents the number of dimensions in the risk feature vector. This represents the j-th component value of the risk feature vector. Indicates the relationship between risk classifier and The corresponding weighting coefficients, This represents the bias term of the risk classifier.

[0035] After obtaining the risk level score, the system discretizes the score into multiple levels using an equal-width binning method. When querying the strategy template library, the query statement is constructed as a range query, which finds matching entries based on the score level. Matching the corresponding validation rule group is accomplished by calculating cosine similarity, comparing the query result with the rule group feature vector. When prioritizing the validation rule group, the scheduling algorithm calculates the urgency score for each rule, based on the rule type and historical execution time. After generating the adaptive validation strategy set, the serializer converts the strategy into XML or JSON format for transmission. In some embodiments, the parsing process may include a data cleaning step, which handles missing and outlier values. Principal component analysis can be applied to extract risk feature vectors, reducing computational complexity. The risk classifier can support online learning, with model parameters updated periodically. The query strategy template library can cache popular query results, reducing latency. Priority scheduling can use heuristic algorithms, such as genetic algorithms, to optimize the order.

[0036] In practical implementation, the extraction of risk feature vectors further involves feature scaling and encoding. Feature scaling uses Z-score normalization to process numerical features, while encoding converts categorical features into numerical representations, such as using label encoding or one-hot encoding. The risk classifier loading process retrieves pre-trained models from a model repository, stored in PMML or ONNX format. Model signature verification during loading prevents tampering. Risk level scoring is performed on a GPU accelerator, which processes batches of feature vectors in parallel to improve throughput. The query strategy template library uses SQL query language, which joins multiple tables to obtain rule group information. The algorithm for matching and validating rule groups uses a k-nearest neighbor classifier, which finds the closest rule group in the feature space. Priority scheduling is implemented based on a priority queue data structure, where rules are ordered by weight, determined by rule importance and resource requirements. When generating an adaptive validation strategy set, the strategy compiler converts the rule sequence into bytecode, which is executed in a virtual machine. In some embodiments, feature vector extraction may include time-series features, calculated from sliding window statistics in historical logs. The risk classifier can be implemented as a support vector machine (SVM), which uses kernel functions to handle non-linear features. The query process can integrate full-text search, which matches keywords in the rule description text. Priority scheduling can consider rule mutual exclusion constraints, which can be resolved through constraint programming. Optionally, a streaming parser can be used to parse security event logs, processing data step-by-step to reduce memory usage. It's understandable that the efficiency of the risk assessment model depends on the feature dimensionality and model complexity, and a trade-off must be struck between accuracy and performance.

[0037] In practical implementation, parsing security event logs involves regular expression matching, which extracts structured fields such as timestamps and event codes from the log text. Parsing the firmware metadata set requires handling byte order issues, which are automatically adjusted by detecting system endianness. The process of extracting risk feature vectors monitors changes in feature distribution, triggering model retraining alerts when changes occur. The risk classifier's inference uses optimization libraries such as IntelMKL to accelerate matrix operations. The output range of the risk level score is configurable, mapping to specific risk level labels.

[0038] The similarity threshold for matching verification rule groups is adjustable, controlling the matching strictness. Conflict detection in priority scheduling uses graph theory algorithms to detect circular dependencies. The output of the adaptive verification policy set includes version control information, which supports policy rollback. In specific implementations, security event log parsing can handle compressed log formats, such as GZIP files, which are decompressed in real-time. Firmware metadata set parsing verifies digital signatures, ensuring the credibility of the metadata source. Risk feature vector extraction can integrate domain knowledge, introduced through feature templates. The risk classifier's training data comes from historical security events, which are labeled with risk levels. The matching algorithm can weight different features, reflecting their importance. Priority scheduling can pre-compute scheduling plans, reducing runtime overhead. It is understood that the entire implementation needs to coordinate with the consensus mechanism of the distributed verification network, ensuring that multiple nodes output a consistent policy set.

[0039] In practical implementation, the allocation of computing resources for running the risk assessment model is dynamically adjusted, scaling container instances based on the amount of input data. An error handling mechanism for parsing security event logs records details of parsing failures, retrying or skipping corrupted data. A caching layer for extracting risk feature vectors stores intermediate results, reducing redundant computation. The risk classifier's model version management automatically switches, selecting the best model based on A / B test results. The risk level scoring calibration process uses Platt scaling, adjusting the scoring probability output. Backup strategies from the query strategy template library periodically snapshot data, preventing data loss. A feedback loop for matching verification rule groups collects execution results, optimizing matching accuracy. Real-time priority scheduling is ensured using a real-time operating system scheduler, meeting deadline requirements. The verification step for generating an adaptive verification strategy set checks the policy logic consistency, using model detection technology. In some embodiments, the parsing process can process multiple log files in parallel, utilizing multi-core processors. Feature extraction can incrementally update feature vectors, adapting to streaming data. The risk classifier can be deployed as a microservice, communicating via a service mesh. Query operations can utilize a partitioning strategy template library, which improves scalability. Priority scheduling can simulate the execution of verification rule groups, predicting their performance impact. It is understood that security considerations in the implementation include encrypted protection of the model and data, using end-to-end encryption to prevent leakage.

[0040] Example 4: The implementation process of extracting risk feature vectors begins with obtaining raw data fields from security event logs and firmware metadata sets. From the security event logs, exception type codes and event severity levels are parsed. Exception type codes are converted into integer enumeration values ​​according to a predefined classification mapping table, and event severity levels are extracted as floating-point numbers from the severity field of the log entry. From the firmware metadata set, the firmware version number and developer identifier are obtained. The firmware version number is decomposed into three integer components—major version number, minor version number, and revision number—according to the semantic version specification. The developer identifier is converted into a fixed-length integer value using a string hash function. The exception type code, event severity level, firmware version number, and developer identifier are encoded into a feature array. The feature array is arranged in contiguous memory blocks according to field order, with each field occupying a predetermined position. The feature array is normalized using a min-max scaling method to linearly transform the values ​​of each dimension to the [0,1] interval, generating the final risk feature vector for use by the risk assessment model. In specific implementation, parsing exception type codes requires processing a multi-level classification system. This system subdivides exceptions into subcategories such as integrity violations and memory errors, with each subcategory assigned an independent code. The parsing of event severity levels considers the priority field in the logs, which is matched against a predefined severity mapping table. Firmware version number decomposition uses regular expressions to match version string patterns and extract the numeric components. The hash calculation of the developer identifier uses the FNV-1a algorithm, which produces a 32-bit hash value. The encoding of the feature array uses bit-field combination techniques to optimize storage space. Normalization parameters are obtained from training data statistics, which include the minimum and maximum values ​​for each feature dimension. Optionally, the exception type code can be extended to include subtype information, represented by additional bits. Event severity levels can incorporate a time decay factor, which reduces the weight of historical events.

[0041] Referring to Table 1, the priority scheduling operation for the verification rule group is based on the output of the risk assessment model. The execution weight of each verification rule is calculated according to the risk level score, taking into account rule type, resource consumption, and historical success rate. Verification rules are arranged in descending order of execution weight to form an initial strategy sequence. A quicksort algorithm is used for efficient reorganization. Rule conflicts in the initial strategy sequence are detected, including resource competition, condition mutual exclusion, and execution order dependencies. Conflict resolution operations are performed, resolving detected conflicts through reordering, condition modification, or rule merging. The resolved strategy sequence is output as an adaptive verification strategy set, containing the rule execution order and configuration parameters. In practice, the execution weight calculation uses a weighted summation model, assigning configurable coefficients to different factors. The initial strategy sequence is generated using a stable sorting algorithm, which maintains the original order of rules with the same weight. Rule conflict detection uses graph theory methods, modeling rule relationships as directed graphs to detect loops. The conflict resolution operation is implemented as a constraint solver, which finds the execution order that satisfies all constraints. It is understandable that the priority scheduling mechanism is a key step in the generation of adaptive verification strategy sets, ensuring that high-priority rules are executed first.

[0042] Table 1: Comparison of Feature Fields and Encoding Methods shows the constituent elements of a risk feature vector. Feature field Data source Encoding Normalization method Exception type code Security event log Integer enumeration (8-bit) One-hot encoding Event severity level Security event log Floating point number (32-bit) Min-max scaling Firmware major version number Firmware metadata collection Unsigned integer (16-bit) Linear scaling Firmware minor version number Firmware metadata collection Unsigned integer (16-bit) Linear scaling Firmware revision number Firmware metadata collection Unsigned integer (16-bit) Linear scaling Developer identification hash Firmware metadata collection Unsigned integer (32-bit) Keep original value In practical implementation, parsing exception type codes requires handling complex exception scenarios, where a single event may correspond to multiple exception types. The system uses a bitmasking mechanism to combine multiple type codes. Event severity level extraction combines static configuration and dynamic adjustment. Static configuration defines the base severity level, while dynamic adjustment corrects the final value based on the event occurrence frequency. Firmware version number decomposition handles non-standard version formats, converting them to standard components through pattern matching and default value processing. The hash calculation of the developer identifier includes salt hardening to prevent hash collision attacks. The memory layout of the feature array considers cache line alignment, optimizing memory access performance. The parameter update mechanism for normalization processing is periodically recalculated to adapt to changes in data distribution. In some embodiments, exception type codes can be associated with response policy templates, which specify the processing flow for specific types. An adaptive adjustment algorithm can be introduced for event severity levels, dynamically scaling according to the environmental threat level. Firmware version number parsing can support version range expressions, handling compatibility check requirements. The developer identifier can verify the digital certificate chain, ensuring the authenticity of the identifier. A verification field can be added to the feature array encoding to detect transmission errors. Normalization can be achieved by using quantile normalization, which reduces the impact of outliers.

[0043] In implementation, the specific formula for calculating execution weights includes multiple weighting terms. The base weight for each verification rule is read from the rule base, and the base weight is set according to the rule type. Resource consumption weights are calculated based on historical performance data, including execution time and memory usage metrics. Historical success rate weights use an exponentially weighted moving average, which gives higher weight to recent results. The final execution weight is obtained by linearly combining these factors, with the coefficients configured by the system administrator. When arranging verification rules in descending order of execution weight, heap sort is chosen as the sorting algorithm, as it maintains good performance even with a large number of rules. A rule dependency graph is established to detect rule conflicts, where nodes represent rules and edges represent execution order constraints. Conflict resolution uses a topological sorting algorithm to address the order requirements in the dependency graph. When outputting the resolved strategy sequence, the system generates an execution plan document, which includes rule triggering conditions and fallback strategies. In implementation, execution weight calculation can integrate machine learning predictions to assess the effectiveness of rules in the current risk scenario. Rule sorting can support multi-objective optimization, balancing execution weights and resource constraints. Conflict detection can monitor rule execution status in real time and dynamically adjust conflict resolution strategies. Conflict resolution can retain multiple alternative solutions, which are activated when the primary solution fails. Optionally, rule dependency depth can be considered in weight calculation, as dependency depth affects weight allocation. Rule sorting can introduce random perturbations to avoid local optima. Conflict detection can visualize rule relationships, providing visual support for administrator decision-making. Conflict resolution can record resolution logs for subsequent analysis and optimization.

[0044] In practical implementation, the risk feature vector generation process needs to work in conjunction with the data preprocessing pipeline. The parser for exception type codes handles log encoding conversion, unifying the representation of different character sets. Outliers are standardized for event severity levels, and Winsorizing is used to prune them. Firmware version number parsing verifies version legitimacy, and version legitimacy checks prevent version number injection attacks. The hash value calculation for the developer identifier uses a cryptographic hash function, such as SHA-256, to ensure collision resistance. The serialization of the feature array adopts a platform-independent format, supporting cross-architecture data transmission. Normalization parameters are stored using version control, which supports parameter rollback. Priority scheduling for verification rule groups is implemented as an independent service, receiving scheduling requests via a message queue. Execution weight calculation uses a parallel computing framework, processing multiple rule weights simultaneously. The rule sorting algorithm optimizes cache locality, reducing cache miss penalties. The conflict detection engine uses a rule relational database, which pre-stores relationships between rules. The conflict resolver applies AI planning technology to generate the optimal execution sequence. In some embodiments, exception type codes can be associated with remediation suggestions, which guide subsequent processing actions. Event severity levels can be weighted across multiple data sources, providing a more comprehensive assessment. Firmware version number parsing can identify special version tags, such as beta and release versions, impacting risk assessment. Developer identifiers can support multi-signature scenarios, requiring the combination of multiple identifiers. Feature arrays can dynamically expand their dimensions to accommodate newly added features. Normalization processing can be implemented as a pluggable module, supporting different normalization algorithms. It is understood that feature extraction and priority scheduling implementations need to consider system real-time requirements, which are met through algorithm optimization and hardware acceleration.

[0045] Example 5: The implementation process of the multi-stage verification process begins with the remote verification agent service receiving the adaptive verification policy set. The remote verification agent service parses the adaptive verification policy set to determine the number of verification stages. The adaptive verification policy set uses XML format to describe the stage division and rule binding relationships. For each verification stage, the system loads the corresponding verification rules and performs firmware attribute checks. The verification rules are dynamically loaded from the policy library into the secure execution environment. The check results of each verification stage are accumulated to generate an overall verification score. The accumulation process uses a weighted summation algorithm to combine stage scores. The overall verification score is compared with a preset threshold to determine firmware loading permissions. The preset threshold is dynamically adjusted according to the security policy. In specific implementation, parsing the adaptive verification policy set uses a DOM parser to traverse the XML document. The DOM parser extracts the number of Phase nodes as the number of verification stages. When loading verification rules, the rule engine retrieves bytecode from the rule library based on the rule identifier. The bytecode is executed by the interpreter. Performing firmware attribute checks involves multiple checkpoints running in parallel. Each checkpoint outputs a boolean result or a numerical score. The accumulated check results use an accumulator register, which maintains its state between stages. Permissions determine the logical comparison between the final score and the threshold register value, which is set by the policy manager. Optionally, the parsing process can verify the digital signature of the adaptive verification policy set, ensuring policy integrity. Loading verification rules supports hot updates, replacing rules without restarting the service. Cumulative results can employ non-linear combinations, utilizing fuzzy logic operations.

[0046] Taking the firmware update scenario of embedded network devices as an example, the adaptive verification strategy set defines a three-stage verification process. The first stage verification rule requires checking the memory distribution characteristics of the firmware image. The system reads the code segment and data segment of the firmware image. The code segment is located through the program header table, and the data segment is analyzed to initialize data blocks. Memory distribution characteristics are calculated, including segment size, alignment attributes, and permission flags. Feature calculation uses an ELF parser to extract segment information. The system verifies whether the memory distribution characteristics conform to predefined security specifications, which require that the code segment is not writable and the data segment is not executable. The second stage verification rule focuses on import table analysis, checking for unauthorized function calls in the firmware image's import table. The import table parser lists all dynamic link symbols. The third stage performs an integrity review, accumulating the results of the first two stages to generate an overall verification score. Loading is allowed when the overall verification score exceeds a threshold; otherwise, the process terminates. In specific implementation, memory mapping is used to read the code segment and data segment, avoiding the copying of large blocks of data. When calculating memory distribution characteristics, the feature extractor calculates segment entropy and overlapping areas. Entropy values ​​detect compressed or encrypted code. Security specifications are verified through a rule engine matching pattern, with the rule engine applying predicate logic to determine compliance. When checking the import table, the symbol resolver verifies the function address range, which must be in the whitelist. The output of the check is formatted as a standard report, which includes pass / fail status and detailed evidence.

[0047] The specific operations of performing firmware attribute checks involve low-level system calls and hardware characteristics. Reading the code and data segments of the firmware image requires the cooperation of the file system driver, which handles block device read requests. Memory distribution characteristics are calculated using geometric analysis methods, which calculate segment boundaries and gap sizes. Verifying memory distribution characteristics involves calling the security policy evaluation module, which applies access control rules. When checking the import table, the dynamic linker interactively resolves external symbols and queries shared library metadata. The output check results are written to the security log, which is managed by the audit subsystem. In specific implementations, the read operation may involve a decompression process, which handles compressed firmware images. Calculating memory distribution characteristics may include fragmentation metrics, which assess memory layout efficiency. The verification process can integrate formal verification tools to prove memory security attributes. Import table checks can detect API hooks, which identify function substitution attacks. The output results may include remediation suggestions to guide users in correcting problems. In some embodiments, code segment reading can verify digital signatures, confirming the trustworthiness of the code source. Memory distribution feature calculations can assess the strength of address space layout randomization, which reflects attack resistance. Security specification verification can include stack protection checks, which detect stack overflow protection mechanisms. Import table checks can statistically analyze system call usage frequency, identifying anomalous behavior. Outputting check results can generate visualizations, helping analysts understand the status.

[0048] The logic for determining firmware loading permissions based on the verification result is implemented using a state machine model. When the verification result is successful, the remote verification agent service issues a loading token, which contains an encrypted timestamp and permission declaration. Firmware loading is allowed to continue, and the system returns control to the loader program. When the verification result fails, the remote verification agent service issues an abort signal, triggering a global error handling routine. The firmware loading process is terminated, allocated resources are cleaned up, and the failure event is logged. In practice, issuing the loading token requires a cryptographic signature operation, using the device's unique key to sign the token content. When loading is allowed to continue, the system verifies the token's validity before transferring execution control. The abort signal is issued through a system interrupt mechanism, ensuring timely response. The termination process includes rolling back completed initialization operations, maintaining system consistency. Optionally, the loading token can have an expiration date to prevent token reuse. Allowing loading can be done in stages, gradually granting permissions. The abort signal can include an error code, distinguishing the cause of failure. The termination process can attempt a safe recovery, reverting to an older firmware version. It is understandable that the permission determination mechanism is the last line of defense for secure firmware loading, and the permission determination mechanism must have high reliability and tamper resistance.

[0049] In practical implementation, the method for determining the number of verification stages considers the balance of strategy complexity. Simple firmware may only require two verification stages, while complex system firmware may require five or more stages. When loading verification rules, the rule loader verifies rule signatures and compatibility to prevent malicious rule injection. The timing of firmware attribute checks is synchronized with the system initialization process to avoid introducing additional delays. The method for accumulating check results supports weight configuration, with scores from critical stages having higher weights. When comparing the overall verification score with a threshold, the threshold can be dynamically adjusted according to the operating environment, with stricter thresholds used in high-risk environments. In practical implementation, the number of stages can be determined based on firmware type heuristic rules, which identify firmware categories and adjust the number of stages accordingly. Rule loading can implement a lazy loading strategy, loading rules on demand to reduce memory consumption. Attribute checks can be executed in parallel for independent check items, utilizing multi-core processors for acceleration. The cumulative result algorithm can exclude abnormal scores, which are filtered using statistical methods. Threshold adjustment can be driven by a machine learning model, which optimizes the threshold based on historical data. In some embodiments, stage division can support nested stages, enabling hierarchical verification. Rule loading can cache frequently used rules, improving loading speed. Attribute checks can be performed incrementally, checking only the changed parts. Cumulative results can include confidence assessments, which measure the reliability of the scores. Threshold comparisons can introduce hysteresis intervals to prevent state oscillations.

[0050] Taking smart gateway firmware loading as an example, the adaptive verification strategy set defines three stages: memory layout verification, code integrity verification, and runtime behavior prediction. The first stage loads memory verification rules, reads the firmware image's code segments to calculate segment size and entry point addresses, and verifies whether the code segments meet the 4KB alignment requirement. The second stage loads code verification rules, calculates the cryptographic hash value of the firmware image, and compares it with a whitelist database. The third stage loads behavior prediction rules, analyzes the firmware import function call graph, and detects the presence of high-risk system calls. After accumulating scores from the three stages, a total score of 85 exceeds the threshold of 80, and the system issues a loading token. In specific implementation, code segments are read using direct memory access, which bypasses the CPU cache to obtain the latest data. Memory distribution characteristics are calculated, including segment relocation analysis, which detects address-independent code. Security specifications are verified by checking segment permission combinations; the code segment must have read and execute permissions. When checking the import table, the function call analyzer constructs a call tree, which detects unauthorized kernel calls. The check results are output to generate a verification certificate, which is attached to the firmware image for subsequent use. Optionally, memory reads can employ a sparse read approach, loading only the necessary segments of data. Distribution feature calculations can include spatial locality metrics, which optimize cache performance. Security specification verification can check for stack execution protection, preventing code injection. Import table checks can verify function parameter types, detecting type obfuscation vulnerabilities. Output results can support multiple serialization formats.

[0051] In practical implementation, the remote verification agent service parses the adaptive verification strategy set, including syntax parsing and semantic analysis. Syntax parsing handles the lexical structure of the strategy file, while semantic analysis verifies the completeness of the verification stage definitions. After determining the number of verification stages, the system creates a stage control block array, which manages the execution status of each stage. For each verification stage, loading verification rules involves linking external symbols, and linking external symbols resolves rule dependencies. Executing firmware attribute checks may trigger hardware-assisted verification, which, such as TXT technology, provides an isolated environment. Cumulative check results use fixed-point arithmetic to avoid floating-point errors. Comparing the overall verification score with a preset threshold uses atomic comparison instructions to prevent concurrent modifications. In practical implementation, syntax parsing can handle strategy template instantiation, which generates specific strategies. Stage control blocks can include stage timeout settings to prevent deadlocks. Rule loading can verify rule version compatibility, checking API consistency. Attribute checks can use processor debugging functions to set hardware breakpoints. Cumulative results can be implemented as a pipelined structure, with overlapping computation and transmission. Threshold comparisons can generate interrupt signals, which notify the loading controller of the decision result. Optionally, policy parsing can support conditional compilation, which selects policy fragments based on the environment. Stage control can implement a checkpoint mechanism, which supports stage rollback. Rule loading can pre-compile rule code, reducing interpretation overhead. Attribute inspection can sample the execution code path to detect runtime exceptions. Accumulated results can be stored encrypted to prevent tampering. Threshold comparisons can make multi-threshold hierarchical decisions, enabling hierarchical authorization. It is understandable that the design of a multi-stage verification process needs to strike a balance between security and performance; increasing the number of stages improves security but increases verification time.

[0052] See Figure 5This chart illustrates two key performance indicators in the multi-stage firmware verification process: completion time (seconds) and detection rate (%). For completion time (blue bar chart, left vertical axis): the runtime behavior prediction stage takes the longest (1.5 seconds); the import table analysis stage takes the shortest (0.6 seconds); the memory layout verification, code integrity verification, and security specification verification stages take 0.8 seconds, 1.2 seconds, and 0.9 seconds, respectively. For detection rate (orange line chart, right vertical axis): the code integrity verification stage has the highest detection rate (98%); the runtime behavior prediction stage has the lowest (68%); the memory layout verification, import table analysis, and security specification verification stages have detection rates of 85%, 76%, and 92%, respectively. Overall, each verification stage exhibits a certain trade-off between detection rate and completion time. For example, code integrity verification has a high detection rate but a longer time, while import table analysis is short but has a lower detection rate. This difference in indicators provides data support for optimizing the multi-stage verification strategy for firmware loading protection, allowing for targeted adjustments between security and verification efficiency.

[0053] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A firmware loading protection method based on a dynamic security protocol, characterized in that, The method includes: Initiate the firmware loading process and invoke the dynamic verification protocol to perform an integrity scan on the firmware image; When an integrity scan detects an anomaly, the security event logging mechanism is triggered, generating a security event log and storing it in the isolation storage, while simultaneously activating the remote authentication agent service; The remote authentication agent service takes over control and reads the security event logs and firmware metadata set from the isolated storage; Security event logs and firmware metadata sets are transmitted to a distributed verification network via an encrypted tunnel; After receiving the security event logs and firmware metadata set, the distributed verification network runs the risk assessment model and outputs an adaptive verification strategy set. The remote verification agent service receives an adaptive verification policy set, executes a multi-stage verification process, and determines firmware loading permissions based on the verification results.

2. The firmware loading protection method based on dynamic security protocol as described in claim 1, characterized in that, The process of invoking the dynamic verification protocol to perform an integrity scan of the firmware image includes: Load the binary data stream of the firmware image and use a hash algorithm to calculate the hash digest value of the firmware image; Retrieve a pre-stored standard hash value from the secure storage area, the standard hash value corresponding to a valid version of the firmware image; The calculated hash digest value is compared with the pre-stored standard hash value to obtain the integrity verification result; An integrity scan is considered to have detected an anomaly when the integrity check result indicates that the hash digest value does not match the standard hash value.

3. The firmware loading protection method based on dynamic security protocol as described in claim 2, characterized in that, The generation of security event logs includes: When the integrity verification result indicates an anomaly, capture the firmware image's loading timestamp and runtime environment parameters; By combining the integrity verification results, loading timestamps, and runtime environment parameters, a security event log is constructed. The security event records are digitally signed to generate a security event log, which is then written to an isolated storage device.

4. The firmware loading protection method based on dynamic security protocol as described in claim 1, characterized in that, The process of reading the security event logs and firmware metadata set from the isolated storage includes: The remote authentication agent service sends a read request to the isolated storage, the read request containing an access token; After verifying the validity of the access token, the isolated storage returns a security event log and a set of firmware metadata. The firmware metadata set includes the firmware version number, developer identifier, and mount address range.

5. The firmware loading protection method based on dynamic security protocol as described in claim 1, characterized in that, The operational risk assessment model outputs an adaptive verification strategy set including: Parse security event logs and firmware metadata sets to extract risk feature vectors; The risk feature vector is input into a pre-trained risk classifier to obtain a risk level score; Based on the risk level score, query the strategy template library and match the corresponding verification rule group; Prioritize the verification rule groups to generate an adaptive verification strategy set.

6. The firmware loading protection method based on dynamic security protocol as described in claim 5, characterized in that, The extracted risk feature vector includes: Parse the exception type code and event severity level from the security event log; Retrieve the firmware version number and developer identifier from the firmware metadata collection; Encode the exception type code, event severity level, firmware version number, and developer identifier into a feature array; The feature array is normalized to generate a risk feature vector.

7. The firmware loading protection method based on dynamic security protocol as described in claim 5, characterized in that, The priority scheduling of the verification rule group includes: The execution weight of each verification rule is calculated based on the risk level score; The verification rules are arranged in descending order of execution weight to form an initial strategy sequence; Detect rule conflicts in the initial policy sequence, perform conflict resolution operations, and output the resolved policy sequence as an adaptive verification policy set.

8. The firmware loading protection method based on dynamic security protocol as described in claim 1, characterized in that, The multi-stage verification process includes: The remote verification agent service parses the adaptive verification strategy set and determines the number of verification stages. For each verification stage, load the corresponding verification rules and perform firmware attribute checks; The results of each verification stage are accumulated to generate an overall verification score. The overall verification score is compared with a preset threshold to determine the firmware loading permission.

9. The firmware loading protection method based on dynamic security protocol as described in claim 8, characterized in that, The firmware attribute check includes: Read the code and data segments of the firmware image and calculate the memory distribution characteristics; Verify whether the memory distribution characteristics conform to the predefined security specifications, check whether there are unauthorized function calls in the import table of the firmware image, and output the check results.

10. The firmware loading protection method based on dynamic security protocol as described in claim 1, characterized in that, The process of determining firmware loading permissions based on verification results includes: When the verification result is successful, the remote verification agent service issues a load token, allowing firmware loading to continue; When the verification result fails, the remote verification agent service sends a stop signal to terminate the firmware loading process.

Images