METHOD AND APPARATUS FOR ISOLATING SENSITIVE UNTRUSTED PROGRAM CODE ON MOBILE DEVICE

Abstract

A method provides isolated and secured execution environments on a terminal controlled by one or more processors having one or more processor cores. The processors execute a first trusted execution environment and a second legacy execution environment. At least one trusted application (4) is executed in the trusted execution environment and processes sensitive data, and a legacy application (2) is executed in the legacy execution environment. Execution environments, called sanctuary instances, are isolated from the first and second execution environments and are executed on a dedicated processor or dedicated processor core. The sanctuary instances may be present physically or virtually. Sanctuary memory areas are assigned to the respective processors or processor cores. At least one sanctuary application (10) is executed in a sanctuary instance, and a sanctuary application (10) interacts with one or more legacy applications (2) and with one or more trusted applications via at least one communication channel.

Claims

1. A method for providing isolated and secured execution environments on a terminal controlled by one or more processors having one or more processor cores, said processor providing and executing a first trusted execution environment and a second unprotected execution environment, said trusted execution environment executing at least one trusted application processing sensitive data, and said unprotected execution environment executing an unprotected application, wherein: one or more further execution environments, called sanctuary instances, which are isolated from the first and second execution environments and are each executed on a dedicated processor or dedicated processor core, which may be present physically or virtualized, and a sanctuary memory area exclusively allocated to the respective processor or processor core, wherein in a sanctuary instance at least one sanctuary application is executed, wherein a sanctuary application interacts with both one or more unprotected applications and one or more trusted applications via at least one communication channel, wherein when the unprotected application makes a communication request to the trusted application, the communication request is redirected to the sanctuary application, which then processes the communication request while performing a communication with the trusted application.

2. The method of claim 1, wherein the sanctuary application is replaceable after delivery of the terminal, wherein the trusted application is replaceable in the trusted execution environment at the end customer only with the help of a manufacturer of the terminal.

3. The method of claim 1, wherein the terminal is a mobile terminal for a mobile radio network, in particular for GSM and LTE, and the sanctuary application is exchangeable via the mobile radio network after delivery of the terminal by an operator of the mobile radio network.

4. The method of claim 1, wherein the trusted execution environment executes at least one trusted application that provides functionality that is not for the purpose of managing, in particular provisioning, the sanctuary instances.

5. The method of claim 1, further comprising providing a sanctuary library (9) for the sanctuary application, the sanctuary library providing basic process and/or memory management functions, in particular to interact, in particular to communicate, with the trusted application.

6. The method of claim 1, wherein the sanctuary library is suitably configured to restrict malicious access to basic process and/or memory management functions.

7. The method of claim 1, wherein the sanctuary memory area is separated from the unprotected execution environment by a hardware memory access control component, in particular by an address space controller, and is allocated exclusively to the processor or processor core on which the sanctuary instance is executed.

8. The method of claim 1, wherein the communication of the sanctuary application using the sanctuary library with a trusted application is via shared memory areas, wherein the shared memory areas between the sanctuary library and the trusted application are protected by the address space controller.

9. The method of claim 1 a sanctuary instance is established and executed only on demand, in particular when a communication request to the trusted application is present, only then a sanctuary instance is established by a component, preferably using a kernel module in the unprotected execution environment.

10. The method of claim 9, wherein the kernel module (7) selects the processor or processor core to be used for the sanctuary instance and loads the sanctuary library and sanctuary application binaries, and then initiates the communication.

11. The method of claim 1, wherein, in the trusted execution environment, a component is executed, preferably as a kernel module, which checks whether a sanctuary instance is correctly set up and only allows communication with a trusted application if there is a correct set up of the sanctuary instance.

12. The method of of claim 1, wherein the processor or processor core uses an RISC instruction set.

13. The method of claim 1, wherein the trusted execution environment is realized by a separate processor extension which, in addition to privilege levels used to subdivide into application, operating system and hypervisor modes, enables a further, orthogonal subdivision which in particular provides system-wide hardware isolation for trusted software, preferably implemented by an ARM TrustZone.

14. A terminal or mobile terminal comprising means and equipment for carrying out the method of claim 1.

