An Overview of Trusted Computing A Project Report submitted by Saran Neti Maruti Ramanarayana (100841098) as Project 2 for COMP 5407F, Fall 2010 Carleton University Abstract This project report gives a brief overview of the challenges in establishing trust among a network of computers potentially running malicious software. We look at some key features in Trusted Computing including the hardware modications, novel protocols and key management ideas while highlighting various privacy con- cerns and open techincal challenges responsible for its slow adoption. We conclude with a few remarks about the social aspects of it. 1 Introduction 1 1 Introduction The widespread use of desktop applications processing sensitive data (e.g banking or health records) has resulted in an ecosystem based on malware exploiting vulnerabilities in software and compromising millions of comput- ers. Commercial security software, like anti-virus, exist to detect and remove infected les but new vulnerabilities are constantly discovered and exploited. While the cycle of discovering, exploitation and xing of security bugs is a never ending process, billions of dollars are lost every year by companies (e.g nancial institutions), providing services through the Internet, due to malicious activity. A major concern among such service providers is their in- ability to determine if a client machine using their service can be trusted with critical information. In other words, even if the end user and the network can be trusted, there is no easy way to tell if a computer contains malicious software, and hence no way to refuse to serve a request originating from such a computer. Trusted Computing is an umbrella term used to describe security related enhancements to a modern computer to assist in establishing a trust rela- tionship under the assumption that it is potentially running compromised software. This process can be broadly described by Attestation - securely measuring the state of a computer, and Verication - remotely determining if a computer can be trusted using its state information. It is important to observe that Trusted Computing does not aim to re- duce vulnerabilities in software or prevent attacks against individual software components. Instead it aims to make the entire software ecosystem more se- cure by regulating interaction between networked computers and facilitating a universally secure computation of a trust metric. Naturally many privacy and ownership concerns arise when access to services are granted or denied based on judgment calls of whether a particular piece of software is trusted. Moreover, since the root of trust is located in hardware, running an alternate piece of software can be made impossible if desired as noted vociferously by Richard Stallman [7]. Some of these issues have been cleverly addressed [12] but a lot remains to be done for widespread adoption by the community at large. We now look in detail at some of the fundamental problems, existing solutions and possible improvements to establish trust under the Trusted Computing model. 2 Assumptions about Hardware and Software 2 2 Assumptions about Hardware and Software Algorithms to process data can either be implemented in hardware or soft- ware or a combination of both. Functionally, primitives or the building blocks of algorithms are designed on hardware, and are invariant for the lifetime of a physical computer as opposed to the higher layer logic which can be modied, loaded into memory and executed. For example, in a PC the x86 instruc- tion set serves as a layer of abstraction between hardware and software. A modern computer consists of many peripheral devices connected to the CPU, where each device itself has evolved into a complex computational unit. The software running on these devices, e.g. network cards, graphic cards, storage drives, is called rmware and its update cycle can be more frequent than the lifetime of the hardware. In order to make clear assumptions about what is trusted and what isn't, it is important to understand the functionality and security that each layer oers. Hardware Microprocessor, memory, display, keyboard, mice etc. are all types of hard- ware devices which are assumed to be trusted for the following reasons 1. The chips controlling them are manufactured in gigantic quantities; duplicate copies of them are found on millions of machines and modi- cation of their functionality is not typically possible without damaging the device. 2. The chips serve the sole purpose of managing the device, making it almost impossible for malware to make use of them for general purpose computation. 3. The code complexity in the chips is not too high, and hence the chips are not reprogrammable, although they may internally have a clear distinction between rmware and hardware. Software All code executed by the Microprocessor starting from bootloader, kernel to userspace applications is untrusted. This layer implements most of the 2 Assumptions about Hardware and Software 3 functionality of modern computers and its contents are very dynamic and constantly changing. Firmware Network and Graphics cards are examples of devices which contain repro- grammable rmware. Trust in this region is a Grey area, because rmware updates are usually delivered through software which is untrusted. Neverthe- less, rmware is often specialized and has access only to its device, making writing malware for it dicult. BIOS is an example of rmware that is untrusted - as it contains a lot of code [2] to initialize devices before hand- ing over control to the bootloader. Attacks have been devised that install backdoors resilient even to disk wipes [6]. In the Trusted Computing model, a specialized hardware called the TPM chip is introduced in the Hardware layer, and provides a way to measure every software ( and some rmware like BIOS ), that loads into the computer. Trusted Platform Module (TPM) Cryptographic Persistent memory processor Endorsement Key (EK) random number generator t Storage Root Key (SRK) RSA key generator Versatile memory Platform Configuration Registers (PCR) SHA-1 hash generator secured input - outpu Attestation Identity Keys (AIK) encryption-decryption- storage keys signature engine Fig. 2.1: TPM chip The TPM chip includes 3 Measuring the state of a computer 4 1. Endorsement Key - A public/private keypair embedded into the TPM that uniquely identies it. The private key never leaves the chip. 2. Storage Rootkey - Used to protect other keys. This can be erased by wiping the TPM clean to its factory state. 3. Platform Conguration Registers (PCR) - Used to store the platform state. 4. Attestation Identity Key (AIK) - Used to validate the TPM chip during remote attestation. It also includes hardware implementations of common cryptographic func- tions. The key idea is that in any operation output = CryptoF unction(data; key), the key, function and data reside in the same chip. If we can somehow gen- erate data to meaningfully reect the state of software output can be used to convey this information to remote parties securely. 3 Measuring the state of a computer In order to be able to convey state information about a computer, we need to know the hardware conguration of a computer and also all the security relevant software that boots up in that computer, in a way that takes into account our trust model - all software is untrusted and can potentially contain malware. Hardware conguration can be vouched for by the vendor in the form of an Endorsement key in the TPM. TPM chips have been hacked into using electron microscopes [5], but our threat model assumes that the adversary does not have physical access to a computer. Measuring software for signs of infestation of malware is tricky. Design of software is also layered, but the abstractions are not necessarily made with strong security mind. When the process isolation guaranteed by an OS kernel doesn't hold up against attacks, lightweight Virtual Machines (VM) equipped with better isolation provided by hypervisors are employed [11]. And when an application is unable to operate on a collective bunch of VMs, software APIs are provided in the Hypervisor layer as an ecient means of communication. [9, 8]. This constant partitioning up of software into isolated containments, and then creating channels between them for communication in order to nd the optimum balance between security and eciency is a never ending process. But this is of interest to us - we want to determine 3 Measuring the state of a computer 5 that critical layer of software which can guarantee isolation of layers above it enabling in a reduction of the total amount of code needed to be trusted. i.e the Trusted Computing Base (TCB). The objective is to split our software stack into layers L0;L1; :::; Ln, and nd a k such that we 1. Minimize the amount of Trusted Code - Pk is minimized, where 0 jLij jLij is the sum of all lines of code running at layer Li. 2. Isolate higher layer applications - For all i > k, all applications A 2 Li must be able to run in secure isolated execution environments. 3. Maximize Eciency - The performance penalty of applications running in a higher layer due to security must be minimized. Finding this layer Lk is the big challenge. The older Flicker project uses only 250 lines of code in the TCB and makes heavy use of the inecient late launch instructions ( AMD SVM or Intel TXT ) on newer commodity processors [17]. The Trustvisor project attempts to minimize the TCB while maintaining reasonable eciency, by using an easily veriable special-purpose hypervisor with about than 6k lines of code [16]. 3.1 What software to measure? We now look at a simple mechanism using the TPM that will ensure that identity of all software loaded on a computer gets recorded. Let S1;S2;S3:::; Sn be a list of software binaries that gets loaded into a computer in that order.