abdul basit - fraunhofersit.sit.fraunhofer.de/smv/publications/download/abdulbasit_master.pdf ·...

Royal Institute of Technology, Sweden

Master Thesis

APPROACHES FOR ATTESTING VIRTUALIZED ENVIRONMENTS

Abdul Basit

Supervisors Nicolai Kuntze Micael Lundvall

Approaches for Attesting Virtualized Environments

Contents Acknowledgments 5 Abstract 7 1. Introduction 9

1.1 Problem Description 9 1.2 Goal 10 1.3 Outline 10

2. Basic Principles 13

2.1 Virtualization 13 2.1.1 Why virtualization 13 2.1.2 Benefits of Virtualization 14 2.1.3 Virtualization Technologies 14

2.1.3.1 Server Virtualization 15 2.1.3.2 Storage Virtualization 18 2.1.3.3 Network Virtualization 18 2.1.3.4 Application Virtualization 18

2.1.4 Inside Virtualization 19 2.1.4.1 Type1 VMM 20 2.1.4.2 Type 2 VMM 20

2.2 Trusted Computing 21 2.2.1 Trusted Computing Group 22 2.2.2 Why Trusted Computing? 22 2.2.3 What is Trust? 22 2.2.4 Trusted Platform 23 2.2.4.1 Architecture of Trusted Platform 23 2.2.5 Trusted Platform Module 23 2.2.5.1 TPM Components 24 2.2.5.2 TPM Functionalities 25 2.2.5.3 TPM Keys 26 2.2.6 Foundation Of Trust 26 2.2.7 Root of Trust 27 2.2.7.1 RTM 27 2.2.7.2 RTS 27 2.2.7.3 RTR 27 2.2.8 TPM Credentials 28 2.2.9 Integrity Measurements 30 2.2.10 Chain of Trust 30 2.2.11 Root of Trust for Virtualized Platforms 31

2.2.12 Virtual Trusted Platform Module 31 2.2.13 Attacks on Trusted Computing 31

2


3. Remote Attestation 35 3.1 What is Remote Attestation? 35 3.2 Need of Remote Attestation 35 3.3 Remote Attestation Entities 36 3.4 Basic Remote Attestation Mechanism 36 3.5 Techniques of Remote Attestation 37 3.5.1 Binary RA 37 3.5.2 Property Based RA 39 3.6 Reporting Protocols 42 3.6.1 Basic Integrity Reporting Protocol 42 3.6.2 Session based Integrity Reporting Protocol 44 3.7 Remote Attestation Challenges 46 4. Remote Attestation for Virtualized Environments 48 4.1 Challenges Regarding RA of Virtual machines 48

4.2 Case Scenario 48 4.3 Trusting Virtual Machines 49 4.4 Binding between vTPM and hTPM 49 4.5 Mapping PCR 50 4.6 Generate AIK Credential 51

4.7 Remote Attestation Protocol for VM 52 4.7.1 For non-mapped PCR 52 4.7.2 For mapped PCR – Deep Attestation 53 4.8 Dynamic Root of Trust for Measurements 55 4.8.1 OSLO 55 5. Implementation 58 5.1 Qemu Implementation 58

5.2 TSS 59 5.3 TPM Emulator - Virtual TPM 59

5.4 Remote Attestation Protocols 60 6. Security Analysis 64 6.1 Attack Scenario 64

6.1.2 Proposal 1 65 6.1.3 Proposal 2 65

7. Summary of Findings 68 7.1 Results 68 7.2 Future Technologies 69 List of Figures 70 List of Abbreviations 72 References 73

3


4


Acknowledgments

I am extremely grateful to Almighty God who provided me not only the

opportunity but also the strength and power to acquire knowledge, skills and

abilities for the successful completion of my thesis.

First of all I like to thank Mr. Nicolai Kuntze who supervised me in

Fraunhofer SIT. He helped me a lot during all the phases and his kind

behavior always motivated me. He kept me on the track to achieve the exact

goals of this thesis work. I learned a lot from the meetings and discussions

with him.

I also acknowledge the support and help by my supervisor Micael Lundvall at

KTH Royal Institute of Technology. The Program Director Thomas Lindh and

Bo Aberg for my master’s course always helped me in administrative work

related to thesis.

At last but not least I like to thank all my colleagues at Fraunhofer SIT whose

presence was bliss for me and administrative staffs who never made me feel

that I am not aware of German language.

5


6


Abstract The advent of various virtualization techniques resulted increase in its usage. From mobiles to high end servers, almost everything is getting virtualized, due to its benefits. Moreover the security concerns are rising due to overall network and device expansion. Efforts are making in to remove the loop holes in the software based security solutions. To cater this hardware based security solutions are introduced in market, in which one of the solutions is based on Trusted Platform Modules. In this Thesis, we have discussed the background and needs of Attestation through virtual TPM. We have established the approaches to attest the Virtualized environments. It includes the remote attestation protocols for the guest and host operating systems.

The aim of Trusted Computing is to establish and communicate trustworthiness of a particular device. On one hand it provides certain cryptographic abilities and storage methods to create and handle certain asymmetric keys. On the other hand Trusted Computing as specified by the Trusted Computing Group (TCG) also introduces the concept of Remote Attestation. This method allows for a secure reporting of the state of the device including boot cycle.

Attesting an environment therefore requires giving proof on the system started in the controlled environment but also on the system underneath. Different approaches were presented in this area. We have analyzed and compared various virtualization technologies, the problems arising from attestation challenge and to analyze the attacks on the virtualized trusted systems and propose appropriate solutions for that.

Overall aim of this thesis is to study, propose and design the remote attestation mechanism for the virtualized environment to develop secure and trustworthy efficient systems.

7


8


1. Introduction This chapter introduces the thesis work. What motivated us to do research on this topic and what are the adopted methods and approaches to solve the problems and the assumptions which we adopted during this course. We cover different techniques and technologies like virtualization; which is a mechanism to run multiple operating systems on single hardware platform, Trusted Computing; which provides mechanism to trust a platform, and Attestation; which provides the state information to requested party.

1.1 Problem Description There are various challenges involved in making the virtualized systems secure and trustworthy. For attesting these environments various enhancements are needed as compared to non-virtualized systems. The protocols need to be more dynamic and efficient to measure the states of the system individually. Another big challenge is to keep virtual systems independent and isolated from each other in every way. These all challenges are to be studied and analyzed here. The need of the research on this topic arises with the increase in the usage of virtualized systems, as virtualization gives us more leverage for the efficient use of underlying hardware running many systems on it. This increase prompted us to look at the security issues of the virtual systems. The usage is dramatically increased as virtualization provides many benefits like isolation of different systems running on a single platform. The efforts to make these systems secure is the main task. To do that, different things have to be analyzed; how to make the virtual system work with trusted platform module, etc. The challenge is to make the overall system trustworthy without compromising isolation and independency between the guest virtual systems. We will discuss in detail, the need of virtualization and trusted computing. The Trusted Computing Group’s (TCG) Trusted Platform Module (TPM) can be used as a trust commodity which can be used to ensure that system boots with the operating system and configurations which owner considers trustworthy. Moreover it allows the platform to convey information about the

9


state of the system for being considered trustworthy whoever wants to interact or wants to challenge the identity of the platform.

1.2 Goal The goal of the thesis is to propose a secure system which is well efficient as well as well independent. The isolation of system is catered by the virtualization technique and the client side security is carried out with trust establishment. The intentions are to study and analyze the already developed techniques for attesting the virtual systems and to develop and implement a remote attestation protocol for the virtual system. Unlike traditional virtual machines the proposed one will be able to attest their identity and able to identify themselves to the remote challenger. The system is able to detect any changes in hardware or software. This will secure the system and can be used in any client-server model providing the trust at client side. From the end-user point of view in any IT system, the user expects its applications to function without any outside intervention, so that the user can be in full confidence and trusts his system to make use of his personal data and other private applications. Nowadays much of the daily user applications rely on online services such as online banking, shopping, meetings. The servers are consolidated by virtualizng the systems and making use of the benefits of virtualization. These virtualized client systems needs to interact with the service providers to have exchange of important sensitive data as in e-banking, e- commerce, health care and defence departments. The security requirements for the virtual machines increases which we will look at it in this thesis. The chances of attack on a user machine more likely to have access to sensitive information, makes the system untrustworthy. The solution to this resides in the remote attestation of the user platform to identify the state of hardware and software to the remote machine. The need for trust establishment by the remote service provider before the exchange of any sensitive information with the consumer leads to enhanced security of virtualized system. There are available solutions for attesting the non-virtualized solutions and lots of research is ongoing for the development and design of remote attestation mechanisms for attesting virtual machines and it is still in its initial stages of development. This advent of usage of virtual machines and the challenges related to attesting the virtual machines running on VMM needs to build a concept that can provide an consolidated solution of

10


virtualization and trusted computing for attestation process. The security requirements are isolation and attestation of virtual machines. We look into the security requirements posed by the virtual machines and develop a concept for the attestation of virtual machine’s configuration of hardware and application components. The security analysis of the developed techniques will also include here. In our thesis we assume that the system is equipped with the integrity measurement kernel. So we are not doing Integrity measurements and skipping that particular step in Remote Attestation process. It will not cause the attestation process to change as the measured configuration values are zeros by default and we are reading these values. Also that the communication links are properly secured and not leakage of data can occur through the transmission.

1.3 Outline In chapter 1 and 2 we will describe the motivation and the background of the thesis. It will discuss briefly the concepts of virtualization and trusted computing which will be used in the following chapters. In chapter 3 we will start focussing on our main topic that is Remote Attestation. We will discuss various RA techniques, their architecture and their advantages and disadvantages. Following this chapter, we will cover the development of protocols for remote attestation for virtual machines. Chapter 5 details about the implementation issues and how the environment is created to experiment and evaluate our protocols. Chapter 6 includes the security analysis and provides an attack which can be possible on RA mechanism in virtualized environments. In last chapter the summary of findings and challenges which are faced during development of this work are presented with theirs usage and futuristic approach.

11


12


