A framework for user centred privacy and security in the cloud · 2.2.2 Continuous monitoring and...

CLARUS – H2020-ICT-2014 – G.A. 644024 CLARUS-D4.4-SECaaS-v1.2

© CLARUS Consortium 1

A framework for user

centred privacy and

security in the cloud

Security as a service for CLARUS

Type (distribution level) Public

Contractual date of Delivery 30/04/2016

Actual date of delivery 25/04/2016

Deliverable number D4.4

Deliverable name Security as a service for CLARUS

Version 1.2

Number of pages 35

WP / Task related to the

deliverable WP4 / Task 4.3

WP / Task responsible OFFIS

Author(s)

(in alphabetical order) Stefan Janacek (OFFIS), Antonio M. Ortiz (MTI), Sven Rosinger (OFFIS)

Partner(s) Contributing OFFIS, MTI

Document ID CLARUS-D4.4-SECaaS-v1.2

Abstract This document describes a security as a service (SECaaS) infrastructure

and concept for the CLARUS framework. This SECaaS differs from usual

SECaaS business models like anti-virus software or intrusion detection

services. While these security services are located in the trusted cloud, a

main assumption of CLARUS is that there is no general trust against the

cloud provider. The proposed SECaaS for CLARUS therefore consists of

the possibility of securing and accessing data, but still being able to profit

from cloud service providers, their hardware, services and offers and thus



circumventing the contradictions.

In total five SECaaS services have been identified:

Continuous monitoring and risk assessment of the platform

CLARUS communication with the CSP

CLARUS end user access to the CLARUS proxy

Exchange in between multiple CLARUS proxy entities

Provision of CLARUS secured data to an external user

While the first four services are in detail described in Deliverable D4.2,

the focus in this deliverable will be on the fifth service covering the

provision of CLARUS secured data to external users without a local

CLARUS proxy instance.

This service mainly bases on the creation of Secure Containers and the

secure transmission of these containers to heterogeneous targeted

devices owned by external entities. The secure containers thereby

contain the ability for external users outside the trusted zone to access

data that has been safeguarded by the obfuscation and encryption

security primitives provided by CLARUS.



Disclaimer

CLARUS (G.A. 644024) is a Research and Innovation Actions project funded by the EU Framework Programme

for Research and Innovation Horizon 2020. This document contains information on CLARUS core activities,

findings and outcomes. Any reference to content in this document should clearly indicate the authors, source,

organisation and publication date. The content of this publication is the sole responsibility of the CLARUS

consortium and cannot be considered to reflect the views of the European Commission.



Table of Contents

Disclaimer .................................................................................................................................................................3

Table of Contents .....................................................................................................................................................4

1 Introduction ......................................................................................................................................................6

1.1 Scope of the Document ............................................................................................................................6

1.2 Outline ......................................................................................................................................................6

1.3 Revision History ........................................................................................................................................7

2 Security as a Service .........................................................................................................................................8

2.1 Definition ..................................................................................................................................................8

2.2 Security as a Service for CLARUS ..............................................................................................................8

2.2.1 Actors ....................................................................................................................................................9

2.2.2 Continuous monitoring and risk assessment of the platform ..............................................................9

2.2.3 CLARUS communication with the CSP ............................................................................................... 10

2.2.4 CLARUS end user access to the CLARUS proxy .................................................................................. 11

2.2.5 Exchange in between multiple CLARUS proxy entities ...................................................................... 11

2.2.6 Provision of CLARUS secured data to an external user ..................................................................... 12

3 Background .................................................................................................................................................... 13

3.1 CLARUS Scenarios .................................................................................................................................. 13

3.2 Extended Scenarios with Security as a Service ...................................................................................... 16

3.3 Virtualisation Basics ............................................................................................................................... 18

3.3.1 Migrations & Live-Migration.............................................................................................................. 20

3.4 Hardware & Virtualisation ..................................................................................................................... 21

3.4.1 Virtualisation on x86 .......................................................................................................................... 21

3.4.2 Virtualisation on ARM ........................................................................................................................ 22

3.5 Trusted Computing & Trusted Execution Environment ........................................................................ 23

3.6 Kernel-based Virtual Machine (KVM) .................................................................................................... 24

3.7 Operating System Overhead and Tiny Linux Distributions .................................................................... 24

4 Security as a Service with Secure Containers ................................................................................................ 25

4.1 Concept .................................................................................................................................................. 25



4.2 Secure Container Details ....................................................................................................................... 26

4.3 Data Access ............................................................................................................................................ 29

4.3.1 Clear Data .......................................................................................................................................... 29

4.3.2 Minimal CLARUS Proxy ...................................................................................................................... 30

4.3.3 Referenced Data ................................................................................................................................ 31

4.4 Migrating Across Servers with Different Architectures ......................................................................... 32

5 Conclusion ..................................................................................................................................................... 34

6 Bibliography ................................................................................................................................................... 35



1 Introduction

1.1 Scope of the Document

This document describes a security as a service (SECaaS) infrastructure and concept for the CLARUS framework.

This SECaaS differs from usual SECaaS business models like anti-virus software or intrusion detection services.

While these security services are located in the trusted cloud, a main assumption of CLARUS is that there is no

general trust in the cloud provider. The proposed SECaaS for CLARUS concept therefore consists of the

possibility of securing and accessing data, while still being able to take advantage of cloud service providers,

their hardware, services and offers; thus circumventing the contradictions.

1.2 Outline

This document is structured as follows:

• Section 2 first summarizes the general understanding of the Security as a Service term and matches it with

the understanding within CLARUS. In total five security services have been identified and are described. For

those services that are not in detail described in this document, references are given to the deliverables

