Our work is an extension of the protocol presented in [132] where the authors introduced the principles of “domain-based storage protection” (DBSP) in a public IaaS cloud. DBSP is based on a set of protocols that allow an IaaS client to shift the responsibility for data confidentiality and integrity to an external TTP – away from the IaaS provider. This approach relies on two
protocols: initial data write operation and subsequent data read and write operations. The core idea of this approach is to store information necessary to derive the decryption key for a given data volume in a header appended to the volume itself. The decryption key can only be derived by the TTP using the information stored at write time in the volume header and TTP’s own secret key. Besides withdrawing data protection responsibility from the IaaS provider, this enables a fluid migration of the IaaS client’s encrypted data assets to a different IaaS provider, while maintaining trust in the same TTP. In addition, the approach in [132] allows to precede the release of the decryption key with a remote attestation of the platform done by the same TTP. Remote attestation would: (i) ensure that the execution platform is in a certain trusted state and (ii) allow the TTP to seal the decryption key to the trusted configuration of the host to prevent its misuse in the form of migration to other platforms or usage in a different platform configuration.
Having briefly covered the background, we proceed with a high-level overview of our protocol.
A domain manager di launches n VM instances and a set of domains Di ={
Domi1, . . . ,Domin} that the VM instances can access to read and write data. To this end, di authenticates to the CP and requests to generate a domain Domik. The request also describes the VM instances belonging to the set VMi that should have access to the specified domain and the respective access rights. The CP is responsible for creating Domik and allocating the corresponding disk space. During this process, the SC (part of the CP) contacts TTP, to generate a symmetric key (KDomik2) that will be used to encrypt data in Domik. Following the successful creation of Domik, a domain manager must prove the right of a certain VM instance to access Domik.
In the following protocol, the participants exchange a number of messages. In order to ensure the integrity of the communication, we assume that each message is signed by the sender and the receiver can easily verify it.
5.1 Domain Sharing
One of the challenges of cloud computing is to enable users to securely administer data in a shared environment. Despite the fact that the protocol in [132] achieves protection of data in the cloud, it is considered a rudimentary work since it lacks sharing functionality. In the following paragraphs, we bridge this gap by presenting an extension of the protocol introduced in [132], which can be added to a typical CP to allow a domain manager to share a storage domain with other VM instances in the IaaS cloud.
Domain Registration Assume that a domain manager diwishes to create a domain Domik. As a first step, di defines the parameters needed to create the domain (e.g volume, size, name, etc.) and a description of the type of data stored in Domik. This description constitutes the metadata (metaik) of Domikand will be used for domain discovery and data search. Upon receiving a domain creation request, the CP generates an XML document (Listing C.1), allocates the corresponding disk space (by e.g. creating a logical volume) and adds metaik to the header of the allocated volume. It also adds the domain credential that will later used by the TTP to the header of the allocated volume.
2All data in a single domain is protected with the same storage protection master key, the domain key. This key is generated by the TTP and cannot ever leave TTP′s logical perimeter.
1 <DomainCredentialscope=”create”>
2 <CredentialID>cred:id</CredentialID>
3 <Timestamp>issue:time</Timestamp>
4 <DomainDescription>
5 <DomainIDEncoding=”xmlenc:rsa”>Domik</DomainID>
6 <DomainNamelang=”EN”>dom:name</DomainName>
7 <DomainManagerEncoding=”xmlenc:rsa”>
8 ETTP (di)
9 </DomainManager>
10 <DomainVolumeEncoding=”xmlenc:rsa”>
11 Edi (volume : id)
12 </DomainVolume>
13 <DomainSize>Edi (disk : size)</DomainSize>
14 <Metadata>metai
k</Metadata>
15 </DomainDescription>
16 </DomainCredential>
Listing C.1: Credential specification for the creation of a new domain.
Once a domain has been created, di can grant access permissions to multiple VM instances.
We analyse the problem of sharing a domain in the following two use cases:
A. Grant access to Domikfor a VM instance in the set VMi: Assume diintends to grant access to Domikfor a VM instance vmil, which is part of the set VMi. To do this, direquests the launch of a new virtual machine vmiland defines the access domain(s) and respective permissions for vmil. More precisely, di generates and sends to the CP an XML document as shown in Listing C.2 where each encrypted element (i.e xmlenc:rsa) is protected with pkTTPand thus TTP is the only one who can decrypt it. Prior to launching the VM instance with the requested domain(s) attached, SC checks that element DomainDescription matches the one stored in the header of the domain Domik. If it does, SC updates the XML structure of Listing C.1 by adding the element VirtualMachine contained in the VM instance launch request.
Once vmil is launched, di generates a credential as shown in Listing C.3 that will be used later to prove that di has granted access permissions for Domik to vmil.
B. Grant access to Domikfor a VM instance in the set VMj: Assume di intends to grant access to Domikto a VM instance vmjl, which is part of the set VMj (operated by domain manager dj).
As we have mentioned earlier, a VM instance must receive a credential from the corresponding domain manager in order to access files in a specific domain. In this case though, the manager of Domikis not the owner of vmjl, so in order to grant access to vmjl, djrequests a valid credential from di. Upon reception – if di accepts to give access to vmjl – it generates a credential as described in Listing C.2 and sends it to the CP. Domain manager di also generates a random nonce rj and sends Edj(rj) todj as well as ESC(rj) to theCP. Upon reception, dj decrypts it with skdj, and sends it to CP which validates that D (ESC(rj)) =D(
Edj(rj))
. Then, SC adds the corresponding VM to the credential of Domik as described in the previous case. More exactly, SC will add a nonce, the VMID and the access permissions (presented in Listing C.4) to the credential of Domik(XML document in Listing C.1).
5.2 Domain Access
Next, we describe the domain confidentiality protection mechanism and present the protocol to retrieve encryption keys and provide access to plain text data for authorized VM instances.
1 <DomainCredentialscope=”addVM”>
2 <CredentialID>cred:id</CredentialID>
3 <Timestamp>issue:time</Timestamp>
4 <DomainDescription>
5 <DomainID>Domik</DomainID>
6 <DomainNamelang=”EN”>dom:name</DomainName>
7 <DomainManager>manager:id</DomainManager>
8 </DomainDescription>
9 <VirtualMachinemanager=”di”>
10 <VMIDEncoding=”xmlenc:rsa”>ETTP(
vmil
)</VMID>
11 <NonceEncoding=”xmlenc:rsa”>ETTP (r)</Nonce>
12 <permissionsEncoding=”xmlenc:rsa”>
13 <permission>r</permission>
14 <permission>w</permission>
15 </permissions>
16 </VirtualMachine>
17 </DomainCredential>
Listing C.2: Credential Specification for the addition of a VM to a domain.
We assume that vmil requires access to the data in Domik. To grant access, SC must retrieve from TTP the symmetric key (Kik) used to confidentiality protect data in Domik. The domain manager operating vmil sends a request to CP in order to mount Domikto the virtual machine instance; the call is forwarded to and processed by SC. In the request, di sends the previously generated credential (Listing C.3) and proves that vmil has access to Domik. SC extracts from the header of the domain Domika data structure (Listing C.1) that contains information about the domain and sends it to TTP along with the unique identifier of vmil.
As a first case, we assume that no data has been stored in Domikyet, which implies that Kikhas not been generated yet. When TTP receives the message from SC, it first decrypts ETTP
(vmil) from the XML document presented in Listing C.3 and locats the ID of the VM instance contained in the credential. Next, TTP checks if the corresponding block (i.e where VMID element is equal with vmil) exists in the credential of the domain. If it does, TTP decrypts the metadata and checks that values match in both XML files. It then finds the permissions of vmil for Domik by decrypting permissions from the domain credential.
Once TTP has validated that vmil is authorized to access Domik, it performs a remote attestation of the compute host where vmiwill be launched (for simplicity, we assume that this is is also the source of the key request). The remote attestation involves obtaining a quote of the compute host’s TPM platform configuration registers to evaluate whether the platform can be trusted.
We leave out the minutiae of remote attestation and evaluation of platform trust level and refer the reader to [131].
In the event of a positive result of the TPM remote attestation, TTP generates a symmetric key (Kik) that encrypts data in the domain. To create the key, TTP generates a random nonce rkand evaluates the following:
Kik=PRF(
metaik∥rk,KTTP
),
where metaik∥rkis respectively the concatenation of metadata and the random generated nonce, and KTTP is a master key that does not leave the security perimeter of TTP. After generating the symmetric key for Domik, TTP seals it to the trusted configuration of the compute host (similar to the key sealing procedures already described in [131, 132]) and returns to SC the response shown in Listing C.5.
1 <DomainCredentialscope=”accessDomain”>
2 <CredentialID>cred:id</CredentialID>
3 <Timestamp>issue:time</Timestamp>
4 <DomainDescription>
5 <DomainIDEncoding=”xmlenc:rsa”>dom:id</DomainID>
6 <DomainNamelang=”EN”>dom:name</DomainName>
7 <DomainManager>manager:id</DomainManager>
8 <MetadataEncoding=”xmlenc:rsa”>ETTP(
metai k
)
</Metadata>
9 </DomainDescription>
10 <VirtualMachinemanager=”di”>
11 <VMIDEncoding=”xmlenc:rsa”>ETTP(
vmil
)
</VMID>
12 <NonceEncoding=”xmlenc:rsa”>ETTP (r)</Nonce>
13 </VirtualMachine>
14 </DomainCredential>
Listing C.3: Credential for presentation of granted permissions for a domain.
Upon receiving the message, SC first decrypts ESC
(vmil)
and checks if the request was sent from the VM instance contained in the response. If it was, SC calls the local TPM to unseal the key which – if the compute host remained in the earlier trusted state – reveals Kik. SC then uses it as input to the disk encryption subsystem on the compute host where vmil is running.
The disk encryption subsystem seamlessly decrypts the mounted volume hosting Domik. Next, the volume containing Domikis mounted as a disk device on vmil– with read-write or read-only rights, depending on the permissions granted by the domain owner.
The case where Kik has already been generated is similar, with the only difference that to recalculate Kik, TTP will have to decrypt ETTP(rk) contained in the updated metadata and use it as an input to the pseudorandom function.
5.3 Revocation
There are cases when credentials of a VM may need to be revoked if a VM instance misbehaved, lost access rights to a domain, or permissions have been changed. In this section we describe the mechanism to change or revoke the permissions of a VM instance for a specific domain.
Following our previous scenario, we assume that diwants to change the access rights of vmil for the domain Domik. We analyse the following two scenarios for di:
A. Prevent vmilfrom accessing Domik: Assume diwants to completely remove vmilfrom the list of VMs that are authorized to access Domik. First, di generates the XML file shown in Listing C.6 and sends it to CP, which forwards the request to the SC on one of the host platforms. Upon reception, SC extracts the credential for Domik from the header of the volume and sends it to TTP along with the XML received from di. TTP decrypts ETTP
(vmil)
and finds the ID of the VM that should remove its access rights. Then, TTP finds the corresponding block in the XML that contains all the VM instances that have access to Domik and removes it. Finally, TTP returns to SC an updated XML document which does not contain vmil and SC updates the header of Domikwith the fresh credential.
B. Change permissions of vmil on Domik: In this case we assume that diintends to just change the permission for vmil ‘read-write’ to ‘read’. The procedure that is followed is identical to the one in scenario A. di generates a new credential for vmil (Listing C.7) and sends it to TTP via CP. Additionally, SC sends to TTP the credential of the domain that is stored in the header of the volume. TTP follows the same steps in order to update the credential of Domik. Following
1 <VirtualMachinemanager=”di”>
2 <VMIDEncoding=”xmlenc:rsa”>ETTP(
vmj l
)</VMID>
3 <NonceEncoding=”xmlenc:rsa”>ETTP(
r′
)
</Nonce>
4 <permissionsEncoding=”xmlenc:rsa”>
5 <permission>r</permission>
6 </permissions>
7 </VirtualMachine>
Listing C.4: Credential Specification for the addition of a VM to a domain.
the successful update of the domain credential, SC sends the fresh credential to diwho can use it in the future in order to prove that vmil is authorized to access the corresponding domain under certain permissions.
In both cases A and B, di has the option to receive from the TTP a confirmation that the permissions for vmil have indeed been withdrawn or modified. To do this, prior to the request di generates a random nonce rrev, encrypts it with TTP and sends it along with the credential of vmil. Upon reception TTP – apart from altering the permissions of the corresponding VM – decrypts ETTP(rrev) and returns todi H(rrev||vmil))3. Given that by definition the TTP will not deviate from the protocol, the returned hash is an implicit confirmation of the fact that TTP has received the update request and has modified the credential accordingly.