A security enhancement device and a security enhancement method

Abstract

The application discloses a security enhancement device and a security enhancement method, and belongs to the technical field of data processing. The security enhancement device comprises a white-box encryption module, an international algorithm engine and a national secret algorithm engine which are internally processed by white-box processing, and is used for providing a password algorithm engine processed by white-box processing to realize white-box storage of a key and password operation; a security service module connected with the white-box encryption module and used for providing a security function service to a mobile application based on the white-box encryption module; a reinforcement execution module used for providing a running state security protection for the security service module and the white-box encryption module; and an interface management module connected with the white-box encryption module, the security service module and the reinforcement execution module respectively and used for controlling access authority of the mobile application to the security enhancement device and managing a life cycle of the security enhancement device. The security enhancement device can realize effective security protection of a mobile terminal.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, specifically relating to a security enhancement device and a security enhancement method. Background Technology

[0002] With the rapid development of the mobile internet and the digital economy, mobile applications have become deeply integrated into key areas such as payment, finance, the Internet of Things, and e-government, making mobile terminal security a cornerstone of the digital economy. However, the security protection of mobile applications faces increasingly severe challenges.

[0003] According to the mobile application security risk analysis of OWASP (Open Web Application Security Project), client application scenarios mainly face the following three types of security risks: (1) Code risks: including application code being reverse engineered, code being tampered with (implanting malicious logic or bypassing security checks), and security defects in the client code itself (such as buffer overflows, logic vulnerabilities, etc.). (2) Data and communication risks: covering insecure local data storage methods (such as storing sensitive data in plaintext), communication links between the client and the server not being effectively protected, and data leakage risks caused by insufficient or improper application of encryption technology. (3) Access and environment risks: mainly reflected in vulnerabilities in the identity authentication mechanism (such as weak passwords, authentication bypass), improper use of the platform, imperfect authorization management, and the implantation of additional malicious functions into the application runtime environment. The above three types of risks are intertwined, and it is difficult to build an effective security protection system by preventing only one type of risk.

[0004] Therefore, how to provide a security enhancement device to achieve effective security protection for mobile terminals is an urgent problem to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a security enhancement device and a security enhancement method, which can achieve effective security protection for mobile terminals.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a security enhancement device embedded in a mobile application, comprising: The white-box encryption module has a built-in international and national cryptographic algorithm engine that has been white-boxed, which is used to provide a white-boxed cryptographic algorithm engine to achieve white-box storage of keys and cryptographic operations. The security service module, connected to the white-box encryption module, is used to provide security function services to mobile applications based on the white-box encryption module. The hardened execution module provides runtime security protection for the security service module and the white-box encryption module. The interface management module connects to the white-box encryption module, the security service module, and the hardening execution module, respectively. It is used to control the access permissions of mobile applications to the security enhancement device and to manage the lifecycle of the security enhancement device.

[0007] Secondly, embodiments of this application provide a security enhancement method applied to a mobile terminal equipped with a security enhancement device, comprising: In response to the trigger operation of the security enhancement device initialization, the device fingerprint of the mobile terminal is obtained; A secure transmission channel is established between the pre-set white-box initial key and the security enhancement device backend, and an initialization request carrying the device fingerprint is sent to the security enhancement device backend through the secure transmission channel. Receive initial key data sent from the security enhancement device's backend; The initial key data is subjected to security protection processing to obtain the security-protected key data; The security-protected key data is stored in a preset hardware security area, and the device fingerprint is bound to the security-protected key data to complete the initialization of the local security instance.

[0008] Thirdly, embodiments of this application provide a service key download method based on a security enhancement device, applied to a mobile terminal equipped with a security enhancement device, including: In response to a business key download request triggered by a mobile application, the stored advanced ciphertext data is read from the hardware security zone. The advanced ciphertext data includes: instance data ciphertext, advanced white-box business root key, and access salt. Obtain the access password for the security enhancement device provided by the user; The access key for the security enhancement device is recalculated based on the access password and access salt. Decrypt the ciphertext of the instance data using the access key of the recalculated security enhancement device to recover the instance data; the instance data contains at least the device fingerprint and white-box protection key bound to the device at initialization. Obtain the current device fingerprint of the mobile terminal; Compare the current device fingerprint with the device fingerprint bound during initialization; If the comparison results indicate that they match, the service key is requested from the mobile application backend through a secure transmission channel, and the service key wrapped in the service root key is received. The business key, which is wrapped in the business root key, is stored in the hardware security area after being protected.

[0009] Fourthly, embodiments of this application provide a security enhancement method applied to the background of a security enhancement device, comprising: Receive an initialization request carrying the device fingerprint sent by the security enhancement device; Based on the initialization request, the hardware security module generates a security enhancement device instance identifier, a protection key, and a business root key. Bind the security enhancement device instance identifier to the device fingerprint; The protection key and the service root key are wrapped separately using the white-box initial key to obtain the protection key wrapped with the white-box initial key and the service root key wrapped with the white-box initial key. The instance identifier, the protection key wrapped in the white-box initial key, and the service root key wrapped in the white-box initial key are sent to the security enhancement device; Perform lifecycle status management on safety enhancement device instances.

[0010] Fifthly, embodiments of this application provide a security enhancement system, including: the security enhancement device described in the first aspect and the security enhancement device backend described in the fourth aspect; The security enhancement device communicates with its backend through a secure transmission channel. The backend generates and stores the root key through a hardware security module. The security enhancement device achieves end-side protection of the key through white-box processing and storage in a hardware security area.

[0011] In a sixth aspect, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in the second aspect.

[0012] In a seventh aspect, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method as described in the second aspect.

[0013] Eighthly, embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the steps of the method as described in the second aspect.

[0014] In this embodiment, the security enhancement device is divided into four independent, interconnected units: a white-box encryption module, a security service module, a hardening execution module, and an interface management module, forming a layered, in-depth security architecture from the inside out. Even if the outer interface and the hardened runtime environment are breached by attackers, the inner white-box encryption core algorithm and key data remain isolated and protected, preventing direct leakage of core cryptographic resources. Furthermore, each module has decoupled responsibilities and independent protection, while simultaneously coordinating and linking with each other, providing comprehensive protection across code execution security, cryptographic operation security, data storage and transmission security, application access control, and instance lifecycle. This addresses the shortcomings of existing single white-box solutions that only protect keys and lack protection for code and runtime environments.

[0015] On the one hand, the white-box encryption module incorporates international and national cryptographic algorithms that have been modified for white-box operation, ensuring that all cryptographic operations and key storage run within a white-box environment. Even if attackers reverse engineer binary code, capture memory data, or debug processes, they cannot extract plaintext keys from the code or memory, thus mitigating the risk of key theft at its source. On the other hand, the hardening execution module provides runtime isolation protection specifically for the white-box encryption and core security service modules. It continuously performs code integrity verification, code obfuscation, environmental risk detection, and virtualized isolated execution throughout the entire process of program compilation, startup, and execution. This forms a barrier against typical client-side attack methods, protecting the cryptographic operation logic from tampering and dynamic reverse engineering, ensuring that the white-box algorithm and key operation logic execute in a trusted and isolated environment, and significantly improving overall anti-cracking capabilities. Furthermore, this installation enhancement device is embedded in existing mobile applications as a software component, eliminating the need for a separate security hardware chip on the terminal. It achieves hardware-level protection solely by relying on the terminal's native system security capabilities in conjunction with white-box encryption, without requiring large-scale refactoring of business code, resulting in lower deployment costs and a wider range of applicable terminals. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the security enhancement device provided in the embodiments of this application.

[0017] Figure 2 This is a first flowchart illustrating the security enhancement method provided in this application embodiment.

[0018] Figure 3 This is a flowchart illustrating the process of obtaining securely protected key data as provided in the embodiments of this application.

[0019] Figure 4 This is a flowchart illustrating the service key download method based on a security enhancement device provided in this application embodiment.

[0020] Figure 5 This is a second flowchart illustrating the security enhancement method provided in the embodiments of this application.

[0021] Figure 6 This is a schematic diagram of the security enhancement system provided in the embodiments of this application.

[0022] Figure 7 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0025] With the rapid development of the mobile internet and the digital economy, mobile applications have become deeply integrated into key areas such as payment, finance, the Internet of Things, and e-government, making mobile terminal security a cornerstone of the digital economy. However, the security protection of mobile applications faces increasingly severe challenges.

[0026] According to the OWASP (Open Web Application Security Project) mobile application security risk analysis, client application scenarios mainly face the following three types of security risks: (1) Code risks: including application code being reverse engineered, code being tampered with (implanting malicious logic or bypassing security checks), and security defects in the client code itself (such as buffer overflows, logic vulnerabilities, etc.). (2) Data and communication risks: covering insecure local data storage methods (such as storing sensitive data in plaintext), communication links between the client and the server not being effectively protected, and data leakage risks caused by insufficient or improper application of encryption technology. (3) Access and environment risks: mainly reflected in vulnerabilities in the identity authentication mechanism (such as weak passwords, authentication bypass), improper platform usage, imperfect authorization management, and the implantation of additional malicious functions into the application runtime environment. The above three types of risks are intertwined, and it is difficult to build an effective security protection system by preventing only one type of risk.

[0027] To address the aforementioned issues, existing technical solutions suffer from the following drawbacks: Firstly, traditional key protection relies heavily on dedicated hardware security chips for terminals, and many ordinary Android, iOS, and HarmonyOS terminals lack the necessary hardware, resulting in high deployment costs and narrow coverage. Secondly, purely software-based white-box solutions can only protect keys and lack code hardening, runtime environment detection, and device binding capabilities. Attackers can bypass protection through root / jailbreaking, emulators, dynamic debugging, code injection, and other means to steal keys and sensitive business data.

[0028] On the other hand, existing mobile security tools are fragmented in function, with code obfuscation, encrypted communication, key storage, and device verification being independent components. This makes it impossible to form a unified and collaborative protection system. Developers need to combine multiple security components to develop, which can easily lead to vulnerabilities such as interface incompatibility, inconsistent security policies, and protection gaps.

[0029] In addition, existing cryptographic algorithms have poor compatibility. Most security components only support international algorithms or only support Chinese cryptographic algorithms, which cannot simultaneously meet the domestic commercial cryptographic compliance and overseas business encryption requirements. The client initialization, business key distribution and back-end management processes are fragmented, lacking an integrated closed-loop security process from end to back-end.

