Authority management system, application installation management method and electronic equipment

Abstract

The invention discloses an authority management system, an application installation management method and electronic equipment. The system comprises a first system and a second system which are mutually independent, the first system is used for application installation; the second system is used for storing the permission configuration file and providing security verification according to the permission configuration file when the first system performs application installation; the second system comprises a trusted execution environment, and the permission configuration file is stored in the trusted execution environment. The first system can only read the permission configuration file in the second system and cannot directly modify the permission configuration file in the second system in the application installation process, so that the security of the permission configuration file is ensured; the application verified by the permission configuration file can be installed by the first system, self-definition of the application allowed to be installed in the first system is achieved, and the flexibility of system safety protection is improved.

Description

Technical Field

[0001] The present invention relates to the field of authority management, and in particular to an authority management system, an application installation management method and an electronic device. Background Art

[0002] For application ecosystems with high security requirements, there is a need to limit application installation permissions. In related technologies, whitelists or blacklists are usually set to manage application installation permissions. However, directly setting whitelists or blacklists in devices has low security and is easy to be tampered with. Summary of the invention

[0003] The technical problem to be solved by the present invention is to provide an application installation authority management method and an electronic device to achieve high-security authority management.

[0004] In order to solve the above technical problems, a technical solution adopted by the present invention is: A rights management system, applied to electronic equipment, comprising a first system and a second system that are independent of each other; The first system is used for application installation; The second system is used to store the authority configuration file and provide security verification according to the authority configuration file when the first system installs the application; The second system includes a trusted execution environment, and the rights configuration file is stored in the trusted execution environment.

[0005] In order to solve the above technical problems, another technical solution adopted by the present invention is: A method for application installation management is implemented by the above-mentioned permission management system, and the method includes: The first system obtains information of the application to be installed; The first system reads the authority configuration file in the second system through the interactive interface, and verifies the application information to be installed according to the authority configuration file; If the verification is successful, the first system performs an application installation operation according to the information of the application to be installed.

[0006] In order to solve the above technical problems, another technical solution adopted by the present invention is: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, each step in the above-mentioned application installation management method is implemented.

[0007] The beneficial effects of the present invention are as follows: a first system and a second system are set up independently of each other, and a permission configuration file is stored in the second system; the first system performs the step of installing an application, and requests the permission configuration file in the second system to perform permission verification when installing the application, so that the steps of application installation and permission verification are implemented in different systems, and the application installation process and the permission verification process are isolated; the permission configuration file is stored in a trusted execution environment in the second system, so that the first system can only read the permission configuration file in the second system during the application installation process and cannot directly modify the permission configuration file in the second system, thereby ensuring the security of the permission configuration file; only applications that pass the permission configuration file verification can be installed by the first system, thereby realizing the customization of applications allowed to be installed in the first system and improving the flexibility of system security protection. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A structural diagram of a rights management system provided by an embodiment of the present invention; Figure 2 A flowchart of a method for managing application installation provided by an embodiment of the present invention; Figure 3 A structural diagram of a specific implementation method of a rights management system according to an embodiment of the present invention; Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0009] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0010] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0011] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0012] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0013] In the related technologies, in the usage scenarios of devices, the hardware providers, the hardware-based product processors, and the final product users are usually inconsistent; the product processors usually hope that only products in their own ecosystem can run on the hardware to ensure the security of the data. For example, when selling hardware to banks, supermarkets and other merchants, they will want an ecosystem based on their own products, and can only install their own acquiring applications, desktop applications, systems and other software, and do not want to install applications from other sources. Especially for financial terminals, the relevant security requirements will be higher. However, in the related technologies, whether to allow application installation is usually simply managed through a whitelist. If the whitelist is tampered with, it will also affect the safety of device use.

