Trusted starting method and system for credential mobile terminal

Abstract

The invention relates to the technical field of creative mobile terminals, in particular to a trusted startup method and system for a creative mobile terminal, and the method comprises the steps: carrying out hierarchical verification and state monitoring on a hardware trust root module, security startup firmware and an operating system kernel, extracting multi-dimensional security features, and constructing a system security feature vector; secondly, establishing a trust chain component dependency graph, and generating a trusted startup sequence with the minimum security risk through constraint optimization; in combination with the trusted startup sequence and the feature vector, intelligently identifying startup threats and dividing risk levels to form a layered security protection strategy; and dynamically adjusting a protection strategy and allocating a resource weight, loading and dividing the trusted component into a high-security verification area and a basic verification area for block verification, and outputting a trusted startup execution result. According to the method, full-link trusted measurement, intelligent risk management and control and resource optimization scheduling in the starting process are realized, and the safety and starting efficiency of the credential terminal are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of information technology innovation mobile terminal technology, and in particular to a trusted boot method and system for information technology innovation mobile terminals. Background Technology

[0002] With the deepening of the information technology application innovation (IT innovation) strategy, IT innovation mobile terminals, as important carriers of critical information infrastructure and industry informatization, face increasingly severe challenges to their security and independent controllability. The boot process of traditional mobile terminals is generally plagued by security vulnerabilities such as broken trust chains, firmware tampering, and malicious code injection. This is especially true in critical stages such as the bootloader, secure boot firmware, and operating system kernel loading; once attacked, the entire system becomes untrusted, leading to sensitive data leakage or device malfunction. Although existing technologies have proposed boot protection mechanisms based on trusted computing architectures, such as the Trusted Boot Chain proposed by the TCG (Trusted Computing Group), these methods still have significant limitations in the IT innovation scenario: on the one hand, most solutions rely on general security models and do not fully consider the technological ecosystem characteristics of domestic processors, domestic operating systems, and domestic cryptographic algorithms; on the other hand, existing mechanisms mostly adopt static verification processes, lacking the ability to dynamically monitor the security status and conduct collaborative risk assessments of multi-layered components such as the hardware root of trust, boot firmware, and operating system kernel, making it difficult to cope with boot-time attacks caused by advanced persistent threats (APTs) and zero-day vulnerabilities.

[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this invention is to provide a trusted boot method and system for domestically developed mobile terminals, aiming to solve the technical problems faced by existing trusted boot technologies in domestically developed mobile terminals, such as static and rigid boot chain verification, insufficient dynamic perception of security risks, difficulty in balancing verification efficiency and security under resource constraints, and lack of adaptation to domestic software and hardware environments and differentiated layered protection.

[0005] To achieve the above objectives, the present invention provides a trusted boot method for a domestically developed mobile terminal, the method comprising: Hierarchical sequential verification and security status monitoring are performed on the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal to obtain a multi-dimensional security feature set and construct a system security feature vector. Construct a trust chain component dependency graph and perform constraint optimization to minimize security risks to obtain a trusted startup sequence; Based on the trusted startup sequence and the system security feature vector, potential threats in the startup process are intelligently identified and risk-classified to obtain a layered security protection strategy. The layered security protection strategy is dynamically adjusted and resource allocation weights are calculated to obtain the startup protection scheme. The trusted component loading process is divided into a high-security verification area and a basic verification area for block verification to obtain the trusted startup execution result.

[0006] Optionally, the hierarchical sequential verification and security status monitoring of the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal, to obtain a multi-dimensional security feature set, and to construct a system security feature vector, includes: A hierarchical sequential verification is performed on the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal to obtain the verification execution sequence. Based on the verification execution sequence, the hardware trust root state, firmware integrity measurement value and kernel boot parameters are obtained, and a system security state matrix is ​​constructed. The historical boot log is divided into time windows, and the security event occurrence rate, verification failure number and threat type distribution are statistically analyzed in each first time window to obtain a security behavior statistical matrix. The system security state matrix and the security behavior statistics matrix are concatenated to obtain a time-series security feature sequence. Based on the time-series security feature sequence, the system security situation and threat evolution trend are modeled to obtain a multi-dimensional security feature set. Based on the multidimensional security feature set, hardware features, firmware features, and software features are extracted respectively, and a system security feature vector is constructed.

[0007] Optionally, the step of extracting hardware features, firmware features, and software features based on the multi-dimensional security feature set, and constructing a system security feature vector, includes: The multidimensional security feature set is input into the bottom-level security feature extraction network for feature map calculation to obtain the basic hardware feature matrix. The bottom-level security feature extraction network contains three convolutional layers and two fully connected layers. Each convolutional layer uses the ReLU activation function and a max pooling layer. The basic hardware feature matrix is ​​input into the mid-layer security feature extraction network for residual calculation to obtain the firmware integrity feature matrix. The mid-layer security feature extraction network uses four residual blocks, each containing two convolutional layers and one skip connection, and a BatchNorm layer is added between the residual blocks. The firmware integrity feature matrix is ​​input into the high-level security feature extraction network for threat correlation analysis to obtain the threat scenario feature matrix. The high-level security feature extraction network uses a transformer encoder structure and includes six multi-head self-attention layers and feedforward neural network layers. The system security feature vector is obtained by weighted fusion and normalization of the basic hardware feature matrix, the firmware integrity feature matrix, and the threat scenario feature matrix.

[0008] Optionally, the construction of the trust chain component dependency graph and the execution of constraint optimization to minimize security risks to obtain a trusted startup sequence include: A trust chain component dependency graph is constructed based on the startup dependency relationship between trust chain components. The edge weights of the trust chain component dependency graph represent the verification latency between components, and the node weights represent the security risk level of the components. Based on the trust chain component dependency graph, security risk constraints are set, including: the overall security risk does not exceed a preset threshold, the verification time of any component is earlier than the start time of its dependent components, and the verification time interval between adjacent components is not less than the minimum security period, thus obtaining a set of constraints. Based on the set of constraints, a graph neural network is used to calculate the dependency graph of the trust chain components to obtain the component security feature matrix. The component security feature matrix is ​​then used to determine the verification order and time allocation of the components to obtain an initial verification scheme. The initial verification scheme is constrained and verified, the actual security risks and verification costs of each component are calculated, and the optimization problem of minimizing security risks is solved based on the Lagrange multiplier method to obtain the optimal verification scheme. Based on the optimal verification scheme, the verification priority and execution order of the components that meet the sequential verification requirements are determined to obtain a trusted startup sequence.

[0009] Optionally, the step of intelligently identifying and risk-classifying potential threats during the startup process based on the trusted startup sequence and the system security feature vector to obtain a layered security protection strategy includes: The trusted startup sequence and the system security feature vector are concatenated and linearly transformed to obtain a security input feature sequence. The security input feature sequence is then input into the forward LSTM layer and the backward LSTM layer respectively to obtain a bidirectional security feature vector. Temporal attention calculation is performed on the bidirectional security feature vector to obtain a security context feature vector. Threat correlation analysis is performed based on the security context feature vector, and weighted by combining it with historical threat data to obtain a threat prediction sequence. Based on the threat prediction sequence, risk scores and rankings are performed on each threat type to obtain a security protection priority list. Resource quotas are then allocated to each type of security measure based on the security protection priority list to obtain a layered security protection strategy.

[0010] Optionally, the dynamic security adjustment and resource allocation weight calculation of the layered security protection strategy to obtain the startup protection scheme, and the division of the trusted component loading process into a high-security verification area and a basic verification area for block verification to obtain the trusted startup execution result, includes: The security tasks in the layered security protection strategy are reordered to obtain an initial security scheduling sequence; The initial security scheduling sequence is divided into multiple second time windows, and the system security status within each second time window is dynamically monitored to obtain a security status sequence. The comprehensive security weight within each second time window is calculated based on the security state sequence, and the execution time of the security task is adjusted according to the comprehensive security weight to obtain a task scheduling scheme. A resource usage limit is set for each task in the task scheduling scheme, and the security resource allocation rate is controlled by the token bucket algorithm to obtain the startup protection scheme. According to the startup protection scheme, the trusted component loading process is divided into a high-security verification area and a basic verification area, and block verification is performed through domestic hardware encryption modules and parallel verification technology to obtain trusted startup execution results.

[0011] Optionally, the process of dividing the trusted component loading process into a high-security verification area and a basic verification area according to the startup protection scheme, and performing block verification through domestic hardware encryption modules and parallel verification technology to obtain a trusted startup execution result, includes: The trusted components in the startup protection scheme are divided into regions according to their security risk levels. Components with security risks higher than the threshold are assigned to the high-security verification zone, and components with security risks lower than the threshold are assigned to the basic verification zone, thus obtaining a component partitioning scheme. The components to be verified in the component partitioning scheme are divided into blocks. Each component is divided into several verification blocks according to a preset block size, and a unique identifier is assigned to each verification block to obtain a verification block sequence. A two-layer verification structure is constructed based on the verification block sequence. A fast signature verification module based on domestic cryptographic algorithms is set in the high-security verification area, and a lightweight hash verification module is set in the basic verification area. A collaborative verification channel between the two areas is established to obtain the verification management unit. Based on the identifier of the verification block and the verification management unit, verification resources are allocated, and different verification blocks of the same component are verified in parallel through the domestic hardware encryption module, and the verification status is recorded in real time to obtain a verification progress table. Based on the verification schedule, the verified blocks are subjected to integrity checks and result aggregation. The verified blocks that pass the checks are integrated into trusted components to obtain the verification integration result. The verification integration results are recorded in the trusted startup log, including verification block location information, security area identifier and verification timestamp. The startup completion status is returned through the domestic trusted computing chip to obtain the trusted startup execution result.

[0012] Furthermore, to achieve the above objectives, the present invention also provides a trusted boot system for domestically developed mobile terminals, the system comprising: The feature construction module is used to perform hierarchical sequential verification and security status monitoring of the hardware root of trust module, secure boot firmware and operating system kernel in the domestically developed mobile terminal, to obtain a multi-dimensional security feature set and construct a system security feature vector. The graph optimization module is used to construct the dependency graph of the trust chain components and perform constraint optimization to minimize security risks, thereby obtaining a trusted startup sequence. The intelligent risk control module is used to intelligently identify and classify potential threats in the startup process based on the trusted startup sequence and the system security feature vector, and obtain a layered security protection strategy. The dynamic verification module is used to dynamically adjust the layered security protection strategy and calculate the resource allocation weight to obtain the startup protection scheme. It also divides the trusted component loading process into a high-security verification area and a basic verification area for block verification to obtain the trusted startup execution result.

[0013] Furthermore, to achieve the above objectives, the present invention also provides a trusted boot device for a domestically developed mobile terminal, the device comprising: a memory, a processor, and a trusted boot program for the domestically developed mobile terminal stored in the memory and executable on the processor, the trusted boot program for the domestically developed mobile terminal being configured to implement the steps of the trusted boot method for the domestically developed mobile terminal as described in any of the above descriptions.

[0014] In addition, to achieve the above objectives, the present invention also provides a medium storing a trusted boot program for a domestically developed mobile terminal, wherein when the trusted boot program for the domestically developed mobile terminal is executed by a processor, the trusted boot method for the domestically developed mobile terminal as described above is implemented.

[0015] This invention provides a trusted boot method for domestically developed mobile terminals. The method constructs a multi-dimensional security feature set and system security feature vector covering hardware, firmware, and software layers through hierarchical sequential verification and security status monitoring. This enables comprehensive perception and quantitative characterization of the security status of key components during the boot process. By constructing a trust chain component dependency graph and performing constraint optimization to minimize security risks, the method scientifically plans the verification sequence and time scheduling, significantly improving the security and execution efficiency of the trust chain establishment process. Combining the trusted boot sequence and system security feature vector, intelligent identification technology is used to accurately predict and classify potential threats during the boot phase, generating differentiated layered security protection strategies and enhancing the system's proactive defense capabilities against unknown attacks and dynamic threats. Furthermore, by dynamically adjusting the protection strategy and allocating resource weights, and dividing the loading of trusted components into a high-security verification area and a basic verification area for block-based parallel verification, the method balances strong security protection for high-risk components with lightweight and efficient processing of low-risk components, effectively optimizing resource utilization and boot performance while ensuring overall boot security. This invention is fully compatible with domestic cryptographic algorithms, domestic hardware encryption modules, and trusted computing chips in the domestic IT innovation environment. It supports an independent and controllable secure boot loop and significantly improves the boot reliability, security controllability, and intelligent protection level of domestic IT innovation mobile terminals in complex threat scenarios. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an embodiment of the trusted startup method for a mobile terminal based on domestic IT innovation according to the present invention.

[0017] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0018] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0019] Reference Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the trusted boot method for a domestically developed mobile terminal according to the present invention. An embodiment of the trusted boot method for a domestically developed mobile terminal according to the present invention is presented.

