a trusted iaas environment with hardware security module

24
A TRUSTED IAAS ENVIRONMENT WITH HARDWARE SECURITY MODULE Abstract—With the proliferation of cloud computing, security concerns about confidentiality violations of user data by the privileged domain and system administrators have been growing. This paper proposes secure cloud architecture with a hardware security module, which isolates cloud user data from potentially malicious privileged domains or cloud administrators. Within a securely isolated execution environment, the hardware security module provides essential security functionality with only restricted interfaces exposed to vulnerable management systems or cloud administrators. Such restriction prevents cloud

Upload: nexgentechnology

Post on 08-Aug-2015

16 views

Category:

Education


3 download

TRANSCRIPT

Page 1: A Trusted IaaS Environment with Hardware Security Module

A TRUSTED IAAS ENVIRONMENT

WITH HARDWARE SECURITY MODULE

Abstract—With the proliferation of cloud computing, security concerns about

confidentiality violations of user data by the privileged domain and system

administrators have been growing. This paper proposes secure cloud architecture

with a hardware security module, which isolates cloud user data from potentially

malicious privileged domains or cloud administrators. Within a securely isolated

execution environment, the hardware security module provides essential security

functionality with only restricted interfaces exposed to vulnerable management

systems or cloud administrators. Such restriction prevents cloud administrators

from affecting the security of guest VMs. The proposed architecture not only

defends against wide attack vectors but also achieves a small TCB. This paper

discusses our hardware and software implementation of the proposed cloud

architecture, analyzes its security, and presents its performance results.

EXISTING SYSTEM:

Page 2: A Trusted IaaS Environment with Hardware Security Module

There have been many prior studies that aimed to enhance the security of cloud

architecture. Here, we discuss several studies focused on hardening virtualization

environments and enhancing the security of guest VMs, followed by enforcement

to launch VMs on a verified platform. Hardening virtualization components. To

enable virtualization, VMM and a privileged domain are essential components.

Hardening such components is a stepping stone toward the security of

virtualization. Bleikertz et al. protects VMM by a policy enforcement scheme

adopted in SELinux. Several studies focused on reducing TCB since a small TCB

implies that the system has a narrow attack surface. Murray et al. reconstructed

privileged domain components to reduce TCB. Since the security processes in the

privileged domain were moved to a separated domain and the domain was smaller

than the privileged domain, overall TCB was reduced. Gebhardt et al. exploited

Virtual Machine eXtension (VMX) for hardening VMM. By segregating code

blocks in VMM by hardware, the TCB of the overall system was reduced.

Enhancing the security of guest VMs. Since the concept of cloud-box execution

was introduced, several implementations have been proposed. To ensure an

execution environment protected from a compromised privileged domain and a

malicious administrator, an addition domain or a modified VMM was used.

However, to secure storage of guest VMs, a cloud user should encrypt VM images

or should deliver a master key for cryptographic operations. That such actions were

Page 3: A Trusted IaaS Environment with Hardware Security Module

burdens for cloud users was not considered in prior work. In contrast, the proposed

system deploys VMs with pre-made images in a cloud repository and delivers

cryptographic keys by a cloud system. Thus, cloud users are free from such

burdens. Adopting an additional domain provides flexibility to manage guest VMs,

such as for encrypting images and for virtual machine introspection (VMI).

PROPOSED SYSTEM:

In this paper makes the following contributions.

_ We propose a trusted cloud system providing restricted interfaces to cloud

administrators. By providing a hardware security module supporting special

storage which is inaccessible to cloud administrators, security-critical data in the

hardware are isolated. Such restriction prevents malicious cloud administrators

from a_ecting the security

of guest VMs.

_ The proposed system provides a secure connection scheme between a user and an

allocated VM. Is also enables a cloud user to verify the allocated VM as well as the

VMM where the allocated VM runs before the first connection. Moreover, the

connection between a cloud user and an allocated VM is secured by exchanging

keys.

Page 4: A Trusted IaaS Environment with Hardware Security Module

_ The proposed system provides a secure storage scheme. To protect VM guest

images from cloud administrators, the cloud system should isolate the

cryptographic environment as well as a cryptographic key and integrity data. Since

the cryptographic environment is not by privileged domains, VM images of guest

VMs are protected in the proposed system.

