So, I never actually posted this and I figure someone out there may be interested... For my masters thesis, I designed (but never got a chance to implement) a decentralized (well, federated), privacy preserving, access control protocol. The purpose of this post is not to explain DRACL but to get you interested enough to download my thesis and take a quick look.
The primary contributions are:
First, an exploration of the privacy, security, usability, reliability, and performance trade offs involved in designing an such an access control protocol. We explore topics like,
- Account recovery versus security: no completely trusted third parties.
- Privacy versus efficiency: e.g., choosing to not update something reveals that it hasn't changed.
- Security versus efficiency: cached credentials, etc.
- Ease of integration: no new services, no server-side network requests, no account management, etc.
- Ease of use: groups, no surprises, etc.
Second, an interesting (not-yet-peer-reviewed-but-probably-mostly-correct-and-definitely-interesting) zero-knowledge (ish) set intersection protocol. We use this protocol to construct "keys" and "ACLs" such that the keys opaquely encode the set groups in which the user is a member and the ACLs opaquely encode the set of groups that have access to a particular piece of content. By opaquely, I mean that neither party learns anything about the sets that their keys encode (except what they learn through running the protocol, see below).
Given a key that intersects with an ACL, a user can prove that the key intersects:
- Without either party learning anything other than the cardinality of the intersection (the user/prover learns this).
- Without revealing any user/prover-identifying information to the website/challenger other than the fact that the user's key intersects with the ACL being proven against.
Furthermore, we can expire keys after a period of time (and even allow semi-trusted third parties to "renew" these keys without granting these parties access to the protected content).
There are quite a few interesting features/guarantees that are hard to sum up succinctly so I recommend you try skimming the thesis. It goes through a lot of trouble to try to explain DRACL in an approachable manner.
The primary downsides are:
- Complexity. We designed the system to be simple from a usability standpoint but, under the covers, the actual logic, protocol, and crypto is complex.
- Size limitations. No user in this system can feasibly have more than 1000 or so friends/groups of friends at a time.
- Expensive crypto. Not "expensive crypto" from a cryptographers standpoint but expensive crypto from a systems engineers standpoint. Authenticating can take multiple seconds of CPU time.