Description

[0048] The basic idea of a sanctuary design is to provide one or more isolated execution environments in which sensitive program code that processes sensitive data can be executed. These isolated environments are called sanctuary instances. The program code running in a sanctuary instance is completely separated from all untrusted program code on the system, and at the same time it is not part of the system's trusted program code, also referred to as a Trusted Computing Base (TCB). In fact, the program code running in a sanctuary instance need not itself be trusted, as it cannot compromise system security. Separation from trusted program code and other untrusted program code is accomplished by running each Sanctuary instance on a dedicated processor or processor core and allocating memory areas exclusively to those processors or processor cores using appropriate isolation mechanisms.

[0049] In practice, the sanctuary design can be used, for example, to extend existing TEE architectures so that the full potential of TEEs can finally be exploited on modern mobile devices. FIG. 2 shows a generic TEE architecture extended by the design principles of the sanctuary when a sanctuary instance is assigned to a physical processor core. FIG. 3 shows an extended TEE architecture when a sanctuary instance is assigned to a virtualized processor core.

[0050] As in the traditional TEE architecture, the system is divided into a normal world and a secure world (Normal World/Secure World). In the normal world, the untrusted program code consists of the unprotected OS (Legacy OS) (1) and the unprotected applications (Legacy Apps) (2). In the secure world, a trusted OS (Trusted OS) (3) is executed along with trusted applications (Trusted Apps) (4). One of the important differences from the state of the art TEE architecture is that the secure world will not contain any program code from a third party vendor. All trusted applications in the TEE will be provided by the device manufacturer or by the TEE provider if developed by a second trusted party. It is up to the manufacturer to decide which functionalities to provide in the TEE. A change after delivery to the end customer is thus not possible or only possible with a very high effort.

[0051] The sensitive third-party code that had to be integrated into the TEE in the form of a custom trusted application is isolated in a sanctuary instance in the form of a sanctuary app (10). This means that instead of a custom trusted application, a mobile operator now develops a custom sanctuary application. For each sanctuary application, there is preferably a corresponding unprotected application, which can also be developed by the mobile network provider or by third parties accessing standard interfaces, for example.

[0052] The sanctuary instance comprises a sanctuary application and a sanctuary library 9. The sanctuary library provides some basic process and memory management functions for the sanctuary application, e.g., running with unprivileged rights in the sanctuary instance. In one possible embodiment, the design principles of a sanctuary instance require that no more than one sanctuary application from different providers run in the sanctuary instance at the same time to prevent data leakage between different mobile services. Running multiple sanctuary applications from the same provider in a sanctuary instance, on the other hand, is possible in the sanctuary design.

[0053] As shown in FIG. 2 and FIG. 3, the sanctuary code runs on a separate processor core and is therefore separated from the untrusted/unsecured program code of the normal world. If the sanctuary instance is assigned to a physical processor core, as shown in FIG. 2, the sanctuary memory area is also preferably separated from the rest of the system by the TZASC hardware component (6). The latest reference implementation, the TZC-400, allows memory areas to be allocated exclusively to bus masters on the system that identify themselves in the transactions they send over the system bus. The CPU, GPU, and other peripherals such as a display controller act as bus masters on the system. The TZC-400 can now use the identifiers sent by the bus masters to perform memory access control. In current TEE architectures, this feature of the TZC-400, called identity-based filtering, is only used to implement media protection applications where memory is allocated to either the CPU or the GPU. In the sanctuary design, this feature is used to allocate an area of memory exclusively to the one physical processor core on which the sanctuary code is to be executed. As a result, the processor cores executing the normal world program code cannot access the memory areas of the sanctuary instances. Since the identity-based filtering feature is not implemented in cache memory, at least so far, the sanctuary code and its data are not cached in the shared cache memory between the processor cores of the same processor cluster. Otherwise, program code in the normal world could gain access to data from a sanctuary instance. On ARM-based systems, this shared cache is typically the L2 cache.

