Fine-grained security access control method and system for trusted application, computer equipment and medium

Abstract

The invention discloses a fine-grained security access control method and system for a trusted application, computer equipment and a medium, and the method comprises the steps: an application developer randomly generates an application signature voucher, and applies for the access authority of the trusted application from a background server of a terminal equipment manufacturer; receiving an authorization signature of the trusted application returned by the background server of the terminal equipment manufacturer; making and issuing an application installation package containing authorization information; when the current APP calls the trusted application, an access authorization verification program of the trusted application is triggered, a system server of the terminal equipment verifies the authorization signature by using a background server public key of a terminal equipment manufacturer preset in the application installation package, the trusted application is called after verification is passed, and the access process of the trusted application is completed. According to the invention, flexible authorization, accurate shielding and dynamic adaptation of the application to access the trusted application can be realized, and the security protection capability and the service adaptation efficiency of the terminal equipment are improved.

Description

Technical Field

[0001] This invention relates to the field of application security access technology, and in particular to a fine-grained security access control method, system, computer device, and medium for trusted applications. Background Technology

[0002] With the rapid development of mobile internet and smart terminals, users are performing increasingly sensitive operations on terminal devices (such as payments, logins, and data encryption), leading to ever-increasing demands for business security. Trusted Execution Environments (TEEs), as independent secure zones within terminal devices, provide an isolated execution environment for sensitive code and data, ensuring they are not tampered with or stolen by malicious software during execution. This has become one of the core technologies for terminal security. In the TEE architecture, applications running within the TEE are called Trusted Applications (TAs), responsible for handling core sensitive logic (such as key generation, encryption operations, and payment verification). Applications running in Rich Execution Environments (REEs) are called Client Applications (CAs), requesting TA services by calling the interfaces provided by the TEE. The Original Equipment Manufacturer (OEM) is responsible for providing the underlying support for the TEE, TAs, and the Device OS. Its backend server (OEMServer) manages application deployment, permission configuration, and other business processes.

[0003] In the existing technology, there are two main schemes for access control of CA to TA: trusted application inspection scheme and terminal system inspection scheme. Although these two schemes can achieve basic access control, they have the following significant defects in practical applications and are difficult to meet the needs of terminal security and business flexibility.

[0004] Therefore, existing technologies still need improvement. Summary of the Invention

[0005] To address the aforementioned deficiencies in existing technologies, this invention provides a fine-grained security access control method, system, computer device, and medium for trusted applications. The technical solution adopted by this invention is as follows: In a first aspect, the present invention provides a fine-grained security access control method for trusted applications, the method comprising: The application developer randomly generates an application signing credential, applies to the backend server of the terminal device manufacturer for access to the trusted application, and receives the authorized signature of the trusted application returned by the backend server of the terminal device manufacturer. The application signing credential includes the application signing private key and the application signing certificate of the trusted application. Application developers create and release application installation packages containing authorization information, which includes the authorization signature of the trusted application and the public key of the backend server of the terminal device manufacturer; When the current APP calls a trusted application, the access authorization verification procedure of the trusted application is triggered. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is successful, the trusted application is called and the access process to the trusted application is completed.

[0006] In one implementation, the method further includes: If the backend server of the terminal device manufacturer receives a request to block access, it will block the trusted application access authorization program of the specified version of the APP based on the request.

[0007] In one implementation, the application developer randomly generates an application signature credential and requests access permissions for the trusted application from the backend server of the terminal device manufacturer, including: The application developer randomly generates a key pair to obtain the application signature credential; Application developers register the generated application signature credentials with the backend server of terminal device manufacturers; The backend server of the terminal equipment manufacturer randomly generates a backend server key pair, which includes the backend server private key and the backend server public key of the terminal equipment manufacturer. The application developer constructs the authorization request parameters and submits them to the terminal device manufacturer's backend server.

[0008] In one implementation, the authorization request parameters include: the application name of the trusted application, the application signing certificate, the trusted application identifier, and the range of trusted application instructions requested for access.

[0009] In one implementation, receiving the authorization signature of the trusted application returned by the backend server of the terminal device manufacturer includes: After reviewing the authorization request parameters, the terminal device manufacturer signs the authorization request parameters using its own backend server private key to obtain the authorization signature of the trusted application, and then returns the authorization signature of the trusted application to the application developer.

[0010] In one implementation, the application developer creates and releases an application installation package containing licensing information, including: Application developers embed a trusted application identifier, the scope of trusted application instructions for requesting access, an authorization signature, and the backend server public key of the terminal device manufacturer into the application binary file. Application developers use the application signing credential to sign the application binary file with embedded relevant information to obtain a trusted application signature; The application developer constructs an application installation package and publishes the application installation package to the backend server of the terminal manufacturer. The application installation package includes: an application binary file with embedded relevant information, a trusted application signature, and an application signature certificate in the application signature certificate.

[0011] In one implementation, if the backend server of the terminal device manufacturer receives a blocking access request, it blocks the trusted application access authorization program of the specified version of the APP based on the blocking access request, including: If the terminal device manufacturer's backend server receives a request to block access, it constructs the blocking request parameters. The terminal device manufacturer's backend server uses its own backend server private key to sign the blocking request parameters and generate an application blocking signature; Based on the blocking request parameters, the application blocking signature, and the backend server public key of the terminal device manufacturer, blocking information is generated; The terminal device manufacturer's backend server pushes the blocking information to the terminal device's system server, so that the terminal device's system server can verify the blocking information.

[0012] In one implementation, the blocking request parameters include: the application name of the application to be blocked, the application signing certificate, the application identifier, and the APP version information.

[0013] In one implementation, when the system server of the terminal device verifies the blocking information, it includes: Obtain the public key of the backend server of the terminal device manufacturer that is pre-installed on the system server of the terminal device at the factory; Check whether the public key of the backend server of the terminal device manufacturer in the blocking information is consistent with the public key of the backend server of the terminal device manufacturer that is preset at the factory. If they match, the system server of the terminal device uses the pre-set public key of the terminal device manufacturer's backend server to verify the application masking signature. After successful verification, the system server of the terminal device caches the blocking request parameters.

[0014] In one implementation, when the current APP calls a trusted application, the access authorization verification procedure of the trusted application is triggered, including: After the application installation package is installed on the terminal device, the current APP calls the relevant interfaces; The request executes the trusted application identifier and trusted application instructions to trigger the access authorization verification procedure of the trusted application.

[0015] In one implementation, the system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorized signature, including: The system server of the terminal device reads the authorization information from the application installation package currently installed by the APP. The system server of the terminal device checks whether the trusted application instruction currently requested for execution is in the application binary file of the application installation package; If so, the system server of the terminal device will verify whether the current APP matches the application to be blocked in the blocking request parameters; If they do not match, the terminal device's system server will check whether the backend server public key of the terminal device manufacturer embedded in the application installation package of the current APP is consistent with the backend server public key of the terminal device manufacturer that it has pre-installed. If they match, the terminal device's system server uses its own pre-installed public key from the terminal device manufacturer's backend server to verify the authorized signature.

