Trusted Platform-as-a-Service: A Foundation for Trustworthy Cloud-Hosted Applications

(1)

Trusted Platform-as-a-Service: A Foundation for

Trustworthy Cloud-Hosted Applications

Andrew Brown

Dept. of Computer Science

Duke University

brownan@cs.duke.edu

Jeffrey S. Chase

Dept. of Computer Science

Duke University

chase@cs.duke.edu

ABSTRACT

The applications we use are increasingly packaged as network services running in the cloud under the control of a service provider. Users of these services have no basis to determine if these services are trustworthy, beyond the assurances of the service provider. Our work addresses the problem of how to build support for trustworthy services in the cloud, within the context of a larger trust management framework.

This paper shows how users can gain insights and trust into service applications by leveraging trust in a neutral third party: a cloud provider that hosts application services on an infrastructure and platform that it controls. A trusted cloud provider may act as a root of trust to attest cloud-hosted services to their clients—a trusted platform cloud. We have prototyped this approach in a trusted platform-as-a-service cloud provider supporting a Python/Django web framework. The cloud provider seals instances of service applications and attests their Python source code to external users. Once launched and attested, service instances run with an independent identity and are isolated from tampering by the cloud customer, except through well-defined operator interfaces that are part of the service definition.

Categories and Subject Descriptors

D.4.6 [Security and Protection]: General

General Terms

Design, Security

Keywords

Cloud Computing

1. INTRODUCTION

How can users know whether a given server-based applica-tion is trustworthy? Users control the applicaapplica-tions they run on their own machines: for example, they can fetch the code

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

from a trusted source, monitor the application’s behavior while it runs, or run the application in an isolated environ-ment [6]. But users have no control over application services accessed through the network. In general, these services are closed systems, and users have no independent insight into their behavior: the only basis for trusting them is to accept assurances offered by the service provider. Many users are willing to trust their service providers with limited evidence or accountability, and many service providers are trustworthy. Even so, service providers may have an incentive to conceal or misrepresent the behavior of the service. Recent concerns about privacy of various popular services are symptoms of this limitation.

To illustrate the problem, consider a simple scenario that serves as a running example in this paper: a voting service. Suppose that a group of users wishes to vote on a matter for which all members of the group have an interest in the outcome. An obvious solution is to run a voting program as a network service: group members log in to a common instance of the service and enter their votes. The program counts the votes and reports the outcome. It is clear what it means to trust this service: each user must believe that it accepts at most one vote from every user, keeps the votes secret, counts the votes correctly, and reports an outcome that reflects the correct count. But a user cannot verify these properties unless it has exclusive control over the service. For example, even if a client trusts the program code, it cannot know if the program was tampered before launch.

Cloud hosting offers the potential to gain trust in services by leveraging trust in a neutral third party: the cloud hosting provider. In a cloud hosting system, a service provider S

requests a cloud provider C to launch the program P on resources owned and controlled by the cloud provider. S

initiates the program launch and may control the service instanceI in well-defined ways after it is launched. But it is C, and notS, that controls the server platform and the launch procedure. Figure 1 depicts this arrangement.

This paper outlines the design and implementation of a cloud platform for trustworthy cloud-hosted services. The basic idea behind our approach—platform attestation of software identity—is familiar from more than a decade of work on trusted computing platforms (e.g., [10, 4, 13, 8, 3]). A trusted platform runs programs in response to user requests, and issues digitally signed assertions of the program’s identity (e.g., a code hash) for use by other entities that interact with the running program instance. Any entity believing that the program P is safe can then infer that the instance I

(2)

(TPM) hardware in most server platforms, and is extended with post-launch checks in various TPM-based systems, e.g., Intel’s Trusted Execution Technology. Note, however, that our approachdoes not use TPM.

In our approach, the cloud providerC itself serves as a trusted platform or software root of trust (“Trusted Platform Cloud”). Our premise is thatC runs a standard and well-tested software stack that offers a general-purpose hosting platform for many tenants, and thatCcan be trusted to have no interest in the outcome of any service instance it hosts as long as the launch request is authorized andSpays the bills. Although our prototype does not use TPM, a cloud provider using our approach could use TPM hardware internally to strengthen assurances of trustworthiness to its customers, by issuing attestations of its own software stack based on a hardware root of trust, as suggested, for example, by Santos et. al. [11]. Alternatively, trust in the cloud providerC

