Application key security protection method and system, electronic device and storage medium

Abstract

This disclosure provides a method, system, electronic device, and storage medium for application key security protection, relating to the field of mobile application security. During application operation, if encrypted key data is detected integrated into the application code, a decryption component is called via an interface, passing in the encrypted key data. The decryption component encapsulates the target business SDK dependency library, encryption key decryption logic, initialization code snippets, and a RASP detection mechanism. When the decryption component is called, it performs RASP detection in real time and, in a secure environment, uses the encryption key decryption logic to decrypt the encrypted key data in memory to obtain the plaintext key. Based on the target business SDK dependency library, the application calls the initialization code snippet to complete the initialization of the target business SDK before destroying the plaintext key in memory. This effectively prevents the leakage of sensitive key information in the application, reduces the risk of key credential leakage, and provides comprehensive, multi-layered security protection for application keys.

Description

Technical Field

[0001] This disclosure relates to the field of mobile application security technology, specifically to an application key security protection method, system, electronic device, and storage medium. Background Technology

[0002] In today's digital age, the widespread use of mobile applications makes their security a critical issue. Mobile applications contain a large number of sensitive credentials, such as API (Application Programming Interface) tokens, encryption keys, and third-party service credentials. If this information is leaked, it can cause serious losses to businesses and users.

[0003] Currently, in mobile application development practices, it is common to hardcode sensitive credentials in plaintext within the code. This practice makes these hard-coded credentials highly vulnerable to attackers during static analysis or binary auditing, potentially leading to malicious calls to backend services, data breaches, user privacy violations, and even significant financial losses and brand reputation crises.

[0004] Furthermore, as businesses grow and diversify, large enterprises often adopt outsourcing or multi-team collaborative development models. In this model, the management and distribution of core credentials become exceptionally difficult. Developers may obtain plaintext keys at runtime by directly accessing the source code or using debugging tools, which significantly increases the risk of internal information leakage.

[0005] Most existing key protection mechanisms focus on static-level protection and are ineffective against runtime dynamic analysis and debugging attacks. Attackers can use dynamic debugging tools to attach to the application process, set breakpoints after the decryption function is executed, and directly read the decrypted plaintext key from registers or memory addresses.

[0006] Therefore, building an application key security protection system that covers the source code level, the build stage, and even the runtime is a key aspect of ensuring the security of mobile applications. Summary of the Invention

[0007] This disclosure aims to at least partially address one of the technical problems in the related art.

[0008] To achieve the above objectives, the first aspect of this disclosure proposes an application key security protection method, which includes: during application operation, monitoring whether encrypted key data is integrated in the application code; in response to the detection of encrypted key data, calling a decryption component through an interface, passing in the encrypted key data, wherein the decryption component at least encapsulates the target business SDK (Software Development Kit) dependency library, encrypted key decryption logic, and initialization code snippet, and the decryption component also has a built-in RASP (Runtime Application Self-Protection) detection mechanism, wherein the decryption component performs RASP detection in real time when called, and decrypts the encrypted key data in memory in a secure environment using the encrypted key decryption logic to obtain the plaintext key; and based on the target business SDK dependency library, using the plaintext key to call the initialization code snippet to complete the initialization of the target business SDK, and then destroying the plaintext key in memory.

[0009] To achieve the above objectives, a second aspect of this disclosure provides an application key security protection system, comprising the following modules:

[0010] The monitoring module is configured to monitor whether encrypted key data is integrated into the application code during application operation.

[0011] This calling module is configured to respond to the detection of encryption key data by calling the decryption component through a standard interface, passing in the encryption key data. This calling module does not hold, process, or store any key information; it serves only as the entry point for the call.

[0012] The decryption component is an independently encapsulated black-box component (AAR / Framework) that encapsulates at least the target business SDK dependency library, encryption key decryption logic, initialization code snippets, and a RASP detection mechanism. At runtime, this decryption component automatically performs RASP detection based on the RASP detection mechanism. Only after confirming the environment is secure does it execute the encryption key decryption logic in memory to obtain the plaintext key. Based on the target business SDK dependency library, it applies the plaintext key to call the initialization code snippet to complete the SDK initialization, and after initialization is complete, it clears the plaintext key from memory.

[0013] Optionally, the decryption component also encapsulates a memory-safe destruction mechanism, thereby clearing the plaintext key from memory based on this memory-safe destruction mechanism.