[0020] In one embodiment, the trusted boot method of the domestically developed mobile terminal includes: Step S100 involves performing hierarchical sequential verification and security status monitoring on the hardware trust root module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal to obtain a multi-dimensional security feature set and construct a system security feature vector.

[0021] The domestically developed mobile terminal can be a mobile computing device built upon an ecosystem of information technology application innovation (IT innovation) based on domestically produced processors, operating systems, cryptographic algorithms, and trusted computing chips. It can serve as a crucial carrier for critical information infrastructure and industry informatization, supporting high-security business applications. For example, the domestically developed mobile terminal can include, but is not limited to, one or more of the following: government-specific tablets, financial security phones, and dedicated secure handheld terminals. The hardware root of trust module can be an immutable hardware unit built into the domestically developed mobile terminal, providing an initial trust anchor and key storage capability. It can be used to provide an initial trust measurement benchmark for the entire boot process, preventing firmware-level tampering. In this embodiment, the hardware root of trust module can be implemented based on a domestically produced trusted computing chip, using a physically unclonable function (PUF) or fuse technology to solidify the root key. Furthermore, the hardware root of trust module can provide measurement values ​​and verification keys to the secure boot firmware, and its state is incorporated into the system security feature vector.

[0022] Secure boot firmware can be a low-level bootloader running before the operating system loads. It is responsible for verifying the integrity of subsequent components and establishing a trust chain. It can be used to perform integrity checks on the operating system kernel, blocking malicious code injection paths. In an exemplary embodiment, the secure boot firmware can be signed using a domestically developed cryptographic algorithm and stored in a read-only or protected storage area. Furthermore, the secure boot firmware can rely on a key provided by the hardware trust root module for self-verification and to measure the operating system kernel; its security state participates in constructing a multi-dimensional security feature set. The operating system kernel can be the core software layer of a domestically developed mobile terminal, managing hardware resources and providing basic service interfaces. It can be used as the foundational platform for upper-layer applications, and its integrity determines the overall trustworthiness of the system. In a specific embodiment, the operating system kernel can be signed using the national cryptographic SM2 / SM3 algorithm and must be verified by the secure boot firmware before loading. Furthermore, the operating system kernel can be verified by the secure boot firmware, and its runtime behavior characteristics are included in the scope of security state monitoring.

[0023] A multidimensional security feature set can be a collection of security attributes from multiple dimensions collected at the hardware, firmware, and software levels. It can provide raw data support for the system security feature vector, enabling a structured expression of the security state. In this embodiment, the multidimensional security feature set can obtain the hash values, runtime behavior indicators, and abnormal event logs of each component through hierarchical sequential verification and security state monitoring. The system security feature vector can be a numerical vector formed by standardizing and normalizing the multidimensional security feature set. It can be used to support machine learning model input, achieving quantitative representation and intelligent analysis of the security state. Furthermore, the system security feature vector can undergo feature engineering processing on the multidimensional security feature set, mapping it to a fixed-dimensional real-number vector. For example, the system security feature vector can be used together with a trusted startup sequence as input for intelligent identification, used for threat prediction and risk classification.

[0024] Step S200: Construct a trust chain component dependency graph and perform constraint optimization to minimize security risks to obtain a trusted startup sequence.

[0025] The trust chain component dependency graph can be a directed graph structure describing the verification dependencies between components during startup. It can be used to explicitly model the trust transmission paths between components, providing a topological basis for optimizing the verification order. In this embodiment, the trust chain component dependency graph can construct nodes and edges based on the startup process of the hardware trust root module, secure boot firmware, and operating system kernel. Minimizing security risk constraint optimization can be a scheduling optimization process aimed at reducing overall startup risk while satisfying security constraints. It can be used to generate a verification scheduling scheme that balances security and efficiency. In an exemplary embodiment, minimizing security risk constraint optimization can use component verification order, resource consumption, historical attack probability, etc., as variables to construct an integer programming or heuristic optimization model. Furthermore, minimizing security risk constraint optimization can be applied to the trust chain component dependency graph to output a trusted startup sequence. The trusted startup sequence can be the optimized component verification and loading execution order, which can be used to guide the verification timing of each component during startup, avoiding trust chain breaks due to improper order. In this embodiment, the trusted startup sequence can be obtained by solving the minimizing security risk constraint optimization on the trust chain component dependency graph. Furthermore, the trusted boot sequence can be input into the intelligent identification module along with the system security feature vector for dynamic threat assessment.

[0026] Step S300: Based on the trusted boot sequence and system security feature vector, intelligently identify and classify potential threats in the boot process to obtain a layered security protection strategy.

[0027] Potential threats during the startup process can be malicious behaviors or abnormal states that may occur during the startup phase, including firmware tampering and kernel hijacking. These can be used as targets for intelligent identification, driving risk grading and protection strategy generation. Intelligent identification can be a technology based on machine learning or rule engines to analyze system security feature vectors to identify abnormal patterns, enabling early warning of unknown attacks and zero-day vulnerabilities. Risk grading can classify identified potential threats according to their severity, scope of impact, and probability of occurrence, providing a basis for decision-making in layered security protection strategies. Layered security protection strategies can be a set of differentiated response measures tailored to different risk levels, enabling precise defense and avoiding performance degradation due to over-protection. In a specific embodiment, layered security protection strategies can be mapped from risk grading results to a predefined policy library or dynamically synthesized through a policy generation engine. Furthermore, layered security protection strategies can accept dynamic security adjustments and resource allocation weight calculations to output startup protection schemes.

[0028] Step S400: Dynamically adjust the layered security protection strategy and calculate the resource allocation weight to obtain the startup protection scheme. Divide the trusted component loading process into a high-security verification area and a basic verification area for block verification to obtain the trusted startup execution result.

[0029] Dynamic security adjustment can be a process of online correction of protection strategies based on real-time changes in security status, which can be used to improve the system's adaptability to dynamic threats. In this embodiment, dynamic security adjustment can trigger policy update logic based on feedback mechanisms (such as newly discovered abnormal behavior). Furthermore, dynamic security adjustment can be applied to layered security protection strategies, working in conjunction with resource allocation weight calculation to output a startup protection scheme. Resource allocation weight calculation can dynamically allocate weight values ​​for resources such as computing, storage, and time based on component risk levels and system load conditions, which can be used to optimize resource utilization efficiency in the verification process. In an exemplary embodiment, resource allocation weight calculation can employ a weighted scoring model, comprehensively considering factors such as risk level, component criticality, and historical resource consumption. Furthermore, resource allocation weight calculation can work in conjunction with dynamic security adjustment on layered security protection strategies to generate a startup protection scheme.

[0030] The startup protection scheme can be a complete startup security execution plan including elements such as verification sequence, resource allocation, and response actions, which can be used to guide the specific implementation of the trusted component loading process. In this embodiment, the startup protection scheme can be generated jointly by dynamic security adjustment and resource allocation weight calculation. Furthermore, the startup protection scheme can drive the division and block-based verification execution of the high-security verification area and the basic verification area. The trusted component loading process can be the process of loading verified components into memory and executing them according to a trusted startup sequence, which can be used to complete the trusted transition from firmware to operating system. Furthermore, the trusted component loading process can be divided into a high-security verification area and a basic verification area, and undergo block-based verification.

[0031] A high-security verification area can be a verification region used to load high-risk or critical components, implementing strong verification mechanisms to ensure the absolute trustworthiness of core components and prevent the penetration of advanced persistent threats. For example, a high-security verification area may include, but is not limited to, one or more of the following: kernel loading area, driver verification area, and security service initialization area. A basic verification area can be a verification region used to load low-risk or non-critical components, implementing lightweight verification mechanisms to reduce verification overhead and improve startup speed. For example, a basic verification area may include, but is not limited to, one or more of the following: user space initialization area, general service loading area, and peripheral configuration area.

[0032] Block verification can divide the trusted component loading process into multiple blocks according to security level and execute verification in parallel. It can be used to achieve a balance between security and efficiency and supports parallel processing.

[0033] The trusted startup execution result can be a system startup status report generated after all verifications and loading are completed. This report can be used to identify whether a complete trust chain has been successfully established during the startup, and can be used by upper-layer applications or remote management platforms. Dynamic security adjustments and resource allocation weight calculations for layered security protection strategies can be performed by combining the current system load and the latest security status to adjust strategy parameters and calculate the resource weights of each verification task. Furthermore, this operation can be achieved through feedback control: if the high-security verification area queue is congested, the resource weight of the basic verification area is temporarily reduced, thereby allowing the protection strategy to adapt to changes in the runtime environment and optimize resource usage.

