Retaining Control Over Private Virtual Machines Hosted by a Cloud Provider Using Mandatory Access...

P di f thProceedings of the13th European Conference on

Cyber Warfare and SecurityTh U i it f PiThe University of Piraeus

Greece3-4 July 2014

Edited byAndrew Liaropoulos and George Tsihrintzis

A conference managed by ACPI, UK

Retaining Control Over Private Virtual Machines Hosted by a Cloud Provider Using Mandatory Access Control, Trusted Boot and Attestation

Armin Simma and Philipp Rusch Vorarlberg University of Applied Sciences, Austria [email protected] [email protected] Abstract: The Trusted Platform Module (TPM) has been heavily criticized because it is accused of taking control over a personal computer from the owner. Interestingly and ironically this is what should be achieved ‐ to some extent ‐ with the system described in this paper: Control should be taken from the cloud service provider (CSP) ‐ which is the owner of the host system with the TPM ‐ and given to the cloud service customer. Naturally, the CSP should still be in control of its host computer system but customers should retain control over their data and virtual machines even when processed on the CSP’s machine. The proposed system should enable customers to trust that their data cannot be read or manipulated by the CSP. Mandatory Access Control (MAC) prevents the CSP (including its administrator) to gain control over virtual machines processed on such a trusted system. The customer can be sure that the CSP’s platform is what it claims to be. This assurance is based on Trusted Computing (TC)‐technology and third party attestation that the platform of the CSP is based on a verified, tested and/or certified trusted system. This way the trust relationship between customer and CSP is not only based on personal acquaintance and contracts between customer and CSP. The trust relationship is based on both technical and organizational measures. Technical measures are MAC and TC‐based technologies (TPM, integrity measurement and attestation). The organizational measure is an ecosystem extending the technical measures and consists of CSP, customer, operating system (OS) developer and a trusted third party (TTP) that tests, verifies and/or certifies trusted systems. A prototype shows that it is possible to build a system that enables cloud customers to trust that the CSP cannot access their virtual machines. Since trust should not be regarded from a technical viewpoint only, findings from social psychology and information sciences are also considered when discussing perception of trust of the cloud customer, and acceptance of cloud services. Keywords: trust, 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 as on a locally hosted system. Security comprises confidentiality and integrity of customer data. Since ‐ in all but a handful of cases ‐ customers cannot physically access the premises of the CSP, they cannot ascertain that the infrastructure including the host OS and virtual machine monitor of the CSP is what the CSP claims it to be. There should be a way for the CSP to prove that its infrastructure ‐ BIOS, boot loader, host OS and virtual machine monitor (VMM) ‐ is in a known and trusted state. Research of the last decade has produced many publications that suggest trusted boot, integrity measurement and remote attestation as a means of gaining this proof (Sailer et al, 2005; Santos et al, 2009; Schiffman et al, 2010; Neisse et al, 2011; Santos et al, 2012a; Bouchenak et al, 2013). These publications mainly focus on the technical issues on the CSP’s premises to create such a trusted cloud system.

1.1 Trusted boot and integrity measurement

In the following a short overview of the technologies upon which the trusted cloud system is based is given: Trusted Computing Group (TCG) (2006) describes a process called Trusted Boot, which is based on Integrity Measurement (TCG, 2007). 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 = SHA1 (PCR || data) i.e. concatenate the PCR value with the data, hash the concatenation and store the result back to the PCR. 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. 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 BIOS code (1), saves the value in the TPM by extending a PCR (2), and then transfers execution to the BIOS. The BIOS measures the bootloader code (3), extends the measured value to the PCR (4),

172

mailto:[email protected]

mailto:[email protected]

Armin Simma and Philipp Rusch

after which the bootloader is executed (5). The bootloader measures the kernel code (6), extends the measured value to the PCR (7), after which the OS is executed (8). The kernel can measure application code (9), stores the value in TPM (10), and then executes the application (11). Applications can be measured and executed consecutively (12)‐(14).