[0014] Furthermore, the decryption component is also configured to clear intermediate variables in memory after initialization is complete.

[0015] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the application key security protection method as described in the first aspect.

[0016] A fourth aspect of this disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the application key security protection method as described in the first aspect.

[0017] The fifth aspect of this disclosure provides a computer program product including a computer program that, when executed, implements the application key security protection method as described in the first aspect.

[0018] This disclosure effectively prevents the leakage of sensitive key information in mobile applications and reduces the risk of key credential leakage. Specifically, it encrypts the plaintext key of the mobile application to obtain encrypted key data, and integrates this encrypted key data into the application code of the mobile application, forming "key obfuscation" at the static code level. During application runtime, the decryption component decrypts the encrypted key data in memory to obtain the plaintext key, and destroys the plaintext key in memory after the application plaintext key completes SDK initialization, forming "key isolation" in the runtime environment. Through the two-layer protection mechanism of "key obfuscation" at the static code level and "key isolation" in the runtime environment, comprehensive and multi-layered security protection is provided for application keys.

[0019] Additional aspects and advantages of this disclosure will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the technical solutions of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0021] Figure 1 This is a flowchart illustrating an application key security protection method according to an embodiment of the present disclosure;

[0022] Figure 2 This is a schematic diagram of the overall architecture of an application key security protection method according to an embodiment of the present disclosure;

[0023] Figure 3 This is a flowchart illustrating a first-layer protection mechanism according to an embodiment of the present disclosure;

[0024] Figure 4This is a schematic diagram illustrating the workflow of a key management and distribution platform in a second-layer protection mechanism according to an embodiment of the present disclosure;

[0025] Figure 5 This is a schematic diagram illustrating the workflow of dynamically registered and initialized components in a second-layer protection mechanism according to an embodiment of the present disclosure;

[0026] Figure 6 This is a schematic diagram of the collaborative operation of two layers of protection according to an embodiment of the present disclosure;

[0027] Figure 7 This is a schematic diagram of the structure of an application key security protection system according to an embodiment of the present disclosure;

[0028] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0029] Embodiments of this disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0030] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0031] To address the problems of easy leakage of hard-coded keys, difficulties in management by multiple teams, and insufficient runtime protection in existing application key security protection, this disclosure provides a multi-layered, end-to-end key protection system covering the source code level, the build stage, and even runtime. This system is designed to enhance the security of mobile application keys, address the increasingly severe mobile security threats, reduce the leakage of sensitive key information, and provide a solid technical guarantee for the core data and business security of enterprise mobile applications.

[0032] The key protection system adopts a layered protection approach, including a two-layer protection mechanism. The first layer focuses on solving the problem of cracking hard-coded keys at the static level. The second layer, based on the first layer, further provides a runtime isolation mechanism to achieve defense in depth. By constructing two layers of protection mechanisms—"key obfuscation" at the static code level and "key isolation" in the runtime environment—the system significantly reduces the security risks caused by various key leakage scenarios, such as data leakage, property loss, and damage to brand reputation.

[0033] This disclosure applies to application development with keys, and can be mainly used in the process of mobile application development, especially in enterprise environments with multi-team collaborative development or outsourced development scenarios.

[0034] Figure 1 This is a flowchart illustrating an application key security protection method according to an embodiment of the present disclosure. Figure 1 As shown, the method includes the following steps:

[0035] Step S1: During application operation, monitor whether the application code integrates encryption key data.

[0036] Optionally, the encryption key data is a binary data block. For example, the encryption key data is generated offline using a key encryption tool that encrypts the application's original plaintext key using at least one or more of composite encryption algorithms and proprietary obfuscation algorithms to generate a binary byte array.

[0037] In one embodiment, the composite encryption algorithm is the AES-256-GCM algorithm. AES-256-GCM not only provides strong confidentiality protection due to its 256-bit key length, but its GCM (Galois / Counter Mode) also provides data integrity and authenticity verification, effectively resisting data tampering attacks. However, it should be noted that this disclosure does not limit the composite encryption algorithm to AES-256-GCM; it can be replaced with other authentication encryption algorithms of the same type. The specific composite encryption algorithm used can be determined based on information such as the operating environment.

[0038] In one embodiment, the private obfuscation algorithm can be a custom bitwise operation algorithm. Further, in one embodiment, the custom bitwise operation algorithm includes at least one or more of the following: a circular shift algorithm, an XOR obfuscation algorithm, etc. The custom bitwise operation algorithm can be a private, non-public bitwise operation algorithm.