2. Basic Principles In this chapter we will build our concept about the basics of background technologies like Virtualization and Trusted Computing. We will discuss the needs and different approaches that are currently used with their pros and cons to make it easy to understand the selected approach used for remote attestation in the next chapters. 2.1 Virtualization “Virtualization is an approach of deploying computing resources that isolates different layers – hardware, software, storage, network, data, etc.” [1] A framework or methodology of dividing the resources of a computer hardware into multiple execution environments, by applying one or more concepts or technologies such as hardware and software partitioning, time-sharing, partial or complete machine simulation, emulation, quality of service, and many others. Virtualization is modified solution between centralized and decentralized systems [3]. Decentralization helped with the ongoing maintenance of each application, since patches and upgrades could be applied without interfering with other running systems. For the same reason, decentralization improves security since a compromised system is isolated from other systems on the network. Decentralization decreases the efficiency of each machine, leaving the average server idle 85 to 90 percent of the time.

2.1.1 Why Virtualization? In a traditional environment usually one server is associated for a particular application. This way of usage is wastage of CPU power, memory and other hardware resources. An organization often needs to run several servers: a web server, a database server, a mail server, an FTP server etc. For all these to deploy, it is costly as well as cumbersome to handle multiple hardware boxes. To reduce the cost and improve the efficiency of hardware, virtualization concept makes it possible to run multiple servers on the same

13


hardware machine with each server/application completely independent of the other, without having any knowledge of other virtual machine. The decoupling of software layer from its underlying hardware resources enables the consolidation and aggregation of servers which benefits in many ways like utilization, availability, and flexibility [1], [2].

2.1.2 Benefits of Virtualization

Some of the benefits [1], [2], [3] of adding the virtualization layer are pointed here:

1. The security of guest operating system increases as they are running independently in form of compartments.

2. Efficiency of hardware usage increases 3. Reallocation of hardware resources according to requirement becomes

easy without the usage of screwdriver kits 4. Multiple different operating systems can be run on a single hardware

platform side by side. For example one machine running Microsoft Windows while other Ubuntu Linux.

5. Power consumption and other related expenses like air conditioning lowers

6. Physical space like floor space and rack space for the computing environment readily decreases.

While virtualizing any system, certain things must be kept in mind before taking the decision. Few of them are performance, server sprawl, complex deployment and maintenance.

2.1.3 Virtualization technologies There are many Virtualization techniques [1] available in market at different levels according to the user requirements. Most important one is the server virtualization. Our main focus of study is server virtualization but we would discuss other virtualizations as well to have a better insight and comparison with server virtualization. Other includes storage virtualization, network virtualization and application virtualization. Each technique is adopted according to user requirements and considering the use cases.

14


2.1.3.1 Server virtualization It is the masking of server resources that is operating systems, number and identity of physical servers [2]. Thus, in simple words it is dividing one physical server into multiple isolated virtual environments. Server virtualization is further categorized into Full Virtualization, Para-Virtualization, OS Virtualization and Hybrid Virtualization. These are explained below: 2.1.3.1.1 Full virtualization It is used for the complete simulation of underlying hardware. The OS is completely decoupled with the hardware by the virtualization layer. We can run different operating systems side by side on a same machine without any changing in the operating system itself [1]. Figure 1. Full Virtualization Layer Pros Some of the advantages of full virtualization are pointed below:

1. Complete isolation between the operating systems 2. No modification is OS required 3. Near native CPU and memory performance 4. Trap and emulate instructions in runtime via binary batching

Cons The disadvantage of Full Virtualization is that its performance can be impacted by trap and emulate technique of x86 privileged instructions

15


Products Some of the market products available for full virtualization technology are Microsoft virtual server, VMware server [4] and VMware ESX [4]. 2.1.3.1.2 Para virtualization (OS-assisted) It provides partial simulation of underlying hardware. It Grants address space virtualization. Its use is felt as there is not always the need of emulating the whole hardware resources. Moreover the performance measures can also be seen in para-virtualization [1], [2].

Figure 2. Para-Virtualization Layer Pros The advantages which para-virtualization provides over other types of virtualizations are given below:

1. Easier to implement 2. No hardware assistance available 3. Highest performance for network and disk input output.

Cons The most important points which makes para-virtualization at back step are:

1. OS modification is needed 2. Lack of Backward compatibility 3. Not very portable

Products The most famous virtualizing tool for para-virtualization is Xen [5].

16


2.1.3.1.3 OS virtualization It is based on single Operating System. The Guest Operating System are installed on the Host OS with complete and whole segregation [1] [2]. Figure 3. OS Virtualization Pros The main advantage is its easy management due to single host OS Cons

1. No support for mixed OS families 2. Not good isolation and security between virtual machines 3. Difficult to limit resource consumption per guest

Products Parallels virtuoso containers 2.1.3.1.3 Native virtualization (hybrid virtualization) It is combination of full and para-virtualization. It uses I/O acceleration techniques (moves data more efficiently and fast). In this method no OS modification is required, but it uses Hardware assistance. Pros Few of its advantages are:

1. Support x64 OS 2. Employs acceleration techniques

Cons Its disadvantages are:

1. Requires CPU architecture that supports hardware acceleration 2. Require some OS modification for para-virtualized guests

17


2.1.3.2 Storage virtualization In most of the storage virtualization the multiple physical devices are presented as single entity to the host server and operating system. (E.g. RAID implementation) New techniques are developed to migrate storage in real time from one storage platform to another in the background based on particular rules. 2.1.3.3 Network Virtualization Network Virtualization is the splitting of the available bandwidth into many channels which acts independently to improve the efficiency and performance of the overall network. Some of the most important forms of network virtualization are:

1. Virtual LAN 2. Virtual IP 3. Virtual private network

2.1.3.4 Application Virtualization (software virtualization) It is a technique to separate applications from Operating System and hardware hosting the Operating System. Figure 4. Application Virtualization It uses application virtual software packages to place data rather than using conventional installation procedures. Each application runs in its own computing space. The product readily available for application virtualization is Microsoft Softgrid.

18


2.1.4 Inside Virtualization The goal of virtualization [3] is to isolate the OS from the underlying hardware system. It can be achieved by introducing shim layer between the OS and hardware which can act as an interface between these two. The most common CPU architecture is x86. In x86 family, the protected mode uses four privileged levels called rings numbered from 0 to 3. Ring 0 is the center one and have the total control of the processor. Ring 3 is the outermost and has the restricted access. Ring 0 to Ring 2 are unrestricted rings called supervisor rings.

Virtualization moves Ring-0 up the privilege rings model by placing the Virtual Machine Monitor, or VMM, in one of the rings, which in turn presents the Ring-0 implementation to the hosted virtual machines. It is upon this presented Ring-0 that guest operating systems run, while the VMM handles the actual interaction with the underlying hardware platform for CPU, memory, and I/O resource access.

Figure 5. x86 Previleged Rings There are two types of VMMs that address the presentation of Ring-0 as follows:

19


2.1.4.1 Type 1 VMM

Type 1 Virtual Machine Monitor [2] is the software that runs directly on top of a given hardware platform, in the true Ring-0. Guest operating systems then run at a higher level above the hardware, allowing for true isolation of each virtual machine.

Figure 6. Type 1 Virtual Machine Monitor [30] 2.1.4.2 Type 2 VMM Type 2 Virtual Machine Monitor [2] is the software that runs within an operating system, usually in Ring-3. Since there are no additional rings above Ring-3 in x86 architecture, the presented Ring-0 on which the virtual machines run on is as distant from the actual hardware platform as it can be. Although this offers some advantages, it is usually compounded by performance-impeding factors as calls to the hardware must traverse many diverse layers before the operations are returned to the guest operating system.

20Figure 7. Type 2 Virtual Machine Monitor [31]


We would be more interested in Full Virtualization and gives a brief overview of para-virtualization as well. For full virtualization we would be emulating the hardware resources using QEMU. The selection of Full Virtualization as our option is due to its simplicity and easiness in use. The motivation behind the usage of Qemu as a full-virtualizer is given below:

1. There is no need of modification in OS 2. TPM support for Qemu is available 3. Simplicity of design and functioning

Setting up a para-virtualized environment like Xen with TPM support is cumbersome process. In Qemu the TPM support is available which can be added by patching the Qemu. The patch for TPM support is available in mailing list of Qemu.

2.2 Trusted Computing The tremendous increase in the network and network contents have given birth to various challenges. Among these challenges one of the most discussing and important one is the security of the terminals. Usually most of the security is concern with the server side without giving much importance to the security at client side. Moreover the solutions to provide security are mostly solely based on the software only, which can be breached in one way or the other. To solve this, a new idea of hardware cum software solution is developed by a consortium consisting of major vendors of the computer world. Trusted Computing [5] is a concept in which we can trust a platform embedded with a specific hardware and with special software stack which is able to do measurements which can be trusted on the basis that they are unable to temper with. These measurements can be reported to remote parties for attestation. We will discuss briefly about this new idea building, its components and functionalities and later on we will discuss various techniques that are currently working for remote attestation and do a comparison about it. At last we will try to highlight the challenges associated with trusted computing when it is applied to virtualized platforms. Trusted Computing arises to address the security problems of today’s world. It refers to specific performance or the expected behaviour of the platform. If the platform misbehaves than the expected one it would be able to stop the communication or halt the process in some way or other. Using trusted computing a remote system is able to trust a particular platform that it is

21


behaving accordingly with no malicious code inside it. TC refers to the addition of hardware to enable entities with which computer interacts to have some level of trust. TC is developed by a non-profit consortium called trusted computing group TCG.

2.2.1 Trusted Computing Group (TCG) This organization [5] is responsible to define, develop and promote TC standards and building blocks of the TC. Its members consist of major vendors of computing world like IBM, HP, SUN, etc. there are different channels in which TCG are working as groups for secure computing environments like mobile, server, storage TPM, and various others.

2.2.2 Why Trusted Computing? Question arises that why we need trusted computing, when we have different software security solutions. One of the answers to this question is that software solution is always run on the operating system, so if the OS itself is corrupted then it will not be able to detect or measure this. Moreover there is always a possibility of an attacker to breach the software. Some of the applications of TC [5] are just mentioned here:

• Enhance security of digital signature process • Identity management • Secure bootstrap and secure execution of applications • Remote attestation

In this thesis we will keep our main focus on Remote Attestation.

2.2.3 What is Trust? Trust [6] is a relative term. In real life it can be treated a degree of confidence or belief. Even in computer world the meaning of trust is very similar. How much one can have a confidence in some platform defines the degree of trust. Trust is not black and white rather it can have grey areas as in real life that you can trust one friend more than the other. Similarly we can say that some systems are trusted more than others. In simple words it defines the degree of confidence. Moreover it must be noted that the Trust is not transitive in case of TPM.

22


2.2.3.1 Transitive Trust Transitivity [32] of trust can be defined in a way that trust can be extended from one entity to other like if entity A trusts entity B and entity B trusts entity C then entity A automatically trusts entity C. this is called transitive trust. In real life the trust is not transitive. In computer there are some cases the trust is transitive and in some cases it is not. We will discuss the trust transitivity in case of TPM in section 2.2.10

2.2.4 Trusted Platform

Trusted platform [] is defined as a computing platform that has a trusted component, which is used to create a foundation of trust for software processes. TC developed a hardware component for that which they named trusted platform module TPM. The TCG provides the specifications for the requirements of the trusted platform, which includes its operation and storage rules. 2.2.4.1 Architecture of Trusted Platform The trusted platform can be seen as consisted of two main parts; the trusted hardware part called Trusted Computing Platform [4] and the software part which is being used for communicating with the TCP, called Trusted Operating System. Trusted Computing Platform As mentioned above it is the hardware part of the trusted system. It provides all the functionalities and operations to perform at the hardware level. TCG specifies a TCP named as Trusted Platform Module which is usually embedded in mainboard of the system. Trusted Operating System As its name implies, it is an operating system necessary to design a trusted system as it is used in the communication and implementing security functions.

2.2.5 Trusted Platform Module TPM [4] is a hardware component embedded in the trusted platform. It consists of various functions. Basically it provides Root of trust for storage and Root of trust for Reporting.

23


2.2.5.1 TPM Components Trusted Platform Module [5] consists of following components which have specific abilities to perform their functions. It must be noted that TPM is not itself a platform but a part of platform. Trusted Platform Module is shown in the figure with its main components. Here are the internal components of TPM.

Figure 8. Trusted Platform Components I/O As from the name, it manages the information flow into and out of the TPM through the communication bus. Typically the bus is called LPC that is low pin count bus. SHA-1 Engine: This is the engine for measuring the Hash or digest. It uses the SHA-1 algorithm and it can be used externally to get the hash values, including boot process. Random Number Generator: It is one of the most important components of TPM. It is the source for randomness. It is used for nonce and key generation. RSA Engine and Key Generator The keys of 512, 1024, 2048 bits can be generated. It also gives the functionality of asymmetric encryption and decryption. The keys need to be loaded into TPM after generation if to be used.

24


Volatile Memory Volatile memory of TPM has main two portions; PCR and key slots Platform Configuration Registers PCR is the volatile memory storage for integrity measurements. The measurements inside PCR can not be over-written but can only be extended. They can track all the measurements. They are then read to make certain decisions about the system state. Key Slots The generated keys need to be loaded before their usage by the TPM. The key slots are meant for loading the keys. Non-Volatile Memory There are certain keys which need to be non-volatile and non-mogratable. The keys like Endorsement key, Storage Root key, Owner authorisation, EK Certificate, etc are stored in non-volatile memory. Opt-in The usage of TPM can be decided by the TPM owner using this module of TPM Execution Engine: This is a microcontroller which controls all the inside functioning of TPM. It verifies, parses and executes the commands. HMAC Engine: It provides the proof of integrity and authentication of data knowledge. 2.2.5.2 TPM Keys TPM is capable of generating and storing the keys in it. There are different types of keys forming a specific hierarchy. We will discuss a few important TPM keys [8] here Endorsement Key It [8] is the key which allows the people to take the ownership of the TPM. It is permanently embedded in the Trusted Platform Module (TPM) security hardware, generally at the time of manufacture. It is 2048 bit RSA non-migratable key. Only the public part of the EK can be read. EK is used to recognize that the TPM is genuine.

25


Storage Root Key It [8] is the root of the TPM keys hierarchy. It is also 2048 bit RSA non-migratable key. They are used to encrypt their child keys and also for sealing purposes. Attestation Identity Key They are non-migratable signing keys [8] which are used by Certifying Authority to certify that AIK belongs to a TPM and issues certificate for that. There can be multiple Attestation Identity Keys for one TPM. 2.2.5.3 TPM Functionalities TPM can be thought as a tamper-evident device which means that unauthorized things can be detected. Basically we can categorize its functions into two categories:

• Shielded Locations • Protected Capabilities

Shielded locations include memory locations inside TPM like PCR. Protected capabilities include functions like encryption, decryption, sealing, binding, key generation, etc. TPM capabilities are briefly explained below: Binding Binding [5] is a process of encrypting an encryption key. The SRK, which is created during the ownership, is used to encrypt some other TPM key, this process is called binding or wrapping. Through binding we can store the keys securely outside the TPM storage. Sealing Sealing [5] is a process of binding a key and associates the wrapped key to the state of the platform. So that TPM will not unwrap the key unless the required state of the platform is met or achieved. Quoting/Attestation Quoting [5] is a process of getting a signed report of current PCR values. This signed report of PCR’s is called Quote, which is further used for the attestation process of the platform.

26


2.2.6 Foundation of Trust The TPM creates a hardware-based foundation of trust [7] [8], enabling enterprises to implement, manage, and enforce a number of functions like cryptography, storage, integrity management, attestation and other information security capabilities.

2.2.7 Root of Trust There are basically three Root of Trust [6],[7],[8] named:

1. Root of Trust for Measurements (RTM) 2. Root of Trust for Storage (RTS) 3. Root of Trust for Reporting (RTR)

TC consists of the establishment of trust. This trust starts from a point where we are sure that it is not tempered with or in other words we trust the starting point. This gives rise to the concept of the root of trust.

RTR RTS

PROTECTED CAPABILITY

SHIELDED CAPABILITY

RTM

TPM

Figure 9. RTS and RTR lies inside TPM 2.2.7.1 Root of Trust for Measurements RTM is a computing engine which is used to do integrity measurements for the software running on the platform. These values are recorded inside TPM. Typically the normal platform computing engine is controlled by the Core Root of Trust for Measurements (CRTM). CRTM is the first code entity which runs on a trusted platform providing the anchor for trust establishment on other hardware pieces and application layers. It usually resides inside BIOS and executes at boot time measuring the state of the system before the operating system is loaded or some

27


malicious codes becomes functional. This must be trusted in order to report TPM. The reflashing of memory has certain criteria cant can’t be done by untrusted parties. 2.2.7.2 Root of Trust for Storage RTS provides the trust for the storage of integrity measurements and sequences of digests. 2.2.7.3 Root of Trust for Reporting RTR provides the trust to reliably report the information about the platform. It should be mentioned that these Root of Trusts must be trusted for TCG compliance. There must be a component from where we can start our trust establishment. This is generally called Core Root of Trust for Measurements.

2.2.8 TPM Credentials For a platform to be considered trusted, it must first obtain the following core credentials from an endorsement CA, a platform CA, and one or more conformance CAs, respectively. 2.2.8.1 Endorsement Credential Each TPM is associated with a unique asymmetric encryption key pair called an Endorsement Key (EK) pair. An endorsement credential provides the surety that the TPM is genuine by binding the public component of this key pair to a TPM description. Endorsement Credential is mostly issued by the TPM manufacturer, with the binding taking the form of a digital signature created using a signing key of the manufacturer. It is one per platform. 2.2.8.2 Platform Credential A credential, typically a digital certificate, attests the platform containing a unique TPM and TBB. It can be used to uniquely identify a specific platform. It also asserts that a TPM has been correctly incorporated into a design conforming to the TCG specifications. The platform CA is typically the platform manufacturer or vendor, but it can be an independent trusted party. In order to create a platform credential, the platform CA requires endorsement credential and conformance

28


credentials to examine it. The Platform Credential contains the name of the platform manufacturer, the platform model number and version and references to the Endorsement Credential and the Conformance Credentials. 2.2.8.3 Conformance Credentials A Conformance credential indicates that the Trusted Building Block (TBB) design and implementation has been accepted according to the evaluation guidelines. It can vouch the information that a particular type of TPM and associated components (such as a RTM and the connection of the RTM and TPM to a motherboard) conform to the TCG specifications. Conformance CAs must be entities with sufficient credibility to evaluate platforms containing TPMs, and are typically conformance testing facilities contain the name of the evaluator, platform manufacturer, the model number and version of the platform, the TPM manufacturer name, TPM model number and version or stepping and a pointer to the location of the TPM and platform conformance documentation. It doesn’t contain the sensitive information and it can not identify the platform. 2.2.8.4 Attestation Identity Key Credentials AIK credentials are extensively used to remote attestation process to make sure the remote verifier that AIK is associated with a valid TPM. It is issued by a Privacy CA that contains the public portion of an AIK key signed by a Privacy CA.

2.2.9 Integrity Measurements It is one of the most important tasks of TC to measure the loaded softwares with integrity and reliability. TC works on the concept of “measure before loaded”. So at every step the next executable block is first measured before passing control to it. Typical components are BIOS, master boot record, boot loader, operating system and application softwares. One component measure the next component that is measures its hash value and stores it in shielded location of TPM called platform configuration registers. In this way a chain of trust will be formed from the starting point to the application level. The log of these measurements is stored outside the TPM and is called Stored Measurement Log (SML). It enables the detection of modified code and malicious or unwanted software which might compromise the platform’s security and thus its level of trust. SML consists of the hash values of the loaded components and/or applications.

29