[0034] In its implementation, when a domestically developed tablet computer boots up, the hardware root of trust module in the domestically produced trusted computing chip first performs a self-test and outputs initial metrics. Then, the secure boot firmware uses the SM2 public key to verify its integrity and performs an SM3 hash comparison of the operating system kernel image, while simultaneously monitoring the CPU abnormal instruction count. The collected multi-dimensional security features (including metrics, verification time, and abnormal counts) are constructed into a system security feature vector. The system performs constraint optimization based on a preset dependency graph, determining the order of verifying critical kernel drivers before loading user services. The intelligent identification module combines this sequence with the feature vector to detect a driver's behavior deviating from the baseline, classifying it as medium risk. A layered strategy triggers secondary verification of the driver and restricts its permissions. The dynamic adjustment module allocates more CPU resources to the high-security verification area based on sufficient battery power. Finally, the kernel completes strong verification in the high-security verification area, user services are quickly loaded in the basic verification area, and the system generates a trusted boot report containing all metric records for subsequent remote auditing.

[0035] In one embodiment, hierarchical sequential verification and security status monitoring are performed on the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal to obtain a multi-dimensional security feature set, and a system security feature vector is constructed, including: A hierarchical sequential verification is performed on the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal to obtain the verification execution sequence. Hierarchical sequential verification can be a process of verifying the integrity and status of key startup components according to component dependency hierarchy and security priority. This ensures the trust chain is established correctly level by level, preventing skipping of critical verification steps. In this embodiment, hierarchical sequential verification can determine the execution order based on the dependencies between the hardware root of trust, secure boot firmware, and operating system kernel. Furthermore, hierarchical sequential verification can output a verification execution sequence, providing a timing basis for collecting data for the system security state matrix. For example, hierarchical sequential verification may include first verifying the physical existence and key consistency of the hardware root of trust, then verifying the firmware SM3 hash, and finally verifying the kernel SM2 signature; or unlocking the loading permission of the next level component only after each level of verification is passed, forming a mandatory dependency chain. The verification execution sequence can be a record of the component verification operation sequence generated by hierarchical sequential verification, which can be used as a time anchor for collecting security state data, ensuring alignment between feature collection and verification actions. In an exemplary embodiment, the verification execution sequence can be implemented by generating a timestamped list of verification events; or by constructing a verification task queue and recording the execution completion order.

[0036] Based on the verification execution sequence, the hardware trust root state, firmware integrity measurement value and kernel boot parameters are obtained, and a system security state matrix is ​​constructed. The historical boot log is divided into time windows, and the security event occurrence rate, verification failure number and threat type distribution are statistically analyzed in each first time window to obtain a security behavior statistical matrix. The hardware root of trust state can be the set of operating states and security attributes of the hardware root of trust module at the verification time. It can be used to reflect whether the root of trust is in the expected security state and is direct evidence of the reliability of the starting point of the trust chain. In a specific embodiment, the hardware root of trust state can be read from the trusted computing chip register to obtain physical state, key validity, anti-tampering flags, etc. Firmware integrity measurement value can be a cryptographic hash value or signature verification result calculated from the secure boot firmware content. It can be used to determine whether the firmware has been tampered with or replaced. In this embodiment, the firmware integrity measurement value can be obtained by calculating the hash of the firmware image using the national cryptographic SM3 algorithm and comparing it with a pre-stored benchmark value. Kernel boot parameters can be a set of configuration and boot parameters passed when the operating system kernel is loaded. They can be used to identify potential risk behaviors such as abnormal boot options (such as disabling security mechanisms or loading debug modules). For example, kernel boot parameters can be obtained by extracting parameter strings from the boot command line or device tree and parsing them. The system security state matrix can be a structured matrix composed of the hardware root of trust state, firmware integrity measurement value, kernel boot parameters, etc. collected during the current boot process. It can be used to uniformly express the multi-dimensional security snapshot of a single boot and support subsequent feature engineering. In one exemplary embodiment, the system security state matrix can be indexed by the verification execution sequence as rows and each security indicator as a column, filled with real-time collected values.

[0037] Historical startup logs can be security events, verification results, and system behavior logs recorded during each startup of a domestically developed mobile terminal. They can provide a long-term behavioral baseline and identify abnormal trends deviating from normal patterns. A time window can be an analysis unit divided from historical startup logs by a fixed time span. It can be used to achieve partial aggregation of time-series data, facilitating the capture of phased changes in the security posture. The first time window can be any specific window instance within the time window division and can be used as the basic unit for statistical security behavior indicators. The security event occurrence rate can be the frequency of security alarms occurring per unit number of startups within a specified time window, and can be used to quantify the overall security stability of the system. In a specific embodiment, the security event occurrence rate can be obtained by dividing the total number of security events within the statistical window by the total number of startups.

[0038] The number of verification failures can be the cumulative number of times a component fails verification within a time window, reflecting the frequency of potential attack attempts or system configuration errors. The threat type distribution can be the proportion of various security threats (such as firmware tampering and kernel hijacking) occurring within a time window, revealing attacker preferences and the direction of attack surface evolution. In this embodiment, the threat type distribution can be obtained by classifying and counting security events according to predefined threat categories and then normalizing the results. The security behavior statistics matrix can be a matrix composed of indicators such as the occurrence rate of security events, the number of verification failures, and the threat type distribution within multiple time windows, used to characterize the long-term security behavior patterns of the system and support trend modeling. For example, the security behavior statistics matrix can be structured with time windows as rows and statistical indicators as columns, forming a time-series statistical table.

[0039] Obtaining the hardware trust root state, firmware integrity measurements, and kernel boot parameters based on the verification execution sequence can be achieved by triggering data collection at the corresponding verification node, ensuring that the metrics are synchronized with the verification actions. Furthermore, this operation can be implemented by immediately reading the TPM register state after hardware verification, caching its hash value after firmware verification, and parsing the boot parameters before kernel loading; or by synchronously collecting the three types of metrics in the verification hook function through a callback mechanism, thereby ensuring the timeliness and contextual consistency of the security status data.

[0040] Constructing the system security status matrix can be achieved by organizing the three types of collected indicators into a matrix structure according to a predefined format. Furthermore, this operation can be implemented by constructing a two-dimensional matrix with components as rows and indicator types as columns, or by using sparse matrix storage to record only non-default value fields, thus providing a structured representation of a single startup's security snapshot. Obtaining the security behavior statistics matrix can be achieved by organizing the statistical results of each window into a matrix. Furthermore, this operation can be implemented by embedding the matrix with window numbers as rows and the three types of statistical indicators as columns, or by adding window start and end times as metadata, thus forming a historical behavior representation that can be used to input the model.

[0041] The system security state matrix and the security behavior statistical matrix are concatenated to obtain a time-series security feature sequence. Based on the time-series security feature sequence, the system security situation and threat evolution trend are modeled to obtain a multi-dimensional security feature set. Feature concatenation can be an operation that merges the system security state matrix and the security behavior statistics matrix along the feature dimension. It can be used to fuse a single startup snapshot with historical behavior context to construct a more comprehensive feature representation. In one specific embodiment, feature concatenation can be achieved by horizontally concatenating the two matrices while maintaining time alignment. The temporal security feature sequence can be a security feature sequence with a time dimension formed after feature concatenation, which can be used to support temporal modeling algorithms (such as LSTM and Transformer) for dynamic analysis of the security posture. In this embodiment, the temporal security feature sequence can be obtained by arranging the concatenated feature vectors in chronological order of startup time. The system security posture can be a comprehensive assessment of the overall security status of the system in the current and recent time periods, which can be used to provide a macro-level security background for risk decision-making. For example, the system security posture can be obtained by deriving a security score or status label based on the temporal security feature sequence through model inference.

[0042] Threat evolution trends can be seen as the development path and changing patterns of security threats over time, and can be used to support the generation of proactive defense strategies. In an exemplary embodiment, threat evolution trends can be obtained by predicting changes in future threat types, frequencies, or attack intensities through time-series models. Feature concatenation of the system security state matrix and the security behavior statistics matrix can be achieved by merging the two matrices along the feature dimension to form a joint feature vector. Furthermore, this operation can be implemented through horizontal concatenation: [current state | historical statistics] or weighted fusion (normalizing the two types of features separately and then weighted summing), thereby integrating real-time state and historical context.

[0043] Modeling system security posture and threat evolution trends based on temporal security feature sequences can be achieved by using temporal models (such as LSTM and Temporal Fusion Transformer) to learn the evolution patterns of security states. Furthermore, this operation can be implemented by training an autoencoder to detect anomalous sequence patterns or using a classification head to predict the main threat types in the next window, thereby enabling security posture assessment and threat trend prediction. A multidimensional security feature set is obtained, which can be derived from the intermediate representation of the modeling output or the original concatenated features. Further, this operation can be achieved by directly using the last hidden state of the temporal model or by retaining the original concatenated features and adding model-generated derived features, thus providing a high-dimensional, structured security representation.

[0044] Based on a multidimensional security feature set, hardware features, firmware features, and software features are extracted respectively, and a system security feature vector is constructed.

[0045] Hardware features can be a subset of features related to the hardware root of trust extracted from a multi-dimensional security feature set, and can be used for hardware-level security assessment and anomaly detection. In one specific embodiment, hardware features can be obtained by filtering dimensions originating from the hardware root of trust state through feature selection or masking mechanisms. Firmware features can be a subset of features related to secure boot firmware extracted from a multi-dimensional security feature set, and can be used to support firmware-level specific threat identification. In this embodiment, firmware features can be obtained by filtering feature dimensions that include firmware integrity measurements and related behavioral indicators. Software features can be a subset of features related to the operating system kernel and boot parameters extracted from a multi-dimensional security feature set, and can be used for kernel-level attack detection and configuration auditing. For example, software features can be obtained by extracting feature dimensions of kernel boot parameters and associated behavioral statistics.

[0046] Based on a multi-dimensional security feature set, hardware, firmware, and software features are extracted separately. This can be achieved by separating feature subsets at different levels through predefined indexes or attention mechanisms. Furthermore, this operation can be implemented using hard masks (selecting dimensions based on feature sources) or soft attention (allowing the model to automatically learn the feature weights of each layer), thus supporting layered security analysis and strategy customization. Constructing a system security feature vector can be achieved by combining the extracted hardware, firmware, and software features into a unified vector. Further, this operation can be achieved by concatenating the three types of features to form the final vector or by fusing the three types of features through a fully connected layer and reducing dimensionality, thereby providing standardized input for subsequent intelligent recognition.

[0047] Taking the enhanced boot security of financial mobile phones as an example, the trusted boot method for domestically produced financial mobile terminals in this embodiment can be as follows: During boot, a domestically produced financial mobile phone first verifies the hardware trust root (reading the PUF state), secure boot firmware (SM3 verification), and operating system kernel (SM2 signature verification) in a hierarchical order, generating a verification execution sequence. At each verification point, the hardware trust root state (e.g., anti-tamper flag), firmware hash value, and kernel boot parameters (e.g., selinux=enforcing) are collected synchronously. These data constitute a system security state matrix. Simultaneously, the system retrieves boot logs from the past 30 days, divides them into six 5-day time windows, and statistically analyzes the security event occurrence rate (e.g., average 0.2%), verification failure count (e.g., 2 times), and threat type distribution (e.g., 80% firmware rollback attempts) within each window, forming a security behavior statistical matrix. The two are concatenated to generate a temporal security feature sequence, which is input into a lightweight LSTM model to identify abnormal debugging options in the current startup parameters and the recent rise in firmware rollback attacks, thus identifying it as a high-risk startup context. Finally, hardware, firmware, and software features are extracted from the multi-dimensional feature set to construct a 128-dimensional system security feature vector for use by the subsequent risk classification module.