[0039] In one embodiment, the original plaintext key of the application can be encrypted first using a composite encryption algorithm. Then, a proprietary obfuscation algorithm is overlaid to generate encrypted key data, significantly increasing the complexity and cost of reverse engineering. For example, the original plaintext key of the application can be encrypted using the AES-256-GCM algorithm, and then a custom bitwise operation algorithm is overlaid to obtain the encrypted key data. Thus, even if an attacker identifies that AES-256-GCM is used at the underlying level, they will need to expend considerable effort to crack this custom obfuscation logic.

[0040] As an implementation, this binary data block contains no readable strings or comments, appearing as a meaningless sequence of bytes in static analysis and unrecognizable as a key by automated tools. This layer of protection effectively defends against all attacks based on static analysis. Even if an attacker obtains the application's source code or binary file, they will only see a string of meaningless binary data and cannot directly obtain the plaintext key. The composite encryption algorithm increases the difficulty of analysis for automated cracking tools.

[0041] For example, key encryption tools output standardized binary byte arrays, such as byte[]ENCRYPTED_KEY={0x3A,0x7F,……} in Java / Kotlin, or let encryptedKey:[UInt8]=[0x3A,0x7F,……] in Swift, to facilitate developers' direct integration into their code.

[0042] Step S2: In response to the detection of encrypted key data, the decryption component is called through the interface, and the decryption key data is passed in. The decryption component at least encapsulates the target business SDK dependency library, the encrypted key decryption logic and the initialization code snippet. The decryption component also has a built-in RASP detection mechanism. When the decryption component is called, it performs RASP detection in real time based on the RASP detection mechanism, and uses the encrypted key decryption logic to decrypt the encrypted key data in memory in a secure environment to obtain the plaintext key. Based on the target business SDK dependency library, the plaintext key is used to call the initialization code snippet to complete the initialization of the target business SDK and then destroys the plaintext key in memory.

[0043] During the real-time execution of RASP detection based on the RASP detection mechanism, the decryption component will terminate if a security threat is detected; otherwise, it will continue to run.

[0044] When the mobile application starts, the target business code calls the public interface of the dynamically registered and initialized decryption component provided by the key management platform during the application initialization phase (such as Application.onCreate() or AppDelegate.application(_:didFinishLaunchingWithOptions:)). For example:

[0045] Java copy

[0046] / / Android Example

[0047] KeyShieldComponent.init(context, encryptedKeyData)

[0048] Swift copy

[0049] / / iOS Example

[0050] KeyShieldComponent.initialize(with: encryptedKeyData)

[0051] Here, encryptedKeyData is the encrypted key data generated by the key encryption tool. The encrypted key data is passed in as a binary byte array and does not contain any plaintext key.

[0052] The decryption component is a fully encapsulated black-box module. In one embodiment, it is encapsulated as an AndroidAAR module, and in another embodiment, as an iOS Framework module. Internally, the decryption component encapsulates at least one target business SDK dependency library, encryption key decryption logic (including reverse processing of composite encryption algorithms and a private obfuscation layer), initialization code snippets (using pseudo-parameter placeholders, i.e., pseudo-parameters replacing encryption key data), and a built-in runtime application self-protection (RASP) detection mechanism. Specifically, the target business SDK dependency library is included in the dependency coordinates of the business SDK module configured for protection on the key management platform; the encryption key decryption logic is the reverse execution logic of the encryption key encryption process; the initialization code uses pseudo-parameter placeholders to replace encryption key data; and the RASP detection mechanism includes at least one or more of anti-debugging detection, anti-Hooking detection, and code obfuscation detection.

[0053] In one embodiment, when the decryption component is invoked and runs, the RASP detection mechanism is started in real time and performs the following detections:

[0054] Anti-debugging detection includes logic to detect debugger attachments, such as checking for attachments by calling ptrace(PTRACE_TRACEME, ...) (Android) or isDebuggerAttached() (iOS) to see if the application is attached by GDB, Frida, or Xcode debuggers. Once a debugger is detected, countermeasures can be taken, such as interrupting execution, throwing fake errors, or directly crashing the application.

[0055] Anti-Hooking detection prevents attackers from tampering with decryption or initialization logic by checking whether the memory addresses of key functions (such as AES_decrypt and memcpy) have been tampered with, checking the integrity of memory code segments, or detecting code injected by hooking frameworks such as Cydia Substrate and Frida.

