Institutionen för datavetenskap780110/FULLTEXT01.pdf · Institutionen för datavetenskap...

Institutionen för datavetenskap Department of Computer and Information Science

Final thesis

Protection of Non-Volatile Data in IaaS-environments

by

Erik Sundqvist

LIU-IDA/LITH-EX-A--14/062--SE

2014-11-18

Linköpings universitet

SE-581 83 Linköping, Sweden Linköpings universitet

581 83 Linköping

Linköping University Department of Computer and Information Science

Final Thesis

Protection of Non-Volatile Data in IaaS-environments

by

Erik Sundqvist

LIU-IDA/LITH-EX-A--14/062--SE

2014-11-18

Supervisor: Marcus Bendtsen Examiner: Prof. Nahid Shahmehri

Abstract

Infrastructure-as-a-Service (IaaS) cloud solutions continue to experience growth, butmany enterprises and organizations are of the opinion that cloud adoption has decreasedsecurity in several aspects. This thesis addresses protection of IaaS-environment non-volatile data. A risk analysis is conducted, using the CORAS method, to identifyand evaluate risks, and to propose treatments to those risks considered non-acceptable.The complex and distributed nature of an IaaS deployment is investigated to identifydi↵erent approaches to data protection using encryption in combination with TrustedComputing principles. Additionally, the outcome of the risk analysis is used to decidethe advantages and/or drawbacks of the di↵erent approaches; encryption on the storagehost, on the compute host or inside the virtual machine. As a result of this thesis,encryption on the compute host is decided to be most beneficial due to minimal needsfor trust, minimal data exposure and key management aspects. At the same time,a high grade of automation can be obtained, retaining usability for cloud consumerswithout any specific security knowledge. A revisited risk analysis shows that both non-acceptable and acceptable risks are mitigated and partly eliminated, but leaves virtualmachine security as an important topic for further research. Along with the risk analysisand treatment proposal, this thesis provides a proof-of-concept implementation usingencryption and Trusted Computing on the compute host to protect block storage datain an OpenStack environment. The implementation directly follows the Domain-BasedStorage Protection (DBSP) protocol, invented by Ericsson Research and SICS, for keymanagement and attestation of involved hosts.

Acknowledgements

This thesis was carried out at the security division of Ericsson Research and at theSwedish Institute of Computer Science (SICS), as a part of a joint project aiming tosecure the use of Infrastructure-as-a-Service deployments of cloud computing. I wouldspecially like to thank Fredric Morenius (Ericsson Research) for his input, advices, au-dits of this thesis report and help throughout the thesis process. I would also like tothank Nicolae Paladi (SICS) for his extraordinary support with the test-bed, deploymentand troubleshooting, and Ph.D. Antonis Michalas (SICS) for his support and overallhelp throughout the work with this thesis. I would also like to thank Professor NahidShahmehri at The Institute of Technology at Linkoping University, for her advices andsuggestions, and Marcus Bendtsen for his help and guidance regarding the methodologyand structure of this thesis report. Thanks to Andras Mehes (Ericsson Research) andMudassar Aslam (SICS) for their understanding and explanations of TPM aspects ofTrusted Computing.

i

Contents

1 Introduction 11.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Limitations and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 62.1 Cloud Computing Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Service Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Deployment Models . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Non-volatile Data in IaaS-environments . . . . . . . . . . . . . . . . . . 92.2.1 Logical Volume Management . . . . . . . . . . . . . . . . . . . . 102.2.2 Storage Security Concerns . . . . . . . . . . . . . . . . . . . . . . 10

2.3 The OpenStack Cloud Platform . . . . . . . . . . . . . . . . . . . . . . . 122.3.1 Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Trusted Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.1 Trusted Platform Module . . . . . . . . . . . . . . . . . . . . . . 14

2.5 IaaS Storage Security in Research and Industry . . . . . . . . . . . . . . 152.6 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.1 Domain-Based Storage Protection . . . . . . . . . . . . . . . . . 17

3 Methodology 183.1 The CORAS Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Structured Brainstorming . . . . . . . . . . . . . . . . . . . . . . 21

4 Risk Analysis of Non-volatile Data in IaaS-environments 224.1 Context Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.1 Step 1 - Preparations and Initial Observations . . . . . . . . . . 234.1.2 Step 2 - Scope of Analysis . . . . . . . . . . . . . . . . . . . . . . 244.1.3 Step 3 - Defining Target of Analysis . . . . . . . . . . . . . . . . 254.1.4 Step 4 - Target Approval . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.1 Step 5 - Risk Identification and IaaS Security Concerns . . . . . 314.2.2 Step 6 - Risk Level Estimation . . . . . . . . . . . . . . . . . . . 354.2.3 Step 7 - Risk Evaluation . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Risk Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.1 Step 8 - Risk Treating Concepts . . . . . . . . . . . . . . . . . . 37

CONTENTS ii

5 Non-volatile Data Protection in IaaS-environments 405.1 Storage Host Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Compute Host Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3 Intra-VM Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Choice of Data Protection Architecture . . . . . . . . . . . . . . . . . . 45

6 Implementing Block Storage Protection in OpenStack 476.1 Implementation Design Choices . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.1 Passivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.1.2 Cloud Platform Independence . . . . . . . . . . . . . . . . . . . . 49

6.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2.1 Modifications to OpenStack . . . . . . . . . . . . . . . . . . . . . 506.2.2 Requirements on Verifiability . . . . . . . . . . . . . . . . . . . . 50

6.3 Comments on Performance . . . . . . . . . . . . . . . . . . . . . . . . . 506.4 Comments on Applicability in OpenStack . . . . . . . . . . . . . . . . . 51

7 Repeated Estimation and Evaluation of Risks 537.1 Repeated Risk Level Estimation . . . . . . . . . . . . . . . . . . . . . . 537.2 Repeated Risk Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8 Discussion and Conclusions 578.1 Evaluation of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.1.1 Revisiting the CIA-triad . . . . . . . . . . . . . . . . . . . . . . . 588.2 Evaluation of Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.3.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608.3.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . 608.3.3 Further Improvements to the Implementation . . . . . . . . . . . 61

Bibliography 62

A CORAS Diagrams 65A.1 Context Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.2 Risk Assessment Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.3 Risk Treatment Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B Implementing the DBSP-protocol in OpenStack 77

iii

List of Figures

2.1 A simplified high-level picture of a multi-tenant IaaS cloud architecture. 82.2 Basic structure of logical volume management. . . . . . . . . . . . . . . 102.3 How issues are transformed using cryptographic techniques. . . . . . . . 112.4 Basic architecture of a small OpenStack-based IaaS cloud environment

consisting of five separate hosts with block storage and networking capa-bilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 The eight steps of the CORAS approach. . . . . . . . . . . . . . . . . . 20

4.1 Symbols of the CORAS risk modelling language. . . . . . . . . . . . . . 224.2 Overall target model of non-volatile data in IaaS environments. . . . . . 234.3 Scope of analysis and physical classification of cloud services. . . . . . . 254.4 Complete target model for the risk analysis. . . . . . . . . . . . . . . . . 264.5 Asset diagram with cloud service user/tenant as stakeholder. . . . . . . 274.6 Asset diagram with cloud service provider as party. . . . . . . . . . . . . 284.7 Risk evaluation criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.8 Potential attack vectors using virtualization technologies. . . . . . . . . 334.9 Risk classification using the risk evaluation criteria. . . . . . . . . . . . . 36

5.1 Target model with data encryption and decryption on the storage host. 425.2 Target model with data encryption and decryption on the compute host. 435.3 Target model with data encryption and decryption inside the virtual ma-

chine on the compute host. . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1 Overall architecture and interconnectivity between system components. 486.2 Secure Component basic architecture and libraries. . . . . . . . . . . . . 496.3 Additional time required for unlocking and locking of volumes introduced

by this implementation of DBSP. . . . . . . . . . . . . . . . . . . . . . . 51

7.1 Re-evaluated risk classification using the risk evaluation criteria. . . . . 557.2 Distribution of risks before and after treatment. . . . . . . . . . . . . . . 56

A.1 Sequence diagram of creation of a volume. . . . . . . . . . . . . . . . . . 65A.2 Sequence diagram of attachment of a volume. . . . . . . . . . . . . . . . 67A.3 Sequence diagram of data read e.g. using SSH. . . . . . . . . . . . . . . 68A.4 Threat diagram showing harm to indirect assets. . . . . . . . . . . . . . 69A.5 Threat diagram of deliberate risks. . . . . . . . . . . . . . . . . . . . . . 70A.6 Threat diagram of accidental risks. . . . . . . . . . . . . . . . . . . . . . 71A.7 Final threat diagram with estimated likelihoods. . . . . . . . . . . . . . 72A.8 Risk picture of non-volatile data in infrastructure clouds. . . . . . . . . 73A.9 Treatments and their impact on the risks. . . . . . . . . . . . . . . . . . 74

iv

A.10 Threat diagram showing treatments to mitigate risks. . . . . . . . . . . 75A.11 Threat diagram with re-estimated likelihoods and consequences. . . . . 76

B.1 Sequence diagram illustrating attachment of an unencrypted volume,showing the extensions made to the original sequence of actions. . . . . 77

B.2 Sequence diagram illustrating attachment of an encrypted volume, show-ing the extensions made to the original sequence of actions. . . . . . . . 78

List of Tables

4.1 Estimated scale of likelihoods. . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Asset table of cloud service user/tenant. . . . . . . . . . . . . . . . . . . 294.3 Asset table of cloud service provider. . . . . . . . . . . . . . . . . . . . . 304.4 Consequence scale of asset user data. . . . . . . . . . . . . . . . . . . . . 304.5 Consequence scale of asset cloud management software. . . . . . . . . . 304.6 Consequence scale of asset user VM. . . . . . . . . . . . . . . . . . . . . 314.7 Risks to direct assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.8 Risks to indirect assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Concluding advantages and disadvantages of di↵erent solutions. . . . . . 46

7.1 Re-evaluated risks to direct assets. . . . . . . . . . . . . . . . . . . . . . 537.2 Re-evaluated risks to indirect assets. . . . . . . . . . . . . . . . . . . . . 54

A.1 High-level risk analysis of non-volatile data in IaaS-environments. . . . . 66

1

Chapter 1

Introduction

Over the past number of years, the concept of cloud computing has experienced a rapidand significant increase in popularity. By applying the concept of resource sharing, enter-prises and organizations deploying their applications in the cloud are o↵ered scalability,reliability and availability to a reasonable cost in a pay-per-use model. The era of cloudcomputing is still highly topical in general, and the Infrastructure-as-a-Service model[18] in particular, due to increased customer interest in running scalable virtual serversin the cloud. It is understandable that enterprises and organizations in possession ofsensitive data, e.g. personal data or health records, ask themselves how to comply withstrict requirements on security while taking advantage of the wide range of benefits of-fered by cloud computing. This thesis aims to investigate such security aspects of cloudcomputing. More particularly, ensuring secure storage and use of non-volatile data inIaaS-environments.

To estimate the assumed decrease in security implied by storing and using data in IaaS-environments, compared to traditional storage on-site, a risk analysis is conducted usingthe CORAS method [35], yielding a summary of potential risks and treatments. Thetreatments are further investigated and combined into an overall security mechanismimplementing encryption and trusted computing principles [10] to secure non-volatiledata. To estimate the e↵ect, risks are re-evaluated, and finally the security mechanismis implemented in an OpenStack environment as a prototype proving the concept. Theimplementation is based on the findings during the risk treatment, adopting a protocol[29] created by Ericsson Research and SICS1.

1.1 Purpose

Refraining from adopting IaaS cloud solutions due to security reasons implies customerloss of the various appealing characteristics enabled by cloud computing. Cloud com-puting indeed introduces a variety of security issues, but the use of state-of-the-arttechnologies may facilitate in addressing such issues, thus encouraging further adoptionof IaaS cloud solutions.

This thesis is also a part of ongoing research by Ericsson Research and SICS, aimingto decide whether it is possible to migrate security-critical information systems to aninfrastructure cloud environment. As a study object for the overall project, a health-caresystem is chosen.

1Swedish Institute of Computer Science

1.2. THESIS OUTLINE 2

The reasons for migrating such systems into a cloud environment are mainly financial,but due to the sensitive nature of health records and other data in such systems, strictsecurity requirements must be met. A Swedish county is involved, providing health-care system software, and a pilot implementation of a secure cloud environment wheresuch systems could be deployed and security-evaluated is under development. The securecloud environment is based on the OpenStack cloud platform, thus motivating the choiceof cloud platform in this thesis. Furthermore, involvement in this project has influencedthe general direction of the thesis.

The motivation in section 1.4 furthermore substantiates the problem and thus the pur-pose and goals of this thesis.

1.2 Thesis Outline

Following the introduction, chapter 2 describes the background and the theoreticalframework forming the basis of this thesis. The background consists of a brief intro-duction to cloud computing in general and the Infrastructure-as-a-Service model in par-ticular, shortly describing virtualization and its role in cloud computing. Furthermore,non-volatile storage in IaaS-environments is described. Additionally, Trusted Comput-ing principles and the OpenStack platform are described. Following the background,the overall methodology and the CORAS method is described in chapter 3.

The analysis part of the report is divided into three chapters, with one additional chapterproviding a brief standalone description of the implementation (chapter 6). First, chap-ter 4 presents the documented results of the risk analysis: identified security concerns,risks, risk levels and risk-treating concepts. In chapter 5, the risk-treating concepts arecombined into di↵erent solutions aiming towards risk mitigation. Finally, in chapter 7,risks are re-evaluated, followed by a discussion in chapter 8 containing an evaluation ofthe results and the method. Furthermore, chapter 8 concludes the thesis by providingrecommendations to future work and briefly discussing the contribution.

Reading Instructions

A number of sections in the background contains information needed to fully understandthe implementation. Thus, all the information in such sections is not necessary for theunderstanding of the risk analysis, however it is facilitating. Such sections are 2.4.1,describing more detailed aspects of trusted computing and section 2.6.1 explaining thekey management protocol implemented in chapter 6. Furthermore, readers may skipsections in the background chapter according to their knowledge in the area.

1.3 Problem Description

Adoption of cloud solutions has increased significantly and rapidly the past number ofyears. Extended support and improved performance of virtualization technologies havecontributed to make the Infrastructure-as-a-Service (IaaS) service model increasinglypopular. According to a survey initiated by the Everest Group, IaaS is the only cloudservice model that experienced an increasing number of consumers between 2012 and2013 [15]. The number of enterprises and organizations planning to adopt IaaS cloudsolutions in a near future have also increased significantly during the same period, ac-cording to [15]. The referenced survey also shows that especially private- and hybridcloud solutions are the IaaS deployment models that are becoming increasingly popular.While public cloud adoption is subject to some growth, future plans of enterprises andorganizations are rather aiming towards the private and hybrid IaaS deployment models.

1.4. MOTIVATION 3

Another survey, conducted by Ponemon Institute reveals that almost half of the re-spondents believe that cloud adoption has decreased their security, and there are alsomajor di↵erences between consumers in their attitude about whom to hold responsiblefor securing and protecting data in the cloud; the consumer or the provider [18].

By taking the two above surveys into consideration and adding the fact that NISTpresents data breaches as the cloud computing top threat of 2013 [2], it is reasonable tosuspect that lack of data protection of data at rest, in transfer and in use, is preventingpotential cloud consumers from adopting public infrastructure cloud solutions. Instead,enterprises and organizations are using private cloud solutions to remain separated fromother, or hybrid cloud solutions where sensitive data are handled separately.

There are already various existing solutions available addressing a variety of securityproblems such as confidentiality, integrity, key management and trust as mentioned inchapter 2. Combining such solutions into an overall and accessible storage protectionsolution for infrastructure clouds is a logical step towards a more secure use of cloudcomputing, but it can certainly be performed in several ways, resulting in various char-acteristics of security, performance and usability.

1.4 Motivation

According to surveys [15] and [18], enterprises and organizations globally are uncertainabout if su�cient security measures have been taken to ensure protection of data storedin public IaaS environments. Thus, by adopting private- or hybrid IaaS solutions and re-frain from using public IaaS environments, enterprises and organizations decrease theirexposure and thereby the risk of unauthorized access to sensitive data. At the sametime, the opportunity to take part of the often huge amount of computing resourcesand storage resources available in a public IaaS environment are missed. Furthermore,single-tenancy tends to inhibit the degree of which resource sharing is adopted, poten-tially leaving computing resources unused, thus in some sense violating one of the mostfundamental concepts of cloud computing.

1.5 Aim

A computer cloud is a complex structure and which architecture and characteristics thatare desirable for a data protection mechanism depends on how the cloud is intended tobe used in combination with the needs of the cloud consumer (e.g. balance betweenexpectations on security and performance). There are four major questions which thisthesis investigates:

Q1 What are the main risks and threat scenarios using and storing non-volatile datain IaaS environments?

Q2 How can a data protection mechanism be implemented to mitigate or eliminaterisks, i.e. allow consumers to benefit from cloud computing without a decrease insecurity?

Q3 How can Trusted Computing principles be used to address important issues suchas key management and trust in a data protection mechanism?

Q4 How prepared is an OpenStack-environment for the modifications needed to adapta selected data protection mechanism?

1.6. LIMITATIONS AND SCOPE 4

The first question deems a risk analysis necessary to gain understanding of what toprotect and what risks exists. The second question intends to clarify and analyse howdi↵erent architectures of data protection mechanisms, i.e. design choices of the basiccomponents and the location of such components in the cloud computing stack, a↵ectsthe ability to protect non-volatile data in IaaS-environments. The third question aimsto investigate how Trusted Computing principles can be used for further security im-provements. The fourth question follows a proof of concept implementation and aims toevaluate how the risks are treated and also evaluate the adaptability of the OpenStack-environment to such a selected mechanism.

1.5.1 Contribution

Contributing to the discussion and development of cloud data security solutions resultsin a contribution to benefit further use and new adoption of public IaaS clouds inparticular, but also continued security-related development of IaaS as a cloud servicemodel in general. The risk analysis also adds to the general discussion of security aspectsin cloud computing which is highly motivated as enterprises and organizations migrateto the cloud. Furthermore, the implementation highlights a practical use-case of trustedcomputing principles.

1.6 Limitations and Scope

Analysis of di↵erent approaches to non-volatile data protection can quickly grow to asubject of unmanageable proportions, thus some limitations in the scope of this thesisare inevitable to be able to come up with concrete design choices, and from that pro-duce a reasonable prototype. Assumptions, limitations and scope of the risk analysis isdescribed separately in chapter 4.

- Data to ProtectThe risk analysis and the resulting protection mechanism is supposed to protect data inblock storage resources and not just arbitrary data. Reasoning during the risk analysisapplies to non-volatile data in IaaS-environments in general, but the implementationis focused on block storage data. However it is reasonable to consider protection ofdata on its way to or from a block storage resource as a feature of such a protectionmechanism. Protecting data during transfer between e.g. two virtual machines with-out involving a storage resource is thus not in scope for the protection mechanism.General data breach due to a malicious virtual machine is also not considered, butdata breaches that directly may a↵ect protection of data in a storage resource, e.g.leaked cryptographic keys is taken into consideration and discussed shortly, as this isrelated to the key management problem.

- Cryptographic techniquesThe protection mechanism relies on existing cryptographic techniques considered to besecure. Despite being theoretically possible to break these cryptographic techniques,such aspects are not considered as a point of failure.

