Finally, we discuss some relevant issues concerning the security of the TLR. An attacker wanting to exploit the attack surface of the TLR would face several difficulties. The attack surface of the TLR comprises the smc interface exposed to the OS, and the managed code and library interface exposed to the trustlets. Both the smc and the library interface are relatively narrow, which reduces the number of vulnerabilities that can be exploited by an attacker. The managed code interface offers a larger attack surface where an attacker could try to exploit a bug in the NetMF engine by providing carefully crafted bytecode sequences in their trustlet code. Although such an attack is possible, the TCB size of the NetMF engine is sufficiently small to be analyzed, thereby reducing the chance of vulnerabilities in the NetMF engine code. Also note that compromising the OS-domain native would not pose any specific problem to the application (e.g., the OS starts forwarding results of a trustlet to a different application). In fact, attacks resulting from an OS compromise can be considered as a particular kind of a man-in- the-middle attack mounted between the trustlet and a trusted remote service, an attack that the application developers already have to mitigate when designing their apps.
The TLR can only provide limited protection against physical attacks: an attacker with the ability to tamper with the hardware could disable the TrustZone protections and over take the defense mechanisms enforced by the TLR. However, such attacks require some degree of sophistication: since the core of the system (the SoC) is packaged in a single die, an attacker would need to break into the SoC in order to conduct this attack successfully. Although this task is not impossible, it would be extremely difficult. To prevent simpler hardware attacks such as probing the bus, the SoC manufacturer could include the memory modules allocated to the secure world directly in the SoC. In this way, bus probing attacks would be impossible without tampering with the SoC.
8.6 Summary
We presented the Trusted Language Runtime (TLR), a system for running trusted ap- plications on the smartphone. TLR offers a trustbox primitive, which is a runtime environment that offers code and data integrity and confidentiality. With the TLR, pro- grammers can write managed-code applications in .Net and specify which parts of the application should run inside a trustbox. These parts, called trustlets, are protected from the remaining code running on the smartphone, including its OS and other applications. TLR uses the ARM TrustZone, which is a hardware technology for trustworthy com- puting found in ARM chips. The rich hardware support offered by ARM TrustZone combined with the flexibility of the .Net programming environments allows the TLR to
offer a secure, yet rich programming environment for developing trusted mobile appli- cations. In addition to presenting the design and a TLR implementation based on the NetMF, this chapter showed that the system performs well, and that it can successfully host an array of compelling applications with stringent security needs.
9 Analysis and Limitations
In this chapter, we aim to show how the systems presented in this thesis fit together and get a deeper understanding of their limitations. To this end, we start by providing a unified design model of these systems based on trusted computing—in fact, despite their diversity, they all borrow their core design principles from trusted computing. Then, we leverage this model to discuss the main limitations of these systems (and of trusted computing in general), hoping that this discussion will help identify open research questions to be addressed in the future.
9.1 A Unified Model for Trusted Computing Systems
Essentially, a trusted computing system aims to improve users’ trust in a particular computing platform by granting access to users’ data on the platform if and only if the platform executes a state machine that the users have approved. Since the state machine of a platform defines its expected properties (e.g., confidentiality and integrity protection of computations), by approving a trusted state machine that implements certain required properties, users can obtain a priori guarantees that those properties will be enforced before uploading their data to the platform.
To restrict data access based on a trusted state machine, trusted computing systems adopt a similar high-level design, whose components are shown in Figure 9.1. The trusted state machine is specified as a piece of trusted software (e.g., a hardened hypervisor as described in Section 3.1.3). Given that a general purpose computing platform can boot an arbitrary piece of software (and therefore execute an arbitrary state machine), to validate the software executing on the platform, the system provides a set of trusted computing primitives. As introduced in Section 2.4.1, these primitives typically include
Figure 9.1: Key elements of a general trusted computing system: trusted software, trusted hardware, trusted computing primitives, and trusted third parties.
trusted boot, remote attestation, and sealed storage. To protect the integrity of these primitives, their implementation is grounded on a piece of trusted hardware (e.g., a TPM). Since the trusted software and hardware components are not directly controlled by the users, users must ultimately rely on trusted third parties to correctly implement and certify these components. For a deeper exposition of some of these concepts, we refer the interested reader to [PMP10].
As described next, this general design can be used to model the components of the trusted computing systems presented in this thesis: Excalibur (for cloud platforms), BrokULOS(for enterprise platforms), and the TLR (for mobile platforms). We clarify how each component is implemented by each system.
Trusted software: The trusted software is typically tailored to enforce specific proper- ties. In Excalibur, the trusted software consists of the monitor code and the client side libraries located on the cloud nodes. These components implement the policy-sealed data abstraction, which can be used for bootstrapping trust in the cloud (see Section 4.2.1). In BrokULOS, the trusted software consists of (i) the trusted programs (brokers) that administrators use to maintain the operating system, and (ii) the software that runs in privileged mode, namely the kernel and OS services. By implementing the security invariants of the Broker Security Model (see Section 6.1.1), the brokers offer the ad- ministrators the tools to manage the system without compromising the confidentiality and integrity of users’ data and computations. Lastly, in the TLR, the trusted software comprises the TLR code and the security-sensitive app code (trustlets). The TLR code guarantees the protection of confidentiality and integrity of the trustlets’ runtime state (see Section 8.1.2).
Trusted computing primitives: To allow for the validation of a platform’s configura- tion, a trusted computing system typically provides trusted computing primitives, each of them serving specific purposes. Excalibur provides an attest-monitor primitive for attesting the configuration of the monitor, and seal and unseal primitives for sealing and unsealing policy-sealed data (see Table 4.4). BrokULOS embbeds trusted computing primitives in the implementation of certain brokers, e.g., the broker for activating a user account the first time a user logs in includes an attestation mechanism that checks the integrity of the system (see Section 6.3.3), and the brokers for backing up and restoring user data implement a mechanism akin to sealed storage to guarantee that the backed up data is encrypted before leaving the user’s account and can only be decrypted by the user (see Section 6.3.2). Lastly, at the API level, the TLR provides seal and unseal primitives that enable validating the integrity and identity of a specific trustlet before entrusting a trustlet with sensitive data (see Section 6.3.3). In all these cases, the implementation of the trusted computing primitives is rooted in trusted hardware.
Trusted hardware: To implement the trusted computing primitives, we use two trusted hardware technologies. In the cloud and enterprise setting, Excalibur and BrokULOS, respectively, use TPMs deployed on the local machines. In the mobile platform, the TLR