[0056] Code obfuscation detection involves deeply obfuscating the binary code of a component, exponentially increasing the difficulty of static analysis and dynamic reverse engineering. For example, by verifying the hash value of the component's own binary code segment, it can be determined whether it has been repackaged or decompiled and tampered with.

[0057] If any security threat is detected (such as the presence of a debugger, a hooked function address, or a code integrity exception), the decryption component immediately terminates execution, throwing an exception or directly calling System.exit() / exit(0) to crash the application, preventing attackers from obtaining any key information. If no security threat is detected, proceed to the next step.

[0058] This embodiment integrates the RASP mechanism for proactive runtime defense, achieving effective protection against dynamic debugging and memory attacks.

[0059] After receiving the encryption key data, the decryption component executes the decryption process:

[0060] For the private obfuscation layer, a custom bitwise operation inverse algorithm that corresponds completely to the encryption stage is executed. For example, each byte is circularly shifted left by 3 bits (rotateLeft(byte, 3)); XORed with the preset key 0x5A (byte ^=0x5A); and multiple rounds of shift and XOR operations are repeated to form a non-linear obfuscation chain.

[0061] For the complex encryption layer, the ciphertext is input into the standard AES-256-GCM decryption algorithm, and decryption is performed using the key derivation key (KDK) pre-installed within the component, outputting the original plaintext key.

[0062] In one embodiment, the decryption component first performs private obfuscation layer decryption and then performs composite encryption layer decryption. For example, the decryption component first performs a reverse custom bitwise operation to restore the original ciphertext of AES-GCM, and then performs AES-256-GCM decryption to restore the plaintext key.

[0063] The entire decryption process is executed only in the application process's memory space. The plaintext key is never written to disk, logs, or shared storage, and it immediately enters the destruction process after decryption to shorten the exposure window of the plaintext key.

[0064] The decryption component has a pre-set templated initialization code snippet. The initialization code snippet uses pseudo-parameters to replace the key content. After decrypting and obtaining the plaintext key in memory, the pseudo-parameters are automatically replaced with the plaintext key to generate the initialization logic of the final executable target business SDK. After the target business SDK is initialized according to the initialization logic, a memory clearing operation is immediately performed to clear the plaintext key in the memory space, shortening its exposure window period.

[0065] In this way, the entire sensitive operation chain of "decryption -> obtaining plaintext -> using plaintext" is completely encapsulated within a black-box component with proactive defense capabilities. Even if business developers can access and debug the application's business code, they cannot access or observe the execution details inside this security component, thus preventing them from easily obtaining the plaintext key at runtime. This effectively isolates risks and achieves defense-in-depth against untrusted development environments.

[0066] In practical applications, business developers only need to include the decryption component dependency in their projects and call its public methods during application initialization, while passing in the encryption key data.

[0067] This disclosure embodiment encrypts the plaintext key of a mobile application to obtain encrypted key data, which is then integrated into the application code of the mobile application, forming a static code-level "key obfuscation." This effectively resists static analysis and basic reverse engineering, strengthening application security. During application runtime, a decryption component decrypts the encrypted key data in memory to obtain the plaintext key. After the application completes SDK initialization with the plaintext key, the plaintext key in memory is destroyed, forming a runtime environment "key isolation." This significantly enhances the defense against runtime attacks such as dynamic debugging and memory scraping, and effectively manages the risk of key leakage during internal or supply chain development. Through this two-layer protection mechanism of static code-level "key obfuscation" and runtime environment "key isolation," comprehensive and multi-layered security protection is provided for application keys, effectively preventing the leakage of sensitive key information in mobile applications and reducing security risks such as data leakage, financial loss, and brand reputation damage caused by key credential leakage.

[0068] Based on the above embodiments, the following describes the entire process from requirement to security assurance.

[0069] Figure 2 This is a schematic diagram of the overall architecture of an application key security protection method according to an embodiment of the present disclosure. Figure 2 As shown in the diagram, this architecture diagram illustrates the overall architecture of application key security protection from requirement to security implementation: based on the key protection requirements of mobile applications, a two-layer protection mechanism is adopted, and the two layers of protection work together to ultimately achieve the goal of mobile application key security protection. Specifically:

[0070] 2-1. Clearly define the key protection requirements for mobile applications; this is the starting point for the entire system construction.

