A terminal compliance self-testing method and related equipment based on a trusted execution environment

Abstract

This application provides a terminal compliance self-testing method and related equipment based on a Trusted Execution Environment (TEE), relating to the field of information security technology. This method performs a complete compliance self-test within the local TEE of a smart terminal, ensuring the tamper-proof nature of the process and results. The method systematically collects device, peripheral, and security status information; verifies the integrity of the secure boot chain to ensure trusted booting from firmware to the application layer; checks password policies and strength verification functions; verifies whether privacy data access control and logs are compliantly recorded and free of plaintext sensitive information; detects whether the encryption algorithm implementation conforms to specifications; and confirms that a secure communication channel with the management server is enabled. Finally, a structured, digitally signed self-test report is generated within the TEE, providing highly reliable evidence for auditing and remote management, significantly improving the automation, coverage, and reliability of terminal compliance verification.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a terminal compliance self-testing method and related equipment based on a trusted execution environment. Background Technology

[0002] With increasingly stringent security requirements for communication equipment, the industry has placed systematic demands on the security architecture, data protection mechanisms, and trusted operating environments of terminal devices. Existing terminal products typically rely on a combination of manual operation and discrete tools to meet these security compliance requirements. This involves independently executing command-line instructions or calling single-function interfaces to collect basic device information, check peripheral status, verify startup logs, test encryption modules, and export permission records. This approach suffers from three major drawbacks: severe fragmentation of the testing process, insufficient automation, and non-standardized output results. Specifically, the lack of a unified scheduling mechanism for each functional module leads to incomplete coverage of testing items, easily overlooking key indicators such as secure startup integrity verification and key lifecycle status. The testing process heavily relies on the experience and judgment of technical personnel, resulting in low efficiency in scenarios involving batch deployment or periodic inspections, and human intervention increases the risk of misjudgment. Furthermore, the inconsistent log formats generated by different modules make it difficult to generate structured, auditable, and traceable compliance reports, failing to meet the stringent requirements for the integrity of the evidence chain. Summary of the Invention

[0003] This application provides a terminal compliance self-testing method and related equipment based on a trusted execution environment to solve one or more technical problems existing in the prior art, and at least provides a beneficial option or creates conditions to realize the automation, standardization and integration of the security testing process, and improve the efficiency and reliability of terminal equipment compliance verification in complex deployment environments.

[0004] On the one hand, this application provides a terminal compliance self-testing method based on a trusted execution environment. The method is executed locally by the smart terminal, and all detection steps are completed in a trusted execution environment, including the following steps: Initiate a compliance self-check procedure within a trusted execution environment; Obtain the basic device information, peripheral configuration information, and system security status information of the smart terminal; Detect whether the secure boot chain of the smart terminal has been enabled and remains intact; Check whether the user authentication password policy and password strength verification function meet the preset security requirements; Check whether functions involving access to private data have access control mechanisms, and verify whether key operation logs are recorded in accordance with security standards and whether sensitive information is stored in plaintext; The system detects whether the encryption algorithm used by the smart terminal complies with the target security specifications and whether the secure communication channel between the smart terminal and the device management server is enabled. Based on the above test results, a structured terminal compliance self-test report is generated in the trusted execution environment.

[0005] Furthermore, the basic device information includes the device model, firmware version number, hardware serial number, and authentication identifier of the radio module; the peripheral configuration information is automatically collected by calling the hardware abstraction layer interface provided by the operating system. When the smart terminal cannot obtain specific peripheral parameters through the local interface, the method further includes: Establish a secure communication connection with the manufacturing execution system in the Trusted Execution Environment. After two-way authentication initiated and verified by the Trusted Execution Environment, request and receive missing configuration data, which may include any one of the following: wireless communication frequency band support range, transmit power level, or near-field communication protocol version.

[0006] Furthermore, the system security status information includes the operating system kernel version and a list of installed security patches; the method calls the system security service interface in the trusted execution environment to obtain the security patch list, and determines whether there are any critical security patches that have not been updated for more than a preset threshold time based on the time difference between the current date and the release date of each patch; if so, it is marked as a security risk item in the terminal compliance self-inspection report, and a suggested patch update guide is attached.

[0007] Furthermore, the integrity detection of the secure boot chain includes: sequentially reading the digital signatures or hash values ​​of the bootloader, the first-stage loader, the operating system kernel, and critical system services in the trusted execution environment, and comparing them with the original trusted values ​​preset in the secure storage area of ​​the trusted execution environment; if the verification of any link fails or the value does not match, it is determined that the secure boot chain has been destroyed, and the tampered boot stage and the corresponding timestamp or version identifier are recorded in the self-inspection report.

[0008] Furthermore, the detection of the secure communication channel includes: actively initiating a connection request with the device management server in a trusted execution environment, capturing the protocol version, encryption suite, and certificate chain used during the handshake process; verifying that the protocol version is not lower than the preset minimum standard for secure communication, that the encryption suite includes a forward confidentiality mechanism, and that the server certificate is issued by a trusted certificate authority and is within its validity period; if any verification item is not met, it is determined that the secure communication channel is not enabled in accordance with the security specifications.

[0009] Furthermore, the detection of the access control mechanism includes: Register monitoring callback functions for sensitive system API calls in a trusted execution environment to intercept access requests for recording, location, camera or microphone in real time, and check whether the corresponding application has obtained explicit user authorization in the system permission management module; Iterate through the log files in the system log directory, use predefined regular expression rules to scan for plaintext strings containing sensitive personal information, and if found, mark them as log leakage risk items and record the file path and context fragments; The predefined regular expression rules are preset in the secure storage area of ​​the trusted execution environment.

[0010] Furthermore, the terminal compliance self-inspection report adopts a machine-readable format and includes the following: detection execution time, device unique identifier, compliance status of each detection item, specific description of non-compliance items, detection evidence summary, and mapping relationship between the detection items and the corresponding security requirements in the target security specification; after the report is generated, it is digitally signed by the trusted execution environment using the device private key.

[0011] On the other hand, this application provides a terminal compliance self-testing system based on a trusted execution environment, including the following functional modules deployed in a smart terminal: The self-test startup module is configured to: start a compliance self-test program in a trusted execution environment; The information acquisition module is configured to: acquire the basic device information, peripheral configuration information and system security status information of the smart terminal; The secure boot detection module is configured to: detect whether the secure boot chain of the smart terminal has been enabled and maintained in integrity; The password policy detection module is configured to detect whether the user authentication password policy and password strength verification function meet the preset security requirements. The permissions and log auditing module is configured to: detect whether functions involving access to privacy data have permission control mechanisms, and verify whether key operation logs are recorded in accordance with security specifications and whether sensitive information is stored in plaintext; The encryption and communication verification module is configured to: detect whether the encryption algorithm used by the smart terminal complies with the target security specifications, and whether the secure communication channel with the device management server is enabled; The report generation module is configured to generate a structured terminal compliance self-inspection report in the trusted execution environment based on the above-mentioned test results. All modules and their execution of detection steps run in a trusted execution environment.

[0012] On the other hand, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the aforementioned terminal compliance self-testing method based on a trusted execution environment.

[0013] On the other hand, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned terminal compliance self-testing method based on a trusted execution environment.

