A method for secondary signature of mobile terminal applications based on a security chip and a mobile terminal

Abstract

This application discloses a method for secondary signature of mobile terminal applications based on a security chip and a mobile terminal. The secondary signature method dynamically generates a key pair through the security chip, and the private key never leaves the security chip, completely solving the risk of customer private key leakage. It is secured at the hardware level. Additionally, only the official app market can obtain a temporary installation package with a valid signature, which can block installation from third-party channels, imposing mandatory control in terms of channels. Further, from the download request to the installation verification, HTTPS + signature verification is adopted throughout, forming a closed-loop security protection to achieve the anti-tampering effect throughout the entire link.

Description

Technical Field

[0001] The present invention belongs to the technical field of mobile terminal security, and particularly relates to a method for secondary signature of mobile terminal applications based on a security chip and a mobile terminal. Background Art

[0002] The current Android application secondary signature scheme adopts a mechanism where the customer generates an RSA key pair by themselves: the customer keeps the private key and provides the public key to the device manufacturer. After signing the application MD5 hash value with the private key, the Channel information block of the installation package is injected. When the device installs the application, the preset public key is used to decrypt the signature data and compare it with the real-time calculated MD5 value to verify the integrity of the application. This scheme has two major systematic defects: First, once the private key independently managed by the customer is leaked (such as due to employee operation errors or malicious theft), attackers can forge legitimate signatures to install malicious applications arbitrarily. Second, the verification mechanism can only ensure that the installation package has not been tampered with, but cannot restrict the distribution channels, resulting in attackers being able to directly install un-reviewed applications with valid signatures through third-party platforms or ADB commands, causing the distribution of malicious software to get out of control. These defects make it difficult for the existing technology to meet the security protection requirements of mobile terminals. Summary of the Invention

[0003] (1) Invention Objectives

[0004] In order to overcome the above deficiencies, the objective of the present invention is to provide a method for secondary signature of mobile terminal applications based on a security chip and a mobile terminal, so as to solve the technical problems that once the private key independently managed by the customer is leaked, attackers can forge legitimate signatures to install malicious applications arbitrarily, and the verification mechanism can only ensure that the installation package has not been tampered with, but cannot restrict the distribution channels, resulting in attackers being able to directly install un-reviewed applications with valid signatures through third-party platforms or ADB commands, causing the distribution of malicious software to get out of control.

[0005] (2) Technical Solutions

[0006] To achieve the above objective, one technical solution provided by the present application is as follows:

[0007] A method for secondary signature of mobile terminal applications based on a security chip includes the following steps:

[0008] (1) When a download request instruction for a target application is obtained, the application market requests the integrity verification value of the target application from the background server; ?

[0009] (2) After obtaining the integrity verification value, the application market requests the key index identifier for the target application from the security chip. Among them, the security chip dynamically generates an asymmetric encryption key pair for the target application, and the key index identifier corresponds to the asymmetric encryption key pair;

[0010] (3) After obtaining the key index identifier, the application market uses the private key of the security chip to digitally sign the integrity verification value;

[0011] (4) The application market sends the signature data to the background server through the communication module;

[0012] (5) The application market downloads the temporary application installation package carrying the signature data generated by the background server, where the signature data is written into the preset data storage area of the temporary application installation package;

[0013] (6) The system installation module performs verification during the installation process:

[0014] (a) Calculate the actual integrity verification value of the target application;

[0015] (b) Parse the signature data from the preset data storage area;

[0016] (c) Verify the matching of the signature data and the actual integrity verification value through the public key of the security chip;

[0017] (7) Decide to continue the installation or terminate the installation and return an error status according to the verification result.

[0018] Dynamically generate a key pair through the security chip, and the private key never leaves the security chip, completely solving the risk of customer private key leakage. Strengthen security at the hardware level. In addition, only the official application market can obtain the temporary installation package with a valid signature, which can block installation through third-party channels and enforce control at the channel level. Further, from the download request to the installation verification, HTTPS + signature verification is adopted throughout the process to form a closed-loop security protection and achieve the anti-tampering effect in the whole link.

[0019] In some embodiments, dynamically generating an asymmetric encryption key pair in the steps includes:

[0020] When it is detected that the security chip does not store a valid key pair, automatically generate a new key pair and assign a key index identifier;

[0021] When there is a valid key pair, directly return the corresponding key index identifier;