where the description is in.

• Section 3 first provides a brief description of the recent 1-to-1, x-to-1 and x-to-x user- and CSP-setups

addressed by CLARUS and motivates the need for a security as a service solution that allows access to be

granted to the protected content for external users outside the trusted zone that is created by the local

CLARUS proxy. On top of this, subsections 3.3 to 3.7 describe the basic technologies that are used to realize

the proposed solution such as virtualization, migration and trusted execution environment and thus define

the background to Section 4.

• Section 4 describes the SECaaS approach for the provision of CLARUS secured data to an external user based

on Secure Containers and compares multiple possible options for realising data access.

• A conclusion is given in Section 5.



1.3 Revision History

Version Date Author Description

0.1 19/02/2016 OFFIS Initial ToC

0.2 04/03/2016 Stefan Janacek (OFFIS) Added Section 2 and Draft of

Section 3

0.3 11/03/2016 Stefan Janacek (OFFIS) Finalized Section 3 and

added Section 4

0.4 04/04/2016 Stefan Janacek (OFFIS), Sven Rosinger

(OFFIS)

Added missing subsections

and general revision of the

document

1.0 06/04/2016 Stefan Janacek (OFFIS)

Release for review by

consortium partners (RHUL,

EURECOM)

1.1 25/04/2016 Stefan Janacek (OFFIS), Sven Rosinger

(OFFIS)

Final release with integrated

feedback

1.2 25/04/2016 Jesús A. Manjón (URV) Minor format changes



2 Security as a Service

2.1 Definition

Although there is no exact scientific definition of security as a service, the term means in most cases a business

model, where security services are provided on the basis of some kind of cost model. Customers can benefit

from these services without the need for paying for their own hardware, software and maintenance. This

renders the security as a service a classical cloud model. Popular examples for these services are

authentication, anti-virus software, anti-malware or spyware software, intrusion detection, and security event

management.

The main benefits mostly stated for this model are

Reduced costs

Benefits from constant updates (virus signatures for example)

External maintenance by experts, who know the systems

Full blown security packages even for smaller companies / customers

2.2 Security as a Service for CLARUS

The definition of security as a service in CLARUS differs a bit from the normally used one. This has several

reasons. One of the most important reasons is that CLARUS does not rely on trust in the cloud provider. If a

customer trusts its CSP, it is not a problem for him to send his clear data to the external cloud provider and e.g.

let him scan his data for viruses. He might even include live monitoring options for his systems, allowing an

external company directly accessing his own systems. This is a concept that is in absolute contrast to the

CLARUS model. Sensitive data should remain on local premises; everything that is outsourced should be

protected in some way. However, for example using a virus scanner on encrypted data does not make sense.

Hence, this classical understanding of security as a service does not match the CLARUS idea.

Instead, CLARUS proposes new and outstanding security models, techniques and ways of thinking, which also

leads to new concepts regarding security as a service. In CLARUS, the service consists of the possibility of

protecting, accessing and processing the data, but still being able to take advantage of cloud service providers

and their hardware, services and offers. However, this access to secured data is tightly coupled with the

CLARUS proxy, which holds the keys, management and knowledge to restore outsourced and secured data.

In the following, the actors in the context of security as a service in CLARUS are explained. Then, the five

services are described that are considered to represent the SECaaS functionality in CLARUS:

Continuous monitoring and risk assessment of the platform

CLARUS communication with the CSP

CLARUS end user access to the CLARUS proxy



Exchange in between multiple CLARUS proxy entities

Provision of CLARUS secured data to an external user

2.2.1 Actors

Throughout the document, several actors are named when the CLARUS use cases and the SECaaS is introduced.

These actors are introduced in this section and shortly described to improve the understanding of the

definitions and descriptions following in this document. SECaaS involves these actors and entities:

CLARUS end users: Users registered at a CLARUS proxy and accessing the proxy directly through the

company’s network

Security Manager: CLARUS proxy security manager that is able to grant access rights to CLARUS users.

Cloud Service Provider (CSP): The CSP offers a service to store data and compute in the cloud. The CSP

is considered to be honest but curious and thus, data that should be outsourced to the cloud should be

encrypted, obfuscated, anonymized or split.

Third party end users: End users from a third party without CALRUS access and without a CLARUS

proxy.

Hardware devices of third party end users: These devices are used by third party end users. It is

fundamental that a trust model to these devices is established in order to maintain the chain of trust

when these users can access data secured by CLARUS.

2.2.2 Continuous monitoring and risk assessment of the platform

CLARUS integrates monitoring capabilities to supervise, at run time, the data accesses and exchanges between

the users, the CLARUS proxies and the cloud providers. This continuous monitoring enables the early

identification of security issues that can affect the correct operation of the system and that may represent a

risk in terms of security and data privacy.

The monitoring module in CLARUS works together with the administration module to guarantee that the

system works properly, according to the established security policies. Monitoring is performed in a transparent

way, without disturbing the normal operation of the system. Moreover, when attacks or potential risks are

detected, countermeasures can be triggered to mitigate the effects of the detected incidents or a list of

remediation recommendations can be provided to the CLARUS system operator(s).

In order to perform the monitoring process, distributed probes are located in different parts of the system

(CLARUS proxies, network interfaces, user devices when possible, cloud services when possible, etc.) with the

aim of inspecting data transactions, and user actions and behaviour. The data is analysed in real time by the

monitoring server that is in continuous contact with a security database that contains security and privacy

information to check that the performed operations are compliant with the security and privacy policies.

According to the security database information, when a security fault is detected, the monitoring system

automatically evaluates the scope of the attack and reacts accordingly by triggering the necessary



