Investigation and Development of a Hypervisor-based Security Architecture utilising a State-of-the-art Hardware Trust Anchor

Transcription

1 Investigation and Development of a Hypervisor-based Security Architecture utilising a State-of-the-art Hardware Trust Anchor Author: Martin Schramm Supervisor: Dr. Donal Heffernan Submitted for the Degree of Masters of Engineering Submitted to University of Limerick, Limerick, Ireland April 2011

2 Abstract Investigation and Development of a Hypervisor-based Security Architecture utilising a State-of-the-art Hardware Trust Anchor Martin Schramm Trusted Computing is a relatively new approach to computer security in which a system should be permanently maintained in a well-defined state - and therefore it will reside in a trustworthy state. The word "trustworthy" in this context means that the system always behaves in a specific way as defined by the platform manufacturer and/or the administrator/owner. A key element of this approach is to employ a security module, which is implemented in hardware, and which is tied to the platform so as to serve as a Trust Anchor. Based on that Root of Trust and other features, an effective security architecture is proposed in this research. Virtualization techniques, which were formerly developed for server consolidation, cost reduction, and conservation of energy are now gaining more and more interest in the field of Trusted Computing. Virtualization can greatly enhance the security of a system by isolating applications, or even whole operating systems, by splitting the computer system into smaller parts, whose integrity can be more easily assured. This project is concerned with the development of a system that will effectively combine the isolation features of the virtualization schemes with a state-of-the-art hardware security module. This system will provide reliable protection against sophisticated software-based attacks and will withstand elementary hardware-based attacks. The building block approach of this proposed security architecture makes sure that many different application fields can archive a high level of security by combining the appropriate components. The research examines some emerging approaches to computer security and proposes a novel security architecture based on a hardware Trust Anchor. An experimental system is developed to provide a proof-of-concept model for evaluation. The target application area for the architecture is the embedded computing space, in particular x86 based architectures. The selection of hardware elements and the choice of hypervisor are discussed and justified. The assumptions on the features of the architecture are evaluated and validated in the context of potential security improvements. Future research in this niche area is proposed. i

3 Declaration This thesis is presented in fulfilment of the requirements for the Degree of Masters of Engineering. All the work detailed in this report is completely my own and has not been submitted to any other academic authority in any university. Where use has been made of the work of other people or any information included that was taken from other sources, all such instances have been fully acknowledged and referenced. Signature: Martin Schramm ii

4 Acknowledgements Firstly, I would like to thank my academic supervisor Dr. Donal Heffernan for his guidance throughout this research project. You were always patient and approachable, I couldn t have asked for a better supervisor. I would also like to thank my German adviser Prof. Dr.-Ing. Andreas Grzemba for his support and guidance throughout the project. You are the one who made it possible to perform this project. Thanks must also go to the two students of our project team, Karl Leidl and Florian Kalleder, for their cooperation. The working atmosphere was very good and our common work was quite successful. iii

5 Dedication I would like to dedicate this work to my wife for all your support. You have always encouraged me and backed me up. This achievement is as much yours as it is mine. iv

6 Table of Contents 1. General Overview Introduction Rational for the project Project Objectives Novelty of the Project Literature Survey Publications resulting from this work Structure of the thesis Summary Security Concerns of Today s Deployed x86 Platforms Introduction Objective General Hardware concerns CPU Protection Rings Direct Memory Access System Management Mode Software concerns Buffer Overflows Large Code Base The human factor Summary Background to Trustworthy Computing Introduction Objective General Approaches to computer security v

7 Table of Contents 3.5. Cryptography Hardware-based security techniques vs. pure software solutions Trusted Computing System Trusted Computing Platform Trusted Platform Module Core Root of Trust for Measurement Trusted Operating System CPU and Chipset security enhancements Intel Virtualization Technology for directed I/O Intel Trusted execution Technology Summary Virtualization Technologies Introduction Objective History and motivation Hypervisor selection criteria The Open Source Hypervisor: Xen Domain-0: Host operating system Domain-U: Guest operating systems Paravirtualized guest operating systems Hardware assisted vitualization: HVM guests Further Hypervisors Summary The Proof of Concept System Introduction Objective General Implementation considerations Hardware components Carrier Board COM Modules ETXexpress-PC ETXexpress-SC TPM Modules Discrete TPM Integrated itpm vi

8 Table of Contents Virtual vtpm Software-based TPM Emulator Security enhanced CPU and chipset Additional hardware-based security modules Software components BIOS Virtualization Layer TrouSerS tpm-tools Trusted Boot (tboot) Launch Control Policy Verified Launch Policy Use cases / Application fields Security vs. usability Summary Validation of the Proof of Concept System Introduction Objective General Summary Results, Conclusion and Further Work Review of the Achievements Summary of Results Future work Knowledge gained from this Research Project Bibliography List of Figures List of Tables List of Listings Glossary of Terms A. IEEE Applied Electronics International Conference 2010 Pilzen I B. IEEE Applied Electronics International Conference 2011 Pilzen VI vii

9 Table of Contents C. Embedded World International Conference 2011 Nuremberg XI D. Kontron - Embedded Security Whitepaper XXII E. The Trusted Platform Module XXXI viii

10 1. General Overview 1.1. Introduction Within recent years the number of IT systems, especially embedded systems, has constantly increased. Furthermore, these systems are being applied in more and more specialist application fields. On that account, attacks against IT systems can potentially cause tremendous financial damage, and other security-related problems. For this reason there is a need for a trustworthy platform with a high level of dependability. Such systems must provide both safety and security features. The security characteristics should not only include protection from hardware manipulations but should also be independent of the employed operating system and software. Originally the x86 architecture [45] was designed with a set of different privilege levels, defined in the hardware. However, due to performance reasons only two of these levels are commonly used today. Also, the commonly-used operating systems, today, are macro-kernel based, which can give rise to additional security weaknesses. Regardless of this, most companies need to continue using popular operating systems. To improve on this situation, it is necessary to research the development of additional security elements, both hardware and software based. The increased dependence on electronic networks further heightens the urgency for hardwarebased protection of information, authentication of users, and the establishment of high degrees of trust in local and remote computing systems. The economic impact of failure to protect such information is demonstrated almost daily by the loss of private information, identity theft, and unethical hacking. 1

11 1. General Overview The Trusted Computing Group (TCG) is a not-for-profit organization formed to develop, define and promote open, vendor-neutral, industry standards for trusted computing building blocks and software interfaces across multiple platforms [4]. The Trusted Computing (TC) approach of the TCG should ensure that a system is maintained permanently in a well-defined and trustworthy state. However, the TCG only defines the components necessary for a Trusted Computing Platform (TCP). In order to achieve a Trusted Computing System (TCS) there is an additional need for a Trusted Operating System (TOS) with trustworthy services and applications, that can reside beside legacy services and applications. In the context of this thesis the Trusted Computing approach, as defined by the Trusted Computing Group, is introduced. The background to virtualization techniques and its suitability for enhancing security of modern platforms are presented in context. Subsequently the implementation of a proof-of-concept system for a new efficient security solution, based on embedded x86 hardware, is presented and evaluated Rational for the project It is well-known that the x86 architecture will continue to have a great impact on the embedded computing market sector into the future, where the market will be no longer be dominated by small microcontrollers, due to an increasing complexity of requirements and the added functionality which is being demanded by clients. The ongoing advantages of the embedded x86 architecture are well understood and include a comprehensive development process, decreased power consumption, reduction of costs and the possibility to use common operating systems such as Microsoft Windows or Linux. The Intel Atom processors [25] are gaining more and more ground in the embedded sector, being employed in application fields such as mobile radio communication, the automotive industry, railroad engineering, avionics, medical engineering, industrial automation and more. Moreover, the embedded computing sector has an obvious need for well-designed platforms with inherent protection against both hardware and software security threats. 2

12 1. General Overview Pure software solutions no longer meet the requirements on protection against manipulation and tampering. Such solutions can by their very nature only relate to already known threats. More effective security techniques must consist of a combination of special hardware and software components. System security breaches and resulting downtime, or leaking of information, can be quite expensive and damaging for a manufacturer s reputation. It is necessary to have full confidence in the functionality, reliability and dependability of such devices. Considering the number of embedded applications that use special x86 embedded computer modules, it is suggested here that research work in this specific area of embedded computing is worthwhile for the future. This has led to the idea of the development of a proof-of-concept platform, which would be able to withstand sophisticated software-based attacks by combining the security by isolation approach with effective hardware security modules. In addition, the proposed solution has the potential to be used in a variety of application fields and use cases Project Objectives The proposed research work is part of a project, which is carried out in cooperation with industrial partners. The most important partner is Kontron Embedded Modules GmbH, which is one of the leading manufacturers of embedded x86 solutions. The logo of the company can be found in figure 1.1. Figure 1.1.: The company logo of Kontron Embedded Modules GmbH Kontron Embedded Modules GmbH has one of its biggest development units in Deggendorf, Germany, which is an important contributor to the ongoing research and development work. 3

13 1. General Overview Since it is not deemed feasible to design an all-round generalized solution for a security architecture in the context of a single research project, the work focuses on the development of trustworthy building blocks for an effective in-depth defense. This will involve providing a basic set of requirements to address the vulnerabilities, including an accurate definition of possible injection vectors as well as identifying possible types of attackers. The trustworthy building blocks that emerge from the development work can be used to build a customer specific, well-directed security solution. Figure 1.2 shows the correlation of the individual principal goals. Figure 1.2.: Principal project goals The basic approach will be to use state-of-the-art technologies, including recent security enhancements of processors and chipsets, along with the traditional approaches that have already been invented and proven. The specific objectives of this research work can be stated as follows: Analyze the state-of-the-art technologies of virtualization techniques and their usability for the specific approach towards enhanced security 4

14 1. General Overview Study the recent processor and chipset security extensions Evaluate the current available, and emerging, hardware trusted architectures and investigate the suitability of associated techniques towards enhanced security Develop the building blocks to enable the portability of individual components into other application areas. This will include the preparation of solutions for different levels of security requirements Propose an effective new security solution based on a combined hardware and virtualization based solution. Model and experimentally evaluate the proposed solution 1.4. Novelty of the Project Today virtualization is mainly used in the field of server consolidation to reduce costs and to add redundancy for a high level of reliability. A key novel aspect of the work defined here is the focus on virtualization techniques for the design and development of a security architecture, with special hardware assistance. The following is a summary of the aspects of the research work which have novelty. An additional abstraction layer is suggested, enabling the isolation of untrustworthy elements from the components that are critical to the system s security. To date the main difficulty of the Trusted Computing approach is that the commonly used operating systems are far too complex for complete integrity measurements. Partitioning the system into small pieces through virtualization might permit better integrity verification. In addition if one of the compartments gets compromised it should have no impact on the integrity of the complete system and the infected part(s) can potentially be reset to a well-defined state more easily. 5

15 1. General Overview Weak security inevitably leads to a loss of trust. An appropriate ratio between user trust and security features has to be identified for practical solutions Literature Survey Many of the topics, which were fundamental to the design of the proof-of-concept prototype, needed to be researched. A deep understanding of the Trusted Computing approach needed to be gained. The best sources of information for these topics were found at the TCG website [4] and the TCG specifications [14] [15] [16] themselves. For a better understanding of virtualization techniques in general, and the Xen hypervisor in particular, different books [24] [65] [63] and papers [18] [28] [53] are considered important. However, since the open source project Xen is constantly evolving, the best information can be found at the Xen homepage [8]. When trying to establish how best to create a more secure system utilizing hardware virtualization and trusted computing support, the main resources were diverse whitepapers [32] [33] and "how to" guides [43] [44] [42] from the Intel Corporation. Since the proposed security solution makes use of a security Trust Anchor from Infineon, documents [21] [20] [37] [38], which describe the functional range of the chip, were very helpful. For the creation of some proof-of-concept platform demonstration applications, a book entitled "A Practical Guide to Trusted Computing" from IBM press [23], describing the most important Application Programming Interface (API) calls, was deemed to be very useful. A review of the current published paper from IEEE [34] [35] [56] [57], Intel Corporation [32] [33] and others completed the literature research. After that is was possible to decide on the optimal direction for future development, in the context of this research project. A full list of reference material can be found in the Reference section of this thesis. 6

16 1. General Overview 1.6. Publications resulting from this work Some of the findings of this research project have been presented at the IEEE Applied Electronics International Conference in Pilzen (CZ) in September 2010, titled as follows: Schramm M., Grzemba A.; "The Benefits of Combining Trusted Computing with Virtualization Techniques"; Applied Electronics International Conference, Pilzen, September This paper describes an approach towards a trustworthy operating system based on a Trusted Platform specified by the Trusted Computing Group (TCG) by using virtualization techniques and modern processor hardware virtualization enhancements. The full paper is provided in Appendix A. Furthermore, an IEEE conference paper has been submitted to the IEEE Applied Electronics International Conference in Pilzen in March 2011, as follows: Schramm M., Grzemba A.; "Trustworthy Building Blocks for a More Secure Embedded Computing Environment"; Submitted to the Applied Electronics International Conference in March This paper depicts the necessary components for the creation of a trusted operating system. The concept of implementing a set of trustworthy building blocks for the creation of an effective security architecture based on the Trusted Platform Module in hardware is described in this paper. Appendix B shows the submitted paper. The following paper has been presented at the Embedded World International Conference in Nuremberg (GER): Schramm M., Grzemba A., Heffernan D.; "Utilizing a State-of-the-art Trust Anchor in Order to Increase the Trustworthiness of Embedded Platforms"; Embedded World International Conference 2011, Nuremberg, March This paper points out the shortcomings of the x86 architecture regarding system security and explains why the commonly used operating systems are quite insecure. It furthermore describes the benefits of hardware-based security modules in comparison to pure software-based security 7

17 1. General Overview solutions. After defining important components for a more secure architecture the specific implementation in the proposed solution is outlined. The final paper can be found in Appendix C. Together with the industrial partner Kontron Embedded Modules GmbH the research developed a Whitepaper titled: "Standardized Security Principles for Embedded Computing Industries", describing the main problems regarding security in today s industrial computing systems. The paper characterises the underlying components of the proof-of-concept system as well as the benefits which can be introduced by adding a virtualization layer on top of the bare hardware. Additionally, some sample use cases are pointed out. The Whitepaper is provided in Appendix D Structure of the thesis It was essential to research the origins of the constant threats that the x86 architecture has to endure. Chapter 2, "Security concerns of today s deployed x86 platforms" discusses some drawbacks of the x86 technology which can be exploited by an attacker that intends to compromise a system. A full outline of the origin of Trusted Computing and trustworthy hardware platforms is given in Chapter 3: "Background to Trustworthy Computing". By means of the Trusted Computing Group specifications it is explained what a Trusted Computing System should look like. Furthermore, the security enhancements of modern CPUs and chipsets are presented and their potential security gains are explained. Additionally, the benefits of hardware-based security is compared to pure software solutions. Chapter 4, "Background to Virtualization Techniques", gives a brief history of virtualization approaches and discusses the motivation for the use of virtualization in order to enhance the security of employed operating systems and applications. It gives an overview of the different types and grades of virtualization and underlines some hypervisor selection criteria for a security 8

18 1. General Overview architecture. Furthermore, the open source hypervisor Xen is described in detail, including hardware assisted virtualization support for modern CPUs. Chapter 5, "Proof of Concept System", is about the requirements and implementation considerations for the system. The individual parts of the prototype are described in detail and different hardware modules, as well as software configurations, are distinguished and explained. Additionally, specific use cases and application fields which are suitable for this specific approach, are pointed out. Once the proof-of-concept system had been fully developed, it was necessary to validate the system. In Chapter 6, "Validation of the Proof of Concept System", there is a description on how the functionality of the individual components is tested using appropriate tools. A summary of the work carried out in this research project is provided in the final chapter of this thesis, Chapter 7: "Results, Conclusions and Further Work". Some ideas for the further development of the proof-of-concept prototype are suggested in this chapter Summary This research project describes the development of a hypervisor-based security architecture utilizing a state-of-the-art hardware Trust Anchor for the embedded x86 sector. An overview on Trustworthy Computing and virtualization techniques is presented, as well as a statement on the shortcomings of the x86 technology regarding system security. This chapter has set out the background for the motivation for the design, building blocks and prototype implementation of the security architecture, which will be described in this thesis. 9

19 2. Security Concerns of Today s Deployed x86 Platforms 2.1. Introduction Before any new concepts for advanced IT security techniques on the embedded x86 architecture can be discussed, there is first a need to develop a basic understanding of the fundamental drawbacks of that architecture in regard to the implementation of system security features. Once a good knowledge of the underlying architectural issues are understood, the set of problems for developing secure applications and operating systems can be more fully appreciated Objective The objective of this chapter is to review the most obvious problems of the x86 architecture regarding best practice when used in security-critical application fields. The topics discussed in this chapter are not restricted only to the embedded sector, rather they are of enormous significance in today s more general pervasive computing environments. The main problems relating to hardware and software deficiencies are outlined. Some focus is also placed on the human factors, as this is always an issue of concern and should never be underestimated. 10

20 2. Security Concerns of Today s Deployed x86 Platforms 2.3. General In recent times the x86 platform has been gaining more and more popularity in many diverse computing environments. This movement can be seen not only in the areas of general computer products but also in the fields of consumer products and in the embedded computing field. The embedded market was formerly dominated by small and cost efficient microcontrollers, or the so called "System On a Chip" (SOC) solutions. However, now, this market segment is becoming more and more dominated by the x86 architecture. There are many reasons for this evolution. The ongoing advantages of the embedded x86 architecture are now well understood. An important benefit that can be singled out is the comprehensive development process that has evolved due to the widespread expert knowledge on the programming of efficient applications in the x86 environment. The feasibility of reusing existing code further speeds up the development time. This all leads to a Reduced Time To Market (TTM) and additional cost savings. A further advantage of the x86 platform is the large pool of peripheral components which are available for this architecture. Another motivation to implement embedded solutions on top of the x86 platform is the high-level of computing power that is available to the x86 processors. Of all the above advantages, perhaps the most important advantage for adopting the x86 platform is being able to use common operating systems such as Microsoft Windows and Linux. In order to meet the growing requirements of increased product complexity and the additional functionality requirements, today s standardized hardware and software components are often used to streamline the development process. The x86 environment is well placed to support such activity. However, the use of standard hardware as well as standard operating systems can often imply some serious security concerns, largely because of the known shortcomings of the deployed components. Such concerns relate to the key subject matter for this thesis. 11

21 2. Security Concerns of Today s Deployed x86 Platforms 2.4. Hardware concerns The security characteristics of a computer system do not only depend on the employed software components but also on the security features provided by hardware. For the creation of an effective security architecture based on the x86 hardware it is very important to be aware of the shortcomings introduced by the hardware itself CPU Protection Rings Modern processors of the x86 family offer four different security levels, which are often illustrated as CPU protection rings [45]. These are Ring 0 up to Ring 3, with Ring 0 being the one having the most privileges, which provides full access to the physical resources of the system. Ring 3 is the least privileged one. The access of a lower privileged ring to the resources of a higher privileged ring is managed by special interfaces which are referred to as gates. Ideally all four rings are used, where the kernel is located in Ring 0, the operating system services reside in Ring 1, the device drivers reside in Ring 2, and the applications reside in Ring 3. Figure 2.1 illustrates the concept of the original design for the CPU protection rings. Figure 2.1.: CPU protection rings - ideal usage [55] For performance reasons and for user comfort reasons, today the x86 architectures make use of two of these four protection rings, only. In this approach the kernel, operating system services 12

22 2. Security Concerns of Today s Deployed x86 Platforms and device drivers all share Ring 0, which is also known as kernel space. The applications are located in Ring 3, which is referred to as user space. In this way a normal user cannot gain critical system access and the remaining rings, Ring 1 and Ring 2, remain unused (see figure 2.2). Figure 2.2.: CPU protection rings - real usage [55] Unfortunately, this approach leads to an increased security risk, due to the fact that the operating system as well as the device drivers hold the same system rights as the kernel, and thus all have full access to the resources of the system. Beyond the formal device drivers, this situation often gives rise to untrustworthy third-party developers being able to produce unreliable critical code, maybe in the form of a malicious device driver, which could be used to compromise the whole system Direct Memory Access Direct Memory Access (DMA) allows specific subsystems within the computer to access the system s memory region for reading and writing purposes, independently of the CPU (see figure 2.3). DMA was developed for performance reasons to allow devices, such as graphics cards and PCI cards, to have fast memory access. The problem regarding security is that the DMA scheme avoids any protections which are managed by the CPU. In fact, a DMA device has access to all memory, making a DMA access similar to an access of Ring 0. If an attacker 13

23 2. Security Concerns of Today s Deployed x86 Platforms could manipulate a DMA capable device to perform a direct memory access to the program s memory, then he/she could attack the system. In a typical DMA attack, most often the memory regions are scanned for characteristic patterns to find valuable information such as encryption keys or passwords [58]. Figure 2.3.: High-level overview of a Direct Memory Access (simplified) System Management Mode The System Management Mode (SMM) and the System Management Interrupt (SMI) are really important features to be considered in the context of security. According to [46] the SMM is the most privileged CPU operation mode on Intel architectures, which allows power-management features and other operating-system-independent functions. The SMM mode can be invoked without notifying or even using the operating system. A special memory region called System Management RAM (SMRAM) contains the SMM code which will be executed when a SMI is initiated. After a SMI has been triggered, the processor saves the current state, which will freeze the operating system, and executes the contents of SMRAM. The SMM code can contain proprietary code from the manufacturer for platform management functions. After the SMM code has been executed, the SMI has completed its operation. A special resume instruction 14

24 2. Security Concerns of Today s Deployed x86 Platforms (RSM) will cause the processor to switch back to the previously saved state. This means that the SMM code has even more privileges than an access of Ring 0. Figure 2.4 illustrates the state transitions into SMM mode. Figure 2.4.: Overview of the processor states [9] The SMM mode can be compared to the real-address mode, in which the page tables are inactive. Thus up to 4 GBytes of memory can be accessed, with the highest privilege operation of the x86 architecture. Over time several possible attacks [59] have been shown such as poisoning the cache of the CPU in order to run arbitrary code with maximum privileges, while remaining invisible to the operating system and applications Software concerns Besides the important hardware concerns, as introduced above, when trying to develop a security architecture the shortcomings of the deployed operating system structures, as well as the actual software applications, must not be underestimated. Such concerns are closely linked to the design flaws of the underlying hardware architecture. Some of the more important issues of concern will be introduced. 15

25 2. Security Concerns of Today s Deployed x86 Platforms Buffer Overflows A huge concern for the security of programs and whole systems are Buffer Overflows. In general, a Buffer Overflow is caused through a malfunction in a program when it writes data into a buffer which is too small to hold that data. This will overrun the buffer s boundary and, if not checked by the program, overwrite subsequent memory regions. A Buffer Overflow can lead to a crash of the program, the corruption of data or even to the damage of data structures of the runtime environment. Buffer Overflows are a common source of many software vulnerabilities and can be maliciously exploited [26]. The techniques to exploit such a vulnerability is dependent of the underlying architecture as well as the operating system structure. A technically skilled attacker might be able to exploit a Buffer Overflow to modify a return address and then execute arbitrary data. Figure 2.5.: Illustration of a Buffer Overflow vulnerability The basic principle of a Buffer Overflow vulnerability is illustrated in 2.5. The program in this example has defined two data items, which are sequenced in memory: a string buffer with a length of 8 bytes and a two-byte integer year. Initially the string contains nothing but zeroes and the variable year contains the number A Buffer Overflow occurs when the program attempts to store the null-terminated string "exceeding" in the buffer. If the length of the string 16

26 2. Security Concerns of Today s Deployed x86 Platforms is not checked, it overwrites the value of year. The value has now been replaced by a number formed from part of the character string. In a big-endian system the value of the variable year would change to Writing an even longer string would overwrite further memory and could cause an error which could terminate the process Large Code Base For the development of secure systems it is very important that the corresponding Trusted Computing Base (TCB) is held as small as possible. The TCB of a system is the set of all hardware, software and firmware components which are critical to its security. If a component of the TCB gets compromised the whole system is no longer trustworthy. Otherwise if a component outside of the TCB gets compromised, then this must not have an impact on the trustworthiness. The correctness of a small TCB can more easily be assured or verified. Today s commonly used operating systems have a large code base. The Linux kernel right now consists of about 14 million lines of code, for instance and Microsoft Windows comprises an estimated 50 million lines of code. A big kernel space is very hard to evaluate for correctness, and this further increases the risk of potential flaws and opens up the opportunity to accommodate a variety of possible injection vectors. Regardless of these security shortcomings, most companies need to continue to use popular operating systems. To improve on this situation, it is necessary to reduce the size of the TCB by implementing additional security elements, both hardware and software based The human factor Besides the challenges induced by hardware and software components an additional potential source of error exists, which is not limited to a specific architecture and which must not be underrated, i.e. the human factor. 17

27 2. Security Concerns of Today s Deployed x86 Platforms When designing and developing a security architecture the developer has to take into account that the user of the system may not have an in-depth knowledge of the functionality of the employed security features. Additionally, the user is often not even aware of the potential threats that the platform might have to suffer. A sophisticated security solution will not bring any benefit if the security parameters are configured incorrectly by the user, possibly through a lack of understanding of the underlying technologies. Even worse the security features might also be completely turned off on a given system. Another concern is the so-called Social Engineering. This is the act of manipulating a person to accomplish specific goals. This may include obtaining security critical information like system passwords, or gaining access to sensitive and confidential data. This way an attacker can circumvent security barriers by exploiting human vulnerabilities Summary Some of the key security concerns of today s deployed x86 platforms have been described, not exhaustively, but in sufficient detail to give an appreciation of the information which will be presented in the upcoming chapters, namely Chapters 3 and 4. Various hardware shortcomings were explained including: the lack of using all four CPU privilege rings, the risk of DMA and SMM attacks, as well as the resulting software concerns. The prevention of buffer overflows can be accomplished by adding code that checks to see that writing of data to a buffer, such as a variable, array, or other allocated memory, never exceeds the length allocated to the buffer. Furthermore, erasing the contents after the use of buffers that contain critical information, such as encryption keys, or passwords, is an important associated memory-management practice. Also, the use of memory pointers should be minimized, and they should be destroyed when they are no longer used. Such techniques should at least reduce the threat of memory-pointer attacks. 18

28 2. Security Concerns of Today s Deployed x86 Platforms Although these risks are well understood and there are approaches to prevent such possible attack vectors, the flaws are still omnipresent in widely deployed operating systems, browsers, and other popular software applications. All of this information is required for the development of an effective security solution, such as the one which was developed by the author during the course of this research project. The next chapter focuses on some important background information on Trustworthy Computing techniques, especially hardware-based security modules which can be used as a Trusted Anchor for a security architecture, to be employed under a trustworthy operating system. 19

29 3. Background to Trustworthy Computing 3.1. Introduction Before any work can be carried out on developing a security architecture for embedded x86 systems, an in-depth knowledge of the background of trustworthy computing needs to be acquired. The specification work which was carried out by the Trusted Computing Group, especially the TCG TPM Main Specification [14] [15] [16], and the Trusted Software Stack Specification [11] provided the author with a good basis for the study Objective The objective of this chapter is to provide a brief background on the trustworthy computing approach. The author has summarized the key information here. A survey of different general approaches to computer security is given followed by the most important cryptographic elements which are essential in building an effective security solution. A discussion of hardwarebased security techniques is compared to pure software approaches. A key element of this chapter is the description of the individual components which are necessary to build a Trusted Computing System. Understanding the functionality of security implants allow one to build the base knowledge for the development of a hardware-based security solution. 20

30 3. Background to Trustworthy Computing 3.3. General The term Trusted Computing (TC), or the so-called trustworthy computing, was first coined in December 1985, in the scope of the standard Trusted Computer System Evaluation Criteria (TCSEC) [17] of the Department of Defense of the United States of America. TCSEC was used to evaluate, classify and select computer systems which were being considered for the processing, storage and retrieval of sensitive or classified information, and this laid the foundation for today s valid international standard on Common Criteria for Information Technology Security Evaluation (CC) [48]. The TC technology pursues a relatively new approach to computer security, according to which a system should permanently be in a well-defined state. In this context trusted means that the system behaves in a manufacturer s predefined fashion. In theory TC systems could be developed and designed according to multiple conventions and principles, however, the standards released by the Trusted Computing Group (TCG) has reached significant importance, and provide a solid basis for design and development, which will be exampled in this thesis. Figure 3.1.: Document Roadmap Diagram of the Trusted Computing Group [12] 21

31 3. Background to Trustworthy Computing The TCG members develop and promote open, vendor-neutral, industry standard specifications for trusted computing building blocks and software interfaces which operate across multiple platforms. The TCG provides specifications for the design, evaluation and conformance testing of trusted computing platforms. Figure 3.1 illustrates the roadmap of the TCG specification work. The base concept of this approach is to introduce an additional hardware component to the platform which serves as the root for an efficient security architecture Approaches to computer security When examining different computer systems and exploring how they attempt to provide system security, the different approaches could be classed basically into three broad categories, which will be described consecutively. Security by Obscurity A very controversial approach to computer security is known as Security by Obscurity, also called Security by Randomization. Proprietary security solutions are still often based on this approach. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers might believe that the flaws are not known, and that attackers will be unlikely to find them. So the system developers try to make the exploitation of such bugs and design errors very hard to achieve. The obvious disadvantage of this approach is that it does not prevent the bugs from being exploited - it only makes the meaningful exploitation much more difficult. As might be imagined such solutions do not work in practice and a well-designed security solution should not be based on the security by obscurity approach [54]. 22