_ The proposed system provides a secure management scheme. Since a

management operation is triggered by a cloud user, and the result of the operation

is reported to the user, a cloud user knows the exact VM state. Therefore, cloud

administrators cannot change the VM state at their discretion.

_ The protocols in this paper are verified by an automatic protocol verification

tool. When a communication protocol is not designed correctly, a malicious entity

can compromise the protocol and take control of communication. We verified that

the protocols are correctly designed with an automatic verification tool.

Module 1

Cloud computing

Cloud computing refers to both the applications delivered as services over the

Internet and the hardware and systems software in the datacenters that provide

those services. There are four basic cloud delivery models, as outlined by NIST

(Badger et al., 2011), based on who provides the cloud services. The agencies may

Page 5: A Trusted IaaS Environment with Hardware Security Module

employ one model or a combination of different models for efficient and optimized

delivery of applications and business services. These four delivery models are: (i)

Private cloud in which cloud services are provided solely for an organization and

are managed by the organization or a third party. These services may exist off-site.

(ii) Public cloud in which cloud services are available to the public and owned by

an organization selling the cloud services, for example, Amazon cloud service. (iii)

Community cloud in which cloud services are shared by several organizations for

supporting a specific community that has shared concerns (e.g., mission, security

requirements, policy, and compliance considerations). These services may be

managed by the organizations or a third party and may exist offsite. A Special case

of Community cloud is The Government or G-Cloud. This type of cloud

computing is provided by one or more agencies (service provider role), for use by

all, or most, government agencies (user role). (iv) Hybrid cloud which is a

composition of different cloud computing infrastructure (public, private or

community). An example for hybrid cloud is the data stored in private cloud of a

travel agency that is manipulated by a program running in the public cloud.

Module 2

System Design

Page 6: A Trusted IaaS Environment with Hardware Security Module

We propose a new cloud architecture protecting the security of guest VMs against

potentially malicious cloud administrators by isolating security-critical processes.

This isolation is accomplished by providing restricted interfaces to a privileged

domain. This architectural isolation guarantees that: a) a secure connection exists

between a cloud user and an allocated VM, b) a secure cryptographic environment

exists for VM images as well as for cryptographic keys and integrity (hash) data,

and c) there is a secure management of guest VMs. The proposed cloud

architecture includes cloud nodes and a trusted 3rd party authority called device

authority (DA). DA verifies each cloud node and lets a cloud user know whether a

VM of the cloud user is running on a verified node. Each cloud node consists of a

VMM called Trusted VMM (TVMM) and of a hardware security. TVMM is a

security-enhanced VMM isolating several data for guest VMs from cloud

administrators. TVMM encrypts the guest VM images with cryptographic keys

delivered by TCM, and enables a secure connection between a cloud user and an

allocated VM. TVMM also validates a management operation triggered by a cloud

user. TCM is a hardware based security module supporting an isolated

environment, and performs several security processes, such as signing and

validation checking, within the isolated environment. TCM also provides special

storage for keys and data. The biggest difference from existing security hardware is

the privilege on the storage. A single root user (a cloud administrator in a cloud

Page 7: A Trusted IaaS Environment with Hardware Security Module

service context) has a root privilege on the storage of existing security hardware,

whereas a cloud user has a privilege only on their TCM data. Therefore, the data in

storage can neither be accessed nor deleted, even by a cloud administrator. In

particular, the proposed architecture provides the following capabilities.

_ Interface isolation: The proposed system provides restricted interfaces to a

privileged domain to isolate security-critical processes and data from the privileged

domain. It also provides security-critical interfaces only to a verified VMM.

_ Secure connection: The proposed system guarantees a secure connection between

a cloud user and an allocated VM.

_ Secure storage: The proposed system guarantees a protected cryptographic

environment for guest VM images.

_ Secure management: The proposed system delegates a VM management

privilege to a cloud user, and provides a way to check the completion of the

management request.

Module 3

Interface isolation

Page 8: A Trusted IaaS Environment with Hardware Security Module

The main goal of the propose architecture is to isolate security critical processes

and data from cloud administrators. Since the proposed architecture does not count

on privileged domains, security processes are performed in TCM and TVMM.

Therefore, the private data in TCM are accessed only by TCM itself and TVMM.