[0048] In one embodiment, based on a multi-dimensional security feature set, hardware features, firmware features, and software features are extracted respectively, and a system security feature vector is constructed, including: The multidimensional security feature set is input into the underlying security feature extraction network to calculate the feature map and obtain the basic hardware feature matrix. The underlying security feature extraction network contains three convolutional layers and two fully connected layers. Each convolutional layer uses the ReLU activation function and a max pooling layer. The underlying security feature extraction network can be a convolutional neural network structure used to extract low-order local security patterns from a multi-dimensional security feature set. It can be used to generate a basic hardware feature matrix representing the physical state and startup context of the hardware trust root. In this embodiment, the underlying security feature extraction network can include three convolutional layers and two fully connected layers. Each convolutional layer is followed by a ReLU activation function and a max-pooling layer to extract spatial local patterns from the input features. For example, the underlying security feature extraction network can include, but is not limited to, one or more of a lightweight CNN feature extractor, a convolutional encoder with pooling, and a ReLU activation convolutional backbone network. The three convolutional layers can be three convolutional operation units in the underlying network used to progressively extract local features, which can be used to gradually abstract the spatial local patterns of the input features. Further, the three convolutional layers can include, but are not limited to, a first convolutional layer (shallow edge detection), a second convolutional layer (combined feature extraction), and a third convolutional layer (higher-order local patterns). The two fully connected layers can be linear transformation layers at the end of the underlying network used for feature integration and dimension mapping, which can be used to fuse the local features extracted by convolution into a fixed-dimensional vector representation. In an exemplary embodiment, the two fully connected layers may include, but are not limited to, a feature compression fully connected layer and an embedding layer before the classification head. The ReLU activation function can be an activation function that introduces a non-linear transformation, defined as the maximum value between the input value and zero, which can be used to enhance the model's expressive power and avoid gradient saturation. The max pooling layer can be an operation that downsamples the convolutional output, preserving the maximum response value in a local region, which can be used to reduce the feature map dimension and enhance translation invariance.

[0049] The basic hardware feature matrix is ​​input into the mid-layer security feature extraction network for residual calculation to obtain the firmware integrity feature matrix. The mid-layer security feature extraction network uses four residual blocks, each containing two convolutional layers and one skip connection, and BatchNorm layers are added between the residual blocks. The intermediate-layer security feature extraction network can be a deep network based on residual structures, used to enhance the nonlinear representation of firmware integrity features. It can accurately capture subtle tampering traces in firmware integrity measurements and output a highly robust firmware integrity feature matrix. In this embodiment, the intermediate-layer security feature extraction network can consist of four residual blocks, each containing two convolutional layers and skip connections. BatchNorm layers are inserted between blocks to stabilize the training process. Exemplarily, the intermediate-layer security feature extraction network can include, but is not limited to, one or more of the following: a ResNet-18 variant security encoder, a residual feature enhancer with BatchNorm, and a stack of dual-convolutional residual blocks. The four residual blocks can be four residual units in the intermediate-layer network used to construct deep nonlinear mappings, which can alleviate the gradient vanishing problem in deep network training. In an exemplary embodiment, the four residual blocks can include, but are not limited to, BasicBlock type residual units, Bottleneck residual units, and residual blocks with pre-activation.

[0050] Skip connections can be identity mapping paths in residual blocks that directly add the input to the output. They can be used to preserve the original information flow and improve training stability and feature reuse capabilities.

[0051] The BatchNorm layer can be a regularization layer that normalizes small batches of data, which can be used to accelerate convergence and reduce internal covariate bias. Furthermore, the BatchNorm layer can include, but is not limited to, channel-level BatchNorm, layer-level normalization LayerNorm, and instance-level normalization InstanceNorm.

[0052] The firmware integrity feature matrix is ​​input into the high-level security feature extraction network for threat correlation analysis to obtain the threat scenario feature matrix. The high-level security feature extraction network uses a transformer encoder structure, which includes six layers of multi-head self-attention layers and feedforward neural network layers. The high-level security feature extraction network can be a semantic modeling network employing a Transformer encoder structure for cross-component threat correlation analysis. It can be used to identify covert attack behaviors scattered across different initiation phases and generate a semantically rich threat scenario feature matrix. In this embodiment, the high-level security feature extraction network may include six multi-head self-attention layers and feedforward neural network layers, modeling long-range dependencies through a self-attention mechanism. Exemplarily, the high-level security feature extraction network may include, but is not limited to, one or more of the following: a security semantic Transformer encoder, a multi-head attention threat modeler, and a serialized security context encoder. The transformer encoder structure can be a sequence modeling architecture based on a self-attention mechanism, used to capture long-range dependencies between features. In an exemplary embodiment, the transformer encoder structure may include, but is not limited to, a standard Transformer encoder, a sparse attention encoder, and an axial attention encoder.

[0053] A six-layer multi-head self-attention layer can be a six-layer attention module in a high-level network used for parallel modeling of dependencies between multiple subspaces. It can be used to achieve dynamic weight allocation and correlation discovery among different security feature dimensions. The feedforward neural network layer can be a two-layer fully connected network following the self-attention layer in a Transformer. It can be used to perform nonlinear transformations and feature fusion on the attention output.

[0054] The system security feature vector is obtained by weighted fusion and normalization of the basic hardware feature matrix, firmware integrity feature matrix and threat scenario feature matrix.

[0055] Weighted fusion can be an operation that linearly combines the three-layer feature matrices according to learnable or preset weights, and can be used to balance the expression strength of security semantics at each layer of hardware, firmware, and software. In this embodiment, weighted fusion can dynamically adjust the contribution of each layer using a weight strategy adapted to the domestic IT innovation environment (such as based on component risk level). Normalization can be a process of scaling the fused feature vectors to a uniform numerical range, which can be used to improve the stability and generalization ability of subsequent intelligent recognition models. Furthermore, normalization can use L2 normalization or Min-Max scaling to ensure consistent feature vector scale.

[0056] For example, in the scenario of government-developed tablets dealing with firmware-level advanced persistent threat attacks, the trusted boot method for the domestically developed mobile terminal in this embodiment can be as follows: When a domestically produced tablet boots up, its multi-dimensional security feature set (including hardware status, firmware hash, kernel parameters, and timing statistics) is input into the underlying security feature extraction network: after three layers of convolution and pooling, the local patterns of abnormal hardware trust root tamper protection flags are extracted to generate a basic hardware feature matrix; this matrix enters the intermediate residual network, and the four residual blocks retain the original signal through skip connections, while simultaneously enhancing the small deviations in the firmware SM3 hash value. The system expresses and outputs a highly sensitive firmware integrity feature matrix. Subsequently, this matrix is ​​fed into the high-level Transformer encoder. The six-layer multi-head self-attention mechanism discovers a strong correlation between "slight firmware hash offset" and "clustering of similar failure events in the historical window," which is identified as a firmware rollback attack attempt, generating a threat scenario feature matrix. Finally, the three feature matrices are fused according to their weights (hardware 0.3, firmware 0.5, threat 0.2) and L2 normalized to form a 128-dimensional system security feature vector, triggering a high-risk protection strategy, blocking kernel loading, and reporting to the management center.

[0057] In one embodiment, a trust chain component dependency graph is constructed, and constraint optimization that minimizes security risk is performed to obtain a trusted startup sequence, including: A trust chain component dependency graph is constructed based on the startup dependencies between trust chain components. The edge weights of the trust chain component dependency graph represent the verification latency between components, and the node weights represent the security risk level of the components. The trust chain component dependency graph can be a directed graph structure that abstracts each startup component as a graph node, and adds a directed edge from A to B if component A needs to be verified by component B before it can start. In this embodiment, this graph structure is used to transform the startup logic into a computable graph model. For example, the trust chain component dependency graph can be statically constructed to generate a fixed dependency graph based on a predefined startup manual, or it can be dynamically constructed to scan the actual loaded components and generate dependencies in real time before each startup. The edge weight can be a numerical value assigned to the directed edge connecting two nodes in the trust chain component dependency graph, used to quantify the verification latency between components. Furthermore, the edge weight can reflect the time overhead required from when a component completes verification to when its dependent components begin verification, providing a basis for time scheduling. In an exemplary embodiment, the specific physical meaning of the edge weight is the verification latency, and its value is determined by the component size, verification algorithm complexity, and hardware performance. For example, the edge weight can be one or more of the following, including but not limited to serial verification latency, parallel coordination latency, and cross-security domain switching latency.

[0058] Verification latency can be the time required to complete the integrity or behavior verification of a component. In one specific embodiment, verification latency is determined by the component size, verification algorithm complexity, and hardware performance, and serves as the specific physical meaning of edge weights, affecting the overall startup timing plan. Node weights can be numerical values ​​assigned to each node in the trust chain component dependency graph, used to characterize the security risk level of the corresponding component. Furthermore, node weights can guide verification resource allocation and priority ranking, enabling high-risk components to receive stronger verification protection. In one exemplary embodiment, the specific semantic content of node weights is the security risk level, and its value is calculated based on a comprehensive analysis of multiple dimensions such as historical attack data, component source credibility, and code complexity. For example, node weights can include, but are not limited to, one or more of the following: integrity tampering risk, abnormal behavior risk, and supply chain contamination risk. The security risk level can be a quantitative assessment of the probability of a component being attacked or failing during startup. In one specific embodiment, the security risk level is calculated based on a comprehensive analysis of multiple dimensions such as historical attack data, component source credibility, and code complexity, used to drive risk-aware verification scheduling.

[0059] Based on the trust chain component dependency graph, security risk constraints are set, including: the overall security risk does not exceed a preset threshold, the verification time of any component is earlier than the start time of its dependent components, and the verification time interval between adjacent components is not less than the minimum security period, thus obtaining a set of constraints. Security risk constraints can be a set of security and timing restrictions that must be met when constructing a trusted startup sequence. Furthermore, security risk constraints can ensure that the generated verification scheme is both secure and feasible, and conforms to startup logic dependencies. For example, security risk constraints can include, but are not limited to, one or more of global risk ceiling constraints, local timing dependency constraints, and minimum interval security constraints. A preset threshold can be the maximum allowable overall security risk ceiling value of the system. In one specific embodiment, the preset threshold serves as a hard boundary in the security risk constraints to prevent overall risk from spiraling out of control. The startup time of a dependent component can be the point in time when a component begins execution (rather than just when verification is completed). In an exemplary embodiment, the startup time of a dependent component is used to establish a causal timing relationship between verification completion and the startup of subsequent components.

