Secure Service Provisioning in a Public Cloud

(1)

Mälardalen University Press Licentiate Theses No. 157

SECURE SERVICE PROVISIONING IN A PUBLIC CLOUD

Mudassar Aslam

2012

School of Innovation, Design and Engineering Mälardalen University Press Licentiate Theses

No. 157

SECURE SERVICE PROVISIONING IN A PUBLIC CLOUD

Mudassar Aslam

2012

(2)

ISSN 1651-9256

(3)

(4)

(5)

Populärvetenskaplig

sammanfattning

Utvecklingen av molntekniker möjliggör utnyttjande av IT-resurser över Internet, och kan innebära många fördelar för såväl företag som privat-personer. Dock innebär denna nya modell för användandet av resurser att säkerhetsfrågor uppstår, frågor som inte existerat i traditionell resur-shantering på datorer. I avhandlingen fokuserar vi på säkerhetsfrågor som rör en användare av molntjänster (t.ex. en organisation, myndighet etc.), när användaren vill leasa molntjänster i form av Virtuella maskiner (VM) från en publik leverantör av Infrastructure-as-a-Service (IaaS).

Det finns många säkerhetsområden i molnsystem: att hålla data hemliga, att resurserna är korrekta, att servicen är den utlovade, att säkerheten kan kontrolleras, etc. I denna avhandling fokuserar vi på säkerhetsproblem som resulterar i att tillit saknas mellan aktörerna i molnsystem, och som därmed hindrar säkerhetskänsliga användare från att använda molntjänster. Från en behovsanalys ur säkerhetsperspektiv föreslår vi lösningar som möjliggör tillit i publika IaaS-moln.

Våra lösningar rör i huvudsak säker livscykelhantering av virtuella maskiner, inklusive mekanismer för säker start och säker migrering av virtuella maskiner. Lösningarna säkerställer att användarens VM alltid är skyddad i molnet genom att den endast tillåts exekveras på pål-itliga (trusted) plattformar. Detta sker genom att använda tekniker för s.k. trusted computing (pålitlig datoranvändning), vilket innebär att användaren på distans kan kontrollera om plattformen är tillförlitlig eller inte. Vi presenterar även en prototypimplementation som visar re-aliserbarheten av de föreslagna säkerhetsprinciperna för säker start och migrering av VM.

(6)

(7)

Abstract

The evolution of cloud technologies which allows the provisioning of IT resources over the Internet promises many benefits for the individuals and enterprises alike. However, this new resource provisioning model comes with the security challenges which did not exist in the traditional resource procurement mechanisms. We focus on the possible security concerns of a cloud user (e.g. an organization, government department, etc.) to lease cloud services such as resources in the form of Virtual Ma-chines (VM) from a public Infrastructure-as-a-Service (IaaS) provider. There are many security critical areas in the cloud systems, such as data confidentiality, resource integrity, service compliance, security audits etc. In this thesis, we focus on the security aspects which result in the trust deficit among the cloud stakeholders and hence hinder a security sensi-tive user to benefit from the opportunities offered by the cloud comput-ing. Based upon our findings from the security requirements analysis, we propose solutions that enable user trust in the public IaaS clouds. Our solutions mainly deal with the secure life cycle management of the user VM which include mechanisms for VM launch and migration. The VM launch and migration solutions ensure that the user VM is always protected in the cloud by only allowing it to run on the user trusted plat-forms. This is done by using trusted computing techniques that allow the users to remotely attest and hence rate the cloud platforms trusted or untrusted. We also provide a prototype implementation to prove the implementation feasibility of the proposed trust enabling principles used in the VM launch and migration solutions.

(8)

(9)

Acknowledgments

First of all, I am really thankful to my Allah who gave me perseverance, knowledge and strength to achieve this milestone. I pray Him to make my knowledge beneficial for others.

I am grateful to all people in SICS, MDH and Ericsson who sup-ported and guided me in doing this work; especially, my co-supervisor Dr. Christian Gehrmann who provided me the opportunity to work in an esteemed research environment at SICS. I am indebted to all the efforts and valuable time that Christian has spent on me for guiding, improv-ing and polishimprov-ing my research skills right from the very first day. I also want to express my sincere regards and gratitude for my main supervi-sor Prof. Mats Björkman who provided me the much needed motivation, inspiration and guidance in achieving this milestone.

I feel happy, satisfied and proud to get the opportunity to work with the learned researchers from SICS and Ericsson who provided very useful feedback to improve my work and tune it according to the current and future industrial demands. I express my gratitude to András Méhes who provided his insightful criticism to remove the lacunae in various stages of this work; Lars Rasmusson, Fredric Morenius and Nicolae Paladi for their collaborative research and development activities; and Rolf Blom for his useful research directions.

I am really thankful to all my co-workers specially Anders Gunnar, Anders Lindgren, Bengt Ahlgren, Björn Grönvall, Henrik Abrahamsson, Ian Marsh, Laura Feeney and Maria Holm who provided a unique profes-sional and research environment for me. I would specially like to thank Oliver Schwarz for his discussions (technical and social) and valuable suggestions whenever solicited.

Finally, I would like to thank all my friends and colleagues including Shahid Raza, Shahzad Saleem, Zeeshan Ali Shah and many others who helped me whenever required.

(10)

vi

I would like to dedicate this work to my parents and family who supported me throughout my academic and professional carrier with their love, guidance and sacrifices whenever required.

Mudassar Aslam Stockholm, October, 2012

This work has been performed in the Secure Systems Group (SecSys) which is a security group within Communication Networks and Systems laboratory (NETS) in the Swedish Institute of Computer Science (SICS). Other partners that were involved in various projects include Ericsson, Saab, TeliaSonera and T2Data. The funding for this work has mainly been provided by VINNOVA through different research projects, and also by the Higher Education Commis-sion (HEC), Pakistan in the form of scholarship grant for my PhD studies.

The SICS is jointly sponsored by the Swedish government and the Industry partners which include TeliaSonera, Ericsson, Saab AB, FMV (Defense Ma-teriel Administration), Green Cargo (Swedish freight railway operator), ABB, and Bombardier Transportation.

(11)

List of Publications

Papers Included in the Licentiate Thesis

1

Paper A Security Considerations for Virtual Platform Provisioning. Mudassar Aslam, Christian Gehrmann. In European Conference

on Information Warfare and Security ECIW-2011, 7-8 July 2011, Tallin, Estonia.

Paper B Securely Launching Virtual Machines on Trustworthy Plat-forms in a Public Cloud.

Mudassar Aslam, Christian Gehrmann, Lars Rasmusson, Mats

Björkman. In 2nd International Conference on Cloud Comput-ing and Services Science, CLOSER 2012, 18-21 April 2012, Porto, Portugal.

