A node security protection method for a mobile terminal device

Abstract

The application discloses a kind of node security protection methods of mobile terminal equipment, and the application relates to terminal security technical field, the method is attached to the outside input data of entering terminal Pollution label and along processing link transmission forms blood relationship chain record, intercepts the cross-node call request initiated by artificial intelligence intelligent agent node, analyzes blood relationship chain record and combines source credibility, path integrity and operation sensitivity Calculation security context trust score, according to trust score by trusted execution environment derived authority upper limit set, with request authority intersection obtains actual granted authority, and when linkage trusted user interface is completed out-of-band secondary confirmation when authority is degraded and involves high sensitive operation, and generates one-time micro-certificate control call release, node switches environment based on hash chain check security context continuity, the application realizes the change from static identity judgment right to dynamic intention judgment right, can identify and block obfuscated proxy attack.

Description

Technical Field

[0001] This invention relates to the field of terminal security technology, specifically to a method for protecting the node security of a mobile terminal device. Background Technology

[0002] With the accelerated deployment of large language models to mobile terminals, mobile devices are gradually evolving into an interactive architecture centered on artificial intelligence agents. These agents are typically granted high system-level calling privileges by the mobile terminal operating system to complete complex tasks across multiple functional nodes such as address book nodes, SMS nodes, and payment interface nodes. Examples include automatically reading album content and forwarding it to designated contacts, completing money transfers on behalf of users, and automatically filling out and submitting forms based on web page content. Because agents have the ability to autonomously perceive external inputs such as web pages, SMS messages, and voice messages and call system interfaces accordingly, once specially designed misleading instructions are implanted in the external input data, the agent may be induced to perform operations that deviate from the user's true intentions without violating its own permission rules. This type of attack is often called a prompt injection attack. Since the agent itself holds legitimate high-level system privileges, attackers often use the agent's legitimate identity to indirectly complete operations that they originally did not have permission to perform, forming a confusing proxy-style attack chain. Its degree of harm and concealment are higher than traditional unauthorized access attacks.

[0003] Mobile terminal operating systems generally adopt application sandbox isolation mechanisms. Each application process runs in an independent sandbox environment. Inter-process communication can only be completed after identity verification by the operating system kernel. Its permission model is usually based on application identity and user authorization: when an application is installed or when it first calls a sensitive interface, it requests specific permissions from the user. After the user agrees, the permission remains basically static and valid in the subsequent running cycle of the application.

[0004] The closest existing technology to this invention is a static permission allocation scheme based on application sandbox isolation. Its main implementation steps are as follows: when an application is installed or calls a sensitive interface for the first time, it requests specific permissions from the user, such as reading the address book and sending SMS messages. After the user agrees, the operating system marks the application's identity as authorized in the permission management database. Subsequently, when the application and its built-in artificial intelligence agent module call system interfaces, the operating system only verifies whether the application identity of the initiating process matches the record in the permission database. If they match, execution is allowed, and the source and credibility of the input data on which the call depends are no longer considered. The structure of this scheme includes three parts: an application sandbox container, a permission management service, and a system interface gateway. The application sandbox container is responsible for isolating the running environment of each application, the permission management service is responsible for maintaining the static mapping relationship between application identity and permissions, and the system interface gateway is responsible for intercepting cross-process calls and initiating identity queries to the permission management service.

[0005] However, the aforementioned existing technologies have significant shortcomings. First, existing permission models rely solely on application identity as the basis for authorization judgment, neglecting the source of the input data driving the current call. Therefore, when the AI ​​agent receives instructions injected with prompts embedded in untrusted external data such as hidden text on web pages or malicious text messages, the operating system cannot distinguish whether the instruction represents the user's true intent or an attacker's forged intent. Second, since the AI ​​agent already possesses legitimate high-level permissions, the operating system treats all its call requests as legitimate operations and allows them to proceed. This leads to the AI ​​agent, after being hijacked by malicious prompts, using its own legitimate identity to complete unauthorized operations pre-set by the attacker, creating confusion. Furthermore, the existing proxy-based attack chain is problematic because once granted, permissions remain statically valid for a long lifespan, lacking a dynamic tightening or downgrading mechanism based on real-time context. Even if the system detects anomalies afterward, it is difficult to intercept the attack at the moment it occurs, potentially leading to serious consequences such as privacy data leakage and asset loss. In addition, simply introducing a strong authentication mechanism based on public-key cryptography to improve security would significantly increase the terminal's computational overhead, affecting user experience and battery life. How to strike a balance between security strength and terminal performance is a problem that existing technologies have not yet adequately solved. To address this, we propose a node security protection method for mobile terminal devices. Summary of the Invention