[0054] If the sanctuary instance is assigned to a virtualized processor core, as shown in FIG. 3, the sanctuary memory area is preferably separated from the rest of the system by virtualization extensions, e.g. an appropriately designed MMU 12. Since the ARMv7 architecture, corresponding virtualization mechanisms are available for ARM processors. The memory access control of the MMU is performed by a two-stage translation from virtual memory addresses to physical memory addresses. The configuration of the MMU can only be done in the privileged hypervisor mode EL2 and is performed by the switch program code 11. In this way, the normal world program code running in lower privileged modes (EL0 or EL1) can no longer configure the MMU and therefore cannot access the memory area of the sanctuary instance. Since the virtualization mechanisms are also implemented in the cache, the sanctuary code and its data can also be stored in the cache memory.

[0055] Sanctuary instances are not always executed or configured in the system. Only when an unprotected application requests to run the sensitive program code of its corresponding sanctuary application, a sanctuary instance is set up and deployed. This saves resources on the system. Sanctuary instances are set up and managed mainly by the new kernel modules (Kernel Modules), components that are part of the unprotected OS (7) and the trusted OS (8). The kernel module of the unprotected OS is mainly used for collecting the needed resources from the unprotected OS. It selects a processor kernel to be used as the sanctuary kernel and loads the sanctuary application and sanctuary library binaries into memory. All security-related management tasks are performed by the trusted OS's kernel module. The kernel module of the trusted OS ensures that a sanctuary instance is actually separated from the other untrusted program code on the system. It checks the sanctuary library binary and ensures that the sanctuary instance is set up correctly. In addition, the kernel module of the trusted OS configures the isolation mechanism used. If the sanctuary instance is to be assigned to a physical processor core, as shown in FIG. 2, the kernel module configures the TZASC component. In addition, the help of the ARM Trusted Firmware TF is needed to verify that the selected physical sanctuary core has been shut down properly. If the sanctuary instance is to be assigned to a virtualized processor core, as shown in FIG. 3, the kernel module calls the switch program code 11 to configure the MMU. After configuring the isolation mechanism and checking the sanctuary library, the sanctuary instance can be started. This is triggered by the kernel module of the unprotected OS. If the sanctuary instance is run on a physical processor core, the kernel module uses the ARM TF to launch the sanctuary core. If the sanctuary instance is run on a virtualized processor core, the kernel module uses the switch program code to trigger the execution of the sanctuary code.

[0056] When a sanctuary instance is up and running, the sanctuary application can communicate with the corresponding unprotected application to receive commands or non-sensitive data from it. In addition, it can use all the trusted functionalities of the device manufacturer and its trusted applications. This means that a sanctuary application can extract sensitive data from the TEE and then process it in an isolated environment provided by the sanctuary instance. Using the kernel module in the trusted OS, a trusted application can always ensure that sensitive data is only shared with a properly established sanctuary instance and with the legitimate sanctuary application that owns the data. Once the sanctuary application has processed the sensitive data, it can be stored back in the TEE and non-sensitive processing results can be returned to the unprotected application. At the point a sanctuary application is installed on a device, it will never contain sensitive data. All sensitive data is made available while the sanctuary application is running. To achieve this, the TEE provides a mechanism with its proven functionalities that allows a remote server or a local program to verify the correct state of a sanctuary application.

[0057] The sanctuary application communicates with its unprotected application or a trusted application through shared memory areas, while the shared memory area between the unprotected application and the sanctuary application is called unprotected shared memory and the shared memory between the sanctuary application and the trusted application is called protected shared memory. Since the protected shared memory may contain sensitive data, it is protected by the isolation mechanism used (TZASC hardware component or MMU with virtualization extensions). FIG. 2 and FIG. 3, respectively, show as an example that the processor core with ID 0 and A, respectively, in normal mode, is denied access to memory address 0x80 because this memory area is allocated to the sanctuary instance.

[0058] When a sanctuary instance is no longer needed and is closed on behalf of the unprotected application, the kernel modules of the unprotected and trusted OS work together to dismantle the sanctuary instance in such a way that no data from inside the sanctuary instance can be picked up by the program code of the normal world. All resources taken from the unprotected OS are returned.