[0016] In one implementation, after successful verification, the trusted application is invoked, and the access process to the trusted application is completed, including: After the verification is successful, the system server of the terminal device sends the trusted application identifier to the trusted execution environment to request the invocation of the corresponding trusted application; The system server of the terminal device transmits instruction parameters to the called trusted application based on the trusted execution environment, so that the trusted application executes the corresponding internal function based on the instruction parameters and obtains the execution result; The system server of the terminal device receives the execution result of the trusted application and feeds back the execution result to the current APP.

[0017] Secondly, embodiments of the present invention also provide a fine-grained security access control system for trusted applications, wherein the system is used to implement the fine-grained security access control method for trusted applications as described in any of the above solutions, and the system includes a backend server of an application developer and a terminal device manufacturer, and a system server of the terminal device. The application developers include: The access permission application module is used to randomly generate application signature credentials and apply to the backend server of the terminal device manufacturer for access permissions to trusted applications. The application signature credentials include the application signature private key and application signature certificate of the trusted application. The authorization signature receiving module is used to receive the authorization signature of the trusted application returned by the backend server of the terminal device manufacturer; The application installation package creation and publishing module is used to create and publish application installation packages containing authorization information, including the authorization signature of the trusted application and the public key of the backend server of the terminal device manufacturer. The system server for the terminal device includes: The authorization signature verification module is used to trigger the access authorization verification program of the trusted application when the current APP calls the trusted application. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is successful, the trusted application is called and the access process to the trusted application is completed.

[0018] In one implementation, the backend server of the terminal device manufacturer includes: The blocking control module is used to block the trusted application access authorization program of a specified version of the APP based on the blocking access request after receiving the blocking access request.

[0019] In one implementation, the application installation package creation and distribution module includes: The information embedding unit is used to embed the trusted application identifier, the scope of trusted application instructions requesting access, the authorization signature, and the backend server public key of the terminal device manufacturer into the application binary file. The file signing unit is used to sign the application binary file with embedded relevant information using the application signing credential to obtain a trusted application signature; The installation package construction and distribution unit is used by application developers to construct application installation packages and distribute the application installation packages to the backend server of terminal manufacturers. The application installation package includes: an application binary file with embedded relevant information, a trusted application signature, and an application signature certificate in the application signature certificate.

[0020] In one implementation, the shielding control module includes: The masking request construction unit is used to construct masking request parameters if the backend server of the terminal device manufacturer receives a masking access request. The masking signature generation unit is used to sign the masking request parameters using its own backend server private key to generate an application masking signature; The blocking information generation unit is used to generate blocking information based on the blocking request parameters, the application blocking signature, and the public key of the backend server of the terminal device manufacturer. The blocking information push unit is used to push blocking information to the system server of the terminal device so that the system server of the terminal device can verify the blocking information.

[0021] In one implementation, the authorized signature verification module includes: The authorization information reading unit is used to read the authorization information from the application installation package currently installed by the APP. The instruction checking unit is used to check whether the trusted application instruction currently requested for execution is in the application binary file of the application installation package; The blocking request parameter verification unit is used to verify, if present, whether the system server of the terminal device verifies whether the current APP matches the application to be blocked in the blocking request parameters; The public key checking unit is used to check whether the public key of the backend server of the terminal device manufacturer embedded in the application installation package of the current APP is consistent with the public key of the backend server of the terminal device manufacturer that it has pre-installed. The authorization signature verification unit is used to verify the authorization signature using the pre-installed public key of the terminal device manufacturer's backend server if the signatures match.

[0022] Thirdly, embodiments of the present invention also provide a computer device, wherein the computer device includes a memory, a processor, and a fine-grained security access control program for a trusted application stored in the memory and executable on the processor. When the processor executes the fine-grained security access control program for the trusted application, it implements the steps of the fine-grained security access control method for a trusted application of any of the above-described schemes.

[0023] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein a fine-grained security access control program for a trusted application is stored on the computer-readable storage medium, and the fine-grained security access control program for the trusted application implements the steps of the fine-grained security access control method for a trusted application as described in any of the above schemes on the computer-readable storage medium.

[0024] Beneficial Effects: Compared with existing technologies, this invention provides a fine-grained secure access control method for trusted applications. First, the application developer randomly generates an application signing credential, applies for access permissions to the trusted application from the terminal device manufacturer's backend server, and receives the authorized signature of the trusted application returned by the terminal device manufacturer's backend server. The application signing credential includes the trusted application's application signing private key and application signing certificate. Next, the application developer creates and releases an application installation package containing authorization information, including the authorized signature of the trusted application and the public key of the terminal device manufacturer's backend server. Then, when the current APP calls the trusted application, the access authorization verification procedure of the trusted application is triggered. The terminal device's system server uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorized signature. After successful verification, the trusted application is called, completing the access process to the trusted application.

[0025] This invention enables dynamic configuration of access control policies, allowing new apps to access trusted applications without system updates, thus improving business flexibility. It can adapt to business scenarios such as changes in application names and signature certificates, without relying on system OTA or patch updates, reducing maintenance costs. Furthermore, based on fine-grained access control, this invention limits the specific instructions that apps can access from trusted applications, enhancing security capabilities, and is compatible with multiple cryptographic and signature algorithms, improving the versatility and scalability of the solution. Attached Figure Description

[0026] Figure 1 This is a technical roadmap for trusted application verification schemes in existing technologies.

[0027] Figure 2 This is a technical roadmap for existing system service (SMS) inspection solutions.

[0028] Figure 3 This diagram illustrates the application environment of the fine-grained security access control method for trusted applications provided in this embodiment of the invention.

[0029] Figure 4 This is a flowchart illustrating a preferred embodiment of the fine-grained security access control method for trusted applications provided in this invention.

[0030] Figure 5 This is a technical roadmap for applying for trusted application authorization in the fine-grained security access control method for trusted applications provided in the embodiments of the present invention.

[0031] Figure 6 This is a technical roadmap for creating and distributing application installation packages containing authorization information in the fine-grained security access control method for trusted applications provided in embodiments of the present invention.

[0032] Figure 7 This is a technical roadmap for blocking access authorization of a specified version of an App in a fine-grained security access control method for trusted applications provided in embodiments of the present invention.

[0033] Figure 8 This is a technical roadmap for terminal-side authorization verification and trusted application access in the fine-grained security access control method for trusted applications provided in embodiments of the present invention.

[0034] Figure 9 A system block diagram of a fine-grained secure access control system for trusted applications provided in embodiments of the present invention.

[0035] Figure 10 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0036] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0037] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0038] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0039] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, the first control information and the second control information are only used to distinguish different control information and do not limit their order.