Paper C Security and Trust Preserving VM Migrations in Public Clouds. Mudassar Aslam, Christian Gehrmann, Mats Björkman. In 2nd

IEEE International Symposium on Trust and Security in Cloud Computing, part of IEEE TrustCom-12, 25-27 June 2012, Liver-pool, UK.

Paper D Protecting Private Data in the Cloud.

Lars Rasmusson, Mudassar Aslam. In 2nd International Con-ference on Cloud Computing and Services Science, CLOSER 2012, 18-21 April 2012, Porto, Portugal.

1

The included articles have been reformatted to comply with the thesis layout

(12)

viii

SICS Technical Reports

• Mudassar Aslam, Christian Gehrmann. TCG Based Approach for Secure Management of Virtualized Platforms: state-of-the-art.

ISSN No. 1100-3154, SICS Technical Report (T2010:05), 2010. Available at http://soda.swedish-ict.se/3993/

• Mudassar Aslam, Christian Gehrmann. Deploying Virtual Ma-chines on Shared Platforms. ISSN No. 1100-3154, SICS Technical

Report (T2011:07), 2011. Available athttp://soda.swedish-ict. se/4170/

(13)

List of Acronyms

AI K _{Attestation Identity Key}

CAP EX _{Capital Expenditure}

Client _{See U ser}

CSA _{Cloud Security Alliance} CSP _{Cloud Service Provider}

EK _{Endorsement Key}

GuestOS _{Guest Operating System}

I aaS _{Infrastructure-as-a-Service}

P aaS _{Platform-as-a-Service}

P CA _{Privacy CA}

P CR _{Platform Configuration Registers} P rovider _{Cloud Service Provider}

P T AA _{Platform Trust Assurance Authority} SaaS _{Software-as-a-Service}

SecaaS _{Security-as-a-Service}

SLA _{Service Level Agreement}

SRK _{Storage Root Key}

(14)

x

T AL _{Trust Assurance Level} T CG _{Trusted Computing Group}

T P M _{Trusted Platform Module}

T SP I _{TCG Service Provider Interface}

T SS _{TCG Software Stack}

U ser _{Cloud Service User}

(15)

8.7 Security Analysis . . . 86 8.7.1 Authentication . . . 87 8.7.2 Confidentiality . . . 88 8.7.3 Integrity . . . 88 8.7.4 Non-Repudiation . . . 89 8.7.5 Replay Protection . . . 89 8.8 Conclusion . . . 89 Bibliography . . . 91 9 Paper C: Security and Trust Preserving VM Migrations in Public Clouds 95 9.1 Introduction . . . 97

(18)

xiv Contents

9.2 Background . . . 98

9.2.1 VM Migration . . . 99

9.3 Related Work . . . 100

9.4 Attack Model and Security Requirements . . . 102

9.4.1 Attack Model . . . 102

9.4.2 Requirements Analysis . . . 103

9.5 Proposed Trusted VM Migration . . . 104

9.5.1 Platform Trust Certification . . . 105

9.5.2 VM Migration Protocol . . . 109

9.6 Requirements Review . . . 112

9.7 Conclusion and Future Work . . . 113

Bibliography . . . 115

10 Paper D: Protecting Private Data in the Cloud 119 10.1 Introduction . . . 121

10.2 Architecture . . . 122

10.2.1 Resources . . . 123

10.2.2 Software Probes . . . 123

10.2.3 Procurement . . . 124

10.2.4 Resource and Policy Description File . . . 124

10.2.5 VM Launch . . . 125

10.2.6 Probe Inlining . . . 126

10.3 Implementation . . . 127

10.3.1 Base System . . . 127

10.3.2 Launch Manager . . . 127

10.3.3 Binary Code Inliner . . . 128

10.4 Security Analysis . . . 129

10.4.1 Locking out the provider with TC . . . 129

10.4.2 Locking out the client . . . 131

10.5 Related Work and Contributions . . . 132

10.5.1 Related Work . . . 132

10.5.2 Contribution . . . 133

(19)

I

Thesis

(20)

(21)

Chapter 1

Introduction

Traditionally, enterprises and organizations procure physical hardware resources to set up their IT infrastructure. However, the availability of multi-core, high performance computing platforms together with the ad-vancements in virtualization technologies and high-speed data networks have created new possibilities of resource procurement usually known as

cloud services. Buying a cloud service can be a quicker, more dynamic

and cost effective way to run an IT service compared to using own hard-ware. Costs can also be saved due to less administration as well as energy savings. Well established cloud service categories are Software-as-a-Service (SaaS), Platform-Software-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) which are sometimes commonly called SPI service mod-els [1]1

. A cloud service is not only limited to SPI service models rather Anything-as-a-Sevice (XaaS) can be offered, for example, Storage-as-a-Service, Database-as-a-Storage-as-a-Service, Security-as-a-Storage-as-a-Service, etc. We focus on security and trust related aspects in an Infrastructure-as-a-Service (IaaS) service delivery model in which a cloud service provider (CSP ) uses plat-form virtualization by means of a hypervisor (e.g. XEN) to create and run multiple virtual instances called Virtual Machines (VMs) for many clients on a single physical machine. The use of virtualization and its ability to create multiple VMs of different specifications (attached mem-ory, storage and processing power etc.) on a single powerful physical machine allows maximum utilization of that machine by providing the service (a VM in IaaS case) to many cloud users simultaneously.

1

SPI models are described in Chapter. 2 (Section. 2.2.1)

(22)

4 Chapter 1. Introduction

Many possible cloud deployment models exist depending upon the nature and requirements of the cloud users. Well know examples are

Private, Public and Hybrid clouds. A private cloud is usually deployed

by the enterprise on premise and its services are provisioned to the users who belong to the same enterprise. On the other hand, in a public cloud model, an independent Cloud Service Provider (CSP) provisions services to any individual, organization or enterprise. The hybrid cloud model integrates both public and private cloud models. The main ad-vantage of using a public cloud over a private cloud is the ability for the cloud user to lease and release computing services dynamically and robustly on-demand without worrying about the up-front capital expen-diture (CAPEX).

Although using public cloud services can bring many business bene-fits, it also raises various security concerns for a security sensitive user. Allowing user VM to be hosted on any platform without verifying its integrity can expose user confidential data, e.g. if the platform is vul-nerable or malicious. Existing cloud models only rely on contractual assurances in Service Level Agreements (SLAs) without providing any technological mechanism for the cloud user to verify the integrity of the remote cloud platform to enable user trust in the offered service before using it. This lack of trust is one of the main reasons for not adopting public cloud services by many potential users [2].

1.1 Contributions

