An apparatus and method for dynamically configuring trusted application access control

Abstract

A processor to provide REE and TEE, wherein memory in the TEE is protected from access or modification by applications executing in the REE. The processor installs a client application in the REE and verifies a signature generated using a service provider private key. The processor determines that the client application requires a service from a TA, contacts an external entity, and receives a service provider public key and data for installing the TA. The key and the data are securely transferred to the TEE. The processor configures a secure domain in the TEE, installs the TA in the secure domain, and associates the TA with the secure domain, wherein the secure domain is also associated with the service provider public key. The processor configures an access control list within the secure domain, wherein access to the TA is controlled by the access control list.

Description

TECHNICAL FIELD

[0001] Various aspects of the present disclosure generally relate to mobile computing devices, and more particularly, to software security within mobile computing devices. BACKGROUND

[0002] Mobile computing devices or devices, such as cell phones or other communication-enabled mobile computing devices, typically include multiple execution environments to enhance security and protect important confidential data and processes. Generally, a first execution environment, referred to as a rich execution environment (REE), includes a full-featured operating system (OS), such as the Android operating system produced by Google, Inc. or iOS produced by Apple, Inc., and a rich set of supporting software services. The REE is used to host user applications that require a rich, full-featured user experience. A second execution environment, referred to as a trusted execution environment (TEE) or secure execution environment (SEE), includes a much smaller set of software services and typically includes hardware-based security features to protect confidential data and programs stored in the TEE. The reduced amount of software executing within the TEE improves security by reducing attack vectors and reducing possible software defects.

[0003] Sensitive applications, such as cryptographic operations and related confidential key material, are typically protected within the TEE using hardware-based security features. The TEE exposes services through a controlled and well-defined interface that can be accessed by client applications (CAs) executing within the REE. Trusted applications (TAs) expose the services consumed by the CAs. An example of a CA- TA pair is an Android payment application executing within the REE that needs to access a trusted cryptographic signing application executing within the TEE in order to sign a payment transaction using an approved signing key. The signing key is an example of confidential key material protected within the TEE. The signing algorithm and signing key are kept within the TEE and are not accessible outside the TEE. Only the signing service can access through the REE-TEE interface. Malware running in the REE cannot access the private key or cryptographic service and therefore cannot misuse or distribute the signing key or associated cryptographic service. An attacker must use the actual physical device to sign a payment message.

[0004] An attacker can still compromise the payment process by running a malicious application in the REE that masquerades as a legitimate payment application, thereby tricking the payment TA into signing fraudulent messages. Ideally, the TEE or TA includes protections to prevent the use of a rogue trusted application.

[0005] One approach is to include a trusted user interface within the TEE, so that the TA does not need to accept input directly from the REE. Adding additional software to the TEE environment increases the chance that the TEE will be compromised. Furthermore, the trusted user interface will have a distinct look and feel from the user interfaces of REE applications, so the companion portion of the application running in the REE will appear distinctly different, resulting in a poor user experience.

[0006] Alternatively, access control mechanisms can be included in the REE, such as is done in the SE Android operating system produced by Google, Inc., to make the TEE available only to certain REE-side CAs. Unfortunately, these schemes tend to be very complex, making them difficult to maintain or modify, and risky to maintain or modify. Furthermore, these schemes rely on software running in the REE, and are therefore vulnerable to tampering, and cannot provide the high level of security required for certain types of TAs.

[0007] Accordingly, there is a need to provide methods and apparatus that address at least some of the problems noted above. SUMMARY

[0008] It is an object of the disclosed embodiments to provide improved methods and apparatus that enable secure and efficient access to trusted applications within a mobile computing device. This object is addressed by the subject matter of the independent claims. Other advantageous modifications can be found in the dependent claims.

[0009] According to a first aspect, the above and further objects and advantages are achieved by an apparatus comprising a processor coupled to a memory, wherein the processor and the memory are configured to provide a rich execution environment and a trusted execution environment. The memory and processes in the trusted execution environment are protected from access or modification by applications executing within the rich execution environment. The processor is configured to install a first client application within the rich execution environment, wherein the first client application comprises a signature generated based on a service provider private key and determine that the first client application requires a service from a trusted application. The processor is configured to send a request to an external entity to install the trusted application; receive one or more messages within the rich execution environment, wherein the one or more messages comprise a service provider public key corresponding to the service provider private key and data for installing the trusted application; and securely transfer the one or more messages to the trusted execution environment. The processor is configured to configure a security domain within the trusted execution environment, wherein the security domain is associated with the service provider public key; install the trusted application within the trusted execution environment; and associate the trusted application with the security domain. The processor is configured to configure an access control list within the security domain (SD), wherein access to the trusted application is controlled by the access control list. Configuring the SD and the access control list makes the TA more secure and access control better. Without a specified ACL configuration, access to the TA can be achieved by allowing any CA to access the TA or allowing the TA to serve only a predefined CA. Allowing all CAs to access the TA creates a serious security risk, while allowing access based on a predefined list is problematic because it is not possible to expose security critical services provided by the TA to any new CA developed after the TA is installed.

