Patent Description:
Mobile computing apparatus or devices, such as cell phones or other communication enabled mobile computing devices, often include multiple execution environments to enhance security and protect important confidential data and processes. Typically a first execution environment, referred to as a rich execution environment (REE), includes a fully features operating system (OS), such as the Android OS 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 where a rich fully featured user experience is required. A second execution environment, referred to as a trusted execution environment (TEE) or a secure execution environment (SEE), includes a much smaller set of software services and often includes hardware based security features to protect confidential data and programs stored within the TEE. The reduced amount of software executing within the TEE improves security by reducing the attack vectors and reducing likelihood of software defects.

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

An attacker could still compromise the payment process by running a malicious application in the REE that pretends to be a legitimate payment application thereby tricking the payment TA into signing fraudulent messages. Ideally, the TEE or TA would include safeguards to prevent fraudulent use of trusted applications.

One approach is to include a trusted user interface within the TEE so the TA does not need to accept inputs directly from the REE. Adding additional software to the TEE environment increases opportunities for the TEE to be compromised. Also, a trusted user interface will have a distinctly different look and feel from the user interface of the REE applications so a companion portion of the application running in the REE will appear distinctly different leading to a poor user experience.

Alternatively, an access control mechanism may be included in the REE, as is done for example in the SE Android OS produced by GOOGLE Inc. , to make the TEE available only for certain REE side CA. Unfortunately these solutions tend to be very complex making them difficult and risky to maintain or modify. Also, these solutions rely on software running in the REE and are therefore susceptible to tampering and cannot provide the high level of security required for some types of TA. Document <CIT> is a relevant prior art in this field.

Accordingly, it would be desirable to provide methods and apparatus that address at least some of the problems identified above.

the invention is defined in the independent claims <NUM>, <NUM> and <NUM>. It is an object of the disclosed embodiments to provide improved methods and apparatus that can provide secure and efficient access to trusted applications within a mobile computing apparatus. Further advantageous modifications can be found in the dependent claims.

According to a first aspect the above and further objects and advantages are obtained by an apparatus including 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, within the rich execution environment, a first client application, wherein the first client application comprises a signature generated based on a service provider private key and to determine that the first client application requires services from a trusted application. The processor is configured to send a request for installation of the trusted application to an outside entity, and to receive, within the rich execution environment, one or more messages, 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 configures within the trusted execution environment a security domain, wherein the security 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 security domain. The processor configures an access control list within the security domain, wherein access to the trusted application is controlled by the access control list. Configuration of the SD and access control list provides improved security and access control for the TA. Without the specified ACL configuration, access to the TA could be provided by allowing any CA to access the TA or allowing the TA to serve only predefined CAs. Allowing all CA to access the TA creates a serious security risk, and allowing access based on a predefined list is problematic because there would be no way to expose security critical services provided by TA to any new CAs developed after installation of the TA.

In a first possible implementation form of the apparatus according to the first aspect the processor is configured to generate, within the rich execution environment, a request for access 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 transfers the request for access 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. When the second client application is authorized, the processor is configured to allow the second client application to access the trusted application. Verifying each request against the access control list provides a reliable means for authorizing every request for access before it is forwarded to the trusted application.

In a possible implementation form of the apparatus according to the first aspect as such or to the first possible implementation form, the application public key comprises an application certificate and the processor is configured to securely transfer the application certificate to the trusted execution environment. Use of an application certificate provides a means to verify the authenticity and integrity of the public key and other information associated with the client application.

In a possible implementation form of the apparatus according to the first aspect 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 allows access to the trusted application to be modified without installing updates or multiple copies of the TA.

In a possible implementation form of the apparatus according to the first aspect, the application public key is the same as the service provider public key and the processor is configured to grant 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 gives assurance that the trusted application, security domain, and client application were all provided by the same source.

In a possible implementation form of the apparatus according to the first aspect, the security domain is associated with a plurality of trusted applications and the processor is configured to grant 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 security domain simplifies access by avoid a proliferation of unnecessary security domains within the TEE.

In a possible implementation form of the apparatus according to the first aspect the apparatus is a mobile communication device. Because mobile communication devices are carried by users at all times it is increasingly important to provide improved security within these devices.