countermeasures to mitigate the damage in the system, thus providing an attack-tolerant system

(complementary information about the attack-tolerant mechanisms integrated in CLARUS can be found in

Deliverable D3.3 “An attack-tolerant framework for the cloud V1”).

Besides the automatic application of countermeasures, administrators and security managers are informed of

any detected risk, which may represent a security or data privacy issue, allowing them to perform additional

actions to eliminate the possibility of suffering this kind of risks in the future. End users can also be informed

with statistical information regarding the utilisation of their data.

Furthermore, the deployment of distributed monitoring modules among several CLARUS proxies will enable the

detection and mitigation of coordinated attacks, making the whole system more robust against security

breaches thanks to the utilization of monitoring and security information from several CLARUS proxies.

Complementary information regarding the monitoring module integrated in CLARUS can be found in

Deliverable D4.2 “Architecture V2”.

2.2.3 CLARUS communication with the CSP

In CLARUS, the proxy holds information and metadata about the outsourced files in the cloud. If a user wants

to access (in the current context, “access” means reading and writing to the data as well as search operations

and computations) the data in the cloud, the CLARUS proxy establishes a connection to the CSP. This

connection must be able to support secure data transfers. However, there are several use cases (for example

the geo-data use case, see Deliverable D2.2 for details) where computations must be performed in the cloud.

In this case, the cloud also contains a CLARUS computation module that performs the single operations and

receives programmatic requests that contain the details of the desired computation task (origin of data, data

range…). The result is passed back to the CLARUS proxy. Figure 1 shows this process. To perform this

communication, a secure service is used. The details of this service, including protocols and data flow, will be

described in Deliverable D4.2 “Architecture V2”.



Figure 1: CLARUS communication service with the CSP

2.2.4 CLARUS end user access to the CLARUS proxy

The CLARUS end user connects to the CLARUS proxy through a user authentication module. Both explicit and

implicit authentication processes are planned. To integrate the CLARUS proxy and the entire CLARUS usage as

much as possible in existing workflows, several existing authentication mechanism will be supported by the

CLARUS proxy. Some of the details of the user authentication to the CLARUS proxy were already described in

Deliverable D4.1 in Section 4.1. Additional details will follow in Deliverable D4.2 “Architecture V2”.

2.2.5 Exchange in between multiple CLARUS proxy entities

When data should be shared between multiple CLARUS proxies, an elaborate secure service is needed to

perform several tasks regarding these proxies. First, these two proxies must authenticate against each other.

To prevent the distribution of (private) keys of the CLARUS proxy owning the data, all traffic is routed through

the proxy that owns the data. This process is pictured in Figure 2. The proxy owning the data must offer a

service that enables the secure data transfer to another authenticated proxy. The connection itself will be

established using secure methods that already exist like VPN or similar SSL-secured connections.



A detailed description of the inter-proxy communication including a protocol view on the communication will

be given in Deliverable D4.2 “Architecture V2”.

Figure 2: Data routing concept for multiple CLARUS proxies: Data access by the external proxy (CLARUS Proxy 1) to the

data owned by CLARUS Proxy 2 is routed through CLARUS Proxy 2. This eliminates the need to distribute keys.

2.2.6 Provision of CLARUS secured data to an external user

If an external user does not have the possibility of operating a CLARUS proxy, he cannot participate. Therefore,

CLARUS needs a service that offers this user the ability to collaborate with partners working on secured data.

In the remaining part of this deliverable the focus is on this service. Section 3 first provides a brief description

of the recent 1-to-1, x-to-1 and x-to-x user- and CSP-setups addressed by CLARUS and motivates the need for a

security as a service solution that allows access to be granted to the secured content for external users outside

the trusted zone. On top of this, subsections 3.3 to 3.7 describe the basic technologies that are used to realize

the proposed solution such as virtualization, migration and trusted execution environment and thus define the

background to Section 4. Section 4 then describes the approach based on Secure Containers and compares

multiple possible options for realising data access. In this case, the term “data access” stands for all possible

operations on secured data, like reading, writing or computations, depending on the use case.



3 Background

3.1 CLARUS Scenarios

CLARUS provides a way to protect data and enables users to take advantage of cloud service providers (CSP)

and the computing and storage power they purchased from them at the same time. CLARUS takes a special

focus on providing the tools and workflows that companies need for their daily business. That’s why a local

CLARUS instance was introduced that acts as a local proxy. This proxy routes all traffic to and from the cloud

and protects the data, hence connecting the end users with their protected data in the cloud. To be able to

understand the additions the security as a service functionality being described in this deliverable will bring to

the CLARUS platform, a look at the targeted scenarios is required first.

The most simple use case is shown in the following Figure 3, where a single user connects through CLARUS to a

single CSP:

Figure 3: Simple CLARUS scenario with one CSP and one user

The end user connects with his client software to the CLARUS proxy instead of directly accessing the CSP. Clear

data is only exchanged between the end user and the proxy within the local and trusted zone. The proxy



translates each user query into either encrypted or obfuscated queries, ensuring a secure data transmission to

an external cloud.

Especially in companies, it is highly unlikely that only a single person will access secured data. Thus, CLARUS will

also need to support collaborative work flows and different user profiles and access models, as shown in the

scenario in Figure 4:

Figure 4: CLARUS scenario with multiple users and one CSP

Another aspect that is not covered in these two scenarios is the possibility that a company might use several

CSPs to store or process data, as shown in Figure 5. In this case, the proxy must ensure the correct routing

towards each CSP according to the distributed data that should be accessed or stored.



Figure 5: CLARUS scenario that includes multiple users and multiple CSPs.

A special case that was not yet covered is the possibility that different companies operate their own separate

