TLS-ENFORCED ATTESTATION. A Project. California State University, Sacramento. Submitted in partial satisfaction of the requirements for the degree of

Transcription

1 TLS-ENFORCED ATTESTATION A Project Presented to the faculty of the Department of Computer Science California State University, Sacramento Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in Computer Science by Jonathan Buhacoff SPRING 2013

2 TLS-ENFORCED ATTESTATION A Project by Jonathan Buhacoff Approved by:, Committee Chair Ted Krovetz, Ph.D., Second Reader Isaac Ghansah, Ph.D. Date ii

3 Student: Jonathan Buhacoff I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the project., Graduate Coordinator Behnam Arad, Ph.D. Date Department of Computer Science iii

4 Abstract of TLS-ENFORCED ATTESTATION by Jonathan Buhacoff In client-server environments, clients need a mechanism to determine that a server can be trusted to provide services to the client. Transport layer security (TLS) provides a mechanism to trust the server s identity by relying on certificates signed by trusted authorities. The client must implicitly trust that the server s administrators maintain the server with trusted software, by installing security patches for example. Increasingly, clients will require more explicit assurances that a server can be trusted. It is possible to obtain such assurances in the form of an attestation by a Trusted Platform Module (TPM) on the server. The goal of this project is to develop a system that allows clients to determine that a server is running trusted software by leveraging the TLS protocol to enforce that a previously accepted attestation is still valid each time the client connects to the server., Committee Chair Ted Krovez, Ph.D. Date iv

5 ACKNOWLEDGEMENTS I would like to extend very sincere and deep thanks to Professor and Department Chair Dr. Cui Zhang for her strong support and to Professors Dr. Ted Krovetz and Dr. Isaac Ghansah for supervising my work. I also thank Uttam Shetty and Raghuram Yeluri of Intel Corporation for their support and encouragement. I would also like to acknowledge Hal Finney of PGP Corporation and Kent Yoder of IBM, who have greatly contributed to my understanding of the subject through their published source code and numerous online postings. My wife Adrienne deserves special recognition for being the only person in the world who was still married to me at the time of this writing. The last 4 months were dedicated to this project, but all the rest of my days are dedicated to her. v

6 TABLE OF CONTENTS Page Acknowledgements...v List of Figures... ix List of Abbreviations...x Chapters 1. INTRODUCTION Background Software-based Security Trusted Computing Group Remote Attestation Motivation Goal ARCHITECTURE Transport Layer Security Trusted Platform Module Trust Remote Attestation Certificates Summary vi

7 3. IMPLEMENTATION Trust Authority Server Attestation Client Trust CONCLUSION FUTURE WORK Runtime Measurement User-Space Measurement Global Knowledge Client Attestation PCR Contents as X.509v3 Extensions Software Updates Automation Trust But Verify Appendix A. Source Code...37 config.h config.c hex.h hex.c hex2bin.c vii

8 showpcr.c extendpcr.c aikpublish.c aikchallenge.c aikrespond.c aikquote.c aikqverify.c create_tpm_key.c Appendix B. Demonstration...86 Client Server Appendix C. Security Tests...88 Appendix D. OpenSSL...91 Downloading OpenSSL Installing OpenSSL Appendix E. Trousers...92 Downloading Trousers Installing Trousers, TPM Tools, and TPM Engine for OpenSSL Bibliography...94 viii

9 LIST OF FIGURES Figures Page Figure 1. Client view of server using regular certificate authority... 2 Figure 2. Layers of abstraction... 3 Figure 3. Extending a PCR... 5 Figure 4. Illustration of a TPM Quote... 9 Figure 5. Client view of server using trust authority Figure 6. Relationship of Client, Server, and Certificate Authority Figure 7. Combining TLS and TPM Figure 8. Provisioning client and server certificates Figure 9. Output of tpm_version Figure 10. Content of pcr.manifest Figure 11. Example of failure to use sealed TPM private key Figure 12. Output of openssl rsa -in aik.pubkey -text -pubin -noout Figure 13. Output of aikqverify ix

10 LIST OF ABBREVIATIONS AIK BIOS CA CSR DAA DNS EK IP Nonce Attestation Identity Key Basic Input/Output System Certificate Authority Certificate Signing Request Direct Anonymous Attestation Domain Name System Endorsement Key Internet Protocol Number used only once NVRAM Non-Volatile Random Access Memory OS PCR PEM RFC RSA Operating System Platform Configuration Register Privacy Enhanced Mail Request for Comments Public key cryptography algorithm created by Rivest, Shamir, and Adleman SSL Secure Sockets Layer; SSLv2 for version 2; SSLv3 for version 3 TCG TLS TPM Trusted Computing Group Transport Layer Security, successor of SSL Trusted Platform Module x