In 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 sends a request to grant access of the second client application to the outside entity, receives within the rich execution environment one or more messages, and securely transfers 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 updates the access control list based on the application public key, wherein the update is configured to allow access of the second client to the trusted application. Including multiple public keys in the access control list allows multiple client applications to access the same trusted application without installing multiple copies of the trusted application signed by different public keys.

In a possible implementation form of the apparatus according to the first aspect, the access control list includes access rules, and the processor is configured to grant access to the trusted application based on the access rules. Including access rules and/or privileges in the access control list provides a means for improved access control when multiple public keys and/or multiple trusted applications are present in the security domain.

According to a second aspect of the disclosed embodiments the above and further objects and advantages are obtained by a method which includes 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 services from a trusted application. The method sends a request for installation of the trusted application to an outside entity; receives, within the rich execution environment, one or more messages, 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 security domain within the trusted execution environment, wherein the security domain is associated with the service provider public key, installs within the trusted execution environment the trusted application, and associates the trusted application with the security domain. The method configures an access control list within the security domain, wherein access to the trusted application by a client application is controlled by the access control list. Configuration of the SD and access control list provides improved security and access control for the TA.

In a first possible implementation form of the method according to the second aspect, the method generates, within the rich execution environment, a request for access to the trusted application from a second client 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 request for access 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. When the second client application is authorized, the method allows the second client application to access the trusted application. Verifying each request against the access control list provides a reliable means for authorizing every request for access before it is forwarded to the trusted application.

In a possible implementation form of the method according to the second aspect, the application public key comprises an application certificate and the method comprises securely transferring the application certificate to the trusted execution environment. Use of an application certificate provides a means to verify the authenticity and integrity of the public key and other information associated with the client application.

In a possible implementation form of the method according to the second aspect as such, 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 access to the trusted application to be modified without installing updates or multiple copies of the TA.

In a possible implementation form of the method according to the second aspect, the application public key is the same as the service provider public key and the method grants 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 gives assurance that the trusted application, security domain, and client application were all provided by the same source.

In a possible implementation form of the method according to the second aspect, the security domain is associated with a plurality of trusted applications and the method grants 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 security domain simplifies access by avoiding a proliferation of unnecessary security domains within the TEE.

According to a third aspect of the disclosed embodiments the above and further objects and advantages are obtained by a computer program product including non-transitory computer program instructions that when executed by a processor are configured to cause the processor to perform the method according to the second aspect as such or to any of the possible implementation forms of the second aspect.

These and other aspects, implementation forms, and advantages of the exemplary embodiments will become apparent from the embodiments described herein considered in conjunction with the accompanying drawings. It is to be understood, however, that the description and drawings are designed solely for purposes of illustration and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

In the following detailed portion of the present disclosure, the invention will be explained in more detail with reference to the example embodiments shown in the drawings, in which:.

Referring now to <FIG> there can be seen an illustration of a block diagram showing a secure software distribution and installation system <NUM> incorporating aspects of the disclosed embodiments. The aspects of the disclosed embodiments are directed to an apparatus <NUM> that includes a processor <NUM> coupled to a memory <NUM>, <NUM>. The processor <NUM> and the memory <NUM>, <NUM> are configured to provide a rich execution environment (REE) <NUM> and a trusted execution environment (TEE) <NUM>. The memory <NUM> and processes <NUM>, <NUM>, <NUM> in the trusted execution environment <NUM> are protected from access or modification by applications <NUM>, <NUM> executing within the rich execution environment <NUM>.

In one embodiment, the processor <NUM> is configured to install a first client application <NUM> within the rich execution environment <NUM>, where the first client application comprises a signature generated based on a service provider private key. The processor <NUM> is also configured to determine that the first client application requires services from a trusted application <NUM> and then send a request for installation of the trusted application to an outside entity <NUM>.

The processor <NUM> is configured to receive, within the rich execution environment, one or more messages, 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. The processor <NUM> is also configured to securely transfer the one or more messages to the trusted execution environment <NUM> and configure, within the trusted execution environment <NUM> a security domain <NUM>. The security domain <NUM> is associated with the service provider public key <NUM>.