[0030] In view of the above-mentioned deficiencies of the prior art, this application provides a security enhancement device, which is an integrated software device with four progressive defenses from the inside out, embedded in the mobile application, with each module performing its own function and working together for protection. The core inner white-box encryption module serves as the cryptographic foundation, integrating both international and national cryptographic dual-algorithm engines to ensure that keys are stored and processed without plaintext throughout the entire process, thus resolving key leakage issues. The middle service layer builds a security service module that reuses the underlying white-box capabilities, uniformly encapsulating five common security capabilities: device fingerprinting, instance management, secure computation, hardware secure storage, and white-box encrypted transmission channels. It provides standardized security services externally, avoiding redundant development of encryption logic for different business applications. The runtime protection layer adds a hardening execution module, specifically providing full-process protection for the inner cryptographic core during compilation and runtime. Through code obfuscation, integrity verification, environmental risk detection, and virtualization to isolate the runtime environment, it blocks reverse engineering, debugging, and tampering attacks. The outer management layer sets up an interface management module to uniformly manage all capability exits, controlling application access permissions and the entire lifecycle of secure instances. This enables trusted access and manageable instance status, while also providing lightweight standard APIs to reduce business integration and modification costs. This four-layer architecture forms an onion-like defense-in-depth; failure of the outer layer does not directly expose the core keys and encryption logic. Each module verifies itself through mutual linkage, resolving the overall security collapse caused by the failure of a single protection component.

[0031] The following combination Figure 1 The security enhancement device provided in the embodiments of this application will be described.

[0032] Figure 1 This is a schematic diagram of the structure of a safety enhancement device provided in an embodiment of this application, as shown below. Figure 1 As shown in the embodiment of this application, the security enhancement device 100 is embedded in a mobile application. The security enhancement device 100 includes: a white-box encryption module 101, which has a built-in white-box processed international algorithm engine and a national cryptographic algorithm engine, used to provide a white-box processed cryptographic algorithm engine to achieve white-box storage of keys and cryptographic operations; and a security service module 102, connected to the white-box encryption module 101, used to provide security function services to the mobile application based on the white-box encryption module 101.

[0033] It should be noted that all cryptographic operations such as encryption, decryption, and signing in mobile applications involve access to key data. With conventional cryptographic algorithms, the key exists in plaintext in memory or program files during runtime. Attackers can directly obtain the key through reverse engineering, memory access, and dynamic debugging, leading to the leakage of business data and payment credentials. Furthermore, existing encryption components on the market only support a single internationally accepted algorithm or a domestically developed commercial cryptographic algorithm, failing to simultaneously meet domestic commercial cryptographic compliance requirements and overseas business encryption needs.

[0034] In this embodiment, a white-box encryption module is set as the underlying cryptographic operation base of the entire device, uniformly carrying all cryptographic algorithm operation logic. All key storage and operation processes are white-box processed to eliminate the risk of key plaintext exposure from the root. At the same time, it integrates two types of cryptographic algorithm engines to uniformly provide standardized cryptographic computing capabilities to the outside world, so that other upper-layer modules do not need to develop encryption logic separately.

[0035] For example, the international algorithm engine has a built-in general commercial cryptographic algorithm executor, which includes at least the RSA (Rivest-Shamir-Adleman) asymmetric cryptographic algorithm and the AES (Advanced Encryption Standard) symmetric cryptographic algorithm, for data encryption and identity signature verification in routine cross-regional business.

[0036] The national cryptographic algorithm engine has built-in cryptographic algorithm execution programs specified by the national commercial cryptography standard. It includes at least the SM2 (SM2 Elliptic Curve Public Key Cryptography Algorithm) asymmetric cryptographic algorithm and the SM4 (SM4 Block Cipher Algorithm) symmetric cryptographic algorithm to meet the requirements for compliant use of commercial cryptography in domestic financial and payment scenarios.

[0037] White-box processing refers to the code transformation of the cryptographic algorithm's execution logic and key storage logic, so that the complete plaintext key will not appear during the algorithm's operation, and there is no complete key data that can be directly extracted in the program file or running memory.

[0038] Cryptographic operations include all cryptographic-related operations such as data encryption, data decryption, digital signature, signature verification, and hash digest calculation.

[0039] Key white-box storage means that keys are not written in plaintext to program installation packages, local disks, or running memory. All key data is permanently stored in ciphertext form after undergoing multiple transformation processes.

[0040] In practical implementation, the white-box encryption module 101 internally undergoes white-box transformation of both the international and national cryptographic algorithm engines. After the transformation, both types of algorithm engines are uniformly deployed within the module. When the security service module 102 initiates a cryptographic calculation request, the request instruction is transmitted to the white-box encryption module 101, which selects the corresponding algorithm engine to complete the calculation. During the calculation process, the key remains in a white-box state throughout. After the calculation is completed, only the encryption result or signature result is output, and no original key data is output externally. All random numbers used in the calculation are generated by the module's built-in true random number generator, ensuring the randomness and security of cryptographic calculations. The white-box encryption module 101 continuously provides underlying cryptographic calculation support to the security service module 102, providing basic cryptographic capabilities for device fingerprint generation, secure storage, and secure transmission links.

[0041] It should be noted that mobile applications require several common security capabilities, including unique device identification, secure hardware storage, encrypted transmission channels, and instance lifecycle binding. If various security logics are developed separately by the application's business code, issues such as non-standard algorithm calls, non-compliant key storage, and tamperable device identifiers may arise. All security functions rely on underlying cryptographic operations; developing them separately would lead to code redundancy and inconsistent security standards.

[0042] Therefore, in this embodiment of the application, a security service module 102 is set to interface with a white-box encryption module 101 to uniformly reuse the underlying white-box cryptographic capabilities, centrally encapsulate all the basic security services required by the mobile application, and the upper-layer business only needs to call the standardized service capabilities without having to be aware of the underlying cryptographic implementation logic, thus unifying and standardizing the security capability calling process and eliminating various vulnerabilities caused by the business's self-developed security logic.

[0043] For example, security function services refer to standardized basic security capabilities provided for mobile applications, including device identification, password calculation, local encrypted storage, encrypted network transmission, and device instance binding.

[0044] In practical implementation, the security service module 102 establishes a stable data interaction channel with the white-box encryption module 101. The security service module 102 is internally divided into an instance personalization unit, a device fingerprint unit, a secure computing unit, a secure storage unit, and a secure link unit. The instance personalization unit generates a unique security enhancement device instance identifier for each mobile device and manages the instance's lifecycle. The device fingerprint unit collects device information and generates a device fingerprint based on that information. The secure computing unit provides cryptographic calculation functionality based on white-box algorithms and includes a built-in true random number generator. The secure storage unit provides secure storage functionality based on white-box algorithms. The secure link unit provides a protocol link for the secure transmission channel based on white-box algorithms.

[0045] When each unit executes its corresponding security capabilities, it uniformly invokes the white-box encryption module to complete the cryptographic calculations. The instance personalization unit generates a unique device instance identifier and manages its status; the device fingerprint unit collects multi-dimensional information from the terminal to generate a unique device identification identifier; the secure computing unit forwards business cryptographic calculation requests to the underlying white-box module; the secure storage unit uses white-box algorithms to encrypt local data and connects to the terminal hardware's secure area; and the secure link unit builds an encrypted transmission channel based on white-box algorithms. All key data generated by the calculations of all units is handed over to the white-box encryption module for white-box processing, after which data storage or network transmission is completed.

[0046] In this embodiment, the hardened execution module 103 is used to provide runtime security protection for the security service module 102 and the white-box encryption module 101.

[0047] It should be noted that the reason for setting up the hardening execution module 103 is that the white-box encryption module 101 and the security service module 102 carry the core cryptographic data and operational logic of the entire device. During program execution, attackers can analyze and tamper with the core module code through debugging tools, simulators, code injection, memory tampering, and other means, thereby compromising the white-box protection logic and stealing key data. Existing security solutions only perform code hardening once during the program compilation stage, lacking continuous protection measures during the runtime phase, and runtime environment risks cannot be intercepted in real time.

[0048] In this embodiment, a hardening execution module 103 is set up to provide full-cycle protection for the underlying white-box encryption module 101 and the security service module 102. It continuously performs code hardening and environmental risk detection during the program compilation stage, program startup stage, and business operation stage, isolates the core code execution space, blocks various reverse attack methods, and ensures that the cryptographic operation logic is not tampered with or debugged.

[0049] For example, runtime security protection refers to the protection operations that are continuously executed throughout the entire program execution process, covering the entire stages of program startup, business operation, and data storage, and intercepting various attacks targeting program code, runtime memory, and device environment in real time.

[0050] In this embodiment, the hardened execution module includes: a local code protection unit for verifying code integrity; a code obfuscation and hardening unit for introducing obfuscation algorithms into binary code during compilation; a security detection and evaluation unit for detecting and evaluating the risks of the current operating environment; and a virtualized high-security operating environment unit for isolating and executing critical code, and providing string encryption, runtime flow control, runtime stack detection, and virtual machine integrity self-detection.

[0051] In practice, the hardening execution module 103 operates independently, continuously monitoring the operational status of the white-box encryption module 101 and the security service module 102. The local code protection unit within the hardening execution module 103 verifies the integrity of the program's binary code in real time, identifying code additions, deletions, and modifications. The code obfuscation and hardening unit injects multi-layered obfuscation logic into the binary machine code during the program compilation stage. The security detection and evaluation unit continuously scans the terminal's operating environment, identifying risks such as device jailbreaking, device rooting, emulator operation, debug program mounting, memory tampering, and application signature anomalies. The virtualization high-security operating environment unit constructs an independent isolated operating space, transferring critical code such as key calculations and signature calculations to this isolated space for execution, simultaneously performing string encryption, flow control, stack data detection, and virtual machine integrity verification. When any risky behavior is detected, the hardening execution module synchronously sends a risk command to the interface management module, terminating all cryptographic operations and locking the local security instance.

[0052] In this embodiment, the interface management module 104 is connected to the white-box encryption module 101, the security service module 102, and the hardening execution module 103, respectively, and is used to control the access permissions of mobile applications to the security enhancement device and manage the lifecycle of the security enhancement device 100.

[0053] It should be noted that the white-box encryption module 101, security service module 102, and hardening execution module 103 all carry sensitive cryptographic logic. If mobile applications are allowed to directly call these internal modules without restriction, unauthorized third-party applications and multiple instances of the application could illegally access cryptographic capabilities to steal key data. Furthermore, the security enhancement device instance includes various state change operations such as initialization, key replacement, and instance cleanup. The lack of a unified management unit can lead to security issues such as instance state chaos and failure to promptly destroy keys.

[0054] By setting up an interface management module as the unified external interaction entry point for the entire device, it is possible to uniformly control access permissions for external applications, centrally manage the entire lifecycle of security instances, uniformly encapsulate standardized call interfaces, isolate external business from internal core cryptographic modules, and achieve trusted access and controllable instance status.

[0055] For example, access permissions are the restrictions on mobile applications calling the internal capabilities of security enhancement devices; only authorized applications can initiate such calls.

[0056] The lifecycle is the complete operation process of a local instance of a security enhancement device, which includes four states: instance initialization, normal business operation, instance data clearing, and key rotation.