[0014] The beneficial effects of this application are as follows: This application provides a terminal compliance self-testing method based on a trusted execution environment (TEA). By fully executing all testing steps in the local TEA of the smart terminal, the security and tamper-proof nature of the self-testing process and results are effectively guaranteed. After starting the compliance self-testing program, this method systematically collects basic device information, peripheral configuration information, and system security status information, and verifies the activation status and integrity of the secure boot chain to ensure trusted booting from the firmware layer to the application layer. Simultaneously, this method determines whether the user authentication password policy and password strength verification function meet preset security requirements, strengthening the security protection of the identity authentication process. Regarding access to privacy data, the method further verifies the existence of the access control mechanism and confirms whether key operation logs are recorded in accordance with security specifications and that sensitive information is not stored in plaintext, thereby preventing the risk of data leakage. Furthermore, this method also detects whether the encryption algorithm used by the terminal complies with the target security specifications and verifies whether the secure communication channel with the device management server is enabled, ensuring the confidentiality and integrity of data transmission. Ultimately, all test results are integrated in a trusted execution environment to generate a structured endpoint compliance self-inspection report, providing a reliable and standardized basis for subsequent audits, certifications, or remote management. This significantly improves the automation level, test coverage, and result reliability of endpoint compliance verification. This application also provides related equipment for the above method; the beneficial effects of this equipment are similar to those of the method described above, and will not be elaborated further here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1This is a flowchart of the terminal compliance self-testing method based on a trusted execution environment provided in this application; Figure 2 This is a structural diagram of the terminal compliance self-testing system based on a trusted execution environment provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] With the widespread application of smart terminal devices in highly security-sensitive fields such as government affairs, finance, communications, and industrial control, the security and compliance capabilities of the devices themselves have become the foundation for ensuring the reliable operation of the overall information system. Terminals not only need to defend against external network attacks, but also need to ensure the integrity, authenticity, and auditability of internal hardware and software components throughout the entire process from startup to operation. Therefore, the industry generally imposes security requirements on terminals covering multiple dimensions, including device identification, secure boot, access control, encryption implementation, log auditing, and peripheral device management. These requirements are typically embodied in a series of technical specifications or compliance standards, and terminal manufacturers must complete the corresponding verification and adaptation during the product design and deployment phases.

[0023] In existing technologies, endpoint security compliance testing primarily relies on manual intervention combined with fragmented tools. Technicians typically use debugging interfaces or remote command-line tools to call system commands or dedicated scripts one by one to collect device information, check configuration status, read startup logs, test encryption interfaces, or export permission policies. While such methods can complete individual tests to some extent, the overall process is highly fragmented and lacks a unified execution framework and result integration mechanism.

[0024] Existing technologies suffer from several significant drawbacks. First, the detection process is not conducted within a protected execution environment, making the collected data and intermediate results susceptible to tampering or forgery by malicious software, thus rendering the detection conclusions unreliable. Especially when devices have been compromised or contain firmware backdoors, detection tools operating in ordinary operating system environments may return corrupted information, failing to accurately reflect the device's security status. Second, the various detection tasks are isolated, lacking logical connections and coordinated scheduling, making it difficult to cover cross-layered, complex security indicators such as secure boot chain integrity, key lifecycle management, and privacy-sensitive operation log anonymization, easily overlooking critical risk points. Third, the detection results are output in unstructured log or text format, with inconsistent formats, significant redundancy, or missing content, making them unsuitable for direct use in automated auditing, remote reporting, or compliance certification. Extensive manual processing and secondary verification are required, resulting in low efficiency and a high risk of errors. Fourth, existing solutions heavily rely on the technical experience of operators. In scenarios involving batch deployment, regular inspections, or the use of multiple device models, it is difficult to guarantee the consistency and repeatability of detection, leading to a high risk of human error. Finally, due to the lack of modular and scalable architecture, when security requirements are updated or terminal hardware platforms are iterated, the detection logic needs to be rewritten and integrated, resulting in high maintenance costs and slow response speed, which restricts the ability of terminal products to quickly adapt to new security specifications.

[0025] Furthermore, some existing solutions attempt to introduce lightweight agents to achieve partial automation. However, these agents still run in the kernel of a general-purpose operating system or in user space, are not bound to the underlying root of trust, and their own security cannot be guaranteed. They also cannot access sensitive states or key materials in the trusted execution environment, resulting in a lack of detection capabilities for TEE-related functions (such as trusted applications, secure storage, and remote authentication). Other cloud-based centralized detection solutions rely on network connectivity and cannot be used offline, in weak network, or highly secure isolated environments. Uploading raw device data to a remote location also introduces new privacy and compliance risks.

[0026] In summary, current endpoint compliance testing technologies have significant shortcomings in terms of security, integrity, automation, standardized output, and maintainability. There is an urgent need for a new method that can autonomously, in a closed-loop, and structured manner complete full-stack security compliance self-testing in a local trusted execution environment, so as to truly achieve trusted verification and efficient delivery of endpoint security status.

[0027] To address the aforementioned issues, this application provides a terminal compliance self-testing method and related equipment based on a trusted execution environment (TEA). The entire terminal compliance self-testing process is embedded within the TEA, relying on hardware-level security isolation mechanisms to ensure the integrity and tamper-proof nature of the testing logic and results. This method involves the smart terminal autonomously initiating a compliance self-testing program locally, without relying on external tools or manual intervention. It sequentially collects basic device information, peripheral configurations, and system security status; verifies the activation status and integrity of the security startup chain; checks whether the user password policy and strength meet preset requirements; confirms effective access control for privacy data and that key operation logs are recorded according to regulations, avoiding plaintext storage of sensitive information; and verifies the compliance of the encryption algorithm implementation and the activation status of the secure communication channel with the device management server. Finally, the various test results are integrated within the TEA to generate a structured terminal compliance self-testing report. The entire process achieves unified scheduling of testing logic, closed-loop verification of cross-layer security indicators, standardization of output format, and high-reliability assurance of the execution environment, significantly improving the automation level, coverage depth, and reliability of terminal compliance self-testing.

[0028] First, the terminal compliance self-testing method based on a trusted execution environment provided in this application will be described in detail below with reference to the accompanying drawings. The method is executed locally by the smart terminal, and all detection steps are completed in a trusted execution environment without the need for external detection equipment.

[0029] It should be noted that a Trusted Execution Environment (TEE) refers to a secure, isolated region built collaboratively by hardware and software. It is isolated from the ordinary operating system environment, protecting the code and data running within it from interference by external malicious programs or unauthorized operations. This environment is typically implemented based on chip-level security mechanisms (such as ARM TrustZone, Intel SGX, etc.), possessing an independent execution context and controlled resource access permissions. It is used to host highly sensitive security functions, such as key management, authentication, and integrity verification.

[0030] Terminal compliance self-testing refers to a systematic security testing process that smart terminal devices autonomously execute locally to verify whether they meet specific security specifications (such as EU 18031) or policy requirements. This process covers multiple dimensions, including device identity, boot chain, access control, encryption implementation, and logging, and ultimately generates an auditable compliance status report. It requires no external tools or manual intervention and is suitable for scenarios such as pre-deployment verification, periodic inspections, or remote authentication.

[0031] Reference Figure 1 The implementation process of the terminal compliance self-testing method based on a trusted execution environment provided in this application embodiment includes, but is not limited to, the following steps.

[0032] Step S110: Initiate a compliance self-check procedure in the trusted execution environment. Step S110, initiating the compliance self-test program within the Trusted Execution Environment (TEE), serves as the security starting point and trust anchor for the entire self-test process. This step ensures that all subsequent testing logic runs within a protected execution space isolated from the ordinary operating system and guaranteed by hardware, fundamentally preventing interference, hijacking, or result forgery by malicious software or unauthorized processes. Because the TEE has independent memory space, controlled resource access permissions, and root-based authentication capabilities, the self-test program's code integrity and execution context are guaranteed after startup in this environment, thus providing a highly reliable operational foundation for subsequent security tests.

[0033] Step S120: Obtain the basic device information, peripheral configuration information and system security status information of the smart terminal.

[0034] In step S120, basic device information and peripheral configuration information are comprehensively collected for compliance assessment to evaluate potential physical or data leakage risks. System security status information reflects the current security mechanisms enabled by the operating system, such as kernel protection features, debug interface status, and secure boot flags. This information collectively constitutes the underlying elements of the endpoint security profile, providing contextual basis and input parameters for subsequent specialized testing.