[0071] 2-2. Implement the first layer of protection, namely static key obfuscation and runtime decryption, to solve the key hard-coding problem and resist static analysis and basic reverse engineering;

[0072] 2-3. Implement a second layer of protection, namely key isolation and access control based on dynamic components, to enhance the defense against runtime attacks and manage the risk of key leakage in internal or supply chain development.

[0073] 2-4. Enable the two layers of protection to work synergistically, integrating their respective advantages;

[0074] 2-5. Achieve secure protection for mobile application keys to reach the ultimate goal.

[0075] The above steps are carried out sequentially, with each step laying the foundation for the next. The first layer of protection is the foundation, while the second layer is an advancement upon the first. The synergistic effect of these two layers of protection is key to achieving security.

[0076] For the first layer of protection, Figure 3 This is a flowchart illustrating a first-layer protection mechanism according to an embodiment of the present disclosure. Figure 3 As shown, this flowchart details the workflow of the first layer of protection. It encrypts the plaintext key using a key encryption tool and decrypts it during application runtime, emphasizing the specific operations and memory security involved in the encryption and decryption processes. Specifically:

[0077] 3-1. The initial state is a plaintext key;

[0078] 3-2. Encrypt the plaintext key using a key encryption tool that includes a composite encryption algorithm (AES-256-GCM), a private obfuscation layer (custom bitwise operations), security management (authorization mechanism), and standardized output (binary byte array).

[0079] 3-3. Obtain the encrypted binary data block;

[0080] 3-4. Integrate the encrypted binary data block into the application code;

[0081] 3-5. Application running;

[0082] 3-6. The runtime decryption component starts working, first performing the reverse custom bitwise operation, and then performing AES-256-GCM decryption;

[0083] 3-7. Output the plaintext key.

[0084] The various components of the key encryption tool work together to encrypt the plaintext key, and the encrypted result is used for application integration. During application runtime, the decryption component operates in accordance with the encryption process to restore the plaintext key.

[0085] This first layer of protection eliminates the plaintext key in the source code and compiled binary files through two stages: "offline pre-encryption" and "runtime decryption." It replaces the plaintext key with encrypted ciphertext data, which is decrypted only in memory during application runtime. Developers no longer write the plaintext key into the code; instead, they integrate it as an encrypted block of binary data. This layer effectively resists all attacks based on static analysis. Even if an attacker obtains the application's source code or binary files, they will only see a string of meaningless binary data and cannot directly obtain the plaintext key. The composite encryption algorithm increases the difficulty of analysis for automated cracking tools.

[0086] For the second layer of protection, on the basis of the first layer of protection, a "key management and distribution platform" and a "dynamic registration and initialization component" are introduced, which aim to achieve closed-loop management of the key lifecycle and completely shield the caller (i.e., business developers) from the plaintext form of the key and the initialization details.

[0087] Figure 4 This is a schematic diagram illustrating the workflow of a key management and distribution platform in a second-layer protection mechanism according to an embodiment of this disclosure. Figure 4 As shown, this flowchart illustrates the workflow of the key management and distribution platform in the second layer of protection, from developer registration to component distribution, providing business developers with usable components. Specifically:

[0088] 4-1. Developers begin the process of modular registration. They add the SDK modules that need protection to the key management and distribution platform, supporting both third-party and internal SDKs. At the same time, they need to provide the initialization code snippet and dependency coordinates of the SDK. Public third-party SDKs do not need to be provided; the platform will dynamically integrate them based on the developer's selection.

[0089] 4-2. Implement code templates. Specifically, when providing initialization code, developers use platform-defined pseudo-parameters, such as PSEUD_PARAMETER_x, to replace the real key. The platform itself only cares about the initialization logic and does not access the plaintext key.

[0090] 4-3. Built-in proactive defense mechanism, which integrates the core logic of the "runtime decryption component" in the first layer of protection into this new component;

[0091] 4-4. Add the SDKs that need protection to the project according to the dependency coordinates provided by the developer;

[0092] 4-5. Integrate initialization code snippets, i.e., initialization code snippets provided by the developer that use pseudo-parameters;

[0093] 4-6. Generate a public API call interface;

[0094] 4-7. Compile and package the component that contains complete logic for "decryption + multi-SDK initialization";

[0095] 4-8. Publish the packaged components to a private component repository, such as a private Maven / CocoaPods repository;