[0006] The purpose of this invention is to provide a method for protecting the node security of mobile terminal devices.

[0007] To address the shortcomings of the existing technologies, the technical problem this invention aims to solve is: in scenarios where mobile terminal devices deploy edge-side AI agents and are endowed with the ability to schedule system resources such as address books, SMS messages, and payment interfaces across nodes, how can the operating system perceive whether the input data of the agent has been contaminated by prompts from untrusted external data, thereby identifying and blocking attackers from performing obfuscated proxy-style unauthorized operations using the agent's legitimate high-privilege identity? Simultaneously, how can dynamic identification, permission downgrading, and secondary confirmation interception of such attacks be achieved without introducing excessive computational overhead or significantly increasing terminal power consumption?

[0008] To address the aforementioned technical problems, this invention provides a node security protection method for mobile terminal devices, comprising the following technical solutions: Adding an initial contamination tag to external input data entering the mobile terminal via a system input interface. The initial contamination tag includes a source category identifier, an initial source credibility value, and a timestamp. When an AI agent node reads external input data with the initial contamination tag and generates an output instruction to initiate a cross-node call, a tag inheritance operation is performed on the output instruction. The initial contamination tag is passed along the data processing link and superimposed on the metadata of the output instruction to form a corresponding lineage chain record. The cross-node system interface call request initiated by the AI ​​agent node is intercepted. The lineage chain record is parsed and feature quantities are extracted. Based on this, a security context trust score for the current call request is calculated. The security context trust score is compared with a preset multi-level threshold. The system determines the processing level of the current call. If the determination result is a downgraded permission processing level or a blocked confirmation processing level, the Trusted Execution Environment (TEE) security kernel determines the upper limit set of permissions based on the trust score and takes the intersection with the requested permission set to obtain the actual granted permission set. If the actual granted permission set is empty, the call is rejected. If the actual granted permission set is a proper subset of the requested permission set and involves highly sensitive capabilities, the system links the trusted user interface to complete out-of-band secondary confirmation. The TEE security kernel generates a micro-credential corresponding to the current call and returns it along with the actual granted permission set to the system interface gateway. The gateway then allows the call operation that meets the conditions. When the AI ​​agent node undergoes application sandbox or network environment switching, the system also performs continuity verification of the security context before and after the switch based on hash chain operation to prevent attackers from bypassing the aforementioned protection mechanism by taking advantage of the state transition window.

[0009] The present invention also provides a node security protection system that is compatible with the above method, and a computer-readable storage medium storing the corresponding computer program, for deploying and implementing the above method at the mobile terminal operating system level.

[0010] Compared with the prior art, the beneficial effects of the present invention by adopting the above technical solution are as follows:

[0011] 1. This invention establishes a transferable and traceable lineage tagging system for data and instructions flowing across nodes, and calculates a security context trust score by combining source credibility, transmission path integrity, and target operation sensitivity. This transforms permission determination from relying on static application identity to relying on dynamic data lineage. Under the permission downgrade processing level and the blocking confirmation processing level, it triggers permission narrowing and out-of-band secondary confirmation for highly sensitive operations such as fund transfers and sensitive information outgoing. This prevents attackers from performing obfuscated proxy-style unauthorized operations by using the legitimate identity of the intelligent agent, thus making up for the shortcomings of existing static permission allocation schemes that cannot perceive the credibility of input data.

[0012] 2. This invention dynamically derives fine-grained, single-use capability downgrade micro-credentials based on the security context trust score, narrowing the actual usable permissions of high-privilege agents in contaminated scenarios to a range that matches the current trust level. When a highly sensitive operation is detected, it triggers out-of-band secondary confirmation in conjunction with the trusted user interface, further reducing the risk of loss caused by unauthorized operations, while not affecting the normal user experience in scenarios with a high level of trust.

[0013] 3. The generation and verification of the micro-credentials in this invention are completed based on symmetric key operations, and the continuity verification of the security context is completed based on a lightweight hash chain. Neither of them relies on a public key cryptography system. This can ensure security strength while taking into account the computing performance and battery life of the terminal, and adapt to the actual deployment environment where mobile terminal resources are limited. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the overall main process in an embodiment of the present invention;