[0035] Step S130: Detect whether the secure boot chain of the smart terminal has been enabled and maintained in integrity. In step S130, it is checked whether the secure boot chain of the smart terminal has been enabled and maintained in integrity. The core objective is to verify the trustworthiness of the entire process from power-on to operating system loading. The secure boot chain ensures, through a step-by-step signature verification mechanism, that the firmware or software components loaded at each stage (such as BootROM, bootloader, kernel image) come from legitimate sources and have not been tampered with. If this chain is damaged or bypassed, attackers may implant persistent malicious code, while the system still appears to be running normally. Therefore, this step confirms whether the root of trust is effectively activated and whether the signatures of each level of components pass verification by reading the boot log, verifying the hash values ​​at each stage, or calling the platform's security service interface, thereby determining whether the terminal is truly running on a complete end-to-end trusted path.

[0036] Step S140: Check whether the user authentication password policy and password strength verification function meet the preset security requirements.

[0037] It should be noted that the password policy and password strength verification function refers to the management rules implemented by the terminal on the authentication credentials set by the user, including requirements such as minimum length, character complexity, historical password restrictions, expiration period, etc., as well as whether the system has the ability to verify password strength in real time and prevent weak password settings, in order to prevent brute-force attacks and credential reuse risks.

[0038] Critical operation logs refer to system records involving security-sensitive behaviors, such as timestamps, operation subjects, target objects, and result status of events like user login / logout, permission changes, data export, and encryption key usage. These logs must be stored in a structured manner according to security standards, and recording sensitive fields such as passwords and keys in plaintext is prohibited. They must also possess anti-deletion and anti-tampering features to support post-event auditing.

[0039] Step S140 checks whether the user authentication password policy and password strength verification function meet the preset security requirements, focusing on the security protection capabilities of the identity authentication process. This step checks whether the system enforces policies such as minimum password length, character complexity combinations, restrictions on historical password reuse, and expiration periods, and verifies whether the system has a real-time strength assessment mechanism when users set new passwords, capable of identifying and rejecting weak passwords (such as consecutive numbers, common dictionary words, etc.). Strong password policies are the first line of defense against brute-force attacks, credential guessing, and lateral movement attacks; their absence or lax configuration will greatly increase the risk of unauthorized access. This step objectively assesses the terminal's compliance level in user identity management by reading the security policy configuration file, simulating the password setting process, or calling the authentication service interface.