[0014] For example, POS machines are provided to some banks. As the product processor, the bank will install its own transaction-related applications on the POS machines and then distribute them to users for use. The bank will hope that during the application installation process, only the bank's own certified applications will be allowed to be installed, rather than any application being installed at will, so as to ensure the security of the POS machines. However, how to achieve secure permission management is an urgent problem to be solved.

[0015] In order to solve the above problems, the present application provides a permission management system, an application installation management method and an electronic device. The following is a detailed introduction to a permission management system of the present application.

[0016] The permission management system in this application can be used in various electronic devices that need to restrict application installation permissions, such as mobile phones, televisions and other terminals, especially in the financial field for financial terminals such as POS machines and cash registers.

[0017] The following is a detailed description of the rights management system in the present invention. Figure 1 , including a first system 110 and a second system 120 which are independent of each other.

[0018] The first system is used for application installation.

[0019] The second system is used to store the authority configuration file and provide security verification according to the authority configuration file when the first system installs the application.

[0020] The second system includes a trusted execution environment, and the rights configuration file is stored in the trusted execution environment.

[0021] In this way, a first system and a second system are set up independently of each other. When an application is installed in the first system, permission verification is performed through the permission configuration file stored in the trusted execution environment in the second system. The permission configuration file is isolated in the second system through the trusted execution environment, and access to the trusted execution environment requires verification, thereby avoiding the problem of tampering with the permission configuration file. At the same time, only applications that have passed the permission configuration file verification can be installed in the first system, thereby realizing customized application installation in the first system and improving the flexibility of system security protection.

[0022] In one embodiment of the present application, a link service 130 is also included. The link service is used for communication between the first system and the second system. In this way, the first system and the second system, which are independent of each other, are linked through the link service, a communication channel between the first system and the second system is constructed, and data interaction between the first system and the second system is realized.

[0023] In one embodiment of the present application, the first system is used to receive an operation request and send the operation request to a link service. In this way, the link service is used as a connection between the first system and the second system. After receiving the operation request, the first system sends the operation request to the link service to access the second system, further isolating the first system from the second system and improving security.

[0024] In one embodiment of the present application, the second system includes a trusted application; the trusted application includes an interactive interface, the interactive interface is used to communicate with the link service and receive the operation request forwarded by the link service; the trusted application is used to receive the operation request and operate the permission profile according to the operation request. In this way, while the permission profile is stored in the trusted execution environment to ensure the security of the permission profile access, a trusted application is provided to communicate with the link service and receive the operation request through the interactive interface in the trusted application, and the permission profile is operated according to the operation request through the trusted application, which further ensures the security of the operation request transmission and processing process. In addition, the trusted application can also be set in the trusted execution environment, so that entering the trusted execution environment and calling the trusted application require security verification, which ensures the security of the permission profile storage and use process.

[0025] In one embodiment of the present application, the interactive interface is further used to perform identity authentication when receiving an operation request. If the identity authentication is successful, the step of receiving the operation request file forwarded by the link service is executed.

[0026] In this way, when the interactive interface receives an operation request, it does not directly forward the operation request, but authenticates the operation request before forwarding it. The operation request is received only after the authentication is passed so that the corresponding trusted application can operate the permission configuration file according to the operation request. In addition to the conventional authentication required for accessing the trusted execution environment in the prior art, the authentication of the operation request is also added. For example, it can verify whether the initiator of the operation request has the authority to access the trusted execution environment or prompt the front end to enter a password for authentication, which further improves the security of the permission configuration file operation. Because the interface is provided to the application layer in the first system through the link service to operate the permission configuration file, if the link service is leaked or tampered with, it may cause security problems. After adding role verification, even if the link service in the first system is exposed, because there is still a role verification process, it is still impossible to access the data in the trusted execution environment without the corresponding authority.

[0027] In one embodiment of the present application, the first system is further used to obtain the rights configuration file upon activation and send the rights configuration file to the link service; the second system is further used to receive the rights configuration file through the interactive interface and save the rights configuration file.

