2. Threat Model

We consider two, independent adversaries: the datastore adversary, and the revoked user adversary. These two adversaries do not collaborate.

 Remember Shannon’s Maxim and Kerckhoffs’ principle: You should assume that all adversaries know the design of your client application and have access to your source code. 

2.1 Datastore Adversary

The Datastore is an untrusted service hosted on a server and network controlled by an adversary. The adversary can view and record the content and metadata of all requests (set/get/delete) to the Datastore API. This allows the adversary to know who stored which key-value entry, when, and what the contents are.

An adversary can add new key-value entries or modify any current key-value entries in the datastore at any time. However, given a snapshot of the datastore at some time, t, an adversary cannot fully revert the datastore to it’s state at time t-1. Similarly, an attacker cannot rollback a file to a previously seen state on the datastore.

The Datastore will not launch any Denial of Service (DoS) attacks. However, assume that it implements a rate-limiting scheme which prevents a user from enumerating the key/value pairs in the Datastore.

2.2 Revoked User Adversary

Assume that each user records all of the requests that their client makes to Datastore and the corresponding responses.

A user who is granted access to a file is considered trusted and will only use the system through the Client API functions. However, after a user has their access to a shared file revoked, that user may become malicious, ignore your client implementation, and use the Datastore API directly.

Malicious users may try to perform operations on arbitrary files by utilizing the request/response information that they recorded before their access was revoked. All writes to Datastore made by a user in an attempt to modify file content or re-acquire access to file are malicious actions.