trademark

3.0 Secure Data Storage and Transactions Logs (cont.)
3.5 Apply lazy revocation and key rotation
3.5.1 Why?
To improve scalability.
3.5.2 How?
• Use lazy revocation (i.e. delay re-encryption until a file is updated in order to make
revocation operation less expensive).
• To implement lazy revocation, generate a new filegroup for all the files that are modified
following a revocation and then move files to this new filegroup as files get re-encrypted.
This process raises two issues, as stated below:
Issue: There is an increase in the number of keys in the system following each
revocation.
Solution: Relate the keys of the filegroups that are involved.
Issue: Because file sets that are re-encrypted following successive revocations are
not really contained within each other, it becomes increasingly difficult to determine
which filegroup a file should be assigned to when it is re-encrypted.
Solution: Use key rotation. Set up the keys so that files are always (re)encrypted with
the keys of the latest filegroup. This ensures that users are required to remember only
the latest keys and derive previous ones when necessary.
3.6 Implement proof of retrievability (POR) or provable
data possession (PDP) methods with high probability
3.6.1 Why?
To enable a user to reliably verify that data uploaded to the cloud is actually available and
intact, without requiring expensive communication overhead
3.6.2 How?
Ateniese et al. [ABC+07] introduced a model for provable data possession (PDP) that allows a
user that has stored data at an untrusted server to verify that the server possesses the original
data without retrieving it. The model generates probabilistic proof of possession by sampling
random sets of blocks from the server, which drastically increases efficiency. The user
maintains a constant amount of metadata to verify the proof. The challenge/response protocol
transmits a small, constant amount of data, which minimizes network communication.
CLOUD SECURITY ALLIANCE Big Data Working Group Guidance
© Copyright 2016, Cloud Security Alliance. All rights reserved.
19