CLARUS proxies but collaborate on the same data. End users from both parties may be working on data stored

at remote CSPs, while the data is only accessible through the according CLARUS proxy. This example is pictured

in Figure 6:



Figure 6: CLARUS scenario where an external user wants to connect to a proxy.

Looking at all of these scenarios, it is quite clear that access to the protected data in the cloud requires a local

CLARUS proxy for each of the end users, who want to access outsourced and secured data. However, in reality

this might soon become a problem, since there are many use cases where a full proxy installation is not

possible. A full CLARUS proxy may consist of several services, running processes and installed modules. For

example on mobile platforms, tablets, set top boxes or other devices, which are restricted in hardware and

software, such an installation is not an option. This is the scenario where the CLARUS security as a service

comes into play.

3.2 Extended Scenarios with Security as a Service

In today’s modern and flexible world, mobile access to data is a must. However, as described in the previous

section, the original CLARUS scenarios do not include mobile access. Instead, this use case may lead to

problems, since a CLARUS proxy provides access to the data, as long as the end user is inside the trusted local

zone. For external access, it must be ensured that:

The data remains protected on the transmission path

Only the authorised user’s device is able to access the data

The CLARUS access management is maintained

Especially since an external user may not have the possibility to install and run a CLARUS proxy, these

requirements must be fulfilled through another mechanism. This is the scenario where the Security as a Service



(SECaaS) for CLARUS is used to provide a solution. Thereby, it is not important if the external user belongs to

the company operating the CLARUS proxy and just wants to have mobile access, or if the person is not

connected to the company. As long as the access rights defined in the CLARUS proxy allow access to this

person, the SECaaS must find a technical solution to enable this access, as shown in Figure 7.

Figure 7: Scenario where an external end user connects to the data secured by CLARUS.

Throughout the remaining part of this document, the SECaaS for CLARUS will be described and sustained with

an extended example of the Health Care Use Case, which was defined in D2.1 (Definition of Application Cases).

Nevertheless the approach is generic and can be applied to any other use case.

According to the CLARUS Health Care Use Case, a hospital stores patient records through a CLARUS proxy on a

secured CSP. If a doctor in this hospital wants to obtain another opinion about a diagnosis, for example from a

specialist working in another hospital, there must be some way to transmit the record to this very person.

To realise this use case, the concept of a Secure Container is introduced, which handles the secure transmission

of data. The Secure Container is explained in detail in Section 4.



Figure 8: Security as a Service for CLARUS, shown with the example of the hospital use case.

This use case is shown in Figure 8. The patient record is the content that should be transmitted. However, there

are several possibilities of the form of the data:

The data can be encrypted or obfuscated. In this case, the Secure Container is transmitted to the

device of the external user and decrypted there.

The data can be cleartext. The original CLARUS proxy has then decrypted the data and further

transmits the data in cleartext. In this case, the Secure Container must take care of protection.

The transmitted data might be only a reference to the data, lying on a remote CSP. The secure

container transmits the reference to the external device and accesses the remote data by creating a

minimal CLARUS proxy. The data access is then managed similarly to the data access in the normal

CLARUS proxy.

3.3 Virtualisation Basics

Virtualisation is a concept that allows the decoupling of operation systems and applications from the

underlying physical hardware. In non-virtualised environments, the operating system and applications are



directly installed on the hardware. In virtualised environments, only a thin layer is installed on the physical

hardware, providing the execution environment for virtual machines.

Figure 9: Virtual and non-virtual environments

This concept is shown in Figure 7. This thin layer is called the hypervisor. It may only consist of a minimal

operating system, only supporting the physical hardware. An integrated virtual machine monitor manages all

installed virtual machines. A single virtual machine now replaces the former physical hardware system,

providing virtual hardware that can be directly used by an operating system and applications. The functions

and processor calls, the operating system and the applications use are mapped by the hypervisor to the real

physical hardware. Modern processors offer virtualisation extensions to provide an improved and near-to-

native performance for virtual machines and their applications.

The benefits of virtualisation and the usage of virtual machines are numerous [1]:

In data centres, multiple virtual machines can be executed on the same physical host, maintaining full

isolation against each other and thus maintaining security and privacy rules. The concept can be used

to improve the energy efficiency of servers in data centres, since a physical server can operate multiple

systems that all had their own physical server previously.

Virtualisation allows the decoupling of hardware and software, greatly improving maintaining and life-

cycle management.

Virtualised systems can be easily cloned, allowing the spawning of new instances of predefined

applications or templates. Load balancing and reactions to changing requirements are improved.

One of the most important benefits of virtualisation is the possibility of migrating virtual machines across

different servers. This topic is covered in the following section.



3.3.1 Migrations & Live-Migration

Since virtualisation technology enables the decoupling of physical hardware and the running software, the

specific hardware used to execute a virtual machine is becoming less important. As a result, it is now possible

to stop the execution of a virtual machine, move the file of this machine to a different server and start the

execution on this target machine. However, this process involves the interruption of the virtual machine. This

migration is thus only of limited use, for example, in production systems, it is not possible to interrupt the

operation of running services.

To prevent this and to circumvent these limitations, the technique of live-migration has been developed. The

requirement for live-migrations is that all data (the virtual hard disk of virtual machines) is located on a

centralized storage server. If this is the case, a migration must only transfer the current state of the virtual

machine, which consists of the current memory.

Figure 10: Migration of a virtual machine to another physical machine.

The process of a live-migration thus transmits the memory state of a virtual machine to the desired target host

and then only switches the execution context, which only takes a few hundred milliseconds at most. By using

this process, the downtime of the virtual machine is reduced to this very short duration; an interruption of the

