One of the differentiating features of Celeste over other similar kinds of object stores is the ability to delete a file even if some components of the system are offline at the time of deletion. The deletion algorithm is separate from any systemic access-control mechanism and relies on a secret kept until the file is to be deleted. Once the secret is exposed, Celeste (actually the Beehive platform) uses that exposed secret to generate information that allows objects that comprise a file to be converted into their anti-object form, and thereby delete the original contents of the file.
A complete description of this algorithm is in the paper
Deleting Files in the Celeste Peer-to-Peer Storage System
By: Gal Baldishi, Germano Caronni, Idit Keidar, Raphael Rom and Glenn Scott
Appears in 25th IEEE Symposium on Reliable Distributed Systems (SRDS'06) pp. 29-38
Sun Microsystems Laboratories Technical Report Number: TR-2007-160
Because knowledge of the secret allows the deletion of objects without going through some other system-wide access control mechanism, exposing the secret to a malicious node would allow that node to delete objects. A malicious node could obviate the system-wide access control mechanism and simply inject the anti-object form of the objects it wishes to delete.
The choice of a secret is important. It's like a password.
Deletion Tokens and Deletion Token Identifiers
Like all identifiable elements in the Celeste/Beehive system, the secret is converted into a 256-bit object-id. This object-id is called the delete-token and is never exposed to any Celeste/Beehive node until deletion is performed. All manipulation of the secret and generation of the delete-token object-id is performed on the client.
When a file is created, the client supplies the object-id of the delete-token (this is a second generation object-id: an object-id of an object-id) called the delete-token-id and this object-id is stored in the meta-data of each object associated with the file. A subsequent exposure of the original delete-token can be verified by any node by simply checking that the object-id of the exposed delete-token is equal to the delete-token-id stored with the object.
Currently the delete-token-id is used as part of the computation of the object-ids of the objects that store the individual bytes of files. This means that if two different files are created which have the same data and the same delete-token (and consequently the same delete-token-id) they will share the data objects that make up the files. This is likely to be convenient in some cases, but carelessness could leave identical files vulnerable to unintended deletion.
Sign up or Log in to add a comment or watch this page.