• No results found

This chapter will address the needs of a secure storage system that should be fulfilled in order for it be deemed secure. In thinking about the requirements at abstract level, it is also important to think about the use cases of the system. There are a number of applications for such a system such as an Emailing System, an extension for Dropboxl or a Music Storage Application. Assume that this system would run as a service, accepting requests from other applications. An emailing system could send a request to this system specifying the files to be backed-up to 83, the keywords to be attached and any additional security operations. The use of Dropbox as an on-line storage service has gained popularity, this system could be adapted to provide secure searchable encryption for a Dropbox service.

One could select the files to be uploaded then specify keywords and this system would perform all the encryption and other security operations before the files are pushed to the Dropbox service.

Another potential use could be to store music on-line where the keywords of the song could be the artist, album and genre.

3.1 Design Criteria

In order for a system to be secure it must satisfy a number of criteria namely V.Ker et al. [20] provide a survey of the common secure storage systems and created a list of Khat requirements are needed in order for a system to be secure. The following list is an adaptation of this list and will be used to guide the design developed in this research:

lhttp://www.dropbox.com/

University

of Cape

Town

• Ensure the Confidentiality of the data being stored

• :"laintain the Integrity of the data to ensure that it has not been tampered with.

• Ensure that File Sharing can be catered for.

• Allow for Key-Revocation when user rights need to be removed.

• Ensure that there is Searchability with in the encrypted data.

• Ensue that the system can recover from a Compromised Key-pair.

3.1.1 Confidentiality

The system needs to maintain Confidentiality of the data being store on the Public cloud.

This means that only authorized users should be allowed to read the contents of the file.

The system should not rely on the underlying storage to handle this as it is assumed that the underlying storage system is untrusted.

3.1.2 Integrity

The system should ensure that tampered or corrupted data is detectable. This includes unauthorized modifications to data by users with only read rights. The system should be able to detect when such events occur.

There also needs to be a method to ensure that the access rights and other file meta-data have not been tampered with. This is to be modified by the file owner ouly, no other user should be allowed to change user rights.

3.1.3 File Sharing

File sharing is an important aspect in any work or personal situation. It is important for this system to allow file owners to grant read rights and read/write rights to other users

III a secure way. Users with read permissions should have access to the "data encryption

University

of Cape

Town

keys" while users with write permissions should have some means of sign changes made to the data.

3.1.4 Key-Revocation

As file sharing is important so is the need to revoke user rights. If a user's rights are to be revoked it needs to be done in such a manner so that there is no way that a user can have further access to the confidential data. There are however two ways of revoking user keys, the one is to immediately revoke the key and the second is to revoke the key only when there is a change to the data. The logic behind this is that there is no loss of confidentiality to unaltered data, since the revoked user is not learning anything new.

3.1.5 Searchability

There have been advances in cryptography to allow for users to search through encrypted text as has been documented in Section 2.6. This can allow a storage system to receive a query, search for relevant matches and return the results without gaining any knowledge about the contents of the query or the results. This technique will allow users to safely store vast amounts of data on a public cloud and query for specific files \vithout losing any confidentiali ty.

3.1.6 Compromised Key-pair

Should a users key-pair be compromised, there needs to be mechanisms in place that will allmv for the system to recover from such a compromise. All files to \vhich this user had rights to need to be re-keyed and re-encrypted.

University

of Cape

Town

3.2 Assumptions and Constraints

It is assumed that the owner of the file trusts the users to which access rights are granted.

Trust in this context means that the user will not decrypt the data and distribute it. The user will not attempt to replicate the file under his/her name.

It is also assumed that no encryption or decryption is done within the cloud. the only processing that will occur in the compute cloud is forwarding requests to the storage cloud and the processing needed for to respond to search queries. All encryption is to be done on the client before being uploaded to a public cloud. By not having any encryption or decryption occurring in a VM instance within the cloud, such as an EC2 instance, there is no potential risk of the public cloud being able to access any of the information since they do have priviledged access[24]. The solution is constrained to the class of applications

\\" here this paradigm makes sense.

3.3 Assessment

These design requirements will be used to assess the design to ensure that it has fulfilled all the requirements. Chapter 6 will test and assess how effectively these requirements were fulfilled and their performance implications.

University

of Cape

Town

Chapter 4 System Design

The ann of this chapter is to explain how the system has been designed to fulfill the requirements set out in Chapter 3. The chapter starts by discussing the overall architecture of the system and how the Client and Server applications interact. The various operations performed by both the client and server are introduced. The data structures used by the

s~'stem are then introduced and explained, namely the the SecuTe File Object, Secure File Object Key Words and the Network Message. Vie then discuss the Authentication Protocol between the client and server. The file system operations are then discussed and formally presented. Next \ve discuss the searching functionality of the system which includes the generation of keywords and how the server performs the encrypted searches. Lastly the users of the system and their access rights are discussed.

4.1 System Architecture

The system comprises of two applications. A client application that runs on a user's com-puter, and a server application that runs on the compute cloud. The responsibility of the server application is to respond to client requests as shown in Figure 4.1.

The client handles all security processing so as to remove all trust from the cloud provider.

The client is responsible for encrypting the file that is to be stored, performing key man-agement, user access management and communicating \vith the application running in the compute cloud.

A user will log in to the client application by providing a password that accesses that user's key-store. Once logged in the user specifies the file which is to be saved onto the cloud along

University

of Cape

Town

with performing any other administration tasks as discussed later. The client application then authenticates itself with the server, as explained in Section 4.3, creates a message and sends it securely to the server application running on the compute cloud, as explained in Section 4.4. This server application checks the message header to determine the task that needs to be completed.

User

4.1.1

-Spec:fy Key Parr : -loa In I

-SP~ClfJ

I".pJl Ue I -Configure sra .

Client Side

Gec;erate Secure file Object i Stored 111 l'emory)

compute Cloud (EC21

Send SFO Keyword To Com put Cloud Via

rep

So ket

Figure 4.1: Overall system architecture