[0010] According to a first aspect, in a first possible implementation form of the apparatus, the processor is configured to generate, within the rich execution environment, an access request to the trusted application from a second client application. The processor identifies the second client application and obtains an application public key corresponding to the second client application from an installation package, wherein the installation package comprises the second client application and the application public key. The processor securely transmits the access request and the application public key to the trusted execution environment and determines, within the trusted execution environment, whether the second client application is authorized to access the trusted application. The determination is based on the application public key and the access control list. In case the second client application is authorized, the processor is configured to allow the second client application to access the trusted application. Verifying each request according to the access control list can reliably authorize the request before forwarding each access request to the trusted application.

[0011] According to the first aspect as such or according to the first possible implementation form of the apparatus, in a possible implementation form of the apparatus, the application public key comprises an application certificate and the processor is configured to securely transmit the application certificate to the trusted execution environment. Using an application certificate can verify the authenticity and integrity of the public key and other information associated with the client application.

[0012] According to the first aspect, in a possible implementation form of the apparatus, the access control list comprises a plurality of application public keys and the processor is configured to allow access to the trusted application based on the plurality of public keys. Including a plurality of public keys in the access control list can modify access to the trusted application without installing an update or a plurality of copies of the TA.

[0013] According to the first aspect, in a possible implementation form of the apparatus, the application public key is the same as the service provider public key and the processor is configured to allow or deny access to the trusted application based on the application public key and the access control list. Using the same public key for the client application and the service provider can guarantee that the trusted application, the secure domain and the client application are all provided by the same source.

[0014] According to the first aspect, in a possible implementation form of the apparatus, the secure domain is associated with a plurality of trusted applications and the processor is configured to allow access to any of the plurality of associated trusted applications based on the access control list. Installing a plurality of trusted applications in a single secure domain simplifies access by avoiding an unnecessary proliferation of secure domains in the TEE.

[0015] According to a possible implementation form of the apparatus according to the first aspect, the apparatus is a mobile communication device. Since mobile communication devices are always carried by a user, it becomes increasingly important to improve the security of these devices.

[0016] According to a possible implementation form of the apparatus according to the first aspect, the processor is configured to determine that a second client application requires access to the trusted application. The processor is configured to send a request to the external entity to allow the second client application to access, receive one or more messages within the rich execution environment, and securely transmit the one or more messages to the trusted execution environment, wherein the one or more messages comprise an application public key corresponding to the second client application and data for updating the access control list. The processor is configured to update the access control list based on the application public key, wherein the update is to allow the second client to access the trusted application. Including a plurality of public keys in the access control list enables a plurality of client applications to access the same trusted application without having to install a plurality of copies of the trusted application signed by different public keys.

[0017] According to a possible implementation form of the apparatus according to the first aspect, the access control list comprises access rules and the processor is configured to allow access to the trusted application based on the access rules. When there are a plurality of public keys and / or a plurality of trusted applications in the secure domain, including access rules and / or permissions in the access control list provides an improved method of access control.

[0018] According to a second aspect of the disclosed embodiments, the above and further objects and advantages are achieved by a method comprising installing a client application within the rich execution environment, wherein the client application comprises a signature generated based on a service provider private key, and determining that the client application requires a service from a trusted application. The method sends a request to an external entity to install the trusted application; receives one or more messages within the rich execution environment, wherein the one or more messages comprise a service provider public key corresponding to the service provider private key and data for installing the trusted application; and securely transfers the one or more messages to the trusted execution environment. The method configures a secure domain within the trusted execution environment, wherein the secure domain is associated with the service provider public key; installs the trusted application within the trusted execution environment; and associates the trusted application with the secure domain. The method configures an access control list within the secure domain, wherein access of the client application to the trusted application is controlled by the access control list. Configuring the SD and the access control list makes the TA more secure and the access control better.

[0019] According to the second aspect, in a first possible implementation form of the method, the method generates, within the rich execution environment, an access request of a second client application to the trusted application, identifies the second client application, and obtains an application public key corresponding to the second client application from an installation package. The installation package comprises the second client application and the corresponding application public key. The method securely transfers the access request and the application public key to the trusted execution environment, and determines, within the trusted execution environment, whether the second client application is authorized to access the trusted application, wherein the determination is based on the application public key and the access control list. In case the second client application is authorized, the method allows the second client application to access the trusted application. Verifying each request according to the access control list can reliably authorize the request before forwarding each access request to the trusted application.