running services is thus prevented. However, live-migrations have strong requirements regarding the running

hypervisors, virtualisation managers and network stack.

In the context of Security as a Service for CLARUS, virtual machine migrations are used to provide access to

protected data. The use of “normal” migrations or live-migrations depends heavily on the use case and the

existing network structure. In many cases, however, it is feasible to apply normal migrations. These have fewer

requirements for the installed software stack in the network, although taking longer to realise. To cut down the

migration time, it is important to keep the virtual machine size as low as possible.



3.4 Hardware & Virtualisation

To improve performance and to enable the usage of normal and unmodified operating systems in virtualised

environments, several hardware improvements and modifications were developed. These allow a hardware

supported virtualisation instead of an entire emulation in software. The requirements and extensions

developed for virtualisation depend on the architecture and platform of the hardware and especially of the

processor used. In this section, these extensions are explained for the x86 and the ARM platform. The x86

platform is one of the major platforms for servers, especially small to mid-sized servers use this architecture,

while mainframes may consist of specialized architectures. In contrast, the ARM architecture is a small and

lightweight platform that is mainly seen in mobile devices (smartphones, tablets), set top boxes, stick

computers or similar small and dedicated devices.

Because of the variance of ARM devices and their huge market share especially with mobile computing devices,

for the CLARUS platform, it is of high interest to provide a possibility to support these devices. In this case, this

means that a user of a mobile device should be able to perform a secure connection to a CLARUS proxy,

enabling the access of secured outsourced data. Our solution includes virtualisation and virtual containers, so a

migration of these virtual containers to and from ARM devices is a requirement for this process.

3.4.1 Virtualisation on x86

On the x86 platform, two major architectures exist that provide virtualisation extensions: AMD virtualisation

(AMD-V) and Intel virtualisation (VT-x). Besides these two, there are some other processor vendors offering

their own extensions, but, especially on the server market, other vendors do not have a significant role.

The Intel VT-x technology is described in Figure 11 and allows the execution of an unmodified operating system

(OS) on processors that support VT-x. Without the extension, a “normal” operating system cannot be

virtualised, because it relies on executing processor codes, which are reserved for the native system. The

execution of these codes is performed in the so called “Ring 0”. A guest OS cannot access this ring, due to

security reasons and the restriction to unprivileged operations. The extension, however, allows a guest OS to

access Ring 0, hence the guest does not even know that it is virtualised and can execute its privileged code. The

Virtual Machine Monitor (VMM) takes care of the mapping to the underlying real hardware.

The AMD-V extension is similar to this, however, as the name states, available on the AMD platform.

The security as a service concept for CLARUS relies on hardware servers with these extensions. Almost all

server processors produced by AMD and Intel and a majority of the desktop processors support this extension.



Figure 11: Intel VT technology and the differences it makes (source [2]). With VT, a guest OS can act as a Ring 0 system,

which allows an unmodified operating system to be executed.

3.4.2 Virtualisation on ARM

The ARM architecture is different to the x86 platform in many cases. It is known for an efficient code set, small

and compact implementations on microprocessors or system on chips (SoC) and its low power consumption

potential. These benefits made it the architecture of the first choice for the vast majority of mobile and small

embedded devices.

Virtualisation on ARM was not possible for a long time, since the needed extensions (comparable to those

extensions on the x86 platform) were missing. The entire guest system was emulated in software, which made

the usage incredibly slow. Since the ARM v7-A and ARM v8-A architectures, virtualisation extensions are also

available on ARM, which allows for the first time a realistic usage of virtual machines and virtualised guests on

ARM processors. Soon, an implementation of the open source KVM hypervisor emerged for the ARM

architecture [3]. This lays the basics for the security as a service module for CLARUS and mobile devices.

The implementation uses a combination of KVM and QEMU to provide the possibility to operate virtual

machines on ARM systems. However, there were still several missing parts for live migrations and full

virtualisation support. Therefore, OFFIS developed additional extensions and tools to support live migrations

and seamless virtualisation between ARM and x86 within the EU FP7 project TRESCCA [4]. These have been

published as open source and will be used and extended to develop the security as a service for CLARUS.



3.5 Trusted Computing & Trusted Execution Environment

Software based solutions to provide security and isolation of modern electronic devices like personal

computers, mobile phones or tablets, have demonstrated limits in fending off attacks and providing assurance

of their current configuration. For this reason, to protect the system while achieving a high level of security and

isolation, hardware components were developed. These modules are used to create a Trusted Execution

Environment (TEE) on the specific system. One of the most known approaches is the Trusted Platform Module

(TPM). However, several other - partly similar modules - were developed, especially for mobile devices and

embedded systems and their processors. The security as a service approach for CLARUS takes advantage of

these systems to enhance the protection of data and to enable access only to specific and registered devices.

Since this CLARUS concept also focuses on mobile devices, a technology called ARM TrustZone is chosen for

these mobile devices.

The ARM TrustZone architecture aims to provide a security framework that enables embedded systems

protection. Instead of providing a fixed security solution, such as what it is proposed by TPM chips, it provides a

flexible infrastructure that can be customized according to the needs of the particular processing core. In order

to achieve flexibility, it offers a programmable environment that guarantees confidentiality and integrity

against specific attacks. In a TrustZone system, the applications’ execution environment is split in secure and

normal (or non-secure) worlds. The former is basically the trusted compartment, the place in which security

assets are protected and confined, while the normal world is the user’s system where common operating

systems such as Linux or Android are installed and programs or mobile apps are executed. These two worlds

are isolated by hardware signals.

This approach allows peripherals such as memory, crypto blocks, keyboard and screen to be secured in order to