[0096] 4-9. Provide business developers with the component's dependency coordinates and calling method descriptions;

[0097] 4-10. Developer access and use.

[0098] The above steps are performed sequentially, with each step laying the foundation for the next. Developer registration and code templating are prerequisites for component building. Once the component is built, it is distributed and made available to business developers.

[0099] Figure 5 This is a schematic diagram illustrating the workflow of dynamically registered and initialized components in a second-layer protection mechanism according to an embodiment of this disclosure. Figure 5 As shown, this flowchart details the internal execution flow of the dynamic registration and initialization components in the second layer of protection, as well as the runtime proactive defense techniques to ensure the security of key usage. Specific steps include:

[0100] 5-1. Business developers introduce component dependencies;

[0101] 5-2. Call the public method and pass in the encryption key data;

[0102] 5-3. Dynamic registration and initialization of components begin;

[0103] 5-4. Receive encryption key data;

[0104] 5-5. Perform decryption operations, including custom bitwise operation reversal and AES-GCM decryption;

[0105] 5-6. Initialize the SDK using the decrypted plaintext key;

[0106] 5-7. Destroy the plaintext key in memory;

[0107] 5-8. This component integrates runtime proactive defense mechanisms, including anti-debugging (detecting debuggers), anti-Hooking (verifying the addresses of critical functions), and code obfuscation (deeply obfuscating binary code).

[0108] The actions of business developers trigger the component's workflow, and the component sequentially completes operations such as data reception, decryption, initialization, and key destruction. A proactive runtime defense mechanism is implemented throughout the entire process, protecting the component from dynamic debugging and memory attacks.

[0109] Figure 6 This is a schematic diagram illustrating the collaborative operation of two layers of protection according to an embodiment of the present disclosure. Figure 6 As shown in the flowchart, this process demonstrates the effectiveness of the two-layer protection working together. By integrating the advantages of both layers, it achieves defense against different types of attacks and control over the risk of key leakage, ultimately ensuring the security of core data and business operations in mobile applications. Specifically, it includes:

[0110] The first layer of protection (static key obfuscation and runtime decryption) and the second layer of protection (key isolation based on dynamic components) work together to achieve synergy between the two layers of protection;

[0111] The two layers of protection work together to produce a variety of effects, including resisting static analysis and basic reverse engineering, improving the ability to defend against runtime attacks, and managing the risk of key leakage.

[0112] These effects work together to ensure the security of core data and business operations in mobile applications.

[0113] The first and second layers of protection form the basis of their synergistic effect, which is crucial for ensuring the security of mobile applications. Different effects work together to achieve the goal of securing application keys.

[0114] In summary, the application key security protection method provided in this disclosure has at least the following advantages:

[0115] First, layered protection: a two-layer protection mechanism is adopted. The first layer of protection targets the problem of cracking hard-coded keys at the static level. The second layer of protection, on the basis of the first layer, further provides a runtime isolation mechanism to achieve defense in depth, cope with dynamic analysis and debugging attacks, significantly reduce the security risks caused by various key leakage scenarios, and provide comprehensive protection for key security.

[0116] Second, composite encryption and obfuscation: The key encryption tool in the first layer of protection uses the composite encryption algorithm AES-256-GCM and is superimposed with a private obfuscation layer, which increases the complexity and cost of reverse engineering and effectively resists static analysis attacks.

[0117] Third, runtime proactive defense: The second layer of protection encapsulates the decryption and use of keys in a "black box" component and introduces an automated platform and integrated runtime application self-protection (RASP) mechanism, including anti-debugging, anti-hooking and code obfuscation techniques, to build an isolated "security black box" with proactive defense capabilities, effectively protect against runtime attacks and manage the risk of key leakage during internal or supply chain development processes.

[0118] Figure 7 This is a schematic diagram of the structure of an application key security protection system according to an embodiment of the present disclosure. Figure 7 As shown, the application key security protection system 70 includes the following modules:

[0119] Monitoring module 71 is configured to monitor whether encrypted key data is integrated into the application code during application operation.

[0120] Module 72 is configured to call the decryption component 73 through a standard interface in response to the detection of encryption key data, and pass in the encryption key data.