2.2.10 Chain of Trust It starts from a point where we can trust. A firmware called Core Root of Trust Measurement is present in BIOS. The measurement starts from CRTM, it measure BIOS and stores its hash in the PCR, then control is passed to BIOS, it measures Boot record and stores it in PCR. In this way the chain will execute till the operating system. It must be kept in mind that if the CRTM gets malicious in some way then all the other measurements will be corrupted and will not be anymore trustworthy. Also it must be kept in mind that TPM is not doing these measurements rather CPU is doing these measurements and TPM is used for storage and reporting and other cryptographic functions. The insertion in the PCRs is irreversible process known as extending the PCR. A PCR is extended by taking hash of the new measurement (m) concatenated with its old value (p).

p = SHA1( p || m ) It is assumed that the Trusted Building Blocks (TBB), like the system’s main processor (which may function as RTM), BIOS (which may act as CRTM), TPM, memory controller, RAM and the paths between those components that are necessary for integrity measurement and reporting have to be trusted.

CRTM

OS Loader

OS

Application

Measurement

Execution

Figure 10. Measurement and Execution process in Trust Chain

30


Transitive trust [7] is also called inductive trust. It is used to extend the trust boundary. In transitive trust, the Root of Trust gives a trustworthy description of a second group of functions [38]. Based on this description, an interested entity can determine the trust it is to place in this second group of functions. In our case of Attestation, TPM carries out measurements starting from TPM to CRTM to BIOS to MBR to OS and finally to Application. These measurements are extended in PCRs of the TPM and later can be used to make the trust decision. In this way we are not able to say that in TPM the trust is transitive as one block is only measuring the next block. It does not trust the next block. Whether the root is trusted is guaranteed by taking managerial approaches and physical protection mechanisms, root of trust is the only trusted model when the computer power on.

2.2.11 Root of Trust for Virtualized Platforms In normal situation the root of trust for measurement starts from CRTM. It is static way of measurement. It is not feasible to deploy CRTM in the virtualized platforms. There are multiple platforms and TPM contains the PCR contents. If at this moment one OS wants to restart then it must be noted that the TPM should not be reset. To make this happen we have to use the dynamic RTM called Dynamic Root of Trust for Measurements. One of the DRTM is OSLO, which is in very early stages of development.

2.2.12 Virtual Trusted Platform Module When a system is virtualized then different Virtual Machines are able to run on that single platform also called guest operating system. To add the TPM support to these VM also called Guest, we need to emulate the hardware TPM inside a VM. We did that by running the TPM emulator inside each VM and we call it as Virtual TPM (vTPM), which provides the functionalities of real TPM. This way we can measure the state of the virtual machines as well.

2.2.13 Security Attacks on TC The vulnerability of Trusted Computing can be assessed by briefly introducing various attacks that can be possible on it.

31


2.2.13.1 TPM Reset Attack In this Attack the PCR values are reset by an attack to their default values and later can be exploited to produce the required values which can be constructed such that a remote attestation can be carried out with the tampered stored measurement log values to verify it. This attack is presented by Kursawe et. Al [9]. Evan Sparks demonstrated this attack by connecting the system over the Low Pin Count Bus (LPC) the TPM can be reset by connecting the LRESET pin of the LPC bus to ground. TCG doesn’t specify any remedy for this as it is a hardware based attack. This can be contoured by either restricting the physical access to the TPM or by removing the BIOS and Bootlaoder from the chain of trust. 2.2.13.2 Cross Certification Vulnerability The certification of a key can be attacked by replacing the key handle and HMAC parameters for the original key by the attacker’s key and still receiving the certificate from the TPM. The signing key in TPM_CertifyKey is AIK and TPM only checks whether the signing key is legitimate one or not. Sigrid Gürgens et. al [10] discuss this attack in more detail 2.2.13.3 Replay Attack on TPM Authorization Sessions Man in the Middle attack can be used by the attacker to intercepts an authorized OIAP session and store authorized commands and later on replays them. The attacker can also be able to overwrite TPM protected capabilities. 2.2.13.3 Platform Reset Attack In this attack [14], [40] the user dumps the memory contents of the volatile memory, which can include the encryption keys and/or other secrets. This is done usually by knowing the fact that the stored data in volatile memory is readable for a small amount of time after the system is powered off. The attacker removes the power and immediately powers it on and loads the memory contents in some bootable media.

32


2.2.13.4 Timing Attack This attack measures the cryptographic operations and extract private keys from an Open SSL based web server. By analysing the required time for TPM operations it can make it possible to guess a private key. This attack has no practical evidence for this attack is not provided.

33


34


3. Remote Attestation In this chapter we will focus on the main area of our thesis that is remote attestation. We will define it need, it building blocks and discuss various protocols for that.

3.1 What is Remote Attestation? Attestation [25] is a mechanism to authenticate a party to a challenging party. It can be said as a combination of authentication and integrity. The authenticating entity can be an application. In simple words Attestation is the process of vouching for accuracy of information. Remote Attestation, as the name implies, is performed remotely over a network connection according to its protocol. This remote attestation protocol can not be trusted until the entity which contains the application that is operating system can not be trusted. Trusted computing provides the operations and functions to trust the operating system. After that we can be able to rely on the attestation protocol to function as required.

3.2 Remote Attestation and its Need With the increase in system complexity, vulnerabilities are increasing as well. When a sensitive data has to be transferred to be used by an authorized user in an authorized way some policy must be implemented on the client. Since the policy is implemented at client side, an attacker is able to the change or deactivates the client software To cope with this the concept of remote attestation is evolved, in which the client platform is first attested before sending sensitive data to it. Thus the sender first establishes the trust on the client before anything. As the name specifies RA is used to attest the system to remote entity. It is used to verify the platform before any communication takes place. This is very useful in the areas of banking, DRM, controlling access to a network, and wherever the trust is needed by the remote entity. This mechanism is called integrity reporting mechanism. There are different protocols for that.

35


3.3 Remote Attestation Entities In any Remote Attestation process there are usually three entities involved which make sure to execute the protocol and in the end provides the trust for the platform. These include:

1. Validating party 2. Challenger or Verifier 3. Certification Authority

CA ChallengerValidator

Figure 11. Remote Attestation Entities

The validating party is the one which is supposed to verify the application residing in it to the challenger. The challenger verifies the contents of what validating party has sent to it with the consultation of trusted third party.

3.4 Basic Remote Attestation Mechanism In the figure a basic overview of the RA is given. First a challenger requests the platform for attestation. The platform creates the event and gets the signed PCR values from TPM embedded to it. Then the platform asks the repository for the platform credentials which will make sure that the platform is trusted one. After receiving the credential, the platform response backs the challenger. The challenger then validates its response and makes a decision whether the remote platform can be trusted or not. Thus the basic attestation mechanism can be seen in three steps. First consists of gathering the PCR information and signing it with AIK. Second step consists of recognizing that AIK belongs to genuine TPM and issuance of AIK credential by a trusted third party. And third and last step is the validation of PCR information and AIK credential received by the challenging entity.

36


3.5 Techniques for Attestation There are numerous techniques developed for Remote Attestation. We can basically classify all of them into two classes:

1. Binary based Attestation 2. Property based Attestation

We will take an overview of these two techniques and later we will discuss few of the integrity reporting protocols.

3.5.1 Binary Attestation Binary Attestation [26] aims at measuring all executed code. It is the traditional way to perform remote attestation. In BA the validating party computes the hash of the executable code and signs this hash and the challenger would compare the received hash with the hash of a known valid image. In binary attestation the measurements are made on binary executables. BA is based on:

1 Integrity measurement and storing in TPM. It builds the chain of trust from BIOS to OS.

2 TPM, capable of reporting the measurements to verifier. The verifier can match them with the known values to decide whether the verified machine fulfils the security requirements.

3.5.1.1 BA Architecture The platform which performs Binary attestation [34] mostly consists of the following components: Verified Machine: It is the client system which is able to verify its configurations and state of system. It includes the verified platform and TPM chip. Verifier Machine: It is the supposed to challenge the verified machine for attestation process and upon receiving the challenge response it validates the measurements. It includes mainly two entities called Configuration Validator and Configuration Assessment. Configuration Validator is responsible for the validating the PCR measurements by using the configuration log. While the Configuration Assessment is responsible for determining the configuration satisfies the verifier requirements.

37


Directory Service: It is a databank of the application hashes and their corresponding required description by the vendor. It is used by the Configuration Validator while validating the software by getting the values from the component directory of the Directory Services.

Verified Machine Verifier Machine Directory Services

Verified Platform

TPM

Component Directory

Config Validator

Config Assesment

Figure 12. Architecture of Binay Attestation

3.5.1.2 BA Mechanism It includes initialization, measure components and then report components. During initialization, various PCR and configuration log files are initialized. During Measurement, hash values of executables are stored in TPM and the configuration files are extended with additional information. 3.5.1.3 Reporting Protocol Binary Attestation generally follows the following steps:

1. Remote verifier sends a challenge “c” to the platform 2. The platform queries TPM using this challenge by TPM_Quote

command 3. TPM response with the signAIK(PCR,c) 4. The platform returns the signed quote together with the log file to the

verifier 5. Verifier takes the decision

3.5.1.4 BA Limitations One of the most prominent BA limitations is its performance in unmanaged networks like p2p [33]. In a large unmanaged network, measuring and storing hashes can become big problem. As different versions and different nodes will measure different hash values there will be large number of hashes that

38


need to be measured and stored. If we consider P different platforms and R different software versions then the total number of valid hashes will be the multiplication of R and P.

Number of hash values = R x P This large amount of data will be cumbersome to measure and store in practical.

Some of the other limitations of binary attestation are given below:

1. Lack of scalability 2. Privacy invasiveness 3. Lack of openness 4. Static, inflexible, inexpressive 5. Program upgrades, program patches and revocation problem

3.5.2 Property Based Attestation Property based attestation [26] is developed to remove the artefacts of the binary attestation scheme. In contrast to binary attestation it is more flexible. It measures the property of the platform and reports it to the challenger. The property of platform describes the behaviour of the platform; it can be certain security requirement or policies. Attesting properties describes those properties which can result in the attestation if fulfilled. In PA the configuration of the platform is not revealed to the challenger or verifier. Some of the important points about property attestation are:

1. Properties of platform or application are reported instead of hashes of executables

