Towards a Trustworthy Thin Terminal for Securing Enterprise Networks By

Towards a Trustworthy Thin Terminal for Securing Enterprise Networks by Evan J. Frenn A Thesis Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE in partial fulfillment of the requirements for the Degree of Master of Science in Computer Science May 2013 APPROVED: Dr. Craig A. Shue, Major Advisor Dr. Krishna K. Venkatasubramanian, Reader Dr. Craig E. Wills, Head of Department Abstract Organizations have many employees that lack the technical knowledge to securely operate their machines. These users may open malicious email attachments/links or install unverified software such as P2P programs. These actions introduce significant risk to an organizations network since they allow attackers to exploit the trust and access given to a client machine. However, system administrators currently lack the control of client machines needed to prevent these security risks. A possible solution to address this issue lies in attestation. With respect to computer science, attestation is the ability of a machine to prove its current state. This capability can be used by client machines to remotely attest to their state, which can be used by other machines in the network when making trust decisions. Previous research in this area has focused on the use of a static root of trust (RoT), requiring the use of a chain of trust over the entire software stack. We would argue this approach is limited in feasibility, because it requires an understanding and evaluation of all the previous states of a machine. With the use of late launch, a dynamic root of trust introduced in the Trusted Platform Module (TPM) v1.2 specification, the required chain of trust is drastically shortened, minimizing the previous states of a machine that must be evaluated. This reduced chain of trust may allow a dynamic RoT to address the limitations of a static RoT. We are implementing a client terminal service that utilizes late launch to attest to its execution. Further, the minimal functional requirements of the service facilitate strong software verification. The goal in designing this service is not to increase the security of the network, but rather to push the functionality, and therefore the security risks and responsibilities, of client machines to the networks servers. In doing so, we create a platform that can more easily be administered by those individuals best equipped to do so with the expectation that this will lead to better security practices. Through the use of late launch and remote attestation in our terminal service, the system administrators have a strong guarantee the clients connecting to their system are secure and can therefore focus their efforts on securing the server architecture. This effectively addresses our motivating problem as it forces user actions to occur under the control of system administrators. 1 Acknowledgements I would sincerely like to thank my research advisor, Professor Craig Shue, for his support and guidance throughout my education at WPI. His advice and assistance on my research, coursework, and general education were greatly appreciated. Specifically, he provided in- sightful and supportive criticism on my thesis and I am truly thankful for the time and effort he has given to supporting my education. I wish to thank all my teachers for their help and support. In particular, I would like to thank Professor Krishna Venkatasubramanian, my thesis reader, for his time and valuable effort. I would like to thank Dr. Nathanael Paul for his enthusiasm and introduction into the field covered in my thesis. I would also like to thank my fellow students in the ALAS lab for their intellectually stimulating conversations and thoroughly enjoyed working with all of them. Lastly, I would like to thank my family and friends for their support in accomplishing this thesis. Without the help of all those mentioned, this work would not be possible. 2 Contents 1 INTRODUCTION 7 2 BACKGROUND 10 2.1 Trusted Platform Module . 10 2.1.1 Remote Attestation . 10 2.1.2 Root of Trust for Measurement . 11 2.1.3 Root of Trust for Storage . 11 2.1.4 Root of Trust for Reporting . 12 2.1.5 Late Launch . 12 2.1.6 Intel Trusted Execution Technology . 12 2.2 ARM TrustZone . 13 2.2.1 TrustZone Hardware . 13 2.2.2 TrustZone Software . 14 3 RELATED WORK 14 3.1 Attestation . 15 3.1.1 Hardware-based Attestation . 15 3.1.2 Software-based Attestation . 18 3.1.3 Time Of Check, Time Of Use . 19 3.2 Isolation . 20 3.2.1 Mobile-based Approaches . 22 3.3 Related Applications . 23 4 Trusted Thin Terminal Design Overview 23 4.1 Adversary Model and Limitations . 25 5 Trusted Thin Terminal Architecture 27 5.1 Trusted Thin Terminal Display . 27 5.2 User Input . 29 5.3 Network Interface Card Support . 32 5.4 TCP/IP stack . 33 5.4.1 Link Layer . 33 5.4.2 Network Layer . 33 5.4.3 Transport Layer . 34 5.4.4 Application Layer . 34 5.5 Design and Implementation Issues . 34 3 6 Results 35 7 Future work 37 7.1 Driver Support . 37 7.2 Authentication . 38 8 Conclusion 38 4 Glossary AC module Authenticated Code module. ACPI Advanced Configuration and Power-management Inter- face. AIK Attestation Identity Key. APIC Advanced Programmable Interrupt Controller. BSP bootstrap processor. BYOD Bring Your Own Device. CoT Chain of Trust. CPL current privilege level. DMA Direct Memory Access. DMAR DMA Remapping. DRTM Dynamic Root of Trust for Measurement. EK Endorsement Key. FCS Frame Check Sequence. GDT Global Descriptor Table. I/O APIC IO APIC. IDT Interrupt Descriptor Table. ILP Initiating Logical Processor. IM Itermediate Driver. ISR Interrupt Service Routine. KBC keyboard controller. KBE keyboard encoder. LOC lines of code. Local APIC Local APIC. LPC bus Low Pin Count bus. 5 MLE Measured Launch Environment. MSR model-specific register. MTM Mobile Trusted Module. NDIS Network Driver Interface Specification. NIC Network Interface Card. NV memory Non-Volatile Memory. NW Normal World. OIC Other Interrupt Controller. OS Operating System. PAL Piece of Application Logic. PALs Pieces of Application Logic. PCH Platform Controller Hub. PCIe PCI Express. PCR Platform Configuration Register. PIC Programmable Interrupt Controller. PKI Public Key Encryption. PMR Protected Memory Region. RA Remote Attestation. RCBA Root Complex Base Address. RLP Responding Logical Processor. RoT Root of Trust. RTM Root of Trust for Measurement. RTR Root of Trust for Reporting. RTS Root of Trust for Storage. SMI System Management Interrupt. SMM System Management Mode. SMP Symmetric Multiprocessing. SMRAM System Management RAM. SMT Symmetric Multi-Threading. 6 SRK Storage Root Key. SRTM Static Root of Trust for Measurement. STM SMM Transfer Monitor. SW Secure World. TC Trusted Computing. TCB Trusted Computing Base. TCG Trusted Computing Group. TEE Trusted Execution Environment. TLR Trusted Language Runtime. TOCTOU Time Of Check, Time Of Use. TP Trusted Path. TPM Trusted Platform Module. TTT Trusted Thin Terminal. TXT Trusted Execution Technology. VGA Video Graphics Array. VM virtual machine. VMM Virtual Machine Monitor. VT-x Intel Virtualization Technology. vTPM virtual TPM. 7 1 INTRODUCTION A fundamental problem with respect to computer security lies in the disparity between the trust and trustworthiness of today's systems. Currently available commodity computers are designed to use Operating Systems (OSs) that require trust from any application running on the system. This trust is inherent to the privilege hierarchy of x86 systems, allowing any software executing in ring 0, namely the kernel, unrestricted access to any application running in ring 3, namely user applications. We formally define trust in the context of computer security as the dependence of A on B, such that the actions of B can influence the security goals of A. As a brief example, the confidentiality of any password input for an application, such as an email account or VPN client, is implicitly a security goal. Any application requiring password input from the user is required to place trust in the operating system as it provides access to user input and can directly affect the confidentiality of the password. While trust in the OS is intrinsic to the design of today's prominent systems, these systems are generally lacking in trustworthiness. We define trustworthiness as the ability of the previously mentioned entity B to ensure the security goals desired by A. There are several design characteristics common to today's prominent operating systems that inhibit their trustworthiness. One of the leading factors to OS's low assurance is their large code bases. For example, Linux 3.6 has roughly 16 million lines of code (LOC) [1] and while Microsoft has not released the size of Windows Vista, 7, or 8, the last released size of Windows XP was roughly 45 million LOC [2]. The extremely large code base of both operating systems is generally caused by over privileging many of their provided features and make it impractical to formally verify the system with regards to security. As an example of improper use of privilege domains commonly employed, device drivers generally do not need the full capabilities that come with running in kernel mode including complete access to system memory. They are, however, usually run within ring 0, needlessly increasing the code base that must be trusted, termed the Trusted Computing Base (TCB). A desirable feature currently lacking from commodity systems is the ability of software to authenticate itself to remote parties. This manifests in a lack of trustworthiness that an application can place in data received from a remote party, either inducing input validation and sanitization requirements or creating possible vulnerabilities. As an example taken from [3], game servers are not able to identify whether network input is coming from a valid version of client software or a version corrupted by a cheating user and must therefore either take precautions to validate client input or allow the user to cheat.

Load more