[0020] According to the second aspect, in a possible implementation form of the method, the application public key comprises an application certificate, and the method comprises securely transferring the application certificate to the trusted execution environment. Using an application certificate can verify the authenticity and integrity of the public key and other information associated with the client application.

[0021] According to the second aspect as such, in a possible implementation form of the method, the access control list comprises a plurality of public keys, and the method allows access to the trusted application based on the plurality of public keys. Including a plurality of public keys in the access control list allows modifying access to the trusted application without installing an update or a plurality of copies of the TA.

[0022] According to the second aspect, in a possible implementation form of the method, the application public key is the same as the service provider public key, and the method allows or denies access to the trusted application based on the application public key and the access control list. Using the same public key for the client application and the service provider can guarantee that the trusted application, the secure domain and the client application are all provided by the same source.

[0023] According to the second aspect, in a possible implementation form of the method, the secure domain is associated with a plurality of trusted applications, and the method allows access to any one of the plurality of associated trusted applications based on the access control list. Installing a plurality of trusted applications in a single secure domain simplifies access by avoiding an unnecessary proliferation of secure domains in the TEE.

[0024] According to a third aspect of the disclosed embodiments, the above mentioned and other objectives and advantages are achieved by a computer program product comprising non-transitory computer program instructions for causing a processor to perform the method according to the second aspect as such or according to any one of the possible implementation forms of the second aspect.

[0025] These and additional aspects, implementation forms and advantages of the example embodiments will be apparent from the embodiments described herein in conjunction with the accompanying drawings. It should be understood, however, that the specification and drawings are designed solely for purposes of illustration and are not intended to limit the definition of the disclosed embodiments, for which reference should be made to the appended claims. Additional aspects and advantages of the application will be set forth in the description that follows, and in part will be obvious from the description, or can be learned by practice of the application. Moreover, the aspects and advantages of the application can be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims. BRIEF DESCRIPTION OF DRAWINGS

[0026] In the following detailed portion of the disclosure, the application will be explained in greater detail by referring to the exemplary embodiments illustrated in the drawings in which:

[0027] Figure 1 is a block diagram of a secure software distribution and installation process 100 in connection with aspects of the disclosed embodiments;

[0028] Figure 2 is a block diagram of a mobile computing device for controlling access to a trusted application based on an access control list in accordance with aspects of the disclosed embodiments;

[0029] Figure 3 is a flow diagram of an exemplary method for installing a TA and configuring an access control list within a TEE in accordance with aspects of the disclosed embodiments; and

[0030] Figure 4 is shown a flow diagram of an exemplary method for allowing access to a trusted application in accordance with aspects of the disclosed embodiments. DETAILED DESCRIPTION

[0031] Referring to Figure 1 , Figure 1 A block diagram of a secure software distribution and installation system 100 in accordance with aspects of the disclosed embodiments is shown. Aspects of the disclosed embodiments relate to a device 110 that includes a processor 150 coupled to a memory 152, 154. The processor 150 and the memory 152, 154 are used to provide a rich execution environment (REE) 112 and a trusted execution environment (TEE) 114. The memory 154 and processes 122, 128, 140 in the trusted execution environment 114 are protected from access or modification by applications 116, 117 executing within the rich execution environment 112.

[0032] In one embodiment, the processor 150 is used to install a first client application 116 within the rich execution environment 112, where the first client application includes a signature generated based on a service provider private key. The processor 150 is also used to determine that the first client application requires a service from a trusted application 122, and then send a request to an external entity 106 to install the trusted application.

[0033] The processor 150 is used to receive one or more messages within the rich execution environment, where the one or more messages include a service provider public key corresponding to the service provider private key and data for installing the trusted application. The processor 150 is also used to securely transfer the one or more messages to the trusted execution environment 114 and configure a secure domain 120 within the trusted execution environment 114. The secure domain 120 is associated with the service provider public key 126.

[0034] The processor 150 is configured to install the trusted application 122 within the trusted execution environment 114, associate the trusted application 122 with the secure domain 120, and configure an access control list 128 within the secure domain 120. Access to the trusted application 122 is controlled by the access control list 128.

[0035] As used herein, the term digital signature or signature refers to a non-reproducible binary value derived from an encryption of the contents of a computer file, message, or other digital data set. The signature can verify the authenticity and integrity of the digital data set. The signature can be generated based on an industry standard signature algorithm, such as the signature algorithm defined in Request for Comments 3279 (RFC 3279) maintained by the Internet Engineering Task Force (IETF), or can be based on any suitable signature algorithm capable of verifying the authenticity and integrity of a digital data set.