[0057] The interface management module 104 includes: an access control unit for controlling the access permissions of mobile applications to the security enhancement device instance; a lifecycle management unit for managing the initialization, normal operation, clearing, and key replacement of the instance; an operating system interface unit for interfaceing with the hardware secure storage mechanism of the operating system; and an application programming interface unit for providing the mobile application with call interfaces for initialization, encryption, decryption, signing, and instance clearing.

[0058] In practice, the interface management module 104 establishes command interaction channels with the white-box encryption module 101, the security service module 102, and the hardening execution module 103, respectively. The internal access control unit of the interface management module 104 verifies the authorization identity of the mobile application initiating the call and rejects all call requests from unauthorized applications. The lifecycle management unit uniformly manages the instance initialization process, instance running status, local instance data clearing operations, and key rotation operations. The operating system interface unit establishes a data interaction channel between the device and the terminal operating system's hardware secure storage area. The application programming interface unit outputs standardized call interfaces to support applications initiating initialization, encryption, decryption, signing, and instance clearing operations. All business requests from mobile applications can only be forwarded to the internal functional modules through the interface management module 104; internal modules will not directly interact with external applications. After receiving the environmental risk signal reported by the hardening execution module 103, the interface management module 104 directly locks the local instance and rejects all new business call requests.

[0059] The overall collaborative execution logic of the four modules is as follows: After the mobile application initiates a security business request, the request instruction is first passed to the interface management module 104. The interface management module 104 verifies the application's access permissions and, after confirming authorization, forwards the instruction to the corresponding internal module. The hardening execution module 103 monitors the running status of the white-box encryption module 101 and the security service module 102 throughout the process, performing environment detection and code protection in real time. After receiving the business instruction, the security service module 102 calls the white-box encryption module 101 to complete the underlying cryptographic operation. The key data generated by the operation is processed in a white-box manner and then stored in the terminal hardware security area through the secure storage unit. When any module detects unauthorized access, code tampering, or abnormal device environment, the interface management module uniformly performs instance locking and operation termination operations. The four modules work together to complete risk handling, forming a complete closed-loop security protection. The entire architecture relies on the division of labor and cooperation of the four modules to solve multiple security risks such as key leakage, code reverse engineering, unauthorized calls, and device environment intrusion in one go.

[0060] By dividing the security enhancement device into a white-box encryption module, a security service module, a hardening execution module, and an interface management module, these four modules are arranged logically in layers: underlying cryptographic support, security capability encapsulation, runtime environment protection, and external access control, forming a complete security system with layered protection. The bottom-layer white-box encryption module is responsible for core cryptographic operations, the middle-layer security service module encapsulates general security capabilities, the hardening execution module is responsible for continuous runtime environment protection, and the outer-layer interface management module uniformly manages external access and instance lifecycle. External mobile applications can only initiate calls through the outer-layer modules; the inner-layer cryptographic operation logic is not directly exposed to the application. Even if any layer of protection logic is attacked and fails, the remaining three layers can still run independently and block sensitive data leakage, fully covering four types of client security risks: code execution risks, key storage and operation risks, device communication risks, and unauthorized call risks. The entire device is integrated as a software component, eliminating the need for independent security encryption hardware on the terminal, and is compatible with multiple mobile operating systems, reducing the workload of application integration and modification.

[0061] The above is an overall description of the security enhancement device 100. Based on the above security enhancement device, this application embodiment also provides a security enhancement method. Figure 2 This is a flowchart illustrating a security enhancement method provided in an embodiment of this application. Figure 2 As shown, the security enhancement method provided in this application embodiment may include S201 and S205.

[0062] S201: In response to the trigger operation of the security enhancement device initialization, obtain the device fingerprint of the mobile terminal.

[0063] In S201, the initialization trigger operation refers to the operation instruction generated when a user enters a sensitive business module such as payment or virtual card application for the first time after logging into the mobile application. This instruction wakes up the security enhancement device to start the local instance generation process.

[0064] Device fingerprints are fixed-length values ​​generated by hashing multi-dimensional inherent information of a mobile terminal. They can uniquely identify a single mobile device and cannot be arbitrarily tampered with or copied.

[0065] It's important to note that the backend needs to differentiate between different mobile terminals to prevent the reuse of the same key data across multiple devices, which could lead to cloning attacks. Without a unique device identifier, attackers could migrate application and key data to other terminals to launch unauthorized services. Collecting the device fingerprint at the beginning of the initialization process ensures that device identity information is maintained throughout the entire initialization interaction. The backend can then generate a unique instance key based on the fingerprint, and the fingerprint and key are bound together in subsequent storage, achieving a single, independent security instance for each terminal. Completing device information collection before initiating network requests avoids invalid requests without an identifier and the distribution of unauthorized keys.

[0066] In practice, after the security enhancement device detects the initialization trigger operation, the hardening execution module initiates a full-dimensional runtime environment detection. This detection includes checking the device's ROOT status, jailbreak status, emulator running status, debugger mounting status, program code integrity, memory tampering risks, and application signature legitimacy. If no anomalies are found during the environment detection, the device fingerprint unit within the security service module collects all available device information from the terminal. This information includes the mobile application installation package name, mobile application signing certificate, device brand, device model, a complete list of the terminal's built-in sensors, and the Android identifier assigned by the system. The device fingerprint unit concatenates all collected information in a fixed order, performs a SHA256 hash operation on the concatenated complete character set, and uses the output as the current terminal device fingerprint, temporarily storing it in memory for subsequent network requests. If the environment detection identifies a risk, the entire initialization process is terminated, and the device fingerprint collection operation is no longer performed.

[0067] S202: Establish a secure transmission channel with the security enhancement device backend based on the pre-set white-box initial key, and send an initialization request carrying the device fingerprint to the security enhancement device backend through the secure transmission channel.

[0068] In S202, the white-box initial key is a key pre-built into the security enhancement device installation package. After being white-boxed, it is used to negotiate and transmit session keys and encrypt various underlying keys issued by the backend during the initialization phase.

[0069] The secure transmission channel is a TLS transmission link modified based on white-box algorithms. All interactive data within the link continuously undergoes encryption operations, and the external network environment cannot parse the transmitted content.

[0070] The initialization request is an interactive message sent by the terminal to the security enhancement device's backend. The message carries the device fingerprint and is used to inform the backend that the current terminal needs to generate a dedicated security instance.

[0071] It should be noted that the network transmission link between the terminal and the backend is vulnerable to plaintext packet capture. The initialization request contains core device identity data such as the device fingerprint, and the various key data issued by the backend are highly sensitive cryptographic resources. Direct transmission through ordinary network channels could lead to the theft of identity information and key data by man-in-the-middle attacks. Therefore, a white-box initial key is pre-deployed within the device, and a dedicated encrypted transmission link is built based on this key. All interactive data is encrypted throughout the entire process to prevent data leakage caused by network packet capture. Simultaneously, the device fingerprint is uploaded to the backend, which can use the fingerprint to distinguish the terminal and generate exclusive key data bound to that device.

[0072] In practice, the secure link unit within the security service module reads the white-box initial key built into the device, calls the white-box encryption module to complete session key negotiation, and builds a secure transmission channel based on the negotiated session key. After the channel is built, the interface management module encapsulates an initialization request message, writing the device fingerprint collected in the previous step into the message. The entire message is then sent to the security enhancement device's backend via the secure transmission channel. Throughout the message transmission, the hardening execution module continuously monitors the program's running status, preventing memory tampering and data hijacking during transmission. The transmission channel remains encrypted until the entire initialization process is completed, and encrypted session resources are not released during the process.

[0073] S203: Receive the initial key data sent from the security enhancement device's backend.

[0074] In S203, the initial key data is a set of data generated and distributed by the security enhancement device backend through the hardware security module. The initial key data includes the security enhancement device instance identifier, the protection key wrapped by the white-box initial key, and the business root key wrapped by the white-box initial key.

[0075] The security enhancement device instance identifier is a unique number generated by the security enhancement device backend for a single device, used to distinguish local security instances of different terminals.

[0076] The protection key is an underlying key generated in the background of the security enhancement device, used by the terminal to establish a secure transmission channel.

[0077] The business root key is an underlying key generated in the background of the security enhancement device, used to encrypt business keys used in subsequent business scenarios.

[0078] It should be noted that core cryptographic resources such as protection keys, business root keys, and security instance identifiers cannot be randomly generated locally on the terminal. Locally generated keys lack the security guarantee of a hardware encryption machine, and their randomness and resistance to cracking are insufficient. Deploying a hardware security module in the backend to uniformly generate various underlying keys and distribute them to the terminal via an encrypted channel ensures the compliance and security of the key generation process. Only after receiving the data from the backend can the terminal perform local key multi-layer encryption conversion and storage operations, completing the preparation of security instance data.

[0079] In practice, the secure transmission channel continuously monitors messages sent from the backend. Upon arrival at the terminal, the secure link unit of the security service module decrypts the messages, with the entire decryption process executed by the white-box encryption module. After decryption, all initial key data is extracted from the message and temporarily stored in an isolated memory area within the virtualized high-security operating environment, without being written to the terminal's regular disk. The hardening execution module continuously verifies the integrity of received data, identifying anomalies such as message tampering and data truncation. If an anomaly is detected, all key data is discarded and the initialization process terminated.

[0080] S204: Perform security protection processing on the initial key data to obtain the security-protected key data.

[0081] In S204, the security protection process involves performing a series of operations, including white-box transformation and secondary encryption, on the key data issued from the backend, thereby enhancing the security strength of key storage.

[0082] The white-box protection key is the key data obtained by sending the protection key, which is wrapped in the white-box initial key and sent from the backend, into the white-box encryption module for transformation and processing.

[0083] The white-box business root key is the key data obtained by sending the business root key, which has been wrapped by the white-box initial key issued by the backend, into the white-box encryption module for transformation and processing.

[0084] The advanced white-box service root key is key data generated by encrypting the white-box service root key twice using the white-box security storage key. It is key data that can be stored in the hardware security area.

[0085] It should be noted that the protection key and business root key issued from the backend are only wrapped in a single layer of white-box initial key, and directly stored on the terminal still pose a risk of reverse extraction. Performing white-box transformation and secondary encryption on both types of keys sequentially increases the difficulty of key cracking. Even if an attacker obtains the terminal's stored files, they cannot decrypt the plaintext key layer by layer. The layered key data meets hardware security zone storage standards, achieving multi-layered protection.

[0086] In practice, the internal secure storage unit of the security service module calls the white-box encryption module to process the initial key data. In the first stage, the protection key, wrapped by the white-box initial key, is sent to the white-box encryption module for white-box transformation, generating a white-box protection key. In the second stage, the business root key, wrapped by the white-box initial key, is sent to the white-box encryption module for white-box transformation, generating a white-box business root key. In the third stage, the device's built-in white-box secure storage key is retrieved, and a second encryption operation is performed on the white-box business root key. The output of this operation serves as the advanced white-box business root key, which is the security-protected key data. All processing operations are performed within a virtualized high-security operating environment. Temporary data generated during processing is automatically cleared after the operation is completed and is not retained in memory.