11 1 Chapter 1 1. INTRODUCTION 1.1 Background In cloud computing and other client/server environments there is always a risk of attack to the server that would result in compromise of the client s confidentiality and data integrity. Server environments range from software as a service, in which a provider is completely responsible for securing and monitoring its servers, to unmanaged dedicated hosting, in which a provider is only responsible for monitoring the network and maintaining the server hardware, and customers are completely responsible for the security of their servers [1]. The precautions implemented by server operators may include firewalls, anti-virus software, and intrusion detection systems. Typically, clients are not aware of the specific security measures implemented by server operators as shown in Figure 1. Clients implicitly trust that the servers they use are free of any malware, and that the software installed on the servers is suitable for accomplishing the client s intended purpose. A client s intended purpose may include enforcing security and policy constraints on data and processes in addition to providing confidentiality and data integrity.

12 2 Figure 1. Client view of server using regular certificate authority 1.2 Software-based Security Anti-virus software relies on being able to scan individual files on disk or in memory. Anti-virus software is typically signature-based, which means that files are scanned and compared against a database of known malware characteristics, or signatures, in order to identify possible malware. Another kind of anti-virus software described by [2] attempts to detect polymorphic viruses, which are viruses that deliberately change the way their code looks in order to avoid signature-based detection. Both types of anti-virus rely on being able to scan individual files which means they have two vulnerabilities: first, the list of files to scan can be manipulated so it does not include the malware; and second, the apparent contents of the files can be manipulated to return fake data for specific files in order to hide the presence of the malware. These vulnerabilities are always present in addition to any implementation-specific vulnerabilities of any security software. Host-based intrusion detection systems typically check the integrity of known system files [3] and may also check the behavior of running processes [4]. Such intrusiondetection systems have the same vulnerabilities as the anti-virus software, and in addition they also have a third vulnerability related to monitoring processes: malware that is able

13 3 to run at the operating system kernel level or as a device driver will have direct access to hardware and will be harder to track by a process monitor or by intercepting system calls. Modern computing systems are comprised of software that is stacked upon other software, each layer providing useful abstractions of the layer below it, and the layers extending down to the hardware drivers that abstract and control access to the computing hardware and peripherals as shown in Figure 2. A consequence of this architecture is that lower levels of software provide an environment for higher levels. In other words, higher levels of software can only perceive what lower levels make available. Because of this architecture, any security system that is rooted in software has the vulnerability that a compromise in lower levels of the software stack can manipulate the computing environment to avoid detection by a security system operating at a higher level in the software stack. Figure 2. Layers of abstraction It is not possible to mitigate this vulnerability by adding more levels of software, because there will always be a lowest level. If it s possible to install or upgrade the software at the

14 4 lowest level then it is also possible to compromise it [5]. For this reason, clients who need assurances about the software running on the system cannot really trust a system with security rooted in software. The root of trust must therefore be in the hardware, where malware cannot compromise it due to hardware-enforced inability to overwrite its functions. 1.3 Trusted Computing Group An association of many software and hardware vendors known as the Trusted Computing Group (TCG) has created specifications for a Trusted Platform Module (TPM), which is a hardware component that is suitable for use as the root of trust in a security system [6] [7]. The TCG specifications provide the basis for a combined hardware and software solution that computer manufacturers can implement in order to enable software running at even the highest levels in the software stack to detect tampering with the firmware, boot loading code, operating system kernel, and any other trusted software at lower levels. Every TPM is able to internally perform encryption, decryption, and hashing. A TPM also contains a bank of 24 registers, each one with a capacity to store 20 bytes of data [8]. These are called Platform Configuration Registers (PCR) because they are used to store information about the computer system in which the TPM is installed. The PCRs are said to be volatile memory because they lose their contents when the power is reset. A TPM also contains some non-volatile memory called NVRAM that can be used to store important information across power cycles. A TPM has three key features that make it suitable to use as the root of trust for a computing system.

15 5 First, only the TPM is able to reset the contents of any PCR. During power-on, each PCR is initialized with 20 bytes of zero [9]. From that point on, any hardware or software external to the TPM can only extend the contents of a PCR, not reset it. When a PCR is extended, the 20 bytes are replaced with the result of a function of both its previous contents and the new data as shown in Figure 3. The function used is the Secure Hash Algorithm (SHA-1) which is a one-way function. This means that external hardware and software determines what data is extended into a PCR but cannot control what will be the PCR s new contents. Figure 3. Extending a PCR Second, the TPM can provide a quote, which is a digitally signed report of the contents of all or selected PCRs [10]. The quote is signed by a private key that is created and used exclusively by the TPM internally and cannot be read by any hardware or software external to the TPM. The corresponding public key can therefore be used to determine that a quote was digitally signed by the TPM and not by anything else, especially

16 6 software. A quote is also called an attestation of the platform state, and the private key is also called an Attestation Identity Key (AIK). The public key must sent securely to challengers as described in the next section, Remote Attestation. Third, each TPM contains an Endorsement Key (EK) that can be used to authenticate the TPM itself, so that software relying on TPM quotes can trust that the corresponding AIK exists in a real hardware TPM and not in any other software, such as a TPM emulator [11]. When the TPM in a server is enabled, these three key features are combined to create a root of trust in the following way: Starting at boot, any software that executes is first measured and its measurement is extended into a PCR. Measuring software means loading its binary code and using it as an input into a one-way function in order to produce a short summary of the code, known as a digest. For example, before the CPU starts executing the BIOS, it first measures the BIOS and then extends a PCR with the measurement [12]. The BIOS then needs to load some drivers and the operating system kernel, but before doing so it first measures each one and extends a PCR with the measurements. At each step, the contents of the PCR bank are modified but they always reflect the entire history of extensions since power on. There are two approaches to leveraging the contents of the PCR bank. The transparent approach assumes detailed knowledge of the boot process and of the software that is expected to be present on the system. With a transparent approach it is possible to predict the contents of the PCR bank by performing the same extension operations in software. The opaque approach does not assume detailed knowledge of the boot process, but

