Method, device and medium for detecting trustworthiness of application running environment

Abstract

The application provides a trustworthiness detection method and device of an application running environment and a medium. The technical scheme of the application utilizes the characteristics that the code and data in the trusted execution environment cannot be cracked, modified and acquired by the outside world. The trusted application corresponding to the trusted execution environment can acquire information related to the third-party application running environment, and the information is encrypted or signed by using an asymmetric encryption algorithm or the like and then transmitted to the server side. The information can only be verified at the server side, thereby reducing the probability of tampering of the information. The trustworthiness of the third-party application running environment is detected based on the information, which is more accurate. Finally, the third-party application can be ensured to run in a trusted running environment, and the security of the application running environment is improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method, device and medium for detecting the trustworthiness of an application runtime environment. Background Technology

[0002] Third-party applications in payment, finance, and gaming sectors typically have high requirements for the trustworthiness of their operating environment, primarily in two aspects: First, terminal devices are often vulnerable to rooting or malicious attacks due to fragmentation and system vulnerabilities. When applications run on such devices, attackers may use tools like hooks or packet sniffing to compromise user privacy, application developers' confidential data, and game balance. In other words, the terminal devices hosting these third-party applications need to possess a certain level of trustworthiness. Second, because attackers or adversaries often have higher privileges on the terminal devices, the third-party applications themselves may also be vulnerable to attack. Therefore, the third-party applications themselves also need to possess a certain level of trustworthiness.

[0003] Therefore, detecting the trustworthiness of the application's runtime environment to ensure that third-party applications run in a trusted environment is a technical problem that this application urgently needs to solve. Summary of the Invention

[0004] This application provides a method, device, and medium for testing the trustworthiness of an application runtime environment, thereby ensuring that third-party applications run in a trusted runtime environment.

[0005] Firstly, a method for verifying the trustworthiness of an application runtime environment is provided. The method includes: a third-party application in a terminal device sending a request message to a mobile device integrity verification module in the terminal device; the mobile device integrity verification module responding to the request message to obtain a first information set, which is an information set used to verify the trustworthiness of the runtime environment of the third-party application; the mobile device integrity verification module sending the first information set to a trusted application corresponding to a trusted execution environment in the terminal device; the trusted application generating a public-private key pair for a secondary certificate corresponding to the third-party application; the trusted application obtaining a second information set, which is an information set used to verify the trustworthiness of the runtime environment; the trusted application signing the first information set and the second information set using the private key in the public-private key pair of the secondary certificate to obtain a first signature; and the trusted application using the root access key of the terminal device... The certificate private key signs the first public key in the secondary certificate's public-private key pair to obtain a second signature. The trusted application sends a first information set, a second information set, a first public key, a first signature, and a second signature to the application server corresponding to the third-party application through the mobile device integrity verification module and the third-party application. The application server checks the validity of the second signature. If the second signature is valid, the application server checks the validity of the first signature using the first public key. If the first signature is valid, the application server checks the validity of each piece of information in the first and second information sets. If all pieces of information in the first and second information sets are valid, the application server determines that the operating environment is trustworthy. If the first signature is invalid, the second signature is invalid, or at least one piece of information in the first and second information sets is invalid, the application server determines that the operating environment is untrustworthy.

[0006] Secondly, a method for verifying the trustworthiness of an application runtime environment is provided, comprising: a third-party application in a terminal device sending a request message to a mobile device integrity verification module in the terminal device; the mobile device integrity verification module responding to the request message to obtain a first information set, the first information set being an information set used to verify the trustworthiness of the runtime environment of the third-party application; the mobile device integrity verification module sending the first information set to a trusted application corresponding to a trusted execution environment in the terminal device; the trusted application generating a public-private key pair for a secondary certificate corresponding to the third-party application; the trusted application obtaining a second information set, the second information set being an information set used to verify the trustworthiness of the runtime environment; the trusted application signing the first information set and the second information set using the private key in the public-private key pair of the secondary certificate to obtain a first signature; the trusted application signing the first public key in the public-private key pair of the secondary certificate using the private key of the root certificate of the terminal device to obtain a second signature; and the trusted application sending the first information set, the second information set, the first public key, the first signature, and the second signature to an application server corresponding to the third-party application through the mobile device integrity verification module and the third-party application, so that the application server can verify the trustworthiness of the runtime environment based on the first information set, the second information set, the first public key, the first signature, and the second signature.

[0007] Thirdly, a method for detecting the trustworthiness of an application runtime environment is provided. This method includes: an application server receiving a first information set, a second information set, a first public key, a first signature, and a second signature from a secondary certificate public-private key pair of a terminal device, all from a third-party application; both the first and second information sets are information sets used to detect the trustworthiness of the runtime environment; the first signature is obtained by a trusted application corresponding to the trusted execution environment in the terminal device signing the first and second information sets using the private key from the secondary certificate public-private key pair; the second signature is obtained by a trusted application signing the first public key using the root certificate private key of the terminal device; the application server checks the legality of the second signature; if the second signature is legal, the application server checks the legality of the first signature using the first public key; if the first signature is legal, the application server checks the legality of each piece of information in the first and second information sets; if all pieces of information in the first and second information sets are legal, the application server determines that the runtime environment is trustworthy; if the first signature is invalid, the second signature is invalid, or at least one piece of information in the first and second information sets is invalid, the application server determines that the runtime environment is untrustworthy.

[0008] Fourthly, a trustworthiness detection system for an application runtime environment is provided, comprising: a terminal device and an application server. The terminal device includes: a third-party application corresponding to the application server, a mobile device integrity verification module, and a trusted application corresponding to the trusted execution environment. The third-party application sends a request message to the mobile device integrity verification module. The mobile device integrity verification module responds to the request message by obtaining a first information set and sending the first information set to the trusted application. The first information set is an information set used to detect the trustworthiness of the runtime environment of the third-party application. The trusted application generates a public-private key pair for a secondary certificate corresponding to the third-party application; obtains a second information set, which is an information set used to detect the trustworthiness of the runtime environment; and signs the first and second information sets using the private key in the public-private key pair of the secondary certificate. The system obtains a first signature; it then signs the first public key in the secondary certificate's public-private key pair using the root certificate private key of the terminal device to obtain a second signature; and finally, it sends a first information set, a second information set, a first public key, the first signature, and the second signature to the application server corresponding to the third-party application through the mobile device integrity verification module and the third-party application. The application server is used to: check the legality of the second signature; if the second signature is legal, then check the legality of the first signature using the first public key; if the first signature is legal, then check the legality of each piece of information in the first and second information sets; if all pieces of information in the first and second information sets are legal, then the operating environment is determined to be trustworthy; if the first signature is invalid, the second signature is invalid, or at least one piece of information in the first and second information sets is invalid, then the operating environment is determined to be untrustworthy.

[0009] Fifthly, a terminal device is provided, comprising: a third-party application, a mobile device integrity verification module, and a trusted application corresponding to a trusted execution environment; the third-party application is used to send a request message to the mobile device integrity verification module; the mobile device integrity verification module is used to respond to the request message, obtain a first information set, and send the first information set to the trusted application, the first information set being an information set used to detect the trustworthiness of the third-party application's runtime environment; the trusted application is used to: generate a public-private key pair for a secondary certificate corresponding to the third-party application; obtain a second information set, the second information set being an information set used to detect the trustworthiness of the runtime environment; sign the first information set and the second information set using the private key in the public-private key pair of the secondary certificate to obtain a first signature; sign the first public key in the public-private key pair of the secondary certificate using the private key of the terminal device's root certificate to obtain a second signature; and send the first information set, the second information set, the first public key, the first signature, and the second signature to the application server corresponding to the third-party application through the mobile device integrity verification module and the third-party application, so that the application server can detect the trustworthiness of the runtime environment based on the first information set, the second information set, the first public key, the first signature, and the second signature.