[0087] S205: Store the security-protected key data in a preset hardware security area and bind the device fingerprint to the security-protected key data to complete the initialization of the local security instance.

[0088] In S205, the hardware security zone is an independent secure hardware runtime space built into the mobile operating system. For Android, it corresponds to the Trusted Execution Environment (TEE), and for iOS, it corresponds to the Secure Enclave. This zone can independently generate encryption keys and is isolated from the runtime space of ordinary applications.

[0089] Device fingerprint binding establishes an association mapping relationship between device fingerprints and multi-layered encryption key data within the hardware security area, and simultaneously verifies fingerprint consistency when reading key data.

[0090] A local security instance is an independent and secure operating platform dedicated to a single mobile device. It contains a complete set of data, including an instance identifier, a bound device fingerprint, and multi-layer encryption keys. It can only be used normally on the terminal that generated the instance.

[0091] It's important to note that the disk storage area of ​​ordinary terminals has weak protection capabilities, making encryption keys easily accessible and susceptible to tampering. The terminal operating system's built-in hardware security area possesses independent encryption capabilities, providing hardware-level storage protection. The processed key data is stored in the hardware security area and simultaneously bound to the device fingerprint, establishing a fixed association between the key data and the device identity. Subsequent business key downloads and encryption operations will verify the fingerprint matching relationship; cross-device use of key data will directly fail verification, preventing key migration and theft at the storage level. After completing the storage and binding operations, a dedicated local security instance is officially generated, and the initialization process is complete.

[0092] In practice, the operating system interface unit within the interface management module initiates a storage call command to the terminal hardware security zone, which then generates a dedicated hardware storage key locally. This hardware storage key uniformly encrypts three types of data—instance data ciphertext, advanced white-box business root key, and access salt—to generate advanced ciphertext data. The hardware security zone persistently writes this advanced ciphertext data to isolated storage space and simultaneously stores a mapping relationship locally, recording the correspondence between the current device fingerprint and the entire set of encrypted key data. After the storage operation is complete, the security enhancement device synchronously reports the initialization completion status to the mobile application and the security enhancement device backend, officially activating the local security instance and completing the full initialization process. The entire storage operation is monitored by the hardening execution module, which automatically clears written data and resets the instance status when hardware zone write anomalies or data tampering are detected.

[0093] In this embodiment of the application, storing the key data after security protection processing into a preset hardware security area may include: storing the instance data ciphertext, the advanced white-box business root key, and the access salt used to generate the access key of the security enhancement device into the preset hardware security area.

[0094] It should be noted that the instance data ciphertext and the advanced white-box business root key belong to two independent protection systems and need to be synchronously and persistently stored to fully support subsequent business key downloads and encryption operations. The access salt is a necessary input factor for reproducing the access key. If it is not persistently stored, the access key cannot be recalculated after the terminal restarts, making it impossible to decrypt and read the instance data ciphertext, thus causing the security instance to fail.

[0095] All three types of data are stored uniformly in a hardware security zone, providing hardware-level protection based on the operating system's hardware isolation capabilities. Ordinary applications cannot read the data within this isolated space. The three types of data are stored synchronously, ensuring that instance identity data, underlying business keys, and key derivation factors are completely matched, allowing any subsequent business process to retrieve all necessary resources.

[0096] The hardware security zone is an independent hardware-isolated storage space provided by the mobile operating system. Android corresponds to the Trusted Execution Environment, and iOS corresponds to the Security Isolation Unit, which has independent encryption computing and isolated storage capabilities.

[0097] In this embodiment, the instance data ciphertext, the advanced white-box service root key, and the access salt used to generate the security enhancement device access key are stored in a preset hardware security area. Specifically, this can be done by: generating a hardware storage key based on the hardware security area; encrypting the instance data ciphertext, the advanced white-box service root key, and the access salt using the hardware storage key to form advanced ciphertext data; and storing the advanced ciphertext data in the preset hardware security area.

[0098] In practice, the interface management module's internal operating system interface unit uniformly aggregates three types of data to be stored: instance data ciphertext, advanced white-box business root key, and access salt. The interface unit initiates a storage command to the hardware security zone, which automatically generates a dedicated hardware storage key. This key is used to encrypt all three types of data to form advanced ciphertext data. The hardware security zone persistently writes the advanced ciphertext data to isolated storage space and simultaneously establishes an internal association mapping, marking the ciphertext data as corresponding to the fingerprint of the current terminal device. Throughout the storage operation, the hardening execution module monitors the operating environment. If risks such as debugging mounts or memory tampering are detected, the storage process is terminated directly, and the written data is cleared. After the storage operation is completed, the hardware security zone sends a storage success signal to the security enhancement device, and the initialization process enters the final stage.

[0099] As an example, such as Figure 3 As shown, the initial key data undergoes security protection processing to obtain the securely protected key data, which may include: S2041: Whitebox the protection key wrapped by the whitebox initial key to obtain the whitebox protection key.

[0100] It's important to note that the protection key issued by the backend is merely an outer wrapper around the white-box initial key; the key itself is not transformed by a white-box algorithm. An attacker, after stripping away the outer wrapping logic, can directly read the complete plaintext protection key. This protection key is used to establish a secure transmission channel between the terminal and the backend; its leakage would render all subsequent network interaction data unencrypted. By performing an independent white-box transformation on the wrapped protection key before storage, the key is disassembled and integrated into the algorithm's execution logic. Therefore, continuous and complete protection key data no longer exists in the program file or runtime memory. Even if an attacker cracks the white-box initial key's wrapping logic, they cannot directly extract the usable protection key, ensuring the security of cryptographic resources during the transmission channel establishment phase.

[0101] In S2041, the protection key wrapped by the white-box initial key is the ciphertext of the protection key after the security enhancement device backend performs encryption operations using the preset white-box initial key, and is sent from the backend to the terminal through a secure transmission channel.

[0102] White-box processing relies on the internal algorithm engine of the white-box encryption module to obfuscate the code logic and split and transform the data in the key ciphertext, so that the complete form of the key will not appear in the program file or runtime memory.

[0103] The white-box protection key is a new type of ciphertext generated after the wrapped protection key is transformed and processed by the white-box encryption module, and is used as protection key data for long-term local storage.

[0104] In practice, the security service module retrieves the initial key data issued from the backend, extracts the protection key wrapped in the white-box initial key, and sends this data to the white-box encryption module. The white-box encryption module calls its built-in white-box algorithm engine to perform a complete white-box transformation operation, which is performed in isolation within a virtualized high-security operating environment. During the operation, the module's built-in true random number generator outputs random factors to participate in the transformation logic. After the transformation is completed, a white-box protection key in a fixed format is output. The intermediate temporary data generated during the operation is automatically cleared by the hardening execution module after the operation and is not retained in the memory space. The white-box protection key is temporarily stored in isolated memory for subsequent process calls.

[0105] S2042: Whitebox the service root key that has been wrapped by the whitebox initial key to obtain the whiteboxed service root key.

[0106] It should be noted that the business root key is the upper-level foundational key of the entire business key system. All business keys used in subsequent business scenarios rely on the business root key for encryption. Leakage of the business root key will result in the risk of all business keys being stolen. The business root key issued by the backend is only encrypted with a single layer of white-box initial key. The key data has a regular format, and reverse engineering tools can quickly identify and strip away the outer encryption logic.

[0107] A white-box transformation is performed specifically on the business root key, scrambling the original key data structure and integrating the business root key into the cryptographic operation code logic. Even if an attacker obtains the terminal storage file, they will not be able to locate the complete business root key data, thus ensuring the underlying security of the entire business key system from the source.

[0108] In S2042, the service root key wrapped by the white-box initial key is the ciphertext of the service root key generated by the security enhancement device backend using the white-box initial key, and is synchronously sent to the mobile terminal along with the initial key data.

[0109] The white-box business root key is the ciphertext form obtained by transforming the wrapped business root key through the white-box encryption module, and serves as the original input data for the secondary encryption operation.

[0110] In practice, the security service module extracts the business root key, wrapped in a white-box initial key, from the initial key data and transmits it to the white-box encryption module for white-box transformation. During the transformation process, random data output by a true random number generator is introduced to disrupt the key data arrangement. Throughout the transformation, the hardening execution module enables runtime stack detection and flow control protection to prevent dynamic debugging and reading of intermediate key data. After the transformation operation is completed, the white-boxed business root key is output and stored in a virtualized isolated memory area, stored separately from the white-boxed protection key generated in the previous step to avoid interference between the two types of key data.

[0111] S2043: Use the white-boxed secure storage key to perform secondary encryption on the white-boxed business root key to generate an advanced white-boxed business root key, which serves as the key data after security protection processing.

[0112] It should be noted that the white-boxed service root key only completes the white-box transformation at the software level. If the terminal hardware security zone protection mechanism fails, the white-boxed service root key can still be read and parsed in batches. Adding a layer of encryption based on the secure storage key, an independent encryption protection layer is superimposed on top of the software white-box protection, forming a double encryption barrier.

[0113] The protection key is only used for establishing the transmission channel and does not require additional secondary encryption. The business root key manages all business keys and has a higher security level requirement; therefore, secondary encryption is only performed on the business root key. The advanced white-box business root key generated after secondary encryption is the final output data of the entire security protection process and is uniformly sent to the hardware secure area for persistent storage, improving the anti-cracking capability of the underlying keys in the business key system.

[0114] In S2043, the white-boxed secure storage key is a dedicated key pre-installed within the security enhancement device and used for white-box transformation, specifically for secondary encryption operations on local key data.

[0115] Secondary encryption involves using an independent secure storage key to perform a new round of symmetric encryption operations on the complete ciphertext of the white-box business root key, thus adding an extra layer of independent encryption protection.

[0116] The advanced white-box business root key is a multi-layered encrypted ciphertext generated by the white-box business root key after being encrypted twice by the secure storage key. It is the key data that is finally output by the security protection processing flow.

[0117] In practice, the security service module reads the white-box security storage key built into the device and simultaneously sends this key, along with the white-box business root key generated in the previous step, to the white-box encryption module. The white-box encryption module uses a symmetric cryptographic algorithm to perform a second encryption operation, which is continuously executed in isolation within a virtualized high-security operating environment. After the encryption operation is complete, the advanced white-box business root key is directly output; this data is the final key data after the initial key data has undergone complete security protection processing. The temporary copy of the white-box business root key generated during the operation is immediately deleted after encryption, retaining only the advanced white-box business root key for subsequent hardware secure area storage processes.

[0118] The protection key and business root key issued by the security enhancement device's backend are only wrapped in a single layer using a white-box initial key. This single-layer encryption protection has security vulnerabilities. If an attacker obtains the application installation package and reverse-engineers the white-box initial key, they can peel back the layers to obtain the key data without deep transformation.