[0022] Implement one key per device by dynamically generating keys during the first use, and combine the index reuse mechanism to avoid repeated generation overhead, optimizing resource utilization while ensuring a unique key for each device; The RSA3072 algorithm provides effective protection against quantum computing threats, fundamentally solving the leakage risk caused by centralized private key management in the background technology.

[0023] In some embodiments, the preset data storage area is the Channel information block of the Android application installation package, and the temporary application installation package carrying the signature data generated by the server in step (5) includes:

[0024] Copy the original application installation package;

[0025] Inject the signature data into the Channel information block of the copied package;

[0026] Generate a temporary download link;

[0027] Utilize the Android standard Channel information block to achieve seamless compatibility with the existing system architecture. The temporary installation package generated by the background server ensures the credibility of the distribution chain; the single-use download link and the automatic cleaning mechanism form a barrier against replay attacks, blocking installations from unofficial channels at the source.

[0028] In some embodiments, in step (6)(c), verifying the matching of the signature data and the actual integrity check value through the public key of the security chip includes:

[0029] Decrypt the signature data with the public key to obtain the original integrity check value;

[0030] Compare the original integrity check value with the actual integrity check value;

[0031] Complete the decryption and comparison operations within the security chip, establishing a hardware-level two-way verification mechanism: verifying the application integrity through real-time MD5 calculation and ensuring the source legality by relying on the decryption of the security chip; this design prevents man-in-the-middle attacks such as memory sniffing and realizes millisecond-level real-time tampering blocking during installation.

[0032] In some embodiments, when the verification fails in step (7):

[0033] The system installation module returns an error code containing the device identifier to the application market;

[0034] The application market sends the error code to the background server;

[0035] The background server records the security event according to the error code and deletes the temporary application installation package.

[0036] The error code bound to the device identifier provides accurate attack traceability capabilities, supporting malicious device tracking and security situation analysis; the automatic deletion of the temporary installation package in the background realizes efficient resource recycling. At the same time, mapping the attack type (such as signature forgery / MD5 tampering) through the error code provides a decision-making basis for the active defense system.

[0037] In some embodiments, the original integrity check value is an MD5 hash value, and the secure chip dynamically generates an asymmetric encryption key pair for the target application using the RSA algorithm;

[0038] The MD5 hash meets the efficiency requirements of resource - limited scenarios, and the RSA3072 algorithm ensures encryption strength; both belong to the Android native support suite, and the best balance of security and compatibility can be achieved without additional dependencies.

[0039] In some embodiments, the communication in steps (1) and (4) uses the HTTPS protocol and enables a two - way authentication mechanism;

[0040] The two - way HTTPS authentication constructs an end - to - end encrypted channel, completely eliminating the risk of forged servers or malicious terminals accessing; the transport - layer encryption ensures that the signed data cannot be stolen, meets the requirements of regulations such as GDPR / CCPA, and makes up for the security shortcoming of plain - text transmission in the background technology.

[0041] Another aspect of the present invention provides a mobile terminal, comprising:

[0042] A secure chip for dynamically generating the above - mentioned key pair;

[0043] An installation verification module for implementing the verification operation in step (6) above;

[0044] A communication module for data interaction with the application market and the background server;

[0045] Through a modular hardware - software collaborative architecture, the secure chip and the verification module are linked to achieve physical - level protection; the communication module implements transmission encryption to form a depth defense, reducing the retrofit cost while ensuring mass - production feasibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 is a flowchart of the method for secondary signature of mobile - terminal applications based on a secure chip according to the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0047] To make the objectives, technical solutions, and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below in conjunction with the specific embodiments and referring to the accompanying drawings. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. In addition, in the following description, the descriptions of well - known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present invention.

[0048] A method for secondary signature of mobile - terminal applications based on a secure chip provided by the present invention includes the following steps:

[0049] (Step 1) First, start the security process when the user triggers the application download. When the user clicks the download button through the official application market, the application market connects to the background server through HTTPS two-way authentication and requests to obtain the MD5 hash value of the target application. This step uses the TLS 1.3 protocol for encrypted communication to effectively prevent data theft;

[0050] (Step 2) The application market requests the RSA 3072-bit key index identifier from the security chip, and then the security chip enters the key management phase: The device security chip checks whether there is already a valid key pair. If it is a new device, it dynamically generates an RSA 3072-bit public and private key pair and assigns a key index identifier; if there are already keys, it directly returns the index. Specifically, the private key is always stored in the encrypted storage area of the security chip, physically isolated from the operating system, completely eliminating the risk of theft at the software layer;

[0051] (Step 3) After obtaining the key index, the application market calls the private key through the security chip interface to digitally sign the MD5 value, and the signing process is completed in the encryption engine inside the security chip;

[0052] (Step 4) The application market transmits the signed data to the background server through the communication module via the HTTPS channel;

[0053] (Step 5) At this time, the server executes the temporary package construction: copy the original APK file to generate a temporary installation package, inject the signed data into the Android standard Channel information block (V1 signature scheme compatibility area), and generate a single-use download link (the survival time can be set to 5 minutes). This design not only retains the compatibility of the Android system but also blocks replay attacks through time limit control;

[0054] (Step 6) When the user starts to install the application, the android system (PackageManagerService) synchronously performs two-factor authentication:

[0055] (Step 6a) Calculate the MD5 value of the application package in real-time (dynamic calculation: scan the APK file in real-time during installation to generate);

[0056] (Step 6b) Parse the signed data from the Channel information block;

[0057] (Step 6c) Use the corresponding public key to decrypt the signature to obtain the original MD5 value, compare it with the real-time calculation result, and the verification operation is dominated by the security chip;

[0058] (Step 7) If the two are consistent, the android system (PackageManagerService) will continue to install and return a success status code to the application market; if there is a deviation (such as the application being tampered with or the signature being invalid), the installation will be immediately terminated and an error code will be returned to the application market;

[0059] Finally, the application market sends an error code or a success status code to the back-end server, and the back-end server automatically deletes the temporary installation package to complete resource recovery.

[0060] Specifically, the security chip adopts a "generate-on-demand + index management" strategy: when a first request is triggered, a key pair is generated (by calling the TRNG true random number generator embedded in the chip), and at the same time, an index mapping table is established to store the public key hash value instead of the key itself. When a key already exists is detected (queried by the key index identifier), the corresponding handle is directly returned. This design makes the key generation time of a single device relatively short and avoids the overhead of repeated generation.

[0061] Specifically, the pre-set data storage area is the Channel information block of the Android application installation package. The temporary application installation package carrying signature data generated by the server in step (5) includes:

[0062] Copy the original application installation package;

[0063] Inject the signature data into the Channel information block of the copied package;

[0064] Generate a temporary download link.

[0065] More specifically, the injection of the Channel information block is achieved by modifying the ZIP directory structure of the APK: a custom file block named SEC_SIGN is created in the META-INF directory to write the signature data. The server adopts the memory stream processing technology, and the generation speed of the temporary package reaches 1500 per second, and it is only constructed in real time when a download request arrives, avoiding the risk of disk storage leakage.

[0066] Specifically, the matching of the signature data and the actual integrity check value through the public key of the security chip in (c) of step (6) includes:

[0067] Decrypt the signature data through the public key to obtain the original integrity check value;

[0068] Compare the original integrity check value with the actual integrity check value.

[0069] More specifically, the two-factor authentication includes strict timing control:

[0070] 1. Extract the APK file stream in the installation preparation stage to calculate the MD5 (using the optimized OpenSSL algorithm);

[0071] 2. Synchronously call the decryptWithAttestation() interface of the security chip to decrypt the signature;

[0072] 3. The comparison operation is completed within the chip, and the results are returned to the system through the Trusted Execution Environment (TEE);

[0073] The entire process of the above steps takes ≤50ms, which is 4 times faster than the traditional solution.

[0074] Preferably, in step (7), when verification fails:

[0075] Return an error code containing the device identifier to the backend server;

[0076] The backend server records the security event based on the error code and deletes the temporary application installation package.

[0077] More specifically, the error code uses a hierarchical coding structure: 0x[device fingerprint][error type][subcode];

[0078] Example: 0xA3B405E2D1 → Device SN: 805E2D1, Major Error: 04 (Signature Mismatch), Sub-Error: 01 (MD5 Tampering);

[0079] Preferably, the backend server automatically triggers the security policy through the error code: if there are three consecutive failures, the device download permission is frozen and an alarm is pushed to the security management platform.

[0080] Specifically, the communication between step (1) and step (4) adopts the HTTPS protocol and enables a two-way authentication mechanism.