[0036] As used herein, the terms private key and public key refer to two keys of a key pair of a suitable asymmetric cryptographic algorithm, such as the Rivest-Shamir-Adleman (RSA) cryptography, elliptic curve cryptography (ECC), or other suitable public-key or asymmetric cryptographic algorithm. Data encrypted using a public key can only be decrypted using an associated or corresponding private key from the same encryption key pair, and vice versa.

[0037] As used herein, the term secure transmission or securely transmitting messages or data refers to a manner of protecting data or information when sending or transmitting data or information over a computer network. Messages and / or data can be securely transmitted over a secure communication channel that is configured or established between two entities. The secure communication channel authenticates both entities and ensures privacy of messages or data sent over the secure communication link. Secure transmission can be achieved by establishing a secure communication channel based on a security protocol and exchanging information or messages over the secure communication channel. For example, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are protocols that provide privacy and authentication at a lower level of the protocol stack and can provide a method of securely transmitting data over a network. Ensuring security of communications at the transport layer or session layer can provide sufficient security for many applications, but can not be sufficient to provide security for all applications. Alternatively, information can be securely transmitted using higher level protocols, such as Open Trust Protocol (OTrP) developed as part of the Global Platform industry initiative or other proprietary security protocols. These higher level protocols can include pre-defined dialogs and sessions and can embed nonce values in each message, thereby securely transmitting messages and data that have a higher degree of privacy, authenticity and integrity. One example.

[0038] As used herein, the term secure domain refers to a logical construct in which a single homogenous security policy is applied to all security services or TAs provided or associated with a secure context or domain. A secure domain can be configured within a TEE for controlling access to security services provided by one or more TAs installed within the secure domain. Many security or trusted protocols, such as the OTrP described above, are configured to support the creation and management of secure domains within a TEE as a way of protecting certain TAs.

[0039] Software development companies and software vendors create applications for use on a variety of mobile computing devices, such as UE 110. Applications designed to run on UE 110 are distributed using a variety of entities or online services 102 that are external to UE 110 and are accessible from UE 110 over a variety of private and public computer networks, such as the Internet.

[0040] When a user application or software application is ready for distribution, the software and data associated with the application are assembled into a distribution package, such as an Android package (typically with an.apk file extension) or an iOS application archive (typically with an.ipa file extension). The service provider 104 uses the service provider's private key 127 to generate a digital signature based on the distribution package and includes the digital signature in the final distribution package 146. The distribution package 146 is then forwarded to the application repository 106, where it is available for distribution to the UE 110. These user applications are designed to run within the REE 112 of the UE 110, so they can be downloaded 134 directly from the application repository 106 and installed on the device through the OS executing within the REE 112 of the UE 110.

[0041] To facilitate the protection of sensitive information and algorithms, certain portions of software applications that handle security sensitive operations and data can be split into smaller and more easily protected applications, referred to herein as trusted applications (TAs). TAs are typically used to perform cryptographic or other important security operations and can include related confidential information or key material needed to perform the cryptographic functions. To protect the TAs from access, misuse, or tampering by malicious applications, the TAs are advantageously installed within a TEE.

[0042] TAs such as the TA 122 are designed to execute within the TEE 114, and thus require a more secure distribution process. To maintain the security and integrity of the UE 110, software executing within the REE 114 of the UE 110 is not authorized or allowed to make modifications to the software, data, or configuration of the TEE 114. The preparation of a distribution package 148 for a trusted software application is similar to the preparation of a normal world application, in that the software developer or vendor assembles all of the software and data for the TA into a distribution package, and the service provider 104 digitally signs the distribution package 148 using the service provider's private key 127. The distribution package 148 for the TA is then forwarded to an entity referred to herein as a trusted service manager (TSM) 108.

[0043] The TSM 108 is a service or entity external to the UE 110 that is accessible by the UE 110 through a private or public computer network. The TSM 108 can have access to confidential material, such as private cryptographic keys, that can be used to identify the TSM 108 to the TEE 114 of the UE 110 as being authorized to make modifications within the TEE 114, such as installing the TA 122. The authorized TSM 108 can download the TA 122 into the TEE 114 on the UE 110 or other mobile computing device, install the TA 122, and make other configuration changes to the environment within the TEE 114 while the mobile computing device is in the field. The trust anchor or other key material can be embedded in the TEE 114 at the time of manufacture or provisioning of the UE 110, which can establish a highly secure network connection between the TEE 114 and the TSM 108. These trust anchors and keys secure the TEE 114 and ensure the integrity and privacy of communications between the TEE 114 and the TSM 108. Only authorized TSMs 108 are permitted to modify or communicate with a given TEE 114.

[0044] When the application is needed, the UE 110 can contact the application repository 106 and download 134 the required application package 146. Once downloaded, the application package 146 can be used to install the software application 116 in the REE 112 of the UE 110. The software application 116 will be referred to herein as a client application (CA) 116. The term CA is used because the CA 116 acts as the client side of a standard client-server software model, where the CA 116 is used to send requests that are received and processed by system services, such as the cryptographic or other services provided by the TA 122.