On the other hand, a privileged domain also needs to access TCM for system

managements. Accessing TCM from a privileged domain, however, jeopardizes

the security of guest VMs. To resolve this dilemma, the proposed system supports

dual interfaces which expose different interfaces, management and security-critical

interfaces, to a privileged domain and TVMM respectively. Management interface

is a set of interfaces for initiating VM creation, destruction, and attestation.

Therefore, the management interface is used by a privileged domain and includes

following functions which are unrelated to accessing private data of guest VMs.

Although the privileged domain initiates the management operations, any security-

sensitive operations are conducted within TCM, protecting the private data.

Measurement and reporting: TCM supports an attestation function including

system measurement and reporting as TPM does. TCM stores system measurement

values in special registers called platform configuration registers (PCRs) and

returns a quoted blob. Since the measurement values are the calculated hash values

of platform software stacks, an external entity is able to attest the platform where

TCM is equipped.

Page 9: A Trusted IaaS Environment with Hardware Security Module

_ Entrusted attestation: After the system boots, only measurement and reporting

and entrusted attestation functions are available to a privileged domain, but other

functions remain unavailable. They become available only after verifying system

states with the entrusted attestation performed via the management interface.

_ Managing VSC: TCM maintains a data structure called VM security context

(VSC), which contains securitycritical data for each VM. VSC has cryptographic

keys for disk encryption, and has the integrity data of VM images. Even though the

keys and integrity data are read and modified via a security-critical interface,

allocation and deallocation are accomplished via the management interface.

Security critical interface is accessible only from the verified TVMM to provide

security related functionality. To be specific, the following functions are provided.

_ Accessing cryptographic keys and integrity data: TCM creates cryptographic

keys for VM images and integrity data of the images, and stores them in VSC. The

keys and integrity data are accessible from TVMM, which is verified with the

entrusted attestation scheme before accessing the keys and integrity data.

_ Signing initial guest image hash: To guarantee that a cloud user connects to a

correct VM on the attested platform, the user should be able to check the initial

guest image hash. The guest image hash is signed by the AIK of TCM to prevent

forgery, and is verified by DA afterwards. This function is used for the secure

connection between users and TCM, as described in the following section.

Page 10: A Trusted IaaS Environment with Hardware Security Module

_ Management request validation: A cloud user sends a management operation to a

cloud node. When such an operation is not triggered by a valid cloud user, the VM

state of a cloud user could be changed arbitrarily. Thus, this function is used for

validating the owner of a guest VM as described in x3.4. In the proposed system

architecture, the system BIOS, bootloader, and VMM are also part of the TCB, in

addition to TCM. Although TCM itself is verified and cannot be changed in an

isolated environment, the other system software stack must be verified to guarantee

the trustworthiness of the entire cloud system. TCM grants VMM accesses to

security sensitive services only if the VMM is verified to be a known-correct

TVMM. Since the TVMM denies any access from a privileged

Module 4

Secure connection

To establish a secure connection between a cloud user and an allocated VM, there

are three equirements. First, a cloud user should attest the platform where the

allocated VM is running. Second, a cloud user should attest the allocated VM

images. Third, a cloud user should receive a VM server key (e.g., SSH server key

of the VM) and set a user key (e.g., user key of SSH server) securely in the

allocated VM. To meet these requirements, we define a secure connection protocol

Page 11: A Trusted IaaS Environment with Hardware Security Module

and summarize keys in the protocol. Since platform information and VM image

information includes ash values that a cloud user does not know, the cloud user

communicates to DA and DA translates such hash values into human recognizable

information according to the protocol. DA communicates to TCM with a session

key created by the entrusted verification protocol. During the entrusted verification

process, DA attests the platform meeting the first requirement. To meet the second

requirement, the proposed system stores the hashes of initial images during initial

deployment, and the hashes are verified by DA afterward to ensure the initial

integrity of VM images. In most cloud services, pre-made VM images are used to

launch a new VM. Even though they exist as unencrypted images in the cloud

repository, they are encrypted with a cryptographic key in VSC before the first

launch. During the encryption process, the initial integrity hash value is calculated

and stored in VSC. The hash value is delivered to DA in Step 9, and DA translates

the hash value to VM image information such as OS version and software stacks.