The processor <NUM> is configured to install, within the trusted execution environment <NUM>, the trusted application <NUM>, associate the trusted application <NUM> with the security domain <NUM> and configure an access control list <NUM> within the security domain <NUM>. Access to the trusted application <NUM> is controlled by the access control list <NUM>.

As used herein the term digital signature, or signature, refers to a difficult to reproduce binary value that is cryptographically derived from the content of a computer file, message, or other set of digital data. Signatures provide a means for verifying the authenticity and integrity of a set of digital data. Signatures may be generated based on an industry standard signature algorithm such as the signature algorithms defined in the request for comment <NUM> (RFC3279) maintained by the Internet Engineering Task Force (IETF), or may be based on any suitable signature algorithm that allows verification of authenticity and integrity of sets of digital data.

As used herein the terms private key, and public key refer to the two keys in the key pair of an appropriate asymmetric cryptographic algorithm such as Rivest-Shamir-Adleman (RSA) cryptography, elliptic curve cryptography (ECC), or other suitable public key or asymmetric cryptographic algorithms. Data that has been encrypted with a public key may only be decrypted with the associated or corresponding private key from the same cryptographic key pair and vise-versa.

As used herein the term secure transfer or to securely transfer messages or data refers to a means of protecting data or information while being sent or transferred across a computer network. Message and/or data may be securely transferred over a secure communication channel configured or established between two entities. The secure communication channel authenticates both entities and ensures the privacy of messages or data being sent across the secure communication link. A secure transfer may be achieved by setting up a secure communication channel based on a secure protocol, and exchanging information or messages over this secure communication channel. For example, secure socket layer (SSL) and transport layer security (TLS) are protocols that provide privacy and authentication at lower levels of the protocol stack, and can provide a means to securely transfer data across a network. Securing communication at the transport or session layer may provide security sufficient for many applications but may not be adequate for all applications. Optionally information may be securely transferred using higher level protocols, such as the Open Trust Protocol (OTrP) being developed as part of the Global Platform industry initiative, or other proprietary secure protocols. These higher level protocols can include predefined conversations and sessions, and may embed nonce values within each message, thereby securely transferring messages and data with a high degree of confidence in the privacy, authenticity, and integrity of the transferred messages or data. An example of a.

As used herein the term security domain refers to a logical construct where a single homogeneous security policy is applied to all security services or TA provided or associated with the security context or domain. A security domain may be configured within a TEE and used to control access to security services provided by one or more TA installed within the security domain. Many secure or trusted protocols, such as the OTrP described above, are configured to support the creation and management of security domains within a TEE as a way to protect certain TA.

Software development companies and software vendors create applications for use on various mobile computing apparatus such as the UE <NUM>. Applications designed to run on UE <NUM> are distributed using various entities or online services <NUM> which are external to the UE <NUM> and accessible from the UE <NUM> over a variety of private and public computer networks such as the Internet.

When preparing a user application or software application for distribution, the software and data associated with the application are assembled into a distribution package such as an Android package (typically having a. apk file extension) or an iOS application archive (typically having a. ipa file extension). A service provider <NUM> generates a digital signature based on the distribution package using the service provider's private key <NUM> and includes the digital signature in the final distribution package <NUM>. The distribution package <NUM> is then forwarded to an application repository <NUM> where it is made available for distribution to UE <NUM>. These user applications are designed to run within a REE <NUM> of the UE <NUM> and thus can be downloaded <NUM> directly from the application repository <NUM> and installed on the device by an OS executing within the REE <NUM> of the UE <NUM>.

To help protect sensitive information and algorithms, certain portions of software applications handling security sensitive operations and data may be separated into smaller more easily secured applications referred to herein as trusted applications (TA). The TA are often configured to perform cryptographic or other important security operations and may include associated confidential information or key material necessary to perform cryptographic functions. To protect the TA from access, misuse, or tampering by malicious applications the TA are beneficially installed within the TEE.

TA, such as the TA <NUM>, are designed to execute within a TEE <NUM> and as such require a more secure distribution process. To maintain security and integrity of the UE <NUM>, software executing within the REE <NUM> of the UE <NUM> is not authorized or allowed to make modifications to software, data, or configuration of the TEE <NUM>. Preparation of the distribution package <NUM> for a trusted software application is similar to that of a normal world application where the software developer or vendor assembles all the software and data for the TA into a distribution package and the service provider <NUM> digitally signs the distribution package <NUM> using the service provider's private key <NUM>. The TA distribution package <NUM> is then forwarded to an entity referred to herein as a trusted service manager (TSM) <NUM>.