could be based on reputation, auditing procedures, economic incentives, or other other social factors, instead of or in addition to certification of theC’s software stack by TPM or other mechanisms.

We have prototyped our approach in a simple platform-as-a-service (PaaS) cloud provider based on the Python/Django web framework. A cloud provider (C) controls the underly-ing infrastructure and provides a standard Python+Django execution environment and associated platform APIs. The application program (P) is transferred as Python source code toC, which executesP in a virtual machine instance loaded with a standard Linux/Apache/Python stack and a set of standard Python/Django library modules deemed safe byC. This structure is similar to many PaaS cloud hosting systems such as Google AppEngine. What is new is that the PaaS platform offers trusted attestation: the cloud provider attests to the identity of the Python source code that implements the application logic loaded onto this standard stack. Calso protects each instance from any tampering after launch, re-stricting any control actions bySother than those supported by explicit operator APIs inP.

Although the Trusted Platform Cloud idea could be used for infrastracture-as-a-service clouds as well, “Trusted PaaS” attestation offers some advantages relative to attestation of machine code or virtual appliances. The attested source code is relatively compact due to the presence of rich support libraries in the platform. The attested software is directly readable by humans, and it may be verified by source-level analysis tools. All functions necessary to translate and exe-cute the program are encapsulated in the trusted platform cloud, minimizing the risk that a malicious tool chain will introduce malware into the program after the source code is inspected [14].

On the down side, the Trusted Computing Base (TCB) maintained by the trusted PaaS cloud provider is quite large, since the platform stack and support modules are part of

C’s TCB. Thus it could be argued that our approach merely shifts the trustworthy services problem rather than solving it. More precisely, we leave the challenge of verifying cloud providers and their software stacks—if needed—as an open problem to be addressed by auditing procedures and/or cloud attestation, e.g., as proposed by Santos et. al. [11].

Our approach is practical and allows us to address trust management for cloud-hosted services, taking the integrity of the cloud provider as a given. BecauseIis sealed against tampering by S, it must run as an independent identity

that speaks with its own keypair and whose private key is encapsulated within the instance and hidden from S. In essence, trusted platforms and attestation introduce software identities that are dynamic, isolated, and autonomous into the identity and trust management framework; theseservice instance identities (SIDs) are independent of any person, organization, or other real-world identity. Clients and other entities that interact with an SID instance I must have a means to infer trust properties ofIand associate them with

I’s public key. In particular, it is no longer sufficient to bind I’s public key to a DNS domain controlled by S—a cornerstone of the security architecture of today’s Web. To address this need, our ongoing work focuses on integrating trusted PaaS attestation with a decentralized trust man-agement framework based on an authorization logic called Attribute-Based Access Control (ABAC) [7]. We believe that the combination of attested SIDs and authorization logics is a powerful approach to introducing trustworthy coordination services into the cloud ecosystem, among other goals.

2. OVERVIEW

Figure 1 depicts the threat scenario (left-hand side) and the basis for the proposed defense in a cloud hosting system (right-hand side), as discussed in the introduction.

Threat model.A service provider launches a malicious or faulty application service, either by accident or for ma-licious intent. An unsuspecting user discovers the service and interacts with it. The service threatens the user, e.g., by misappropriating user data, failing to provide the adver-tised service, and/or vectoring additional harmful functions without user consent. The user has no basis for trusting the service and must do so only out of faith.

Proposed defense. The service provider launches the application service as an instance hosted on a trusted plat-form cloud. The cloud provider issues a signed attestation of the service code. Users of the service, or their web browsers or other user agents, may read and validate the attestation. The attestation is bound to the instance’s public key, which the client uses to authenticate the instance.

This structure enables users or user agents to reason about the behavior of the instance, and decide whether to trust it. For example, clients may use an extended authorization logic to combine the attestation with assertions about the the properties of the program issued by other trusted par-ties, as outlined later. The trusted PaaS model offers an additional option: it may in some cases be sufficient for the cloud provider to expose the source code for direct inspec-tion through a special link that is securely bound to the instance, holding the service provider accountable for the program that it has launched. This approach is compatible with existing browsers and other standard user agents for interacting with cloud services. It is the model supported in our initial prototype.

To illustrate, we have implemented and deployed the secure group voting example outlined in the introduction. Figure 2 depicts a simplified view of the code. A chosen member from the group (who acts as the service providerS) finds the program codeP and requests a trusted PaaS cloud provider

