World Engineering Congress 2010, 2nd 5th August 2010, Kuching, Sarawak, Malaysia Conference on Engineering and Technology

y Education

ESTABLISHING TRUSTED PROCESS IN TRUSTED COMPUTING PLATFORM

1, 2, 3,4

Mohd Anuar Mat Isa1, Azhar Abu Talib 2, Jamalul-lail Ab Manan3, Siti Hamimah Rasidi 4 Information Security Cluster, MIMOS Berhad, Technology Park Malaysia, 57000 Bukit Jalil Kuala Lumpur, Malaysia. Email: {anuar.isa, atalib, jamalul.lail, hamimah.rasidi}@mimos.my

ABSTRACT
Since 1999, information security practitioners including researchers and developers have embarked on trusted computing as a new approach to enhance platform and infrastructure trust and at the same time enhance user privacy. Trusted computing had been driven by major industry players including IBM, HP, AMD, Intel and Microsoft. Today, most researchers use trusted computing to solve trust and integrity problems. However, they have only focused on enhancing or modifying existing TPM standard. Therefore, this paper clarifies the concept of establishing trust and its implementation for a secure platform. Keywords: trusted process, trusted computing, trusted software, trusted hardware, trusted platform module

INTRODUCTION
Trusted Computing Group (TCG) is an organization that develops and produces standard specifications for applying trusted computing solutions in various platforms. These specifications facilitate user and developer in designing trusted systems. With the current technology trend moving towards cloud computing, privacy is now a primary concern. In digital context, privacy is about preventing others from gaining access to information without the informed consent of its rightful owners. Cell phones, caller ID, credit cards, and Internet provide people with dramatic new levels of freedom and interaction that can enhance business processes and personal livelihood, but these innovations come with a privacy price tag. All of these systems are capable of providing information, including financial and personal data that most users assume to be confidential. The TCG believes that the ability to ensure such confidentiality through privacy controls is an essential prerequisite of a trusted system [1].

PROBLEM STATEMENT
The TCG has provided trusted computing specifications via TPM chip specifications which can be found embedded inside todays desktop or laptop main board. Circa 2008, proposed new a specification to support embedded devices such as mobile phone, PDA, tablet PC and etc. With all these specifications coming from the TCG group, the developer community lacks the understanding of how trusted platform can be implemented in a system. The main question coming from the community is How can we be assured device(s) and system(s) are trusted if we use trusted computing platform (e.g. TPM) as root of trust?. In order to answer this question, we need to refer to its definition, architecture and design of trusted platform as mentioned by TCG. In particular, we need to look at specific methods that had been implemented in trusted devices and some software layers in ensuring a trusted runtime environment. In this paper, we will discuss one particular method to establish a trusted process in a trusted platform.

TRUST SYSTEM BASED ON TRUSTED COMPUTING PLATFORM (TCP) Definition of Trust

We begin our discussion with some key definitions related to trusted computing. First, Trust means an entity can be trusted if it always behaves in the expected manner for the intended purpose [1]. Therefore, trust is a declaration by a well known authority that the platform can be trusted to behave properly for the intended purpose. This authority is prepared to issue an endorsement (e.g. credential or certificate) of the platform because it has already assessed the integrity of the platform. Trust is a complicated notion that has been studied and debated in different areas such as social science and humanities as well as computer science [2]. In fact, trust is a fusion of several elements of the platform that span the enterprise to consumer, including reliability, safety, confidentiality, integrity and availability. However, a possible definition to quantify trust is using the notion trustworthy. Trustworthy is the degree to which the (security) behavior of the component is demonstrably compliant with its stated functionality [3]. Defining trust to be quantified is only the first order of things. It is necessary but not sufficient. Next, is to clearly define Trusted Process. It refers to either a

ISSN XXXX-XXXX 200x FEIIC

World Engineering Congress 2010, 2nd 5th August 2010, Kuching, Sarawak, Malaysia Conference on Engineering and Technology Education