[0045] After the required application package 146 is downloaded, the UE 110 can obtain the public key 126 corresponding to the private key 127, preferably through an alternate communication channel, and use the public key 126 to verify the required application package 146. The required application package 146 can also be referred to as a distribution package, which is used to distribute and install the CA 116. The public key 126 that can be used to verify the distribution package 146 is referred to herein as being associated with the CA 116. The public key 126 associated with the CA 116 is referred to herein as the application public key. As used herein, the term application public key refers to a public key associated with a CA that can be used to verify a distribution package used to distribute the CA.

[0046] To meet the security requirements of highly sensitive applications, the UE 110 is configured to support multiple computing environments as described above. The processor 150 is configured to provide a REE 112 that executes within a portion of the memory 152. The TEE 114 runs in a secure region of the host processor 150 and a secure portion of the memory 154, and is configured to provide an isolated execution environment separate from the REE 112 while ensuring the integrity and confidentiality of data and program code loaded within the TEE 114. The memory 154 and processes executing within the TEE 114 are protected from modification or access by processes executing within the REE 112.

[0047] During or after installation of the CA 116, an OS or other process executing within the REE 112 can detect that the CA 116 requires services from the TA 122. The need for the TA 122 can be detected when the CA 116 is installed on the UE 110, or alternatively, can be detected at a later time, for example, when the CA 116 is executed, or during a scan or other operation performed within the REE 112. Upon detecting the need for the TA 122, the UE 110 will send a message to the trusted service manager (TSM) 108 requesting installation of the TA 122 to obtain the required TA 122.

[0048] To enable the TA 122 to be securely transferred, configured, and installed within the TEE 114, the TSM 108 establishes a secure communication channel 138 between the TSM 108 and the TEE 114. A trusted communication agent 118 is included in the REE 112 to facilitate establishment of the secure communication channel 138. In one embodiment, the secure communication channel 138 can be based on the OTrP discussed above. For the OTrP, the trusted communication agent 118 is an implementation of the OTrP agent that is configured to establish the secure communication channel between the TSM 108 and the OTrP TA 140 executing within the TEE 114.

[0049] Installation of the TA 122 within the TEE 114 involves multiple steps managed or controlled by the TSM 108. Once the secure communication channel 138 is established by the TSM 108, one or more messages are exchanged between the TSM 108 and the TEE 114 to create a security domain (SD) 120 within the TEE 114, install the TA 122 within the SD 120, and configure an access control list 128 associated with the SD 120.

[0050] The SD 120 is associated with the service provider 104 and includes a public key 126 of the service provider that can be used to identify and authorize access to and management of the SD 120. Optionally, the public key 126 can be embedded in a public key certificate, such as an X.509 certificate that has been signed or issued by a trusted certificate authority.

[0051] The TSM 108 configures an access control list 128 within or associated with the SD 120 through one or more messages. The access control list 128 is advantageously stored in memory 154 protected within the TEE 114, thereby protecting the access control list 128 from modification by applications or software processes executing outside of the TEE 114, such as programs executing in the REE 112.

[0052] By including identifying information associated with the CA 116, such as the public key 126, in the access control list 128, the access control list can be used to determine which CAs 116 can be allowed to access the TAs 122. When a CA 116 requests access to a particular TA 122, the public key 126 or other identifying information from the CA 116 is checked against the access control list 128 to determine whether the CA 116 is authorized to access the requested TA 122. Optionally, the access control list 128 can associate rules or permissions with the identifying information to further guide access to the TAs 122.

[0053] In certain embodiments, it is desired to allow a second CA 117 to access a TA 122 that has already been installed in the SD 120. When the second CA 117 is associated with an application public key 129, where the application public key 129 is different from the public key associated with the first CA 116, the second CA 117 can not be allowed to access the SD 120 or the TA 122. One method of allowing the second CA 117 to access the TA 122 is to create a second SD (not shown) and install a second copy of the TA 122 in the second SD using the same process as described above. However, installing a second copy of the TA 122 not only wastes computing resources, but can also introduce other software related issues such as version control.

[0054] The disclosed embodiments provide an improved solution to update the access control list 128 to allow the second CA 117 to access the TA 122 that was previously installed in the SD 120. The access control list 128 can be updated by adding the application public key 129 or other identifying information of the second CA 117.

[0055] As described above, any modification of the TEE 114 must be made by the TSM 108 over the secure communication channel 138. Configuration of the access control list 128 is initiated by sending a message from the UE 110 to the TSM 108 requesting authorization for the second CA 117 to access the TA 122. The TSM 108 establishes a secure channel 138 with the TEE 114 and sends one or more messages over the secure communication channel 138 to update or add the private key 129 or other identifying information to the access control list 128. Optionally, access rules or permissions can be configured in the access control list 128 to facilitate the access control decision for the second CA 117.