[0059] The Sanctuary design can be used to solve the problems of existing TEE architectures. By moving the third-party sensitive program code from the secure world to Sanctuary instances, each mobile vendor can obtain from the device manufacturer the ability to transfer its own sensitive program code to the devices. The reason for this is that all Sanctuary code is not part of the system's TCB, which means that the mobile device manufacturer does not have to trust this program code. The sanctuary code has no privileged rights on the system and yet is completely isolated from other untrusted program code. The isolation works both ways. The program code of the normal world cannot access the memory areas of the sanctuary instances, and the program code of the sanctuary instances cannot access the memory area of the normal world. Therefore, the sanctuary design even covers the notion of a malicious sanctuary application. A malicious trusted application, on the other hand, is not covered by current TEE architectures. Because of these design features, deploying sanctuary applications can be as simple as deploying traditional unprotected applications because extensive safety assessments of sanctuary applications are not required. Because the sanctuary design is flexible and introduces only a few new components, most existing TEE solutions can be modified to implement the sanctuary design.

[0060] A possible test implementation of the sanctuary design followed the sanctuary architecture shown in FIG. 2. A Linux is used as the unprotected OS (1), while the unprotected applications (2) are represented by C programs running on the Linux kernel in user space. The Linux kernel has been extended with its own kernel module (7). For example, the open-source TEE called OP-TEE was used as a trusted OS (3), which also allows the implementation of trusted applications (4). OP-TEE was extended with its own kernel module (8). For the sanctuary library (9), the Zircon microkernel was used because of its relatively small size of 1 MB and because it provides a full userspace environment. The sanctuary applications (10) are written as C programs running on the Zircon microkernel. A slightly modified version of the ARM Trusted Firmware was used as monitor program code.

[0061] In the test implementation, two trusted applications were implemented that provide some basic trusted functionality needed to implement most mobile services on a device. One trusted application provides some remote certification functionality that can be used to verify the state of a sanctuary application from a remote server. As mentioned earlier, this functionality is needed to transfer sensitive data to the device. The second trusted application provides some sealing functionality that can be used to securely and permanently store any data from a sanctuary application on the device. This trusted application also ensures that only the authorized sanctuary application can extract its stored data. In the test implementation, the real-world scenario of a one-time password (OTP) generator application, which is widely used for two-factor authentication, was implemented. The application consists of an unprotected component in the normal world and a sanctuary application. Using the two trusted applications, the generator application can request a secret key from a remote server and then keep it secure. At a later time, the sanctuary application can generate a new OTP using the key and the current timestamp, which is then sent to the unprotected component of the generator application and displayed to the user who wants to perform two-factor authentication.

[0062] Since the OTP generation algorithm processes sensitive data (the secret key), this must be protected at runtime. In current TEE architectures, a separate trusted application would be required in the TEE. This implementation has shown that the same can be achieved with the sanctuary design without the need for third-party code in the TEE. The implementation evaluation shows that the sanctuary architecture is practical and does not cause a high performance loss.

[0063] Important for the implemented variant where the sanctuary instance is bound to a physical processor core is that the memory separation is enforceable on a per-core basis in hardware.

[0064] The reason for this is that the identifiers assigned to the various bus masters in the system are assigned in hardware and cannot be changed via software. Through experiments with virtualization tools from ARM, the so-called ARM Fast Models, it was found that unique identifiers can be assigned to each processor core with minimal effort when designing the hardware of a mobile device. In addition, a filter mechanism can be used to transfer these identifiers to all transactions of the bus masters that send them over the system bus.

LIST OF REFERENCE SIGNS

[0065] 1 Unprotected OS (Legacy OS) [0066] 2 Unprotected application (Legacy App) [0067] 3 Trusted OS (Trusted OS) [0068] 4 Trusted application (Trusted App) [0069] 5 ARM Trusted Firmware [0070] 6 Trust Zone Address Space Controller (TZASC) [0071] 7 Kernel Module (Kernel Module) [0072] 8 Kernel Module (Kernel Module) [0073] 9 Sanctuary Library (Sanctuary Library) [0074] 10 Sanctuary App (Sanctuary App) [0075] 11 Switching program code (Switching Code) [0076] 13 Memory Management Unit (MMU)