In this thesis we address some security issues and risks in cloud com-puting. In particular, we are considering public cloud services offered according to the IaaS model through virtualized computing resources. We identity the security threats in IaaS clouds that arise due to the dis-tributed nature of cloud infrastructure and undermine user trust. Our proposed solutions in form of protocols and service deployment models enable user trust in the cloud services. Our suggested solutions are built upon Trusted Computing mechanisms and utilize standard hardware security features offered by a Trusted Platform Module (TPM)2

. The feasibility of our new concept and protocols has been verified through a prototype implementation.

The main contributions of this thesis are the following.

2

(23)

1.1 Contributions 5

1. Security Requirements Analysis of IaaS Public Clouds We make threats analysis of virtual machine provisioning in IaaS clouds. Considering these threats, we define security requirements for trustworthy public IaaS clouds. The analyses provide us with insight on several unsolved security research issues as well as a foundation for our further research. The threats analysis results were published in ECIW’113

. 2. Secure VM launch

We propose mechanisms that allows the cloud user to remotely ver-ify the security properties of the offered cloud service platform of the provider. Our proposed solution addresses trust building mea-sures for the initial launch of the user VM on the provider infras-tructure. We also provide a prototype implementation of the pro-posed mechanisms. This work has been published in CLOSER’124 conference which covered various aspects of cloud computing in-cluding security.

3. Secure VM migrations

We present design principles and mechanisms to allow user VMs to migrate across cloud platforms according to user specified security policies on the host platform configurations. Our suggested proto-col enforces these policies on platform level preventing migration to untrusted/miss-configured host platforms. The proposed VM mi-gration solution complements and extends our earlier launch proto-col and makes the suggested trust model and protoproto-cols applicable to a large set of IaaS usage scenarios. The secure VM migration results was published in TrustCOM’125

.

The contributions mentioned above only present the security require-ments which are important for increasing user trust in the public clouds. The cloud community (e.g. Cloud Security Alliance [3]) is working to enumerate a complete set of cloud security requirements to cover the management, administrative, legal and technical aspects. The focus and scope of this thesis is limited to the transparent handling of the user VM in public IaaS clouds. We consider the VM life cycle and provide solutions for the initial phases of VM life cycle, such as VM launch and

3 http://academic-conferences.org/eciw/eciw2011/eciw11-home.htm 4 http://closer.scitevents.org/?y=2012 5 http://www.scim.brad.ac.uk/~hmibrahi/TrustCom2012/

(24)

6 Chapter 1. Introduction

migration. Our contributions provide first steps in designing trustworthy cloud services. However, there are many other security requirements in the later stages of VM life cycle (i.e. VM operation, VM management) that must be fulfilled to make the public cloud models trustworthy for both stakeholders, the user and provider. Some of the well known se-curity requirements include the protection of provider resources against malicious users (e.g. spammers), protection of user data against illegal retention by the provider, protection of one user VM from the other (i.e. strong isolation), etc. We assume that our contributions, as presented in this thesis, can remove the first barrier in convincing the potential cloud users to send their data in the public clouds.

1.2 Thesis Outline

The outline of the thesis is as follows. In Chapter 2 we present the background of the technologies used in this thesis which describes virtu-alization, cloud computing and trusted computing. Chapter 3 presents the security aspects of cloud computing, especially the need for trans-parent and trustworthy cloud services before giving an overview of our solutions in Chapter 4. In Chapter 5 we present conclusions and future work. We present technical overviews of the papers that we include in this thesis in Chapter 6. These papers are presented in Chapters 7 - 10.

(25)

Chapter 2

Background

In this chapter, we introduce the concepts which are fundamental for better understanding of the problems we focus on (see Chapter 3), and their solutions we propose in this thesis (see Chapter 4). We start with an introduction to virtualization which is the underlying technology to provide the dynamicity and flexibility to the cloud services. We present an abstract overview of the cloud computing, its stakeholders and com-mon cloud service delivery models. Finally, we provide an overview of Trusted Computing concepts (Section 2.3.1) which are fundamental in our proposed solutions.

2.1 Virtualization

Virtualization has been in use for many decades in different forms and at different layers. For example, it has been used to create sandbox en-vironments (at the application layer) and by the operating systems to share system resources (e.g. memory, CPU, etc) between different pro-cesses. With the advancement of hardware capabilities which provide powerful multi-core, high performance computing platforms, there is a potential to fully utilize these hardware capabilities. This has been ad-dressed recently by using the virtualization techniques such as system virtualization which allows multiple Virtual Machines (VMs) to run on a single physical platform. Each VM has a full software stack (including OS) and it runs in parallel to other VMs but each VM is like a physically separated real machine. The virtualization layer that runs and separates

(26)

8 Chapter 2. Background

different VMs is called a hypervisor. A hypervisor runs in the most priv-ileged mode in a system and has full control over vital system resources. There are different hypervisors implementations like XEN [4], KVM [5] and VMware [6] each allowing multiple user VMs.

The solutions we provide are independent of the hypervisor used for platform virtualization. However, we prefer using a thin hypervisor (i.e. small in footprint) so that its small code base could be verified easily and limits the areas of attack. This is usually achieved by directly running the hypervisor over the hardware without loading any operating system before hypervisor (unlike KVM which runs as a process in the Linux OS), and also by excluding management tasks from the hypervisor implementation. The hypervisors like VMware and XEN follow this architecture. Since the XEN hypervisor is open source and better suits our requirements, we use it in our prototype implementations. However, our solutions can be adapted easily for any other virtualization solution. A brief introduction of XEN hypervisor is given in the following section.

2.1.1 The XEN Hypervisor

The XEN hypervisor runs directly over computer hardware allowing it to run many instances of operating systems concurrently called Guest

Oper-ating Systems (GuestOSs). XEN is supported on a variety of platforms

like x86, Itanium, Power PC and ARM processors and can run vari-ous operating systems (Linux, Solaris, Windows, etc) simultanevari-ously as GuestOS [4]. A XEN-virtualized platform has the following three main components as shown in Figure. 2.1.

1. The XEN hypervisor which runs directly over the hardware and provides interface for all hardware accesses.

2. The Domain 0 referred to as Dom0 which is launched by the XEN hypervisor at the time of system startup. The Dom0 has privileged access to all system resources and is responsible for managing other user domains (e.g. start, stop, etc.)

3. The Domain User referred to as DomU operates independently on the system but is managed by Dom0. The DomU can run any supported operating system either unmodified leveraging vir-tualization hardware extensions (Intel VT, AMD-V) or by doing special modifications to the guest operating system to allow par-avitualization.

(27)

2.2 Cloud Computing 9     _{}                   _{}_{}









     

Figure 2.1: Architecture of a Virtualized Platform using XEN Hypervisor