32 3. Background to Trustworthy Computing Security by Correctness Another approach is called Security by Correctness. This approach has the longer-term goal to produce software that does not have bugs or any maliciously behaving code. This could solve many concerns regarding system security. The problem related to this approach is that the required tools to make sure that a given piece of code is correct, in terms of implementation, design and ethical behaviour, do not exist. Over the time, a lot of research effort in the software engineering domain that has attempted to achieve Security by Correctness. So-called "safe languages", code verifiers, developer s education, manual code audits etc. are all approaches which attempt to achieve this goal. However, it is very hard to assure the correctness of software on any higher level of abstraction, above the implementation level. Security by Isolation Because of the problems in effectively implementing the Security by Correctness approach, another approach, based on isolation, exists. The basic idea is to split a computer system into smaller pieces and to make sure that each piece is separated from the other ones, so that if the system gets compromised or malfunctions, then it cannot affect the other entities in the system. In practice the isolation approach has turned out to be very complex to implement. One problem is deciding on how to partition the system into meaningful pieces and how to set permissions for each piece. Furthermore, the commonly used operating systems are largely based on monolithic kernels (with some exceptions), which means that a bug in any of the kernel components might allow one to bypass the isolation mechanisms which are provided by the rest of the system. It is proposed here by the author that state-of-the-art virtualization technology could be employed to solve the stated problems. A thin bare-metal hypervisor can act somewhat like a micro kernel and enforce isolation between other components in the system. Together with hardware-based security modules and other trustworthy building blocks it is suggested by the author that commonly used operating systems can be additionally hardened. 23

33 3. Background to Trustworthy Computing 3.5. Cryptography Cryptography resides at the core of any security system. This is often the first element that comes into mind when planning computer security. The basic goals of cryptography are: Confidentiality, Integrity, Non-repudiation and Authentication. If a system has to process, transfer or store confidential data in a secure manner, it must employ some sort of cryptographic process, such as encryption. Even if cryptography seems to be accepted by some as a panacea for almost all computer security related threats, it has to be understood that the correct usage of cryptographic processes is a quite complicated task. The creation and distribution of keys are critical issues for any secure system and failure to perform this task well can compromise the ultimate security of the system. Furthermore it must also be assured that the usage of cryptography does not violate any data privacy regulations. Below, the various elements of cryptography are briefly itemized. For more detailed information on cryptography please refer to [61]. Symmetric cryptographic algorithms Asymmetric cryptographic algorithms Hybrid cryptographic algorithms Digital signatures Hash algorithms Message Authentication Codes Random Number Generators Certification Authorities Cryptographic protocols effectively combine these basic cryptographic elements and are widely used for secure application-level data transport. A cryptographic protocol usually incorporates aspects, such as key agreement or establishment, entity authentication, symmetric encryption and message authentication methods, as well as non-repudiation methods. 24

34 3. Background to Trustworthy Computing 3.6. Hardware-based security techniques vs. pure software solutions The preceding chapter and sections have introduced two important points, that can be summarized as: Pure software-based security solutions possess many attack points and inherent weaknesses. The hardware concerns of the x86 architecture related to security, as described in Chapter 2, furthermore confirms that software solutions are insufficient. Hardware-based security technologies can dramatically decrease or even eliminate those weaknesses through the introduction of protected capabilities and the use of non-algorithmic processes that are truly random. To the extent that hardware devices can be physically secured against tampering, they can potentially offer significantly stronger overall system security if they are combined with carefully developed software components. Pure software solutions no longer meet the requirements on protection against manipulation and tampering. Such solutions can by their very nature only relate to already-known threats. Software is just an application, and therefore it can be broken [27]. The author in this thesis is emphasizing that more effective security techniques must consist of a combination of special hardware and software components and any security-based application must utilize both hardware and software components and must not rely solely upon software algorithms. Cryptographic processes become increasingly important as an administrator or user takes steps to make a system more secure. Security weaknesses in the host system s operating system can provide attack avenues into the CPU s memory that might allow an attacker to obtain critical key information. This issue can be successfully addressed by using hardware-based security modules as an integral part of the platform to run any security-related processes, to store keys in a secure fashion, and to maintain authentication information about software and hardware components. A desirable feature for a security architecture is to be able to verify the integrity of the platform components. However, a platform with a verifying software module as part of the same 25

35 3. Background to Trustworthy Computing system forms a potential problem which should not be underestimated. If the system gets compromised one can not guarantee that the verifying software component itself was not also compromised. An additional hardware component with its own specially secured resources permits the attestation of the system s integrity. An example implementation of this concept is included in this research work Trusted Computing System The overall goal of the Trusted Computing (TC) approach of the Trusted Computing Group (TCG) is the realisation of a so-called Trusted Computing System (TCS). A TCS basically consists of a Trusted Computing Platform (TCP) and a Trusted Operating System (TOS) with trustworthy services and applications. Figure 3.2 illustrates the schematic design of a TCS. Figure 3.2.: Schematic design of a Trusted Computing System [55] Trusted Computing Platform The Trusted Computing Platform (TCP) as defined by the Trusted Computing Group (TCG) consists of the Trusted Platform Module (TPM) and the Core Root of Trust for Measurement (CRTM) Code. The TCP should be able to record the state of the integrity of software and hardware components during the actual boot process of a platform. 26

36 3. Background to Trustworthy Computing Trusted Platform Module The Trusted Platform Module (TPM) is a cryptographic hardware chip which is tied to the platform of a computer system and whose basic structure and functionality has been specified by the Trusted Computing Group. A detailed description about the individual components of the chip, as well as an account on the functionality of this hardware-based security implant can be found in Appendix E. The TPM offers basic cryptographic engines in hardware and therefore the functionality of the TPM module often is compared to the operating mode of a high-end smartcard. However, there are some major differences between these two hardware-based security modules. First of all a smartcard is used to authenticate a specific user, whereas the Trusted Platform Module is tied to a client platform and therefore can be used to authenticate a specific computing platform. Furthermore the TPM offers special protected capabilities, such as a secured memory region and the possibility for a secure generation of cryptographic keys inside of the chip. Special Roots of Trust are used for the creation of a key hierarchy, ensuring that each newly created key is bound to the TPM first, before it leaves the chip in an encrypted form. The most interesting feature of the TPM is the Platform Configuration Register (PCR). A special memory region inside of the TPM stores the hash values of special data blocks during the boot process. These values represent the actual state of the system and can be used for attestation purposes and for the sealing of data not only to the platform, but also to a specific configuration state of that platform. Additionally these values can be used as a guarantee for a secure bootstrap of the system since they are creating a Chain of Trust over the components involved in the boot process Core Root of Trust for Measurement Besides the TPM a TCP requires another component, which is named the Core Root of Trust for Measurement (CRTM), generally implemented as a BIOS extension, hence it is within the firmware part of the system. The CRTM contains the first instructions executed when powering 27

37 3. Background to Trustworthy Computing up the system and generates check sums over the components involved in the boot process. With the creation of these check sums the TCP initiates a Chain of Trust starting at the BIOS Power On Self Test (POST) and ending at the Master Boot Record (MBR). This is also called the Static Chain of Trust, and assures that each and any executed component in this operating stage can be clearly identified. The CRTM Code comprises an implementation of the Root of Trust for Measurement (RTM). Refer to Appendix E for more information about the Roots of Trust Trusted Operating System A trusted platform is an essential part of a trustworthy computing system. Another important component is a Trusted Operating System (TOS). Compared to the TCP, which has been clearly specified by the TCG, there are no clear definitions or specifications for the creation of a TOS. In general a TOS can be figured as a combination of a trustworthy kernel, services and applications. A TOS should meet a list of demands stated below: Integrity Measurement and Protection The Static Chain of Trust for Measurement ends at the Master Boot Record. The first task of a TOS needs to continue in this chain during a boot process of the operating system by adding integrity measurement routines to the boot manager and operating system loader. In order to be able to represent the actual state of the system, and not the state the system had during boot process, the integrity measurements should be sustained even during the runtime of the operating system. However, commonly used operating systems are far too complex which makes complete integrity measurements of all security critical data quite infeasible. The Chain of Trust could be extended to a Tree of Trust. (Remote) Integrity Validation A TOS must furthermore offer the possibility to evaluate the current state of the platform in order to verify the trustworthiness. If the integrity validation takes place on the same system it is mandatory that the verifying component is also part of the trust chain. 28

38 3. Background to Trustworthy Computing However, if the system has been compromised the verifying component could also have been compromised. As a result the integrity validation should be performed by a remote system. Trusted Software Stack In order to communicate with the TPM and to provide an interface to the TPM for trusted computing aware applications, a TOS must provide a Trusted Software Stack (TSS). The basic structure of the TSS has been specified by the TCG. It consists of multiple abstraction layers, as illustrated in figure 3.3. Nowadays, implementation of a Trusted Software Stack exists for different operating systems. For more detailed information on the TSS please refer to [11]. Figure 3.3.: Trusted Software Stack [12] Protected Execution An important requirement for a trustworthy operating system is the ability to execute arbitrary software applications in a protected execution environment. It must be guaran- 29

39 3. Background to Trustworthy Computing teed that the storage region of an application is shielded from access and modification by another application. Especially the Trusted Computing Base (TCB) of the system and additional security critical components must be secured from untrustworthy processes. However, the structure of commonly used operating systems offers some challenges for the implementation of the Protected Execution goal. As already stated, these operating systems are largely based on monolithic kernel structures and all active processes in the kernel can share the same memory region. This forms a drawback, regarding security because it provides the possibility to manipulate security critical data structures of the operating system kernel. For the realization of the Protected Execution goal different approaches exist. The most feasible approach, in the author s opinion, is to use virtualization techniques in combination with special processor security enhancements. All approaches are based on the same basic idea, i.e. to partition the system into small parts with variable security requirements. Trusted GUI, Input and Output The goal of a Trusted GUI is the creation of a trusted channel between the user/administrator and the operating system. The rational behind this goal is that the user/administrator normally cannot distinguish between GUI elements of the operating system and potentially maliciously-behaving applications. Regarding Trusted Computing this implies a significant security risk. If the user cannot trust the displayed information then it is not possible to inform the user about the current state of the system. In the case of system compromise the reporting component could also be compromised. Beyond the difficulty of a trustworthy output of information, the problem of secure data input and output also has to be addressed. Again the implementation of Trusted Channels and Trusted Paths between the peripheral devices and the application could solve this problem. However, this implies both software and hardware changes. 30

40 3. Background to Trustworthy Computing 3.8. CPU and Chipset security enhancements The TCP as defined by the TCG is subject to some restrictions relating to the defined goals of Trusted Computing. In the design and development of a trustworthy operating system, especially in trying to the achieve Protected Execution, many large design hurdles need to be overcome. For this reason the CPU and chipset manufacturers are working on a range of new security features for the recent and future product generations. Some of the work in this area is summarized below to the extend where the concepts are employed in the research work by the author Intel Virtualization Technology for directed I/O The Intel Virtualization Technology for directed I/O (Intel VT-d) offers hardware security extensions supporting I/O virtualization [41]. Like the Memory Management Unit (MMU), which handles access to memory requested by the CPU by translating virtual addresses to physical addresses, Intel VT-d features an Input/Output Memory Management Unit (IOMMU), which handles access to memory requested by I/O devices by translating device addresses to physical addresses. Therefore Intel VT-d can mitigate the risk of DMA attacks, by introducing a hardware capability called DMA-remapping, which translates the addresses of DMA requests only to pre-assigned physical memory regions. Thus a DMA capable device can only get access to a well-defined memory region, which provides the necessary isolation between computer resources in a virtualized environment. Intel VT-d furthermore permits the assignment of PCI devices directly to a guest VM, which allows sandboxing of a security-critical device driver in a small special-purpose VM whose integrity can more easily be assured. 31

41 3. Background to Trustworthy Computing Intel Trusted execution Technology The Intel Trusted execution Technology (Intel TXT) describes a set of hardware extensions to the processor and chipset, which can address many goals of Trusted Computing [39]. Intel TXT builds up on the basic concept of a Dynamic Root of Trust for Measurement (DRTM), which can preserve the integrity of operating system structures or virtualized environments [29]. These extensions are working hand in hand with the virtualization enhancements and offer a possible approach for the protected execution of software structures, such as Virtual Machine Monitor (VMM), operating system kernel and applications. This approach is also referred to as Measured Launched Environment (MLE) [40]. Special processor extensions, called Safer Mode extentions (SMX), permit the measured launch of software, using the chipset leverage of the Intel VT-d to provide memory protections. The CPU enhancements make excessive use of the Trusted Platform Module and contain hardware to authenticate so-called Authenticated Code Modules (ACM) and to perform integrity measurements. ACM modules are platformspecific binaries, digitally signed by Intel, which are loaded and executed into an exclusive CPU RAM called Authenticated Code RAM (ACRAM). There are two types of ACM modules. The BIOS ACM is integrated into the BIOS and performs secure platform initialization. The Secure Initialization (SINIT) ACM enforces special user-defined policies and performs DRTM measurements, ensuring that only configurations known as trustworthy can be launched [32] Summary This chapter provided an introduction to some general approaches to computer security and presented the basic elements of most security solutions, including cryptography. After pointing out the importance of hardware-based security modules the components necessary to build a Trusted Computing System have been described in overview fashion. Special attention in given to the need for a trustworthy operating system and how additional CPU and chipset security enhancements can add enhanced trust to a system. The security approaches which have been 32

42 3. Background to Trustworthy Computing summarized here will be built upon towards the development of the proof-of-concept trusted architecture by the author. 33

43 4. Virtualization Technologies 4.1. Introduction The general basis for the development of a hypervisor-based security architecture for embedded x86 platforms is, of course, to have a working knowledge of the Trusted Computing approach as well as the components necessary for the creation of a Trusted Computing Platform. But it is also necessary to know how to make commonly-used operating systems more secure by employing some tactical features. In this thesis virtualization technology is proposed as part of an integrated enhanced security architecture. Adding a virtualization layer on its own does not bring any additional security benefits. It is also necessary to intelligently select the appropriate hypervisor and to make use of hardware assisted virtualization enhancements, as provided by some recent processors and chipsets Objective The objective of this chapter is to provide a brief background on the history of virtualization and to explain the motivation for proposing virtualization as a layer for the development of a security architecture. The main issues concerning the selection of an appropriate hypervisor are outlined. The main part of this chapter will be concerned with a description of the open source hypervisor Xen, which is the chosen virtualization layer for the proposed security architecture in this thesis. In a final step a discussion of further hypervisors, which could also be used for future enhanced security architectures is presented. 34

44 4. Virtualization Technologies 4.3. History and motivation Virtualization is not a new concept; it has been used for decades. An example of virtualization is virtual memory, which can enable a computer system to appear to have more memory available than is physically installed on the system. Nowadays virtualization is more popular than ever and various types and categories of virtualization exit. Today s virtualization technologies can have the potential to fundamentally change the way computer resources are consumed. Since the power and performance of the commodity x86 hardware is continuing to increase, virtualization techniques are often used for the consolidation of multiple physical hardware platforms into one virtualized environment, with multiple virtual machines, in order to save costs and to reduce energy consumption. In recent times, virtualization technology is gaining more and more interest for use in security architectures [47]. Hypervisors can provide security, based on their strong isolation ability. A hypervisor will address isolation on a more rudimentary level, as compared to a conventional operating system. Rather than isolate different processes the hypervisor isolates whole operating systems. It is the responsibility of each virtualized operating system to employ further security mechanisms at the application level. The hypervisor will handle the access to the privileged part of the hardware and will provide each guest with the illusion that it is running directly on its own dedicated hardware platform. In theory, if a malicious software program or a malicious user manages to compromise a virtual system, even then this system will still be unable to get access to resources which are assigned to different guest operating systems or to the host operating system. Furthermore, a compromised guest operating system can be reset to a trustworthy state more easily than a conventional system, thus reducing downtime. In general, the interface between a Virtual Machine (VM) and the hypervisor can be much simpler than in the case of a traditional operating system. The hypervisor itself can also be much simpler, as it does not need to provide various services, such as services for networking and file system handling. The virtualization support of modern computers (e.g. Intel VT-x and Intel VT-d) allows further simplification of the hypervisor code base. They can also enable the creation of so-called driver domains, which are special purpose virtual appliances for hosting 35

45 4. Virtualization Technologies device driver code, such as networking code. The integrity of these special isolated containers can be leveraged through hardware assistance, which can further assure the overall integrity Hypervisor selection criteria For the employment of virtualization technology, for the purpose of adding security through isolation to a system, the virtualization layer has to be carefully chosen. The only feasible type of virtualization for the creation of a hypervisor-based security architecture is a baremetal hypervisor, as this type runs directly on the underlying hardware, controls the hardware resources, and can assign these resources to the individual virtual machines. It has to be understood that in such a virtualized environment, the hypervisor becomes the sole most privileged software component of the system. So the hypervisor software becomes a complete part of the Trusted Computing Base of a system. Compared to the security flaws contained in modern operating systems, virtualization techniques are much more secure as they do not suffer from inherent insecurities. However, merely picking a bare-metal hypervisor, which will serve as an additional abstraction layer, is not sufficient for the creation of an effective security architecture. According to [64] an integrity-protected-hypervisor on the x86 platform has to meet several requirements. These demands are even further necessary due to the shortcomings of the x86 hardware structure regarding system security. All in all 12 integrity rules for an integrity-protected-hypervisor are described in [64]. The tiny-held bare-metal and open source hypervisor, Xen, was chosen for the proposed security architecture which is described in this thesis, as Xen meets most of the demands. Even though the hypervisor Xen has a very small code base, it has not yet been formally verified to be free of vulnerabilities. A flaw in the hypervisor software could possibly be exploited for a successful attack on a virtual machine, in order to get access to further system resources. To mitigate this potential weak point, the integrity of the hypervisor should be permanently monitored for assurance. The previously described Trusted Computing technology can have 36

46 4. Virtualization Technologies the potential to further improve the security of the hypervisor. By hardware-based security modules, special mechanisms can be used to ensure the correct launch and integrity maintenance of a Virtual Machine Monitor (VMM), as well as to help in the definition of more robust system policies The Open Source Hypervisor: Xen The open source hypervisor Xen originates from the computer laboratory of the University of Cambridge, where it was conceived in the year 2001, and the concept was first published in the year 2003, in an article called "Xen and the Art of Virtualization" [18]. Today, Xen is used in many commercial products as well as in research environments. Figure 4.1 shows the logo for the Xen hypervisor. Figure 4.1.: The logo for the Xen hypervisor [8] Xen is a hypervisor, which can be employed for various architectures, including IA-32, x84-64, Itanium and ARM architectures. Nowadays the Xen community develops and maintains the Virtual Machine Monitor (VMM) as free software, licensed under GPLv2. In Xen systems the Xen hypervisor always forms the lowest layer, and therefore most privileged software layer, on top of the system hardware, which will schedule the individual guest operating systems across the physical CPUs. Currently the Xen developers and community members are trying to get the full Xen support to be included into the Linux mainline kernel. In early 2011 the most significant parts of Xen 37

47 4. Virtualization Technologies have been accepted to be included into the mainline Linux kernel version The next versions of the Linux kernel might offer full Xen support, which would realize the deployment of Xen virtualized environments. As a design principle, the code base of the VMM Xen is relatively small. Xen consists of just tens of thousands lines of code, which is orders of magnitudes less than the size of an operating system kernel. In general, less code size can often also mean fewer bugs, and thus fewer potential security flaws which could potentially be exploited to attack a system. A Xen virtual environment basically consists of the Xen hypervisor itself, a privileged host operating system, Domain-0, as well as one or more paravirtualized guest domains and/or hardware-virtualized guest domains Domain-0: Host operating system The host operating system in a Xen environment is termed Domain-0, or Dom-0 for short. Domain-0 is a specially modified Linux kernel, which forms a unique virtual machine running on the Xen hypervisor, which receives special management privileges and has special rights to access physical I/O resources as well as rights to interact with the other guest domains. Any Unix-like operating system may be used as Domain-0, which will be booted automatically when the hypervisor boots. The integrity of Domain-0 is very critical for the security level of the system as Domain-0 can control and manage all further guest domains. Therefore it should be held as small as possible and should only be used for the management of the guest operating systems. The Domain-0 does not even need a Graphical User Interface and can be accessed securely by the system administrator through SSH or a similar protocol Domain-U: Guest operating systems The counterpart of the Domain-0, in Xen terminology, is called Domain-U, or Dom-U. It describes an unprivileged domain, which by default, has no access to the hardware. Such a 38

48 4. Virtualization Technologies guest operating system is started by the Xen daemon xend in Domain-0, which the user can access with the Xen management command line tool called xm [63]. Two different types of guest Domains can be created with Xen, paravirtualized guest operating systems, and Hardware Virtual Machines (HVM), which utilize special hardware-based virtualization extensions Paravirtualized guest operating systems Paravirtualization requires the guest operating system to be explicitly modified to be virtualization aware. According to the CPU protection Ring model, as illustrated in figure 4.2, the hypervisor is located in the most privileged CPU ring, Ring 0, and thus the operating system has to move to another ring. For the x86 architecture the operating system will be moved to Ring 1. Since the operating system kernel sources have not been designed and developed to run in another protection ring, rather than Ring 0. The Xen hypervisor exposes a set of so-called Hypercalls which can be used by both Domain-0 and guest domains to directly interact with the hypervisor. Any Unix-like operating system could be modified in order to be used as a paravirtualized guest operating system in a vitualized Xen environment. Figure 4.2.: Xen-Hypercalls [24] 39

49 4. Virtualization Technologies Hardware assisted vitualization: HVM guests Paravirtualized guest operating systems have to be specially modified, in order to be more virtualization friendly. However, these modifications are not possible or feasible for all types of operating systems. For instance, the kernel sources of Microsoft Windows operating systems are closed and thus cannot be easily modified. The regular operating system has to remain in Ring 0. However, the hypervisor must be the most privileged software component in a virtualized environment, in order to be the only instance which is privileged to access the underlying hardware resources. Since the release of version 3.0 of the Xen hypervisor, it features the capability to also run unmodified operating systems as unprivileged guest domains. A basic requirement for the virtualization of a closed-source operating system is hardware virtualization assistance of the host machine s processor. Intel has added special virtualization enhancements to the CPU and called the underlying technology the Intel Virtualization Technology (Intel VT-x) [52]. Intel VT-x adds a new set of commands to the processor, called Virtual Machine extension (VMX). Conceptually the virtualization enhancements of Intel VT-x can be thought of as an additional CPU protection Ring -1, intended for the hypervisor to be the most privileged one (see figure 4.3). Figure 4.3.: CPU protection rings - additional Ring -1 [55] 40

50 4. Virtualization Technologies A hypervisor can run in VMX mode and can be completely invisible to the operating system, which is running in Ring 0. However, if an unmodified operating system does not know that it is running in a virtualized environment, it cannot easily take advantage of any features provided by the hypervisor. This leads to a loss of performance and flexibility. Hardwareassisted virtualization, in Xen terminology, is often referred to as a Hardware Virtual Machine (HVM) Further Hypervisors One of the author s goals for the development of the proposed security architecture was the use of open source components. After analyzing the state-of-the-art technologies of virtualization techniques and their usability for the proposed approach towards enhanced security, the open source hypervisor Xen was chosen as candidate. The Kernel-based Virtual Machine (KVM) [2] is an open source virtualization solution, which could also be utilized for the creation of a hypervisor-based security architecture. KVM has already been accepted to be distributed as part of the mainline Linux kernel. In a KVM architecture each VM is another type of Linux usermode process, with the sole difference that such a so-called VM process has no access to the Linux system call interface. Instead, it can only interact with the kernel via the virtualization instructions of hardware virtualization enhancements. In that case the kernel becomes the hypervisor for the VM processes. KVM therefore only supports hardware-assisted virtualization and requires special hardware components, whereas Xen also supports paravirtualization. In addition KVM does not support dedicated driver domains. Because of these reasons, in the author s opinion, the tiny-held bare-metal hypervisor Xen can realize a smaller Trusted Computing Base (TCB) and thus was chosen for the development of the proposed proof-of-concept system. Some application fields have stringent requirements regarding real-time capabilities. The employment of virtualization techniques in such application fields can be a very complicated task. 41

51 4. Virtualization Technologies The use of a hypervisor for a security architecture can potentially hinder the successful implementation of such an approach. The Wind River Hypervisor [7] is an embedded hypervisor that could guarantee real-time capabilities and deterministic behaviour using resource partitioning. However, as already stated a key goal of the research work was to create an open platform, which is why Xen was chosen as the candidate for the proposed security architecture Summary The potential abilities and advantages of virtualization have been described, not exhaustively, but in sufficient detail to understand why virtualization, today, can really add security through isolating security-critical parts from potentially untrustworthy parts. In particular the open source virtualization solution Xen, which has been chosen for the proposed approach in this thesis, has been described in a little detail. In addition, the Intel Virtualization Technology for virtualization assistance of the CPU on x86 platforms (Intel VT-x) has been introduced, which allows the virtualization of operating systems whose kernel sources are closed and cannot be modified in order to be paravirtualized. Also further hypervisors have been briefly introduced which could be used for the creation of a hypervisor-based security architecture. 42

52 5. The Proof of Concept System 5.1. Introduction When this project was initially proposed it was seen as a key goal to realize a security enhanced platform which could offer effective protection against sophisticated software-based attacks, and also offer a way to monitor the integrity of the platform in order to ensure that the platform could be constantly maintained in a well-defined state; and thus give confidence that it would be in a trustworthy state. The aim was to show that this easy to use proof-of-concept system would be based on trustworthy building blocks, which allow developers to port particular partial solutions to other use cases in order to be able to build customized customer specific, well-defined security solutions. Through the course of this chapter a complete account of the work carried out in producing the proof-of-concept system will be developed Objective The main objective outlined at the inception of this project was to develop enhanced security architecture, built on a hypervisor-based security architecture that would utilize a state-of-theart hardware Trust Anchor. A key feature was that the solution should be user friendly, based on a building block approach, and would offer developers a way to easily adopt security features to build their own customized trusted platforms. As stated previously, the proposed solution is based on a Trusted Computing Platform as specified by the Trusted Computing Group. A virtualization layer is used to add security by 43

53 5. The Proof of Concept System partitioning the system into smaller parts, whose integrity can be easily guaranteed and verified. Special processor and chipset extensions work to serve as an additional Trust Anchor, adding supplementary security features, and supporting the protected execution of operating systems and/or virtualization software General The industrial partner Kontron is one of the leading manufacturers of embedded x86 solutions. Kontron, amongst others, develops the so-called Computer On Module (COM), which are small modules consisting of the complete x86 system, with a processor and chipset. Standardized connectors are used to connect the module to a corresponding backplane, which is developed by the customer of the Original Equipment Manufacturer (OEM). Depending on the actual use case, an appropriate COM module can be chosen which meets all of the customer requirements. This concept ensures many benefits, such as decreased development costs, and it also offers the ability to upgrade a system if needed. In recent times the customers of Kontron have been increasingly requesting a platform, which has built-in security features. In these times of constant security threats, the customers of COM boards are starting to question the security features which are currently provided by pure software-based solutions, and also the protection abilities of commonly used operating systems. Today, the manufacturers are becoming more conscious of potential loss of revenue, and the possible damage to reputation, in the case of a successful illicit compromising of system. It is well understood that the development of efficient security architectures for the x86 architecture is quite a complicated task. The hardware structure of the x86 architecture has some weak points which can be exploited by a successful attack on a system. Furthermore, software threats, such as Buffer Overflow vulnerabilities in applications, and the ubiquitous use of commonly operating systems, additionally increase the risk of possible system compromise. Regardless of these various shortcomings, many manufacturers need to continue to use these popular operating systems. Taking all of these issues into consideration, new ways must be found to make these operating systems, and the associated applications, more trustworthy. 44

54 5. The Proof of Concept System In the near future, pure software-based security solutions will no longer meet the demands for the required enhanced security standards. A piece of software is simply a running application, and thus it can be somewhat compromised, or even broken, by malicious malware or malicious users. In order to address the shortcomings of today s employed x86 platforms, it is being strongly proposed by the author that more specific hardware-based security schemes are required. A common approach to hardware-based security is to anchor a piece of hardware with special protection capabilities to the platform, which should serve as a Root of Trust for the whole security architecture. In this way it is possible for the user/owner of the platform to have explicit confidence in the correct functionality of the hardware security module. For the proposed security architecture in this thesis the Trusted Platform Module was chosen as candidate for a state-of-the-art hardware Trust Anchor. The Trusted Platform Module has the potential to increase the security of a system by providing a set of basic cryptographic functions, and offers the possibility to realize the secure generation of cryptographic keys inside of the TPM. Furthermore, the TPM provides methods to seal data, not only to a specific system but also to the state which the system had during the actual encryption process, and includes the ability to create a secure boot process. However, the arising problem is that the commonly used operating systems are far too complex and thus are vulnerable to software-based attacks. For the creation of a trustworthy computing system, both a trusted hardware platform and a trusted operating system are necessary. It is being proposed here that the state-of-the-art virtualization techniques, especially a thin bare-metal hypervisor, can be used to address some shortcomings of the x86 hardware structure, and can mitigate the security concerns introduced by the large code base in the kernel space of popular operating systems. The tiny held virtualization layer runs directly on the hardware and therefore can control the access of the individual virtual appliances to the hardware resources. The hypervisor runs in a higher privileged ring than that of the rest of the system, and can allocate defined resources to the individual virtual machines. The author s proposed security architecture effectively combines the isolation ability gained by virtualization techniques with a trustworthy computing platform, which is equipped with 45

