Observations and Conclusions

TrustZone technology is delivered with many ARM chips, but it is often left disabled by the firmware. There are however some development boards with full TrustZone function- ality, such as the Freescale iMX53 [13]. Also, ARM Development Studio 5 [4] offers full emulation of this technology.

It is also important to notice that the TrustZone only offers protection at runtime. If an attacker had the proper resources to extract the flash chip from the device and inspect its content he would find the Secure world software image unencrypted and he would be able to retrieve the encryption keys. This is what the TrustZone whitepapers define as a lab attack and are considered beyond the scope of an encryption system for mobile de- vices - if some data were valuable enough for some attacker to go through this amount

of trouble to retrieve it, this data should not be stored on a mobile phone in the first place. The implementation of a software module for the TrustZone is a complex task and it falls out of the scope of this thesis. However, given the attention that this technology has drawn over the past years, we chose to design the Content Provider encryption system around this concept, i.e. some sensitive operations are considered to be executed in the Secure world.

We will make the assumption that some encryption keys cannot be retrieved even if the Android instance installed on the machine is corrupted. An attacker would use root priv- ileges to dump flash and RAM content, but the keys would be stored in secure memory areas and the Normal world Android would not be able to access them. Also we designed the system such that all sensitive operations were moved to a separate service and we mod- ified the libraries used by the Content Providers to forward all data encryption(decryption) requests to this service using shared memory. Porting this implementation to a TrustZone- enhanced OS would only require the addition of the proper TrustZone API calls that switch the CPU from the Normal to the Secure world mode.

Chapter 5

System design

This chapter discusses technical details of the Content Provider encryption system i.e. the exact means by which encryption keys and user configurations are stored and managed and how data is encrypted.

This system is designed with the TrustZone technology in mind. To be more precise, it is assumed that some components will run in the Secure world and they can only be accessed from the Normal world in a manner that is controlled by the hardware platform. However, as shown in Chapter 4, this technology is disabled by the firmware on most de- vices, and the system should work under these conditions as well, at least in the domestic mode (where no communication to a CA is required and exposing a container encryption key would not cause damage to more than one device). For this reason, some data struc- tures that are only accessible to the Secure world (and are therefore protected by hardware mechanisms) are nevertheless encrypted. In other words, our system offers the strongest security guarantees under the assumption that the TrustZone is active, otherwise, if the OS is corrupted1_{, the encryption system is also vulnerable.}

In the design of our system we will assume that the enterprise mode only works with TrustZone-enabled devices. Certain restrictions, that will be pointed out in this chapter, constrain us to only use this operation mode if the hardware platform supports the Trust- Zone technology. On the other hand, the domestic mode can be installed on devices that do not have a TrustZone, but in this case there are some vulnerabilities that will also be discussed.

5.1

Local applications

There are two main software modules that run on the mobile device and ensure data access: a monitor service and a cryptographic service. The monitor service is in charge of all account management operations: it ensures that the user provided the proper au- thentication credentials and that it is entitled to access the container that it requests. The cryptographic service only encrypts or decrypts data as requested by the user and is under the control of the monitor service. This means that it is only given access to the

1

More precisely, if a malicious process finds a way to inspect the memory image of the process that manipulates encryption keys, these keys can be revealed.

necessary keys by the monitor service and, as long as it is not notified by the monitor that it must no longer answer queries coming from the user applications, it will do so without any extra access verifications. These two services will run as threads in the same process, thus there is no IPC mechanism employed when they need to share data. In fact, they could be merged into one single service. The decision to have two such services is only motivated by the wish to obtain a clean design, where each service corresponds to one of the major tasks of our system: manage users and encrypt/decrypt data.

Ideally, both these services would run in the Secure world. However, if the device is not endowed with this technology, the container encryption key will appear at some point in the memory image of the cryptographic service and, since there is no hardware memory protection, an attacker with root privileges will be able to inspect this image. At this point the system will have to rely on the fact that the service cannot be brought in a running state unless the end-user introduced the proper login credentials. In other words, without a valid password, that is not stored anywhere on the device, encryption keys will not be loaded in memory. Even with the limitation of not having a TrustZone, our encryption system offers better functionality than the default Android encryption: access control can be configured and screen locking will prevent the adb from reading decrypted data.