2.2 Cloud Computing

A cloud is a pool of virtualized resources available over the Internet. Vir-tualization allows to configure the computing resources dynamically for the client which can then be leased following the pay-per-use payment model. Other than dynamicity and elasticity provided by virtualization, there are many other characteristics of the cloud computing which are defined in various definitions available today. One of the most compre-hensive definitions is provided by The National Institute of Standards and Technology (NIST) [1] which states that:

“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable com-puting resources (e.g., networks, servers, storage, applica-tions, and services) that can be rapidly provisioned and re-leased with minimal management effort or service provider interaction.”

(28)

Benefit Description

Flexibility The underlying virtualization technologies allow cloud users to request for the exact amount of re-quired resources (e.g. a VM with quad-core pro-cessing and 8GB memory etc.)

Scalability The service can be leased/released dynamically on demand

No upfront invest-ment (CAPEX)

The cloud service can be leased dynamically which means that CAPEX costs to start/expand the business can be reduced a lot

Less operating costs (OPEX)

The physical cloud platforms which are used for the provisioned service are managed by the CSP which saves many operational expenses for the cloud user business

Ubiquitous access The cloud services are usually web bases which allows them to be accessed from variety of devices e.g. laptops, mobile devices, etc.

Table 2.1: Benefits of using cloud based services

The characteristics like elasticity, rapid provisioning, minimal man-agement effort, etc. promise many business benefits which are instru-mental in the recent surge towards the demand for using cloud services (see Section. 2.2.1). On the other hand, there are still many unresolved security issues (See Chapter. 3) which must be addressed before a large majority of security sensitive users can consider using the cloud services to get various benefits listed in Table 2.1.

2.2.1 Service Models

The cloud computing aims at providing different IT services (e.g. stor-age, database, applications, VM, etc.) over the Internet so that the user does not worry about establishing and managing the underlying infras-tructure. Numerous types of such cloud services have emerged in the recent years. In the following sections, we present a brief summary of the well known categories usually referred to as SPI service models [1] followed by a more detailed use case of the IaaS model that we consider in this thesis.

(29)

2.2 Cloud Computing 11

Software-as-a-Service: Software-as-a-Service cloud model refers to the provisioning of any useful application/software over the Internet. There are many SaaS offerings to date, e.g. Google provides office suite in the form of Google Docs [7]. Similarly, SAP provides many busi-ness process applications in their cloud solutions [8]. Other SaaS cloud providers are Rackspace [9], Salesforce [10] etc.

Platform-as-a-Service: Platform-as-a-Service cloud model refers to the provisioning of provider managed platforms which provide devel-opment frameworks for the cloud users. The operating system and the required development environment is setup and managed by the cloud provider. The cloud user builds up his/her applications using such platforms. Examples of PaaS providers include Microsoft Windows Azure [11], Google App Engine [12] and Force.com [10].

Infrastructure-as-a-Service: Infrastructure-as-a-Service cloud model refers to the provisioning of the computing resources (e.g. CPU, memory, storage, etc.) that are used to create a user Virtual Machine (VM) which belongs to the cloud user and runs just like a physical machine. In an IaaS model, the cloud user takes the responsibility of managing his/her VM by installing the desired operating system and other softwares. Some examples of IaaS providers are Amazon EC2 [13], GoGrid [14] and Flex-iScale [15].

Our Use Case: In this thesis, we consider a use case in which the

Cloud Service Provider (CSP) sells its computing resources, self-owned or leased from a third party called an infrastructure provider, to the users (or clients) according to an IaaS model (see Figure. 2.2). There are usually two or sometimes three main entities with respect to their roles as defined in Table 2.2. However, many other business models also exist which can have even more entities (e.g. Amazon Simple Storage Service (Amazon S31

) offers cloud storage in large quantities called buckets which are used by other storage service providers like Dropbox2

to offer services to the end-users).

In the IaaS model, the provider uses virtualization to allocate plat-form resources (e.g. CPU, memory, etc.) to the user according to his/her

1

http://aws.amazon.com/s3/

2

(30)

12 Chapter 2. Background                              

Figure 2.2: Infrastructure-as-a-Service (IaaS) Cloud Model

needs. Using these resources, the user can create an instance of his/her virtual machine. The use of virtualization allows multiple users to run their VMs on a single physical platform. According to the existing cloud infrastructures, the process of creating user VM involves three main steps. These include 1) the service request which is done by visiting the provider portal/website, 2) the service select i.e. selecting the re-quired configuration (number of rere-quired CPU cores, rere-quired memory and storage etc.), and 3) the service start which creates and starts the user VM in the provider network. There are also other intermediate steps like payment, VM image transfer/selection etc. In this thesis, we analyze this process with respect to security and focus on the the lim-itation that the user is forced to trust the cloud provider that his/her VM will only be hosted on secure platforms during its life time. We address this limitation and extend the existing process of VM life cycle management by embedding digital trust (see Section. 2.3) into it which promises better security guarantees for the user.

2.2.2 Deployment Models

Different motivations to use/provide cloud services result in different cloud deployment models. For example, an organization may be inter-ested in setting up a local cloud called Private Cloud, for better resource utilization, and hence deliver IT services (XaaS) to various departments

(31)

2.2 Cloud Computing 13

Entity Role Example

Infrastructure Provider

Manage physical cloud plat-forms

Datacenters Cloud

Ser-vice Provider (CSP)

Rent resources from one or many infrastructure providers to render IT services (SaaS,

P aaS, IaaS) to the end user

Amazon Inc., Google Inc., Microsoft Cor-poration

Cloud User or Client

lease or release IT services dy-namically on-demand from a CSP for own business opera-tions

An individual or a business like web hosting company etc.

Table 2.2: Stakeholders in a typical cloud model

(e.g. human resource, finance, etc.). On the other hand, a new/small company might not want to invest heavily on procuring computing re-sources for its required IT services, rather prefer to lease the required IT services from a third party cloud provider called a Public Cloud provider. Both models have their pros and cons which makes room for a Hybrid

Cloud which tries to maximize the benefits of both models and explore

possibilities to minimize the disadvantages of either model (public and private). However, selecting the right balance in utilizing a private or public resource remains an administrative and management challenge in hybrid clouds. We consider the security perspective of the public clouds which promise most business benefits but need better security solutions to fulfill the requirements of many security sensitive users.

Public Clouds - The Security Perspective

The emergence of cloud computing has brought many benefits for both, the user and provider of the service. A large majority of normal IT users (e.g. home users) is already using one or more public cloud services at very less cost3

(e.g. storage, email, etc.). However, many organizations and businesses despite recognizing many business benefits promised by the public clouds, hesitate in using public cloud services due to their se-curity concerns. Some companies tend to setup their own private cloud for better internal resource utilization, and also to make their