[0040] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0041] It should also be understood that the terms "and / or" as used in this specification and the appended claims refer to any combination of one or more of the associated listed items and all possible combinations, and include such combinations.

[0042] In the existing technology, there are two main schemes for access control of CA (application calling TA interface) to TA (trusted application). The implementation process of the two schemes is described in detail below.

[0043] Existing Solution 1: TA Inspection Solution This solution pre-defines access control policies within the TA, allowing the TA to directly verify the CA's legitimacy. Figure 1 As shown, the specific process is as follows: (1) The CA calls the interface provided by the SystemService of a system application to request the execution of the TACMD-1 (instruction number) instruction of the payment TA, with the parameter being PARAM-1.

[0044] (2) After receiving the request, SystemService (the system server of the terminal device) reads the AppPkgName (application name) and AppSigningCert (application signature certificate) of the App through the system interface of DeviceOS (the terminal system).

[0045] (3) The SystemService sends a call request to the TEE, passing the TAUUID of the TA (the identifier of the trusted application, such as 123e4567-e89b-12d3-a456-426614174000).

[0046] (4) TEE locates the corresponding trusted application based on TAUUID.

[0047] (5) SystemService transmits parameters to TA via TEE: {AppPkgName, AppSigningCert, TACMD-1:0x0001, PARAM-1}.

[0048] (6) The TA has a pre-set list of allowed Apps (including AppPkgName and AppSigningCert). The TA will match the received parameters with the pre-set policy: if the match is successful, it will continue to execute; if the match is not successful, it will refuse access and return an error code.

[0049] (7) TA locates the internal execution function according to TACMD-1, executes the payment logic with PARAM-1 as parameter, and generates the execution result RES-1.

[0050] (8) TA returns RES-1 to SystemService via TEE.

[0051] (9) SystemService forwards RES-1 to App, completing the entire call process.

[0052] Option 2: SystemService Check Solution This solution pre-defines access control policies in SystemService, allowing SystemService to perform validity checks before calling the TEE. Figure 2 As shown in the diagram. The specific process is as follows: (1) The App calls the SystemService interface and requests to execute the TA's TACMD-1 instruction with the parameter PARAM-1.

[0053] (2) SystemService reads AppPkgName and AppSigningCert through the system interface of DeviceOS.

[0054] (3) SystemService has a pre-defined list of policies that allow access to TA (including the correspondence between TAUUID, AppPkgName, and AppSigningCert). SystemService will match the current request's {TAUUID, AppPkgName, AppSigningCert} with the pre-defined policies: if the match is successful, continue execution; if the match is not successful, access will be denied.

[0055] (4) The SystemService sends a call request to the TEE, passing the TAUUID of the TA.

[0056] (5) TEE locates the payment TA application based on TAUUID.

[0057] (6) The SystemService transmits the parameters {TACMD-1:0x0001, PARAM-1} to the payment TA via the TEE.

[0058] (7) TA locates the execution function according to TACMD-1, executes it with PARAM-1 as parameter, and obtains RES-1.

[0059] (8) TA returns RES-1 to SystemService via TEE.

[0060] (9) SystemService forwards RES-1 to App to complete the call.

[0061] Although the two existing solutions can achieve basic access control, they have the following significant drawbacks in practical applications, making it difficult to meet the requirements of endpoint security and business flexibility: I. Fixed Access Control Policies and Poor Flexibility: Existing solutions require the access control policies for {AppPkgName, AppSigningCert, TAUUID} to be pre-configured in the TA (Solution 1) or SystemService (Solution 2), which are strongly bound to the underlying DeviceOS and TEE. If a new App needs to be added that is allowed to access the TA (e.g., a new bank App that calls the payment TA), the pre-configured policy must be modified through system updates (e.g., OTA updates, system service patches), which cannot support the selective addition of new Apps in real time. For example, if a newly launched wealth management App needs to call the payment TA to implement a recharge function, it must wait for a major system update on the terminal device to complete the policy configuration, resulting in an excessively long business launch cycle.

[0062] Second, the lack of version-level blocking capabilities leads to high security risks: When a specific version of an app has a security vulnerability (such as a payment logic vulnerability or a signature forgery vulnerability), existing solutions cannot temporarily block that version's access to the payment transaction provider (TA). For example, if an app version 1.0 is found to have a payment vulnerability, attackers can exploit this vulnerability to illegally call the payment TA and initiate fraudulent transactions. However, existing solutions cannot only block access to version 1.0; they can only wait for all users to upgrade to the patched version, which may result in significant financial losses for many users during this period.

[0063] 3. Inability to adapt to application business changes, resulting in high maintenance costs: Solution 1 requires that the TA (Application Technology Provider) pre-configure the AppPkgName and AppSigningCert of the App. If the application changes its name due to business needs (e.g., AppPkgName changes from com.tencent.mm.wechat to com.tencent.mm) or changes its signing certificate (e.g., the developer changes the key pair), the TA's pre-configured strategy cannot automatically adapt. It is necessary to update the TA through an OTA (Over-The-Air) update package. However, the success rate of OTA updates is severely limited by the time window of major system version updates (e.g., if users do not upgrade their systems for a long time), resulting in some users' Apps being unable to access the TA normally.

[0064] Option 2 has a similar problem: SystemService's default policy cannot automatically adapt to changes in application name or signing certificate. It needs to be fixed through system service update packages. However, the coverage of system patches is limited by whether users enable automatic updates, resulting in high maintenance costs and a poor user experience.

[0065] Fourth, the access control is coarse-grained and lacks security: Existing solutions can only control whether "a certain App is allowed to access a certain TA", but cannot limit the specific instructions that an App can access from a TA. For example, after a WeChat App obtains access to a payment TA, it can call all the instructions of that TA (including initiating payment, checking balance, changing payment password, etc.). If the App is maliciously tampered with, it may illegally call sensitive instructions, leading to data leakage.

[0066] In summary, existing technical solutions have significant shortcomings in terms of access control flexibility, security, and adaptability. There is an urgent need for a trusted application access control method that can achieve fine-grained authorization, dynamic blocking, and flexible adaptation to solve the aforementioned technical problems. Based on this, this embodiment provides a fine-grained secure access control method for trusted applications. The method based on this embodiment can achieve dynamic configuration of access control policies, supporting new apps to access trusted applications without system updates, thus improving business flexibility. Specifically, in this embodiment, the application developer first randomly generates an application signing credential, applies for access permissions to the trusted application from the terminal device manufacturer's backend server, and receives the authorized signature of the trusted application returned by the terminal device manufacturer's backend server. The application signing credential includes the application signing private key and application signing certificate of the trusted application. Then, the application developer creates and publishes an application installation package containing authorization information, including the authorized signature of the trusted application and the public key of the terminal device manufacturer's backend server. Next, when the current APP calls the trusted application, the access authorization verification procedure of the trusted application is triggered. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is successful, the trusted application is called and the access process to the trusted application is completed.