C to launchP as an instance. ClaunchesP on a standard Python/Django platform stack. The platform stack running in the instance generates a new keypair for the instance. C

offers a new cloud services API to bind the instance’s public key securely to a client-readable display of the source code,

(3)

Program Instance Service Provider User Runs/ Invokes Becomes _Program Instance Service Provider

User Cloud Provider

Initiates/ Invokes Runs On Becomes Seals/ Provides Platform Attests Controls Administers

Figure 1: On the left-hand side, a service provider S runs a service program P and controls the resulting service instanceI: users ofI have no basis to trust it other than to accept assurances ofS. On the right-hand side, a neutral third-party cloud provider hosts the service. The cloud provider seals the service instance against tampering and attests to the identity of the software that it runs. Any entity with knowledge of P

and trust inC can then reason about the behavior of I and its trustworthiness.

and to a secure hash of the code. A URL derived from the instance URL enables users to inspect the Python code attested by the cloud provider.

These trusted PaaS mechanisms enable users to reason about the behavior ofIfrom known properties of the program

P thatIis running. In the case of the voting example,P is simple enough for group members to verify its correctness and safety. The actual working code for the voting application is 238 lines of Python (percloc). It is compact in part because it uses standard support libraries in the platform stack to implement common functions. For example, it uses standard libraries to e-mail the voters entered by the operator and request them to participate in the vote. Users accept by clicking a secure HTTPS URL in the e-mail message, which includes a large random token to authenticate each client.

3. SEALED INSTANCES

The trustworthy services model requires that each service runs as an autonomous entity (SID) with its own keypair. Trust in the instance stems from believed properties of the program that it is running (P), and not from the identity of the cloud customer who launched it (S). Scan control the instance, but only in limited ways allowed by a well-defined operator API inP.

A key element of the trusted platform cloud model is that the cloud providerC seals the instance to isolate it from tampering by S. In particular, S cannot “log in as root” and modify the software stack or configuration, as would be allowed on a standard IaaS cloud system (e.g., using EC2 APIs). The concept of instance “sealing” means that an instance, once launched, cannot be modified or tampered except through the application’s defined API. This prevents

Sfrom modifying the code and inserting malicious code at a later time, or accessing the service’s data.

To see why sealing is important, consider the voting ap-plication example. Each user is able to view the program code attested by the cloud provider, and the code is simple enough to see that it behaves as expected. For example, it is clear from the code that votes are counted anonymously. Now suppose thatS is untrustworthy. IfS could update the code after launch without detection,Scould modify the code to record user votes rather than merely counting them. This change violates the anonymity property, but users

in-specting the launched code would incorrectly conclude that the instance is safe. (This is an example of the well-known pitfall called Time-of-Check-to-Time-of-Use.) In our system

S is not permitted to changeP once it is launched. The cloud provider must also seal the instance against any path to inspect or manipulate its program state, including low-level debugging interfaces or raw storage access. For example, ifScould access the instance state, thenScould manipulate the vote count or close the poll early to commit a transient vote count thatSviews as favorable.

Our solution is to seal the instance againstall methods of access apart from the program’s defined web interface or API. Programs define any special operator interfaces needed to administer the service. For the voting application, the operator (admin) interface enables an operator to enter a list of voter e-mail addresses, open the voting, and close the voting. Part of the admin interface can be seen in Figure 2: the view1 _{to close a poll is accessible only by an “admin.”}

The result of the poll is visible only after the voting is closed. Importantly, these administrative interfaces are part of the service definitionP, so they are visible to any endorsing entities as a basis for reasoning about the program’s behavior and security properties. The admin may have special powers relative to other users, but those powers are enumerated and disclosed in the program code. If an admin has the power to abuse private data, it appears in the program for all to see. Privilege to access the admin interface is granted to the cloud customer S that initiated the launch of the service to provide it to a user community. In our prototype, S

authenticates to the admin interface using a password passed into the instance through the cloud provider API. In addition to permission to access the admin interface, S may also request C to terminate the instance. These limited forms of control are the only actions thatS can perform on the instance. In essence, S may impose a fail-stop failure on the instance, but it cannot subvert the instance (Byzantine failure) once it is launched

One can view this sealing of the instance as a change of identity. In today’s Web, we ordinarly view a service as running with the identity of the service provider that initiated