[0015] Figure 2 This is a schematic diagram of the micro-credential generation and permission verification sub-process in an embodiment of the present invention;

[0016] Figure 3 This is a schematic diagram of the environment switching hash chain continuity verification process in an embodiment of the present invention. Detailed Implementation

[0017] The following is in conjunction with the appendix Figure 1-3 The specific embodiments of the present invention will be further described below. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0018] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0019] The mobile terminal device node security protection method proposed in this invention runs in the collaborative architecture of the normal execution environment and the trusted execution environment of the mobile terminal operating system. The main chip of the processor in the mobile terminal hardware layer has a trusted execution environment security area that is physically isolated from the normal execution environment. This security area has an independent computing unit and a secure storage area, which is used to execute key security logic and protect sensitive data such as keys from being read by programs running in the normal execution environment. The node security protection system that is compatible with this method mainly includes a data lineage tracing module, a security context calculation module, a micro-credential generation and derivation module, a zero-trust verification module, and a trusted user interface interaction module.

[0020] At the system architecture level, the ordinary execution environment, starting from the external input source, sequentially includes AI agent nodes, other application nodes, and the inter-process communication bus of the operating system kernel. The external input sources include various types of external data sources such as web pages, SMS messages, and voice messages. The data lineage tracking module is embedded in the inter-process communication bus using a tag-passing method to continuously attach, transmit, and update pollution tags to the data and instructions flowing through the bus. The trusted execution environment deploys a security context computation module, a micro-credential generation and derivation module, and a key management function unit. It interacts with the ordinary execution environment through a pre-established secure channel. The key management function unit is responsible for generating and storing the symmetric key used for micro-credential computation; this key does not leave the trusted execution environment. At the execution environment boundary, the trusted user interface module is directly connected to the trusted execution environment through a secure display path independent of the ordinary execution environment. This secure display path is independent of the graphics rendering link of the ordinary operating system and is used to prevent malicious programs running in the ordinary execution environment from intercepting or tampering with out-of-band secondary confirmation information by means of overlay display, simulated clicks, etc. Data from external input sources enters the artificial intelligence agent node after being tagged with lineage tags. Cross-node call requests initiated by the agent node enter the trusted execution environment through the inter-process communication bus carrying lineage tags for security context calculation and micro-credential derivation. When it is determined that user confirmation is required, the trusted execution environment invokes the trusted user interface through a secure channel to complete out-of-band confirmation before allowing it to pass to the target node.

[0021] Regarding data lineage tracing and contamination tag generation, when data from external input sources enters the terminal via the system input interface, the operating system kernel appends an initial contamination tag to the metadata header of the data object. The tag includes a source category identifier, an initial source credibility value, and a timestamp. The source category identifier distinguishes whether the data originates from a webpage, SMS, voice message, or a third-party interface return result. The initial source credibility value quantifies the inherent credibility of that source type. When an AI agent node reads this tagged data and generates inference output—the proposed cross-node call instruction—the operating system kernel performs tag inheritance on this output instruction. The operation transmits the pollution label of the input data downstream along the data processing link and superimposes it into the metadata of the output instruction, forming the lineage record of the instruction. This lineage record can be represented as an ordered chain composed of several entries. Each entry records the node identifier, timestamp, and corresponding credibility increment involved in a data flow, thereby supporting the tracing of the complete data source of the instruction. When the agent initiates a cross-node system interface call, the inter-process communication bus of the operating system intercepts the call request, parses the lineage record it carries, and extracts features such as the initial credibility value of the source, the length of the transmission path, and whether the path passes through untrusted nodes.

[0022] Furthermore, the extracted features are input into the security context calculation module to calculate the trust score for this call request, as follows:

[0023] ;

[0024] In the above formula, This indicates the security context trust score for this cross-node call request. This represents the credibility score of the original input source in the instruction's lineage chain, ranging from 0 to 1. A higher score indicates a direct user input source, while a lower score indicates an unverified external webpage or SMS message source. This score represents the integrity of the bloodline transmission path; the more nodes in the path and the more unreliable nodes in the route, the lower the score. This represents the sensitivity score of the target operation itself. The higher the sensitivity, such as transferring money or sending text messages, the lower the value of this item. , , The corresponding weight coefficients, and satisfying The specific values ​​can be pre-configured according to the terminal security policy, or can be dynamically adjusted by the backend risk model based on historical attack samples.