[0067] The fine-grained security access control method for trusted applications in this embodiment can be applied to, for example... Figure 3 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on other network servers. Fine-grained security access control methods for trusted applications can be executed by terminal 102 or server 104, or they can be executed collaboratively by terminal 102 and server 104.

[0068] The terminal 102 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, IoT device, or portable wearable device. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices, etc.

[0069] Server 104 can be an independent physical server, a cloud server, or a service node in a blockchain system, where the service nodes in the blockchain system form a peer-to-peer network.

[0070] In addition, server 104 can also be a server cluster consisting of multiple physical servers, which can be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0071] Terminal 102 and server 104 can be connected via Bluetooth, USB (Universal Serial Bus) or network, etc., and this application does not impose any restrictions.

[0072] In some embodiments, such as Figure 4 As shown, a fine-grained security access control method for trusted applications is provided. This method can be applied to terminals, such as computers and other intelligent product terminals.

[0073] The method specifically includes the following steps: Step S100: The application developer randomly generates an application signing credential, applies to the backend server of the terminal device manufacturer for access to the trusted application, and receives the authorized signature of the trusted application returned by the backend server of the terminal device manufacturer. The application signing credential includes the application signing private key and the application signing certificate of the trusted application.

[0074] Specifically, in this embodiment, the application developer first randomly generates a key pair to obtain the application signing credential. The application signing credential includes the application signing private key and application signing certificate of the trusted application. Next, the application developer registers the generated application signing credential with the backend server of the terminal device manufacturer. Then, the backend server of the terminal device manufacturer randomly generates a backend server key pair, which includes the backend server private key and the backend server public key of the terminal device manufacturer. Next, the application developer constructs authorization request parameters and submits them to the backend server of the terminal device manufacturer. The authorization request parameters in this embodiment include: the application name of the trusted application, the application signing certificate, the trusted application identifier, and the range of trusted application instructions requested for access. Finally, after reviewing the authorization request parameters, the terminal device manufacturer signs the authorization request parameters using its own backend server private key to obtain the authorization signature of the trusted application, and returns the authorization signature of the trusted application to the application developer.

[0075] In practical applications, such as Figure 5 As shown, Figure 5 The image shows the steps an application developer takes to request specific instructions from the OEMServer to access a particular TA. 1. Generating Application Signing Certificates: The App Developer uses cryptographic tools (such as OpenSSL, KeyTool) to randomly generate a key pair {AppSigningPrivKey, AppSigningCert}. AppSigningPrivKey is the application signing private key, and AppSigningCert is the application signing certificate. AppSigningPrivKey uses a secure cryptographic algorithm (such as RSA 2048-bit, ECC secp256r1, SM2) for subsequent application installation package signing; AppSigningCert is a digital certificate conforming to the X.509 v3 standard, containing information such as the application developer's identifier (e.g., company name, unified social credit code), the public key corresponding to AppSigningPrivKey, and the certificate validity period, used to verify the app's legitimacy. The App Developer also registers AppSigningCert with the OEMServer.

[0076] 2. OEMServer generates a backend server key pair: The OEMServer randomly generates a backend server key pair {OEMServerPrivKey, OEMServerPubKey} in the background. OEMServerPrivKey is the backend server private key of the terminal device manufacturer, and OEMServerPubKey is the backend server public key of the terminal device manufacturer. Key algorithms can include ECC (secp256r1), RSA (2048 bits and above), SM2, etc. OEMServerPrivKey is stored in the OEMServer's secure key management module (such as the hardware security module HSM) to prevent private key leakage; OEMServerPubKey is pre-installed in the terminal device's SystemService for subsequent signature verification.

[0077] 3. Constructing the Authorization Request Parameters: AppDeveloper constructs the authorization request parameter AppTAReq (authorization request parameter), whose structure is {AppPkgName, AppSigningCert, TAUUID, [TACMD-1, TACMD-2, ..., TACMD-n]}. Parameter descriptions: AppPkgName: The application name of the trusted application; AppSigningCert: Application signing certificate (PEM format string); TAUUID: Trusted Application Identifier, a unique identifier for a trusted application. For example, the UUID of a payment application is "123e4567-e89b-12d3-a456-426614174000". [TACMD-1, ..., TACMD-n]: A list of TA instruction numbers requesting access, used to indicate the range of trusted application instructions requested for access. The instruction numbers are hexadecimal or decimal numbers, used to uniquely identify the specific function of the TA.

[0078] 3. Submitting an authorization request: The AppDeveloper submits the AppTAReq to the OEMServer through the developer platform, requesting access to the specified TA's instruction permissions. After receiving the request, the OEMServer retrieves the AppSigningCert registered by the developer from the application developer information database, performs a consistency check with the AppSigningCert in the AppTAReq, and verifies the developer's qualifications (such as whether it is a certified developer and whether it has signed a security agreement).

[0079] 4. Generate a trusted application authorization signature: After the OEMServer approves the application, it uses its own OEMServerPrivKey to sign the AppTAReq, generating an authorization signature (AppTASig). The signature algorithm can be RASSA-PSS, ECDSA, EdDSA, SM2, etc., and the hash function should use SHA-256 or higher strength. The signature formula is: AppTASig = Sig_Sign(key = OEMServerPrivKey, data = AppTAReq, hash = SHA-256) 5. Return Authorization Signature: The OEMServer returns the generated AppTASig to AppDeveloper through the developer platform. AppDeveloper receives it and stores it in the local development environment for subsequent application installation package creation.

[0080] Step S200: The application developer creates and releases an application installation package containing authorization information, which includes the authorization signature of the trusted application and the public key of the backend server of the terminal device manufacturer.

[0081] In this embodiment, the application developer first embeds a trusted application identifier, the scope of trusted application access requests, an authorization signature, and the backend server public key of the terminal device manufacturer into the application binary file. Next, the application developer uses the application signing certificate to sign the application binary file with the embedded information, obtaining a trusted application signature. Then, the application developer constructs an application installation package and publishes the application installation package to the terminal manufacturer's backend server. The application installation package includes: the application binary file with the embedded information, the trusted application signature, and the application signing certificate from the application signing certificate.

