Client Application
4.2 System Data-Structures
4.2.1 Secure File Object
The Secure File Object is the container that is used to store data securely on the cloud.
All security operations on this container are performed at the client, the server performs no modifications to this object. The structure of the secure file object is shown in Figure -1.2.
Each secure file object has a unique file encryption key. any symmetric encryption will suffice. The attributes of a secure file object are:
• File Name: The name of the object file.
• OwnerID : The ID of the owner/creator of the file.
• Last l\Iodified User ID : The ID of the user that last modified the data.
• Read List: List of users with ~'ead access rights, mapping UserID to [FEK]pu
• Public Key List :List of users Public keys and an is-writer flag.
University
of Cape
Town
Owners Encrypted OwnerlD last r"odlfied
Read List Public Key
[FEKjPcOwne [Encrypte,j
Publ,c rData]Fek Data Hashed SFO Hashed
User 10 Ust Keywords]
Key & & Signed
PuOSS Signed
of
t
UserlD: UserlD:
[FEKJPu Public Key
+ •
UserlD: UserlD [FEKJPu Pubhc Key,
IsWnter
Figure 4.2: The Structure of the Secure File Object
• Encrypted File Encryption Key: The File encryption key is encrypted with the owners Public key.
• Encrypted Keywords: An encrypted string of keywords. This field is merely used ad-ministration purposes since the searchable key\\'ord generation is a one-way function.
It is encrypted with the same Symmetric Key that is used by the owner to create encrypted keywords by the owner, thus only the owner has access to this string.
• Encrypted Data Digital Signature.
• Secure File Object Digital Signature.
As mentioned in Section 3.1, there are a number of requirements that Ileed to be satis-fied by this system in order to provide a secure means of storage.
Confidentiality
The secure file object provides Confdentiality by encrypting the data field with a File En-cryption Key. Only users with reaci( and write) permissions may read the contents of the
University
of Cape
Town
data field. The data field is encrypted using a Symmetric Encryption Algorithm, like DES.
The File Encryption Key is only generated by the File Owner upon Secure File Object creation and when user rights are revoked.
Integrity
Integrity is maintained in two ways, firstly the integrity of the data field needs to be checked and secondly the integrity of the secure file object as a whole needs to be checked.
Data integrity is maintained by hashing the encrypted data field then signing this hash with the users private key. The user then sets the" Last :vlodified UserID" to his own user ID. Subsequent users look up the Last Modified Users Public Key in Public Key List, decrypt the signature and check the integrity of the encrypted data.
Secure File Object integrity is maintained by hashing all the fields of the secure file object except for those that users may alter(Last Modified UserID, Encrypted Data and Encrypted Data Digital Signature) and then encrypting the hash with the owners private key. The resulting hash is as follows:
SFODigest
=
[F(FileName IOwnerID IReadList IPublicKeyList I [FEKjPuowner IPuOwner)jprowner",·here F is a hash function such as SHA or MD5. The hash is then signed with the owners Private Key.
\\"hen a user loads the SFO from the cloud, the user then uses the Public key of the owner to decrypt the Digest and chec'{ the hash.
File Sharing
Like any file system, there needs be a way of sharing files with other users of the system, for this reason the secure file object makes use of two lists. The Read List is a list of user
University
of Cape
Town
id's -+[FEK]puuser. Since the FEK is encrypted with the users Public key, that user can gain access the FEK by decrypting it with his Private Key.
The Public key list maps user id's -+(Public Key, Is \\Triter) and is needed for two rea-sons. firstly it is used to maintain a list of all user public keys to be used in key revocation as explained in Section 4.2.1 and the secondly it is used to maintain a list of which users have write access to the data with the is-writer flag.
\\Then a user downloads a SFO from the cloud, that user will use the "Last Modified C serID" to look up the public key of that user in this list and check whether that user does ill fact have write access to this file.
Key- Revocation
\Vith allowing access to users there need to be mechanisms in place for removing access to users. Revoking a users read access rights means that the owner needs to generate a new File Encryption Key (FEK) and re-encrypting the encrypted data field with a llew FEK.
Then the owner needs to remove the revoked user from the read list and the public key list.
The owner then iterates through the public key list encrypting the new FEK with each users Public Key. The user do llot need even know that a new FEK has been issued, since the whole process is transparent to them.
Revoking a users write access rights is to simply set the Is-\Vriter flag to false in the Public Key List. User revocation can only be performed by the owner. Once the changes have been made the SFO is signed again to maintain integrity. Since the SFO needs to be signed, only the owner can make these changes. This stops users from falsely assigning themselves write access or read access.
University
of Cape
Town
Malicious Users
The design of the system assumes that users can be trusted, i.e. if an owner grants access to a user, that user will not be malicious. However measures should be in place so the the system can detect any malicious activity.
If a user is granted read access, that user can modify the contents, generate a Encrypted Data Digest and set the Last Modified User ID field. However, when the next user loads this file, that user will do an integrity check. As mentioned an integrity check is done by looking up the Public Key of the Last Modified User; since this Is-'Writer flag is not set, the system will generate an error because an unauthorized user has modified the contents.
If a read user adds write permissions then this change will be detected by subsequent users since the malicious user is unable to generate a Secure File Object Digest. This will inform subsequent users that there has been an unauthorized change to the secure file ob-ject.
There is another problem with malicious users that is not easily fixed and a suitable solution is beyond the scope of this research. That is the problem of a user taking ownership away from the file owner.
Since all read users have access to all fields of the SFO, they can create a new SFO (thus becoming the file owner), copy the encrypted contents of the old SFO along with the read and public key list, name the new SFO to that of the old SFO, and delete the old version.
To the other readers the file will still look the same, however, the file has changed owners.
A solution to this problem is to implement a Public Key Infrastructure (PKI) that allows users to check whether a File ID maps to a given Owner Public Key. As this is outside the scope of this research, a more naive approach was taken. The file O\vner stores a local copy of the file list. This file list is then used to do a reconciliation with the files store on the Storage Service. Should there be a difference, then the owner knows that some malicious
University
of Cape
Town
activity has occurred.