2. A platform is capable of attesting that its current configuration possesses such property allowing a verifier to infer whether a platform is trustworthy or not without knowing which particular software is running

3. Allows data or keys to be sealed to properties. 3.5.2.1 High Level view of PA In Property Attestation, matchmaking process takes place between the verifier policy and the platform policy.

39


Verifier policy The verifier policy includes following important points:

1. Includes verifier’s property requirements 2. Includes trust policy describing which entity she trusts for signing and

certifying property related statements 3. A verifier may have a privacy policy describing to whom she wants to

disclose security requirements and trust policy. Platform Policy The platform policy includes following important points:

1. Includes the properties that can be assured by the platform 2. Privacy and trust policies as well.

3.5.2.2 PA Architecture Property based Attestation process consists of following main components which are briefly discussed and detailed in the figure below Property Certifier: agent that certifies which security properties are associated with which component Verification Proxy: To a verified platform; it acts as a verifier of binary attestation while to a verifier; it acts as a verified platform Property Verifier: engages with property prover in PA. It requires verifier policy as its input

Verified Machine Verification Proxy Directory Services

Verified Platform

TPM

Component Directory

Config Validator

Property Validator

Verifier Machine

Property Validator

Property Directory

40Figure 13. Architecture of Property Based Attestation


3.5.2.3 PA protocol: The property based attestation protocol consists of following steps:

1. Platform verification request 2. Measurement request 3. TPM quote request/response 4. Measurements 5. Config validation 6. Property validation 7. Platform property status

3.5.2.4 Deployment Scenarios There are mainly two scenarios for the deployment of Property Attestation, which are briefly given below:

1. Verification proxy on a dedicated machine: there are only few approved configurations for verification proxy. The verification proxy verifiers can use these configurations for trustworthiness of VP.

2. Self Attestation: to deploy VP on the platform itself. This can be done using virtualization.

Unfortunately, Property Based Attestation only succeeds in shifting the problems with attestation to an entity other than the verifier, with all of the original problems persisting for the entity that needs to verify a PCR- based attestation. Moreover, a software component satisfying a particular property is by no means guaranteed to still satisfy that property after it has been patched, without rerunning the evaluation procedure. Such an evaluation procedure may contribute to the marginalisation of minority platforms, since the cost of establishing that a given platform state matches some desirable property may be so great that only a few well-funded organisations are able to obtain such a result. Also, exactly what properties can be satisfied using such an approach remains an open question? More positively, Property Based Attestation at least shifts the problems to an expert specialising in the particular business of attestation. With this approach, the number of entities needing to verify such complex attestations could be significantly reduced, and these entities could be given additional resources to enable them to complete their task. After the analysis it is concluded that PA is not much suitable in our case because it still contains the problem when the properties are mapped according to configuration. That party still knows the configuration of the platform.

41


We will be more focussing on the Binary Attestation as there are few issues in property based attestation which needs to be discussed and finalized.

3.6 Reporting Protocols Various protocols have been developed. Many of them are still in the developing stage. We will start our discussion from the very basic integrity reporting protocol and later discuss property based attestation protocol. We will also give an overview of some new ideas which can be used in the attestation process.

3.6.1 Basic Integrity Reporting Protocol One of the basic protocols [33] for integrity reporting is discussed here. The entities are involved here are two parties. The steps of remote attestation of B against A are given below:

B A

1. Load Key (AIK_private)

2. Retrieve Quote

3. Retrieve SML

1. Validate AIK Credential

2. Validate Signature

3. Validate nonce and SML

Quote, SML & AIK Credential

Nonce

Figure 14. Basic Remote Attestation Protocol

42


The steps of this protocol are discussed below:

1. A Create a non-predictable 160bit nonce 2. A => B ChallengeRequest(nonce) 3. B Load AIK 4. B Retrieve Quote = sign{PCR, nonce}AIKpriv 5. B Get stored measurement log (SML) 6. B => A Send (Quote, SML) and Cred(AIK) 7. A Validate Cred(AIK) 8. A Validate sign{PCR, nonce}AIKpriv 9. A Validate nonce and SML using PCR

In the first step A, which is a challenger in this case creates a nonce and then challenge B with that nonce. After receiving the request the platform B will load the AIK and sign the PCR and nonce with its private AIK. Then B sends this quote, SML and credential of AIK to challenger A. it verifies the AIK credential and validate the PCR and nonce. In this basic integrity protocol an attacker can masquerade the challenger. The reason for this is that the challenger only identifies that the AIK belongs to valid TPM. There is a solution for this attack that we can use a session key between the challenger and the platform, so the attacker who is not having this session key would not be able to disguise the challenger.

3.6.2 Session based Integrity Reporting Protocol In this protocol [33] we establish a session key. The key is generated according to DH parameters. Both parties agree to the common generator g and common group m. The usage of session key will make sure that the attacker can not disguise the challenger. The protocol is shown in the diagram and discussed afterwards.

43


B A

1. Load AIK_private

2. Retrieve Quote

3. Retrieve SML

4. Compute Session Key

1. Validate AIK Credential


3. Validate nonce and SML

4. Compute Session Key

5. Create Session Nonce

Nonce

Quote, SML & AIK Credential

Session Nonce

ENC(Session Nonce) Session Key Validate Session

Nonce

Figure 15. Session based Remote Attestation Protocol The steps involved in this protocol are given below: A Create a non-predictable 160bit nonce A Generate DH Key A => B ChallengeRequest B GenerateKey B Load AIK B Retrieve Quote B Get stored measurement log (SML) B ComputeSessionKey(KAB) B => A ChallengeResponse A Validate cert(AIKpub) A Validate Quote A Validate nonce and SML using PCR A ComputeSessionKey(KAC) A Create a non-predictable 160bit Session nonce A= > B ChallengeRequest(session nonce) B Compute Response = enc{session nonce1}KAC A > B ChallengeResponse(Response) A Validate Session nonce

44


In Step 1, the challenger A creates a nonce and generate asymmetric key (KA). The public part of KA with nonce is sent to the platform. The platform C also generates asymmetric key (KC) and retrieves the Quote by signing the nonce, public part of KC, and PCR with the private part of the AIK. At the same time platform also calculates the session key. Then platform C sent this information including Quote, public part of KC, SML and AIK credential. The challenger upon receiving this information first validates the credential, nonce, SML using PCR. Then it creates the session key and another nonce and sent it to platform as a challenge to validate the session key. The platform C encrypts this nonce with the session key KAC generated by it and sends back the response. The challenger will validate this nonce. In this way we can protect the communication between the challenger and verified platform from the masquerading attacks. Moreover for more security we can use this session key for encrypting all the following data after this authentication.

3.7 Remote Attestation Challenges RA is still in the stage of infancy and faces many challenges [32]. There are the general challenges for remote attestation of non-virtualized systems. Few of them are given below:

1. The first challenge is closing the gap between existing remote attestation solution and TCG specification. In TCG, trust is defined as the expectation that a device will perform in a particular manner for a specific purpose. However most of the existing solutions do not achieve this

2. The second problem is that most of the existing attestation techniques

do not specifically specify the dynamic nature of programs to be attested

3. Large amount of variability in versions and configurations 4. Another problem is that the time of use and time of attestation

discrepancy Remote Attestation for virtualized systems faces more challenges which are covered in next chapter.

45


46


4. Remote Attestation of Virtualized Platforms When we are dealing with virtualization, it means we are creating multiple virtual environments to run separate operating systems. If the system is installed with the hardware TPM (hTPM), and we want the trust establishment to all the virtualized environments, then one of the solutions is to create the virtual TPM called vTPM instances. Each vTPM instance is associated with its own virtual machine VM.

4.1 Challenges Regarding Attesting Virtualized Platforms The things we should have to cater for this design [21], [26] are given below:

1. Same TCG usage model 2. Association between vTPM and VM 3. Communication and binding between vTPM and hTPM 4. Remote Attestation 5. Migration

We are more concerned with point 4 that is Remote Attestation. And will discuss a bit about the binding between vTPM and hTPM.

4.2 Case Scenario The entities in remote attestation of a virtualized platform [28] can be divided into; Guest is residing on a Host (Virtual Machine Monitor). The other two entities are the same as in traditional attestation, which are Attester and Privacy Certification Authority. This is shown in the figure as below:

HOST

GUESTATTESTER

PCA

Figure 16. Remote Attestation Entities in Virtualized Environment

47


We did Remote Attestation of VM with Qemu as the full virtualization tool.

4.2 Trusting Virtual machines As per our aim of the thesis we want to place a level of trust in the Virtual Machine that the machine is not tempered with or doesn’t compromise the integrity of the platform. With the increase in the virtualization use in networks the security of virtual machine has became an important concern for the organizations. There are several questions which are often asked and in research while concerning Virtual Machines. What are the binding rules between the VM’s vTPM and Host’s hTPM? How the VM will protect its private data and its integrity? What assurances are given that a system operating within one of the virtual environments will not harm the environment, other guest OS's, or the VMM? There are lot of other questions imposed which are gradually being answered and worked around to find their best solution.

4.3 Binding between vTPM and hTPM: The binding between virtual TPM and hardware TPM is very important. As this binding can provide the extra anchor for security on the virtual TPM functionalities and moreover during deep attestation this binding is more essential. The interaction between the virtual TPM and hardware TPM can also be carried out through this binding. There are different approaches by which this binding is achieved. IBM proposes few approaches [15] for binding vTPM with hTPM. In one of its approaches the virtual TPM is tied to the underlying platform by connecting the EK certificate of virtual TPM to that of AIK of the hardware TPM. This way the usual method of getting the AIK credentials remains the same as for the virtual TPM as well. The other approach ties the vTPM and hTPM by issuing the credentials for virtual TPM AIK based on the AIK issued by hardware TPM. In this way the usual method of acquiring the AIK credentials from certification authority changes. The binding between the vTPM and hTPM is mainly concerned with the generation and management of keys. Because keys are the main entities which make the algorithm, storage and overall system secure. The keys

48