[0082] In practical applications, combined with Figure 6 As shown in the illustration, in this embodiment, the AppDeveloper embeds the authorization information into the application binary file, creates a complete application installation package, and publishes it to the OEMServer (the terminal manufacturer's backend server). The specific steps are as follows: 1. Embedding Authorization-Related Information: AppDeveloper embeds the following authorization information in the AppBinary (application binary file): {TAUUID, [TACMD-1, ..., TACMD-n], AppTASig, OEMServerPubKey}. Where: TAUUID is the trusted application identifier; [TACMD-1, ..., TACMD-n] is the scope of trusted application instructions requested for access; AppTASig is the authorization signature; and the backend server public key of the terminal device manufacturer is also included. OEMServerPubKey is the backend public key (PEM format) provided by the OEMServer, used for terminal-side verification of AppTASig. Note: AppInstallPkg already contains AppPkgName and AppSigningCert, so there is no need to embed them again.

[0083] 2. Signing the Application Binary File: AppDeveloper uses the AppSigningPrivKey (application signing credential) generated in step 1 to sign the AppBinary, which already contains embedded authorization information, generating AppSig (trusted application signature). The signing algorithm is consistent with the AppSigningPrivKey algorithm, ensuring that the AppBinary has not been tampered with.

[0084] 3. Constructing the Application Installation Package: AppDeveloper constructs the application installation package (AppInstallPkg), with the structure {AppBinary (containing authorization information), AppSig, AppSigningCert}. This installation package contains all the files and security verification credentials required for the application to run, and its integrity and legitimacy will be verified during installation on the terminal device.

[0085] 4. Publishing the application installation package: AppDeveloper publishes the AppInstallPkg to the OEMServer through the OEMServer's application publishing platform. The OEMServer verifies the installation package (such as verifying the legality of AppSig and AppSigningCert). Once the verification is successful, the package is uploaded for end users to download and install.

[0086] Step S300: If the backend server of the terminal device manufacturer receives a blocking access request, it blocks the trusted application access authorization program of the specified version of the APP based on the blocking access request.

[0087] Specifically, if the terminal device manufacturer's backend server receives a blocking access request, it constructs blocking request parameters. These parameters include: the application name of the application to be blocked, the application signing certificate, the application identifier, and the app version information. Next, the terminal device manufacturer's backend server signs the blocking request parameters using its own backend server private key, generating an application blocking signature. Then, based on the blocking request parameters, the application blocking signature, and the terminal device manufacturer's backend server public key, blocking information is generated. Finally, the terminal device manufacturer's backend server pushes the blocking information to the terminal device's system server, allowing the terminal device's system server to verify the blocking information.

[0088] When the system server of the terminal device verifies the blocking information, it first obtains the backend server public key of the terminal device manufacturer, which is pre-configured at the factory. Next, it checks whether the backend server public key of the terminal device manufacturer in the blocking information matches the pre-configured backend server public key. If they match, the system server uses the pre-configured backend server public key to verify the application blocking signature. After successful verification, the system server caches the blocking request parameters.

[0089] Combination Figure 7 As shown, when a specific version of an app has a security vulnerability or violates regulations, the OEMServer can temporarily block access to that version. The specific steps are as follows: 1. Receiving Blocking Requests: The OEMServer receives blocking requests from trusted sources (such as application developers, security incident response centers, and OEM security teams). The blocking request must include the requester's identity credentials (such as the developer's signing certificate or the incident response center's API key). After verifying the requester's legitimacy, the OEMServer initiates the blocking process.

[0090] 2. Constructing the blocking request parameters: The OEMServer constructs the blocking request parameters (AppForbidReq), with the structure {AppPkgName, AppSigningCert, TAUUID, [AppVer-1, AppVer-2, ..., AppVer-n]}. Parameter descriptions: AppPkgName, AppSigningCert, and TAUUID are consistent with the corresponding parameters in steps S100 and S200 above; [AppVer-1, ..., AppVer-n]: A list of App versions to be blocked, representing the application names of the applications to be blocked.

[0091] 3. Generate a masking signature: The OEMServer uses the OEMServerPrivKey to sign the AppForbidReq, generating a masking signature (AppForbidSig). The signing algorithm is consistent with the authorization signature, ensuring the legality and integrity of the masking command.

[0092] 4. Generate and push blocking information: The OEMServer generates blocking information AppForbidInfo, with the structure {AppForbidReq, AppForbidSig, OEMServerPubKey}, and pushes it to the DeviceOS-side SystemService of the terminal device. Push methods can include push notifications, system service retrieval (SystemService periodically queries the OEMServer for the blocking list), etc.

[0093] 5. SystemService pre-configured server public key: When the terminal device leaves the factory, SystemService pre-configures the OEMServerPubKey (which is consistent with the OEMServerPubKey in the authorization process) and stores it in the secure storage area of ​​SystemService (such as the device's secure partition) to prevent tampering.

[0094] 6. Verify the public key in the blocking information: After receiving AppForbidInfo, SystemService first extracts the OEMServerPubKey and performs a consistency check with its own pre-set OEMServerPubKey. If they match, it means the blocking information comes from a legitimate OEMServer, and the process continues to the next step; if they do not match, it is determined to be illegal blocking information, execution is refused, and a security log is recorded.

[0095] 7. Verify the masking signature: SystemService uses the pre-configured OEMServerPubKey to verify AppForbidSig. The verification formula is: AppForbidSigVerifyResult=Sig_Verify(key=OEMServerPubKey, data=AppForbidReq, sig=AppForbidSig). If the verification passes (result is TRUE), it means the masking information has not been tampered with, and the next step continues; if the verification fails (result is FALSE), execution is rejected and logged.

[0096] 8. Caching Blocking Information: SystemService caches the content of AppForbidReq to local secure storage. The cache can be set with an expiration time (e.g., 24 hours, 7 days), and supports remote updates or deletion of blocking rules by the OEMServer. The cached information will be used for version matching during terminal-side authorization verification.

[0097] Step S400: When the current APP calls a trusted application, the access authorization verification procedure of the trusted application is triggered. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is passed, the trusted application is called and the access process to the trusted application is completed.

[0098] Specifically, after the application installation package is installed on the terminal device, the current APP calls the relevant interface to request the execution of a trusted application identifier and a trusted application instruction, triggering the access authorization verification procedure of the trusted application. Next, the terminal device's system server reads the authorization information from the application installation package installed by the current APP. Then, the terminal device's system server checks whether the trusted application instruction requested for execution is in the application binary file of the application installation package. If it is, the terminal device's system server verifies whether the current APP matches the application to be blocked in the blocking request parameters. If they do not match, the terminal device's system server checks whether the backend server public key of the terminal device manufacturer embedded in the application installation package installed by the current APP is consistent with its own pre-set backend server public key of the terminal device manufacturer. If they are consistent, the terminal device's system server uses its own pre-set backend server public key of the terminal device manufacturer to verify the authorization signature.

[0099] After successful verification, the terminal device's system server transmits the trusted application identifier to the trusted execution environment (TEA) to request the invocation of the corresponding trusted application. Next, the terminal device's system server, based on the TEA, transmits instruction parameters to the invoked trusted application, enabling the trusted application to execute its corresponding internal function based on these parameters and obtain the execution result. Finally, the terminal device's system server receives the execution result from the trusted application and feeds it back to the current application.

[0100] In practical applications, combined with Figure 8 As shown, after the end user installs AppInstallPkg (the application installation package), the app triggers an authorization verification process when calling a trusted application. After SystemService completes multiple verifications, it calls TA. The specific steps are as follows: 1. SystemService pre-configured server public key: When the terminal device leaves the factory, SystemService has pre-configured OEMServerPubKey, which is consistent with the public key in the authorization process and the blocking process, providing a basis for subsequent signature verification.

[0101] 2. App initiates interface call request: Apps with AppInstallPkg installed call the TA access interface provided by SystemService to request the execution of the {TAUUID, TACMD-x} instruction, with the parameter being PARAM-x, which is to request the execution of the trusted application identifier and trusted application instruction.

[0102] 3. Read App basic information: After receiving the request, SystemService reads the App's basic information through the DeviceOS system interface: AppPkgName, AppSigningCert, and AppVer (current installed version).

[0103] 4. Read the authorization information embedded in the App: SystemService reads the authorization information embedded in AppBinary through the DeviceOS system interface: {TAUUID, [TACMD-1, ..., TACMD-n], AppTASig, OEMServerPubKey}.

[0104] 5. Verify the validity of the request instruction: SystemService checks whether the currently requested TACMD-x (e.g., 0x0001) exists in the App's embedded list of [TACMD-1, ..., TACMD-n]. If it exists, it means that the App has requested access permission for this instruction and proceeds to the next step; if it does not exist, it refuses to execute and returns error code 0x80000001 (illegal instruction) to the App.

[0105] 6. Verify if blocked: SystemService queries the locally cached list of AppForbidReqs and checks if the current App's {AppPkgName, AppSigningCert, TAUUID, AppVer} matches a specific AppForbidReq (version supports wildcard matching). If a match is found, it means the version has been blocked, execution is refused, and error code 0x80000002 (version blocked) is returned; if no match is found, proceed to the next step.

[0106] 7. Verify the server public key in the App: SystemService checks whether the OEMServerPubKey embedded in the App matches its own pre-set OEMServerPubKey. If they match, it means the authorization information comes from a legitimate OEMServer, and proceed to the next step; if they do not match, execution is refused, and error code 0x80000003 (public key mismatch) is returned.

[0107] 8. Construct authorization verification parameters: SystemService constructs the authorization verification parameter AppTAReq_Verify, whose structure is consistent with the AppTAReq submitted by AppDeveloper, namely {AppPkgName, AppSigningCert, TAUUID, [TACMD-1, ..., TACMD-n]}.

[0108] 9. Verify the authorized signature: SystemService uses the preset OEMServerPubKey to verify AppTASig. The verification formula is: AppTASigVerifyResult=Sig_Verify(key=OEMServerPubKey, data=AppTAReq_Verify, sig=AppTASig). If the verification passes (the result is TRUE), it means that the authorization information has not been tampered with, and continue to the next step; if the verification fails, refuse to execute and return error code 0x80000004 (signature verification failed).

[0109] 10. Request TEE to call the target trusted application: SystemService sends a call request to TEE, passing the parameter TAUUID, and requests to locate the target trusted application.

[0110] 11. TEE locates the target trusted application: TEE searches for the corresponding trusted application (such as payment TA) in its own TA list based on TAUUID. After successful location, it returns confirmation information to SystemService.

[0111] 12. Transmitting execution parameters: SystemService transmits execution parameters {TACMD-x, PARAM-x} to TA via TEE, which are the instructions and related parameters requested by the current App.

[0112] 13. TA executes instructions and returns results: The trusted application locates the internal execution function based on TACMD-x, executes the corresponding business logic (such as payment verification, key generation) with PARAM-x as the parameter, and generates the execution result RES-x (such as payment success identifier, encrypted data). TA returns RES-x to SystemService via TEE.

[0113] 14. Result returned to the current App: SystemService forwards RES-x to the current App that initiated the request. The current App executes subsequent business logic based on the result (such as displaying a payment success page or processing encrypted data) to complete the entire trusted application access process.

[0114] Compared with the prior art, the present invention has the following significant advantages: 1. Significantly Enhanced Access Control Flexibility: This invention issues AppTASig through the OEMServer and embeds the authorization information into the App installation package. SystemService verifies authorization through signature verification, eliminating the need to pre-configure access control policies in the TA or SystemService. When a new App accesses the TA, the AppDeveloper only needs to apply for authorization from the OEMServer and update the installation package, without requiring system OTA or patch updates. This allows for real-time support for selectively added App access. For example, if a bank App needs to add permission to call the payment TA, it only needs to complete the authorization application and release the installation package. Users can access the App normally after updating it, without waiting for system updates. The business launch cycle is shortened from weeks to hours.

[0115] 2. Fine-grained access control for enhanced security: This invention supports limiting the specific TA commands that an App can access through a [TACMD-1,...,TACMD-n] command list, achieving fine-grained "command-level" authorization. For example, the WeChat App can only access the "Initiate Payment" (0x0001) and "Verify Payment Result" (0x0002) commands of the Payment TA, and cannot access sensitive commands such as "Change Payment Password" (0x0003). Even if the App is tampered with, it is difficult to obtain sensitive functions beyond the authorized scope, significantly reducing security risks.

[0116] Meanwhile, this invention supports version-level blocking, which can accurately block App versions with vulnerabilities. For example, if an App version 1.0 has a security vulnerability, the OEMServer can block only that version without affecting the use of other normal versions, enabling a rapid response to security incidents and preventing data leakage or property loss.

[0117] 3. Adaptable to business changes, reduced maintenance costs: This invention only requires the SystemService to pre-configure the OEMServerPubKey, without needing to pre-configure information such as the AppPkgName and AppSigningCert. When the App changes its name or signing certificate due to business needs, the App Developer only needs to re-register the new certificate with the OEMServer, apply for a new authorized signature, and update the App installation package. There's no need to update the TA or SystemService, and it's not limited by major system version update windows. For example, after WeChat App changes its signing certificate, users can obtain the new authorization simply by updating the App, without waiting for a system OTA update, reducing maintenance costs and significantly improving the user experience.

[0118] 4. Reduced System Development and Upgrade Costs: Existing solutions require the Application Controller (TA) or SystemService to pre-configure numerous access control policies, increasing the development complexity of TA and SystemService. This invention, however, only requires SystemService to pre-configure the OEMServerPubKey; the TA does not need to concern itself with application authorization information, significantly reducing the development and testing costs of TA and SystemService. Simultaneously, it avoids system OTA or patch updates caused by policy updates, reducing system upgrade and maintenance costs and increasing user acceptance of system updates.

[0119] Based on the above embodiments, the present invention also provides a fine-grained secure access control system for trusted applications. The system in this embodiment is used to implement the steps in the above method embodiments. For example... Figure 9 As shown in the diagram, the system in this embodiment includes: an application developer, a backend server of a terminal device manufacturer, and a system server of the terminal device. The application developer includes: an access permission application module, an authorization signature receiving module, and an application installation package creation and distribution module. The access permission application module is used to randomly generate an application signature credential and apply to the backend server of the terminal device manufacturer for access permissions to a trusted application. The application signature credential includes the application signature private key and application signature certificate of the trusted application. The authorization signature receiving module is used to receive the authorization signature of the trusted application returned by the backend server of the terminal device manufacturer. The application installation package creation and distribution module is used to create and distribute an application installation package containing authorization information, including the authorization signature of the trusted application and the public key of the backend server of the terminal device manufacturer. The system server of the terminal device includes an authorization signature verification module, which is used to trigger the access authorization verification program of the trusted application when the current APP calls the trusted application. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is successful, the trusted application is called and the access process to the trusted application is completed.

[0120] The backend server of the terminal device manufacturer includes a blocking control module, which, upon receiving a blocking access request, blocks the trusted application access authorization program of a specified version of the APP based on the blocking access request.

[0121] In one implementation, the backend server of the terminal device manufacturer includes: The blocking control module is used to block the trusted application access authorization program of a specified version of the APP based on the blocking access request after receiving the blocking access request.

[0122] In one implementation, the application installation package creation and distribution module includes: The information embedding unit is used to embed the trusted application identifier, the scope of trusted application instructions requesting access, the authorization signature, and the backend server public key of the terminal device manufacturer into the application binary file. The file signing unit is used to sign the application binary file with embedded relevant information using the application signing credential to obtain a trusted application signature; The installation package construction and distribution unit is used by application developers to construct application installation packages and distribute the application installation packages to the backend server of terminal manufacturers. The application installation package includes: an application binary file with embedded relevant information, a trusted application signature, and an application signature certificate in the application signature certificate.

[0123] In one implementation, the shielding control module includes: The masking request construction unit is used to construct masking request parameters if the backend server of the terminal device manufacturer receives a masking access request. The masking signature generation unit is used to sign the masking request parameters using its own backend server private key to generate an application masking signature; The blocking information generation unit is used to generate blocking information based on the blocking request parameters, the application blocking signature, and the public key of the backend server of the terminal device manufacturer. The blocking information push unit is used to push blocking information to the system server of the terminal device so that the system server of the terminal device can verify the blocking information.

[0124] In one implementation, the authorized signature verification module includes: The authorization information reading unit is used to read the authorization information from the application installation package currently installed by the APP. The instruction checking unit is used to check whether the trusted application instruction currently requested for execution is in the application binary file of the application installation package; The blocking request parameter verification unit is used to verify, if present, whether the system server of the terminal device verifies whether the current APP matches the application to be blocked in the blocking request parameters; The public key checking unit is used to check whether the public key of the backend server of the terminal device manufacturer embedded in the application installation package of the current APP is consistent with the public key of the backend server of the terminal device manufacturer that it has pre-installed. The authorization signature verification unit is used to verify the authorization signature using the pre-installed public key of the terminal device manufacturer's backend server if the signatures match.

[0125] The working principle of each module in the system of this embodiment is the same as that of each step in the above method embodiment, and will not be repeated here.

[0126] In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a fine-grained secure access control method for a trusted application. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0127] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0128] In some embodiments, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps: The application developer randomly generates an application signing credential, applies to the backend server of the terminal device manufacturer for access to the trusted application, and receives the authorized signature of the trusted application returned by the backend server of the terminal device manufacturer. The application signing credential includes the application signing private key and the application signing certificate of the trusted application. Application developers create and release application installation packages containing authorization information, which includes the authorization signature of the trusted application and the public key of the backend server of the terminal device manufacturer; When the current APP calls a trusted application, the access authorization verification procedure of the trusted application is triggered. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is successful, the trusted application is called and the access process to the trusted application is completed.

