Retaining Control over Private Virtual Machines Hosted by a Cloud Provider Using Mandatory

Access Control, Trusted Boot and Attestation

Armin Simma, Philipp Rusch
Vorarlberg University of Applied Sciences, Austria
armin.simma@fhv.at
philipp.rusch@students.fhv.at

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. The measurement flow. (Based on TCG, 2007)

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), 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).

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)

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[..]”.
§ Low usability: Usage of and trust in attestation-based cloud computing is adversely affected
by low usability (Jarvenpaa, Tratinsky and Saarinen, 1999), (Heijden, Verhagen and
Creemers, 2003). In the prototypical implementations mentioned above, the cloud customer
has to compare the PCR values by hand. However, it would be unreasonable to ask the
average customer to do so.
Therefore it is proposed that additional software should run on the local computer of the cloud
customer. This software is called Cloud Attestor and Advisor (CAA). CAA needs to be
integrated with the TC-based attestation system running on the CSP’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 customer directly interacts with.
Therefore trust level of customers into CAA must be very high.  
§ (Missing?) Recommendations and reputation: In the following CAA is compared with antivirus
software since both perform security-relevant tasks, both download comparative data from a
remote entity – called signature files in antivirus software - and both must be trusted by end
users if end users should accept them.
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% of the participants in a study from McAfee (2011) answered they use free
software for security protection purpose. Many computer 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 survey that 58% cannot distinguish between 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 malware signature
database. This signature database (as well as the software) comes from a trusted entity. The
same should be implemented in TC-based and attestation-based cloud ecosystems: trusted
reference values for PCRs are downloaded from a separate trusted entity and the local
(trusted) software handles the necessary attestation and integrity checks.
It should be emphasized at this point that most users trust antivirus software without detailed
knowledge about the technologies behind it. The following question arises: Where does the
high trust level result from? The hypothesis of the authors is that the contributing factors are
recommendations by experts and/or the media, usability and the reputation of the companies
developing 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 TPM main 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 the ecosystem 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 has been discovered that insider attackers are among the nine most critical threats
to cloud systems (Cloud 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. The trust 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.

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.
§ 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.

References
Amazon Web Services (2013) “AWS CloudHSM Product Details “ [online],
http://aws.amazon.com/cloudhsm/details/ [Accessed 30 January 2014 ]
Bleikertz, S., Bugiel, S., Ideler, H., Nürnberger, S. and Sadeghi, A.-R. (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., Chockler, G., Chockler, H., Gheorghe, G., Santos, N. and Shraer, A. (2013),
“Verifying cloud services: present and future”, ACM SIGOPS Operating Systems Review, Vol. 47
No. 2, pp. 6–19.
Chen, L., Landfermann, R., Löhr, H., Rohe, M., Sadeghi, A.-R. and Stüble, C. (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.
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., Jaeger, T., Valdez, E., Caceres, R., Perez, R., Berger, S., Griffin, J.L., 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., Zhang, X., Jaeger, T. and van Doorn, L. (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., Rodrigues, R., Gummadi, K.P. and Saroiu, S. (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., Moyer, T., Vijayakumar, H., Jaeger, T. and McDaniel, P. (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__i
ntegrity_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., Karppinen, K., Juhola, A. and Savola, R. (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., Chen, J., Chen, H. and Zang, B. (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.