hardware-based or software-based process with the host platform that is trusted without the need for further inspection to perform as expressed by the host platform certificate [4]. Trusted process is an important element in the trusted platform because it defines the basis of how can processes in a system become trusted in a computing environment. The definition clearly spells out that a process can only be trusted if the platform is trusted and a platform gains its trusted credential through the platform testimonials issued by the platform makers. Thirdly, Trusted Computing Platform (TCP) [5] is the term the community has used for the implementation of the trusted components based on the TCGs specifications.

Trustworthiness of a Trusted Process

The TCG defines some key elements to evaluate trustworthiness of the hardware and software using root of trust in the security architecture. The Trusted Computing Platform (e.g. TPM) specifications are an industry attempt to build a series of roots of trust 1 in a computing platform. We could implement trusted process in physical machine or virtual machine by establishing root of trust in the architecture. A complete set of roots of trust has at least the minimum functionalities necessary to describe the platform characteristics that affect the trustworthiness of the platform [6]. Therefore, the owner of the system (e.g. user or manufacturer) needs to have well defined trust on the platform based on worth of trust 2 [5] on the hardware or software. To address this trustworthiness issue, the TCGs specifications propose these key elements to establish foundation (root) of trust for a platform (e.g. Figure 1): 1. Root of Trust for Measurement (RTM) 2. Root of Trust for Storage (RTS) 3. Root of Trust for Reporting (RTR)

Figure 1: Element of Trusted process.

Root of Trust for Measurement The TCP performs integrity measurement 3 of the platform by calculating and reporting of measurement digests of measured values4. These measurement values are representations of embedded data (e.g. option ROM), microcode (e.g. firmware), or program code, scanned and fetched to TPM by measurement agent, such as the CRTMs agent in TCG BIOS. Normal platform computing engine is typically controlled by Core Root of Trust for Measurement (CRTM). The CRTM refers to instructions executed by the platform when it acts as the RTM. The RTM is also the root of chain of transitive trust (e.g. Figure 2) and trusted process is the RTM for that trust domain [4]. Hence, combination of multiple CRTM (or trust domain) is represented as Trusted Building Block (TBB). The Trusted Building Block (TBB) is the combination of CRTM, TCP, contacts (joins) of CRTM to motherboard, and contacts of TCP to motherboard. The connection of CRTM to TCP is done through transitive trust of CRTM connection and TCP connection. The transitive trust (as shown in Figure 2) also known as
1 2

Root of trust is a starting point we trust the system (e.g. we need to trust the CPU to do execution of the instruction(s)). Physical protections and other techniques protect them against at least some types of malicious actions by an adversary with direct physical access [5]. Measurement is process of obtaining the identity of an entity [1]. The TPM supports cryptographic hashing of measured values and calculates the measurement digest by extending the value of a Platform Configuration Register (PCR) with a calculated or provided hash value using hashing algorithm (e.g. SHA-1) [7].

3
4

ISSN XXXX-XXXX 200x FEIIC

World Engineering Congress 2010, 2nd 5th August 2010, Kuching, Sarawak, Malaysia Conference on Engineering and Technology Education

inductive trust, is a process where root of trust gives a trustworthy description of a second group of functions [6]. Indeed, an interested entity can determine the trust it is to place in this second group of functions. If the interested entity determines that the trust level of the second group of functions is acceptable, the trust boundary is extended from the root of trust to include the second group of functions and then; the second group of functions can give a trustworthy description of the next group of functions, etc [6]. Indeed, in order to maintain the transitive chain of trust that is rooted in the CRTM, a trusted entity must measure the next entity to which it will transfer control [13].