[0129] In one implementation, the method further includes: If the backend server of the terminal device manufacturer receives a request to block access, it will block the trusted application access authorization program of the specified version of the APP based on the request.

[0130] It should be noted that the user information (including but not limited to user device function information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0131] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0132] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0133] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

[0134] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fine-grained security access control method for trusted applications, characterized in that, The method includes: The application developer randomly generates an application signing credential, applies to the backend server of the terminal device manufacturer for access to the trusted application, and receives the authorized signature of the trusted application returned by the backend server of the terminal device manufacturer. The application signing credential includes the application signing private key and the application signing certificate of the trusted application. Application developers create and release application installation packages containing authorization information, which includes the authorization signature of the trusted application and the public key of the backend server of the terminal device manufacturer; When the current APP calls a trusted application, the access authorization verification procedure of the trusted application is triggered. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is successful, the trusted application is called and the access process to the trusted application is completed.

2. The fine-grained security access control method for trusted applications according to claim 1, characterized in that, The method further includes: If the backend server of the terminal device manufacturer receives a request to block access, it will block the trusted application access authorization program of the specified version of the APP based on the request.

3. The fine-grained security access control method for trusted applications according to claim 2, characterized in that, Application developers randomly generate application signing credentials and request access permissions for trusted applications from the backend servers of terminal device manufacturers, including: The application developer randomly generates a key pair to obtain the application signature credential; Application developers register the generated application signature credentials with the backend server of terminal device manufacturers; The backend server of the terminal equipment manufacturer randomly generates a backend server key pair, which includes the backend server private key and the backend server public key of the terminal equipment manufacturer. The application developer constructs the authorization request parameters and submits them to the terminal device manufacturer's backend server.