[0056] Figure 2 A block diagram of a UE 200 is shown, illustrating a process for controlling access of CAs 116, 117 to TAs 122, 228, incorporating various aspects of the disclosed embodiments. Figure 2 The UE 200 shown in FIG. 2 is similar to the UE 110 shown in FIG. 1, where like numbers refer to like elements. The 200 includes a second TA 228 that has been installed in the SD 120 by the TSM 108 according to the process described above. Figure 1

[0057] In operation, when the CA 116 executing within the REE 112 requires service of the TA 122, the CA 116 generates an access request 248 to the TA 122. The access request 248 can be any request for a service process supported by the TA 122. For example, the access request 248 can be a request to generate a digital signature for a retail purchase, or can be a request to decrypt a media file or to encrypt a banking transaction, etc.

[0058] The trusted agent or daemon (teecd) 214 receives the access request 248, identifies the CA 116, and retrieves 250 the application public key or certificate 230 from, for example, the Android manifest. The application certificate 230 uniquely identifies the signer of the client application distribution package 210 and includes a public key that can be used to identify the CA 116. In certain embodiments, the certificate 230 can be a certificate of the service provider 104 and include the service provider public key 126. Optionally, the certificate 230 can be different from the certificate of the service provider 104, but can still include the same public key as the service provider public key 126.

[0059] ​The client certificate 230 and associated access request 248 are securely transmitted 254 to the TEE 114. Any suitable manner of securely transmitting the access request 248 and associated application certificate 230 from the REE 112 to the TEE 114 can be advantageously employed. For example, in one embodiment, the UE 110 employs an Android OS within the REE 112. In the example of the Android OS, the application certificate 230 can be copied into memory managed by the OS kernel and securely transmitted to the TEE 114 by using a shared memory space. The access request 238 is securely transmitted 252, 254 through a TrustZone driver 212 executing within the OS of the REE 112 and a REE connection agent 226 executing within the TEE 114. Those skilled in the art will readily recognize that any manner of securely transmitting the access request 248 along with the application certificate 230 or corresponding public key to the TEE 114 can be advantageously employed without departing from the spirit and scope of the disclosed embodiments.

[0060] Verification of the access request 248 and the application certificate 230 and / or public key is performed by an access control list (ACL) verification point process 224 within the TEE 114. The ACL verification point process 224 checks 258 the public key associated with the access request 248 against the access control list 128 to determine whether the requested access should be allowed. Optionally, the ACL verification point process 224 can be included in a TA loader 280 that is used to load and prepare the TA 122 for execution within the TEE 114. In one embodiment, the ACL verification point process 224 allows access to the TA 122 when the public key included in the access request 248 is present in the access control list 128. Alternatively, the ACL verification point process 224 can include additional logic to allow or deny access based on rules or permissions associated with each public key in the access control list 128. When access is allowed, the request 248 is passed to the TA 122 for processing, and any results generated by the TA 122 can be returned to the CA 116.

[0061] In certain embodiments, it can be necessary to load the TA 122 prior to passing the access request 248 to the TA 122. When the TA 122 is loaded, the TA loader 280 can check the TA installation data 282 to verify that the public key included in the TA installation data 282 matches the CA 116 public key 126.

[0062] In certain embodiments, a second CA 117 associated with a different public key 129 can also require access to the TA 122. As described above, the access control list 128 can be updated to include the public key 129 associated with the second CA 117. The ACL verification point 224 can then be used to allow access based on the second public key 129 in the access control list 129.

[0063] In certain embodiments, multiple TAs 122, 228 can be installed in a single SD 120. When the SD 120 includes multiple TAs 122, 228, it can be desirable to allow certain CAs 116 to access the TAs 122, 228 simultaneously, and restrict a second CA 117 to access only a second TA 228. These additional access rules can be used, for example, to determine which CA 116, 117 can access which TA 122, 228. Alternatively, the access rules can provide more fine-grained control to allow one CA 116 to access a particular set of services provided by a TA 122, and allow a second client application 117 to access a different set of services provided by the TA 122.

[0064] Figure 3 An exemplary method 300 for installing a TA and configuring an access control list within a TEE is shown in connection with aspects of the disclosed embodiments. The exemplary method 300 begins when a CA is installed 302 into the REE of a mobile computing device or UE. Upon installation of the CA, the UE can determine 304 that the services of a TA are required. Alternatively, the UE can make the determination 304 at some time after installation, such as when the CA is loaded and executed.