protect them from software attacks. ARM processors supporting TrustZone include v8 (ARM Cortex-A57, ARM

Cortex-A53), and v7 (from the ARM1176 to the Cortex-A15) architectures, thus covering many of today’s

mobile devices and almost all future devices.

In the context of the Security as a Service for CLARUS, this TrustZone architecture is used to protect the data

that is secured by CLARUS and allows only specific, targeted devices to decrypt incoming data. Thus, attacking

the transmission of data to the targeted device will result in only receiving encrypted messages, while only the

TrustZone can decrypt the incoming data. The TrustZone will also take care of isolating the data against other

programs running on the device.

If a TEE is needed on “normal” computers like PCs or servers, a TPM chip can be used, which is already

productively used and included in most of today’s computers. The research thus focuses on embedded

solutions that need to secure CLARUS data when accessing this from mobile devices.



3.6 Kernel-based Virtual Machine (KVM)

KVM allows Linux systems to act as a hypervisor and thus manages and executes virtual machines. KVM is the

reference hypervisor for security as a service in CLARUS. It supports many CPU architectures (ARM, x86,

PowerPC, S/390, etc.) and is completely integrated in the Linux kernel.

KVM is considered the most popular hypervisor deployed in OpenStack. It is implemented as a Linux kernel

module, which effectively turns the Linux kernel into a hypervisor. On ARM, it exploits the ARM Virtualisation

Extension to create a fully-featured virtualisation environment providing hardware isolation for CPU, memory,

interrupts and timers. The KVM approach takes advantage of the existing Linux kernel infrastructure, including

the scheduler and memory management. This results in a tiny code base, compared to other hypervisors such

as XEN or VMWare ESX. KVM works by exposing a simple ioctl interface, through which a regular Linux process

can request to be turned into a virtual machine. When using QEMU/KVM, the QEMU emulator is this process,

which leverages on KVM for the processor and the memory virtualisation and provides an extensive set of

software device implementations used to emulate I/O guest devices. Thus, KVM will handle CPU context

switching when the process of a virtual machine gets scheduled by the Linux kernel, while the QEMU emulator

takes care of the VM’s I/O capabilities (e.g., storage, networking, shared memory, etc.) of each guest.

3.7 Operating System Overhead and Tiny Linux Distributions

The security as a service for CLARUS aims at migrating small secure containers to external devices that do not

have access to their own CLARUS proxy. However, migrating virtual machines is often connected to a significant

overhead, caused by the need to transmit the entire operating system and its disk image. In CLARUS, this

should be prevented and small and fast to transmit containers should be used instead of full-blown operating

system images. Such alternatives are several tiny Linux distributions that allow a full operation of software and

scripts, but also reduce their size to a minimum. For example, by using these distributions, it is possible to

achieve a migration overhead of about 10 MB. Migrating such an image is a matter of a few seconds at most

and as such is not a problem. Also, the devices that need to execute the virtual machine containing the minimal

operating system are small and embedded devices with limited hardware capacity. Using such a small

distribution does not only save migration time, but also reduces run time overhead and RAM usage. Therefore,

security as a service for CLARUS uses tiny Linux images as the operating system for the virtualised secured

containers.

CLARUS uses the Linux distribution Tiny Core Linux1 for the purpose of Secure Containers, which allows an

installation size of less than 11 MB and boot times of 2 seconds.

1 www.tinycorelinux.net



4 Security as a Service with Secure Containers

4.1 Concept

The concept of Security as a Service includes the creation of Secure Containers that contain the ability to access

the data (by using several options, which will be detailed later) and the transmission of these containers to the

targeted devices. The entire process in short can be described like this:

The user registered to the CLARUS proxy that manages the data to be shared initiates the creation of a

secure container.

The security manager/user needs to provide the encryption key for the secure container, which is the

public key of the target device’s trusted execution environment. This makes sure that the secure

container can only be decrypted by the targeted device.

The CLARUS proxy extracts the information about the data (location of storage, required decryption

details, additional metadata).

The CLARUS proxy starts the creation of a new secure container by cloning a predefined template

containing a complete virtual machine image with a minimalistic operating system and all needed

libraries.

The extracted data and all necessary metadata are stored in this virtual machine.

The entire virtual machine image, which is basically a file, is encrypted using AES and a pseudo-random

key. This makes the virtual machine image a Secure Container.

The randomly generated AES key is encrypted with the provided public key of the target’s device, thus

generating a digital envelope.

The Secure Container is transmitted to the external user, who requested access to the data.

On the external user’s device, the Secure Container is decrypted using the AES key from the digital

envelope (decrypted with the private key of the internal trusted execution environment). The result is

the virtual machine image created by the original CLARUS proxy.

On the user’s device, this virtual machine image can now be executed on a hypervisor. The user can

access the data through the virtual machine. Normally, access to the data will be handled through the

internal network protocols of the virtual machine monitor, so that the user can simply use a web

browser to access the data.

The concept is now explained in detail. The entire process relies on the creation and migration of virtual

machines. In the first step, when the user selects the data that should be shared and initiates the process of

sharing this data, all needed information to provide access to the data is serialized to a virtual machine.

At this point, CLARUS benefits already from the possibilities virtualisation offers. It is an important feature of

virtualisation to enable the fast creation of new virtual machines from existing templates. This concept is used

here to create instances of a tiny operating system with all necessary extensions included to operate a CLARUS

access protocol. By cloning such an existing template, the new virtual machine instance is available in the time



of only a few seconds at most. This concept is not new and already exploited by companies like docker2, which

enables customers to spawn their own instances of predefined applications.

The CLARUS proxy only needs to provide and add information about the specific data and the way it should be

accessed. The details of these access protocols are described in Section 4.3. Since the clone process of virtual