[0060] The minimum security period can be the shortest time interval that must be maintained between verification operations of adjacent components. In one specific embodiment, the minimum security period is used to prevent side-channel attacks or resource contention vulnerabilities caused by overly dense verification. The constraint set can be a mathematical constraint system composed of multiple security risk constraints. Furthermore, the constraint set can serve as a definition of the feasible region of the optimization problem, ensuring the legality of the solution.

[0061] Based on the set of constraints, a graph neural network is used to calculate the dependency graph of the trust chain components to obtain the component security feature matrix. The component security feature matrix is ​​then used to determine the verification order and time allocation of the components to obtain an initial verification scheme. Obtaining the constraint set can be achieved by integrating all the aforementioned constraints into a set of mathematical expressions. Furthermore, this operation can be implemented using symbolic modeling tools, thereby forming a feasible domain definition for the optimization problem. Graph neural network computation can be message passing and aggregation operations performed on the trust chain component dependency graph to extract structured risk features. In a specific embodiment, graph neural network computation fuses node weights, edge weights, and topological information through multi-layer graph convolution or graph attention mechanisms. Exemplarily, graph neural network computation can employ Graph Convolutional Network (GCN), Graph Attention Network (GAT), Graph Isomorphic Network (GIN), etc. The component security feature matrix can be a matrix output by graph neural network computation, with each row corresponding to the embedding vector of a component, encoding its risk and dependency context. In an exemplary embodiment, the component security feature matrix is ​​generated by aggregating neighbor information from multiple rounds on the trust chain component dependency graph, providing a data-driven decision basis for verification order and time allocation.

[0062] The initial verification scheme is constrained and verified, the actual security risks and verification costs of each component are calculated, and the optimization problem of minimizing security risks is solved based on the Lagrange multiplier method to obtain the optimal verification scheme. Constraint verification can be a process of checking whether an initial verification scheme meets all security risk constraints. In one specific embodiment, constraint verification determines feasibility by substituting the constraint set, filtering out infeasible schemes and ensuring the legitimacy of the optimization starting point. Actual security risk can be the real risk value presented by each component and its combination under a specific verification scheme. In an exemplary embodiment, actual security risk is dynamically calculated based on node weights, verification coverage, and attack models, serving as a core component of the optimization objective function. Verification overhead can be the total amount of computational, storage, or time resources required to execute the verification scheme. In one specific embodiment, verification overhead serves as an implicit constraint or regularization term in the optimization problem to prevent over-protection.

[0063] Constraint verification of the initial verification scheme can involve checking each condition in the constraint set to ensure it is met. Furthermore, this operation can be implemented using a constraint solver, which can eliminate invalid schemes and ensure the effectiveness of subsequent optimizations. Calculating the actual security risks and verification costs of each component can be done by reassessing the risk values ​​and resource consumption based on the time allocation and coverage in the verification scheme. Further, this operation can be performed by accumulating the CPU cycles and memory usage required for each component's verification using a risk simulator, and considering the extended exposure window caused by verification delays, thus providing accurate feedback for the optimization objective. The optimization problem of minimizing security risk can be a mathematical programming problem with the overall security risk as the minimization objective and the constraint set as the constraint. In an exemplary embodiment, the optimization problem of minimizing security risk is used to drive the evolution from the initial verification scheme to the optimal verification scheme.

[0064] Based on the optimal verification scheme, the verification priority and execution order of the components that meet the sequential verification requirements are determined to obtain a trusted startup sequence.

[0065] Verification priority can be the relative importance ranking of components in the verification schedule. In an exemplary embodiment, verification priority is used to guide high-risk or critical path components to receive verification resources preferentially. Execution order can be the physical order in which components are loaded and run during the startup process. In a specific embodiment, the execution order is ultimately reflected in the specific content of the trusted startup sequence. Determining the verification priority and execution order of components that meet the sequential verification requirements according to the optimal verification scheme can be achieved by mapping the optimization results to an executable priority queue and schedule. Further, this operation can be implemented by a scheduler compiler, thereby generating an instruction sequence that can be parsed by the startup manager. Obtaining the trusted startup sequence can be achieved by serializing the verification priority and execution order into a standard format. Further, this operation can be implemented by a serialization engine, thereby serving as the authoritative scheduling basis for the startup execution phase.

[0066] Taking the startup optimization of domestically produced mobile phones in the financial industry as an example, the trusted startup method for domestically developed mobile terminals in this embodiment can be as follows: When a domestically produced financial mobile phone starts up, the system identifies the components that need to be loaded, including: a trusted root chip, an SM2-signed bootloader, a kernel encrypted with Chinese national cryptographic standards, and a secure payment driver. First, a trust chain component dependency graph is constructed, where the bootloader points to the kernel, and the kernel points to the payment driver; the edge weight is set to the average verification time of each component (e.g., 80ms for the bootloader and kernel), and the node weight is assigned according to the component sensitivity (0.9 for the payment driver and 0.3 for the ordinary driver). Constraints are set: total risk ≤ 1.5, verification must be earlier than startup, and the interval between adjacent verifications ≥ 10ms. After aggregation by the graph neural network, a component security feature matrix is ​​generated. Initially, the high-risk payment driver is prioritized for verification. Constraint verification reveals that the scheme violates time-series dependencies. Therefore, the Lagrange multiplier method is used for optimization, reducing the total risk to 1.2 while satisfying all constraints. Finally, a trusted startup sequence is generated: first verify the Bootloader (t=0ms), then verify the kernel (t=90ms), and finally verify the payment driver (t=180ms) and ordinary services in parallel (t=185ms), ensuring that high-risk components complete strong verification within the minimum exposure window.

[0067] In one embodiment, based on trusted boot sequences and system security feature vectors, potential threats during the boot process are intelligently identified and risk-classified to obtain a layered security protection strategy, including: The trusted startup sequence and the system security feature vector are concatenated and linearly transformed to obtain a security input feature sequence. The security input feature sequence is then input into the forward LSTM layer and the backward LSTM layer respectively to obtain a bidirectional security feature vector. The secure input feature sequence can be a temporal input feature representation formed by concatenating and linearly transforming a trusted startup sequence and a system security feature vector. This can provide a structurally unified and semantically aligned input for a bidirectional LSTM, supporting the modeling of the dynamic security state during the startup process. In this embodiment, the secure input feature sequence can encode the trusted startup sequence (such as the component verification order) into positional or categorical features, concatenate it with the system security feature vector, and then perform linear projection through a fully connected layer to form a fixed-dimensional temporal feature sequence. For example, the secure input feature sequence can be implemented by converting each component ID in the trusted startup sequence into a learnable embedding vector, concatenating it with the system security feature vector, and then inputting it into a linear layer; or by performing one-hot encoding on the trusted startup sequence, concatenating it with a normalized system security feature vector, and then performing batch normalization and linear transformation.

[0068] The forward LSTM layer can be a long short-term memory network layer that processes the secure input feature sequence in a forward time manner, and can be used to model the forward temporal evolution of the secure state during startup. In an exemplary embodiment, the forward LSTM layer can sequentially receive features from the secure input feature sequence from the initial startup to the current time, updating the hidden state to capture historical dependencies. Further, the forward LSTM layer can be one or more of, including but not limited to, single-layer LSTM, stacked LSTM, and variant LSTM with gating mechanisms. The backward LSTM layer can be a long short-term memory network layer that processes the secure input feature sequence in a backward time manner, and can be used to supplement backward dependency information not covered by the forward LSTM, enhancing the ability to identify abnormal patterns. In a specific embodiment, the backward LSTM layer can process the input sequence from the end of startup back to the initial time, capturing the influence of future context on the current state. Exemplarily, the backward LSTM layer can be, including but not limited to, a single-layer backward LSTM, a multi-layer backward LSTM, and the backward branch in a bidirectional coupled LSTM.

[0069] The bidirectional security feature vector can be a comprehensive temporal feature vector formed by concatenating the outputs of the forward and backward LSTM at each time step. It can be used to fuse the contextual information before and after the startup process, improving the ability to perceive complex attack chains. In this embodiment, the bidirectional security feature vector can be formed by concatenating or weighted fusion of the hidden state vectors of the two directional LSTMs at the same time step. The trusted startup sequence and the system security feature vector are concatenated and linearly transformed to obtain a secure input feature sequence. This can be achieved by encoding the trusted startup sequence as a discrete identifier or positional embedding, concatenating it with the system security feature vector, and then linearly mapping it through a fully connected layer. Furthermore, this operation can be achieved by converting each component ID in the trusted startup sequence into a learnable embedding vector, concatenating it with the system security feature vector, and then inputting it into a linear layer; or by performing one-hot encoding on the trusted startup sequence, concatenating it with the normalized system security feature vector, and then implementing batch normalization and linear transformation. This unifies heterogeneous feature scales and constructs an input format suitable for temporal model processing.

[0070] Temporal attention is calculated on the bidirectional security feature vector to obtain the security context feature vector; Temporal attention computation can be a mechanism that assigns different weights to each time step in the bidirectional security feature vector to highlight critical security events. This can be used to automatically focus on the verification phase of high-risk components or the moment of abnormal behavior, improving threat identification accuracy. In an exemplary embodiment, temporal attention computation can calculate the importance score of each time step and sum it using a learnable query-key-value mechanism or an additive attention function. Furthermore, temporal attention computation can include, but is not limited to, additive attention, multiplicative (scaled dot product) attention, and multi-head temporal attention. The security context feature vector can be a compressed representation of the bidirectional security feature vector after being weighted by temporal attention. It can be used as input for threat correlation analysis, condensing the key security semantics of the entire startup process. In this embodiment, the security context feature vector can be generated by weighted aggregation of attention weights and the bidirectional feature vector to produce a single high-dimensional context vector.

[0071] Threat correlation analysis is performed based on security context feature vectors, and weighted by combining historical threat data to obtain a threat prediction sequence; Threat correlation analysis can be a process of identifying the association between security context feature vectors and known threat patterns, and can be used to determine whether the current startup state matches a specific attack type (such as firmware rollback or kernel hijacking). In a specific embodiment, threat correlation analysis can calculate the association strength between the current context and the threat prototype through classification heads, similarity matching, or graph neural networks. For example, threat correlation analysis may include, but is not limited to, prototype-based matching, rule-based reasoning, and clustering based on embedding space distance.

[0072] Historical threat data can be a collection of threat events, their characteristics, and response results recorded by the system in the past. It can be used to provide prior knowledge for current threat prediction and enhance the generalization ability against variant attacks. In this embodiment, historical threat data can be obtained from local security logs or remote threat intelligence platforms, and after anonymization and vectorization, it can be used for model training or online weighting. Furthermore, historical threat data can be combined with threat correlation analysis results for weighting, affecting the confidence level of the final threat prediction sequence.