- Trusted Third PartyA Trusted Third Party (TTP) is assumed to be completely trustworthy and successfulin fulfilling its tasks. Even if that is not always the case and a trusted third party mayfail, no data protection mechanism in this thesis takes any actions to mitigate risk ofsuch a failure, or to prevent any potential damage of such a failure.

1.6. LIMITATIONS AND SCOPE 5

- Trusted Platform ModuleA Trusted Platform Module (TPM) is always considered to be secure in the context ofthis data protection mechanism. This means that metrics stored in any of the platformconfiguration registers (PCRs) are considered genuine and unforgeable. Cryptographickeys bound or sealed to a TPM is also considered completely secure in context of theTPM. There are some assumptions made on what measurements that can be madeby the TPM. To produce a measurement able to be verified, it has to be the samebetween restarts of the trusted host, which implicates that code has to be hashed inthe same order, which is not the case for all operating system code (e.g. dynamicallyloaded libraries). In these protection mechanisms, the measurement and verificationcapabilities of the TPM might be extended, allowing the whole operating system tobe a part of the trusted computing base for any host.

- Trusted ComputingOther aspects vital in fulfilling the security purpose of Trusted Computing, in additionto trust in the TTP and trust in the TPM, are also assumed to be secure.

- Cloud Management PlatformThe implementation is made in an OpenStack-environment, but the conceptual designshould be as applicable to other cloud management platforms as possible. However,the selection of a certain platform implicates that the OpenStack-environment will bepresent in the analysis in the cases where a specific issue or behavior is needed to beput in context of an cloud environment.

- Security of Virtual MachinesBreach of confidentiality caused by exploited vulnerabilities in a virtual machine incontrol of a cloud consumer is not actively prevented in the data protection mechanismdiscussed in this project. The security solutions assumes that the cloud consumeror the cloud service provider is taking necessary precautions to avoid such exploits.However, the potential outcome of such an exploit is briefly discussed in context ofthe di↵erent solutions.

- Privacy and AnonymityAnonymity aspects of the implemented mechanism are out of scope of this thesis, andthus neither considered nor discussed.

From here and throughout the thesis report, above-mentioned assumptions are assumedto hold.

6

Chapter 2

Background

The results of the literature studies are presented in this background chapter organizedin two parts, where the first part covers the fundamentals of cloud computing and useof non-volatile data in infrastructure cloud computing. The second part briefly explainsOpenStack and Trusted Computing which is used in the proof-of-concept implementa-tion.

The term cloud computing has many explanations and there is no final agreed definitionof cloud computing. It is referred to as a new computer paradigm and sometimeseven a new technology [6]. The purpose of this thesis is not to contribute to the largevariety of explanations and interpretations already available. But to be able to referto some properties of cloud computing and address security concerns, a short review ofits fundamental concepts is necessary. Readers who already are familiar with the topicscovered in this chapter may skip these sections accordingly.

2.1 Cloud Computing Basics

The National Institute of Standards and Technology1 (NIST) have composed a widelyused high-level definition of cloud computing [23]:

”Cloud computing is a model for enabling ubiquitous, convenient, on-demandnetwork access to a shared pool of configurable computing resources (e.g.,networks, servers, storage, applications, and services) that can be rapidlyprovisioned and released with minimal management e↵ort or service providerinteraction.”

In this thesis, cloud computing aspects are explained according to the cloud definitiondeveloped by NIST. According to this definition, a cloud can typically be describedto have five essential characteristics; on-demand self-service, broad network access, re-source pooling2, rapid elasticity and measured service. From a security point of view,the resource pooling characteristic may be the most important and challenging sincethe hardware boundary using separate computational hardware resources is put out ofaction.

1A US measurements standards laboratory.2Multiple consumers share the resources provisioned by the cloud provider in a multi-tenant model

[23].

2.1. CLOUD COMPUTING BASICS 7

2.1.1 Service Models

NIST classifies a cloud deployment as one out of three types of service models [23]. Thefundamental service model provides a basis which the other service models are builtupon. Simply put, the service model declares what the cloud consumer is able to useand control; just an application, an execution environment or an entire platform.

• Software as a Service (SaaS) - A cloud consumer is only allowed to use certainapplications provided by the cloud provider. Applications are accessible from aclient device3, and configuration of applications using application-wide or system-wide settings are not permitted. SaaS is the most confined service model andbuilds on top of a cloud platform, and finally a cloud infrastructure. Web-basede-mail and o�ce-suites are examples of SaaS implementations.

• Platform as a Service (PaaS) - A cloud consumer hold capabilities to use the un-derlying platform to deploy its own applications but is limited to use programminglanguages, libraries and tools that the cloud provider has chosen to support in theunderlying infrastructure. The result is a confined environment, i.e. platform. Aweb hosting service is one example of a PaaS provider, where a user deploys itsown web-applications using supported technologies.

• Infrastructure as a Service (IaaS) - The most fundamental service model wherethe cloud consumer is in command of an entire virtual platform. Implicitly, theuser is in full control of the operating-system and able to deploy and run arbitrarysoftware. The underlying cloud infrastructure is still out of control of the cloudconsumer. Amazon Web Services is an example of a well-known IaaS vendor.

2.1.2 Deployment Models

According to NIST, how a cloud is deployed can be categorized into four di↵erent typesdepending on the intended group of tenants4 and their concerns;

• Private cloud - The cloud infrastructure is exclusively used by a single tenant,e.g. organization or enterprise. Resource sharing is only applicable between cloudusers within the same organization or enterprise.

• Community cloud - The cloud infrastructure is used by several tenants with com-mon concerns. Resource sharing in this deployment model is between severaltenants.

• Public cloud - The cloud infrastructure is accessible and open for use by any tenant(the general public), pushing the concept of resource sharing to its maximum.

• Hybrid cloud - A hybrid infrastructure based upon two or more cloud infrastruc-tures of the other cloud deployment models into one single cloud infrastructure.

Despite classified as a private cloud or a community cloud, the cloud infrastructuremay be provided and managed by an organization or a third party. Thus, the clouddeployment model only classifies a cloud infrastructure with respect to its intended typeof usage.

3Web-browsers and programs are typical client devices4Similar to a user or a group of users in terms of general computing

2.1. CLOUD COMPUTING BASICS 8

As the focus of this thesis is to investigate security of non-volatile data in infrastruc-ture clouds, the term cloud computing is from here and onwards used interchangeablywith infrastructure cloud computing. A simplified high-level picture of an IaaS cloudarchitecture is shown in Figure 2.1, illustrating k tenants jointly running j virtual guestmachines sharing the computational resources of i physical hosts. Such resources areprovisioned by a cloud provider through virtualization and managed by a cloud man-agement platform.

Tenant kTenant 2Tenant 1

Host 1 Host 2 Host 3 Host i

V i r t u a l i z a t i o n

Guest 1 Guest 2 Guest 3 Guest 4 Guest 5 Guest j

C l o u d M a n a g e m e n t P l a t f o r m

Figure 2.1: A simplified high-level picture of a multi-tenant IaaS cloud architecture.

2.1.3 Virtualization

Virtualization is one of the key technologies in cloud computing, enabling resource shar-ing and also rapid elasticity as hardware is emulated. According to VMware5, ”the termvirtualization broadly describes the separation of a resource or request of a service fromthe underlying physical delivery of that service” [38]. In cloud computing, hardwarevirtualization is adopted to create one or several instances of virtual hardware upon asingle instance of physical hardware. This allows one or several guest operating systemsto run on an separate confined platform residing in a single physical machine. The sep-aration between physical hardware and virtual hardware is achieved by introducing anabstraction layer which mediates all access between any so-called virtual machine andthe physical machine [34]. This abstraction layer is referred to as a Virtual MachineMonitor [31] (VMM) or a hypervisor6 and in addition to running and managing virtualmachines, the hypervisor is also responsible for enforcing separation.

There exist various flavors of hardware virtualization [1] where full virtualization andparavirtualization are commonly used. Full virtualization enables configuration andemulation of a complete set of hardware, making it possible for an unmodified operatingsystem to run on the virtual machine, even unaware of the fact that the machine isvirtual [11]. For increased performance, direct device assignment can also be adoptedto replace the performance demanding emulation [4]. The other type of virtualizationis para-virtualization, where the hypervisor makes one or several types of hardwareresources of the physical host available to the guest through interfaces, thus eliminatingthe need of the performance-demanding emulation of all hardware [34]. Since the guestneeds to run a modified operating system to make use of the interfaced hardware inpara-virtualization, compatibility has to some extent been traded for performance.

5VMware, Inc. is a software company providing virtualization software i.a.6Both the terms VMM and Hypervisor are used interchangeably according to virtualization technol-

ogy vendor, but in this thesis the term hypervisor is mostly used.

2.2. NON-VOLATILE DATA IN IAAS-ENVIRONMENTS 9

2.2 Non-volatile Data in IaaS-environments

Each virtual machine is assigned its own instance storage, enabling storage of arbitrarydata such as logs and configuration files. This storage is normally neither durable norpersistently stored at the end of the virtual machine life-cycle. In this sense, launchingan instance of a virtual machine is comparable to booting a Live-CD on a desktopcomputer; saving data to files is possible, but everything is gone once the virtual machineis rebooted. Consequently, cloud consumers are likely to need persistent storage tostore arbitrary data over time, where object storage and block storage are two commonapproaches [9].

- Block Storage - Using block storage, data are stored in blocks, i.e. a sequence ofbytes, which are written to/read from a block device. A block device is the most rawand lowest-level representation of a storage device, revealing the underlying physicalstructure to the user. Commonly, the block device is used to host a file-system, a layerof abstraction between the user and the end-device resulting in a more convenientrepresentation, allowing the user to handle and organize files instead of blocks. Suchabstraction layers are not always desirable, and there are applications which maybenefit from running directly on a block-device, such as databases. As databases maywant to implement a specific type of caching, the caching capabilities provided andcontrolled by the operating system is not always desirable. A major benefit of usingblock devices is the freedom of choice, i.e. the possibility for users to deploy a file-system of their choice or use their own application-specific block device representations.To a virtual machine, the block storage device appears as directly attached to thatcertain machine, and is accessed through any device access mechanism provided bythe operating system. The freedom of choice have made block devices an importantapproach to persistent storage in infrastructure clouds.

- Object Storage - The need of scalable and accessible storage which can be accessedfrom several devices simultaneously gave birth to object storage. Object storage issomewhat similar to a file-system deployed on a block device, but is generally accessedthrough a lightweight RESTful API7, achieving large accessibility. The abstractionlayer also decouples the objects from the blocks where the data physically resides,making it highly scalable, since the natural boundaries of a block device no longerare a limitation. Objects are replicated in a distributed network of storage resourcesproviding redundancy, and automated load-balancing ensures high performance [8].Objects are normally requested through a proxy, keeping track of at which storageresource an object is located.

Object storage is ideal for read-intensive data which is required to be widely accessible,such as images and pictures. As data is replicated in a distributed network, changesto objects may cause inconsistency, or an eventual delay while consistency is ensured.Thus, object storage is most suited for static data, or non-frequently modified data. Itis important to mention that object storage is a type of storage itself, and has a majorarea of use outside infrastructure cloud computing. Despite major benefits, there is stilla need for block storage solutions in infrastructure clouds as mentioned above. It isalso important to mention that block storage also can be scalable to some extent, byadopting logical volume management (described in section 2.2.1) and using file-systemsthat allow resizing.

Cloud storage is often provided as a separate service, e.g. in Amazon Web Services,Amazon EC2 service is responsible for managing the virtual machines, while Amazon

7Representational State Transfer, a simpler alternative to SOAP


EBS provides block storage and Amazon S3 provides object storage. Depending on theexisting application-programming interfaces, it is possible to combine computationalresources and storage resources from di↵erent providers, e.g. compute resources inOpenStack (described in section 2.3) can use block storage provided by Amazon EBS.

2.2.1 Logical Volume Management

Logical volume management enables scaling of block storage devices and resource pool-ing, which are two NIST cloud computing characteristics [23] also applicable to storage.Another benefit of using logical volume management is the possibility to create volumeslarger than one single physical disk. Logical volume management can be seen as a type ofvirtualization applied on disk level, where a set of physical volumes are grouped togetherand presented as a large homogeneous disk, a so-called volume group [16]. This groupis then used to hold virtual volume entities mapped to the physical volumes, so-calledlogical volumes. Since a logical volume only is a reservation of blocks on the physicalvolumes, it is easy to reserve more available blocks, or release blocks that are not neededany longer, thus enable scaling of the volume size.

VG0

Mapping-tableOS

Logicalvolumes

Volumegroups

Physicalvolumes

Figure 2.2: Basic structure of logical volume management.

As previously discussed, ability to scale block devices may depend on what the blockdevice is used for. A block device itself is often not that useful without deploying anabstraction layer. To be able to benefit from the feature of resizing block devices, thisabstraction layer must support resizing as well.

2.2.2 Storage Security Concerns

One of the most frequently proposed notions of computer security is the CIA triad[12], referring to three security properties; confidentiality, integrity and availability. Therisk of these properties to be violated is present regardless if data are available over anetwork or through physical access exclusively. Loss of data due to hard-drive breakdown(availability), or data breaches (confidentiality) caused by stolen hard-drives during abreak-in are examples of such physical violations. But making data available over anetwork, such as the Internet, introduces a new widely available and versatile entrypoint, in parallel to the physical entry point resulting in a much greater risk that theCIA properties are violated.


An e�cient and straight-forward method of addressing the integrity and confidentialityissues is to use cryptographic techniques. While introducing cryptographic techniquessolves confidentiality and integrity issues in theory, the reality is that the mentionedissues are transformed into a set of new concerns shown in Figure 2.3, with the confi-dentiality/integrity problem as entry-point.

Con�dentiality / Integrity

TrustData loss (availability)

Key managementEncryption

Lost keys

Ou

tso

urc

ing

Outsourcing

Leaked keys

Leaked keys

Lost keys

Figure 2.3: How issues are transformed using cryptographic techniques.

By adopting encryption, the need to ensure confidentiality and integrity of data appliesto the encryption key instead. A leaked key may result in compromised confidentialityand illegal modifications to a key might lead to data loss. By outsourcing data protectionor key management to an external party, that party must be trusted. A failing externalparty may lead to compromised data security. Figure 2.3 illustrates this correlation ofissues.

2.3. THE OPENSTACK CLOUD PLATFORM 12

2.3 The OpenStack Cloud Platform

OpenStack8 is an open-source cloud computing project and community joined by severalmajor enterprises such as Ericsson, VMware, IBM and Intel Corporation. The Open-Stack cloud management platform makes use of already existing hypervisor technologies,messaging software, logical volume management software and databases. OpenStack canbe viewed as a higher-level coordinator, consistently composed of a set of general inter-faces and protocols used to coordinate several software into an IaaS-environment. Dueto its generality, OpenStack can be deployed on a huge variety of platforms.

2.3.1 Architectural Overview

An OpenStack deployment is component based and built upon several intercommunicat-ing standalone services responsible for a certain function. The cornerstone service is thecomputing service, the cloud fabric controller, Nova9. Thus having Nova installed andconfigured on a host results in having the resources of the host, i.e. CPU and memory,provisioned to the cloud resource pool. Additionally there are services responsible fornetworking (Neutron) and storage, and one single computer can run several services,e.g. a compute node may also provision its hard drives by installing the block stor-age service (Cinder) or the object storage service (Swift). There are also a number ofshared services, such as an identity managing service, an web-based dashboard service(Horizon), an image service and a telemetry service for billing purposes. Each service isaccessed through an application programming interface and user managing of the cloudis performed from a command-line client or the web-based dashboard service. Every callbetween services is performed using a messaging system implementing AMQP10. Thestrict component based approach used in OpenStack makes the cloud itself scalable,manageable and expandable.

The compute service, the block storage service and the object storage service are theimportant services in context of this thesis and is therefore explained in more detail,according to the OpenStack Configuration Reference [26].

Nova

Nova is the heart of the IaaS system, handling the virtual machines. Nova does nothandle the virtual machines itself, but is using existing hypervisors and possibly emu-lators installed on the host, such as KVM/QEMU or Xen. However, Nova is respon-sible for communicating with the hypervisor/emulator and thus dispatching requestsfor launching of virtual machines. It is also responsible for communicating with thehypervisor/emulator to attach and detach arbitrary virtual hardware such as virtualhard-drives (provided by Cinder) and virtual network interfaces (provided by Neutron).To be precise, Nova uses the libvirt virtualization API to communicate with the hy-pervisor/emulator. For simplicity, libvirt is omitted while explaining the di↵erent cloudservices below.

8The OpenStack project, https://www.openstack.org/9Nova consists of several sub-services such as Nova API, Nova Scheduler, Nova Conductor and Nova

Compute. The pure cloud fabric controller is Nova Compute which for simplicity reasons is referred toas Nova.

10Advanced Message Queuing Protocol (AMQP) - an open standard application layer protocol formessage-oriented middleware.

2.4. TRUSTED COMPUTING 13

Cinder

Cinder manages block devices, which includes creation, removal and expansion of vol-umes upon request. When Cinder has been installed and properly configured, physicaldevices at the host are provisioned to the cloud in the form of volume groups where userscan host their volumes. To attach a volume to a virtual machine, a network-based stor-age protocol is used to first connect it to the compute node hosting the virtual machineand finally it is forwarded to the virtual machine by configuring the hypervisor/emulatorthrough Nova.

Swift

Swift provides object storage by combining physical hard-drives into a scalable storageresource. Unlike block storage, a cloud consumer uses a REST API to write, read anddelete data, so-called objects, residing in an object storage resource, so-called container,over network. Thus, an object storage resource is accessed through a virtual network in-terface in the virtual machine instead of the virtual disk interface, involving the networkservice (Neutron) in provisioning of object storage. Despite the di↵erences, the overallarchitecture is similar; storage nodes and compute nodes connected over a network.

With the description of the OpenStack overall architecture in mind, together with thedescription of Nova, Cinder and Swift, Figure 2.4 is showing an example of what anOpenStack-based cloud environment can look like.

nova nova nova

cinder

horizon

cinder cinder

neutron

API

CloudManagement

Layer

Standard OS CentOS

CPU RAM CPU RAM CPU RAM HDD HDD HDDProvisioned

Hardware

StandardHardware

VM0 VM1 VM2 VM3 VM4 VM5

VLAN1

VLAN0

Ubuntu Ubuntu Ubuntu CentOS

User

Manager/user

Figure 2.4: Basic architecture of a small OpenStack-based IaaS cloud environmentconsisting of five separate hosts with block storage and networking capabilities.

2.4 Trusted Computing

Trusted Computing is an initiative taken by the Trusted Computing Group (TCG). Itis a consortium between several major organizations11 in the Information Technologyindustry aiming towards more secure computing. The TCG have developed a specifi-cation of a reference architecture that is used to ensure trust which according to TCG

11E.g. AMD, Cisco, Hewlett-Packard, IBM, Intel Corporation, Microsoft

2.4. TRUSTED COMPUTING 14

holds if a device or system is behaving in a particular expected manner for a specificpurpose [36].

Assuming that no entity in a system is trusted by default is a security precaution,but it greatly constrains the possibilities to use the system. Trustworthiness should beachieved as a result of some satisfactory verification of the system, which in the TCGspecification is solved by introducing the Trusted Platform Module (TPM).

2.4.1 Trusted Platform Module