The VM image information is delivered to the cloud user in Step 10 and the cloud

user is able to check the allocated VM images. To meet the third requirement, a

VM server key and a user key are also exchanged securely with the proposed

protocol. For major cloud service vendors, cloud systems create user keys and

stores them in their server. Afterwards, an allocated VM downloads the user key

via HTTP. Accordingly, cloud administrators can access the stored user key.

Page 12: A Trusted IaaS Environment with Hardware Security Module

Contrary to such an approach, with the proposed protocol, a cloud user creates a

pair of cryptographic keys and delivers the public part of the key to the allocated

VM. The user key is denoted by UK. Since the user key is asymmetric, the private

part of the user key is and is never revealed. The VM server key denoted by VK is

created by the OS of the allocated VM and is delivered to the cloud user via the

protocol. Therefore, only the cloud user is able to connect to the allocated VM.

Once a VM server key and a user key are exchanged, the communication between

a cloud user and an allocated VM is secured by a public key protocol such as the

Needham- Schroeder-Lowe protocol.

CONCLUSION

Security is a primary consideration for cloud users. Even though security threats by

cloud administrators are feasible

and critical, cloud service providers are mainly concerned with security threats

from external attacks rather than internal attacks. This viewpoint hinders the

proliferation of cloud computing. In this paper was presented a cloud system

architecture consisting of TCM and TVMM to prevent cloud administrators from

a_ecting the security of guest VMs. As the architecture isolates the data of cloud

users from cloud administrators, the data of cloud users are protected even with a

Page 13: A Trusted IaaS Environment with Hardware Security Module

compromised privileged domain or malicious cloud administrators. The proposed

system provides security functionality against wide attack vectors and achieves a

small TCB. It also shows reasonable I/O performance, proving its feasibility.

REFERENCES

[1] D. G. Murray, G. Milos, and S. Hand, “Improving xen security through

disaggregation,” in Proceedings of the 4th ACM SIGPLAN/SIGOPS international

conference on Virtual Execution Environments (VEE), 2008, pp. 151–160.

[2] N. Santos, K. Gummadi, and R. Rodrigues, “Towards trusted cloud

computing,” in Proceedings of the 2009 conference on Hot topics in cloud

computing (HOTCLOUD), 2009.

[3] L. Chunxiao, A. Raghunathan, and N. Jha, “Secure virtual machine execution

under an untrusted management OS,” in Proceedings of IEEE 3rd International

Conference on Cloud Computing (CLOUD), 2010, pp. 172–179.

[4] S. Butt, H. A. Lagar-Cavilla, A. Srivastava, and V. Ganapathy, “Selfservice

cloud computing,” in Proceedings of the 2012 ACM conference on Computer and

Communications Security (CCS), 2012, pp. 253–264.

Page 14: A Trusted IaaS Environment with Hardware Security Module

[5] J. Kong, “Protecting the confidentiality of virtual machines against untrusted

host,” in 2010 International Symposium on Intelligence Information Processing

and Trusted Computing (IPTC), 2010, pp. 364–368.

[6] “TCG architecture overview, version 1.4,” http://www.trustedc

omputinggroup.org/resources/.

[7] B. D. Payne, M. D. de Carbone, and W. Lee, “Secure and flexible monitoring

of virtual machines,” in proceedings of the 23rd Annual Computer Security

Applications Conference (ACSAC), 2007, pp. 385– 397.

[8] Chunxiao Li, A. Raghunathan, and Niraj K. Jha, “A trusted virtual machine in

an untrusted management environment,” IEEE Transactions on Services

Computing, vol. 5, no. 4, pp. 472–483, 2012.

[9] Y. Xia, Y. Liu, H. Chen, and B. Zang, “Defending against VM rollback attack,”

in Proceedings of 42nd IEEE/IFIP International Conference on Dependable

Systems and Networks Workshops (DSN-W), 2012, pp. 1–5.

[10] “Amazon elastic compute cloud (EC2),” http://aws.amazon.com/ec2/.

[11] J. Choi, J. Park, J. Seol, and S. Maeng, “Isolated mini-domain for trusted

cloud computing,” in Proceedings of the 13th IEEE/ACM International

Symposium on Cluster, Cloud and Grid Computing (CCGrid), 2013, pp. 194–195.