[0119] This application embodiment employs three consecutive, progressive processing steps to sequentially complete the white-box transformation of the protection key, the white-box transformation of the business root key, and a secondary encryption operation of the business root key, forming a multi-layered protection structure with two layers of white-box transformation superimposed on a layer of hardware-associated encryption. The two types of core keys undergo white-box processing independently, achieving deep integration of key data and program code, blocking the path of static reverse extraction of keys. An additional layer of encryption is added for the business root key, further increasing the barrier to cracking it. All processing operations are completed within a virtualized, high-security operating environment, and temporary computation data is automatically destroyed to avoid intermediate key forms remaining in memory. The advanced white-boxed business root key obtained after these three layers of processing possesses multi-layered encryption protection capabilities. After being stored in the terminal hardware security area, it achieves a dual superposition of software white-box protection and hardware storage protection, reducing the risk of key leakage.

[0120] In this embodiment, in response to the triggering operation of the security enhancement device initialization, an access key for the security enhancement device can also be generated. The security enhancement device access key is a key derived from a local random access password and a random access salt through multiple iterative hash calculations, specifically used for local instance data encryption decryption and local authentication verification. Specifically, in response to the triggering operation of the security enhancement device initialization, a random number is generated as the security enhancement device access password, and another random number is generated as the access salt; multiple iterative hash calculations are performed on the security enhancement device access password and access salt to obtain the security enhancement device access key.

[0121] In practice, after the security enhancement device detects the initialization trigger operation, the access control unit inside the interface management module calls the built-in true random number generator in the secure computing unit to generate a set of large random numbers as the access password, and simultaneously generates another set of independent large random numbers as the access salt. The secure computing unit calls the built-in hash algorithm of the white-box encryption module to perform multiple rounds of iterative hash operations with the access password and access salt as input. The number of iterations is a fixed security threshold, and the output of the multiple rounds of operations serves as the access key. The key generation process is performed entirely in a virtualized high-security operating environment. After generation, the access password is no longer persistently stored; only the access salt is retained for subsequent reproduction of the access key. The access key is temporarily stored in isolated memory for instance data encryption operations.

[0122] It should be noted that instance data requires a dedicated key for decryption and authentication after storage, and this decryption key cannot be uniformly distributed by the backend. Instance data differs across different terminal devices and application users; distributing a unified key from the backend would allow instance data to be mutually decrypted across devices.

[0123] Access keys are dynamically generated based on local random data on the terminal. Each device generates a unique access key for each initialization. Only the current device holds the original random data required to generate the access key, and other terminals cannot replicate the access key, thus preventing instance data from being decrypted and read across devices.

[0124] By binding the access key generation logic to the initialization trigger operation, the authentication key preparation is completed synchronously during the instance creation phase. This eliminates the need to add an extra key generation step to the business process, simplifying the overall process sequence.

[0125] After generating the access key for the security enhancement device, the instance data is encrypted using the access key to generate ciphertext of the instance data.

[0126] For example, the instance data includes at least one of the following: security enhancement device instance identifier, mobile application user identifier, instance status, device fingerprint, and white-box protection key.

[0127] Instance data is a collection of data used to describe the complete identity and running status of a local security instance, and includes multiple basic fields.

[0128] The security enhancement device instance identifier is a unique number assigned by the backend to the current terminal instance, used to distinguish security instances created by different devices.

[0129] A mobile application user identifier is a globally unique identification number assigned by a mobile application to the currently logged-in user.

[0130] Instance status indicates the current running stage of a local security instance, including four types of statuses: uninitialized, running normally, locked, and pending cleanup.

[0131] The instance data ciphertext is the ciphertext data obtained after the complete instance data has been encrypted using the access key, and the original instance information cannot be read directly.

[0132] In practice, the security service module aggregates all instance data fields and concatenates them into a complete data string in a fixed order. The secure computing unit retrieves the access key generated in the previous step and calls the built-in symmetric cryptographic algorithm of the white-box encryption module to perform encryption operations on the complete data string. During the operation, runtime stack detection is enabled to prevent key data from being dynamically captured. After the encryption operation is completed, the ciphertext instance data is output and stored in virtualized isolated memory, awaiting unified storage in the hardware secure area. The original plaintext instance data is immediately cleared from memory after encryption, leaving no plaintext copy on the terminal.

[0133] It should be noted that instance data contains various types of sensitive information that can be used to forge devices and hijack instances, such as instance identifiers, user identifiers, device fingerprints, and white-box protection keys. Plaintext storage will leak device identity and instance basic password resources.

[0134] The instance data is encrypted using a locally derived access key and stored in ciphertext. When reading the instance data, it must be decrypted using the access key. Programs that do not have the correct access key cannot parse the internal information of the instance.

[0135] Instance data and business root keys are encrypted separately, using two independent key systems for protection. The leakage of one key system will not cause the leakage of the other set of sensitive data simultaneously, reducing the overall security risk.

[0136] In this embodiment of the application, before obtaining the device fingerprint of the mobile terminal, the method further includes: performing security checks on the current operating environment, and the security checks include at least one of the following: root detection, jailbreak detection, emulator detection, code integrity detection, debug mode detection, memory detection, and signature verification.

[0137] It should be noted that the device fingerprint carries the terminal's unique identity information. The initialization process relies on the device fingerprint to generate a unique security instance and bind multi-layered key data. Various malicious attack methods first tamper with the terminal's operating environment and then initiate the initialization process, thereby forging a legitimate device identity and completing application cloning and key theft.

[0138] If a device fingerprint is collected without environmental verification, attackers can use emulators, debugging tools, and modified program code to tamper with device information. The backend will then issue keys based on the forged fingerprint, creating a security instance that can be copied across devices, rendering the entire key protection system completely ineffective.

[0139] Security checks are performed before device fingerprint collection, serving as the first security checkpoint in the initialization process. This allows for the early identification of various abnormal operating environments. If a risk is detected, the entire subsequent process is terminated immediately, preventing the generation of security instances bound to fake device information under unauthorized conditions. Multi-dimensional detection measures cover all types of attack paths, including software and hardware tampering, program modification, and debugging hijacking, blocking attacks that forge device identities at the source and ensuring that the collected device fingerprint corresponds to a genuine and trustworthy terminal operating environment.

[0140] In practice, upon receiving the initialization trigger, the hardening execution module prioritizes initiating all security detection items to scan the operating environment in parallel. The entire scanning process is performed within a virtualized, high-security operating environment. If any detection item identifies an environmental risk, the hardening execution module immediately sends a risk signal to the interface management module. The interface management module then directly interrupts the initialization process, ceasing all subsequent steps such as device fingerprint collection, channel setup, and key exchange. Only when all detection items show no abnormalities does the hardening execution module issue an issuance command to the security service module. Only then will the device fingerprint unit initiate the device information collection logic, generating device fingerprint data for subsequent network interactions. The entire detection process is protected against code obfuscation, ensuring that the detection logic itself cannot be reverse-engineered and guaranteeing the reliability and effectiveness of the risk identification logic.

[0141] In this embodiment of the application, obtaining the device fingerprint of a mobile terminal may include: obtaining the device information of the mobile terminal, concatenating the device information to obtain a hash value, which is used as the device fingerprint.

[0142] For example, the device information includes at least one of the following: mobile application installation package name, mobile application signing certificate, device brand, device model, sensor list information, and obtainable Android identifiers.

[0143] Device information consists of various raw parameters that distinguish the identity of applications and terminals, and is divided into two categories: application-level information and terminal hardware-level information.

[0144] The mobile application installation package name is a unique package identifier assigned to an application by the operating system, and different applications have independent package names.

[0145] A mobile application signing certificate is an identity credential configured by the developer during the application compilation and packaging stage. Tampering with the application installation package will also change the certificate content.

[0146] The device brand is the identifier of the terminal hardware manufacturer, and different manufacturers' devices have a fixed brand field.

[0147] The device model is a terminal hardware model identifier assigned by the manufacturer to distinguish different hardware specifications of devices under the same brand.

[0148] The sensor list information is a complete set of parameters for various sensors built into the terminal, including sensor name, manufacturer, and accuracy parameters. Sensor configurations may vary between different devices.

[0149] An Android identifier is a persistent device identification field assigned to an application by the Android operating system to distinguish different application instances on the same device.

[0150] In practice, the security service module's internal device fingerprint unit first reads various device information sequentially. When reading application-related information, it retrieves the installation package name and original signature certificate data from the operating system's application management interface. When reading hardware-related information, it calls the system hardware interface to read the device brand and model, and iterates through the system sensor management interface to collect all sensor parameters. When reading the system identifier, it calls the system interface to obtain the Android identifier; if the interface does not have permission to return data, it skips that field without interrupting the collection process. All collected raw device information is temporarily stored in isolated memory within a virtualized, high-security operating environment, and is not written to the terminal's ordinary disk. The entire collection process is monitored by the hardening execution module to intercept memory tampering and parameter hijacking.

[0151] Next, the device fingerprint unit arranges all collected device information fields in a fixed preset order, adding fixed delimiters between fields to distinguish boundaries and prevent confusion between different field contents. After all fields are sequentially concatenated, a complete and continuous data string is generated. The concatenation process does not modify the original content of any field, only adjusts the data layout. The complete data string after concatenation is stored in isolated memory, and the temporary data of the original split fields is automatically cleared, retaining only the concatenated data string for hash calculation.

[0152] Finally, the device fingerprint unit invokes the built-in SHA256 hash algorithm engine of the white-box encryption module, sending the concatenated data string as input to the hash operation process. The entire operation is performed in a virtualized, isolated environment, and intermediate data generated during the operation is automatically destroyed after completion. The hash operation outputs a fixed-length value, which is directly defined as the device fingerprint corresponding to the current application on the current terminal. This value is temporarily stored in isolated memory for use in subsequent initialization request message encapsulation. The original concatenated data string is immediately cleared from memory after the hash operation, ensuring that no plaintext device information is left on the terminal.

[0153] This application also provides a method for downloading service keys based on a security enhancement device, applicable to mobile terminals equipped with a security enhancement device, such as... Figure 4 As shown, the method includes: S401-S408 S401: In response to a business key download request triggered by a mobile application, read the stored advanced ciphertext data from the hardware security zone.

[0154] For example, the advanced encrypted data includes: instance data ciphertext, advanced white-box business root key, and access salt.

[0155] A business key download request is an instruction generated when a mobile application initiates a highly sensitive business operation. Common scenarios include applying for a virtual bank card or initiating a mobile payment transaction. The instruction triggers a security enhancement device to retrieve the business-specific key.

[0156] Advanced ciphertext data is a set of ciphertexts generated by unified encryption using hardware storage keys during the initialization process, and is persistently stored within the hardware secure area.

[0157] The instance data ciphertext is generated during the initialization phase by encrypting all instance identity information with the access key.

[0158] The advanced white-box business root key is a business root key that has undergone white-box transformation and secondary encryption processing, and is used to encrypt all business keys.

[0159] The access salt is a random factor randomly generated during the initialization phase, which, together with the access password, iteratively calculates the access key.