55 5. The Proof of Concept System a Trusted Platform Module. Figure 5.1 shows a high-level overview of the proof-of-concept system, which is being proposed here. Figure 5.1.: Architecture of the experimental proof-of-concept system The embedded x86 hardware components, consisting of a combination of a Backplane and a COM Module, have been equipped with a Trusted Platform Module, realized as a hardwarebased security implant. Depending on the demands of the customer, the TPM can either be attached to the COM Module, directly integrated in the chipset of the COM module, or it can be applied to the Backplane. On top of the hardware is the thin bare metal system and the open source hypervisor, Xen is used to securely isolate different applications or whole operating systems. The use of virtualization technologies implies further benefits. With virtualization, legacy applications can be run on modern hardware platforms. However, even if Xen meets most of the requirements of an integrity protected hypervisor, as stated in [64], it cannot be guaranteed that the tiny-held virtualization layer is free of vulnerabilities. Furthermore, Xen still cannot compartmentalize the SMM code and thus it could be vulnerable to a SMM attack [58], like many popular hypervisors. In this type of attack the contents of the SMRAM are maliciously altered in order to execute arbitrary data with maximum privileges. Xen requires a special host management VM, called Domain-0, which is part of the Trusted Computing Base and it must be specially secured. 46

56 5. The Proof of Concept System To mitigate these shortcomings the proposed proof-of-concept system utilizes further trustworthy building blocks, namely the processor and chipset security enhancements from Intel. The corresponding hardware components of the proof-of-concept system features the Intel Trusted execution Technology (Intel TXT) and the Intel Virtualization Technology for Directed I/O (Intel VT-d). Furthermore, the platform utilizes Intel s extensions for virtualization of the CPU in x86 architectures (Intel VT-x), so as to be able to run unmodified operating systems in a virtualized environment. A modified BIOS version, especially adjusted for the proposed security architecture, has been provided by Kontron. Figure 5.2 illustrates the hardware structure of the proof-of-concept system with the utilized hardware-based trusted building blocks. Figure 5.2.: Hardware structure of the proof-of-concept system The combination of the Trusted Platform Module, a hardware-based security implant, serving as Trust Anchor, together with recent processor and chipset security extensions from Intel, along with the appropriate software components, in the author s opinion, provide a good foundation for the development of an effective security architecture based on the x86 architecture. 47

57 5. The Proof of Concept System 5.4. Implementation considerations The appropriate combination of the Trusted Computing technology, together with the security enhancements of modern processors and chipsets with virtualization techniques, can increase the security level of commonly used operating systems, and therefore the security of whole computing platforms. One goal of this research project is the evaluation of trustworthy building blocks for the creation of a secure open platform with a good level of portability. Thus, the proposed building blocks can be applied in various application fields for many different use cases. Thus, the proof-of-concept system described in this chapter can only be an illustrative example for an efficient security solution, demonstrating that the isolation ability of virtualization techniques is a promising approach for the creation of a Trusted Operating System. Interested manufacturers can pick up this concept and use the proposed proof-of-concept platform as an introduction to Trusted Computing techniques. The individual choices of employment of the particular components for more specific platforms will depend on the respective application fields and use cases. The design of such a platform can be a very complicated task. The integrity of each security-critical component has to be specially protected due to the fact that a security architecture can only be as strong as its weakest link. An attacker need only find one weak spot to eventually compromise the system. For the design of a security enhanced platform it is very important for the designer to have a good understanding of the possible attack types that will probably arise for the particular platform, as well as the different types of attackers, as this knowledge will have a benefit on securing the system against attack. The richness of possible attack vectors furthermore hampers the challenge to address them completely. Only the full comprehension of the underlying architecture can qualify the system designer to develop sophisticated security architectures. The security level of multiple systems should never be based on the same secret. For instance, if many different platforms employ the same key for the protection of sensitive confidential data, an attacker only needs to break one system in order to compromise all others. This is called a Break Once Run Everywhere (BORE) attack. The use of a Trusted Platform Module as an Anchor of a security architecture provides effective protection against a BORE attack, 48

58 5. The Proof of Concept System because each TPM is equipped with a unique Endorsement Key and Storage Root Key on top of the TPM key hierarchy. Furthermore, a designer of a trustworthy computing platform has to be aware of the financial value of the data which should be protected. As a general rule the costs spent for additional security features must not exceed the value of the confidential data that must be kept secret Hardware components The author s proposed security architecture was developed on top of a test bench where experimental solutions could be assessed and evaluated for their suitability for enhanced security. The industrial partner Kontron therefore provided the necessary hardware components. During the project work the proof-of-concept system was developed with different Computer On Modules (COM) for the evaluation of the trustworthy building blocks on legacy and state-of-the-art hardware components Carrier Board The Kontron COM Express Evaluation Carrier Board (see figure 5.3) was used as backplane for the test bench. Figure 5.3.: ETXexpress evaluation Backplane [51] 49

59 5. The Proof of Concept System This carrier board is specially designed to allow developers to evaluate the functionality of modular COM modules. Furthermore these backplanes have two seven-segment displays for the indication of the BIOS POST code. For the proposed proof-of-concept system the BIOS version of the different types of COM modules had to be adjusted; and the BIOS POST codes were very helpful in debugging some arising problems. The evaluation board is equipped with a LPC card socket which enabled the evaluation of different locations of the Trusted Platform Module during the research project. Depending on the requirements the TPM can be attached to the COM module or to the backplane. The Kontron COM Express Evaluation Carrier Board has the following features: Hard Disk: 4 x SerialATA Ethernet: 1 x 10/100/1000 MBit Ethernet connector Video: 1 x VGA USB: 6 x USB 2.0 port PCI: 3 x PCI slot LPC: 1 x LPC slot Special feature: BIOS POST code indication for debugging purposes COM Modules For the investigation and development of the proposed hardware-based security architecture two different types of COM modules were provided by Kontron during the research project, one type is called ETXexpress-PC, produced before 2009, and a more recent type is named ETXexpress-SC, which was produced in These two types allowed the evaluation of the individually employed trustworthy building blocks on different hardware platforms, which helped in getting an in-depth knowledge of the utilized components. Furthermore, these two types differ in the implementation of the hardware-based Trust Anchor and in the way in which the security features have to be correctly configured. 50

60 5. The Proof of Concept System ETXexpress-PC The development work of the research described in this thesis started with the ETXexpressPC COM module from Kontron (see figure 5.4), for the development of a security enhanced platform. The EXTexpress-PC module is equipped with the fifth-generation of the Centrino platform, codenamed Montevina, produced in 2008, which unifies the second generation of the Intel Core 2 Duo processors, codenamed Penryn with the Intel Mobile Express series 4 chipset, codenamed Cantiga. It features a so-called itpm module from Intel, which is directly integrated in the chipset. Figure 5.4.: ETXexpress-PC COM Module [49] The Kontron ETXexpress-PC module has the following features: CPU: Intel Core 2 Duo up to 2.26 GHz Chipset: Intel GS45 with Intel ICH9M RAM: Up to 8GB DDR3 (667/800/1066 MHz) dual channel SO-DIMM memory Security features: Integrated TPM1.2 from Intel / Intel VT-d / Intel TXT Dimensions (H x W): 125mm x 95 mm 51

61 5. The Proof of Concept System ETXexpress-SC Towards the end of the project Kontron provided the ETXexpress-SC COM module (see figure 5.5) for the evaluation of the proof-of-concept system on a state-of-the-art hardware platform as well as for further developments. The ETXexpress-SC module is equipped with the seventhgeneration of the Centrino platform, codenamed Huron River, produced in 2011, which unifies the Intel Core i-series with the Intel Mobile Express series 6 chipset, codenamed Cougar Point. It features a discrete TPM module from Infineon, which is soldered to the module. Figure 5.5.: ETXexpress-SC COM Module [50] The Kontron ETXexpress-SC module has the following features: CPU: Intel Core i5 / Intel Core i7 Chipset: Intel Mobile QM76 RAM: Up to 16GB DDR3 (800/1066/1333 MHz) dual channel SO-DIMM memory Security features: Discrete TPM1.2 from Infineon / Intel VT-d / Intel TXT Dimensions (H x W): 125mm x 95 mm 52

62 5. The Proof of Concept System TPM Modules One objective of the research work, as stated previously, is the use of a hardware-based security module. Therefore, the currently available and emerging hardware Trust Anchors were assessed and evaluated for their suitability for the creation of an effective security-enhanced architecture. The concepts resulting from this research work should facilitate manufacturers to pick up the main concepts and to develop their own trustworthy platforms with a high level of dependability. The Trusted Computing approach forms a promising approach towards more trustworthy computing. As a result the Trusted Platform Module was chosen as the security implant for the proposed proof-of-concept system in this research work. During the research project different types of TPM were employed and evaluated Discrete TPM The TPM Main Specification [14] does not prescribe that the Trusted Platform Module must be a hardware component. However, the most common type of Trusted Platform Module, offering the highest level of security, is the discrete TPM. The hardware module is soldered to the platform and connected via the LPC bus (i.e. the Low Pin Count bus). Figure 5.6 shows a typical hardware implementation of a TPM from Infineon. The ETXexpress-SC module is equipped with this type of TPM. Figure 5.6.: Trusted Platform Module from Infineon [36] 53

63 5. The Proof of Concept System The LPC bus is not a very common bus in embedded environments. A new version of TPM is planned for embedded systems, which can be connected via SPI or I 2 C bus Integrated itpm Another type of Trusted Platform Module has been developed by Intel, which is often referred to as the Intel integrated TPM (itpm). The ETXexpress-PC module is equipped with this type of TPM. The Intel integrated TPM is not purely based on hardware components. More precisely the itpm is a mixture of firmware and hardware components which is split into parts. One part of the functionality is contained in the CPU and another part is located in the chipset (see figure 5.7). One possible weak point of the Intel integrated TPM is that it uses an area of the system flash memory as non-volatile memory. This region stores important keys, certificates and policies, as described in more detail in Appendix E. A real problem arises if the COM module is detached from the backplane, or if the owner s CMOS battery runs flat, or if the battery is completely removed. As a consequence, the contents of the flash memory will be vanished and all encrypted data will be lost. Figure 5.7.: Components of an integrated itpm from Intel (simplified) However, currently there are efforts to integrate the hardware structure of the TPM directly in the silicon die of the chipset. This would furthermore increase the trust level of a platform 54

64 5. The Proof of Concept System because the data will be encrypted directly in the chipset. The ideal solution is where no data will be stored on the platform in an unencrypted form Virtual vtpm In conjunction with virtualization an additional type of TPM exists: the virtual TPM (vtpm), initially developed by IBM [19]. The scope of this research is to add security to virtualizable platforms. The TPM is usually not intended to be utilized in virtualized environments. IBM has extended the command set of the TPM specification with 9 additional virtualization commands [30]. The vtpms were initially implemented for the Xen hypervisor. The main concept arising from the work in this thesis is illustrated in figure 5.8. The vtpm is implemented in the Xen traditional way with a frontend and backend driver model. A so-called vtpm Manager software is located in Domain-0 and it handles the access of the individual vtpm instances to the hardware TPM. Figure 5.8.: Virtual vtpm implementation in Xen [19] The vtpm functionality is included in the Xen hypervisor package and can be optionally turned on before compiling and installing Xen. The vtpm is an open source product, which forms a 55

65 5. The Proof of Concept System trustworthy building block that can be used if the individual virtual machines require access to an own instance of TPM, depending on the specific use case. For a trustworthy launch of the virtualization layer and the host operating system the vtpm implementation is not required Software-based TPM Emulator A further type of Trusted Platform Module implementation utilized in this research work is the software-based TPM Emulator [62]. The software-based implementation enabled the author to speed up the development and evaluation process of the proof-of-concept system. However, since the TPM Emulator is a software application, it should not be used for security-critical applications Security enhanced CPU and chipset The proof-of-concept system utilizes the previously described security and virtualization extensions of recent Intel CPUs and chipsets. The enhancement for virtualizing the CPU on x86 architectures (Intel VT-x) is used for the creation of so-called Hardware Virtual Machines (HVM) in Xen. Using this technology, an additional CPU protection ring, Ring -1, will be added for the hypervisor to become the most privileged one. Therefore, the operating system kernel can stay in Ring 0 and needs not to be modified to become more virtualization friendly. The benefits of this technology are related to performance and flexibility rather than enhanced security. Using VT-x enables one to run unmodified operating systems and operating systems whose kernel sources are closed, such as Microsoft Windows, in a Virtual Machine (VM). A further benefit is to be able to run legacy applications on modern hardware platforms. Employing VT-x enhances the usability and feasibility of the concepts of the proposed proof-of-concept system in this thesis. Intel VT-d [41] is utilized in the proposed architecture to support virtualization of I/O devices and to offer hardware-based security extensions for the mitigation of the potential risk of malicious DMA access. The implementation of an Input/Output Memory Management Unit 56

66 5. The Proof of Concept System (IOMMU) can be configured to remap DMA addresses only to well-defined physical memory regions. Furthermore, Intel VT-d is used for the secure pass-through of PCI devices. The proof-of-concept system in this research uses this technique for the creation of a dedicated tiny-held virtual appliance used for networking, whose integrity can by assured more easily. The Intel TXT processor capabilities [32] are employed in the proof-of-concept system for the measured and protected launch of critical system software, such as the virtualization layer and the operating system kernel. The integrity of such a so-called Measured Launched Environment (MLE) can be checked by the CPU enhancements, which allows special software components to execute only on pre-defined software configurations by creating a Dynamic Root of Trust Additional hardware-based security modules During the specification phase of this research project the capabilities of different hardwarebased security modules were evaluated for their suitability for enhancing the trust level of commonly used embedded x86 platforms. The Trusted Platform Module was finally selected as the security implant for the proof-of-concept system. However, depending on the application field and the requirements on security features, further hardware-based security modules can be employed for the development of a multi-layered security architecture. Whereas the Trusted Platform Module can be used to authenticate the hardware platform, additional technologies, such as smartcards or USB security tokens, could be used to authenticate the individual user of the platform for multi-factor authentication Software components Besides the hardware components, consisting of the Backplane, COM module, Trusted Platform Module, and security enhancements of CPU and chipset, as well as optional additional hardware-based security techniques, the proof-of-concept system employs software and software components, which will be described below. 57

67 5. The Proof of Concept System BIOS In order to make use of the hardware-based security features, it is important that the BIOS of the platform supports the various components for added trust which have been noted above. For the security enhancements to come into effect, the corresponding BIOS settings for the Intel VT-x, Intel VT-d and Intel TXT have to be enabled. Furthermore, the Trusted Platform Module functionality has to the enabled in the BIOS and the ownership of the module has to be taken into account. The original BIOS version of the COM modules employed in the proof-of-concept system did not have support for the Intel TXT technology and a modified BIOS version has been provided by Kontron. Since the TPM module can be cleared with a BIOS setting, with evidence of physical presence, the proof-of-concept system should always implement a BIOS password Virtualization Layer The open source hypervisor, Xen, is used in the proof-of-concept system for the virtualization of different operating systems, which adds security by isolating security critical parts from potentially untrustworthy ones. During this research work different versions of Xen were evaluated for their suitability for enhanced security characteristics. As already stated, the proof-of-concept system is based on Xen versions 4.x which enable the creation of special purpose virtual appliances, such as a dedicated network domain. In an early stage of the research work a system without virtualization, utilizing the Intel TXT, was developed. This was done to evaluate the correct functionality of the Intel TXT and the modified BIOS version. Therefore various Linux distributions were specially configured and compiled to support Intel TXT, Intel VT-d and the integrated TPM from Intel. Additionally, easy-to-use installers for these modified operating systems were created. 58

68 5. The Proof of Concept System TrouSerS In order to offer the host operating system an interface for the communication with the Trusted Platform Module, as well as for the development of Trusted Computing aware applications, a Trusted Software Stack is necessary. One design goal of the proposed proof-of-concept system was the creation of an open platform, based on open source components. The proof-of-concept system implements the open source implementation, called TrouSerS [6], initially developed and released by IBM, and it is compliant to the Trusted Software Stack Specification of the Trusted Computing Group tpm-tools IBM also developed a set of tools called tpm-tools [5] included in the overall TrouSerS SourceForge project. These tools offer basic TPM management functions and functions for data management. The open source tpm-tools are also implemented in the proposed proofof-concept, which were used during the research project for the evaluation of the correct functionality of the Trusted Software Stack and the TPM implementation. These tools furthermore offer an insight for the developers in how to program Trusted Computing aware applications Trusted Boot (tboot) To leverage the Intel TXT Technology the software package tboot is used in the proposed proof-of-concept system. The tboot also called Trusted Boot, is an open source project, which can enforce system policies during the boot process of the platform [3]. The Trusted Boot implementation is an example implementation for the creation of a Measured Launched Environment (MLE) [40]. It supports several Linux distributions as well as the Xen hypervisor. During the research project Microsoft Windows was not supporting Intel TXT. The software package consists of two components. The first part is the tboot pre-kernel/vmm module, which will be launched before the actual Linux kernel or virtualization layer and 59

69 5. The Proof of Concept System attempts to perform a measured launch of the system. The second part consists of a set of tools for the creation of platform policies. These policies will define which system configurations should be able to boot in a well-defined manner and order. All other configurations will result in a reboot of the system or even a system halt. The tboot project offers functions for the definition of special policy indices in the non-volatile memory region of the TPM; as well as functions to write the fingerprint of the created policies into the TPM. Two different types of policies can be created, i.e. Launch Control Policies (LCP) and Verified Launch Policies (VLP) Launch Control Policy The Launch Control Policy (LCP) is used to define the types of acceptable MLEs, as well as the acceptable static PCR values on the platform, which are stored in the Static Root of Trust for Measurement (STRM) PCRs. This way the administrator of the platform can decide which version of the tboot pre-kernel/vmm module should be able to launch, only if the rest of the boot process was performed in a well-defined configuration. All other configurations will result in a reboot of the system with a subsequent system halt displaying the error log. Two different versions of the LCP policy creation tools exist. The ETXexpress-PC COM module, a platform developed before 2009, makes use of the version 1 of the LCP policy creation tools and the ETXexpress-SC COM module, produced in 2011, utilizes the version 2 of the LCP tools which offers some additional configuration abilities Verified Launch Policy The Verified Launch Policy (VLP) is used to define the virtualized environments and operating system structures which should be able to boot with a well-defined configuration. During the boot process of these components the TPM measures the integrity by hashing these components and storing the measured values in the Dynamic Root of Trust for Measurement (DRTM) PCRs. The CPU will evaluate the resulting hash values in a specially secured memory region inside 60

70 5. The Proof of Concept System of the processor. Depending on the type of VLP, only successfully verified components will be able to execute. All other configurations will result in a system halt Use cases / Application fields A design goal for the proposed security architecture was the definition of trustworthy building blocks based on open source components for the creation of an open platform. A key goal for the proposed proof-of-concept system was that it could be possible to apply the solution in many different application fields. Some interesting example application fields are briefly outlined below. Gaming Industry - Casino operators are always looking for smart and stylish gaming devices, which are based on secure platforms that are protected against malicious behaviour and tampering. Especially, slot machines often consist of multiple physical systems, each with a well defined task. The concepts of the proposed security architecture could be ported to the gaming industry applications for the secure consolidation of these multiple physical systems into one virtualized environment. Industrial Automation - Today industrial computing equipment has a great need for platforms with a high level of dependability. Furthermore, often legacy systems are employed, which are required to run on older or even obsolete hardware platforms. Virtualization offers the benefit to run legacy software and operating systems on stateof-the-art hardware platforms. The use of hardware-based security can enhance the trustworthiness of the employed computer workstations. Automotive Industry - Today s vehicles are loaded with electronic features, such as infotainment systems. There is even a movement to employ virtualization techniques in the automotive industry. Therefore, security and safety are very important for future of in-vehicle electronic systems. The concept of a hardware-based Trust Anchor, combined with the isolation ability of thin bare-metal hypervisors, can potentially be of use for the automotive industry. 61

71 5. The Proof of Concept System Medical Sector - The healthcare industry has many innovations, including advanced computing technologies, such as networked patient monitors. Therefore it is essential to employ highly reliable and secure computing infrastructures. It must be ensured that software is running in a stable and reliable computing environment that additionally protects the Privacy of patient data. The concepts of the proposed architecture in this thesis can address these requirements Security vs. usability The enhanced security mechanisms proposed in this thesis will unavoidably have an impact on user convenience. The correct use of the proposed solution demands good knowledge of the underlying components to configure the parameters in a correct manner. A desirable feature is to increase the usability of the proposed security architecture. During the research project several efforts were made to enhance the usability aspects of the developed architecture. To assure an easy deployment of the proof-of-concept system, easy-touse installation programs have been created which allow interested manufacturers to evaluate the security architecture more quickly. Furthermore, scripts for the creation of sample platform policies have been written for easy provisioning of the TPM and the platform. The correct use of the TPM management tools, as well as the platform policy creation tools, which are provided by the open source software packages, is a quite complicated task. The creation and the deployment of platform policies requires technical engineering know how and a good knowledge of the employed technologies. Furthermore, the command line policy creation tools possess a potential weak point regarding security. When the policies are written into the non-volatile memory of the Trusted Platform Module, the system administrator has to authenticate himself/herself to the TPM, by typing in the TPM owner password. Unfortunately, the password has to be typed in as a command line argument, and therefore it could be clearly visible. Even worse, the typed-in commands will be saved in the command line history and thus could be retrieved at any time. If the policies 62

72 5. The Proof of Concept System are written to the TPM with normal user rights, any person with access to the platform can potentially find out information about the TPM owner s password. Based on the above discussion on configuration and the use of command-line tools, towards the end of this research work, it was seen as a desirable feature to develop a Graphical User Interface (GUI), which would effectively address the described weak points and enhance the usability, and thus the acceptability of the proposed security solution, which is described in this thesis. According to the individual goals of the research project the GUI is developed in the C++ programming language, using Qt for platform independence. The GUI forms an effective tool, which can be used by the system administrator for the provisioning and maintenance of the proposed security architecture. By utilizing the Trusted Software Stack API, the tool combines functions for the management of the Trusted Platform Module, such as commands for taking ownership or clearing the TPM with data management functions. Furthermore, the GUI is developed to provide an easy-to-use scheme for the creation and the deployment of platform configuration policies. The system administrator will provide the information about the individual software components, which should be able to launch with a well-defined configuration, the program will automatically create the corresponding platform policy and write the policy into the TPM non-volatile storage. At the time of writing this thesis the GUI is in an early stage of development. It makes use of the most important TSS API calls. Below the use of the TSS API is demonstrated in the example of sealing arbitrary data to a specific system state. The functions for error handling have been omitted for more clarity. Before a program can make use of the capabilities provided by the TPM it first has to connect to the device (see listing 5.1). The arbitrary data will be sealed to a subset of the Platform Configuration Register (PCR) values. Therefore a PCR object has to be created, which will be filled with the chosen PCR values (see listing 5.2). 63

73 5. The Proof of Concept System Listing 5.1: Connect to local TPM 23 /* Create context */ 24 i f ( contextcreate(&hcontext)!= TSS_SUCCESS) 25 /* Error handling */ /* Connect to context */ 28 i f ( contextconnect(hcontext)!= TSS_SUCCESS) 29 /* Error handling */ /* Connect to local TPM */ 32 i f (contextgettpm(hcontext, &htpm)!= TSS_SUCCESS) 33 /* Error handling */ Listing 5.2: Create PCR object 38 /* Create PCR object */ 39 i f ( contextcreateobject(hcontext, TSS_OBJECT_TYPE_PCRS, initflag, &hpcrs)!= TSS_SUCCESS) 40 /* Error handling */ /* Read PCR values from TPM */ 43 for ( i = 0; i < selectedpcrslen ; i++) { 44 i f (tpmpcrread(htpm, selectedpcrs[ i ], &pcrsize, &pcrvalue)!= TSS_SUCCESS) 45 /* Error handling */ /* Set PCR values for PCR object */ 48 i f (pcrcompositesetpcrvalue(hpcrs, selectedpcrs[ i ], pcrsize, pcrvalue)!= TSS_SUCCESS) 49 /* Error handling */ 50 } if ( initflag ) { 53 UINT32 localityvalue = 54 TPM_LOC_ZERO TPM_LOC_ONE TPM_LOC_TWO TPM_LOC_THREE TPM_LOC_FOUR; /* Set locality information */ 57 i f ( pcrcompositesetpcrlocality( hpcrs, localityvalue)!= TSS_SUCCESS) 58 /* Error handling */ 59 } 64

74 5. The Proof of Concept System A symmetric key is be used for the encryption of the arbitraty data, which is created securely inside of the TPM using the internal Random Number Generator (see listing 5.3). Listing 5.3: Utilize RNG for the creation of a symmetric key 67 /* Get some random data for use as symmetric key */ 68 i f (tpmgetrandom(htpm, EVP_CIPHER_key_length(EVP_aes_256_cbc() ), &randkey)!= TSS_SUCCESS) 69 /* Error handling */ The symmetric key will be bound to the TPM. Therefore a new asymmetric key is created with the Storage Root Key (SRK) as parent key (see listing 5.4). Listing 5.4: Create new asymmetric key object 75 /* Load the SRK */ 76 i f (keyloadkeybyuuid(hcontext, TSS_PS_TYPE_SYSTEM, SRK_UUID, &hsrk)!= TSS_SUCCESS) 77 /* Error handling */ /* Get the default policy for the SRK secret */ 80 i f ( policyget(hsrk, &hsrkpolicy)!= TSS_SUCCESS) 81 /* Error handling */ /* Set the secret for the policy */ 84 i f ( policysetsecret( hsrkpolicy, (UINT32)pswd_len, (BYTE *)passwd)!= TSS_SUCCESS) 85 /* Error handling */ /* Create a new RSA key object */ 88 i f ( contextcreateobject(hcontext, TSS_OBJECT_TYPE_RSAKEY, keyflags, &hkey)!= TSS_SUCCESS) 89 /* Error handling */ /* Create a new policy object for the RSA key object */ 92 i f ( contextcreateobject(hcontext, TSS_OBJECT_TYPE_POLICY, TSS_POLICY_USAGE, &hpolicy)!= TSS_SUCCESS) 93 /* Error handling */ /* Set the secret for the policy */ 96 i f ( policysetsecret( hpolicy, strlen (TPMSEAL_SECRET), (BYTE *)TPMSEAL_SECRET)!= TSS_SUCCESS) 97 /* Error handling */ 65

75 5. The Proof of Concept System /* Assign the policy to the RSA key object */ 100 i f ( policyassign( hpolicy, hkey)!= TSS_SUCCESS) 101 /* Error handling */ /* Create the RSA key with SRK as parent key */ 104 i f (keycreatekey(hkey, hsrk, NULL_HPCRS)!= TSS_SUCCESS) 105 /* Error handling */ /* Load the newly created RSA key */ 108 i f (keyloadkey(hkey, hsrk)!= TSS_SUCCESS) 109 /* Error handling */ After the newly created key has been loaded, an encrypted data object is created that will hold the symmetric key. This key is then sealed with the asymmetric RSA key to the platform configuration (see listing 5.5). 66

76 5. The Proof of Concept System Listing 5.5: Sealing of symmetric key 118 /* Create encrypted data object for the symmetric key */ 119 i f ( contextcreateobject(hcontext, TSS_OBJECT_TYPE_ENCDATA, TSS_ENCDATA_SEAL, &hencdata)!= TSS_SUCCESS) 120 /* Error handling */ /* Create a new policy object for the encrypted data object */ 123 i f ( contextcreateobject(hcontext, TSS_OBJECT_TYPE_POLICY, TSS_POLICY_USAGE, &hpolicy)!= TSS_SUCCESS) 124 /* Error handling */ /* Set the secret for the policy */ 127 i f ( policysetsecret( hpolicy, strlen (TPMSEAL_SECRET), (BYTE *)TPMSEAL_SECRET)!= TSS_SUCCESS) 128 /* Error handling */ /* Assign the policy to the encrypted data object */ 131 i f ( policyassign( hpolicy, hencdata)!= TSS_SUCCESS) 132 /* Error handling */ /* Encrypt and seal the symmetric key */ 135 i f ( dataseal(hencdata, hkey, EVP_CIPHER_key_length(EVP_aes_256_cbc() ), randkey, hpcrs)!= TSS_SUCCESS) 136 /* Error handling */ /* Get the encrypted data blob */ 139 i f ( getattribdata(hencdata, TSS_TSPATTRIB_ENCDATA_BLOB, TSS_TSPATTRIB_ENCDATABLOB_BLOB, & enclen, &enckey)!= TSS_SUCCESS) 140 /* Error handling */ /* Get the key blob */ 143 i f ( getattribdata(hkey, TSS_TSPATTRIB_KEY_BLOB, TSS_TSPATTRIB_KEYBLOB_BLOB, &sealkeylen, & sealkey)!= TSS_SUCCESS) 144 /* Error handling */ 67

