A unified access security protection method for mobile terminals based on multimodal feature vectors
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-07
- Publication Date
- 2026-08-14
AI Technical Summary
[0003]现有技术中的终端接入安全防护方案对于移动端终端安全防护均存在明显的技术短板,无法满足企业移动端终端统一接入安全的实际需求,与企业移动端终端接入安全场景不适配
[0007]本发明提供的基于多模态特征向量的移动端终端统一接入安全防护方法的有益效果在于:能够确保SDK运行稳定性和信息采集的连续性,生成不可伪造、不可篡改、不可克隆的移动端终端的唯一标识,保障TUID的安全性,为精准阻断提供核心支撑,精准识别各类异常,降低误报率、漏报率,确保终端信息的机密性、完整性,规避隐私泄露风险。
Smart Images

Figure CN122579111A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of mobile terminal security protection technology, and in particular to a unified access security protection method for mobile terminals based on multimodal feature vectors. Background Technology
[0002] Existing terminal access security protection solutions mainly involve setting up a unified terminal access platform for basic access or identification management, or anomaly identification and management based on the multi-dimensional characteristics of converged devices in scenarios such as video surveillance and industrial equipment monitoring.
[0003] Existing terminal access security solutions all have significant technical shortcomings in protecting mobile terminals, failing to meet the actual needs of enterprises for unified mobile terminal access security and being unsuitable for enterprise mobile terminal access security scenarios. The main drawbacks of existing terminal access security solutions for mobile terminal security protection are as follows: fragmented access control for mobile terminals, easy tampering of SDKs, and poor SDK operational stability; poor security of terminal identifiers, easily tampered with, and inaccurate terminal location; low accuracy in judging abnormal terminal status, prone to false alarms and missed alarms; and low security in information collection and transmission, posing a risk of privacy leakage.
[0004] Therefore, it is necessary to provide a unified access control method suitable for mobile terminals to provide high-precision and high-security unified access security protection for mobile terminals. Summary of the Invention
[0005] The purpose of this invention is to provide a unified access security protection method for mobile terminals based on multimodal feature vectors, which can be used to manage the access security of mobile terminals throughout the entire process and provide high-precision and high-security unified access security protection.
[0006] The mobile terminal unified access security protection method based on multimodal feature vectors provided by this invention includes: deploying a unified access APP and SDK on the mobile terminal; binding the SDK with the unified access APP and setting management permissions to prevent tampering with the binding relationship and SDK settings; using the SDK to collect multi-dimensional static and dynamic information of the mobile terminal; encrypting and generating a unique identifier for the mobile terminal based on the static information collected by the SDK; establishing an encrypted tunnel between the SDK and a secure access gateway and monitoring the status of the encrypted tunnel; integrating a terminal abnormal behavior judgment model into the secure access gateway deployment; converting the static and dynamic information collected by the SDK into multimodal feature vectors; inputting the multimodal feature vectors into the terminal abnormal behavior judgment model; fusing the multimodal feature vectors to obtain a fused feature vector; comparing the fused feature vector with a terminal abnormal semantic anchor point library to calculate an anomaly judgment score and outputting the anomaly judgment result; and performing precise access control and blocking processing on the terminal based on the anomaly judgment result and the unique identifier of the mobile terminal.
[0007] The beneficial effects of the unified access security protection method for mobile terminals based on multimodal feature vectors provided by this invention are as follows: it can ensure the stability of SDK operation and the continuity of information collection, generate a unique identifier for mobile terminals that is unforgeable, unalterable, and uncloneable, ensure the security of TUID, provide core support for precise blocking, accurately identify various anomalies, reduce false alarm rate and false negative rate, ensure the confidentiality and integrity of terminal information, and avoid the risk of privacy leakage.
[0008] In one possible embodiment, the static information of the mobile terminal collected by the application SDK includes terminal hardware information and system information; the dynamic information of the mobile terminal collected by the application SDK includes the terminal's IP address, geographical location information, network connection status, terminal operating status, and terminal operation behavior; the SDK encrypts all the collected information in real time.
[0009] In another possible embodiment, the unique identifier of the mobile terminal is generated by encrypting static information collected by the SDK, including: extracting unchangeable hardware features of the terminal from the static information collected by the SDK, including hardware serial number, IMEI, WiFi MAC address, CPU serial number, and Bluetooth MAC; performing a hash operation on the extracted hardware features to generate a 32-bit hardware feature code; combining the hardware feature code with the timestamp of the terminal's first access to the system to perform an encrypted signature to generate a 16-bit encrypted verification code; and concatenating the hardware feature code, the encrypted verification code, and the timestamp of the terminal's first access to the system to obtain the unique identifier of the mobile terminal.
[0010] In other possible embodiments, after generating a unique identifier for the mobile terminal, the identifier is uploaded to a secure access gateway. The secure access gateway stores the identifier in a trusted terminal ledger and sets up an anti-tampering mechanism for the unique identifier of the mobile terminal. The anti-tampering mechanism includes: the SDK performs integrity verification of the identifier stored locally on the terminal according to a set period, and determines an anomaly when it detects that the identifier stored locally has been tampered with; when uploading the unique identifier of the mobile terminal to the secure access gateway, the identifier is digitally signed using a preset private key, and the secure access gateway verifies the signature using a public key, and refuses access when the signature verification fails; the secure access gateway sends a verification command to the SDK according to a set period, the SDK re-collects the static information of the mobile terminal and regenerates the unique identifier of the mobile terminal using the same algorithm and encrypts and uploads it, and the secure access gateway compares the recalculated identifier with the identifier stored in the trusted terminal ledger, and determines an anomaly if the comparison result is inconsistent.
[0011] The SDK establishes an encrypted tunnel with the secure access gateway and monitors the encrypted tunnel status, including: the SDK sending an encrypted tunnel establishment request to the secure access gateway, the request carrying the mobile terminal's unique identifier, terminal IP address, geographical location information, and SDK version information; after receiving the request, the secure access gateway verifies the mobile terminal's unique identifier, and if the verification passes, it returns an encrypted tunnel establishment response to the SDK, carrying the encrypted tunnel's configuration parameters; the SDK establishes an encrypted tunnel with the secure access gateway according to the received configuration parameters, and simultaneously monitors the encrypted tunnel status in real time; the secure access gateway monitors the encrypted tunnel connection status in real time and records data transmission.
[0012] The static and dynamic information collected by the SDK is converted into multimodal feature vectors, including: extracting and converting the static and dynamic information collected by the SDK according to dimensions and converting them into feature vectors to obtain hardware feature vectors, network feature vectors, operating status feature vectors, and operation behavior feature vectors. Specifically, the hardware feature vector is generated by extracting the terminal's IMEI, CPU serial number, WiFi MAC address, and device SN number, concatenating them, and then performing a SHA-256 hash operation. The network feature vector is generated by extracting network behavior data, which is then standardized and encoded. Network behavior data includes IP address change frequency, network connection status, traffic inbound and outbound rates, connected server addresses, and port usage. The operating status feature vector is generated by extracting system operating data, which is then standardized and encoded. System operating data includes CPU utilization, memory usage, background service status, and battery temperature. The operation behavior feature vector is obtained by inputting operation behavior data into a visual encoder for feature extraction. The operation behavior data includes unstructured data, which is converted into image features before being input into the visual encoder.
[0013] The terminal anomaly semantic anchor library includes preset core semantic anchors for various terminal anomalies and the anomaly feature vector corresponding to each anchor; the anomaly feature vector corresponding to the anchor is a base vector generated by extracting multimodal feature vectors under anomaly scenarios.
[0014] The fused feature vector is compared with a preset terminal anomaly semantic anchor point library to calculate an anomaly judgment score. This includes: comparing the fused feature vector with the anomaly feature vector in the preset terminal anomaly semantic anchor point library to calculate the cosine similarity. When the cosine similarity is greater than the set similarity threshold, it is included in the judgment score. The anomaly judgment score is calculated by combining the basic score of anomaly judgment and the matching similarity between the fused feature vector and each anchor point in the terminal anomaly semantic anchor point library.
[0015] Precise access control for terminals based on anomaly assessment results includes: when a terminal is determined to be abnormal based on the anomaly assessment score, applications / systems within the access permission range are allowed and alarm logs are generated; when the terminal is determined to be normal based on the assessment score, applications / systems within the access permission range are allowed; when the terminal is determined to be abnormal based on the anomaly assessment score, all access permissions are restricted; when any of the following anomalies occur: the terminal is determined to be abnormal based on the anomaly assessment score, the terminal's unique identifier is detected to have been tampered with, the encrypted tunnel is abnormal, or the terminal is exhibiting malicious attack behavior, the security access gateway closes the corresponding encrypted channel using the unique identifier of the terminal exhibiting the anomaly, adds the terminal's unique identifier to the blacklist, and rejects all access requests from the corresponding terminal. After the corresponding terminal performs rectification, it sends a rectification verification request. The security access gateway then re-assesses the anomaly. When the anomaly assessment result is no anomaly, the unique identifier of the rectified terminal is removed from the blacklist and access permissions are restored. Attached Figure Description
[0016] Figure 1 A flowchart illustrating a unified access security protection method for mobile terminals based on multimodal feature vectors, provided in an embodiment of the present invention;
[0017] Figure 2 This is a schematic diagram of an electronic device structure provided in an embodiment of the present invention. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "comprising" and similar expressions used herein mean that the element or object preceding the word covers the element or object listed following the word and its equivalents, but do not exclude other elements or objects.
[0019] This embodiment provides a unified access security protection method for mobile terminals based on multimodal feature vectors.
[0020] See Figure 1 The unified access security protection method for mobile terminals based on multimodal feature vectors includes:
[0021] S101: Deploy the unified access APP and SDK on the mobile terminal. The SDK is bound to the unified access APP. Set management permissions to prevent tampering with the binding relationship and SDK settings.
[0022] In one possible implementation, a unified access app is deployed on the mobile terminal. When the unified access app is installed on the mobile terminal, the silent installation process of the SDK (Software Development Kit) is automatically triggered. The unified access app serves as the sole access point for all mobile applications / systems within the enterprise. The SDK is a high-privilege SDK, possessing core permissions for terminal information collection, encrypted tunnel establishment, and behavior detection. Once installed, the SDK is automatically bound to the unified access app, preventing tampering and ensuring its operational stability and security. The high-privilege SDK's terminal information collection permission request complies with the "Information Security Technology - Basic Specifications for Mobile Internet Applications (Apps) Collecting Personal Information," collecting only necessary information related to terminal security protection and refraining from collecting irrelevant privacy data, thus ensuring user data compliance.
[0023] S102: The application SDK collects multi-dimensional static and dynamic information of the mobile terminal, encrypts and generates a unique identifier for the mobile terminal based on the static information collected by the SDK, establishes an encrypted tunnel with the security access gateway, and monitors the status of the encrypted tunnel.
[0024] In one possible embodiment, the static information of the mobile terminal collected by the application SDK includes terminal hardware information and system information; the dynamic information of the mobile terminal collected by the application SDK includes the terminal's IP address, geographical location information, network connection status, terminal operating status, and terminal operation behavior; the SDK encrypts all the collected information in real time.
[0025] The process of generating a unique identifier for a mobile terminal based on static information collected by the SDK includes: extracting unchangeable hardware features of the terminal from the static information collected by the SDK, including hardware serial number, IMEI, WiFi MAC address, CPU serial number, and Bluetooth MAC; performing a hash operation on the extracted hardware features to generate a 32-bit hardware feature code; combining the hardware feature code with the timestamp of the terminal's first access to the system to generate a 16-bit encrypted verification code; and concatenating the hardware feature code, the encrypted verification code, and the timestamp of the terminal's first access to the system to obtain the unique identifier of the mobile terminal.
[0026] After generating a unique identifier for the mobile terminal, the identifier is uploaded to a secure access gateway. The secure access gateway stores the identifier in the terminal's trusted ledger and sets up an anti-tampering mechanism for the mobile terminal's unique identifier. The anti-tampering mechanism includes: the SDK performs integrity verification of the identifier stored locally on the terminal according to a set period; when tampering of the locally stored identifier is detected, an anomaly is determined; when uploading the mobile terminal's unique identifier to the secure access gateway, a preset private key is used to digitally sign the identifier, and the secure access gateway uses a public key to verify the signature; if the verification fails, access is rejected; the secure access gateway sends a verification command to the SDK according to a set period; the SDK re-collects the static information of the mobile terminal, regenerates the unique identifier of the mobile terminal using the same algorithm, and encrypts and uploads it; the secure access gateway compares the recalculated identifier with the identifier stored in the terminal's trusted ledger; if the comparison result is inconsistent, an anomaly is determined.
[0027] The SDK establishes an encrypted tunnel with the secure access gateway and monitors the encrypted tunnel status, including: the SDK sending an encrypted tunnel establishment request to the secure access gateway, the request carrying the mobile terminal's unique identifier, terminal IP address, geographical location information, and SDK version information; after receiving the request, the secure access gateway verifies the mobile terminal's unique identifier, and if the verification passes, it returns an encrypted tunnel establishment response to the SDK, carrying the encrypted tunnel's configuration parameters; the SDK establishes an encrypted tunnel with the secure access gateway based on the received configuration parameters, while simultaneously monitoring the encrypted tunnel status in real time; the secure access gateway monitors the encrypted tunnel connection status in real time and records data transmission.
[0028] In one specific embodiment, after the SDK is installed, the terminal information collection module automatically starts to collect multi-dimensional static and dynamic information of the mobile terminal. Specifically, the static information includes terminal hardware information (CPU model, memory capacity, storage capacity, hardware serial number) and system information (operating system version, system kernel version, system architecture); the dynamic information includes the terminal's real-time IP address, geographical location information (latitude and longitude, accurate to the regional level, without collecting specific coordinates to protect privacy), network connection status (network type, connection strength, gateway address), terminal running status (process list, thread utilization, CPU load, memory usage), and terminal operation behavior (application installation / uninstallation records, permission request records, developer mode enabled status). The SDK performs real-time encryption processing on all collected information to prevent the information from being stolen or tampered with during local storage and transmission on the terminal.
[0029] For example, the national cryptographic algorithm SM4 is used to encrypt the information collected by the SDK in real time.
[0030] The unique identifier of a mobile terminal is defined as a 64-bit string, consisting of a hardware signature, an encrypted verification code, and a timestamp. It is deeply bound to the terminal hardware, and changes in the IP address do not affect the unique identifier of the mobile terminal, ensuring that the identifier is unique, unchanging, and cannot be cloned.
[0031] The SDK extracts unalterable hardware features from static information, including the hardware serial number, IMEI (International Mobile Equipment Identity), WiFi MAC address, CPU serial number, and Bluetooth MAC address. These extracted hardware features are concatenated to construct a SHA-256 hash, generating a 32-bit hardware signature. Based on this signature, and combined with the timestamp of the terminal's first system access, a 16-bit encrypted verification code is generated using the SM2 algorithm. The unique identifier of the mobile terminal is obtained by concatenating the hardware signature, the verification code, and the timestamp of the terminal's first system access. This unique identifier is stored in the terminal system's secure storage (Keystore / security sandbox), which is inaccessible and tamper-proof to third-party applications. Furthermore, the generated unique identifier is automatically uploaded to the secure access gateway, which stores it in the terminal's trusted ledger, completing the unique binding of the terminal.
[0032] The mobile terminal's unique identifier is protected against tampering through a triple anti-tampering mechanism, including local anti-tampering, transmission anti-tampering, and dynamic anti-tampering. Local anti-tampering specifically refers to storing the mobile terminal's unique identifier using the national cryptographic standard SM4. The SDK performs integrity checks on the locally stored identifier at set intervals, immediately identifying an anomaly if tampering is detected. Transmission anti-tampering specifically refers to using an SM2 digital signature when uploading the mobile terminal's unique identifier to the secure access gateway; if the secure access gateway fails the signature verification, access is denied. Dynamic anti-tampering specifically refers to the secure access gateway periodically issuing verification commands. The SDK re-collects information and recalculates the mobile terminal's unique identifier using hardware features, comparing the recalculated identifier with the identifier stored in the terminal's trusted ledger. If they do not match, the connection to the terminal is immediately blocked.
[0033] The SDK sends an encrypted tunnel establishment request to the secure access gateway, carrying the mobile terminal's unique identifier, terminal IP address, geographical location information, and SDK version information. Upon receiving the request, the secure access gateway verifies the mobile terminal's unique identifier and the SDK version's validity. If the verification passes, it returns an encrypted tunnel establishment response to the SDK, carrying the encrypted tunnel's configuration parameters (encryption algorithm, tunnel port, and session timeout). Based on the configuration parameters, the SDK establishes an encrypted tunnel with the secure access gateway using a combined SSL / IPSec encryption protocol. Data transmission within the encrypted tunnel uses the national standard SM4 algorithm for encryption and the SM3 algorithm for integrity verification. Key exchange uses the SM2 elliptic curve algorithm to ensure the confidentiality, integrity, and non-repudiation of data within the channel. A kill-switch mechanism is also enabled to monitor the tunnel status in real time; in the event of an abnormal disconnection, all outbound traffic from the terminal is immediately blocked to prevent data leakage. The secure access gateway monitors the encrypted tunnel in real time, recording information such as the tunnel's connection status, data transmission volume, and terminal access duration. If a tunnel anomaly is detected (such as connection interruption, data tampering, or abnormal traffic), the encrypted tunnel is immediately closed, and the terminal status is marked as abnormal.
[0034] S103: Integrate the terminal abnormal behavior judgment model into the security access gateway deployment, convert the static and dynamic information collected by the SDK into multimodal feature vectors, input the multimodal feature vectors into the terminal abnormal behavior judgment model, fuse the multimodal feature vectors to obtain fused feature vectors, compare the fused feature vectors with the terminal abnormal semantic anchor point library to calculate the abnormal judgment score, and output the abnormal judgment result.
[0035] In one possible embodiment, the static and dynamic information collected by the SDK is converted into multimodal feature vectors, including: extracting and converting the static and dynamic information collected by the SDK according to dimensions into feature vectors to obtain hardware feature vectors, network feature vectors, operating status feature vectors, and operation behavior feature vectors; wherein, the hardware feature vector is generated by extracting the terminal's IMEI, CPU serial number, WiFi MAC address, and device SN number, concatenating them, and then performing a SHA-256 hash operation; the network feature vector is generated by extracting network behavior data and performing standardization and encoding processing, the network behavior data including IP address change frequency, network connection status, traffic inbound and outbound rates, connection server address, and port usage; the operating status feature vector is generated by extracting system operating data and performing standardization and encoding processing, the system operating data including CPU utilization, memory usage, background service status, and battery temperature; the operation behavior feature vector is obtained by inputting operation behavior data into a visual encoder for feature extraction, the operation behavior data including unstructured data, the unstructured data is converted into image features before being input into the visual encoder.
[0036] The terminal anomaly semantic anchor library includes preset core semantic anchors for various terminal anomalies and the anomaly feature vector corresponding to each anchor; the anomaly feature vector corresponding to the anchor is a base vector generated by extracting multimodal feature vectors under anomaly scenarios.
[0037] The fused feature vector is compared with the terminal anomaly semantic anchor point library to calculate the anomaly judgment score. This includes: comparing the fused feature vector with the anomaly feature vector in the preset terminal anomaly semantic anchor point library to calculate the cosine similarity. When the cosine similarity is greater than the set similarity threshold, it is included in the judgment score. The anomaly judgment score is calculated by combining the basic score of anomaly judgment and the matching similarity between the fused feature vector and each anchor point in the terminal anomaly semantic anchor point library.
[0038] In one specific embodiment, an edge-side multimodal perception Transformer model (a lightweight version of AndesVL 0.6B) is used as the terminal abnormal behavior judgment model. The lightweight AndesVL multimodal perception Transformer model is integrated into the secure access gateway. The model is optimized using quantized perception training technology and sparsity technology to reduce computing power consumption, while supporting edge-side local inference and gateway collaborative judgment to ensure judgment efficiency and privacy protection.
[0039] The SDK collects terminal information to accurately analyze abnormal terminal behavior. The specific process is as follows: The SDK standardizes the collected static and dynamic terminal information, converting it into multimodal feature vectors that the model can recognize. These include hardware feature vectors, network feature vectors, operational status feature vectors, and operational behavior feature vectors. The hardware feature vector is generated by extracting the terminal's IMEI, CPU serial number, WiFi MAC address, and device SN, concatenating them, and then performing a SHA-256 hash operation. The network feature vector is generated by standardizing and encoding network behavior data, including IP address change frequency, network connection status, traffic inbound / outbound rates, connected server addresses, and port usage. The operational status feature vector is generated by standardizing and encoding system operation data, including CPU utilization, memory usage, background service status, and battery temperature. The operational behavior feature vector is obtained by inputting operational behavior data into a visual encoder for feature extraction. This operational behavior data includes unstructured data, which is converted into image features before being input into the visual encoder.
[0040] The multimodal feature vector of the secure access gateway is input into the AndesVL multimodal perception Transformer model. The model fuses the multi-dimensional features through a cross-modal attention layer to obtain a fused feature vector, captures the dependencies between features, and performs anomaly judgment by combining the semantic anchor alignment mechanism of cross-modal weak supervision anomaly detection. Specifically, the fused feature vector is compared with a preset terminal anomaly semantic anchor library.
[0041] For example, the abnormal behavior assessment process is as follows: Core semantic anchors for various types of terminal abnormal behavior are preset, with each anchor corresponding to a unique abnormal feature vector. An abnormal semantic anchor library is constructed by combining these core semantic anchors and their corresponding abnormal feature vectors. The abnormal feature vectors corresponding to the core semantic anchors are extracted from standard multimodal feature vectors for the corresponding abnormal scenarios. The AndesVL model, through a cross-modal attention layer, deeply fuses five types of sub-vectors from the multimodal feature vectors, breaking down modal barriers, capturing the correlation between different features, and generating a fused feature vector. The fused feature vector is then compared one by one with the abnormal feature vectors corresponding to all core semantic anchors for various types of terminal abnormalities in the anchor library. The cosine similarity between the two is calculated. For abnormal feature vectors with similarity reaching a set threshold, a weighted sum is performed based on the weighted scores of the corresponding abnormal feature vectors. The abnormal assessment score is calculated using the formula: base score + weighted sum of similarity of abnormal feature vectors - reverse abnormal score, thereby determining whether the terminal exhibits abnormal behavior and, if so, what type of abnormal behavior it is.
[0042] The preset abnormal terminal behavior types include: abnormal terminal environment, such as installing attack software (e.g., viruses, Trojans, malicious plugins), granting developer privileges, tampering with system configurations, and rooting / jailbreaking operations; abnormal network behavior, such as frequent IP address changes (more than a preset threshold per unit time), abnormal network connection (frequent disconnections and reconnections), and abnormal IP access (access to high-risk IP addresses); and abnormal operation behavior, such as frequent application installation / uninstallation, abnormal permission requests (requesting high-risk permissions unrelated to terminal access), and malicious tampering with SDK configurations. The base score and weighted scores of each core semantic anchor point involved in calculating the anomaly assessment score are dynamically adjusted according to the enterprise's security needs to ensure the flexibility and accuracy of the assessment.
[0043] After the analysis and processing are completed, the analysis results will be output in the form of a report. The report includes: the terminal anomaly analysis score (0-100 points), and interpretable text generated by combining the semantic anchor alignment mechanism, which clarifies the type of abnormal behavior, the time of occurrence of the anomaly, the characteristics of the anomaly, and the basis for the analysis (i.e. the core semantic anchor that triggered the anomaly and the matching similarity), forming a complete analysis report.
[0044] S104: Based on the anomaly assessment results and the unique identifier of the mobile terminal, the security access gateway performs precise access control and blocking on the terminal.
[0045] Precise access control for terminals based on anomaly assessment results includes: when the terminal is determined to be abnormal based on the anomaly assessment score, allowing applications / systems within the access permission range and generating alarm logs; when the terminal is determined to be normal based on the assessment score, allowing applications / systems within the access permission range; and when the terminal is determined to be abnormal based on the anomaly assessment score, restricting all access permissions.
[0046] When any of the following anomalies occur: the terminal is judged to be abnormal based on the anomaly assessment score, the terminal's unique identifier is detected to have been tampered with, the encrypted tunnel is abnormal, or the terminal is engaging in malicious attacks, the security access gateway closes the corresponding encrypted channel using the unique identifier of the terminal with the anomaly, adds the terminal's unique identifier to the blacklist, and rejects all access requests from the corresponding terminal. After the corresponding terminal performs rectification, it sends a rectification verification request. The security access gateway then re-assesses the anomaly. When the anomaly assessment result is no anomaly, the unique identifier of the terminal that has completed rectification is removed from the blacklist and its access permissions are restored.
[0047] In one specific embodiment, the access control of mobile terminals by the secure access gateway includes: the secure access gateway associating the access permissions of the mobile terminal with its unique identifier (a preset application / system access permission list), allowing only applications / systems within the terminal's access permission range, thus achieving fine-grained access control of "one person, one terminal, one permission". Simultaneously, access permissions are dynamically adjusted based on anomaly assessment scores: the anomaly assessment score is compared with a normal score range determined according to the enterprise's security requirements; when the anomaly assessment score is lower than the normal score range, it is determined that the terminal has a reverse anomaly, an alarm log is generated, and access is allowed; when the anomaly assessment score is within the normal score range, it is determined that the terminal has no anomaly, and access is allowed; when the anomaly assessment score is higher than the normal score range, it is confirmed that the terminal is abnormal, and all access permissions are immediately restricted. Furthermore, when any of the following anomalies are detected: terminal anomaly, tampering of the terminal's unique identifier, encrypted tunnel anomaly, or malicious attack behavior by the terminal, the security access gateway will precisely block access based on the terminal's unique identifier. This includes: closing the encrypted tunnel corresponding to the terminal and rejecting all access requests from that terminal; adding the terminal's unique identifier to a blacklist, permanently prohibiting the terminal from accessing enterprise applications / systems, even if the terminal changes its IP address or network. After being blocked, the terminal will undergo rectification based on the determined anomaly type (e.g., uninstalling attack software, disabling developer permissions, or restoring the unique identifier to its normal state). After rectification, the SDK sends a rectification verification request to the security access gateway. Upon receiving the verification request, the security access gateway will re-evaluate the terminal's anomaly. If the re-evaluation score falls within the normal range, the unique identifier of the rectified terminal will be removed from the blacklist, restoring the terminal's access permissions.
[0048] In one possible embodiment, taking the scenario of enterprise mobile terminals (such as employee mobile phones) accessing internal enterprise applications / systems as an example, the specific implementation process of the unified access security protection method for mobile terminals based on multimodal feature vectors is as follows:
[0049] Enterprises push the unified access APP installation package to employees' mobile devices. When employees install the unified access APP, the APP automatically triggers the silent installation process of the SDK. The SDK installation package is embedded in the unified access APP, requiring no manual operation from employees. After the SDK is installed, it is automatically bound to the unified access APP and written to the deep directory of the terminal system, prohibiting manual uninstallation and tampering. The SDK requests necessary permissions such as terminal information collection, background operation, and network access, but does not collect irrelevant privacy data such as employees' address books and SMS messages, ensuring compliance.
[0050] After the SDK starts, it automatically collects multi-dimensional information about the terminal, including static information such as terminal hardware serial number (phone IMEI code), CPU model (e.g., Snapdragon 8 Gen3), memory capacity (8GB), storage capacity (256GB), operating system version (Android 14), and system kernel version (5.15.0); and dynamic information such as real-time IP address (192.168.1.100), geographic location information (30°N, 120°E, regional level), network type (5G), connection strength (-50dBm), process list (WeChat, Enterprise WeChat, Unified Access APP, SDK process), CPU load (20%), memory usage (30%), application installation records (3 applications installed in the past 7 days, no applications from unknown sources), and permission request records (only Unified Access APP and SDK request necessary permissions). The SDK uses the national cryptographic SM4 algorithm to encrypt the above information and stores it in a hidden directory on the terminal, while simultaneously transmitting the encrypted information to the secure access gateway in real time.
[0051] The core features of the terminal's hardware serial number (861234567890123), IMEI (International Mobile Equipment Identity), WiFi MAC address, and CPU unique identifier are extracted and hashed using the SHA-256 algorithm to generate a 32-bit hardware feature code (8a7b6c5d4e3f2g1h0i9j8k7l6m5n4o3p). Based on the hardware feature code and combined with the terminal's first system access timestamp (1713567890123), the national cryptographic algorithm SM2 is used for encrypted signing to generate a 16-bit encrypted verification code (a1b2c3d4e5f6g7h8). By concatenating a 32-bit hardware signature, a 16-bit encrypted checksum, and a 16-bit timestamp (1713567890123 converted to 16-bit hexadecimal), a 64-bit TUID (8a7b6c5d4e3f2g1h0i9j8k7l6m5n4o3pa1b2c3d4e5f6g7h812345678) is obtained, which is the unique identifier of the mobile terminal. After the TUID is generated, it is automatically uploaded to the secure access gateway, which stores the TUID in the terminal's trusted ledger, completing the unique binding of the terminal.
[0052] The anti-tampering protection process includes: Local anti-tampering: The TUID is encrypted and stored in the terminal system's secure directory (Keystore / security sandbox) using the national cryptographic algorithm SM4. The SDK performs an integrity check on the TUID every 30 minutes. If the TUID is detected to have been tampered with, an APP pop-up alarm is immediately triggered, and the terminal access request is stopped. Transmission anti-tampering: When the TUID is transmitted to the secure access gateway, the SDK uses the enterprise's preset private key to digitally sign the TUID. The secure access gateway uses the public key to verify the signature. If the signature verification fails, access is rejected. Dynamic verification: The secure access gateway sends a TUID verification request to the SDK every 30 minutes. The SDK re-collects the terminal's hardware characteristics, recalculates the new TUID using the same algorithm, and encrypts and uploads it. The gateway retrieves the original TUID of the terminal from the terminal's trusted ledger for comparison. If the comparison matches, access is maintained; if the comparison does not match, it is determined to be abnormal.
[0053] The SDK sends a tunnel establishment request to the secure access gateway, carrying the encrypted TUID, terminal IP address (192.168.1.100), geolocation information, and SDK version. Upon receiving the request, the secure access gateway verifies the TUID and the SDK version, then returns tunnel configuration parameters to the SDK (encryption algorithm: SM4, tunnel port: 443, session timeout: 30 minutes). Based on the configuration parameters, the SDK establishes an encrypted tunnel with the secure access gateway using a combined SSL / IPSec encryption protocol. Data transmission uses SM4 encryption and SM3 integrity verification, while key exchange uses the SM2 algorithm. A kill-switch mechanism is also enabled to monitor the tunnel status in real time. The secure access gateway monitors the tunnel connection status and records data transmission volume. If a tunnel connection interruption is detected, a reconnection request is immediately sent to the SDK. If reconnection fails, the terminal status is marked as abnormal.
[0054] The AndesVL 0.6B lightweight multimodal perception Transformer model is integrated into the secure access gateway. The model is optimized using quantized perception training technology to adapt to the gateway's computing power requirements.
[0055] The SDK converts the collected multi-dimensional terminal information into feature vectors. Specifically, it converts the process list and operation logs into image features, and then extracts these features using the model's SigLIP-2-base visual encoder to obtain hardware feature vectors, network feature vectors, running status feature vectors, and operation behavior feature vectors. The specific steps are as follows:
[0056] Unstructured process lists and operation logs are structured and converted into pseudo-image matrices (simulated grayscale image format, with a uniform size of 224×224) adapted to the visual encoder. The process list is arranged as a two-dimensional numerical matrix based on "process start time (row) - process attributes (column)". The row dimension is sorted from earliest to latest by process start time, and the column dimension includes core attributes such as process ID, process name, signature status, CPU usage, memory usage, and permission requests. Each attribute text / value is mapped to a grayscale value of 0-255 (e.g., signature status: signed = 255, unsigned = 0; CPU usage: 0% = 0, 100% = 255; no high-risk permissions = 255, high-risk permissions = 0). The operation log is converted into a time-series heatmap matrix based on "time axis (horizontal axis) - operation type (vertical axis)". The horizontal axis divides the 5-minute time window into 224 time slices, and the vertical axis is sorted by operation risk level (e.g., installing unknown applications, requesting high-risk permissions, normal network access, etc.). The grayscale value of the cell corresponds to the number of operations / risk level within the corresponding time slice (no operation = 255, one high-risk operation = 100, multiple high-risk operations = 0).
[0057] The pseudo-image matrix of the process list and the time-series heatmap matrix of the operation log are input into the SigLIP-2-base visual encoder of the model. The encoder first divides the pseudo-image into 16×16 feature patches and captures the correlation between patches through a pre-trained attention mechanism (such as the correlation between unsigned processes and high-risk permission requests, and the time-series pattern of continuous high-risk operations in a short period of time). Finally, it outputs 768-dimensional process behavior feature vectors and 768-dimensional operation behavior feature vectors, respectively, which completely preserve the abnormal pattern information in the processes and logs.
[0058] Other dimensions of terminal information are extracted synchronously and converted into feature vectors. The hardware feature vector (32-dimensional) is generated by concatenating the terminal IMEI, CPU serial number, WiFi MAC address, and device SN number, and then performing a SHA-256 hash operation. It is a fixed value (not changing with the terminal's operating status). The network feature vector (64-dimensional) is generated by standardizing and encoding network behavior data such as IP address change frequency, network connection status, traffic inbound and outbound rates, connected server addresses, and port usage. It is a dynamically updated value. The operating status feature vector (64-dimensional) is generated by standardizing and encoding system operating data such as CPU utilization, memory usage, background service status, and battery temperature. It is a dynamically updated value.
[0059] The hardware feature vector (32-dimensional), network feature vector (64-dimensional), running state feature vector (64-dimensional), process behavior feature vector (768-dimensional), and operation behavior feature vector (768-dimensional) are concatenated in sequence to obtain a complete multimodal feature vector of 1696 dimensions, which can be used for subsequent cross-modal feature fusion and anomaly detection in the AndesVL model.
[0060] For example, the definition of converting the collected multi-dimensional terminal information into feature vectors is shown in the table below:
[0061] Table 1. Definition of Feature Vector
[0062]
[0063] The secure access gateway inputs multimodal feature vectors (1696 dimensions) into the AndesVL multimodal awareness Transformer model. The model fuses multi-dimensional features through a cross-modal attention layer, capturing the dependencies between features of different modalities (such as the correlation between "unsigned process" and "high CPU load", and the correlation between "high-risk permission request" and "abnormal traffic"). Combined with the semantic anchor alignment mechanism of cross-modal weakly supervised anomaly detection, it achieves accurate judgment, completely solving the problems of low accuracy and high false alarm rate of single-modal judgment. The specific judgment process is as follows:
[0064] Core semantic anchor points for various abnormal terminal behaviors are pre-defined, with each anchor point corresponding to a unique abnormal feature, forming a standardized anchor point library. This library corresponds to the dimensionality of the multimodal feature vectors (both are 1696-dimensional), ensuring the feasibility of subsequent similarity calculations. The anchor point feature vectors are generated by extracting standard multimodal feature vectors for the corresponding abnormal scenarios. For example, the anchor vector for unknown signature processes is a baseline vector obtained by extracting process behavior and runtime status features from a large number of terminal samples with unknown signature processes, and then standardizing it. This baseline vector serves as a reference standard for subsequent similarity comparisons. The definitions of some core semantic anchor points are shown in the table below.
[0065] Table 2 Definition of Core Semantic Contradiction
[0066]
[0067] The AndesVL model, through a cross-modal attention layer, deeply fuses five sub-vectors (hardware, network, runtime state, process behavior, and operational behavior) from a 1696-dimensional multimodal feature vector. This breaks down modal barriers, captures the correlations between different features, and generates a "fused feature vector" (still 1696-dimensional, retaining all original feature information and enhancing the discriminative power of anomalous features). The attention layer assigns higher weights to anomalous features, "aggregating" anomalous features scattered across different modalities to form a more discriminative fused feature.
[0068] The model compares the fused feature vector with each anchor feature vector in the anchor library, calculating the cosine similarity between the two (similarity ranges from 0 to 1; the closer to 1, the better the match between the terminal feature and the anchor, and the higher the probability of anomaly), thus achieving precise alignment between terminal features and anomaly semantics. The similarity calculation uses the cosine similarity algorithm, with the formula: Where A is the fused feature vector and B is the abnormal feature vector; the similarity threshold is set to 0.7. When the similarity is ≥0.7, the anchor point is judged to be successfully matched and included in the judgment score; when the similarity is <0.7, the anchor point is judged to be mismatched and no score is awarded.
[0069] The calculation method adopts "base score + weighted sum of similarity of each anchor point - reverse anomaly", with a score range of 0-100 points. The higher the score, the higher the probability of terminal anomaly. The base score and the weight of each anchor point are dynamically adjusted according to the enterprise's security needs to ensure the flexibility and accuracy of the assessment. If the similarity reaches the standard, the corresponding score is accumulated to obtain the terminal anomaly assessment score. For example, anchor point 1: unknown signature process, weight 18 points; anchor point 2: high-risk permission request, weight 17 points; anchor point 3: abnormal CPU load, weight 15 points, and the base score is preset to 40 points. The model calculates the similarity between the fused feature vector and each anchor point. Among them, the unknown process feature has a similarity of 92% with anchor point 1, the high-risk permission feature has a similarity of 88% with anchor point 2, and the CPU load (75%) has a similarity of 85% with anchor point 3. The assessment score is calculated as: 40 + (18×92%) + (17×88%) + (15×85%) ≈ 85 points (confirmed anomaly), and the abnormal behavior is "installation of attack software".
[0070] The secure access gateway, based on the terminal's TUID, queries its access permissions (only allowing access to a few enterprise apps). Since the assessment score is 85 (confirmed as abnormal), all access permissions for the terminal are immediately restricted. The secure access gateway closes the encrypted tunnel corresponding to the terminal, adds its TUID to the blacklist, and denies all access requests from the terminal. After the employee uninstalls the attack software, they send a rectification verification request to the secure access gateway through the unified access app. The SDK re-collects the terminal information and transmits it to the gateway. The gateway reassesses, and the assessment score is 25 (no abnormality). The terminal's TUID is removed from the blacklist, and its access permissions are restored.
[0071] The mobile terminal unified access security protection method based on multimodal feature vectors provided in this invention is specifically designed to meet the actual needs of enterprises for unified access security protection of mobile terminals.
[0072] Deploy a unified access APP as the sole access point for all enterprise mobile applications / systems to achieve centralized management and control of terminal access; at the same time, automatically and silently install the SDK during APP installation, deeply bind it to the APP, prohibit manual uninstallation or tampering, ensure the stability of SDK operation and the continuity of information collection, and improve the access control system.
[0073] The system collects the terminal's tamper-proof hardware characteristics to generate a unique identifier for the terminal, which is then stored in the system's secure area. This unique identifier is deeply bound to the terminal hardware, making it unforgeable, unalterable, and uncloneable. This meets the needs of large-scale enterprise deployment, ensures the security of the unique identifier, provides core support for precise blocking, and completely eliminates the dependence on IP addresses.
[0074] Integrating the lightweight multimodal awareness Transformer model (AndesVL) on the edge to the secure access gateway, it merges static terminal information (hardware, system) and dynamic information (IP, running status, operation behavior) to achieve deep fusion of multi-dimensional features, accurately identify various anomalies such as terminal environment, network behavior, and operation behavior, including deep anomalies such as the installation of attack software and the granting of developer privileges, thereby reducing false alarm rate and false negative rate.
[0075] A closed-loop security protection system has been built, encompassing unified access APP, SDK, unique identifier, encrypted tunnel, multimodal analysis, and precise blocking. This system organically combines access, data collection, analysis, control, and blocking to achieve full-process control of terminal access security.
[0076] The SDK only collects necessary information related to terminal security protection, complies with data compliance requirements, and does not collect irrelevant privacy data. The collected information is encrypted and stored and transmitted using the national cryptographic algorithm SM4. The encrypted tunnel uses a combination of SSL / IPSec protocol and national cryptographic algorithm to ensure the confidentiality and integrity of terminal information and avoid the risk of privacy leakage.
[0077] In other embodiments of this application, an electronic device is disclosed, such as... Figure 2 As shown, the electronic device 200 may include: one or more processors 201; a memory 202; a display 203; one or more application programs (not shown); and one or more computer programs 204. These devices can be connected via one or more communication buses 205. The one or more computer programs 204 are stored in the memory and configured to be executed by the one or more processors 201. The one or more computer programs 204 include instructions that can be used to perform actions such as... Figure 1 And the steps in the corresponding embodiments.
[0078] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0079] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0080] If the integrated unit 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 solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.
[0081] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.
Claims
1. A unified access security protection method for mobile terminals based on multimodal feature vectors, characterized in that, include: A unified access APP and SDK are deployed on the mobile terminal. The SDK is bound to the unified access APP, and management permissions are set to prevent tampering with the binding relationship and the settings of the SDK. The SDK is used to collect multi-dimensional static and dynamic information of the mobile terminal. Based on the static information collected by the SDK, a unique identifier of the mobile terminal is generated in encryption. The SDK establishes an encrypted tunnel with the security access gateway and monitors the status of the encrypted tunnel. The terminal abnormal behavior judgment model is integrated into the security access gateway deployment. The static and dynamic information collected by the SDK is converted into multimodal feature vectors. The security access gateway inputs the multimodal feature vectors into the terminal abnormal behavior judgment model. The terminal abnormal behavior judgment model fuses the multimodal feature vectors to obtain a fused feature vector. The fused feature vector is compared with the terminal abnormal semantic anchor point library to calculate the abnormal judgment score and output the abnormal judgment result. The secure access gateway performs precise access control and blocking on terminals based on anomaly analysis results and the unique identifier of the mobile terminal.
2. The method according to claim 1, characterized in that, The static information of the mobile terminal collected by the SDK includes terminal hardware information and system information; The dynamic information of the mobile terminal collected by the SDK includes the terminal's IP address, geographical location information, network connection status, terminal operating status, and terminal operation behavior; The SDK encrypts all collected information in real time.
3. The method according to claim 1, characterized in that, The unique identifier for the mobile terminal is generated by encrypting the static information collected by the SDK, including: The terminal's unchangeable hardware features are extracted from the static information collected by the SDK, including hardware serial number, IMEI, WiFi MAC address, CPU serial number, and Bluetooth MAC. The extracted hardware features are concatenated and then hashed to generate a 32-bit hardware feature code. The hardware signature code is combined with the timestamp of the terminal's first access to the system for encryption and signing, generating a 16-bit encrypted verification code. The unique identifier of the mobile terminal is obtained by concatenating the hardware feature code, the encryption verification code, and the timestamp of the terminal's first access to the system.
4. The method according to claim 3, characterized in that, After generating a unique identifier for the mobile terminal, the identifier is uploaded to the secure access gateway. The secure access gateway stores the identifier in the trusted ledger of the terminal and sets up a mechanism to prevent tampering of the unique identifier of the mobile terminal. The anti-tampering mechanism includes: The SDK performs integrity checks on the identifier of the terminal's local storage according to a set period, and determines an anomaly when it detects that the identifier of the local storage has been tampered with. When uploading the unique identifier of the mobile terminal to the secure access gateway, the identifier is digitally signed using a preset private key. The secure access gateway verifies the signature using a public key, and refuses access if the signature verification fails. The secure access gateway sends verification commands to the SDK at a set period. After the SDK re-collects the static information of the mobile terminal, it regenerates the unique identifier of the mobile terminal using the same algorithm and uploads it in encryption. The secure access gateway compares the recalculated identifier with the identifier stored in the terminal's trusted ledger. If the comparison result is inconsistent, it is judged as abnormal.
5. The method according to claim 1, characterized in that, The SDK establishes an encrypted tunnel with the secure access gateway and monitors the status of the encrypted tunnel, including: The SDK sends an encrypted tunnel establishment request to the secure access gateway, the request carrying the unique identifier of the mobile terminal, the terminal IP address, the geographical location information and the SDK version information; After receiving the request, the secure access gateway verifies the unique identifier of the mobile terminal. If the verification is successful, it returns an encrypted tunnel establishment response to the SDK, which carries the configuration parameters of the encrypted tunnel. The SDK establishes an encrypted tunnel with the secure access gateway based on the received configuration parameters, and monitors the encrypted tunnel status in real time. The secure access gateway monitors the encrypted tunnel connection status in real time and records data transmission.
6. The method according to claim 1, characterized in that, The static and dynamic information collected by the SDK is converted into multimodal feature vectors, including: The static and dynamic information collected by the SDK are extracted and converted into feature vectors according to dimensions to obtain hardware feature vectors, network feature vectors, running status feature vectors, and operation behavior feature vectors. The hardware feature vector is generated by extracting the terminal's IMEI, CPU serial number, WiFi MAC address, and device SN number, concatenating them, and then performing a SHA-256 hash operation. The network feature vector is generated by extracting network behavior data, standardizing and encoding it, and the network behavior data includes IP address change frequency, network connection status, traffic inbound and outbound rates, connection server address and port usage. The operating status feature vector is generated by extracting system operating data, standardizing and encoding it, and the system operating data includes CPU utilization, memory usage, background service status and battery temperature. The operation behavior feature vector is obtained by inputting operation behavior data into a visual encoder for feature extraction. The operation behavior data includes unstructured data, which is transformed into image features before being input into the visual encoder.
7. The method according to claim 1, characterized in that, The terminal anomaly semantic anchor point library includes the core semantic anchor points for various types of terminal anomalies and the anomaly feature vector corresponding to each anchor point. The abnormal feature vector corresponding to the anchor point is a baseline vector generated by extracting multimodal feature vectors under abnormal scenarios.
8. The method according to claim 1, characterized in that, The fused feature vector is compared with a preset terminal anomaly semantic anchor point library to calculate an anomaly judgment score, including: The fused feature vector is compared with the abnormal feature vector in the preset terminal abnormal semantic anchor point library to calculate the cosine similarity. When the cosine similarity is greater than the set similarity threshold, it is included in the judgment score. The anomaly assessment score is calculated by combining the base score of the anomaly assessment with the similarity between the fused feature vector and each anchor point in the terminal anomaly semantic anchor point library.
9. The method according to claim 1, characterized in that, Precise access control of the terminal based on the anomaly assessment results includes: when the terminal is determined to be abnormal based on the anomaly assessment score, allowing applications / systems within the access permission range and generating alarm logs; when the terminal is determined to be normal based on the assessment score, allowing applications / systems within the access permission range; and when the terminal is determined to be abnormal based on the anomaly assessment score, restricting all access permissions. When any of the following anomalies occur: the terminal is determined to be abnormal based on the anomaly assessment score, the terminal's unique identifier is detected to have been tampered with, the encrypted tunnel is abnormal, or the terminal is engaging in malicious attacks, the security access gateway closes the corresponding encrypted channel using the unique identifier of the terminal experiencing the anomaly, adds the terminal's unique identifier to the blacklist, and rejects all access requests from the corresponding terminal. After the corresponding terminal performs rectification, it sends a rectification verification request. The security access gateway then re-assesses the anomaly. If the anomaly assessment result indicates no anomaly, the unique identifier of the rectified terminal is removed from the blacklist and its access permissions are restored.