The TSM <NUM> is a service or entity external to the UE <NUM> that is accessible by the UE <NUM> over a private or public computer network. The TSM <NUM> has access to confidential material, such as private cryptographic keys, that can be used to identify the TSM <NUM> to the TEE <NUM> of a UE <NUM> as being authorized to make modifications, such as installing TA <NUM>, within the TEE <NUM>. An authorized TSM <NUM> can download a TA <NUM> into a TEE <NUM> on a mobile computing apparatus such as the UE <NUM>, install the TA <NUM>, and make other configuration changes to the environment within the TEE <NUM> while the mobile computing apparatus is in the field. Trust anchors or other key material may be embedded in the TEE <NUM> during manufacturing or provisioning of the UE <NUM> that allows a highly secure network connection to be established between the TEE <NUM> and the TSM <NUM>. These trust anchors and keys ensure security of the TEE <NUM> and ensure integrity and privacy of communication between the TEE <NUM> and the TSM <NUM>. Only an authorized TSM <NUM> is allowed to modify or communicate with a given TEE <NUM>.

A UE <NUM> desiring to use an application can contact the application repository <NUM> and download <NUM> the desired application package <NUM>. Once downloaded, the application package <NUM> may be used to install the software application <NUM> in the REE <NUM> of the UE <NUM>. The software application <NUM> will be referred to herein as a client application (CA) <NUM>. The term CA is used because the CA <NUM> acts as the client side of a standard client-server software model where the CA <NUM> is configured to send requests that are received and processed by system services, such as the cryptographic or other services provided by the TA <NUM>.

After downloading the desired application package <NUM>, the UE <NUM> may obtain, preferably through an alternate communication channel, a public key <NUM> corresponding to the private key <NUM>, and use that public key <NUM> to validate the desired application package <NUM>. The desired application package <NUM>, which may also be referred to as a distribution package, is used to distribute and install a CA <NUM>. The public key <NUM>, which may be used to validate the distribution package <NUM>, is said to be associated with the CA <NUM>. A public key <NUM> associated with a CA <NUM> is referred to herein as an application public key. As used herein the term application public key refers to a public key that is associated with a CA and that may be used to validate the distribution package that was used to distribute the CA.

To support the security needs of highly sensitive applications, the UE <NUM> is configured to support multiple computing environments as described above. The processor <NUM> is configured to provide a REE <NUM> executed within one portion of the memory <NUM>. A TEE <NUM> runs in a secure area of the main processor <NUM> and a secure portion of the memory <NUM> and is configured to provide an isolated execution environment separate from the REE <NUM> and configured to guarantee integrity and confidentiality of data and program code loaded within the TEE <NUM>. Memory <NUM> and processes executing within the TEE <NUM> are protected from modification or access by processes executing within the REE <NUM>.

During or after installation of the CA <NUM>, the OS or other processes executing within the REE <NUM> may detect that CA <NUM> requires services from a TA <NUM>. Detection of the need for a TA <NUM> may occur at the time the CA <NUM> is installed on the UE <NUM> or optionally detection may occur at a later time, such as when the CA <NUM> is executed, or during a scanning or other operation occurring within the REE <NUM>. After detecting the need for a TA <NUM>, the UE <NUM> will send a message requesting installation of the TA <NUM> to a trusted service manager (TSM) <NUM> to obtain the required TA <NUM>.

To support secure transfer, configuration, and installation of the TA <NUM> within the TEE <NUM>, the TSM <NUM> sets up a secure communication channel <NUM> between the TSM <NUM> and the TEE <NUM>. A trusted communication agent <NUM> is included in the REE <NUM> to facilitate establishing the secure communication channel <NUM>. In one embodiment, the secure communication channel <NUM> may be based on the OTrP discussed above. With OTrP the trusted communication agent <NUM> is an implementation of an OTrP Agent configured to establish a secure communication channel between the TSM <NUM> and an OTrP TA <NUM> executing within the TEE <NUM>.