1

A “view” is a Django term that refers to a Python function that handles the request-response processing for a particular URL.

(4)

def close_voting(request, pollid): if request.user.is_admin():

poll = Poll.objects.get(id=pollid) poll.voting_closed = True

def submit_vote(request, pollid): poll = Poll.objects.get(id=pollid) if (not poll.voting_closed and

request.user not in poll.voters): # Polls are open and user has not voted, # record this vote

# Mark this user as having voted poll.voters.add(request.user) # Record this vote in the tally choice = request.form.choice

candidate = poll.candidate.get(id=choice) candidate.tally += 1

# Display vote success page

return render("vote_successful.html") def display_results(request, pollid):

poll = Poll.objects.get(id=pollid) if poll.voting_closed:

# Voting is closed, display results

return render("display_results.html", poll)

Figure 2: A simplified view of the voting applica-tion. This shows how simple code can be verified “at a glance” for correctness and security. Notice that votes are securely counted, users and their votes are not correlated, and results cannot be viewed by any-one until voting is closed.

it. That is, a running program has all of the powers of the identity S on behalf of whom it is running, and no other powers; any trust that users place in the running program instance is the same as the trust they place inSand other programs run by S. In contrast, sealed instances can be thought of as having their own identity, separate fromS, with their own separate level of trust from users. A user who does not necessarily trust S may still trust a sealed, endorsed, attested instance launched byS. This trust flows from properties of the programP, and not from the identity ofS. This concept is similar to the Unixsetuidmechanism, in which a program runs with the identity of the owner of the program file, rather than the identity associated with the process that executed it. Thesetuidmechanism is commonly used to allow users to launch programs that run with more or different privilege than the user itself has, including access to private state that is not directly accessible to the user. To protect the system, runningsetuidprograms must be sealed against any tampering by the user.

As a side effect, sealing of instances inhibits normal up-grades to their code. Any upgraded versions ofP must be deployed as separate instances with their own identities. Var-ious techniques could be used to carry instance state forward

through a chain of secure instance identities, but we have not investigated this issue.

4. PROTOTYPE

We have prototyped a trusted PaaS cloud provider using a Eucalyptus infrastructure-as-a-service cloud under the con-trol of a front-end service based on Open Resource Concon-trol Architecture (ORCA) [5, 2]. The TCB includes the ORCA server, the Eucalyptus cloud manager, and a default sealed image.

As shown in Figure 3, a request fromS toC to launch a PaaS application is received at the ORCA server, which issues a request to the Eucalyptus cloud controller to launch a KVM virtual machine instance loaded with the default sealed image. The sealed image contains an up-to-date (“secure”) Linux-Apache-Python based web stack, with Django for the web framework. The image also contains a custom startup script that works with the ORCA server to perform these steps:

• Acquire and unpack a tar file containing a Django project (P) that was passed in at boot time through the ORCA server. Verify the code hash.

• Install the application and configure the web server appropriately.

• Generate a new keypair and SSL (X.509) certificate request.

• Pass the certificate request to the ORCA server through a secure channel. The ORCA server signs the certificate with its private key and passes the signed certificate back to the instance startup script.

• Install the certificate and start up the web server and the application.

• Seal the instance: close the SSH server and any other listening services apart from the web server.

The node then serves web requests over HTTPS using the certificate signed by the cloud provider (the ORCA server). The SSL private key is necessarily kept secret from the service provider. To limit the attack surface area, the private key is known only to the instance and is never transmitted to any other machine; the key never leaves the instance and is destroyed when the instance is destroyed. Since the certificate is signed byC, users are assured the SSL connection is to a machine controlled byC, which would not be possible ifS

were allowed to upload its own certificate and key.

On a separate port on the virtual machine instance node, another web server runs that is not controlled by the up-loaded application. In our prototype this server providesC’s attestation: a hash and a snapshot of the program source code launched in the instance. Since the cloud provider is presumed trusted, users know that this interface is not con-trolled by the application and always responds with the true code that is running in the instance.

5. TRUST MANAGEMENT

Trust management in the Web currently relies on binding the instance public key to a domain name trusted by the user. The binding is established by means of a certificate issued by one of a collection of designated Certifying Authorities,

(5)

Handler Instance Service Provider Secure Service Cloud Provider Trusted Computing Base Sealed Image Startup Script Requests Service Fetches/Runs Launches VM ORCA Server Provides Cloud Interface Program Cloud/Cluster Controller Administers Becomes User Interacts With Becomes (1) (2) (3) (4) (5) (6)