[0025] Trust score The security level of this call is determined by comparing it with preset multi-level thresholds: if... If the value exceeds the preset high trust threshold, it is determined to be a normal release level. If the value is between the preset low trust threshold and the preset high trust threshold, it is determined to be a permission downgrade. If the value is below the preset low trust threshold, it is determined to be a blocking confirmation processing level.

[0026] Regarding the dynamic downgrade generation of fine-grained micro-credentials, when the judgment result is a permission downgrade processing level or a blocking confirmation processing level, the system enters this stage. The Trusted Execution Environment (TEE) security kernel generates a limited-capability one-time micro-credential in real time. The TEE security kernel receives the call request information forwarded by the ordinary execution environment, including the initiating node identifier, target interface identifier, and security context trust score. In addition to lineage tag summaries, the trusted execution environment kernel is based on trust scores. The pre-defined permission downgrade mapping strategy table is queried to determine the permission limit set corresponding to this request. This permission limit set has a monotonically increasing relationship with the trust score, and an asymmetric tightening strategy is adopted for operation types with different sensitivity. That is, under the same trust score, the permission tightening for operations involving fund changes is greater than that for read-only operations. This overcomes the common practice in the field of applying a uniform tightening ratio to all operation types. For example, when the trust score is in a high range, the permission limit set can cover read operations and non-fund notification sending operations. When the trust score is in a medium range, the permission limit set only retains read-only operations and does not include operations involving fund changes or actively sending information to the outside. When the trust score is in a low range, the scope of the permission limit set is further narrowed, and only low-risk operations such as alarm prompts to the user are retained.

[0027] The set of permissions actually granted in this call request is calculated as follows:

[0028] ;

[0029] In the above formula, This indicates the actual set of permissions granted to this call. This represents the set of permissions declared by the AI ​​agent node in this request. Indicated by trust score The determined set of upper limit permissions, symbol This represents the intersection operation of two permission sets;

[0030] like If the set is empty, meaning the requested permissions and the set of maximum permissions have no intersection, then the trusted execution environment kernel directly rejects the call and returns a rejection response to the normal execution environment. for A proper subset of the condition, i.e., a permission downgrade occurs and the operation is determined to involve highly sensitive capabilities, such as fund transfers or the external transmission of sensitive information, is selected. In this case, the trusted execution environment kernel, while generating the downgraded micro-credential, simultaneously invokes the trusted user interface module through a secure channel. This module displays the initiating node of the call, the target operation, and the risk level assessment information to the user. The user then completes out-of-band secondary confirmation within the secure display area. Micro-credential generation can only proceed after user confirmation. If the user refuses or fails to respond within the timeout period, the call is terminated. equal If so, a normal micro-voucher will be generated directly;

[0031] The trusted execution environment kernel generates the micro-credential for this call based on a symmetric key algorithm, as follows:

[0032] ;

[0033] In the above formula, This represents the value of the micro-voucher generated this time. This refers to keys securely stored within a trusted execution environment. The hash message authentication code is calculated for the key. Indicates the node identifier that initiated the call. This indicates the contamination tag digest value of the bloodline chain in this call. This refers to a one-time random number generated by a trusted random number generator within a trusted execution environment. This ensures that each generated micro-credential is unique and protects against replay attacks. The timestamp representing the generation of the micro-credential is provided by the trusted clock of the trusted execution environment and is used to limit the validity period of the micro-credential. This indicates that the above fields are concatenated sequentially.

[0034] The trusted execution environment kernel will generate micro credentials Together with the actual set of permissions granted The request is then forwarded to the system interface gateway in the normal execution environment, which then simply allows the request. Within the scope and carrying a valid micro-certificate The specific invocation operation is such that the micro-credential expires immediately after a single invocation is completed or after the preset validity period is reached, and cannot be reused, thus strictly limiting the actual capability of the invocation to a range that matches the current level of trust.

