should be resumed by the TPM. The TPM internally verifies whether the migration counter of the TPMCS is consistent with the one stored inside the migration counter of the root-data structure. This verification prevents against an already migrated TPM context or a replayed TPM context being again loaded into the TPM. The TPM then unseals the structure and verifies that the signature sign+1is a valid signature of Dn+1.
If the signature is valid, implying that the data structure was generated on this specific TPM, the TPM loads the values Dn+1 into its internal memory.
8.7 Satisfied Security Requirements
In contrast to our first approach that used a software TPM to virtualize a TPM (com- pare 7.5.3), we are now directly using a virtualization-enhanced hardware TPM. This hardware TPM satisfies all requirements (R.1 - R.3) that a software TPM satifies. In addition, it also satsifies the security requirement (R.4) since all cryptographic secrets are protected by hardware measures and can thus only be accessed by hardware.
8.8 Related Work
Another very related proposal has been made by England and Loeser [57]. The authors propose to safely share a TPM among other virtual machines by paravirtualizing the TPM. All TPM data that cannot be shared is paravirtualized, i.e., the state of each VM’s TPM is stored in software. This is for example true for the PCRs which cannot be shared amongst all VMs. However, the approach has two major drawbacks. First, it does not provide the same security level as our proposed multi-context hardware TPM, and, Second, the EK must be shared through all VMs which is a potential security vulnerability.
Sadeghi et al. propose in [136] a virtual TPM architecture that supports property- based attestation. Their approach extends a virtual TPM with mechanisms that allows migrating a vTPM instance to another platform that offers the same platform proper- ties. However, in contrast to our work, the approach by Sadeghi et al. is also based on the software TPM [20] and, thus, does not provide lifetime protection of secrets.
Similar to a TPM, ARM has introduced the TrustZone technology [5] which is an extension to the ARM architecture. The TrustZone technology tries to ensure reliable implementation of security critical applications by adding a second secure processor execution mode in which applications with a higher protection level are run. In contrast to the TPM, ARM TrustZone technology is implemented within the microprocessor core itself. However, TrustZone does not provide the flexibility of a TPM and does only support a small set of the functionalities that a TPM supports.
Intel and AMD have recently introduced the Trusted Execution Technology (TXT) [38, 180] and the Secure Virtual Machine technology [6], respectively. Both architec- tures extend the processor instruction set with a number of additional special purpose instructions, that directly communicate with a TPM. In addition, these architectures
implement virtualization technology and are, thus, capable of supporting different effi- cient VMs with hardware measures.
8.9 Summary
Trusted Computing technologies provide a sound way of securing computer systems and also a technological means for trust establishment. For this purpose, the Trusted Com- puting Group introduced a hardware module called trusted platform module (TPM) that protects cryptographic secrets and is capable of acting as a trust anchor. However, the TPM cannot be used directly in next-generation operating systems that utilize vir- tualization technologies. In this chapter, we proposed an efficient approach for using TC-technology in virtual environments. Our approach extends the TPM specification and shows how a hardware TPM that is capable of supporting virtualization with hard- ware measures should be designed. To provide hardware-based protection domains, we introduced a second TPM privilege level and a TPM Control Structure. The combi- nation of both concepts allows a virtual environment to directly operate on the TPM without loss of security properties. Since the approach we presented in this chapter uti- lizes recent developments in the virtualization technology of processor architectures, it could easily be adapted to integrate Trusted Computing technology in next-generation processor architectures. In that case, highly-efficient and secure Trusted Computing technology would be available to next-generation operating systems that are based on virtualization.
Part IV
Transaction Software
Chapter 9
Secure Transaction Software
This chapter presents a secure transaction software that can be used for sensitive e- commerce transactions. This transaction software runs on our security architecture presented in the preceding chapter and is, thus, capable of providing a proof that it is in a trusted state. Parts of this chapter have been previously published in An Approach to a Trustworthy System Architecture Using Virtualization [156] and Towards Secure E-Commerce Based on Virtualization and Attestation Techniques [158].
9.1 Introduction
In the preceding sections, we presented the design and implementation of an attestation- supporting security architecture. However, a security architecture cannot provide pro- tection for confidential data if the application that is used as input interface and trans- action software suffers from a wide range of vulnerabilities. This shows that besides an underlying security architecture, the need for a secure transaction software evolves.
In today’s personal computers, security sensitive transactions are often facilitated by the use of web-browsers such as Microsoft’s Internet Explorer, Mozilla’s Firefox or Apple’s Safari. However, such browsers were never explicitly designed for acting as a secure transaction software. Further complicating this problem is the issue of browser help objects (such as flash players and video codecs) which extend the complexity of these web-browsers. Since these components could be used to inject malicious code and users are typically not adept at separating useful applications from malicious ones, these components should not be part of a secure transaction client. Mozilla’s Firefox, the most widespread web-browser, as an example, consists of around 1 million lines of code, showing that the code complexity is huge. Because of their huge complexity and the ability to execute additional programs, such as scripts, active code or applets, web- browsers have become a de facto operating system [40]. However, since many software engineering studies have shown that the code complexity is correlated with the number of errors and defects [151, 15], a secure transaction software should be as simple as possible.
To make matters worse, the unsecure web-browsers typically run on unsecure and unreliable operating systems. As shown in the preceding chapter, one vulnerability of the underlying operating system can be exploited, thereby allowing an attacker to surreptitiously install subversive programs, such as malware and spyware, which can eavesdrop, record and distribute a user’s actions, passwords, credit card information, bids in auctions or other sensitive data. As a result, it is difficult for users to ascertain whether or not their computer’s software system can be trusted. However, such assur- ances are necessary if users are to become more comfortable purchasing goods on-line [59].
Another aspect that needs attention is that even if we are to assume trusted user environments, a system may be vulnerable to man-in-the-middle (MitM) attacks. MitM attacks pose a serious threat to current electronic commerce applications that are based on TLS [112]. These attacks exploit the fact that ordinary users often improperly verify a merchant’s certificate. Even if the users carefully examine the certificate presented by the merchant, they cannot be certain that the merchant’s identity is authentic, since their own software could have maliciously modified the certificate presented to them. In order for users to place trust in their system for use in e-commerce, it is, therefore, necessary to provide them with assurances that:
1. they have a trusted client configuration.
2. authentication data, such as passwords, cannot be accidentally transferred to an improperly verified server.
In this chapter, we present a secure transaction software that runs in the virtualization- based environment presented in Chapter 7 to achieve strong isolation between com- partments of different trust levels. This setup ensures that the sensitive e-commerce transaction client is immune from infection by malicious processes running in different compartments. To prevent MitM attacks on TLS and to ensure that the client appli- cation is trusted, we propose several security protocols that are based on our proposed attestation protocols. Using these protocols, we can ensure
1. that the client configuration remains untampered and trusted for the duration of the transaction.
2. that confidential data, such as authentication passwords, are only accessible to the electronic commerce server to which the users intend to transfer their data. This chapter is organized as follows: Section 9.2 describes our e-commerce archi- tecture; in Sections 9.3 and 9.4, we discuss how to ensure that a client’s platform is trusted and how to establish a secure channel with a remote host that is resistant to MitM attacks. In Section 9.5, we provide an informal security analysis of our proposal. In Section 9.6, we discuss some of the implementation issues that arise. In Section 9.7 we look at other work that is related to this chapter; and finally, we summarize with Section 9.8.