Figure 1: The measurement flow (Based on TCG, 2007)

1.2 Integrity reporting and attestation After measurement, it must be possible to securely request the PCR values. TCG (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. Figure 2 shows the simplified process of integrity reporting: The challenger is the entity that requests the PCR values. It creates a nonce using a random number generator (RNG). This nonce is sent to the TPM. The TPM concatenates the nonce and the value of the requested PCR and hashes the result. This hash is signed using a signature key, which is generated from the Storage Root Key. The signature is sent back to the challenger. The challenger creates a hash from the concatenated nonce and reference PCR value. If the reference hash and the received hash are the same, the integrity of the PCR value is verified.

Figure 2: Integrity reporting (Based on TCG, 2007)

173


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, Rehman and Anwar (2011), Zhang et al (2011), Neisse, Holling and Pretschner (2011) and Selhorst, Stüble and Teerkorn (2008) have developed prototypes that perform trusted boot, integrity measurement and attestation. Different open source projects (IMA, tboot, xmhf) allow code to be downloaded and to build systems based on trusted boot, integrity measurement and attestation. Nevertheless, such Trusted Computing (TC)‐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 uses 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 CSP or cloud implementation that uses TPM, TC technology and/or trusted boot. The question arises: Why does no CSP use or offer TC technology after almost a decade of research and many (big) companies supporting TC? TCG (2014) gives a list of the members of TCG. In the following deficiencies of such TC‐based systems and (possible) reasons for the reluctance of using and installing such systems in commercial or open source cloud systems are enumerated; solutions to the issues are also listed.

The static nature of attestation: the difficulty of changing or updating (operating) systems that should be attested is described in Sadeghi and Stüble (2004). Each update or patch of an OS forces to create and publish new PCR values.

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 ‐ and the TPM extend operation takes time. Experiments of Neisse, Holling and Pretschner (2011) suggest that time necessary for measuring is proportional to the size of the file. Many publications try to overcome this issue by minimizing the size of the TCB: Steinberg and Kauer (2010) built a small micro hypervisor called NOVA, which is the TCB in their system. Murray, Milos and Hand (2008) propose disaggregation to minimize the TCB. Bleikertz et al (2013) base their system on a small trusted domain builder.

Information leakage: Revealing information about the host OS is not recommended. Malicious users who know details about the OS could potentially use found vulnerabilities (Santos et al 2012b). Sending PCR values to a challenger during attestation and knowing the code that created the reference values reveals all details of the host OS. Sadeghi and Stüble (2004) introduced property‐based attestation, which allows attesting properties and not binary code. Chen et al (2006) developed a protocol for property‐based attestation.

The complexity of TC‐based systems and ‐ as a consequence ‐ low acceptance by customers: 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 that Situational Normality‐Competence has a high influence on Institution‐Based Trust. The level of trust can be increased when experts and/or highly respected organizations recommend trusting and using such systems. McKnight et al (2002, p 354) 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[..]”.

174


Low usability: Usage of and trust in attestation‐based cloud computing is adversely affected by lowusability (Jarvenpaa, Tratinsky and Saarinen, 1999), (Heijden, Verhagen and Creemers, 2003). In theprototypical implementations mentioned above, the cloud customer has to compare the PCR values byhand. However, it would be unreasonable to ask the average customer to do so. Therefore it is proposedthat additional software should run on the local computer of the cloud customer. This software is calledCloud Attestor and Advisor (CAA). CAA needs to be integrated with the TC‐based attestation systemrunning on the CSP’s premises. CAA compares the PCR values received during the attestation process withthe integrity values published by a trusted third party. CAA software is what the customer directlyinteracts with. Therefore trust level of customers into CAA must be very high.

(Missing?) Recommendations and reputation: In the following CAA is compared with antivirus softwaresince both perform security‐relevant tasks, both download comparative data from a remote entity – calledsignature files in antivirus software ‐ and both must be trusted by end users if end users should acceptthem. Antivirus and anti‐malware software is well established. A study of McAfee (2012) shows that 83%of participants of the study have working security protection, which includes antivirus software. 39% ofthe participants in a study from McAfee (2011) answered they use free software for security protectionpurpose. Many computer users do not care or do not have the knowledge to care about the details of anyfound malware. Gross J. and Rosson M. (2007) discovered in a survey that 58% cannot distinguishbetween virus and worm and 25% of them are not even aware they have a virus scanner on their system.The antivirus software installed on the local system receives malware signatures from a central malwaresignature database. This signature database (as well as the software) comes from a trusted entity. Thesame should be implemented in TC‐based and attestation‐based cloud ecosystems: trusted referencevalues for PCRs are downloaded from a separate trusted entity and the local (trusted) software handlesthe necessary attestation and integrity checks. It should be emphasized at this point that most users trustantivirus software without detailed knowledge about the technologies behind it. The following questionarises: Where does the high trust level result from? The hypothesis of the authors is that the contributingfactors are recommendations by experts and/or the media, usability and the reputation of the companiesdeveloping the protection software.

3. The five pillars for trusted clouds

The authors propose an ecosystem for Infrastructure as a Service (IaaS) cloud that extends the technical controls (trusted boot, measurement and attestation, MAC) 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, OS and VMM) the CSP is using conforms to specified security requirements. The TTP has the task to test and check that the BIOS, bootloader, host OS and the virtual machine monitor conform to specified requirements defined in advance. The TTP does not have to check this on the physical premise of the CSP. The test, check and audit of the system can be done locally.