[0010] Sixthly, an application server is provided, comprising: a receiving module and a detection module. The receiving module is used to receive a first information set, a second information set, a first public key, a first signature, and a second signature from a secondary certificate public-private key pair of a terminal device, all from a third-party application. Both the first and second information sets are information sets used to detect the trustworthiness of the operating environment. The first signature is obtained by a trusted application corresponding to the trusted execution environment in the terminal device signing the first and second information sets using the private key from the secondary certificate public-private key pair. The second signature is obtained by a trusted application signing the first public key using the root certificate private key of the terminal device. The detection module is used to: detect the legality of the second signature; if the second signature is legal, then detect the legality of the first signature using the first public key; if the first signature is legal, then detect the legality of each piece of information in the first and second information sets; if all pieces of information in the first and second information sets are legal, then determine that the operating environment is trustworthy; if the first signature is invalid, the second signature is invalid, or at least one piece of information in the first and second information sets is invalid, then determine that the operating environment is untrustworthy.

[0011] A seventh aspect provides an electronic device comprising: a processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform a method as described in any one of the first to third aspects or their respective implementations.

[0012] Eighthly, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform a method as described in any one of the first to third aspects or any implementation thereof.

[0013] Ninth aspect, a computer program product is provided, including computer program instructions that cause a computer to perform a method as described in any one of the first to third aspects or implementations thereof.

[0014] In a tenth aspect, a computer program is provided that causes a computer to perform a method as described in any one of the first to third aspects or any implementation thereof.

[0015] The technical solution provided in this application leverages the characteristic that code and data within a trusted execution environment (TEE) cannot be cracked, modified, or obtained by external parties. Trusted applications within the TEE can obtain information related to the runtime environment of third-party applications and transmit this information to the server after encryption or signing using asymmetric encryption algorithms. This information can only be verified on the server side, reducing the probability of tampering. Therefore, using this information to detect the trustworthiness of the third-party application's runtime environment is more accurate. For payment, financial, or gaming applications, when the technical solution provided in this application detects that the third-party application's runtime environment is untrustworthy, it can prompt the user to prohibit payment or illegal activities, thus ensuring that the third-party application runs in a trusted environment and improving the user experience.

[0016] Meanwhile, this application provides a decentralized detection method, that is, the application server only needs to go to the root certificate verification server to verify the second signature when it first verifies the second signature. After that, the application server can complete the verification of the second signature itself based on the identifier of the terminal device stored locally and the second public key of the secondary certificate. This can effectively protect the application server's own trade secrets, such as the number of daily active users (DAU) of third-party applications.

[0017] Furthermore, in this application, both the root certificate public / private key pair and the secondary certificate public / private key pair of the terminal device are implemented based on a one-device-one-key mechanism. Therefore, if the trusted execution environment of a certain terminal device is compromised, it will not significantly affect other devices of the same model or even all related devices, thus providing good security. In addition, the anonymous identifier of the terminal device is generated based on a one-device-one-key mechanism, thereby improving user privacy and security. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 An illustrative application scenario diagram of the technical solution of this application is shown;

[0020] Figure 2 An interactive flowchart illustrating an application runtime environment reliability detection method provided in this application embodiment;

[0021] Figure 3A schematic diagram of the first information set provided in the embodiments of this application;

[0022] Figure 4 A schematic diagram of the signature verification information package provided in an embodiment of this application;

[0023] Figure 5 An interactive flowchart illustrating another application runtime environment reliability detection method provided in this application embodiment;

[0024] Figure 6 A schematic diagram of a terminal device 600 provided in an embodiment of this application;

[0025] Figure 7 A schematic diagram of an application server 700 provided in an embodiment of this application;

[0026] Figure 8 A schematic diagram of a root certificate verification server 800 provided for an embodiment of this application;

[0027] Figure 9 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0030] Before introducing the technical solution of this application, the relevant knowledge of the technical solution of this application will be explained below:

[0031] Trusted Execution Environment (TEE): Typically used for Digital Rights Management (DRM), mobile payments, and sensitive data protection. On Android, TEEs are usually implemented using TrustZones on Advanced RISC Machines (ARM). Security features: 1. Protected by hardware mechanisms: Applications in normal operation can only communicate with the TEE through specific entry points. 2. Regarding communication mechanisms, the TEE can access the system in normal operation, such as the Android operating system's memory; however, the reverse is not true—Android cannot directly access memory within the TEE environment. 3. Resistant to certain hardware-based attacks: Under normal circumstances, the code and data within the TEE cannot be cracked, modified, or obtained from outside sources.

[0032] Trusted Application (TA): An application that typically runs in a TEE environment.

[0033] The Replay Protected Memory Block (RPMB) is used to protect system data from unauthorized deletion and access. RPMB is directly managed by the TEE (Trusted Execution Environment), and only the TEE can access the content protected by the RPMB. RPMB uses a built-in counter, key, and Hash-based Message Authentication Code (HMAC) verification mechanism to prevent replay attacks, ensuring that data is not maliciously overwritten or tampered with.

[0034] One device, one key: Each terminal device has a unique public-private key pair, which is different from the public-private key pair of any other terminal device. The one device, one key mechanism ensures that even if one terminal device is attacked and its public-private key pair is leaked, other terminal devices will not be affected.

[0035] One device, one key: Terminal devices of the same model use the same public-private key pair, while terminal devices of different models use different public-private key pairs.

[0036] Random salt: A random factor introduced to prevent hash values ​​from being cracked.

[0037] Application (APP) signing: When an application developer releases their application, they need to generate their own signing key pair and securely store the private key. During the release, the developer signs the APP using the private key and includes the signature, along with the public key, in the APP installation package. When the application is installed on the system, the system uses the public key from the application to verify the validity of the signature. Typically, APP signatures are quite long and use hash algorithms, such as Secure Hash Algorithm 1 (SHA-1), to calculate the signature and use it as a representative signature.

[0038] The Mobile Device Integrity Checker (MDIC) module, also known as the Mobile Device Integrity Check Service, is primarily responsible for collecting or transmitting information within the system's authorized limits.

[0039] RSA: It is currently the most influential public-key encryption algorithm. It can resist all known cryptographic attacks to date and has been recommended by the International Organization for Standardization (ISO) as a public-key data encryption standard. RSA is an asymmetric encryption algorithm, meaning that the encryption key and the decryption key are different. Content encrypted with the private key can only be decrypted with the public key, and vice versa.

[0040] SHA-256: For any message length, SHA256 will produce a 256-bit hash value, called a message digest. This digest is equivalent to a 32-byte array, usually represented by a 64-bit hexadecimal string, where 1 byte = 8 bits and a hexadecimal character is 4 bits long.

[0041] Device ID: A unique serial number that identifies a terminal device. It is generally necessary to ensure that the device IDs of any two devices are different and difficult to forge or modify. However, because the device ID can uniquely identify a user, its collection could potentially infringe on user privacy.

[0042] Figure 1 An illustrative application scenario diagram of the technical solution of this application is shown, such as... Figure 1As shown, the terminal device 110 can have third-party applications and trusted applications corresponding to the trusted execution environment installed, and it has a mobile device integrity verification module. The mobile device integrity verification module communicates with the third-party applications and trusted applications through an application programming interface (API). The application server 120 corresponding to the third-party application can communicate with the third-party application, and the application server 120 can communicate with the root certificate verification server 130.