exist-3

(32)

ing infrastructures cloud-compatible for any possible future migration to the public clouds. However, large scale migration to public clouds by such organizations can only be made possible after the public clouds are equipped with the required security mechanisms. The goal of this re-search is to make public clouds secure enough such that they meet the security requirements of both, the normal and security sensitive users.

2.3 Introducing Digital Trust

Trust4

plays an important role in a stable and long lasting business re-lationship. In the information technology field, the definition of trust is not only limited to social aspects which strengthen it, for example, one-to-one relationship, the past experiences of both parties etc. Instead, the client using a service remotely also needs mechanisms for security assess-ment of the underlying infrastructure. These mechanisms can be imple-mented using the technological advances and hence pave way for enabling

digital trust. The initiative to realize this digital trust was taken in 1999

by a consortium called Trusted Computing Platform Alliance (TCPA). The TCPA consortium, initially having five members5

, is succeeded by Trusted Computing Group (TCG) which has over 190 members to date. The distributed architecture of cloud computing, which is also a reason for lack of user trust in the cloud services, makes good use case and potential area for trusted computing to strengthen user trust.

2.3.1 The Trusted Computing Group (TCG)

The Trusted Computing Group (TCG) is a non-profit, industry-standards organization6

with the mission of proposing specifications and technol-ogy for trusted computing platforms. A trusted computing platform is embedded with a tamper-resistant security chip called the Trusted Plat-form Module (TPM) which implements the most important TCG spec-ification [16]. The TCG proposed mechanisms can be used for:

• the security of information assets by using securely stored crypto-graphic keys in the TPM’s ’Protected Storage’.

4

firm belief in the reliability, truth, or ability of someone or something (Oxford

Dictionary)

5

Compaq, HP, IBM, Intel, Microsoft

6

(33)

2.3 Introducing Digital Trust 15

• securely storing the current platform state in TPM’s Platform Configuration Registers (PCR). The platform state can later be reported to a remote client for the platform integrity verification through a process called Remote Attestation.

2.3.2 Trusted Platform Module (TPM)

The TCG defined Trusted Platform Module specifications can be imple-mented in hardware or software but hardware based TPM is considered more secure. The TPM is a fundamental security building block in the TCG architecture and therefore its components must function as in-tended. This can be ensured by following good engineering practices, manufacturing process and industry reviews. The main components of a TPM are shown in Figure 2.3.

                        

Figure 2.3: TPM Component Architecture

2.3.3 TPM - Key Management

The TCG proposed security and trust enhancing mechanisms are based upon various protocols and principles supported by TPM. One of the main capabilities of the TPM is to provide data protection using various types of TPM keys. TPM supports secure ways for its key management which includes the following:

(34)

be created using TPM_CreateWrapKey command [17] which uses random number generator in the TPM.

Key Storage: Some root keys are stored in the TPM non-volatile

stor-age (NV-storstor-age) but that storstor-age is not sufficient for all TPM keys; therefore other keys are usually stored out of TPM in a Key Cache after in-chip encryption called key wrapping with one of the TPM-resident root key (e.g. Storage Root Key)

Key Usage: A TPM key can only be used if it is already loaded in

the TPM. In order to use a wrapped key (which is stored out of the TPM), it is first decrypted with its root key and then loaded for the required cryptographic operation.

A TPM supports many cryptographic operations such as encryp-tion/decryption, signing, reporting platform state, etc. As a basic secu-rity principle, different types of keys are used for different purposes for which the TCG classifies TPM keys into following 7 categories. These keys make a key hierarchy as shown in Figure 2.4.

            _{} 

(35)

1. Endorsement Key (EK): Every TPM has a unique asymmetric key pair called Endorsement Key (EK). The EK is a non-migratable key, that is, its private part never leaves the TPM. The EK is usually gen-erated by the TPM manufacturer and should ideally be supplemented with a certificate called Endorsement Credential that is stored in the TPM NV-storage. The EK is never used for encryption/decryption or signing purposes rather its use is limited to only two tasks. First, to get the platform ownership which is a process of generating a Storage Root Key (SRK) and is only possible with owner’s physical presence. Second, the EK is used in the protocol for platform identity registration with the Privacy-CA (PCA) who certifies the Attestation Identity Keys (AIK) discussed below.

2. Storage Keys: These are asymmetric keys used for storing other keys or data securely external to TPM. The ’Storage Root Key (SRK)’ is an important non-migratable storage key which is the root of all TPM protected keys, that is, every TPM key is wrapped (encrypted) with the SRK before it is stored out of TPM. As stated earlier, SRK is generated when the TPM ownership is taken.

3. Signing Keys: These are asymmetric keys which can only be used for signing application data or messages.

4. Binding Keys: The bind keys are used to encrypt (or bind) small amount of data (e.g. a symmetric key) on one platform and decrypt (or unbind) it on a remote platform.

5. Identity Keys: These are non-migratable keys and are also called At-testation Identity keys (AIK). These are exclusively used for signing TPM data like PCR register values. An AIK signed message also ac-companies an AIK certificate which is issued by a mutually trusted CA and certifies that the AIK is a non-migratable TPM key.

6. Authentication Keys: These are symmetric keys which are used to secure communication channel with TPM.

7. Legacy Keys: These are legacy system keys which are created out of TPM and then imported in the TPM for signing or encryption opera-tions.

2.3.4 TPM Message Protection

In this section, we first introduce the TPM supported operations for message protection and later give a brief introduction of technique we used in our solutions for intended purpose. The TCG classifies TPM protected messages in to the following four categories [18]:

(36)

1. Binding/Unbinding: The TCG notion of binding actually refers to the encryption of a message using a public key whose corresponding private key is stored in the recipient’s TPM (usually in key cache). The platform with TPM unbinds (decrypts) the received message using TPM_UnBind command after loading the private key in the TPM. It is noteworthy here that the TPM does not have any command to do bind-ing which means that encryption is always performed out of TPM. The binding opertion is either performed by using the TCG Service Provider Interface (TSPI) which is a part of TCG Software Stack (TSS) or by any other available cryptographic library (e.g. JavaTM Cryptographic Extension7

, OpenSSL8

, etc.).

2. Signing: Signing is also a traditional cryptographic operation to en-sure the integrity and authenticity of the message. The TPM supports TPM_Signcommand that uses a signing key to return the required digital signature. The receipient of the message can use standard signature ver-ification process to verify the authenticity and integrity of the received message.