[0160] In practice, the mobile application sends a business key download request to the interface management module, which then calls the operating system interface unit to initiate a hardware secure area read command. The hardware secure area verifies the calling program's identity; upon successful verification, it decrypts the internally stored high-level encrypted data and outputs three types of data: instance data encrypted data, the high-level white-box business root key, and the access salt. All read data is sent to isolated memory in a virtualized high-security operating environment and is not written to a regular disk. The hardening execution module simultaneously performs runtime environment security checks, identifying risks such as debugging and memory injection. If any anomalies are detected, the subsequent process is terminated, and all read data is cleared.

[0161] S402: Obtain the access password for the security enhancement device provided by the user.

[0162] For example, the access password for the security enhancement device is a large random number randomly generated during the initialization phase. When the user operates the business process, they re-enter the corresponding password as an input parameter for deriving the access key.

[0163] In practice, the interface management module sends a password retrieval command to the mobile application. The mobile application collects the user-input access password and sends it back to the security enhancement device. Password data is only temporarily stored in virtualized isolated memory and is never written to local storage. The hardening execution module monitors the password transmission process and intercepts memory hijacking attempts to steal password data. After password data collection is complete, it waits to be combined with the access salt to calculate the access key.

[0164] S403: Recalculate the access key for the security enhancement device based on the access password and access salt.

[0165] In practice, the security service module's internal security computing unit retrieves the access salt and the user-provided access password from isolated memory, and calls the white-box encryption module's built-in hash algorithm to perform multiple rounds of iterative calculations. The number of iterations is consistent with the initialization process. The entire calculation is performed in a virtualized, high-security operating environment. After the calculation is completed, the access key is output. The original access password is immediately cleared from memory after the calculation, and only the access key is retained for subsequent decryption operations.

[0166] S404: Decrypt the instance data ciphertext using the recalculated access key of the security enhancement device and recover the instance data.

[0167] For example, the instance data includes at least the device fingerprint and white-box protection key that were bound to the device during initialization.

[0168] In practice, the secure computing unit sends the access key and encrypted instance data to the white-box encryption module, which then calls a symmetric decryption algorithm to complete the decryption operation. The entire decryption process is protected by the hardened execution module stack detection and flow control, preventing dynamic reading of intermediate decryption data. Upon successful decryption, the complete plaintext instance data is output, and the internally bound device fingerprint and white-box protection key are extracted and stored in isolated memory. If decryption fails, the device clears all temporary data, directly terminating the business key download process and refraining from further steps.

[0169] S405: Obtain the current device fingerprint of the mobile terminal.

[0170] For example, the current device fingerprint is a new hash identifier generated by concatenating and hashing local hardware and software information in real time during the execution of the business key download process, representing the identity of the physical terminal where the current program is actually running.

[0171] In practice, the fingerprint acquisition logic within the security service module's device fingerprint unit repeatedly initializes the fingerprint collection logic, sequentially reading the application package name, application signature, device brand and model, sensor parameters, and Android identifier. These are then concatenated in a fixed order and used to generate the current device fingerprint via SHA256 hashing. The entire acquisition and processing is performed in a virtualized, isolated environment. Simultaneously, the hardening execution module conducts security checks on the runtime environment, identifying risks such as emulators, root access, and debugging. If any risk is detected, the process is terminated immediately. The generated current device fingerprint is temporarily stored in isolated memory, awaiting comparison and verification.

[0172] S406: Compare the current device fingerprint with the device fingerprint of the device bound during initialization.

[0173] In practice, the device fingerprint unit reads the bound device fingerprint and the current device fingerprint from the isolated memory, comparing the two hash values ​​byte by byte. If the two values ​​match perfectly, an issuance command is sent to the interface management module to continue the background key request process. If there is any difference between the two values, the device is deemed to have been illegally migrated. The device clears all temporary keys and fingerprint data, directly terminates the business key download process, and does not send any requests to the background.

[0174] S407: If the comparison results indicate that they match, request the service key from the mobile application backend through the secure transmission channel and receive the service key wrapped in the service root key.

[0175] In practice, the secure link unit within the security service module retrieves the white-box protection key and negotiates a session key with the backend to establish a secure transmission channel. The interface management module encapsulates the business key request message and sends it to the mobile application backend through an encrypted channel. The backend calls the hardware security module to generate the business key, uses the business root key to complete the encrypted package, and then sends back the ciphertext. The secure link unit receives and decrypts the returned message, extracts the business key wrapped by the business root key, and stores it in isolated memory. The entire transmission process is monitored by the hardening execution module to identify risks of message tampering and link hijacking.

[0176] S408: After the business key wrapped in the business root key is securely protected, it is stored in the hardware security area.

[0177] In practice, the internal secure storage unit of the security service module sends the business key, wrapped in the business root key, to the white-box encryption module for white-boxing processing, obtaining the white-boxed business key. The white-boxed secure storage key is then retrieved to perform secondary encryption on the white-boxed business key, generating an advanced white-boxed business key. The interface management module calls the operating system interface unit to send the advanced white-boxed business key to the hardware security area. The hardware security area uses the local hardware storage key to encrypt the key again, generating advanced ciphertext persistent storage. All temporary key data generated during the computation process is automatically deleted after the computation is completed. Once the entire storage operation is finished, the business key download process is complete.

[0178] It should be noted that business keys are used for highly sensitive business operations such as payment transactions and virtual card authentication. Key leakage will directly pose a risk to fund and account security. Available business keys are not permanently cached locally on the terminal; users need to retrieve the business key from the backend when initiating corresponding business operations.

[0179] If the key is directly issued from the backend and stored locally, it lacks multiple layers of security checks, including device identity verification, local authentication verification, and environmental security verification. Attackers can copy the data stored in the hardware's secure area and migrate it to other terminals to illegally download the business key.

[0180] In this embodiment, the entire process sequentially completes encrypted text reading, local access key reproduction, instance data decryption, secondary verification of device fingerprint, background key retrieval, and multi-layer encrypted storage of business keys. This process reuses the device fingerprint, access salt, and multi-layered encryption key system retained during the initialization phase to complete local legitimacy verification. Only the original terminal that created the secure instance can successfully obtain the business key. All key transmission and storage are protected by both white-box transformation and hardware security zones. Simultaneously, continuous runtime environment risk detection is implemented to block attacks such as emulator attacks, device porting attacks, program tampering attacks, and dynamic debugging attacks, ensuring that business keys can only be legally used on the bound device, thus constructing a secure closed loop for the entire business key distribution chain.

[0181] As an example, storing a business key wrapped in a business root key in a hardware secure area after security protection processing can include: white-boxing the business key wrapped in a business root key to obtain a white-boxed business key; using the white-boxed secure storage key to perform secondary encryption on the white-boxed business key to generate an advanced white-boxed business key; and storing the advanced white-boxed business key in the hardware secure area.

[0182] As an example, before reading the stored high-level encrypted data from the hardware secure area, a process is also included to perform security checks on the current operating environment, including the following: root detection, jailbreak detection, emulator detection, code integrity detection, debug mode detection, memory detection, and signature verification.

[0183] In this embodiment, the secure transmission channel is established based on the white-box protection key in the instance data, and the mobile application backend and the security enhancement device backend share the same hardware security module.

[0184] The mobile application backend is a backend service that carries business logic such as payment and virtual card application, and is responsible for generating business keys according to business needs.

[0185] The security enhancement device backend is a dedicated backend service for managing terminal security instances, issuing protection keys and business root keys, and collecting terminal security detection data.

[0186] The hardware security module is a dedicated encryption hardware device with a built-in encryption algorithm engine and a security key storage area. All root key and business key generation, encryption, and storage operations are completed inside the hardware, and the keys will not be output in plaintext form outside the hardware.

[0187] It should be noted that when the terminal transmits data such as instance initialization messages and business key distribution messages between the terminal and the backend, the messages carry various encrypted key ciphertexts and device identity information. Ordinary network links do not have data encryption protection, and man-in-the-middle attacks can capture the complete transmission messages and parse them to obtain the underlying key-related data.

[0188] A dedicated secure transmission channel is built by relying on the white-box protection key stored inside the instance data. The channel key is bound to a single secure instance of a device, and different device instances cannot reuse the transmission encryption key to prevent cross-device forgery of interactive messages.

[0189] The mobile application backend handles business logic processing, while the security enhancement device backend manages instance and key lifecycles. Both types of backends require key generation, key storage, and key encryption operations. Deploying multiple separate hardware security modules leads to inconsistent key management standards, increased hardware costs, and longer key exchange chains. By sharing the same hardware security module, all root keys and business keys are uniformly generated and managed by this module. This standardizes the key generation process, shortens the key transfer chain, and reduces the risk of key leakage on the backend side. These two technical features work together to achieve end-to-end instance binding encryption and unified hardware control of backend keys, forming a complete end-to-end secure key transmission and generation system.

[0190] This application also provides a security enhancement method, applied to the background of a security enhancement device, such as... Figure 5 As shown, the security enhancement method includes: S501-S506 S501: Receive an initialization request carrying the device fingerprint sent by the security enhancement device.

[0191] In practice, the backend service continuously monitors the encrypted transmission link port, receiving initialization request messages uploaded by the terminal through the secure transmission channel. The backend secure connection unit decrypts the message based on the channel negotiation key and extracts the device fingerprint data stored within the message. The backend has built-in environment verification logic to verify the legality of the message transmission channel and the integrity of the message. If the verification fails, the message is discarded directly, and the subsequent key generation process is not executed. After successful verification, the device fingerprint and the original request message are sent to the backend business processing unit, awaiting the key generation stage.

[0192] S502: Based on the initialization request, generate the security enhancement device instance identifier, protection key, and business root key through the hardware security module.

[0193] In practice, after the backend business processing unit verifies the validity of the initialization request, it issues a batch generation command to the hardware security module. The hardware security module has a built-in true random number generator that generates random factors based on underlying hardware noise, sequentially generating a unique instance identifier, a protection key, and a business root key. All three types of data are stored in the secure storage area within the hardware security module, with only the ciphertext data required for encryption processing being output to the backend service process. After the hardware completes the generation operation, it sends a generation completion signal and intermediate data of the encrypted key back to the backend. The backend temporarily stores the data, awaiting binding and encryption packaging operations.

[0194] S503: Bind the security enhancement device instance identifier to the device fingerprint.

[0195] In practice, the backend business processing unit reads the instance identifier output by the hardware security module and the device fingerprint carried in the initialization request message. It then writes both sets of data into the backend persistent database, generating a one-to-one associated storage record. The backend synchronously verifies historical binding records in the database. If the same device fingerprint is already bound to another instance identifier, it is determined that there is a risk of duplicate initialization, the device is marked as suspicious, and subsequent key issuance permissions are restricted. After the binding record is generated, the backend enters the key package encryption process.

