Summary: In this paper, the authors talk about using cryptography to provide access control for a distributed file system in such a way that decentralizes the notion of a reference monitor. When a file is created, a public/private asymmetric key pair and a symmetric key are associated with the file on the creating host. To perform a write, the file is encrypted with the symmetric key, hashed and signed with the private (aka. 'write') key. To verify the authenticity of a write, the signature can be checked. To read, the file is downloaded, the signature is checked with the public (aka. 'read') key and decrypted with the symmetric key. This system allows file creators to control who has read or write access to a given file by choosing who to give keys that act as capabilities controlling access to the file. Additionally, the file server need only have the 'read' portion of the asymmetric key pair so that it can validate the signatures of file writes before committing changes to stable storage. The 'read' asymmetric key does *not* give the server access to read the contents of files, however. This prevents the compromise of a server from also compromising the contents of all of the files stored on the server. CNFS, an implementation of the protocol based on NFS, is discussed and analyzed as well. ------------------------------------------------------------------------------- Pros: + Flexible design, works with current infrastructure + Minimalizes server trust + Data stored encrypted + No encryption needed before transmission of information Cons: - Poorly written paper, very repetitive - Revoking some user's access to a file would involve revoking keys from everyone and then reissuing. - Users giving away keys to unauthorized people is impossible to track - can be done anonymously - system has no way to enforce a "copy" right - Key generation overhead on file creation is high, would really hurt mobile devices - If a client system dies, it loses those keys (and thus files) forever - System works for read and write rights, but no other rights (e.g.. execute) - No quota management - Public/private key conventions are all broken - There exists a man in the middle key change attack that can DoS file creators - Anecdotal argument from Apu about the authors' non-scalability argument of current file systems: "I've seem some fairly huge systems in my time and they all seem to scale" ------------------------------------------------------------------------------- Votes: Strong Accept: 0 Accept: 0 Reject: 12 Strong Reject: 2