[0035] Regarding lightweight zero-trust verification based on a trusted execution environment architecture, to prevent security context distortion caused by hijacking during state handover when AI agent nodes switch between different application sandboxes or network environments, this invention adopts a lightweight state continuity verification scheme based on hash chains. When a node first establishes a security context, the trusted execution environment kernel generates an initial state hash value. The node identifier and initial trust score are stored together in the Trusted Execution Environment's secure storage area. When a node undergoes a state transition event, such as migrating from one application sandbox to another, or when the network environment changes, the Trusted Execution Environment kernel collects the state information involved in this transition. This includes the sandbox identifier and network environment identifier before and after the handover, as well as the context change parameters corresponding to this handover. This includes the increase in the trust score recalculated after this switch;

[0036] The hash value of the new state after this state transition is calculated as follows:

[0037] ;

[0038] In the above formula, Indicates the first The state hash value after the next state transition. This represents the state hash value saved after the last switch was completed. This indicates lightweight hash function operations. This indicates the status information collected during this switchover. Indicates the context change parameters for this switch, symbol This indicates sequential concatenation operations;

[0039] The Trusted Execution Environment kernel will newly computed The state information is compared and verified with the state information re-reported by the node in the target environment. If they match, it is determined that the state transition has not been tampered with, the security context continuity is maintained, and the node is allowed to continue using its current trust score and permission downgrade policy in the new environment. If they do not match, it is determined that there is an anomaly in the state handover process, the node's trust score is reset to the preset baseline level, and the data lineage tracing and trusted user interface secondary confirmation process are retried. The trusted execution environment kernel is updated. Replace the original It is persistently stored as the baseline value for the next state transition verification, forming a continuous hash chain to achieve zero-trust continuous verification across nodes and environments. Moreover, this process only involves symmetric hash operations, does not rely on public key certificate systems, has extremely low computational overhead, and is suitable for long-term continuous operation in environments with limited mobile terminal resources.

[0040] The aforementioned data lineage tracking module, security context calculation module, micro-credential generation and derivation module, and zero-trust verification module work together in actual operation: the data lineage tracking module continuously tags the data flowing across nodes and supports the calculation of trust scores, which serve as the input basis for the security context calculation module to determine the security level. The determination result of the security context calculation module triggers the micro-credential generation and derivation module to complete the permission downgrade and credential issuance within the trusted execution environment. When necessary, it links with the trusted user interface to complete out-of-band confirmation. The zero-trust verification module continuously verifies the continuity of the security context in scenarios where the node undergoes a state transition, preventing attackers from bypassing the aforementioned protection mechanism by taking advantage of the state transition window. Together, these modules form a closed loop of node security protection covering the entire chain of input perception, intent determination, permission granting, and state continuation.

[0041] The implementation process of this invention is described below using a specific application scenario. Assume an AI agent is deployed on a mobile terminal. The user requests the agent to read a newly arrived SMS message and perform corresponding operations based on its content. This SMS message is actually forged by an attacker, and the message body contains an injection instruction that induces the agent to transfer money to a designated third-party number. When the agent reads the SMS message, the operating system kernel has already appended an initial contamination label to the metadata header of the SMS data, marking its source category as SMS and setting a low initial source trust value. After the agent generates the proposed transfer call instruction based on the SMS content, this instruction inherits and superimposes the contamination label from the SMS data, forming a corresponding lineage record. When the agent initiates a cross-node transfer call, the inter-process communication bus intercepts the request and parses the lineage record, extracting features such as a low source trust score, an untrusted node in the transmission path, and the highly sensitive target operation of a transfer. The security context calculation module calculates a trust score lower than a preset low trust threshold, thus determining that the confirmation process should be blocked. After querying the permission downgrade mapping policy table, the trusted execution environment kernel determines that the set of upper limit permissions corresponding to this request does not include direct transfer permissions. Therefore, the intersection of the request permission set and the upper limit permission set is a proper subset. Since this operation falls under a preset high-sensitivity capability, the trusted user interface module is invoked through a secure channel. The system displays the initiating node, target operation, and risk level information to the user in the secure display area, indicating that the current instruction is suspected to originate from an untrusted source. After verification, the user rejects the call, and the system immediately terminates the transfer operation, thus preventing asset loss. If the user subsequently initiates the same type of call in a trusted scenario, such as by manually entering the transfer instruction, the trust score calculated by the security context calculation module will be higher than the preset high-trust threshold due to the high source trust score in the instruction's lineage record. The system will then determine it as a normal release level, and the trusted execution environment kernel will directly generate the corresponding micro-credential and release the call without triggering secondary confirmation. This ensures security without affecting the user experience in normal scenarios.