Figure 3: This graphic depicts the process for deployment on our current implementation. A Service provider first requests a new instance from the ORCA server and provides the program code. ORCA then launches a trusted image designated for running secured code. The image has a script that fetches the program, launches it, and seals itself.

which are (in practice) globally trusted by web users. Among other limitations, this existing trust model presumes that both the domain name and the private key are the property of the service providerS.

This conventional approach is not suitable for endorsing the public key of a secure service instance (SID), because the instance’s private key is its own and is not revealed to

S. In our prototype, the instance authenticates to the web browser using an X.509 identity certificate that is signed by

C. With the existing Web trust management framework, this approach requires the user browser to acceptC as a Certifying Authority.

We propose to integrate the trusted platform cloud mech-anisms with trust management in a more satisfactory way, using an authorization logic. This approach enables a client to combine signed security assertions from multiple sources in determining what trust to assign to the instanceI and its public key. In particular, users or their user agents (e.g., apps) may combine assertions about properties of the pro-gramP with assertions byCthat bind the code forP to the instanceI and its public key.

Figure 4 illustrates a simple example of this idea. A third-party “Attribute Authority” asserts security properties ofP, which are issued as signed credentials bound to the hash of

P. In the example of Figure 4, the issued assertion says “A

believes thatPissafe.” The Attribute AuthorityAmight be an automated code analysis service, a trusted organization with access to the source code, or some other endorsing entity. The client combines this assertion with a credential signed by the cloud provider saying “C attests that I is running

P”, and endorsing I’s public key. Reasoning from these assertions, the client can conclude thatIissafe, if the client trusts the assertions made byAandC. Of course, these trust policies might involve a richer set of code attributes and local policies for reasoning about attributes and their sources. We are basing our ongoing work on the ABAC project [7] and the software package libabac [9], which defines a simple yet powerful authorization logic for reasoning from attribute credentials encoded as X.509 attribute certificates.

6. RELATED WORK

Code attestation by a root of trust is now available in Trusted Platform Module (TPM) implementations in most server platforms. TPM is tamper-evident hardware that attests to machine code loaded into memory [10, 3].

The vTPM project [1] extends TPM attestation capabil-ities to secure virtual machines. Terra [4] utilizes virtual machines on itstrusted virtual machine monitor to provide a mechanism for applications with differing security require-ments to run together on commodity hardware. They also have remote attestation features built in that allow their VMs to cryptographically identify the software they run.

Various other projects leverage TPM capabilities for re-mote attestation of software to other entities across a network. Flicker [8] defines a mechanism for isolating programs running on a machine with a minimal trusted computing base. Flicker uses TPM to provide attestation, including remote attesta-tion, of subprograms that run in a local isolated environment. Flicker protects the integrity of attested subprogram actions even in the presence of malicious operating system, BIOS, and DMA devices, without requiring a new operating system or virtual machine monitor.

BIND [13] is aimed at a practical implementation of code attestation and addresses two difficult problems: time-of-check to time-of-use complications and difficulty of hash verification. BIND is able to attest code at a fine-grained level rather than an entire memory image.

All of these systems can serve as a foundation for in-stance attestation for virtual machine providers, such as cloud infrastructure-as-a-service providers. With suitable extensions, they could support attestation of cloud-hosted services to their clients, as in our proposal. The goal of our work is to explore cloud service architecture and trust management for attested cloud-hosted services, taking trust in the cloud provider as a given. Our approach does not rely on TPM, but it could leverage these TPM-based approaches to strengthen protection by rooting the attestation chain in trusted hardware operated by the cloud provider, rather than trust in the cloud provider itself. Notably, Santos et.

(6)

Program Code Attribute

Authority Cloud Provider

Instance Endorses/ Certifies A.safe←P Attests C.P←I Client Trusts/ Invokes Becomes Trusts

Figure 4: In ongoing work, we are integrating with a trust management framework based on the ABAC authorization logic. A third party issues signed as-sertions of safety properties of the programP. The cloud provider issues an ABAC certificate attesting that the instanceI is running P. An ABAC-aware client or certifying proxy uses an ABAC inference engine to infer that I has the asserted safety prop-erties of P, and uses that inference to drive autho-rization decisions for interactions withI.