[0121] The decryption component 73 is an independently encapsulated black-box component (AAR / Framework) containing: the target business SDK dependency library, encryption key decryption logic, initialization code snippets, and a RASP detection mechanism. This decryption component 120 automatically performs RASP detection based on the RASP detection mechanism at runtime. Only after confirming the environment is secure does it execute the encryption key decryption logic in memory to obtain the plaintext key. Based on the target business SDK dependency library, it applies the plaintext key to call the initialization code snippet to complete the SDK initialization, and then immediately clears the plaintext key from memory; otherwise, it terminates actively.

[0122] The calling module 72 does not hold, process, or store any key information; it serves only as the entry point for the call.

[0123] Optionally, the decryption component 73 also encapsulates a memory-safe destruction mechanism, thereby clearing the plaintext key from memory based on the memory-safe destruction mechanism.

[0124] Furthermore, the decryption component 73 is also configured to clear intermediate variables in memory after initialization is complete.

[0125] This application key security protection system decouples business development from key management through module isolation and separation of responsibilities, so that business developers do not need to access any plaintext keys or decryption logic.

[0126] The application key security protection system provided in this disclosure can execute the methods provided in the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0127] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Figure 8 As shown, the electronic device 80 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the electronic device 80 further includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus 804.

[0128] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0129] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0130] In the above embodiments, it should be understood that the processor can be a CPU (Central Processing Unit), or other general-purpose processors, DSPs (Digital Signal Processors), ASICs (Application Specific Integrated Circuits), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0131] The memory may include RAM (Random Access Memory) and may also include NVM (Non-volatile Memory), such as at least one disk storage device.

[0132] The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings of this application are not limited to only one bus or one type of bus.

[0133] This disclosure also provides a computer program product, including a computer program that, when executed by a processor or the like, implements the above-described method.

[0134] This disclosure also provides a computer-readable storage medium storing computer-executable instructions that, when executed, implement any of the methods described above.

[0135] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0136] For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use in or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0137] Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

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

[0139] In the description of this disclosure, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. In this disclosure, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0140] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0141] In this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this disclosure according to the specific circumstances.

[0142] Although embodiments of the present disclosure have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A method for application key security protection, characterized in that, Includes the following steps: During application operation, monitor whether the application code integrates encrypted key data; In response to the detection of encrypted key data, the decryption component is called through an interface, passing in the encrypted key data. The decryption component at least encapsulates the target business software development kit (SDK) dependency library, encrypted key decryption logic, and initialization code snippets. The decryption component also has a built-in runtime application self-protection RASP detection mechanism. When the decryption component is called, it performs RASP detection in real time, and in a secure environment, it uses the encrypted key decryption logic to decrypt the encrypted key data in memory to obtain the plaintext key. Based on the target business SDK dependency library, it uses the plaintext key to call the initialization code snippets to complete the initialization of the target business SDK, and then destroys the plaintext key in memory.

2. The method according to claim 1, characterized in that, The encryption key data is a binary data block.

3. The method according to claim 2, characterized in that, The encryption key data is obtained by encrypting it using a composite encryption algorithm and a private obfuscation algorithm.

4. The method according to claim 3, characterized in that, The composite encryption algorithm is the AES-256-GCM algorithm.

5. The method according to claim 3, characterized in that, The proprietary obfuscation algorithm is a custom bitwise operation algorithm, including at least one of the following: a circular shift algorithm or an XOR obfuscation algorithm.

6. The method according to any one of claims 1 to 5, characterized in that, The initialization code snippet uses pseudo-parameters instead of the encryption key data.

7. The method according to any one of claims 1 to 5, characterized in that, The RASP detection includes at least one of anti-debugging detection, anti-hooking detection, and code obfuscation.

8. An application key security protection system, characterized in that, The application key security protection system includes: The monitoring module is configured to monitor whether encrypted key data is integrated into the application code during application operation. The calling module is configured to respond to the detection of encryption key data by calling the decryption component through an interface, passing in the encryption key data; The decryption component at least encapsulates the target business software development kit (SDK) dependency library, encryption key decryption logic, and initialization code snippets, and has a built-in runtime application self-protection RASP detection mechanism. The decryption component is configured to perform RASP detection and, in a secure environment, decrypt the encryption key data in memory using the encryption key decryption logic to obtain the plaintext key. Furthermore, based on the target business SDK dependency library, the plaintext key is used to call the initialization code snippets to complete the initialization of the target business SDK, and then the plaintext key in memory is destroyed.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the application key security protection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed, it implements the application key security protection method as described in any one of claims 1 to 7.

Images