generated inside vTPM are not as secured as hTPM, so we can use the hTPM keys to wrap the vTPM keys, which not only serves our purpose of providing extra anchor of security for vTPM keys but it will also increase the binding to a stronger level between vTPM and hTPM. For key generation and their protection between vTPM and hTPM we propose three solutions:

4.3.1 Proposal 1 In first proposal we propose that all the keys are generated by hTPM for all vTPM instances. The problem with this will be high load on hTPM and the identification is required when keys are generated, i.e. at a particular time hTPM is creating keys for which vTPM instance. One solution to this might be to use the request-response procedure, i.e., the hTPM response back the keys to that vTPM which has requested it without keeping any association tables.

4.3.2 Proposal 2: Here we propose that the keys are generated inside vTPM itself according to same algorithm as used by hTPM. To make these keys secure, they can be wrapped with the SRK of hTPM. The problem lies in the very less interaction between vTPM and hTPM. Moreover if by anyway an attacker is able to get the SRK, he can get all the keys for all vTPM instances

4.3.3 Proposal 3 Here the proposal says that the keys are generated by the vTPM itself and wrapped with the corresponding keys of the hTPM. Here we need to create corresponding keys from hTPM to each and every key of vTPM. E.g., AIK(vTPM) is wrapped with AIK(hTPM).

49


4.4 PCR Mapping It must be noted that the PCR 0 – 7 of vTPM are mapped by the physical TPM PCR 0 to 7. The other PCR can be used by the vTPM for the measurements of the guest. The mapped lower PCR specifies the boot measurements of the whole system including the BIOS, Bootloader, etc. the upper PCRs can be used by the Guest for its own measurements. It must be noted that in virtualized environments it is done by the use of Dynamic CRTM.

Figure 17. PCR mapping showing between hTPM and vTPM

4.5 Generate AIK Credential The AIK credential [32] is created by gathering the required information about the challenged platform and sent to the trusted third party called Privacy CA. PCA examines the data sent by client and validates the EK credential, platform credential and conformance credential and issues the AIK credential and encrypts it back to the client by the public part of AIK. The usual process of acquiring AIK credential from a certification authority is demonstrated in the figure 18. Here the Client requests for the AIK credential from Privacy Certification Authority.

50


Figure 18. Generation of AIK Credential It must be kept in mind that the provider of the AIK credential is mostly the manufacturer of the Trusted Platform Module. In case of Virtual systems, the guest operating system in which a virtual TPM is running, the generation of credential takes place with layer below it that is VMM. It is done as VMM in this case is kind of manufacturer of the vTPM. When the AIK credential for the layer below guests is needed, i.e., the credential for the VMM, then the VMM will contact the PCA as PCA is the entity which contains the database for the manufactured TPM. The overall algorithm of the AIK credential can be considered same for both Guest and Host.

4.6 Remote Attestation Protocol for Virtual Machines We will consider two scenarios for remote attestation for virtualized environments. First we will discuss the algorithm to attest the Guest without caring about where it is residing or the lower layers of it. Secondly we will discuss the protocol to attest the whole system including the lower layers as well including VMM. This type of attestation is called Deep Attestation in much of material.

51


4.6.1 For Non-Mapped PCR During the challenge for the platform for attestation process the challenged system will first checks whether the PCR required is a mapped one or not. The process that will be carried out is shown below:

1. Checks if PCR is mapped one

2. Generate and Load vAIK

1. Validate vAIK

2. Issue vAIK Credential

1. Retrieve Quote from vTPM

2. Retrieve SML*

1. Validate vAIK Credential


3. Validate nonce and SML*

Nonce , PCR

vAIK Credential Request

vAIK Credential

Sign_vAIK(PCR,nonce), SML*, vAIK_Credential

CHALLENGER GUEST HOST

Figure 19. Remote Attestation Protocol for Guest Virtual Machine The steps that are carried out in this protocol are discussed below:

1. verifier challenges attester for attestation with 160 bit nonce 2. Checks if the requested PCR is a mapped register. If not it will follow

the following steps. 3. vTPM do the following steps after receiving the attestation request

a. Platform requests the vTPM to generate asymmetric vAIK which is stored in NVRAM of vTPM.

b. vTPM sends a request for the vAIK credential from the VMM. Here the vAIK credential can be issued by the VMM as it is the creator or manufacturer of the virtual TPM.

52


c. VMM sends the vAIK credential back to platform through vTPM

manager. 4. vTPM measures the PCR value and signs PCR and nonce with the

private vAIK. 5. platform reads the SML 6. platform sends {Sign_vAIK(PCR,nonce), SML, vAIK_Credential}to

verifier 7. Verifier receives the challenge response from attester and will perform

following steps: a. First it validates the vAIK credential that AIK belongs to the TPM

by checking the vEK, Conformance and Platform Credential. vAIK credential contains the public vAIK, which is read from it.

b. Now the verifier validates the signed data of PCR and nonce. It will extract the PCR value and the nonce by using the vAIK public. It will check whether the nonce is the same as was sent or not. Moreover this step also verifies vAIK signature.

c. The validity of PCR content is done in this step. The verifier will calculate the hash from the SML and compares it with the PCR value. If it equals and all the above steps are successful then the system can be trusted

8. Verifier then replies back to the attester that it trusts the attester or not.

It must be noted that the hardware TPM authenticity can be added in the vTPM authentication process.

4.4.2 For Mapped PCR – Deep Attestation When the challenger requests for the attestation of the PCR which is mapped one, it means that it is interested in attestation of the lower layers as well, i.e. VMM. Mostly this kind of attestation in which the verifier wants the attestation of the system beneath the VM is called Deep Attestation.

53


1. Checks if PCR is mapped one

1. Validate vAIK

2. Issue vAIK Credential

1. Retrieve Quote from vTPM

2. Retrieve SML*

1. Validate vAIK & AIK Credential

2. Validate Respective Signature

3. Validate Respective nonce and SML*

Nonce , PCR

vAIK Credential Request

Quote, Deep Qoute

CHALLENGER GUEST HOST

1. Generate and Load vAIK

1. Generate and Load AIK

vAIK Credential Request 1. Validate AIK

2. Issue AIK CredentialSign_AIK(PCR,nonce),

SML1*, AIK_CredentialSign_AIK(PCR,nonce), SML1*, AIK_Credential

PCA

Nonce , PCR

vAIK Credential

Figure 20. Remote Attestation Protocol for Guest VM and Host

The steps that are carried out in this protocol are discussed below:

1. verifier challenges attester for attestation with 160 bit nonce 2. Checks if the requested PCR is a mapped register. If it is then follow

the following steps. 3. Guest will send this request to physical TPM with same nonce. 4. In the meantime vTPM gets its vAIK credential from the VMM 5. hTPM will do the following steps

a. generates AIK b. gets AIK credential from privacy CA c. signs the requested PCR values and nonce i.e. Sing_AIK{PCR

, nonce} d. gets the SML values for the PCR e. assembles the data and sends back to the vTPM manager (or

TSS on Dom0) from where it is requested.

54


6. vTPM takes the assembled data and signs it with its own private AIK 7. Assembles this data with the vAIK credential and sends back to the

verifier. [Sing_AIK{PCR, nonce}, SML, AIK_Cred ], [Sing_vAIK{vPCR, vnonce}, vSML, vAIK_Cred]

8. Verifier receives the challenge response from attester and will perform following steps:

a. First it validates the vAIK credential that vAIK belongs to the vTPM by checking the vEK, Conformance and Platform Credential. vAIK credential contains the public vAIK, which is read from it.

b. Verifier decrypts the received data using public vAIK. c. Now Verifier evaluates the AIK_Credential of the physical TPM d. Reads the PCR value and nonce. It validates the nonce with the

one it sent in request e. PCR value is compared with the hash of the SML f. If it equals and all the above steps are successful then the

system can be trusted

9. Verifier then replies back to the attester that it trusts the attester or not.

4.5 Dynamic Root of Trust of Measurement (DRTM) The main problem of CRTM is its large Trusted Computing Base [25]. We couldn’t achieve secure level of ordered by TCG with big TCB. We can reduce the size of TCB by removing the OS and VMM from old TCB. In a scenario where multiple virtual machines are running on a single hardware machine, and if need arises to reset a particular VM, we don’t want re-measurement of the entities that are part of booting process of operating system. The reason behind this is that we are mapping the lower PCR measurements to the vTPM of the VM. There are different solutions proposed for this challenge. The two most important of them will be discussed briefly.

4.5.1 OSLO Open Secure LOader (OSLO) proposes to use the dynamic root of trust feature of newer x86 processors as this shortens the trust chain, can minimize the Trusted Computing Base of applications and is less vulnerable to TPM and BIOS attacks.

55


Resetting of PCR at every start-up of virtual machine can cause some problems, which is discussed above that we do not want to reset the Lower PCRs as they are the measurements of BIOS and Bootloader. It can be solved by eliminating the measurements related to BIOS, Bootloader from the chain of trust. This is possible in the new chips of AMD and Intel. OSLO [25] can solve our problem in the ways discussed below:

1. On VM start-up or reset, only a particular PCR is reset. In OSLO the DRTM will only reset PCR 17. In this way DRTM can tell whether the reset is malicious or it’s a DRTM request.

2. The removal of BIOS, Bootloader from the chain of trust, as discussed

previously.

OSLO is basically meant for removing the problems of booting process of CRTM. The TCB size still remains as a problem, which is discussed by the NIZZA.

56


57


5. Implementation The implementation of the concept of Remote Attestation for Virtual Machines is implemented by using Qemu as a full virtualization tool. The host OS is Ubuntu Jaunty 9.04 and the Guest OS is also Ubuntu Jaunty 9.04. vTPM on the Guest is implemented by using the TPM Emulator by Berlios and the TSS used in our case is jTSS with inclusion of iAIK libraries for different functionalities. We make four different java codes which interact with each other for the complete process of RA of VM. We have implemented the Remote Attestation protocols for Virtual Machines which is discussed in previous chapter. The RA of VM for non-mapped PCR and with mapped PCR also called deep attestation is implemented by using various tools as mentioned above.