Installation of the TA <NUM> within the TEE <NUM> involves multiple steps which are managed or controlled by the TSM <NUM>. Once the TSM <NUM> establishes a secure communication channel <NUM>, one or more messages are exchanged between the TSM <NUM> and the TEE <NUM> to create a security domain (SD) <NUM> within the TEE <NUM>, install the TA <NUM> within the SD <NUM>, and configure an access control list <NUM> associated with the SD <NUM>.

The SD <NUM> is associated with the service provider <NUM> and includes the service provider's public key <NUM> which may be used to identify and authorize access and management of the SD <NUM>. Optionally the public key <NUM> may be embedded in a public key certificate such as an X. <NUM> certificate that has been signed, or issued by a trusted certificate authority.

The TSM <NUM> configures, via the one or more messages, the access control list <NUM> within or associated with the SD <NUM>. The access control list <NUM> is beneficially stored in memory <NUM> protected within the TEE <NUM> thereby protecting the access control list <NUM> from modification by applications or software processes executing externally to the TEE <NUM>, such as programs executing in the REE <NUM>.

By including identifying information, such as the public key <NUM>, associated with the CA <NUM> in the access control list <NUM>, the access control list can be used to determine which CA <NUM> may be allowed to access the TA <NUM>. When the CA <NUM> requests access to a particular TA <NUM>, the public key <NUM>, or other identifying information, from the CA <NUM> is checked against public keys in the access control list <NUM> to determine whether the CA <NUM> is authorized to access the requested TA <NUM>. Optionally, the access control list <NUM> may associate rules or privileges with the identifying information to further guide access to the TA <NUM>.

In certain embodiments it is desirable to allow a second CA <NUM> to access a TA <NUM> that is already installed in the SD <NUM>. When the second CA <NUM> is associated with an application public key <NUM> that is different than the public key associated with the first CA <NUM>, the second CA <NUM> may not be allowed to access the SD <NUM> or TA <NUM>. One approach for allowing the second CA <NUM> to access the TA <NUM> would be to create a second SD (not shown) and install a second copy of the TA <NUM> in the second SD using the same process as described above. However, installing a second copy of TA <NUM> is wasteful of computing resources and may also introduce additional software related problems such as version control.

The disclosed embodiments provide an improved solution where the access control list <NUM> is updated to allow the second CA <NUM> to access the TA <NUM> that has been previously installed within the SD <NUM>. The access control list <NUM> may be updated by adding the application public key <NUM> or other identifying information for the second CA <NUM>.

As discussed above, any modification of the TEE <NUM> must be made by the TSM <NUM> via a secure communication channel <NUM>. Configuration of the access control list <NUM> is initiated by sending a message from the UE <NUM> to the TSM <NUM> requesting that the second CA <NUM> be given access to the TA <NUM>. The TSM <NUM> establishes a secure channel <NUM> with the TEE <NUM> and sends one or more messages over the secure communication channel <NUM> to update or add the private key <NUM> or other identifying information to the access control list <NUM>. Optionally access rules or privileges may be configured in the access control list <NUM> to help guide access control decisions for the second CA <NUM>.

<FIG> illustrates a block diagram of the UE <NUM> showing a process for controlling access of CA <NUM>,<NUM> to TA <NUM>, <NUM> incorporating aspects of the disclosed embodiments. The UE <NUM> illustrated in <FIG> is similar to the UE <NUM> illustrated in <FIG> where like numerals indicate like elements. The <NUM> includes a second TA <NUM> which has been installed within the SD <NUM> by the TSM <NUM> in accordance with the processes described above.

In operation, when the CA <NUM> executing within the REE <NUM> requires services of a TA <NUM>, the CA <NUM> generates a request for access <NUM> to the TA <NUM>. The request for access <NUM> may be any request for processing by a service supported by the TA <NUM>. For example the request for access <NUM> may be a request to generate a digital signature for a retail purchase or it may be a request to decrypt a media file, or to encrypt a banking transaction, etc..

A trusted agent or daemon (teecd) <NUM> receives the request for access <NUM>, identifies the CA <NUM>, and retrieves <NUM> an application public key or certificate <NUM> from, for example, an Android manifest. The application certificate <NUM> uniquely identifies the signer of the client application distribution package <NUM> and includes a public key which may be used to identify the CA <NUM>. In certain embodiments the certificate <NUM> may be the service provider <NUM> certificate and include the service provider public key <NUM>. Optionally the certificate <NUM> may be different from the service provider <NUM> certificate but may still include the same public key as the service provider public key <NUM>.