3. Sealing/Unsealing: Sealing is similar to binding in terms of encryp-tion but it also includes platform configuraencryp-tion which must be satisfied to be able to unseal the message. Since sealing is a TPM operation therefore for performance reasons usually small data like a symmetric key is sealed/unsealed. Hence, in order to seal large amount of data it is first encrypted using a symmetric key which is then sealed (en-crypted) using a non-migratable asymmetric key by also providing the platform configuration (PCR values). The platform can only unseal (decrypt) the message if it has the corresponding private key and also the platform configuration matches the values specified in the message sealing. Two important points must be remembered while using the seal/unseal operation. First, in the seal operation any platform config-uration can be specified, current or future, which is must for unsealing the data successfully; this implies that the platform is not required to be in the trusted state when sealing is done. However, the TPM_Seal command also includes the current platform state which is returned by TPM_UnSeal command and may, or may not, be of the user’s interest.

Second, the seal and unseal operations must be performed on the same

platform. This limitation restricts remote users to seal their data to the destination platform. 7 www.docs.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide. html 8 http://www.openssl.org/docs/crypto/rsa.html

(37)

4. Sealed-Signing: The sealed-signing combines the effects of both op-erations by including the PCR values in computing the digest to sign. This feature can be used to inspect the sender’s platform configuration at the time of message signing.

2.3.5 Sealing Data Remotely

As highlighted earlier, the seal and unseal operations must be performed on the same platform which means that a remote party cannot benefit from the protections provided by the seal operation. However, in dis-tributed systems such as clouds where the remote user owns the resource (a VM) which is managed by another entity, it can be very useful to seal user data remotely to the correct platform in trusted state. This re-quirement also applies to a cloud user who wants his/her VM to run only on known, trusted cloud platforms. We achieve the properties of seal operation in our solutions described in Chapter 4 by using a TPM key (we call it, bind key) which is locked to PCRs. We create this key with TPM_CreateWrapKey command which allows to specify the required platform state (represented by PCRs) to use that key. The public part of this key is then sent to the cloud user who can use the public bind key to encrypt the VM (by encrypting the symmetric key used to encrypt the user VM). Since the private bind key is only available to the intended platform in correct configuration, the user VM is considered sealed to that platform.

(38)

(39)

Chapter 3

Security Critical Areas in

Cloud Computing

There are many security critical areas in the cloud environments ranging from technical aspects (e.g. identity and access management, virtualiza-tion etc.) to the non-technical aspects (e.g. governance, compliance, au-dit). These security aspects are throughly discussed by Cloud Security Alliance (CSA)1

in a comprehensive security guidance document [19]. A high priority list is compiled in another complementary document by CSA called the top threats to cloud security [20]. While CSA research covers all cloud environments, a more specific survey for IaaS cloud se-curity is done by Vaquero et al. in [21], which analyzes various existing solutions with respect to the threats identified by CSA.

The existing body of research on cloud security, including the afore-mentioned research, identifies many cloud security risks. However, the focus of this thesis is to make cloud services trustworthy for which

trans-parency and security assessment are vital. These requirements are

specif-ically mentioned by Security-as-a-Service working group2

in their report which defines various categories of Security-as-a-Service (SecaaS) [22]. The purpose of identifying SecaaS categories is to allow cloud users to evaluate the cloud service security to better decide whether the in place security mechanisms meet user needs or not. The SecaaS defined

cat-1

https://cloudsecurityalliance.org/

2

https://cloudsecurityalliance.org/research/secaas/

(40)

22 Chapter 3. Security Critical Areas in Cloud Computing

egories provide good basis to evaluate the security of a SaaS, PaaS or Iaas cloud delivery model. Since we are focusing on an IaaS model, the IaaS only categories are highlighted (shown bold-faced) in Table.3.1. All five IaaS categories are considered in our solutions where ever they are applicable (e.g. using gateways, VM encryption, etc.). However, our research focus and provided solutions are closely related to the Security

Assessment (category#5), which is elaborated in the following section.

Category Core Functionalities (listed for IaaS only)

1: Identity and Access Manage-ment

Not applicable to IaaS (SaaS, PaaS only)

2: Data Loss Prevention Not applicable to IaaS (SaaS, PaaS only)

3: Web Security Not applicable to IaaS (Saas, PaaS only)

4: Email Security Not applicable to IaaS (SaaS only)

5: Security Assessments Analyzing platform integrity, vulnera-bility testing and security/risk rating

6: Intrusion Management Providing physical security, Data traf-fic inspection

7: Security Information and Event Management (SIEM)

Not applicable to IaaS (SaaS, PaaS only)

8: Encryption Data protection at rest and in motion

9: Business Continuity and Disaster Recovery

Data and infrastructure replication, ge-ographically distributed infrastructure

10: Network Security Authentication and Access controls, DoS protection, security gateways

Table 3.1: CSA Defined Categories for Security-as-a-Service

3.1 Security Assessment of the Host

Plat-form

The core functionalities for the security assessment of the host plat-form include analyzing platplat-form integrity, perplat-forming vulnerability test-ing and providtest-ing security and risk rattest-ing to the platforms. The security

(41)

3.2 Conclusion 23

assessment is generally considered to be done by third-party audits. Al-lowing a cloud user to do the security assessment of the cloud platform prior to the use of service, can help reinstate user trust in the offered cloud service. Our solutions provide such mechanisms to the cloud user. The security of the host platform can be assessed by considering two as-pects - 1) the Physical Security and 2) Platform Integrity. These asas-pects are discussed in the following sections.

3.1.1 Physical Security

The physical security comes under the intrusion management category (see Table.3.1) which is the responsibility of the CSP (or infrastructure provider) who manages the datacenters. The existing methods for physi-cal intrusion detection, prevention and response are mature and reliable. These include hiring professional security staff, utilizing video surveil-lance, biometrics etc. The authorized staff is usually required to pass two-factor authentication to access datacenter floors and all their ac-cesses are logged and audited [23]. All these security mechanisms make it very difficult for an attacker to perform any physical attack (e.g. cold boot) on the the cloud platforms.

3.1.2 Platform Integrity

Securing host platforms against physical attacks is possible but still the overall platform security depends upon its integrity which is measured from its software configuration. The platform’s software configuration is represented by the software stack which is the list of every loaded software component in the platform bootstrapping. The knowledge of loaded software components in a platform is important for its vulnera-bility analysis, integrity verification and assigning it any security or risk rating. These tasks can be performed remotely by leveraging trusted computing which features secure boot for securely recording boot pro-cess, and supports secure protocols for remote integrity verification called

remote attestation.

3.2 Conclusion

As stated earlier, the physical security of the host platform can easily be ensured. However, for overall platform security we must ensure the

(42)

24 Chapter 3. Security Critical Areas in Cloud Computing

integrity of the platform which is managed by the platform

administra-tors. The role of platform administrators is to keep the platform secure