[0040] For example, the system enforces the following policy: passwords must be at least 8 characters long and contain at least three of the following: uppercase letters, lowercase letters, numbers, and special characters. The TEE reads the currently active password policy parameters by calling system security service interfaces (such as Android's LockPatternUtils or the policy configuration file of the Linux PAM module). To further verify that the verification logic is truly effective, the TEE simulates a user setting a weak password (such as "123456") in an isolated environment and listens for system rejection via callbacks, returning a "password strength insufficient" error code. If the system accepts the weak password or does not trigger verification, the function is deemed not to be correctly enabled. This detection ensures that not only does the policy configuration exist, but its execution path has also not been bypassed.

[0041] Step S150: Check whether the functions involving access to privacy data have an access control mechanism, and verify whether the key operation logs are recorded in accordance with security specifications and whether sensitive information is stored in plaintext.

[0042] Step S150 checks whether functions involving access to privacy data have access control mechanisms and verifies whether key operation logs are recorded in accordance with security standards and without storing sensitive information in plaintext, aiming to protect user privacy and operational auditability. On one hand, the system must implement explicit authorization mechanisms for access to sensitive data such as location, contacts, photos, and sensors, ensuring that applications only obtain necessary permissions with user permission and supporting dynamic revocation. On the other hand, all key actions involving permission changes, data export, and account login must generate structured logs, recording the operation subject, time, object, and result, and strictly prohibiting the storage of sensitive fields such as passwords, keys, and biometrics in plaintext. This step comprehensively assesses the terminal's compliance with privacy protection and audit trail requirements by checking permission model configuration, simulating privacy data access requests, and parsing system log content.

[0043] Step S160: Detect whether the encryption algorithm used by the smart terminal complies with the target security specifications, and whether the secure communication channel between the smart terminal and the device management server is enabled.

[0044] In step S160, it is checked whether the encryption algorithm used by the smart terminal complies with the target security specifications, and whether the secure communication channel between the terminal and the device management server is enabled, focusing on the security of data during static storage and dynamic transmission. Regarding encryption algorithms, it is necessary to confirm whether the symmetric encryption (such as AES), asymmetric encryption (such as RSA, ECC), hash functions (such as SHA-256), and random number generators used by the terminal meet industry-recognized standards, and whether there are issues such as the use of weak algorithms (such as MD5, DES) or insecure implementations (such as hard-coded keys or insufficient entropy sources). Regarding the secure communication channel, it is necessary to verify whether the terminal and the management server have established an encrypted connection through protocols such as TLS, whether two-way certificate authentication has been completed, and whether enhanced features such as forward secrecy have been enabled. This step ensures that the terminal has sufficient cryptographic strength in data encryption / decryption and remote interaction by calling encryption library interfaces, analyzing the network handshake process, and checking certificate configurations.

[0045] Step S170: Based on the above test results, generate a structured terminal compliance self-inspection report in the trusted execution environment.

[0046] In step S170, based on the above test results, a structured terminal compliance self-inspection report is generated in the trusted execution environment, which is the closed-loop output of the entire self-inspection process. This report integrates the names, expected values, actual observed values, judgment results, and timestamps of all test items in a standardized format (such as JSON or a custom binary structure), ensuring the content is complete, non-repudiable, and easy for machines to parse. Since the report generation process is entirely completed in the trusted execution environment, its content cannot be tampered with externally and can be directly used for local evidence storage, remote reporting, compliance auditing, or as credentials for device network access. This structured output not only improves the traceability and interoperability of the results but also provides a reliable data foundation for automated security governance.

[0047] In some embodiments of this application, basic device information includes static attributes such as the terminal's unique identifier, hardware model, manufacturer information, firmware version, and chip serial number. This information is used to identify the device and serves as the basis for security policy matching and audit tracing. It is typically stored in read-only or protected storage areas to prevent forgery or tampering. Peripheral configuration information refers to the status and attributes of various peripheral devices connected to the main control chip, such as the enabling status, driver version, and access permission settings of cameras, microphones, USB interfaces, Bluetooth modules, SIM card slots, etc. This information is used to assess potential data leaks or physical attack surfaces, ensuring that unnecessary peripherals are disabled or strictly controlled.

[0048] In some embodiments of this application, peripheral configuration information is automatically collected by calling the Hardware Abstraction Layer (HAL) interface provided by the operating system. This mechanism enables the terminal to obtain the operating status and capability parameters of various peripherals in a standardized manner without directly accessing the underlying hardware registers. The HAL shields the differences between different chip platforms or driver implementations, providing a unified data view for upper-layer detection logic, thereby improving the compatibility and portability of the self-testing method. This collection process is initiated and supervised by a trusted execution environment, ensuring that the acquired peripheral information is not maliciously tampered with or disguised, effectively preventing attackers from circumventing security policies by forging device attributes.

[0049] When a smart terminal cannot obtain specific peripheral parameters through a local interface, the method further includes establishing a secure communication connection with the manufacturing execution system (MES) within a trusted execution environment. This supplementary mechanism addresses the issue that some high-end or customized peripherals (such as dedicated RF modules and security elements) cannot have their complete configuration read through regular system calls due to driver closures or interface limitations. By connecting back to the MES—the authoritative backend platform used to record and manage hardware specifications during the equipment production phase—the terminal can dynamically complete missing key parameters at runtime, ensuring the completeness and accuracy of compliance testing.

[0050] This secure communication connection is initiated by the Trusted Execution Environment (TEE) and enforces two-way authentication. This means that not only must the terminal prove its identity to the Manufacturing Execution System (MAS) (usually through a pre-installed device certificate or remote authentication mechanism), but the MAS must also present valid server credentials to the terminal to prevent man-in-the-middle attacks or the injection of false configuration data by a fake server. The entire authentication and communication process is conducted through an encrypted channel, and the key materials are only unsealed and used within the TEE, eliminating the risk of sensitive information leakage.

[0051] Through this secure channel, the terminal can request and receive missing configuration data, including any of the following: wireless communication frequency band support range, transmit power level, or near-field communication protocol version. The wireless communication frequency band support range determines whether the device can legally operate in the regulated frequency bands of a specific country or region; the transmit power level relates to electromagnetic radiation compliance and communication security; and the near-field communication protocol version affects the device's interoperability and anti-attack capabilities in scenarios such as payment and access control. Although these parameters are not often exposed to general operating system interfaces, they are crucial for assessing whether a terminal complies with industry access standards or regional regulations. Obtaining this data through a trusted source retrieval mechanism ensures the authority of the information and maintains a closed-loop execution of the entire self-inspection process within a high security boundary.

[0052] In some embodiments of this application, the terminal has a device certificate and corresponding private key pre-installed in the TEE (Telecommunication Equipment Environment). This private key is stored in a secure storage area within the TEE (such as an RPMB partition or TrustZone ProtectedStorage) and cannot be exported. When missing peripheral parameters need to be obtained, the network proxy module within the TEE proactively initiates an HTTPS connection to the MES backend via the TLS 1.3 protocol, completing mutual authentication during the TLS handshake phase: the terminal presents the device certificate, and the MES verifies its signature chain and checks the certificate revocation status; simultaneously, the terminal also verifies whether the MES server certificate is issued by a trusted CA within the organization and whether the domain name matches. Communication uses ECDHE key exchange to ensure forward confidentiality, and all requested data (such as device serial number and required parameter types) is transmitted encrypted. If the connection fails or authentication fails, the self-test process marks this item as "information unverifiable," but this does not affect the execution of other locally verifiable items, ensuring overall robustness.

[0053] In some embodiments of this application, system security status information includes the operating system kernel version and a list of installed security patches. This system security status information covers the operational status of operating system security mechanisms, including whether mandatory access control is enabled, kernel address space layout randomization, stack protection, secure boot flags, debug interface status, etc., reflecting the overall security protection level of the system at present.

[0054] The method described above retrieves a list of security patches by invoking a system security service interface within a trusted execution environment. This operation aims to accurately determine the current status of security updates installed on the terminal. Since security patches are a critical line of defense for fixing known vulnerabilities and resisting new attacks, their completeness and timeliness directly affect the overall security level of the device. By initiating the call within a trusted execution environment, it ensures that the retrieved patch list originates from a trusted system service and is not interfered with or tampered with by malware during transmission and processing, thereby guaranteeing the authenticity and reliability of the subsequent judgment.

[0055] Building upon this, the method further determines whether there are any critical security patches that have not been updated for more than a preset threshold time based on the time difference between the current date and the release dates of each patch. This time threshold is typically set according to industry best practices or organizational security policies, such as 90 days or 180 days, and is used to quantitatively assess the lag in endpoint response to newly disclosed vulnerabilities. Critical security patches specifically refer to updates that fix high-risk or severe vulnerabilities; if they are not applied for a long period, they will expose devices to publicly exploitable attack surfaces. By automatically calculating the time interval and comparing it to the threshold, this step achieves an objective and quantitative assessment of patch management compliance, avoiding the subjectivity and omission risks of manual verification.

[0056] If critical security patches remain unupdated for an extended period exceeding a preset threshold, they are marked as security risks in the structured endpoint compliance self-inspection report, along with recommended patch update guidelines. This mechanism not only makes potential threats explicit, facilitating rapid identification of high-priority issues by operations and maintenance personnel, but also lowers the remediation threshold and accelerates risk closure by providing specific operational suggestions (such as recommended patch version numbers, acquisition paths, or upgrade procedures). Since both the marking and generation processes are completed within a trusted execution environment, these risk items cannot be removed or hidden by local malware, ensuring the integrity and non-repudiation of audit evidence and providing a solid basis for subsequent security decisions, access controls, or remote governance.

[0057] In some embodiments of this application, a secure boot chain refers to the process of verifying the integrity and authenticity of subsequently loaded components (such as bootloaders, operating system kernels, driver modules, etc.) step by step from the moment the device is powered on. Each component must undergo cryptographic verification (such as digital signature verification) before execution to ensure that it has not been tampered with or replaced, thereby constructing an end-to-end trust path from firmware to the application layer and preventing malicious code from being implanted in the early stages of the system.

[0058] The integrity check of the secure start chain includes the following steps.

[0059] First, the digital signatures or hash values ​​of the bootloader, first-stage loader, operating system kernel, and critical system services are sequentially read within a trusted execution environment. This process aims to verify the authenticity and tamper-proof status of all critical software components from device power-on to full system operation. Since the secure boot chain relies on a root of trust to propagate trust relationships layer by layer, replacing or modifying any component at any level will break the entire trust chain. By performing the read operation within the trusted execution environment, it is ensured that the obtained signatures or hash values ​​originate from protected system interfaces, preventing malware from forging or intercepting verification data, thereby guaranteeing the trustworthiness of the verification process itself.

[0060] Subsequently, these real-time read digital signatures or hash values ​​are compared with the original trusted values ​​pre-installed in a secure storage area within the trusted execution environment. This secure storage area is typically protected by hardware mechanisms and can only be read within a specific security context. The original values ​​stored therein are legitimate benchmarks solidified at the device's factory or during the last trusted update, representing a vendor-certified clean state. The comparison process is performed in an isolated environment, eliminating external interference and ensuring the independence and accuracy of the judgment logic. This cryptographic evidence-based verification method can effectively identify boot chain pollution caused by advanced persistent threats such as firmware implantation, kernel hijacking, or system service replacement.

[0061] If any verification step fails or a value mismatch occurs, the secure boot chain is deemed compromised. This indicates that the terminal may have been subjected to a low-level attack or is running unauthorized code. Even if it appears to function normally, its security is no longer reliable. In this case, the system not only interrupts subsequent unnecessary detection processes to prevent continued operation in an untrusted environment, but also clearly records the tampered boot stage and its corresponding timestamp or version identifier in the self-inspection report. This record specifies whether the anomaly occurred in the bootloader, the first-stage loader, the kernel, or a critical system service, along with its expected version and the actual observed identifiers, providing security analysts with precise fault location information. Because this record is generated in a trusted execution environment and embedded in a structured report, it possesses tamper-proof characteristics and can serve as high-confidence audit evidence for incident response, compliance review, or device isolation decisions.

[0062] In some embodiments of this application, the core of secure boot detection lies in detecting whether the secure Boot function of the system is enabled. It interfaces with the firmware layer or boot management module of a specific device to directly read the actual enabled status of secure Boot, avoiding information distortion caused by abstraction layer shielding or driver compatibility issues.

[0063] By incorporating SecureBoot's enabled status into the overall compliance self-inspection process, the system effectively verifies whether the endpoint possesses the basic defenses to prevent the execution of unsigned or tampered code during the startup phase. This is a prerequisite for building an end-to-end trust chain and a mandatory requirement for endpoint devices in most security specifications. Once SecureBoot is detected as disabled, the system will mark it as a high-risk item in the endpoint compliance self-inspection report and can cross-verify it with other detection modules (such as secure boot chain integrity verification), thereby improving the accuracy and depth of the overall judgment. This customized detection mechanism not only enhances the accuracy and bypass resistance of the detection but also provides a reliable technical basis for subsequent automated remediation, remote policy distribution, or device access control.

[0064] In some embodiments of this application, the secureBoot detection interface is a trusted application (TA) running in a trusted execution environment (TEE). It communicates with the insecure world via the GlobalPlatform TEE ClientAPI and enters the ARM TrustZone Monitor mode via the SMC (Secure Monitor Call) instruction, thereby invoking the security service interface provided by the platform firmware (such as UEFI or BootROM). Specifically, this interface reads the status values ​​of the platform configuration register (PCR) or EFI variables (such as SecureBoot and SetupMode). These variables are written by the firmware at startup based on the key database and signature verification results and are hardware write-protected. The detection logic in the TEE parses this raw byte data to determine whether SecureBoot is enabled (value 0x01) and SetupMode is disabled (value 0x00), thus confirming that the system is in a valid secure boot mode. The entire process does not rely on reports from the upper layers of the operating system, avoiding the risk of being tampered with by rootkits or kernel modules.

[0065] In some embodiments of this application, a secure communication channel refers to a data transmission link established between the terminal and the device management server that is authenticated and encrypted. It is usually implemented based on protocols such as TLS / SSL to ensure the confidentiality, integrity, and anti-replay capability of interactive content such as instruction issuance, status reporting, and certificate exchange, and to prevent man-in-the-middle attacks or data eavesdropping.

[0066] The detection of secure communication channels includes the following steps.

[0067] First, the connection request to the device management server is proactively initiated within the Trusted Execution Environment (TEE). This operation ensures that the security verification of the terminal's remote communication capabilities is conducted in a highly trusted context protected by hardware and isolated from the ordinary operating system environment. By initiating the connection directly from the TEE, interference from intermediate proxies, hijacking modules, or malicious network stacks that may exist in traditional user space or kernel space is avoided. This accurately reflects the actual state of the secure channel established between the terminal and the server, providing a reliable basis for subsequent compliance assessments.

[0068] During connection establishment, the method captures the protocol version, cipher suite, and certificate chain used in the handshake phase. These elements collectively determine the security strength and attack resistance of the communication session. The protocol version reflects the secure transmission standard adopted (such as TLS 1.2 or TLS 1.3); older versions may have known vulnerabilities or lack modern security features. The cipher suite defines the specific algorithm combination for key exchange, authentication, bulk encryption, and message authentication; its configuration directly affects the confidentiality and integrity of data. The certificate chain is used to verify the authenticity of the server's identity, preventing the connection from being redirected to a fake server. All these parameters are captured and recorded before the handshake is completed, ensuring that the analysis is based on the original negotiation results rather than forged information afterward.

[0069] Subsequently, the system verifies that the protocol version is no lower than the preset minimum standard for secure communication. This standard is usually set based on industry best practices or organizational security policies, such as prohibiting the use of deprecated protocols like SSL 3.0 or TLS 1.0, and mandating at least TLS 1.2 to support stronger encryption algorithms and protection mechanisms. Simultaneously, the encryption suite must include a forward secrecy mechanism, employing ephemeral key exchange algorithms such as ECDHE, to ensure that even if the long-term private key is leaked in the future, historical communication content cannot be decrypted, thus significantly improving long-term data security. Furthermore, the server certificate must be issued by a trusted certificate authority and be valid to verify the legitimacy of the other party and prevent man-in-the-middle attacks or the use of self-signed certificates to bypass authentication.

[0070] If any verification item is not met, such as an outdated protocol version, missing forward secrecy in the encryption suite, or a certificate not issued by a trusted authority or that has expired, the secure communication channel is deemed not to be enabled according to security specifications. This determination means that although the terminal may have established a network connection, its communication process is at risk of being eavesdropped on, tampered with, or impersonated, failing to meet compliance requirements in high-security scenarios. This conclusion will be accurately recorded in the terminal compliance self-inspection report, serving as a key risk item to prompt maintenance personnel to promptly fix the configuration or update the root of trust, thereby ensuring end-to-end security of the interaction between the terminal and the management infrastructure. Because the entire detection and determination process is completed in a closed loop within a trusted execution environment, its results possess high tamper-proof and authoritative qualities, and can be directly used for access control, remote auditing, or automated response systems.

[0071] In some embodiments of this application, taking the scenario of secure communication channel detection for an OMC middleware service as an example, its preset state is determined by a combination of multiple pieces of evidence: First, the TEE checks if the main APK file exists in the ` / system / priv-app / OMCService / ` directory and if its SHA-256 hash value matches the pre-built manifest. Second, it queries the system service registry (such as Android's ServiceManager) to see if a Binder service named `com.vendor.omc.IOMCService` exists. Finally, it verifies whether the application holds a special purpose certificate issued by an enterprise CA (Extended Key Usage includes "Device Management"). Enabling secure transport functionality involves the TEE proactively initiating a TLS handshake to the management address configured in the OMC, capturing the negotiated protocol version, cipher suite, and server certificate chain, and confirming that it meets minimum security standards (such as TLS 1.2+, PFS support, and valid certificates).

[0072] In some embodiments of this application, the access control mechanism refers to the authorization management measures implemented by the system for applications or users to access privacy data (such as location, contacts, photos, sensor information). It is usually based on the principle of least privilege, requires explicit user authorization, and supports dynamic permission revocation to ensure that sensitive operations are only performed under legitimate authorization.

[0073] The detection of access control mechanisms includes the following steps.

[0074] (1) Register monitoring callback functions for sensitive system API calls in the trusted execution environment, intercept access requests for recording, location, camera or microphone in real time, and check whether the corresponding application has obtained explicit user authorization in the system permission management module.

[0075] Specifically, the system dynamically monitors application access to high-risk hardware or data resources at the runtime level. By deploying monitoring logic in a trusted execution environment, it ensures that the interception mechanism itself is not interfered with or bypassed by potential malicious processes in ordinary operating systems, thereby enabling real-time capture and analysis of access requests to critical peripherals such as recording, location, cameras, or microphones. Whenever an application attempts to call these sensitive interfaces, a callback function immediately intervenes to check whether there is an explicit authorization record actively granted by the user in the system's permission management module. This authorization model based on explicit user consent is a core principle of privacy protection, effectively preventing applications from secretly collecting sensitive information without the user's knowledge. If unauthorized access is detected, the system will immediately identify it as a failure of permission control and include it in subsequent reports as a security violation, thereby strengthening the terminal's proactive defense capabilities against access to privacy data.

[0076] (2) Traverse the log files in the system log directory and use predefined regular expression rules to scan for plaintext strings containing sensitive personal information. If found, mark them as log leakage risk items and record the file path and context fragments. The predefined regular expression rules are preset in the secure storage area of ​​the trusted execution environment.

[0077] Specifically, logs are intended for troubleshooting and operational auditing. However, if developers are negligent or system design flaws result in sensitive information such as passwords, ID numbers, mobile phone numbers, and geographic coordinates being written to logs in plaintext, information leakage is highly likely, especially if logs are uploaded, shared, or devices are lost. Therefore, this method performs log scanning tasks in a trusted execution environment to ensure the analysis process is not tampered with or circumvented. The regular expression rules used are specifically designed to match the typical formats of various sensitive information.

[0078] For example, the 11-digit pattern of Chinese mobile phone numbers, the 18-digit structure of ID card numbers, and the characteristics of common bank card numbers are not stored in ordinary file systems, but are pre-installed in a secure storage area of ​​a trusted execution environment. This area is protected at the hardware level and can only be read by authorized code, preventing attackers from covering up leakage by modifying the rules.

[0079] Once a match is detected during the scan, the system marks it as a log leakage risk item and accurately records the file path and contextual fragments containing sensitive content, providing traceable and locatable evidence for security audits. This mechanism not only verifies the effectiveness of access control during the data usage phase but also extends to the data retention phase, comprehensively covering the entire lifecycle requirements of privacy protection.

[0080] In some embodiments of this application, the regular expression rule set pre-placed in the TEE secure storage area contains matching patterns for common sensitive information within China, such as: ID card numbers using \d{6}(18|19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|

[12] \d|3

[01] )\d{3}[\dXx], mobile phone numbers using 1[3-9]\d{9}, and bank card numbers using \d{16,19}, combined with a second verification using the Luhn algorithm. To avoid false positives, the rules exclude test strings (such as "13800138000") and encoded content from logs; for Base64 or Hex encoded fields, the system first attempts to decode before matching. The rule set is stored in the form of an encrypted binary blob, and the version number is synchronized with firmware updates. If the rules need to be expanded in the future, new rule packages can be issued through a secure OTA channel. The TEE uses the device's public key to verify the signature, decrypts and replaces the old rules, ensuring the security and atomicity of the update process.

[0081] In some embodiments of this application, a structured terminal compliance self-inspection report refers to a collection of test results generated in a trusted execution environment and encapsulated in a standardized machine-readable format (such as JSON, XML, or a custom binary structure). It includes fields such as the test item name, expected value, actual value, judgment result, and timestamp of each security indicator. It is not only convenient for local storage and remote transmission, but also can be seamlessly connected to security information and event management platforms, compliance audit systems, or device lifecycle management backends, providing a standardized data foundation for security status monitoring and policy execution of large-scale terminal clusters.

[0082] The terminal compliance self-inspection report includes the following: test execution time, device unique identifier, compliance status of each test item, detailed description of non-compliance items, summary of test evidence, and mapping relationship between test items and corresponding security requirements in the target security specification. After generation, the report is digitally signed by the trusted execution environment using the device's private key.

[0083] Specifically, the report includes the test execution time, which is used to accurately record the moment when the self-test operation occurred, providing a key time anchor for subsequent time series analysis, periodic compliance comparison, or security incident backtracking. The unique device identifier ensures that each report is strictly bound to its physical or logical entity, preventing the report from being copied, misused, or associated with the wrong device, and is a prerequisite for achieving device-level trusted auditing.

[0084] The compliance status of each test item is presented clearly as pass or fail, intuitively reflecting the terminal's compliance with each security requirement, facilitating rapid identification of the overall security level and weaknesses. For non-compliance items, the report provides further detailed descriptions, including the content of the violation, the difference between the actual observed value and the expected standard, and the potential risk impact, enabling operations personnel or security analysts to quickly understand the nature of the problem and take targeted measures.

[0085] The evidence summary extracts key data fragments supporting various judgments, such as the hash value when the start chain verification fails, sensitive string samples found in the logs, or the name of the encryption suite used in the communication handshake. These summaries retain sufficient technical details for verification while avoiding the transmission of redundant raw data, balancing efficiency and auditability.

[0086] Furthermore, the report clearly establishes a mapping relationship between the tested items and the corresponding safety requirements in the target safety specifications, corresponding technical test results one-to-one with abstract compliance clauses. This allows non-technical personnel to understand the specific regulatory entries violated by a particular technical deviation. This mapping not only enhances the report's interpretability but also provides a clear chain of compliance evidence for cross-team collaboration, third-party certification, or regulatory inspections.

[0087] After the report is generated, it is digitally signed by the Trusted Execution Environment (TEE) using the device's private key. This step is the core mechanism for ensuring the report's integrity and authenticity. Because the private key is securely stored only within the TEE and cannot be exported, the signing process is completely isolated from the ordinary operating system. Attackers cannot forge or tamper with the report content and then re-sign it. Any modification to the report will result in verification failure, thus ensuring that the recipient can be certain that the report indeed originated from the designated device and has not been altered. This digital signature mechanism gives the terminal compliance self-inspection report legal-grade evidentiary value, making it a trusted credential for device access control, remote verification, or security audits.

[0088] In some embodiments of this application, the encryption algorithm implementation refers to the cryptographic algorithm and its specific engineering implementation method used by the terminal in the process of data storage, transmission, or processing, including symmetric encryption, asymmetric encryption, hash functions, random number generators, etc. This application focuses on whether its implementation conforms to recognized security standards (such as AES-256, RSA-2048, SHA-256, etc.), whether there are known vulnerabilities or weak configurations, and whether it has passed security authentication.

[0089] Compliance testing of encryption algorithm implementations includes the following steps.

[0090] First, the cryptographic service provider's interface is invoked within a trusted execution environment to enumerate the currently supported cryptographic algorithm identifiers. This step aims to comprehensively understand the range of cryptographic capabilities the terminal relies on and ensure that the enumeration process itself is conducted in a highly secure and isolated environment. Since cryptographic algorithms are fundamental to ensuring data confidentiality, integrity, and authentication, their selection and implementation directly affect the overall security strength of the system. By initiating the invocation within a trusted execution environment, malware can be prevented from forging or hiding parts of the algorithm interface, thereby obtaining a true and complete list of supported algorithms and providing accurate input for subsequent classification and verification.

[0091] If the enumeration results include the national cryptographic algorithms SM2, SM3, or SM4, further verification is needed to confirm whether their implementation calls cryptographic modules certified by the State Cryptography Administration. As my country's independently controllable cryptographic standard system, national cryptographic algorithms have mandatory or priority application requirements in critical information infrastructure sectors such as government affairs, finance, and energy. However, simply declaring support for national cryptographic algorithms is insufficient to ensure compliance; it must be confirmed that their underlying implementation originates from modules that have passed security review by the State Cryptography Administration and obtained commercial cryptographic product certification. This step, by checking the algorithm call path, module signature, or interface binding relationship, determines whether a legally certified cryptographic implementation is truly used, preventing vendors from impersonating compliant national cryptographic functions through unverified self-developed or open-source code, thereby mitigating regulatory risks and ensuring the security and legal validity of algorithm execution.

[0092] If the enumeration results include internationally recognized algorithms such as AES or the SHA series, then it is verified whether they are implemented using authoritative and security-certified software or hardware. Although algorithms such as AES and SHA-256 are publicly available and widely used, their implementation quality varies greatly, with potential vulnerabilities such as side-channel leakage, weak random number sources, and buffer overflows. Therefore, compliance not only focuses on the algorithm type but also emphasizes the security qualifications of the implementation carrier. This method ensures that even when using international algorithms, the execution environment has sufficient resistance to attacks and engineering reliability by identifying whether the encryption operation is provided by a cryptographic library or hardware security module (such as the encryption engine in a TEE or a dedicated security chip) certified by FIPS 140-2 / 3, Common Criteria, or other internationally recognized standards.

[0093] All verification results, along with algorithm identifiers, implementation sources, and certification status, are written into the terminal compliance self-inspection report, forming a complete and traceable chain of evidence for cryptographic compliance. The algorithm identifier clearly specifies the specific algorithm types supported by the terminal; the implementation source indicates whether it originates from the operating system kernel, trusted execution environment, dedicated hardware, or a third-party library; and the certification status records whether the terminal possesses national or international certification qualifications and their certificate numbers or version information. This fine-grained data not only meets the transparency requirements of regulatory audits but also provides a basis for decision-making regarding device selection, security hardening, or cross-border deployment. Because the entire testing and recording process is completed in a closed loop within a trusted execution environment, the generated cryptographic compliance information possesses high tamper-proof and non-repudiation properties, serving as authoritative proof of the true state of the terminal's cryptographic capabilities.

[0094] In some embodiments of this application, a complete implementation process for terminal compliance self-testing based on a Trusted Execution Environment (TEE) is provided. This process, centered on a highly secure and isolated TEE, constructs a closed-loop system from environment initialization and multi-dimensional detection to the generation of verifiable reports. Upon initiation of the self-test, the terminal first performs a pre-verification of environment integrity within the TEE: integrity checks are performed on all currently running Trusted Applications (TAs) to confirm that no unknown TAs are running and that permission configurations conform to preset rules; if the verification fails, the self-test process is terminated directly to prevent the detection logic from executing in a contaminated environment, ensuring that all subsequent operations are performed on a trusted baseline.

[0095] Subsequently, the system deploys a dedicated Secure Boot Detection (TA) within the TEE, configuring it with an independent memory domain and permission whitelist, allowing access only to the SMC instruction control register and the REE FUSE area. Its code segment undergoes an integrity check after loading and is set to read-only mode to prevent tampering. Based on this, the terminal begins collecting basic device information, including device model, firmware version, hardware version, and core identifiers such as the radio module. It also automatically detects the connection and configuration status of peripherals such as the LCD, touchscreen, cash drawer, serial port, Ethernet, USB, Wi-Fi, and Bluetooth using the manufacturer's SDK. For parameters that the system cannot directly read (such as Wi-Fi frequency bands and Ethernet module details), the terminal securely connects to the Manufacturing Execution System (MES) within the TEE using a timestamp-based one-time key challenge-response mechanism. After two-way authentication, it obtains the missing authoritative configuration data, ensuring the integrity and accuracy of peripheral information.

[0096] Next, the system performs several in-depth security and compliance checks in sequence: verifying whether the SecureBoot function is enabled, bypassing the operating system layer through the underlying interface; checking whether the OMC middleware service has enabled a secure communication channel, and periodically performing runtime memory integrity checks on its client executable code—the TEE periodically reads the OMC process code segment, calculates the hash value and compares it with the benchmark value; if an inconsistency is found, the detection process is immediately terminated and marked as high-risk in the report; checking whether the lock screen password, password setting, and password strength verification mechanisms have been correctly ported and activated, in addition to reading the configuration, it also performs byte-level verification on at least three high-risk vulnerability remediation points, comparing the binary code with the preset features. The system uses hash values ​​to confirm the actual installation of patches; it monitors calls to privacy functions such as location, recording, and microphone; if unauthorized behavior is detected, in addition to logging, it triggers the TEE to send a signal to the power management unit via SMC instructions to forcibly cut off the power supply to the corresponding peripheral until the user re-authorizes, thus achieving physical data blocking; when scanning critical log files, it uses a lightweight text classification model based on BERT for secondary verification of suspected sensitive information. The inference process of this model is executed entirely within the TEE, and the parameters are fixed in a secure storage area and cannot be modified, reducing the false alarm rate; at the same time, it checks whether the system security patches have been updated within the last three months to prevent the exposure of known vulnerabilities due to delayed patching.

[0097] After all tests are completed, the system generates a structured self-inspection report within the TEE (Test Environment). This report covers the compliance status of each test item, a detailed description of any non-compliance, the risk level, and a summary of technical evidence. During report generation, the system hashes the original evidence (such as Secure Startup PCR values, encryption algorithm verification results, log fragments, etc.) and embeds the hash value into a signature file. The recipient can verify the report's integrity by randomly checking whether the hash value of any original evidence matches the Merkle root. The final report is in a machine-readable format, allowing developers or testers to quickly extract key technical indicators and directly input them into the laboratory's formal testing forms. The entire process is executed in a closed loop within a highly secure and isolated environment, requiring no manual intervention. This not only improves testing efficiency and coverage depth but also significantly enhances the authenticity, tamper-proofness, and auditability of the results through dynamic verification within the TEE, hardware-level response, and a verifiable chain of evidence, providing solid and reliable technical support for the secure and compliant delivery of terminal devices.

[0098] In some embodiments of this application, the TEE strictly adheres to the principle of least privilege when accessing resources in the insecure world. For example, when reading log files, the TEE does not directly access the file system. Instead, it opens the specified path through a trusted proxy process in the insecure world (authenticated by the system signature) and returns a read-only file descriptor. The TEE receives data blocks through shared memory and immediately verifies their hash values. For Hardware Abstraction Layer (HAL) interface calls, the TEE requires the HAL implementation to provide integrity proofs based on RPMB (such as MAC tags for ION buffers) to prevent the injection of forged data into the intermediate layer. Furthermore, all path strings passed to the TEE from the insecure world are normalized to prevent path traversal attacks.

[0099] In some embodiments of this application, when deploying a Secure Boot Detection Trusted Application (TA) in a Trusted Execution Environment (TEE), it is configured with independent memory domain isolation and a permission whitelist, allowing access only to the SMC instruction control register and the REE FUSE storage area, while prohibiting access to other TEE memory spaces. The TA's code segment is set to read-only after an integrity check is performed during TEE startup to prevent tampering. Simultaneously, when sending configuration information from the normal execution environment to the TEE, the TEE first requests a random number from the Hardware Abstraction Layer (HAL) and requires the SM3 hash value of that random number to be embedded in the returned result. The TEE verifies the hash's correctness before proceeding with subsequent processing, effectively preventing replay attacks and forged data injection from the REE side.

[0100] During the scanning of sensitive log information, a lightweight text classification model based on BERT is used for secondary verification of suspected sensitive content. The inference process of this model is executed entirely within the TEE, and the parameters are fixed in a secure storage area at the factory and cannot be modified, reducing the false positive rate. In addition to reading the patch list, security patch detection also performs byte-level verification on at least three high-risk vulnerability fixes. By comparing the binary code within the TEE with the preset feature hash value, the actual patch installation is confirmed. When connecting the TEE and the MES system, a "timestamp-based one-time pad" challenge-response mechanism is used. The terminal includes the current timestamp and a random number, and the MES response includes a signature. The TEE verifies the signature name, and communication continues only if the time difference does not exceed 30 seconds, preventing replay and man-in-the-middle attacks.

[0101] After generating the test report, the original evidence (such as Secure Boot PCR values, encryption algorithm verification results, log fragments, etc.) is hashed, and the hash value is embedded in the report signature file. The recipient can verify the report's integrity through random sampling. During sensitive API monitoring, if unauthorized access is detected, in addition to logging, the TEE will trigger a signal to the power management unit via SMC commands to forcibly cut off power to the corresponding peripheral until the user re-authorizes, achieving physical-level data blocking. National cryptographic algorithm compliance testing, in addition to verifying the authentication certificate, also performs algorithm correctness verification: the TEE generates plaintext and a key, respectively calls the terminal's national cryptographic implementation and the built-in benchmark implementation for encryption, and compares the results to prevent weak encryption replacement. During OMC client testing, the TEE periodically reads its process code segment and calculates the hash value, comparing it with the benchmark value. If they are inconsistent, the process is terminated and marked as high-risk. A pre-test is added before self-testing to confirm that no unknown TAs are running and that permission configurations are compliant. If the test fails, the self-test is terminated directly to avoid execution in a contaminated TEE environment.

[0102] Secondly, refer to Figure 2 This application provides a terminal compliance self-testing system based on a trusted execution environment, including the following functional modules deployed in a smart terminal: The self-test startup module is configured to start a compliance self-test program in a trusted execution environment.

[0103] The information acquisition module is configured to acquire basic device information, peripheral configuration information, and system security status information of the smart terminal.

[0104] The secure boot detection module is configured to detect whether the secure boot chain of the smart terminal is enabled and maintained in integrity.

[0105] The password policy detection module is configured to detect whether the user authentication password policy and password strength verification function meet the preset security requirements.

[0106] The permissions and log auditing module is configured to: detect whether functions involving access to privacy data have permission control mechanisms, and verify whether key operation logs are recorded in accordance with security standards and whether sensitive information is stored in plaintext.

[0107] The encryption and communication verification module is configured to detect whether the encryption algorithm used by the smart terminal complies with the target security specifications, and whether the secure communication channel between the smart terminal and the device management server is enabled.

[0108] The report generation module is configured to generate a structured terminal compliance self-inspection report in a trusted execution environment based on the above test results.

[0109] All modules and their execution of detection steps run in a trusted execution environment.

[0110] Furthermore, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the aforementioned terminal compliance self-testing method based on a trusted execution environment.

[0111] Furthermore, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned terminal compliance self-testing method based on a trusted execution environment.

[0112] In summary, the terminal compliance self-testing method and related equipment based on a trusted execution environment provided in this application have the following technical effects.

[0113] This technical solution embeds all detection logic within a hardware-level isolated trusted execution environment, fundamentally ensuring the integrity, tamper-proof nature, and high reliability of the self-inspection process and results, effectively resisting interference or forgery of the detection process by malicious software. By automating and integrating multi-dimensional detection of basic device information, peripheral configuration, secure startup status, password policies, access control, log compliance, encryption implementation, security patches, and middleware connections, it significantly improves the breadth and depth of compliance verification, solving the problems of fragmented processes, reliance on manual operation, and non-standardized results in existing technologies. For parameters that cannot be obtained locally, an innovative secure backlink mechanism with the manufacturing execution system is introduced to dynamically supplement key configuration data while ensuring identity authentication and encrypted communication, enhancing the completeness and adaptability of the detection. Simultaneously, all detection items are mapped to actual security specification requirements, and the final structured report clearly presents the compliance status, risk details, and technical evidence. Furthermore, the report is digitally signed by the device's private key in the trusted execution environment, possessing legal-grade auditability and non-repudiation. The overall solution not only significantly improves the efficiency, accuracy, and scalability of terminal security compliance self-testing, but also provides solid technical support for device network access, remote management, regular inspections, and third-party certification, demonstrating outstanding practicality and promotional value.

[0114] It should be noted that in all specific embodiments of this application, all data processing activities related to user identity or personal characteristics, such as user information, user behavior data, historical data, and location information, will be conducted in accordance with the principles of legality, legitimacy, and necessity. All data collection, use, storage, and processing will be subject to compliance with applicable national and regional laws, regulations, and industry standards, and informed consent from users will be obtained in a clear and explicit manner before processing. For the processing of sensitive personal information, separate consent from users will be obtained through prominent means such as pop-up prompts and independent confirmation pages. If any processing conflicts with laws and regulations, the laws and regulations will prevail, and necessary data processing will only be carried out within the scope permitted by laws and regulations, ensuring that all data-based applications, analyses, and technical implementations are conducted within the scope permitted by laws and regulations.

[0115] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0116] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0117] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0118] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0119] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Additionally, computer-readable media can even be paper or other suitable media on which programs can be printed, for example, by optically scanning the paper or other media, then editing, interpreting, or, if necessary, processing it in a suitable manner to obtain the program electronically, and then storing it in computer memory.