The attestation that the CSP is using the specific certified system is done using trusted boot, a chain of trust, integrity measurement and remote attestation. To confine the root user, a MAC system is integrated in the CSP system.

The secure and trusted ecosystem should be based on five pillars; the first four are technical measures, while the last pertains to the organizational architecture:

1. Hardware root of trust: Our system is based on the TPM. This part of our ecosystem is specified in the TPMmain specification of TCG (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 (tamper‐proof) way. The CSP and the consumer must trust the hardware root of trust. 2. A complete chain of trust during trusted boot: It is essential for the overall security and integrity of theecosystem that the chain of trust has no gaps between the individual blocks that are measured and executed. This has been described by Kauer (2007) and Martin (2008). Trusted boot has been introduced in section 1.1 and is described in TCG (2006). 3. Integrity Reporting and Attestation: This has been introduced in section 1.2. Details can be found in TCG(2006) and TCG (2007) 4. MAC to confine users including the root user: Regarding possible adversaries against a cloud system, it hasbeen discovered that insider attackers are among the nine most critical threats to cloud systems (Cloud

175


Security Alliance, 2013). Since administrators (root users in Linux systems) usually have all access rights, the root users are the most powerful insiders and thus ‐ if they are malicious ‐ the most critical insider attackers. Thus, a trusted cloud ecosystem must ensure that a malicious root user cannot harm the system, steal data or engage in any other malicious activity. Shashidharan and Jitesh (2011) suggest using a MAC 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 et al (2013) consider five actors in their model as being possible adversaries, one of them being the root user. Their protection of the cloud against 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. Trust Ecosystem: The author's contribution will focus on the ecosystem surrounding the technological base on the CSP’s premises. The authors advocate separating the entity that assumes the role of the challenger in figure 2 and the entity that reviews the code used for the platform. The former is software on the cloud customer site (CAA) and deserves closer attention since this is what the customer interacts with; the latter is a TTP that reviews code, creates digital signatures of the binaries and publishes these reference integrity values. In the following section the complete trust ecosystem is described in detail.

4. The trust ecosystem

To explain the two entities ‐ introduced with the fifth pillar in section 3 ‐ the ecosystem is compared to code signing combined with public key infrastructure (PKI). In a PKI a digital certificate signed by a certificate authority – the TTP ‐ attests authenticity of the public key of the certificate holder. A software signature is an encrypted hash of code. Signing is done with the private key of the signer. The corresponding public key is authenticated with the certificate. The similarities between our trust ecosystem and PKI are that both use code signing and both require a TTP. The main difference is the category of trust that is provided: PKI provides identity trust; our system should provide provision trust. PKIs do neither guarantee anything about the reliability of the certificate holder nor state anything about the quality of service provided by the certificate holder. But the certificate increases the level of trust. Josang et al (2007) describes categories of trust, two of them being identity trust and provision trust. In our trust system identity trust is a prior condition but provision trust is postulated as well: The cloud customer should be enabled to trust that the platform of the CSP is reliable and that confidentiality and integrity of the customer’s data is assured. To achieve provision trust in our cloud ecosystem an additional entity is introduced. The term Trusted Third Tester (TTT) is used for this entity because it is more than a TTP in a PKI, which provides only for identity trust. The TTT checks, tests, reviews and/or audits the software platform that is used by the CSP. If the trust level in TTT is high, trust in CSP can be improved if technical pillars 1 to 4 from section 3 are implemented and used in the ecosystem. Figure 3 gives an overview of our proposed ecosystem: (1) The developer develops the OS, the bootloader or the firmware. Examples for this entity are the open source community or a commercial software company. If it is the open source community there must be a coordinating organization that requests certification and code review from the trusted third party. (2) The TTT tests, verifies and audits the software. The TTT can be the open source community, a commercial or a (semi‐)governmental organization. (3) The TTT signs and publishes the integrity values. (4) On the premises of the CSP the specific VMM and/or host OS is running. Each physical host of the CSP is equipped with a TPM. (5) and (6) comprise the integrity reporting process from figure 2. CAA software is the challenger, the TPM responds with signed PCR values. (7) CAA compares the PCR values received from TPM with the reference values received from TTT in (3). In contrast to the entities from figure 3 the entities enumerated in TCG (2006) are not specific to cloud systems but cover general trust infrastructures.

176


Figure 3: The trust ecosystem

5. Implementation

The authors are working on a prototype of the overall trust ecosystem. Up to now the software that runs on the CSP’s site is implemented. The prototype is implemented using open source software: It is based on a Linux system (Debian 7.2.0) including SELinux. Integrity measurement architecture (IMA) and software for TPM usage allow for trusted boot and attestation. Figure 4 gives an overview of the architecture.

Figure 4: Architectural overview of the prototype

In the following the building blocks of figure 4 are listed and described. The software is either part of the Debian distribution or it can be downloaded from sourceforge.net with the exception of the Local Attestation Tool.

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 first presented by Sailer et al(2004).

TPM Driver is a kernel device driver for Linux that enables the TPM.

SELinux is a MAC system.

KVM is a full virtualization solution for Linux.

177


TrouSerS is a library to access the TPM functionality.

tpm‐tools comes with TrouSerS. It contains the commands to interact with the TPM.

Local Attestation Tool is a client‐server application developed by the authors that allows for integrity reporting as described in section 1.2.

6. Conclusion and further research Missing trust in CSPs is one of the key inhibitors for further acceptance and propagation of cloud technologies (Gupta et al, 2013). TC is one of the most promising technologies to establish trust in cloud systems. Furthermore, cloud systems are one of the most appealing applications of TC. To promote TC in cloud systems, further research is needed that combines technical solutions with findings from behavioral science, social psychology and usability research. Many publications and surveys exist that analyze intentions and trust of users of web stores, web services or Internet auctions. There are also publications that analyze trust in cloud systems (Uusitalo et al, 2010; Pearson and Benameur, 2010; Pearson, 2013). However, further research is necessary to be able to transfer these findings to the field of TC‐based cloud computing. The reputation of web service providers is an influencing factor for the level of trust (Jarvenpaa, Tratinsky and Saarinen, 1999). Assuming that online stores and cloud platforms basically have the same trust factors, the following actions are needed: Organizations (TTTs) able to perform diligent tests and reviews of source code of cloud platforms should be established. Trust in these organizations is fundamental. To increase the reputation of – and as a consequence trust in ‐ these organizations, experts from the scientific community or governmental organizations should promote and recommend TTTs. The open source community could also be a TTT. It is predestined to perform reviews of open source code for cloud systems. Reviews can be performed decentralized but the creation, signature and publication of integrity values should be done by one central organization, which has to be trusted by customers. One key advantage of the open source community being TTT is the fact that it is not mistrusted as some governmental organizations currently are as shown by a survey of Pew Research Center (2013). Heijden, Verhagen and Creemers (2003) state that there is a strong positive correlation between the size of an organization and its level of trust. Separating the developer, CSP and TTT allows small‐sized CSPs – which usually are less known and thus less trusted – to become “certified” by TTT. TTT attests that this CSP uses a trusted platform, thereby increasing the trust level into the CSP. Our ecosystem provides no solution to the problem of information leakage when using binary attestation. Property‐based attestation should be integrated with the ecosystem. Kostiainen, Asokan and Ekberg (2011) enumerate deficiencies of property‐based attestation, one of which is the required existence of a TTP. Our ecosystem already contains such a TTP. A factor that could increase trust in the proposed TC‐based system is usability. Karppinen (2012) states that “ease of use has the biggest effect” on trusting cloud services. In the discussion section of Roy et al (2001) it is stressed that certain usability criteria are key factors for high trust levels. Further research and action is needed to improve user experience. In our prototype attestation is done using the Local Attestation Tool. This should be extended to allow for remote attestation. In section 2 it was stressed that such CAA software is what the customer directly interacts with; therefore special focus must be put on the usability of CAA. TC‐based cloud technologies are adversely affected by mistrust in TPM. One of the reasons for this mistrust is that TPM often is used synonymously with digital rights management (Schneier, 2005; Law, 2006). To counter such arguments clear explanations of the technologies are essential. It should be emphasized that TPM ‐ when used for remote attestation ‐ does not prevent the usage of any software product or vendor. It is the cloud customer who decides whether or not to send his data or virtual machine to the cloud.

178


References

Amazon Web Services (2013) “AWS CloudHSM Product Details “ [online], http://aws.amazon.com/cloudhsm/details/ [Accessed 30 January 2014 ]

Bleikertz, S. et al (2013), “Client‐Controlled Cryptography‐as‐a‐Service in the Cloud”, in Jacobson, M., Locasto, M., Mohassel, P. and Safavi‐Naini, R. (Eds.), Applied Cryptography and Network Security, Lecture Notes in Computer Science, Springer Berlin Heidelberg, Vol. 7954, pp. 19–36.

Bouchenak, S. et al (2013), “Verifying cloud services: present and future”, ACM SIGOPS Operating Systems Review, Vol. 47 No. 2, pp. 6–19.

Chen, L. et al (2006), “A protocol for property‐based attestation”, Proceedings of the first ACM workshop on Scalable trusted computing, ACM Press, pp. 7–16.

Cloud Security Alliance (2013) "The Notorious Nine. Cloud Computing Top Threats in 2013" [online], https://cloudsecurityalliance.org/download/the‐notorious‐nine‐cloud‐computing‐top‐threats‐in‐2013/ [Accessed 30 January 2014]

Gross, J.B. and Rosson, M.B. (2007), “Looking for trouble: understanding end‐user security management”, Proceedings of the 2007 symposium on Computer human interaction for the management of information technology, ACM Press, p. 10.

Gupta, S., Kumar, P. and Abraham, A. (2013), “Cloud Computing: Trust Issues, Challenges, and Solutions”, Managing Trust in Cyberspace, Taylor & Francis, pp. 13‐40

Van der Heijden, H., Verhagen, T. and Creemers, M. (2003), “Understanding online purchase intentions: contributions from technology and trust perspectives”, European Journal of Information Systems, Vol. 12 No. 1, pp. 41–48.

Jansen, B., Ramasamy, H.‐G.V. 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, ACM Press, pp. 101–110.

Jarvenpaa, S.L., Tractinsky, N. and Saarinen, L. (2006), “Consumer Trust in an Internet Store: A Cross‐Cultural Validation”, Journal of Computer‐Mediated Communication, Vol. 5 No. 2, pp. 1–5.

Jøsang, A., Ismail, R. and Boyd, C. (2007), “A survey of trust and reputation systems for online service provision”, Decision Support Systems, Vol. 43 No. 2, pp. 618–644.

Karppinen, K. (2012), “Users’ Trust and Secure Feeling towards Cloud Services”, Proceedings of the 2012 International Conference on Advances in Computer‐Human Interactions, pp. 360–365.

Kauer, B. (2007), “OSLO: Improving the Security of Trusted Computing”, Proceedings of 16th USENIX Security Symposium, USENIX Association, Berkeley, CA, USA, pp. 16:1–16:9.

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, IEEE, pp. 380–387.

Kostiainen, K., Asokan, N. and Ekberg, J.‐E. (2011), “Practical Property‐Based Attestation on Mobile Devices”, in McCune, J., Balacheff, B., Perrig, A., Sadeghi, A.‐R., Sasse, A. and Beres, Y. (Eds.),Trust and Trustworthy Computing, Lecture Notes in Computer Science, Springer Berlin Heidelberg, Vol. 6740, pp. 78–92.

Law, S. (2006) "The Trusted Platform Module" [online], https://chillingeffects.org/anticircumvention/weather.cgi?WeatherID=534 [Accessed 30 January 2014]

Martin, A. (2008), The Ten Page Introduction to Trusted Computing, Tech. Rep. RR‐08‐11, Oxford University Computing Laboratory.

McAfee (2011) “McAfee Reveals Average Internet User Has More Than $37,000 in Underprotected ‘Digital Assets’” [online], www.mcafee.com/au/about/news/2011/q3/20110927‐01.aspx [Accessed 30 January 2014]

McAfee (2012) “Consumer Alert: McAfee Finds One in Every Six Personal Computers Have Zero Protection”, [online], www.mcafee.com/cn/about/news/2012/q2/20120530‐01.aspx [Accessed 30 January 2014]

McKnight, D.H., Choudhury, V. and Kacmar, C. (2002), “Developing and Validating Trust Measures for e‐Commerce: An Integrative Typology”, Information Systems Research, Vol. 13 No. 3, pp. 334–359.

Murray, D.G., Milos, G. and Hand, S. (2008), “Improving Xen security through disaggregation”, Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, ACM Press, Seattle, WA, USA, pp. 151–160.

Nahari, H. (2007), “Trusted Secure Embedded Linux”, Proceedings of the Linux Symposium, Ottawa, Canada, pp. 79–86. Neisse, R., Holling, D. and Pretschner, A. (2011), “Implementing Trust in Cloud Infrastructures”, Presented at the 11th

IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, IEEE, Newport Beach, CA, USA, pp. 524–533.

Pearson, S. (2013), “Privacy, Security and Trust in Cloud Computing”, in Pearson, S. and Yee, G. (Eds.),Privacy and Security for Cloud Computing, Computer Communications and Networks, Springer London, pp. 3–42.

Pearson, S. and Benameur, A. (2010), “Privacy, Security and Trust Issues Arising from Cloud Computing”, Presented at the 2010 IEEE Second International Conference on Cloud Computing Technology and Science, pp. 693–702.

Pew Research Center (2013) “Trust in Government Nears Record Low, But Most Federal Agencies Are Viewed Favorably” [online], www.people‐press.org/2013/10/18/ [Accessed 30 January 2014]

Roy, M.C., Dewit, O. and Aubert, B.A. (2001), “The impact of interface usability on trust in Web retailers”, Internet Research, Vol. 11 No. 5, pp. 388–398.

179

http://aws.amazon.com/cloudhsm/details/

http://www.mcafee.com/au/about/news/2011/q3/20110927-01.aspx

http://www.people-press.org/2013/10/18/


Sadeghi, A.‐R. and Stüble, C. (2005), “Property‐based attestation for computing platforms: caring about properties, not mechanisms”, Proceedings of the 2004 workshop on New security paradigms, ACM Press, pp. 67–77.

Sailer, R. et al (2005), “Building a MAC‐Based Security Architecture for the Xen Open‐Source Hypervisor”, Presented at the Annual Computer Security Applications Conference, IEEE, pp. 276–285.

Sailer, R. et al (2004), “Design and Implementation of a TCG‐based Integrity Measurement Architecture”, Proceedings of the 13th Conference on USENIX Security Symposium ‐ Volume 13, SSYM’04, USENIX Association, Berkeley, CA, USA, pp. 16–16.

Santos, N., Gummadi, K.P. and Rodrigues, R. (2009), “Towards Trusted Cloud Computing”, Proceedings of the 2009 conference on Hot topics in cloud computing, Article No. 3.

Santos, N., Rodrigues, R. and Ford, B. (2012a), “Enhancing the OS Against Security Threats in System Administration”, Proceedings of the 13th International Middleware Conference, Middleware ’12, Springer‐Verlag New York, Inc., New York, NY, USA, pp. 415–435.

Santos, N. et al (2012b), “Policy‐sealed Data: A New Abstraction for Building Trusted Cloud Services”, Proceedings of the 21st USENIX Conference on Security Symposium, Security’12, USENIX Association, Berkeley, CA, USA, pp. 10–10.

Schiffman, J. et al (2010), “Seeding clouds with trust anchors”, Proceedings of the 2010 ACM workshop on Cloud computing security workshop, ACM Press, pp. 43–46.

Schneier, B. (2005) "Trusted Computing Best Practices", [online], https://www.schneier.com/blog/archives/2005/08/trusted_computi.html [Accessed 30 January 2014]

Selhorst, M., Stüble, C. and Teerkorn, F. (2008), “Introduction and Analysis of the Open Source TCG Software Stack TrouSerS�and Tools in its Environment”, Study on behalf of the German Federal Office for Information Security (BSI), Bonn (Germany), Sirrix AG

Shashidharan, A. and Shah, J. (2011) "Enabling Cloud Customers to Trust the Cloud", [online] http://jiteshs.com/cloud‐trust.pdf [Accessed 30 January 2014]

Steinberg, U. and Kauer, B. (2010), “NOVA: a microhypervisor‐based secure virtualization architecture”, Proceedings of the 5th European conference on Computer systems, ACM Press, pp. 209–222.

TCG (2006) "TCG Infrastructure Work Group Architecture Part II ‐ Integrity Management", Specification Version 1.0, Rev.1.0 [online] https://www.trustedcomputinggroup.org/resources/infrastructure_work_group_architecture_part_ii__integrity_management_version_10 [Accessed 28 January 2014]

TCG (2007) "TCG specification architecture overview", Rev.1.4 [online] www.trustedcomputinggroup.org/files/resource_files/AC652DE1‐1D09‐3519‐ADA026A0C05CFAC2/TCG_1_4_Architecture_Overview.pdf [Accessed 28 January 2014]

TCG (2011) "TPM Main Specification", Specification Version 1.2, Rev.116 [online] https://www.trustedcomputinggroup.org/resources/tpm_main_specification [Accessed 28 January 2014]

TCG (2014) "TCG Members" [online], www.trustedcomputinggroup.org/about_tcg/tcg_members [Accessed 28 January 2014]

Uusitalo, I. et al (2010), “Trust and Cloud Services ‐ An Interview Study”, Presented at the IEEE Second International Conference on Cloud Computing Technology and Science, IEEE, pp. 712–720.

Zhang, F. 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, ACM Press, pp. 203–216.

180

http://www.trustedcomputinggroup.org/about_tcg/tcg_members

Retaining Control Over Private Virtual Machines Hosted by a Cloud Provider Using Mandatory Access...

Documents

Transcript of Retaining Control Over Private Virtual Machines Hosted by a Cloud Provider Using Mandatory Access...