Retaining Control over Private Virtual Machines Hosted by a Cloud Provider Using Mandatory Access Control, Trusted Boot and Attestation Armin Simma, Philipp Rusch Fachhochschule Vorarlberg, Austria
[email protected] [email protected] Abstract: The Trusted Platform Module (TPM) was and is heavily criticized. The TPM is accused to take control over a personal computer from the owner. Interestingly and ironically this is what we (to some extent) want to achieve with our system: We want to take control from the cloud provider -‐ which is the owner of the host system with the TPM -‐ and give control to the service client. Naturally, the cloud provider still should be in control of its host computer system but the client should retain control over his data and virtual machines even when processed on the provider’s machine. Our system shall succeed in the balance between these conflicting interests: the cloud provider can e.g. switch on and off its hardware, it can decide which client’s data (or virtual machine) can be processed on its hardware but on the other side the client can trust that his data cannot be read or manipulated by the cloud provider. The client can be sure that the provider’s platform is what it claims to be. With platform we mean firmware, bootloader, host operating system and virtual machine monitor. The client can assure that the platform of the provider was verified, tested and/or certified based on fingerprints of the certified/trusted systems; the client can check this fingerprint and he can be sure that the provider uses a trusted platform which was not manipulated and which does not allow the provider (even not the provider’s administrator) to gain control over data and virtual machines processed on such a trusted platform. This way the trust relationship between client and provider is not (only) based on personal acquaintance and (legal) contracts between client and provider. The trust relationship is based on five pillars: 1.) Trust in an open source (host) operating system that is publicly available and tested. 2.) Trust in a host system that is non-‐ manipulable and that prevents the provider including the administrator to see any virtual machine contents by using mandatory access control with restricting rules. 3.) Attestation: the provider proves that his system is based on a certified platform; this is technically achieved by using TPM, secure boot and integrity measurement. 4.) Separation of the verification, testing and certification process to hardware manufacturer (TPM including it’s credentials), to operating system developer (by publishing known fingerprints of its software) and a trusted third party that tests, verifies and/or certifies trusted systems. 5) Separation of necessary tasks concerning attestation and verification of integrity values between different entities: Trusted client software running on the local system of the cloud customer and an organization that tests, checks and/or verifies software platforms of the cloud providers. We implemented a prototype to show that it is possible to build a system that moves control over the virtual machine from the cloud provider to the service client. We are discussing factors influencing the trust level in the cloud provider and its platform including socio-‐economic, usability and psychological factors. ODER: Since trust cannot be regarded from a technical viewpoint only we also consider socio-‐economic, usability and psychological factors when discussing acceptance and trust perception of the cloud customer. Keywords: Cloud Security, Trusted Boot, TPM, Mandatory Access Control, Attestation. 1. Introduction Cloud customers who process or store their data in the cloud want to have the same level of security for their data and processes as on a locally hosted system. With security we mean confidentiality and integrity of the customer data. Since -‐ in all but a handful of cases -‐ a cloud customer cannot physically access the premises of the cloud provider he cannot control whether the infrastructure including the host operating system and virtual machine monitor of the cloud provider is what the provider claims. There should be a way for the cloud provider to prove that its infrastructure -‐ BIOS, boot loader, host operating system and virtual machine monitor (VMM) -‐ is in a known and trusted state. Research of the last decade produced many publications that suggest trusted boot, integrity measurement and remote attestation to gain this prove. The publications mainly focus on the technical issues on the cloud provider’s premises to create such a trusted cloud system. Trusted Boot and Attestation
We give a short overview on the technologies that we base our system upon. Trusted Computing Group (2007) describes a process called authenticated boot. The basic idea is that each part of the computer system is measured before it is executed. Measuring means calculating a hash value of the binary. The measured values are stored in platform configuration registers (PCR) in the TPM. PCR values can only be written to by using the following extend operation: PCR_i = SHA1 (PCR_i,m). Thus a PCR value depends on all values that were extended to this PCR since the system was started. Figure 1 shows the integrity measurement process
Figure 1: The measurement flow. (Trusted Computing Group, 2007) The measurement chain is started with the core root of trust for measurement (CRTM). The CRTM is part of the TPM and thus the initially trusted hardware part. The CRTM measures the OS loader code (1) then transfers execution to the OS loader code (2), which itself does a measurement – this time of the OS code (3), after which the OS code starts (4). The OS can measure application code (5) then the application can be executed (6) (Trusted Computing Group, 2007). There can be more than the three stages of measurement. An example can be the separation of the OS loader code into two or more parts. Free Software Foundation (2012) describes the GNU GRUB boot loader which is divided in two stages. After measurement it must be possible to securely request the PCR values. Trusted Computing Group (2007) calls this process integrity reporting. Each TPM has credentials embedded. These credentials are encryption keys that are permanently embedded in the TPM by the TPM manufacturer. Integrity reporting and the credentials allow for remote attestation. Remote attestation allows a remote entity to request proof that a system is based on a genuine TPM and that integrity values are received from PCRs of a TPM. Remote attestation is based on digitally signing the integrity values. Using a CRTM, trusted boot, integrity reporting and attestation the remote entity can be sure that the individual parts of the system which were executed consecutively during startup produced specific integrity values when measured. 2. Weakness and issues with trusted cloud computing based on integrity measurement and attestation Khan et al. (2011), Fengzhe et al. (2011) and Neisse et al. (2011) developed running prototypes that perform trusted boot, integrity measurement and attestation. Different open source projects allow code to be downloaded and to build systems based on trusted boot, integrity measurement and attestation: http://linux-‐ ima.sourceforge.net/, http://sourceforge.net/projects/tboot/ and http://sourceforge.net/projects/xmhf/ Nevertheless such Trusted Computing-‐based systems could not prevail in commercial cloud implementations. Amazon AWS offers a system called CloudHSM which at first glance seems to be based on a similar hardware as the TPM. The Hardware Security Module (HSM) that AWS is using is Luna SA. The aim of CloudHSM is not trusted boot but to provide a “secure key storage and cryptographic operations within a tamper-‐resistant hardware device”. (Amazon Web Services, 2013) To the best of our knowledge there is no commercial cloud provider or cloud implementation that is using TPM, Trusted Computing (TC) technology and/or trusted boot. The question arises: Why is no cloud provider using or offering TC technology after almost a decade of research and many (big) companies supporting TC? Trusted Computing Group (2014) gives a list of the members of the Trusted Computing Group. In the following we enumerate deficiencies of such trusted computing-‐based systems and (possible) reasons
for the reluctance of using and installing such systems in commercial or open source cloud systems. We also list existing solutions and propose new solutions to the issues. 1. The static nature of attestation: the difficulty of changing or updating (operating) systems that should be attested is described in Sadeghi (2004): Each update or patch of an operating system forces to create and publish new PCR values. 2. The size of the trusted computing base (TCB): The TCB is the part of a TC-‐based system that must be measured before it can be executed. A huge size of the TCB leads to performance degradation of the overall system since measuring which is based on hashing takes time. Experiments of Neisse et al. (2011) suggest that time necessary for measuring increases proportionally to the size of files. Many publications try to overcome this issue by minimizing the size of the TCB: Steinberg, U. and Kauer B. (2010) built a small micro hypervisor called NOVA which is the TCB in their system. Murray D., Milos G., and Hand S. (2008) propose disaggregation to minimize the trusted computing base. Bleikertz S. et al ( 2013) base their system on a small trusted domain builder. 3. The complexity of TC-‐based systems and -‐ as a consequence -‐ low acceptance by end users: It will be hard for a computer user or in our case a cloud customer who is not an expert in the field of IT security or TC technology to understand attestation-‐based and TC-‐based systems. If users understand all the details of a system the level of trust in such systems usually is higher than if the systems are highly complex and the details are not or only vaguely understood. McKnight et al. (2002) calls this category of trust Situational Normality-‐Competence which is a subcategory of Institution-‐ Based Trust. They showed in a study that Situational Normality-‐Competence has a high influence onto Institution-‐Based Trust. The level of trust can be increased when experts and/or highly respected organizations recommend to trust and use such systems. McKnight et al. (2002) propose different strategies depending on the experience and knowledge of end users. If the end user is less experienced they advocate that “clear explanations of structural and technological safeguards may be used to promote institutional trust”. For more experienced users they propose “such mechanisms as endorsements from respected customers, seals of approval from professional associations…”. Digital Certificates used in SSL (secure sockets layer)-‐based websites initially suffered from the same fact. Trust into certificates raised when big software companies – in this case browser and operating system developers -‐ introduced root certificates in their systems. Holz, R. et al. (2011) measured and analyzed the public key infrastructures (PKI) and X.509 certificates used in web browsers. We are aware that trust in X.509 certificates and certificate authorities is not the same category of trust as we need it in our TC-‐based attestation system. Jøsang A et al. (2007) differentiate between identity trust (in PKI) and provision trust. The latter category of trust is what is needed in cloud systems. 4. Usage of and trust in attestation-‐based cloud computing is adversely affected by low usability (Jarvenpaa et al. 1999) (Büttner et al. 2006) . In the above mentioned prototypical implementations the cloud customer has to compare the PCR values by hand. This is not reasonable to the average cloud customer. We propose additional software running on the local computer of the cloud customer. We call this software cloud attestor and advisor (CAA). CAA needs to be integrated with the TC-‐based attestation system running on the cloud provider’s premises. CAA compares the PCR values received during the attestation process with the integrity values published by a trusted third party. CAA software is what the cloud customer directly interacts with. Therefore trust level of cloud customers into CAA must be very high. In the following we compare CAA with antivirus software since both perform security-‐relevant tasks, both download comparative data from a remote entity and both must be trusted to by end users if they should be accepted by end users. Anti virus and anti malware software is well established software. A study of McAfee (2012) shows that 83% of participants of the study have working security protection which includes antivirus software. 39% of the participants in a study from McAfee (2011) answered they use free software for security protection purpose. Many computer end users do not care or do not have the knowledge to care about the details of any found malware. Gross J. and Rosson M. (2007) discovered in a small survey that 58% cannot distinguish between virus and worm and 25% of them are even not aware to have a virus scanner on their system. End users just want the antivirus software to clean their system. The antivirus software installed on the local system receives malware signatures from a central malware signature database. This signature database (as well as the software) comes from a trusted
third party. The same should be implemented in TC-‐based and attestation-‐based cloud ecosystems: trusted integrity values are downloaded from a separate trusted entity and the local (trusted) software handles the necessary attestation and integrity checks. We summarize and emphasize at this point that most end users trust antivirus software without detailed knowledge about technologies behind it. The following question arises: Where does the high trust level result from? We discuss this question later. 3. The five pillars for trusted clouds We propose an ecosystem for Infrastructure as a Service (IaaS) clouds that extends the technical controls (trusted boot, measurement and attestation, mandatory access control) with the help of a trusted third party and an (indirect) certification and audit system: A trusted third party certifies that the software (including bootloader, operating system and VMM) the cloud provider is using, conforms to specified security requirements. The trusted third party (TTP) has the task to test and check that the BIOS, bootloader, host operating system and the virtual machine monitor conforms to specified requirements defined in advance. The TTP does not have to check this on the physical premise of the cloud provider. The test, check and audit of the system can be done locally. The prove that the cloud provider is using the specific certified system is done using secure boot, a chain of trust, integrity measurement and remote attestation. To confine the root user a mandatory access control system is integrated in the cloud provider system. We advocate to base a secure and trusted cloud ecosystem on five pillars: the first four are technical measures the last pertains to the organizational architecture. We first enumerate the five pillars and describe them in the next paragraph: 1) Hardware root of trust 2) A complete chain of trust during authenticated boot as described by the Trusted Computing Group TCG (2007) 3) Integrity Reporting and Attestation 4) Mandatory access control to confine users including the root user and untrusted processes. 5) Ecosystem of trust: Separating trusted entities; Trusted Third Tester and Cloud Provider 1) Hardware root of trust: Our system is based on the Trusted Platform Module (TPM). This part of our ecosystem is specified in the TPM main specification of the Trusted Computing Group (2011). It should be possible to use any hardware root of trust that has the possibility to measure upper layer firmware or software and is able to store the measurements in a secure (non-‐manipulatable) way. The hardware root of trust must be trusted by the cloud provider and the consumer. 2) It is essential for the overall security and integrity of the ecosystem that the chain of trust has no gaps between the individual blocks that are measured and executed. This has been described by Martin (2008) or Shashidharan and Jitesh (2011). 3) Integrity reporting and attestation has been described in section 1. 4) Regarding possible adversaries against a cloud system it has been discovered that insider attackers are among the nine most critical threats to cloud systems (Cloud Security Alliance, 2013). Since an administrator (root user in Linux systems) usually has all access rights the root user is the most powerful insider and thus -‐ if he is malicious -‐ the most critical insider attacker. A trusted cloud ecosystem must ensure that a malicious root user cannot harm the system, steal data or do other malicious activity. Shashidharan and Jitesh (2011) suggest to use a mandatory access control system to confine the root user. Nahari (2007) describes a system that combines MAC, trusted boot and embedded linux. Sailer et al. (2005) integrated a MAC system into a XEN hypervisor. Bleikertz S. et al. (2013) consider five actors in their model who are possible adversaries. Bleikertz S. et al. (2013) differentiate between root users with physical access and root users with only logical access. Their protection of the cloud against logical root users is based on MAC for low-‐level resources and on a de-‐ privileged Dom0. in a typical Xen implementation Dom0 is the domain that allows direct interaction with the hypervisor. Dom0 allows for starting, stopping or managing other domains. 5) Our contribution will focus on the ecosystem surrounding the technological base on the provider’s premises: We advocate to separate the entity that identifies the running cloud platform used by the provider and the entity that tests and audits the software and hardware used for the platform. The local software on the cloud customer site deserves closer attention since this is what the cloud customer interacts with. In the following section we describe the trust ecosystem in detail.
4. The trust ecosystem To explain the two entities -‐ introduced with the fifth pillar in the third section -‐ we compare our ecosystem to software signatures combined with public key infrastructure (PKI). In a public PKI a digital certificate signed by a certificate authority provides authentication of the certificate holder. The main difference between our trust ecosystem and PKI is the category of trust that is provided: PKI provides identity trust, our system should provide provision trust. PKIs do not guarantee anything about the reliability of the certificate holder. PKIs do not state anything about the quality of service provided by the certificate holder. But the certificate gives the customer -‐ who is the user of a service -‐ a higher level of trust than without certificate. Josang A et al. (2007) describes categories of trust, two of the are identity trust and provision trust. The certificate authority or another entity – often called a registration authority – can check the authenticity of the certificate requestor with more or less diligence. Software signatures are usually based on a PKI. Signing a software allows for identity trust but not for provision trust: The software signature identifies the signer but it does not state anything about the quality or reliability of the software. In our trust system identity trust is a prior condition but we also postulate provision trust: The cloud customer should be enabled to trust that the cloud provider is providing its service with high quality of service, that the infrastructure and platform of the provider is reliable and secure. The cloud customer should be enabled to trust that the provider’s system allows for confidentiality and integrity of the customer’s data.
Figure 2: The trust ecosystem Comparing this to our cloud ecosystem introduces an additional entity: A trusted third party (TTP) which is trusted to by cloud consumers checks, tests, reviews and/or audits the platform that is used by the cloud provider. If trust level in this TTP is higher than the trust level in the cloud provider the overall trust level from the customer to the cloud provider is as high as the trust level of the TTP if and only if pillars 1, 2 and 3 from section 3 are implemented and used in the ecosystem. Figure 2 gives an overview of our proposed ecosystem: (1) The developer is the developer of the operating system and/or the developer of the bootloader and/or the developer of the firmware. Examples for this entity are the open source community or a commercial software company. If it is the open source community (developing an open source hypervisor) there must be a coordinating organization that requests certification with the trusted third party. Recently trust in open source has increased due to several leaks which accuse governmental organizations like secret services. If cloud customers do not trust in (big) software companies they will neither trust in a TTP. In this case the software developed and published in (1) must be open source. (2) The TTP tests, verifies and audits the software. We introduce the term trusted third tester (TTT) for this entity because it is more than a TTP in a PKI which provides only for identity trust. The TTT can be -‐ analogous to the developer -‐ the open source community or a commercial or a (semi-‐)governmental organization. If we use the analogy of PKI again, we can find companies that are commercial companies but they are
commissioned by the governmental entities. (3) The TTP signs and publishes the integrity values. (4) On the premises of the cloud service provider the specific VMM and/or host operating system is running. Each physical host of the provider is equipped with a TPM. (5) and (6) The Cloud service customer can use the attestation technology described in chapter 1 to get a prove that a specific system is running on the cloud premises. For better usability a trusted software is performing these tasks of challenging the TPM and attestation. (7) This software compares the received integrity values with the signed hashes received in (3). 5. Implementation We are working on a prototypical implementation of the trust ecosystem. So far we have implemented the system that runs on the cloud provider’s site. Our prototype is implemented using open source software: It is based on a Linux system including a mandatory access control system and on the integrity measurement architecture (IMA), which allows trusted boot and attestation. Figure 3 is an overview of the architecture of the prototype.
Figure 3: Architectural overview of the prototype We list the building blocks in figure 3. The software is either part of the Debian distribution or it can be downloaded from sourceforge.net. • TrustedGRUB is an extension of the GRUB bootloader to allow for trusted boot. • IMA module is a kernel module that allows for integrity measurement. It was presented by Sailer et al. (2004). • TPM Driver is a kernel device driver for Linux that enables the TPM. • SELinux is a mandatory access control system. • kvm KVM is a full virtualization solution for Linux . • TrouSerS is a library to access the TPM functionality. • tpm-‐tools comes with TrouSerS. It contains the commands to interact with the TPM. • Remote Attestation Tool is a client server application that allows for remote attestation as described in section 1. 5. Conclusion and Further Research Missing trust in cloud service providers is the key inhibitor for further acceptance and propagation of cloud technologies. We see TC as the most promising technology to establish trust into cloud ecosystems. On the other hand cloud systems are one of the most appealing applications of TC. To further promote TC in cloud systems we need further research and action that combines technical, socio-‐economic, usability and psychological factors. Further research is necessary to be able to transform the influencing factors of trust from web stores onto the field of cloud computing. Reputation of the service provider is an influencing factor for the level of trust (Jarvenpaa et. al, 1999). Assuming that online stores and cloud platforms basically have the same trust factors the following actions are needed: Organizations (the TTT) should be established that are able to perform detailed tests and reviews of source code of cloud platforms. These organizations must be well regarded. To increase reputation on these organizations experts from the scientific community as well as governments must
promote these organizations. Another factor that could increase trust in the proposed TC-‐based system is usability. Further research is needed to build CAA software with high usability. 6. References • Bleikertz S. et al. ( 2013) "Client-‐controlled cryptography-‐as-‐a-‐service in the cloud", Proceedings of the 11th international conference on Applied Cryptography and Network Security, pp 19-‐36 • Bouchenak Sara, et al. (2013) "Verifying cloud services: present and future" SIGOPS Oper. Syst. Rev., Vol 47, No 2, July, pp 6-‐19 • Cloud Security Alliance. (2013) The Notorious Nine. Cloud Computing Top Threats in 2013, URL:https://cloudsecurityalliance.org/download/the-‐notorious-‐nine-‐cloud-‐computing-‐top-‐threats-‐in-‐ 2013/ • Free Software Foundation (2012) GNU GRUB, URL: http://www.gnu.org/software/grub/ • Fengzhe Zhang et al. (2011) "CloudVisor: retrofitting protection of virtual machines in multi-‐tenant cloud with nested virtualization", Proceedings of the Twenty-‐Third ACM Symposium on Operating Systems Principles (SOSP '11), pp 203-‐216 • Gross J. and Rosson M. (2007) "Looking for trouble: understanding end-‐user security management", Proceedings of the 2007 symposium on Computer human interaction for the management of information technology (CHIMIT '07), Article 10 • Jansen B., Ramasamy H., and Schunter M. (2008) "Policy enforcement and compliance proofs for Xen virtual machines", Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments (VEE '08), pp 101-‐110 • TODO Jøsang A., Ismail R., Boyd C. (2007) "A survey of trust and reputation systems for online service provision", Decision Support Systems, Vol. 43, Issue 2, March, pp 618-‐644 TODO • Khan I., Rehman H, and Anwar Z. (2011) "Design and Deployment of a Trusted Eucalyptus Cloud", Proceedings of the 2011 IEEE 4th International Conference on Cloud Computing (CLOUD '11), pp 380-‐387. • Martin Andrew (2008) The Ten Page Introduction to Trusted Computing, techreport, OUCL • Murray D., Milos G., and Hand S. (2008) "Improving Xen security through disaggregation", Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments (VEE '08), pp 151-‐160 • Nahari H. (2007) "Trusted Secure Embedded Linux", Proceedings of the Linux Symposium pp. 79-‐86 • Neisse, R., Holling, D., Pretschner, A. (2011) "Implementing Trust in Cloud Infrastructures", 11th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), May, pp.524-‐533 • Sadeghi, A. and Stüble C. (2004) "Property-‐based attestation for computing platforms: caring about properties, not mechanisms", Proceedings of the 2004 workshop on New security paradigms (NSPW '04) pp. 67-‐77 • Sailer, R. et al. (2005) "Building a MAC-‐based security architecture for the Xen open-‐source hypervisor", Computer Security Applications Conference, 21st Annual , pp 285, 5-‐9 • Santos N., Rodrigues R., and Ford B. (2012) "Enhancing the OS against security threats in system administration", Proceedings of the 13th International Middleware Conference, pp 415-‐435 • Santos, Nuno, Krishna P. Gummadi, and Rodrigo Rodrigues (2009) "Towards trusted cloud computing." Proceedings of the 2009 conference on Hot topics in cloud computing, Article 3 • Schiffman Joshua et al. (2010) "Seeding clouds with trust anchors" Proceedings of the 2010 ACM workshop on Cloud computing security workshop, pp 43-‐46 • Shashidharan, A., and Jitesh, S.(2011) Enabling Cloud Customers to Trust the Cloud • Steinberg, U. and Kauer B. (2010) "NOVA: a microhypervisor-‐based secure virtualization architecture", Proceedings of the 5th European conference on Computer systems (EuroSys '10), pp 209-‐222 • Trusted Computing Group (2007). "TCG specification architecture overview", Rev.1.4 • Trusted Computing Group (2011). "TPM Main Specification", Specification Version 1.2, Rev.116 • Trusted Computing Group (2014). "TCG Members" [online], http://www.trustedcomputinggroup.org/about_tcg/tcg_members • Heijden H., Verhagen T, and Creemers M. (2003) “Understanding online purchase intentions: contributions from technology and trust perspectives”, Eur. J. Inf. Syst. 12, 1, March, pp 41-‐48.
• • •
• • • • • •
Amazon Web Services (2013) “AWS CloudHSM Product Details “ [online], http://aws.amazon.com/cloudhsm/details/ McKnight D.H. et al. (2002) “Developing and Validating Trust Measures for e-‐Commerce: An Integrative Typology” Info. Sys. Research Vol. 13, 3 (September) Holz, R. et al. (2011) “The SSL landscape: a thorough analysis of the x.509 PKI using active and passive measurements” Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference, pp 427-‐444. McAfee (2012) “Consumer Alert: McAfee Finds One in Every Six Personal Computers Have Zero Protection”, [online], http://www.mcafee.com/cn/about/news/2012/q2/20120530-‐01.aspx McAfee (2011) “McAfee Reveals Average Internet User Has More Than $37,000 in Underprotected ‘Digital Assets’”, [online], http://www.mcafee.com/au/about/news/2011/q3/20110927-‐01.aspx Roy, M.C. et al.(2001),The impact of interface usability on trust in Web retailers Sailer et al. (2004) “Design and Implementation of a TCG-‐based Integrity Measurement Architecture” 13th Usenix Security Symposium, August, pp 223–238 Jarvenpaa, S., Tratinsky, N., and Saarinen, L. (1999) "Consumer trust in an Internet store: A cross-‐cultural Validation," Journal of Computer-‐Mediated Communication, pp 1-‐5 Büttner, O.B., Schulz, S. and Silberer, G. (2006). “Vertrauen, Risiko und Usability bei der Nutzung von Internet-‐Apotheken”, Konsumentenvertrauen: Konzepte und Anwendungen für ein nachhaltiges Kundenbindungsmanagement, pp 355-‐366