77 5. The Proof of Concept System Finaly the context to the TPM is closed (see listing 5.6). 189 contextclose(hcontext) ; Listing 5.6: Close context to TPM Besides the management and policy creation function, the GUI will also give an insight into how to program Trusted Computing aware applications, a concept that some of the interested customers of Kontron can pick up on, for the development of their own specific applications Summary This chapter has described how the proposed security architecture of the research project was developed and implemented. The applied hardware and software components have been described in some detail. The proof-of-concept system has been developed on two different COM Modules from Kontron Embedded Modules GmbH, where each has a different type of TPM. Thus comparisons between COM Modules, TPM Modules, and Platform Policy Creation Tools have been made. With the suggestions of some possible use cases and application fields, and a discussion on how to improve the usability of the proposed solution, an overview on the proof-of-concept system has been presented. 68

78 6. Validation of the Proof of Concept System 6.1. Introduction The proof-of-concept security architecture was designed and developed according to the guidelines, as described in the previous chapters. It consists of several hardware, firmware and software components. For the correct functionality of the proposed security architecture, it is mandatory that the platform runs through a sophisticated provisioning process, which has to be fully understood so that it complies with the intended behaviour. It is possible that mistakes can arise from a wrong implementation or configuration of any of the various employed components. Since a smooth interaction of all involved parts is essential, some validation work is required Objective In order to assure confidence in the third party developers who will create systems based on the proposed approach in this thesis, the correctness of the functionality of each component needs to be somehow guaranteed. Further, the claimed security benefits introduced by the proposed security architecture, compared to the traditional operating systems, have to be established. To assure the functionality and correctness of the proposed system, several test runs should take place that will demonstrate the enhanced security features. Some test and validation work is 69

79 6. Validation of the Proof of Concept System described here. Beyond the test reports for the individual test cases, some interesting files are also created which contain important debug information General This section describes the specific configuration of the proposed proof-of-concept system and will give an overview of the platform provisioning process. Furthermore, it describes how the correct functionality of the concept is tested in different scenarios and it will provide a discussion of how the proposed proof-of-concept system can offer an enhanced security level, compared to a traditional computing system. The work shows how some bugs in the prototype implementation were found and rectified. Configuration of the proof-of-concept system During the research work two different types of COM Express modules were provided by the industrial partner, Kontron, for the development of the proof-of-concept system, as already described in Chapter 5. Thus, two types of the proof-of-concept systems exist. One type is based on the ETXexpress-PC COM module, which was produced before 2009, and the second type is based on the more recent ETXexpress-SC COM module, produced in These two types of COM modules possess different hardware configurations and also the software components have to be configured in different ways for the proof-of-concept system to be fully functional. The configuration of hardware and software components of these two types of modules are outlined as follows: ETXexpress-PC-based proof-of-concept system CPU: Intel Core 2 Duo, 2 x 1.86 GHz Chipset: Intel GS45 with Intel ICH9M RAM: 2 GB DDR MHz dual channel SO-DIMM memory 70

80 6. Validation of the Proof of Concept System Hardware-based security module: Integrated TPM1.2 from Intel Backplane: COM Express Eval Type 2 BIOS: Modified version with TPM, Intel VT-x, Intel VT-d and Intel-TXT support Hypervisor: Xen version 4.1 Host operating system: Ubuntu Linux 10.4 with Long-Term-Support (LTS) Guest operating systems: Ubuntu Linux 10.4 with LTS, Windows XP SP3 Trusted Software Stack: trousers ubuntu4 TPM management tools: tpm-tools Measured Launched Environment software: tboot revision 252 SINIT-AC module: GM45, PS45 and PM45 Express Launch Control Policy: lcp creation tools version 1 Verified Launch Policy: vlp creation tool tb_polgen ETXexpress-SC-based proof-of-concept system CPU: Intel Core i5, 2 x 2.5 GHz Chipset: Intel Mobile QM67 RAM: 4 GB DDR MHz dual channel SO-DIMM memory Hardware-based security module: Discrete TPM1.2 SLB96355TT from Infineon Backplane: COM Express Eval Type 2 BIOS: Modified version with TPM, Intel VT-x, Intel VT-d and Intel-TXT support Hypervisor: Xen version 4.1 Host operating system: Ubuntu Linux Guest operating systems: Ubuntu Linux 10.10, Windows XP SP3 71

81 6. Validation of the Proof of Concept System Trusted Software Stack: trousers TPM management tools: tpm-tools Measured Launched Environment software: tboot revision 252 SINIT-AC module: i5 and i7 Processor Dual Launch Control Policy: lcp creation tools version 2 Verified Launch Policy: vlp creation tool tb_polgen Provisioning of the proof-of-concept system Various steps are necessary for the implementation of the proof-of-concept system. The whole platform provisioning process overview is illustrated in figure 6.1. The starting point of this provisioning process assumes that the hardware components, especially the COM module, are in their factory state. The first step, Step Number 1, is to install a fresh and specially modified BIOS binary, illustrated as BIOS.bin, onto the evaluation platform. This will ensure that the provisioning process is starting from a well-known state. This BIOS version will include the support for the Trusted Platform Module, as well as support for the security and virtualization enhancements from the Intel system extensions (Intel VT-x, Intel VT-d and Intel TXT). The virtualization extensions Intel VT-x and Intel VT-d should be enabled in this step, before proceeding to Step Number 2. The resulting system state will be an Intel VT enabled system. A next major step is the choice and installation of an appropriate Linux operating system. It is important that this system is configured to be as small as possible and should only contain the most important applications, since it will be the Domain-0 in a Xen virtualized environment. If necessary additional drivers or patches can be applied to the system. Before proceeding to the next step the correct functionality of the operating system should be verified. The outcome of this step is a fully functional Linux operating system. 72

82 6. Validation of the Proof of Concept System The third step in the platform provisioning process is the installation of the Xen hypervisor. The hypervisor sources have to be obtained from the Xen Homepage and subsequently configured, compiled and installed. Additionally the host operating system has to be configured and the guest operating systems have to be installed. In utilizing the Intel VT-d technology a special virtual appliance for networking can be created for additional security. The correct functionality of the Virtual Machine Monitor implementation has to be verified in order to complete this provisioning step. Following Step Number 3 the virtualized environment is fully functional. Step Number 4 deals with the activation and provisioning of the Trusted Platform Module. Therefore, as a first action, the TPM has to be enabled in the BIOS of the platform. The ownership of the TPM must be taken over, for instance by using the corresponding function of the open source tpm-tools package. In order to make use of the tpm-tools package, the open source implementation of a Trusted Software Stack, called TrouSerS, also has to be installed to the system. Afterwards, the TPM can be provisioned by using the TPM provisioning scripts from Intel. These batch files, executed from a DOS bootable USB stick, will define three policy indices in the TPM non-volatile storage region: Auxiliary ; Default ; and Owner. The last action of Step Number 4 will be to lock these newly defined indices. The resulting system state will be a TPM enabled platform, which will be a properly provisioned platform. In Step Number 5 the Intel TXT functionality has to be enabled in the BIOS of the platform. From this point onwards, the platform will be Intel TXT enabled. After the Intel TXT functionality has been enabled, the correct functionality has to be verified in Step Number 6. Therefore, the EFI TXT Tool Kit from Intel, which can be accessed via Intel Business Link, is used. These tools verify some basic settings and configurations in the BIOS, and can also perform state transitions. The EFI based commands can be executed from an EFI bootable USB stick. The Intel TXT hardware settings will be verified by the tool "TXTINFO", which queries certain registers, memory and further system resources that are related to the Intel TXT functionality. This tool will be executed first in a Non-TXT State. Afterwards, the correct TXT entry will be verified, by using the tool GETSEC that will invoke some of the Safer Mode extensions (SMX) commands for the processor. Therefore, the platform specific Secure INITialization Authenticated Code (SINIT-AC) module has to be obtained from the 73

83 6. Validation of the Proof of Concept System SourceForge tboot project homepage. The call of GETSEC[SENTER], with the SINIT-AC module as parameter will verify the secure transition into the TXT State. Once the system is in the TXT State, the TXTINFO tool will once again be executed and the output will be evaluated. Finally the call of GETSEC[SEXIT] should securely exit the TXT State. Only if all of these EFI TXT Tools will have passed the tests, will the basic Intel TXT functionality have been verified; if not, a debugging process will need to be enforced. Following the successful completion of this step, the basic platform TXT settings on the evaluation platform will have been verified. The next step, Step Number 7, deals with the installation of the tboot software package onto the Domain-0 for the Linux host operating system. The first action is to download tboot from the corresponding SourceForge homepage. Alternatively the software package can also be obtained form the Mercurial repository. Later, the software has to be compiled and installed to the target system. Further, the bootloader s configuration has to be modified and the platformspecific SINIT-AC module, which will have already been downloaded, will have to be added to the configuration. After performing this step of the platform provisioning process, the actual system state will feature a Measured Launched Environment (MLE) enabled platform. However, the platform policy, which is installed by default, will basically be a so-called any policy scheme, which will successfully boot any platform configuration. The last step, Step Number 8, will complete the platform provisioning process. This step is concerned with the creation and deployment of specially adjusted platform configuration policies, by using the platform policy creation tools provided by the tboot project. The first action of this step will be to define additional indices inside of the non-volatile memory region of the TPM, such as a MLE error index and an index for the footprint of the customized policies. After the definition of the required indices, various platform policies, i.e. Launch Control Policy (LCP) and Verified Launch Policy (VLP), will be created, which will restrict the MLE to only launch the well-defined software components, with a well-defined configuration, in a welldefined order. Finally, the system will have to be rebooted in order to verify the newly-enabled measured launch capabilities. Once the correct policy enforcement of the previously defined custom policies has been verified, the platform provisioning process of the evaluation platform will have been completed and the proof-of-concept system will have been fully verified. 74

84 6. Validation of the Proof of Concept System Figure 6.1.: Proof-of-concept platform provisioning process overview 75

85 6. Validation of the Proof of Concept System The proposed proof-of-concept system utilizes some components, such as the Trusted Platform Module and the virtualization and Trusted Computing enhancements from Intel, which have to be explicitly activated in the BIOS. In order to use all of these enhancements the BIOS has been modified by Kontron. Especially the Intel Trusted execution Technology (Intel TXT) enhancements cannot be activated with the standard factory BIOS version. The evaluation of the Intel TXT functionality on the ETXexpress-PC board has revealed some bugs in the BIOS implementation, which were detected and rectified in the course of this project work. Additionally, when evaluating the TPM functionality on the ETXexpress-SC module it turned out that the Platform Configuration Register (PCR) registers were not reset, in the case of a platform reboot or reset. This misbehaviour was corrected with a new BIOS version. Proof-of-concept test scenarios Once the platform had been correctly provisioned, according to the guidelines, which have been described above, it should be able to detect and withstand sophisticated software-based attacks, as well as elementary hardware-based attacks. For the full validation of the proposed proof-of-concept system, several test scenarios have been defined, which on the one hand demonstrate the correct behaviour of the platform, and on the other hand further highlight why the proposed solution can offer a higher security level that traditional computing systems. Below the individual test scenarios are described in some detail. Changing the platform configuration by low-level software manipulation A desirable attack point for an attacker can be to maliciously modify low-level system software components of the platform, such as the code and/or configuration of the BIOS, and/or the platform extensions code, as well as the code and configuration data of the Initial Program Loader (IPL). In this way the attacker can potentially trick the platform into executing arbitrary code which was not meant to be executed on the platform. Thus, the platform can be booted into an untrustworthy state, which might grant access to confidential data. 76

86 6. Validation of the Proof of Concept System The proposed proof-of-concept system implements methods for the creation of a secure, and therefore trustworthy, boot process. Therefore, during the creation of the platform configuration policies, the manufacturer/owner of the platform can decide to also include a subset of the Static Root of Trust for Measurement (SRTM) PCR registers to the platform the configuration policy. These register values are created as part of the static Chain of Trust during the boot process of the platform, which starts at the BIOS Power-On-Self- Test (POST), right after powering up the system, and which ends at the Master Boot Record (MBR), immediately before the tboot module takes control. As a result, low-level software modifications, such as changing the BIOS version of the boot loader of the system, will be detected by the Trusted Platform Module, as the corresponding static PCR register will contain another integrity measurement value. After executing the tboot module, the CPU of the platform will check if the system is in the well-defined state, as required by the platform configuration policy written to the non-volatile storage of the TPM. Since the integrity values differ from the values defined as trustworthy, the CPU will avert the launch of the Measured Launched Environment (MLE), due to a violation of the Launch Control Policy (LCP). For the test scenario, the BIOS version of the proof-of-concept platform has been modified. As a result, the policy was enforced correctly and did not allow the execution of the modified platform configuration. After powering up the system, it rebooted immediately and the corresponding error code was written into the TXT error index. During the next boot process, the system stopped execution and informed the user that it was not able to boot earlier, due to a wrong platform configuration. The results of the test demonstrate that the policy creation tools successfully included the chosen static PCR registers and the tboot module correctly executed the defined policy. In a traditional system, changing the BIOS version would not have been noticed by the operating system. Changing the platform configuration by hardware manipulation Instead of modifying the low-level software components of the system, an attacker could also try to change the hardware components of the platform, such as the network card, in the case that the attacker has physical access to the platform. This way, the attacker 77

87 6. Validation of the Proof of Concept System can potentially trick the platform into booting with a changed hardware configuration. The added hardware components could be specially modified by the attacker, in order to obtain security critical data, passwords and secret encryption keys. The already mentioned methods for the creation of a trustworthy boot process, which are implemented in the proposed proof-of-concept system, can also be potentially used for the detection of elementary hardware manipulations. Some of the static PCR registers can also represent the hardware configuration. Many devices, such as network cards, are equipped with an additional firmware part, which is located inside an optional ROM. The code inside the optional ROM, as well as its configuration data, will also be hashed during the boot process of the platform, and the integrity measurement will be stored securely inside of the TPM. As a result, elementary hardware changes, such as replacing the network card, will also be detected by the Trusted Platform Module, as the corresponding static PCR registers will contain other integrity measurement values. The processor of the system will check if the system is in the well-defined state, according to the platform configuration policy, after execution the tboot module. In the case of a modification, the integrity values will differ form the values definitely known as being trustworthy. Therefore, the CPU will avert the execution of the MLE, due to a violation of the Launch Control Policy. For the test scenario, in the experimental configuration, an additional network card from 3Com was attached to the proof-of-concept system, in order to simulate a hardware manipulation. As a result the hardware manipulation was detected, the policy was enforced correctly and did not allow the execution of the modified platform configuration. The system rebooted immediately after the power was given to the platform and a corresponding error code was written into the TXT error index. During the next bootstrap the system stopped execution and informed the user that it was not able to boot earlier, due to a wrong platform configuration. The results of the test demonstrated that the module tboot correctly executed the policy. A traditional system might have booted without any notification for the user. 78

88 6. Validation of the Proof of Concept System Changing the Measured Launched Environment (MLE) enforcing module tboot As a third attack point an attacker could also try to modify the module tboot, which is used to enforce the execution of a Measured Launched Environment (MLE). A malicious user could try to trick the tboot module into the successful execution of platform configurations, which may have not been explicitly defined as trustworthy during the policy creation process. This way, arbitrary software components would be able to launch, that could possibly be used to compromise the system. The tboot module has to be executed before the virtualization layer and the operating system kernel. In practice, the bootloader configuration has to be specially modified. The tboot module is part of the Dynamic Chain of Trust and therefore is also measured as a part of the platform configuration policy. The combined hash value, calculated for the employed module, as well as the tboot command line parameters in the configuration file, is also contained in the Launch Control Policy of the system. As a result, changes to the version of tboot, as well as changes to the command line parameters of the corresponding boot loader configuration file, will be detected by the executing processor, when checking the configuration of the system. In case of a modification of the tboot module, the CPU will immediately avert the execution of the MLE, due to a violation of the Launch Control Policy. For this test scenario, both a different version of tboot, as well as a modification of the corresponding tboot entry in the bootloader configuration file, were performed. As a result both modifications were detected by the CPU, which led to the correct enforcement of the defined platform configuration policy, which did not allow the execution of the modified platform configuration. The system wrote the specific error code into the TXT register and rebooted afterwards. During the next boot process the system stopped execution and informed the user that is was not able to boot earlier, due to a wrong configuration of the Measured Launched Environment. These results demonstrated the correct execution of the defined policy. 79

89 6. Validation of the Proof of Concept System Changing the components defined for protected execution Another attack possibility for an attacker is to modify the system software components, which are normally required to be executed. In a virtualized environment the boot order of the individual components is clearly defined. An attacker could try to subvert the integrity of the system by modifying these software components. Such modifications could consist of malicious changes to the operating system kernel, or the virtualization layer. If a malicious user manages to compromise one virtual system, further attacks could possibly follow. Besides the Launch Control Policy, also Verified Launch Policies can be created for the proof-of-concept platform. This type of policy describes the system software components, such as hypervisor, operating system kernel and initial ramdisk, which can only be launched with a well-defined configuration, and in a pre-defined order. Together with the integrity measurement of the tboot module, the measurements gained by the Verified Launch Policy will be stored in the dynamic PCR registers. This way is can be assured that only the defined software components, launched with the special configuration, as defined in the bootloader configuration file, are valid. As a result, changes to any of the system software components, such as operating system kernel changes, or changes to the hypervisor itself, will be detected by the Trusted Platform Module, as the corresponding dynamic PCR registers will contain alternated integrity measurement values. Once the CPU will evaluate if the system configuration is one of the intended configurations, as specified by the LCP and VLP policies, the modifications will be identified. Depending on the type of VLP policy, the system will either stop execution immediately, or continue execution and notify the user about the modifications. In the case of a continued boot process, the dynamic PCR values will not be accessible and all data sealed to these values cannot be decrypted in the untrustworthy state. For this test scenario, all possible ways of system modifications, including kernel and hypervisor modifications, have been carried out. As a result the Verified Launch Policy was enforced correctly and did not allow the execution of the modified system software 80

90 6. Validation of the Proof of Concept System components. When using the policy type halt the system will stop execution after the boot process and will display that a violation of the Verified Launch Policy has occurred. When using the policy types continue or nonfatal the system will boot the modified configuration, but the encrypted data will not be able to be decrypted. In a traditional system the changes to the operating system kernel or Virtual Machine Monitor (VMM) might not have been noticed. Boot an arbitrary system form a LiveCD or an USB stick If an attacker has physical access to the platform another attack type could be possible. The attacker might be able to boot an arbitrary operating system form a LiveCD or an USB stick, if the corresponding interfaces are available at the targeted system. In this way an attacker could avoid any protection mechanisms of the employed software-based security solutions and would have full access to the system and the data stored on the system s hard disk drive. In the proposed proof-of-concept system all security critical data will not only be encrypted, but also sealed to a specific state of the system, which is definitely known to be trustworthy. Both the static as well as the dynamic PCR registers can be included in the sealing process. This way it can be assured that the system or the user of the system can only get access to the security sensitive data if the system is in a trustworthy state. As a result, an attacker which physical presence to the system might have the oportunity to boot an arbitrary system, by using a LiveCD or an USB stick. However, this will not form a trusted boot process and therefore the dynamic PCR values will not be accessible. The attacker will not be able to decrypt the sealed data For this test scenario, the proof-of-concept system has been booted with a standard Linux operating system on a LiveCD. The result was that the file system of the system was accessible, however, the security critical data could not have been obtained in a clear format. In a real case scenario the whole of the virtual hard drives of the Virtual Machines would be sealed to the system state which would be definitely known as trustworthy. In 81

91 6. Validation of the Proof of Concept System a traditional system that does not make use of cryptography, a LiveCD boot could reveal security critical data. Memory scrub when Secrets flag is set Another possible way to attack a system and to retrieve secret data, such as encryption keys and passwords, is known as a Cold Boot Attack. In this type of attack the contents of RAM are scanned for valuable information. An attacker could try to read out the contents of RAM directly after the abrupt shutting down of the power supply of the system. The contents of RAM will remain readable for seconds, or up to minutes, after the power has been removed, or even longer if the RAM will be additionally cooled. The Intel TXT technology, which is utilized in the proposed proof-of-concept system, has introduced a special Secrets flag, which will be set right after a successful start of a Measured Launched Environment. If the MLE is correctly torn down the Secrets flag will be reset. This Secrets flag will indicate that security sensitive data, such as encryption keys, could be stored temporary in the RAM memory. The BIOS-AC module is responsible for the secure initialization of the platform. Therefore, it will perform a wipe of all the contents in RAM if the Secret flag is set during the platform initialization process. As a result, an attacker would not have the benefit of abruptly shutting down the system. When the system will be powered again, the BIOS-AC module will detect that the Secrets flag is set and perform an effective memory wipe. After the memory wipe the system will halt and will require an additional power-cycle in order to boot from a clean state. Therefore, the proof-of-concept system can mitigate the risk of a Cold Boot Attack. For this test scenario the proof-of-concept system was reset during the execution of a Measured Launched Environment. When the system was powered again, the implemented BIOS-AC successfully detected the Secrets flag and performed the memory wipe. It was not possible to read out the contents of the RAM. A traditional system might be more susceptible to a Cold Boot Attack. 82

92 6. Validation of the Proof of Concept System Since all the described test runs were passed, the functionality of the proof-of-concept system can be deemed to have been successfully validated Summary The validation of the proof-of-concept system, as described in this chapter, showed that, even as a prototype solution, the scheme can be seen to be working in a reliable and stable fashion. Special emphasis is given to the platform provisioning process, which has to be carefully followed for the correct configuration of the platform. Several test scenarios demonstrated the enhanced security level of the proposed security architecture, compared to traditional operating system structures. Some small errors in the BIOS implementation were discovered during the process of testing the functionality. Now the proof-of-concept prototype is ready to be presented to interested manufacturers of embedded platforms. 83

93 7. Results, Conclusion and Further Work Now that the proof of concept system has been described, the purpose of this chapter is to summarise the results of the work that has been done and to discern if the original project objectives were in fact achieved. Some proposed future work for the project is also suggested. When asking manufacturers of embedded devices about their strategies and plans to add additional security features, there is often a vagueness, or even disinterest, in the replies. Currently, trusted computing systems are often considered as an unnecessary complexity that can give rise to malfunctions or possible misconfigurations, and thus their inclusion in product roadmaps is often ignored. However, in the near future, all this could change very quickly. Changes in people s thinking will be driven by an increased awareness of the constant security threats and the risk of potential loss of revenue and damage to a manufacturer s reputations. A good example for this increased awareness is the recent appearance of malware in the special application field of industrial automation [22]. Although this research project has come to an end this chapter will suggest some additional features that could be included into this project, to further develop the concepts which have already been introduced in this work. Such advancements are being purposed in the hope that the project will continue into the future. 84

94 7. Results, Conclusion and Further Work 7.1. Review of the Achievements The original project objectives proposed the development of a proof-of-concept system, which should be based on various building blocks which would enable the portability of individual components into other application domains. The platform should be based on a hardware security module which should serve as a Trust Anchor for the whole security architecture. Additionally, the recent processor and chipset security schemes, along with virtualization enhancements, were proposed to be studied and implemented in the prototype. Furthermore, the state-of-the-art technologies of virtualization techniques and their usability towards enhanced security solutions were proposed to be analysed. A prototype system, as defined by the project objectives, was created. The full design detail can be found in Chapter 5. The whole system consists of several parts, where each part has clearly defined tasks. During the development of the proof-of-concept system, special consideration was given to the issue of user friendliness. For the demonstrator the complexity of platform provisioning and management functions were minimized. This was achieved by the development of a Graphical User Interface (GUI) for an easy interaction with the security features. In summary it can be stated that the project has met all of the requirements that were set out in the stated objectives for the research work Summary of Results When analysing the security risks of today s employed x86 platforms it appears that the x86 architecture possesses some general weaknesses as a consequence of the hardware structure itself. The operating system developers have sacrificed security features, which were designed by the hardware manufacturers, in favour of performance features and user convenience features. Additionally, many hardware components, such as the Direct Memory Access functionality, or the System Management Mode of Intel architectures, have not been designed with security 85

95 7. Results, Conclusion and Further Work in mind. Nowadays, these design weaknesses can be exploited as an injection vector for a successful attack. Besides the different weak points in hardware components, there are also some concerns regarding the system software and the associated applications. Poorly written code is fault-prone, and open to problems such as for Buffer Overflows and other attack possibilities. The commonly used and well-established operating systems have a very large code base and are often based on monolithic kernel structures. This increases the attack scope dramatically, because the theoretical number of exploitable bugs can also accumulate with the size of the software code. All these security weaknesses make it very clear that pure software-based security solutions can no longer provide adequate protection against sophisticated attacks and are insufficient for the creation of an effective security architecture. Today, the increased dependence on electronic networks further heightens the security risks and requires hardware-based protection of information, authentication of users, and the establishment of more-trusted infrastructures. More elaborate security techniques must consist of a combination of special hardware and software components. The Trusted Computing Group potentially offers a promising approach towards more trustworthy computing. As discussed in Chapter 3, a key aspect of this approach is a cryptographic hardware chip called the Trusted Platform Module which is tied to the platform. Based on this Trust Anchor a Chain of Trust should be established which guarantees the integrity of the system. However, it is now well understood that a trusted platform alone is not sufficient for the creation of a trusted computing system. Such a system design must also be based on a trustworthy operating system. However, the creation of a trusted operating system is a very complicated task. Furthermore, for many reasons most companies need to continue to use popular operating systems. The creation of a trustworthy operating system is still an active area of research and it is still at an early stage of evolution. The use of virtualization techniques for the development of a trusted operating system, as well as to add trust in commonly used operating systems, seems to be a very worthwhile approach. Virtualization adds security by isolating security 86

96 7. Results, Conclusion and Further Work critical parts of a system from potentially untrustworthy components. A resulting problem is that by just implementing virtualization techniques alone, no security benefit is achieved. An adequate thin-hypervisor has to be carefully chosen, which fulfils the stringent requirements for an integrity protected hypervisor. The open source hypervisor Xen meets most of these requirements. The virtualization and security enhancements of modern CPUs and chipsets provide a possible solution for the protected execution of software, which can address many goals of Trusted Computing, which are currently left unsolved by the Trusted Computing Platform as specified by the Trusted Computing Group. Trusted Computing, together with these CPU security extensions, furthermore has the potential to greatly enhance the security of hypervisors by ensuring a well-defined launch of the virtualization layer. Thus only those configurations which are definitely known to be trustworthy will be executed. Any other configuration will result in a reboot or even a system halt. The combination of the isolation ability provided by different virtualization technologies, along with Trusted Computing techniques, provides a very important field of research. The Trusted Platform Module is usually not intended to be utilized in virtualized environments. In order to equip the individual virtual machines with an own instance of TPM, a virtual TPM can be assigned to the VMs, where a virtual TPM is closely linked to the hardware TPM. The Trusted Computing Group is aware of the security benefits that can be achieved through the isolation approach, and the next version of TPM might well be more receptive to the inclusion of integrated virtualization support. Enhanced security mechanisms, unavoidably have an impact on user convenience. Even now, while effective security solutions are required more than ever, it is very hard to sell security features which have even the smallest impact on system performance or on usability. Often the use of security features demands technical engineering know-how to configure the security parameters in the correct manner. A compromise between security features and usability has to be found for a practicable security solution. Furthermore, effective management tools are necessary for the system administrator to oversee the platform security capabilities. 87

97 7. Results, Conclusion and Further Work Specialist application fields also require special security solutions. For mission-critical realtime systems, for instance, the security features must not affect the real-time capability of the solution. The usability of virtualization techniques for mission-critical systems is in question and the field of ongoing research. This thesis has some inroads in this area but there a still huge amount of work to be done Future work As the proof-of-concept system is already at the working prototype stage, some possible advancements will be proposed, in an effort to show further possible development phases. If more time was provided the proof-of-concept demonstrator could be further developed, which the author proposes, as follows: 1. The proposed approach focuses on adding trust to the platform itself. The next steps will include setting up a small network of trustworthy platforms and investigating how the individual systems can add trust to each node as well as to the network and to evaluate which additional components will be necessary for the creation of a trustable network [13]. Further work will develop theoretical models of the security strategies and will develop risk assessments and proof scenarios. 2. To further decrease the Trusted Computing Base of the platform, the size of the operating system residing in Domain 0 should be held as small as possible. Since Domain 0 is the management domain in Xen it should not be used for general computing purposes in an efficient security architecture. The next version of the demonstrator platform should employ a minimal Linux operating system based only on the necessary packages for the system administrator. 3. As described in Chapter 3 one goal for the creation of a trustworthy operating system is the implementation of a Trusted Input/Output system. Depending on the application field and the specific use case, special considerations in Trusted Channels and Trusted Paths should be taken into account. To avoid the leaking of information the important 88