machine templates is a common process, which is already mature, no additional work is needed here. Also, if

the resulting virtual machine would be executed on a server with already running clones of the same template,

additional network settings might be necessary (IP address, MAC address, routing tables, …). However, the

resulting virtual machine is intended to be migrated to an external device and executed there to allow access

to specific data. Thus, the network settings remain unchanged here. Actually, these network settings are

prepared to allow a default access to the virtual machine by software running on the device to allow the user

to access the data.

Once the virtual machine is created, the encryption of it will start. This process and the details of the virtual

machine and what makes it a Secure Container is described in the next section.

4.2 Secure Container Details

The Secure Container mainly consists of an encrypted, virtualised minimal operating system with CLARUS

additions, which will be explained in detail in the following sections. This is shown in Figure 12. In detail, a

virtual machine can be serialized to a file. This file stores internal states and configurations of the virtual

machine and – of course – the virtual hard disk that stores all the data and the operating system. A very

common file format for such a file container is the open QCOW23 format, used by QEMU to store virtual

machines.

2 http://www.docker.com 3 http://www.linux-kvm.org/page/Qcow2



Figure 12: The basic structure of the virtual machine that is migrated to the external device. The virtual

machine image includes a minimal operating system and the information about the data access or the

data itself. The migration of the virtual machine is performed with an encrypted version of the image file.

This file format, however, is not secured by any means and is also used to exchange virtual machines in an

open and standardised manner. A Secure Container thus needs to add an additional security layer on top of a

virtual machine serialized to a QCOW2 file. This is achieved by using AES encryption of the entire QCOW2 file.

The reason AES is used to encrypt the file is mainly performance. Using a public-private-key encryption method

here would result in longer encryption and decryption times and it would also lead to slightly larger file sizes to

transfer.

To limit the overhead in terms of encryption time, a digital envelope is created. As shown in Figure 13, a

random AES key is generated, which is used to encrypt the QCOW2 file of the virtual machine. The random AES

key is then encrypted using RSA and the public key of the target device’s trusted execution environment. This

makes sure that the decryption of the entire virtual machine image is only possible with the private key of the

target device. Hence, only this device can execute the resulting virtual machine.

The transmission of the virtual machine image, the QCOW2 file, should be established with secure connections,

like VPN. This is a general rule, but in this case the Security as a Service solution for CLARUS does not depend

on it. However, it is in general highly advised to only use secure connections to transfer sensitive data or

information about this data, even if it is encrypted.

On the target device, the AES key that was used to encrypt the virtual machine image is first needed. It can be

obtained from the provided RSA-encrypted key message.



Figure 13: Transmission of a Secure Container to the destination hardware device

With all these information available, the original QCOW2 file can be restored on the target device and finally

executed on the installed hypervisor. In this case, this is the KVM with QEMU, as already explained in Section 2.

The KVM hypervisor in combination with the running virtual machine exposes a virtual network device, which

allows access to the virtual machine. This makes the access of the data very easy, the user might for example

just start a web browser and connect to the virtual machine, which then presents the desired data. This

process is pictured in Figure 14. Of course, all network aware applications can be used to access the specific

data, but the web browser is the most common example.

An additional benefit of the virtualisation technique applied here in combination with the presence of a trusted

execution environment is the possibility to take advantage of the keys stored in this environment. By using

previous work from the TRESCCA project, the hypervisor and the virtual machine can access the trusted

execution environment and thus use these keys to further protect the data and its access. For example, not

only the virtual machine image might be encrypted, but also the specific access to the data might be bound to

the private key of the device.



Figure 14: The inside if a Secure Container and access to it on an external device

With the combination of virtualisation extensions for ARM platforms, this Secure Container process can be

applied on many tablet devices, smartphones, set top boxes and – of course – on traditional x86 PCs and

servers.

4.3 Data Access

Once the Secure Container has been transferred to the external device, the user owning the device must be

able to access the data. There are multiple options how this data access and the data storage can be realised.

These options are described in the following subsections.

4.3.1 Clear Data

In the simplest case, clear data is stored in the Secure Container. The tiny operating system contains a small

web server that is able to provide an interface to the data, while the data is stored in clear form directly in the

Secure Container. The external user can access the data at any time and without any limitations, for example,

he does not need to establish a web connection.

The security functions of the Secure Container ensure that access to the clear data is only provided through the

defined interface. However, if the data can be accessed, it is always possible to make copies or save some parts

of it, for example by making screen shots. This is something that cannot be prevented in any case. However, in

this very simple use case, where the data is stored in the Secure Container, updates to the original data in the

cloud are not synchronized to the data stored in the Secure Container.



Figure 15: Access of clear data encapsulated in a Secure Container and provided by a minimal web server

Looking back at the use cases described in Section 3.2, the storage of data in the Secure Container is possible

for patient records. The external specialist should only view and interpret the data, but not change it.

4.3.2 Minimal CLARUS Proxy

If there are complex calculations required to access the data or if changes to the data should be synchronized

directly with the original data stored in the cloud, another option of storing the data should be used.

Here, a minimal CLARUS proxy is located and operated inside of the Secure Container. This proxy only contains

the modules needed to decrypt and access and if desired also to modify the data that was released to this

external user. Instead of storing the data in the Secure Container, the data access is realised analogously to the

“real” CLARUS proxy. The data remains stored at the CSP and the minimal and preconfigured CLARUS proxy

only has information to access the cloud data.

The advantages with this option are:

Original data is accessed and modified, if allowed. Synchronization of the data occurs by accessing the

same data as the person who created it.

Complex calculations are outsourced to the cloud, just like in the normal CLARUS proxy.

The disadvantages of this solution are:

This option might need more hardware resources than the storage of clear data. The minimal CLARUS

proxy must be operated in addition to the interface providing the data to the user. This solution might

not be feasible on smartphones or similar, very small and limited devices.



Figure 16: Accessing data through a minimal CLARUS proxy.

4.3.3 Referenced Data

If the data that should be accessed is protected by anonymization or splitting, access to the data does not

require a minimal CLARUS proxy. Instead, only the references needed to access the data and some metadata

must be available in the Secure Container.

Using this option, the advantages of the minimal CLARUS proxy remain: synchronization of the data is achieved

by accessing the original data and calculations are also performed on the cloud side. In addition to these

advantages, the Secure Container does not need to operate a minimal CLARUS proxy. Only access information

to the data is needed. Therefore, a very small and lightweight service can be implemented in the Secure

Container. This also allows the usage of this option for small and limited devices.



Figure 17: Access to split or anonymized data. The Secure Container does not need to include a CLARUS

proxy, it is enough to provide a table with the locations of the data and optionally additional metadata.

4.4 Migrating Across Servers with Different Architectures

As already stated, a challenge is to migrate the virtual machine containing the Secure Container to remote

devices, some of them having different hardware architectures. The solution is to apply a combination of

QEMU emulation and the available hardware features.

Since not every host platform can benefit from hardware assisted virtualisation, QEMU is also capable of

running guests in pure emulation mode, meaning that the guest code is firstly translated to an intermediate

language to be then translated to the host architecture assembly code, even if the guest and host share the

same architecture. This is the concept of the QEMU tiny code generator (TCG). Even if slower than KVM, TCG is

currently used and maintained because it enables the execution of virtual machines compiled for an

architecture different than the host one (for example it allows to run an ARM Android image on x86).

Generally, QEMU supports both live and offline migration. When used with QEMU/KVM, its migration depends

on the type of processor used to run the guests. When migrating machines from KVM enabled guests to QEMU

instances that can't support KVM (like when an ARM virtual machine is migrated from an ARM host to a x86

host), some incompatibility issues have to be solved since QEMU does not describe the two processors inner

state in the same manner, and the migration of virtual machines is nothing but a migration of saved states of

all the guest components (devices, CPU, memory, ...). In addition to that, both the outgoing and the destination

QEMU instances need to be of the same version, otherwise differences in the platform model emulation could

lead to a migration failure.

KVM achieves better performance, but since the guest instructions are directly executed on the host's

processor, it requires the host and guest CPU architectures to be homogeneous. On the other hand, the latter



completely emulates in software the target CPU, thus translating the guest into host instructions. This

introduces certain overhead, but enables VMs to be executed on different architectures. Except for

performance, these two solutions should be functionally equivalent. However, they are currently some

differences that prevent migration from KVM and TCG using the mainline QEMU. To combine the performance

and the flexibility of both solutions, a patch was created during the TRESCCA project for KVM to TCG hybrid

migration for ARM VMs. It enables the guests to achieve best performance while running on ARM platforms,

and additionally gives the possibility to migrate ARM virtual machines to cloud systems using different

architectures. All architectures able to run the QEMU emulator (i.e. x86, s390, MIPS, etc.) are thus possible

targets for migration.

By exploiting these results, it is possible to create a Secure Container virtual machine and migrate it across the

servers operating the CLARUS proxy (mostly x86 servers, located at the CLARUS proxy owner) and external

devices (mostly ARM architecture).



5 Conclusion

This document described the challenges of the Security as a Service for CLARUS and it showed the differences

to currently existing SECaaS concepts. Since CLARUS takes cloud computing a step further, these traditional

SECaaS concepts cannot be applied anymore.

Several services were described that are needed in the CLARUS context to establish the secure communication

between end users, CLARUS proxies and CSPs. The details of these services will follow in D4.2, while this

document focused on the possibility of providing CLARUS access to external end users without a dedicated

CLARUS proxy.

This security service has been motivated with the health use case, trying to securely send patient records to an

external specialist outside the trusted zone. The provided techniques allow this process and also take care of

securing the provided data or the access information to this data respectively.

For this, the concept of Secure Containers was introduced that makes use of existing and publically available

basic technologies such as virtualization, migration and trusted execution environment. Secure Containers

encapsulate a virtual machine and contain all necessary information to access the data or – according to the

use case – the data itself. A special focus was placed on the possibility of migrating this Secure Container to

external devices. These devices might also have different hardware architectures, the provided solution can

cope with these differences.

This aspect of the Security as a Service approach for CLARUS enhances the possibilities of CLARUS and allows

for new use cases and options, while it also preserves the CLARUS core abilities.



6 Bibliography

[1] P. Barham, B. Dragovic, K. Fraser, S. Hand and T. Harris, “Xen and the Art of Virtualization,” SIGOPS Oper.

Syst. Rev., vol. ACM, 2003.

[2] A. Karasik and V. Maximov, “Improving the efficiency of virtualization environment for the organization of

automated knowledge control and e-learning,” Education and Science without Borders, vol. 2, 2013.

[3] C. Dall and J. Nieh, “KVM/ARM: The Design and Implementation of the Linux ARM Hypervisor,” ACM ASPLOS

14, 2014.

[4] B. Katzmarski and A. Rigo, “TRESCCA - Deliverable D3.3 - Initial prototypes of Emulation and VM

Serialization,” 2014. [Online]. Available: http://www.trescca.eu/downloads/D3.3_public.pdf.

A framework for user centred privacy and security in the cloud · 2.2.2 Continuous monitoring and...

Documents

Transcript of A framework for user centred privacy and security in the cloud · 2.2.2 Continuous monitoring and...