[0120] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0121] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

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

[0123] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A terminal compliance self-testing method based on a trusted execution environment, characterized in that, The method is executed locally by a smart terminal, and all detection steps are completed in a trusted execution environment, including the following steps: Initiate a compliance self-check procedure within a trusted execution environment; Obtain the basic device information, peripheral configuration information, and system security status information of the smart terminal; Detect whether the secure boot chain of the smart terminal has been enabled and remains intact; Check whether the user authentication password policy and password strength verification function meet the preset security requirements; Check whether functions involving access to private data have access control mechanisms, and verify whether key operation logs are recorded in accordance with security standards and whether sensitive information is stored in plaintext; The system detects whether the encryption algorithm used by the smart terminal complies with the target security specifications and whether the secure communication channel between the smart terminal and the device management server is enabled. Based on the above test results, a structured terminal compliance self-test report is generated in the trusted execution environment.

2. The terminal compliance self-testing method based on a trusted execution environment as described in claim 1, characterized in that, The basic device information includes the device model, firmware version number, hardware serial number, and authentication identifier of the radio module; the peripheral configuration information is automatically collected by calling the hardware abstraction layer interface provided by the operating system. When the smart terminal cannot obtain specific peripheral parameters through the local interface, the method further includes: Establish a secure communication connection with the manufacturing execution system in the Trusted Execution Environment. After two-way authentication initiated and verified by the Trusted Execution Environment, request and receive missing configuration data, which may include any one of the following: wireless communication frequency band support range, transmit power level, or near-field communication protocol version.