5.1 QEMU Implementation The Virtualizer used to virtualize the system to create virtual machines is Qemu 0.9.1 [11]. it is an open source machine emulator which we used as an alternative to full virtualizer. It runs only on x86 architecture processors. We used Qemu as a full virtualizer because the support for TPM is now available and moreover it is easy to setup. In general Qemu doesn’t support TPM capabilities. To achieve this we patched the Qemu emulator to add TPM support [6] and then built it. Qemu disk is created for the VM and then OS is installed on it and later on it can be run with the TPM support for VM with this simple command line in terminal: qemu – tpm <socket path for TPM> - m <memory> <path to qemu space for VM>

58


Figure 21. Guest VM on Qemu with TPM Support

5.2 TCG Software Stack Trusted Computing Groups has specified the specifications for the software stack used for trusted computing to develop applications accessing and using high level functionalities of TPM. The latest specifications for TSS are 1.2. There are different TSS [9], [13] developed in different environments for usage, among them includes Trousers in C, TPM/j [13] in java and jTSS in java. We opted for jTSS as our implementation.

5.2.1 jTSS jTSS [22] is developed by the iAIK Graz for the TCG Software Stack for java programming language. It implements all layers in Java. jTSS consists of two parts; TSS Service Provider (TSP) and TSS Core Services (TCS). TSS Service Provider It is the entity which is used for accessing the TPM and all its functions. It allows the user to develop the applications that access the TPM. In simple it provides a link between the application and the TPM. You need have the right for permission of read write the TPM created socket.

5.2.2 TSS Core Services TCS is a daemon which interacts with the TPM. It is responsible for creating the TPM command streams, TPM command serialization, TPM resource management, event log management and the system persistent storage. It is implemented as a library.

5.3 Virtual TPM vTPM is implemented by using the TPM emulator [12] developed by Berlios. It is installed in every VM separately. The vTPM and even the hTPM need to have ownership before their use. The persistence storage for TPM date needs to be set.

59


Figure 22. Architecture of TPM Emulator and its interaction TPM Emulator implements three different components:

1. tpmd: It is a user-space daemon to implement all the TPM functions and its components which satisfies the specifications of the TCG

2. tddl: It is an interface to access the TPM emulator. It is formed as a device driver library for Unix

3. tpmd_dev: It is a kernel module simulating a physical TPM by providing the character device /dev/tpmforwarding all commands to the user-space daemon tpmd

5.4 Remote Attestation Protocol Remote Attestation protocols have been developed using all the entities discussed above. We have developed the code that runs in Host OS and Guest OS and also developed the Privacy CA and Remote Attester. PCA issues the AIK credentials to the requested party and Remote Attester verifies the measurements and credentials sent from the guest or host and issues the RA credential. Two project files are created one Basit_Host and other Basit_Guest. Basit_Host must reside on the host while Basit_Guest resides on Guest VM. The four main program codes are named as; host.java, guest.java, pca.java, ra.java. The input arguments for the programs are fetched from a file called

60


Settings.java. It includes the default configurations and path for the storage of keys and credentials. PCA and RA are run first, then Host and then Guest program. To run this developed system it is provided that TPM Emulator and Qemu is properly setup on Host Operating System. The Guest Operating System contains properly setup TPM Emulator as well. The necessary steps to run the Remote Attestation protocols, which should be followed are given:

1. Run TPM on Host machine by running the command on shell tpmd –d –f

2. Set the location of persistence storage in jtss_tcs.ini and jtss_tsp.ini in Basit_Host project.

3. Set the locations for key storage and certificate storage in Settings.java

file under Basit_Host project.

4. Take ownership of TPM on host by running Take_Ownership.java in the Basit_Host project, which will get the authorisation from the Settings.java file. Set the authorisation password in Settings.java file in the same project.

5. Create Server pair keys for PCA and RA with help of

CreateServerPairKeys.java in the Basit_host project. The key pair needs a tag which is given as an argument of the program.

6. Run Virtual machine by using Qemu Emulator

qemu –m 448 –tpm /var/run/tpm/tpmd_socket0 /home/basit/qemuhd -m is the memory assigned, -tpm is the TPM support and its socket and the next parameter is the location of Guest OS. This command will run the Virtual Machine.

7. Set the location of persistence storage in jtss_tcs.ini and jtss_tsp.ini in Basit_Guest.

8. Set the locations for key storage and certificate storage in Settings.java

file under Basit_Guest project. 9. Run vTPM on virtual machine by running

tpmd –d –f

61


10. Take Ownership of vTPM similar as in Host Operating System. Run

Take_Ownership.java under Basit_Guest project, which will get the authorisation from the Settings.java file. Set the authorisation password in Settings.java file in the same project.

11. Now run host.java, pca.java and ra.java on Host machine located in

Basit_Host project

12. Run guest.java on VM located in Basit_Guest project for remote attestation.

13. For Attestation of only guest system set pcr_flag in guest.java,

host.java and ra.java to FALSE. If pcr_flag is set to TRUE, then deep attestation will take place.

14. The AIK certificate of Host can be seen in its storage folder on Host

OS.

15. The vAIK certificate and Attestation certificate can be seen in the storage folder on Guest OS

62


63


6. Security Analysis We have analyzed the remote attestation techniques and developed the remote attestation mechanism for the virtualized environments. We also made efforts to find a possible attack on the Remote Attestation process for the VMs. We give the scenario of the attack, how it will function and what can be the possible solution for that.

6.1 Attack Scenario Consider two Virtual Platforms P1 and P2. the Virtual Platform P1 consists of the Virtualization layer VMM1 and the Virtual Machine installed on it as VM1. Similarly P2 consists of VMM2 and VM2.

VMM1

VM1

VMM2

VM2

VMM1

Figure 23. Attack Scenario in RA of Virtual Machine We consider that the VMM1 is an infected machine or tapered one. All of the other entities VM1, VM2 and VMM2 are good ones. VMM1 challenges the P2 for deep attestation and keep the measurements of its PCR. When a remote attester challenges the VM1 for deep attestation, VM1 measure its quote and send the nonce to the underlying layer of VMM1. VMM1 will use the measurements of the P2 and send that response to VM1 and finally back to Remote Attester that is the VMM1 will gives the false implication that it is VMM2. It is a kind of man in middle attack in which VMM1 masquerades the challenger that it is VMM2.

64


There are two proposals which we like to discuss and present about this attack, which do need many other enhancements to make it fully immune from this attack.

6.1.2 Proposal 1 One of the proposals towards the solution for this problem can be the use of VM Address and signature of VMM in Attestation Response. The VM address can be a unique address over a network to recognize the VM. So in the above discussed scenario, when the remote challenger wants the attestation for VM1, the tampered VMM1 will try to get the information from VM2 and VMM2 of platform 2. VM2 will response back to the challenger with its address that is VM2 address and sign it with VMM2 key. In this way VMM1 can not be able to use the response of platform 2 for the remote challenge. The reason for using the VM address is to identify that from which VM the response is coming and to uniquely identify the VM in challenge. The reason for signing with VMM key is because the corrupted challenger VMM can not be able to change the VM address in the response. In our scenario, when the VMM2 will sign the VM2 address and response back to VMM1, then VMM1 will not be able to make changes in the response and can not be able to forward this response to the remote challenger of VM1, as remote challenger will now be able to recognize that this response is from VM2 rather than VM1. We assume in this proposal that platform 2 is not controlled by bad owner who makes tampering with the VMM1 and the challenger will have a database for VM addresses.

6.1.3 Proposal 2 One of the other proposals can be measuring the number of hops of Nonce value sent as a challenge. Nonce value is used to identify the request and its corresponding response to cater multiple requests and delayed responses. In simple words nonce can be used to identify the challenge request. In this proposal at every step we can extent the nonce with itself and forward it as a nonce for next entity. In normal scenario, when VM1 is challenged with

65


nonce value “N”, the VM1 will take its sha1 and send it to VMM1, the VMM1 will measure the quote and takes sha1 of the hashed nonce again and send it back to VM1. The VM1 will response back the challenger. The challenger will calculate the sha1 of nonce sent twice and compares it with the received one and provides the validation.

VMM1

VM1N

H 1 H 2

H 2

Sha1(Sha1(N))==H 2 Figure 24. Normal Functioning of proposal 2 In our attack scenario, when VM1 is challenged with a nonce, it sends the hash of nonce to VMM1, the VMM1 will use this hash to challenge the platform 2. VM2 of platform 2 will receive this one-time hashed nonce and send the hash of this to VMM2. Then VMM2 will take the hash of two-time hashed nonce and response back to the VMM1 challenger. Now VMM1 can not be able to use this measurement as its response to the remote challenger. Because now the nonce is hashed three times, which will not be validated as it is more than twice.

VMM1

VM1

VMM2

VM2

VMM1

N

H 1

H 2 H 3 H 1 H 3 H 3

H 3 Sha1(Sha1(N)) != H 3

Figure 25. Proposal 2 functionality during bad VMM1 Here we assume that there is strong isolation between the guest and host operating systems.

66


67


7. Summary of Findings This chapter covers the summary of findings based on the analysis and results from this thesis. We will also discuss the use of this thesis work in the current applications examples and its usage in future application environments.

7.1 Results The protocols for the Remote Attestation for Virtualized Environments are successfully created and implemented on the system with Qemu as a full virtualizer and ubuntu jaunty as the host and guest operating system. The TPM was installed on host OS and vTPM is installed on the guest OS using the emulation of TPM. In this thesis we were able find how to virtualize the system and how to create the virtual TPM for virtual machines and how to interact with the privacy CA and remote challenger for the issuance and validation of credentials. The efficiency and isolation challenge was solved by the technique of virtualization but the security of the virtual machines was posing a question mark. We researched on the security of VM and devised the mechanism to secure the client side consisting of VMs by analyzing the main features of remote attestation in an un-virtualized case and then the techniques already developed for the trust establishment of VM. The introduction of hardware with software provides a good solution to enhance the security and to remove the challenges posed by software loop holes. TPM gives the capability to generate and store the secret information which is neither read by the owner of the system neither it can be extracted or accessed by any outside entity. This way it gives a proven way to keep the secrets intact. But there are still few problems which TCG is working on like interoperability and owner control. There are many challenges towards the security and efficiency of the performance of systems. The challenge of isolation and security are catered by the techniques of virtualization and trusted computing simultaneously. We have developed a mechanism in which each virtual machine will be able to attest its integrity to a remote challenger. Not only that, this integrity