17 7 requires confidence that the system is currently running trusted software. With an opaque approach it is possible to simply record the current contents of the PCRs and compare them to the contents after future boots. With a careful implementation of either approach, it is possible for system administrators who install anti-virus and intrusion detection software to trust that the computing environment is not being manipulated by malware running at a lower level in the software stack. 1.4 Remote Attestation It is important to consider the security of the public key used to verify TPM quotes. If software running a TPM-enabled server relies on the AIK public key to verify TPM quotes, it is still vulnerable to malware at a lower level hiding the real TPM and providing instead a software-simulated TPM, replacing the corresponding public key with a public key for the simulated TPM. Due to the nature of software-based security, it is impossible to completely eliminate this possibility for software running on the same machine. A practical solution to this problem is called Remote Attestation, in which an external party verifies the quote. In a Remote Attestation model, software running on a server does not attempt to determine whether its own platform is trusted. Instead, it allows challengers external to the platform to request TPM quotes from the platform and it is the responsibility of challengers to verify the authenticity of the TPM quote and to make trust decisions based on its contents. Challengers must have a means to determine that the AIK used to sign the quote is protected by a real TPM, and they must be able to determine whether the contents of the server s PCR bank indicate that the server is running only trusted software.

18 8 Before Remote Attestation can take place, the challenger must first authenticate the server s TPM. This involves requesting a proof from the server that the TPM is authentic. The proof may include an Endorsement Key from the manufacturer, the Attestation Identity Key, as well as Conformance Credential and Validation Credential from quality assurance laboratories [9]. The protocol for Remote Attestation is that the challenger creates a challenge comprised of an encrypted nonce and list of PCRs to be quoted. A nonce is a number that is used only once within the context of a cryptographic system, in this case to prevent replay attacks. The challenger sends the challenge to the remote server. Because the challenge is encrypted using the AIK public key, and because the corresponding AIK private key is usable only by the remote server s TPM, the remote server must use its TPM to decrypt the challenge. The remote server also uses its TPM to generate a quote for the requested PCRs. The response is the TPM quote, which contains the decrypted challenge and the selected PCR values as shown in Figure 4. The quote is digitally signed by the AIK private key. The remote server sends the response to the challenger. The challenger verifies the quote using the known AIK public key and the challenge nonce.

19 9 Figure 4. Illustration of a TPM Quote 1.5 Motivation In cloud computing, and other client/server environments in which it is desirable to implement Remote Attestation, there is a very prominent inconvenience: clients must not only be able to associate the contents of the server s PCR bank to known combinations of trusted software, but also that association must be checked each time the client must make a decision to trust a server, and the client must verify the server AIK used to sign the quotes belongs to a real TPM. This adds a lot of complexity to even the simplest client/server applications. This project is motivated by the desire to use Remote Attestation in cloud computing and client/server environments without adding complexity to clients. 1.6 Goal The goal of this project is to develop a system in which a client may rely on Remote Attestation to make trust decisions without adding the above-mentioned complexity. Specifically, since the TLS protocol implementation is ubiquitous in clients, it is the goal

20 10 of this project to develop a system in which clients leverage TLS and its related infrastructure in order to verify a server s platform characteristics in addition to its identity on every connection to a remote server, as shown in Figure 5. Figure 5. Client view of server using trust authority

21 11 Chapter 2 2. ARCHITECTURE 2.1 Transport Layer Security Every connection using Transport Layer Security (TLS) begins with a handshake in which the client and server agree on an encryption key to protect the connection [13]. The handshake is a critical event because it aims to ensure the confidentiality and integrity of the connection. The TLS handshake ends successfully when the client and server have agreed on a set of cryptographic algorithms and protocols to use for the connection, have authenticated each other, and have agreed upon a share secret key to encrypt data transmitted between them [13]. The TLS protocol has evolved since its inception as the Secure Sockets Layer (SSL) to mitigate new threats as they are discovered. In order to preserve compatibility with older clients and servers, many clients and servers typically allow a handshake using a previous version of the protocol and do not strictly require using only the latest version. This compatibility-preserving behavior has been used to attack TLS connections, by intercepting the protocol negotiation phase of the handshake and impersonating to both sides that the other side only supports older versions of TLS or SSL -- versions that have exploitable vulnerabilities [14]. In order to defend against this attack, the protocol proposed in this project is only defined for TLS 1.2 as specified in RFC 5246, with the additional requirement that both clients and servers be configured to reject previous versions of the protocol, namely SSLv2 [15] and SSLv3.