3. The terminal compliance self-testing method based on a trusted execution environment as described in claim 1, characterized in that, The system security status information includes the operating system kernel version and a list of installed security patches; the method calls the system security service interface in a trusted execution environment to obtain the security patch list, and determines whether there are any critical security patches that have not been updated for more than a preset threshold time based on the time difference between the current date and the release date of each patch; If present, mark it as a security risk item in the terminal compliance self-inspection report and attach recommended patch update guidelines.

4. The terminal compliance self-testing method based on a trusted execution environment as described in claim 1, characterized in that, The integrity check of the secure boot chain includes: sequentially reading the digital signatures or hash values ​​of the bootloader, the first-stage loader, the operating system kernel, and critical system services in the trusted execution environment, and comparing them with the original trusted values ​​preset in the secure storage area of ​​the trusted execution environment; if the verification of any link fails or the value does not match, it is determined that the secure boot chain has been destroyed, and the tampered boot stage and the corresponding timestamp or version identifier are recorded in the self-inspection report.

5. The terminal compliance self-testing method based on a trusted execution environment as described in claim 1, characterized in that, The detection of the secure communication channel includes: actively initiating a connection request with the device management server in a trusted execution environment, capturing the protocol version, encryption suite, and certificate chain used during the handshake process; verifying that the protocol version is not lower than the preset minimum standard for secure communication, that the encryption suite includes a forward confidentiality mechanism, and that the server certificate is issued by a trusted certificate authority and is within its validity period; if any verification item is not met, it is determined that the secure communication channel is not enabled in accordance with the security specifications.