68


measurement can be carried out to the lower layers of the guest and thus host can also be able to attest itself to the remote challenger. There are still lot of challenges that need attention. One of them is the trust on the emulated TPM. One needs to trust the vTPM before it can be used to measure and function for the integrity of the guest virtual machine. One of the other challenges is the development of trusted grub and getting the measurement values of the booting process. TC gives us the ability to monitor the changes in the client system whether it can be software based tampering or hardware one, by the mechanism of developed protocols. It is very basic binary based attestation architecture for reporting integrity measurements of VMs.

7.2 Future Technologies The developed algorithms can be used in different application where there is a need of isolated and secure virtual machines. Most of the servers in today’s world are virtualized one which is the main target of this thesis. Other targeted applications include P2P networks, e-banking, e-commerce, health care and defense. The nanodatacenters [39] project by European Union can adopt this technique so that the service provider can be assured of the consumer before the actual transmission of media can take place. This way no unregistered or tampered consumer will be able to capture the media over peer to peer network of nanodatacenters. Trust establishment for VMs is still in its initial phases, and there are more entities still to be developed to make it run as a full fledged trusted network including the secure communication between the PCA and Client equipped with TPM chip and the new virtualizing processor architectures will encourage the use of virtual platforms which will encourage to enhance the security of VMs.

69


List of Figures Figure 1. Full Virtualization Layer Figure 2. Para-Virtualization Layer Figure 3. OS Virtualization Figure 4. Application Virtualization Figure 5. x86 Privileged Rings Figure 6. Type 1 Virtual Machine Monitor Figure 7. Type 2 Virtual Machine Monitor Figure 8. Trusted Platform Components Figure 9. RTS and RTR lies inside TPM Figure 10. Measurement and Execution process in Trust Chain Figure 11. Remote Attestation Entities Figure 12. Architecture of Binary Attestation Figure 13. Architecture of Property Based Attestation Figure 14. Basic Remote Attestation Protocol Figure 15. Session based Remote Attestation Protocol Figure 16. Remote Attestation Entities in Virtualized Environment Figure 17. PCR mapping showing between hTPM and vTPM Figure 18. Generation of AIK Credential Figure 19. Remote Attestation Protocol for Guest Virtual Machine Figure 20. Remote Attestation Protocol for Guest VM and Host VMM

70


Figure 21. Guest VM on Qemu with TPM Support Figure 22. Architecture of TPM Emulator and its interaction Figure 23. Attack Scenario in RA of Virtual Machine Figure 24. Normal Functioning of proposal 1 Figure 25. Proposal 2 functionality during bad VMM1

71


List of Abbreviations AIK Attestation Identity Key

BA Binary Attestation

BIOS Basic Input Output System

CRTM Core Root of Trust of Measurement

DRTM Dynamic Root of Trust of Measurement

EK Endorsement Key

hTPM Hardware Trusted Platform Module

MBR Master Boot Record

OS Operating System

PA Property based Attestation

PCR Platform Configuration Register

P2P Peer 2 Peer

RA Remote Attestation

RTM Root of Trust of Measurement

RTR Root of Trust of Reporting

RTS Root of Trust of Storage

SML Stored Measurement Log

SRK Storage Root Key

TC Trusted Computing

TCG Trusted Computing Group

TPM Trusted Platform Module

TSS TCG Software Stack

vAIK Virtual Attestation Identity Key

VM Virtual Machine

VMM Virtual Machine Monitor

vTPM Virtual Trusted Platform Module

72


References [1] Greg Shields, “The Shortest Guide to Selecting Right Virtualization Solution” by Parallels [2] Davide Rule, Rogier Dittnet, “Server Virtualization”, Syngress Publishers, 2007

[3] John Hoopes, Tom Olzak , “Virtualization for Security: Including Sandboxing, Disaster Recovery” [4] http://www.vmware.com/ [5] http://xen.org/ [6] Trusted Computing Group. TCG Architecture Overview, revision 1.4, August 2007, 2007. Available at www.trustedcomputinggroup.org. [7] Roderick M. Kramer, “Orgatizational Trust”, Oxford 2006 [8] SEAN W. SMITH, “TRUSTED COMPUTING PLATFORMS: DESIGN AND APPLICATIONS”, Department of Computer Science, Dartmouth College, Springer [9] Trusted Computing Group. TCG Software Stack (TSS) Specification Version 1.2, Level 1, Errata A, 2007. [10] Trusted Computing Group. TPM Main, Part 1, Design Principles, spec v1.2 rev103, 2007. [11] QEMU devel mailing list. Patch to Add TPM support. http://www.mail-archive.com/[email protected]/msg13408.html. [12] Mario Strasser et. al. Software-based TPM Emulator. http://tpm-emulator.berlios.de/. [13] Luis Sarmenta (MIT) et. al. TPM/J Java-based API for the Trusted PlatformModule. http://projects.csail.mit.edu/tc/tpmj/. [14] Sparks et. al. TPM Reset Attack. http://www.cs.dartmouth.edu/~pkilab/ sparks/.

73


[15 ] S. Gurgens, C. Rudolph, D. Scheuermann, M. Atts, and R. Plaga. Security Evaluation of Scenarios Based on the TCG’s TPM Specification. NOTES IN COMPUTER SCIENCE, 4734:438, 2007. [16] Nicolai Kuntze and Andreas U. Schmidt. Trusted ticket systems and applications. In H. Venter, M. Eloff, L. Labuschagne, J. Eloff, and R. von Solms, editors, New Approaches for Security, Privacy and Trust in Complex Systems, volume 232 of IFIP International Federation for Information Processing, pages 49–60, Boston, 2007. Springer. [17] Andreas Leicher and Andreas Brett. Ethemba - Ethemba Trusted Host Environment Mainly Based on Attestation. http://ethemba.info, 2008. [18] Sun Microsystems. JDK 6 Security-related APIs and Developer Guides. http://java.sun.com/javase/6/docs/technotes/guides/security/. [19] QEMU. open source processor emulator. http://bellard.org/qemu/. [20] Dr. Andreas U. Schmidt. Trusted Computing: Introduction and Applications, Lecture notes. [21] S. Berger, R. Caceres, K.A. Goldman, R. Perez, R. Sailer, and L. van Doorn. vTPM: Virtualizing the Trusted PlatformModule. 2006. [22] IAIK. Trusted Computing for the Java(tm) Platform. 2008. http://trustedjava.sourceforge.net/ [23] A. Leicher. Trusted Ticket Systems. Diploma Thesis, Johann Wolfgang Goethe Universität, Frankfurt amMain, 2009. [24] Haldar, V., D. Chandra and M. Franz, Semantic Remote Attestation – Virtual Machine Directed Approach to Trusted Computing, in: Proceedings of the 3rd Virtual Machine Research and Technology Symposium, May 6-7, 2004, San Jose, CA, USA (2004) [25] Shi, E., A. Perrig and L. van Doorn, BIND: A Fine-Grained Attestation Service for Secure Distributed Systems, in: 2005 IEEE Symposium on Security and Privacy (S&P 2005), 8-11 May 2005, Oakland, CA, USA (2005) [26] Kauer, B., OSLO: Improving the Security of Trusted Computing, in: roceedings of the 16th USENIX Security Symposium, August 6-10, 2007, Boston, MA, USA (2007) [27] Dries Schellekens, Brecht Wyseur, Bart Preneel, “Remote Attestation on Legacy Operating Systems With Trusted Platform Modules”, Electronic Notes in Theoretical Computer Science 197 (2008) 59–72

74


[28] Shane Balfe, Eimear Gallery, Chris J. Mitchell and Kenneth G. Paterson, “Challenges for Trusted Computing”, Information Security Group, Royal Holloway, University of London, April 29, 2008 [29] Frederic Stumpf_, Michael Benz__, Martin Hermanowski, and Claudia Eckert, “An Approach to a Trustworthy System Architecture Using Virtualization”, Department of Computer Science, Darmstadt University of Technology Darmstadt, Germany [30] Jiqiang Liu Jia Zhao Zhen Han,”A Remote Anonymous Attestation Protocol in Trusted Computing”, Computer and Information Technology Department, Beijing Jiaotong University,Beijing 100044, P R China [31] Ernie Brickell1, Jan Camenisch2, Liqun Chen, “Direct Anonymous Attestation”, Trusted Systems Laboratory, HP Laboratories Bristol HPL-2004-93, June 3, 2004 [32] Liang Gu, Xuhua Ding2, Robert H. Deng2, Yanzhen Zou1, Bing Xie1, Weizhong Shao, Hong Mei, “Model–Driven Remote Attestation: Attesting Remote System from Behavioral Aspect”, School of Information Systems, Singapore Management University [33] Ville Likitalo, “Remote Attestation and Peer-to-Peer Networks”, Helsinki University of Technology, Laboratory of Information Processing Science [34] Frederic Stumpf, Omid Tafreschi, Patrick Roder, Claudia Eckert, “A Robust Integrity Reporting Protocol for Remote Attestation”, Darmstadt University of Technology, Department of Computer Science, D-64289 Darmstadt, Germany [35] Jonathan Poritz, Matthias Schunter, Els Van Herreweghen, Michael Waidner, “Property attestation— Scalable and privacy-friendly security assessment of peer computers”, IBM Zurich Research Laboratory [36] http://upload.wikimedia.org/wikipedia/commons/1/1a/VMM-Type1.JPG [37] http://upload.wikimedia.org/wikipedia/commons/1/1a/VMM-Type2.JPG [38] http://www.trustedcomputinggroup.org/developers/glossary [39] http://www.nanodatacenters.eu/ [40] “TCG Platform Reset Attack Mitigation Specification”, Version 1.00, Revision 1.00, 2008, Available at ww.trustedcomputinggroup.org.

75

abdul basit - fraunhofersit.sit.fraunhofer.de/smv/publications/download/abdulbasit_master.pdf ·...

Documents