98 7. Results, Conclusion and Further Work communication channels should be encrypted. This will include the development of trustworthy peripherals. 4. The impact on performance for a system, by introducing security solutions, has always been an issue with applications, operating systems, and other information technology infrastructures, which often leads to some form of performance limitations, or usability limitations, in systems. Especially in the specialist application field of industrial automation, many applications require soft or even hard real time capabilities. The use of a hypervisor for a security architecture can potentially hinder the successful implementation of such an approach. Additional investigations will be necessary in order to build up a real-time capable security solution, for example by the dedication of one core of a multi-core environment to the real-time task. 5. Increased security features inevitably have an impact on user convenience. Thus a compromise between the security features and usability has to be found. The proposed security architecture still requires technical engineering know how to configure security parameters in the correct manner. This project work incorporated the development of a user-friendly graphical user interface for the management of the security features provided by the platform. To further increase the user friendliness of the demonstrator platform the program will be upgraded with additional functionality, such as an update ability feature. 6. One fact about the concept of Trusted Computing that often gets ignored, is that measured integrity values, representing the state of the platform, have to be verified by a remote party. Efficient approaches for Remote Attestation [60] have to be planned depending on the application field. For example, a client platform should only be allowed to get access to a server platform if both systems are in a well-defined state, and thus a trustworthy state. 7. The results of this project, especially the proof-of-concept platform, will be presented to the customers of Kontron in order to increase the awareness for the need of a increased security level in our pervasive computing environments. Over time Kontron will provide 89

99 7. Results, Conclusion and Further Work client feedback on the new concepts and based on such feedback an updated white paper will be prepared. Once the proof of concept system was addressed and demonstrated, and the functionality was tested and reviewed, the key objectives for this research project were achieved Knowledge gained from this Research Project After initially spending time investigating the state-of-the-art technologies for hardware-based security modules, a richer understanding was gained into the world of IT security and trusted computing systems, as well as the associated basic cryptographic algorithms and protocols. Although, on starting the project work, the author already had a basic comprehensive understanding of virtualization techniques, much more depth and appreciation was gained during the review phase of the currently available hypervisors, especially the open source hypervisor: Xen. A completely new and unknown experience to the author was that of leading a project team consisting of two students. During the time of this project, weekly meetings had to be arranged to review the research project status, synchronise results and to discuss further plans and prospects. 90

100 Bibliography [1] ISO/IEC : Information technology Trusted Platform Module Part 1: Overview. [2] Official KVM website. [3] Official tboot project sourceforge website. [4] Official TCG website. [5] Official tpm-tools sourceforge website. tpm-tools/. [6] Official TrouSerS project sourceforge website. files/trousers/. [7] Official WindRiver - Hypervisor website. hypervisor/. [8] Official Xen website. [9] Phrack magazine - system management mode hacks. html?issue=65&id=7. [10] TCG PC Client Specific TPM Interface Specification (TIS), July [11] TCG Software Stack (TSS) Specification Version 1.2 Level 1, March [12] TCG Specification Architecture Overview, [13] TCG Trusted Network Connect, September [14] TPM Main-Part 1 Design Principles, March [15] TPM Main-Part 2 TPM Structures, March [16] TPM Main-Part 3 Commands, March

101 Bibliography [17] DoD STD. Trusted Computer System Evaluation Criteria. Dod Computer Security Center, December [18] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen and the art of virtualization. In Proceedings of the nineteenth ACM symposium on Operating systems principles, SOSP 03, pages , New York, NY, USA, ACM. [19] Stefan Berger, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, and Leendert Doorn. vtpm: Virtualizing the trusted platform module. In In USENIX Security, pages , [20] Hans Brandl. Trusted Computing: The TCG Trusted Platform Module Specification. Embedded Systems, [21] Hans Brandl and Thomas Rosteck. Technology, implementation and application of the trusted computing group standard (tcg) - secure platforms provide new levels of security. Technical report, Infineon, [22] Martin Brunner, Hans Hofinger, Christoph Krauß, Christopher Roblee, Peter Schoo, and Sascha Todt. Infiltrating critical infrastructures with next-generation attacks: W32.stuxnet as a showcase threat. Fraunhofer SIT, Darmstadt, December [23] David Challener, Kent Yoder, Ryan Catherman, David Safford, and Leendert Van Doorn. A practical guide to trusted computing. IBM Press, first edition, [24] David Chisnall. The Definitive Guide to the Xen Hypervisor (Prentice Hall Open Source Software Development Series). Prentice Hall PTR, Upper Saddle River, NJ, USA, [25] Intel Corporation. Intel atom processor z5xx series for embedded computing [26] Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole. Buffer overflows: Attacks and defenses for the vulnerability of the decade. DARPA Information Survivability Conference and Exposition,, [27] Roger R. Dube. Hardware-based Computer Security Techniques to Defeat Hackers: From Biometrics to Quantum Cryptography. Wiley Publishing, [28] Keir Fraser, Steven H, Rolf Neugebauer, Ian Pratt, Andrew Warfield, and Mark Williamson. Safe hardware access with the xen virtual machine monitor. In In 1st Workshop on Operating System and Architectural Support for the on demand IT InfraStructure (OASIS,

102 Bibliography [29] Carl Gebhardt, Chris I. Dalton, and Richard Brown. Preventing hypervisor-based rootkits with trusted execution technology. Elsevier Network Security Newsletter, 11:7 11, November [30] Kenneth Goldman, Reiner Sailer, Dimitrios Pendarakis, and Deepa Srinivasan. Scalable integrity monitoring in virtualized environments. In Proceedings of the fifth ACM workshop on Scalable trusted computing, STC 10, pages 73 78, New York, NY, USA, ACM. [31] David Grawrock. Dynamics of a Trusted Platform: A Building Block Approach. Intel Press, 1st edition, [32] David Grawrock. Establishing security with trusted execution technology architecture. Technical report, Intel Corporation, [33] David Grawrock. Establishing trust through system protection. Technical report, Intel Corporation, [34] John Linwood Griffin, Trent Jaeger, Ronald Perez, Reiner Sailer, and Leendert Van Doorn. Trusted virtual domains: Toward secure distributed services. In In Proc. of the First Workshop on Hot Topics in System Dependability (Hotdep05. IEEE Press, [35] Junkai Gu and Weiyong Ji. A secure bootstrap based on trusted computing. International Conference on New Trends in Information and Service Science, pages , [36] Infineon, embedded-security/trusted-platform-management/trusted-platform-module-%28tpm1. 2%29/channel.html?channel=ff ab681d0112ab6921ae011f. Infineon Trusted Platform Module SLB 9635 TT 1.2. [37] Infineon. TPM Key Backup and Recovery For Trusted Platforms, September [38] Infineon. Using Trusted Computing for enhancing Embedded Computing Platforms, July [39] Intel Corporation. Intel Trusted Execution Technology - Preliminary Architecture Specification, August [40] Intel Corporation. Intel Trusted Execution Technology MLE Developer s Guide, June [41] Intel Corporation. Intel Virtualization Technology for Directed I/O - Architecture Specification, September

103 Bibliography [42] Intel Corporation. Installing Xen* on an Intel Embedded Platform, October [43] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer s Manual - Volume 2B, September [44] Intel Corporation. A Practical Guide To tboot, November [45] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer s Manual - Volume 1: Basic Architecture, January [46] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer s Manual - Volume 3B, January [47] Invisible Things Lab. Qubes OS Architecture - Specification, January [48] ISO/IEC Standard Common Criteria for Information Technology Security Evaluation, August [49] Kontron Embedded Modules GmbH, computeronmodules/com+express/com+express+basic/etxexpresspc.html. ETXexpress- PC - Datasheet. [50] Kontron Embedded Modules GmbH, computeronmodules/com+express/com+express+basic/etxexpresssc.html. ETXexpress- SC - Datasheet. [51] Kontron Embedded Modules GmbH, computeronmodules/com+express/com+express+compact/starterkits+and+evaluation+ boards/com+express+eval+type+2.html. Starterkits and Evaluation Boards - Datasheet. [52] F. Leung, G. Neiger, D. Rodgers, A. Santoni, and R. Uhlig. Intel virtualization technology hardware support for efficient processor virtualization. Intel Technology Journal, [53] J. McDermott, J. Kirby, B. Montrose, T. Johnson, and M. Kang. Re-engineering xen internals for higher-assurance security. Inf. Secur. Tech. Rep., 13:17 24, January [54] Rebecca T. Mercuri and Peter G. Neumann. Security by obscurity. Commun. ACM, 46:160, November [55] Thomas Mueller. Trusted Computing Systeme: Konzepte und Anforderungen. Springer- Verlag, [56] Ronald Perez, Leendert van Doorn, and Reiner Sailer. Virtualization and hardware-based security. IEEE Security and Privacy, 6:24 31, September

104 Bibliography [57] Bruce Potter. High time for trusted computing. IEEE Security and Privacy, pages 54 56, [58] Joanna Rutkowska and Rafal Wojtczuk. Detecting & Preventing the Xen Hypervisor Subversions [59] Joanna Rutkowska and Rafal Wojtczuk. Attacking smm memory via intel cpu cache poisoning [60] Dries Schellekens, Brecht Wyseur, and Bart Preneel. Remote attestation on legacy operating systems with trusted platform modules. Sci. Comput. Program., 74:13 22, December [61] Bruce Schneier. Applied cryptography (2nd ed.): protocols, algorithms, and source code in C. John Wiley & Sons, Inc., New York, NY, USA, [62] Mario Strasser and Heiko Stamer. A software-based trusted platform module emulator. volume 4968 of Lecture Notes in Computer Science, pages Springer, [63] Chis Takemur and Luke Awford. The Book of Xen - a practical guide for the system administrator. No Starch Press, [64] Amit Vasudevan, Jonathan M. McCune, Ning Qu, Leendert Van Doorn, and Adrian Perrig. Requirements for an integrity-protected hypervisor on the x86 hardware virtualized architecture. In Proceedings of the 3rd international conference on Trust and trustworthy computing, TRUST 10, pages , Berlin, Heidelberg, Springer-Verlag. [65] William von Hagen. Professional Xen Virtualization. Wrox Press Ltd., Birmingham, UK, UK,

105 List of Figures 1.1. The company logo of Kontron Embedded Modules GmbH Principal project goals CPU protection rings - ideal usage CPU protection rings - real usage High-level overview of a Direct Memory Access (simplified) Overview of the processor states Illustration of a Buffer Overflow vulnerability Document Roadmap Diagram of the Trusted Computing Group Schematic design of a Trusted Computing System Trusted Software Stack The logo for the Xen hypervisor Xen-Hypercalls CPU protection rings - additional Ring Architecture of the experimental proof-of-concept system Hardware structure of the proof-of-concept system ETXexpress evaluation Backplane ETXexpress-PC COM Module ETXexpress-SC COM Module Trusted Platform Module from Infineon Components of an integrated itpm from Intel (simplified) Virtual vtpm implementation in Xen Proof-of-concept platform provisioning process overview E.1. Internal component structure of a Trusted Platform Module XXXI E.2. TPM states and state transitions XXXVI E.3. Highlevel overview of a Chain of Trust XXXVII 96

106 List of Figures E.4. Root of Trust for Storage - Key Hierarchy XXXIX E.5. Attestation procedure XLI 97

107 List of Tables E.1. Platform Configuration Register usage XXXV E.2. Locality Addresses XXXVIII 98

108 List of Listings 5.1. Connect to local TPM Create PCR object Utilize RNG for the creation of a symmetric key Create new asymmetric key object Sealing of symmetric key Close context to TPM

109 Glossary of Terms A Application Programming Interface An Application Programming Interface (API) is a set of definitions of the ways one piece of computer software communicates with another. It is a method of achieving abstraction, usually (but not necessarily) between lower-level and higher-level software. Attestation Identity Key The Attestation Identity Key (AIK) is an asymmetric RSA key pair, created by a Trusted Platform Module (TPM), used for the attestation of the trustworthiness of a platform to a third party. The Attestation Identity Key pair originates from the Endorsement Key (EK) and the public part of this key pair is transmitted to the attesting party which cannot be linked to the Endorsement Key for privacy protection reasons. B Basic Input Output System The Basic Input Output System (BIOS) is a de facto standard in IBM PC compatible computers, defining a firmware interface. The BIOS software is the first code executed when a platform is powered on. The BIOS identifies and initializes system devices and locates, loads and executes software held on a boot device. For Trusted Computing purposes the BIOS must be part of the static Chain of Trust for a secure bootstrap of the system. C Common Criteria for Information Technology Security Evaluation The Common Criteria for Information Technology Security Evaluation (CC) is an international standard for computer security evaluation and certification (ISO/IEC 15408). The Common Criteria standard provides assurance that the specification, implementation and evaluation processes of a computer security product have been carried out in a standard manner. 100

110 Glossary of Terms Computer On Module A Computer On Module (COM) is a subtype of an embedded computer system which illustrates an extension of the System On a Chip (SOC) concept. COM modules are complete computer systems built on a single circuit board which will usually lack the standard connectors for input/output peripherals. COM modules are usually mounted on a backplane which wires the bus signals to standard peripheral connectors. Core Root of Trust for Measurement In Trusted Computing (TC) capable systems the Core Root of Trust for Measurement (CRTM) code contains the first instructions executed when powering up the platform. The CRTM code, which is often implemented as BIOS extension must be explicitly trusted by the platform owner and includes the instructions for the creation of a Chain of Trust used for a secure bootstrap of the system by calculating a hash value of the next component and storing this value securely inside the Trusted Platform Module (TPM) before executing this component. D Direct Memory Access The Direct Memory Access (DMA) functionality allows specific subsystems within the computer to access the system s memory region independently of the CPU. DMA was developed by reason of performance and not with security in mind. Therefore the direct memory access difficulty has to be taken into account when developing trusted computing systems. Dynamic Root of Trust for Measurement The Dynamic Root of Trust for Measurement (DRTM) is a method for the establishment of a trusted boot sequence. It should provide assurance that the system, which booted is the exactly the system which was intended to boot. The Intel Trusted execution Technology (TXT) builds up on the central concept of a DRTM. E Endorsement Key The Endorsement Key (EK) is an unique RSA key pair with a length of 2048 bit, which usually is created during manufacturing process of a Trusted Platform Module (TPM). The EK can be clearly identified for a specific TPM and therefore must never leave the TPM, due to privacy reasons. 101

111 Glossary of Terms G Graphical User Interface A Graphical User Interface (GUI) is a software component that allows the user of a computer system the interaction with the system via graphical elements rather than text commands. A GUI represents the available informations and actions through visual indicators and symbols. The actions are usually performed through a direct manipulation of the individual graphical icons. H Hash-based Message Authentication Code The Hash-based Message Authentication Code (HMAC) is a cryptographic algorithm used for the calculation of a Message Authentication Code (MAC) in combination with a secret key. This way, both the data integrity and the authenticity of a message can be verified simultaneously. I Input/Output Memory Management Unit The Input/Output Memory Management Unit (IOMMU) is a special form of Memory Management Unit (MMU) which connects an I/O bus which is capable of performing Direct Memory Access (DMA) to the main system memory. Intel Virtualization Technology for Directed I/O (Intel VT-d) implements an IOMMU for Intel chipsets. L Low Pin Count The Low Pin Count (LPC) bus is used to connect low-bandwidth devices to the CPU. The physical wires of the Low Pin Count bus are usually connected to the southbridge of the chipset. The Trusted Platform Module (TPM) is also connected via the LPC bus. M Master Boot Record The Master Boot Record (MBR) us the first sector of a partitioned data storage device, with a size of 512 byte. After the BIOS has initialized all components it passes execution to the instructions contained in the MBR which will contain information for the bootstrap of the operating system. In a Trusted Computing (TC) capable system the MBR must be part of the Chain of Trust. 102

112 Glossary of Terms Memory Management Unit The Memory Management Unit (MMU) is a hardware component which is responsible for the handling of memory access requested by the CPU. The MMU translates virtual addresses to physical addresses and offers memory protection features. Message Authentication Code A Message Authentication Code (MAC) usually is a short piece of information used to authenticate a message. For the creation of MAC values different cryptographic primitives, such as hash functions or block cipher algorithms are used. P Personal Identification Number A Personal Identification Number (PIN) most often is a secret numeric password shared between a system and the user of that system introduced for the authentication of the user to the system. Platform Configuration Register The Platform Configuration Register (PCR) are a special memory region located in the volatile memory of a Trusted Platform Module (TPM), each with a size of 160 bit. These register store the hash values of special data blocks during boot process of the platform and therefore they can represent the state of the platform. Power On Self Test The BIOS Power On Self Test (POST) refers to routines, which run immediately after the power is applied to the system. The BIOS POST protects the bootstrapped code from being interrupted by faulty hardware components. Only if the POST completes successfully the bootstrap of the system will continue. R Root of Trust for Measurement The Root of Trust for Measurement (RTM) is one out of three Roots of Trust as defined by the Trusted Computing Group (TCG) needed for the creation of a Trusted Computing Platform (TCP). The Root of Trust for Measurement is the basic component for the integrity measurements and the creation of a Chain of Trust. This Root of Trust is realized by the Core Root of Trust for Measurement (CRTM) BIOS extension. 103

113 Glossary of Terms Root of Trust for Reporting The Root of Trust for Reporting (RTR) is one out of three Roots of Trust as defined by the Trusted Computing Group (TCG) needed for the creation of a Trusted Computing Platform (TCP). The Root of Trust for Reporting is responsible for the establishment of a platform identity and the protection of the transferred Platform Configuration Register (PCR) values during attestation of the system. This Root of Trust is realized by the Endorsement Key (EK) and corresponding certificates. Root of Trust for Storage The Root of Trust for Storage (RTS) is one out of three Roots of Trust as defined by the Trusted Computing Group (TCG) needed for the creation of a Trusted Computing Platform (TCP). The Root of Trust for Storage ensures that security critical data, such as keys, which have to be stored on an external storage device are bound to the platform first through encryption. This Root of Trust is realized by the Storage Root Key (SRK). S Secure Hash Algorithm The term Secure Hash Algorithm (SHA) describes a group of standardized cryptographic hash functions. These functions serve for the calculation of unique check sums of arbitrary electronic data and messages. As a requirement for secure hash algorithms it must be impractically to find two messages with the same hash value. Static Root of Trust for Measurement The Static Root of Trust for Measurement (SRTM) is a method for the establishment of a trusted boot sequence. The system starts booting from a immutable piece of firmware, i.e. the Core Root of Trust for Measurement (CRTM) BIOS extension, which initiates a measurement process, in which each component measures the next one in a chain, also called Chain of Trust. Storage Root Key The Storage Root Key (SRK) is an RSA key pair with a length of 2048 bit, which is created inside of the Trusted Platform Module (TPM) when the owner of the platform takes the ownership of the security module. The Storage Root Key forms the top of the TPM key hierarchy. Unlike the Endorsement Key (EK) the Storage Root Key can be changed an unlimited amount of times by first clearing the TPM and than taking ownership again. System Management Interrupt The System Management Interrupt (SMI) is used to enter the System Management Mode 104

114 Glossary of Terms (SMM), an operating mode of Intel architectures. The System Management Interrupts are disabled, while the processor executes in the System Management Mode. A SMI can be signalized through an external processor pin or through a special SMI message received by the CPU through the Advanced Programmable Interrupt Controller (APIC). System Management Mode The System Management Mode (SMM) is a basic operating mode of Intel architectures. Moreover the SMM mode is the most privileged CPU operation mode, which allows power-management features and other operating-system-independent functions. The processor will enter the System Management Mode if a System Management Interrupt (SMI) is triggered. The SMM mode is security critical and could be used as a attack vector if the attacker achieves to change the code of the System Management Mode. System Management RAM The System Management RAM (SMRAM) is a special memory region which contains the executable code of the System Management Mode (SMM), which will be executed when a System Management Interrupt (SMI) is initiated. The actual location of the SMRAM can be in a separate RAM memory or in the system memory. The SMRAM space is mapped to the physical address space and so a size up to 4 GBytes of memory can be addressed. System On a Chip The term System On a Chip (SOC) refers to an approach of integrating all required components for specific tasks of an electrical system or computer system into one single integrated circuit (IC). T Time To Market The term Time To Market (TTM) is used in commerce to express the length of time starting from a product being conceived until it is available for sale. True Random Number Generator A True Random Number Generator (TRNG) often also called hardware random number generator is a type of Random Number Generator (RNG), which can produce genuine random numbers as opposed to the Pseudo Random Number Generator (PRNG). True Random Number Generators often use noise generated by a resistor or a semi-conductor diode for the generation of statistically independent series of bits. 105

115 Glossary of Terms Trusted Computer System Evaluation Criteria The Trusted Computer System Evaluation Criteria (TCSEC) is a standard defined by the Department of Defense of the United States of America, which sets requirements for the effectiveness of important security controls built into a computer system. The TCSEC standard was used to evaluate, classify and select appropriate computer systems for the processing of sensitive information and has been superseded by the international standard Common Criteria for Information Technology Security Evaluation (CC). Trusted Computing Trusted Computing (TC) is a technology which has been developed and is promoted by the Trusted Computing Group (TCG). The main idea of this technology is the intention that a trusted computing capable computer will always behave in expected ways as defined by the platform manufacturer/owner. This behaviour will be enforced by both hardware and software components. In practice, a hardware element called Trusted Platform Module which features basic cryptographic functions and special protected capabilities is used as Trust Anchor for a security architecture. Trusted Computing Base The Trusted Computing Base (TCB) of a system is the set of all software/firmware and hardware components, which are critical to its security. This means that vulnerabilities or bugs inside the TCB could probably be used to compromise the whole system. Otherwise misbehaving parts outside of the Trusted Computing Base must not have an impact on the overall system security. Therefore the design point around the TCB is to keep it small and simple for high security levels. Commonly used operating systems for the x86 architecture have a very large Trusted Computing Base which makes it very hard to build a Trusted Computing System (TCS). Trusted Computing Group The Trusted Computing Group (TCG) is an industry consortium which develops open vendor-neutral industry standard specifications for trusted building blocks and software interfaces across multiple platforms. The TCG provides specifications for the design, evaluation and conformance testing of trusted computing platforms. The Trusted Computing Group defines the components necessary for the creation of a so called Trusted Computing Platform (TCP) one part of a Trusted Computing System (TCS). Trusted Computing Platform The Trusted Computing Platform (TCP) forms one part of a Trusted Computing System (TCS) and has been defined by the Trusted Computing Group (TCG). A Trusted Computing Platform consists of a Trusted Platform Module (TPM) and the Core Root of Trust for Measurement (CRTM) code. A TCP should offer special protected capabilities and 106

116 Glossary of Terms be able to record the state of the integrity of software and hardware components during boot process of a platform. Trusted Computing System The Trusted Computing System (TCS) is the overall goal of the Trusted Computing (TC) approach of the Trusted Computing Group (TCG). A Trusted Computing System should always behave in a pre-defined way and should withstand sophisticated software-based and hardware-based attacks. A TCS basically consists of a Trusted Computing Platform (TCP) and a Trusted Operating System (TOS) with trustworthy services and applications. Trusted Operating System The Trusted Operating System (TOS) is an essential part of a Trusted Computing System (TCS). Compared to the Trusted Computing Platform (TCP), which has been clearly specified by the Trusted Computing Group (TCG), there are no clear definitions or specifications for the creation of a TOS. In general a TOS can be figured as a combination of a trustworthy kernel, services and applications. Trusted Platform Module The Trusted Platform Module (TPM) is a cryptographic hardware chip which is tied to a platform and whose basic functionality and structure has been specified by the Trusted Computing Group (TCG). The TPM is one part of a Trusted Computing Platform (TCP) and offers special protected capabilities such as the Platform Configuration Register (PCR) which can be used for remote attestation and sealed storage purposes. The TPM module forms a Trust Anchor for a security architecture. Trusted Software Stack The Trusted Software Stack (TSS) provides an interface to the Trusted Platform Module (TPM), which can be used by Trusted Computing (TC) capable applications in order to communicate with the TPM. The basic structure of the Trusted Software Stack has been specified by the Trusted Computing Group (TCG). A TSS consists of multiple abstraction layers. Trusted Third Party The term Trusted Third Party (TTP) describes an entity which enables interactions between two parties who both trust the third party. In practice the relying parties use this trust to secure own interactions. Trusted Third Parties are often applied in cryptographic protocols, for example, a Certification Authority (CA) acts like a Trusted Third Party issuing digital certificates. 107

117 A. IEEE Applied Electronics International Conference 2010 Pilzen Some of the findings of this research project have been presented at the IEEE Applied Electronics International Conference in Pilzen (CZ) in September 2010 titled as follows: Schramm M., Grzemba A.; "The Benefits of Combining Trusted Computing with Virtualization Techniques"; Applied Electronics International Conference, Pilzen, September This paper describes an approach towards a trustworthy operating system based on a Trusted Platform specified by the Trusted Computing Group (TCG) by using virtualization techniques and modern processor hardware virtualization enhancements. The full paper is provided on the following pages. I

118 A. IEEE Applied Electronics International Conference 2010 Pilzen The Benefits of combining Trusted Computing with Virtualization Techniques Martin Schramm, B.Eng. University of Applied Sciences Deggendorf Deggendorf, Germany Prof. Dr.-Ing. Andreas Grzemba University of Applied Sciences Deggendorf Deggendorf, Germany Abstract Within the last few years attacks against IT systems have reached an alarming number. Since these systems are applied in more and more application fields the arising financial damage is tremendous. The Trusted Computing (TC) approach of the Trusted Computing Group (TCG) should ensure that a system is permanently in a well-defined and trustworthy state. However the TCG only defines the components necessary for a Trusted Computing Platform (TCP) which provides the functionality to measure the integrity of the system during boot process. These integrity measurements must be sustained during runtime of an operating system in order to make qualitative statements of the system state. Common operating systems are far to complex which makes a complete measurement of all security critical files quite impossible. This paper presents an approach towards a security architecture by using virtualization technologies as well as security enhancements of modern processor architectures for hardening an operating system on top of a TCP. I. INTRODUCTION The TCG [1] is a non-profit organization that defines open standards for TC technologies. The main component of the TCG approach is a hardware chip named Trusted Platform Module (TPM) [2] which is attached to the motherboard of the machine connected via LPC bus or directly integrated in the southbridge of the chip set. This chip offers cryptographic functions and engines for encryption/decryption, calculation and verification of digital signatures as well as the capacity for the creation of hash values and true random numbers. Each TPM contains several special purpose cryptographic keys. The unique Endorsement Key (EK) represents the identity of the platform. Each TPM manufacturer has to provide a certificate to the EK attesting the compliance of the TPM to the specifications. The Storage Root Key (SRK) always resides in the nonvolatile memory of the TPM and forms the top of the TPM key hierarchy. This means, that each new created key has to be encrypted (wrapped) either by the SRK or another key of the hierarchy. Attestation Identity Keys (AIKs) are created by the TPM and linked to the platform using certificates from the EK. AIKs are used for attestation purposes. The functionality of the TPM is often compared to the operating mode of a high-end smart card. However there are some major differences among the two technologies. First of all a smart card authenticates a specific person whereas a TPM module authenticates a particular platform. Furthermore the TPM contains a set of special register in the versatile memory the socalled Platform Configuration Register (PCR). A TPM version compliant to the TCG TPM Main Specification Version 1.2 must offer a minimum number of 24 PCRs. These register store the hash values of security critical data using integrity measurements. This approach relies on three Roots of Trust two of them anchored in the TPM and one implemented as BIOS extension. Based on these Roots of Trust a Chain of Trust should be established. The Core Root of Trust for Measurement (CRTM) starts this chain by measuring the integrity of the next component, i.e. the BIOS, before executing it. With alternating measurement and execution flows a continuous chain should be established. The TCG only defines the static chain of trust during the boot process of the platform whereas the dynamic chain of trust is part of a Trusted Operating System (TOS). There are no precise specifications of how a dynamic chain of trust should be implemented but is is crucial that the chain is continued during runtime in order to make meaningful conclusions about the trustworthiness of the current state during attestation process. A security architecture should be based on a small Trusted Computing Base (TCB). The TCB is the set of all software, firmware and hardware components that are critical to the security of a system. If one of the components gets compromised the whole system is not trustworthy any longer. Otherwise if a component outside of the TCB gets compromised than this must not have an impact on the trustworthiness. The correctness of a small TCB can easier be assured or verified. The security of a computer system does not only depend on the software running on it but also on the security features provided by hardware. The x86 architecture is based on CPU protection rings. Usually four rings with different privilege levels, ring 0 (most privileged) up to 3 (least privileged) are defined. Special gates regulate the access of a underprivileged ring to the resources of a more privileged one. Due to performance and user convenience reasons common x86 operating systems are only using two of the four rings. The applications are located in ring 3 also called user mode whereas the kernel the OS services and the device drivers have to share ring 0 known as kernel mode and the remaining rings are unused. So each II

119 A. IEEE Applied Electronics International Conference 2010 Pilzen driver has full access to the resources of the system. This makes complete integrity measurements of all critical components far to complex. Figure 1 gives an overview of the CPU privilege rings. Fig. 1. CPU privilege rings TC requires a simple architecture. Virtualization techniques can solve this problem and ensure that the conventional and established operating systems can be used in a security architecture for TC purposes. According to [3] a Virtual Machine Monitor (VMM) is the smallest and simplest system to provide secure isolation for a security architecture based on small components. Adding virtualization brings attractive benefits like flexibility, simplicity and compatibility. With virtualization an abstraction layer namely the VMM is added between the bare hardware and the operating system. On paravirtualized systems the VMM is located in ring 0 and displaces the kernel in ring 1 to be the more privileged one. The VMM controls the underlying hardware and allocates the available resources like CPU-time memory and network bandwidth to the particular Virtual Machine (VM). Commonly the VMM is called the host and the VMs are termed as guests. The individual VMs are isolated from each other and have no knowledge of the others. Although VMM has not been developed as a security architecture special modifications can provide supplemental security properties. Figure 2 shows the relationship between the VMM and the VMs. Fig. 2. Virtualization Architecture In addition the processor and chip-set manufacturers have developed extensions for their products which can be used for TC purposes. Intel [4] and AMD [5] have added virtualization support to their processor architectures. These enhancements enable the virtualization of operating systems without the necessity of kernel modifications for instance by adding a new CPU ring -1 with a higher privilege level than ring 0. This is not only of interest in the server market where the execution of multiple commodity operating systems should be supported on a single machine but also in the client area where there is a need to completely increase system security and reliability. However the TPM is not designed to be used in virtual environments due to the fact that the TPM was meant to represent the identity of a single platform. Berger et al [6] propose to virtualize the hardware TPM so that each VM can be equipped with its own instance of virtual TPM (vtpm). Especially for the scope of TC processor manufacturers have added particular enhancements for modern processor architectures. ARM has developed a technology called TrustZone [7] which can take advantage of the functions offered by the TPM. Intel and AMD have introduced the Trusted Execution Technology (TXT) [8] and the Secure Execution Mode (SEM) [9], respectively. Both architectures extend the processor instruction set with additional commands that can directly communicate with the TPM. In addition these new instructions work hand in hand with the virtualization extensions. With this new instruction set it is possible to implement a Trusted VMM (TVMM) which permits a measured start of VMs. II. SECURITY ARCHITECTURE One of the design criteria for the proposed security architecture was to enable that common operating systems can be used within this architecture. Most users became accustomed to their favorite operating system and are not willing to give up ease of use for a higher level of security. Manufacturers of computer systems are also often not prepared to change the structure of their products. This section presents a proposal for a hypervisor-based approach towards a TOS on top of the TCP defined by the TCG. A. Types of VMM implementation Basically there are two different types of VMM implementation. In the first solution the VMM is running in a so-called host operating system. Better capable for the application in the field of TC is the second type in which the VMM is running on top of the bare hardware. This way it can be guaranteed that the individual VMs can only get access to the specified resources controlled by the hypervisor software. Furthermore virtualization can occur in different grades. Paravirtualized systems have to be modified in order to run in another CPU ring than ring 0 and this only has small performance influences of about 2-4 %. The open-source hypervisor Xen [10] has paravirtualization ability. With support of the virtualization processor extensions from Intel or AMD [4], [5] the guest operating systems don t have to be modified which enables the virtualization of operating systems whose kernel sources are closed. This is called hardware basedvirtualization. Both Xen and KVM [11] are capable of hardware-based virtualization and take advantage of a III

120 A. IEEE Applied Electronics International Conference 2010 Pilzen modified version of QEMU [12] for the emulation of I/O Devices. B. System Description Figure 3 shows the basic architecture of the proposed security system. Fig. 3. TVMM based security architecture The architecture is built up on top of the TCP of the TCG which consists of a hardware TPM and a TCG compliant BIOS. The TCP is responsible for the static chain of trust and the involved integrity measurements. To continue the chain from the MBR TrustedGRUB [13] can be used. TrustedGRUB is an enhancement of the open-source bootloader GNU GRUB with the capability of continuing the static chain of trust by filling the gap between MRB and running operating system. TrustedGRUB also supports Xen [10]. A TVMM e.g. Xen or KVM handles the access of the individual VMs to the platform s hardware and takes care of the required isolation of the VMs. Intel TXT [8] enables the measured start of the VMM and stores the hash values in PCR 17 and 18. Therefore the open source pre-kernel/vmm module Trusted Boot [14] can be used. Trusted Boot enables the verified launch of operating system kernels or VMM. Especially in Xen one particular VM is used as management VM. It is the first VM booting after the TVMM. This VM is part of the TCB and should be held as small as possible to minimize the risk of compromising. It is responsible for management functions like creation termination etc. of VMs. Additionally the management VM contains a vtpm Manager [6] which controls the vtpm instances for running VMs and binds them to the hardware TPM. Each vtpm instance performs a full set of the TCG TPM Main Specification [2], thus allowing each VM to use the vtpm instances as if the VM had a direct control over the physical TPM chip. By generating an EK per vtpm, this architecture allows each vtpm, and hence each VM that uses the instance to decrypt information using the private key associated with the EK. It also enables the creation of an independent key hierarchy per vtpm. The PCR values of the static chain of trust can be mapped from the hardware TPM to the register of the vtpm instances. In this architecture besides the management VM two different VMs are used. The Common VM can be running common operating systems like Linux distributions or Windows versions. Intel VT [4] enables hardware-based virtualization. The Common VM is not part of the TCB and therefore can run all common but untrusted or untrustworthy applications like the Internet browser. The Secure VM may only contain security critical applications and that which should be isolated by the common ones. Because of its structure and contents the Secure VM on the whole is part of the TCB. For this reason the operating system of the Secure VM should be held as small as possible and built with least necessary support components. For example this could be a version of ttylinux [15]. This Linux system can be reduced to just a few megabytes of code even though it provides a complete command line environment and is ready for Internet access as well. Another possible approach for the Secure VM is the implementation of Integrity Measurement Architecture (IMA) [16] in a Linux distribution. IMA is a software architecture and implementation for Linux that provides verifiable evidence regarding the current runtime of a measured system. IMA maintains a list of hash values covering all executable content loaded into a Linux system run-time since the start of the system. IMA usually was not defined to be used in virtualized systems. However because the vtpms [6] virtualize the hardware TPM the IMA can be ported to VMs to provide integrity measurements. To enable the applications of the VMs to take advantage of the vtpms a Trusted Software Stack (TSS) [17] is required. The TSS is specified by the TCG. For Linux systems the open-source TCG Software Stack TrouSerS [18] which is compliant to the specification of the TCG can be used. III. CONCLUSION AND FUTURE WORK Fig. 4. Components of a Trusted Computing System The TC technology offers an innovative approach and building blocks for the creation of security architectures. The TCG only defines the components necessary for a TCP. IV

121 A. IEEE Applied Electronics International Conference 2010 Pilzen In this paper, we presented a hypervisor-based security architecture as an approach towards a TOS on top of the TCP defined by the TCG. A Trusted Computing System (TCS) consists of a TCP and a TOS with trusted services and trusted applications (see figure 4). A TOS could also be based on a microkernel architecture but a VMM is found to be simpler in construction by the developers, more acceptable by the users and more profitable by the manufacturers than a microkernel approach. A measured TVMM enforces an isolation policy to separate security critical applications from untrusted and untrustworthy components. A Secure VM with specific security mechanisms runs the critical applications in a closed and simple environment. So attacks against the Common VM cannot cause leaking of secrets. Another great benefit of virtualization has not been mentioned yet. With virtualization it is possible to make snapshots of a specific system state. This way if a component of the Common VM gets compromised a prior state definitely known as trustworthy can easily be restored. For architectures which are based on a chain of trust it is very important that this chain is consistently without leaving any gaps. The dynamic chain of trust hinders the possibility of Time-of-check-to-time-of-use (TOCTTOU) attacks due to the fact that the integrity measurement values can report the current state of the system and not only the state the system had during boot process. The TPM stores the integrity measurement data of the TVMM and the VMs. The contents of the PCRs are mapped to the vtpm instances which contain further measurement data. These can be used for attestation purposes so that other entities can trust the system. The following work will focus on implementing a prototype of the security architecture and defining the most convenient type of virtualizaton as well as VMM, operating systems and appropriate software for integrity measurements. Also special application fields for specific implementations of the security architecture should be considered. One fact about the concept of TC often gets disregarded. The measured integrity values representing the sate of the platform have to be verified by a remote party. Platform attestation with the verifying component as part of the same system forms a problem which should not be underestimated. If the system gets compromised one can not exclude that the verifying component also has been modified. Efficient approaches for Remote Attestation have to be planed. In this context the pros of the combination of the security architecture with further security technologies like smart card, token, biometrics and others should be investigated. REFERENCES [1] Trusted Computing Group; application fields; (Access: March 2010) [2] Trusted Computing Group; TPM Main Specification Level 2; Version 1.2, Revision 103; 9 th July 2007; Available at: main specification [3] M. Hohmuth, M. Peter, H. Haerting, J. S. Shaprio: Reducing TCB size by using untrusted components - small kernels versus virtual-machine monitors ; 11th ACM SIGOPS European Workshop, Leuven, Belgium, 2004; Available at: ps/reducingtcb.pdf [4] Intel Virtualization Technology; Intel Virtualization Technology for Directed I/O - Architecture Specification ; Revision 1.2; September 2008; Available at: ftp://download.intel.com/technology/computing/vptech/intel% 28r%29 VT for Direct IO.pdf [5] AMD Virtualization; AMD-V Nested Paging ; Revision 1.0; July 2008; Available at: NPT-WP-1%201-final-TM.pdf [6] virtual TPM; S. Berger, R. Cáceres, K. A. Goldman, R. Perez, R. Sailer and L. van Doorn: vtpm: virtualizing the trusted platform module ; Proceedings of the 15th conference on USENIX Security Symposium; Berkeley, CA, USA: USENIX Association, 2006; [7] ARM TrustZone; ARM Security Technology: Building A Secure System Using TrustZone Technology ; April 2009; Available at: doc.prd29-genc c/prd29-genc c trustzone security whitepaper.pdf [8] Intel Trusted Execution Technology; Intel Trusted Execution Technology Software Development Guide ; December 2009; Available at: downloads/ pdf [9] AMD Secure Execution Mode; AMDs Vision for Trustworthy Computing ; October 2004; Available at: digitalidworld.com/2004/attendees/slides/ E1.pdf [10] Xen hypervisor; P. Barham, B. Dragovic, K. Fracer, S. Hand, T. Harris, A. Ho, R. Neugebauery, I. Pratt, A. Warfield: Xen and the Art of Virtualization ; Proceedings of the 19th Symposium on Operating Systems; Bolton: ACM Press, 2003: ; [11] Kernel-based Virtual Machine; Available at: http: // Page (Access: March 2010) [12] QEMU, the open source processor emulator; Available at: (Access: March 2010) [13] TrustedGRUB, TC version of GRUB bootloader; Available at: (Access: March 2010) [14] tboot; J. Cihula: Trusted Boot - Verifying the Xen Launch ; Xen Summit; Intel Corp.; Fall 2007; Available at: fall07/23 JosephCihula.pdf [15] ttylinux; ttylinux User Guide ; 21 st March 2010; Available at: Guide.pdf [16] IMA, integrity measurement architecture; R. Sailer, X. Zhang, T. Jaeger, L. van Doorn: Design and Implementation of a TCG-based Integrity Measurement Architecture ; Proceedings of the 13th conference on USENIX Security Symposium; Berkeley, CA, USA: USENIX Association, 2004; [17] Trusted Computing Group; TCG Software Stack (TSS) Specification; Version 1.2; 7 th March 2007; Available at: stack/specifications [18] TrouSerS, open-source TCG Software Stack; M. Selhorst, C. Stble, F. Teerkorn: TSS Study - Open Source TCG Software Stack TrouSerS and Tools in its Environment ; May 2008; V

122 B. IEEE Applied Electronics International Conference 2011 Pilzen An IEEE conference paper has been submitted to the IEEE Applied Electronics International Conference in Pilzen in March 2011, describing further results of the research work, as follows: Schramm M., Grzemba A.; "Trustworthy Building Blocks for a More Secure Embedded Computing Environment"; Submitted to the Applied Electronics International Conference in March This paper depicts the necessary components for the creation of a trusted operating system. The concept of implementing a set of trustworthy building blocks for the creation of an effective security architecture based on the Trusted Platform Module in hardware is described in this paper. The full proposed paper is provided on the following pages. VI

123 B. IEEE Applied Electronics International Conference 2011 Pilzen Trustworthy Building Blocks for a more secure embedded computing environment Martin Schramm, B.Eng. University of Applied Sciences Deggendorf Deggendorf, Germany [email protected] Prof. Dr.-Ing. Andreas Grzemba University of Applied Sciences Deggendorf Deggendorf, Germany [email protected] Abstract It is amazing how accustomed we have grown to the ubiquitous threats in our every day computing lives. By now the design flaws in hardware components, as well as software applications and operating systems, are well known and can easily be exploited if an injection vector is found. Furthermore, there is a movement in the embedded sector to shift away from proprietary software and hardware components to the wellestablished x86 architecture and to employ commonly used operating systems such as Windows or Linux. In addition attacks against IT systems are becoming more sophisticated and pure software-based solutions cannot guarantee lifetime integrity anymore. To improve on this situation, it is necessary to anchor additional hardwarebased security modules as an integral part of a platform. Today s systems have a requirement for a high level of dependability, offering both safety and security features. In this paper we propose an efficient hardware-based security architecture utilizing Trusted Computing (TC) techniques based on trustworthy building blocks. A key focus of the work is the development of a hypervisorbased security architecture which utilizes a state-of-theart hardware trust anchor to increase the security and trustworthiness of commonly used operating systems in the embedded x86 sector. I. INTRODUCTION Recent statistics [1] on computer security breaches demonstrate that there has been an explosive growth of successful computer attacks worldwide. The platform designer has to take into account all possible security considerations for each and every implemented component, but an attacker has only to find one injection vector in order to run malicious code that will eventually compromise the whole system. A security solution is only as strong as its weakest link. Today, designers often chose standardized hardware and software components, to meet increasing complexity demands and to support a greater functional range of system requirements. For instance the Intel R Atom processors are gaining more and more ground in the embedded sector, being employed in application fields such as mobile radio communication, automotive industry, railroad engineering, avionics, medical engineering, industrial automation and more [2]. The ongoing advantages of the embedded x86 architecture are well understood and include a comprehensive development process, decreased power consumption, reduction of costs, and the possibility to use common operating systems. However, the use of standard hardware as well as standard operating system structures can imply serious security concerns because of the well-known shortcomings of the deployed components [3]. The recent appearance of malware in the specialist application field of industrial automation has led to an increased awareness of the urgent potential threats in embedded computing environments. The compounded effects of compromising the security and privacy of embedded systems have impacts on: Risk Management, Asset Management, Monitoring & Response as well as Connectivity considerations. Connectivity provides inherent benefits such as increased flexibility through remote management of multiple platforms, but the increased dependence on electronic networks further heightens the urgency for hardware-based protection of information, authentication of users, and the establishment of high degrees of trust in local and remote computing systems. II. REQUIREMENTS FOR A TRUSTWORTHY SYSTEM When defining system integrity two individual goals have to be pursued in order to build a so called Trusted System. A Trusted System implies the understanding that the system will always behave as intended, and two important goals in this regard can be listed: Hardware Integrity and Image Integrity. These two goals should ensure that the hardware configuration cannot be altered without authorization, and that the software and data cannot be modified without authorization. In other words a Trusted Computing System (TCS) consists of a Trusted Computing Platform (TCP) as well as a Trusted Operating System (TOS). A platform must contain a set of key attributes in order to be trustworthy, as follows: Integrity Measurements Logging & Reporting Protected Capabilities Attestation In order to create a protocol that be relied upon to properly relate to the executable software of a system it is very important to clearly identify these attributes. The platform must have the ability to record metrics of its characteristics. One way to achieve this might be the creation of unique checksums using hash functions. It is very important that such integrity values are stored in a tamper resistant memory region. Additionally the system must provide special secured interfaces for the readout of such integrity values. Reporting is a process VII

124 B. IEEE Applied Electronics International Conference 2011 Pilzen to record and report a platform s status in a secure way using cryptographic protocols. The term protected capabilities describes a set of commands such that their correct execution must not depend on the integrity of the system. They can have exclusive permissions to access shielded locations and will be safe to operate on sensitive data. Such features imply the inclusion of a secure storage region for arbitrary data, mechanisms for the creation of true random numbers, cryptographic algorithms and keys, key management functions, as well as the capability for binding and sealing data to a platform and its current state. A process of vouching for the accuracy of information is called attestation. Attestation can be classified into local and remote attestation and three different goals can be archived with attestation: 1) attest to the platform, 2) attestation of the platform and 3) authentication of the platform. Attestation is the process of providing integrity measurements and is used to determine a platform s current configuration. In the following sections the individual requirements for our specific approach are described in detail. A. Secure Boot / Trusted Boot In practice, the bootstrap process begins at power up. The microprocessor most often begins executing instructions at a specific memory location in a readonly memory device. This process usually includes a hardware diagnostic test, followed by loading the first sector of a disk into memory, and then continues executing the instructions it finds there. In a secure bootstrap it must be assured that only the intended components can be launched in a predefined order with a predefined configuration. Failure at any point results in notifying the user or even in a system shutdown. A secure bootstrap cannot be archived solely with software components. If the boot process can be manipulated it cannot be assured that the verifying component has not been tampered with. In order to avoid this situation, a piece of hardware can be introduced which guarantees the integrity of the boot process by alternating measurement and execution flows. This way a continuous Chain of Trust can be established (see figure 1). Fig. 1. Chain of Trust B. Secure Memory Management A secure memory management scheme is a very important and critical Building Block for a security architecture. Memory management becomes a possible attack avenue when an attacker creates a buffer overflow, which then can allow execution of attack code. A buffer overflow is an anomaly where a program, while writing data to a buffer, overruns the buffer s boundary and overwrites adjacent memory. This can be accomplished by intentionally exceeding the bounds of allocated memory for arrays and variables, or through the use of memory pointers. Although there are techniques to avoid such flaws the vulnerabilities are still omnipresent and these types of attacks are very common and highly effective [4]. Direct Memory Access (DMA) is a feature of modern computers and microprocessors that allows certain hardware subsystems within the computer to access system memory for reading and/or writing across the bus independently of the CPU. The design goal of DMA was to allow fast memory access to devices. The problem regarding security is that DMA allows a peripheral device to directly access system memory without any involvement of the CPU. In this type of attack the contents of RAM are scoured for valuable information such as encryption keys or passwords [5]. System Management Mode (SMM) is the most privileged CPU operation mode on Intel architectures and facilitates power-management features and other operating-system-independent functions. It resides in a protected region of memory called System Management RAM. A System Management Interrupt (SMI) is used to enter SMM mode. Over time, several possible attacks based in the SMM violation [6] have been demonstrated, such as poisoning the cache of the CPU in order to run arbitrary code with maximum privileges, while remaining invisible to the operating system and applications. C. Trustworthy Software Components Pure software-based security approaches cannot guarantee long-term system integrity anymore [7]. Still, hardware-based solutions need a Trusted Operating System with trustworthy services and applications. Commonly used operating systems have many benefits, such as ease-of-use and a cost-reduced rapid development process, and provides the opportunity to reuse software components. However, regarding system security, these operating systems are far too complex, and thus gives rise to issues which hinder the design of effective security solutions. D. Trusted Input/Output Another important Building Block is the need for Trusted Input/Output for securing peripheral devices. This includes two elements: firstly, a Trusted Channel [8] for data input and output which provides integrity, confidentiality and authenticity for the transmitted data, and secondly the assurance of integrity and authenticity of the end points. The counterpart to Trusted Channels is called a Trusted Path [9]. This is usually a visual sign which should assure users that they are working with a trustworthy program or system. To archive this goal both soft- and hardware modifications are necessary. VIII