4. The fine-grained security access control method for trusted applications according to claim 3, characterized in that, The authorization request parameters include: the application name of the trusted application, the application signing certificate, the trusted application identifier, and the range of trusted application instructions requested for access.

5. The fine-grained security access control method for trusted applications according to claim 4, characterized in that, Receive the authorization signature of the trusted application returned by the backend server of the terminal device manufacturer, including: After reviewing the authorization request parameters, the terminal device manufacturer signs the authorization request parameters using its own backend server private key to obtain the authorization signature of the trusted application, and then returns the authorization signature of the trusted application to the application developer.

6. The fine-grained security access control method for trusted applications according to claim 5, characterized in that, Application developers create and release application installation packages that contain licensing information, including: Application developers embed a trusted application identifier, the scope of trusted application instructions for requesting access, an authorization signature, and the backend server public key of the terminal device manufacturer into the application binary file. Application developers use the application signing credential to sign the application binary file with embedded relevant information to obtain a trusted application signature; The application developer constructs an application installation package and publishes the application installation package to the backend server of the terminal manufacturer. The application installation package includes: an application binary file with embedded relevant information, a trusted application signature, and an application signature certificate in the application signature credential.

7. The fine-grained security access control method for trusted applications according to claim 6, characterized in that, If the backend server of the terminal device manufacturer receives a request to block access, it blocks the trusted application access authorization program of the specified version of the APP based on the request, including: If the terminal device manufacturer's backend server receives a request to block access, it constructs the blocking request parameters. The terminal device manufacturer's backend server uses its own backend server private key to sign the blocking request parameters and generate an application blocking signature; Based on the blocking request parameters, the application blocking signature, and the backend server public key of the terminal device manufacturer, blocking information is generated; The terminal device manufacturer's backend server pushes the blocking information to the terminal device's system server, so that the terminal device's system server can verify the blocking information.