22 12 In a TLS connection, the server must typically authenticate itself to the client. In some environments, clients must also authenticate themselves to the server. This project focuses on the integration of Remote Attestation into server authentication, and leaves the integration of Remote Attestation into client authentication for future work. The authentication in TLS is implemented using RSA encryption. The server generates an RSA key pair, which is comprised of one private key and one public key. The private key is stored on the server and the public key is either provided to its clients or certified by an authority as shown in Figure 6. The key pairs have the characteristic that data encrypted using the public key can only be decrypted using the private key. In TLS, clients authenticate the server by sending a challenge encrypted using the server s public key which is known to the client. If the server is able to decrypt the challenge and reply with its decrypted contents, it demonstrates possession of the corresponding private key. Figure 6. Relationship of Client, Server, and Certificate Authority It is important to note that server authentication in TLS only provides trust in the identity of the server. In order for the client to verify that the server is running specific software that is trusted to comply with the client s security expectations, other mechanisms are needed. However, if it s possible to secure the server s TLS private key such that it is

23 13 only usable when the server is running trusted software, then a successful TLS connection requires use of that private key to decrypt the client s challenge and thus demonstrates that the server is indeed running trusted software, as shown in Figure 7. Figure 7. Combining TLS and TPM 2.2 Trusted Platform Module The Trusted Platform Module (TPM) is a hardware-based root of trust for a computing platform. In this project, the platform containing the TPM is the remote server. The TPM can create and store RSA private keys and has a bank of 24 registers. Each register is called a Platform Configuration Register (PCR) and can only be reset internally by the TPM. All other software and hardware external to the TPM can only extend the value of the register. This means that the current value of any PCR is a consequence of the entire history of extensions to that PCR since power-on. The TPM is also able to provide

24 14 digitally signed reports of the current contents of all or selected PCRs. These digitally signed reports are also called quotes. The remote server administrator uses the TPM to create at least one special-purpose RSA key called an Attestation Identity Key (AIK), and when a quote is requested it is signed using the AIK private key. It is important to note that the AIK private key is only readable to the TPM. Digital signatures produced by a TPM are therefore considered secure once the AIK public key has been verified as belonging to a real TPM. There are two distinct ways to verify that an AIK comes from a real TPM. The first way is to use a Privacy CA [9]. The Privacy CA maintains a directory of all TPM manufacturers and their endorsement certificates. The endorsement certificates are X.509 certificates containing RSA public keys corresponding to the endorsement keys that manufacturers place in the TPM. In the case that a manufacturer has not provided an endorsement credential, or has not published its endorsement certificate, it is possible for the system administrator to create a local endorsement key and corresponding certificate, and then generate endorsement credentials to import into the TPM. The local administrator must then coordinate with the Privacy CA to add the local endorsement certificate to the list of known manufacturers. The second way is to use a mechanism called Direct Anonymous Attestation (DAA) which relies on a group signature scheme [16] to prove that a TPM is a member of a group known as real TPMs, and can handle compromised keys [17]. For this project, it does not matter which of the two mechanisms is used to verify the AIK.

25 15 The TPM s ability to create new RSA key pairs is complemented by its ability to protect the private keys in different ways. The protection to apply to a private key is determined at the time the key is created by the person or software that requested creation of the key. A private key can be migratable or non-migratable. A migratable private key can be exported by the TPM in an encrypted format that can then be imported by another TPM. A non-migratable key can only be exported in an encrypted format that is readable only by the same TPM. A private key can be protected so that it can only be used to encrypt and decrypt data on the same platform on which it was created, and only when the PCR bank has specific contents. This is called sealing. It s possible to seal a key to the PCR bank s current contents or to any other contents, such as expected future contents [10]. A sealed key can only be used when the PCR bank s contents match the conditions specified by the sealed key. This is enforced internally by the TPM. When data is encrypted using a sealed key, it is called sealed data. If a private key is used to encrypt data that is bound to the local TPM but not to any specific PCR contents, it is called a binding key. Because the contents of the PCR bank, also known as PCR values, are formed during the boot process, the PCR values reflect the combination of software running on the system. According to the TCG specification, TPMs are shipped disabled and must be enabled by the owner of the hardware in an opt-in system [9]. In order to enable the TPM, the system owner must reboot the server and enter the BIOS configuration screen in order to clear and enable the TPM. Many TPM operations require an authorization password, starting

26 16 with the act of taking ownership of the TPM after enabling it. Therefore, use of the TPM strongly implies the authorization of the system owner. 2.3 Trust It is the client s responsibility to define what constitutes a trusted server. The client must associate specific PCR contents with a trust indication -- either trusted or untrusted. In practice, at least one PCR and its content must be defined as indicating that the server is running trusted software. It is not necessary to maintain a list of untrusted platforms because anything that is not explicitly listed as trusted is considered to be untrusted. The server administrator must know what PCR values correspond to trusted software, either by using the transparent method or the opaque method. The transparent method requires detailed knowledge of the platform boot process and digests of all measured components in order to compute an expected PCR value. The opaque method requires provisioning a trusted system in an isolated environment and recording its PCR values as a trusted configuration. For this project, it does not matter which method is used to determine the trusted PCR values, but the opaque method was chosen for its simplicity. In real-world use, the opaque method could be cumbersome to manage for a large number of servers with different configurations. The server administrator must securely distribute the trusted server certificate to clients. Clients using the certificate must trust that the proper verification was done for the server s platform characteristics as well as its identity.