The TPM is typically an isolated piece of hardware that is physically attached to acertain platform mounted on the motherboard, and accessed through a TCG-specifiedinterface. Amongst the TPM features are platform attestation and protected storage[10]. The TPM architecture is mainly built upon the cryptographic co-processor, a por-tion of persistent memory, a portion of versatile memory and the input-output interfaceto communicate with the host platform. The architecture specifies the core componentsof the TPM enabling these features.

• Cryptographic co-processor - the fundamental cornerstone of the TPM is the abilityto perform random number generation and key generation. It can also performencryption, decryption, hashing and signing12.

• Endorsement Key (EK) - is an asymmetric key-pair created and stored in thepersistent memory when the TPM is manufactured. The key-pair is permanentlyembedded in the TPM hardware and the private key can never leave the TPMchip (non-migratable). Thus, the public key certificate issued by the TPM vendorcan be used to identify a certain TPM hardware, i.e. a specific platform.

• Storage Root Key (SRK) - another non-migratable key stored in the persistentmemory, but is generated inside the TPM when the user takes ownership of theplatform. The SRK is used to protect other keys created using the platform byencrypting them with the SRK so that they cannot be used without that specificTPM, i.e. bound to that certain platform.

• Platform Configuration Registers (PCR) - contains strong cryptographic digests(also called integrity measurements) of metrics of the platform characteristics suchas program code loaded during the boot process. The digests are extended by re-hashing a previous PCR-value in combination with a new metric. This procedureresults in a secure hash that identifies the integrity and state of the platform, e.g.what program code that has been executed.

• Attestation Identity Keys (AIK) - an either migratable or non-migratable asym-metric key created to identify that a platform is trusted without revealing theidentity of the TPM (the EK). This makes it possible to maintain anonymitywhile communicating with external parties. The AIK is created by signing prop-erties of the EK, and can then be verified by the TPM manufacturer issuing theEK and later verified by an external party.

• Storage Keys - derived from the SRK to protect data. Can be used to seal andbind data to a certain TPM and is described below.

12In TCG specification version 1.2 used in this thesis, RSA with 2048 bits keys are used for encryptionand decryption while SHA-1 are used for hashing

2.5. IAAS STORAGE SECURITY IN RESEARCH AND INDUSTRY 15

These components are combined in various ways to provide the features described in[10], e.g. platform attestation is performed by signing an integrity measurement usingan AIK and have it verified by some third party. Thus, the integrity and the identityof the platform can be attested. Since the TPM is a separate hardware module onlyaccessible through a specific interface, it is resistant against software tampering. Thus,to tamper with the TPM, physical access to the hardware is required. Except for remoteattestation, the TPM can be used to bind and seal data.

• Binding - by using a public key derived from the Storage Root Key stored in acertain TPM, any data (e.g. a symmetric encryption key) encrypted with thatpublic key can only be decrypted by that specific TPM. The data is said to bebound to that specific platform.

• Sealing - by binding data and considering the TPM state, it is possible to encryptdata using a public key which then only can be decrypted on a certain platformin a certain state. This is an extension to normal binding and is called sealing.By sealing data, a party sending data to a platform is able to not only verify theplatform identity authorized to access the plain-text data, but also that it is in atrusted state.

Using a Trusted Third Party

A Trusted Third Party (TTP) is a trusted13 entity used as a third party in communi-cation between two parties who both trust the third party to facilitate secure commu-nication. In combination with public-key cryptography to identify the TTP, the TTPis well suited for performing di↵erent types of security related actions, such as verifyingintegrity measurements, authentication and key generation. Another important bene-fit from using the TTP in Trusted Computing is that it makes it possible to maintainanonymity between communicating parties, but it is not considered for the rest of thisthesis.

Limitations

The TCG specification as a security architecture does rely on trusting the fundamen-tal components such as the Trusted Platform Module and a Trusted Third Party. Ifsuch trusted entities fail, roots of trust fail accordingly, leaving the platform untrusted.Software-tampering with the TPM is made di�cult by isolating it as a standalone hard-ware chip, but with physical access to the TPM hardware the conditions change.

The applicability of the attestation is also limited since the expansion of integrity mea-surements need to be performed in the same order every time to give the same measure-ment. This results in requirements on what code that can be attested, and might leadto di�culties in verifying the integrity of dynamically loaded portions of code.

2.5 IaaS Storage Security in Research and Industry

Since the beginning of the cloud computing era, the security aspects of adopting cloudsolutions have been a topic for research. By considering the top threats defined byCloud Security Alliance [2], a shift in focus can be observed. Threats against cloudservice providers caused by malicious users has been downgraded and threats against

13Trust as defined according to [36].

2.6. RELATED WORK 16

cloud users are emphasized. As Trusted Computing technologies are getting increasinglymature, adoptions of such techniques in cloud computing are also subject of research[28, 29].

It is reasonable to assume that many of the di�culties lie in implementing securitywithout violating the attractive implications of cloud computing. Such a di�culty is forexample the ability to maintain control of outsourced data using cryptographic tech-niques, and at the same time having it highly accessible. This puts requirements on keymanagement schemes, which nowadays is a huge area of research, e.g. in [40]. While stillvery immature, homomorphic encryption to operate on encrypted data should likely be agroundbreaking technique solving many of the problems with data storage outsourcing.Accordingly, such techniques are highly topical and subject of research, e.g. in [24].

Trusted Computing is well established in terms of securing operating systems, and is alsofrequently appearing in research on virtualization, to perform integrity checks on virtualmachines [5]. Furthermore, research is also aiming towards additional applications ofTrusted Computing to virtualization in context of cloud computing, such as verifyingintegrity of the compute host [28] and secure use of cloud storage [29].

2.6 Related work

When it comes to cloud security in general and cloud storage security in particular, alot of focus and work has been put into finding procedures for assessing, verifying andensuring that data is safely stored at an acceptable performance impact. Wang et al [39]proposes a method to achieve publicly auditable cloud storage services by using a thirdparty that assess the risk of outsourced data. By making a cloud storage service publiclyauditable, it is suggested that a data owner can gain trust in the provider. Furthermore,by letting a trusted third party perform the assessment, the data owner can also makeuse of the computational resources needed to assess the risk. The solution proposed in[39] addresses the issue of trusting the cloud storage provider.

Proper deletion of data on request is another important aspect of secure cloud storage,and in [30], Paul et al proposes a scheme able to securely erase data and also to provethat the actual data really has been removed. The scheme ability of giving this proofmakes it a interesting solution to the issue of ensuring data destruction.

In [19], Kamara et al suggests a data protection scheme where data is encrypted beforeit is sent to the cloud for storage. The author suggests using searchable encryptionschemes in combination with attribute-based encryption schemes to secure data butalso be able to search through data without the need of decrypting it.

As the key enabling technology of cloud computing and multi-tenancy, virtualizationsecurity is a large research area. In [33], Sabahi discusses a number of security issuesregarding the use of virtualization, and in [41] Zhang et al performed an attack against acertain virtualization issue to retrieve cryptographic keys. Ensuring secure virtualizationplatform in IaaS environments is up to the cloud service provider. Therefore, trust isrelated to virtualization security. As all computations in a virtual machine is observableon the VM host, it is desirable that the compute host holding the VM-instance canbe trusted. In [28], Paladi et al comes up with a mechanism and protocol that allowsVM-instances to be launched on a provable trusted compute host, and furthermore themechanism allows the client conducting the VM launch to verify that it indeed has beenlaunched on a trusted compute host.

2.6. RELATED WORK 17

2.6.1 Domain-Based Storage Protection

In [29], Morenius et al proposes a protocol for storage protection in IaaS environments,which is a step towards combining individual techniques such as Trusted Computing andencryption to achieve protection of storage resources. The protocol is an extension to [28]where each virtual machine running on a trusted host and each volume protected underDomain-Based Storage Protection (DBSP) additionally is bound to a so-called domain.The domain is a theoretical quantity of data protected under a certain cryptographic key,where only the virtual machines belonging to a specific domain are allowed to access thedata. Access to a domain is granted by proving access rights through an assertion to atrusted third party. The compute host running a virtual machine authorized to a certaindomain receives a Session Domain Key from the TTP, used for further communicationwithin the boundaries of that certain domain and may pose as a proof of the accessrights. As domain association is performed during launch, membership of a domainguarantees a successful attestation of the compute host. Writing to a protected domainfor the first time implies creating the keys used to protect the data. The detailedbehavior and sequence of events is described in [29], with the general idea that the so-called metadata needed to derive the protection keys are stored in the actual domain,making it self-contained. For first time and subsequent data reads and writes, keys arederived by the TTP using the metadata in combination with a non-migratable masterkey. The software controlling and enforcing above-described behavior is referred to asthe Secure Component.

The protocol proposes one way of combining di↵erent security technologies into a in-tegrated protection mechanism, but there are aspects not discussed in the paper, e.g.verifiability proving that an implementation of DBSP is operating as expected. Theprotection solutions discussed and proposed in this thesis uses schemes proposed in theDBSP paper [29], and aims to further investigate and evaluate how such a protocol canbe implemented in an IaaS-environment and integrated into a protection solution.

18

Chapter 3

Methodology

This project is divided into four methodological steps; study of literature, structuredidentification of risks and threats to non-volatile data in IaaS-environments using theCORAS method, proposing approaches to risk-treating data protection and finally revis-iting the most important risks to evaluate the successfulness of a selected implementedmechanism. A certain approach to data protection is selected as a result of qualitativereasoning and revisiting of the risks. In addition, a proof-of-concept implementationis performed to briefly evaluate implementation-level issues of such a mechanism. TheCORAS approach is described in more detail in section 3.1.

The overall methodological approach and structure of the project consists of the follow-ing high-level steps described in order of execution:

1. Study of Literature

The study of literature is covering the basics of infrastructure cloud computingplus use and storage of non-volatile data in the IaaS service model. To facilitatethe risk analysis; a basic understanding of cloud computing security issues is gainedby reading a wide range of articles covering cloud-computing security aspects.

2. Target Modeling and Risk Analysis

A CORAS risk analysis is conducted to identify the most important risks to non-volatile data in IaaS-environments and to propose treatments to such risks. Fur-thermore, the target model is built upon documentation of how non-volatile datais used in IaaS-environments in general and OpenStack in particular. The out-come of this step is the result of the CORAS risk analysis. Finally, at the pointof risk treatment identification, any additional requirements are introduced andmotivated.

3. Risk Treatment and Protection

The risk treatments from the CORAS analysis are evaluated in their risk treatingability and cost, and are combined into a complete set of risk treatments formingan approach to data protection. Each approach is subject to an evaluation consid-ering the non-acceptable risks to motivate its risk-treating ability. Any additionaladvantages or drawbacks of a certain approach are also introduced and consideredin the evaluation. The outcome of this step is a comparison between di↵erentapproaches to data protection and a proposal for a risk-treating protection mech-anism.

3.1. THE CORAS METHOD 19

4. Implementation, Repeated Risk Level Estimation and Evaluation

The selected mechanism is implemented in OpenStack as a proof-of-concept pro-totype to identify implementation-level issues and briefly evaluate the adaptabilityof such a data protection mechanism to an IaaS-environment based on OpenStack.

Furthermore, the selected solution is subject to a fully implemented and repeatedrisk assessment, implementing step 6-7 of CORAS. In addition to the risk level es-timation conducted while motivating the di↵erent solutions, risks a↵ecting indirectassets are considered and repeatedly evaluated and the entire resulting risk-pictureis presented in terms of before-and-after.

3.1 The CORAS Method

The risk analysis conducted in this project is based on the CORAS approach; a modelbased risk analysis method using a customized language for threat and risk modeling.The results are presented using di↵erent types of diagrams defined in the language.CORAS consists of eight separate steps (shown in 3.1) organized into three phases;context establishment, risk assessment and risk treatment. Below is a description of theeight steps defined in [35] and their application in this specific project:

1. Preparation of the risk analysis process by gaining initial knowledge and under-standing of the target; use and storage of non-volatile data in IaaS-environmentsin general OpenStack in particular. Size and scope of the analysis are briefly dis-cussed. The preparations are based on study of literature related to infrastructurecloud computing.

2. Introductory meeting with the customer to highlight the main goals and concernsof the customer and the initial target of the analysis from the customer’s point ofview. The customer in this risk analysis is Ericsson Research. The result of thesecond step is a definition of focus and scope of the analysis.

3. Agree on the target of analysis, its scope and focus. In cooperation with EricssonResearch, the main direct and indirect assets are identified and a high-level riskanalysis is conducted to identify the most important threat scenarios and vulner-abilities to be subject of further investigation. The outcome of the third step is adocumentation of the target description and the identified assets.

4. Decision point where all of the information collected in the previous steps is com-plete and is to be approved by the customer. As a final preparation, a risk evalua-tion criteria is created in cooperation with the customer, together with definitionsof likelihoods and consequences concerning each direct asset. The CORAS riskevaluation criteria matrix is used to classify risks as acceptable and non-acceptableor using a multi-step criteria [35].

5. Risk identification using structured brainstorming, organized as a walkthroughof the target model to identify threats, unwanted incidents and vulnerabilities, allsubstantiating the risks. The results and outcome are documented on the fly usinga certain type of diagram defined in the CORAS language.

6. Risk level estimation of the risks represented by the unwanted incidents, alsoperforming structured brainstorming. Risk level estimating consists of determininglikelihood of threat scenarios and unwanted incidents, followed by determining


Preparations for the analysis

Customer preparation of the target

Refining the target description using asset diagrams

Approval of the target description

Risk identification using threat diagrams

Risk level estimation using threat diagrams

Risk evaluation using risk diagrams

Risk treatment using treatment diagrams

Figure 3.1: The eight steps of the CORAS approach.

consequence to each asset a↵ected by the unwanted incidents. In this risk analysis,the likelihood of the unwanted incidents and threat scenarios are derived from thelikelihood of the preceding threat scenario from left-to-right, i.e. from the initialvulnerability ending up in the actual risk. The combination of likelihood andconsequence defines the risk level of each identified risk.

7. Risk evaluation where each risk is evaluated if it is acceptable or not. If a riskis acceptable or not is decided by putting the risk in the matrix defined by acertain risk evaluation criteria. Indirect risks are also considered during the riskevaluation.

8. Risk treatments are proposed by evaluating their ability to reduce likelihoodand/or consequence of the preceding threat scenarios and vulnerabilities, thusmitigating the risk. Treatments are also discussed from a cost-benefit perspectiveand in terms of feasibility. The risk treatment plan concludes the risk analysis.

The context establishment phase consists of the first three steps, i.e. until approvalof the target to be analyzed. The actual risk analysis is performed during the riskassessment phase; steps 5-7, resulting in an overall risk picture of the target. Finally,the last phase, i.e. risk treatment, consists of the last step in the CORAS approachaiming to identify risk treatments from the overall risk picture.

The purpose of the context establishment phase of the risk analysis is to, in a structuredway, set the focus of the analysis resulting in a target model covering the goals of thecustomer. The context establishment helps in transforming the customer interests intosuch a target model, without influencing the customer. Due to pre-defined specificationsin this project, the focus of the risk analysis has partly been set in a strictly techni-cal direction from the beginning. Yet, there are several major benefits from using anapproach such as CORAS, as risks are identified and assessed instead of pure threat


scenarios e.g. when using attack trees. Another benefit is the well-defined method tocollect information during the risk assessment, and the language used to document thefindings. Finally, as a risk re-evaluation of identified risks is to be performed as a stepin evaluating the risk treatment, the risk evaluation criteria in CORAS is suitable forsuch a comparison.

3.1.1 Structured Brainstorming

The CORAS approach makes use of structured brainstorming in the fifth and sixthsteps where risks are identified and assessed. Structured brainstorming is an approachto brainstorming where each participant is given the equal amount of time to contributeand introduce his or her ideas. Ideally, the participants in the sessions of structuredbrainstorming are representing several di↵erent interests and backgrounds, enabling con-tinuous identification of more risks than a single homogenous group of individuals. Dueto the technical nature of the customer, the implicitly technological nature of the in-dividuals contributing with ideas and the pre-specified scope of analysis, it is possiblethat more risks could have been identified with additional interests contributing.

22

Chapter 4

Risk Analysis of Non-volatileData in IaaS-environments

This chapter describes the execution and results of the conducted CORAS risk analysisand is organized in three sections according to the CORAS method; context establish-ment, risk assessment and risk treatment. In the first section, the target model andassets are described, followed by threat diagrams and description of the identified secu-rity concerns in the second section. In the third section, the risk treatment concepts areintroduced and combined into di↵erent approaches to protection of non-volatile data inchapter 5.

CORAS [35] defines the symbols and notation shown in figure 4.1.

Threat scenario!

Human threat!(accidental)!

Human threat!(deliberate)!

Non-human!threat!

Direct!asset!

Indirect!asset!

Party! Vulnerability!

Treatment scenario!

Unwanted!incident! Risk!

Figure 4.1: Symbols of the CORAS risk modelling language.

4.1 Context Establishment

Due to the technical orientation and the pre-defined scope, the target model defined inthis risk analysis is a system architectural model involving end-point entities such asvirtual machines, compute nodes and storage nodes hosting storage resources (i.e. thehard drives). Furthermore, systems and the interconnectivity between such systems,crucial in enabling persistent storage, are covered by the target model.

Important aspects are data transactions, management of block storage and managementof object storage. A data transaction is the life cycle of the transaction between a storageresource on one side and a virtual machine on the other side, e.g. a read action or awrite action. Management of block storage is the events of creating, removing, attachingand detaching block storage volumes. Furthermore, management of object storage is theevents of creating and removing block storage containers. The model is used as a basis

4.1. CONTEXT ESTABLISHMENT 23

to identify unwanted incidents and threat scenarios based on security-critical data paths,control paths and points of failure. Beyond the scope of the actual risk analysis, themodel is involved in evaluating the proposed treatments and solutions in context of IaaSenvironments1.

4.1.1 Step 1 - Preparations and Initial Observations

Based on the high-level OpenStack documentation of non-volatile data, combined withan investigation of the IaaS structure in Nova [27, 25], an initial target model is created.

Any tenant in control of a virtual machine is able to store and use arbitrary data inpersistent block storage or object storage, provisioned by a network-connected storagenode. A block storage volume is typically attached in two steps; first to the computenode hosting the virtual machine and then to the actual virtual machine where it appearsas an ordinary local volume. Data is read and written by any process running insidea virtual machine. A cloud consumer can typically connect to the virtual machinethrough an arbitrary protocol, such as SSH or VNC, to control the virtual machine. Anobject storage container is similar to a volume but contains objects; but unlike a blockstorage volume, a container is not attached to a certain virtual machine. To read anobject within a container, an object is pulled over a network, and to write an objectto a container, such object is pushed over a network. In object storage the objects aretypically distributed over several nodes. A storage node acts as a proxy to present theobjects to the virtual machine.

Cloud Consumer Cloud Manager

CLI(admin)

Compute End-Point Storage End-Point

VMCM

BS

BS

CM

Network

CLI (ssh) CLI

Network

OBJ

Network

OBJ

OBJ

OBJ

OBJ

DistributedStorage

Figure 4.2: Overall target model of non-volatile data in IaaS environments.