[0043] Optionally, the third-party application can be a payment application, a financial application, a game application, etc., and this application does not impose any restrictions on this.

[0044] Optionally, the terminal device 110 and the application server 120 can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions. For example, communication between the application server 120 and third-party applications can be based on the 5th generation (5G) communication system, the 4th generation (4G) communication system, the 3rd generation (3G) communication system, Wireless Fidelity (WiFi), or other wireless communication technologies.

[0045] Optionally, the terminal device 110 may be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, vehicle terminal, smart TV, etc., but is not limited to these.

[0046] Optionally, the application server 120 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0047] Optionally, the root certificate verification server 130 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services.

[0048] Optionally, when a user clicks on a third-party application, the trustworthiness detection method for the application runtime environment provided in this application can be automatically triggered.

[0049] As mentioned above, third-party applications such as payment, finance, and games typically have high requirements for the trustworthiness of their operating environment. Therefore, detecting the trustworthiness of the application's operating environment to ensure that third-party applications run in a trustworthy environment is a technical problem that this application urgently needs to solve.

[0050] To address the aforementioned technical issues, this application primarily utilizes the characteristic that code and data within a trusted execution environment cannot be cracked, modified, or obtained by external parties. The trusted application corresponding to the trusted execution environment can obtain information related to the runtime environment of third-party applications and transmit this information to the server after encrypting or signing it using asymmetric encryption algorithms. This information can only be verified on the server side.

[0051] The technical solution of this application will be described in detail below:

[0052] Figure 2 This application provides an interactive flowchart of an application runtime environment trustworthiness detection method. The execution entities involved in this method may include: a terminal device and an application server. The terminal device may include: a third-party application, a mobile device integrity verification module, and a trusted application corresponding to the trusted execution environment, such as... Figure 2 As shown, the method includes:

[0053] S201: A third-party application sends a request message to the mobile device integrity verification module;

[0054] Optionally, the above request message is used to request the mobile device integrity verification module to obtain the first information set.

[0055] Optionally, the third-party application can obtain the first random salt corresponding to the third-party application from the application server; accordingly, the request message may include: the first random salt. Since the random salt is a random factor introduced to prevent the hash value from being cracked, the first random salt has the effect of preventing replay of the third-party application.

[0056] S202: The mobile device integrity verification module responds to the request message to obtain the first information set;

[0057] It should be understood that the first information set is the information set used to detect the trustworthiness of the operating environment.

[0058] Optionally, the first information set includes at least one of the following, but is not limited to: the signature of the third-party application, the package name-version number of the third-party application, the first random salt, and the version number of the mobile device integrity verification module.

[0059] For example, Figure 3 A schematic diagram of the first information set provided in the embodiments of this application, as shown below. Figure 3 As shown, the first information set includes: the signature of the third-party application, the package name-version number of the third-party application, the first random salt, and the version number of the mobile device integrity verification module.

[0060] Optionally, since hash algorithms can be used to sign third-party applications, the signature of a third-party application can be called the hash signature of the third-party application, denoted as APP-HASH. The package name-version number of the third-party application can include: the package name and version number of the third-party application, denoted as APP-PKG-VERSION.

[0061] Optionally, the mobile device integrity verification module uses inter-process communication to obtain the signature of the third-party application and the package name-version number of the third-party application.

[0062] For example, in the Android system, when a third-party application calls the mobile device integrity verification module, the mobile device integrity verification module daemon can use getCallingPid to obtain the process ID of the third-party application, and further obtain the signature and package name-version number of the third-party application based on the process ID of the third-party application.

[0063] It should be understood that since the version number of the mobile device integrity verification module is the version number of the mobile device integrity verification module itself, the mobile device integrity verification module can directly obtain this version number.

[0064] S203: The mobile device integrity verification module sends the first information set to the trusted application;

[0065] S204: Trusted application generates a public / private key pair for a secondary certificate corresponding to a third-party application;

[0066] Optionally, after obtaining the first set of information, the trusted application can directly generate the public-private key pair of the second-level certificate of the third-party application using the RSA algorithm. The RSA algorithm can be a 2048-bit or 4096-bit RSA algorithm. The trusted application can also use Elliptic Curve Cryptography (ECC) or Elliptic Curve Public Key Cryptography (SM2) to generate the public-private key pair of the second-level certificate of the third-party application. This application does not impose any restrictions on this.

[0067] Optionally, the trusted application can store the public-private key pair of the third-party application's secondary certificate in the RPMB. This public-private key pair corresponds to the signature and / or package name of the third-party application. Based on this, the trusted application can subsequently obtain the public-private key pair of the third-party application's secondary certificate from the RPMB without generating it itself. It can simply retrieve the pair from the RPMB based on the correspondence between the public-private key pair and the signature and / or package name of the third-party application. Of course, the trusted application can also generate the public-private key pair of the third-party application's secondary certificate each time; this application does not impose any restrictions on this.

[0068] S205: Trusted application obtains second information set;

[0069] The second information set is used to detect the trustworthiness of the operating environment of third-party applications.

[0070] Optionally, the second set of information includes at least one of the following: the status information of the terminal device, the identifier of the terminal device, and the module-version number of the trusted execution environment; wherein, the module-version number of the trusted execution environment includes: the model of the terminal device and the version number of the trusted execution environment.

[0071] Optionally, the terminal device's status information may include whether the terminal device's bootloader has been unlocked. If the bootloader is unlocked, it indicates that the terminal device is at risk of being rooted, meaning the terminal device itself is untrusted. Furthermore, the terminal device's status information may also include whether the integrity information of the terminal device's system partition has been modified. If the integrity information of the system partition has been modified, it indicates that the terminal device is at risk of being rooted, meaning the terminal device itself is untrusted.

[0072] Optionally, in the Android system, the aforementioned system partition can be the boot partition of the terminal device, and the integrity information can be information from the verify boot process.

[0073] Optionally, the identifier of the terminal device included in the second information set may be the actual identifier of the terminal device.

[0074] Since the root certificate public-private key pair of the terminal device is implemented based on the one-device-one-key mechanism, in other words, each terminal device corresponds to a unique root certificate public-private key pair. Therefore, when the server verifies the second signature, it needs to obtain the identifier of the terminal device. However, if the trusted application provides the real identifier of the terminal device, it may cause user privacy issues. Therefore, the trusted application does not provide the real identifier of the terminal device, but an anonymous identifier.

[0075] Optionally, the anonymous identifier of the terminal device is generated based on a one-device-one-key mechanism. In other words, for terminal devices of the same model, trusted applications can use the same encryption key to generate their respective anonymous identifiers.

[0076] Optionally, the anonymous identifier of the terminal device can also be generated based on a mechanism of one key per multiple device models or one key per vendor, and this application does not impose any restrictions on this.

[0077] Optionally, the true identifier of the terminal device is stored in a trusted execution environment, such as in the RPMB of the trusted execution environment. When the identifier of the terminal device is an anonymous identifier of the terminal device, the trusted application can retrieve the true identifier of the terminal device from the trusted execution environment, such as the RPMB, and determine the model of the terminal device; further determine the encryption key corresponding to the model; add a second random salt to the true identifier of the terminal device to obtain the sum; and encrypt the sum using the encryption key to obtain the anonymous identifier of the terminal device.

[0078] Optionally, the trusted application can encrypt the addition result using a pre-built symmetric or asymmetric encryption algorithm. The symmetric encryption algorithm can be, but is not limited to, the Advanced Encryption Standard (AES) algorithm. The asymmetric encryption algorithm can be, but is not limited to, encryption algorithms such as RSA, ECC, SM2, and SM1.