27 Remote Attestation Before sending data to a remote server, a client must first verify that the remote server is running trusted software. This is accomplished using Remote Attestation. The typical procedure for Remote Attestation is that the client, having knowledge of the server s AIK, sends a challenge to the server accompanied by a list of PCRs that should be quoted. The server forwards the challenge to the TPM and obtains the TPM quote, which contains the contents of the specified PCRs, the challenge, and a digital signature created by the AIK that covers both the PCR contents and the challenge. The server replies to the client with the TPM quote. The client then verifies the quote using the server s known AIK. As time passes since the creation of a TPM quote, the chance that the server s state has changed continues to increase. If old TPM quotes are used in decision-making, the client risks that the server is no longer in a trusted state. Therefore, unless the client has an assurance that the server has not changed since the last quote, a TPM quote must be obtained each time a client makes a decision to trust the server. In this project, the goal is to avoid the need to perform the quoting procedure each time the client connects to a remote server. If the server seals a private key to a specific set of PCRs and the client associates the corresponding public key to the same set of PCRs, and if that key pair is used to authenticate the server during a TLS connection, then the client knows that successful connections demonstrate the server is running trusted software. In order to avoid adding complexity to the client, the task of associating the server key to a set of PCRs is delegated to a trust authority, which then issues a certificate to the server as shown in Figure 8.

28 18 Figure 8. Provisioning client and server certificates 2.5 Certificates In TLS, the server sends its public key to the client. However, if the client does not already know the server s public key, it cannot trust a key provided by the server. This is because an attacker can intercept the handshake and can provide its own public key instead of the server s public key [18]. The client would then encrypt the challenge using the attacker s public key, which the attacker could trivially decrypt and reply with the correct decrypted content. To mitigate this threat, clients need either a trusted directory of server public keys that can be referenced when connecting to a new server, or a way to verify that a particular public key is associated with a particular server. Internet servers typically obtain certificates from a well-known company, called a Certificate Authority (CA), which associate the server s public key with the server s address. There are many such companies. The certificates are typically in a format called

29 19 X.509, which is comprised of the server s address and public key, and a digital signature by the CA that authenticates the information on the certificate. Clients are responsible for maintaining a list of trusted CAs. When a client connects to a remote server, the client receives the server s public key in X.509 certificate format that also includes the server s address and the CA that issued the certificate. The client can then check that a listed CA issued the certificate, and once the CA is found in the list the client can use the CA public key to verify the digital signature on the server certificate. In this project, the trust authority is a CA that associates a set of PCR values comprising the trusted platform characteristics with the server identity, and issues a server certificate that covers both. 2.6 Summary The project integrates the TLS protocol and the TCG specification to create a mechanism that allows a client to assert that a server is running trusted software simply by successfully establishing a TLS connection with that server. The project is comprised of the following components: server, trust authority, and client. The server administrator creates an RSA key pair in which the private key is sealed by the TPM to a specified set of PCR values indicating the server is running trusted software. The public key is submitted to the trust authority for certification. The trust authority verifies that the public key submitted by the server corresponds to a private key sealed by that server s TPM to a specific set of PCR values, and that the server s AIK corresponds to a real TPM. The trust authority sends a quote request to the server, including an encrypted random nonce as the challenge and the specified set of

30 20 PCR values. When the trust authority receives the TPM quote reply from the server, it can verify that the server s PCR values are trusted and it knows the server s AIK. The trust authority then signs the server s public key. The trust authority must be trusted by the client to provide assertions of the server s platform characteristics, namely its PCR contents, and the fact that the server s TLS private key is sealed to a specific set of PCR values. The trust authority maintains a list of PCR values indicating the server is trusted. The client maintains a list of trust authorities. When the client connects to the server, it follows the normal TLS procedure of checking that the server certificate was signed by a trusted CA, in this case a trust authority. Unlike typical TLS applications, if the server certificate is not signed by the trust authority, it must be rejected - the user must not be prompted to accept the certificate. This is usually a configurable behavior in TLS libraries used by application software. The client can then connect to the server using TLS and have assurance that the server s private key is sealed in the TPM to a set of PCR values that indicates the server is running trusted software.

31 21 Chapter 3 3. IMPLEMENTATION To demonstrate real-world usage, the trust authority, server, and client, should be installed on separate computers. It is also possible to install them all on a single computer in order to quickly experiment with the solution proposed by this project. 3.1 Trust Authority When a server requests a trust certificate, the trust authority must challenge the server and evaluate the response. In this section, the trust authority will be prepared to receive requests. The procedure for approving requests will be detailed in a later section Install OpenSSL The OpenSSL library is required for compiling the source code provided with this project and the OpenSSL tool is required for following the procedure outlined below. Please see Appendix D, OpenSSL, for detailed instructions on how to download and install OpenSSL Build the source code published in Appendix A The aikchallenge and aikqverify tools will be needed to authenticate the server s AIK and platform characteristics. Due to the fact that server used to test this project has a TPM with an endorsement key for which the manufacturer has not published a complete certificate chain, the aikchallenge program was modified to allow skipping the endorsement certificate validation. This hack should be disabled for real-world use. The commands to build the tools are: gcc -o aikchallenge aikchallenge.c -lcrypto