8. The fine-grained security access control method for trusted applications according to claim 7, characterized in that, The blocking request parameters include: the application name of the application to be blocked, the application signature certificate, the application identifier, and the APP version information.

9. The fine-grained security access control method for trusted applications according to claim 7, characterized in that, When the system server of the terminal device verifies the shielding information, it includes: Obtain the public key of the backend server of the terminal device manufacturer that is pre-installed on the system server of the terminal device at the factory; Check whether the public key of the backend server of the terminal device manufacturer in the blocking information is consistent with the public key of the backend server of the terminal device manufacturer that is preset at the factory. If they match, the system server of the terminal device uses the pre-set public key of the terminal device manufacturer's backend server to verify the application masking signature. After successful verification, the system server of the terminal device caches the blocking request parameters.

10. The fine-grained security access control method for trusted applications according to claim 9, characterized in that, When the current APP calls a trusted application, the access authorization verification procedure of the trusted application is triggered, including: After the application installation package is installed on the terminal device, the current APP calls the relevant interfaces; The request executes the trusted application identifier and trusted application instructions to trigger the access authorization verification procedure of the trusted application.

11. The fine-grained security access control method for trusted applications according to claim 10, characterized in that, The system server of the terminal device verifies the authorized signature using the backend server public key of the terminal device manufacturer pre-installed in the application installation package, including: The system server of the terminal device reads the authorization information from the application installation package currently installed by the APP. The system server of the terminal device checks whether the trusted application instruction currently requested for execution is in the application binary file of the application installation package; If so, the system server of the terminal device will verify whether the current APP matches the application to be blocked in the blocking request parameters; If they do not match, the terminal device's system server will check whether the backend server public key of the terminal device manufacturer embedded in the application installation package of the current APP is consistent with the backend server public key of the terminal device manufacturer that it has pre-installed. If they match, the terminal device's system server uses its own pre-installed public key from the terminal device manufacturer's backend server to verify the authorized signature.

12. The fine-grained security access control method for trusted applications according to claim 11, characterized in that, After successful verification, the trusted application is invoked, and the access process to the trusted application is completed, including: After the verification is successful, the system server of the terminal device sends the trusted application identifier to the trusted execution environment to request the invocation of the corresponding trusted application; The system server of the terminal device transmits instruction parameters to the called trusted application based on the trusted execution environment, so that the trusted application executes the corresponding internal function based on the instruction parameters and obtains the execution result; The system server of the terminal device receives the execution result of the trusted application and feeds back the execution result to the current APP.

13. A fine-grained secure access control system for trusted applications, characterized in that, The system is used to implement the fine-grained security access control method for trusted applications as described in any one of claims 1-12, and the system includes a backend server for the application developer and a backend server for the terminal device manufacturer, and a system server for the terminal device. The application developers include: The access permission application module is used to randomly generate application signature credentials and apply to the backend server of the terminal device manufacturer for access permissions to trusted applications. The application signature credentials include the application signature private key and application signature certificate of the trusted application. The authorization signature receiving module is used to receive the authorization signature of the trusted application returned by the backend server of the terminal device manufacturer; The application installation package creation and publishing module is used to create and publish application installation packages containing authorization information, including the authorization signature of the trusted application and the public key of the backend server of the terminal device manufacturer. The system server for the terminal device includes: The authorization signature verification module is used to trigger the access authorization verification program of the trusted application when the current APP calls the trusted application. The system server of the terminal device uses the backend server public key of the terminal device manufacturer pre-installed in the application installation package to verify the authorization signature. After the verification is successful, the trusted application is called and the access process to the trusted application is completed.

14. The fine-grained secure access control system for trusted applications according to claim 13, characterized in that, The backend server of the terminal equipment manufacturer includes: The blocking control module is used to block the trusted application access authorization program of a specified version of the APP based on the blocking access request after receiving the blocking access request.

15. The fine-grained secure access control system for trusted applications according to claim 14, characterized in that, The application installation package creation and distribution module includes: The information embedding unit is used to embed the trusted application identifier, the scope of trusted application instructions requesting access, the authorization signature, and the backend server public key of the terminal device manufacturer into the application binary file. The file signing unit is used to sign the application binary file with embedded relevant information using the application signing credential to obtain a trusted application signature; The installation package construction and distribution unit is used by application developers to construct application installation packages and distribute the application installation packages to the backend server of terminal manufacturers. The application installation package includes: an application binary file with embedded relevant information, a trusted application signature, and an application signature certificate in the application signature certificate.

16. The fine-grained secure access control system for trusted applications according to claim 15, characterized in that, The shielding control module includes: The masking request construction unit is used to construct masking request parameters if the backend server of the terminal device manufacturer receives a masking access request. The masking signature generation unit is used to sign the masking request parameters using its own backend server private key to generate an application masking signature; The blocking information generation unit is used to generate blocking information based on the blocking request parameters, the application blocking signature, and the public key of the backend server of the terminal device manufacturer. The blocking information push unit is used to push blocking information to the system server of the terminal device so that the system server of the terminal device can verify the blocking information.

17. The fine-grained secure access control system for trusted applications according to claim 16, characterized in that, The authorized signature verification module includes: The authorization information reading unit is used to read the authorization information from the application installation package currently installed by the APP. The instruction checking unit is used to check whether the trusted application instruction currently requested for execution is in the application binary file of the application installation package; The blocking request parameter verification unit is used to verify, if present, whether the system server of the terminal device verifies whether the current APP matches the application to be blocked in the blocking request parameters; The public key checking unit is used to check whether the public key of the backend server of the terminal device manufacturer embedded in the application installation package of the current APP is consistent with the public key of the backend server of the terminal device manufacturer that it has pre-installed. The authorization signature verification unit is used to verify the authorization signature using the pre-installed public key of the terminal device manufacturer's backend server if the signatures match.

18. A computer device, characterized in that, The computer device includes a memory, a processor, and a fine-grained security access control program for a trusted application stored in the memory and executable on the processor. When the processor executes the fine-grained security access control program for the trusted application, it implements the steps of the fine-grained security access control method for a trusted application as described in any one of claims 1-12.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a fine-grained security access control program for a trusted application, which implements the steps of the fine-grained security access control method for a trusted application as described in any one of claims 1-12 on the computer-readable storage medium.

Images