Figure 2: Transitive trust applied to system boot from a static root of trust [6]. There are two different methods of establishing root of trust in the platform, namely, using either static root of trust for measurement (S-RTM) and dynamic root of trust for measurement (D-RTM). In S-RTM trust model, the integrity measurement processes start at a platform reset event and an immutable root (e.g. TCG-BIOS boot block) and continues to move forward to the next layer (refer to Figure 2). The benefits of this method include its simplicity and easiness to be implemented in standalone machine with a minimal number of elements in TBB. However, S-RTM running on a complex system can cause a large and unmanageable TBB; and of course, it will affect overall performance of the system. Besides that, if any of hardware component(s), microcode or firmware (e.g. BIOS, hard disk, WiFi, etc) in boot process change or get updated after trust is established, then some applications (e.g. Trusted Grub [8], Microsoft Bitlocker [9]) may not work at all or may display false error messages because there are changes in PCR(s) digests. In D-RTM, trust properties of components can be ignored (such as before loading virtual machine) until a secure event triggers and initializes the system; and then starts initialization of RTM for that domain [11]. Any components (trusted) before executing the D-RTM secure event will be excluded from TBB (dynamic TBB) and cannot be executed after trust properties of the system are established [11]. Using new security feature of processors (such as AMDs Secure Virtual Machine (SVM) architecture, Intels Trusted Execution Technology (TXT), and AMDs processor instruction (e.g. SKINIT)), these new instructions will enable some pieces of code be executed in an isolated environment [10]. Consequently, we do not need to trust the normal S-RTM; but only trust the code running in the isolated environment. Therefore, as long as the D-RTM become the code running in the isolated environment, we can trust the D-RTM as long as we also trust the processor. For example, Intel TXT works by creating a) Measured Launch Environment (MLE) that enables an accurate comparison of all the critical elements against a trustable sources, b) a secret protection via hardware-assisted method to protect memory snooping, and c) an attestation through the TPM to provide trust verification process and audit activities [11]. Root of Trust for Storage The RTS is the point from which all trust in protected storage is predicated through maintaining an accurate summary of values of integrity digests and sequence of digests [6]. The RTS provides protection of data in use by held in external storage devices within TCP. Normally, private keys generated within the TCP can be stored outside (encrypted) in a way that allows the TCP to use them later without ever exposing such keys in the clear outside the TCP. The RTS also provides the mechanism to ensure that release of information only occurs in a named environment (e.g. TPM_SEAL & TPM_UNSEAL use PCR(s) digest as part of encryption keys). The TCP may be implemented in practice to provide secure storage for an unlimited number of private keys or

ISSN XXXX-XXXX 200x FEIIC

World Engineering Congress 2010, 2nd 5th August 2010, Kuching, Sarawak, Malaysia Conference on Engineering and Technology Education

other data by using encryption to provide confidentiality and integrity for external blobs. The resulting encrypted file, which contains header information in addition to the data or key, is called a BLOB (Binary Large Object) and is output by the TCP and can be loaded within the TCP when needed [7]. Data protected by the RTS can migrate to other TCP but the platform identification (e.g. tpmProof 5) is only inserted into TCP internally generated and non-migratable information. Root of Trust for Reporting The RTR exposes the measurement digests stored in the PCRs (e.g. Figure 3) and attests to the authenticity of these measurement digests based on trusted platform identities (e.g. Direct Anonymous Attestation (DAA) protocol or Properties Based protocol). The trusted platform identities for RTR are defined by Attestation Identity Credentials for Attestation Identity Keys (AIK) generated by the TCP. The TCP creates digital signatures over the PCR values using an AIK [17]. The AIK credential creation process is outside the control of the TCP. However, the Certification Authority (CA) will attest (with the AIK credential) that the AIK is tied to valid Endorsement, Platform and Conformance credentials. Without these credentials, the AIK cannot prove that PCR values belong to a specific TCP. The migration of AIK from one TCP to another must be prohibited because it violates identity and privacy of a platform.

Figure 3: Measurement digests stored in the PCRs [6]. The RTR is responsible for establishing platform identities6, reporting platform configurations7, protecting reported values, and providing a function for attesting to reported values [17]. The RTR shares responsibility of protecting measurement digests with the RTS. The design and implementation of the interaction between the RTR and RTS should mitigate observation and tampering with the messages. It is strongly encouraged that the RTR and RTS implementation occur in the same package such there are no external observation points. For a silicon-based trusted device (e.g. TPM or MTM) this would imply that the RTR and RTS are in the same silicon package with no external busses.