32 22 gcc -c aikqverify.c gcc aikqverify.o -o aikqverify -lcrypto -ltspi Create the trust authority key pair The trust authority private key will be used to sign server certificates. In the following steps, openssl prompts for a password. The trust authority administrator can choose any password, but it must be remembered in order to sign certificates later. In the commands below, a backslash at the end of a line indicates the next line is a continuation. openssl genrsa -des3 -out ca.key 1024 openssl req -new -key ca.key -subj "/C=US/ST=California/L=Sacramento/O=CSUS/OU=ECS/CN=TrustAuthority" \ -out ca.csr openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt echo 01 > serial echo >> serial Publish the CA certificate It is assumed from this point on that a copy of the file ca.crt is provided to all clients securely. It is important to copy it securely because if an attacker intercepts the CA certificate and replaces it with the attacker s own certificate, the attacker will be able to create its own server certificate with fake PCR contents and it will accepted by victims. The secure copy mechanism can be SFTP, SSH, or by telephone confirmation of certificate fingerprints.

33 Server The server used in this project is running GNU/Linux 2.6. The server must be initialized with the following sequence of actions: - Install OpenSSL, Trousers, Trousers TPM Tools, and the Trousers TPM Engine for OpenSSL - Build the source code published in Appendix A - Enable the TPM and take ownership - Create an AIK - Create a TLS key pair sealed to current PCR values - Submit TLS public key to trust authority for certificate - Install TLS certificate - Listen for TLS client connections using TLS certificate Detailed instructions to complete each step are provided in this section and supplemented in the appendices Install OpenSSL and Trousers Please see Appendix D, OpenSSL, for detailed instructions on how to download and install OpenSSL. Please see Appendix E, Trousers, for detailed instructions on how to download and install Trousers, Trousers TPM Tools, and Trousers TPM Engine for OpenSSL.

34 Build the source code published in Appendix A Build the source code published in Appendix A. This step requires the OpenSSL and Trousers libraries. The tss_err.o file is created by the TPM Quote Tools package. In the commands below, a backslash at the end of a line indicates the next line is a continuation. gcc -c hex.c -o hex.o gcc -c config.c gcc -o hex2bin hex2bin.c gcc -o showpcr showpcr.c -ltspi gcc config.o hex.o -o extendpcr extendpcr.c -ltspi gcc config.o hex.o -o create_tpm_key create_tpm_key.c -ltspi -lssl gcc getcert.o remote.o tss_err.o config.o hex.o -o getcert -lcrypto -ltspigcc config.o \ hex.o -o aikpublish aikpublish.c -ltspi gcc config.o hex.o -o aikrespond aikrespond.c -ltspi Enable the TPM and take ownership Enable the TPM and take ownership using the procedure described by Habets [2]. If the BIOS software on the server has TPM support, the TPM must be enabled using the BIOS [3]. If the BIOS software lacks TPM support, the following commands provided by TPM Tools can be used. Fig. 9 illustrates sample output from the tpm_version tool. tpm_version tpm_setpresence --assert tpm_clear --force tpm_setenable --enable --force

35 25 tpm_setactive --active tpm_takeownership -u -y TPM 1.2 Version Info: Chip Version: Spec Level: 2 Errata Revision: 2 TPM Vendor ID: STM TPM Version: Manufacturer Info: 53544d20 Figure 9. Output of tpm_version A lot of the commands used next require the TPM owner password. To prevent the password from appearing in the Linux process list, the programs must either prompt for the password, or read it from an environment variable, or read it from a file. Switch to the /var/local directory where the work will be done and write the TPM owner password into the file tpm.owner.secret using an editor such as vi Create the AIK Create the AIK in /var/local. The getcert command takes a single parameter that is the file to which to write the endorsement certificate. The aikpublish command takes the endorsement certificate file as input, and produces two files: aik.proof is a public file containing the AIK public key, information about the TPM, and a copy of the endorsement certificate; aik.blob is an encrypted file containing the AIK private key. cd /var/local getcert ekcert aikpublish ekcert aik.proof aik.blob Create the sealed TLS private key Create a TLS key pair sealed to current PCR values. Fig. 10 illustrates sample output.