and available for the required services for which may update platform configuration without needing any physical access. While providing ad-min rights to the management personnel is indispensable, a malicious employee can misuse his/her access rights to change the platform config-uration which could expose the platform to various vulnerabilities. Due to such possibilities, a remote platform user always has fears of breach of his/her confidential data. However, if users are allowed to assess the platform configuration themselves or by a trusted third party on their behalf, the user trust can be revived. We discuss such potential threats and mechanisms to mitigate them in our solutions provided in Chap-ters 7-10.

(43)

Chapter 4

Our Solutions for Secure

and Trustworthy Cloud

Services

In this chapter we discuss our followed research method in Section 4.1 followed by our solutions that promise to secure the cloud services with particular focus on making the cloud services transparent and trust-worthy. This chapter only summarizes the main contributions leaving further details for the second part of this document which elaborates our contributions in Chapter 7, 8, 9 and 10. Before presenting our solutions, first we describe the research method followed in this work.

4.1 Research Method

We adopted Constructive Research method [24] where the key idea is the construction, which is based on the existing knowledge used in novel ways, with possibly adding a few missing links. This means that the constructive research is a hybrid of traditional scientific research with respect to learning existing systems, and follows engineering research in creating new artifacts. Following the constructive research hybrid scheme, we used scientific research methods to study the current state-of-the-art, whereas the engineering research methods were used to produce

(44)

26 Chapter 4. Our Solutions for Secure Cloud Services

new results (i.e. models and protocols) based on the existing knowledge base.

Our research goal, i.e. to enable user trust in the remote virtualized

platforms (e.g. cloud), is derived and motivated by the industrial

de-mand of investigating new service delivery models to get the potential benefits from new technological advances. Keeping the research goal in mind, we started with collecting the relevant knowledge by reading the specifications, white papers, tutorials etc. The next step was to study the current state-of-the-art and explore research problems in our research domain. This was done by following the scientific research methods of literature review which included peer reviewed academic and research publications indexed by publishers like IEEE1

, Springer2 , ACM3

, etc. The initial outcome, i.e. our peer reviewed security requirements publication (See Chapter. 7), gave us an insight to the initial set of problems for further research.

The problems identified in the initial review were further explored with the objective of providing their solutions which are our main re-search contributions. We iteratively applied scientific rere-search methods to investigate each problem, which allowed us to refine and focus on a particular research problem (e.g. VM launch, VM migration). The en-gineering research methods were used to provide the solutions for each identified problem, with the objective of using existing mechanisms and providing novel extensions where required. As an outcome of the fol-lowed engineering process, we provided new models, protocols and a prototype that extends existing body of research. We analyzed our so-lutions using logical argumentation and reasoning approach to discuss their security effectiveness. This is done by providing the security anal-ysis of the proposed solutions. Our solutions presented in this thesis contribute towards the research goal of enabling user trust in the public clouds. 1 http://www.ieee.org/index.html 2 http://www.springer.com/ 3 http://www.acm.org/

(45)

4.2 Security Analysis for Virtual Platform Provisioning 27

4.2 Security Analysis for Virtual Platform

Provisioning

We consider the generic model of provisioning virtual resources to the users with the aim of analyzing and suggesting security requirements of the users.In our security analysis we assume an enterprise/organization (e.g. a telecommunication operator) to be the user of virtual resources who has very high security expectations from the service provider. On the other hand, the provider of the virtual resources can also have fears about misusing of their provisioned resources. The focus of our secu-rity analysis is to identify threats and list various secusecu-rity requirements from both stakeholders’ perspective. We give a brief overview of our per-formed security analysis whereas the details can be found in Chapter 7.

4.2.1 Threats

In a virtual resource provisioning model both entities are vulnerable to various threats from the other party. We list major threats which are analyzed to define the security requirements of both stakeholders:

• The attacker4

installs malicious code on the physical host or in the user VM

• The host platform is badly configured by the provider which makes it vulnerable to various known attacks

• The provider accesses confidential run-time or configuration data from the user VM

• The user (i.e. owner of the VM) repudiates VM launch process • The user attacks other user VMs running in parallel to affect their

functionality

• The user tries to get confidential data from other user VMs • The attacker impersonates a legitimate provider or user

4

(46)

4.2.2 Security Requirements

The major security requirements derived from the analyzed threats are listed below which are described in detail in Chapter 7.

• All communication between the user client and the entities in the provider network (provider management machines, user VM, etc.) must be secured after mutual authentication.

• The user must have mechanisms (e.g. secure protocols) to remotely verify the authenticity and integrity of the physical platform pro-visioned to host the user VM.

• The hypervisor which provides the isolation between different user VMs must be small to minimize vulnerabilities and to realize pos-sibilities of certifying it.

• The user VM must be allowed to migrate to other physical plat-forms without compromising the security of the running VM.

4.2.3 Summary

We considered various threats and requirements which included many conventional security requirements tailored for our specific use case. We also identified security areas which need proper mechanisms and solu-tions to strengthen trust in the remotely provisioned virtualized services. While the conventional security requirements could be addressed by ex-isting standard security mechanisms, the security requirements for trust enhancing seem to be more challenging and interesting. The results from our security analysis provide open research questions for further research as described in the following sections.

4.3 Secure Virtual Machine Launch and

Man-agement Mechanism

In the virtual resource provisioning which corresponds to Infrastructure-as-a-Service cloud provisioning model, the first VM life cycle step is the secure launching of user VM in the provider network. The threats identified in Section 4.2.1 and the the security requirements analyzed in Section 4.2.2 demand for a secure VM launch mechanism which could

(47)

4.3 Secure Virtual Machine Launch and Management

Mechanism 29

also allow the user to validate the security guarantees promised by the provider. The possibility to validate the contractual guarantees during the VM launch process increases user trust in using the service. We propose and implements such mechanisms in a protocol that leverages Trusted Computing techniques to fulfill user requirements. The proposed VM launch protocol is briefly described in the following section while the details can be found in Chapter 8.

4.3.1 VM launch

The design principles of the launch protocol rely on Trusted Comput-ing mechanisms like secure boot,sealComput-ing and remote attestation; there-fore, the host platform is first configured (see Section 8.4) to use these TPM operations. The actual launch protocol has three main phases. In the first phase, the user client establishes a secure channel with the provider network and gets various details of the destination platform like its integrity state, user access policy, licensing information, Service Level Agreements (SLAs), etc. The security profile of the platform which is dependent upon its integrity state is validated by the user client in the second phase of the protocol using remote attestation techniques. Fi-nally, in the third stage, the user client encrypts the VM image with a TPM key which is only available a) on the same validated platform, b) in the same attested state. The sealing of user VM to the attested plat-form ensures that the VM launch cannot be diverted to a compromised or malicious platform.