Block and object storage are managed through a front-end cloud management layerconnected to a back-end cloud management (CM) service on each node involved in pro-visioning of persistent storage. The user ordinarily interacts with such managementlayers through a command-line interface (CLI) or a graphical user-interface over a net-work such as the Internet. Furthermore, data is transferred between compute nodes andstorage nodes over such a network. In addition to the cloud user, there is typically acloud administrator acting on behalf of the cloud service provider.

1Not an implicit part of the CORAS risk analysis


Figure 4.2 indicates the system structure and the physical separation of hosts typicallyinvolved in usage and provisioning of persistent storage. It is important to point outthat a compute node and a storage node may be the same host2. Despite having sev-eral services running on the same host, the same network-based protocols are used tocommunicate with the exception that the data is not leaving the host3.

4.1.2 Step 2 - Scope of Analysis

With respect to the purpose of this thesis, the main focus of this risk analysis is to deter-mine the most important risks to security of sensitive data in a public IaaS-environment.Furthermore, it is in scope to identify treatments to such risks, to possibly enable de-ployment of systems handling sensitive data in such environments. A primary goal ofthe treatments is to approach a similar level of data security in public IaaS-environmentsas prior to cloud migration.

Founded in the motivation in section 1.4, focus is put on securing data within thecloud infrastructure, leaving the storage node and the compute node as interesting andimportant entities in scope of the risk analysis. The client is also briefly involved, butspecific risks regarding the di↵erent access methods used by a client or a manager touse and/or manage storage are not considered in detail as such, but as a single point offailure. Thus, such access methods are evaluated assuming they are untrusted.

The virtual machine and the cloud management software are interesting due to theiraccess to user data. Thus, unwanted incidents and threat scenarios not directly a↵ectinguser data are out of scope of the analysis. The risk treatment also does not activelytry to decrease the attack surface of a virtual machine instance in control of a user, butthe consequences of successfully attacking a virtual machine are considered and brieflyevaluated.

Briefly mentioned above is the OpenStack network service, provisioning network capa-bility to virtual machine instances. Virtual networks in IaaS environments are a researchtopic itself and therefore such aspects are put outside the scope. Virtual networks havean important role in provisioning of object storage, as any object write and object readfrom a virtual machine is passed through the node providing the virtual network.

Due to the complex nature of distributed storage used for object storage, only storageend-points presenting objects to users or virtual machines are considered in this riskanalysis. Such nodes are from here and on called storage nodes, despite that the physicalstorage is distributed on several nodes.

Figure 4.3 shows a more fine-grained declaration of the scope, together with connectionconstraints between parts of the systems (e.g. cloud management services are onlyintended to be accessed through a specified application-layer interface). This applies toboth service-to-service and service-to-client communication, and all requests are subjectof proper authorization prior to execution. The gray lines in figure 4.3 show paths ofmanagement data, and the black lines shows typical paths of user data.

2Conversely, the di↵erent sub-services of a service may be run on separate hosts.3Internal loop-back communication within the host may depend on operating system and software.


Remote access

Command-lineinterface

Webbrowser

Dashboardservice

API

Client

BlockStorageService

ObjectStorageService

ComputeService

API API

DistributedStorageService

User VM Hard-drive

Hard-drive

DistributedStorageService

Hard-drive

Sco

pe

Sco

pe

External access of Object Storage is possible but not considered in thisanalysis

Figure 4.3: Scope of analysis and physical classification of cloud services.

4.1.3 Step 3 - Defining Target of Analysis

Hardware virtualization is one of the most important technologies in the computenode/end-point in figure 4.2. The hypervisor/emulator presents the network-attachedstorage to the virtual machine, which means that an attached block storage volume orretrieved object storage data also is accessible within the compute node.

A disk is physically attached to the storage node and provisioned as block storage. Al-ternatively, the storage node hosts an object proxy connected to a distributed networkof storage resource nodes where object containers reside. A block storage volume isprovisioned over a network using any network-carried storage protocol4, and an objectstorage container is provisioned as a push-pull entity, often accessible through HTTP.In OpenStack, a hard-drive resource intended to hold a block storage volume is virtu-alized by implementing logical volume management, introducing an abstraction layerwhich decouples a block storage volume from the physical volume. Characteristics oflogical volume management are interesting from a security point of view, as describedin section 2.2.1. Object storage containers are similar to virtual block storage volumesbut controlled by a object storage service. The compute node does seemingly not distin-guish a network-attached block storage disk from a locally attached disk, which meansthat ordinary disk transactions are either encapsulated or transformed into a protocolsuitable for passing data along a network, such as ISCSI.

Based on the above-mentioned observations, the block storage model is extended tocover the fundamental technical architecture showed in figure 4.4. Connection betweennodes are sub-divided into terms of transport- and network protocols under control ofthe operating system.

4E.g. Internet Small Computer System Interface (iSCSI), IP-based storage protocol.


Compute node Storage node

Hardware Hardware

OS OS

VM1VM0

ISCSITarget

NIC

TCP/IP LVM

NIC

TCP/IP

ISCSIInitiator

Cloud Management Services Cloud Management Services

HTTPserver

OBJ

ObjectProxy

VLANcontrol

HTTP clientDistributed

Storage

OBJOBJOBJ

Hypervisor

Accelerator

Figure 4.4: Complete target model for the risk analysis.

Sequence diagrams in figures A.3, A.1 and A.2 show communication protocols for theevents of reading block storage data, creating volumes and attaching volumes to virtualmachines. Write actions are similar to read actions, remove similar to create and detachsimilar to attach, and thus not described in separate sequence diagrams. As virtualnetworks are out of scope of this risk analysis, reading and writing objects are notdescribed with sequence diagrams.

Defining Assets and Asset Diagrams

Asset diagrams defined in the CORAS language describes entities found valuable bysome party and therefore worth protecting. Assets are classified as direct assets andindirect assets, with the corresponding symbols shown in figure 4.1:

- Direct assets - assets that directly can be harmed, such as user data which e.g. canbe impermissibly read or modified.

- Indirect assets - assets that can be harmed in case of an event that damages a directasset. For instance, reputation is an indirect asset which may be harmed by damaginga direct asset, such as the ability to provide a service.

A directed arrow from one asset to another indicates that damage to an asset mightresult in harm on another. Assets worth protecting are determined through interactionwith the customer. Identified and emphasized assets reflect the general direction andmotivation of the risk analysis.

Assets are identified and separated on behalf of various stakeholders; in this case thecloud service user and the cloud service provider. The identified assets are essentially thesame but with di↵erent interpretations. The most e↵ort is put on protecting the assetsbelonging to the cloud service user, as it is tenant security concerns mainly preventingenterprises and organizations from adopting cloud solutions [18].


Cloud Service User Assets

Increased adoption of public IaaS-solutions is one of the high-level goals, described insection 1.3, but it is dependent on user trust in the cloud service provider and the abilityto successfully prevent data breaches. Thus, the main assets are: user data, increasedusage and trust. Furthermore, increased usage is highly reliant of user e�ciency. Ad-ditionally, securing user data is highlighting the virtual machine due to the presenceof data and the cloud management software due to its central role in enforcing userseparation.

Cloudmanagement

software

Cloud ServiceUser

Userefficiency

User data

Trust inCloud Service

Provider

UserVM

IncreasedIaaS usage

Figure 4.5: Asset diagram with cloud service user/tenant as stakeholder.

The resulting asset diagram is demonstrated in figure 4.5. Harming the user virtualmachine or the cloud management software will likely harm user e�ciency. Exploitedcloud management software or leaked user data is indeed a↵ecting the trust in the cloudservice provider. However this depends on how the data is leaked, as data leakage dueto an exploited user virtual machine, accidentally made vulnerable by the user shouldreasonably not a↵ect the trust in the cloud service provider.

Cloud Service Provider Assets

From the point of view of the cloud service provider, the indirect assets are transformed;trust in the cloud service provider is an issue of reputation and increased IaaS-usagecorresponds to economic growth. Thus, the indirect assets are similar, making the riskanalysis interesting to the cloud service provider also. Identified assets to the cloudservice provider are shown in the asset diagram in figure 4.6.


Cloud ServiceProvider

User data

Cloudmanagement

software

ReputationEconomicgrowth

Figure 4.6: Asset diagram with cloud service provider as party.

High-level Risk Analysis

The results of the high-level risk analysis, presented in table A.1 in appendix A, e.g.shows that the Cloud Service Provider together with other tenants are considered assignificant threats, besides the more conventional hackers and eavesdroppers.

4.1.4 Step 4 - Target Approval

CORAS defines an incident as an unwanted event causing harm to one or several assets[35]. A risk is the severity of an incident to a single asset, were the severity of theincident is determined by the incident likelihood in combination with the consequence.

Likelihood scale

The likelihood scale classifies likelihoods using discrete steps. Depending on the natureof the risk analysis this value can be a quantitatively determined probability valuebased on statistics or measurements, or a qualitative estimation. According to researchconducted by Cloud Security Alliance, the total number of cloud computing incidents ofall types were 71 as of 2011, compared to 33 as of 2010 [20]. It is reasonable to assumethat the number of incidents has continued to increase but statistically credible figurescannot be presented, neither for the number of occurrences nor type of incidents.

Due to the uncertainty and absence of exact and current figures and the seeminglylarge discrepancy between types of incidents in [20], a self-defined qualitative scale isused to define likelihood using five steps; rare, unlikely, possible, likely and certain,demonstrated in table 4.1. The description of each likelihood is a rough estimationpartly based on the number of occurrences stated by the Cloud Security Alliance.


Likelihood Description

Certain Incident occurs frequently and monthly

Likely Incident occurs several times during a year

Possible Incident occurs occasionally every year

Unlikely Incident occurs a few times over many years

Rare Incident occurs a single time over many years

Table 4.1: Estimated scale of likelihoods.

Asset Importance

Defining importance of each asset aims to create a decision support when determiningwhich risks are of most importance to treat and which risks that may have to be accepted.Asset importance is defined between 1 (minor importance) and 5 (major importance)where the highest importance indicates that the asset must be protected5, and the lowestimportance indicates that the potential risk of harm to the asset may be accepted. Thediscrepancy of asset importance between the cloud service user and the cloud serviceprovider implicates need of two di↵erent definitions of asset importances. Importancevalues are estimated in context of the analysis, and are presented in table 4.2 and 4.3.

Asset Importance Type

User data 5 Direct asset

Cloud Management Software 2 Direct asset

Trust in Cloud Service Provider 3 Indirect asset

Increased IaaS usage 2 Indirect asset

User VM 4 Direct asset

User e�ciency 4 Indirect asset

Table 4.2: Asset table of cloud service user/tenant.

5Protection costs are considered later


Asset Importance Type

User data 3 Direct asset

Cloud Management Software 3 Direct asset

Reputation 4 Indirect asset

Economic growth 4 Indirect asset

Table 4.3: Asset table of cloud service provider.

Consequences

Each direct asset is associated with a consequence scale defining the severity of harmto the asset. Similar assets can have the same consequence scale, and combined withthe likelihood scale, the risk can be estimated. The specific properties of each identifieddirect asset in this risk analysis justifies the requirement of having individual consequencetables. Estimated consequences are identified and presented for each direct asset intables 4.4, 4.5 and 4.6.

Consequence Description

Severe Data publicly disclosed

Major Data disclosed to other tenant

Moderate Data integrity compromised

Minor Data accessed by cloud service provider

Insignificant Data confidentiality or integrity not compromised

Table 4.4: Consequence scale of asset user data.


Severe Persistent and invisible compromise of cloud management soft-ware enabling illegal access to user data

Major One-time compromise of cloud management software

Moderate Vulnerabilities in cloud management software

Minor Reconnaissance of cloud management software

Insignificant No e↵ect on cloud management software

Table 4.5: Consequence scale of asset cloud management software.

4.2. RISK ASSESSMENT 31


Severe Rootkit or similar for sustained illegal access to user VM

Major One-time exploit of vulnerability in user VM

Moderate Vulnerable software in user VM

Minor Reconnaissance of user VM

Insignificant No risk of illegal access to user VM

Table 4.6: Consequence scale of asset user VM.

Risk Evaluation Criteria

In this risk analysis, risks are simply classified as not acceptable, desired to investigatefurther and acceptable. The initial straight-forward classification is to split the riskevaluation matrix diagonally and accept all risks in the upper-left part (green) of thematrix. The risks located below the diagonal should be investigated further (yellow).Furthermore, all risks with severe consequence or certain likelihood are determined tobe unacceptable (red). In addition, focus is decided to be put on major-possible, major-likely and moderate-likely, as those are decided important to treat. The risk evaluationcriteria is shown in figure 4.7.

Insignificant Minor Moderate Major Severe

Rare

Unlikely

Possible

Likely

Certain

Figure 4.7: Risk evaluation criteria.

4.2 Risk Assessment

This section describes the results of the risk assessment phase of the CORAS risk analysisusing CORAS threat diagrams.

4.2.1 Step 5 - Risk Identification and IaaS Security Concerns

To identify threat scenarios and unwanted incidents, a set of initial threat diagramsare used. In figure A.5 in appendix A, deliberate threat scenarios are shown, e.g. ahacker/burglar might exploit vulnerable software in a virtual machine to illegally ac-cess a virtual machine, possibly resulting in compromised VM security. Furthermore,accidental threat scenarios are shown in figure A.6, e.g. a tenant/user may have an im-properly configured virtual machine which is exploited by a hacker to illegally access the


virtual machine, potentially leading to compromised confidentiality of data. The finalthreat diagram in figure A.7 in appendix A is derived from the initial threat diagramsand present a threat picture.

Infrastructure Cloud Security Concerns

Storing and using data in cloud environments is facing some new and interesting issues,di↵erent from the inevitable consequences of making data available over a network. Onecausative factor resulting in issues regarding secure storage of data is the separationbetween owning data and storing data; the cloud consumer owns data but the cloudprovider stores data [39, 22]. Another important factor is the sharing of resources;di↵erent cloud consumers are intentionally sharing computational resources and storageresources in a multi-tenant model.

It is widely known that data being sent over network is a feasible subject to eavesdrop-ping, and today there exist several mature solutions and mechanisms protecting dataduring transfer. When it comes to data at rest, cryptographic techniques has been showncapable of protecting data. However, it is not as directly adoptable in cloud computingwhen owning data does not implicate storing data [39]. A cloud is a complex archi-tecture and cryptographic techniques can be introduced at di↵erent levels in the cloudcomputing stack, resulting in varying security properties. Understanding the underlyingthreats is an important step in deciding how a mechanism to protect non-volatile datais to be designed.

Resource sharing in combination with the distributed nature of a cloud environmentsmakes it reasonable to divide protection of data into two di↵erent categories; externaland internal protection. Internal protection aims toward protecting data from unautho-rized access by other cloud consumers but also protecting data from being impermissiblyaccessed by the cloud provider. External protection aims toward protecting data fromoutside the cloud environment, such as eavesdropping and attacks against cloud man-agement software. Imagine non-volatile data that is stored encrypted on a block storagevolume attached to a virtual machine, or non-volatile data fetched from object storage.Since the virtual machine is running on a host controlled by the cloud provider, pro-cessing plain-text data in that specific virtual machine implies that the data exist inplain-text in some memory on that certain host, thus exposed to the cloud provider.

Implications of Multi-tenancy

Resource pooling and sharing of resources are two of the key concepts in cloud computingand, as explained above, virtualization is one fundamental technology making sharing ofcomputational resources possible [13]. Thus, proper isolation between tenants is one ofthe main objectives of maintaining confidentiality and integrity. Satisfactory isolationis highly dependent on handling issues originating from underlying concepts necessaryto achieve resource pooling. Such issues involve e.g. ensured data destruction on logicalvolumes, prevention of account hijackings and hardware virtualization security.

Hardware Virtualization Security

Deploying a guest operating system upon emulated hardware does not make the oper-ating system itself more vulnerable than installing it directly on physical hardware. Infact, use of properly configured virtualization can lead to a series of security advantages[32]. For example, an organization using one single physical machine to host severaldi↵erent services may experience a security-related benefit migrating each service to a


separate virtual machine, giving each service an isolated environment [7, 3]. This mayreduce any potential damage to other services caused by one misbehaving service.

Thus, virtualization is sometimes mentioned as a security improvement due to the isola-tion [7]. Still, ensuring guest operating system isolation is mentioned as one of the moreimportant security issues using virtualization technologies. It may seem contradictory,but it emphasizes the importance of understanding the primary purpose of adoptingvirtualization in context of cloud computing; resource sharing and operational e�ciency[34].

Albeit indirectly, some of the security issues concerning virtualization technologies canpotentially be exploited in a way that may pose a threat to confidentiality and integrityof data in storage resources. Below, some of these main security issues are described,and how and why they pose a threat to secure storage of data and usage of such data.

Hardware

Hypervisor

Guest VM1(vulnerable)

Snapshot of Guest VM2

Guest VM2(victim)

Guest VM0(malicious)

RAM Data

RAM Data

Data

Figure 4.8: Potential attack vectors using virtualization technologies.

Hypervisor Security and Guest-OS Isolation

In order to successfully enforce separation, the hypervisor itself needs to be secure inorder to ensure a secure virtualization environment. Furthermore, securing the hyper-visor mainly relies on secure management and handling of the di↵erent programs thatcontrol the hypervisor [34]. Imagine a worst case scenario, where a malicious virtualmachine manages to take control over the hypervisor, a so-called escape, resulting inan environment where one malicious virtual machine is in control of the other virtualmachines [33, 3] as well as their shared resources.

So called side-channel attacks are feasible [41]: a malicious virtual machine could extracta cryptographic key from a victim virtual machine, both running on the same state-of-the-art hypervisor. Such an attack poses a serious threat to data confidentiality andintegrity, and highlights the importance and di�culty of handling keys securely.

Introduced as a complex new layer between resources and users, and furthermore as adelimiter between users, the hypervisor may be utilized as an additional attack vector,


as shown in Figure 4.8.

Snapshot Management and Migration

Snap-shotting is a powerful feature allowing to restore a suspended virtual machine intoa previous state, or migrate a virtual machine in a certain state to another host. Toachieve this functionality, all data relevant to be able to enter that state is stored in asnapshot. Depending on the snapshot content, careless handling of snapshots may posea serious indirect threat to confidentiality and integrity of sensitive data. Passwords andcryptographic keys are two examples of such sensitive data that usually resides in themain memory. Since the main memory is needed to recreate a certain state, passwordsand keys might be stored in the snapshot [34]. If this is the case, a stolen snapshotimplies stolen cryptographic keys and protection of data is compromised. Thus, thesnapshot feature might be exploited as one more attack vector.

Data residing in persistent storage may also temporarily be loaded into the main memoryfor processing. If stored in a snapshot that is handled improperly, a data breach mayoccur. By tampering with snapshot data, it may also be possible to invoke maliciousbehavior that may lead to a data breach.

Data Remanence and Ensured Data Destruction

Storing data in a storage resource controlled by a cloud storage provider implies thatthe data can be backed up, migrated and replicated by the provider, without the cloudconsumer even noticing. Since cloud computing comes with several expectations onscalability and availability, it is likely and desirable that data are migrated or copiedfrom one disk to another [30]. But moving data around requires data to be activelydestroyed on every disk where it has resided [13]. If not, a cloud consumer might beprovisioned a logical volume mapped to the same hard-drive blocks where data belongingto another cloud consumer used to reside. Thus, complete destruction of sensitive dataupon request should be as important and obvious as ensuring that accidentally lost datacan be recovered.