[0196] S504: Wrap the protection key and the service root key with the white-box initial key to obtain the protection key wrapped with the white-box initial key and the service root key wrapped with the white-box initial key.

[0197] In practice, the backend business processing unit calls the hardware security module, sending the pre-set white-box initial key, the hardware-generated protection key, and the business root key to the hardware encryption processing unit. Internally, the hardware calls a symmetric cryptographic algorithm to first encrypt the protection key using the white-box initial key, generating a packaged ciphertext of the protection key; then, it independently encrypts the business root key using the same white-box initial key, generating a packaged ciphertext of the business root key. The hardware only outputs these two types of encrypted ciphertext to the backend service; the original protection key and business root key plaintext remain internally within the hardware security module and are not output externally. The two sets of ciphertext are temporarily stored in the backend memory, awaiting distribution to the terminal along with the instance identifier.

[0198] S505: Send the instance identifier, the protection key wrapped in the white-box initial key, and the service root key wrapped in the white-box initial key to the security enhancement device.

[0199] In practice, the backend business processing unit encapsulates the instance identifier, the wrapped protection key ciphertext, and the wrapped business root key ciphertext into a unified response message according to a fixed format. The backend secure connection unit reuses the secure transmission channel established when the terminal initiates the request and pushes the complete response message to the terminal. During message transmission, message integrity is continuously verified. If message loss or tampering occurs, it is automatically retransmitted once. If retransmission fails, the instance initialization process is marked as interrupted. After the terminal fully receives the message, the backend retains a log of this distribution operation, which includes the instance identifier, device fingerprint, and distribution time, for subsequent security auditing.

[0200] S506: Perform lifecycle status management on security enhancement device instances.

[0201] In practice, the backend continuously maintains the instance status database, with each binding record having an independent status field. After the terminal completes initialization and reports the completion signal, the backend marks the corresponding instance status as running normally. The backend periodically receives runtime environment security detection data uploaded by the terminal. When anomalies such as rooting, jailbreaking, emulator access, or code tampering are detected, the instance status is changed to locked, and all subsequent business key application requests for that instance are rejected. The backend supports receiving key rotation instructions initiated by the terminal, triggering the hardware security module to regenerate the protection key and business root key, and updating the instance's associated key data. When the terminal initiates an instance cleanup operation, the backend marks the instance status as deregistered, synchronously archives the binding records, and releases the corresponding key storage resources within the hardware security module. The backend provides a unified query interface, allowing operations and maintenance personnel to retrieve the full-process status change logs of any instance, enabling security risk tracing.

[0202] It should be noted that the terminal itself does not have the capability to generate high-security keys locally. The quality of its random number generation and the conditions for key isolation and storage cannot meet the high-security standards of financial payment and other similar services. All underlying basic keys must be generated uniformly by the backend. Each terminal's security instance needs to be bound to a unique device identity to prevent key reuse across devices and subsequent cloning attacks.

[0203] The backend process executes sequentially: receiving terminal requests, hardware key generation, identity binding, key encryption and encapsulation, data distribution, and full-lifecycle instance management, forming a complete closed-loop processing logic. The hardware security module independently completes key generation and encryption operations; the key remains within the encryption hardware throughout the process and will not appear in plaintext during the backend service process. Before key distribution, a white-box initial key is used to encrypt the package, preventing key theft through packet capture during transmission. Instance identifiers are permanently bound to device fingerprints, allowing the backend to identify abnormal devices and manage key distribution permissions based on this binding relationship. At the end of the process, instance lifecycle management is added to continuously track instance operation status and support management operations such as abnormal freezing, key rotation, and instance destruction, enabling full-process monitoring and handling of terminal security instances from creation to deregistration. The entire process corresponds one-to-one with the terminal initialization process, with the client and backend collaborating to complete a one-machine-one-instance security binding system, addressing the shortcomings of client-side key generation and global management capabilities.

[0204] In this embodiment, the security enhancement device also issues a security policy to itself; based on the security policy, it receives security detection and evaluation data reported by the security enhancement device; and based on the security detection and evaluation data, it identifies abnormal mobile devices.

[0205] Security policies are a set of standardized rules generated by backend configuration, which specify terminal security detection items, risk judgment thresholds, anomaly reporting frequency, and risk handling actions.

[0206] The security policy is distributed by pushing the complete policy file to the terminal security enhancement device through a secure transmission channel in the background, and the terminal updates and executes the rules locally.

[0207] In practice, backend operations personnel configure security policies according to business compliance requirements. These policies include the types of detections to be performed, the judgment conditions for various risks, the terminal data reporting cycle, and the local handling logic after anomaly identification. The backend sends the complete policy data to the hardware security module for encryption and pushes it to the security enhancement device through a secure transmission channel between the terminal and the backend. Upon receiving the encrypted policy data, the security enhancement device calls the white-box encryption module to decrypt it and synchronously updates the policy rules to the hardening execution module. When the hardening execution module subsequently performs runtime environment checks, it strictly follows the latest received security policy for scanning and judgment. After the terminal completes the policy update, it sends a receipt confirmation message back to the backend. The backend records the policy distribution time and the corresponding instance identifier, completing the distribution process.

[0208] It should be noted that different industries and business scenarios have different security requirements for mobile terminal operating environments, and a uniform, fixed testing standard cannot adapt to the differentiated business management needs. A standardized security policy uniformly distributed from the backend can batch-constrain the testing rules of all terminal security enhancement devices, achieving unified global security standard management.

[0209] The environmental detection data generated during terminal operation is only stored locally. The backend cannot actively detect whether the terminal has risks such as jailbreaking, emulators, or code tampering. It continuously receives security detection and assessment data reported by the terminal and can fully grasp the real-time operating status of each device.

[0210] This application relies on comparative analysis of reported data and preset security policies. The backend can automatically distinguish between compliant devices and abnormal devices with security risks, and perform control actions such as instance locking and stopping key issuance for abnormal devices, blocking highly sensitive business operations initiated by risky devices from the cloud. The entire process forms a cloud-based closed-loop control mechanism for policy issuance, data collection, and risk identification, making up for the shortcomings of local terminal detection, which can only block single device operations and cannot achieve global risk aggregation and handling.

[0211] This application also provides a security enhancement system, such as... Figure 6 As shown, the security enhancement system 10 includes: a security enhancement device 100 and a security enhancement device backend 200; the security enhancement device 100 and the security enhancement device backend 200 communicate through a secure transmission channel; the security enhancement device backend 200 generates and stores a root key through a hardware security module; and the security enhancement device achieves end-side protection of the key through white-box processing and storage in a hardware security area.

[0212] In practice, the security enhancement device is deployed within the mobile application of each mobile terminal, while the backend of the security enhancement device is deployed in a dedicated high-security data center in the cloud. Before the two ends interact, the terminal side uses white-box protection to negotiate the session key and establishes a dedicated secure transmission channel. All initialization requests, key distribution messages, and terminal security detection reporting data are transmitted through this channel. The integrity of the messages is verified throughout the transmission process, and any tampered messages are discarded immediately.

[0213] All system top-level root keys are uniformly generated by the hardware security module called by the security enhancement device in the background. The hardware performs persistent key storage and only outputs the encrypted key ciphertext to the terminal. The root key plaintext is permanently stored inside the hardware security module.

[0214] After receiving various key ciphertexts from the backend, the terminal sends them to the white-box encryption module for white-box transformation. After the transformation, the key data is written to the hardware security area by calling the operating system interface. The hardware security area will generate a dedicated hardware storage key to encrypt the key data again, forming a multi-layered ciphertext persistent storage. Ordinary application processes on the terminal cannot read the original key data inside the hardware security area.

[0215] In this embodiment, the security enhancement system adopts a multi-level white-box key system, which includes, from high to low: a white-box initial key, pre-installed in the security enhancement device and its backend; a protection key and a business root key, generated by the security enhancement device backend during initialization via a hardware security module and then distributed after being wrapped by the white-box initial key; a business key, generated by the mobile application backend during business download and then distributed after being wrapped by the business root key; and an access key, dynamically generated by the security enhancement device based on the access password and access salt. It should be noted that if the system uses only a single key to complete all operations such as transmission, business encryption, and local authentication, the key is used for too many purposes. Once the key is leaked, the transmission link, business data, and local instance authentication will all fail simultaneously.

[0216] The key hierarchy is divided into multiple layers based on key management levels and usage scenarios. Upper-layer keys uniformly encrypt and wrap lower-layer keys. Each layer of keys undergoes white-box transformation after being distributed or generated locally, achieving hierarchical key isolation. The top-level key in the cloud exists only within the hardware security module and is not distributed to the terminal. The terminal only holds the encrypted lower-layer key ciphertext. Different key levels correspond to independent scenarios for transmission channel construction, business data encryption, and local instance decryption and authentication, with permissions isolated from each other. The breach of any one layer of keys will not affect other layers, significantly reducing overall security risk. The entire key system is derived, encrypted, and white-box transformed level by level from top to bottom, forming a complete closed-loop key protection chain.

[0217] In this embodiment, the protection key is used to establish a secure transmission channel, the business root key is used to wrap the business key, and the keys at each level are derived, wrapped, and white-boxed at each level. The root key is not exposed to the mobile terminal at any time.

[0218] It's important to note that a single-layer key lacks layered encryption protection; an attacker can obtain the entire set of cryptographic resources simply by cracking the single key. In contrast, upper-layer keys encrypt lower-layer keys, forming multiple layers of encryption. Each layer undergoes a white-box transformation to scramble the original key data structure, significantly increasing the difficulty of reverse engineering. The top-level root key is stored entirely in a cloud-based hardware security module and is never transmitted to the terminal in plaintext or ciphertext form, thus eliminating the possibility of root key leakage at the terminal from the source.

[0219] Hierarchical derivation refers to the generation or encryption of lower-level keys based on upper-level keys, forming a top-down key generation dependency relationship.

[0220] Hierarchical wrapping means that each lower-level key uses the corresponding upper-level key to perform encryption operations, and is protected by the upper-level key.

[0221] Stepwise white-box transformation refers to the process where all key ciphertexts sent to the terminal are sequentially transformed into white-box formats on the terminal itself.

[0222] The fact that the root key is not exposed to the mobile terminal throughout the process means that the original plaintext of the white-box initial key, protection key, and business root key is only stored in the cloud hardware security module. The terminal only holds the ciphertext form after multi-layer encryption transformation and does not have any root key plaintext.

[0223] In practice, the entire key system is derived and packaged from top to bottom. The white-box initial key serves as the top-level base key, wrapping the protection key and the business root key; the business root key wraps the business key; and the access key is independently derived locally on the terminal for local authentication. All key ciphertexts sent from the cloud to the terminal are sent to the white-box encryption module for white-box transformation upon arrival. The transformed keys are then encrypted a second time using a secure storage key and stored in the hardware security area. The original plaintexts of the white-box initial key, protection key, and business root key are always stored within the cloud hardware security module and are never sent to the terminal. The terminal can only use the multi-layered encrypted key ciphertext to perform cryptographic operations and cannot obtain any top-level root key plaintext.