TPM Hardware
TCG have completed specifications version 1.2 to implement a trusted process using the TPM hardware. The TPM hardware along with its supporting software and firmware provides the platform root of trust. It is able to extend its trust to other parts of the platform by building a chain of trust, where each link extends its trust to the next one. TCG requires the TPM be physically protected from tampering. This includes physically binding the TPM module (if it were physically a discrete part) to the other physical parts of the platform (e.g. motherboard) such that it cannot be easily disassembled and transferred to other platforms. These mechanisms are intended to resist tampering. Tamper evidence measures are to be employed to enable detection of tampering upon physical inspection [6]. Figure 4 shows mixture of various roots in the platform using TPM [1].

TpmProof is a value that provides the uniqueness to values stored off of the TPM. By invalidating tpmProof all off TPM blobs will no longer load on the TPM [14]. 6 The RTR is a cryptographic identity (e.g. EK) used to distinguish and authenticate an individual TCP. The TCP uses the RTR to answer an integrity challenge.
7

Reporting - supply an accurate digest of all sequences of presented integrity metrics.

ISSN XXXX-XXXX 200x FEIIC

World Engineering Congress 2010, 2nd 5th August 2010, Kuching, Sarawak, Malaysia Conference on Engineering and Technology Education

Figure 4: Root of trust of TPM [1].

CONCLUSION & FUTURE WORK

This paper presented the concept of establishing trusted process based on TCG design. We focus our discussion on fundamental components of trusted computing systems and how to achieve trustworthiness within the system. The trusted process which is established will address the risks caused by inadequate security; i.e. trusted process assures that every platform comes with strong hardware based protection (TPM chip). Furthermore, a system that implements trusted process will help protect the most sensitive information, such as private and symmetric keys, from theft or use by malicious code. When used with privacy enhancing technology, the trusted environment will help permeate a more conducive environment for pervasive business activities.

REFERENCES
[1] Vincent J. Zimmer, Shiva R. Dasar, Sean P. Broga, Trusted Platforms UEFI, PI and TCG-based firmware (pp 8), white paper by Intel Corporation and IBM Corporation, 2009 [2] Xin Huang, Yuxing Peng, An Effective Approach for Remote Attestation in Trusted Computing (pp 2), International Symposium on Web Information Systems and Applications, WISA 2009. [3] Benzel, T.V., Irvine, C.E., Levin, T.E., Bhaskara, G., Nguyen, T.D., Clark, P.C. Design principles for security.Technical Report NPS-CS-05-010, Naval Postgraduate School, September 2005 [4] TCG, TCG PC Client Specific Implementation Specification For Conventional BIOS (pp 15-75), version 1.20 final revision 1.00 (2005) [5] Sean W. Smith, Trusted Computing Platforms: Design and Application (pp 1-7), Springer 2005 [6] TCG, TCG Specification Architecture Overview (pp 1-24), Specification Revision 1.4, 2nd August 2007 [7] TCG, Protection Profile PC Client Specific Trusted Platform Module TPM Family 1.2 (pp 6-10), Level 2, Version: 1.1; July 10, 2008 [8] Bernhard Kauer. OSLO: Improving the security of Trusted Computing (pp 610), 16th USENIX Security Symposium, August 2007. [9] Microsoft, BitLocker Drive Encryption: Scenarios, User Experience, and Flow (pp 4-6), May 16, 2006, webpage:http://www.microsoft.com/whdc/system/platform/hwsecurity/BitLockerFlow.mspx [10] Cong Nie, Dynamic Root of Trust in Trusted Computing (pp 2-3), TKK T-110.5290 Seminar on Network Security, 2007 [11] Intel, Intel Trusted Execution Technology (pp 5-6), whitepaper, 2010, website: www.intel.com/Assets/en_US/PDF/whitepaper/323586.pdf [12] Sundeep Bajikar, Trusted Platform Module (TPM) based Security on Notebook PCs - White Paper (pp 17), Mobile Platforms Group Intel Corporation, 2002 [13] TCG, TCG EFI Platform Specification (pp 6), Version 1.20, Final Revision 1.0, 7 June 2006 [14] TCG, TPM Main Part 1 Design Principles (pp 51), Specification Version 1.2, Level 2 Revision 103, 9 July 2007

ISSN XXXX-XXXX 200x FEIIC