Post on 28-Jun-2020
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
2.2. NON-VOLATILE DATA IN IAAS-ENVIRONMENTS 10
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.
2.2. NON-VOLATILE DATA IN IAAS-ENVIRONMENTS 11
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
3.1. THE CORAS METHOD 20
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
3.1. THE CORAS METHOD 21
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
4.1. CONTEXT ESTABLISHMENT 24
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.
4.1. CONTEXT ESTABLISHMENT 25
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.
4.1. CONTEXT ESTABLISHMENT 26
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].
4.1. CONTEXT ESTABLISHMENT 27
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.
4.1. CONTEXT ESTABLISHMENT 28
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.
4.1. CONTEXT ESTABLISHMENT 29
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
4.1. CONTEXT ESTABLISHMENT 30
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.
Consequence Description
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
Consequence Description
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
4.2. RISK ASSESSMENT 32
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
4.2. RISK ASSESSMENT 33
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,
4.2. RISK ASSESSMENT 34
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.
4.2. RISK ASSESSMENT 35
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. RISK ASSESSMENT 36
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.
Insignificant Minor Moderate Major Severe
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
Identifier Description Consequence Likelihood
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
4.3. RISK TREATMENT 38
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.
4.3. RISK TREATMENT 39
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
Compute node Storage node
Hardware Hardware
OS OS
VM1
DATA
VM0
****
ISCSITarget
NIC
TCP/IP LVM
****
NIC
TCP/IP
ISCSIInitiator
DATA
Cloud Management Services Cloud Management Services
HTTPserver
OBJ
ObjectProxy
VLANcontrol
HTTP clientDistributed
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
Compute node Storage node
Hardware Hardware
OS OS
VM1
DATA
VM0
****
ISCSITarget
NIC
TCP/IP LVM
****
NIC
TCP/IP
ISCSIInitiator
DATA
Cloud Management Services Cloud Management Services
HTTPserver
OBJ
ObjectProxy
VLANcontrol
HTTP clientDistributed
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
Compute node Storage node
Hardware Hardware
OS OS
VM1
DATA
VM0
****
ISCSITarget
NIC
TCP/IP LVM
****
NIC
TCP/IP
ISCSIInitiator
DATA
Cloud Management Services Cloud Management Services
HTTPserver
OBJ
ObjectProxy
VLANcontrol
HTTP clientDistributed
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.
Identifier Description Consequence Likelihood
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.
Identifier Description Consequence Likelihood
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.
Insignificant Minor Moderate Major Severe
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.
A.1. CONTEXT ESTABLISHMENT 67
: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.
A.1. CONTEXT ESTABLISHMENT 68
: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
Trust inCloud Service
Provider
moderate
Userefficiency
Trust inCloud Service
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.
A.2. RISK ASSESSMENT DIAGRAMS 70
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.
A.2. RISK ASSESSMENT DIAGRAMS 71
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.
A.2. RISK ASSESSMENT DIAGRAMS 72
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.
A.2. RISK ASSESSMENT DIAGRAMS 73
User VM
User data
Cloud ManagementSoftware
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
Cloud ServiceProvider
Hacker
Other tenant(from inside VM)
Cloud ServiceProvider
Hacker/burglar
Other tenant(from inside VM)
Eavesdropper
Cloud ServiceProvider
Cloud ServiceProvider
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
Cloud ManagementSoftware
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
Cloud ServiceProvider
Hacker
Other tenant(from inside VM)
Cloud ServiceProvider
Hacker/burglar
Other tenant(from inside VM)
Eavesdropper
Integrity checksand attestation
Encrypting data Ensured datadestruction
Tenant security-awareness
Figure A.9: Treatments and their impact on the risks.
A.3. RISK TREATMENT DIAGRAMS 75
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.
A.3. RISK TREATMENT DIAGRAMS 76
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