[0065] The UE sends a request 308 to an external entity, such as a TSM, to obtain the required TA. To protect the security of the TEE, programs executing outside the TEE, such as user applications or operating system services executing in the REE, have no authority to make modifications to the data, program code, or configuration of the TEE. The external entity or TSM possesses secret material, such as a private key, that indicates its authority to install TAs on a particular UE and to modify the data and configuration of the TEE.

[0066] A secure communication channel is established between the external entity and the TEE, such as the secure communication channel 138 described above. Various components executing within the REE can participate in establishing the secure communication channel, but none of these components can view or modify any messages passing through the secure communication channel. All messages exchanged between the external entity and the UE are securely transmitted to the TEE 312.

[0067] The secure communication channel between the UE and the external entity can be based on any appropriate type of computer network, such as an air interface or a hardware-based network. Examples of appropriate air interfaces include any mobile phone air interface standard, such as LTE, LTE-advanced, etc., or a wireless network such as Wi-Fi, or any other air interface that can support a computer network. A hardware-based network is any computer network method that uses copper cable, fiber optic, or other physical connections between network nodes.

[0068] A secure domain is created 314 within the TEE. The secure domain creates a logical separation or container for providing an isolated space within the TEE in which programs and data can be protected from access or tampering by unauthorized programs within the secure domain.

[0069] The TA is installed within and associated with the secure domain 320. Associating the TA with the secure domain allows only processes that are authorized to access the secure domain to access the TA, thereby protecting the TA.

[0070] An access control list is created and / or configured within each secure domain 322. The access control list is used by an ACL verification point process or similar process to determine whether access requests by a particular TA should be allowed. The access control list can include a list of public keys or other information suitable to identify which CAs are authorized to access TAs within the SD. Optionally, the access control list can include additional rules or permissions associated with each public key to further guide access decisions.

[0071] In certain embodiments, it is desired to allow a second CA to access a TA installed within the SD. This can be accomplished by updating the access control list to include a public key or other identifying information associated with the second CA. The UE can send a message to the TSM or other external entity that is authorized to access and modify the TEE when needed. In response, the TSM or other external entity can establish a secure communication channel with the TEE and update the access control list to include the additional public key or other needed information.

[0072] Figure 4 A flowchart illustrating an exemplary method 400 for allowing access to a trusted application in connection with aspects of the disclosed embodiments is shown. For ease of understanding, the exemplary method 400 will be described below with respect to an Android OS-based UE. Those skilled in the art will readily recognize that the exemplary method 400 can be advantageously used to control access to TAs on any UE having a REE and a TEE without departing from the spirit and scope of the disclosed embodiments.

[0073] When a CA executing within the REE of a UE requires service from a TA, the CA generates 402 an access request including any information needed by the TA to process the requested operation. Processes executing in the REE, such as components of the OS, identify and validate 404 the CA and the access request. The public key associated with the CA is obtained 406, for example, by retrieving the application certificate from the Android manifest associated with the CA. The access request is securely transmitted 410 to the TEE along with the public key or application certificate. An ACL validation point process executing within the TEE receives the access request along with the public key of the CA and determines whether the CA is authorized 410 to access the TA. This determination can be based on the public key or other identifying information included in the access request, as well as an access control list associated with the SD on which the TA is installed. When the ACL validation point determines that access should be allowed 412-Y, the access request is forwarded 414 to the TA, and when access is denied 412-N, the access request is denied 418.

[0074] In certain embodiments, the access control list includes a plurality of public keys or identifying information. In this case, a second CA having a different public key than the SD can be allowed access when one of the plurality of public keys in the access control list corresponds to the public key of the second CA.

[0075] Optionally, the SD can have more than one TA installed. The ACL validation point can be used to allow access to one or more TAs based on the public key associated with the access request.

[0076] Thus, although there have been shown, described and pointed out fundamental novel features of the application as applied to the exemplary embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of devices and methods can be made by those skilled in the art without departing from the spirit of the application. Further, it is expressly intended that all combinations of these elements and those that are particularly described herein-including any elements resulting from performing any of the methods described herein on any of the items, processes, or materials described herein or modifying any of the items, processes, or materials described herein-are to be within the scope of the application. Furthermore, it is expressly intended that all elements which are replacements for any elements described herein, which are "comparable" to any elements described herein, or which are "comparable" with respect to any "functionally similar" elements found in any described embodiment (whether or not such "comparable" elements are expressly described in the description) are to be within the scope of the application. In addition, many modifications can be made to adapt a particular situation or material to the teachings of the application without departing from its central scope. Therefore, it is to be understood that the application can be practiced otherwise than as specifically described without actually departing from the spirit and scope of the application as recited in the appended claims.

Claims