[0028] Among them, the activation process of the electronic device is the first power-on process of the electronic device. During the activation process, the electronic device needs to be initialized and the corresponding operating parameters and other operations need to be imported; at this time, the first system can obtain the permission configuration file through networking or receiving user input, and send the permission configuration file to the second system for storage by the second system, that is, the first system executes the external interaction process, and only the data verified by the first system can be sent to the second system for verification again by the trusted execution environment in the second system. The second system only interacts with the first system, and the first system interacts with the outside world, which further reduces the possibility of the second system being attacked, thereby further ensuring the security of storing data and executing operation processes in the second system.

[0029] The following specifically introduces an application installation management method in the present invention, which is implemented by the above-mentioned permission management system. Figure 2 The method includes steps 210 to 230.

[0030] Step 210: The first system obtains information of applications to be installed.

[0031] In one embodiment of the present application, step 210 also includes step 211: the first system obtains the rights configuration file when activated and sends the rights configuration file to the link service; the second system is also used to receive the rights configuration file through the interactive interface and save the rights configuration file. In this way, the import process of the rights configuration file is loaded into the activation process of the first system, so that the latest rights configuration file can be automatically obtained.

[0032] Step 220: The first system reads the authority configuration file in the second system through the interactive interface, and verifies the information of the application to be installed according to the authority configuration file.

[0033] In one embodiment of the present application, step 220 also includes step a: the second system sets the allowed access roles of the trusted application and the access rights corresponding to each allowed access role, and the access rights include read-only and read-write. In this way, roles with different permissions are set for the trusted application, and the roles can be directly matched for the first system in advance, so that the first system has the permissions corresponding to the roles. Here, the first system can be a fixed identity, or it can be the identity of the logon person in the first system obtained by the first system; by performing permission management through roles, only the role needs to be changed to quickly adjust the permissions, which improves the efficiency of management, and when accessing the second system, in addition to the conventional security verification means of the trusted execution environment and the trusted application in the second system in the prior art, the role permission verification of the first system accessing the second system is added, which further improves the security of the permission configuration file operation.

[0034] Then, in step 220, the first system reads the permission configuration file in the second system through the interactive interface, including step b: the second system verifies whether the first system matches the allowed access role, and if so, allows the first system to read the permission configuration file. In this way, only the first system that has passed the access role verification is allowed to operate the permission configuration file in the second system, and according to the different matching access roles, the access rights corresponding to the access roles are also different, so the permission management of different visitors is realized, and it can be limited to only allow reading of the permission configuration file without opening the write permission or being able to read and write, thereby refining the management of the access rights of the permission configuration file and improving the security of operating the permission configuration file.

[0035] In one embodiment of the present application, the permission configuration file includes an installation source whitelist, an application blacklist, and a self-update whitelist; the permission configuration file can configure permissions during the application installation process from three perspectives: the application installation source, the application itself, and whether the application can self-update, thereby providing a more flexible setting method when performing permission control, which can match the user's detailed needs. For example, if a certain application installation source is allowed to perform application installation operations, but the installation of a specific application is to be blocked, the application can be added to the application blacklist after setting the installation source whitelist to achieve personalized application installation permission control.

[0036] In one embodiment of the present application, a priority can also be set for each type of permission configuration file, and permission verification can be performed in sequence according to the priority order. If the installation condition is met in the permission configuration file with a high priority, it is judged that the verification is passed. For example, the order of priority from high to low is the installation source whitelist, the application blacklist, and the self-update whitelist. After receiving the application information to be installed, if its first initiator information is in the installation source whitelist, the verification is passed. Otherwise, it is confirmed whether the identification information of the application in the application information to be installed is in the application blacklist. If not, the verification is passed; if it is, it is only necessary to confirm whether the first initiator information is in the self-update whitelist. If so, the verification is passed, otherwise the application installation process is stopped. The priority order can be modified according to different scenarios.