[0224] Figure 7 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0225] like Figure 7 As shown, the electronic device may include a processor 701 and a memory 702 storing computer program instructions.

[0226] Specifically, the processor 701 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0227] Memory 702 may include mass storage for data or instructions. For example, and not limitingly, memory 702 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 702 may include removable or non-removable (or fixed) media, or memory 702 may be non-volatile solid-state memory. Memory 702 may be internal or external to the integrated gateway disaster recovery device.

[0228] In one instance, memory 702 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0229] Memory 702 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to this application.

[0230] The processor 701 reads and executes computer program instructions stored in the memory 702 to achieve... Figure 2 The methods / steps in the illustrated embodiments, and achieve... Figure 2 The technical effects achieved by executing the methods / steps shown in the examples are not elaborated here for the sake of brevity.

[0231] In one example, the electronic device may also include a communication interface 703 and a bus 710. For example, Figure 7As shown, the processor 701, memory 702, and communication interface 703 are connected through bus 710 and complete communication with each other.

[0232] The communication interface 703 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0233] Bus 710 includes hardware, software, or both, that couples components of the receiving terminal together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 710 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0234] Furthermore, in conjunction with the security enhancement methods described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the security enhancement methods described in the above embodiments.

[0235] Furthermore, in conjunction with the security enhancement methods described in the above embodiments, this application embodiment can provide a computer program product for implementation. This computer program product includes computer instructions; when executed by a processor, these computer instructions implement any of the security enhancement methods described in the above embodiments.

[0236] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0237] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0238] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0239] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0240] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A safety enhancement device, characterized in that, Embedded within mobile applications, including: The white-box encryption module has a built-in international and national cryptographic algorithm engine that has been white-boxed, which is used to provide a white-boxed cryptographic algorithm engine to achieve white-box storage of keys and cryptographic operations. A security service module, connected to the white-box encryption module, is used to provide security function services to the mobile application based on the white-box encryption module; The hardening execution module is used to provide runtime security protection for the security service module and the white-box encryption module; The interface management module is connected to the white-box encryption module, the security service module, and the hardening execution module, respectively, and is used to control the access permissions of the mobile application to the security enhancement device and manage the lifecycle of the security enhancement device.

2. The safety enhancement device according to claim 1, characterized in that, The international algorithm engine includes at least the RSA asymmetric algorithm and the AES symmetric algorithm, and the national cryptographic algorithm engine includes at least the SM2 asymmetric algorithm and the SM4 symmetric algorithm.

3. The safety enhancement device according to claim 1, characterized in that, The security service module includes: The instance personalization unit is used to generate a unique security enhancement device instance identifier for each mobile device and to manage the lifecycle of the instance; A device fingerprint unit is used to collect device information and generate a device fingerprint based on the device information; The secure computing unit provides cryptographic computation functions based on white-box algorithms and has a built-in true random number generator. Secure storage unit, used to provide secure storage functionality based on white-box algorithms; The secure link unit is used to provide a protocol link for secure transmission channels based on white-box algorithms.

4. The safety enhancement device according to claim 1, characterized in that, The hardening execution module includes: A local code protection unit is used to verify code integrity. Code obfuscation and hardening unit, used to introduce obfuscation algorithms into binary code at compile time; The safety detection and assessment unit is used to detect and assess the risks of the current operating environment; The virtualized high-security runtime environment unit is used to isolate and execute critical code, and provides string encryption, runtime flow control, runtime stack inspection, and virtual machine integrity self-detection.

5. The safety enhancement device according to claim 1, characterized in that, The interface management module includes: Access control unit, used to control mobile applications' access permissions to security enhancement device instances; The lifecycle management unit is used to manage instance initialization, normal operation, cleanup, and key replacement; Operating system interface unit, used to interface with the hardware secure storage mechanism of the operating system; The Application Programming Interface (API) unit provides mobile applications with calling interfaces for initialization, encryption, decryption, signing, and instance cleanup.

6. A security enhancement method, characterized in that, Applied to mobile terminals equipped with security enhancement devices, including: In response to the trigger operation of the security enhancement device initialization, the device fingerprint of the mobile terminal is obtained; A secure transmission channel is established between the security enhancement device backend and the pre-set white-box initial key, and an initialization request carrying the device fingerprint is sent to the security enhancement device backend through the secure transmission channel. Receive the initial key data sent by the security enhancement device's backend; The initial key data is subjected to security protection processing to obtain the security-protected key data; The security-protected key data is stored in a preset hardware security area, and the device fingerprint is bound to the security-protected key data to complete the initialization of the local security instance.

7. The method according to claim 6, characterized in that, The initial key data includes at least one of the following: a security enhancement device instance identifier, a protection key wrapped in a white-box initial key, and a service root key wrapped in a white-box initial key; The step of performing security protection processing on the initial key data to obtain security-protected key data includes: The protection key wrapped by the white-box initial key is white-boxed to obtain the white-box protection key; The service root key, which is wrapped by the white-box initial key, is then white-boxed to obtain the white-boxed service root key. The white-boxed service root key is encrypted a second time using the white-boxed secure storage key to generate an advanced white-boxed service root key, which serves as the key data after security protection processing.

8. The method according to claim 7, characterized in that, Also includes: In response to the triggering operation of the security enhancement device initialization, an access key for the security enhancement device is generated; The instance data is encrypted using the access key of the security enhancement device to generate ciphertext of the instance data, which includes at least one of the following: the instance identifier of the security enhancement device, the mobile application user identifier, the instance status, the device fingerprint, and the white-box protection key; The step of storing the security-protected key data in a preset hardware security area includes: The instance data ciphertext, the advanced white-box service root key, and the access salt used to generate the access key for the security enhancement device are stored in a preset hardware security area.

9. The method according to claim 6, characterized in that, Before obtaining the device fingerprint of the mobile terminal, the method further includes: Perform security checks on the current operating environment, including at least one of the following: root detection, jailbreak detection, emulator detection, code integrity detection, debug mode detection, memory detection, and signature verification.

10. The method according to claim 6, characterized in that, The step of obtaining the device fingerprint of the mobile terminal includes: Obtain device information of the mobile terminal, the device information including at least one of the following: mobile application installation package name, mobile application signing certificate, device brand, device model, sensor list information, and obtainable Android identifier; The device information is concatenated to obtain a hash value, which serves as the device fingerprint.

11. The method according to claim 7, characterized in that, The trigger operation in response to the initialization of the security enhancement device, generating an access key for the security enhancement device, includes: In response to the trigger operation of the security enhancement device initialization, a random number is generated as the security enhancement device access password, and another random number is generated as the access salt; The access key for the security enhancement device is obtained by performing multiple iterative hash calculations on the access password and the access salt.

12. The method according to claim 8, characterized in that, The step of storing the instance data ciphertext, the advanced white-box service root key, and the access salt used to generate the security enhancement device access key into a preset hardware security area includes: Based on the aforementioned hardware security zone, a hardware storage key is generated; The instance data ciphertext, the advanced white-box service root key, and the access salt are encrypted using the hardware storage key to form advanced ciphertext data; The advanced encrypted data is stored in a preset hardware security area.

13. A method for downloading service keys based on a security enhancement device, characterized in that, Applied to mobile terminals equipped with security enhancement devices, including: In response to a business key download request triggered by a mobile application, stored advanced ciphertext data is read from the hardware security zone. The advanced ciphertext data includes: the instance data ciphertext, the advanced white-box business root key, and the access salt. Obtain the access password for the security enhancement device provided by the user; The access key for the security enhancement device is recalculated based on the access password and the access salt. The instance data is decrypted using the access key of the recalculated security enhancement device to recover the instance data; the instance data contains at least the device fingerprint and white-box protection key bound to the device during initialization. Obtain the current device fingerprint of the mobile terminal; Compare the current device fingerprint with the device fingerprint of the device bound during initialization; If the comparison results indicate that they match, the service key is requested from the mobile application backend through a secure transmission channel, and the service key wrapped in the service root key is received. The business key, which is wrapped in the business root key, is stored in the hardware security area after being subjected to security protection processing.

14. The method according to claim 13, characterized in that, The step of storing the business key, which is wrapped in the business root key, in the hardware security area after security protection processing includes: The service key wrapped by the service root key is white-boxed to obtain the white-box service key; The white-box service key is encrypted a second time using the white-box security storage key to generate an advanced white-box service key; The advanced white-box business key is stored in the hardware security area.

15. The method according to claim 13, characterized in that, Before reading the stored high-level encrypted data from the hardware-secure area, the following steps are also included: Perform security checks on the current operating environment, including one of the following: root detection, jailbreak detection, emulator detection, code integrity detection, debug mode detection, memory detection, and signature verification.

16. The method according to claim 14, characterized in that, The secure transmission channel is established based on the white-box protection key in the instance data, and the mobile application backend and the security enhancement device backend share the same hardware security module.

17. A security enhancement method, characterized in that, Applications in the backend of security enhancement devices include: Receive an initialization request carrying the device fingerprint sent by the security enhancement device; Based on the initialization request, a security enhancement device instance identifier, a protection key, and a service root key are generated through the hardware security module. Bind the security enhancement device instance identifier to the device fingerprint; The protection key and the service root key are wrapped with the white-box initial key respectively to obtain the protection key wrapped with the white-box initial key and the service root key wrapped with the white-box initial key. The instance identifier, the protection key wrapped in the white-box initial key, and the service root key wrapped in the white-box initial key are sent to the security enhancement device; Lifecycle status management is performed on the security enhancement device instance.

18. The method according to claim 17, characterized in that, Also includes: A security strategy is issued to the security enhancement device; Based on the security strategy, receive security detection and evaluation data reported by the security enhancement device; Based on the security detection and assessment data, abnormal mobile devices are identified.

19. A security enhancement system, characterized in that, include: The security enhancement device according to any one of claims 1 to 5 and the security enhancement device background according to any one of claims 17 to 18; The security enhancement device communicates with its backend via a secure transmission channel. The backend generates and stores the root key through a hardware security module. The security enhancement device achieves end-side protection of the key through white-box processing and storage in a hardware security area.

20. The security enhancement system according to claim 19, characterized in that, The security enhancement system employs a multi-level white-box key system, which includes, from highest to lowest level: The white-box initial key is pre-installed in the security enhancement device and the background of the security enhancement device; The protection key and the business root key are generated by the security enhancement device backend through the hardware security module during initialization and then distributed after being wrapped by the white-box initial key. The business key is generated by the mobile application backend during business download and is distributed after being wrapped by the business root key; The access key is dynamically generated by the security enhancement device based on the access password and access salt. The protection key is used to establish a secure transmission channel, and the business root key is used to wrap the business key. The keys at each level are derived, wrapped, and white-boxed at each level, and the root key is not exposed to the mobile terminal at any time.

Images