6. The terminal compliance self-testing method based on a trusted execution environment as described in claim 1, characterized in that, The detection of the access control mechanism includes: Register monitoring callback functions for sensitive system API calls in a trusted execution environment to intercept access requests for recording, location, camera or microphone in real time, and check whether the corresponding application has obtained explicit user authorization in the system permission management module; Iterate through the log files in the system log directory, use predefined regular expression rules to scan for plaintext strings containing sensitive personal information, and if found, mark them as log leakage risk items and record the file path and context fragments; The predefined regular expression rules are preset in the secure storage area of ​​the trusted execution environment.

7. The terminal compliance self-testing method based on a trusted execution environment as described in claim 1, characterized in that, The terminal compliance self-inspection report is in a machine-readable format and includes the following: the test execution time, the device's unique identifier, the compliance status of each test item, a detailed description of any non-compliance items, a summary of the test evidence, and the mapping relationship between the test items and the corresponding security requirements in the target security specification; after the report is generated, it is digitally signed by the trusted execution environment using the device's private key.

8. A terminal compliance self-testing system based on a trusted execution environment, characterized in that, This includes the following functional modules deployed within smart terminals: The self-test startup module is configured to: start a compliance self-test program in a trusted execution environment; The information acquisition module is configured to: acquire the basic device information, peripheral configuration information and system security status information of the smart terminal; The secure boot detection module is configured to: detect whether the secure boot chain of the smart terminal has been enabled and maintained in integrity; The password policy detection module is configured to detect whether the user authentication password policy and password strength verification function meet the preset security requirements. The permissions and log auditing module is configured to: detect whether functions involving access to privacy data have permission control mechanisms, and verify whether key operation logs are recorded in accordance with security specifications and whether sensitive information is stored in plaintext; The encryption and communication verification module is configured to: detect whether the encryption algorithm used by the smart terminal complies with the target security specifications, and whether the secure communication channel with the device management server is enabled; The report generation module is configured to generate a structured terminal compliance self-inspection report in the trusted execution environment based on the above-mentioned test results. All modules and their execution of detection steps run in a trusted execution environment.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the terminal compliance self-test method based on a trusted execution environment as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the terminal compliance self-test method based on a trusted execution environment as described in any one of claims 1 to 7.

Images