36 26 showpcr > pcr.manifest 0 891eb0b556b83fcef1c10f3fa e34f8f91 17 bfc3ffd7940e9281a3ebfdfa4e a3f55d8 18 dc3831d76dbb34f8906c1f9e14fc99ed227bb d4c4f0eecb20a1d2b512ae80d7df6af612d Figure 10. Content of pcr.manifest create_tpm_key ssl.tpm.key The create_tpm_key command automatically uses the pcr.manifest file in the current directory. This should be improved in future work to accept command line parameters for the PCR list and the owner authorization secret file. The output of the create_tpm_key command is a file that contains an encrypted private key and a public key. The encrypted private key can only be read by the TPM Request the TLS certificate Use OpenSSL to create a Certificate Signing Request (CSR). In the command below, the subject is arbitrary but the CN component should be set to the server s IP address or DNS hostname, whichever will be used by clients to access the server. openssl req -keyform engine -engine tpm -key ssl.tpm.key -new -subj "/C=US/ST=California/L=Sacramento/O=CSUS/CN= " -out ssl.tpm.csr A CSR is signed by the private key, which is sealed to specific PCR values. If the current PCR values do not match those to which the key was sealed, the command will fail with an error message similar to that shown in Fig :error: D:tpm engine:tpm_rsa_priv_enc:request failed:e_tpm.c:1104: :error:0D0C3006:asn1 encoding routines:asn1_item_sign:evp lib:a_sign.c:279: Figure 11. Example of failure to use sealed TPM private key

37 27 Submit the CSR to the trust authority and receive the signed certificate. In a demonstration, this requires copying the files aik.proof, and ssl.tpm.csr to the trust authority, following the attestation steps in section 3.3, creating the certificate, and copying the certificate to the server. The certificate filename is assumed to be ssl.tpm.crt Install the TLS certificate For demonstration, the TLS certificate can simply be copied from the trust authority to the server. In real-world use, it would further need to be placed in a location specific to the web server software in use Listen for TLS connections Use the OpenSSL s_server tool to listen for TLS connections. In the command below, the backslash at the end of a line indicates the next line is a continuation. openssl s_server -accept tls1 -cert ssl.tpm.crt -key ssl.tpm.key -CAfile ca.crt \ -keyform engine -engine tpm In real-world use, the HTTP server would be configured to use ssl.tpm.key with the OpenSSL TPM Engine. For example, the mod_ssl module of the Apache Http Server has a configuration parameter called SSLCryptoDevice that can be set to the value tpm in order to achieve something equivalent to the command line shown above. 3.3 Attestation The attestation process happens between the trust authority and the server that requests a trust certificate. When the trust authority receives a certificate request, it must verify the private key corresponding to the request is protected by a real TPM.

38 Challenge the AIK public key These steps are performed by the trust authority upon receiving a CSR from a server. Create a challenge secret comprised of 32 random bytes. openssl rand 32 > aik.challenge.secret The aikchallenge command encrypts the challenge secret using the AIK public key which is embedded in the aik.proof file. It outputs the encrypted challenge, as well as the AIK public key into a separate file in PEM format. aikchallenge aik.challenge.secret aik.proof aik.challenge aik.pubkey It s possible to examine the contents of the AIK public key with this command: openssl rsa -in aik.pubkey -text -pubin noout Sample output from the openssl command is shown in Fig. 12. Public-Key: (2048 bit) Modulus: 00:ab:71:8e:e9:1e:4a:83:00:83:e6:0a:16:6d:8c: 24:0d:c9:75:45:e1:5a:5d:b3:9f:c0:43:c8:1a:a6: 34:c8:b9:a4:db:2f:1f:e1:6f:5c:81:9b:16:67:23: df:4f:d8:51:2a:8b:67:64:b6:c9:84:cf:1c:7c:29: b5:4d:17:0c:ad:d2:ff:d7:af:36:2c:96:48:93:9e: b1:a4:6d:2e:fe:8c:2c:ad:79:be:c1:49:58:a3:dd: 61:71:ee:00:8c:fd:20:05:45:3d:d9:74:be:d2:fe: 2b:29:4c:d0:43:63:be:5c:91:d8:23:3a:d0:a1:4c: 10:1a:8a:42:41:29:49:15:09:58:91:9e:76:f9:ad: 95:5a:7e:10:fc:ed:f7:37:60:68:b0:8c:0d:d6:52: cd:e6:28:d0:c3:b7:78:1b:11:8a:26:05:ec:cd:75: d5:be:3e:ec:d0:d3:86:b0:18:be:90:72:5b:dd:8a: ca:74:7f:95:45:1c:a9:3e:28:69:f9:90:4a:09:a7: 62:a5:22:a3:52:5e:05:5a:2a:74:7d:0e:ca:9c:db: dd:b4:1a:fc:15:99:df:93:ff:9a:32:c1:f0:50:76: ee:51:f3:21:a1:c9:92:3f:fc:1f:c4:4a:74:c2:4f: af:fc:1d:96:fd:2b:ad:48:e7:ee:73:20:17:7e:b4: c2:39 Exponent: (0x10001) Figure 12. Output of openssl rsa -in aik.pubkey -text -pubin -noout Copy the aik.challenge file to the server that requested the certificate.

39 Create a TPM Quote These steps are performed on the server after receiving the aik.challenge file. The aikrespond tool uses the files aik.blob and aik.challenge as inputs and produces the file aik.challenge.response as output. aikrespond aik.blob aik.challenge aik.challenge.response The output file aik.challenge.response is the decrypted challenge. Having decrypted it, the server will now use it as nonce in a TPM quote. The list of PCRs mentioned in the following command line is the list that will be certified by the trust authority if the request is approved. The command is shown here: aikquote -c aik.challenge.response aik.blob aik.quote Copy the aik.quote file to the trust authority Verify the TPM Quote These steps are performed on the trust authority after receiving the file aik.quote from the server. Verify the TPM quote by checking that it includes the decrypted nonce from aik.challenge.secret, and that it was signed by the AIK private key corresponding to aik.pubkey. The command is shown here: aikqverify -c aik.challenge.secret aik.pubkey aik.quote If the aikqverify command succeeds, it will display a list of PCR contents that were quoted, as shown in Fig. 13. These are the PCR contents that the server requests to be certified.