[0079] S206: A trusted application signs the first information set and the second information set using the private key in the public-private key pair of the secondary certificate to obtain the first signature;

[0080] Optionally, when a trusted application signs the first and second information sets using the private key in the public-private key pair of the secondary certificate, it may use the SHA256+RSA algorithm to sign, but is not limited to this.

[0081] For example, a trusted application can first apply the SHA256 algorithm to the first information set and the second information set to obtain the hash values ​​corresponding to the first information set and the second information set, and then sign the hash value using the private key in the public-private key pair of the secondary certificate to obtain the first signature.

[0082] S207: Trusted applications use the root certificate private key of the terminal device to sign the first public key in the public-private key pair of the secondary certificate to obtain the second signature;

[0083] Optionally, when a trusted application signs the first public key in the public-private key pair of the secondary certificate using the root certificate private key of the terminal device, it may use the SHA256+RSA algorithm to implement the signature, but is not limited to this.

[0084] For example, a trusted application can first apply the SHA256 algorithm to the first public key to obtain the hash value corresponding to the first public key, and then sign the first public key with the root certificate private key to obtain the second signature.

[0085] Optionally, the root certificate public-private key pair of the terminal device can be generated using the RSA algorithm, which can be a 2048-bit or 4096-bit RSA algorithm, ECC or SM2, etc., but is not limited to these.

[0086] S208: The trusted application sends a first information set, a second information set, a first public key, a first signature, and a second signature to the mobile device integrity verification module;

[0087] It should be understood that the information packet consisting of the first information set, the second information set, the first public key, the first signature, and the second signature can be called the signature verification information packet.

[0088] Optionally, the root certificate private key of the terminal device can be burned into the terminal device.

[0089] For example, Figure 4 This is a schematic diagram of the signature verification information package provided in the embodiments of this application, as shown below. Figure 4 As shown, the signature verification information package includes: the signature of the third-party application, the package name-version number of the third-party application, the first random salt, the version number of the mobile device integrity verification module, the status information of the terminal device, the identifier of the terminal device, the module-version number of the trusted execution environment, the first signature, the first public key and the second signature.

[0090] S209: The mobile device integrity verification module sends a first information set, a second information set, a first public key, a first signature, and a second signature to a third-party application;

[0091] S210: The mobile device integrity verification module sends a first information set, a second information set, a first public key, a first signature, and a second signature to the application server corresponding to the third-party application;

[0092] S211: The application server checks the validity of the second signature;

[0093] S212: If the second signature is valid, the application server checks the validity of the first signature using the first public key;

[0094] S213: If the first signature is valid, the application server checks the validity of each piece of information in the first information set and the second information set;

[0095] S214: If all information in the first information set and the second information set is valid, then the application server determines that the operating environment is trustworthy;

[0096] S215: If the first signature is invalid, the second signature is invalid, or at least one piece of information in the first information set and the second information set is invalid, the application server determines that the operating environment is untrustworthy.

[0097] Optionally, after obtaining the first information set, the second information set, the first public key, the first signature, and the second signature, the application server needs to check the legality of the second signature and the first signature. If both are legal, it indicates that the first information set and the second information set protected by the first public key are complete. Further, the application server checks the legality of the first information set and the second information set. Only when all information in the first information set and the second information set is legal is the operating environment of the third-party application determined to be trustworthy. If the first signature is invalid, the second signature is invalid, or at least one piece of information in the first information set and the second information set is invalid, the operating environment of the third-party application is determined to be untrustworthy.

[0098] It should be understood that the detection method provided in this application is a decentralized detection method. In other words, it is not necessary to use the root certificate verification server to verify the second signature every time, as detailed below:

[0099] Figure 5 An interactive flowchart of another application runtime environment trustworthiness detection method provided in this application embodiment, wherein S211 includes:

[0100] S510: The application server detects whether the application server locally stores the identifier of the terminal device and the second public key of the secondary certificate corresponding to the terminal device;

[0101] S520-a: If the application server's local storage terminal device identifier and the first public key and the second public key are consistent, then the application server determines that the second signature is valid;

[0102] S520-b: If the application server does not store the terminal device identifier locally or the first public key and the second public key are inconsistent, the application server sends the terminal device identifier, the first public key and the second signature to the root certificate verification server.

[0103] S530-b: The root certificate verification server checks the legitimacy of the second signature based on the terminal device's identifier, the first public key, and the second signature;

[0104] S540-b: The application server receives an instruction message from the root certificate verification server, which is used to indicate the validity of the second signature.

[0105] Optionally, for the first time obtained terminal device identifier, the application server can send the terminal device identifier and the second signature to the root certificate verification server. Since the root certificate verification server locally stores the root certificate public key of the terminal device, and since the root certificate public and private key pair of the terminal device is implemented based on the one-device-one-key mechanism, the root certificate verification server determines the root certificate public key based on the terminal device identifier, and verifies the second label using the root certificate public key.

[0106] Optionally, the identifier of the terminal device obtained by the application server can be either the real identifier of the terminal device or an anonymous identifier. If it is the real identifier of the terminal device, the root certificate verification server can directly determine the root certificate public key based on the real identifier of the terminal device, because the root certificate verification server locally stores the correspondence between the real identifier of the terminal device and the root certificate public key. If it is an anonymous identifier of the terminal device, the root certificate verification server needs to decrypt the anonymous identifier to obtain the real identifier of the terminal device, and further determine the root certificate public key based on the real identifier of the terminal device.

[0107] Optionally, the root certificate verification server stores the decryption key corresponding to the terminal device model. Based on this, after the root certificate verification server obtains the anonymous identifier of the terminal device, it can determine the model of the terminal device and determine the decryption key corresponding to the model of the terminal device according to the correspondence between the model and the decryption key stored locally. The anonymous identifier of the terminal device is decrypted using the decryption key to obtain the real identifier of the terminal device.

[0108] Optionally, when the terminal device's identifier is an anonymous identifier, the application server can send the Trusted Execution Environment (TEE) module-version number to the root certificate verification server. Since the TEE module-version number includes the terminal device's model, the root certificate verification server can determine the terminal device's model through the TEE module-version number, thereby determining the decryption key corresponding to that model. In turn, it can decrypt the anonymous identifier of the terminal device to obtain the terminal device's true identifier.

[0109] It should be understood that if the trusted application uses a symmetric encryption algorithm to identify the true identity of the terminal device, then the decryption key here is the same encryption key used by the trusted application to identify the true identity of the terminal device. If the trusted application uses an asymmetric encryption algorithm to identify the true identity of the terminal device, then when the trusted application encrypts the true identity of the terminal device using the public key of a certain key pair, the decryption key here is the private key of that key pair.

[0110] Optionally, if the second signature is obtained using the SHA256+RSA algorithm, the root certificate verification server can first verify the second signature using the root certificate private key to obtain a hash value. Then, the root certificate verification server can sign the first public key using SHA256 to obtain a hash value. Compare the two hash values. If the two hash values ​​are the same, it means that the second signature is valid; otherwise, it means that the second signature is invalid.

[0111] Optionally, if the application server does not store the terminal device identifier and the second public key locally, it stores the terminal device identifier and the first public key locally after the indication message indicates that the second signature is valid. Based on this, in subsequent processes, if the application server stores the terminal device identifier locally and the first and second public keys match, it indicates that the second signature is valid, because the second signature has been verified by the root certificate verification server.

[0112] Optionally, if the first signature is obtained using the SHA256+RSA algorithm, the application server can first verify the first signature using the first public key to obtain a hash value. Then, the application server can sign the first information set and the second information set using SHA256 to obtain a hash value. Compare the two hash values. If the two hash values ​​are the same, it means that the first signature is valid; otherwise, it means that the first signature is invalid.

[0113] Optionally, the application server may detect the legality of each piece of information in the first and second information sets in the following ways, but is not limited to these:

[0114] Optionally, if the first information set includes the signature of a third-party application, then since the signature of the terminal device is normally generated by the application server, the application server can obtain the correct signature of the third-party application. Furthermore, it can compare the correct signature of the third-party application with the signatures of the third-party applications included in the first information set. If the two match, it indicates that the signature of the third-party application is valid. If the two do not match, it indicates that the signature of the third-party application is invalid.

[0115] It should be understood that if the signature of a third-party application is invalid, it means that the third-party application is invalid, and therefore the operating environment of the third-party application is untrustworthy.

[0116] Optionally, if the first information set includes the package name and version number of a third-party application, and the application server can obtain the package name and version number of the vulnerable third-party application, it can further compare the package name and version number of the vulnerable third-party application with the package name and version number of the third-party applications included in the first information set. If they match, it indicates that the package name and version number of the third-party application is invalid. If they do not match, it indicates that the package name and version number of the third-party application is valid.

[0117] It should be understood that if the package name-version number of a third-party application is invalid, it means that the third-party application is invalid, and therefore the runtime environment of the third-party application is untrustworthy.

[0118] Optionally, if the first information set includes a first random salt, then since the random salt of a third-party application is normally generated by the application server, the application server can obtain the correct random salt of the third-party application. Furthermore, it can compare the correct random salt of the third-party application with the first random salt included in the first information set. If they match, the first random salt is valid. If they do not match, the first random salt is invalid.

[0119] It should be understood that if the first random salt is invalid, it indicates that the third-party application is invalid, thus indicating that the operating environment of the third-party application is untrustworthy.

[0120] Optionally, if the first information set includes the version number of the mobile device integrity verification module, and the application server can obtain the version number of the vulnerable mobile device integrity verification module, it can further compare the version number of the vulnerable mobile device integrity verification module with the version number of the mobile device integrity verification module included in the first information set. If they match, it indicates that the version number of the mobile device integrity verification module is invalid. If they do not match, it indicates that the version number of the mobile device integrity verification module is valid.

[0121] It should be understood that if the version number of the mobile device integrity verification module is invalid, it means that the terminal device is untrusted, which indicates that the operating environment of the third-party application is untrusted.

[0122] Optionally, if the second information set includes: the status information of the terminal device, and the application server determines through the status information of the terminal device that the bootloader of the terminal device is unlocked, or although the bootloader is not unlocked, the integrity information of the system partition of the terminal device has been modified, then the status information of the terminal device is invalid. If the application server determines through the status information of the terminal device that the bootloader of the terminal device is not unlocked, or although the bootloader is unlocked, the integrity information of the system partition of the terminal device has not been modified, then the status information of the terminal device is valid.

[0123] It should be understood that if the status information of the terminal device is invalid, it means that the terminal device is untrustworthy, thus indicating that the operating environment of the third-party application is untrustworthy.

[0124] Optionally, if the second information set includes the identifier of the terminal device, then since the application server can know the legitimate identifier of the terminal device, it can further compare the legitimate identifier of the terminal device with the identifier of the terminal device included in the second information set. If the two match, it indicates that the identifier of the terminal device is legitimate. If the two do not match, it indicates that the identifier of the terminal device is illegitimate.

[0125] It should be understood that if the terminal device's identifier is invalid, it means that the terminal device is untrustworthy, thus indicating that the operating environment of the third-party application is untrustworthy.

[0126] Optionally, if the second information set includes the module-version number of the trusted execution environment (TEE), the application server can obtain the module-version number of the vulnerable TEE. Furthermore, it can compare the module-version number of the vulnerable TEE with the module-version numbers of the TEE included in the second information set. If they match, the module-version number of the TEE is invalid. If they do not match, the module-version number of the TEE is valid.

[0127] It should be understood that if the module-version number of the trusted execution environment is invalid, it indicates that the terminal device is invalid, thus indicating that the runtime environment of the third-party application is untrusted.

[0128] Optionally, when the application server determines that both the third-party application and the terminal device are trustworthy, it determines that the operating environment of the third-party application is trustworthy; conversely, when the application server determines that the third-party application and / or the terminal device are untrustworthy, it determines that the operating environment of the third-party application is untrustworthy.

[0129] In summary, this application leverages the characteristic that code and data within a trusted execution environment cannot be cracked, modified, or obtained from external sources. Trusted applications within this environment can obtain information related to the runtime environment of third-party applications and transmit this information to the server after encryption or signing using asymmetric encryption algorithms. This information can only be verified on the server side, reducing the probability of tampering and thus making the detection of the trustworthiness of the third-party application's runtime environment more accurate. For payment or financial applications, when the technical solution provided in this application detects that the runtime environment of a third-party application is untrustworthy, the user can be prompted to prohibit payment, ensuring that the third-party application runs in a trusted environment. For gaming applications, illegal activities such as cheating or resource exploitation often unlock the bootloader of the terminal device. The technical solution provided in this application can detect the untrustworthiness of the third-party application's runtime environment, prohibiting these illegal activities and improving the gaming experience for legitimate players.

[0130] Meanwhile, this application provides a decentralized detection method, that is, the application server only needs to go to the root certificate verification server to verify the second signature when it first verifies the second signature. After that, the application server can complete the verification of the second signature itself based on the identifier of the terminal device stored locally and the second public key of the secondary certificate. This can effectively protect the application server's own business secrets, such as the DAU data of third-party applications.

[0131] Furthermore, in this application, both the root certificate public / private key pair and the secondary certificate public / private key pair of the terminal device are implemented based on a one-device-one-key mechanism. Therefore, if the trusted execution environment of a certain terminal device is compromised, it will not significantly affect other devices of the same model or even all related devices, thus providing good security. In addition, the anonymous identifier of the terminal device is generated based on a one-device-one-key mechanism, thereby improving user privacy and security.

[0132] It should be noted that this application can also adopt a centralized detection method. That is, after the application server obtains the signature verification information packet, it can send the signature verification information packet to the root certificate signature verification server. The root certificate signature verification server can directly detect the legality of the second signature, the first signature, and the information in the first information set and the second information set. For specific detection methods, please refer to the detection method of the application server mentioned above. This application will not elaborate on this.

[0133] This application also provides a trustworthiness detection system for an application runtime environment, comprising: a terminal device and an application server. The terminal device includes: a third-party application corresponding to the application server, a mobile device integrity verification module, and a trusted application corresponding to the trusted execution environment. The third-party application sends a request message to the mobile device integrity verification module. The mobile device integrity verification module responds to the request message by obtaining a first information set and sending the first information set to the trusted application. The first information set is an information set used to detect the trustworthiness of the runtime environment of the third-party application. The trusted application generates a public-private key pair for a secondary certificate corresponding to the third-party application; obtains a second information set, which is an information set used to detect the trustworthiness of the runtime environment; and signs the first and second information sets using the private key in the public-private key pair of the secondary certificate. The system obtains a first signature; it then signs the first public key in the secondary certificate's public-private key pair using the root certificate private key of the terminal device to obtain a second signature; and finally, it sends a first information set, a second information set, a first public key, the first signature, and the second signature to the application server corresponding to the third-party application through the mobile device integrity verification module and the third-party application. The application server is used to: check the legality of the second signature; if the second signature is legal, then check the legality of the first signature using the first public key; if the first signature is legal, then check the legality of each piece of information in the first and second information sets; if all pieces of information in the first and second information sets are legal, then the operating environment is determined to be trustworthy; if the first signature is invalid, the second signature is invalid, or at least one piece of information in the first and second information sets is invalid, then the operating environment is determined to be untrustworthy.

[0134] Optionally, the trusted application is also used to: determine the real identifier of the terminal device and the model of the terminal device; determine the encryption key corresponding to the model; add a second random salt to the real identifier of the terminal device to obtain the sum; encrypt the sum using the encryption key to obtain the anonymous identifier of the terminal device; wherein the second information set includes the anonymous identifier of the terminal device.

[0135] Optionally, the application server is specifically used to: detect whether the application server locally stores the identifier of the terminal device and the second public key of the secondary certificate corresponding to the terminal device; if the application server locally stores the identifier of the terminal device and the first public key and the second public key are consistent, then the second signature is determined to be valid; if the application server locally does not store the identifier of the terminal device or the first public key and the second public key are inconsistent, then the application server sends the identifier of the terminal device, the first public key and the second signature to the root certificate verification server; the root certificate verification server is used to detect the validity of the second signature based on the identifier of the terminal device, the first public key and the second signature; the application server receives an indication message from the root certificate verification server, the indication message being used to indicate the validity of the second signature.

[0136] Optionally, the application server is further configured to: if the application server does not store the identifier of the terminal device and the second public key locally, then after the indication message indicates that the second signature is valid, store the identifier of the terminal device and the first public key locally.

[0137] Optionally, the identifier of the terminal device is an anonymous identifier of the terminal device; correspondingly, the application server is also used to send the module-version number of the trusted execution environment to the root certificate verification server; the root certificate verification server is specifically used to: detect the legitimacy of the second signature based on the identifier of the terminal device, the module-version number of the trusted execution environment, the first public key and the second signature.

[0138] Optionally, the root certificate verification server is specifically used for: determining the terminal device model based on the module-version number of the trusted execution environment; determining the decryption key corresponding to the model; decrypting the anonymous identifier of the terminal device using the decryption key to obtain the real identifier of the terminal device; determining the root certificate public key of the terminal device based on the real identifier of the terminal device; and verifying the legitimacy of the second signature using the root certificate public key and the first public key.

[0139] Optionally, the third-party application is also used to obtain the first random salt corresponding to the third-party application from the application server; correspondingly, the first information set includes: the first random salt.

[0140] The application runtime environment reliability detection system provided in this application can be used in the above method embodiments, and will not be described in detail here for the sake of brevity.

[0141] Figure 6 This is a schematic diagram of a terminal device 600 provided in an embodiment of this application, as shown below. Figure 6 As shown, the terminal device 600 includes: a third-party application 610, a mobile device integrity verification module 620, and a trusted application 630 corresponding to a trusted execution environment. The third-party application 610 is used to send a request message to the mobile device integrity verification module 620; the mobile device integrity verification module 620 is used to respond to the request message, obtain a first information set, and send the first information set to the trusted application. The first information set is an information set used to detect the trustworthiness of the runtime environment of the third-party application 610; the trusted application 630 is used to: generate a public-private key pair for a secondary certificate corresponding to the third-party application 610; and obtain a second information set, the second information set being used to detect... The system generates a set of information to test the trustworthiness of the operating environment; it signs the first and second information sets using the private key in the public-private key pair of the secondary certificate to obtain a first signature; it signs the first public key in the public-private key pair of the secondary certificate using the private key of the root certificate of the terminal device to obtain a second signature; and it sends the first information set, the second information set, the first public key, the first signature, and the second signature to the application server corresponding to the third-party application 610 through the mobile device integrity verification module 620 and the third-party application 610, so that the application server can detect the trustworthiness of the operating environment of the third-party application based on the first information set, the second information set, the first public key, the first signature, and the second signature.

[0142] Optionally, the first information set includes at least one of the following: the signature of the third-party application, the package name-version number of the third-party application, the first random salt corresponding to the third-party application, and the version number of the mobile device integrity verification module.

[0143] Optionally, the third-party application 610 is further configured to: obtain a first random salt from the application server before sending a request message to the mobile device integrity verification module 620; correspondingly, the request message includes: the first random salt.

[0144] Optionally, the second set of information includes at least one of the following: the status information of the terminal device, the identifier of the terminal device, and the module-version number of the trusted execution environment; wherein, the module-version number of the trusted execution environment includes: the model of the terminal device and the version number of the trusted execution environment.

[0145] Optionally, the identifier of the terminal device is an anonymous identifier of the terminal device; Trusted Application 630 is also used to: determine the real identifier of the terminal device and the model of the terminal device; determine the encryption key corresponding to the model; add a second random salt to the real identifier of the terminal device to obtain the sum; and encrypt the sum using the encryption key to obtain the anonymous identifier of the terminal device.

[0146] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be found in the method embodiments. To avoid repetition, further details are omitted here. Specifically, Figure 6 The terminal device 600 shown can execute the method steps corresponding to the terminal device in the above method embodiments. The aforementioned and other operations and / or functions of each module in the terminal device 600 are for implementing the method steps corresponding to the terminal device in the above method embodiments. For the sake of brevity, they will not be described in detail here.

[0147] The terminal device 600 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0148] Figure 7 A schematic diagram of an application server 700 provided in an embodiment of this application is shown below. Figure 7 As shown, the application server 700 includes a receiving module 710 and a detection module 720. The receiving module 710 is used to receive a first information set, a second information set, a first public key, a first signature, and a second signature from the public-private key pair of the secondary certificate of the terminal device, all from a third-party application. Both the first and second information sets are information sets used to detect the trustworthiness of the operating environment. The first signature is obtained by a trusted application corresponding to the trusted execution environment in the terminal device signing the first and second information sets using the private key from the public-private key pair of the secondary certificate. The second signature is obtained by a trusted application signing the first public key using the private key of the root certificate of the terminal device. The detection module 720 is used to: detect the legality of the second signature; if the second signature is legal, then detect the legality of the first signature using the first public key; if the first signature is legal, then detect the legality of each piece of information in the first and second information sets; if all pieces of information in the first and second information sets are legal, then the operating environment is determined to be trustworthy; if the first signature is invalid, the second signature is invalid, or at least one piece of information in the first and second information sets is invalid, then the operating environment is determined to be untrustworthy.

[0149] Optionally, the first information set includes at least one of the following: the signature of the third-party application, the package name-version number of the third-party application, the first random salt corresponding to the third-party application, and the version number of the mobile device integrity verification module.

[0150] Optionally, the second set of information includes at least one of the following: the status information of the terminal device, the identifier of the terminal device, and the module-version number of the trusted execution environment; wherein, the module-version number of the trusted execution environment includes: the model of the terminal device and the version number of the trusted execution environment.

[0151] Optionally, the detection module 720 is specifically used to: detect whether the application server locally stores the identifier of the terminal device and the second public key of the secondary certificate corresponding to the terminal device; if the application server locally stores the identifier of the terminal device and the first public key and the second public key are consistent, then the second signature is determined to be valid; if the application server locally does not store the identifier of the terminal device or the first public key and the second public key are inconsistent, then the application server sends the identifier of the terminal device, the first public key and the second signature to the root certificate verification server; so that the root certificate verification server can detect the validity of the second signature based on the identifier of the terminal device, the first public key and the second signature; the receiving module 710 is also used to receive an indication message from the root certificate verification server, the indication message being used to indicate the validity of the second signature.

[0152] Optionally, the identifier of the terminal device is an anonymous identifier of the terminal device; the application server 700 further includes: a sending module 730, used to send the module-version number of the trusted execution environment to the root certificate verification server, so that the root certificate verification server can detect the legitimacy of the second signature based on the identifier of the terminal device, the module-version number of the trusted execution environment, the first public key and the second signature.

[0153] Optionally, the application server 700 further includes a storage module 740, which stores the terminal device's identifier and the first public key locally if the application server does not store the terminal device's identifier and the second public key locally after an indication message indicates that the second signature is valid.

[0154] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be found in the method embodiments. To avoid repetition, further details are omitted here. Specifically, Figure 7 The application server 700 shown can execute the method steps corresponding to the application server in the above method embodiments. The aforementioned and other operations and / or functions of each module in the application server 700 are for implementing the method steps corresponding to the application server in the above method embodiments. For the sake of brevity, they will not be described in detail here.

[0155] The application server 700 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. Optionally, the software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0156] Figure 8 A schematic diagram of a root certificate verification server 800 provided in this application embodiment is shown below. Figure 8 As shown, the root certificate verification server 800 includes a receiving module 810 and a detection module 820. The receiving module 810 is used to receive the identifier of the terminal device, the first public key and the second signature in the public-private key pair of the terminal device's secondary certificate from the application server. The detection module 820 is used to detect the legality of the second signature based on the identifier of the terminal device, the first public key and the second signature. The second signature is obtained by a trusted application corresponding to the trusted execution environment of the terminal device signing the first public key with the root certificate private key of the terminal device.

[0157] Optionally, the identifier of the terminal device is an anonymous identifier of the terminal device; correspondingly, the receiving module 810 is also used to: receive the module-version number of the trusted execution environment; the detection module 820 is specifically used to: detect the legality of the second signature based on the identifier of the terminal device, the module-version number of the trusted execution environment, the first public key and the second signature.

[0158] Optionally, the detection module 820 is specifically used for: determining the model of the terminal device based on the module-version number of the trusted execution environment; determining the decryption key corresponding to the model; decrypting the anonymous identifier of the terminal device using the decryption key to obtain the real identifier of the terminal device; determining the root certificate public key of the terminal device based on the real identifier of the terminal device; and detecting the legality of the second signature using the root certificate public key and the first public key.

[0159] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be found in the method embodiments. To avoid repetition, further details are omitted here. Specifically, Figure 8The root certificate verification server 800 shown can execute the method steps corresponding to the root certificate verification server in the above method embodiments. The aforementioned and other operations and / or functions of each module in the root certificate verification server 800 are respectively for implementing the method steps corresponding to the root certificate verification server in the above method embodiments. For the sake of brevity, they will not be described in detail here.

[0160] The root certificate verification server 800 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application embodiment can be completed by integrated logic circuits in the processor hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0161] Figure 9 This is a schematic block diagram of an electronic device provided in the embodiments of this application. The electronic device may be a terminal device, an application server, or a root certificate verification server in the above method embodiments.

[0162] like Figure 9 As shown, the electronic device may include:

[0163] The system includes a memory 910 and a processor 920. The memory 910 stores computer programs and transfers the program code to the processor 920. In other words, the processor 920 can retrieve and run the computer program from the memory 910 to implement the methods described in the embodiments of this application.

[0164] For example, the processor 920 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0165] In some embodiments of this application, the processor 920 may include, but is not limited to:

[0166] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0167] In some embodiments of this application, the memory 910 includes, but is not limited to:

[0168] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0169] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 910 and executed by the processor 920 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0170] like Figure 9 As shown, the electronic device may further include:

[0171] Transceiver 930, which can be connected to processor 920 or memory 910.

[0172] The processor 920 can control the transceiver 930 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 930 may include a transmitter and a receiver. The transceiver 930 may further include antennas, and the number of antennas may be one or more.

[0173] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0174] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0175] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0176] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0177] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0178] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0179] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for detecting the reliability of an application runtime environment, characterized in that, include: A third-party application in a terminal device sends a request message to the mobile device integrity verification module in the terminal device. The mobile device integrity verification module responds to the request message to obtain a first information set, which is an information set used to detect the trustworthiness of the third-party application's operating environment. The mobile device integrity verification module sends the first information set to the trusted application corresponding to the trusted execution environment in the terminal device. The trusted application generates a public / private key pair for the secondary certificate of the third-party application; The trusted application acquires a second information set, which is an information set used to detect the trustworthiness of the operating environment; The trusted application signs the first information set and the second information set using the private key in the public-private key pair of the secondary certificate to obtain a first signature; The trusted application uses the root certificate private key of the terminal device to sign the first public key in the public-private key pair of the secondary certificate to obtain the second signature. The trusted application sends the first information set, the second information set, the first public key, the first signature, and the second signature to the application server corresponding to the third-party application through the mobile device integrity verification module and the third-party application. The application server checks the validity of the second signature; If the second signature is valid, the application server checks the validity of the first signature using the first public key; If the first signature is valid, the application server checks the validity of each piece of information in the first information set and the second information set; If all information in the first information set and the second information set is valid, then the application server determines that the operating environment is trustworthy. If the first signature is invalid, the second signature is invalid, or at least one piece of information in the first information set and the second information set is invalid, then the application server determines that the operating environment is untrustworthy.

2. The method according to claim 1, characterized in that, Also includes: The trusted application determines the true identity of the terminal device and the model of the terminal device; The trusted application determines the encryption key corresponding to the device model; The trusted application adds a second random salt to the real identifier of the terminal device to obtain the summation result; The trusted application encrypts the addition result using the encryption key to obtain the anonymous identifier of the terminal device; The second information set includes the anonymous identifier of the terminal device.

3. The method according to claim 1 or 2, characterized in that, The application server detects the validity of the second signature, including: The application server detects whether it locally stores the identifier of the terminal device and the second public key of the secondary certificate corresponding to the terminal device; If the application server locally stores the identifier of the terminal device and the first public key and the second public key are consistent, then the application server determines that the second signature is valid; If the application server does not store the identifier of the terminal device locally or the first public key and the second public key are inconsistent, the application server sends the identifier of the terminal device, the first public key and the second signature to the root certificate verification server. The root certificate verification server detects the legitimacy of the second signature based on the identifier of the terminal device, the first public key, and the second signature; The application server receives an indication message from the root certificate verification server, the indication message being used to indicate the legality of the second signature.

4. The method according to claim 3, characterized in that, Also includes: If the application server does not store the identifier of the terminal device and the second public key locally, the application server will store the identifier of the terminal device and the first public key locally after the indication message indicates that the second signature is valid.

5. The method according to claim 3, characterized in that, The identifier of the terminal device is an anonymous identifier of the terminal device; correspondingly, the method further includes: The application server sends the module-version number of the trusted execution environment to the root certificate verification server; The root certificate verification server checks the validity of the second signature based on the identifier of the terminal device, the first public key, and the second signature, including: The root certificate verification server detects the legitimacy of the second signature based on the identifier of the terminal device, the module-version number of the trusted execution environment, the first public key, and the second signature.

6. The method according to claim 5, characterized in that, The root certificate verification server checks the validity of the second signature based on the identifier of the terminal device, the module-version number of the trusted execution environment, the first public key, and the second signature, including: The root certificate verification server determines the model of the terminal device based on the module-version number of the trusted execution environment; The root certificate verification server determines the decryption key corresponding to the device model. The root certificate verification server decrypts the anonymous identifier of the terminal device using the decryption key to obtain the real identifier of the terminal device; The root certificate verification server determines the root certificate public key of the terminal device based on the real identifier of the terminal device. The root certificate verification server uses the root certificate public key and the first public key to detect the legitimacy of the second signature.

7. The method according to claim 1 or 2, characterized in that, Before the third-party application in the terminal device sends a request message to the mobile device integrity verification module in the terminal device, it also includes: The third-party application obtains the first random salt corresponding to the third-party application from the application server; Accordingly, the first information set includes: the first random salt.

8. A method for detecting the reliability of an application runtime environment, characterized in that, include: A third-party application in a terminal device sends a request message to the mobile device integrity verification module in the terminal device. The mobile device integrity verification module responds to the request message to obtain a first information set, which is an information set used to detect the trustworthiness of the third-party application's operating environment. The mobile device integrity verification module sends the first information set to the trusted application corresponding to the trusted execution environment in the terminal device. The trusted application generates a public / private key pair for the secondary certificate of the third-party application; The trusted application acquires a second information set, which is an information set used to detect the trustworthiness of the operating environment; The trusted application signs the first information set and the second information set using the private key in the public-private key pair of the secondary certificate to obtain a first signature; The trusted application uses the root certificate private key of the terminal device to sign the first public key in the public-private key pair of the secondary certificate to obtain the second signature. The trusted application sends the first information set, the second information set, the first public key, the first signature, and the second signature to the application server corresponding to the third-party application through the mobile device integrity verification module and the third-party application, so that the application server can detect the trustworthiness of the operating environment based on the first information set, the second information set, the first public key, the first signature, and the second signature.

9. The method according to claim 8, characterized in that, Also includes: The trusted application determines the true identity of the terminal device and the model of the terminal device; The trusted application determines the encryption key corresponding to the device model; The trusted application adds a second random salt to the real identifier of the terminal device to obtain the summation result; The trusted application encrypts the addition result using the encryption key to obtain the anonymous identifier of the terminal device; The second information set includes the anonymous identifier of the terminal device.

10. A method for detecting the reliability of an application runtime environment, characterized in that, include: The application server receives a first information set, a second information set, a first public key, a first signature, and a second signature from a public-private key pair of a secondary certificate from a third-party application. The first information set is obtained as follows: a third-party application in the terminal device sends a request message to the mobile device integrity verification module in the terminal device; the mobile device integrity verification module responds to the request message to obtain the first information set; the mobile device integrity verification module sends the first information set to the trusted application corresponding to the trusted execution environment in the terminal device; the first information set is an information set used to detect the trustworthiness of the third-party application's running environment. The secondary certificate public-private key pair is a public-private key pair generated by the trusted application that corresponds to the third-party application; The second information set is obtained by the trusted application and is used to detect the trustworthiness of the third-party application's operating environment. The first signature is obtained by the trusted application signing the first information set and the second information set using the private key in the public-private key pair of the secondary certificate; The second signature is obtained by the trusted application signing the first public key using the root certificate private key of the terminal device; The application server checks the validity of the second signature; If the second signature is valid, the application server checks the validity of the first signature using the first public key; If the first signature is valid, the application server checks the validity of each piece of information in the first information set and the second information set; If all information in the first information set and the second information set is valid, then the application server determines that the operating environment is trustworthy. If the first signature is invalid, the second signature is invalid, or at least one piece of information in the first information set and the second information set is invalid, then the application server determines that the operating environment is untrustworthy.

11. The method according to claim 10, characterized in that, The application server detects the validity of the second signature, including: The application server detects whether it locally stores the identifier of the terminal device and the second public key of the secondary certificate corresponding to the terminal device; If the application server locally stores the identifier of the terminal device and the first public key and the second public key are consistent, then the application server determines that the second signature is valid; If the application server does not store the identifier of the terminal device locally or the first public key and the second public key are inconsistent, the application server sends the identifier of the terminal device, the first public key, and the second signature to the root certificate verification server so that the root certificate verification server can detect the legality of the second signature based on the identifier of the terminal device, the first public key, and the second signature. The application server receives an indication message from the root certificate verification server, the indication message being used to indicate the legality of the second signature.

12. A reliability testing system for an application operating environment, characterized in that, include: The terminal device includes: a third-party application corresponding to the application server, a mobile device integrity verification module, and a trusted application corresponding to the trusted execution environment. The third-party application is used to send a request message to the mobile device integrity verification module; The mobile device integrity verification module is used to respond to the request message, obtain a first information set, and send the first information set to the trusted application. The first information set is an information set used to detect the trustworthiness of the third-party application's operating environment. The trusted application is used for: Generate the public / private key pair for the secondary certificate of the third-party application; Obtain a second information set, which is an information set used to detect the trustworthiness of the operating environment; The first signature is obtained by signing the first information set and the second information set using the private key in the public-private key pair of the secondary certificate. The second signature is obtained by signing the first public key in the public-private key pair of the secondary certificate using the private key of the root certificate of the terminal device. The mobile device integrity verification module and the third-party application send the first information set, the second information set, the first public key, the first signature, and the second signature to the application server corresponding to the third-party application. The application server is used for: Verify the validity of the second signature; If the second signature is valid, then the validity of the first signature is checked using the first public key; If the first signature is valid, then check the validity of each piece of information in the first information set and the second information set; If all information items in the first information set and the second information set are valid, then the operating environment is determined to be trustworthy. If the first signature is invalid, the second signature is invalid, or at least one piece of information in the first information set and the second information set is invalid, then the operating environment is determined to be untrustworthy.

13. A terminal device, characterized in that, include: Trusted applications corresponding to third-party applications, mobile device integrity verification modules, and trusted execution environments; The third-party application is used to send a request message to the mobile device integrity verification module; The mobile device integrity verification module is used to respond to the request message, obtain a first information set, and send the first information set to the trusted application. The first information set is an information set used to detect the trustworthiness of the third-party application's operating environment. The trusted application is used for: Generate the public / private key pair for the secondary certificate of the third-party application; Obtain a second information set, which is an information set used to detect the trustworthiness of the operating environment; The first signature is obtained by signing the first information set and the second information set using the private key in the public-private key pair of the secondary certificate. The second signature is obtained by signing the first public key in the public-private key pair of the secondary certificate using the private key of the root certificate of the terminal device. The mobile device integrity verification module and the third-party application send the first information set, the second information set, the first public key, the first signature, and the second signature to the application server corresponding to the third-party application, so that the application server can detect the trustworthiness of the operating environment based on the first information set, the second information set, the first public key, the first signature, and the second signature.

14. An application server, characterized in that, include: The receiving module is used to receive a first information set, a second information set, a first public key, a first signature, and a second signature from a public-private key pair of a secondary certificate from a third-party application. The first information set is obtained as follows: a third-party application in the terminal device sends a request message to the mobile device integrity verification module in the terminal device; the mobile device integrity verification module responds to the request message to obtain the first information set; the mobile device integrity verification module sends the first information set to the trusted application corresponding to the trusted execution environment in the terminal device; the first information set is an information set used to detect the trustworthiness of the third-party application's running environment. The secondary certificate public-private key pair is a public-private key pair generated by the trusted application that corresponds to the third-party application; The second information set is obtained by the trusted application and is used to detect the trustworthiness of the third-party application's operating environment. The first signature is obtained by the trusted application signing the first information set and the second information set using the private key in the public-private key pair of the secondary certificate; The second signature is obtained by the trusted application signing the first public key using the root certificate private key of the terminal device; The detection module is used for: Verify the validity of the second signature; If the second signature is valid, then the validity of the first signature is checked using the first public key; If the first signature is valid, then check the validity of each piece of information in the first information set and the second information set; If all information items in the first information set and the second information set are valid, then the operating environment is determined to be trustworthy. If the first signature is invalid, the second signature is invalid, or at least one piece of information in the first information set and the second information set is invalid, then the operating environment is determined to be untrustworthy.

15. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method of any one of claims 1 to 11.

16. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 11.

Images