The destruction issue can be solved by introducing procedures for erasing data, andsome cloud providers mention in their service descriptions that they are adopting suchprocedures. However, new issues are introduced as irreversibly wiping out data can bea quite resource demanding task [37]. Furthermore, as usual when security concernsshould be handled by the cloud provider, the data destruction ensuring issue reformsinto a trust issue; does the cloud provider erase the data irreversibly?

Assuming infallible key management, use of encryption overcomes the risk of databreaches since no data is stored in clear-text on disks. Destroying data is ensuredby destroying the key and making it unrecoverable, which in turn makes the data un-recoverable. Still, data destruction can be implemented to improve security even moresince data still may be recovered in case the key was not destroyed properly.

Trust in Cloud Service Providers

Since the cloud provider typically has unlimited privilege in the system, it can monitorall information it wants to. In the same way, every single bit stored using a storageresource belonging to a cloud storage provider can be read by the provider. If thecloud storage provider is not the same as the cloud provider, this issue can be solved byensuring that no data enters the storage resource in plain text, but it does not eliminatethe need of trusting the cloud provider.


Several of the previously described issues in this section are issues which needs to beaddressed by the cloud provider to e.g. provide a secure virtualization environment.Furthermore, every single issue stated to be addressed by the cloud provider becomesan issue of trust; do you trust that the cloud provider addresses the issue in a satisfactoryway? So, trust is shown to play an important role in cloud security in general.

Account Hijacking

Account hijacking is a problem not merely related to cloud computing and the risk ofaccount hijacking is always present using any type of credentials as authentication andauthorization for access to resources in a network. According to NIST, account hijackingin context of cloud computing is mentioned as the third top security issue with increasingrelevance [2]. NIST also mention stolen account credentials as a potential root causeto compromised confidentiality and integrity, since information bounded to a certainaccount might be used to access data belonging to another cloud consumer.

Dealing with the risk of account hijacking is a challenging problem and user accounts isa natural way of achieving separation between cloud consumers. The risk and potentialoutcome of an account hijacking is important to be aware of, and one way to decreasethe risk of account hijackings is to implement a two-factor or multi-factor authenticationsystem.

Legal Issues

Due to the distributed nature of a computer cloud, moving data within a cloud may verywell imply moving data between countries and geographical jurisdictions. Data that issubject to di↵erent laws and regulations may be problematic. For example, according tothe Crypto Law Survey started by Bert-Jaap Koops [21], there are a number of countrieswhere use of encryption is prohibited by law. The prohibition of using cryptographictechniques is not a security issue itself but it inhibits the use of cloud computing as aconcept to some extent, as it forces a cloud provider to avoid expansion into certainjurisdictions. It can also be a problem for a cloud consumer, since protecting data usingcryptographic techniques on a cloud provider in such countries are only possible if cloudconsumers violates the law.

4.2.2 Step 6 - Risk Level Estimation

The risk levels have been determined by estimating the likelihood of the di↵erent threatscenarios. Likelihoods of more general threat scenarios such as illegal read/write accessto user data has been derived from likelihoods of preceding specific threat scenarios. Fur-thermore, the likelihood of the unwanted incidents have been derived from the causativethreat scenarios. Finally the consequences to each of the direct assets have been esti-mated. The estimation of likelihoods and consequences are presented in the final threatdiagram in figure A.7 in appendix A.

Finally, the risk diagram in figure A.8 in appendix A shows the identified risks, whocauses the risk and which asset the risk might harm. For example, a cloud serviceprovider and/or a tenant may accidentally cause the risk of a vulnerable virtual machine(VVM), potentially causing harm to the asset user VM. Additionally, figure A.4 inappendix A shows how the indirect risks are derived from the direct risks, e.g. decreasedtrust in cloud service provider may be caused by harm to user data [D-TR(I)] or cloudmanagement software [C-TR(I)].


4.2.3 Step 7 - Risk Evaluation

Risks are classified as they are placed in the risk evaluation criteria, demonstrated infigure 4.9. Risks to direct assets are presented in table 4.7 and risks to indirect assets arepresented in table 4.8. The risk evaluation identifies four non-acceptable risks relatedto direct assets; ECM, VVM, CDC and EVM. By revisiting the importance table of thecloud service user, one can conclude that the importance of treating CDC is emphasizedby the high importance of the asset user data. The two risks regarding the user virtualmachine are also highlighted due to the relatively high importance of the accordingasset.


Rare

Unlikely D-UE(I)

Possible CDA CDI, VCM, V-UE(I), C-UE(I), C-IU(I)

ECM EVM

CDC

Likely VVM

C-TR(I)

D-IU(I) D-TR(I)

Certain

Figure 4.9: Risk classification using the risk evaluation criteria.

Identifier Description Consequence Likelihood

VVM Vulnerable user virtual machine Moderate Likely

EVM Exploited user virtual machine Severe Possible

CDC Compromised data confidentiality Severe Possible

CDI Compromised data integrity Moderate Possible

CDA Compromised data availability Insignificant Possible

VCM Vulnerable cloud management software Moderate Possible

ECM Exploited cloud management software Major Possible

Table 4.7: Risks to direct assets.

Additionally, there are three risks regarding indirect assets also not acceptable, all tosome extent related to confidentiality of user data; C-TR(I), D-TR(I) and D-UI(I). The

4.3. RISK TREATMENT 37


V-UE(I) Harmed user e�ciency due to compromised orvulnerable user virtual machine

Moderate Possible

D-UE(I) Harmed user e�ciency due to compromised con-fidentiality, integrity or availability of user data

Major Unlikely

C-UE(I) Harmed user e�ciency due to compromised orvulnerable cloud management software

Moderate Possible

D-TR(I) Harmed trust in cloud provider due to compro-mised confidentiality, integrity or availability ofuser data

Severe Likely

C-TR(I) Harmed trust in cloud provider due to compro-mised or vulnerable cloud management software

Moderate Likely

D-IU(I) Decreased IaaS usage due to decreased trust incloud provider or user e�ciency as a result ofcompromised CIA of user data

Major Likely

C-IU(I) Decreased IaaS usage due to decreased trust incloud provider or user e�ciency as a result ofcompromised or vulnerable CM software

Moderate Possible

Table 4.8: Risks to indirect assets.

main reason to the high risk of compromised virtual machines or cloud managementsoftware is the which means possible unwanted events related to user data. The risksrelated to indirect assets follows directly from the risks to the direct assets, which meansthat mitigation of direct risks is mitigating indirect risks in the context of this riskanalysis. By considering the asset importance table to evaluate the indirect risks, usere�ciency is decided most important followed by trust, highlighting all the identifiedindirect risks further.

4.3 Risk Treatment

A risk is treated by reducing the likelihood and/or the consequence. The proposed risktreating concepts in this project is mainly decreasing the likelihood of the various threatscenarios and thus the likelihood of the incidents resulting from the threat scenarios.Due to the non-quantitative nature of the consequences defined during the context es-tablishment, it is di�cult to reduce the consequence level of certain incidents. The risktreatment is divided into identifying risk treatment concepts and an extended targetedcomparison in chapter 5.

4.3.1 Step 8 - Risk Treating Concepts

The concepts identified to treat non-acceptable risks are shown in figure A.9 in appendixA, e.g. encryption is used to mitigate the risk of compromised data confidentiality.Figure A.10 in appendix A shows risk treatment in further detail. Below, identifiedconcepts able to mitigate the non-acceptable risks are categorized and briefly described


in terms of benefits, costs and how associated risks are treated, i.e. reduced likelihoodor consequence.

Securing Virtual Machines

The conducted risk analysis reveals that the existence of vulnerabilities in a virtualmachine, potentially causing exploitation of such a virtual machine, is crucial when itcomes to security of data. Meanwhile, it is reasonable to consider such risks amongst thehardest and most expensive to overcome, because cloud consumers typically must be in-volved (discussed further in chapter 7). Preventing misconfiguration of virtual machinesoftware or installation of any vulnerable program, while maintaining user freedom, isvery dependent on the cloud consumer. Direct treatment to such risks is to educatecloud consumers and emphasize the importance of updated and secure software. En-suring proper security-measurements of network-attached and publicly available virtualmachines is likely to mitigate the risks of vulnerable and exploited virtual machines sig-nificantly, thus reducing the risk of compromised confidentiality and integrity of data.Risks are exclusively mitigated by reducing the likelihood, since a successful exploit of avirtual machine still may lead to the worst consequence as defined in the risk analysis.

Encryption

Using cryptographic techniques is an obvious course of action to treat risks to confiden-tiality and integrity of data. As mentioned in section 2, the success rate of adoptingencryption depends on the successfulness in handling encryption keys. Implementing en-cryption mitigates the severity of several threat scenarios, such as eavesdropping, stolenhard-drives and illegal access to nodes6. Adopting encryption results in an one-timeimplementation cost, related to management of keys and a minor reduction of perfor-mance. When it comes to performance, encryption can be considered quite inexpensive,due to hardware-accelerated symmetric encryption in today’s processors. Because ofthe distributed nature of an IaaS-environment, use of encryption is important to pro-tect data. The ability to mitigate related risks is based on both reduced likelihoods andconsequences. Additionally by adopting encryption, integrity issues are partly solvedsince illegal modifications to data are discovered in form of unreadable data.

Trusted Computing

Trusted computing principles can be used to attest behavior and trustworthiness of anynode through the use of a Trusted Platform Module. By verifying nodes in the cloud,vulnerable and erroneous configuration of cloud management software and virtualizationsoftware could be detected by a trusted third party. Thus, threat scenarios such as illegalaccess to compute node, illegal access to storage node and tenant-escape7 of virtualmachine instances could be reduced in likelihood and corresponding risks mitigated.The cost of ensuring trustworthiness of a node can be considered as moderate as itimplies that a verification process has to be conducted. Thus it is desirable to keep thenumber of nodes where verification is needed as small as possible. The number of nodesneeded to be trusted depends on the cloud structure and which nodes that may pose arisk if compromised.

6Depending on at which nodes data is sent or used in clear text.7Also an intruder exploiting a VM with the main goal of entering another VM on the same compute

node.


Automation

Automation is not a self-contained technology but rather one of several characteristicsto consider while treating risks. In the area of cloud storage security, minimized needfor tenant intervention can be good practice as it may ease the operation of securitymechanisms. Yet it might be hard to balance automation as tenants may questiontheir degree of security using a totally automated protection mechanism. Therefore,verifiability is important in a automated security solution. The cost of automation isdirectly related to the cost of implementing the protection solution and the additionallyrequired verification mechanism.

Verifiability

Verifiability aims towards stating beyond reasonable doubt that the functionality andcapability of performing a certain action. In enterprise usage of systems or other usewhere security is particularly important, verifiability is a desired property as this helpsusers to maintain trust in a protection solution and a system in its entirety. The costof verifiability depends on how the security mechanism is implemented.

40

Chapter 5

Non-volatile Data Protectionin IaaS-environments

Section 4.3.1 briefly describes concepts necessary and useful to design mechanisms in-tended to protect non-volatile data in IaaS-environments, and thus to mitigate thenon-acceptable risks. A straightforward approach is to implement the above mentionedconcepts and technologies straight o↵; encrypting hard-drives, attesting and verifyingevery single host in the infrastructure cloud and finally educate cloud consumers insecurity-awareness, justifying the assumption that their virtual machine instances willbe secure. As securing virtual machines is out of scope of the protection mechanism tobe proposed, only the consequences of lost data confidentiality due to a compromisedvirtual machine is just briefly considered in combination with how di↵erent solutionsare able to mitigate such consequences. The above-mentioned straight-forward approachleaves a variety of questions: Where should the encryption be performed? Is attestationof every node required? In case a tenant fails to keep its virtual machines secure, whatare the consequences? This chapter aims to investigate such questions, with respect tothe results of the risk analysis in chapter 4.

The main di↵erence between the below proposed security architectures, and the startingpoint of the comparison, is where cryptographic operations on data is performed in theinfrastructure cloud stack: on the storage host, on the compute host or inside thevirtual machine. Thus, the di↵erent architectures are called storage host encryption(SHE), compute host encryption (CHE) or virtual machine encryption (VME). Wherethe encryption is performed has shown to influence the aspects of trust requirements,consequences in the event of compromised hosts, key management issues as well asaspects related to operation and usage of infrastructure clouds.

The below proposed approaches are evaluated with respect to their ability to treat thenon-acceptable direct and indirect risks. To make the comparison perspicuous, the non-acceptable direct and indirect risks are grouped into five di↵erent groups according tosimilarities. The groups are related to the risk treating concepts discussed in section4.3.1.

• Data confidentiality - ensuring data confidentiality is mentioned as a high priorityobjective, and is achieved by treating CDC, implicitly treating the indirect risk ofdecreased trust in the cloud service provider due to harm to user data D-TR(I).Data confidentiality is achieved by encryption.

• Key management - closely related and important to data confidentiality [CDC,

5.1. STORAGE HOST ENCRYPTION 41

D-TR(I)]. Key management also plays an important role in treating the risksof vulnerable and exploited virtual machines (EVM, VVM), as keys are accessibleinside the virtual machine if the encryption is performed inside the virtual machine.

• Trust requirements - trusted computing principles are used to treat the risk ofvulnerabilities in cloud management software and thus ECM. Furthermore, thelikelihood of illegal non-physical access to the compute or storage host is decreased,thus reducing the likelihood of CDC. Implicitly, the indirect risks of decreased trustin cloud provider due to exploited cloud management software and harm to userdata are treated [C-TR(I), D-TR(I)].

• Performance - to promote increased use of cloud computing D-IU(I), performanceaspects are considered.

• Automation - by not involving the user in management of security-critical mech-anisms, user e�ciency is retained D-IU(I). Furthermore, automation may easetreating CDC in case of users without security-awareness.

The following approaches to protection of non-volatile data di↵er in their overall archi-tecture, and placement of risk treating concepts and to which degree such concepts areadopted. The protocol of trusted key distribution and authorization follows the proto-type of the Domain-Based Storage Protection protocol invented by Ericsson Researchand SICS [29]. The protocol is decoupled from the architecture and is described infurther detail in the implementation description in chapter 6.

5.1 Storage Host Encryption

Encrypting data on the storage host in the case of block storage is reasonably performedby encrypting a logical volume belonging to a certain tenant. In the case of objectstorage, an object is reasonably encrypted on the fly as it is pulled from, or pushed tothe object proxy. Thereafter, the data accessed by connecting to the storage node is inclear text as demonstrated in figure 5.1 (E=cryptographic operations, K=cryptographickey).

• Data confidentiality - data is transferred in clear text inside the storage node, be-tween the storage node and the compute node, inside the compute node and insidethe virtual machine. As data is transferred between nodes in clear text, separatetransfer encryption is needed1. CDC due to stolen hard-drives is significantly low-ered as data is stored encrypted, but as keys are used on the same host the riskstill exist. Within a distributed storage holding objects, data is encrypted.

• Key management - keys and cipher-text data are stored together on the same hostmaking it more sensitive to intruders. For instance, if one accesses the storage hostphysically during burglary to steal hard-drives containing block storage volumes,the key(s) to each hard-drive in the same host is also there. However, in the caseof object storage, the data is stored in a distributed network.

• Trust requirements - as the storage host is responsible for holding keys and encryptdata it is required to be attested to mitigate the risk of intrusion or compromisedcloud management software. Since the data is entering the compute node in cleartext, the compute node also need to be attested. Furthermore to ensure properprotection of data in transfer, both involved end-points need to be trusted.

1Preferably solved through use of TLS or IPSec, optional but implemented in IPv6 [17]

5.2. COMPUTE HOST ENCRYPTION 42


Hardware Hardware

OS OS

VM1

DATA

VM0

****

ISCSITarget

NIC

TCP/IP LVM

****

NIC

TCP/IP

ISCSIInitiator

DATA


HTTPserver

OBJ

ObjectProxy

VLANcontrol


Storage

OBJOBJ*****

Hypervisor

Accelerator

E

K

E

K

Figure 5.1: Target model with data encryption and decryption on the storage host.

• Performance - depends on the infrastructure cloud structure and the relation ofnumber of storage hosts to number of compute hosts. An infrastructure cloud islikely to consist of a larger number of compute hosts using a smaller number ofstorage hosts resulting in a possible performance bottleneck.

• Automation - possible to obtain a high level of automation as encryption is per-formed without involvement of the tenant.

5.2 Compute Host Encryption

Encrypting and decrypting data on the compute host but outside of the virtual machineis performed by encrypting and decrypting data on its way to the network-attachedstorage host2, thus presenting data in clear text to the virtual machine as demonstratedin figure 5.2 (E=cryptographic operations, K=cryptographic key). Encryption can forexample be integrated with the hypervisor or controlled separately by a detached process.

• Data confidentiality - data is transferred in clear text inside the compute host andinside the virtual machine, but outside the compute host it is in cipher-text. Asdata is sent over network in cipher-text, no separate transfer encryption is needed.

• Key management - keys and cipher-text data are stored separately as data is storedon the storage host and the key(s) is used on the compute host. Thus a stolenstorage host or a storage host subject of intrusion does likely not disclose any data.

• Trust requirements - encryption and decryption is performed on the compute host,thus this host is required to be attested and trustworthy. The compute host isalso the only host able to hold data in clear text. As the storage host neither

2As HTTP is used, data on its way to a object storage resource must be filtered.

5.3. INTRA-VM ENCRYPTION 43


Hardware Hardware

OS OS

VM1

DATA

VM0

****

ISCSITarget

NIC

TCP/IP LVM

****

NIC

TCP/IP

ISCSIInitiator

DATA


HTTPserver

OBJ

ObjectProxy

VLANcontrol


Storage

OBJOBJ*****

Hypervisor

Accelerator

E

K

E

K

*****

Figure 5.2: Target model with data encryption and decryption on the compute host.

handles data in clear text nor keys, it is not required to be attested to ensureconfidentiality3.

• Performance - performance aspects of compute host encryption need further ex-planation. The same reasoning as for storage host encryption performance holds,but as encryption consume CPU-resources it is important to schedule CPU-usageof encryption to a specific tenant, or at least charge for the increased CPU-usage.If one tenant on a compute host is using encryption and others do not, it is unfairif shared CPU-resources are used. Although with today’s processors, the amountof CPU resources consumed is typically reasonably small.

• Automation - possible to obtain a high level of automation as encryption is per-formed without involvement of the tenant.

An additional major benefit with compute host encryption is that storage from anothercloud storage provider, for instance Amazon EBS or Amazon S3, can be used and benefitfrom the same storage protection mechanism.

5.3 Intra-VM Encryption

Encrypting and decrypting data inside the virtual machine is performed either by trans-parently providing such a feature or leave it to the tenant.

• Data confidentiality - data is encrypted and decrypted inside the virtual machine,which uses computational resources of the compute host. As compute host re-sources are used, data is consequently visible to the compute host. Thus, encrypt-ing and decrypting data inside the virtual machine does not lead to minimized

3If compromised availability should have been in focus, the storage host should have needed to betrusted

5.3. INTRA-VM ENCRYPTION 44


Hardware Hardware

OS OS

VM1

DATA

VM0

****

ISCSITarget

NIC

TCP/IP LVM

****

NIC

TCP/IP

ISCSIInitiator

DATA


HTTPserver

OBJ

ObjectProxy

VLANcontrol


Storage

OBJOBJ*****

Hypervisor

Accelerator

E

K

E

K

*****

Figure 5.3: Target model with data encryption and decryption inside the virtualmachine on the compute host.

exposure of data compared to encrypting and decrypting data on the computehost. Other characteristics is the same as while encrypting and decrypting dataon the compute host.

• Key management - keys are probably stored in the virtual machine making thewhole solution sensitive to a vulnerable and exploited virtual machine. Withrespect to the conducted risk analysis this is a major drawback since the virtualmachine is more likely to be vulnerable than the compute host and the storagehost. The reason for the high severity of leaked keys even if data in the meantimeis disclosed is that keys might be used later to decrypt data by exploiting othervulnerabilities at other locations in the cloud computing stack, even if the initialvulnerability in the virtual machine is fixed. As a major reason for using blockstorage is high performance and multiple readers, it is reasonable to assume thatkeys must be widely distributed, potentially leading to decreased security.

• Trust requirements - the compute host is required to be attested and trustworthyas the data and the keys always are present on the compute host. Furthermore,the trust requirements are the same as the requirements when encrypting anddecrypting on the compute host. If a cryptographic key is leaked from a virtualmachine, the need for trust in the storage host is emphasized, since leaked or stolenkeys in combination with a vulnerable storage host may lead to compromised dataconfidentiality.

• Performance - from a performance point of view, encryption inside the virtualmachine is more fair since the virtual computational resources provisioned to aspecific tenant is used.

• Automation - relies on a specific implementation; if encryption features are pro-vided as virtual hardware or pre-configured while launching a virtual machine, theautomation is similar to the previous approaches but visible to the tenant. If the

5.4. CHOICE OF DATA PROTECTION ARCHITECTURE 45

tenant is responsible for encrypting data, automatic encryption and decryptiondoes obviously not exist.

Additionally, as keys are stored in the virtual machine, it is reasonable to assume thatkeys also are stored in any snapshot taken from such a virtual machine. This fact em-phasizes the importance of secure handling of snapshots, either by encrypting snapshots,or adding trust requirements on any host handling such. Regardless, snapshots must beencrypted during transfer.

5.4 Choice of Data Protection Architecture

Based on the above mentioned observations of the di↵erent storage protection architec-tures (SHE, CHE and VME), performing encryption and decryption on the computehost (CHE) is decided as the most advantageous solution with respect to the treatmentcost estimations and risk level estimations in chapter 4, and by the motivation andproblem description in chapter 1.3, with the following elaborated motivation:

• Data confidentiality is required, and the path of clear-text data is ideally as shortas possible. CHE and VME are considered most and equally suited accordingto reasoning in section 5.3. In addition, encrypted transfer between nodes is arequirement to mitigate the risk of the highly probable eavesdropping threat sce-nario, where CHE and VME automatically entails protected transfer of data. Byalways having data in cipher-text on the storage host, the consequence of the threatscenario of illegal access to storage host is drastically lowered (CHE or VME). Thevirtual machine is considered most likely to be subject to an attack (CHE), butas data inevitably is used in clear-text inside the virtual machine, focus is puton minimizing the path of clear-text data. To conclude, above reasoning justifiesencryption inside virtual machine (VME) or on compute host (CHE) as the bestsuited approaches, and practically equivalent when it comes to data confidentiality.

• Keys are desired to be stored separate from the cipher-text data (CHE), as mo-tivated in section 5.1. Furthermore, it is desired and important to minimize theexposure of the keys by handling them outside a virtual machine, as the virtualmachine likely is more vulnerable than the compute host or storage host (CHE orSHE), potentially making a key leakage result in a long-term compromise of dataconfidentiality. To conclude, encryption on the compute host (CHE) is most suit-able due to full separation of keys, stored cipher-text data, and virtual machines.Secondly most suited is encryption on the storage host (SHE), due to separationfrom the virtual machine.

• Trust in a specific host is following attestation of that host and the limitations oftrusted computing must be considered. Due to such limitations and absence ofguarantee that a vulnerable software under no circumstance can pass the integritychecks, it is reasonable to keep the software base as small as possible. To minimizethe software base, CHE or VME is the best approaches, as only the compute hostmust be attested, which nevertheless is required. Attestation and integrity checksare reducing the likelihood of vulnerabilities in cloud management software andother software on the attested hosts, reducing the likelihood of the threat scenariosconcerning illegal access to any host. However, performing encryption inside thevirtual machine entails requirements on trust in case of key leakage, covering the

5.4. CHOICE OF DATA PROTECTION ARCHITECTURE 46

storage host and any host involved in snapshot and image management. Thus, thebest solution with minimal need of trust is encryption on the compute host (CHE)where only the compute host must be trusted. The second most appropriateapproach is storage host encryption (SHE), where the compute and storage hostmust be trusted. The least appropriate approach is encryption inside the virtualmachine (VME) as even more hosts probably need to be attested.

Risk treatment 1 (best) 2 3

Data confidentialityCDC, D-TR(I)

CHE, VME SHE

Key managementCDC, VVM, EVM, D-TR(I)

CHE SHE VME

Trust requirementsECM, CDC, C-TR(I), D-TR(I)

CHE SHE VME

PerformanceD-IU(I)

SHE VME CHE

TransparencyCDC, D-IU(I)

CHE, SHE VME

Table 5.1: Concluding advantages and disadvantages of di↵erent solutions.

• Performance and usage of computational resources are of importance as tenantsuse a pay-per-use model. The most fair approach is reasonably that encryptionis performed on the storage host (SHE), possibly to a slightly increased cost-per-gigabyte. The second most fair approach is that a tenant using CPU-resources toencrypt data use its provisioned computational resources as in the case of encryp-tion and decryption performed inside the virtual machine (VME). It is importantto mention that this performance discussion focuses on fairness. When focusing onthroughput, it highly depends on the constellation of hosts in the cloud to avoidintroducing a bottleneck.

• Automation is desired in this protection solution for user e�ciency and increasedsecurity according to the motivation in section 4.3.1. Both SHE and CHE do notrequire involvement of the cloud consumer in their operations, thus leaving thecompute host (CHE) or the storage host (SHE) as the best suited hosts to performencryption and decryption. It is important to mention that user involvement andcontrol of the protection solution might be desired in some cases.

Table 5.1 shows how the choice of host where encryption is to be performed, is impactingthe ability to treat the di↵erent risks. This qualitative reasoning justifies the choice ofimplementing the protection mechanism architecture according to the compute hostencryption proposal.

47

Chapter 6

Implementing Block StorageProtection in OpenStack

This chapter describes the fundamental design choices and the overall architecture ofthe implementation of Domain-Based Storage Protocol [29] on the compute host. Thus,according to the motivation in chapter 5, encryption is performed on the compute hostfollowing attestation, substantiating the assumptions of a trustworthy host. All de-tails regarding key management and protocol are interpreted from [29] to fit into anOpenStack environment.

The original description and definition of the protocol is presented in [29] and brieflysummarized in section 2.6.1. In [29] there are two separate events; first time datareads/writes and subsequent data reads/writes, and the so called Secure Component(SC) is the controlling entity responsible for enforcing the protocol. Due to the theo-retical and context free nature of the protocol, various assumptions are made for thisthesis:

• The protocol is proposing to place the Secure Component in the administrativeDom0 using the baremetal Xen hypervisor. As the test-bed is using a hostedvirtualization environment running KVM/QEMU, no such administrative domainis present. Thus, the assumption is made that the Secure Component is completelyseparated from any tenant.

• The protocol use the theoretical domain entity to separate access rights to data. Asno such entity exist in the OpenStack environment, a domain is assumed to consistof a single volume, thus having one key for each encrypted volume. Implicitly,metadata used to derive keys are stored in the beginning of each volume beforethe encrypted data. However, it is expected that the theoretical domain conceptis meant to be instantiated in a practical implementation.

• The event of first time data write/read is mapped to the first time attach of avolume in OpenStack1. Accordingly, the event of subsequent data write/read ismapped to subsequent attach of a volume.

1The reason for not mapping the first time data read/write to the creation of a volume is thatcreation is invoked and controlled by Cinder running on the untrusted storage host.

6.1. IMPLEMENTATION DESIGN CHOICES 48

6.1 Implementation Design Choices

Figure 6.1 shows the overall architecture of the implementation; added entities (or-ange) and interconnections between added and existing entities. The Secure Componentis enforcing the protocol, thus communicating with the trusted platform module, thenetwork-attached trusted third party and existing disk encryption software (DM-crypt).Furthermore, the SC reads the metadata used by the TTP to derive keys from the verybeginning of the encrypted volume. The hook is a middleware introduced to decouplethe protocol behavior from the entity that initiates a request. The architecture is de-scribed in further detail by explaining the two main design choices used; passivity andcloud platform independence.

Compute node

Hardware

OS

VM1

NIC

TCP/IP

iSCSI-initiator

VT-x

KVM

QEMU

Cloud Management Services

libvirtd

nova-api nova-cpunova-sched

TPM

SC

DM-crypt

Hook

Trusted Third Party

Attestation- and key management

software

Storage host

Figure 6.1: Overall architecture and interconnectivity between system components.

6.1.1 Passivity

The implementation strive to be as passive as possible by observing and listening tothe virtualization environment to identify when volumes are attached or detached. Thepassive behavior facilitates deployment and maintenance by reducing the need of mod-ifications to existing code involved in the usage of block storage. The implementationmakes use of an existing framework in the libvirt API which is used to trigger externalprocesses, so-called hooks, at certain events in the virtualization environment. As theprocesses are triggered by libvirt, any virtualization environment supported by libvirtshould be able to have this implementation integrated. As libvirt2 did not support hookson volume attach or volume detach, the framework was extended to support such events.

2Version 0.10.2 was used to develop this proof-of-concept prototype

6.2. ARCHITECTURE 49

6.1.2 Cloud Platform Independence

By decoupling the protocol (SC) from the initiator (Hook), the implementation is keptindependent and separated of the underlying cloud management platform. This isachieved by organizing the code in a client/server like structure, where the client con-tains the platform-specific code, and thus is the only entity needed to be modified toadopt the solution in another environment. Using libvirt, the so-called hook is acting asclient. Furthermore, this structure of the code make it possible to write a client listeningto user input, thus enabling an ordinary desktop user to have this implementation ofthe DBSP-protocol integrated.

6.2 Architecture

Further details of the hook and the Secure Component is presented in figure 6.2 (or-ange=behaviour, blue=helpers, grey=existing), also showing existing libraries, such aslibcryptsetup used to control the disk encryption software and TrouSerS to communicatewith the TPM. Furthermore, the TTP is connected to the Secure Component througha lightweight protocol in a client/server like manner. The communication between thehook and the Secure Component is implemented using BSD sockets and is following aminimal inter-process communication (IPC) protocol. A separate metadata controlleris reading and writing metadata from and to the volumes.

SCKernelcode

IPC endpoint

IPCinitiator

libcryptsetup

libvirt

DM-crypt

TrouSerS

TTP-client

Kernelcode

TPM

Nova

TTPMeta-data-controller

Hook

Secure Component

Plaintext

Ciphertext

UNIX sockets

main()daemon

Lib

virt

ho

ok

“fra

me

wo

rk”

Storagehost

User VM

Figure 6.2: Secure Component basic architecture and libraries.

The cylinders at the bottom of figure 6.2 corresponds to block devices on the com-pute host. The rightmost cylinder correspond to the original block device connectedto the compute host through iSCSI. The leftmost cylinder correspond to the virtualblock device created by the device mapper framework in Linux using the cryptographicmapping target. In absence of the Secure Component, the rightmost block device is the

6.3. COMMENTS ON PERFORMANCE 50

one connected to the virtual machine by the virtualization environment. Implement-ing disk encryption, the rightmost block device is unreadable, and thus the decryptedvirtual block device is presented to the virtual machine instead. As demonstrated infigure 6.2, the metadata is stored on the first block at the rightmost block device. Theabove mentioned behavior does not di↵er from normal disk encryption in Linux usingDM-crypt, except for the metadata on the block device3. Thus, the main invention ofthe DBSP-protocol is the key management; how keys are generated and retrieved onlyif the host can prove its trustworthiness.

Sequence diagrams explaining the procedure of attaching a volume are presented infigure B.2 and B.1.

6.2.1 Modifications to OpenStack

By interacting with libvirt the need to modify the OpenStack code is kept at minimum.For security reasons4, a check-box is added to the dashboard interface where the userselects if a volume is encrypted or not, thus also minimizing overhead in case of anunencrypted volume. Additionally, another check-box is added to trigger the first-timedata write/read behavior, i.e. write the metadata to the beginning of the volume. Suchmodifications to the dashboard also requires changes to the OpenStack API, by addingparameters to the related call chains. Modifications are introduced with focus on com-patibility with unmodified OpenStack software and retained ability to use unencryptedvolumes.

6.2.2 Requirements on Verifiability

Verifying correct operation is desirable to give confidence to the user while using trans-parent security mechanisms. In a protection solution where neither the storage host northe client software is trusted, verifiability is crucial from a security point of view. Themetadata used to derive keys are as above mentioned stored on the volume, implyingthat it can be read or modified by the storage host. As the metadata is encrypted bythe TTP, it cannot be disclosed to the storage host and any attempt of modification isdiscovered by validating the message authentication code provided with the metadata.Still, a compromised storage host may be successful in erasing the metadata. In thiscase the check-box discussed in 6.2.1 poses a crucial lifeline, detecting a conflict when avolume the user expects to be encrypted, seemingly is unencrypted. The severe securityissue is triggered if a compromised storage host erases the metadata simultaneously asthe check-box parameter is modified as it passes through the API on an untrusted host.This sequence of events can result in attachment of a volume, writing data in clear-textin belief that data indeed is encrypted. A solution to this problem is proposed in section8.3.3.

6.3 Comments on Performance

A brief performance evaluation has been conducted, with focus on determining theoverhead introduced by implementing and using this security mechanism. Figure 6.3shows timings for unlocking and locking of a volume, where the table rows correspondsto specific events, and the columns corresponds to where in the code the times aremeasured; SC or QEMU (hook). SC-UNL means that timings are from the specific

3Using LUKS, a header is present on the block device similar to DBSP but other content.4Explained in section 8

6.4. COMMENTS ON APPLICABILITY IN OPENSTACK 51

unlock-method, and SC-ACC shows accumulated time in SC. For locking, times are notsubdivided as TPM and TTP are not used. At the bottom of figure 6.3, timings arecategorized to determine how much time is spent in TPM, TTP and SC. All timings arethe average of ten measurements.

The overall conclusion is that the TPM operations are the bottleneck in this type of im-plementation, and the overhead of SC operations are negligible in comparison. Through-put of data is not considered, as it is directly related to the performance of encryptionsoftware and cryptographic accelerators, and not this specific implementation.

Figure 6.3: Additional time required for unlocking and locking of volumes introducedby this implementation of DBSP.

6.4 Comments on Applicability in OpenStack

Adopting encryption straight o↵ using any disk encryption tool is simple, leaving keymanagement as the remaining challenging problem. The problem mainly arise whenthe user is involved and the implicit involvement of OpenStack. OpenStack implementsits own databases and keeps it own states on top of and independently of the under-lying software, making modifications to OpenStack necessary to retain consistency orto enable user interaction and delivery of comprehensive status messages. The Open-Stack community project aiming towards disk encryption mentioned in section 2.6 isimplemented on OpenStack level and is thus more closely connected to the user. Byintegrating such a protection solution directly into OpenStack code, it is reasonableto assume increased exposure of vital security mechanisms as a downside, potentially

6.4. COMMENTS ON APPLICABILITY IN OPENSTACK 52

leading to compromised security of data.

Reasonably, OpenStack is modified to ease user interaction by extending the API anddatabases. Furthermore, a channel between the OpenStack databases and the protectionmechanisms is implemented. Thus, the user can retrieve detailed error messages andmaintain status information of the protection, without revealing details and behavior ofthe security mechanism to OpenStack.

53

Chapter 7

Repeated Estimation andEvaluation of Risks

This chapter presents the results of a repeated estimation of likelihoods, consequencesand derived risk levels, and furthermore a brief motivation of how the risk levels areestimated. Additionally, risks are repeatedly evaluated to provide a post-treatment riskpicture. The repeated evaluation and the resulting risk picture is used to briefly evaluatethe risk treatment of the selected choice of treatment. Shortcomings associated to theresult are discussed in chapter 8.

7.1 Repeated Risk Level Estimation

The likelihood of vulnerable software in the virtual machines has not been reduced,leaving the incident of vulnerable virtual machines and exploited virtual machines un-changed. Neither the consequence is reduced considering the consequence table 4.6.


VVM Vulnerable user virtual machine Moderate Likely

EVM Exploited user virtual machine Severe Possible

CDC Compromised data confidentiality Severe Unlikely (-1)

CDI Compromised data integrity Moderate Unlikely (-1)

CDA Compromised data availability Insignificant Unlikely (-1)

VCM Vulnerable cloud management software Moderate Unlikely (-1)

ECM Exploited cloud management software Major Rare (-2)

Table 7.1: Re-evaluated risks to direct assets.

The likelihood of the risks of vulnerable or compromised cloud management softwareare greatly reduced because of the reduced likelihoods of the causing threat scenarios(vulnerabilities/misuse of cloud management software are considered rare/unlikely in-stead of possible/possible due to integrity checks of associated software and hosts). The

7.1. REPEATED RISK LEVEL ESTIMATION 54

likelihoods of the corresponding risks are consequently estimated to unlikely (-1) forECM and rare (-2) for VCM. The consequences according to table 4.5 are not reduced.

The eavesdropping threat scenario and improper data destruction procedure threat aregreatly mitigated by adopting encryption and thus decided to be as low frequent thatthey are removed out of the threat diagram.

Since the storage host not is trusted (due to absence of integrity checks), the likelihoodof illegal access to the storage host is unchanged. However, the likelihood of illegalaccess to the trusted compute host is greatly reduced and estimated to be rare insteadof unlikely (-1), as a result of adopting Trusted Computing principles. This also holds forthe likelihood of tenant-initiated illegal VM access (rare instead of possible), since a VM-escape is determined rare on the trusted compute host. Above mentioned reduction oflikelihoods propagates as shown in A.11 and result in an overall reduction from possibleto unlikely (-1) for CDC, CDI and CDA. Consequences are not reduced, according totable 4.4.


V-UE(I) Harmed user e�ciency due to compromisedor vulnerable user virtual machine

Moderate Possible

D-UE(I) Harmed user e�ciency due to compromisedconfidentiality, integrity or availability ofuser data

Major Rare (-1)

C-UE(I) Harmed user e�ciency due to compromisedor vulnerable cloud management software

Moderate Rare (-2)

D-TR(I) Harmed trust in cloud provider due to com-promised confidentiality, integrity or avail-ability of user data

Moderate (-2) Unlikely (-2)

C-TR(I) Harmed trust in cloud provider due to com-promised or vulnerable cloud managementsoftware

Moderate Rare (-3)

D-IU(I) Decreased IaaS usage due to decreased trustin cloud provider or user e�ciency as a resultof compromised CIA of user data

Major Unlikely (-2)

C-IU(I) Decreased IaaS usage due to decreased trustin cloud provider or user e�ciency as a resultof compromised or vulnerable CM software

Moderate Rare (-2)

Table 7.2: Re-evaluated risks to indirect assets.

The complete repeated estimation of risks derived from threat scenarios is shown infigure A.11, and re-estimated risk levels for direct assets are concluded in table 7.1.