The client certificate <NUM> and associated request for access <NUM> are securely transferred <NUM> to the TEE <NUM>. Any appropriate means for securely transferring the request for access <NUM> and associated application certificate <NUM> from the REE <NUM> to the TEE <NUM> may be advantageously employed. For example in one embodiment the UE <NUM> employs the Android OS within the REE <NUM>. With the Android OS example the application certificate <NUM> may be copied into memory managed by the OS kernel and securely transferred to the TEE <NUM> through the use of a shared memory space. The request for access <NUM> is securely transferred <NUM>, <NUM> through a trust zone driver <NUM> executing within the OS of the REE <NUM> and a REE connection agent <NUM> executing within the TEE <NUM>. Those skilled in the art will readily recognize that any means of securely transferring the request for access <NUM> along with the application certificate <NUM> or corresponding public key to the TEE <NUM> may be advantageously employed without straying from the scope of the disclosed embodiments.

Validation of the request for access <NUM> and the application certificate <NUM> and/or public key are carried out within the TEE <NUM> by an access control list (ACL) validation point process <NUM>. The ACL validation point process <NUM> checks <NUM> the public key associated with the request for access <NUM> against the access control list <NUM> to determine whether the requested access should be granted. Optionally, the ACL validation point process <NUM> may be included in a TA loader <NUM> that is used to load the TA <NUM> and prepare it for execution within the TEE <NUM>. In one embodiment, the ACL validation point process <NUM> grants access to the TA <NUM> when the public key included with the request for access <NUM> is present in the access control list <NUM>. Alternatively, the ACL validation point process <NUM> may include additional logic to grant or deny access based on rules or privileges associated with each public key in the access control list <NUM>. When access is granted, the request <NUM> is passed to the TA <NUM> for processing, and any result generated by the TA <NUM> may be returned back to the CA <NUM>.

In certain embodiments the TA <NUM> may need to be loaded prior to passing the request for access <NUM> to the TA <NUM>. When loading the TA <NUM> a TA loader <NUM> may check the TA installation data <NUM> to verify a public key included in the TA installation data <NUM> matches the CA <NUM> public key <NUM>.

In certain embodiments a second CA <NUM> associated with a different public key <NUM> may also require access to the TA <NUM>. As described above, the access control list <NUM> can be updated to include the public key <NUM> associated with the second CA <NUM>. The ACL validation point <NUM> can then be configured to grant access based on the second public key <NUM> in the access control list <NUM>.

In certain embodiments, multiple TA <NUM>, <NUM> may be installed within a single SD <NUM>. When an SD <NUM> includes multiple TA <NUM>, <NUM> it may be desirable to allow certain CA <NUM>, to access both TA <NUM>, <NUM>, and to limit the second CA <NUM> to access only the second TA <NUM>. These additional access rules may be used for example to determine which CA <NUM>, <NUM> can access which TA <NUM>, <NUM>. Optionally the access rules may provide finer grained control to allow one CA <NUM> access to a certain set of services provided by the TA <NUM> and to allow a second client application <NUM> access to a different set of services provided by the TA <NUM>.

<FIG> illustrates an exemplary method <NUM> for installing a TA within a TEE and configuring an access control list incorporating aspects of the disclosed embodiments. The exemplary method <NUM> begins when a CA is installed <NUM> within the REE of a mobile computing apparatus or UE. At the time the CA is installed the UE may determine <NUM> that the services of a TA are required. Optionally the UE may determine <NUM> at some time after installation such as when the CA is loaded and executed.

The UE sends a request <NUM> to an outside 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 application or OS services executing within the REE, are not authorized to make modifications to the data, program code, or configuration of the TEE. The outside entity or TSM possesses confidential material, such as private keys, that identify it as having authority to install TA and modify the data and configuration of the TEE on a particular UE.

A secure communication channel, such as the secure communication channel <NUM> described above, is established between the outside entity and the TEE. Various components executing within a REE may participate in establishing the secure communication channel, however none of these components have the ability to view or modify any of the messages passing through the secure communication channel. All messages exchanged between the outside entity and the UE are securely transferred to the TEE <NUM>.