40 eb0b556b83fcef1c10f3fa e34f8f91 17 bfc3ffd7940e9281a3ebfdfa4e a3f55d8 18 dc3831d76dbb34f8906c1f9e14fc99ed227bb d4c4f0eecb20a1d2b512ae80d7df6af612d Success! Figure 13. Output of aikqverify Create the server s TLS certificate. In the following command, a backslash at the end of a line indicates the next line is a continuation. openssl x509 -req -days 365 -in ssl.tpm.csr -CA ca.crt -CAkey ca.key -CAserial \ serial -out ssl.tpm.crt Copy the certificate file ssl.tpm.crt to the server. 3.4 Client The client must have at least one trust authority certificate in order to verify server TLS certificates. The file ca.crt is the trust authority certificate. Open a connection to the server: openssl s_client -connect :7777 -tls1 -CAfile ca.crt If the connection succeeds, the server has demonstrated possession of a private key whose corresponding public key was certified by the trust authority. Refer to Appendix B for example output of client and server connections. 3.5 Trust A successful TLS connection indicates the server is trusted. The client must assume that the trust authority properly verified that the server has a real TPM and that the server s TLS private key is sealed in the TPM with specific PCR contents for which a certificate was issued.

41 31 Chapter 4 4. CONCLUSION This project outlines a system by which clients have some assurance that the servers they connect to are not only identified, but also that the server platform is in a specific configuration acceptable to the client. The configuration specification may include one or more of the 24 available Platform Configuration Registers provided by the Trusted Platform Module on the server. An authority that is trusted by the client, called a trust authority, verifies the server platform configuration. The trust authority verifies the server s credentials and platform configuration, and if the configuration is acceptable it issues an X.509 certificate to the server to use with Transport Layer Security (TLS) connections. The server s Trusted Platform Module seals server private key corresponding to the certificate so that it can only be used when the server platform is in the same specific configuration that was certified. Clients equipped with a copy of the trust authority s own X.509 certificate can connect to certified servers. One step in creating a TLS connection is verifying the server certificate with known certificate authorities. If the trust authority certificate successfully verifies the server certificate, and if the server is able to demonstrate possession of the corresponding private key by decrypting the challenge sent as part of the TLS protocol, then the server demonstrates that its current platform configuration matches the certificate.

42 32 These results were achieved using a variety of open source command line tools. Some of the open source tools were modified, and those modifications as well as original code written for this project are all included in Appendix A, Source Code. There is a lot of room for improvement. Some ideas are mentioned in Chapter 5, Future Work.

43 33 Chapter 5 5. FUTURE WORK 5.1 Runtime Measurement The operating system should measure every executable before it is started. A PCR should be designated for runtime measurements and extended with each executable program s measurement. If the executable program s measurement was already extended into the runtime PCR, then it should be skipped. So the runtime PCR value would be the set of programs executed within the operating system, ordered according to the time of first execution of each program, with each program being considered only once. 5.2 User-Space Measurement The operating system should measure every executable before it is started. The list of authorized executable programs is what should be extended into the PCR. If an executable is not on the list, then the PCR must be extended. 5.3 Global Knowledge Every software program is created by an individual or organization and is copied by everyone else. It should be possible to create a public directory of known programs, with their digests signed by the authors. This should include drivers, kernels, and even wellknown trusted configuration files. 5.4 Client Attestation In some situations, servers may require proof that clients are running trusted software. For example, streaming media servers that provide copyrighted content may want

44 34 assurances that the clients are running software that is trusted to respect the copyright and prevent unauthorized use. 5.5 PCR Contents as X.509v3 Extensions Clients validate a server certificate by checking that it is present in a list of trusted certificates or is signed by a trusted authority, just as they already do with any other server TLS certificate. A more dynamic approach to trusting servers is also possible using X.509v3 extensions. When the trust authority certifies a server s TLS public key, it should use X.509v3 extensions to annotate the certificate with the PCR contents that were quoted by the server during the attestation process. This change would enable clients to keep track of which certificate indicates which trusted state without having to maintain additional metadata. Clients could implement a more dynamic certificate validation function that checks the certificate was issued by a trusted authority and then checks the annotated PCR contents against a list of trusted platform characteristics. This would require clients to maintain only a list of one or more trusted authorities and a list of trusted platform characteristics represented as PCR values. 5.6 Software Updates In data center environments, uptime is a critical measure of performance, and CPU utilization is a profit factor that must be maximized. Furthermore, there are typically many servers that are identical in terms of the hardware and software used. When there are software updates, they are typically tested on a small set of servers and then replicated to similar servers throughout the data center. This leads to an issue with trust certificates: