D1.2 Requirements from the Use Cases - ESCUDO-CLOUD · of common ESCUDO-CLOUD requirements, which...

Project title: Enforceable Security in the Cloud to Uphold Data Ownership

Project acronym: ESCUDO-CLOUD

Funding scheme: H2020-ICT-2014

Topic: ICT-07-2014

Project duration: January 2015 – December 2017

D1.2

Requirements from the Use Cases

Editors: David Bowden (EMC)Florian Kerschbaum (SAP)

Reviewers: Neeraj Suri (TUD)Stefano Paraboschi (UNIBG)

Abstract

This document details the common security requirements of the four ESCUDO-CLOUD use cases. Eachuse case addresses a specific application scenario, which can be classified as Private/Hybrid Clouds, In-frastructure Provisioning, Cloud Storage, and Cloud Processing. This permits to cover an entire Cloudlife-cycle where a company may choose to outsource infrastructure, middleware, data and applications. Foreach use case, we used the ESCUDO-CLOUD dimensions to categorize the specific requirements, thendefined common terms and concepts. Based on these common terms and concepts, we identify the commonESCUDO-CLOUD requirements across the use cases. We also reviewed the current state of the industry,with respect to the scenarios covered by the use cases, and assessed gaps that might be addressed. Finally,an update to the assignment of requirements to work package tasks is also presented. The requirementsare determined by the desire of data owners to receive secure Cloud storage services, and not to have theirdata confidentiality, integrity, or availability compromised. These requirements are also determined by thelegal and business environment surrounding likely deployments. Combining the specific and common re-quirements will help steer the ESCUDO-CLOUD project technological development process according toits goals and objectives.

Type Identifier Dissemination DateDeliverable D1.2 Public 2015.12.31

This project has received funding from the European Union’s Horizon 2020 research and innovation programmeunder grant agreement No 644579. This work was supported in part by the Swiss State Secretariat for Education,Research and Innovation (SERI) under contract No 150087. The opinions expressed and arguments employed hereindo not necessarily reflect the official views of the European Commission or the Swiss Government.

ESCUDO-CLOUD Consortium

1. Università degli Studi di Milano UNIMI Italy

2. British Telecom BT United Kingdom

3. EMC Corporation EMC Ireland

4. IBM Research GmbH IBM Switzerland

5. SAP SE SAP Germany

6. Technische Universität Darmstadt TUD Germany

7. Università degli Studi di Bergamo UNIBG Italy

8. Wellness Telecom WT Spain

Disclaimer: The information in this document is provided "as is", and no guarantee or warranty is given that theinformation is fit for any particular purpose. The below referenced consortium members shall have no liability fordamages of any kind including without limitation direct, special, indirect, or consequential damages that may resultfrom the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2015by Università degli Studi di Milano, British Telecom, EMC Corporation, IBM Research GmbH, SAP SE, TechnischeUniversität Darmstadt, Università degli Studi di Bergamo, Wellness Telecom.

2

Versions

Version Date Description

0.1 2015.11.23 Initial Release

0.2 2015.12.14 Second Release

1.0 2015.12.31 Final Release

3

List of Contributors

This document contains contributions from different ESCUDO-CLOUD partners. Contributorsfor the chapters of this deliverable are presented in the following table.

Chapter Author(s)

Executive Summary David Bowden (EMC)

Chapter 1: Introduction David Bowden (EMC)

Chapter 2: Common Terms and Concepts David Bowden (EMC)

Chapter 3: Use Cases Section 3.1: Elli Androulaki (IBM), NikolaKnezevic (IBM), Christian Cachin (IBM)Section 3.2: Florian Kerschbaum (SAP)Section 3.3: Ali Sajjad (BT), Theo Dimitrakos(BT)Section 3.4: Mercedes Castano Torres (WT),Ignacio Campos Rivera (WT)

Chapter 4: Requirements Analysis David Bowden (EMC)

Chapter 5: Use Case Requirements Compari-son to Current Technologies

Section 5.1: Nikola Knezevic (IBM)Section 5.2: Florian Kerschbaum (SAP)Section 5.3: Ali Sajjad (BT)Section 5.4: Mercedes Castano Torres (WT)

Chapter 6: Conclusions Florian Kerschbaum (SAP)

4

Contents

Executive Summary 9

1 Introduction 111.1 Purpose of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Structure of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 ESCUDO-CLOUD Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4 Requirements Analysis Methodology . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Common Terms and Concepts 172.1 Trust Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Trusted Third Party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 Data Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4 Data Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 ESCUDO-CLOUD Security Framework . . . . . . . . . . . . . . . . . . . . . . 20

3 Use Cases 223.1 Use Case 1: OpenStack Framework (IBM) . . . . . . . . . . . . . . . . . . . . . 223.2 Use Case 2: Secure Enterprise Data Management in the Cloud (SAP) . . . . . . 253.3 Use Case 3: Federated Secure Cloud Storage (BT) . . . . . . . . . . . . . . . . . 293.4 Use Case 4: Elastic Cloud Service Provider (WT) . . . . . . . . . . . . . . . . . 33

4 Requirements Analysis 374.1 Use Case Requirements to Work Package Tasks . . . . . . . . . . . . . . . . . . 374.2 Synthesis of Common Requirements . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1 Data confidentiality (a-i) . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.2 Data integrity (a-ii) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.3 Data availability (a-iii) . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.4 Access by data owners (b-i) . . . . . . . . . . . . . . . . . . . . . . . . 464.2.5 Selective sharing with other users/owners (b-ii) . . . . . . . . . . . . . . 494.2.6 Upload/download (c-i) . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.7 Fine-grained retrieval (c-ii) . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.8 Write operations (c-iii) . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.9 Single Cloud provider (d-i) . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.10 Multi Cloud and federated Cloud (d-ii) . . . . . . . . . . . . . . . . . . 56

5

6 Contents

5 Use Case Requirements Comparison to Current Technologies 595.1 Use Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Use Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3 Use Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.4 Use Case 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6 Conclusions 68

Appendix A Glossary 70

Appendix B Use Case Requirements to Work Package Tasks 74

Appendix C Dimensions to Use Case Requirements 77

Appendix D Common Requirements 79

Bibliography 87

ESCUDO-CLOUD Deliverable D1.2

List of Figures

1.1 Relationship of WP1 to other WPs . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Trust boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Trusted third party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Three basic components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 Distributed components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Overview of the Use Case 1 trust boundaries . . . . . . . . . . . . . . . . . . . . 233.2 Overview of the Use Case 2 trust boundaries . . . . . . . . . . . . . . . . . . . . 273.3 Overview of the Use Case 3 trust boundaries . . . . . . . . . . . . . . . . . . . . 303.4 Overview of the Use Case 4 trust boundaries . . . . . . . . . . . . . . . . . . . . 34

4.1 Syndicating encryption keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Clustered key managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Separating encryption and data storage . . . . . . . . . . . . . . . . . . . . . . . 484.4 Key hierarchy and associated data access . . . . . . . . . . . . . . . . . . . . . . 494.5 Simple security scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.6 Distributed security scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.7 Syndicating encryption agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.8 Multi-layer encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.9 Interposing Federated-Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.10 Syndicating Federated-Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7

List of Tables

1.1 ESCUDO-CLOUD Dimensions and Sub-Dimensions . . . . . . . . . . . . . . . 13

3.1 Use Case 1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Use Case 2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3 Use Case 3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4 Use Case 4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Work Package Tasks to Use Case Requirements . . . . . . . . . . . . . . . . . . 384.2 Categories for use case requirements (a-i) . . . . . . . . . . . . . . . . . . . . . 394.3 Categories for use case requirements (a-ii) . . . . . . . . . . . . . . . . . . . . . 434.4 Categories for use case requirements (a-iii) . . . . . . . . . . . . . . . . . . . . 444.5 Categories for use case requirements (b-i) . . . . . . . . . . . . . . . . . . . . . 464.6 Categories for use case requirements (b-ii) . . . . . . . . . . . . . . . . . . . . . 494.7 Categories for use case requirements (c-i) . . . . . . . . . . . . . . . . . . . . . 514.8 Categories for use case requirements (c-ii) . . . . . . . . . . . . . . . . . . . . . 524.9 Categories for use case requirements (c-iii) . . . . . . . . . . . . . . . . . . . . 544.10 Categories for use case requirements (d-i) . . . . . . . . . . . . . . . . . . . . . 554.11 Categories for use case requirements (d-ii) . . . . . . . . . . . . . . . . . . . . . 56

B.1 Use Case Requirements to Work Package Tasks . . . . . . . . . . . . . . . . . . 76

C.1 Dimensions and Use Case Requirements . . . . . . . . . . . . . . . . . . . . . . 78

D.1 Common Security Framework Requirements . . . . . . . . . . . . . . . . . . . . 81D.2 Common Key Manager Requirements . . . . . . . . . . . . . . . . . . . . . . . 83D.3 Common Access Controller Requirements . . . . . . . . . . . . . . . . . . . . . 85D.4 Common Encryption Agent Requirements . . . . . . . . . . . . . . . . . . . . . 86

8

Executive Summary

One of the main factors slowing the uptake of Cloud solutions is the user’s perception, and pos-sibly reality, of the lack of security when outsourcing their data to the Cloud. This is especiallyimportant for businesses and organisations that are legally obliged to comply with specific industryregulations. The lack of a comprehensive and broadly adopted security framework, means that it isdifficult for many data owners to ensure regulatory compliance when outsourcing their data to theCloud. ESCUDO-CLOUD seeks to address these concerns by providing effective and deployableCloud security solutions.

Deliverable D1.2 comprises the "Requirements from the use cases", which extends the initialdeliverable D1.1 "First version of requirements from the use cases". Together they comprise theM1-12 activities of Task 1.1, which considers four ESCUDO-CLOUD data storage use cases.Each use case represents a real-world scenario, where one of the participating SME and industrialpartners in the project has direct experience, and for which, there are outstanding security issuesthat are not being addressed by current procedures or technologies. Task 1.1, and its constituentdeliverables D1.1 and D1.2, comprise the initial part of Work Package 1. The final goal is acollection of modular, compatible, and interoperable tools representing the ESCUDO-CLOUDframework implementation, which can be applied and validated in the use cases, as part of Tasks1.3 and 1.4.

The ESCUDO-CLOUD use cases were detailed in D1.1. It provides a description of Clouddata storage scenarios identified by the industrial partners, which represent a broad spectrum ofCloud storage deployments, and for which there are outstanding challenges. Each use case stressesdifferent security aspects, enabling focused deployment of specific solutions, in the context of thewider ESCUDO-CLOUD project objectives, as well as exploitation in specific business and usagescenarios. The analysis strategy performed by D1.1 resulted in a detailed list of requirements foreach use case. The requirements were further categorized using the four ESCUDO-CLOUD di-mensions and ten sub-dimensions, also detailed in D1.1, which provide an overarching frameworkfor considering Cloud security challenges. Additionally D1.1 made an initial contribution to a setof common ESCUDO-CLOUD requirements, which was included in its annex.

Extending the work of D1.1, D1.2 details three additional pieces of work that were carried outto conclude Task 1.1 a) an update to the assignment of use case requirements to work packagetasks; b) the synthesis of a common set of ESCUDO-CLOUD terms, concepts and requirements,from the specific use case requirements; and c) a review of current industry solutions coveredby the use cases, highlighting possible gaps, and the procedure or technologies that ESCUDO-CLOUD will produce to meet them.

The specific use case requirements, combined with the common ESCUDO-CLOUD require-ments, and the industry gap analysis, will be used to drive the research and development work ofthe technical core work packages WP2, WP3 and WP4, which will align the work carried out inthe technical tasks of the ESCUDO-CLOUD project with the needs of the use cases and enableexploitation of that work by the SME and industry partners.

9

1. Introduction

ESCUDO-CLOUD considers four use cases corresponding to real world problems and marketstrategies of major providers of technologies and services in the Cloud. The work that will be car-ried out in the project, and the techniques that will be produced, start from an analysis of use casesand the eventual deployment to them. The industrial partners and the SME have clear exploitationplans for managing the innovations brought by the project, described by the use cases, which willsignificantly enhance their offerings and will provide actual impact in the Cloud industry.

Figure 1.1: Relationship of WP1 to other WPs

Figure 1.1 illustrates an overview of the relationship between Work Package 1 (WP1) and theother work packages in ESCUDO-CLOUD. It focuses on the use cases considered by the project.WP1 provides requirements (T1.1), which will also drive the research and development work in theother core work packages (WP2, WP3, WP4), and will continuously monitor their progress (T1.2).Additionally WP1 will subsequently facilitate the deployment (T1.3) and validation (T1.4) of thedeveloped tools and techniques. The purpose of the work package is to ensure that the activitiescarried out by the project correspond to actual needs of the use cases and enable direct exploitationby the SME and industrial partners.

WP1’s objectives are to a) provide requirements from the different use cases; b) monitor re-search activities in the other core technical work packages, to ensure the work is in line with the

11

12 Introduction

results anticipated by the use cases; c) provide deployment of the project techniques and their val-idation in the use cases. The final outcome of WP1 is a collection of modular tools and techniquesrepresenting the ESCUDO-CLOUD security framework, implemented in the context of the usecases and meeting their specific requirements and business objectives.

1.1 Purpose of this Document

The objectives of Task 1.1 are to define and elaborate the four ESCUDO-CLOUD use cases,andproduce two deliverables a) document D1.1, which analyzes the four use cases and itemizes theirrequirements; b) document D1.2, which reviews the individual use case requirements and abstractsthe common ESCUDO-CLOUD requirements. D1.1 was delivered after month 6 of the project,and formed the basis for this document, D1.2.

Document D1.1 defines four use cases a) Use Case 1 (IBM) looks at the user security re-quirements in the OpenStack framework, which is widely used in implementing public and hybridCloud solutions; b) Use Case 2 (SAP) considers the abstract challenges associated with processingencrypted data as part of a collaborative MRO business ecosystem; c) Use Case 3 (BT) considersthe challenges of the user sharing their data in a Federated-Cloud environment, and how thoseusers would share their data with other users; d) Use Case 4 looks at the challenges associatedwith implementing an elastic Cloud using one or more CSPs. Document D1.1 defines the spe-cific use cases and their individual requirements; summaries of each use case are included in thisdocument.

Document D1.2 elaborates on the work started in D1.1 by correlating the specific use caserequirements to work package tasks, and the ESCUDO-CLOUD dimensions. ESCUDO-CLOUDuse cases cover a broad spectrum of possible Cloud solutions from which to investigate and re-search its security aspects. D1.2 seeks to define the shared concepts and terms from the use casesto produce the common ESCUDO-CLOUD requirements, and augment the specific use case re-quirements for the core work package tasks.

1.2 Structure of the Document

Document D1.2 is structured into the following chapters:

• Chapter 2: This chapter considers the use cases defined in document D1.1, and seeks to syn-thesize and elaborate a common set of concepts and terms. The concepts and terms providea common vocabulary with which to discuss the use cases and the common ESCUDO-CLOUD requirements.

• Chapter 3: This chapter gives a summary of ESCUDO-CLOUD use cases, and is takenlargely from document D1.11. The summaries have been included to provide a context forthe individual use case requirements. The itemized requirements are listed at the end of eachuse case section.

• Chapter 4: This chapter considers the specific use case requirements, and seeks to categorizethem using the ESCUDO-CLOUD dimensions, into a common set of requirements for theproject. Not all common requirements will be applicable to all use cases, but this chapter

1Some minor amendments have been made to match the style of document D1.2.


Section 1.3: ESCUDO-CLOUD Dimensions 13

endeavours to provide the description of the common requirements, which are itemized inAppendix D.

• Chapter 5: This chapter considers current security technologies used in the Cloud. It takesthese as a starting point, and examines how ESCUDO-CLOUD could enhance them.

• Chapter 6: This final chapter summarises the content and findings of the document anddraws conclusions for the subsequent work of the ESCUDO-CLOUD project.

1.3 ESCUDO-CLOUD Dimensions

ESCUDO-CLOUD provides a set of diverse techniques for protecting the user’s data in the Cloud.These techniques are evaluated in the context of the ESCUDO-CLOUD use cases, by consideringthe security challenges from a number of perspectives, termed ESCUDO-CLOUD dimensions.This ensures that the security aspects of the use cases are considered from multiple points of view.The ESCUDO-CLOUD dimensions are a) security properties; b) sharing requirements; c) accessrequirements; d) Cloud architectures. The dimensions are further divided into sub-dimensions, asitemised in Table 1.1, and elaborated on in the following sub-sections. Not all sub-dimensions areapplicable to all use cases, and likewise, not all use cases are applicable to all sub-dimensions, forexample "Upload/download" sub-dimension is not applicable to Use Case 2. However, the broadrange of security aspects covered by the use cases ensures that the challenges highlighted by thedimensions are explored.

Dimension Sub-Dimensiona) Security properties i) Confidentiality; ii) Integrity; iii) Availabilityb) Sharing requirements i) Access by data owners; ii) Selective sharing with other

users/ownersc) Access requirements i) Upload/download; ii) Fine-grained retrieval; iii) Write opera-

tionsd) Cloud architectures i) Single Cloud provider; ii) Multi Cloud and federated Cloud

Table 1.1: ESCUDO-CLOUD Dimensions and Sub-Dimensions

The dimensions and sub-dimensions are labelled a to d and a-i, a-ii, a-iii, b-i, etc. The labelsare used in subsequent sections to reference the dimensions and sub-dimensions.

Security properties (a)

Security properties cover the basic aspects of keeping the user’s data safe in the Cloud, both fromthe CSP2 and any unauthorised third party. The various aspects of security are grouped under theclassical Confidentiality-Integrity-Availability precepts, commonly represented by the acronymCIA.

2The term CSP typically refers to an external organisation that provides Cloud services over the Internet, but in thiscontext, it may also include departments that provide services within an organisation, i.e. private Clouds


14 Introduction

Confidentiality (a-i)The confidentiality precept ensures the privacy of the user’s data whilst in the Cloud, whichcan only be viewed by the user themselves, or a third party that they have specifically au-thorised. The term viewed is used in preference to access, as viewed implies that the user’sdata is in plain text and its meaning can be comprehended.

The conventional mechanism for obfuscating the user’s data on the CSP is by encryption,typically using a symmetric-key algorithm such as AES. However encryption is not the onlymechanism to obfuscate the user’s data, another method is called fragmentation (coveredlater in the document).

Integrity (a-ii)The precept of integrity ensures that the user’s data is not altered in any way, either mali-ciously or through carelessness, except by the intent of the user or a third party authorisedby the user. In the context of ESCUDO-CLOUD it means that the data returned to the user,from the Cloud, is a faithful copy of the original.

Ensuring that the data is a faithful copy may be challenging if the data is processed while inthe Cloud, or updated by another authorised user without the original owner’s knowledge.ESCUDO-CLOUD considers data integrity in the context of these challenges.

Availability (a-iii)The availability precept ensures that the user’s data is accessible to them when they needit, and in a timely manner3. The data may be safely stored in the Cloud, inaccessible tounauthorised users and a faithful copy of the original, but if an authorised user cannot reachthe data when they require it, it fails the availability criteria.

Data availability is particularly challenging in the context of Cloud data storage, as notonly must the Cloud storage facility be available, but also the Internet. Additionally anymechanism used to obfuscate the data, or control access to it, must also be available. Whenthe data is on the user’s own system, they are largely in control of its availability, but inutilizing the Cloud the data owner must relinquish this task to a third party.

Availability, and to an extent confidentiality, both cover the requirement to ensure that ifthe user intends their data to no-longer be available, then it is put beyond use, includingsanctioned and unsanctioned4 copies in the Cloud. This may mean that the data copies aredeleted. However it could mean that the copies are still available, but no-longer reachableor intelligible.

Sharing requirements (b)

Access by data owners (b-i)In this simple security scenario the data owner utilizes the Cloud to store their data, but itis not necessary for them to share it with any other user. Therefore the storage and dataobfuscation processes are considerably streamlined. A good example of single data accessmight be a user’s private email box.

3For the data to be available the user needs to be able to access it in a reasonable time frame. If the CSP informed theuser that they could have access to their data, but due to technical difficulties, it would take several months to retrieve,then the data can’t reasonably be said to be available.

4If a data owner stores their data on a CSP, the CSP may take an unauthorised copy of the data for other purposes,say for use in their test system.


Section 1.3: ESCUDO-CLOUD Dimensions 15

Selective sharing with other users/owners (b-ii)In the more complex scenario, the data owner not only wishes to store their data in the Cloud,but also make it available to other users. In a number of security scenarios this will requirethe data to be available even when the data owner’s system is not. Here the data owner mustrely on the services of a trusted third party to act as data broker for their data in the Cloud,and to provide the same, or better, level of security that they would do themselves. A goodexample of shared storage in the Cloud might be Dropbox™ or Syncplicity™.

Access requirements(c)

Upload/download(c-i)ESCUDO-CLOUD is focused on securely storing data-at-rest within the Cloud, but thisimplies that the user’s data must safely transit from the user’s system to a safe location in theCloud and back again; therefore securely uploading and downloading data into the Cloudis a necessary consideration. It encompasses aspects such as a) type and format of data;b) the secure channel that the data will transit over; c) how both parties will authenticateeach other.

Fine-grained retrieval (c-ii)It would be possible for a user to store their data in the Cloud as a single entity, which wouldbe sent, received, shared, etc. as a whole. Whilst this approach is simple, it potentially hasa number of drawbacks, including a) the data owner can’t securely share only a portion oftheir data with another user; b) encrypting and decrypting large quantities of data can incura substantial processing overhead and delay; c) communications bandwidth is unnecessarilywasted. The solution considered by ESCUDO-CLOUD divides the data into parts, whichfacilitates fine-grained data retrieval as each part can be obfuscated and stored separately,and then data parts can be retrieved as atomic entities.

Dividing and retrieving data in a logical and automated way is not without its challenges, andit is these Cloud challenges that ESCUDO-CLOUD considers as part of this sub-dimension.

Write operations (c-iii)Write operations in the Cloud pose additional security risks compared to merely accessingthe data, which can include a) extended communications channels, causing a higher latencywith receipt acknowledgements; b) the possibility of man-in-the-middle attacks modifyingthe data in transit, unbeknownst to the sender or receiver; c) a malicious third party mayadd data to change its meaning. Whilst these, and other, challenges to write operationsmay occur on the user’s own system, they are more likely to occur when the user adds orupdates their data in the Cloud. Thus ESCUDO-CLOUD looks at how write operations canbe securely managed and performed in the Cloud.

Cloud architectures (d)

Single Cloud provider (d-i)This architecture covers the simpler single ESCUDO-CLOUD security scenario, where thedata is stored on one CSP, and all security functionality is implemented on the user’s systemor the CSP’s. Typically there is only one direct channel between the user’s system andCSP’s, and whilst data sharing with other users is possible in this scenario, the functionalityis more limited.


16 Introduction

Multi Cloud and federated Cloud (d-ii)This architecture covers the more complex and diverse ESCUDO-CLOUD security scenar-ios, where there is more than one CSP that may provide different services to the data owner.A federated Cloud is based on an architecture where multiple CSPs are aggregated together,but appear to the user as a single CSP, typically with a single CSP interposed between theuser’s system and the other CSPs. For the purposes of ESCUDO-CLOUD, a multi Cloudarchitecture encompasses scenarios where the security functionality is split between two ormore CSPs, for example the Security-as-a-Service is handled by one CSP or trusted thirdparty, and Storage-as-a-Service is handled by another CSP. In such a scenario there is likelyto be a three way communication between the user and the CSPs, and the user’s system isaware of the multiple CSPs and the functions they perform within the security framework.

Different architectures have different benefits and drawbacks. The nature of ESCUDO-CLOUD use cases ensures that the different architectures are effectively considered. Themore complex case of multiple CSPs can lead to additional security threats if the CSPscollude, but can offer new Cloud data security techniques, such as a) splitting data betweenthe CSPs; b) avoiding vendor lock-in; c) ensuring data availability by storing copies of thedata at multiple locations.

1.4 Requirements Analysis Methodology

D1.2 has three main objectives a) to update the association of use case requirements to workpackage tasks built in D1.1; b) to synthesize the specific use case requirements into a commonset of requirements; c) to consider the challenges posed by the use cases, and the available Cloudsecurity technologies, then, from this, explain how ESCUDO-CLOUD will help address theseCloud industry deficiencies. The purpose of the common requirements is to provide a shared setof terms and concepts across the ESCUDO-CLOUD project, and to augment the specific use caserequirements in guiding the research of the core work packages.

The methodology used to synthesize the common requirements was, 1) classifying the spe-cific use case requirements by the ten ESCUDO-CLOUD sub-dimensions, which were defined indocument D1.1; 2) further subdividing the specific requirements into logical categories, based ona synthesized common set of concepts in the requirements; 3) defining a common set of terms andconcepts; then finally 4) elaborating common ESCUDO-CLOUD requirements, that were specifi-cally stated or implied, from the categorizations and the specific use case requirements.

The comparison to current technologies analysis was performed by each use case owner a) re-viewing their specific use case requirements; b) comparing them to current Cloud industry prac-tices, techniques and research; and then c) documenting the current shortcomings, and explaininghow the ESCUDO-CLOUD research will help address them.


2. Common Terms and Concepts

Many areas of overlap exist between the different use cases, however they are described usingdifferent terms or concepts. This chapter seeks to provide a unifying framework by identifyingthese concepts and terms and defining a common description. It facilitates understanding of usecases and aids in finding commonalities between their requirements.

Many of these common concepts map directly to a set of common requirements. These com-mon requirements are identified and given a unique reference code. Each section in this chaptercontains a description of the common term and the associated reference codes at the end. For afull list of common requirements, indexed by their reference codes, see Appendix D.

The definition of the common terms and concepts are results of the requirements analysis. Themethodology used by the analysis is described in Section 1.4 and the main results are detailedin Section 4.2. The common terms and concepts are included here as they may be useful whenreviewing the use case summaries in Chapter 3.

2.1 Trust Boundary

In ESCUDO-CLOUD the trust boundary encloses a region where the user can safely trust thatcomponents, protocols and their data are secure on a remote environment outside of their directcontrol. It is assumed that the user has taken sufficient measures to secure their own system frommalicious attack1. Components, protocols and data inside the trust boundary are assumed to beverified and safe, whereas components, protocols and data outside the boundary are not. Thusdata that crosses the trust boundary must be in a form that is unintelligible to those that do nothave the privileges to it. The trust boundary is a logical construct, not a practical implementation,however the two may coincide, for example a VPN tunnel. In the security scenario diagrams thetrust boundary is represented by a dotted line.

Whilst the main focus of ESCUDO-CLOUD is ensuring the security of the user’s data-at-rest,by necessity it also considers some aspects of data-in-transit, as the data must pass from the user’ssystem into the Cloud. It is assumed that data-in-transit will pass over a secure channel, such as aVPN tunnel or SSL connection, between the user’s system and the target CSP2.

Figure 2.1 illustrates an example of the security scenarios used later in this section. The box onthe left represents the user’s system and the box on the right the CSP. The dotted line extends fromthe user’s system and into the CSP’s environment. In this scenario data is transferred between thesystems unencrypted, but over a secure communications channel. The encryption agent (discussed

1Securing the user’s system from malicious attack, or even accidental intrusion, is outside the scope of the ESCUDO-CLOUD research. The one exception is where ESCUDO-CLOUD components are installed on the user’s system froma third party, and these components need to be verifiable as trusted.

2In this context the term CSP also encompasses providers of more specialized services, such as Cloud storagesolutions.

17

18 Common Terms and Concepts

Figure 2.1: Trust boundary

later in the section) resides inside the user’s trust boundary, and is therefore assumed to be trusted.It encrypts the user’s data and passes it to the CSP for storage.

The presence of a trust boundary does not negate "defense in depth"[Sty04], where mul-tiple layers of security may offer higher levels of protection. Where appropriate, ESCUDO-CLOUD will specifically investigate defense in depth techniques, such as multi-layered encryptionschemas, to enhance the features of the security framework. Additionally the trust boundary canbe helpful in defining the attack surface of the security framework, which is useful to considerwhen performing threat analysis of a given security scenario.

Common requirements: REQ-CO-SF-1, REQ-CO-SF-3, REQ-CO-SF-21, REQ-CO-SF-22, REQ-CO-SF-29, REQ-CO-KM-10, REQ-CO-AC-11, REQ-CO-EA-11

2.2 Trusted Third Party

Other than the simple case where the user encrypts their data at source, the user must rely on aTrusted Third Party (TTP) organization to store their data securely in the Cloud. The third partymight provide Cloud security services or data storage services, as in the case of a CSP. It is notthat a CSP is inherently untrustworthy, but rather the lack of an industry wide security frameworkwithin the Cloud industry means that it is often difficult for the data owner to ensure an auditablelevel of trust when outsourcing the storage of their data. In addition the nature of the CSP’sanonymous multi-tenancy environment means that whilst the CSP might be trustworthy, theirtenants may not. A CSP’s failure to adequately vet prospective tenants opens their environment upto a potentially Malicious Third Party (MTP). These MTPs may seek to misuse their internal hosttenancy to attack the CSP or other co-hosted tenants. Thus a TTP is a third party organization thatwould pass the user’s own regulatory security audit.

Figure 2.2 illustrates an example of the security scenarios including a TTP. The box on the leftrepresents the user’s system, the box on the right the CSP and the box in the middle the TTP. Thetwo dotted lines extend from the user’s system to the TTP’s environment and from the TTP to theCSP’s environment; both routes represent secure channels between the respective systems. In thisscenario the encryption agent (discussed later in the section) resides on the TTP’s environment.This in turn implies that the TTP’s environment, including procedures, technologies, etc. havepassed a security audit commensurate with the user’s regulatory audit requirements. The CSPmay also be a TTP, if it passes the required security audits. Note that the user’s encrypted datacrosses the trust boundary in the CSP.

Common requirements: REQ-CO-SF-2


Section 2.3: Data Parts 19

Figure 2.2: Trusted third party

2.3 Data Parts

Whilst the user could store their data as a single unit, it would be accessed and transferred as awhole, this would be inefficient and not facilitate fine grained access to parts of the data. Moretypically the user’s data is divided into logical parts, such as files, objects, rows, etc., and it is thesedata parts that are individually accessed.

Common requirements: REQ-CO-SF-30, REQ-CO-EA-2

2.4 Data Obfuscation

To ensure the confidentiality and integrity of the user’s data on a untrusted environment, the datamust be made incomprehensible to an unauthorized observer3, which can be termed as data ob-fuscation. Typically data obfuscation is achieved by applying a cryptographic algorithm4 to thedata to encrypt it. However there are other techniques to achieve data obfuscation, such as datafragmentation, which is investigated by ESCUDO-CLOUD.

Data fragmentation is a technique to perform data obfuscation by splitting the data into dif-ferent parts, where each part can be stored in plain text but is of no value in itself5. Only thelinkage between the parts can render the data intelligible, and like encryption keys, these linkagesare stored in a secure location. To give a banking example, the fact that John has a bank account,number 900354, and a balance of C100, is sensitive data; but without the associations between thedata fragments, John, 900354, and C100 are of little value.

The use case requirements focus primarily on encryption as the data obfuscation technique,but in theory data fragmentation could be used to replace or complement data encryption.

3In practice this means that the CSP, or other untrusted third party, can’t view or modify the users data in plain text.4Data at rest is usually encrypted with a symmetric key as a) symmetric algorithms are more efficient; b) the same

system is responsible for encrypting and decrypting the data, and therefore has access to the same key.5Typically the data fragments are stored on separate CSPs, so attempts to reconstruct the data from its parts are

hampered.


20 Common Terms and Concepts

Figure 2.3: Three basic components

Figure 2.4: Distributed components

2.5 ESCUDO-CLOUD Security Framework

The ESCUDO-CLOUD Security Framework, or simply the security framework, is the collectionof components and protocols that form the practical implementation of the ESCUDO-CLOUDmiddleware. Two of the basic framework components are the key manager and access controllerservices, sometimes collectively referred to as the policy framework. A third basic service is theencryption agent6, which handles the encryption and decryption of the user’s data. Icons thatrepresent the three security framework components are illustrated in figure 2.3.

The key manager a) stores the data encryption keys; b) handles their distribution within thesecurity framework; c) manages their lifecycle. The access controllera) defines the users and theiraccess rights to the data; b) holds metadata on the data or data parts, such as location and datadigest [Rea92]; c) maintains policies or rules that manage the lifecycle of the data or data parts,such as automatic deletion at a given date.

Whilst these components are not novel to ESCUDO-CLOUD, their incorporation in a securityframework for securing the user’s data in the Cloud is. The components reside either on theuser’s system or within the framework’s trust boundary. The security framework will typicallyhave at least one instance of each component, however different use case implementations mayrequire multiple instances of a given type. For example if the encryption process is split acrossmultiple CSPs, an encryption agent would be required on each CSP. Multiple components of thesame type may also be configured in a parent/child relationship, where one component is themaster coordinating the activities of the children. For example a master key manager distributedkeys to subordinate key managers, to improve key retrieval performance. The security frameworkcomponents may be tightly integrated and packaged as a single unit, or packaged separately andbe located on distributed systems. For example the key manager and access controller may resideon the user’s system, but the encryption agent may reside on the CSP, as illustrated in figure 2.4.

If the components are packaged as a single unit, their interactions can be considerably simpli-fied. For example the access controller can directly retrieve the required key from the key manager.If the components are located on different systems, they would be required to exchange control

6The encryption agent is applicable where data obfuscation is achieved by encrypting the data, which is the currentnorm. If another data obfuscation technique is used, such as data fragmentation, another type of agent would berequired.


Section 2.5: ESCUDO-CLOUD Security Framework 21

messages to coordinate their operations so that the security framework functions as a whole.To simplify the security diagrams in the following subsections, the control messages and key

distributions are sometimes omitted.

Common requirements: REQ-CO-SF-1, REQ-CO-SF-19, REQ-CO-SF-20, REQ-CO-SF-23, REQ-CO-KM-1, REQ-CO-KM-2, REQ-CO-KM-5, REQ-CO-AC-10, REQ-CO-EA-1


3. Use Cases

This chapter summarises the four use cases defined for ESCUDO-CLOUD, followed by theiritemized requirements, and is taken from project deliverable D1.1. Document D1.1 also pro-vides a more detailed explanation of the use cases. The four use cases cover the following areasa) facilitating user data security in the OpenStack framework; b) managing secure data sharing indatabases; c) secure federated data storage in the Cloud; d) secure user data storage in an elasticCloud environment. Each use case was defined by an industrial partner a) IBM; b) SAP; c) BT;d) WT.

The techniques researched and developed by ESCUDO-CLOUD will be applicable in manyparadigms of data protection in the Cloud service, as demonstrated by the above use cases, al-though their realisation may take the form of diverse implementations resulting in different solu-tions addressing the specific requirements of different use-cases. For example, the first use-casefocuses on enhancing open source Cloud platforms with built-in data protection capabilities, whilethe second use case focuses on the improvement of data protection for Cloud-based data-sharingapplications and platforms. In both cases the data protection is essentially governed by the Cloudinfrastructure, platform or data-base service provider. In contrast, the third use-case focuses onprotecting data hosted on multiple Cloud platforms at the infrastructure or hosted application levelwhile shifting the governance of the data protection and data access management off the Cloudinfrastructure to the data owner assisted by a security service that is independent of any Cloudinfrastructure. While the fourth use-case is about an intermediary building an elastic, Cloud-basedsecure storage and data synchronisation service by leveraging 3rd party Cloud infrastructures anddata storage services while the intermediary assures and governs the data protection independentlyof the Cloud hosts.

The technologies and tools developed as part of ESCUDO-CLOUD will be validated throughtheir deployment to the four use cases. Each use case represents a real world problem definedby one of the industrial partners, and considers user security challenges in the Cloud that are notcurrently addressed by existing technologies. The use cases cover a diverse set of application do-mains, which provide a rich set of scenarios that will encourage novel solutions to be developedas part of ESCUDO-CLOUD. Whilst all the use cases have the same common theme of securingthe users data in the Cloud, they will approach different aspects of the problem, which will en-able ESCUDO-CLOUD to develop a broad range of novel solutions to the challenges, as well asexploiting them in the specific use cases.

3.1 Use Case 1: OpenStack Framework (IBM)

The OpenStack data-at-rest encryption use case, which is driven by IBM, provides an excellentopportunity to demonstrate some of the key technologies developed by ESCUDO-CLOUD. Thescenario of this use case relates to a Cloud-storage platform, which supports server-side encryption

22

Section 3.1: Use Case 1: OpenStack Framework (IBM) 23

with flexible key-management solutions. As such this use-case is particularly applicable for thedevelopment of internal Cloud solutions as well as for CSPs building private or public Cloudsolutions using open source frameworks such as OpenStack. In particular, it consists of data-at-rest encryption and key management solutions, to be used with OpenStack Swift, an object-storage system that runs on commodity hardware and provides failure resilience, scalability, andhigh throughput in software. Encryption occurs on the server side under the governance of thestorage provider; encryption inside the storage platform is an important feature for large-scaleand enterprise-class storage systems. Coupled with a suitable key-management solution that isable to control and securely erase cryptographic keys, the encryption technology also supports thecontrolled destruction of data, which is called secure data deletion here. Data-at-rest encryptionand secure deletion are important requirements for enterprise-level Cloud storage services.

The goal of this use case consists of adding cryptographic protection technology inside a pri-vate Cloud platform, in particular, to storage systems. Clients of Cloud services and operators ofthe CSPs benefit from data encryption in the storage systems, so as to make the system resistantto attacks that target lower layers of the infrastructure.

From Work Package 2, Task 2.1 (Protection of data at rest), and Task 2.2 (Key-managementsolutions), the main expected results will consist of technologies to protect the confidentiality andthe authenticity of the stored data. In particular, methods for encryption and integrity verificationwill be applied in the context of the OpenStack Cloud platform and demonstrate how the methodsof ESCUDO-CLOUD can lead to more security in Cloud platforms. Furthermore, the secure dele-tion of data will be supported and demonstrated in the OpenStack Cloud storage platform. Thistechnology will highlight one of the main features offered by the ESCUDO-CLOUD key man-agement approach. Figure 3.1 shows the overview of the Use Case 1 trust boundaries, with onlythe data owner being the trusted entity and the data being encrypted at rest on a single OpenStackbased CSP.

data owner

outsourcing

outsourcing

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

data access

Figure 3.1: Overview of the Use Case 1 trust boundaries

From Work Package 3 (Information sharing in the Cloud), Task 3.2 (Secure multi-user inter-actions and sharing), the technology to guarantee integrity and consistency of data accessed bymultiple users will be demonstrated through OpenStack Cloud storage. This novel technology


24 Use Cases

protects data that is shared and concurrently accessed by multiple clients from being altered ormodified. Showing this enhancement in the OpenStack Cloud storage platform represents a keystep to promoting and exploiting this result.

Taken together, the technology demonstrated in use case 1 aims at the business goals of pro-tecting against insider attacks, ensuring compliance with legal regulations, and increasing the valueof the storage service in response to customer demand. This directly supports the main approachof ESCUDO-CLOUD.

A wide subset of IBM’s storage and Cloud storage offerings and products make use of theOpenStack framework. This framework does not yet have some of the required enterprise-gradefeatures. Thus, applying this technology to extend the OpenStack framework with cryptographicprotection, and to offer enterprise-grade services to its customers is an important competitive fea-ture in the market.

Req. Ref. DescriptionREQ-UC1-IKM-1 The system supports CRUD operations for cryptographic keys and re-

lated cryptographic material, which is used in the Cloud infrastructure.REQ-UC1-IKM-2 Deployment and management of infrastructure keys is driven by policies

and automated, to the extent possible.REQ-UC1-IKM-3 The Cloud infrastructure-key management system supports the relevant

open standards that are used by the industry (OASIS KMIP for RESTAPIs and possibly OASIS PKCS #11 for interfaces to secure hardwaremodules).

REQ-UC1-IKM-4 The Cloud infrastructure-key management system supports the securedeletion of cryptographic material.

REQ-UC1-TKM-1 The system supports CRUD operations for cryptographic keys and re-lated cryptographic material, which is used by a tenant.

REQ-UC1-TKM-2 Deployment and management of tenant keys is driven by policies andautomated, to the extent possible.

REQ-UC1-TKM-3 The Cloud tenant-key management system supports the relevant openstandards that are used by the industry (OASIS KMIP for REST APIsand possibly OASIS PKCS #11 for interfaces to secure hardware mod-ules).

REQ-UC1-TKM-4 The Cloud tenant-key management system supports the secure deletionof cryptographic material.

REQ-UC1-SKM-1 Key-management systems can be operated in a redundant and fault-tolerant way and do not introduce any single point of failure.

REQ-UC1-SKM-2 Key-management systems do not limit the scalability of the Cloud plat-form. They must either be offered with large enough throughput or theymust be scalable on their own.

REQ-UC1-SKM-3 Key-management systems can cope with the weak forms of consistencyfound in Cloud platforms such as OpenStack. In particular, the key-management systems provide support for eventual consistency of theunderlying operations in the Cloud platform.

Table 3.1: Use Case 1 Requirements


Section 3.2: Use Case 2: Secure Enterprise Data Management in the Cloud (SAP) 25

3.2 Use Case 2: Secure Enterprise Data Management in the Cloud(SAP)

This aerospace engine MRO use case is particularly suited for ESCUDO-CLOUD. On the onehand there is a clear data sharing requirement best managed in the Cloud and on the other handthe data to be exchanged is highly sensitive, possibly even personally identifiable.

SAP considers the specific use case of outsourcing the supply chain interactions in the aerospaceengine maintenance industry. So called MRO providers offer their services to several airlinesleveraging cost savings by streamlining the process. In general, two main business-optimizingservices have to be guaranteed in the aero engine overhaul supply chain: the CF and the CPSof the overhaul activities. The first one allows MRO service providers to obtain demand forecastsfrom all customers based on on-condition engine status observations, reducing so overall costs dueto a more accurate capacity planning; while the collaborative planning and scheduling guaranteesbetter supply chain performance, since an ideal receipt point for each engine can be computed.

Traditionally, each party on each stage of the supply chain has its rather isolated forecastingprocesses which are mainly based on data of historical demand that arose from their direct cus-tomers. The problem with these orders from the next stage is that they are again results of anisolated forecast and in general don’t match the actual sales on the buyer’s stage. Instead, theytend to have a larger variance. This effect of demand distortion results in amplified forecastingnumbers and dramatic swings in demand increasing with every step on the supply chain furtheraway from the end customer. This phenomenon is known as the bullwhip effect.

However, this information does exist, and CF is an attempt to bring them together to createa single, more accurate forecast which is accepted by all collaborating members of the supplychain. In a collaborative forecasting process ideally all supply chain members add their particularexpertise and information to find the best possible forecast. The information about end customerdemand is shared with the upstream supplier, so demand distortion can be reduced drastically.This again will drastically reduce the bullwhip effect.

A central issue for maintenance and support service providers concerns the management of thegrowing amount of information generated by the development of highly complex aircraft systemsand by stakeholders’ requirements in terms of dependability increase and LSC decrease. To facethese problems, maintenance and support actors are depending more and more on ICT solutions.These are one of the main elements not only to improve the effectiveness and efficiency of themaintenance process for complex systems with a long lifecycle, but also to reduce the associatedrisks and to contribute to a more efficient business process. The benefits linked to the use of ICTsystems in this business segment are:

• More controlled content sharing;

• Information exchange and knowledge management;

• Coordination of maintenance process with other processes;

• Connection to strategic business objectives and external stakeholder requirements.

The technological challenge of this use case is to develop new supply chain cooperation sys-tems, based on encrypted database technology. This technology is based on the search and aggre-gation of encrypted data and can be applied in planning the MRO service to different customers


26 Use Cases

without knowing the actual status of the aero fleet nor the capacity usage of the service provider,nor the inventory status.

Supply chain collaboration is the alignment of individual plans and strategies of the involvedparties. The stronger coordination and the overcoming of information asymmetries with partnersshall conduce to improvements of the supply chain performance. Additionally, the uncertain-ties in demand may be reduced by taking into account interactions at other levels of the supplychain. Better knowledge of the downstream demand enables the customer to facilitate the ven-dor’s predictability skills concerning his production and delivery capacities by providing him withappropriate data. Reduced inventory and hence lower costs are potential benefits for the partners.

We have to consider the following data sharing risks:

Loss of information advantageDisclosing sales information to other organizations may change relationships among part-ners in a supply chain, since it may reduce the ”information rents” effect for which especiallya weak partner profits;

Reconstruction of strategic decisionsSharing of data increases the visibility of operations for all companies involved; thus ifconfidentiality is not preserved, a competitor could anticipate company’s future plans;

Development of a competitive product/serviceWith the knowledge of suppliers, competitors can develop new competitive products or offermore competitive services;

Weakening of the bargaining power after disclosure of purchase or supply volumeA customer may compare its own purchase volume to that of other customers in order tocalculate its share; such information can be used to strengthen its bargaining power. In thesame way, suppliers can calculate their share of overall supply; this information increasestheir power over the customer in a business negotiation.

ESCUDO-CLOUD is ideally positioned to help overcome these risks. Using ESCUDO-CLOUD technology, e.g. developed in the context of WP3, allows data protection in the Cloudwhile still enabling data sharing. These are the types of solution required for the future adoptionof the use case. Figure 3.2 shows the overview of the Use Case 2 trust boundaries, with the dataowner and users being the trusted entities and the data is encrypted in a database on a single CSP.

The main technical functionality of this use case is to calculate the total forecasts for thefuture overhaul demand. The process can be broken down in two major steps. In the first step theindividual demand forecast is estimated. The calculation for this is to be applied on the encryptedusage data of each customer. The second step in the process is the secure aggregation of theinterim results. We want to compute a sum which would be straightforward if the interim resultswere centrally available in plaintext. They are, however, sensitive data for each customer and werequire a secure aggregation protocol across different keys.

To grant or restrict shared data access to MROs and airlines processing unencrypted queryresults, data owners have to implement additional fine-grained access control mechanisms. Imple-menting such a multi-user mode using encrypted query processing for a single user operating withone key combined with an additional authorization step at the application server can be compro-mised: Assume that a user working for the data owner and a service provider’s employee collude.


Section 3.2: Use Case 2: Secure Enterprise Data Management in the Cloud (SAP) 27

data owner

outsourcing

outsourcing

data access

data access

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

data accessdata access


If the user knows the decryption key of the data and the employee provides the encrypted datastored in the database, they are able to decrypt all data bypassing the access control mechanisms.

For use case 2 the following ESCUDO-CLOUD dimensions are important and can be furtherdetailed:

Security propertiesConfidentiality and integrity of access control decisions are very important. An access de-cision should not be delegated to the Cloud provider.

Sharing requirementsData is supposed to be shared in a selective manner with others.

Access requirementsFine-grained access as in a relational database system and data may be added, but alsosometimes updated or deleted.

Cloud architecturesThe use case is initially targeted for a Single-Cloud architecture as found in most businessapplication.

Req. Ref. DescriptionREQ-UC2-AC-1 Access control decisions should be based on the subject of a client,

i.e. the subject granularity is a client. It is at the discretion of a clientwhether he intends to enforce finer-granular access control, e.g. at thelevel of the user. This can be either achieved by increasing the num-ber of clients (at the corresponding performance penalty) or enforcingregular access control at the database driver.

REQ-UC2-AC-2 It should be possible to group several users into a group and grant orrevoke access for the entire group.


28 Use Cases

REQ-UC2-AC-3 Access control decisions should be based on the object of a databasecell as identified by a column (in a table) and a row owner. It should bepossible to group several cells (in the same column) for the same accessrights.

REQ-UC2-AC-4 The access control model should be an access control matrix. Advancedmodels, such as role-based access control or attribute-based access con-trol, are initially out-of-scope. These advanced models can be mappedinto the access control matrix using additional tools, but these are alsoinitially out of scope.

REQ-UC2-AC-5 Access control rights should be grantable and revocable by the databaseadministrator with support of the data owning clients. A grant or revokeoperation is triggered by the database administrator, but the necessaryadaptions, such as the revelation of a key or the re- encryption of datamust be performed by a client. Revoking operations are supposed to beinfrequent.

REQ-UC2-AC-6 Access control should be enforced by the client, i.e. cryptographicallyenforced. Access control should not be entrusted to the CSP. The in-tegrity of access control decision is of the utmost importance to theclients. The clients should stay in control of their data.

REQ-UC2-KM-1 Each client should have its own key generated and kept confidential atits site. This key is not supposed to be shared. From its master key otherkeys for access to finer-granular objects (such as a database column)may be derived.

REQ-UC2-KM-2 There should be keys for access by groups. These keys are shared bygroups of clients to access common data. From these keys other keysfor access to finer-granular objects (such as a database column) may bederived.

REQ-UC2-KM-3 Client keys should be stored securely, e.g. in a secure key store(PKCS#12) protected by a password. Additional mechanisms such ashardware security modules are initially optional.

REQ-UC2-KM-4 Group keys may be derived using a public key hierarchy stored at theCSP. This is a low priority feature.

REQ-UC2-EQ-1 The database should support different encryption schemes for differ-ent database operations. Notably, the database should support order-preserving encryption for range and rank queries, deterministic encryp-tion for equality selection/joins, and grouping, probabilistic encryptionfor retrieval and count operations and additively homomorphic encryp-tion for summation. The additively homomorphic database operator re-quires a change in implementation, since addition needs to be replacedby modular multiplication. This needs to be supported. Other databaseoperations may be adapted simply by adapting the type.


Section 3.3: Use Case 3: Federated Secure Cloud Storage (BT) 29

REQ-UC2-EQ-2 The encryption should be adjustable to the database operations per-formed. Probabilistic encryption is more secure than deterministic en-cryption which is more secure than order-preserving encryption. Yet,order-preserving encryption enables strictly more database operationsthan deterministic encryption which enables strictly more database op-erations than probabilistic encryption. Hence, we wrap an order-preserving encryption in a deterministic encryption wrapped in a prob-abilistic encryption. Depending on the functionality needed by a querywe decrypt to appropriate layer. Order-preserving encryption will al-ways be maintained.

REQ-UC2-EQ-3 In order to adjust the encryption and operate on different keys we need toanalyze and evaluate the query differently. The database driver should atleast support three different query evaluation techniques: query rewrit-ing, proxy re-encryption and post-processing. Query rewriting shouldbe able to encrypt parameters under the different keys and split thequeries over multiple tables, one for each access group. The resultshould be combinable. Proxy re-encryption should be able to adjust thekeys of different columns for comparison, e.g. in an equality join acrossdifferent access groups. This may entail a new proxy re-encryptionscheme. Post-processing should support combining query result of dif-ferent keys, e.g. aggregations under different keys in additively homo-morphic encryption. Post-processing should also enable processing se-quential operations with incompatible encryption schemes, such as sort-ing a homomorphic encryption.

REQ-UC2-EQ-4 All database operations should be supported across different client keys,i.e. spanning multiple access groups.


3.3 Use Case 3: Federated Secure Cloud Storage (BT)

This use case considers the application of data protection in Multi-Cloud environments includingfederated secure Cloud storage. It will offer data protection as a service via a Cloud servicestore that enables customers to protect their data stored on multiple Cloud platforms. As suchthis use case is particularly applicable for Managed Security Service Providers and for Cloud userorganisations who want to control the protection of data at rest across multiple Cloud environmentsand apply uniform data protection and data access policies for heterogeneous data stored in amultiplicity of Cloud providers (including internal, private and public Clouds).

The data is protected by leveraging a Cloud-based data protection service for encrypting inde-pendently of the Cloud provider hosting it, and ensuring that CSPs have no access to the encryptionkeys or its protection and access control policies. The encrypted data can be stored on multipleCloud storage services like block storage, object stores and Big Data clusters. Access control andkey management are offered as tightly coupled services that manage the protection of the data


30 Use Cases

data owner

outsourcing

outsourcing

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

data access

ESCUDOCLOUD

ESCUDOCLOUD

outsourcing


via an integrated policy framework. This tight integration will ensure that the decryption of theprotected data is only possible in the client’s environment following a policy-based approval pro-cedure and the resulting release of the encryption key. The encryption and decryption process willbe transparent to applications and end-users while the data-at-rest will always stay in encryptedstate on the multiple Cloud platforms, in compliance with specific data security standards andregulations.

The core deliverable of the Data Protection as a Service use case is to ensure the confidentiality,integrity and availability of the customer’s data, which is enforced by using client-side encryptionapproach. In addition to this core responsibility, the access and usage of the key management andaccess control features is also directly relevant to the ESCUDO-CLOUD security properties. Thekey challenge addressed by ESCUDO-CLOUD here is to offer the key management feature andthe policy-based access control feature as a service through a Cloud service store. The instanceof a key management service and the access control service have to be tightly coupled for eachcustomer, which will allow them to specify key release rules that are applicable only under specificconditions. Figure 3.3 shows the overview of the Use Case 3 trust boundaries, with only the dataowner being the trusted entity and the data is encrypted on different types of storage medium onmultiple CSPs.

Furthermore, two of the sharing requirements of ESCUDO-CLOUD have to be catered forby this use case. The first is the simpler situation where only the customers have access to theencryption keys and thus no one else, especially the CSPs, has the ability to read the plaintextdata. The second is a more complex situation where the customers can make their data availableto others by sharing the keys and modifying access control policies.

It is also relevant from the perspective of ESCUDO-CLOUD access requirements, as it hasto provide the customers with the means to access and retrieve their data from different types ofCloud-based storage services, e.g., block storage, object storage and Big Data services. This alsoincludes the domain aspects of controlling access to the data through policy based security rulesthat enforce the release of keys.

The last point of relevance to the ESCUDO-CLOUD effort is the operation of the use case ina Multi-Cloud environment, providing the ability of selectively using different CSPs.


Section 3.3: Use Case 3: Federated Secure Cloud Storage (BT) 31

Req. Ref. DescriptionREQ-UC3-KM-1 Each tenant should be provisioned with an instance of a key manage-

ment service from the Cloud service store. Each tenant is given a uniqueidentifier at the time of the tenant account creation and the same identi-fier is used across the components of the data protection solution to iden-tify and reference a tenant. Each tenant account has further (at least one)administrator accounts that are used to manage the tenants instances ofkey management, access control, and data storage and encryption ser-vices.

REQ-UC3-KM-2 The tenants should be able to generate, modify and remove keys fromtheir key management service instance. The modification is limited tospecific attributes of a key e.g., the expiry date.

REQ-UC3-KM-3 The key management service should be able to offer different key typesand generation algorithms to each tenant, e.g., AES128, AES256, 3DESetc.

REQ-UC3-KM-4 Only the tenants should be able to create and manage the keys. Thisshould be enforced by safeguarding access to the tenant’s instance of thekey management service with a robust authentication and authorisationmechanism.

REQ-UC3-KM-5 The CSPs should have no access or visibility of the tenants’ keys. Thisshould be enforced by ensuring that the key store used by the tenant’skey management service is not hosted on untrusted platforms or CSPs.Furthermore, keys can only be released from the key store if they passthe access control checks associated with them.

REQ-UC3-KM-6 The tenants should be able to cache their keys on trusted virtual ma-chines or gateways in order to outsource or improve performance of theencryption and decryption process. The encryption and decryption pro-cess should be carried out by a software agent or plug-in that has beenprovisioned on the trusted virtual machine by the service store. The keysshould only be cached for the duration of the encryption or decryptionprocess and should not be present on the virtual machine or the gatewaywhile the data is at rest.

REQ-UC3-AC-1 Each tenant should be provisioned with an instance of an access controlservice from the Cloud service store. Each tenant is given a unique iden-tifier at the time of the tenant account creation and the same identifieris used across the components of the data protection solution to identifyand reference a tenant. Each tenant account has further (at least one) ad-ministrator accounts that are used to manage the tenants instances of keymanagement, access control, and data storage and encryption services.

REQ-UC3-AC-2 The tenants should be able to create, delete and modify access controlpolicies from their instance of the access control service.


32 Use Cases

REQ-UC3-AC-3 The access control service should be able to offer use of different systemand data attributes for the construction of a security rule, e.g. filesys-tem, user, application, and time attributes. Each access control policycan be comprised of a collection of security rules to offer and modularapproach.

REQ-UC3-AC-4 Only the tenants should be able to create and manage their access controlpolicies. This should be enforced by safeguarding access to the tenant’sinstance of the access control service with a robust authentication andauthorisation mechanism.

REQ-UC3-AC-5 The CSPs should have no access or visibility of the tenants’ keys. Thisshould be enforced by ensuring that the policy manager and the policydatabase used by the tenant’s access control service is not hosted onuntrusted platforms or CSPs.

REQ-UC3-AC-6 All data protection operations should be governed by access controlpolicies by either approving or denying access to the required keys. Theclient-side encryption agent or plug-in should be able to request the ac-cess control service for issuing it with the encryption key. The requesthas to include the attributes that are present in the security policy so thatthe access control service can evaluate the request conditions and takeaction to either release the key or deny the request.

REQ-UC3-AC-7 The access control service of tenants should be tightly coupled withtheir key management service, such that no key can be utilised withoutan approving access control policy.

REQ-UC3-SO-1 Each tenant should be provisioned with a Cloud service store account.Each tenant is given a unique identifier at the time of the tenant accountcreation and the same identifier is used across the components of thedata protection solution to identify and reference a tenant. Each tenantaccount has further (at least one) administrator account, used to man-age the tenants instances of key management, access control, and datastorage and encryption services.

REQ-UC3-SO-2 The service store should provide the tenants with access to the storageservices of multiple Cloud service providers. This should be done bycreating transparent access profiles of each CSP so that the tenant doesnot have to perform Cloud provider specific authentication and accessprocedures.

REQ-UC3-SO-3 The service store should be able to offer block storage service to thetenants. The tenants should be able to specify the size, format etc. of theblock storage and attach it as a data volume with their virtual machines.

REQ-UC3-SO-4 The service store should be able to offer object storage service to thetenants. The tenants should be able to specify the object buckets’ namesand other properties and be able to provision it for the use of the end-users.

REQ-UC3-SO-5 The service store should be able to offer Big Data storage service(HDFS) to the tenants. The tenants should be able to provision the con-figured HDFS cluster for the use of the end- users.


Section 3.4: Use Case 4: Elastic Cloud Service Provider (WT) 33

REQ-UC3-SO-6 The tenants should be able to enable or disable the use of data protectionservice on the storage service of their choice.

REQ-UC3-SO-7 The service store should be able to offer key management as a service tothe tenants. This is a pre-requisite for the KM feature described above.

REQ-UC3-SO-8 The service store should be able to offer access control as a service tothe tenants. This is a pre-requisite for the AC feature described above.

REQ-UC3-DE-1 The core encryption process should only be controlled and managed bythe tenant. It should be transparent to the end-user and only the tenantshould be able to specify the target storage services where the encrypteddata has to be stored.

REQ-UC3-DE-2 The tenant should be able to deploy and manage the core encryptionprocess on trusted virtual machines or gateways as an agent or plug-in.This should be done via the use of the service store’s interface to theassociated CSP where the target virtual machine or gateway is hosted.

REQ-UC3-DE-3 The core encryption process should be FIPS 140 compliant.REQ-UC3-DE-4 The encryption agent or plug-in should be able to access the tenant’s key

management service and access control service. This should be done byenabling it to connect to these services over an encrypted channel usingprotocols like SSL/TLS.

REQ-UC3-DE-5 The keys should only be released to the encryption agent or plug-inupon approval of an access control policy. The encryption operationshould only be performed after the policy authorising the encryptionhas been met and the associated key has been released by the accesscontrol service.


3.4 Use Case 4: Elastic Cloud Service Provider (WT)

This use case considers the use of an elastic CSP. As such this use-case is of particular relevancefor Cloud service brokers or intermediaries offering a secure Cloud data storage capability to theircustomers while possibly leveraging other Cloud providers for storing this data and ensuring thatdata is protected from such other Cloud providers and other users.

In this use case scenario a data owner has access to his/her files stored in the Cloud usingsome middleware available on the client (web portal or agent). The middleware will enable thecommunication between the end user and the CSP. Furthermore, by using an elastic Cloud, itwill be possible to adapt the capacity of the Cloud to the requirements of the user. Additionally,by using the ESCUDO-CLOUD middleware with an elastic Cloud, the encryption provided byESCUDO-CLOUD will be present in the third party Cloud too (so, ESCUDO-CLOUD will bepresent for all data transfers).

With the ESCUDO-CLOUD middleware, the users would have secure access to their datahosted by the Cloud providers such that the data is not compromised. They will also be able tomanage their data from a web browser or an agent (installed in their devices). Finally, it will be


34 Use Cases

possible to synchronize stored files from third-parties like Google Drive or Dropbox. So, by usingESCUDO-CLOUD the users will be able to leverage the Cloud services that they would typicallyrequest from a CSP but with a higher level of security, access control and assurance.

The current typical usage of Cloud services involves continuous operations on sensitive data.Though data at rest may be stored encrypted (and therefore securely), when it is operated on, itmust be decrypted. This constant encryption and decryption of user data means that the decryptionkey is present in RAM somewhere. It may be in the OS, it may be in the Data Base ManagementSystem, or it may even be in the application itself. This means that a user with access to a sys-tem inside the CSP can access the database decryption key, or potentially even the unencrypteddatabase contents, from the RAM, or ’working memory,’ of the computer. As a result, the ro-bustness of the database encryption scheme becomes nearly irrelevant and would likely not haveposed a substantial barrier to someone with the capability to circumvent authentication protocolsin the first place. Figure 3.4 shows the overview of the Use Case 4 trust boundaries, only the dataowner and the data users are the trusted entities and the data is encrypted on file storage serviceson multiple CSPs.

data owner

outsourcing

outsourcing

data access

data access

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

data access data access

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

ESCUDOCLOUD

outsourcing

data access

data access

data access


Opinions vary on how and where to use encryption in the Cloud. Regardless of the approach,key management remains a challenge as businesses walk a fine line between trust and controlbetween their own organization and the CSP. Some CSPs combine powerful data encryption withpatented homomorphic split-key encryption technology to increase security and protect keys. Onepart of the key is hosted by the CSP, while the second part, the master key, is held by the customer.The result is that customers control their data and do not need to trust anyone else with their keys.This technology easily encrypts any disk or data storage unit with proven encryption algorithmssuch as AES-256 and makes it safe from hackers, unauthorized access, competitors, and otherthreats.

Use Case 4 not only encrypts all data files stored on the CSP, but also offers a uniform userinterface, irrespective of what CSP is being used. Furthermore, the middleware will be responsible


Section 3.4: Use Case 4: Elastic Cloud Service Provider (WT) 35

of the decryption of the data files when the user, with the correct privileges, accesses them (througha web browser or with an agent).

Req. Ref. DescriptionREQ-UC4-AC-1 Each user should have a unique username and password to enter in the

system through a web portal. The user will login in the middlewareusing his credentials, and only with them will be able to access his/herstored data files.

REQ-UC4-AC-2 By using the agent, it should be possible to remember the credentials.When a user accesses for the first time the agent installed in his device(computer, mobile...) he will login with his username and password, buthe should not need to introduce them again.

REQ-UC4-AC-3 Each user will have a unique username/password to login to the middle-ware. The middleware will control what data the user can access andwhat operations the user can perform on that data. For example, a userwith read privileges should not be able to modify a data file.

REQ-UC4-AC-4 Only the file owner should be able to authorize another user for readingor modifying his data files, that is to say that the file owner will assignthe role of the rest of the users.

REQ-UC4-AC-5 Only the administrator of the system (the ESCUDO-CLOUD middle-ware) should be able to enable the access of a locked user. This is aprerequisite for the REQ-UC4-AC-6.

REQ-UC4-AC-6 Each user should have a limit of attempts to access the system. Forexample, if a user introduces five wrong credentials, he will be locked.

REQ-UC4-SS-1 The Cloud (or storage service) should have capacity enough to store thedata files of the users.

REQ-UC4-SS-2 The storage services should be accessible for the end users throughESCUDO-CLOUD middleware.

REQ-UC4-SS-3 By using an elastic Cloud should be possible to adapt the capacity ofthe Cloud to the user requirements. It is a pre-requisite for the requisiteREQ-UC4-SS-1.

REQ-UC4-SS-4 The storage service should comply with ”EU Directive 95/46/EC - TheData Protection Directive” The personal data is defined under Article 2a: ”personal data shall mean any information relating to an identifiedor identifiable natural person (”data subject”); an identifiable person isone who can be identified, directly or indirectly, in particular by refer-ence to an identification number or to one or more factors specific to hisphysical, physiological, mental, economic, cultural or social identity”.This is a pre-requisite for the requisite REQ-UC4-SS-5.

REQ-UC4-SS-5 The CSP should implement appropriate technical and organizationalmeasures to protect personal data against accidental or unlawful destruc-tion or accidental loss, alteration, unauthorized disclosure or access, inparticular where the processing involves the transmission of data over anetwork, and against all other unlawful forms of processing. This is apre-requisite for the Data Encryption requirements below.


36 Use Cases

REQ-UC4-DE-1 The files should be stored encrypted. Only the user with the correct priv-ileges will be able to decrypt the information, not even the administratorof the server will be able to access the content of the user data files. Thisis a pre-requisite for REQ-UC4-DE-2 and REQ-UC4-DE-3.

REQ-UC4-DE-2 The data files should remain encrypted on the CSP until the user ac-cesses them through a web browser.

REQ-UC4-DE-3 The data files should remain encrypted on the CSP until the user syn-chronizes the server with the agent installed on his device.

REQ-UC4-DE-4 An end user should be able to securely download a data file from theCSP through the web browser. To fulfil this purpose, the CSP shouldhave enough capacity to make an ”on flight decryption”.



4. Requirements Analysis

This chapter covers the first two sets of results from the requirements analysis a) the mapping ofthe use case requirements to the core ESCUDO-CLOUD work package tasks; and b) the synthesisof the common requirements from the individual use case requirements. The methodology forsynthesizing the common requirements was described in Section 1.4. The analysis was based onthe initial definition of the use case requirements, and their associated core work package tasks,drawn from document D1.1.

4.1 Use Case Requirements to Work Package Tasks

This section presents a continuation of the work started in document D1.1, and shows the map-pings of the use case requirements to the core ESCUDO-CLOUD work package tasks, and viceversa. The mapping of tasks to requirements is shown in Table 4.1, and the reverse mapping fromrequirements to tasks is shown in Table B.1 in Appendix B, which also provides additional de-pendency and priority information. In consultation with the use case owners, the mappings ofrequirements to tasks was reassessed as part of the analysis process, and some have been amendedfrom the originals set out in document D1.1.

Note that the mapping from requirements to tasks is a many-to-many relationship, meaningthat multiple requirements map to multiple tasks and vice versa. For brevity, the description ofthe use case requirements and associated sub-dimensions have been omitted, but can be crossreferenced using Appendix C and Appendix D .

Work Package Task Requirements ReferenceWork Package 2 Task 2.1 REQ-UC1-IKM-1, REQ-UC1-IKM-2, REQ-UC1-IKM4,Protection of data at rest REQ-UC1-TKM4, REQ-UC2-AC-1, REQ-UC2-AC-6,

REQ-UC3-DE-1, REQ-UC3-DE-3, REQ-UC4-SS-4,REQ-UC4-SS-5, REQ-UC4-DE-1, REQ-UC4-DE-2,REQ-UC4-DE-3

Work Package 2 Task 2.2 REQ-UC1-IKM-1, REQ-UC1-IKM-2, REQ-UC1-IKM-3,Key-management REQ-UC1-TKM-1, REQ-UC1-TKM-2, REQ-UC1-TKM-3,solutions REQ-UC1-SKM-1, REQ-UC1-SKM-2, REQ-UC1-SKM-3,

REQ-UC2-AC-2, REQ-UC2-AC-5, REQ-UC2-AC-6,REQ-UC2-KM-1, REQ-UC2-KM-2, REQ-UC2-KM-3,REQ-UC2-KM-4, REQ-UC3-KM-1, REQ-UC3-KM-2,REQ-UC3-KM-3

Work Package 2 Task 2.3 REQ-UC2-AC-3, REQ-UC3-KM-4, REQ-UC3-KM-5,Efficiency and private REQ-UC3-AC-1, REQ-UC3-AC-2, REQ-UC3-AC-3,data access REQ-UC3-AC-4, REQ-UC3-AC-5, REQ-UC3-AC-6,

37

38 Requirements Analysis

REQ-UC3-AC-7, REQ-UC3-DE-1, REQ-UC3-DE-2,REQ-UC3-DE-4, REQ-UC3-DE-5, REQ-UC4-AC-1,REQ-UC4-AC-2, REQ-UC4-AC-3, REQ-UC4-DE-4

Work Package 2 Task 2.4 REQ-UC1-IKM-1, REQ-UC1-IKM-2, REQ-UC1-IKM-4,Requirements-based REQ-UC1-TKM-1, REQ-UC1-TKM-2, REQ-UC1-TKM-4,threat analysis REQ-UC1-SKM-1, REQ-UC1-SKM-2, REQ-UC1-SKM-3

REQ-UC3-DE-2, REQ-UC3-DE-4, REQ-UC3-DE-5REQ-UC4-SS-5

Work Package 3 Task 3.1 REQ-UC2-AC-1, REQ-UC2-AC-2, REQ-UC2-AC-4,Selective sharing REQ-UC2-AC-5, REQ-UC2-KM-1, REQ-UC2-KM-2,

REQ-UC2-KM-4, REQ-UC3-KM-6, REQ-UC3-DE-4,REQ-UC3-DE-2, REQ-UC3-DE-5

Work Package 3 Task 3.2 REQ-UC1-SKM-3Secure multi-userinteractions and sharingWork Package 3 Task 3.3 REQ-UC2-AC-3, REQ-UC2-AC-6, REQ-UC2-KM-1,Support for collaborative REQ-UC2-KM-2, REQ-UC2-EQ-1, REQ-UC2-EQ-2,queries REQ-UC2-EQ-3, REQ-UC2-EQ-4Work Package 3 Task 3.4 REQ-UC1-IKM-1, REQ-UC1-IKM-2, REQ-UC1-TKM-1,Security testing REQ-UC1-TKM-2Work Package 4 Task 4.1 REQ-UC4-AC-4, REQ-UC4-AC-5, REQ-UC4-AC-6,Security metrics and REQ-UC4-SS-1, REQ-UC4-SS-4, REQ-UC4-SS-5,assessment REQ-UC4-DE-2, REQ-UC4-DE-4Work Package 4 Task 4.2 REQ-UC4-SS-2, REQ-UC4-SS-3, REQ-UC4-DE-1,Multiple providers for REQ-UC4-DE-3securityWork Package 4 Task 4.3 REQ-UC3-SO-1, REQ-UC3-SO-2, REQ-UC3-SO-3,Federated object storage REQ-UC3-SO-4, REQ-UC3-SO-5, REQ-UC3-SO-6,

REQ-UC3-SO-7, REQ-UC3-SO-8, REQ-UC4-SS-3Table 4.1: Work Package Tasks to Use Case Requirements

4.2 Synthesis of Common Requirements

This section takes each of the sub-dimensions in turn and analyzes their associated use case re-quirements to synthesize the common ESCUDO-CLOUD requirements. There are a number ofcommon ESCUDO-CLOUD themes that run through all the use cases, but may be expressed usingdifferent terms and concepts. This section seeks to define a common set of terms and concepts,along with those defined in Chapter 2, to represent the requirements in the use cases, and extractthe elements that may be implied, but not explicitly stated. Due to the variety and breadth of theareas covered by the use cases, not all terms or concepts may be applicable in each case. Addition-ally their implementation in each use case may vary depending on the specific context and howthey are applied.


Section 4.2: Synthesis of Common Requirements 39

4.2.1 Data confidentiality (a-i)

An inspection of the use case requirements associated with the “Security properties - Confiden-tiality” sub-dimension (a-i) suggests that they can be grouped into the following categories 1) dataconfidentiality through access control policies; 2) appropriate levels of encryption; 3) secure dele-tion of data by deleting keys; 4) scalability of the infrastructure does not compromise data confi-dentiality; 5) data confidentiality should comply with relevant standards. The categories and theirassociated use case requirements are listed in Table 4.2, followed by a description of the categoriesand their associated common requirement references.

Category Use Case Requirements1) Data confidentiality through REQ-UC1-IKM-2, REQ-UC1-TKM-2,access control policies REQ-UC1-IKM-1, REQ-UC1-TKM-1,

REQ-UC2-AC-1, REQ-UC2-AC-2,REQ-UC2-AC-3, REQ-UC2-AC-4,REQ-UC2-AC-5, REQ-UC2-AC-6,REQ-UC2-KM-2, REQ-UC2-KM-1,REQ-UC2-KM-4,REQ-UC2-EQ-4, REQ-UC3-KM-1,REQ-UC3-KM-2, REQ-UC3-KM-3,REQ-UC3-KM-4, REQ-UC3-KM-5,REQ-UC3-AC-1, REQ-UC3-AC-2,REQ-UC3-AC-3, REQ-UC3-AC-4,REQ-UC3-AC-5, REQ-UC3-AC-6,REQ-UC3-AC-7, REQ-UC3-SO-1,REQ-UC3-DE-1, REQ-UC4-AC-1,REQ-UC4-AC-2, REQ-UC4-AC-4,REQ-UC4-DE-1

2) Appropriate levels of encryption REQ-UC2-EQ-1, REQ-UC2-EQ-2,REQ-UC2-EQ-3

3) Secure deletion of data by REQ-UC1-IKM-4, REQ-UC1-TKM-4deleting keys4) Scalability of the infrastructure REQ-UC1-SKM-2, REQ-UC3-KM-6,does not compromise data REQ-UC3-DE-2, REQ-UC3-DE-4,confidentiality REQ-UC3-DE-5, REQ-UC4-DE-2,

REQ-UC4-DE-3, REQ-UC4-DE-4,REQ-UC1-SKM-3

5) Data confidentiality should REQ-UC2-KM-3, REQ-UC4-SS-4,comply with relevant standards REQ-UC4-SS-5

Table 4.2: Categories for use case requirements (a-i)



1) Data confidentiality through access control policies

The data owner will be provisioned with a key manager and access controller that manages accessto their data. The data owner will have an administration account, which uniquely identifies themto the security framework. Authentication of the user will typically be achieved with a unique username and password, but other authentication mechanisms may be supported. An administratorcan create, modify or revoke a) other user accounts; b) other administrator accounts; c) groupand users within the groups; d) the right of users or groups to access data or data parts; e) whatoperations the users or groups can perform on the data; f) policies or rules that control accessto the data, such as automatic expiry date. The user, groups, policies and access rights will beimplemented using an access control matrix, and the access control matrix will support the full setof CRUD operations on the data or data parts.

The access control matrix will govern the life cycle and distribution of the data encryptionkeys, so that this process is transparent to the user. The user simply uploads data to the CSP, andthe security framework automatically generates the associated encryption keys. Likewise whenthe user requests the data to be deleted, the framework automatically deletes the associated keys.

Common requirements: REQ-CO-SF-7, REQ-CO-SF-25, REQ-CO-KM-1, REQ-CO-KM-3, REQ-CO-KM-4, REQ-CO-AC-1, REQ-CO-AC-2, REQ-CO-AC-3, REQ-CO-AC-5, REQ-CO-AC-6, REQ-CO-AC-12, REQ-CO-AC-13, REQ-CO-AC-15, REQ-CO-AC-17

2) Appropriate levels of encryption

This category is covered in Section 4.2.7 2) Multi-layered encryption schemas.

3) Secure deletion of data by deleting keys

Ensuring the deletion1 of the user’s data on a CSP2 can be problematic for a number of reasonsa) the CSP may delete the reference to the data but not the data itself; b) the data deletion techniquemay not conform to industry standards; c) the CSP may not delete backup copies of the user’s data;d) the physical storage media may be taken out of the CSP’s secure environment for deletion ofthe data; e) the CSP may have outsourced the destruction of the storage media to a third party.The basic problem is that when the data owner stores their data in the Cloud, they are no longer incontrol of the storage media.

If the user’s data is encrypted with a sufficiently strong cryptographic algorithm, it can beplaced beyond use by deleting all encryption keys that can decrypt the data, that might be termeddeletion by data obfuscation. Whilst the encrypted data remains untouched on the CSP environ-ment, the data will be permanently obfuscated, so the result is the same as deleting it. Using thistechnique means that it is no-longer strictly necessary to delete the actual data on the storage me-dia, however it is prudent to request the CSP to do so as a precautionary measure. If the encryptionkeys remain within the user’s trust boundary, the data owner has an auditable mechanism to provethat the data has been deleted; it also has the added advantage that the encryption keys are likelyto be considerably shorter than the data itself, and therefore it is quicker to delete them.

Common requirements: REQ-CO-SF-4, REQ-CO-SF-5, REQ-CO-KM-20

1Sometimes referred to as data erasure.2Or third party storage service.



Figure 4.1: Syndicating encryption keys

4) Scalability of the infrastructure does not compromise data confidentiality

The security frameworks in the Cloud must be scalable to support large numbers of users. Thiswill typically involve scaling the framework horizontally by having multiple instances of theframework’s components either in a peer-to-peer or parent/child configuration, and syndicatingthe data’s encryption keys or access control policies.

Figure 4.1 illustrates a security scenario where the TTP hosts the master key manager, and eachCSP hosts a child key manager. The user updates the access control policies on the TTP, and theaccess controller/key manager on the TTP syndicates the encryption keys to the CSP. Additionallythe syndication process should be transparent to the user.

Having the data’s encryption keys cached locally on the CSP has the advantage that the en-cryption agent does not have to retrieve the keys each time from the master key manager, and thusthe local encryption process is faster, but it is also more complex to manage as there are multiplecopies of the encryption key at several locations. Typically the child key managers should retainkeys for no longer than is necessary for the efficient operation of the security framework.

If the user deletes a key on the master key manager, the key must also be deleted on the childkey managers. The deletion command may take some time to propagate to the child key managers,this is the notion of eventual consistency of the state of the security framework. However thisraises the possibility that the user has requested that the data’s encryption key be deleted, but inthe small intervening window, the data was accessed by another authorized user, before the keydeletion control message was propagated to the child key manager. The security framework mustimplement mechanisms to handle the window where the framework is in an inconsistent state.

All control messages and encryption keys should be exchanged over secure connections be-tween distributed security framework components, to prevent man-in-the-middle attacks. Typi-cally data should be encrypted as soon as is practical on entry to the CSP’s environment, and aslate as practical when it is sent to the user, i.e. where ever possible the user’s data should be en-



crypted on the CSP’s infrastructure. Therefore the CSP must have sufficient processing capacityto perform the encryption/decryption process in a timely manner.

The security framework may have multiple access controllers in a parent/child configurationto allow the framework to scale. The user, groups, policies and access rights are specified in themaster access control matrix in the parent access controller. When the master access control matrixis updated, the updates are syndicated to the child access controllers, who update their accesscontrol matrices. The same syndication and consistency concept that apply to key managers,should also apply to access controllers.

In certain security framework implementations there may be more than one master key man-ager or access controller for redundancy. If there are multiple key managers or access controllersthey should function in a peer-to-peer relationship in that a change made to any master componentwill be syndicated to all other master components. The existence of multiple master components,and the syndication process between them, should be transparent to the user. Therefore a conflictresolution mechanism must be implemented to automatically reconcile conflicting updates.

Common requirements: REQ-CO-SF-3, REQ-CO-SF-6, REQ-CO-SF-7, REQ-CO-SF-24, REQ-CO-SF-37, REQ-CO-SF-39, REQ-CO-KM-5, REQ-CO-KM-6, REQ-CO-KM-7, REQ-CO-KM-13, REQ-CO-KM-14, REQ-CO-KM-15, REQ-CO-KM-16, REQ-CO-KM-17, REQ-CO-KM-21, REQ-CO-AC-3, REQ-CO-AC-7, REQ-CO-AC-9, REQ-CO-AC-19, REQ-CO-AC-22, REQ-CO-AC-23, REQ-CO-AC-24, REQ-CO-EA-7, REQ-CO-EA-8, REQ-CO-EA-9

5) Data confidentiality should comply with relevant standards

The security framework should ensure that the user’s data remains confidential, particularly whereit relates to personally identifiable information. The framework should conform to industry secu-rity standards, including EU directive 95/46/EC and PKCS#12 [MNP+14].


4.2.2 Data integrity (a-ii)

An inspection of the use case requirements associated with the “Security properties - Integrity”sub-dimension (a-ii) suggests that they can be grouped by the following categories 1) Controllingdata modification via key manager and access controller components; 2) Encryption standards;3) Transmission over secure channels. The categories and their associated use case requirementsare listed in Table 4.3, followed by a description of the categories and their associated commonrequirement references.



Category Use Case Requirements1) Controlling data modification via REQ-UC2-AC-5, REQ-UC2-AC-6,key manager and access controller REQ-UC2-KM-1, REQ-UC2-KM-2components REQ-UC2-KM-4, REQ-UC3-KM-2,

REQ-UC3-KM-4, REQ-UC3-KM-5,REQ-UC3-KM-6, REQ-UC3-AC-1,REQ-UC3-AC-2, REQ-UC3-AC-3,REQ-UC3-AC-4, REQ-UC3-AC-5,REQ-UC3-AC-7, REQ-UC3-SO-1,REQ-UC3-DE-1, REQ-UC3-DE-2,REQ-UC3-DE-5, REQ-UC4-DE-4

2) Encryption standards REQ-UC2-KM-3, REQ-UC3-KM-3,REQ-UC3-AC-6, REQ-UC3-DE-3

3) Transmission over secure REQ-UC3-DE-5, REQ-UC4-SS-5channels

Table 4.3: Categories for use case requirements (a-ii)

1) Controlling data modification via key manager and access controller components

The data owner must be able to control access to the data or data parts, so only authorized userscan modify it. The data owner controls access to the data via two core components of the securityframework; the key manager and the access controller.

Only the data owner, through their administrator account, or another administrator designatedby the data owner, should be able to grant permission to a user or group of users to modify theirdata. The CSP should never have the authority to modify the data, unless specifically authorizedto do so by one of the administrators. This will typically be in exceptional circumstances, suchas data recovery following an infrastructure failure, and should only be allowed with suitablesafeguards in place. The security framework should provide the data owner with mechanisms toensure that the data is a faithful copy of the original, such as a data digest [Rea92], which is storedin the access controller. The CSP should not be able to modify the owners data as part of routineoperations, such as data backups.

The access controller is based on an access control matrix, which defines whether a specificuser, or group of users, can perform specific operations on the data or data parts, such as writeoperations that would modify the data. In addition, the controller may also provide constraints orsecurity rules that apply to specific users, groups or data parts. For example a specific group ofusers may only be able to modify a data part during normal trading hours. The access controllershould be accessed in a secure manner, typically via a user name and password.

Common requirements: REQ-CO-SF-32, REQ-CO-KM-22, REQ-CO-AC-2, REQ-CO-AC-3,REQ-CO-AC-5, REQ-CO-AC-6, REQ-CO-AC-12, REQ-CO-AC-13, REQ-CO-AC-20

2) Encryption standards

In the case of data obfuscation by encryption, the ability to decrypt and modify the data is con-trolled by access to the encryption keys. All keys should be stored in the security framework’s key



manager, which must conform to PKCS#12 [MNP+14] and FIPS-140 [Sec01] standards. The usershould have a choice of encryption key algorithms, such as AES128, AES256, 3DES, etc. Theuser should be verified before being given access to the key manager, typically via a user nameand password.


3) Transmission over secure channels

It is assumed that the user’s data, and control messages between the components of the securityframework, will always pass over a secure channel between the user’s system and the CSP’s envi-ronment, such as a VPN tunnel. This will prevent man-in-the-middle attacks from modifying theuser’s data in transit.

Common requirements: REQ-CO-SF-3, REQ-CO-SF-24

4.2.3 Data availability (a-iii)

An inspection of the use case requirements associated with the “Security properties - Availability”sub-dimension (a-iii) suggests that they can be grouped by the following categories 1) Controllingavailability of data; 2) Resilience of encryption keys; 3) Scaling security framework. The cate-gories and their associated use case requirements are listed in Table 4.4, followed by a descriptionof the categories and their associated common requirement references.

Category Use Case Requirements1) Controlling availability of data REQ-UC1-IKM-1, REQ-UC1-IKM-2,

REQ-UC1-TKM-1, REQ-UC1-TKM-2,REQ-UC3-KM-1, REQ-UC3-KM-2,REQ-UC3-KM-3, REQ-UC3-KM-4,REQ-UC3-KM-5, REQ-UC3-AC-2,REQ-UC3-AC-3, REQ-UC3-AC-4,REQ-UC3-AC-5, REQ-UC3-SO-1,REQ-UC3-DE-2, REQ-UC3-DE-3,REQ-UC3-DE-4, REQ-UC4-AC-6,REQ-UC4-SS-2, REQ-UC4-DE-4

2) Resilience of encryption keys REQ-UC1-SKM-1, REQ-UC3-DE-5,REQ-UC4-AC-5, REQ-UC4-SS-5

3) Scaling security framework REQ-UC1-SKM-2, REQ-UC1-SKM-3,REQ-UC3-KM-6, REQ-UC3-AC-1,REQ-UC3-AC-6, REQ-UC3-AC-7,REQ-UC3-DE-1

Table 4.4: Categories for use case requirements (a-iii)



1) Controlling availability of data

The key manager and access controller must ensure that the data is kept available until the userspecifically deletes it, either by deleting the data itself or by deleting all copies of the data’s en-cryption key, which places the data beyond use. Only the data owner or a user designated by themshould be able to change the availability of the data, via a robust security framework.


2) Resilience of encryption keys

If the encryption key is lost, encrypted data is placed beyond use, i.e. it is effectively deleted andis no-longer available. The key manager and security framework should be sufficiently resilient,so that a key can be restored if it is lost through infrastructure failure, i.e. some form of encryptionkey backup mechanism is required. The backup mechanism must be sufficiently sophisticated sothat it can ensure that all copies of an intentionally deleted key are destroyed, including any backedup keys.

Common requirements: REQ-CO-KM-18

3) Scaling security framework

Scaling the security framework, possibly with multiple clustered key managers/access controllers,poses the challenge of ensuring that the user’s data is available regardless of the key manager/accesscontroller the user connects to. Likewise if the data’s key is deleted, it must not be available viaone of the other clustered key managers, which may have erroneously kept the key. This impliesthe requirement for a control protocol between the clustered components of the security frame-work and sophisticated key caching algorithms. So an action performed by a user on one keymanager/access controller is propagated in a timely manner to all other key managers/access con-trollers in the cluster. As far as it is possible, the cluster and internal control messages should betransparent to the user. The nodes of the cluster may be set-up in a peer-to-peer or parent/childconfiguration.

The difficulty with clustered key managers/access controllers is that synchronous systems donot scale well, as they must wait for all update acknowledgements to be returned before confirmingthe update. Asynchronous systems do scale well, but are only eventually consistent. The securityframework needs to address this challenge to ensure consistent data availability.

Figure 4.2 illustrates an example scenario of clustered key managers. Two key manager in-stances exist on a TTP between the user’s system and CSP; however the key managers could belocated on different TTPs or even the CSP itself 3. Both the key managers are shown tightlycoupled with their associated access controllers, and with a secure channel between them, overwhich control messages can pass and indicates that the key managers form a cluster. Each keymanager/access controller in the cluster is referred to as a cluster node.

In this scenario the user can connect to either key manager/access controller instance, makingthe security framework more robust and scalable. If the user modifies the keys or access controlpolicies on one instance, the cluster manages the propagation of the keys and policies between theinstances of the key manager/access controller in the cluster 4.

3This assumes that any security framework component was installed on the CSP from a trusted source and itsauthenticity can be verified.

4This may also include the encryption agent.



Figure 4.2: Clustered key managers

As a byproduct distributing keys and policies between clustered key managers may provide analternative backup mechanism, in contrast to conventional off-line backup copies. Similar to thedata block replication feature, multiple nodes in the cluster contain a key manager, which storeidentical keys. If a key manager is irrevocably lost, a new instance can be instantiated and joinedto the cluster; the new key manager could then be populated with copies of the existing keys.

Common requirements: REQ-CO-SF-21, REQ-CO-SF-37, REQ-CO-KM-5, REQ-CO-KM-11,REQ-CO-KM-13, REQ-CO-KM-14, REQ-CO-AC-7, REQ-CO-AC-11, REQ-CO-EA-11

4.2.4 Access by data owners (b-i)

An inspection of the use case requirements associated with the “Sharing requirements - Access bydata owners” sub-dimension (b-i) suggests that they can be grouped by the following categories1) Data owners allocated key manager and access controller; 2) Point of data encryption. The cate-gories and their associated use case requirements are listed in Table 4.5, followed by a descriptionof the categories and their associated common requirement references.

Category Use Case Requirements1) Data owners allocated key manager REQ-UC1-IKM-1, REQ-UC1-TKM-1,and access controller REQ-UC2-KM-1, REQ-UC2-KM-3,

REQ-UC2-AC-4, REQ-UC4-AC-3,REQ-UC3-KM-1, REQ-UC3-KM-2,REQ-UC3-KM-4, REQ-UC3-KM-5,REQ-UC3-AC-1, REQ-UC3-AC-2,REQ-UC3-AC-4, REQ-UC3-AC-5,REQ-UC3-SO-1, REQ-UC3-DE-1,REQ-UC3-DE-3, REQ-UC4-AC-1,REQ-UC4-AC-2, REQ-UC4-AC-5,REQ-UC4-AC-6, REQ-UC4-SS-2,REQ-UC4-SS-5, REQ-UC4-DE-1

2) Point of data encryption REQ-UC4-DE-2, REQ-UC4-DE-3,REQ-UC4-DE-4

Table 4.5: Categories for use case requirements (b-i)



1) Data owners allocated key manager and access controller

The data owner will have their own instance of a key manager and access controller. The functionof the key manager is to act as a repository for the keys, and control their life-cycle and distribution;the access controller manages access to the owner’s data or data parts, and what operations can beperformed on them.

Ideally the location and operation of the security components should be transparent to the user.Whilst complete location and operation transparency may not be practical in all scenarios, such asadministrating the security framework via a TTP, the user should not have to be concerned withthe low level details of how it functions.

The data owner will be allocated at least one administration account for the key manager/accesscontroller. If the key manager and access controller are co-resident, only a single administrationaccount may be required. The user can then create one or more accounts for themselves or othertrusted users. Typically the user will sign-on to the key-manager/access controller using a uniqueuser name and password, but other techniques, such as mutual certificate authentication, may beconsidered. It is important that the user signs-on either on a trusted system or via a secure link,so that the password cannot be compromised by a man-in-the-middle attack. To simplify usingthe security framework over multiple data requests, the user may be able to cache their securitycredentials on their own trusted system. Caching sign-on credentials must be implemented in asecure way, and may only be applicable for certain security scenarios.

If a user sign-on repeatedly fails, i.e. the user name or password is incorrectly entered mul-tiple times, the user’s account is locked out and must be reset by one of the user’s administrationaccounts. If an administration account is locked out, it can also be reset by one of the user’s otheradministration accounts.

Whilst the user’s data may be stored as a single entity, more typically it will be divided intological parts, e.g. files, objects, etc. The access controller will manage each data part as a separateentity, and ideally each entity will have its own encryption key generated from a master key. Aseach user may be able to perform different operations on different parts of the data, the accessrights may best be defined in the form of an Access Control Matrix [HFK06]. The user’s admin-istrator account will be provided with an API, UI or command line interface to manage the useraccounts, data parts and the operations that can be performed on them.

The key manager will also be provided with an API, UI or command line interface to managethe data’s encryption keys. Keys will typically be generated automatically in collaboration withthe access controller, but the user should have the capability to manage the life-cycle of the keysmanually, e.g. to ensure they are deleted and thus put the encrypted data beyond use. The user’smaster key should never leave the key manager, only subordinate keys, generated for specific dataparts, should be distributed to the encryption agents; this prevents an encryption agent given onedata part key from decrypting another data part, for which it has not been given access rights.The key manager and access controller may provide a common user interface to simplify theprocess of administering the security framework. Typically the user does not had to manage theencryption agent directly, but delegates this task to the key manager/access controller, so theremay be no need for it to have an API, UI or command line interface. Additionally the encryptionagent should maintain no long term state, and can thus be instantiated if it fails, which should betransparent to the user.

It is important that the key manager/access controller maintains robust key and access controlstores. If the key store is lost, the data may be unintentionally put beyond use. Backup mechanisms



Figure 4.3: Separating encryption and data storage

must be put in place to ensure that the stores can be re-instantiated in the event that the workingcopy is lost. Equally well, if a data encryption key is deleted from the working copy, it must alsobe guaranteed that it cannot be restored from the backup mechanism. This may appear counter-intuitive, but if it is the data owner’s intention to permanently delete the data, and the frameworkachieves this by deleting the encryption key and thus put the data beyond use, then there must be nopossibility that the key can be restored from any source. This implies that the security frameworkhas very tight control over the backup mechanism, and that this control can be adequately audited.It is unlikely that current generic backup technologies will have sufficient functionality to meetthe requirements of the security framework.

Common requirements: REQ-CO-SF-7, REQ-CO-SF-10, REQ-CO-SF-11, REQ-CO-SF-12, REQ-CO-SF-13, REQ-CO-SF-14, REQ-CO-SF-15, REQ-CO-SF-25, REQ-CO-SF-26, REQ-CO-SF-27, REQ-CO-SF-28, REQ-CO-SF-31, REQ-CO-SF-33, REQ-CO-KM-2, REQ-CO-KM-8, REQ-CO-KM-9, REQ-CO-KM-19, REQ-CO-AC-2, REQ-CO-AC-5, REQ-CO-AC-8,REQ-CO-AC-14, REQ-CO-AC-16, REQ-CO-AC-18, REQ-CO-EA-3, REQ-CO-EA-10

2) Point of data encryption

In scenarios where the user is using the CSP solely as a data storage service, the user’s datashould be encrypted and decrypted either on an intermediary system, or at the point it arrives orleaves the CSP’s environment, i.e. the data should be unencrypted on the CSP for the minimumtime possible. Even though the data should be within the user’s trust boundary on the CSP’senvironment, ensuring that where possible it remains encrypted, helps provide defense in depthagainst MTPs. Figure 4.3, illustrates the secure scenario where the user’s data is encrypted on theTTP but stored on the CSP. This scenario is more secure than encrypting the data on the CSP, asthere is a separation of concerns; the TTP handles the encryption of the data but does not store it,and the CSP receives and stores the data but only in its encrypted form.

Encrypting and decrypting the data at the boundary of the CSP, may not apply to scenarioswhere the data is processed in some way on the CSPs environment. However even if the data isprocessed on the CSP, it may still be possible to obfuscate the user’s data, either through multi-layer encryption or data fragmentation.

Common requirements: REQ-CO-SF-16, REQ-CO-EA-9



4.2.5 Selective sharing with other users/owners (b-ii)

An inspection of the use case requirements associated with the “Sharing requirements - Selectivesharing with other users/owners” sub-dimension (b-ii) suggests that they can be grouped by thefollowing categories1) Key hierarchies for fine grained data access; 2) Managing multiple usersthrough groups and roles; 3) Distributed key-management and encryption. The categories andtheir associated use case requirements are listed in Table 4.6, followed by a description of thecategories and their associated common requirement references.

Category Use Case Requirements1) Key hierarchies for fine grained REQ-UC2-KM-1, REQ-UC2-KM-2,data access REQ-UC2-KM-42) Managing multiple users through REQ-UC2-AC-2, REQ-UC2-AC-4,groups and roles REQ-UC2-AC-5, REQ-UC4-AC-43) Distributed key-management and REQ-UC1-SKM-3, REQ-UC3-KM-6,encryption REQ-UC3-DE-2, REQ-UC3-DE-4,

REQ-UC3-DE-5Table 4.6: Categories for use case requirements (b-ii)

1) Key hierarchies for fine grained data access

Figure 4.4: Key hierarchy and associated data access

A hierarchy of parent/child keys that provides different levels of access to the users encrypted data,enabling the user to share parts of their data. Figure 4.4 illustrates the concept of the key hierarchyon the left and the associated data access on the right; the shaded area indicates the accessible data.Only the ancestor, or master, key can encrypt/decrypt the whole data, whereas the child keys canencrypt/decrypt only portions of the data, in a descending level of granularity. The child keys arederived from the master key by an appropriate algorithm[BCP03][Wui12].

Common requirements: REQ-CO-KM-23, REQ-CO-EA-3

2) Managing multiple users through groups and roles

To allow the data owner to share their data in a simple and controlled manner on the Cloud, theyshould be able to define one or more groups that can access their data, and add new users to agroup. Access rights to the data are defined by roles, and a specific user can be assigned one ormore roles. A role defines the type of access rights to the data, such as read or write, and the



Figure 4.5: Simple security scenario

Figure 4.6: Distributed security scenario

granularity of the data that can be accessed. The data owner can revoke a user’s role at any time,or restrict the user’s access to all or part of the data. It is envisaged that the user would delegatethe management of groups and roles to an access controller, which would either be located on theuser’s system or a TTP in the Cloud, and which would be accessed via and API, UI or command-line interface.

Common requirements: REQ-CO-KM-9, REQ-CO-AC-2, REQ-CO-AC-5

3) Distributed key-management and encryption

Two core components of a security framework are the key manager and the encryption agent. In asimple security scenario both these components can be located on the user’s system, as illustratedin figure 4.5, and thus there are no issues with the distribution of keys or security frameworkcomponents.

If the data owner wishes to share their data securely with other users in the Cloud, it is likelythat one or both of these components would have to be relocated into a distributed security frame-work.

Figure 4.6 illustrates a distributed security scenario where the key manager is located on theTTP and the encryption agent is located within the user’s trust boundary on the CSP. In this sce-nario the user has delegated the storage and management of the encryption keys to the TTP, butthey are still able to control key management through the administration interface. The user sendsthe unencrypted data directly to the CSP over a secure channel, and the encryption key is trans-ferred to the encryption agent over another secure channel. The encryption agent can then encryptthe data, before passing it to the CSP for storage. A similar process operates in reverse when theuser wishes to retrieve the data.



Figure 4.7: Syndicating encryption agent

Locating the key manager (and the access controller) on the TTP enables other authorizedusers, represented by the boxes in the top right, to share the owner’s data without having to accessthe data owner’s system. Instead they can access the key manager/access controller directly on theTTP. This is an important requirement to enable sharing of data between users, as the data ownersystem does not have to be available for other authorized users to access their data.

One mechanism to place the encryption agent inside the user’s trust boundary on the CSP, isto syndicate a copy of the agent from the TTP to the CSP over the secure channel that connectsthem, illustrated in figure 4.7. Alternatively the user could install the encryption agent themselvesor have the CSP install the agent for them; in the latter case there must be some mechanism toverify that the agent is trusted.

Common requirements: REQ-CO-SF-17, REQ-CO-SF-21, REQ-CO-SF-22, REQ-CO-AC-16,REQ-CO-EA-1

4.2.6 Upload/download (c-i)

An inspection of the use case requirements associated with the “Access requirements - Upload/download”sub-dimension (c-i) suggests that they can be grouped into a single category 1) secure transfer ofdata, control messages and keys. The category and its associated use case requirements are listedin Table 4.7, followed by a description of the category and its associated common requirementreferences.

Category Use Case Requirements1) Secure transfer of data, REQ-UC1-IKM-1, REQ-UC1-TKM-1,control messages and keys REQ-UC3-KM-2, REQ-UC4-SS-2,

REQ-UC4-DE-4Table 4.7: Categories for use case requirements (c-i)



1) Secure transfer of data, control messages and keys

The users data should pass over a secure channel between the user’s system, TTP and CSP. Ifthe data is encrypted when passes over a channel, the channel does not technically need to beencrypted as the data is already obfuscated. However it is advisable to use secure channels in thesecircumstances as it provides defense in depth against man-in-the-middle and session hijackingattacks. Control messages and encryption keys should always pass over a secure channel.


4.2.7 Fine-grained retrieval (c-ii)

An inspection of the use case requirements associated with the “Access requirements - Fine-grained retrieval” sub-dimension (c-ii) suggests that they can be grouped by the following cat-egories 1) fine-grained data access; 2) multi-layered encryption schemas. The categories and theirassociated use case requirements are listed in Table 4.8, followed by a description of the categoriesand their associated common requirement references.

Category Use Case Requirements1) Fine-grained data access REQ-UC1-IKM-2, REQ-UC1-TKM-2,

REQ-UC2-AC-3, REQ-UC2-AC-4,REQ-UC2-EQ-4, REQ-UC3-AC-7,REQ-UC4-DE-1, REQ-UC4-DE-2,REQ-UC4-DE-3

2) Multi-layered encryption schemas REQ-UC2-EQ-1, REQ-UC2-EQ-2,REQ-UC2-EQ-3

Table 4.8: Categories for use case requirements (c-ii)

1) Fine-grained data access

In the simple case the user’s data is encrypted with a single key on the CSP’s environment. Inmany cases the user may require only a portion of their data to be retrieved, either to reduce thequantity of data to be transmitted or provide another user with only a portion of their data. Toreturn only a portion of the user’s encrypted data, the CSP would have to be able to a) decrypt thedata; b) identify and extract the required data portion; c) and return the required portion of the datato the user. Such a level of access gives the CSP an undesirable visibility of the user’s data. Bysubdividing the user’s data into parts and obfuscating the data parts individually, portions of thedata can be retrieved without the CSP having to decrypt them.

Where possible, subdividing the data into data parts should be automated, to reduce the burdenon the user. If the user is forced to specify how the data is to be divided every time they storetheir data, it is likely that they will not make full use of data parts. When dividing the dataconsideration should be given to how it will be retrieved and used, and also the cost trade-offbetween finer-grained data and potentially increased encryption overhead. In many cases the levelof data partitioning will be implicit from its structure.



• File system data can be partitioned at the level of the file rather than the file system.

• Objects can be partitioned at the level of the object rather than the object store.

• Databases can be partitioned at the level of the table, row or column rather than the databasefiles. In some circumstances it may be more efficient to group row and columns into largerlogical parts.

The user must also be provided with mechanisms to identify and retrieve the portion of datathey require. Searching encrypted data may be possible in some cases using certain encryptionalgorithms, but in many cases meta-data will need to be stored to identify the data parts. Themeta-data defining the data parts is stored in the access control matrix, along with a reference tothe key used to encrypt the associated data.

Common requirements: REQ-CO-SF-30, REQ-CO-SF-34, REQ-CO-AC-4, REQ-CO-EA-4

2) Multi-layered encryption schemas

Where data is to be processed on the CSP or by a user with reduced privileges, it may be possibleto encrypt the data with an encryption schema that allows the data to be processed in an encryptedstate. For example two data parts encrypted with a deterministic encryption schema can be com-pared without their contents being revealed. This technique can be applied to many different typesof data parts including database rows, files, objects, etc.

Whilst deterministic encryption provides less confidentiality than probabilistic encryption5,it may be appropriate for the level of data security required. Rather than deciding the type ofencryption schema at the outset, the data may be successively encrypted with more confidentialencryption schemas. Then, when the operation to be performed on the data and the access rightsof the user are validated, the data can be successively decrypted to an appropriate level where theoperation can be performed.

Figure 4.8: Multi-layer encryption

5If we have two pieces of deterministically encrypted data A and B, where A is known, and B is known to equal A,then the contents of B can be inferred.



Figure 4.8 illustrates the concept of multi-layer encryption. Two pieces of data A and B arefirst encrypted with a deterministic encryption schema, and then with a probabilistic encryptionschema. A user, with restricted data access privileges, requests an operation to compare the twopieces of data. The security framework determines that the user can compare the data, but notsee it in plain text. It is therefore valid for the security framework to decrypt the data using aprobabilistic encryption schema, at which point the two pieces of data can be compared.

The key manager will need to store keys for each data part and each encryption schema. Theaccess controller will need to store metadata by data part on the a) encryption schemas used;b) the sequence they were applied; c) their associated encryption keys; d) the operations that canbe performed at a specific encryption level; e) the operations that can be performed by a specificuser or group.

Common requirements: REQ-CO-SF-36, REQ-CO-SF-37, REQ-CO-KM-24, REQ-CO-AC-21,REQ-CO-EA-12, REQ-CO-EA-13

4.2.8 Write operations (c-iii)

An inspection of the use case requirements associated with the “Access requirements - Writeoperations” sub-dimension (c-iii) suggests that they can be grouped by the following categories1) multi-layer encryption schemas; 2) managing multiple users through groups and roles; 3) dy-namic CSP storage expansion; 4) protection against data overwrites; 5) caching user’s credentialson write operations.The categories and their associated use case requirements are listed in Ta-ble 4.9, followed by a description of the categories and their associated common requirementreferences.

Category Use Case Requirements1) Multi-layer encryption schemas REQ-UC2-EQ-1, REQ-UC2-EQ-2,

REQ-UC2-EQ-32) Write operations with REQ-UC2-EQ-4different keys3) Dynamic CSP storage expansion REQ-UC4-SS-1, REQ-UC4-SS-3,4) Protection against data REQ-UC4-SS-5overwrites5) Caching user’s credentials REQ-UC4-AC-2on write operations

Table 4.9: Categories for use case requirements (c-iii)

1) Multi-layer encryption schemas

This category is covered in Section 4.2.7 2) Multi-layered encryption schemas.

2) Write operations with different keys

This category is covered in Section 4.2.7 1) Fine-grained data access.



3) Dynamic CSP storage expansion

The CSP must ensure that they have sufficient storage capacity to accommodate the capacity theyhave contracted to provide. This implies that the CSP will have mechanisms to dynamically ex-pand their storage on demand, or inform the user that they are unable to provide the additionalstorage.

Common requirements: REQ-CO-EA-8

4) Protection against data overwrites

The CSP must provide mechanisms to ensure that the user’s data is not maliciously or accidentallyoverwritten as part of a write operation, and that only authorized users can modify existing data.


5) Caching user’s credentials on write operations

For client side encryption, the encryption agent on the user’s device will be able to cache theuser’s credentials for write operations, thus the user will only have to enter their credentials onceper session to authorize all write operations during that session.


4.2.9 Single Cloud provider (d-i)

An inspection of the use case requirements associated with the “Cloud Architectures - Single-Cloud provider” sub-dimension (d-i) suggests that they can be grouped by the following cate-gories1) key management service supports open standards; 2) unique user credentials within CSP.The categories and their associated use case requirements are listed in Table 4.10, followed by adescription of the categories and their associated common requirement references.

Category Use Case Requirements1) Key management service supports REQ-UC1-IKM-3, REQ-UC1-TKM-3open standards2) Unique user credentials within REQ-UC3-SO-1, REQ-UC4-SS-5CSP

Table 4.10: Categories for use case requirements (d-i)

1) Key management service supports open standards

The key management will support the OASIS KMIP open standard for communicating with theservice over standard APIs. The APIs will support both infrastructure and user6 key managementoperations. Ideally the APIs would also support the OASIS PKCS#11 standard.

6In this context the user is a tenant on the CSPs environment.




2) Unique user credentials within CSP

This category is covered in Section 4.2.1 1) Data confidentiality through access control policies.

4.2.10 Multi Cloud and federated Cloud (d-ii)

An inspection of the use case requirements associated with the “Cloud Architectures - Multi-Cloud and Federated-Cloud” sub-dimension (d-ii) suggests that they can be grouped by the fol-lowing categories1) Federated-Cloud architectures; 2) securing different data storage structures.The categories and their associated use case requirements are listed in Table 4.11, followed by adescription of the categories and their associated common requirement references.

Category Use Case Requirements1) Federated-Cloud architectures REQ-UC3-KM-1, REQ-UC3-KM-2,

REQ-UC3-KM-5, REQ-UC3-KM-6,REQ-UC3-AC-1, REQ-UC3-SO-2,REQ-UC3-SO-6, REQ-UC3-SO-7,REQ-UC3-SO-8, REQ-UC4-SS-2,REQ-UC4-SS-5

2) Securing different data storage REQ-UC3-SO-3, REQ-UC3-SO-4,structures REQ-UC3-SO-5, REQ-UC4-SS-3

Table 4.11: Categories for use case requirements (d-ii)

1) Federated-Cloud architectures

There are two principal security framework scenarios in a Multi-Cloud/Federated-Cloud config-uration a) the TTP is interposed between the user’s system and one or more CSPs; b) the TTPsyndicates keys to encryption agents hosted on one or more CSPs, and the user sends their datadirectly to the encryption agents over a secure channel.

Figure 4.9 illustrates the first security scenario where the TTP sits between the user’s systemand one or more CSPs. The user sends their data unencrypted to the TTP over a secure channel.Therefore the user delegates to the TTP a) key management; b) access control; c) user and groupmanagement; d) the CSPs used to provide data storage facilities; e) the syndication of the data tothe CSPs. As the TTP does not store the user’s data and the CSPs never see the data in plain text,the scenario is more secure than one where the encryption and storage are vested in the same entity.This scenario has the advantage that the whole security framework is located on the TTP and itsoperation is transparent to the data owner, including the automated division of the data into dataparts. Additionally other users can connect directly to the TTP, and the data owner can authorizethose users to access the data or data parts via their administration account. The disadvantage isthat the data owner vests all responsibility for the security of their data to the TTP, and thereforethey need very robust security auditing processes, but they only need to audit the TTP and not theCSPs that store the data.



Figure 4.9: Interposing Federated-Cloud

Figure 4.10: Syndicating Federated-Cloud



Figure 4.10 illustrates the second security scenario where the TTP hosts the key manager/accesscontroller, but the encryption agent is hosted on one or more CSPs, inside the user’s trust bound-ary. The user manages the security framework in a similar manner to the first scenario, except thatthey now send their data directly to the CSPs, the TTP never sees their data. The disadvantage isthat the operation of the security framework is not as transparent to the user as the first scenario.The data owner must a) split the data into data parts and request the key manager/access controllerto generate separate keys and access policies; b) send the data to the appropriate CSP; c) ensurethat the encryption agent is validated and inside their trust boundary. The main advantage with thissecurity scenario is that the audit requirements for the TTP are lower, as the TTP never sees theuser’s data. There are several additional facilities that could simplify the operation of the securityframework for the user:

• An additional agent could be located on the user’s system to handle the division of datainto data parts, coordinate control messages between security framework components, anddistribute data to the CSPs.

• The encryption agent could be made more intelligent so that it would handle the divisionof data into data parts, requesting the key manager to generate new keys for the data, andregistering the data with the access controller.

Common requirements: REQ-CO-SF-17, REQ-CO-SF-21, REQ-CO-SF-22, REQ-CO-SF-25,REQ-CO-SF-33, REQ-CO-KM-1, REQ-CO-EA-3, REQ-CO-EA-5, REQ-CO-EA-6

2) Securing different data storage structures

This category is covered in Section 4.2.7 1) Fine-grained data access.


5. Use Case Requirements Comparison toCurrent Technologies

The following sections provide a comparison between the the use case requirements and the cur-rent technologies available for securing the users data in the Cloud. The purpose of the analysiswas to identify possible gaps in the current technologies, and areas that ESCUDO-CLOUD mightinvestigate to provide a broader set of security solutions, which would be deployed, Task 1.3, andvalidated, Task 1.4, as part of the use case exploitations.

5.1 Use Case 1

Use Case 1 deals with the encryption in Openstack Swift. As such, its functional requirementsaddress protection of data at-rest for object stores (Work Package 2), secure deletion of data (WorkPackage 2), and the technologies to guarantee integrity and consistency of objects when accessedby multiple clients (Work Package 3). Finally, the functional requirements of Use Case 1 implythe use of key-management solutions in Cloud setting (Work Package 2).

The next several paragraphs address the related state-of-the-art for each area of the functionalrequirements of Use Case 1.

Protection of data at-rest

The currently existing open-source Cloud object storage solutions do not have support for data-at-rest encryption and neither integrates with enterprise-strength key-management systems. Inparticular, systems based on hardware-security modules (HSMs) are not available in the Cloudcontext, except for one or two isolated vendor-specific solutions. Unfortunately, the protocolswhich are currently used today to interact with HSMs, such as PKCS#11 (REQ-UC1-IKM-3,REQ-UC1-TKM-3), are not suited for the dynamic, virtualised and multi-tenant environment ofthe Cloud.

ESCUDO-CLOUD will improve in this area by making the support for data-at-rest encryptionthe first class citizen of the Cloud object storage. Furthermore, ESCUDO-CLOUD will explore theintegration with enterprise-level key-management systems, as well as scalable key-managementsystems (REQ-UC1-SKM-2, REQ-UC1-SKM-3).

Secure deletion

As physical deletion of data does not offer enough guarantees with the proliferation of variousstorage techniques, commonly used by Cloud object stores, secure deletion in Use Case 1 focuseson encryption based secure deletion (REQ-UC1-TKM-4), augmented with policy driven work-flows (REQ-UC1-IKM-2, REQ-UC1-TKM-2). Since all existing object storage systems utilizefile systems for final data storage, we note the state-of-the-art for secure deletion in this field.

59

60 Use Case Requirements Comparison to Current Technologies

The first work to utilize encryption for secure deletion is one of Boneh and Lipton [BL96].Di Crescenzo et al. [CFIJ99] introduce a tree construction for efficient secure deletion of arbitraryfiles among a group of files. The master key at the root of the tree is kept in erasable memory,and every key in the tree encrypts several keys below, until the keys at the leaves encrypt the filesthemselves.

Perlman’s Ephemerizer [Per07] employs a temporal sequence of keys modeling different ex-piration times for encrypted data. Peterson et al. [PBH+05] use all-or-nothing transforms (AONT)at the block level for secure deletion, in combination with overwriting. The idea is to store everyblock through an AONT and then to overwrite only a part of it, which will render the whole blockinaccessible.

Finally, the FADE system [TLLP10] uses public-key cryptography and introduces some simplepolicies with Boolean operators governing deletion. Work of Cachin et al. [CHHS13] offers moreexpressive policies than the FADE system. It introduces a general cryptographic model for policy-based secure deletion of data in storage systems, whose security relies on the proper erasure ofcryptographic keys. Deletion operations are expressed in terms of a policy that describes datadestruction through deletion attributes and protection classes.

Integrity and consistency of data in distributed systems

Many previous systems providing data integrity rely on trusted components, which is not easilyachievable in the Cloud environment. Distributed file systems with cryptographic protection (e.g.,FARSITE [ABC+02] or SiRiUS [GSMB03]) cannot provide the strong notion of integrity andconsistency because they rely on trusted directory services for freshness. Several recent systemsensure data integrity with the help of additional trusted hardware, such as CATS [YC07], which of-fers accountability based on an immutable public publishing medium, or A2M [CMSK07], whichassumes an append-only memory. Iris [SvDJO12] relies on a trusted gateway appliance, whichmediates all requests from the clients.

With authenticated data structures [NN00, MND+04], the single-writer, multi-reader modelof remote storage can be authenticated, assuming a trusted way to distribute authenticators fromthe writer. In practice, this approach is often taken for software distribution, where new releasesare authenticated by broadcasting hash values of the packages over a mailing list. Nevertheless,this approach is not applicable for situations where multiple clients have write rights.

In the multi-client model, [MS02] have introduced the notion of fork linearizability and im-plemented SUNDR, the first system to guarantee fork-linearizable views to all clients. It detectsintegrity and consistency violations among all clients that “see” each other’s operations. Sev-eral systems have expanded this notion to different applications [FZFF10] and improved its effi-ciency [CSS07]. Others have explored aborting operations [MDSS09] or introduced weak fork lin-earizability in order to avoid blocking operations, such as FAUST [CKS11] and Venus [SCC+10].

BST [WSS09] and COP [CO14] guarantee fork linearizability for arbitrary services run by aByzantine server, not only for data storage, and support wait-freedom for commuting operations.

Vicos [BCK15] builds directly on COP, but improves the efficiency by avoiding the local statecopies at clients and by reducing the computation and communication overhead. The main advan-tage is that clients can remain offline between executing operations without stalling the protocol.Unlike SUNDR, FAUST, and Venus all use messages of size Θ(n) with n clients, the message sizein Vicos does not depend on n.

The motivation for ESCUDO-CLOUD is to further improve in this field by allowing multi-


Section 5.2: Use Case 2 61

writer integrity protection (REQ-UC1-SKM-1), as well as building practical integrity protectionprotocol that scales well in the terms of supported users.

Key-management

Some secure deletion schemes are related to monotone secret sharing schemes and to key-assignmentschemes for hierarchical access control. The survey by Crampton et al. [CMW06] presents a sum-mary of the literature on key assignment.

As Cloud environments are inherently large-scale, the use of KMIP where the client targetsa single key might not scale well (REQ-UC1-SKM-2). Thus, KLMS [BCH+10] offers a pattern-based method to simplify and to automate the deployment task for keys and certificate (REQ-UC1-IKM-3, REQ-UC1-TKM-3).

Since many of the previous tasks in Use Case 1 rely on key-management as the main de-pendency, there is an inherent dependency on key-management related requirements, as noted intheir description, most notably REQ-UC1-IKM-1 and REQ-UC1-TKM-1. As we want to reducehuman errors as much as possible, a standard approach is through automation, hence there is adependency on REQ-UC1-IKM-2 and REQ-UC1-TKM-2.

5.2 Use Case 2

The requirements (REQ-UC2-EQ-1, REQ-UC2-EQ-2) of Use Case 2 imply encrypted query pro-cessing on untrusted databases [SWP00, HILM02, DVJ+03, AES03, AKSX04, CDCdVF+09,YBDD09, BCLO12, PRZB11, PZ13]. To grant or restrict shared data access to their own person-nel in addtion to processing encrypted queries, data owners have to implement fine-grained accesscontrol mechanisms. Implementing such a multi user mode using encrypted query processing for asingle user operating with one key [SWP00, HILM02, DVJ+03, AES03, AKSX04, CDCdVF+09,BCLO12, PRZB11] combined with an additional authorization step at the application server like[RMSR04] can be compromised: Assume that a user working for the data owner and a serviceprovider’s employee collude. If the user knows the decryption key of the data and the employeeprovides the encrypted data stored in the database, they are able to decrypt all data bypassing theaccess control mechanisms. Hence, we derived requirement REQ-UC2-EQ-4.

As part of the ESCUDO-CLOUD project we will attempt the design, implementation, andevaluation of a system that securely processes relational operations over encrypted, access re-stricted relations. Its approach is to encrypt data with different access rights using different en-cryption keys (REQ-UC2-EQ-4). Further, it introduces techniques to handle query processing overdata encrypted with multiple encryption keys (REQ-UC2-EQ-3). This novel system builds on pre-vious work in encrypted query processing for a single user as described in [HILM02, DVJ+03,AES03, CDCdVF+09, PRZB11], but will be the first system that efficiently supports queries overdata encrypted with different keys. Existing approaches only support query processing with mul-tiple keys for searchable encryption which allows to check if an encrypted value matches a token[YBDD09, PZ13, ARCI13] or if there is no shared data [PRZB11].

The support of query processing over access controlled encrypted data presents two majorchallenges: The first challenge is the mapping of any complex access control structure required ina multi user scenario to an encryption enforced access control model which still allows query exe-cution (REQ-UC2-AC-1, REQ-UC2-AC-2, REQ-UC2-AC-3, REQ-UC2-AC-4, REQ-UC2-AC-5,REQ-UC2-AC-6). Previous works only focus on the access control mechanism [DCdVFJ+07]



(REQ-UC2-AC-6) or the key management [AFB05, DDCdVF+05] (REQ-UC2-KM-4). The sec-ond challenge is to efficiently execute a range of queries while minimizing the revealed informa-tion on the server and the amount of computations on the client. Current approaches for multipleusers offer either limited functionality [YBDD09, PRZB11, PZ13, ARCI13] or expose confidentialinformation to the database [Ora10].

We summarize the related work of the state-of-the-art as follows.

Queries over encrypted data

Encryption schemes supporting certain relational operations include key word search [SWP00]or range queries [AKSX04, BCLO12, PLZ13, KS14]. Some works provide data confidentialityusing tuple-wise encryption and execute queries using indexes organized in buckets [HILM02,DVJ+03] (REQ-UC2-EQ-1). Ciriani et al. satisfy privacy-constraints by (partial) encryption andfragmentation of data and rely on the application logic to process a query [CDCdVF+09]. Popaet al. introduce adjustable query-based symmetric encryption to process queries on server-side[PRZB11] (REQ-UC2-EQ-2). Tu et al. propose an extension of this system to execute complexqueries e.g. nested subqueries as seen in the TPC-H Benchmark by partitioning the query executionbetween server and client (REQ-UC2-EQ-3). Query processing with multiple keys without sharingdata is presented in [PRZB11] and using searchable encryption in [YBDD09, PZ13, ARCI13].Ferretti et al. introduce a proxy concept to handle multiple users in the CryptDB setting, but donot present an experimental evaluation or a security analysis to prove their claims [FCM13].

Joins over encrypted data

Deterministic encryption schemes that offer symmetric and transitive proxy re-encryption are pre-sented in [PH78, PRZB11]. Hacigümüs et al. require extensive query rewriting to compute joins[HILM02]. Agrawal et al. propose an interactive approach [AES03]. Furukawa et al. provide anon-transitive and non-symmetric approach to compute a join such that a probabilistic encryptionis degraded to be deterministic in the single user mode [FI13]. The encryption scheme presentedin [ARCI13] also handles join operations, but no confidentiality guarantees are provided.

Access Control

A system for encryption enforced access control for outsourced data is proposed in [DCdVFJ+07](REQ-UC2-AC-6), but this solution does not support query execution on encrypted data. Rizvi etal. introduce authorization views that enable the specification of access policies using SQL querieson the application level [RMSR04]. This restricts the access of users but does not prevent a serviceprovider or an intruder from learning the data stored on the database.

Key Management

The key management strategies introduced in [AFB05, DDCdVF+05] (REQ-UC2-KM-4) can becombined with our access control model. The method provide a way of securely generating sharedgroup keys from public information and one secret key.



5.3 Use Case 3

The functional requirements of Use Case 3 are concerned with the security and management ofdata that is hosted on third party infrastructures, for example in the form of file and block stor-age, object storage and Big Data clusters. These problems are further complicated in the Cloudcomputing environment as the data can be replicated and moved automatically to cater for thescalability and reliability needs of the Cloud providers customers, thus increasing the risk of a se-curity compromise. In addition to the data security concerns, most customers also have to abide bytheir company’s data protection policies and governmental regulatory compliance (e.g., HIPAA,HITECH, Sarbanes-Oxley, GLB, and PCI DSS). Furthermore, a customer can make use of manyother CSPs offering storage services, in addition to BT Cloud Compute, with each Cloud provideroffering its own Application Programming Interface (API), specialised services, and security func-tionalities to satisfy various user requirements. Therefore, in this use case we will provide a Cloudsecurity service that provides data protection as a service to customers for different types of storagemedia that works seamlessly across multiple Cloud vendors.

Overview of Tasks Contributing to Use Case 3

The main task contributing to the implementation of the Use Case 3 functional requirements isTask 4.3 (T4.3) of the Work Package 4 (WP4 - Multi-Cloud and Federated-Cloud). The purpose ofthis task is to design and develop a set of services and tools that are able to provide data protectionfor block, object and Big Data storage systems on multiple IaaS Cloud platforms. It aims toprovide the users of a federation of Cloud storage providers the capability to store encrypted dataand objects on the infrastructure of these providers in such a way that only the users have accessto the decryption keys. This will be enforced by an identity and integrity-based enforcementmechanism that will tightly integrate the key management process with a policy-based accesscontrol process, so that only authorised virtual machines and agents receive decryption keys andare able to access the encrypted devices and objects. This task will also ensure that the dataprotection service is interoperable with the storage services offered by different CSPs. It will focuson the interoperability feature by using a service store orchestrator that is able to provision thestorage services to the users of the data protection service and provision the required componentsof the data protection service on multiple CSPs.

The main components of this task are a) a key management server that will generate, host,and manage all the keys according to the requirements of the various encryption and decryptionprimitives and techniques used by the data protection service; b) a access control server that willmanage the rules and policies used to govern the release of decryption keys; c) a service orchestra-tor that will provision and manage the main components of the data protection service on multipleCloud providers; and d) a data encryption component that performs the core encryption functionsof the data protection solution. The centralised components of the data protection service solutiondesigned in this task will be deployed on the BT Cloud Compute test-bed, while also ensuring thatthe core functionality of the federated secure Cloud storage service works across multiple Cloudplatforms, including but not limited to Amazon EC2 and CloudStack etc.

We summarize the related work of the state-of-the-art in the following two sub-sections.



Data Security Solutions in the Cloud

In general, data security in the Cloud is provided through access control policies and cryptographicmethods. As typical examples, Yu et al. introduced a fine-grained access control for data inuntrusted Cloud storage (REQ-UC3-AC-1, REQ-UC3-AC-4, REQ-UC3-AC-5, REQ-UC3-KM-4, REQ-UC3-KM-5, REQ-UC3-DE-1) [YWRL10] based on a combination of three techniques:attribute-based encryption, proxy re-encryption, and lazy re-encryption. To further support datasharing, Kang et al. proposed an Identity-Based Authentication scheme by which the owner canshare his encrypted data stored in the Cloud [KZ10] while Zhao at el. [ZRL+10] presented aprogressive encryption system based on Elliptic Curve Cryptography that allows the owner toshare his encrypted data with other consumers without revealing the plain-text data to untrustedentities (REQ-UC3-KM-3, REQ-UC3-KM-6).

In addition to the above basic works, to address the issue of key loss, Huang et al. presenteda key recovery scheme in YiCloud [HLZ+11], a framework providing data privacy built on top ofSector [GG09]. The basic idea of this solution is to maintain secret shares at the partially trustedparties for key recovery. On the other hand, considering public audit-ability, Wang et al. presenteda model on Cloud storage for data integrity verification based on Merkle hash trees [WWR+11]while Almualla et al. designed a new security architecture with sharing keys [AY11] that fulfils allsecurity requirements in an environment that supports lawful interception if appropriate conditionsare met (REQ-UC3-AC-6, REQ-UC3-AC-7).

Data Encryption as a Service

Commercial Cloud computing providers such as Amazon and Google have started to provide dataencryption services for their data storages [Ama, Goo]. Their encryption services, however, arerather simple and have a number of limitations such as vendor lock-in and inflexibility in key man-agement (REQ-UC3-KM-1, REQ-UC3-KM-2, REQ-UC3-KM-3). In addition to these already de-ployed services, a number of other services were introduced as a result of various research efforts.In particular, the authors of [IKC09] introduced a Privacy as a Service, which was implementedby a set of protocols to ensure the security of data in Cloud architecture. On the other hand, theauthors of [KVA14] designed ESPRESSO, a Data Encryption as a Service for Cloud Storage Sys-tems. This service was designed for integration with two open-source Cloud storage platforms:Swift in OpenStack [Ope] and Cumulus in Nimbus [Nim]. Authors of [SG14] further presenteda Secret Storage as a Service that is designed to securely storing, tracking, and controlling accessto digital secrets such as cryptographic keys and hashed passwords (REQ-UC3-DE-2, REQ-UC3-DE-4, REQ-UC3-DE-5). Our proposed framework is different from these services in the sensethat we provide a full life-cycle of data security management and maximize the flexibility of usersin using the data encryption service in such a way that is compliant to industry standards (REQ-UC3-DE-3).

The closest works to ours are [DDEM+14] and [PSDC15]. Specifically, with respect to thework in [DDEM+14], our service is similar because both services target Multi-Cloud environ-ments and provide several options for users to customize the services (REQ-UC3-SO-1 to REQ-UC3-SO-8). The difference, however, is that the security service in that work focuses on protectingthe VM with firewalls and security tools while our focus is specifically on data encryption. Onthe other hand, while [PSDC15] shares the ideas with our work in providing data encryption as aservice, the architecture and design principles of the two works are very different.



5.4 Use Case 4

Use Case 4, "Elastic Cloud Provider", is based on a concept of dynamically extendible Cloudstorage, but implemented in a secure way (REQ-UC4-SS-4, REQ-UC4-SS-5), and without theneed to trust third parties, who may be subcontracted to provide the dynamic storage. In this usecase, the data owner will store, and manage, their encrypted data-files in the Cloud and access themusing an ESCUDO-CLOUD middleware (REQ-UC4-AC-3), via a web portal and a componentinstalled on the data owners device, where the files are stored in plain text.

The advantage of this security scenario is that the encryption is performed on the data owner’sdevice. The final storage location, and any intermediary data-in-transit storage locations, are un-able to observe the owners data in plain text. Even the CSP’s administrators cannot view the datain an intelligible form (REQ-UC4-DE-1). Thus the data owner only has to trust the ESCUDO-CLOUD middleware. Additionally the middleware will provide for the management and policyenforcement of specific user roles and rights over the data, e.g. reader, writer or owner (REQ-UC4-AC-3).

The solution has to provide strong encryption and key management facilities, whilst enablingcompliance with regulatory requirements the user might have. Additionally the solution should betransparent to any client side processes, applications and the users themselves. The objective is notto require changes to the existing infrastructure, but ensure a strong separation of responsibilities,which will provide the user with fine-grained access controls to protect their data, by users, groupsand processes.

Many CSPs provide complex security facilities, on their infrastructure, to secure the user’sdata and access to it1. However this implies the user must place a high level of trust in the CSP,as the CSP receives the data in its unencrypted form, and must be entrusted to encrypt the databut not look at it. Since the users cannot guarantee the security of their data, they may exposethemselves to an unacceptable level of risk; therefore in many cases the safest option is to encryptthe data on the user’s own device, before it every reaches the CSP. This approach has the advantagethat the data is kept safe, both in-transit, and at rest, even if the CSP subcontracts the storage ofthe user’s data to another CSP2. However managing keys and encrypting data is not a trivial taskfor the users, especially if there are multiple distinct user identities, roles and privileges to accessthe data, therefore the users may choose to utilize a third party security solution to ensure theclient side encryption and safety of their data on the CSP. The goal of Use Case 4 is to investigatepossible solutions for storing pre-encrypted data on CSPs, which requires the least amount ofeffort and management by the user, and on differing user devices, such as laptops, mobiles, etc.

Other Security Frameworks

Currently, there are some security frameworks that provide similar, or a subset of, the functionalityenvisioned for ESCUDO-CLOUD.

BoxCryptorBoxCryptor [Box] provides client side encryption, and is basically an intermediary stepbefore accessing storage services, such as Dropbox and Google Drive. However it does notoffer an integrated storage solution as part of the implementation (REQ-UC4-SS-1).

1For example oAuth or 2-step authentication.2This can occur in lean CSPs storage business models, where the CSP does not necessarily have sufficient storage

on hand to meet the contractual obligations with their user’s, but instead dynamically expands their storage capacity tomeet market demands, termed Elastic Cloud Provider.



SpiderOakSpiderOak is a better approximation to ESCUDO-CLOUD, with respect to functionality, asit provides encryption of the owners data on the client side, and storage in its own Cloud onthe server side [Spi]. It utilizes the "zero-knowledge" concept regarding the user identity,and their password. The user interacts with SpiderOak, for storing their data, etc., througha web browser or native application (REQ-UC4-AC-2, REQ-UC4-DE-3). SpiderOak is aspecific service that is required if the user wants to encrypt their data, and then export thisdata to the CSP. However it cannot store the data in the CSP’s infrastructure, in an encryptedmode by default.

TresoritTresorit[Tre] is similar in functionality to the concept of ESCUDO-CLOUD, and is one ofthe most well-rounded products on the market, at this time. Features include a) client sideencryption of the owner’s data; b) granular levels of access privileges to the data, basedon user identity; and c) access via web browser or application user interfaces. Howeverin this solution there is a charge for using the service. As in the previous case this is aspecific service that the user need to use to encrypt their data before uploading it to theCloud infrastructure. The objective is not only to encrypt the data transparently to the user,but to enrich the service that is offered without an additional charge.

Encryption libraries

This subsection discusses the relevant JavaScript libraries that are available for integrating into theUse Case 4 solution, and which can be utilised to provide data digest and encryption for the clientside implementation (REQ-UC4-AC-1, REQ-UC4-DE-2). Data digests, produced using one wayhashing algorithms, and bidirectional data encryption algorithms, are currently available for inte-gration into web applications. JavaScript APIs are available for performing basic cryptographicoperations in web applications, such as a) one way hashing; b) signature generation and verifi-cation; c) data encryption and decryption. However these features do not appear to cover all thefunctionality required to meet this ESCUDO-CLOUD use case.

Following an investigation of the available JavaScript libraries, the following candidates havebeen identified:

PolyCryptPolyCrypt is a native JavaScript implementation of the WebCrypto API [Pola]. This librarycame out of developments made by the W3C WebCrypto working group, which lets webapplications gain access to the high-grade encryption functionality that is available in thebrowser. The challenge that PolyCrypt tried to address was to allow the development com-munity to evolve the API without fully engaging with the browser vendor implementations,which was not entirely possible within the scope of the API developed by W3C WebCryptoworking group. Polycrypt is no longer under active development, but its source code andsample applications are still available on GitHub [Polb].

Stanford JavaScript Crypto LibraryThe Stanford Javascript Crypto Library (SJCL) is a project under the umbrella of the Stan-ford Computer Security Lab. Its aim is to build a secure, small footprint, and easy to usecross-browser JavaScript library for cryptography [SHB09]. It provides basic encryption



and decryption, as well as support for different cryptographic algorithms and other possi-bly useful features. Additionally, from the perspective of ESCUDO-CLOUD, it supportsa broad range of browsers on different operating systems. The source code is available onGitHub [JsD].

Crypto-JSCryptoJS is a set of standard and secure cryptographic algorithms implemented as a JavaScriptlibrary [Cry]. They claim to provide efficient cryptographic implementations, and have acommon API for access by the application itself. Currently the project is inactive but has alot of useful information regarding one way cryptographic hashes, such as MD5, and bidi-rectional encryption algorithms, such as AES. It also interoperates with OpenSSL.

Another way to encrypt the user’s data would be a browser plug-in. The plug-in could provideclient side encryption, rather than incorporating it directly into the web application. A possi-ble option, although currently inactive, might be FireGPG. It is a Firefox plug-in released underthe Mozilla Public License (MPL), which provides an integrated interface for GnuPG operationson web page text, and including encryption, decryption, signing and signature verification [Fir].However the plug-in needs to have been manually installed by the user, which is not ideal fromthe Use Case 4 perspective.


6. Conclusions

Deliverable D1.1 identified the four use cases of ESCUDO-CLOUD. Each use case then – in ad-dition to the business motivation – identified its technical requirements. Based on these identifiedrequirements this deliverable D1.2 performed an analysis. First, it extracted and generalized com-mon requirements that are applicable among several use cases – including use cases that are notnecessarily part of ESCUDO-CLOUD or that have to be developed in the future. This analysissupports the exploitation of ESCUDO-CLOUD results beyond the funding period, since it allowspotential exploiters to match their requirements to the work performed in ESCUDO-CLOUD.Second, it performed a comparison to the state-of-the-art identifying gaps that need to be closedby the research in ESCUDO-CLOUD. This helps align the efforts across ESCUDO-CLOUD andhighlights the contributions to be delivered by ESCUDO-CLOUD.

From this common requirements and state-of-the-art analysis we draw the following conclu-sions:

• The use cases cater for a wide variety of Cloud deployment scenarios. While the Cloudeconomy shows significant growth rates year-over-year, it is still in its infancy comparedto the on-premise, in-house IT. This manifests itself in a significant number of differenttypes of Cloud deployment and use which compete for the end users. Furthermore, newbusiness models explore new models of Cloud deployment all the time. Hence, particularlyin research, we need to accommodate a breadth of possible scenarios. Among them are, forexample, Single-Cloud or Multi-Cloud deployments with varying levels of trust regardingthe deployment of different components. ESCUDO-CLOUD is well equipped to researchand develop for a multitude of them. This ensures that ESCUDO-CLOUD will remainuseful no matter which direction the Cloud market is going to develop.

• As a consequence we see a wide variety of requirements in ESCUDO-CLOUD use cases.Since the use cases cater for different deployment models we see that they also have a diverseset of requirements. While for all of them security is a key aspect, they cater for diverse trustmodels and risks. This shows that – next to the Cloud market and IT supply chain – Cloudsecurity is also not well understood. However, we see the clear customer requirementsfor security necessitating projects such as ESCUDO-CLOUD. Furthermore, the variety ofrequirements makes it hard to distil common requirements across all use cases, but we wereable to generalize them, such that they are also applicable in and easily transferable toother – potentially future or outside of ESCUDO-CLOUD– use cases. The exploitationin ESCUDO-CLOUD tackles this challenge by driving each use case individually.

• Encryption or data obfuscation supports meeting many security requirements. Despite thevariety of requirements, trust levels and deployment models, all use cases include an encryp-tion or data obfuscation component that can meet the core security requirements. Encryptionor data obfuscation seems to be best suited to overcome the security challenges posed by

68

69

all the use cases of ESCUDO-CLOUD. This supports ESCUDO-CLOUD, since it allowsto focus and align the technological development, potentially allows re-use of components(also beyond the funding period) and minimizes the potential investment. Furthermore, itjustifies the investment in ESCUDO-CLOUD and the proposed plan of work minimizingthe technical and adoption risk. Encryption or data obfuscation seems to bring the userback into control over its data and operations in the Cloud. This regained control fosters themarket adoption and technological development.

• Cryptography brings with it a set of new technical challenges. From the state-of-the-artanalysis and its identified gaps we can conclude that despite the need for cryptography andits match to the requirements there are still many technical challenges to be overcome. Par-ticularly, key management – the confidentiality and availability of keys – seems to be amajor building block of future solutions. Clearly, when data is encrypted the key becomescrucially important. All uses case feature some aspect of key management – be it for ac-cess control, trust management or deletion. This shows that there is a need for projectssuch as ESCUDO-CLOUD, since not all technical challenges have been solved yet. Ei-ther development or even fundamental research is lacking behind the needs of customers.ESCUDO-CLOUD is well positioned in order to help fill these gaps and bring long-lastingvalue to the European economy.

This completes the requirements analysis of this deliverable D1.2. The use case developmentwill be driven based on this deliverable D1.2 (and D1.1). Furthermore, it will help align the work,such as a requirements driven threat analysis. Technical work packages (WP2 - WP4) are alreadyaligned in the proposal to the needs of the use cases, such that many obstacles for technologytransfer are already removed.


A. Glossary

The glossary defines terms used in the document, and is divided by letter.

A Terms

Term DefinitionAPI Application Program InterfaceAES Advanced Encryption Standard

C Terms

Term DefinitionCF Collaborative demand forecastingCIA Confidentiality, Integrity, AvailabilityCPS Collaborative planning and schedulingCRUD Create, Read, Update, DeleteCSP Cloud Service Provider

D Terms

Term DefinitionDBMS Data Base Management SystemDPaaS Data Protection as a Service

H Terms

Term DefinitionHDFS Hadoop Distributed File SystemHSM Hardware Security Module

70

71

I Terms

Term DefinitionICT Information and communications technologyIKM Infrastructure KeyIaaS Infrastructure as a Service

J Terms

Term DefinitionJBOD Just a Bunch Of Disks

K Terms

Term DefinitionKM Key ManagementKMIP Key Management Interoperability ProtocolKMS Key Management System

L Terms

Term DefinitionLDAP Lightweight Directory Access ProtocolLSC Life Support Cost

M Terms

Term DefinitionMRO Maintenance, Repair, and OperationsMTP Malicious Third Party

O Terms

Term Definition


72 Glossary

OASIS Advancing Open Standards for the Information SocietyOS Operating System

P Terms

Term DefinitionPaaS Platform as a ServicePII Personally identifiable informationPIR Private Information RetrievalPKCS Public-Key Cryptography StandardPoC Proof of Concept

R Terms

Term DefinitionREST Representative State TransferRAM Random Access Memory

S Terms

Term DefinitionSaaS Software as A ServiceSAN Storage Area NetworkSDN Software Defined NetworkingSOAP Simple Object Access ProtocolSP Service ProviderSSO Single Sign-On

T Terms

Term DefinitionTKM Tenant Key ManagementTTP Trusted Third Party


73

U Terms

Term DefinitionUI User Interface


B. Use Case Requirements to Work PackageTasks

Table B.1 includes a list of use case requirements mapped to work package tasks. Each require-ment may be addressed by multiple tasks and vice versa. As defined in the D1.1 document,requirements may depend on the implementation of other requirements. Requirements have alsobeen prioritized based on whether they are a) high - must-have; b) medium - should-have; c) low- nice-to-have .

For more detail on the dependencies and assignment of priorities, see the D1.1 document fora fuller description of the requirements.

Requirements Refer-ence

Work Package / Task Dependencies onOther Requirements

Priority

REQ-UC1-IKM-1 WP2/T2.1, WP2/T2.2 MediumREQ-UC1-IKM-2 WP2/T2.1, WP2/T2.2 REQ-UC1-IKM-1 MediumREQ-UC1-IKM-3 WP2/T2.2 REQ-UC1-IKM-1 MediumREQ-UC1-IKM-4 WP2/T2.1 REQ-UC1-IKM-2,

REQ-UC1-IKM-3Medium

REQ-UC1-TKM-1 WP2/T2.2 HighREQ-UC1-TKM-2 WP2/T2.2 REQ-UC1-TKM-1 MediumREQ-UC1-TKM-3 WP2/T2.2 REQ-UC1-TKM-1 HighREQ-UC1-TKM-4 WP2/T2.1 REQ-UC1-TKM-2,

REQ-UC1-TKM-3High

REQ-UC1-SKM-1 WP2/T2.2 REQ-UC1-TKM-1,REQ-UC1-IKM-1

High

REQ-UC1-SKM-2 WP2/T2.2 REQ-UC1-TKM-1,REQ-UC1-IKM-1

Medium

REQ-UC1-SKM-3 WP2/T2.2, WP3/T3.2 REQ-UC1-TKM-1,REQ-UC1-IKM-1,REQ-UC1-SKM-1

Medium

REQ-UC2-AC-1 WP2/T2.1, WP3/T3.1 REQ-UC2-KM-1 HighREQ-UC2-AC-2 WP2/T2.2, WP3/T3.1 REQ-UC2-KM-2 HighREQ-UC2-AC-3 WP2/T2.2, WP3/T3.3 REQ-UC2-EQ-2 HighREQ-UC2-AC-4 WP3/T3.1 MediumREQ-UC2-AC-5 WP2/T2.2, WP3/T3.1 REQ-UC2-EQ-3 LowREQ-UC2-AC-6 WP2/T2.1, WP2/T2.2,

WP3/T3.3REQ-UC2-KM-3 High

74

75

REQ-UC2-KM-1 WP2/T2.2, WP3/T3.1,WP3/T3.3

High

REQ-UC2-KM-2 WP2/T2.2, WP3/T3.1,WP3/T3.3

High

REQ-UC2-KM-3 WP2/T2.2 HighREQ-UC2-KM-4 WP2/T2.2, WP3/T3.1 REQ-UC2-KM-2 HighREQ-UC2-EQ-1 WP3/T3.3 HighREQ-UC2-EQ-2 WP3/T3.3 REQ-UC2-EQ-1 HighREQ-UC2-EQ-3 WP3/T3.3 HighREQ-UC2-EQ-4 WP3/T3.3 REQ-UC2-EQ-3 HighREQ-UC3-KM-1 WP2/T2.2 REQ-UC3-AC-7,

REQ-UC3-SO-1,REQ-UC3-SO-2

High

REQ-UC3-KM-2 WP2/T2.2 REQ-UC3-KM-1 MediumREQ-UC3-KM-3 WP2/T2.2 REQ-UC3-KM-1,

REQ-UC3-DE-1,REQ-UC3-DE-3

Low

REQ-UC3-KM-4 WP2/T2.3 REQ-UC3-KM-1 HighREQ-UC3-KM-5 WP2/T2.3 REQ-UC3-KM-1 HighREQ-UC3-KM-6 WP3/T3.1 REQ-UC3-KM-1,

REQ-UC3-DE-2Low

REQ-UC3-AC-1 WP2/T2.3 REQ-UC3-SO-1,REQ-UC3-SO-6

High

REQ-UC3-AC-2 WP2/T2.3 REQ-UC3-AC-1 MediumREQ-UC3-AC-3 WP2/T2.3 REQ-UC3-AC-1 LowREQ-UC3-AC-4 WP2/T2.3 REQ-UC3-AC-1 HighREQ-UC3-AC-5 WP2/T2.3 REQ-UC3-AC-1 HighREQ-UC3-AC-6 WP2/T2.3 REQ-UC3-AC-1,

REQ-UC3-KS-1High

REQ-UC3-AC-7 WP2/T2.3 REQ-UC3-AC-1,REQ-UC3-KM-1

High

REQ-UC3-SO-1 WP4/T4.3 HighREQ-UC3-SO-2 WP4/T4.3 MediumREQ-UC3-SO-3 WP4/T4.3 HighREQ-UC3-SO-4 WP4/T4.3 HighREQ-UC3-SO-5 WP4/T4.3 HighREQ-UC3-SO-6 WP4/T4.3 MediumREQ-UC3-SO-7 WP4/T4.3 HighREQ-UC3-SO-8 WP4/T4.3 HighREQ-UC3-DE-1 WP2/T2.1, WP2/T2.3 HighREQ-UC3-DE-2 WP2/T2.3, WP3/T3.1 MediumREQ-UC3-DE-3 WP2/T2.1 MediumREQ-UC3-DE-4 WP2/T2.3, WP3/T3.1 MediumREQ-UC3-DE-5 WP2/T2.3, WP3/T3.1 High


76 Use Case Requirements to Work Package Tasks

REQ-UC4-AC-1 WP2/T2.3 HighREQ-UC4-AC-2 WP2/T2.3 HighREQ-UC4-AC-3 WP2/T2.3 HighREQ-UC4-AC-4 WP4/T4.1 HighREQ-UC4-AC-5 WP4/T4.1 REQ-UC4-AC-6 HighREQ-UC4-AC-6 WP4/T4.1 REQ-UC4-AC-5 HighREQ-UC4-SS-1 WP4/T4.1 REQ-UC4-SS-3 HighREQ-UC4-SS-2 WP4/T4.3 HighREQ-UC4-SS-3 WP4/T4.3 REQ-UC4-SS-1 HighREQ-UC4-SS-4 WP2/T2.1, WP4/T4.1 REQ-UC4-SS-5 HighREQ-UC4-SS-5 WP2/T2.1 REQ-UC4-SS-4,

REQ-UC4-DE-1,REQ-UC4-DE-2,REQ-UC4-DE-3,REQ-UC4-DE-4

High

REQ-UC4-DE-1 WP2/T2.1 REQ-UC4-DE-2,REQ-UC4-DE-3,REQ-UC4-SS-5

High

REQ-UC4-DE-2 WP2/T2.1 REQ-UC4-DE-1,REQ-UC4-SS-5

High

REQ-UC4-DE-3 WP2/T2.1 REQ-UC4-DE-1,REQ-UC4-SS-5

High

REQ-UC4-DE-4 WP2/T2.3, WP4/T4.1 REQ-UC4-SS-5 HighTable B.1: Use Case Requirements to Work Package Tasks


C. Dimensions to Use Case Requirements

Table C.1 maps the use case requirements to the ESCUDO-CLOUD dimensions and sub-dimensions.See Section 1.3 for a description of the dimensions and sub-dimensions, and Chapter 4 for a de-scription of the categorization of these requirements under the ESCUDO-CLOUD sub-dimensionsfor the purpose of finding common requirements. The requirements references have been nor-malised so they all have the same format.

Sub-Dimension Requirement Referencea.i) Confidentiality REQ-UC1-IKM-1, REQ-UC1-IKM-2, REQ-UC1-IKM-4,

REQ-UC1-TKM-1, REQ-UC1-TKM-2, REQ-UC1-TKM-4,REQ-UC1-SKM-2, REQ-UC1-SKM-3, REQ-UC2-AC-1,REQ-UC2-AC-2, REQ-UC2-AC-3, REQ-UC2-AC-4,REQ-UC2-AC-5, REQ-UC2-AC-6, REQ-UC2-KM-1,REQ-UC2-KM-2, REQ-UC2-KM-3, REQ-UC2-KM-4,REQ-UC2-EQ-1, REQ-UC2-EQ-2, REQ-UC2-EQ-3,REQ-UC2-EQ-4, REQ-UC3-KM-1, REQ-UC3-KM-2,REQ-UC3-KM-3, REQ-UC3-KM-4, REQ-UC3-KM-5,REQ-UC3-KM-6, REQ-UC3-AC-1, REQ-UC3-AC-2,REQ-UC3-AC-3, REQ-UC3-AC-4, REQ-UC3-AC-5,REQ-UC3-AC-6, REQ-UC3-AC-7, REQ-UC3-SO-1,REQ-UC3-DE-1, REQ-UC3-DE-2, REQ-UC3-DE-4,REQ-UC3-DE-5, REQ-UC4-AC-1, REQ-UC4-AC-2,REQ-UC4-AC-4, REQ-UC4-SS-4, REQ-UC4-SS-5,REQ-UC4-DE-1, REQ-UC4-DE-2, REQ-UC4-DE-3,REQ-UC4-DE-4

a.ii) Integrity REQ-UC2-AC-5, REQ-UC2-AC-6, REQ-UC2-KM-1,REQ-UC2-KM-2, REQ-UC2-KM-3, REQ-UC2-KM-4,REQ-UC3-KM-1, REQ-UC3-KM-2, REQ-UC3-KM-3,REQ-UC3-KM-4, REQ-UC3-KM-5, REQ-UC3-KM-6,REQ-UC3-AC-1, REQ-UC3-AC-2, REQ-UC3-AC-3,REQ-UC3-AC-4, REQ-UC3-AC-5, REQ-UC3-AC-6,REQ-UC3-AC-7, REQ-UC3-SO-1, REQ-UC3-DE-1,REQ-UC3-DE-2, REQ-UC3-DE-3, REQ-UC3-DE-4,REQ-UC3-DE-5, REQ-UC4-SS-5, REQ-UC4-DE-4

a.iii) Availability REQ-UC1-IKM-1, REQ-UC1-IKM-2, REQ-UC1-TKM-1,REQ-UC1-TKM-2, REQ-UC1-SKM-1, REQ-UC1-SKM-2,REQ-UC1-SKM-3, REQ-UC3-KM-1, REQ-UC3-KM-2,REQ-UC3-KM-3, REQ-UC3-KM-4, REQ-UC3-KM-5,

77

78 Dimensions to Use Case Requirements

REQ-UC3-KM-6, REQ-UC3-AC-1, REQ-UC3-AC-2,REQ-UC3-AC-3, REQ-UC3-AC-4, REQ-UC3-AC-5,REQ-UC3-AC-6, REQ-UC3-AC-7, REQ-UC3-SO-1,REQ-UC3-DE-1, REQ-UC3-DE-2, REQ-UC3-DE-3,REQ-UC3-DE-4, REQ-UC3-DE-5, REQ-UC4-AC-5,REQ-UC4-AC-6, REQ-UC4-SS-2, REQ-UC4-SS-5,REQ-UC4-DE-4

b.i) Access by data REQ-UC1-IKM-1, REQ-UC1-TKM-1, REQ-UC2-AC-4,owners REQ-UC2-KM-1, REQ-UC2-KM-3, REQ-UC3-KM-1,

REQ-UC3-KM-2, REQ-UC3-KM-4, REQ-UC3-KM-5,REQ-UC3-AC-1, REQ-UC3-AC-2, REQ-UC3-AC-4,REQ-UC3-AC-5, REQ-UC3-SO-1, REQ-UC3-DE-1,REQ-UC3-DE-3, REQ-UC4-AC-1, REQ-UC4-AC-2,REQ-UC4-AC-3, REQ-UC4-AC-5, REQ-UC4-AC-6,REQ-UC4-SS-2, REQ-UC4-SS-5, REQ-UC4-DE-1,REQ-UC4-DE-2, REQ-UC4-DE-3, REQ-UC4-DE-4

b.ii) Selective sharing REQ-UC1-IKM-2, REQ-UC1-TKM-2, REQ-UC1-SKM-3,with other users/owners REQ-UC2-KM-1, REQ-UC2-AC-2, REQ-UC2-AC-4,

REQ-UC2-AC-5, REQ-UC2-KM-2, REQ-UC2-KM-4,REQ-UC3-KM-6, REQ-UC3-DE-2, REQ-UC3-DE-4,REQ-UC3-DE-5, REQ-UC4-AC-4, REQ-UC4-SS-5

c.i) Upload/download REQ-UC1-IKM-1, REQ-UC1-TKM-1, REQ-UC3-KM-2,REQ-UC4-SS-2, REQ-UC4-DE-4

c.ii) Fine-grained REQ-UC1-IKM-2, REQ-UC1-TKM-2, REQ-UC2-AC-3,retrieval REQ-UC2-AC-4, REQ-UC2-EQ-1, REQ-UC2-EQ-2,

REQ-UC2-EQ-3, REQ-UC2-EQ-4, REQ-UC3-AC-7,REQ-UC4-DE-1, REQ-UC4-DE-2, REQ-UC4-DE-3

c.iii) Write operations REQ-UC2-EQ-1, REQ-UC2-EQ-2, REQ-UC2-EQ-3,REQ-UC2-EQ-4, REQ-UC4-AC-2, REQ-UC4-SS-1,REQ-UC4-SS-3, REQ-UC4-SS-5

d.i) Single-Cloud REQ-UC1-IKM-3, REQ-UC1-TKM-3, REQ-UC3-SO-1,provider REQ-UC4-SS-5d.ii) Multi-Cloud and REQ-UC3-KM-1, REQ-UC3-KM-2, REQ-UC3-KM-5,Federated-Cloud REQ-UC3-KM-6, REQ-UC3-AC-1, REQ-UC3-SO-2,

REQ-UC3-SO-3, REQ-UC3-SO-4, REQ-UC3-SO-5,REQ-UC3-SO-6, REQ-UC3-SO-7, REQ-UC3-SO-8,REQ-UC4-SS-2, REQ-UC4-SS-3, REQ-UC4-SS-5

Table C.1: Dimensions and Use Case Requirements


D. Common Requirements

The following tables contain the list of common ESCUDO-CLOUD requirements identified fromthe use cases. The tables consist of two columns; the requirement’s reference code and a longdescription of the requirement. Each itemized requirement is drawn from one or more of thesections in the Common Terms and Concepts, Chapter 2, and Synthesis of Common Requirements,Section 4.2.

Security Framework Requirements (SF)

Req. Ref. Description

REQ-CO-SF-1The security framework must implement a practical implementation ofthe logical trust boundary; it can’t be assumed that the data owner orCSP will do this.

REQ-CO-SF-2 To be considered a trusted third party, the third party must pass regularsecurity audits that are commensurate with the data owners regulatorysecurity requirements.

REQ-CO-SF-3 Data, keys and control messages must be transferred over a secure chan-nel between systems, such as a VPN tunnel or SSL connection.

REQ-CO-SF-4 The security framework may implement functionality to delete theuser’s data by deleting the encryption key rather than the data itself,termed deletion by data obfuscation.

REQ-CO-SF-5 If the security framework performs deletion by data obfuscation, theencryption algorithm must be sufficiently strong so that a brute forceattack method could not decrypt the data during the useful life of thedata.

REQ-CO-SF-6 Deletion by data obfuscation can only be used in security scenarioswhere the security framework can guarantee that the keys will be deletedon all distributed key managers and encryption agents; even if the con-nection to those components is permanently severed.

REQ-CO-SF-7 The syndication of encryption keys from a key manager to other keymanagers, encryption agents or other security framework componentsshould be transparent to the user’s.

REQ-CO-SF-8 The security framework should conform to industry security standards,including EU directive 95/46/EC, OASIS KMIP, FIPS-140, PKCS#11and PKCS#12.

REQ-CO-SF-9 The security framework must ensure that the data is kept available unlessthe data owner, administrator or authorized user specifically deletes it.

79

80 Common Requirements

REQ-CO-SF-10 If the user signs on to the security framework using a user name andpassword, they must either sign on over a secure channel or a componentof the security framework installed on their own system.

REQ-CO-SF-11 If the user signs on to the security framework via a framework compo-nent installed on their own system, the locally installed component maycache the user’s credentials so that they do not have to repeatedly signon to the framework.

REQ-CO-SF-12 If a locally installed security framework component caches the user’scredentials, mechanisms must be put in place to prevent man-in-the-middle and session hijacking attacks.

REQ-CO-SF-13 If a locally installed security framework component caches the user’scredentials, the credentials must be stored locally in a secure way.

REQ-CO-SF-14 If a user sign on repeatedly fails, the user’s account should be locked outand can only be reset by an administrator.

REQ-CO-SF-15 If an administrator sign on repeatedly fails, the administrator’s accountshould be locked out and can only be reset by an another administrator.

REQ-CO-SF-16 Where the security scenario permits it, the security framework shouldprovide a separation of concerns, e.g. if the TTP encrypts the user’sdata it should not store it, and if the CSP stores the data it should not seeit in plain text.

REQ-CO-SF-17 An authorized user should be able to access the data via the securityframework even when the data owner’s system is not available, e.g. theuser can directly connect to the security framework via the TTP.

REQ-CO-SF-18 The CSP must provide mechanisms to ensure that the data owner’s datais not maliciously or accidentally overwritten as part of a write opera-tion, and that only requests from the data owner’s security frameworkcan modify existing data.

REQ-CO-SF-19 The security framework will implement at least three types of compo-nent, key manager, access controller and data obfuscation agent; typi-cally the data obfuscation agent will be an encryption agent.

REQ-CO-SF-20 The security framework components can be packaged as a single unit,as dispersed components on separate systems, or a combination thereof.

REQ-CO-SF-21 The security framework must implement measures to validate that allcomponents inside the CSP are trusted.

REQ-CO-SF-22 If the security framework installs components, or requires componentsto be installed, on the user’s system, the user must be provided withmechanisms or procedures to verify that the components are trusted.

REQ-CO-SF-23 The security framework must provide one or more agents to obfuscatethe user’s data, typically these will be encryption agents.

REQ-CO-SF-24 If the security framework components are dispersed control messageswill be required to be sent over secure channels between the compo-nents.


81

REQ-CO-SF-25 When a user uploads data via the security framework, the frameworkwill automatically generate keys to encrypt the data; likewise if a userdeletes a specific piece of data or data part, the keys are also deleted.

REQ-CO-SF-26 The security framework component that triggers the generation of theencryption keys may vary depending on the specific implementation ofthe security scenario.

REQ-CO-SF-27 If the key manager and access controller are packaged as a single unit,each administrator should have one sign on for both components.

REQ-CO-SF-28 If the key manager and access controller are packaged as a single unit,they should have a single UI, API or command line interface to bothcomponents.

REQ-CO-SF-29 Data that crosses the trust boundary must be in a form that is unintelli-gible to those that do not have the privileges to it.

REQ-CO-SF-30 Other than the simple case where the data owner wants their data to beencrypted as a whole, the security framework must provide mechanismsfor the data to be divided into logical data parts, which are individuallyidentified and encrypted.

REQ-CO-SF-31 If the security framework divides data into default data parts, an admin-istrator must have the ability to override the default data divisions.

REQ-CO-SF-32 Using a suitable mechanism, such as a data digest, the security frame-work must ensure that the CSP or MTP have not modified the data dur-ing its storage; ideally the data integrity check should be performed ona regular basis, and not just when the data is requested by the user.

REQ-CO-SF-33 The security framework should support the separate encryption of dataparts, otherwise the CSP would require visibility of the unencrypted datato return a portion of it to the user.

REQ-CO-SF-34 The security framework may provide a mechanism to allow an autho-rized user to search for the part of the data they require, which is asso-ciated with the meta-data in the access controller.

REQ-CO-SF-35 The security framework should provide the administrators a choice ofencryption key algorithms, such as AES128, AES256, 3DES, etc.

REQ-CO-SF-36 Data obfuscation has a associated cost and limits the way it can be pro-cessed, therefore it should be obfuscated to a level that is suitable for thesensitivity of its contents and the operations to be performed on it.

REQ-CO-SF-37 Where data needs to be processed in an encrypted state, the securityframework will implement mechanisms for processing of partially de-crypted data, such as multi-layer encryption.

REQ-CO-SF-38 The security framework should be designed so that it can scale to meetincreasing data storage and retrieval requirements.

REQ-CO-SF-39 The security framework must implement mechanisms to automaticallyresolve conflicts in its internal state, i.e. the resolution of internal con-flicts must be transparent to the user.

Table D.1: Common Security Framework Requirements



Key Manager Requirements (KM)


REQ-CO-KM-1The key manager is responsible for generating, storing, syndicating anddeleting the encryption keys.

REQ-CO-KM-2 On initial setup the data owner will be provisioned with at least one keymanager and an administrator account to control its functionality.

REQ-CO-KM-3 The owner’s administrator account can create other user or administratoraccounts.

REQ-CO-KM-4 An administrator account can perform the CRUD operations on otheruser and administrator accounts.

REQ-CO-KM-5 The key manager will transparently manage the life cycle of the key.REQ-CO-KM-6 The key manager will only issues keys to users and TTPs that are autho-

rized to receive them, in accordance with the policies managed by theaccess controller.

REQ-CO-KM-7 Where a child key manager is located on a CSP, the child key managershould retain the encryption keys for no longer than is necessary for theefficient operation of the security framework.

REQ-CO-KM-8 An administrator must be able to override the key managers automatedprocesses, and manage the keys manually, however the key managermust ensure that consistent key state is maintained across the securityframework.

REQ-CO-KM-9 If multiple data owners are hosted on the same key manager instance,the key manager must be implemented in such a way that the encryptionkeys in the key store are completely isolated from each other.

REQ-CO-KM-10 The key manager must reside inside the data owner’s trust boundary.REQ-CO-KM-11 The key manager is placed or instantiated in the data owners trust bound-

ary either by the data owner themselves or a TTP, so that the authenticityof the controller can be verified.

REQ-CO-KM-12 The key manager will only create, read, update or delete encryption keysfor administrators or other components of the security framework.

REQ-CO-KM-13 If the key manager is in a peer-to-peer relationship with other key man-agers in the security framework, keys can be generated on any key man-ager, and the generating key manager is responsible for syndicating thekeys to the other key managers.

REQ-CO-KM-14 If the key manager is in a peer-to-peer relationship with other key man-agers in the security framework, any key manager can issue a controlmessage to delete the key on the other key managers.

REQ-CO-KM-15 If the key manager is in a parent/child relationship with other key man-agers in the security framework, only the master key manager can gen-erate keys, which are then syndicated to the child key managers.


83

REQ-CO-KM-16 If the key manager is in a parent/child relationship with other key man-agers in the security framework, only the master key manager can issuea control message to delete a key on the child key managers.

REQ-CO-KM-17 Whilst key updates are being syndicated between key managers or othersecurity framework components, there is a window where the frame-work is in an inconsistent state, therefore the security framework mustimplement functionality to ensure that the updates are done in a timelymanner and that all operations are deterministic.

REQ-CO-KM-18 The key manager will be resilient, so that if a manager instance is ir-revocably lost, a replacement manager can be instantiated, in a timelymanner, without loosing any of the encryption keys.

REQ-CO-KM-19 A user will only be required to have a single login, even if there aremultiple access controllers.

REQ-CO-KM-20 If the security framework performs deletion by data obfuscation, the keymanagers must ensure that all copies of the data part’s encryption keysare deleted, and can’t be recovered by any means.

REQ-CO-KM-21 Where a child key manager is located on a CSP, the child key managershould retain the encryption keys for no longer than is necessary for theefficient operation of the security framework.

REQ-CO-KM-22 The CSP must not have administrator privileges to the data owner’s keymanager instance, unless they are specifically granted access due to ex-traordinary circumstances, and only with suitable safeguards in place.