al. propose an approach to meet this goal of atrusted cloud computing platform [11] based on TPM attestation chains. Our work is complementary to these efforts.

Our approach combines remote attestation with a role-based authorization logic [7] called Attribute-Based Access Control (ABAC). The Nexus project [15, 12] takes a similar approach at the node OS level: Nexus offers a new operating system [15] on a TPM-based hardware root of trust, and a powerful new authorization logic called NAL [12] to reason about attested software instances. Nexus and NAL show that authorization logic is a powerful tool for reasoning about attested software identities. Our ongoing work explores a similar combination as a basis for trustworthy cloud services.

7. CONCLUSION

Remote attestation can come in many forms, but for the case of a trusted cloud provider that provides a generic plat-form for service applications, attestation of these applications is simple, beneficial, and powerful. Users with no insights into what their services are doing with their sensitive data have no choice to trust the service blindly. For situations where this is not acceptable, a technical solution involving the cloud provider attesting the instance code solves this “break” in the trust chain.

Acknowledgements

This research is supported by the National Science Founda-tion through award CNS-0910653, and by Duke University.

8. REFERENCES

[1] S. Berger, R. C´aceres, K. A. Goldman, R. Perez, R. Sailer, and L. van Doorn. vTPM: virtualizing the

trusted platform module. InProceedings of the 15th USENIX Security Symposium - Volume 15, Aug. 2006. [2] J. Chase, L. Grit, D. Irwin, V. Marupadi, P. Shivam,

and A. Yumerefendi. Beyond Virtual Data Centers: Toward an Open Resource Control Architecture. In Selected Papers from the International Conference on the Virtual Computing Initiative (ACM Digital Library), May 2007.

[3] P. England, B. Lampson, J. Manferdelli, and B. Willman. A trusted open platform.Computer, 36(7):55 – 62, July 2003.

[4] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh. Terra: a virtual machine-based platform for trusted computing. InProceedings of the Nineteenth ACM Symposium on Operating Systems Principles, SOSP ’03, pages 193–206, 2003.

[5] D. Irwin, J. S. Chase, L. Grit, A. Yumerefendi, D. Becker, and K. G. Yocum. Sharing Networked Resources with Brokered Leases. InProceedings of the USENIX Technical Conference, June 2006.

[6] B. Lampson. Accountability and freedom. InCambridge Computer Seminar, Cambridge, UK, October 2005. [7] N. Li, J. C. Mitchell, and W. H. Winsborough. Design

of a role-based trust-management framework. In Proceedings of the 2002 IEEE Symposium on Security and Privacy, pages 114–130, May 2002.

[8] J. M. McCune, B. J. Parno, A. Perrig, M. K. Reiter, and H. Isozaki. Flicker: an execution infrastructure for TCB minimization. InProceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, Eurosys ’08, pages 315–328, New York, NY, USA, 2008. ACM.

[9] M. Ryan, T. Faber, J. Wroclawski, and S. Schwab. Attribute-based access control.

http://abac.deterlab.net/, 2011. [Online; accessed 22-July-2011].

[10] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. Design and implementation of a TCG-based integrity measurement architecture. InProceedings of the 13th conference on USENIX Security Symposium - Volume 13, SSYM’04, pages 16–16, Berkeley, CA, USA, 2004. USENIX Association.

[11] N. Santos, K. P. Gummadi, and R. Rodrigues. Towards trusted cloud computing. InProceedings of the Workshop on Hot Topics in Cloud Computing, HotCloud’09. USENIX Association, 2009.

[12] F. B. Schneider, K. Walsh, and E. G. Sirer. Nexus authorization logic (NAL): Design rationale and applications.ACM Trans. Inf. Syst. Secur., 14:8:1–8:28, June 2011.

[13] E. Shi, A. Perrig, and L. V. Doorn. BIND: A fine-grained attestation service for secure distributed systems. InIn IEEE Symposium On Security and Privacy, pages 154–168, 2005.

[14] K. Thompson. Reflections on trusting trust.Commun. ACM, 27:761–763, August 1984.

[15] D. Williams, P. Reynolds, K. Walsh, E. G. Sirer, and F. B. Schneider. Device driver safety through a reference validation mechanism. InProceedings of the 8th USENIX conference on Operating systems design and implementation, OSDI’08, pages 241–254, Berkeley, CA, USA, 2008. USENIX Association.