[0073] Weighting can be a process of incorporating statistical patterns or confidence factors from historical threat data into the current threat prediction result. It can be used to improve sensitivity to high-frequency or high-risk threat types and suppress occasional noise interference. In an exemplary embodiment, weighting can employ exponential smoothing, Bayesian updating, or attention mechanisms to fuse current predictions with historical data. The threat prediction sequence can be a sequence of predicted probabilities or confidence levels for each potential threat type during startup. It can be used to quantify the likelihood of each type of threat (such as Bootloader tampering or kernel vulnerability exploitation) and support subsequent risk scoring. In this embodiment, the threat prediction sequence can be generated from the weighted threat correlation analysis results via Softmax or Sigmoid activation.

[0074] Based on the threat prediction sequence, risk scores and rankings are performed on each threat type to obtain a security protection priority list. Resource quotas are then allocated to each type of security measure based on the security protection priority list to obtain a layered security protection strategy.

[0075] The risk score can be a numerical risk level indicator assigned to each type of threat based on a threat prediction sequence. This can be used to achieve comparable quantification of threats and provide a basis for ranking. In one specific embodiment, the risk score can be weighted by combining a threat severity coefficient, an impact scope weight, and a prediction confidence level. For example, the risk score can include, but is not limited to, CVSS-based scores, custom business impact scores, and combined multidimensional scores.

[0076] Sorting can be an operation that arranges various threats in descending order based on risk scores. This can be used to determine the priority of security responses and guide resource allocation. In this embodiment, sorting can use algorithms such as quicksort and heapsort to arrange threat types according to their risk scores.

[0077] A security protection priority list can be an ordered list of threat types and their corresponding protective actions, arranged from highest to lowest risk. This list can serve as a direct basis for resource quota allocation, ensuring that high-risk threats receive priority access to defense resources. In one exemplary embodiment, the security protection priority list can be generated by mapping the sorting results to a predefined library of protective actions. Resource quotas can be the upper limit of computing, time, or storage resources allocated to each type of security measure. This can be used to implement differentiated resource scheduling and ensure the effective execution of critical protective measures. In this embodiment, resource quotas can allocate CPU cycles, memory bandwidth, or verification timeouts according to the order in the security protection priority list, using a proportional or threshold strategy. For example, resource quotas may include, but are not limited to, CPU time slice quotas, memory isolation quotas, and verification timeout thresholds.

[0078] Based on the threat prediction sequence, risk scoring and ranking are performed on each threat type to obtain a security protection priority list. This can be achieved by assigning a risk score (e.g., predicted probability × severity coefficient) to each threat type and generating a priority list by sorting the scores in descending order. Furthermore, this operation can be implemented by mapping a predefined severity level table (e.g., high / medium / low) to numerical weights and multiplying them by the predicted probability, or by dynamically adjusting the severity coefficients based on business context (e.g., current application type) before calculating a comprehensive score. This transforms ambiguous threat signals into actionable response priorities, supporting precise defense.

[0079] Based on a security protection priority list, resource quotas are allocated to each type of security measure to obtain a tiered security protection strategy. This can be achieved by allocating decreasing resource quotas according to priority (e.g., allocating 70% of verification time to high-priority measures), forming a specific execution strategy. Furthermore, this operation can be implemented using tiered quotas (allocating fixed high quotas to the first N measures and basic quotas to the rest), or by using a continuous decay function (e.g., exponential decay) to dynamically calculate quota ratios based on priority ranking. This maximizes the defense effectiveness against high-risk threats with limited resources and avoids resource egalitarianism.

[0080] Taking a firmware rollback attack on a domestically produced mobile phone in the financial industry as an example, the trusted startup method for a domestically produced financial mobile phone in this embodiment can be as follows: When a domestically produced financial mobile phone starts up, its security input feature sequence concatenates the verification order (hardware trust root → old firmware → kernel) with abnormal hash value features; bidirectional LSTM captures the timing pattern of abnormal firmware version and kernel compatibility; the timing attention mechanism focuses on the high abnormal score in the firmware verification stage; the security context feature vector is matched to the "firmware rollback" attack prototype through threat correlation analysis, and combined with historical data showing that this attack has been frequent recently, the confidence of "firmware rollback" in the weighted threat prediction sequence reaches 0.92; the system gives the highest risk score and ranks it first in the security protection priority list; the resource quota allocation module allocates an independent verification thread and complete SM2 signature verification resources for it, while low-priority services only perform lightweight hash verification; the finally generated layered security protection strategy successfully blocks the loading of malicious old firmware and ensures transaction security.

[0081] In one embodiment, the layered security protection strategy is dynamically adjusted and resource allocation weights are calculated to obtain a startup protection scheme. The trusted component loading process is divided into a high-security verification area and a basic verification area for block verification to obtain a trusted startup execution result, including: The security tasks in the layered security protection strategy are reordered to obtain the initial security scheduling sequence; In this context, a security task can be the smallest schedulable security operation unit within a layered security protection strategy, such as integrity verification, behavior monitoring, or key loading. It can serve as the basic unit for dynamic scheduling, supporting fine-grained resource allocation and time adjustment. In an exemplary embodiment, a security task may include, but is not limited to, one or more of integrity verification tasks, runtime behavior monitoring tasks, and key derivation and injection tasks. The initial security scheduling sequence can be a preliminary execution order formed by reordering security tasks in the layered security protection strategy according to priority or dependency, and can be used to provide a baseline scheduling scheme for subsequent dynamic adjustments based on time windows. Furthermore, the initial security scheduling sequence can be generated through topological sorting or priority queues based on inter-task dependency constraints and initial risk assessment results.

[0082] The security tasks in the layered security protection strategy are reordered to obtain an initial security scheduling sequence. This can be achieved by sequentially arranging the security tasks based on task dependencies, initial risk levels, or preset priorities. For example, this operation can be implemented by using topological sorting to handle security tasks with dependencies (such as verifying firmware before verifying the kernel), or by using a priority queue to sort tasks from high to low risk levels, thereby establishing a dynamically adjustable scheduling baseline.

[0083] The initial security scheduling sequence is divided into multiple second time windows, and the system security status within each second time window is dynamically monitored to obtain a security status sequence. The second time window can be a continuous, non-overlapping execution period segmented along the time dimension of the initial security scheduling sequence, which can be used to achieve fine-grained slice monitoring and dynamic response of the startup process. In a specific embodiment, the second time window can be one or more of the following, including but not limited to the boot phase window, kernel loading window, and service initialization window. The system security status can be a set of real-time indicators reflecting the security posture of the domestically developed mobile terminal within a specific time window, which can be used as the basic input for calculating the comprehensive security weight and driving dynamic adjustment of task scheduling. Furthermore, the system security status can be collected through hardware performance counters, abnormal event logs, memory access patterns, etc.

[0084] The security state sequence can be a time series of system security states arranged in order of a second time window, which can be used to characterize the dynamic evolution trajectory of the security posture during startup. In an exemplary embodiment, the security state sequence can be obtained by sampling and recording the system security state within each second time window. Dividing the initial security scheduling sequence into multiple second time windows can be achieved by segmenting the scheduling sequence into continuous time periods based on a fixed duration or the number of tasks. For example, this operation can be implemented by slicing for equal durations (each 50ms is a window) or by slicing according to logical stages (each stage of booting, kernel loading, and user space initialization is a window), thereby supporting fine-grained dynamic monitoring and response.

[0085] The system security status is dynamically monitored within each second time window to obtain a security status sequence. This can be achieved by continuously collecting hardware and software security indicators and recording snapshots within each window. Furthermore, this operation can be implemented by collecting hardware indicators such as abnormal CPU instructions and cache hit rate through the PMU (Performance Monitoring Unit), or by monitoring software behaviors such as memory allocation patterns and system call frequency through lightweight probes, thereby enabling real-time perception of the security posture during the startup process.

[0086] The comprehensive security weight within each second time window is calculated based on the security state sequence, and the execution time of the security task is adjusted according to the comprehensive security weight to obtain the task scheduling scheme. The comprehensive security weight is a quantitative indicator reflecting the overall risk level of each time window, calculated based on the security state sequence. It can be used to dynamically adjust the execution time of security tasks, allocating more verification time to high-weight windows. In a specific embodiment, the comprehensive security weight can be obtained by weighted calculation of multiple security indicators (such as anomaly frequency, sudden changes in resource consumption, and known vulnerability matching degree). The task scheduling scheme can be the final scheduling plan after reallocating the execution time of each task in the initial security scheduling sequence according to the comprehensive security weight. It can be used to match the verification rhythm with the actual security situation and improve threat response sensitivity. Furthermore, the task scheduling scheme can extend the execution time of tasks in high-risk windows and compress the task time in low-risk windows while maintaining task dependencies.

[0087] Calculating the comprehensive security weight within each second time window based on the security state sequence can be achieved by weighted fusion of various security indicators within the window, outputting a single risk score. For example, this operation can use a linear weighted model (anomaly count × 0.4 + resource mutation rate × 0.3 + known vulnerability matching degree × 0.3), or employ a lightweight neural network to non-linearly fuse multi-dimensional indicators, thereby quantifying the actual security risk in each time period and guiding scheduling adjustments. Adjusting the execution time of security tasks based on the comprehensive security weight yields a task scheduling scheme, which can involve increasing the time allocation for tasks in high-weight windows and compressing the time for tasks in low-weight windows. Furthermore, this operation can be achieved by scaling proportionally (original time × (1 + comprehensive security weight)) or setting a threshold trigger (extending the verification timeout limit if the weight exceeds the threshold), thus matching the verification rhythm with dynamic risks.

[0088] By setting resource usage limits for each task in the task scheduling scheme and controlling the rate of security resource allocation through the token bucket algorithm, a startup protection scheme is obtained. The resource usage limit can be a maximum threshold for computing, memory, or I / O resource consumption set for each security task in the task scheduling scheme. It can be used to prevent individual security tasks from excessively occupying system resources, leading to startup blockage or performance degradation.

[0089] The security resource allocation rate refers to the speed at which available resources are allocated to security tasks per unit of time, and can be used to control the impact of security mechanisms on the overall system performance. In an exemplary embodiment, the security resource allocation rate is regulated by a token bucket algorithm to ensure smooth and controllable resource allocation. The token bucket algorithm can be a traffic shaping and rate limiting algorithm that controls the rhythm of resource allocation through token generation and consumption mechanisms. It can be used to ensure the supply of resources for critical tasks while avoiding sudden resource contention. Furthermore, the token bucket algorithm can operate by adding tokens to the bucket at a fixed rate, requiring tokens to be consumed when executing a security task, and waiting when no tokens are available. Setting resource usage limits for each task in the task scheduling scheme can be achieved by configuring hard limits on CPU time, memory usage, or I / O bandwidth for each security task. For example, this operation can be implemented by limiting the CPU share and memory limit of a task through cgroups, or by setting task priority and time slice limits in the RTOS, thereby preventing the security mechanism itself from becoming a performance bottleneck.