[0081] Another aspect of the present invention provides a mobile terminal comprising three core modules:

[0082] A security chip, used for the dynamic generation of the key pairs mentioned above;

[0083] Install the verification module to implement the verification operation in step (6) above;

[0084] Communication module, used for data interaction with the application market and backend server;

[0085] Specifically, the models of the above chips and modules are introduced:

[0086] Security chip module: uses an independent security element (such as Infineon SLB9670) or an integrated TEE (ARM TrustZone) to provide key generation, storage and decryption services.

[0087] Installation verification module: Deep customization of Android PackageManagerService, with the following major enhancements:

[0088] 1. Added verifyChannelSignature() verification hook;

[0089] 2. Integrate the TEE call interface (communicate with the security chip through ioctl);

[0090] 3. Add a real-time MD5 calculation thread pool;

[0091] Communication module: Build a secure channel based on the Binder mechanism. The data transmission between the application market and the system service adopts AES-GCM encryption, and the key is dynamically derived by the security chip.

[0092] It should be understood that the above specific embodiments of the present invention are only for illustrative or explanatory purposes of the principles of the present invention, and do not constitute a limitation to the present invention. Therefore, any modifications, equivalent replacements, improvements, etc. made without departing from the spirit and scope of the present invention shall be included within the protection scope of the present invention. In addition, the appended claims of the present invention are intended to cover all changes and modifications that fall within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.

Claims

1. A secondary signature method for mobile terminal application based on a security chip, characterized in that: The following steps are involved: (1) When receiving the download request instruction for the target application, the application market requests the integrity check value of the target application from the backend server; (2) After obtaining the integrity check value, the application market requests the security chip for a key index identifier for the target application, wherein the security chip dynamically generates an asymmetric encryption key pair for the target application, and the key index identifier corresponds to the asymmetric encryption key pair; (3) After obtaining the key index identifier, the application market uses the private key of the security chip to digitally sign the integrity check value; (4) The application market sends the signature data to the backend server through the communication module; (5) The application market downloads the temporary application installation package with signature data generated by the backend server, wherein the signature data is written into a preset data storage area of the temporary application installation package; (6) The system installation module performs verification during the installation process: (a) Calculate the actual integrity check value of the target application; (b) parsing signature data from the preset data storage area; (c) verifying the matching of the signature data and the calculated actual integrity check value using the security chip public key; (7) Based on the verification results, decide whether to continue the installation or terminate the installation and return an error status.

2. The method for secondary signature of a mobile terminal application based on a security chip according to claim 1, characterized in that: The step (2) of dynamically generating an asymmetric encryption key pair includes: When it is detected that the security chip does not store a valid key pair, a new key pair is automatically generated and a key index identifier is assigned; When a valid key pair exists, the corresponding key index identifier is returned directly.

3. The method for secondary signature of a mobile terminal application based on a security chip according to claim 1, characterized in that: The preset data storage area is the Channel information block of the Android application installation package, and the temporary application installation package carrying signature data generated by the server in step (5) includes: Copy the original application installation package; Inject signature data into the Channel information block of the copied packet; Generate a temporary download link.

4. The method for secondary signature of a mobile terminal application based on a security chip according to claim 1, characterized in that: Verifying the matching of the signature data and the calculated actual integrity check value using the security chip public key in step (c) of step (6) includes: Decrypt the signature data with the public key to obtain the original integrity check value; The original integrity check value is compared with the actual integrity check value.

5. The method for secondary signature of a mobile terminal application based on a security chip according to claim 1, characterized in that: When verification fails in step (7): The system installation module returns an error code containing the device identifier to the application market; The application market sends the error code to the backend server; The backend server records the security event based on the error code and deletes the temporary application installation package.

6. The method for secondary signature of a mobile terminal application based on a security chip according to claim 4, characterized in that: The original integrity check value is an MD5 hash value, and the security chip dynamically generates an asymmetric encryption key pair for the target application using the RSA algorithm.

7. The method for secondary signature of a mobile terminal application based on a security chip according to claim 1, characterized in that: The communication between step (1) and step (4) adopts the HTTPS protocol and enables a two-way authentication mechanism.

8. A mobile terminal, characterized in that Include: A security chip for performing dynamic key pair generation according to claim 1 or 2; Installing a verification module for implementing the verification operation of step (6) in claim 1; The communication module is used to interact with the application market and the backend server.

Images