As consequences are not reduced for risks to direct assets, the consequences are alsounchanged for risks to indirect assets except for D-TR(I). It is reasonable to assumethat the risk of harmed trust in the cloud provider due to compromised confidentiality,integrity and availability of data is reduced by increasing customer confidence that the

7.2. REPEATED RISK EVALUATION 55

provider has taken precautions. Additionally, the overall reduction in likelihood a↵ectsthe likelihood of the indirect risks as presented in table 7.2.

7.2 Repeated Risk Evaluation

The re-estimated risks are evaluated using the same risk evaluation criteria as in theoriginal risk analysis. The re-evaluated risks are shown in figure 7.1.


Rare C-UE(I),

C-TR(I),

C-IU(I)

ECM,

D-UE(I)

Unlikely CDA CDI, VCM,

D-TR(I)

D-IU(I) CDC

Possible V-UE(I) EVM

Likely VVM

Certain

Figure 7.1: Re-evaluated risk classification using the risk evaluation criteria.

The conclusion from the re-evaluation of the risks is that the risks to the virtual machine(EVM, VVM) remain unchanged, as expected, since such risks are are intentionally leftout of the risk treatment. All non-acceptable indirect risks (D-IU(I), D-TR(I), C-TR(I))are limited to an acceptable level. Interesting is that the proposed solution does not treatthe risk of compromised data confidentiality (CDC) enough to dismiss it as acceptable.

The inability to successfully treat CDC is reasonably explained by the utmost impor-tance of eliminating the seemingly highly probable risk of externally initiated illegalaccess to the virtual machine. Another explanation is found in the performance of therisk analysis; as it is impossible to make CDC acceptable without reducing the conse-quence of the incident given the defined risk evaluation criteria.

General Risk Treatment

A final satisfying observation is the overall direct and indirect risk treating e↵ect, aseven a large amount of the already acceptable risks and risks desirable to investigatefurther are reduced in likelihood, resulting in an overall better risk-picture. Prior torisk treatment, both the mean and the median of direct and indirect risks were possibleand moderate. With risk treatment activities introduced, the mean risk is unlikely andmoderate, while the median risk approaches rare likelihood. Furthermore, adopting risktreatment, the median and mean risks are classified as acceptable. The general risktreatment is shown in figure 7.2. Discrete values are used in the left diagram in figure7.2 which means equal likelihood and consequence of risks in proximity to other risks.In the right diagram in figure 7.2, the relations are accurate.

7.2. REPEATED RISK EVALUATION 56

consequence

probability

consequence

Risk prior to treatment

Risk after treatment

mean - after

mean - prior

median - after

median - prior

probability

Figure 7.2: Distribution of risks before and after treatment.

57

Chapter 8

Discussion and Conclusions

This chapter briefly evaluates the method used to reach the result, i.e. the CORASanalysis. Furthermore, the result is briefly evaluated by mentioning and discussingremaining issues and revisiting the CIA-triad. The risk treatment is implicitly evaluatedas a part of the repeated risk evaluation. Finally, the entire thesis is concluded byrevisiting the aim and original problem to discuss around the contribution of this thesisand recommendations on further research and improvements of the implementation.

8.1 Evaluation of Results

Below is a brief evaluation of the most important remaining issues yet to be covered anddiscussed. All below mentioned issues are vital in maintaining data security, but due tothe limitations in scope, they are evaluated separately.

Importance of Securing Virtual Machines

The importance of VM security can not be emphasized enough. If compromised confi-dentiality is considered to cause a severe consequence, mitigating the risk to an accept-able level1 is impossible without securing the virtual machine. As virtual machines oftenare launched from snapshots or images, secure handling and storage of such are also im-portant. There is undergoing research on implementing Trusted Computing principlesin virtualization, mentioned in section 8.3.3.

Security of Middle Layer or Client Software

In this risk analysis, any middle layer software or client software is decided not tobe trusted. Such software can likely be verified using trusted computing techniques,despite not mentioned in this thesis. A trade-o↵ can be made where client software isleft untrusted and a verification mechanism is implemented to guarantee and prove thatany action is performed properly. Strict requirements on security may oblige the userto not even trust the web-browser or the front-end client, implying hard requirementson verifiability.

Implications of the Trusted Third Party

In the proposed solutions, the trusted third party introduced to handle attestation andkey management becomes an important foundation of the security architecture. Thus,

1Acceptable level using the risk evaluation criteria defined in this risk analysis

8.2. EVALUATION OF METHOD 58

failure in achieving its purpose, the trusted third party may compromise the security inwhole. By using a trusted third party it is important to ensure and evaluate the securityof the party itself. Inability to derive keys can compromise short-term availability andlost keys can severely compromise long-term availability. Furthermore, the limitationsof trusted computing and the trusted platform module should be evaluated.

Social Engineering and the Human Factor

The human factor is notoriously hard to control, and apart from insecure virtual ma-chines, account hijacking may be a serious problem in maintaining data confidentiality.Using two-factor authentication mechanisms may facilitate in reducing the risk of ac-count hijackings but at the same time worsening user experience and e�ciency. Thebalance is important, as aggravating authentication too much may result in the oppo-site, e.g. if a user starts to store passwords in a manner where they are easily accessibleto non-authorized parties. Today, a skilled social engineer is very likely to be success-ful in deceiving a user to reveal authentication details. Involving additional factorsin the authentication process, such as geolocation of data [14] and trusted computingprinciples, might help reducing the impact of human mistakes.

8.1.1 Revisiting the CIA-triad

The likelihood of compromised confidentiality, integrity and availability is estimated tohave been reduced slightly by applying the treatment concepts proposed in this thesis.The decrease is explained by decreased likelihood of the preceding threat scenarios,but it is reasonable to assume that the integrity issue is partly solved by solving theconfidentiality issue, as tampering with encrypted data is likely to be discovered. Despitebeing out of focus in this risk analysis, the availability aspect is of high importance. Thelikelihood of compromised availability due to compromised cloud management softwareis reduced by integrity checking, but it is reasonable to assume that the risk at the sametime is slightly increased, as keys are more complicated to backup and lost keys willresult in lost data.

8.2 Evaluation of Method

Below is a brief evaluation of aspects concerning the performance of the risk analysiswith respect to the results.

Failed Treatment of Confidentiality Issue

The inability to solve CDC by solely reducing the likelihood can be identified by justlooking at the risk evaluation criteria, as all severe risks are unacceptable. As theconsequence of user data is defined, it is not reasonable to relieve the consequence, asdata in the worst case scenario may end up publicly accessible, independent of what anattack may look like. The above reasoning suggests that such a risk evaluation criteria isadvantageously used in combination with a consequence scale based on time of exposureor the amount of data which is exposed. The above reasoning is also emphasized by thefact that according to the definition of consequence, one byte of data publicly availablein one second is as severe as one gigabyte of data publicly available during one year. Byintroducing time and amount (or more generally, value of data) in the consequence, it isreasonable that the discrepancy in consequence between di↵erent solutions to protectionshould add to the evaluation, disadvantageous to Intra-VM encryption, as it makes sense

8.3. CONCLUSIONS 59

to estimate the time that data is exposed to be higher if cryptographic keys are leaked,and not just the data.

Accuracy of Risk Level Estimations

According to CORAS, risks are estimated in co-operation with the customer by esti-mating likelihood and consequence [35]. If the risk analysis is conducted in context ofa certain business, it is likely that the organization initiating the risk analysis can con-tribute with statistical data, substantiating likelihoods and consequences and thus therisk levels. It is reasonable to assume that there in most cases is a discrepancy betweenactual risk and perceived risk, but as this risk analysis applies to the general conceptof block storage in IaaS cloud computing, the accuracy of such factors is dependenton qualitative reasoning and knowledge of the participants. Therefore, the accuracyof the estimated likelihoods and consequences are hard to verify, leaving the repeatedestimation of risks as an evaluation of the overall risk-treating e↵ect.

Scope Induced Result Limitations

Due to the technically limited scope of the risk analysis defined in section 4.1.2, only aportion of the original problem is covered as many aspects regarding the user, i.e. thehuman factor are left out. To present a more universal risk picture, the scope shouldideally be extended to cover access methods and user interaction with cloud managementsoftware.

Adopting CORAS in Context of Cloud Computing

CORAS is well suited for adoption in this type of context, mainly due to the consis-tent and well-defined threat modeling language. One of the major benefits of CORAS,the interaction with individuals representing a widely spread base of competence andknowledge might be hard to achieve on a technically conceptual level, as the risk analy-sis is limited to the concept of storing and using non-volatile data in IaaS-environmentsrather than a specific implementation of IaaS cloud computing by a certain organizationor enterprise.

8.3 Conclusions

In this thesis, execution of a risk analysis using CORAS has identified major threat sce-narios and risks by using and storing sensitive non-volatile data in IaaS-environments,with focus put on the compute and storage nodes. The risk of compromised confi-dentiality is highlighted by the risk analysis, thus considered most important to treat.Compromised confidentiality of data is determined to be caused by vulnerabilities in thecloud management software or vulnerabilities in the virtual machines (Q1). By adopt-ing encryption and trusted computing principles, various risks are greatly reduced. Bydi↵erent combinations of trusted computing principles and encryption, di↵erent charac-teristics of security and performance are achieved. By matching the di↵erent requestsand requirements in this project, compute-host encryption is considered well-suited (Q2,Q3). The identified risks are re-evaluated, and an overall better risk-picture is presentas a result of the re-evaluation (Q2). Yet, there are several aspects to consider, somevital to security of data, such as securing virtual machines.

In parallel, the DBSP-protocol has been successfully implemented on the compute hostin an OpenStack environment, proving the capabilities of such a security mechanism.

8.3. CONCLUSIONS 60

The implementation is fairly independent of the cloud management platform and is pas-sively implemented, listening to events in the virtualization environment. Furthermore,the possibilities to implement such a security mechanism in general and in OpenStackin particular have been briefly evaluated (Q4). To conclude the analysis, a brief exami-nation of using the CORAS method in the context of cloud computing with respect tothe result has been conducted.

Non-volatile data in distributed IaaS-environments are mainly secured by encryption ofdata in proximity to computations on data, thus minimizing exposure. At the computehost, where the physical separation of users is put out of action, data is secured by main-taining an integrity checked and secure virtualization environment, enforcing separationbetween tenants.

8.3.1 Contribution

While the IaaS service model experiences an increasing number of adopters, this thesiscontributes in highlighting the very important security issues of storing and using non-volatile data in IaaS-environments. By proposing a protection solution and providing acloud platform independent implementation of such a solution this thesis contributes tocloud storage security in general, and cloud storage security in OpenStack in particular.While proposing risk treatments, adoption of trusted computing aspects in cloud com-puting is investigated and evaluated, contributing to the growing area of applicabilityof trusted computing principles.

Leaving an implementation capable of securing block storage data even outside a cloudenvironment, for example to protect storage in a distributed enterprise network, thisthesis also contributes to security of storage in general. As an improvement to theimplementation, a verification mechanism is proposed (Token-based Verification Mecha-nism in section 8.3.3) which can guarantee proper behavior of vital aspects involving anuntrusted host. The above mentioned improvement is similar to the principle of tokeninjection discussed in [28].

Finally, this thesis contributes to the CORAS risk analysis method by providing docu-mented experience, guidelines and an evaluation of implementing the CORAS methodin context of cloud computing.

8.3.2 Recommendations

The theoretical boundaries of data introduced in [29], i.e. domains, are an importanttopic as the amount of data subject to leakage is minimized with decreasing size of adomain, allowing fine-grained control of access to data.

Additionally, at a certain point, the likelihood of a successful data breach is loweredto an acceptable level by using state-of-the-art technologies such as attestation andencryption. At such a point, the low likelihood might result in movement of focusto other type of risks. Still, the event of a leaked key can be devastating to certainenterprises, e.g. storing and handling of personal data. Thus, utmost reduction of theconsequences are important. Minimizing the amount of data encrypted using a singlekey is such a mitigating action.

Further research and development of homomorphic encryption principles is of high in-terest to cloud storage security, and facilitates in solving the risk of compromised dataconfidentiality. In combination with domain-based storage protection, homomorphic en-cryption could be used in the domains containing the most sensitive data, thus reducingthe consequence of an exploited virtual machine.

8.3. CONCLUSIONS 61

While this risk analysis uses qualitative scales defining consequence, it would be inter-esting to conduct a similar analysis in the context of an established implementation tobe able to use a quantitative scale defining consequences and likelihoods.

8.3.3 Further Improvements to the Implementation

The scope of the risk analysis and the scope of the implemented mechanism are quiteconsistent, leaving a variety of aspects yet to be covered. Here a few of them arementioned, which implemented could help increase security further.

Token-based Verification Mechanism

By providing an encrypted and signed token to the attach-call, user verification of en-cryption is enabled. The encrypted token must be created, encrypted and signed bythe user in a trustworthy way2. When the token reaches the compute host where thevolume is attached, the token is explicitly encrypted by the compute host using thevolume encryption key retrieved from the TTP. As the compute host is trustworthy, itis trusted in successfully encrypting the token and writing it to reserved blocks on theblock device. It is now possible to verify the token on the virtual block device attachedto the virtual machine; if the token is present and is unmodified, it is a proof of properencryption.

Protection Rings to Secure Keys

Keys retrieved from the TPM are temporarily present at OS user privilege level whilethey are loaded into the device mapper target to enable encryption and decryption.Attestation is substantiating the assumptions that the compute host is secure, but asa precaution, security could be increased further by only allow high privilege users tohandle cryptographic keys. There is also existing functionality making it possible topass keys directly from the TPM into the device mapper target, without revealing thekey to the user process.

Implementing Virtual TPM

Research lead by IBM is aiming towards implementing virtual trusted platform mod-ules [5] with the intention to integrity check concurrently running virtualized operatingsystems. As the IaaS service model is based on concurrency, such functions could be ofgreat value facilitating virtual machine security.

2This likely implies that the token is encrypted outside the web-browser client or command-lineclient, and entered manually to the call parameters.

62

Bibliography

[1] Tim Abels, Puneet Dhawan, and Balasubramanian Chandrasekaran. An overviewof xen virtualization. Dell Power Solutions, 8:109–111, 2005.

[2] Cloud Security Alliance. The notorious nine: Cloud computing top threats in 2013.Technical report, 2013.

[3] Fatma Bazargan, Chan Yeob Yeun, and Mohamed Jamal Zemerly. State-of-the-artof virtualization, its security threats and deployment models. International Journalfor Information Security Research (IJISR), 2(3/4), 2012.

[4] Muli Ben-Yehuda, Jon Mason, Orran Krieger, Jimi Xenidis, Leendert Van Doorn,Asit Mallick, Jun Nakajima, and Elsie Wahlig. Utilizing iommus for virtualizationin linux and xen. In Linux Symposium, 2006.

[5] Stefan Berger, Ramn Cceres, Kenneth Goldman, Ronald Perez, Reiner Sailer, andLeendert van Doorn. vtpm: Virtualizing the trusted platform module. USENIXAssociation, (15), 2006.

[6] Markus Bohm, Stefanie Leimeister, Cristoph Riedl, and Helmut Krcmar. Cloudcomputing and computing evolution. Technische Universitat Munchen (TUM),Germany, 2010.

[7] Mariana Carroll, Alta Van Der Merwe, and Paula Kotze. Secure cloud computing:Benefits, risks and controls. In Information Security South Africa (ISSA), 2011,pages 1–9. IEEE, 2011.

[8] Brian F Cooper, Raghu Ramakrishnan, Utkarsh Srivastava, Adam Silberstein,Philip Bohannon, Hans-Arno Jacobsen, Nick Puz, Daniel Weaver, and RamanaYerneni. Pnuts: Yahoo!’s hosted data serving platform. In Proceedings of theVLDB Endowment, 1(2):1277–1288, 2008.

[9] Michael Factor, Kalman Meth, Dalit Naor, Ohad Rodeh, and Julian Satran. Objectstorage: The future building block for storage systems. In Local to Global DataInteroperability-Challenges and Technologies, 2005, pages 119–123. IEEE, 2005.

[10] Eimear Gallery and Chris J Mitchell. Trusted computing: Security and applications.Cryptologia, 33(3):217–245, 2009.

[11] Bernard Golden. Virtualization for dummies. John Wiley & Sons, 2013.

[12] Dieter Gollmann. Computer Security. John Wiley and Sons, 3 edition, 2012.

[13] Bernd Grobauer, Tobias Walloschek, and Elmar Stocker. Understanding cloudcomputing vulnerabilities. Security & privacy, IEEE, 9(2):50–57, 2011.

BIBLIOGRAPHY 63

[14] Aurel Gross. Using geolocation in authentication and fraud detection for web-basedsystems. Master’s thesis, Athabasca University, 2011.

[15] Everest Group. Enterprise cloud adoption survey 2013: Summary of results. Tech-nical report, 2013. Publication EGR-2013-4-O-0856.

[16] Michael Hasenstein. The logical volume manager (lvm). White paper, 2001.

[17] Cisco Inc. Ipv6 security brief. Technical report, 2011.

[18] Ponemon Institute. Encryption in the cloud: Who is responsible for data protectionin the cloud? Technical report, 2012.

[19] Seny Kamara and Kristin Lauter. Cryptographic cloud storage. In Financial Cryp-tography and Data Security, pages 136–149. Springer, 2010.

[20] Ryan Ko and Stephen S G Lee. Cloud computing vulnerability incidents: A statis-tical overview. Technical report, Cloud Security Alliance, 2011.

[21] Bert-Jaap Koops. Crypto law survey, 2013.

[22] Leonardo A Martucci, Albin Zuccato, Ben Smeets, Sheikh Mahbub Habib, ThomasJohansson, and Nahid Shahmehri. Privacy, security and trust in cloud computing:The perspective of the telecommunication industry. In Ubiquitous Intelligence &Computing and 9th International Conference on Autonomic & Trusted Computing(UIC/ATC), 2012 9th International Conference on, pages 627–632. IEEE, 2012.

[23] Peter Mell and Tim Grance. The nist definition of cloud computing. NationalInstitute of Standards and Technology, 53(6):50, 2009.

[24] Michael Naehrig, Kristin Lauter, and Vinod Vaikuntanathan. Can homomorphicencryption be practical? In Proceedings of the 3rd ACM workshop on Cloud com-puting security workshop, pages 113–124. ACM, 2011.

[25] OpenStack Foundation. OpenStack Cinder Developer Guide, 2014.

[26] OpenStack Foundation. OpenStack Configuration Reference, 2014. Havana-release,http://docs.openstack.org/havana/config-reference/bk-config-guide-havana.pdf ac-cessed 20 mar 2014.

[27] OpenStack Foundation. OpenStack Nova Developer Guide, 2014.

[28] Nicolae Paladi, Christian Gehrmann, Mudassar Aslam, and Fredric Morenius.Trusted launch of virtual machine instances in public iaas environments. In In-formation Security and Cryptology–ICISC 2012, pages 309–323. Springer, 2013.

[29] Nicolae Paladi, Christian Gehrmann, and Fredric Morenius. Domain-based storageprotection (dbsp) in public infrastructure clouds. In Secure IT Systems, pages279–296. Springer, 2013.

[30] Mithun Paul and Ashutosh Saxena. Proof of erasability for ensuring comprehen-sive data deletion in cloud computing. In Recent Trends in Network Security andApplications, pages 340–348. Springer, 2010.