[0042] This invention also provides two alternative implementation methods to achieve the invention's objectives. First, in situations where terminal computing power or application scenarios have high real-time requirements and cannot afford the overhead of dynamic trust score calculation, a static rule base can be pre-established for typical high-risk operations. This base stipulates that any call request containing an external untrusted source marker in the lineage tag will trigger permission downgrade and secondary confirmation via the trusted user interface, eliminating the need for continuous weighted trust score calculation. Rule matching replaces numerical computation, further reducing system resource consumption while sacrificing some judgment precision. Second, in scenarios where terminal device computing power is limited but a stable network connection is available, the calculation logic of the security context trust score and the permission downgrade mapping strategy table can be migrated to a cloud security service. The terminal trusted execution environment is only responsible for the final issuance of micro-credentials and the maintenance of the local state hash chain. After desensitization, the lineage tag features are uploaded to the cloud for risk assessment. The cloud returns the risk level for the terminal trusted execution environment to generate the corresponding micro-credential. This ensures that the core issuance process is still completed in the terminal trusted environment, while the more complex risk assessment logic is handled by cloud computing power, adapting to diverse device forms with varying terminal hardware capabilities.

[0043] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0044] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of the present invention. Therefore, any modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for node security protection of a mobile terminal device, characterized in that, include: An initial contamination tag is attached to external input data entering the mobile terminal via the system input interface. This initial contamination tag includes a source category identifier, an initial source credibility value, and a timestamp. When an AI agent node reads the external input data with the initial contamination tag and generates an output command to initiate a cross-node call, a tag inheritance operation is performed on the output command. The initial source credibility value from the initial contamination tag is numerically superimposed with the risk increment corresponding to the output command to obtain a source credibility score for the output command. The superimposed tag is then transmitted along the data processing link and written into the metadata of the output command, forming a lineage record corresponding to the output command, thus intercepting the AI ​​agent node. The system initiates a cross-node system interface call request, parses the lineage record, and extracts features including an initial source trustworthiness value, the integrity of the transmission path, and whether it passes through an untrusted node. Based on these features, a security context trust score is calculated for this cross-node system interface call request. This security context trust score is obtained by weighted summation of the source trustworthiness score, path integrity score, and target operation sensitivity score. The security context trust score is compared with preset high trust thresholds and preset low trust thresholds: if the security context trust score is higher than the preset high trust threshold, it is determined to be a normal release level; if the security context trust score is between the preset low trust threshold and the preset high trust threshold, it is determined to be a normal release level. When the security context trust score is between the threshold values, it is determined to be a permission downgrade processing level. When the security context trust score is lower than the preset low trust threshold, it is determined to be a blocking confirmation processing level. When the processing level of this call request is either the permission downgrade processing level or the blocking confirmation processing level, the trusted execution environment security kernel queries the preset permission downgrade mapping policy table based on the security context trust score to determine the permission upper limit set corresponding to this call request. Then, it performs an intersection operation between the permission set declared by the AI ​​agent node in this request and the permission upper limit set to obtain the permission set actually granted to this call request. When the permission set actually granted to this call request is empty, the call request is rejected. When the set of permissions actually granted in this call request is a proper subset of the set of permissions declared in this request, and this call involves preset highly sensitive capabilities, the trusted user interface module is invoked through a secure channel to display the initiating node, target operation, and risk level information of this call. The user is then asked to complete out-of-band secondary confirmation in the secure display area. If the user confirms, a micro-credential is generated. If the user rejects the call request or fails to receive a response from the user within a preset time period, the call is terminated. The trusted execution environment's security kernel generates the micro-credential corresponding to this call and returns the micro-credential along with the set of permissions actually granted in this call request to the system interface gateway of the normal execution environment.The system interface gateway will only allow calls that fall within the set of permissions actually granted in this call request and carry valid micro-credentials.

2. The node security protection method for a mobile terminal device according to claim 1, characterized in that: The source credibility score ranges from 0 to 1 and increases with the increase of the credibility of the external input data source. The path integrity score decreases with the increase of the number of nodes in the transmission path and decreases with the increase of the number of untrusted nodes in the transmission path. The target operation sensitivity score decreases with the increase of the target operation sensitivity.