125 B. IEEE Applied Electronics International Conference 2011 Pilzen The intelligent combination of diverse trustworthy building blocks can help in defining effective security architectures. III. BUILDING BLOCK APPROACH The key focus of this work is the development of a hypervisor-based security architecture which utilizes a state-of-the-art hardware trust anchor in order to increase the security and trustworthiness of commonly used operating systems in the embedded x86 sector. Unlike security by obscurity [10] which does not realize a trusted solution, this work proposes a defense by adding multiple layers of security, also called defense in depth, which will have significant potential to work effectively. It is understood that the more security layers which must be overcome before a hacker can gain access to critical information, the more difficult the execution of a successful attack becomes. Figure 2 shows the hardware reference architecture of our proposed security architecture. B. Trusted Platform Module The Trusted Computing Group (TCG) [17] developed specifications for a special hardware security module called the Trusted Platform Module [4]. This can be implemented in a chip which is tamper-resistant as well as tamper-evident and it typically resides on the motherboard of the platform. The TPM offers cryptographic functions, a secure input/output system, as well as a secure memory. Figure 3 illustrates the internal structure of a TPM chip. Fig. 3. Internal structure of a TPM chip Fig. 2. Hardware structure of the Proof of Concept System In the proof of concept system a virtualization layer, basically a type I bare metal hypervisor [11], controls the access to the resources of the system and adds security by isolating whole operating systems or applications. A Trusted Platform Module (TPM) [12] serves as a hardware Trust Anchor. Here special CPU and chipset extensions, such as hardware virtualization support (Intel R VT-x [13], Intel R VT-d [14]), and Trusted Computing features (Intel R TXT [15]) are employed to add additional trust. The following sections give an overview of the individual components of the proposed security architecture. A. Cryptography Cryptography resides at the core of any security system. This is often the first element that comes into mind when planning computer security. The basic goals of cryptography are: confidentiality, integrity, non-repudiation and authentication. The creation and distribution of keys are critical issues of a secure system and failure to perform this task well can determine the ultimate security of the system [16]. The TPM features some special capabilities as it contains the so called Platform Configuration Register (PCR) in the versatile memory region. These registers store the hash values of security-critical data using integrity measurements (see table I). These values can be used for sealing purposes, for example. Sealing is a process where data is not only encrypted to a particular platform but also to a specific state of that platform. Furthermore, the TPM chip serves as a Trust Anchor in which Roots of Trust permit the creation of a Chain of Trust. TABLE I PCR USAGE PCR: PCR usage: 0 CRTM, BIOS and Platform Extensions 1 Platform Configuration 2 Option ROM Code 3 Option ROM Configuration and Data 4 IPL Code (usually the MBR) 5 IPL Configuration and Data (for use by the IPL Code) 6 State Transition and Wake Events 7 Host Platform Manufacturer Control 8-15 Defined for use by the Static Operating System 16 Debug Defined for use by the Dynamic Operating System C. Trusted Execution Technology Intel has launched a secure computing initiative which is now code named Trusted execution Technology (TXT) [15]. The TXT system seeks to close the attack vectors that existed in previous systems using hardware-based security from the boot phase. Goals of the TXT technology are to realize a secure boot process and application launch, as well as the IX

126 B. IEEE Applied Electronics International Conference 2011 Pilzen shielding of encryption keys and whole memory regions. A TXT-enabled system makes excessive use of the Trusted Platform Module and features a so-called Dynamic Root of Trust for Measurement (DRTM) which allows the startup of a Measured Launched Environment (MLE) [18]. Whereas the Static Root of Trust for Measurement (SRTM) always starts at power up of the platform, the DRTM can basically start at any time during the runtime of the system. Special Launch Control Policies [19] and Verified Launch Policies make sure that the individual components can only be booted with a well-known configuration in a previously defined order. Manipulation attempts will result in the notification the user or even in a system shutdown. Sealed data can only be recovered again if the system is in the same trustworthy state as it was in during the encryption process. This represents an effective protection from software-based attacks. The open source pre-kernel/vmm project tboot [20] is an example for such a measured launched environment. D. Virtualization Technology Virtualization technology, which was intended for consolidation and the reduction of costs, is gaining more and more interest for its use in security critical application fields. The security level of a virtualized system benefits from the isolation ability of that technology. Individually partitioned and separated parts have no knowledge of each other, have their own resources allocated by the virtualization software layer, and they cannot break out of their assigned areas. Intel R VT-x [13] is the technology for CPU virtualization on the x86 platform. Besides the benefits of the performance boost of hardware-based virtualization support, it also enables the virtualization of unmodified operating systems, such as the Windows systems, by adding a new CPU Ring -1 where the Hypervisor becomes the most privileged one. Intel Virtualization Technology for directed I/O (Intel R VT-d) [14] features an Input/Output Memory Management Unit (IOMMU) which enables guests to directly use peripheral devices through DMA interrupt remapping, working towards mitigating the risk of DMA attacks. IV. CONCLUSION AND FUTURE WORK By combining the trustworthy Building Blocks presented in this paper, a proposed security solution will offer sophisticated protection against software-based attacks. However, one has to keep in mind that such a solution cannot offer full prevention against all sophisticated hardware-based attacks. The impact on performance for a system by introducing security solutions has always been an issue with applications, operating systems, and other information technology infrastructures, which leads to limitations in systems. The security and virtualization enhancements from Intel can mitigate against such limitations by reducing the performance overhead. Increased security features inevitably have an impact on user convenience. Thus a compromise between the security features and usability has to be found. The goal of a building block approach is to increase the security and trustworthiness of the platform by providing easy-to-use management tools for creating application-specific security policies. The proposed approach focuses on adding trust to the platform itself. The next steps will include setting up a small network of trustworthy platforms and investigate how the individual systems can add trust to each node as well as to the network and to evaluate which additional components will be necessary for the creation of a trustable network. Further work will develop theoretical models of the security strategies and will develop risk assessments and proofs. REFERENCES [1] Fahmida Y. Rashid, Study: Cybercrime hits two-thirds Internet users study-cybercrime-hits-two-thirds-internet-users/ (Access: March 2011) [2] Intel Atom processors for embedded computing download. intel.com/embedded/processors/prodbrief/ pdf (Access: March 2011) [3] Martin Schramm and Andreas Grzemba, The Benefits of combining Trusted Computing with Virtualization Techniques, Applied Electronics International Conference, 2010 [4] Crispin Cowan et al., Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade, System Administration and Network Security, 2000 [5] Joanna Rutkowska and Rafal Wojtczuk, Detecting & Preventing the Xen Hypervisor Subversions, Black Hat USA, 2008 [6] Joanna Rutkowska and Rafal Wojtczuk, Attacking SMM Memory via Intel CPU Cache Poisoning, 2009 [7] Roger R. Dube, Hardware-Based Computer Security Techniques to Defeat Hackers - From Biometrics to Quantum Cryptography, Wiley, 2008 [8] David Grawrock, Dynamics of a Trusted Platform: A Building Block Approach, Intel Press, 2008 [9] Shi Wenchang, Implementing operating system support for extended trusted path in TPM-capable environments, Springer Link, 2006 [10] Rebecca T. Mercuri and Peter G. Neumann, Security by Obscurity, COMMUNICATIONS OF THE ACM, 2003 [11] Xen hypervisor; P. Barham, B. Dragovic, K. Fracer, S. Hand, T. Harris, A. Ho, R. Neugebauery, I. Pratt, A. Warfield: Xen and the Art of Virtualization ; Proceedings of the 19th Symposium on Operating Systems; Bolton: ACM Press, 2003: ; [12] Trusted Computing Group; TPM Main Specification Level 2; Version 1.2, Revision 103; 9 th July 2007; Available at: main specification [13] Intel Vanderpool Technology for IA-32 Processors (VT-x) Preliminary Specification, 2005 [14] Intel Virtualization Technology; Intel Virtualization Technology for Directed I/O - Architecture Specification ; Revision 1.2; September 2008; Available at: ftp://download.intel.com/technology/computing/vptech/intel% 28r%29 VT for Direct IO.pdf [15] Intel Trusted Execution Technology, Preliminary Architecture Specification, 2007 [16] Bruce W. Schneier, Applied Cryptography, Wiley, 1996 [17] Trusted Computing Group; application fields; trustedcomputinggroup.org/developers (Access: March 2011) [18] Intel - Measured Launched Environment; Intel Trusted Execution Technology Measured Launched Environment Developer s Guide ; December 2009; Available at: com/technology/security/downloads/ pdf [19] Intel - Launch Control Policy; Intel Trusted Execution Technology Launch Control Policy Linux Tools User Manual ; November 2007; Available at: tboot/files/tboot/ [20] J. Cihula: Trusted Boot - Verifying the Xen Launch ; Xen Summit; Intel Corp.; Fall 2007; Available at: files/xensummit fall07/23 JosephCihula.pdf X

127 C. Embedded World International Conference 2011 Nuremberg Following paper has been presented at the Embedded World International Conference in Nuremberg (GER): Schramm M., Grzemba A., Heffernan D.; "Utilizing a State-of-the-art Trust Anchor in Order to Increase the Trustworthiness of Embedded Platforms"; Embedded World International Conference 2011, Nuremberg, March This paper points out the shortcomings of the x86 architecture regarding system security and explains why the commonly used operating systems are quite insecure. It furthermore describes the benefits of hardware-based security modules in comparison to pure software-based security solutions. After defining important components for a more secure architecture the specific implementation in the proposed solution is stated. The final paper can be found on the following pages. XI