[31] Gerald J Popek and Robert P Goldberg. Formal requirements for virtualizablethird generation architectures. Communications of the ACM, 17(7):412–421, 1974.

[32] Rob Randell. Virtualization security and best practices. Technical report, VMWare,Inc., 2008.

BIBLIOGRAPHY 64

[33] Farzad Sabahi. Secure virtualization for cloud environment using hypervisor-basedtechnology. Int. Journal of Machine Learning and Computing, 2(1), 2012.

[34] Karen Scarfone. Guide to security for full virtualization technologies. DIANEPublishing, 2011.

[35] Mass Soldal-Lund, Bjornar Solhaug, and Ketil Stolen. Model Driven Risk-Analysis,The CORAS Approach. Springer Berlin Heidelberg, 2011.

[36] Trusted Computing Group. TCG Specification Architecture Overview, 2007. Revi-sion 1.4, accessed 20 feb 2014.

[37] Bob Violino. The in-depth guide to data destruction. Technical report, 2010.

[38] Inc. VMWare. White paper: Virtualization overview. http://www.vmware.com/

pdf/virtualization.pdf. accessed 2014-02-20.

[39] Cong Wang, Kui Ren, Wenjing Lou, and Jin Li. Toward publicly auditable securecloud data storage services. Network, IEEE, 24(4):19–24, 2010.

[40] Weichao Wang, Zhiwei Li, Rodney Owens, and Bharat Bhargava. Secure and ef-ficient access to outsourced data. In Proceedings of the 2009 ACM workshop onCloud computing security, pages 55–66. ACM, 2009.

[41] Yinqian Zhang, Ari Juels, Michael K Reiter, and Thomas Ristenpart. Cross-vmside channels and their use to extract private keys. In Proceedings of the 2012 ACMconference on Computer and communications security, pages 305–316. ACM, 2012.

65

Appendix A

CORAS Diagrams

A.1 Context Establishment

:Client :Cinder :Storage Node

Create volume

Authorize client/tenant

ack

Select host

ack

Create volume

Create logical volume

ack

ack

ack

Figure A.1: Sequence diagram of creation of a volume.

A.1. CONTEXT ESTABLISHMENT 66

Who/what causes it? How? What is the incident?What does it harm?

What makes it possi-ble?

Other tenant (deliberate) VM-escape to retrieve data be-longing to another tenant orcryptographic keys used to pro-tect data belonging to anothertenant

Weak separation as a re-sult of insu�cient virtu-alization security

Other tenant (acciden-tal/deliberate)

A tenant is provisioned a volumewhere old data remains and isdisclosed to tenant or third party

Resource sharing of harddrives without properdata destruction

Cloud Service Provider(deliberate)

The Cloud Service Provider own-ing the hardware resources ille-gally access user data

Hardware resources incontrol of Cloud ServiceProvider

Cloud Service Provider(accidental) and hacker(deliberate)

Cloud management software isused to illegally gain access to ac-count belonging to a tenant

Vulnerabilities in thecloud managementsoftware

Eavesdropper Accessing data during transferfrom compute node to storagenode or reverse

Unencrypted and ex-posed transfer of databetween hosts

Hacker Breaking into VM belonging toa tenant to illegally access ten-ant data or cryptographic keysaccessible from VM to access en-crypted data

Vulnerabilities in soft-ware running insidenetwork-connected vir-tual machine or in cloudmanagement software

Remote hacker Data is illegally accessed bybreaking in to the storage nodecontaining the hard-drives

Data stored in plain text

Hacker/burglar Hard-drives containing sensitivedata are stolen from its physicallocation leading to disclosure ofuser data

Data stored in clear textand/or insu�cient physi-cal security

Table A.1: High-level risk analysis of non-volatile data in IaaS-environments.


:Client

:Nova

:Com

pute

Nod

e:U

serVM

:Storage

Nod

e

Attachvolume

Authorizeclient/tenan

t

ack

Find/con

figu

restoragehost

Initiate

iSCSItarget

ack

ack

Attachvolume

Con

nect(iSCSI)

Get

volume

ack

ack

Attachto

VM

PnP

(Plug-an

d-play)

ack

ack

ack

ack

Figure

A.2:Sequence

diagram

ofattachmentof

avo

lume.


:Client

:UserVM

:Com

pute

Nod

e:Storage

Nod

e

Con

nect(SSH)

Authorizeclient

OK

Open

afile

forread

ing

Read

Read(iSCSI)

Readblocks

ack

ack

ack

ack

Process

data

OK

Logou

t

Figure

A.3:Sequence

diagram

ofdataread

e.g.

usingSSH.

A.2. RISK ASSESSMENT DIAGRAMS 69

A.2 Risk Assessment Diagrams

IncreasedIaaS usage

IncreasedIaaS usage

User VM

User data

Cloud ManagementSoftware

CompromisedConfidentiality

[possible]

CompromisedIntegrity

[possible]

CompromisedAvailability

[possible]

VM instanceCompromised

[possible]

VM instanceVulnerable

[likely]

Cloud ManagementSoftware vulnerable

[possible]

moderate

severe

severe

moderate

insignificant

major

moderate

Userefficiency


Provider

moderate

Userefficiency


Provider

Userefficiency

IncreasedIaaS usage

moderate

severe

moderate

major

minor

moderate

minor

minor

moderate

Cloud ManagementSoftware compromised

[possible]

Figure A.4: Threat diagram showing harm to indirect assets.


Use

r V

M

Use

r da

ta

Clo

ud M

an

ag

emen

tSo

ftw

are

Co

mpro

mis

edco

nfi

den

tia

lity

Co

mp

rom

ised

inte

gri

ty

Com

pro

mis

edava

ilab

ilit

y

VM

sec

uri

tyco

mpro

mis

ed

Clo

ud M

an

ag

emen

tSo

ftw

are

co

mp

rom

ised

Mis

use

of

CM

so

ftw

are

Sto

len h

ard

-d

rive

s

VM

-esc

ap

e to

Com

pute

Host

Data

ea

vesd

rop

ped

du

ring

tra

nsf

er

Ille

ga

l acc

ess

to V

M

Insu

ffic

ien

t d

ata

rem

ova

l p

roce

du

res

Data

rem

an

ence

Wea

k vi

rtua

liza

tio

nse

curi

ty

Impro

per

co

nfi

gura

tion

of

VM

Vu

lner

ab

le s

oft

wa

reru

nnin

g i

n V

M

Unen

cryp

ted

tran

sfer

of

da

ta

Vu

lner

abil

itie

s in

C

M s

oft

ware

Insu

ffic

ien

t p

hys

ical

secu

rity

Oth

er t

ena

nt

Ea

vesd

rop

per

Clo

ud

Ser

vice

Pro

vid

er

Hack

er/

burg

lar

Da

ta i

lleg

all

y a

cces

sed b

y C

SP

Ille

ga

l acc

ess

toS

tora

ge

Ho

st

CS

P o

wn

sre

sourc

es

Vu

lner

ab

leSto

rag

e H

ost

Hack

er/

bu

rgla

r

C I

A of

dat

aFigure

A.5:Threat

diagram

ofdeliberaterisks.


Use

r V

M

Use

r d

ata

Clo

ud

Ma

na

gem

ent

So

ftw

are

Co

mp

rom

ised

con

fid

enti

ali

ty

Co

mp

rom

ised

inte

gri

ty

Co

mp

rom

ised

ava

ila

bil

ity

VM

sec

uri

tyco

mp

rom

ised

Clo

ud

Ma

na

gem

ent

So

ftw

are

co

mp

rom

ised

Mis

use

of

CM

so

ftw

are

Ha

rd-d

rive

cra

sh

Ten

an

t is

es

cap

ing

VM

to

Co

mp

ute

Ho

st

Ha

cker

ga

ins

ille

ga

l a

cces

s to

VM

Insu

ffic

ien

t d

ata

rem

ova

l p

roce

du

res

Da

ta r

ema

nen

ce

Imp

rop

er

con

fig

ura

tio

n o

f V

M

Vu

lner

ab

le s

oft

wa

reru

nn

ing

in

VM

Insu

ffic

ien

t u

pd

ate

so

f C

M s

oft

wa

re

Insu

ffic

ien

t b

ack

up

pro

ced

ure

s

Ten

an

t/u

ser

Clo

ud

Ser

vice

Pro

vid

er

Ha

cker

ga

ins

ille

ga

l a

cces

s to

Sto

rag

e H

ost

Insu

ffic

ien

t u

pd

ate

so

f S

tora

ge

Ho

st

C I

A of

dat

a

Wea

k vi

rtu

ali

zati

on

secu

rity

Figure

A.6:Threat

diagram

ofaccidentalrisks.


Use

r V

M

Use

r d

ata

Clo

ud

Ma

na

gem

ent

So

ftw

are

Co

mp

rom

ised

Co

nfi

den

tia

lity

[po

ssib

le]

Co

mp

rom

ised

Inte

gri

ty

[po

ssib

le]

Co

mp

rom

ised

Ava

ila

bil

ity

[po

ssib

le]

VM

in

sta

nce

Co

mp

rom

ised

[po

ssib

le]

Clo

ud

Ma

na

gem

ent

So

ftw

are

co

mp

rom

ised

[po

ssib

le]

Ille

ga

l a

cces

s to

V

M-i

nst

an

ce

[po

ssib

le]

Ille

ga

l a

cces

s to

Co

mp

ute

Ho

st

[un

like

ly]

Ille

ga

l a

cces

s to

Sto

rag

e H

ost

[un

like

ly]

Ille

ga

l re

ad

/wri

tea

cces

s to

use

r d

ata

[po

ssib

le]

Da

ta e

ave

sdro

pp

edd

uri

ng

tra

nsf

er

[cer

tain

]

CS

P a

cces

ses

use

r d

ata

[un

like

ly]

Da

ta r

ema

nen

ce

[un

like

ly]

Mis

use

of

Clo

ud

Mg

mt.

So

ftw

are

[po

ssib

le]

Insu

ffic

ien

t d

ata

rem

ova

l p

roce

du

res

Wea

k vi

rtu

ali

zati

on

sep

ara

tio

n /

mu

lti-

ten

an

cy

Mis

con

fig

ure

dp

ub

lic

*-h

ost

Vu

lner

ab

lep

ub

lic

*-h

ost

Da

ta t

ran

sfer

in

cle

ar

text

CS

P o

wn

sre

sou

rces

Acc

ou

nt

hij

ack

ing

[lik

ely]

Ten

an

t/u

ser

Clo

ud

Ser

vice

Pro

vid

er

Oth

er t

ena

nt

(fro

m i

nsi

de

VM

)

Ea

vesd

rop

per

Clo

ud

Ser

vice

Pro

vid

er

Ha

cker

/b

urg

lar

Vu

lner

ab

levi

rtu

ali

zati

on

VM

in

sta

nce

Vu

lner

ab

le

[lik

ely]

Clo

ud

Ma

na

gem

ent

So

ftw

are

vu

lner

ab

le

[po

ssib

le]

Vu

lner

ab

ilit

ies

in C

lou

dM

an

ag

emen

t S

oft

wa

re

[po

ssib

le]

Vu

lner

ab

leso

ftw

are

in

VM

[cer

tain

]

Ha

rd-d

rive

sst

ole

n

[ra

re]

Po

or

ph

ysic

al

secu

rity

moder

ate

sever

e

seve

re

mo

der

ate

insign

ifica

nt

maj

or

mod

erat

e

Figure

A.7:Final

threat

diagram

withestimated

likelihoo

ds.


User VM

User data


CDC: Compr.confidentiality

[not-acceptable]

CDI: Compr.integrity

[investigate]

CDA: Compr.availability

[acceptable]

VVM: VM vulnerable

[not-acceptable]

ECM: Cloud Mgmt.Software exploited[not-acceptable]

EVM:VM exploited

[not-acceptable]

VCM: Cloud Mgmt. Software vulnerable

[investigate]

Tenant/user


Hacker

Other tenant(from inside VM)


Hacker/burglar


Eavesdropper



Hacker/other tenant

CDC,CDI,CDA

CDC,CDI,CDA

Figure A.8: Risk picture of non-volatile data in infrastructure clouds.

A.3. RISK TREATMENT DIAGRAMS 74

A.3 Risk Treatment Diagrams

User VM

User data


CDC: Compr.confidentiality

[not-acceptable]

VVM: VM vulnerable

[not-acceptable]

ECM: Cloud Mgmt.Software exploited[not-acceptable]

EVM:VM exploited

[not-acceptable]

VCM: Cloud Mgmt. Software vulnerable

[investigate]

Tenant/user


Hacker



Hacker/burglar


Eavesdropper

Integrity checksand attestation

Encrypting data Ensured datadestruction

Tenant security-awareness

Figure A.9: Treatments and their impact on the risks.


Use

r V

M

Use

r d

ata

Clo

ud

Ma

na

gem

ent

Soft

ware

Co

mpro

mis

edC

onfi

den

tia

lity

[po

ssib

le]

Com

pro

mis

edIn

teg

rity

[poss

ible

]

Co

mpro

mis

edA

vail

ab

ilit

y

[po

ssib

le]

VM

inst

an

ceC

om

pro

mis

ed

[poss

ible

]

Clo

ud

Ma

na

gem

ent

So

ftw

are

co

mp

rom

ised

[poss

ible

]

Ille

ga

l a

cces

s to

V

M-i

nst

an

ce

[po

ssib

le]

Ille

ga

l acc

ess

toC

om

pu

te H

ost

[un

like

ly]

Ille

gal

acc

ess

toS

tora

ge

Host

[unli

kely

]

Ille

ga

l re

ad/w

rite

acc

ess

to u

ser

da

ta[p

oss

ible

]

Da

ta e

ave

sdro

pp

edd

uri

ng t

ransf

er

[cer

tain

]

CS

P a

cces

ses

use

r d

ata

[unli

kely

]

Da

ta r

ema

nen

ce

[un

like

ly]

Mis

use

of

Clo

ud

Mg

mt.

Soft

wa

re

[po

ssib

le]

Insu

ffic

ien

t da

tare

mo

val

pro

cedu

res

Wea

k vi

rtua

liza

tio

nse

para

tio

n /

mu

lti-

tena

ncy

Mis

confi

gu

red

pu

bli

c *

-ho

st

Vuln

era

ble

pub

lic

*-h

ost

Da

ta t

ran

sfer

in

cle

ar

text

CS

P o

wns

reso

urc

es

Acc

oun

th

ija

ckin

g

[lik

ely]

Ten

an

t/u

ser

Clo

ud

Ser

vice

Pro

vider

Oth

er t

ena

nt

(fro

m i

nsi

de

VM

)

Ea

vesd

rop

per

Clo

ud

Ser

vice

Pro

vid

er

Ha

cker

/b

urg

lar

Vuln

era

ble

virt

ua

liza

tion

VM

in

stan

ceV

uln

erab

le

[lik

ely]

Clo

ud M

an

ag

emen

tS

oft

ware

vu

lner

able

[po

ssib

le]

Vuln

erab

ilit

ies

in C

lou

dM

an

ag

emen

t So

ftw

are

[poss

ible

]

Vu

lner

ab

leso

ftw

are

in

VM

[cer

tain

]

Hard

-dri

ves

sto

len

[rare

]P

oor

ph

ysic

al

secu

rity

moder

ate

sever

e

seve

re

mo

der

ate

insign

ifica

nt

maj

or

moder

ate

Inte

gri

ty c

hec

ksa

nd a

ttes

tati

on

Encr

ypti

ng d

ata

En

sure

d d

ata

des

tru

ctio

n

Ten

an

t se

curi

ty-

aw

are

nes

s

Figure

A.10:Threat

diagram

show

ingtreatm

ents

tomitigaterisks.


Use

r V

M

Use

r d

ata

Clo

ud

Ma

na

gem

ent

Soft

ware

Co

mpro

mis

edC

onfi

den

tia

lity

[unli

kely

]

Com

pro

mis

edIn

teg

rity

[un

like

ly]

Co

mpro

mis

edA

vail

ab

ilit

y

[unli

kely

]

VM

inst

an

ceC

om

pro

mis

ed

[poss

ible

]

Clo

ud

Ma

na

gem

ent

So

ftw

are

co

mp

rom

ised

[un

like

ly]

Ille

ga

l a

cces

s to

V

M-i

nst

an

ce

[rare

]

Ille

ga

l acc

ess

toC

om

pu

te H

ost

[ra

re]

Ille

gal

acc

ess

toS

tora

ge

Host

[unli

kely

]

Ille

ga

l re

ad/w

rite

acc

ess

to u

ser

da

ta[u

nli

kely

]

CS

P a

cces

ses

use

r d

ata

[unli

kely

]

Mis

use

of

Clo

ud

Mg

mt.

Soft

wa

re

[un

like

ly]

Wea

k vi

rtua

liza

tio

nse

para

tio

n /

mu

lti-

tena

ncy

Mis

confi

gu

red

pu

bli

c *

-ho

st

Vuln

era

ble

pub

lic

*-h

ost

CS

P o

wns

reso

urc

es

Acc

ou

nt

hij

ack

ing

[po

ssib

le]

Ten

an

t/u

ser

Clo

ud

Ser

vice

Pro

vider

Oth

er t

ena

nt

(fro

m i

nsi

de

VM

)

Clo

ud

Ser

vice

Pro

vid

er

Ha

cker

/b

urg

lar

Vuln

era

ble

virt

ua

liza

tion

VM

in

stan

ceV

uln

erab

le

[lik

ely]

Clo

ud M

an

ag

emen

tS

oft

ware

vu

lner

able

[rare

]

Vuln

erab

ilit

ies

in C

lou

dM

an

ag

emen

t So

ftw

are

[rare

]

Vu

lner

ab

leso

ftw

are

in

VM

[cer

tain

]

Hard

-dri

ves

sto

len

[rare

]P

oor

ph

ysic

al

secu

rity

moder

ate

sever

e

seve

re

mo

der

ate

insign

ifica

nt

maj

or

moder

ate

Figure

A.11:Threat

diagram

withre-estim

ated

likelihoo

dsan

dconsequ

ences.

77

Appendix B

Implementing theDBSP-protocol in OpenStack

:Nova :Libvirtd :Hook :TPM :TTP :SC

iscsi-init(id)

device

attach

attach-volume(device)

unlock-request?

NO

device

attach-to-vm(device)

OK

ExtensionsExtensions

OK

update-db()

Figure B.1: Sequence diagram illustrating attachment of an unencrypted volume,showing the extensions made to the original sequence of actions.

78

:Nova :Libvirtd :Hook :TPM :TTP :SC

iscsi-init(id)

device

attach

attach-volume(device)

unlock-request?

YESipc-unlock(device)

read-meta(device)

metaget-key(meta)

gen-key(meta)

keyseal-key(key)

{key}PKTPM

{key}PKTPM

unseal-key()

key

unlock-volume(key)

mapper

mapper

mapper

attach-to-vm(mapper)

OK

ExtensionsExtensions

OK

update-db()

Figure B.2: Sequence diagram illustrating attachment of an encrypted volume,showing the extensions made to the original sequence of actions.

På svenska Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ In English The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

© Erik Sundqvist

Institutionen för datavetenskap780110/FULLTEXT01.pdf · Institutionen för datavetenskap...

Documents

Transcript of Institutionen för datavetenskap780110/FULLTEXT01.pdf · Institutionen för datavetenskap...