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:

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

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.

_ 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

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

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

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

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.

_ 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.

_ 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

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.

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

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.

[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.

A Trusted IaaS Environment with Hardware Security Module

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Viewers also liked

Viewers also liked (16)

Similar to A Trusted IaaS Environment with Hardware Security Module

Similar to A Trusted IaaS Environment with Hardware Security Module (20)

Recently uploaded

Recently uploaded (20)

A Trusted IaaS Environment with Hardware Security Module