[0090] Based on the startup protection scheme, the trusted component loading process is divided into a high-security verification area and a basic verification area. Block verification is performed using domestic hardware encryption modules and parallel verification technology to obtain the trusted startup execution result.

[0091] The domestically produced hardware encryption module can be a dedicated cryptographic coprocessor integrated into a domestically developed mobile terminal, supporting national cryptographic algorithms such as SM2 / SM3 / SM4. It can provide strong encryption verification support for high-security verification components that conforms to domestic standards. In one specific embodiment, the domestically produced hardware encryption module can be called through a hardware instruction interface to provide high-speed, side-channel attack-resistant encryption / decryption and signature verification capabilities. Furthermore, the domestically produced hardware encryption module can provide key protection and accelerated computation for the high-security verification area in block verification. Parallel verification technology can be a technique that utilizes multi-core processors or hardware acceleration units to simultaneously perform independent verification on multiple trusted components, which can be used to shorten the overall verification time and improve startup efficiency. In an exemplary embodiment, parallel verification technology can include, but is not limited to, one or more of the following: multi-core parallel verification, heterogeneous computing unit parallel verification, and pipelined staged parallel verification.

[0092] Taking the startup of a domestically produced financial mobile phone as an example, the trusted startup method of the domestically developed mobile terminal in this embodiment can be as follows: The system first sorts the security tasks such as integrity verification, key loading, and behavior monitoring in the layered security protection strategy according to their dependencies to form an initial security scheduling sequence; then, the sequence is divided into three second time windows: Bootloader verification period, kernel loading period, and service initialization period; within each window, the system continuously monitors indicators such as the number of abnormal instructions and memory access entropy value through PMU and lightweight probes to form a security state sequence; calculations show that the comprehensive security weight of the kernel loading period has increased significantly (due to the detection of abnormal jumps), and the system automatically extends the execution time of the kernel verification task in this window and allocates a higher CPU share to it; at the same time, the resource consumption rate of the service initialization period task is limited by the token bucket algorithm to prevent it from preempting key verification resources; finally, the kernel component is allocated to the high-security verification area, where the domestic hardware encryption module uses the SM2 algorithm to complete the signature verification, while the general driver performs parallel verification through SM3 hashing in the basic verification area; the whole process maintains the overall startup smoothness while ensuring strong verification of high-risk components.

[0093] In one embodiment, the trusted component loading process is divided into a high-security verification area and a basic verification area according to the startup protection scheme, and block verification is performed using a domestically produced hardware encryption module and parallel verification technology to obtain the trusted startup execution result, including: The trusted components in the startup protection scheme are divided into regions according to their security risk levels. Components with security risks higher than the threshold are assigned to the high-security verification zone, and components with security risks lower than the threshold are assigned to the basic verification zone, resulting in a component partitioning scheme. The security risk level can be an assessment metric used to quantify the likelihood of a trusted component being attacked or tampered with during startup. In this embodiment, the security risk level can be calculated based on component type, historical vulnerability records, behavioral characteristics, and the current system security status. Further, the security risk level can be one or more of the following: risk level of critical system components, risk level of peripheral drivers, risk level of user service modules, etc. The threshold can be a preset security risk level boundary point used to distinguish between high-risk and low-risk components. For example, the threshold can be configured by the system security policy or dynamically adjusted based on historical threat data. The component partitioning scheme can be a mapping table formed after assigning regions to trusted components according to the security risk level and the threshold. In a specific embodiment, the component partitioning scheme can bind each trusted component to its corresponding security region (high-security verification region or basic verification region).

[0094] The components to be verified in the component partitioning scheme are divided into blocks. Each component is divided into several verification blocks according to a preset block size, and a unique identifier is assigned to each verification block to obtain a verification block sequence. The component to be verified can be a software or firmware unit that has been assigned to a specific security area and is awaiting integrity verification. In one specific embodiment, the component to be verified may include a bootloader image, an operating system kernel binary, a device driver module, etc. The preset block size can be a fixed or configurable data length unit used to divide the component to be verified into multiple verification blocks. For example, the preset block size can balance verification granularity and parallel efficiency, avoiding insufficient parallelism due to excessively large blocks or scheduling overhead due to excessively small blocks. Further, the preset block size can adopt a page-aligned block size (such as 4KB), an algorithm-optimized block size (such as SM3 group alignment), or a dynamically adapted block size, etc. A verification block can be an independent verification unit obtained by dividing the component to be verified according to the preset block size. In this embodiment, the verification block can be logically divided through memory mapping or file segmentation reading without changing the original component content. Further, the verification block can support fine-grained parallel verification and state tracking. The unique identifier can be a globally unique code assigned to each verification block to identify its source, location, and the component to which it belongs. In an exemplary embodiment, the unique identifier can be generated by combining fields such as component ID, offset address, and block sequence number. Furthermore, unique identifiers ensure that verification results are traceable and recombinable, preventing block obfuscation or replay attacks. A verification block sequence can be an ordered set of all verification blocks and their unique identifiers organized in component and block order.

[0095] A two-layer verification structure is constructed based on the verification block sequence. A fast signature verification module based on domestic cryptographic algorithms is set in the high-security verification area, and a lightweight hash verification module is set in the basic verification area. A collaborative verification channel between the two areas is established to obtain the verification management unit. The dual-layer verification structure can be a layered verification system composed of a strong verification mechanism in a high-security verification zone and a lightweight verification mechanism in a basic verification zone. In a specific embodiment, the dual-layer verification structure can achieve synergistic optimization of security strength and verification efficiency. Furthermore, the dual-layer verification structure can include a signature-hash dual-layer structure, an encryption-verification dual-layer structure, a hardware-software collaborative dual-layer structure, etc. The fast signature verification module can be a high-efficiency digital signature verification unit deployed in the high-security verification zone and implemented based on domestic cryptographic algorithms. In this embodiment, the fast signature verification module can call a domestic hardware encryption module to accelerate SM2 signature verification, supporting pre-computation and batch processing optimization. Furthermore, the fast signature verification module can provide anti-forgery and anti-tampering identity authentication guarantees for high-risk components. The lightweight hash verification module can be a unit deployed in the basic verification zone that uses a low-computational-overhead hash algorithm (such as SM3) for integrity verification. For example, the lightweight hash verification module can calculate the SM3 digest of the verification block in a normal execution environment and compare it with a pre-stored value. Furthermore, the lightweight hash verification module can complete the integrity verification of low-risk components with minimal performance cost.

[0096] The collaborative verification channel can be a communication mechanism connecting the high-security verification zone and the basic verification zone, used to synchronize verification status and abnormal events. In an exemplary embodiment, the collaborative verification channel can achieve cross-region information transmission through shared memory, secure message queues, or trusted interrupts. Furthermore, the collaborative verification channel can prevent verification fragmentation between regions and support global consistency judgment and linkage response. The verification management unit can be a unified control entity integrating the two-layer verification structure, the collaborative verification channel, and resource scheduling logic.

[0097] Based on the identifier of the verification block and the verification management unit, verification resources are allocated. Different verification blocks of the same component are verified in parallel through the domestic hardware encryption module, and the verification status is recorded in real time to obtain the verification progress table. The verification resources can be computing, storage, and encryption hardware resources used to perform verification operations. In one specific embodiment, the verification resources can support the execution of parallel verification tasks. Further, the verification resources may include computing units of domestically produced hardware encryption modules, CPU core time slices, secure memory buffers, etc. The verification status can be the real-time status information of each verification block during the verification process, such as pending verification, in progress, successful, or failed. The verification progress table can be a data structure that records the current verification status of all verification blocks. In this embodiment, the verification progress table can be maintained by the verification management unit and updated in real time with the verification process. Further, the verification progress table can provide a status basis for integrity verification and result aggregation.

[0098] Based on the verification schedule, the verified blocks are subjected to integrity checks and result aggregation. The verified blocks that pass the verification are integrated into trusted components to obtain the verification integration result. Integrity verification can be a comprehensive consistency check of verified blocks to ensure no omissions or out-of-order errors. In an exemplary embodiment, integrity verification can compare the number of verification blocks, identifier continuity, and aggregate hash values. Furthermore, integrity verification can prevent component reconstruction errors due to partial block verification failures or loss. Result aggregation can be the process of recombining the verification blocks that have passed integrity verification into a complete and trusted component in their original order. The verification integration result can be a complete and trusted component image formed after result aggregation. Furthermore, the verification integration result can serve as valid input for subsequent loading and execution.

[0099] The verification and integration results are recorded in the trusted boot log, including verification block location information, security area identifier and verification timestamp. The boot completion status is returned through the domestic trusted computing chip, and the trusted boot execution result is obtained.

[0100] The trusted startup log can be an immutable log recording key metadata of the entire block verification process. In this embodiment, the trusted startup log can be written to a storage area protected by a domestically produced trusted computing chip. Furthermore, the trusted startup log can support post-audit, remote proof, and fault backtracking. The verification block location information can be the offset address or logical location of the verification block within its respective component. Furthermore, the verification block location information can ensure that the verification block can correctly restore the original component structure during result aggregation. The security area identifier can be a label indicating the verification area (high security or basic) to which the verification block belongs. Furthermore, the security area identifier can be used for log analysis and policy optimization, reflecting the verification intensity distribution. The verification timestamp can be the precise time when each verification block completes verification. Furthermore, the verification timestamp can support performance analysis and attack sequence correlation analysis. The startup completion status can be a system ready signal returned by the domestically produced trusted computing chip after confirming that all components have passed verification. In a specific embodiment, the startup completion status can be determined based on the integrity of the trusted startup log and the consistency of the verification integration results. Furthermore, the startup completion status can serve as an authorization credential for the formal loading of the operating system.

[0101] For example, in the scenario of a government-sponsored mobile phone startup, the trusted startup method of the mobile terminal in this embodiment can be as follows: The system performs a risk assessment on components such as the Bootloader, kernel, and graphics driver according to the startup protection scheme. It finds that the kernel risk level (0.85) is higher than the threshold (0.7), so it is classified into the high-security verification zone, while the graphics driver (0.4) is classified into the basic verification zone. Then, the kernel is divided into 256 verification blocks with a block size of 4KB, and each block is assigned a unique identifier such as 'kernel_0x1000_0'. The verification management unit starts a two-layer structure: the high-security zone calls the domestic hardware encryption module to verify the SM2 signature of each block in parallel, and the basic zone calculates the SM3 hash of the driver block. During the verification process, if the high-security zone detects an abnormal signature of a block, it immediately suspends the loading of the basic zone through the collaborative verification channel. After all blocks are verified, the system verifies the block continuity and aggregate hash, and reassembles the kernel image. Finally, the log containing the location, region identifier, and timestamp of each block is written to trusted storage. After the domestic trusted computing chip confirms that there are no errors, it releases the startup completion state, and the operating system loads normally.