[0037] If no priority order is set, you can set it according to the strictness of permission control to require that all permission profiles are met to allow application installation, or to allow application installation as long as the permission profiles of the preset types are met. For example, application installation can be allowed if only one type of permission profile is met. I will not go into details here.

[0038] In one embodiment of the present application, verifying the information of the application to be installed according to the authority configuration file in step 220 includes steps 221 to 223.

[0039] When the permission configuration file is an installation source whitelist, execute step 121: the first system obtains the first initiator information in the application information to be installed, and determines whether the first initiator information is in the installation source whitelist. If so, the verification is passed, otherwise, it prompts that the installation source is wrong and stops the application installation process. In this way, the first initiator information in the application information to be installed is verified. For example, when installing an application in the application market, the application market will initiate the application information to be installed. The application market is the first initiator information. The first initiator information is in the installation source whitelist. Only when the first initiator information is in the installation source whitelist, the application installation package on the shelf is prevented from being installed. Because the application installation source of the application market usually performs security verification on the application installation package on the shelf, limiting the source of the application when installing the application can preliminarily exclude application installation packages that may be tampered with, such as installation packages from browsers.

[0040] When the permission configuration file is an application blacklist, step 222 is executed: the first system obtains the identification information of the application in the application information to be installed, and determines whether the identification information is in the application blacklist. If so, it prompts that there is a blacklist application and stops the application installation process, otherwise the verification is passed. In this way, a blacklisting operation for a single application is provided. For example, various entertainment applications can be added to the application blacklist on a learning terminal, so that the entertainment applications cannot be used on the learning terminal to ensure the use effect of the learning terminal; for example, the installation of other third-party payment software can be rejected on a financial terminal.

[0041] When the permission configuration file is a self-update whitelist, step 223 is executed: the first system obtains the first initiator information in the application information to be installed, and determines whether the first initiator information is in the self-update whitelist; if so, the identification information of the application in the application installation request is obtained, and it is determined whether the identification information matches the first initiator information. If so, the verification is passed, otherwise, it is prompted that there is no corresponding permission and the application installation process is stopped. In this way, for some applications, the function of installing other applications can be restricted and self-update can be allowed, thereby realizing the self-update of the software in the electronic device and avoiding the vulnerability in the installed application from being repaired in time. Therefore, if the application is in the self-update whitelist, on the basis of verifying the matching of the first initiator information, it is also necessary to verify whether the identification information of the application in the application information to be installed provided by it corresponds to the identification information of the first initiator itself. If both correspond, it means that the application information to be installed sent by the application is the update information of the application itself, that is, the application to be installed is its own version update. If the identification information does not correspond, it means that the application information to be installed corresponding to other applications is submitted, which does not belong to the scope of self-update, and the judgment of whether the application is self-updated is realized.

[0042] Step 230: If the verification is successful, the first system performs an application installation operation according to the application information to be installed.

[0043] To summarize, during the process of application installation, the first system obtains information about the application to be installed; it first requests the permission configuration file in the second system through the interactive interface, and verifies the information about the application to be installed according to the permission configuration file. If the verification passes, it means that the information about the application to be installed meets the requirements and can be installed. Only then will the first system install the application to be installed. By setting the permission configuration file, the application installation in the first system can be customized to improve flexibility.

[0044] In the permission configuration file, the installation source whitelist, application blacklist and self-update whitelist are set; the priority between the three or the list that needs to be met for installation can be further configured; the three types of permission configuration methods combined with the priority or necessity settings further provide more detailed adjustable permissions and richer adjustment dimensions, which can adapt to user needs in different scenarios.

[0045] The following is a detailed introduction to the application embodiments of the present application. The present application can apply the above-mentioned solution to various electronic devices, perform permission verification during the application installation process, especially in financial terminals such as POS machines and cash registers, to ensure the security of the financial terminal use process.