128 C. Embedded World International Conference 2011 Nuremberg Utilizing state-of-the-art Trust Anchor in order to increase the trustworthiness of embedded platforms Martin Schramm, B.Eng. University of Applied Sciences Deggendorf Deggendorf, Germany Prof. Dr.-Ing. Andreas Grzemba University of Applied Sciences Deggendorf Deggendorf, Germany Dr. Donal Heffernan University of Limerick Limerick, Ireland Abstract Within recent years the number of embedded systems has been constantly increasing. Additionally these systems are being applied in more and more specialist application fields. On that account attacks against IT systems can cause tremendous financial damage, and other problems. For this reason there is a need for a trustworthy platform with a high-level of dependability offering both safety and security features. The security characteristics do not only include protection from hardware manipulations but also depend on the deployed operating system and software. Originally the x86 architecture was designed with a set of different privilege levels. However, due to performance reasons only two of these levels are used today. Also the commonly used operating systems are macro-kernel based, which causes additional security weaknesses. Regardless of this, most companies need to continue using popular operating systems. To improve on this situation, it is necessary to develop additional security elements, both hardware- and software-based. It is suggested that systems can be additionally hardened considering a combination of: 1) the isolation ability of virtualization techniques and 2) hardware-based security features, such as special processor extensions and/or Trusted Platform Modules. The Trusted Computing (TC) approach of the Trusted Computing Group (TCG) should ensure that a system is permanently in a well-defined and trustworthy state. However the TCG only defines the components necessary for a Trusted Computing Platform (TCP) which provides the functionality to measure the integrity of the system during the boot process. These integrity measurements must be sustained during runtime of an operating system in order to make qualitative statements about the system state. This paper presents an approach towards a security architecture by using virtualization technologies as well as the security enhancements of modern processor architectures for hardening an operating system on top of a TCP. TABLE OF CONTENTS: I INTRODUCTION II OVERVIEW ON TRUSTWORTHY COMPUTING III HARDWARE-BASED SECURITY TECHNIQUES VERSUS SOFTWARE SOLUTIONS III-A Secure Bootstrap Loading III-B Secure Memory Management and Trusted Execution Technology III-C The Trusted Platform Module III-D Token, FPGA and further techniques III-E Trustworthy Software Components IV PROOF OF CONCEPT SYSTEM V CONCLUSION REFERENCES XII

129 C. Embedded World International Conference 2011 Nuremberg I. INTRODUCTION Within the last few years attacks against IT systems have reached an alarming number. Since these systems are applied in more and more application fields the arising financial damage is tremendous. Recent statistics on computer security breaches demonstrate that there has been an explosive growth of successful computer attacks worldwide. Valuable personal and corporate information is being compromised, and computer systems that control communications and critical infrastructure operations are being attacked. Attackers will always seek the weakest point in any security system and launch their attacks against that point because an IT security system is only as strong as its weakest link. Due to increasing complexity and the added functionality requirements, today standardized hardware and software components are often used. The Intel Atom processors are gaining more and more ground in the Embedded Sector, being employed in application fields such as mobile radio communication, automotive industry, railroad engineering, avionics, medical engineering, industrial automation and more [1]. The ongoing advantages of the embedded x86 architecture are well understood and include a comprehensive development process, decreased power consumption, reduction of costs and the possibility to use common operating systems such as Microsoft Windows or Linux. However, the use of standard hardware as well as standard operating system structures can imply serious security concerns because of the known shortcomings of the deployed components. Originally the x86 architecture was designed with a set of different privilege levels in which it was intended that only the secure kernel in Ring 0, which is the Ring with the most privileges, would have full system rights. However, due to performance and other reasons only two of these levels are used today. Figure 1 clarifies this. This means that the kernel, the operating system services, and the device drivers are all located in Ring 0 and have full access to the resources of the system. So any malicious code in a device driver, which might have come from an untrustworthy third party developer, can compromise the whole system. Fig. 1. CPU protection rings (left: ideal / right: real) This big Kernel Space amplifies the size of the Trusted Computing Base (TCB), that part of the system the user has to trust explicitly, because a compromise of any part of the TCB leads to a total loss of integrity. For that and further reasons there is a need for a trustworthy platform with a high-level of dependability, which offers both safety and security features. In particular, for distibuted networked systems security engineering plays a major role. Proprietary security solutions are still often based on the Security by Obscurity [2] principle in which the actual security level can not be properly estimated. Very often specific shortcomings and possible injection vectors can easily be found. Also pure software security solutions like firewalls, virus and malware scanner are not sufficient to protect a system because these can only react to threats which are already known. If the malicious code is only slightly altered then these solutions may fail. The recent appearance of malware in the field of industrial automation solutions makes this very clear. The increased dependence on electronic networks further heightens the urgency for hardware-based protection of information, authentication of users, and the establishment of high degrees of trust in local and remote computing systems. The economic impact of failure to protect such information is demonstrated almost daily by the loss of private information, identity theft, and unethical hacking. Effective security solutions focus on hardware-based security modules which are bonded or tied to the platform and therefore serve as a Trust Anchor for the whole security architecture [3]. Thereby, an effective solution could ensure that it would not be possible for malicious software to bypass the security mechanisms of the hardware. It should be possible to develop applications with cutting-edge security solutions for individual use cases, by employing a trustworthy operating system, with trustworthy services [4]. 2 XIII

130 C. Embedded World International Conference 2011 Nuremberg In the context of this paper the idea of trustworthy computing and the different approaches to hardware-based security solutions, combined with effective software components, is discussed briefly. Subsequently the implementation of a proof of concept system for a security architecture based on a state-of-the-art Trust Anchor is presented. II. OVERVIEW ON TRUSTWORTHY COMPUTING We have to keep in mind that it is definitely not possible to design an all-round generalized solution for a security architecture due to the fact that different application fields require particular security requirements depending on the information which should be kept secret, and have different applications face different types of possible attackers. Advances in computer security technologies are occurring at a fast pace. As a result, defenses are dynamic and forever evolving. However, the basic principles stay the same even though the elements are evolving. A brief overview on the trustworthy computing techniques and elements is presented here. Cryptography: The first element that comes into mind when a person thinks about computer security is cryptography. There are two basic forms of cryptographic processes symmetric, in which the same key is used to encrypt and decrypt a message, and asymmetric, in which the key employed to encrypt a message is different from the key employed to decrypt the message. Cryptography resides at the core of any computer-security system [5]. The creation and sharing of strong keys is a critical part of a secure system, and failure to perform either task well can determine the ultimate security of the system. Passwords and Keys: In computer security, a password is a secret that should, in principle, be known only to the creator of the password. A password is usually employed as part (or all) of a cryptographic key. Passwords are not only used for encryption purposes. They also can play a role in authenticating the user. Authentication sometimes involves the prior sharing of one or more secrets and then the subsequent checking of the secrets being presented by a user against what has previously been shared. The process of authenticating a person is different than that of authenticating a computer, because a person is not comprised of numerical information that is relatively easy to access, as is true for a computer. Authentication of a person requires the capture of numerical information through the use of a device that, with some high degree of confidence, should be unique to the intended person. Authentication may contain one or more factors that are evaluated by the receiving party in order to determine whether or not a person is in fact who he claims to be. Neither factor alone is as strong as a combination of factors. Such factors may include: Something you know: In authentication, passwords fall into the category of something the user knows. Something you have: The additional requirement for a piece of hardware creates two-factor authentication in which something you know must be accompanied by something you have. Various tokens and Smart Card technologies often provide this second authentication factor. Something you are: The degree to which we can find unique characteristics that can be measured and used to uniquely separate people from one other determines whether or not such a measurement can be employed in authentication. Random Number Generators: A good random-number generator should have several characteristics in order to satisfy strict mathematical requirements of randomness. It should: Produce numbers that pass major known criteria for randomness Have no repetitive pattern in its output Have no initial conditions that reset the output to repeat a sequence Not be spoofable Not be susceptible to commandeering, in which the generator is forced to produce a predictable stream There are two basic types of random-number generators: pseudo-random-number generators (PRGs) and hardware-based random-number generators. Security and the Internet: Today the two most important Internet protocols are Transmission Control Protocol (TCP) and the Internet Protocol (IP). These protocols were developed in the early 1980s and security was not build into the specifications. As a result, today s Internet lacks even the most basic mechanisms for security, such as authentication or encryption. These features 3 XIV

131 C. Embedded World International Conference 2011 Nuremberg have been added as an afterthought, and the fact that these features are not built ab initio in is becoming increasingly problematic. The Trusted Computing (TC) approach: The Trusted Computing Group (TCG) [6] is an organization with representatives of the leading computer-industry companies worldwide, who sought a means to improve computer security and authentication. In particular, the TCG wanted to: Create a means for checking system integrity Authenticate a system to the network Enable secure storage of information The group develops open specifications for trustworthy computing systems in order to increase the security level with justifiable costs. The basic idea behind this approach is the integration of a tamper resistant hardware component, named the Trusted Platform Module (TPM) [7], into the platform which should serve as a trustworthy base for the security of the computing system by enabling the verification of the integrity, and warranting its authenticity. In addition the CPU and chipset manufacturers have also become aware of the shortcomings of the x86 architecture and have begun to integrate additional features into their products which should harden the running operating systems, as well as applications, and which should react to threats and manipulation attempts in an appropriate manner. ARM has developed a technology called TrustZone [8] which can take advantage of the functions offered by the TPM. Intel and AMD have introduced the Trusted Execution Technology (TXT) [9] and the Secure Execution Mode (SEM) [10], respectively. Both architectures extend the processor instruction set with additional commands that can directly communicate with the TPM. In addition these new instructions work hand in hand with the virtualization extensions, which will be discussed below. With this new instruction set it is possible to implement a Trusted Virtual Machine Monitor (TVMM) which permits a measured start of VMs. Security by Isolation: Trusted Computing (TC) requires a simple architecture. Virtualization techniques can solve this problem and ensure that a conventional and established operating systems can be used in a security architecture for TC purposes. According to [11] a Virtual Machine Monitor (VMM) is the smallest and simplest system to provide secure isolation for a security architecture based on small components. Adding virtualization brings attractive benefits like flexibility, simplicity and compatibility. With virtualization an abstraction layer, namely the VMM [12], is added between the bare hardware and the operating system. On paravirtualized systems the VMM is located in Ring 0 and displaces the kernel in Ring 1 to become the more privileged one. The VMM controls the underlying hardware and allocates the available resources, such as CPU-time memory and network bandwidth, to the particular Virtual Machine (VM). Commonly the VMM is called the host and the VMs are termed as guests. The individual VMs are isolated from each other and have no knowledge of the others. Although VMM has not been developed as a security architecture, special modifications can provide supplementary security properties. Intel [13] and AMD [14] have added virtualization support to their processor architectures. These enhancements enable the virtualization of operating systems without the necessity of kernel modifications, for instance by adding a new CPU Ring -1 with a higher privilege level than Ring 0. This is not only of interest in the server market, where the execution of multiple commodity operating systems should be supported on a single machine, but also in the client area where there is a need to completely increase system security and reliability. III. HARDWARE-BASED SECURITY TECHNIQUES VERSUS SOFTWARE SOLUTIONS The preceding sections have introduced two important points: Pure software security solutions are fraught with attack points and inherent weaknesses. Hardware-based security technologies have the capability to dramatically reduce or eliminate those weaknesses through the introduction of non-algorithmic processes that are truly random. To the extent that these hardware devices can be physically secured against tampering, they can offer significantly stronger overall security when combined with carefully developed software. Any security-based application must employ both hardware and software and not rely solely upon software. Software is just a running application, and therefore it can be broken. Different concepts introduce a variety of approaches that implement the advantages offered by hardware-based security. A. Secure Bootstrap Loading In practice, the bootstrap process begins at power-up. The microprocessor most-often begins executing instructions at a specific memory location in a read-only memory device. This process usually includes a hardware diagnostic test, followed by loading the fist sector of a disk into memory, and then continues executing the instructions it finds there. Failure at any point results in notifying the user. A secure bootstrap cannot be archieved solely with software components. If the boot process can be manipulated it cannot be assured that the verifying component has not been 4 XV

132 C. Embedded World International Conference 2011 Nuremberg tampered with. In order to avoid this situation, a piece of hardware can be introduced that is an integral part of the platform, is initiated at the factory, and includes an inheritance process that establishes progressively higher levels of trust as the contents and versions of hardware and software modules residing on the platform are checked during the bootstrap process. Valid signatures of these modules are stored in secure, encrypted memory on this device at the factory, and the bootstrap process proceeds to check the integrity and validity of modules using signatures. B. Secure Memory Management and Trusted Execution Technology Memory management becomes an attack avenue when an attacker creates a buffer overflow, which then allows execution of attack code. This can be accomplished by intentionally exceeding the bounds of allocated memory for arrays and variables and trough the use of memory pointers. Although there are techniques to avoid such flaws they are still omnipresent and these types of attacks are very common and highly effective. Intel has launched a secure computing initiative which was code named LaGrande and has been renamed as the Trusted Execution Technology (TXT) [9]. The TXT system seeks to close the attack vectors that existed in previous systems using hardware-based security techniques including memory access. An undesirable feature of the Direct Memory Access (DMA) architecture is that it allows a peripheral device to directly access system memory without any involvement of the CPU. In this type of attack, the contents of RAM are scoured for valuable information such as encryption keys or passwords. Using a technique called domain separation, TXT provides protected execution of commands, in which software can be run such that it is isolated from all other software. Using a domain manager, no other software can access an application s data or control the devices that the application is operating. The domain manager blocks access to protected memory pages, except access by the owning application itself. The TXT system employs a feature called sealed storage in which data that must be stored for a long time must be protected during writing, storage and retrieval. Complete isolation of data by an application is an essential part of this feature. The TXT technology makes excessive use of the Trusted Platform Module. C. The Trusted Platform Module The TCG developed specifications for a special hardware security module called the Trusted Platform Module (TPM) [7]. The TPM is a chip that creates and securely stores private and public PKI keys and hash values. The TPM chip is tamper-resistant as well as tamper-evident and resides on the motherboard of a TPM-enabled platform. The TPM among other things checks the system integrity and the status of the hardware and software environment, it can authenticate the system to the network, enable secure storage of data and keys and provid hardware-based encryption. Figure 2 illustrates the internal structure of a TPM chip. Fig. 2. Internal structure of a TPM chip Each TPM contains several special purpose cryptographic keys. The unique Endorsement Key (EK) represents the identity of the platform. Each TPM manufacturer has to provide a certificate to the EK attesting the compliance of the TPM to the specifications. The Storage Root Key (SRK) always resides in the non-volatile memory of the TPM and forms the top of the TPM key hierarchy. This means that each newly created key has to be encrypted (wrapped) either by the SRK or another key of the hierarchy. Attestation Identity Keys (AIKs) are created by the TPM and linked to the platform using certificates from the EK. AIKs are used for attestation purposes. The functionality of the TPM is often compared to the operating mode of a high-end Smart Card. However, there are two main differences. First of all the TPM authenticates a specific platform whereas a Smart Card authenticates a specific person. Furthermore, the TPM Module contains a set of special registers in the versatile memory, the so-called Platform Configuration Register (PCR). A TPM version compliant to the TCG TPM Main Specification Version 1.2 must offer a minimum number of 24 PCRs. These registers store the hash values of security-critical data using integrity 5 XVI

133 C. Embedded World International Conference 2011 Nuremberg TABLE I PCR USAGE PCR Index: PCR usage: 0 CRTM, BIOS and Platform Extensions 1 Platform Configuration 2 Option ROM Code 3 Option ROM Configuration and Data 4 IPL Code (usually the MBR) 5 IPL Configuration and Data (for use by the IPL Code) 6 State Transition and Wake Events 7 Host Platform Manufacturer Control 8-15 Defined for use by the Static Operating System 16 Debug Defined for use by the Dynamic Operating System measurements. The first eight PCRs are defined for the use within the Pre-Boot environment which is also called the Static Root of Trust for Measurement (SRTM). Throughout the BIOS boot process a log of all executable code is created and extended into PCRs. Table I shows exemple usage of the PCR register. D. Token, FPGA and further techniques An aternate technology that employs the something you have philosophy of authentication is the use of a Token which has some unique information such as keys on it. USB security tokens or Smart Cards are an example for this technology and can be used for multi-factor authentication for additionaly hardened computer systems. There are many more techniques, such as the implementation of cryptographic engines in FPGAs to build system-on-a-chip solutions, as well as common biometric technologies. But these are out of scope of this paper and will not be discussed in detail. E. Trustworthy Software Components Pure software-based security approaches cannot guarantee long-term system integrity anymore. Still hardware-based solutions need trustworthy services and applications. Commonly used operating systems have many benefits like ease of use and cost reduction through the rapid development processes and opportunity to reuse software components. However, regarding system security, these operating systems are far too complex, and such issues hinder the design of effective security solutions. Virtualization technology, which was intended for consolidation and the reduction of costs, is experiencing more and more interest for its use in security critical application fields [15]. The security level of a virtualized system benefits from the isolation ability of that technology. Individually partitioned and separated parts have no knowledge of eachother, have their own resources allocated by the virtualization software layer, and they cannot break out of their assigned areas. IV. PROOF OF CONCEPT SYSTEM One of the design criteria for the proposed security architecture was to enable common operating systems to be used within this architecture. Most users became accustomed to their favorite operating system and are often not willing to give up ease-of-use for a higher level of security. Manufacturers of computer systems are also often not prepared to change the structure of their products. Fig. 3. Proof of Concept Reference Design 6 XVII

134 C. Embedded World International Conference 2011 Nuremberg The Proof of Concept System proposed here is based on a Virtual Machine Monitor (VMM), for example the open source hypervisor Xen [16], which functions as additional abstraction layer (see figure 3). This virtualization layer runs on the bare hardware and therefore is the only entity which has full access to the physical resources of the system. In the example presented, the Host operating system consists of a small Linux system which is located on top of a virtualization layer. Because the Host OS is Linux based it can be held as small as possible and contains only the necessary modules for the specific application. The platform is equipped with different hardware-based security modules namely a Trusted Platform Module [7] as well as a Intel VT-x [17], Intel VT-d [13] and Intel TXT [9] capable CPU and chipset. Further modules like a Smart Card or a Token can be added according to the individual security needs of the manufacturer. Figure 4 illustrates the hardware structure. Fig. 4. Hardware structure of the Proof of Concept System Because this approach is based on security modules in hardware it offers a higher level of security than pure softwarebased solutions because the hardware-based security modules cannot be easily circumvented or annulled by maliciously behaving software. In this way the solution provides an effective protection against software-based attacks. With these hardware security enhancements a trustworthy launch of the VMM and Host OS can be assured by defining special application specific policies, which guarantee that only a well-defined configuration of the virtualization layer, as well as Host operating system, can be executed. Any modifications to security critical files will be recognized. This assumes that the Guest OS can only be executed if the virtualization layer, and the Host operating system, as well as the image of the Guest OS, has not been altered and are therefore in a trustworthy state. The TPM Module offers basic cryptographic functions. Additionally during the boot process the TPM stores the integrity values of the platform in a tamper-proof and protected memory region by calculating hash values of security critical files. Fig. 5. Chain of Trust In this way a continuous Chain of Trust with alternating measurement and execution flows can be established (see figure 5). The Core Root of Trust for Measurement (CRTM) code starts the chain by measuring the integrity of the next component before executing it. 7 XVIII

135 C. Embedded World International Conference 2011 Nuremberg Furthermore, the Intel TXT capable CPU and chipset enables the so-called Dynamic Root of Trust for Measurement (DRTM) which allows the protected execution of a so-called Measured Launched Environment (MLE) [18] with special platform policies and verified launch policies. This way the user/administrator can define for an individual configuration which virtualization layer or operating system kernel should be launched in a predefined way. The measured launch of the VMM makes sure that the created VMs can also be trusted. Intel VT-d (Intel Virtualization Technology for directed I/O) inhibits direct memory access through DMA and interrupt remapping. This is actually very important to security because normal DMA access bypasses the CPU for a better performance leading to security problems. Intel VT-x furthermore adds hardware support for virtualization. These integrity values can be used to prove that the system has not been tampered with in a process called Remote Attestation. There a remote entity can evaluate the calculated values with well-known ones, which are considered as trustworthy, and make a decision whether the platform can be trusted or not. Furthermore, these values can be used to seal sensitive data not only to the platform but also to the current state of that platform. This way, it can be assured that the data can be recovered again on that particular platform only if it is in the same configuration state as it was during sealing process. This can ensure the protection of the intellectual property (IP). Virtualization can eliminate the need to port legacy code to a new operating system. If a manufacturer has an existing application running on an old operating system, the application and operating system can run in a VM which supports legacy code while other applications run on different operating systems. Since many legacy applications were written to run alone on dedicated hardware, virtualization provides a safe environment where this software can be run in isolation and avoids conflicts with other applications. Virtualization brings in another great security feature. It brings back the security by isolation situation even when the devices are connected to a network [15]. With virtualization it is possible to separate individual applications or whole operating systems from each other. Therefore, the different operating systems have no knowledge about each other and each one thinks it is the only system running on top of its own hardware. In fact the virtualization layer makes sure that each operating system only gets access to the predefined hardware resources, such as CPU time and memory regions. The usage of a tiny held version of the Linux open source operating system as the Host OS permits self designs and developments and this is more secure than using other common operating systems due to a decreased number of possible errors, and fewer existing viruses and malware. Both the virtualization layer and the Linux Host OS support the open source pre-kernel/vmm module Trusted Boot (tboot) [19] which uses the Intel TXT to perform a measured and verified launch of an OS kernel/vmm. Currently Linux is the only operating system which supports the enhanced security features provided by Intel TXT. Together with a virtualization layer on top of the bare hardware it can be used to make sure that Guests can only be launched if the system has not been tampered with. However, this does not mean that the manufacturer is restricted to using the Linux open source operating system. By utilizing the hardware-based virtualization support provided by Intel VT-x, closed source operating systems like the Windows systems can run unmodified on top of the VMM. The virtualization layer and Host OS make sure that the Guest OS is booted in a well-defined and trustworthy state. V. CONCLUSION Unlike Security by Obscurity [2], which does not work in realizing a trusted solution, security defense by adding multiple layers of security (also called defense in depth ) does have significant prospects to work effectively. The fact is that the more security layers that must be overcome before a hacker can gain access to critical information, the more difficult the execution of a successful attack becomes. Fig. 6. Components of a Trusted Computing System 8 XIX

136 C. Embedded World International Conference 2011 Nuremberg The TCG only defines the components necessary for a Trusted Computing Platform (TCP)T, but the TC technology offers an innovative approach and building blocks for the creation of new security architectures. In this paper, we presented a hypervisor-based security architecture as an approach towards a TOS on top of the TCP defined by the TCG. A Trusted Computing System (TCS) consists of a TCP and a TOS with trusted services and trusted applications (see figure 6). A TOS could also be based on a microkernel architecture but a VMM was found to be simpler in construction by the developers, more acceptable by the users, and more profitable by the manufacturers, as compared to the microkernel approach. A proper implemented VMM enforces an isolation policy to separate security critical applications from untrusted and untrustworthy components. A secure VM with specific security mechanisms runs the critical applications in a closed and simple environment. So attacks against common VM cannot cause leaking of secrets. Another great benefit of virtualization which has not been mentioned yet is that with virtualization it is possible to make snapshots of a specific system state. In this way if a component of a common VM gets compromised, then a prior trustworthy state can easily be restored. For architectures which are based on a chain of trust it is very important that this chain is consistently adhered to without leaving any gaps. The dynamic chain of trust hinders the possibility of Time-of-check-to-time-of-use (TOCTTOU) attacks due to the fact that the integrity measurement values can report the current state of the system, and not only the state the system had during its boot process. One important fact about the concept of TC often gets disregarded. The measured integrity values representing the state of the platform need to be verified by a remote party. Platform attestation with the verifying component as part of the same system forms a problem which should not be underestimated. If the system gets compromised one can not exclude the possibility that the verifying component might also have been modified. While the presented methodology is intended as a tool to bring security to legacy systems or to mission-critical systems, it still requires technical engineering know how to configure security parameters the right way. The impact on performance for a system by introducing security solutions has always been an issue with applications, operating systems, and other information technology infrastructures, which leads to limitations in systems. The security and virtualization enhancements from Intel can mitigate against such limitations by reducing the performance overhead. The security solution presented in this paper offers sophisticated protection against software based attacks. However one has to keep in mind that the solution cannot offer full prevention against all sophisticated hardware-based attacks. Increased security features inevitably have an impact on user comfort. So a compromise between the security features and the usability has to be found. The goal of this approach is to increase the security and trustworthiness of the platform by providing easy-to-use management tools for creating application-specific security policies. REFERENCES [1] Intel Atom processors for embedded computing (Access: January 2011) [2] Rebecca T. Mercuri and Peter G. Neumann, Security by Obscurity, COMMUNICATIONS OF THE ACM, 2003 [3] Roger R. Dube, Hardware-Based Computer Security Techniques to Defeat Hackers - From Biometrics to Quantum Cryptography, Wiley, 2008 [4] TrouSerS, open-source TCG Software Stack; M. Selhorst, C. Stueble, F. Teerkorn: TSS Study - Open Source TCG Software Stack TrouSerS and Tools in its Environment ; May 2008; Available at: [5] Bruce W. Schneier, Applied Cryptography, Wiley, 1996 [6] Trusted Computing Group; application fields; (Access: January 2011) [7] Trusted Computing Group; TPM Main Specification Level 2; Version 1.2, Revision 103; 9 th July 2007; Available at: main specification [8] ARM TrustZone; ARM Security Technology: Building A Secure System Using TrustZone Technology ; April 2009; Available at: trustzone security whitepaper.pdf [9] Intel Trusted Execution Technology, Preliminary Architecture Specification, 2007 [10] AMD Secure Execution Mode; AMDs Vision for Trustworthy Computing ; October 2004; Available at: /attendees/slides/ E1.pdf [11] M. Hohmuth, M. Peter, H. Haerting, J. S. Shaprio: Reducing TCB size by using untrusted components - small kernels versus virtual-machine monitors ; 11th ACM SIGOPS European Workshop, Leuven, Belgium, 2004; Available at: ps/reducingtcb.pdf [12] Sean Campbell and Michael Jeronimo, Applied Virtualization Technology - Usage Models for IT Professionals and Software Developers, Intel Press, 2006 [13] Intel Virtualization Technology; Intel Virtualization Technology for Directed I/O - Architecture Specification ; Revision 1.2; September 2008; Available at: ftp://download.intel.com/technology/computing/vptech/intel%28r%29 VT for Direct IO.pdf 9 XX

137 C. Embedded World International Conference 2011 Nuremberg [14] AMD Virtualization; AMD-V Nested Paging ; Revision 1.0; July 2008; Available at: final-TM.pdf [15] The Invisible Things Lab, Qubes - Operating System (Access: January 2011) [16] P. Barham, B. Dragovic, K. Fracer, S. Hand, T. Harris, A. Ho, R. Neugebauery, I. Pratt, A. Warfield: Xen and the Art of Virtualization ; Proceedings of the 19th Symposium on Operating Systems; Bolton: ACM Press, 2003: ; [17] Intel Vanderpool Technology for IA-32 Processors (VT-x) Preliminary Specification, 2005 [18] Intel - Measured Launched Environment; Intel Trusted Execution Technology Measured Launched Environment Developer s Guide ; December 2009; Available at: [19] J. Cihula: Trusted Boot - Verifying the Xen Launch ; Xen Summit; Intel Corp.; Fall 2007; Available at: fall07/ 23 JosephCihula.pdf 10 XXI

138 D. Kontron - Embedded Security Whitepaper Together with the industrial partner Kontron Embedded Modules GmbH the research developed a Whitepaper titled "Standardized Security Principles for Embedded Computing Industries" describing the main problem regarding security in today s industrial computing systems. It characterises the underlying components of the proof-of-concept system as well as the benefits which can be introduced by adding a virtualization layer on top of the bare hardware. Additionally some sample use cases are pointed out. The Whitepaper is provided on the following pages. XXII

139 D. Kontron - Embedded Security Whitepaper Standardized Security Principles for Embedded Computing Industries If it s embedded, it s Kontron. XXIII

140 D. Kontron - Embedded Security Whitepaper Whitepaper Standardized Security Principles for Embedded Computing Industries Security is becoming an issue that is more and more important at the industrial computing level. However, most industrial solution vendors are not particularly aware of the computer security issues involved. Moreover, well-investigated security approaches used in consumer and mobile computer markets are not applicable and must be adapted. In 2010, Kontron, a premier supplier of industrial computers, started a research project together with Intel to build up a reference system with several mechanisms aimed at achieving high security levels while answering the industry s needs. The project is still active today and has already demonstrated several solution paths for certain industries. Real-life test pilots have already been started, while further real-life test scenarios are welcome. Contents Standardized Security Principles for Embedded Computing Industries Summary Contents Introduction Solution Principle and Use Case Samples Reference System Linux as a reference system Limitations of such a security solution Compendium About Kontron XXIV