[0102] Furthermore, to achieve the above objectives, the present invention also provides a trusted boot system for domestically developed mobile terminals, the system comprising: The feature construction module is used to perform hierarchical sequential verification and security status monitoring of the hardware root of trust module, secure boot firmware and operating system kernel in the domestically developed mobile terminal, to obtain a multi-dimensional security feature set and construct a system security feature vector. The graph optimization module is used to construct the dependency graph of the trust chain components and perform constraint optimization to minimize security risks, thereby obtaining a trusted startup sequence. The intelligent risk control module is used to intelligently identify and classify potential threats in the startup process based on the trusted startup sequence and the system security feature vector, and obtain a layered security protection strategy. The dynamic verification module is used to dynamically adjust the layered security protection strategy and calculate the resource allocation weight to obtain the startup protection scheme. It also divides the trusted component loading process into a high-security verification area and a basic verification area for block verification to obtain the trusted startup execution result.

[0103] Other embodiments or specific implementations of the trusted boot system for domestically developed mobile terminals described in this invention can be found in the above-described method embodiments, and will not be repeated here.

[0104] Furthermore, to achieve the above objectives, the present invention also provides a trusted boot device for a domestically developed mobile terminal, the device comprising: a memory, a processor, and a trusted boot program for the domestically developed mobile terminal stored in the memory and executable on the processor, the trusted boot program for the domestically developed mobile terminal being configured to implement the steps of the trusted boot method for the domestically developed mobile terminal as described in any of the above descriptions.

[0105] In addition, to achieve the above objectives, the present invention also provides a medium storing a trusted boot program for a domestically developed mobile terminal, wherein when the trusted boot program for the domestically developed mobile terminal is executed by a processor, the trusted boot method for the domestically developed mobile terminal as described above is implemented.

[0106] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A trusted boot method for a domestically developed mobile terminal, characterized in that, The method includes: Hierarchical sequential verification and security status monitoring are performed on the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal to obtain a multi-dimensional security feature set and construct a system security feature vector. Construct a trust chain component dependency graph and perform constraint optimization to minimize security risks to obtain a trusted startup sequence; Based on the trusted startup sequence and the system security feature vector, potential threats in the startup process are intelligently identified and risk-classified to obtain a layered security protection strategy. The layered security protection strategy is dynamically adjusted and resource allocation weights are calculated to obtain the startup protection scheme. The trusted component loading process is divided into a high-security verification area and a basic verification area for block verification to obtain the trusted startup execution result.

2. The trusted boot method for a domestically developed mobile terminal as described in claim 1, characterized in that, The hierarchical sequential verification and security status monitoring of the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal yields a multi-dimensional security feature set, and a system security feature vector is constructed, including: A hierarchical sequential verification is performed on the hardware root trust module, secure boot firmware, and operating system kernel in the domestically developed mobile terminal to obtain the verification execution sequence. Based on the verification execution sequence, the hardware trust root state, firmware integrity measurement value and kernel boot parameters are obtained, and a system security state matrix is ​​constructed. The historical boot log is divided into time windows, and the security event occurrence rate, verification failure number and threat type distribution are statistically analyzed in each first time window to obtain a security behavior statistical matrix. The system security state matrix and the security behavior statistics matrix are concatenated to obtain a time-series security feature sequence. Based on the time-series security feature sequence, the system security situation and threat evolution trend are modeled to obtain a multi-dimensional security feature set. Based on the multidimensional security feature set, hardware features, firmware features, and software features are extracted respectively, and a system security feature vector is constructed.

3. The trusted boot method for a domestically developed mobile terminal as described in claim 2, characterized in that, Based on the multi-dimensional security feature set, hardware features, firmware features, and software features are extracted respectively, and a system security feature vector is constructed, including: The multidimensional security feature set is input into the bottom-level security feature extraction network for feature map calculation to obtain the basic hardware feature matrix. The bottom-level security feature extraction network contains three convolutional layers and two fully connected layers. Each convolutional layer uses the ReLU activation function and a max pooling layer. The basic hardware feature matrix is ​​input into the mid-layer security feature extraction network for residual calculation to obtain the firmware integrity feature matrix. The mid-layer security feature extraction network uses four residual blocks, each containing two convolutional layers and one skip connection, and a BatchNorm layer is added between the residual blocks. The firmware integrity feature matrix is ​​input into the high-level security feature extraction network for threat correlation analysis to obtain the threat scenario feature matrix. The high-level security feature extraction network uses a transformer encoder structure and includes six multi-head self-attention layers and feedforward neural network layers. The system security feature vector is obtained by weighted fusion and normalization of the basic hardware feature matrix, the firmware integrity feature matrix, and the threat scenario feature matrix.

4. The trusted boot method for a domestically developed mobile terminal as described in claim 1, characterized in that, The process of constructing a trust chain component dependency graph and performing constraint optimization to minimize security risks to obtain a trusted startup sequence includes: A trust chain component dependency graph is constructed based on the startup dependency relationship between trust chain components. The edge weights of the trust chain component dependency graph represent the verification latency between components, and the node weights represent the security risk level of the components. Based on the trust chain component dependency graph, security risk constraints are set, including: the overall security risk does not exceed a preset threshold, the verification time of any component is earlier than the start time of its dependent components, and the verification time interval between adjacent components is not less than the minimum security period, thus obtaining a set of constraints. Based on the set of constraints, a graph neural network is used to calculate the dependency graph of the trust chain components to obtain the component security feature matrix. The component security feature matrix is ​​then used to determine the verification order and time allocation of the components to obtain an initial verification scheme. The initial verification scheme is constrained and verified, the actual security risks and verification costs of each component are calculated, and the optimization problem of minimizing security risks is solved based on the Lagrange multiplier method to obtain the optimal verification scheme. Based on the optimal verification scheme, the verification priority and execution order of the components that meet the sequential verification requirements are determined to obtain a trusted startup sequence.

5. The trusted boot method for a domestically developed mobile terminal as described in claim 1, characterized in that, The method of intelligently identifying and risk-classifying potential threats during the startup process based on the trusted startup sequence and the system security feature vector, resulting in a layered security protection strategy, includes: The trusted startup sequence and the system security feature vector are concatenated and linearly transformed to obtain a security input feature sequence. The security input feature sequence is then input into the forward LSTM layer and the backward LSTM layer respectively to obtain a bidirectional security feature vector. Temporal attention calculation is performed on the bidirectional security feature vector to obtain a security context feature vector. Threat correlation analysis is performed based on the security context feature vector, and weighted by combining it with historical threat data to obtain a threat prediction sequence. Based on the threat prediction sequence, risk scores and rankings are performed on each threat type to obtain a security protection priority list. Resource quotas are then allocated to each type of security measure based on the security protection priority list to obtain a layered security protection strategy.

6. The trusted boot method for a domestically developed mobile terminal as described in claim 1, characterized in that, The layered security protection strategy is dynamically adjusted and resource allocation weights are calculated to obtain a startup protection scheme. The trusted component loading process is divided into a high-security verification area and a basic verification area for block verification to obtain a trusted startup execution result, including: The security tasks in the layered security protection strategy are reordered to obtain an initial security scheduling sequence; The initial security scheduling sequence is divided into multiple second time windows, and the system security status within each second time window is dynamically monitored to obtain a security status sequence. The comprehensive security weight within each second time window is calculated based on the security state sequence, and the execution time of the security task is adjusted according to the comprehensive security weight to obtain a task scheduling scheme. A resource usage limit is set for each task in the task scheduling scheme, and the security resource allocation rate is controlled by the token bucket algorithm to obtain the startup protection scheme. According to the startup protection scheme, the trusted component loading process is divided into a high-security verification area and a basic verification area, and block verification is performed through domestic hardware encryption modules and parallel verification technology to obtain trusted startup execution results.

7. The trusted boot method for a domestically developed mobile terminal as described in claim 6, characterized in that, The process of loading trusted components is divided into a high-security verification area and a basic verification area according to the startup protection scheme, and block verification is performed through domestic hardware encryption modules and parallel verification technology to obtain trusted startup execution results, including: The trusted components in the startup protection scheme are divided into regions according to their security risk levels. Components with security risks higher than the threshold are assigned to the high-security verification zone, and components with security risks lower than the threshold are assigned to the basic verification zone, thus obtaining a component partitioning scheme. The components to be verified in the component partitioning scheme are divided into blocks. Each component is divided into several verification blocks according to a preset block size, and a unique identifier is assigned to each verification block to obtain a verification block sequence. A two-layer verification structure is constructed based on the verification block sequence. A fast signature verification module based on domestic cryptographic algorithms is set in the high-security verification area, and a lightweight hash verification module is set in the basic verification area. A collaborative verification channel between the two areas is established to obtain the verification management unit. Based on the identifier of the verification block and the verification management unit, verification resources are allocated, and different verification blocks of the same component are verified in parallel through the domestic hardware encryption module, and the verification status is recorded in real time to obtain a verification progress table. Based on the verification schedule, the verified blocks are subjected to integrity checks and result aggregation. The verified blocks that pass the checks are integrated into trusted components to obtain the verification integration result. The verification integration results are recorded in the trusted startup log, including verification block location information, security area identifier and verification timestamp. The startup completion status is returned through the domestic trusted computing chip to obtain the trusted startup execution result.

8. A trusted boot system for a domestically developed mobile terminal, characterized in that, The system includes: The feature construction module is used to perform hierarchical sequential verification and security status monitoring of the hardware root of trust module, secure boot firmware and operating system kernel in the domestically developed mobile terminal, to obtain a multi-dimensional security feature set and construct a system security feature vector. The graph optimization module is used to construct the dependency graph of the trust chain components and perform constraint optimization to minimize security risks, thereby obtaining a trusted startup sequence. The intelligent risk control module is used to intelligently identify and classify potential threats in the startup process based on the trusted startup sequence and the system security feature vector, and obtain a layered security protection strategy. The dynamic verification module is used to dynamically adjust the layered security protection strategy and calculate the resource allocation weight to obtain the startup protection scheme. It also divides the trusted component loading process into a high-security verification area and a basic verification area for block verification to obtain the trusted startup execution result.

9. A trusted boot device for a domestically developed mobile terminal, characterized in that, The device includes: a memory, a processor, and a trusted boot program for a domestically developed mobile terminal stored in the memory and executable on the processor, wherein the trusted boot program for the domestically developed mobile terminal is configured to implement the steps of the trusted boot method for a domestically developed mobile terminal as described in any one of claims 1 to 7.

10. A medium, characterized in that, The medium stores a trusted boot program for a domestically developed mobile terminal, and when the trusted boot program for the domestically developed mobile terminal is executed by a processor, it implements the steps of the trusted boot method for a domestically developed mobile terminal as described in any one of claims 1 to 7.

Images