[0046] (1) The first system obtains the permission configuration file, stores the permission configuration file in the trusted execution environment (TEE) of the second system, and the trusted applications (TA) in the second system operate the permission configuration file. This is equivalent to the above step 211.

[0047] Specifically, after the first system obtains the permission configuration file, it sends it to the corebridge service (link service). The coregridge service establishes a secure link with the TA's interactive interface and sends the permission configuration file to the TA's interactive interface, so that the TA can save the permission configuration file in the TEE.

[0048] It also includes calling role permission verification, that is, adding SE (Security-Enhanced) permissions for the specified caller in the second system. When the corebridge service sends data to the interactive interface, the interactive interface verifies the permission of the data sender, so that even if the corebridge service is leaked, the second system cannot be accessed directly through the corebridge service, further improving security. This is equivalent to the above steps a and b.

[0049] Among them, the permission configuration files include the installation source whitelist, application blacklist, and self-update whitelist. The installation source whitelist limits the installation source, and the package name can be configured in the installation source whitelist, such as the package name of the application market. The application blacklist restricts applications that are not allowed to be installed. While restricting third-party applications from installing other applications, the self-update whitelist retains its permission to self-update, allowing third-party applications to update themselves, facilitating vulnerability repairs and function upgrades. Storing all three types of permission configuration files in the TEE environment and operated by TA can effectively prevent hacker attacks.

[0050] Among them, when the electronic device is turned on and activated for the first time, the first system can connect to the network and request the background server to obtain the permission configuration file and finally write it into the TEE environment of the second system. Then, during the process of the first system performing the application installation operation, the permission configuration file in the second system can be called according to the relevant security specifications to verify whether the application can be installed, thereby improving the security of the permission configuration file and effectively preventing the permission configuration file from being tampered with. If the permission configuration file is directly stored in the first system, for example, directly stored in the Android operating system, the user can have the operation permission to the permission configuration file after obtaining the root permission (super administrator permission) and thus modify the permission configuration file. If the permission configuration file is placed in the TEE, even if the root permission is leaked, the TEE cannot be accessed.

[0051] See attached Figure 3 TEE is an independent execution environment that runs with the Android operating system (equivalent to the first system), runs trusted code and stores / processes sensitive data. All operations that need to be kept confidential are performed in the secure world, such as fingerprint recognition, password processing, data encryption and decryption, security authentication, etc. The data stored in TEE cannot be directly modified by the first system and needs to be verified by the second system.

[0052] (2) The first system obtains apk information (information of the application to be installed), which is equivalent to the above step 210.

[0053] (3) Read the permission configuration file in the second system through the corebridge service and interactive interface, and verify the application information to be installed according to the permission configuration file. This is equivalent to the above step 220. The specific verification process is described below: ① When verifying the apk information during the application installation process, obtain whether the installation source whitelist is configured in TEE. If so, obtain the installation source whitelist through the trusted application. If it matches the apk information, continue the installation process; if the package name of the application market is configured, the verification is passed if the apk information matches the application market package name. If it does not match, such as a browser, folder, or adb command, etc., an installation source error message is thrown and the application installation is stopped. apk is the format of the Android system installation package ② When verifying the apk information during the application installation process, obtain whether the application blacklist is configured in the TEE. If so, obtain the application blacklist through the trusted application. If it matches the apk information, throw the application as a blacklist application information upward, otherwise the verification passes.

[0054] ③ When verifying the apk information during the application installation process, obtain whether the self-update whitelist is configured in the TEE. If so, obtain the self-update whitelist through the trusted application. If it matches the apk information, the verification passes, otherwise the insufficient permission information is thrown upward.

[0055] (4) If the verification is successful, the first system performs the application installation operation according to the apk information, which is equivalent to the above step 230.