1. A device (110), characterized in that: The processor (150) includes a processor (150) coupled to memory (152, 154), wherein the processor (150) and the memory (152, 154) are used to provide a rich execution environment (112) and a trusted execution environment (114), wherein the memory (154) and processes in the trusted execution environment (114) are protected from access or modification by applications (116, 117) executing in the rich execution environment (112), and the processor (150) is used to: A first client application (116) is installed within the rich execution environment (112), wherein the first client application includes a signature generated based on the service provider's private key; It is determined that the first client application requires a service from a trusted application (122); Send a request to an external entity (106) to install the trusted application; Within the rich execution environment (112), one or more messages are received, wherein the one or more messages include a service provider public key corresponding to the service provider private key and data for installing the trusted application; Securely transmit the one or more messages to the trusted execution environment (114). A security domain (120) is configured within the trusted execution environment (114), wherein the security domain (120) is associated with the service provider's public key (126); The trusted application (122) is installed within the trusted execution environment (114). Associate the trusted application (122) with the security domain (120); and An access control list (128) is configured within the security domain (120), wherein access to the trusted application (122) is controlled by the access control list (128).

2. The device (110) according to claim 1, characterized in that, The processor (150) is used for: Within the rich execution environment (112), an access request for the trusted application (122) is generated from the first client application (116); Identify the first client application (116). Obtain the application public key corresponding to the first client application from the installation package (146), wherein the installation package (146) includes the first client application (116) and the application public key; The access request and the application public key are securely transmitted to the trusted execution environment (114). Within the trusted execution environment (114), it is determined whether the first client application (116) is authorized to access the trusted application (122), wherein the determination is based on the application's public key and the access control list (128); and If the first client application (116) is authorized, the first client application (116) is allowed to access the trusted application (122).

3. The device (110) according to claim 2, characterized in that, The application public key includes an application certificate, and the processor is used to securely transmit the application certificate to the trusted execution environment (114).

4. The apparatus (110) according to any one of claims 1-3, characterized in that, The access control list (128) includes multiple application public keys, and the processor (150) is used to allow access to the trusted application (122) based on the multiple public keys.

5. The apparatus (110) according to claim 2 or 3, characterized in that, The application public key is the same as the service provider public key (126), and the processor (150) is used to allow or deny access to the trusted application (122) based on the application public key and the access control list (128).

6. The apparatus (110) according to any one of claims 1-3, characterized in that, The security domain is associated with a plurality of trusted applications (122, 228), and the processor is configured to allow access to one or more of the plurality of associated trusted applications (122, 228) based on an access control list (128).

7. The apparatus (110) according to any one of claims 1-3, characterized in that, The device (110) is a mobile communication device.

8. A method (300), characterized in that, include: Install a (302) client application within a rich execution environment, wherein the client application includes a signature generated based on the service provider's private key; It is determined (304) that the client application requires a service from a trusted application; Send a request (308) to an external entity to install the trusted application; Receive (310) one or more messages within the rich execution environment, wherein the one or more messages include a service provider public key corresponding to the service provider private key and data for installing the trusted application; Securely transmit (312) the one or more messages to the trusted execution environment; Configure a security domain (314) within the trusted execution environment, wherein the security domain is associated with the service provider's public key; Install the trusted application (318) within the trusted execution environment; Associate the trusted application with the security domain (320); and Configure an access control list (322) within the security domain, wherein access to the trusted application by a client application is controlled by the access control list.

9. The method (300) according to claim 8, characterized in that, The method (300) further includes: Within the rich execution environment, an access request for the trusted application is generated (402) from the second client application; Identify (404) the second client application; Obtain (406) the application public key corresponding to the second client application from the installation package, wherein the installation package includes the second client application and the corresponding application public key; The access request and the application public key are securely transmitted (408) to the trusted execution environment; Within the trusted execution environment, it is determined (410) whether the second client application is authorized to access the trusted application, wherein the determination is based on the application's public key and the access control list; and If the second client application is authorized, (414) the second client application is allowed to access the trusted application.

10. The method (300) according to claim 9, characterized in that, The application public key includes an application certificate, and the method includes: securely transmitting the application certificate to the trusted execution environment.

11. The method (300) according to any one of claims 8 to 10, characterized in that, The access control list includes multiple public keys, and the method includes: allowing access to the trusted application based on the multiple public keys.

12. The method (300) according to claim 9 or 10, characterized in that, The application public key is the same as the service provider public key, and the method includes: allowing or denying access to the trusted application based on the application public key and the access control list.

13. The method (300) according to any one of claims 8 to 10, characterized in that, The security domain is associated with multiple trusted applications, and the method includes: allowing access to any of the multiple associated trusted applications based on the access control list.

14. A computer program product, characterized in that, Includes non-transitory computer program instructions, which, when executed by a processor (150), cause the processor (150) to perform the method (300) according to any one of claims 8 to 11.

Images