REQ-CO-KM-23 To provide fine grained access, keys for data parts should be createdusing a parent/child key hierarchy generated from a master key witha suitably algorithm; the master key should not be syndicated to theencryption agents.

REQ-CO-KM-24 If the security framework implements multi-layer encryption, for eachmulti-encrypted data part the key manager must store a key for eachencryption schema.Table D.2: Common Key Manager Requirements

Access Controller Requirements (AC)


REQ-CO-AC-1On initial setup the data owner will be provisioned with at least oneaccess controller and an administrator account to manage it.

REQ-CO-AC-2 The access controller will store its policies in an access control matrix.REQ-CO-AC-3 The access controller stores meta-data on users, groups and administra-

tors.REQ-CO-AC-4 The access controller stores meta-data on the data or data parts; includ-

ing their identifiers, location, data digest and associated encryption keys.



REQ-CO-AC-5 The access controller links data or data parts to users, and specifies whataccess rights a user has over a certain piece of data, e.g whether the usercan create, read, modify or delete’s specific data on the storage managedby the data owners security framework.

REQ-CO-AC-6 The access controller may optionally provide rules or policies that gov-ern how and when the data or data parts can be accessed, e.g. a certaingroup of users can only access a specific data part during normal trad-ing hours. These rules or policies are set by the administrator based onfunctionality provided by the controller.

REQ-CO-AC-7 The access controller will be resilient, so that if a controller instance isirrevocably lost, a replacement controller can be instantiated, in a timelymanner, and the original policies reinstated.

REQ-CO-AC-8 If multiple data owners are hosted on the same access controller in-stance, the access controller must be implemented in such a way thatthe users, policies, etc. in the access control matrix, are completely iso-lated from each other.

REQ-CO-AC-9 The access controller will only issues data policies users and TTPs thatare authorized to receive them, in accordance with the policies in theaccess control matrix.

REQ-CO-AC-10 The access controller must reside inside the data owner’s trust boundary.REQ-CO-AC-11 The access controller is placed or instantiated in the data owners trust

boundary either by the data owner themselves or a TTP, so that the au-thenticity of the controller can be verified.

REQ-CO-AC-12 The owner’s administrator account can create other user, group or ad-ministrator accounts.

REQ-CO-AC-13 An administrator can create, read, update and delete other user, groupand administrator accounts.

REQ-CO-AC-14 A user will only be required to have a single login, even if there aremultiple access controllers.

REQ-CO-AC-15 An administrator can create, read, update and delete a user’s or group’saccess privileges to individual data parts.

REQ-CO-AC-16 The access controller will only create, read, update or delete data poli-cies from administrators or other components of the security framework.

REQ-CO-AC-17 The access controller will restrict create, read, update or delete opera-tions based on the security framework component performing the oper-ation, and the user making the request.

REQ-CO-AC-18 An administrator must be able to override the access controller’s au-tomated processes, and manage the users and data policies manually,however the access controller must ensure that consistent access controlmatrix state is maintained across the security framework.

REQ-CO-AC-19 Where a child access controller is located on a CSP, the child access con-troller should retain the user information and data policies for no longerthan is necessary for the efficient operation of the security framework.


85

REQ-CO-AC-20 The CSP must not have administrator privileges to the data owner’saccess controller instance, unless they are specifically granted accessdue to extraordinary circumstances, and only with suitable safeguardsin place.

REQ-CO-AC-21 If the security framework implements multi-layer encryption, for eachmulti-encrypted data part the access controller must store the sequenceof encryption schemas applied, their associated encryption keys, the op-erations that can be applied at each level, and the operations that can beperformed by specific users or groups.

REQ-CO-AC-22 If the access controller is in a peer-to-peer relationship with other accesscontrollers in the security framework, users, groups, administrators anddata policies can be updated on any access controller, and the generatingaccess controller is responsible for syndicating the updates to the otherkey managers.

REQ-CO-AC-23 If the access controller is in a parent/child relationship with other accesscontrollers in the security framework, only the master access controllercan update users, groups, administrators and data policies, which arethen syndicated to the child access controllers.

REQ-CO-AC-24 Whilst access control matrix updates are being syndicated between ac-cess controllers or other security framework components, there is a win-dow where the framework is in an inconsistent state, therefore the secu-rity framework must implement functionality to ensure that the updatesare done in a timely manner and that all operations are deterministic.

Table D.3: Common Access Controller Requirements

Encryption Agent (EA)


REQ-CO-EA-1The encryption agent can be implemented as a standalone security com-ponent, combined with other components of the security framework, orembedded into another trusted software component, such as a DBMS.

REQ-CO-EA-2 By default the encryption agent should divide the data into parts, whichare separately encrypted, unless an administrator overrules the defaults.

REQ-CO-EA-3 The encryption agent will request a new encryption key, from the keymanager, for each data part that is encrypted.

REQ-CO-EA-4 The encryption agent or access controller will uniquely identify eachdata part that is encrypted, and return the identifier to the user.

REQ-CO-EA-5 If the data is sent directly from the user’s system to the encryption agenton the CSP, the encryption agent will be responsible for triggering thegeneration of the associated encryption keys and meta-data.



REQ-CO-EA-6 If the data is sent directly from the user’s system to the encryption agenton the CSP, the encryption agent will be responsible for dividing thedata into logical data parts, based on rules typically stored in the accesscontroller.

REQ-CO-EA-7 The encryption agent should retain the encryption keys for no longerthan is necessary for the efficient operation of the security framework.

REQ-CO-EA-8 Where the encryption agent is located inside the trust boundary on theCSP’s environment, the CSP must provide sufficient processing powerso that the encryption/decryption process can be performed in a timelymanner.

REQ-CO-EA-9 Where the encryption agent is located inside the trust boundary on theCSP’s environment, the user’s data should be encrypted as soon as prac-tically possible; likewise on leaving the CSP’s environment, the datashould be decrypted as late as is possible.

REQ-CO-EA-10 If the encryption agent is located inside the trust boundary on the CSP’senvironment, it must not maintain any long term state, i.e. all encryptionkeys and meta-data must be held in memory, to prevent the CSP fromrecreating them from long term storage.

REQ-CO-EA-11 If the encryption agent is located inside the trust boundary on the CSP’senvironment, there must be some mechanism to validate that the agentis trusted, either by syndicated an instance of the agent from the TTP, orby validating the agent’s digest is authentic.

REQ-CO-EA-12 The encryption agent should support multiple encryption schemas,which would be required for multi-layer encryption.

REQ-CO-EA-13 If the security framework implements multi-layer encryption, the en-cryption agent must be able to apply successive encryption schemas tothe data or data parts.

Table D.4: Common Encryption Agent Requirements


Bibliography

[ABC+02] A. Adya, W. J. Bolosky, M. Castro, G. Cermak, R. Chaiken, J. R. Douceur,J. Howell, J. R. Lorch, M. Theimer, and R. P. Wattenhofer. FARSITE: Feder-ated, available, and reliable storage for an incompletely trusted environment. InProc. 5th Symp. Operating Systems Design and Implementation (OSDI), pages46–66, 2002.

[AES03] R. Agrawal, A. Evfimievski, and R. Srikant. Information sharing across privatedatabases. In Proceedings of the ACM Conference on Management of Data, SIG-MOD ’03, pages 86–97, 2003.

[AFB05] M. J. Atallah, K. B. Frikken, and M. Blanton. Dynamic and efficient key man-agement for access hierarchies. In Proceedings of the 12th ACM Conference onComputer and Communication Security, CCS ’05, pages 190–202, 2005.

[AKSX04] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Order preserving encryption fornumeric data. In SIGMOD ’04, 2004.

[Ama] Amazon Encryption Service. http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html. Accessed: 2015-07-07.

[ARCI13] M. R. Asghar, G. Russello, B. Crispo, and M. Ion. Supporting complex queriesand access policies for multi-user encrypted databases. In Proceedings of the2013 ACM Workshop on Cloud Computing Security Workshop, CCSW ’13, pages77–88, 2013.

[AY11] S. A. Almulla and C. Y. Yeun. New secure storage architecture for cloud com-puting. In Proceedings of the International Conference on Future InformationTechnology (FutureTech), pages 75–84, 2011.

[BCH+10] M. Björkqvist, C. Cachin, R. Haas, X. Hu, A. Kurmus, R. Pawlitzek, andM. Vukolic. Design and implementation of a key-lifecycle management system.In Financial Cryptography and Data Security, 14th International Conference, FC2010, Tenerife, Canary Islands, January 25-28, 2010, Revised Selected Papers,pages 160–174, 2010.

[BCK15] M. Brandenburger, C. Cachin, and N. Knezevic. Don’t trust the cloud, verify:integrity and consistency for cloud object stores. In Proceedings of the 8th ACMInternational Systems and Storage Conference, SYSTOR 2015, Haifa, Israel, May26-28, 2015, pages 16:1–16:11, 2015.

[BCLO12] A. Boldyreva, N. Chenette, Y. Lee, and A. O’Neill. Order-preserving symmetricencryption. IACR Cryptology ePrint Archive, 2012.

87

88 Bibliography

[BCP03] E. Bresson, D. Catalano, and D. Pointcheval. A simple public-key cryptosystemwith a double trapdoor decryption mechanism and its applications. In Advancesin Cryptology-ASIACRYPT 2003, pages 37–54. Springer, 2003.

[BL96] D. Boneh and R. J. Lipton. A revocable backup system. In Proceedings of the6th USENIX Security Symposium, San Jose, CA, USA, July 22-25, 1996, pages91–96, 1996.

[Box] Boxcryptor official website. https://www.boxcryptor.com/.

[CDCdVF+09] V. Ciriani, S. De Capitani di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, andP. Samarati. Keep a few: Outsourcing data while maintaining confidentiality. InProceedings of the 14th European Conference on Research in Computer Security,ESORICS ’09, pages 440–455, Berlin, Heidelberg, 2009. Springer-Verlag.

[CFIJ99] G. D. Crescenzo, N. Ferguson, R. Impagliazzo, and M. Jakobsson. How to forgeta secret. In STACS 99, 16th Annual Symposium on Theoretical Aspects of Com-puter Science, Trier, Germany, March 4-6, 1999, Proceedings, pages 500–509,1999.

[CHHS13] C. Cachin, K. Haralambiev, H. Hsiao, and A. Sorniotti. Policy-based secure dele-tion. In 2013 ACM SIGSAC Conference on Computer and Communications Se-curity, CCS’13, Berlin, Germany, November 4-8, 2013, pages 259–270, 2013.

[CKS11] C. Cachin, I. Keidar, and A. Shraer. Fail-aware untrusted storage. SIAM Journalon Computing, 40(2):493–533, April 2011.

[CMSK07] B.-G. Chun, P. Maniatis, S. Shenker, and J. Kubiatowicz. Attested append-onlymemory: Making adversaries stick to their word. In Proc. 21st ACM Symposiumon Operating Systems Principles (SOSP), pages 189–204, 2007.

[CMW06] J. Crampton, K. M. Martin, and P. R. Wild. On key assignment for hierarchicalaccess control. In 19th IEEE Computer Security Foundations Workshop, (CSFW-19 2006), 5-7 July 2006, Venice, Italy, pages 98–111, 2006.

[CO14] C. Cachin and O. Ohrimenko. Verifying the consistency of remote untrustedservices with commutative operations. In M. K. Aguilera, L. Querzoni, andM. Shapiro, editors, Proc. 18th Intl. Conference on Principles of Distributed Sys-tems (OPODIS), volume 8878 of Lecture Notes in Computer Science, pages 1–16.Springer, 2014.

[Cry] Crypto-js - javascript implementations of standard and secure cryptographic al-gorithms. https://code.google.com/p/crypto-js/.

[CSS07] C. Cachin, A. Shelat, and A. Shraer. Efficient fork-linearizable access to un-trusted shared memory. In Proc. 26th Annual ACM Symposium on Principles ofDistributed Computing (PODC), pages 129–138. ACM, 2007.

[DCdVFJ+07] S. De Capitani di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, and P. Samarati.Over-enrcryption: Management of access control evolution on outsourced data.In Proceedings of the 33rd Conference on Very Large Databases, VLDB ’07,pages 123–134, 2007.


Bibliography 89

[DDCdVF+05] E. Damiani, S. De Capitani di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, andP. Samarati. Key management for multi-user encrypted databases. In Proceed-ings of the ACM Workshop on Storage Security and Survivability, StorageSS ’05,pages 74–83, 2005.

[DDEM+14] J. Daniel, T. Dimitrakos, F. El-Moussa, G. Ducatel, P. Pawar, and A. Sajjad.Seamless Enablement of Intelligent Protection for Enterprise Cloud Applicationsthrough Service Store. In Proceedings of the 6th IEEE International Conferenceon Cloud Computing Technology and Science (CloudCom), pages 1021–1026,December 2014.

[DVJ+03] E. Damiani, S. D. C. Vimercati, S. Jajodia, S. Paraboschi, and P. Samarati. Bal-ancing confidentiality and efficiency in untrusted relational dbmss. In Proceed-ings of the 10th ACM Conference on Computation and Communication Security,CCS ’03, pages 93–102, 2003.

[FCM13] L. Ferretti, M. Colajanni, and M. Marchetti. Access control enforcement onquery-aware encrypted cloud databases. In Proceedings of the 2013 IEEE Inter-national Conference on Cloud Computing Technology and Science - Volume 01,CLOUDCOM ’13, pages 717–722, Washington, DC, USA, 2013. IEEE Com-puter Society.

[FI13] J. Furukawa and T. Isshiki. Controlled joining on encrypted relational database.In Proceedings of the 5th Conference on Pairing-Based Cryptography, Pairing’12, pages 46–64, 2013.

[Fir] Firegpg official website. http://pl.getfiregpg.org/s/home.

[FZFF10] A. J. Feldman, W. P. Zeller, M. J. Freedman, and E. W. Felten. SPORC: Groupcollaboration using untrusted cloud resources. In Proc. 9th Symp. on OperatingSystems Design and Implementation (OSDI), pages 337–350, 2010.

[GG09] Y. Gu and R. L. Grossman. Sector and Sphere: The Design and Implementationof a High Performance Data Cloud. Philosophical Transactions of The RoyalSociety A: Mathematical Physical and Engineering Sciences, 367(1897):2429–2445, 2009.

[Goo] Google Cloud Storage. http://googlecloudplatform.blogspot.co.uk/2013/08/google-cloud-storage-now-provides.html. Accessed: 2015-07-07.

[GSMB03] E.-J. Goh, H. Shacham, N. Modadugu, and D. Boneh. SiRiUS: Securing remoteuntrusted storage. In Proc. Network and Distributed Systems Security Symposium(NDSS), 2003.

[HFK06] V. C. Hu, D. F. Ferraiolo, and D. R. Kuln. Assessment of access control systems.Technical report, National Institute of Standards and Technology, Sep 2006.

[HILM02] H. Hacigümüs, B. Iyer, C. Li, and S. Mehrotra. Executing sql over encrypted datain the database-service-provider model. In Proceedings of the ACM Conferenceon the Management of Data, SIGMOD ’02, pages 216–227, 2002.


90 Bibliography

[HLZ+11] Z. Huang, Q. Li, D. Zheng, K. Chen, and X. Li. YI Cloud: Improving userprivacy with secret key recovery in cloud storage. In Proceedings of the 6thInternational Symposium on Service Oriented System Engineering (SOSE), pages268–272, December 2011.

[IKC09] W. Itani, A. Kayssi, and A. Chehab. Privacy as a Service: Privacy-Aware DataStorage and Processing in Cloud Computing Architectures. In Proceedings ofthe 8th IEEE International Conference on Dependable, Autonomic and SecureComputing (DASC), pages 711–716, December 2009.

[JsD] Jsdoc reference. http://bitwiseshiftleft.github.io/sjcl/doc/.

[KS14] F. Kerschbaum and A. Schröpfer. Optimal average-complexity ideal-securityorder-preserving encryption. In to appear in: CSS ’14, 2014.

[KVA14] S. Kang, B. Veeravalli, and K. M. M. Aung. ESPRESSO: An Encryption as a Ser-vice for Cloud Storage Systems. In Proceedings of the International Conferenceon Autonomous Infrastructure, Management, and Security (AIMS), pages 15–28,June 2014.

[KZ10] L. Kang and X. Zhang. Identity-Based Authentication in Cloud Storage Shar-ing. In Proceedings of the International Conference on Multimedia InformationNetworking and Security (MINES), pages 851–855, November 2010.

[MDSS09] M. Majuntke, D. Dobre, M. Serafini, and N. Suri. Abortable fork-linearizablestorage. In Proc. 13th Conference on Principles of Distributed Systems(OPODIS), volume 5923, pages 255–269. Springer, 2009.

[MND+04] C. Martel, G. Nuckolls, P. Devanbu, M. Gertz, A. Kwong, and S. G. Stubblebine.A general model for authenticated data structures. Algorithmica, 39(1):21–41,January 2004.

[MNP+14] K. Moriarty, M. Nystrom, S. Parkinson, A. Rusch, and M. Scott. Pkcs#12: Per-sonal information exchange syntax v1.1. Technical report, Internet EngineeringTask Force, 2014.

[MS02] D. Mazières and D. Shasha. Building secure file systems out of byzantine stor-age. In Proc. 21st Annual Symposium on Principles of Distributed Computing(PODC), pages 108–117. ACM, 2002.

[Nim] Nimbus. http://www.nimbusproject.org/.

[NN00] M. Naor and K. Nissim. Certificate revocation and certificate update. IEEE J.Selected Areas in Communications, 18(4):561–570, April 2000.

[Ope] OpenStack. https://www.openstack.org/.

[Ora10] Oracle Inc. Transparent data encryption: New technologies and best practices fordatabase encryption. http://www.oracle.com/us/products/database/sans-tde-wp-178238.pdf, 2010.


Bibliography 91

[PBH+05] Z. N. J. Peterson, R. C. Burns, J. Herring, A. Stubblefield, and A. D. Rubin.Secure deletion for a versioning file system. In Proceedings of the FAST ’05 Con-ference on File and Storage Technologies, December 13-16, 2005, San Francisco,California, USA, pages 19—28, 2005.

[Per07] R. J. Perlman. File system design with assured delete. In Proceedings of theNetwork and Distributed System Security Symposium, NDSS 2007, San Diego,California, USA, 28th February - 2nd March 2007, 2007.

[PH78] S. Pohlig and M. Hellman. An improved algorithm for computing logarithms overand its cryptographic significance (corresp.). IEEE Transaction on InformationTheory, 24:106–110, 1978.

[PLZ13] R. A. Popa, F. H. Li, and N. Zeldovich. An ideal-security protocol for order-preserving encoding. In Proceedings of the IEEE Symposium on Security andPrivacy, S&P ’13, pages 463–477, 2013.

[Pola] Polycrypt: A webcrypto polyfill. http://polycrypt.net/.

[Polb] Polycrypt github. https://github.com/polycrypt/polycrypt.

[PRZB11] R. A. Popa, C. M. S. Redfield, N. Zeldovich, and H. Balakrishnan. Cryptdb:Proctecting confidentiality with encrypted query processing. In Proceedings ofthe 23rd ACM Symposium on Operating Systems Principles, SOSP ’11, pages85–100, 2011.

[PSDC15] P. Pramod, A. Sajjad, T. Dimitrakos, and D. W. Chadwick. Security-as-a-Servicein Multi-cloud and Federated Cloud Environments. In Proceedings of the 9thIFIP International Conference on Trust Management (IFIPTM), pages 251–261,May 2015.

[PZ13] R. A. Popa and N. Zeldovich. Multi-key searchable encryption. IACR CryptologyePrint Archive, 2013:508, 2013.

[Rea92] R. Rivest and el. al. Rfc 1321: The md5 message-digest algorithm. Internetactivities board, 143, 1992.

[RMSR04] S. Rizvi, A. Mendelzon, S. Sudarshan, and P. Roy. Extending query rewritingtechniques for fine-grained access control. In Proceedings of the ACM Conferenceon the Management of Data, SIGMOD ’04, pages 551–562, 2004.

[SCC+10] A. Shraer, C. Cachin, A. Cidon, I. Keidar, Y. Michalevsky, and D. Shaket. Venus:Verification for untrusted cloud storage. In Proc. 2010 ACM Cloud ComputingSecurity Workshop (CCSW), pages 19–30, 2010.

[Sec01] Security requirements for cryptographic modules, May 2001.

[SG14] A. Sayler and D. Grunwald. Custos: Increasing Security with Secret Storageas a Service. In Proceedings of the Conference on Timely Results in OperatingSystems (TRIOS), October 2014.


92 Bibliography

[SHB09] E. Stark, M. Hamburg, and D. Boneh. Symmetric cryptography in javascript, Dec2009.

[Spi] Spideroak official website. https://spideroak.com/.

[Sty04] M. Stytz. Considering defense in depth for software applications. Security &Privacy, IEEE, 2(1):72–75, 2004.

[SvDJO12] E. Stefanov, M. van Dijk, A. Juels, and A. Oprea. Iris: A scalable cloud filesystem with efficient integrity checks. In Proc. 28th Annual Computer SecurityApplications Conference (ACSAC), pages 229–238, 2012.

[SWP00] D. X. Song, D. Wagner, and A. Perrig. Practical techniques for searches on en-crypted data. In Proceedings of the IEEE Symposium on Security and Privacy,S&P ’00, pages 44–55, 2000.

[TLLP10] Y. Tang, P. P. C. Lee, J. C. S. Lui, and R. J. Perlman. FADE: secure overlaycloud storage with file assured deletion. In Security and Privacy in Communica-tion Networks - 6th Iternational ICST Conference, SecureComm 2010, Singapore,September 7-9, 2010. Proceedings, pages 380–397, 2010.

[Tre] Tresorit official website: End-to-end encrypted cloud storage for business.https://tresorit.com/.

[WSS09] P. Williams, R. Sion, and D. Shasha. The blind stone tablet: Outsourcing durabil-ity to untrusted parties. In Proc. 16th Annual Network and Distributed SystemsSecurity Symposium (NDSS), pages 131–145, 2009.

[Wui12] P. Wuille. Hierarchical deterministic wallets. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki, Feb 2012. [Online; accessed 21-July-2015].

[WWR+11] Q. Wang, C. Wang, K. Ren, W. Lou, and J. Li. Enabling public auditability anddata dynamics for storage security in cloud computing. IEEE Transactions onParallel and Distributed System, pages 847–859, 2011.

[YBDD09] Y. Yang, F. Bao, X. Ding, and R. H. Deng. Multiuser private queries over en-crypted databases. Int. J. Appl. Cryptol., 1(4):309–319, August 2009.

[YC07] A. R. Yumerefendi and J. S. Chase. Strong accountability for network storage.ACM Transactions on Storage, 3(3), 2007.

[YWRL10] S. Yu, C. Wang, K. Ren, and W. Lou. Achieving Secure, Scalable, and Fine-grained Data Access Control in Cloud Computing. In Proceedings of the IEEEINFOCOM, pages 1–9, March 2010.

[ZRL+10] G. Zhao, C. Rong, J. Li, F. Zhang, and Y. Tang. Trusted Data Sharing over Un-trusted Cloud Storage Providers. In Proceedings of the 2nd International Confer-ence on Cloud Computing Technology and Science (CloudCom), pages 97–103,November 2010.


D1.2 Requirements from the Use Cases - ESCUDO-CLOUD · of common ESCUDO-CLOUD requirements, which...

Documents

Transcript of D1.2 Requirements from the Use Cases - ESCUDO-CLOUD · of common ESCUDO-CLOUD requirements, which...