[0056] To summarize, after obtaining the permission configuration file through the first system, the permission configuration file can be stored in the TEE of the second system. The first system requests the server to obtain or update the permission configuration file and stores it in the second system. The second system only interacts with the first system. The security of the second system is further guaranteed on the basis of using TEE through environmental isolation. When accessing the second system, not only TEE authentication is required, but also double verification of the caller's identity is added in the second system to further ensure the security of the permission configuration file. Through the dual protection of TEE and identity verification, even if the first system obtains root permissions, the permission configuration file in the second system cannot be directly obtained.

[0057] Please refer to the attached Figure 4 The present invention also provides an electronic device 300, including a memory 301 and a processor 302, and a computer program stored in the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the various steps in the above-mentioned application installation management method.

[0058] The beneficial effects of the electronic device of the present invention are the same as those of the above method and will not be described in detail here.

[0059] The above are only embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the specification and drawings of the present invention, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A rights management system, characterized in that: Applied to electronic equipment, the system comprises a first system and a second system which are independent of each other; The first system is used for application installation; The second system is used to store the authority configuration file and provide security verification according to the authority configuration file when the first system installs the application; The second system includes a trusted execution environment, and the rights configuration file is stored in the trusted execution environment.

2. A rights management system according to claim 1, characterized in that: Also included is a link service, the link service being used for communication between the first system and the second system; The first system is used to receive an operation request and send the operation request to the link service; The second system includes a trusted application; The trusted application includes an interactive interface, and the interactive interface is used to communicate with the link service and receive the operation request forwarded by the link service; The trusted application is used to receive an operation request and operate the authority configuration file according to the operation request.

3. A rights management system according to claim 2, characterized in that: The first system is also used to obtain the rights profile when activated and send the rights profile to the link service; The second system is further configured to receive the authority configuration file through the interactive interface and save the authority configuration file.

4. A rights management system according to claim 2, characterized in that: The interactive interface is also used to perform identity authentication when receiving the operation request. If the identity authentication is successful, the step of receiving the operation request forwarded by the link service is executed.

5. An application installation management method, characterized in that: The method is implemented by a rights management system according to any one of claims 1 to 4, comprising: The first system obtains information of applications to be installed; The first system reads the authority configuration file in the second system through the interactive interface, and verifies the application information to be installed according to the authority configuration file; If the verification is successful, the first system performs an application installation operation according to the information of the application to be installed.

6. The application installation management method according to claim 5, characterized in that: The permission profile includes a whitelist of installation sources; The verifying the to-be-installed application information according to the authority configuration file includes: The first system obtains the first initiator information in the application information to be installed, and determines whether the first initiator information is in the installation source whitelist. If so, the verification is passed; otherwise, an installation source error is prompted and the application installation process is stopped.

7. The application installation management method according to claim 5, characterized in that: The permission configuration file includes an application blacklist; The verifying the to-be-installed application information according to the authority configuration file includes: The first system obtains identification information of the application in the to-be-installed application information, and determines whether the identification information is in the application blacklist. If so, it indicates that there is a blacklist application and stops the application installation process. Otherwise, the verification is passed.

8. The application installation management method according to claim 5, characterized in that: The permission profile includes a self-updating whitelist; The verifying the to-be-installed application information according to the authority configuration file includes: The first system obtains first initiator information in the to-be-installed application information, and determines whether the first initiator information is in the self-update whitelist; If so, obtain the identification information of the application in the application installation request, and determine whether the identification information matches the first initiator information. If so, the verification is successful. Otherwise, it is prompted that the corresponding permission does not exist and the application installation process is stopped.

9. The application installation management method according to claim 5, characterized in that: The second system sets the allowed access roles of the trusted application and the access rights corresponding to each of the allowed access roles, wherein the access rights include read-only and read-write; The first system reading the authority configuration file in the second system through the interactive interface includes: The second system verifies whether the first system matches the allowed access role, and if so, allows the first system to read the rights profile.

10. An electronic device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and running on the processor, and when the processor executes the computer program, it implements an application installation management method as described in any one of claims 5-9.

Images