Summary: Support for Write Privileges on Outsourced Data

This is a summary of the paper “Support for Write Privileges on Outsourced Data” by di Vimercati et al. (IFIP 2012). All the information is based on my understanding of the paper and may contain inaccuracies.

Overview

Considering the scenario of data outsourcing and its rapid diffusion in the era of cloud computing, the authors identify the need to differentiate read-only and read-write access to resources. They propose a solution to enforce write access control over files using cryptography.

This solution build on previous work that considered read access control whose key management was based on the token-based key derivation approach. Each resource (e.g., a file) in the system is encrypted using a different key that should be shared by the users who have access to the resource. However, that implies that each user has to manage a large number of keys (one for each resource they can access).

To overcome this problem, the token-based key derivation approach associates a label to each key, and defines tokens that can be used to derive one key from another. For example, to derive key k_j from key k_i, use user can use the token T_{i,j}=k_j \oplus h(k_i,l_j) (where h is a deterministic cryptographic function, and l_j is the label of the key k_j). This approach reduces the number of keys for each user to only one, but creates an overhead to store the tokens for derivation.

The write access control is enforced by associating a write tag to each resource, and the server only allows updates if a valid write tag is presented. Each write tag is encrypted using a key shared with the server and with users who have write access to the resource, and that key can also make be obtained using token-based key derivation. Even considering an untrusted server (honest-but-curious), the server cannot access the resource directly, since the encryption keys for the resource itself and for its write tag are different. In this solution, for each resource, the following data is uploaded to the server:

  • Encrypted resource (ciphertext)
  • Label of the key used to encrypt the resource (shared by readers)
  • Encrypted write tag
  • Label of the key used to encrypt the write tag (shared by writers)

Finally, this work proposes another extension to allow integrity control of the data, allowing data owners to verify if the data has been tampered with. The integrity verification is implemented using HMAC functions, since they are about three orders of magnitude faster than signature-based approaches. Therefore, three other fields are uploaded to the server for each encrypted resource: user tag, group tag, and timestamp of the operation. The user tag is a HMAC function whose input is the resource, the previous write tag, the user’s key and the timestamp.

Only users allowed to write can generate a valid user tag, and this can be verified by the data owner who generated all the keys in the system. The group tag is generated by a HMAC function whose input is the resource, the time stamp and the writers’ key.  It is used to extend such verification to the other writers. The timestamp prevents attacks utilizing old but valid keys.

Contributions

The authors focus on efficiency aspects, choosing to use symmetric encryption (HMAC functions) over asymmetric encryption (signatures) for integrity control, thus improving the overall performance.

The token-based key derivation helps with the key management, and it does not need a trusted authority for such a job.

Limitations

The disadvantages of the token-based key derivation approach are not discussed in depth, but it can incur an overhead in space due to the number of tokens and labels that should be made public.

The work does not present an experimental evaluation.

Final Notes

A presentation giving an overview of this work is available at SlideShare:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s