4.3.2 VM Management

Once the VM is securely launched, the user needs to communicate with its VM whereas the provider needs a console to manage the platform. The user client-VM communication can be done using any existing re-mote platform management tool (e.g. SSH). On the other hand, the provider management tasks are directed towards the management VM (in Dom0) for operations such as enabling or disabling resource usage metering, modifying licensing policy, etc. These provider management operations are further described in Chapter 10.

(48)

4.3.3 Implementation

We implement the VM launch protocol and also the tools for managing that VM after the launch. The launch protocol is focused on provid-ing security guarantees to the user that the host platform is trustwor-thy. On the other hand, the management tools allow the provider with mechanisms to transparently enforce usage/licensing policies on the user VM. However, the mechanisms for policy enforcement, such as inserting software probes, is not part of this thesis contributions. The running prototype of the VM launch and management mechanisms implements entities like Privacy CA for platform identity registration and

Procure-ment Server for resource allocation for VM launch. We provide a brief

overview of the following two main entities.

1. User/Provider Client: The client console runs in either of launch or management mode. Typically, the launch mode is only used by the user for initiating his/her VM launch request. The user client in launch mode runs procurement, attestation and actual VM launch steps to securely launch his/her VM on the procured platform. The client console in management mode allows cloud user to perform VM operations like pause, resume, shutdown, etc. while allowing the provider to enforce usage or licensing policies. The allowed op-erations for the clients are determined at the host platform by the

Policy Manager (See Section. 8.4.1) according to the connecting

client’s role (i.e. user or provider) as specified in his/her certificate.

2. Host Platform: The host platform (e.g the cloud platform in an IaaS cloud provisioning) runs the TCG Software Stack (TSS) which is used by our Management Agent to perform TPM oper-ations needed in the launch protocol. The management agent is implemented and deployed at application layer in the Management

VM (i.e. dom0). The management agent handles

communica-tion with the clients and runs launch and management protocols using functionalities exposed by four components, namely

Com-partment Manager, Integrity Manager, Credentials Manager and Policy Manager. The details and working of these components are

(49)

4.4 Secure Virtual Machine Migration Mechanism 31

4.4 Secure Virtual Machine Migration

Mech-anism

VM migration is an important VM management operation performed by the provider in various circumstances. However, the secure VM launch solution referred in Section 4.3.1, proposes sealing of the user VM to a specific platform. As a consequence, the user VM cannot be migrated even on legitimate cloud platforms. The main objective of secure VM mi-gration solution is to allow the provider to legitimately migrate user VM to other platforms without compromising on the security requirements laid down for our previous solutions. Hence, we propose a VM migration solution which is secure, flexible, transparent and scalable. The details of our proposed migration mechanism are presented in Chapter 9. We provide a brief summary of the solution in the following sections.

4.4.1 Concepts

PTAA

In our VM migration solution we introduce an independent and trusted entity called Platform Trust Assurance Authority (PTAA). The PTAA is assumed to be a team/organization of computer security experts who perform security analysis (e.g. penetration testing, vulnerability analy-sis, etc.) of different software components (e.g. an OS and its versions, applications) and define their security impact on the overall system. Us-ing the ratUs-ing of each component in a system, the overall ratUs-ing for the system is defined which is represented by a metric called Trust Assurance

Level (TAL) which can be a numeric (e.g 1,2,3) or verbal(e.g. least, low,

average, normal, high) value.

Trust_Token

The TAL-value assigned to a platform configuration must be communi-cated to the platform verifier with an assurance that the platform con-figuration has not been changed after getting a higher Trust Assurance Level. We achieve this by introducing a Trust_Token which ties the

TAL-value with a TPM based, non-migratable, asymmetric key pair

(50)

in the evaluated configuration (see next section). The Trust_Token also contains platform ID and the time when it is generated as shown below.

T T = SignP T AA[T TI D, P LAT F ORMI D, T AL− val, P KBI N D, T]

4.4.2 Platform Certification (Phase-I)

The platform certification phase is separated from actual VM migration phase for performance and scalability reasons. The platform certification is performed by the provider immediately after she sets up the platform for provisioning. However, the certification process can be done any later time as well, for example, after platform up gradation to achieve higher Trust Assurance Level. The outcome of the certification process is a Trust_Tokenthat is received by the platform. The Trust_Token can later be used in actual VM migration phase (see Section 4.4.3) without any need to involve the trusted third party, that is, PTAA.

4.4.3 VM Migration (Phase-II)

The significance of our migration scheme is the usage of security and trust assuring bind key which is shared between the source and des-tination platforms by sharing each others Trust_Tokens. Other than sharing encryption keys, the Trust_Tokens also provides the TAL-value of the destination platform which rates the trustworthiness of the plat-form. The user VM can only be migrated to the destination platform if it satisfies a minimum threshold of the TAL-value specified by the user in its VM migration policy. If the destination platform is found

“trust-worthy”, the VM is sent to the destination after encrypting it with the

bind key. The bind key properties ensure that the VM can be decrypted at the destination platform if and only if it has the same configuration for which it was assigned the TAL-value. Finally, after successful VM migration the user gets a notification who can then optionally audit the integrity of new VM destination (e.g. by sending a bind key encrypted challenge to the platform)

Secure Service Provisioning in a Public Cloud

SECURE SERVICE PROVISIONING IN A PUBLIC CLOUD

Mudassar Aslam

2012

SECURE SERVICE PROVISIONING IN A PUBLIC CLOUD

Mudassar Aslam

2012

Populärvetenskaplig

sammanfattning

Abstract

Acknowledgments

List of Publications

Papers Included in the Licentiate Thesis

SICS Technical Reports

List of Acronyms

Contents

I

Thesis

1

II

Included Papers

49

I

Thesis

Chapter 1

Introduction

1.1

Contributions

1.2

Thesis Outline

Chapter 2

Background

2.1

Virtualization

2.1.1

The XEN Hypervisor









2.2

Cloud Computing

2.2.1

Service Models

2.2.2

Deployment Models

2.3

Introducing Digital Trust

2.3.1

The Trusted Computing Group (TCG)

2.3.2

Trusted Platform Module (TPM)

2.3.3

TPM - Key Management

2.3.4

TPM Message Protection

2.3.5

Sealing Data Remotely

Chapter 3

Security Critical Areas in

Cloud Computing

3.1

Security Assessment of the Host

Plat-form

3.1.1

Physical Security

3.1.2

Platform Integrity

3.2

Conclusion

Chapter 4

Our Solutions for Secure

and Trustworthy Cloud

Services

4.1

Research Method

4.2

Security Analysis for Virtual Platform

Provisioning

4.2.1