The secure communication channel between the UE and the outside entity may be based on any appropriate type of computer network such as an air interface or hardware based network. Examples of an appropriate air interface are any of the mobile phone air interface standards such as LTE, LTE advanced, etc. or a wireless network such as WiFi, or any other air based interface that can support a computer network. A hardware based network is any computer networking approach that use copper, fiber, or other physical connections between network nodes.

A security domain is created <NUM> within the TEE. The security domain creates a logical separation or container configured to provide an isolated space within the TEE where programs and data may be protected from access or tampering by programs not having permission within the security domain.

The TA is installed <NUM> within and associated with the security domain <NUM>. Associating the TA with a security domain protects the TA by allowing only processes that are authorized to access the security domain to access the TA.

An access control list is created and/or configured within each security domain <NUM>. The access control list is used by an ACL validation point or similar process to determine whether a request for access should be granted for a particular TA. The access control list may include a list of public keys or other information suitable for identifying which CA are authorized to access TA within the SD. Optionally the access control list may include additional rules or permissions associated with each public key to further guide access determinations.

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

<FIG> illustrates a flow chart of an exemplary method <NUM> for granting access to trusted applications incorporating aspects of the disclosed embodiments. As an aid to understanding the exemplary method <NUM> will be described below with respect to a UE based on the Android OS. Those skilled in the art will readily recognize that the exemplary method <NUM> may be advantageously employed to control access to a TA on any UE having a REE and a TEE without straying from the scope of the disclosed embodiments.

When a CA executing within the REE of a UE requires services from a TA, it generates <NUM> a request for access including any information necessary for the TA to process the requested operations. Processes executing in the REE, such as components of the OS, identify and validate <NUM> the CA and the request for access. The public key and optionally the application certificate associated with the CA is obtained <NUM> for example by retrieving the application certificate from an Android manifest associated with the CA. The request for access along with the public key or application certificate is securely transferred <NUM> to the TEE. An ACL validation point process executing within the TEE receives the request for access along with the public key of the CA and determines whether the CA is authorized <NUM> to access the TA. This determination may be based on the public key or other identifying information included with the request for access, and an access control list associated with the SD in which the TA is installed. When the ACL validation point determines that access should be granted <NUM>-Y, the request for access is forwarded <NUM> to the TA, and when access is denied <NUM>-N the request for access is rejected <NUM>.

In certain embodiments the access control list includes a plurality public keys or identifying information. When this is the case, a second CA having a different public key than the SD, may be granted access when one of the plurality of public keys in the access control list corresponds to the public key of the second CA.

Optionally, the SD may have more than one TA installed. The ACL validation point may be configured to grant access to one or more of the TA based the public key associated with the request for access.

Claim 1:
An apparatus (<NUM>) comprising a processor (<NUM>) coupled to a memory (<NUM>, <NUM>) wherein the processor (<NUM>) and the memory (<NUM>, <NUM>) are configured to provide a rich execution environment (<NUM>) and a trusted execution environment (<NUM>), wherein the memory (<NUM>) and processes (<NUM>, <NUM>, <NUM>) in the trusted execution environment (<NUM>) are protected from access or modification by applications (<NUM>, <NUM>) executing within the rich execution environment (<NUM>), and wherein the processor (<NUM>) is configured to:
install, within the rich execution environment (<NUM>), a first client application (<NUM>), wherein the first client application comprises a signature generated based on a service provider private key;
determine that the first client application requires services from a trusted application (<NUM>);
send a request for installation of the trusted application to an outside entity (<NUM>);
receive, within the rich execution environment (<NUM>), one or more messages, 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;
securely transfer the one or more messages to the trusted execution environment (<NUM>);
configure, within the trusted execution environment (<NUM>) a security domain (<NUM>), wherein the security domain (<NUM>) is associated with the service provider public key (<NUM>);
install, within the trusted execution environment (<NUM>), the trusted application (<NUM>);
associate the trusted application (<NUM>) with the security domain (<NUM>); and
configure an access control list (<NUM>) within the security domain (<NUM>), wherein access to the trusted application (<NUM>) is controlled by the access control list (<NUM>).