3. The node security protection method for a mobile terminal device according to claim 1, characterized in that: The security context trust score is obtained by multiplying the source credibility score, the path integrity score, and the target operation sensitivity score by their respective weight coefficients and then summing them. The sum of the three weight coefficients is 1, and the weight coefficients are pre-configured according to the preset terminal security policy and can be dynamically adjusted according to the risk model.

4. The node security protection method for a mobile terminal device according to claim 1, characterized in that: The set of upper limit permissions is monotonically increasing with the security context trust score; the lower the security context trust score, the narrower the range of the set of upper limit permissions.

5. The node security protection method for a mobile terminal device according to claim 1, characterized in that: The micro-credential is generated by the trusted execution environment security kernel based on the key stored securely within it, combined with the node identifier that initiated the call, the contamination tag digest value of the lineage record corresponding to this call, a one-time random number, and the timestamp of this micro-credential generation, through hash message authentication code calculation. The micro-credential expires after a single call and also expires after a preset validity period.

6. The node security protection method for a mobile terminal device according to claim 1, characterized in that: The risk level information includes the corresponding level in the permission downgrade processing level and the blocking confirmation processing level to which this call belongs. The security display area is provided by a security display path independent of the normal execution environment to prevent the out-of-band secondary confirmation process from being intercepted and tampered with by programs in the normal execution environment.

7. The node security protection method for a mobile terminal device according to claim 1, characterized in that: Also includes: When the AI ​​agent node experiences at least one switching event, namely, application sandbox environment switching and network environment switching, the trusted execution environment security kernel collects the state information involved in this switching and the context change parameters corresponding to this switching. Combining the state hash value saved after the previous state switching, the state information involved in this switching, and the context change parameters corresponding to this switching, it calculates the new state hash value after this state switching. The new state hash value is compared with the state information re-reported by the AI ​​agent node in the target environment. If the comparison result is consistent, it is determined that this state switching has not been tampered with, and the AI ​​agent node is allowed to continue to use the security context trust score and permission downgrade policy before the switching in the target environment. If the comparison result is inconsistent, the security context trust score of the AI ​​agent node is reset to the preset baseline level, and the label inheritance operation and the out-of-band secondary confirmation process are retried.

8. A node security protection system for a mobile terminal device, characterized in that, include: The data lineage tracing module, located in the inter-process communication bus of the operating system kernel, is used to attach initial contamination tags to external input data entering the mobile terminal via the system input interface. When the AI ​​agent node reads the external input data with the initial contamination tags and generates an output instruction to initiate a cross-node call, it performs tag inheritance operations on the output instruction to form a lineage chain record corresponding to the output instruction. The security context calculation module, located in the trusted execution environment, is used to intercept cross-node system interface call requests initiated by the AI ​​agent node, parse the lineage chain record and extract corresponding features, calculate the security context trust score of the current call request based on the features, and compare the security context trust score with a preset high trust threshold and a preset low trust threshold to obtain the processing level of the current call request. The micro-credential generation and derivation module, located in the trusted execution environment, is used to determine the processing level of the current call request when the processing level is... When the corresponding level in the downgrade processing level and the blocking confirmation processing level is selected, the upper limit set of permissions corresponding to this call request is determined based on the security context trust score, and the set of permissions actually granted to this call request is determined in combination with the set of permissions declared in this request. A micro credential is generated for this call. The trusted user interface module is connected to the trusted execution environment through a secure display path independent of the ordinary execution environment. It is used to display the initiating node, target operation, and risk level information of this call when the set of permissions actually granted to this call request is a proper subset of the set of permissions declared in this request and this call involves preset high-sensitivity capabilities. It receives the user's out-of-band secondary confirmation result. The trusted execution environment returns the micro credential along with the set of permissions actually granted to this call request to the system interface gateway of the ordinary execution environment. The system interface gateway only allows call operations that are within the range of the set of permissions actually granted to this call request and carry a valid micro credential.

9. A node security protection system for a mobile terminal device according to claim 8, characterized in that: It also includes a zero-trust verification module, which is set in the trusted execution environment. When the AI ​​agent node experiences at least one switching event, namely application sandbox environment switching and network environment switching, it performs continuity verification on the security context before and after the switching based on hash chain operation. If the verification results are inconsistent, the security context trust score of the AI ​​agent node is reset to a preset baseline level.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the node security protection method for the mobile terminal device as described in any one of claims 1 to 7.

Images