141 D. Kontron - Embedded Security Whitepaper Whitepaper Introduction Nowadays, computer systems represent an important part of our everyday life. Everyone knows about the big advantages that systems such as digital cameras, mobile phones, navigation systems, self-service terminals bring, as well as the various possibilities, online banking for instance, that they offer. In addition, most users are aware of the major disadvantages the risk of viruses, worms, phishing attacks and fraud, to name but a few but these should also include complex usage and handling. And they know how to handle security and safety issues by installing firewalls, virus and malware scanners, IDS systems and others, due to the fact that most of the disadvantages originate in the network. In industry, computer systems also play an important role (e.g. in industrial automation systems) in the controlling of devices, performing of quality checks in visualization tasks and so forth. Up until now, they could effectively prevent attacks and fraud simply by physical isolation. The devices, typically consisting of an operating system (OS) and architecture, were not connected to any network or even had any open interfaces such as USB ports, and so the installation of any other software was very difficult. But that s about to change. Increased efficiency and streamlined processes imply that machines need to be connected more and more to other systems. So the connection to the World Wide Web is not a question of if, but when. Furthermore, direct access through standardized interfaces, mainly USB, could end up in the installation of new but compromised OS images. Physical isolation just doesn t work anymore. So the drawbacks are becoming more and more valid also in the embedded market, and the problems are no longer limited to personal computers. One might initially think that the answer could be quite easy adopt the behavior established in the personal computer section and install protection software. But there is a major difference. Personal computer equipment is soon outdated and thus replaced more frequently. This generally means that the latest hardware and software components are used, and updating to the newest protection mechanisms is easy since it is carried out at the same time. Certain industries, however, use highly customized solutions which cannot be replaced on an ad-hoc basis. This results in situations in which, on one hand, devices can be easily brought into the web, but on the other, protection mechanisms are either outdated or simply no longer available for the selected platform. Switching to newer platforms would result in major software adaptation efforts. Consequently, industrial companies set up homebrew solutions such as simple hash validation of images and certain proprietary checks in their software. Furthermore, the recent emergence of software that behaves maliciously in highly specialized application fields shows that security solutions consisting of pure software are no longer sufficiently secure. Standardized and highly secure platform mechanisms are available but these are mainly not used. Kontron and Intel have initialized a study at the local University of Applied Science in Deggendorf, where current and proven high security mechanisms such as Trusted Platform Modules (TPM) and Intel Trusted execution Technology (TXT) as well as Intel Virtualization Technology (VT) are evaluated to build a Proof-of-Concept system that solves the problems that arise. Solution Principle and Use Case Samples Hardware-based security mechanisms such as TPM and TXT are combined with virtualization techniques to solve application-specific requirements. Use case 1: Legacy system needs to be connected All critical communication is carried out via a highly secure system, while the existing software can still be run and has a simple (unprotected) interface. An updated system with a secure OS acts as a firewall and allows only defined access. Legacy software does not need to be updated and a high level of security can be attained. Use case 2: A completely secure boot-chain is required, but the OS does not support a secure boot A virtualized and secure OS boots up with TXT support and therefore a defined secure state can be achieved. The secure OS validates the production OS image before it is booted up. Depending on certain needs, hypervisors such as Wind River (resource partitioning) or Linux with Xen (hardware abstraction) could be used. Use case 3: Certain industries require dedicated systems with dedicated tasks, i.e. the gaming industry with a secure controlling OS, while another OS runs the game itself. Reference System The Proof-of-Concept system is based on a Virtual Machine Monitor (VMM) which functions as an additional abstraction layer (see Figure 1). This virtualization layer, the Open Source hypervisor Xen, for instance, runs on the bare hardware and therefore is the only entity which has full access to the physical resources of the system. 3 XXV

142 D. Kontron - Embedded Security Whitepaper Whitepaper Figure 1 shows the schematic setup of an ideal security solution based on the Computer-on-Modules concept The Host operating system consists of a small Linux system which is located on top of a virtualization layer. The Proofof-Concept system has been tested with various Linux distributions such as Ubuntu, Debian and Fedora, but other distributions are also supported. Because the Host operating system is Linux-based it can be kept as small as possible and contains only the necessary modules for the specific application, decreasing the risk of a successful attack. The platform is equipped with different hardware based security modules namely a Trusted Platform Module as well as a Intel VT-x, Intel VT-d and Intel TXT capable CPU and chipset. Depending on individual security needs, the administrator can choose whether the TPM should be tied to the Carrier board or be attached to the COM Module either as discrete module or integrated into the chipset. Further modules such as Smart Card or Token can be added according to the individual security needs of the manufacturer. Because this approach is based on security modules in hardware, it offers a higher level of security than pure software-based solutions because the hardware-based security mechanisms cannot be easily circumvented or annulled by malicious software. In this way the solution provides an effective protection against software-based attacks. With these hardware security enhancements, a trustworthy launch of the VMM and Host OS can be assured by defining special application-specific policies which guarantee that only a well-defined configuration of the virtualization layer as well as Host operating system can be executed. Any modifications to security critical files will be recognized. Furthermore, the images of the Guest operating systems can be encrypted and sealed to a specific known system state. This ensures that the Guest OS can only be executed if the virtualization layer, Host operating system, as well as the image of the Guest OS, have not been altered and are therefore in a trustworthy state. The TPM Module offers basic cryptographic functions that can be utilized by sophisticated software products. Moreover, during the boot process the TPM stores the integrity values of the platform in a tamper-proof and protected memory region, known as the Platform Configuration Register (PCR), by calculating hash values of security-critical files. In this way a continuous chain of trust, also called the Static Root of Trust for Measurement (SRTM), with alternating measurement and execution flows can be established (see Figure 3). Each part of this chain is first measured before it is executed. Therefore any manipulations in the booting process can be detected even if the malicious part is able to fake all further measurements, and the platform can react in a pre-defined manner. 4 XXVI

143 D. Kontron - Embedded Security Whitepaper Whitepaper Figure 3 shows hand-over in a secure boot chain during the booting-up process Figure 2 shows the hardware structure of the Proofof-Concept system Furthermore the Intel TXT capable CPU and chipset enables the so-called Dynamic Root of Trust for Measurement (DRTM) which permits protected execution of a Measured Launched Environment (MLE) with special platform policies and verified launch policies. This way the user or administrator can define which virtualization layer or operating system kernel with individual configuration should be able to launch in a predefined way. The measured launch of the VMM also ensures that the created VMs can be trusted if they are sealed to the unmodified version of the hypervisor. Intel VT-d (Intel Virtualization Technology for directed I/O) inhibits direct memory access through DMA and interrupt remapping. This is very important to security because normal DMA access bypasses the CPU to give better performance, thus leading to security problems. Commonly, platforms suffer from this security hole when an attacker manages to overwrite memory regions via DMA access in order to execute malicious code that compromises system integrity. In addition, the Intel VT-x adds hardware support for virtualization, which decreases the performance overhead and enables a variety of operating systems to be executed. These integrity values can be used to check that the system has not been tampered with through a process known as Remote Attestation. In this, a remote entity can evaluate the calculated values against known ones considered to be trustworthy and make a decision as to whether the platform can be trusted. Furthermore these values can be used to seal sensitive data not only to the platform, but also to the current state of the platform. This makes certain that the data can be recovered again on that particular platform only if it is in the same configuration state as it was during the sealing process and can ensure the protection of the intellectual property (IP). Virtualization can eliminate the need to port legacy code to a new operating system. If a manufacturer has an existing application running on an old operating system, the application and operating system can run in a VM which supports legacy code, while other applications run on different operating systems. Since many legacy applications were written to run alone on dedicated hardware, virtualization provides a safe environment where this software can run in isolation, avoiding conflicts with other applications. Virtualization adds another powerful security feature. It brings back security by isolation even when the devices are connected to a network. With virtualization it is possible to separate individual applications or even entire operating systems from each other. Therefore the various operating systems have no knowledge of each other, and think they are the only system running on top of their own hardware. In fact the virtualization layer makes sure that each operating system only has access to predefined hardware resources such as CPU time and memory regions. The usage of virtualization technology adds security through isolation and permits legacy software to be run on modern platforms. Special hardware-based trust anchors enable the measured start of a virtualization layer and a Host OS whose integrity can be verified by a remote party. Special securitysensitive data can be encrypted and sealed to the known and trusted state and only be recovered when the system is again in the identical state. 5 XXVII

144 D. Kontron - Embedded Security Whitepaper Whitepaper Linux as reference system The usage of a tiny version of the Open Source operating system Linux as the Host OS permits one's own designs and developments to be used and is more secure than other common operating systems due to the decreased error rate and fewer existent viruses and malware. For the Proof-of- Concept system, widespread distributions such as Ubuntu 10.4 and Fedora 13 have been analyzed with kernel version However other distributions could also be used for a specific solution according to the needs of the developer. Another major benefit of this specific approach has still to be mentioned. Virtualization can permit snapshots of a specific system state to be made. Thus if a component of a VM becomes compromised, a prior state definitely known to be trustworthy can easily be restored, reducing downtime. Both the virtualization layer and the Linux Host OS support the Open Source pre-kernel/vmm module Trusted Boot (tboot), which uses Intel TXT to perform a measured and verified launch of an OS kernel/vmm. For the reference design, tboot rev 244 was used. The concept is based on the ETXexpress-PC module and therefore the GM45, PS45 and PM45 Express SINIT-AC modules are used. Currently, Linux is the only operating system that supports the enhanced security features provided by Intel TXT. Together with a virtualization layer on top of the bare hardware it can be used to make sure that Guests can only be launched if the system has not been tampered with. However this does not mean that the manufacturer is restricted to using the Linux Open Source operating system. By utilizing hardware-based virtualization support provided by Intel VT-x closed source, operating systems such as Microsoft Windows can run unmodified on top of the VMM. The virtualization layer and Host OS make sure that the Guest OS is booted in a well-defined and trustworthy state. This proposed security solution is highly flexible and based on Open Source components, permitting own designs and developments to be utilized according to individual needs. Furthermore it is based on standardized hardware security modules that offer more protection against attacks and fraud than pure software-based solutions or proprietary security mechanisms. Limitations of such a security solution While the methodology shown is a tool to bring security to legacy systems or to mission-critical real time systems, it still requires technical engineering know how to configure security parameters in the correct manner. The performance impact due to security has always been an issue for applications, operating systems, and other information technology infrastructures. The security and virtualization enhancements from Intel can mitigate this limitation by reducing the performance overhead. The security solution described offers sophisticated protection against software-based attacks. It must however be kept in mind that it cannot completely prevent sophisticated hardware-based attacks. Increased security features inevitably have an impact on user comfort, so a compromise between security features and usability must be found. The goal of this approach is to increase the security and trustworthiness of the platform by providing easy-to-use management tools for creating application-specific security policies. Compendium Relevant terms are briefly explained: TPM Stands for Trusted Platform Module and is a hardware security module whose basic functionality has been specified by the Trusted Computing Group. It offers basic cryptographic functions such as asymmetric cryptography, the creation and verification of digital signatures, the calculation of hash values and message authentication codes, as well as the creation of true random numbers. The TPM is attached to the platform and has the ability to create the hash values of security-critical data during the boot and run time of an operating system, enabling a trusted system state to be attested to. TXT Stands for Trusted execution Technology and is a feature of new Intel platforms that provides the ability for process isolation and a DMA exclusion vector to isolate I/O devices from the security kernel. It operates hand-in-hand with the Intel Virtualization Technology as well as the Trusted Platform Module to provide sealed storage and platform attestation. With TXT it is possible to boot a system only if it is in a known and therefore trustworthy state. DMA Direct Memory Access (DMA) allows a peripheral, such as a PCI card, to directly access memory without any CPU involvement. A DMA device therefore has access to all of memory. An attacker can manipulate the device to perform a DMA to the program's memory. Hypervisor and Virtualization Virtualization provides a software layer, called the Virtual Machine Monitor (VMM), beneath the operating system. This software layer manages multiple virtual machines, each containing an operating system and software applications. Applications running in virtual machines cannot interfere with each other. The VMM can be used to create another layer of security that prevents applications from gaining access to the application data of other OSs. This capability can inhibit someone, such as a hacker writing malware, from creating an application that modifies the data in another program. Hypervisors are often orders of magnitudes smaller in size and less complex than modern operating systems. 6 XXVIII

145 D. Kontron - Embedded Security Whitepaper Whitepaper About the University of applied Scienes (FHD, Germany) The University of Applied Sciences Deggendorf (FHD) was founded in 1994 and is one of the youngest Bavarian universities. It was ranked several times as one of the top German universities in teaching. The research group Innovative Communication Systems was founded in 2002 by Professor Grzemba. The main focus lies on hardware and software applications emphasising emedded IT technologies and communication systems. The research group Embedded Systems focus on the development and application of embedded technologies on the topics In-car Communication Systems, Communication Systems in Building Automation and Embedded PCs. Additional fields of activity are custom circuit and PCB design, development of custom software on various hard- and software platforms, Green IT and Trusted Computing. The research on Green IT aims to define and develop tools for energy profiling suited to the needs of the embedded x86 platform. As shown by current malware related incidents, the field of security is gaining more attraction in all fields of embedded systems. Therefore the Embedded Systems Research group is examining Trusted Platform technolgies and Trust Anchors with a special emphasis on the x86 platform. In 2008 a new working group for geo-information technology, formerly included in the research group water and environment was founded. Main objective is to carry out interdisciplinary research on topics related to the application of GI technology in several fields, including environmental management and decision support systems. FHD is partner of the Bavarian State Ministry of the Environment, Public Health and Consumer Protection and the Bavarian Water Management Authorities in research and education and was running several research projects funded by the State of Bavaria and co-financed by the European Union (ILUP, Lower Vils, Municipal River Basin Management). The research centre has four academic, five non-academic staff members and two PhD students. About ten graduates, diploma students, trainees and students are working on projects funded by third-party. 7 XXIX

146 D. Kontron - Embedded Security Whitepaper Whitepaper About Kontron Kontron, the global leader of embedded computing technology, designs and manufactures embedded and communications standards-based, rugged COTS and custom solutions for OEMs, systems integrators, and application providers in a variety of markets. Kontron engineering and manufacturing facilities, located throughout Europe, North America, and Asia-Pacific, work together with streamlined global sales and support services to help customers reduce their time-to-market and gain a competitive advantage. Kontron s diverse product portfolio includes: boards & mezzanines, Computer-on-Modules, HMIs & displays, systems & platforms, and rugged & custom capabilities. Kontron is a Premier member of the Intel Embedded Alliance and has been a VDC Platinum Vendor for Embedded Computer Boards 5 years running. Kontron is listed on the German TecDAX stock exchange under the symbol "KBC". For more information, please visit: Corporate Offices Europe, Middle East & Africa Oskar-von-Miller-Str Eching/Munich Germany Tel.: +49 (0)8165/ Fax: +49 (0)8165/ [email protected] North America Stowe Drive Poway, CA USA Tel.: Fax: [email protected] Asia Pacific 17 Building,Block #1,ABP. 188 Southern West 4th Ring Road Beijing , P.R.China Tel.: Fax: [email protected] #Whitepaper - Standardized Security Principles for Embedded Industries - FHD# PDL All data is for information purposes only and not guaranteed for legal purposes. Subject to change without notice. Information in this datasheet has been carefully checked and is believed to be accurate; however, no responsibility is assumed for inaccuracies. All brand or product names are trademarks or registered trademarks of their respective owners. 8 XXX

147 E. The Trusted Platform Module 1 The Trusted Platform Module (TPM) is a cryptographic hardware chip which is tied to the platform and whose basic structure and functionality has been specified by the TCG TPM Main Specification. The most recent version of this specification is the TPM Main Specification Level 2 Version 1.2, Revision 116 [14] [15] [16]. JTC1, a joint committee of the International Organization for Standardization, or ISO, and IEC, the International Electrotechnical Commission, has accepted and published the Trusted Computing Group Trusted Platform Module specification Version 1.2 as ISO/IEC standard [1]. Given that some sections of the specification do not describe concrete solutions but rather give recommendations, it is possible that a TPM implementation differs from the depicted functional range and operating mode. Internal Components Figure E.1 illustrates the basic structure of the TPM components. The individual components can be classified in four logical areas. Figure E.1.: Internal component structure of a Trusted Platform Module 1 The references which are referred to within this appendix are referencing the main Reference list of this thesis. XXXI

148 E. The Trusted Platform Module Secured I/O The secured input / output of the TPM ensures that only specific commands can interact with the module. This component is accountable for the communication inside as well as outside of the chip. Normally the TPM is soldered to the platform and connected via the Low Pin Count (LPC) bus to the southbridge of the chipset. As an alternative the TPM module can be integrated directly in the chipset. Cryptographic Processor The main component of a TPM consists of a cryptographic processor with various engines for cryptographic operations. Symmetric Crypto Engine The TPM utilises symmetric cryptographic algorithms for TPM internal used authentication of data, such as passwords and Personal Identification Number (PIN), for the protection of data on the communication channel between TPM and software components, as well as for the encryption of data blocks, which have to be deposed outside of the TPM memory. All symmetric operations are used only inside of the chip and cannot be provided to external components. HMAC Engine Hash-based Message Authentication Code (HMAC) is a specific construction for calculating a Message Authentication Code (MAC) involving a cryptographic hash function in combination with a secret key. A TPM module uses HMAC algorithms to assure that a message sent to the TPM has not been modified on the communication channel. Also, the HMAC functionality is available TPM internal only. True Random Number Generator According to TCG specification each TPM must offer a True Random Number Generator (TRNG). In order to guarantee the randomness of the calculated random values, the TPM makes use of characteristics of the system hardware as entropy, such as thermal random noise from electronic components. The obtained random numbers are used by the TPM internals for the creation of cryptographic keys, but also outside of the TPM by using a special command TPM_GetRandom. Given that ensures that these values are true random numbers, they can also be used as Salt for software implemented pseudo random number generators, which usually are considerably faster than TRNG. XXXII

149 E. The Trusted Platform Module SHA-1 Engine The Secure Hash Algorithm engine implements the cryptographic hash function SHA-1 in hardware with a constant output of 160 Bits. The engine mainly is used by the HMAC component for the creation of MAC codes and for updating the Platform Configuration Register (PCR) during the boot process and runtime of the system. The related commands can be invoked by any hardware or software component and do not require any authentication. RSA Engine For the use of asymmetric cryptographic algorithms the TPM has implemented the approved and established RSA algorithm. According to the TCG specification a TPM must support key lengths of 512, 768, 1024 and 2048 bits, however the use of keys with a length of 2048 bits is advised. The RSA engine can be used both for encryption / decryption processes as well as for the calculation and verification of digital signatures. The provided functions can be used internally as well as externally. Persistent Memory The third logical component of the TPM module comprises a persistent memory with the following entities: Endorsement Key (EK) The Endorsement Key (EK) is a RSA key pair with a length of 2048 bits, which usually is created during the manufacturing process of the TPM chip. This asymmetric key pair serves as a unique identity of the platform which cannot be deleted in TPM modules, which were designed according to the version 1.1b of the TCG TPM Main Specification, and only with some limitations in modules following the TCG TPM Main Specification version 1.2. The private part of the EK must never leave the chip whereas the public part can be readout unless a special command blocks this. Due to data privacy reasons the EK nowadays is only used for the encryption of the owner s password as well as for attestation purposes. Storage Root Key (SRK) Like the EK, the Storage Root Key (SRK) is a RSA key pair with a length of 2048 bits. However, in contrast to the EK, the SRK is not created during the manufacturing process of the TPM chip. The SRK is generated during a process which is often refereed to as taking ownership through the owner of the platform XXXIII

150 E. The Trusted Platform Module and disposed in the persistent memory of the the TPM. According to the TCG specification both the EK and the SRK mandatory must be stored inside of the security module and not on an external storage device. The private part of the SRK also must never leave the chip, however, a SRK can be changed an arbitrary amount of times through clearing the current owner and issuing the take ownership command. The SRK is used for the secure use of additional keys and serves as root for a key hierarchy. TPM Configuration Flags Additionally in the persistent memory region of the TPM there are so-called Permanent Flags for the long-lasting storage of configuration parameters. Owner Authorization Secret The Owner Authorization Secret is a hash value with a total length of 160 bits which represents the owner password, which the owner of the platform has to type in, when taking ownership of the TPM module. Since the password is encrypted with the EK it can only the encrypted by the TPM for authentication of the owner. Versatile Memory The last logical part of the TPM consists of a versatile memory region with the following components: Platform Configuration Register (PCR) The Platform Configuration Register (PCR) provide memory regions with a size of 160 bits each, which are located in the volatile memory of the TPM. These areas store the SHA-1 hash values of special data blocks, such as the Basic Input Output System (BIOS), boot loader, kernel, drivers and applications during the boot process, as well as the runtime of an operating system. This way these entries represent the current state of the system and can be used for the evaluation of the trustworthiness and integrity of the platform. The PCR registers only allow read access to avoid manipulation attempts. The TCG TPM Main Specifications specify a minimum of 16 registers for TPM modules following version 1.1b of the standard and 24 registers for TPM modules of version 1.2. However, the individual register can store the hash values of more than one component by using a special feature that allows extension. Therefore the new data to be measured is appended to the old hash value and a new hash value is calculated over the whole data block. Since the order of hash operations is of importance and XXXIV

151 E. The Trusted Platform Module the chronological events of creating hash values should be traceable an additional entry in the so-called Stored Measurement Log (SML) is created after each update. Table E.1 shows the usage of the PCR registers as intended by the TCG TPM Main Specification. Table E.1.: Platform Configuration Register usage [55] PCR: PCR usage: 0 CRTM, BIOS and Platform Extensions 1 Platform Configuration 2 Option ROM Code 3 Option ROM Configuration and Data 4 IPL Code (usually the MBR) 5 IPL Configuration and Data (for use by the IPL Code) 6 State Transition and Wake Events 7 Host Platform Manufacturer Control 8-15 Defined for use by the Static Operating System 16 Debug Defined for use by the Dynamic Operating System Attestation Identity Key (AIK) The Attestation Identity Key (AIK) forms an asymmetric key pair with a total length of 2048 bits as well, which come into operation by the process of evaluating the trustworthiness of the platform. If the EK would be used for this task, it would be possible to uniquely identify the platform after two evaluation processes which gives rise to a problem regarding data privacy. For this reason the AIK has been introduced, which cannot be linked to the EK. Therefore these keys have to be signed by a Trusted Third Party (TTP). AIK keys are most often stored on a external storage device. Storage Keys The TPM module furthermore provides the ability to store additional key pairs in a secure memory region. The amount of these key slots, however, is limited and on this account additional keys are typically stored on an external storage device. This does not form a data privacy problem if the keys are tied to the TPM through prior encryption. XXXV

152 E. The Trusted Platform Module Functionality Operating Modes According to the TPM specification the owner of the platform must have complete control of the TPM. A pre-condition therefore is that the module has to be delivered in a deactivated state so as to leave the decision to use the module, or not, to the owner. In addition it has to be assured that only the owner can be allowed to enforce critical state changes through physical presence. All together the TPM contains three pairs of separate operating modes, Disabled/Enabled, Deactivated/Activated and Unowned/Owned. The state Disabled blocks all functions, except for commands which query basic TPM information, such as version number and commands, which change the state to Enabled. In the state Enabled all functions are available unless they are blocked through the states Deactivated and Unowned. In order to change the state Unowned into Owned a proof of physical presence has to be provided. The state Deactivated is similar to the state Disabled, however, it is possible to take ownership of the platform. In the state Activated all functions of the TPM are available, unless they are blocked through the state Unowned. Figure E.2 shows the resultant states and state transitions. Figure E.2.: TPM states and state transitions [55] Platform Integrity The TPM measures the integrity of software and hardware components through the calculation of hash values of security critical data blocks of these components and store these values in a secure way in the PCR register. XXXVI

153 E. The Trusted Platform Module Trust Concept To guarantee the integrity of the measurements and the whole system, special Roots of Trust are required. The TCG defines three of these roots. The Root of Trust for Measurement (RTM) is the basic component for the integrity measurements. This Root of Trust is realised by the Core Root of Trust for Measurement (CRTM) BIOS extension. Another root, the Root of Trust for Storage (RTS), ensures that security sensitive data, such as keys, which have to be stored on an external storage device, are tied to the platform first, through encryption. The third root is called Root of Trust for Reporting (RTR), which is responsible for the establishment of a platform identity and the protection of the transferred PCR register values during attestation of the system. Using these Roots of Trust a Chain of Trust can be established. RTM starts this chain by measuring the next component first before executing it. This way a continuous chain without any gaps with alternating measurement and execution flows can be established. Figure E.3 illustrates the concept of the Chain of Trust. Figure E.3.: Highlevel overview of a Chain of Trust [12] The Chain of Trust can be split into two segments. The part created by the TCP is also called Static Root of Trust for Measurement (SRTM). It has been clearly specified by the TCG and happens on each TCG compliant platform, identically, independently of the operating system. The second part is called Dynamic Root of Trust for Measurement (DRTM), which has to be generated by a Trusted Operating System (TOS) or equivalent authority. Compared to the static Chain of Trust there are no explicit specifications available for a dynamic Chain of Trust. XXXVII

154 E. The Trusted Platform Module Locality The TPM provides an unspoofable hardware mechanism for secure access of different platform components; this is called locality. The TCG TPM PC Client Specific TPM Interface Specification [10] defines locality as a concept that allows various trusted processes on the platform to communicate with the TPM such that the TPM is aware of which trusted process is sending commands. This trust scheme is implemented using dedicated ranges of LPC addresses and a new LPC "start" field. Six localities are defined: numbers 0-4 and Legacy. Only a TPM compliant to version 1.2 of the TPM specification offers this feature. Each locality has a specific meaning: Locality 4 - Trusted hardware. The platform hardware ensures that only trusted processes have access to this locality. Assertions should be made by the hardware DRTM. Locality 3 - Auxiliary components. These are optional components, which represent processes that will gain control after the trusted hardware at locality 4 but before the normal trusted process runtime (TOS) has control. The auxiliary component may or may not be part of the DRTM. Locality 2 - Trusted Operating System. The TOS gains control after the locality 3 and 4 processes have properly initialized the platform. Locality 1 - Environment set up by a Trusted Operating System. The TOS can provide access to locality 1, but must not necessarily use locality 1. Locality 0 - This locality provides access to the TPM for the SRTM and any other processes operating after the SRTM. Legacy Locality - The legacy locality provides backwards compatibility with version 1.1. It is the same as locality 0. Table E.2.: Locality Addresses [31] Locality System Address LPC Address 0 0XFED4_0xxx 0x0xxx 1 0XFED4_1xxx 0x1xxx 2 0XFED4_2xxx 0x2xxx 3 0XFED4_3xxx 0x3xxx 4 0XFED4_4xxx 0x4xxx XXXVIII

155 E. The Trusted Platform Module The chipset provides the locality mechanism. A reserved set of addresses correlates with the localities, as shown in table E.2. The chipset has the responsibility to protect those addresses from any process that does not match the locality. Key Concept The TPM manages cryptographic keys through the creation of a key hierarchy. Using the internal cryptographic components (RSA engine and TRNG) the TPM is able to create RSA key pairs securely inside the chip to ensure that the private part of such a pair can never leave the chip in decrypted form. Given that the created keys are intended to be used by the RSA engine, key lengths of 512, 1024 and 2048 can be generated. Furthermore, during key creation non-migratable keys, which are tied to the specific TPM, and migratable keys, which can be migrated to other TPM modules can be distinguished. Each new created key is equipped with a key password for authorization migratable keys have an additional migration password. The TCG defines a total of four different key types: Storage Keys Storage Keys are keys used for the encryption of arbitrary data or other cryptographic keys. This keys basically serve for the creation of the key hierarchy and the secure storage of keys on an external device outside the TPM and are also often called Wrapping Keys. An exceptional position within the storage keys has the Storage Root Key (SRK), which serves as the top of the key hierarchy and Root of Trust for Storage (RTS). Figure E.4.: Root of Trust for Storage - Key Hierarchy [12] XXXIX

156 E. The Trusted Platform Module Figure E.4 illustrates the architectural design of the RTS and the functional principle of the establishment of a key hierarchy. Signing Keys Signing Keys are used for signing arbitrary data, which can be both migratable as well as non-migratable keys. A special form of signing keys are the Attestation Identity Keys (AIK). These keys serve as an identification of the platform and cannot be migrated as they are tied to the platform. Binding Keys Binding Keys are the counterpart of signing keys. They are used for the encryption of small amounts of data and symmetric keys, which are employed to encrypt greater amounts of data outside of the TPM in a secure way. Like signing keys they can be both migratable as well as non-migratable. Legacy Keys Legacy Keys are a combination of signing and binding keys and can be used for encryption purposes and also for the creation and verification of digital signatures. Cryptographic Operations The integrated cryptographic engines inside of the TPM module offer a set of functions, which can be compared to those of a smartcard: Asymmetric encryption and decryption of arbitrary data blocks using the RSA algorithm. This operation is also called Binding, because the data is tied to the specific TPM and therefore also to the the platform, as long as a non-migratable key is used. Generation and verification of digital signatures of arbitrary data blocks using the RSA signature scheme. Creation of hash values of data according the SHA-1 standard Creation of true random numbers using a TRNG Despite some similarities with smartcards, these technologies must not be put on the same level. A smartcard generally authenticates a specific user, whereas the TPM module authenticates a specific platform. The major difference between TPM and a smartcard is the Platform Configuration Register (PCR) that permits additional functions: XL

157 E. The Trusted Platform Module Sealing Sealing is an enhanced version of binding. The idea behind sealing is that data is not only encrypted and tied to a specific platform but also the individual state the platform. Sealed data can only be restored again on the same platform, if the system is in the same configuration state, in which it was during sealing process. This can be achieved by including a subset of PCR registers in the encryption process. Sealed-Signing Like sealing, sealed-signing is an enhanced version of the RSA signature scheme. Here, in addition to the actual data, user-defined PCR values are introduced into the process of signature creation. This way a sender of a signed message can, besides his identity, additionally transmit the current state of the platform. The sealed-signing technique is, amongst others, used for remote attestation. Remote Attestation The process of providing integrity measurements to determine a platform s current configuration is called attestation. Basically the trustworthiness of a platform depends on the current state of software and hardware components. According to the Trusted Computing approach of the TCG the individual Platform Configuration Register represents the state of the system. Figure E.5.: Attestation procedure [12] XLI

158 E. The Trusted Platform Module Generally an attestation process is initiated by a remote system called a challenger. To guarantee the correctness of the transmitted data, the TPM signs the requested PCR values. The freshness of the transmitted data is given through a challenge response protocol in which the challenger sends a nonce (number used once) to the responding party. The nonce also gets signed together with the PCR values and is sent back to the challenger. Figure E.5 illustrates the attestation procedure. XLII