1. Group Management, Permissions, and Revocation in OceanStore Barbara Engelhardt George Porter Naveen Sastry UC Berkeley January 2002

2. OceanStore’s world view Promiscuous caching, untrusted infrastructure, world-wide scale

3. OceanStore’s world view No one server can be trusted to provide access control Data location may not be fully known—it may not be possible to “hunt and kill” all data files Unlike traditional operating systems, OceanStore has no trusted kernel Result: OceanStore has different needs in access control than traditional operating systems and “trusted” distributed filesystems

4. The need for groups Administrative need: commercial setting has 10K+ users and huge number of files People constantly entering and leaving groups Any solution likely to be fully distributed Want: Centralized revocation and control Aggressive caching and FS’s untrusted nature Groups must be convenient for both readers/writers and group managers

5. Problem We cannot assume security of any particular nodes Controlling writes can be done in inner ring Controlling reads more difficult Cannot trust servers to selectively release information Solution for Ocean Store: Use inner ring to verify write requests Use client-side crypto to prevent unauthorized reads Keep all needed keys with ACLs

6. Groups in OceanStore Similar to Kevin Fu’s cryptographic storage file system, keys are bundled with the files However, group lists are distributed through the network as regular files No group server—indirection is introduced to provide end users with the keys they need to read files

7. Protecting Files Blocks of each file are encrypted with symmetric keys (IDEA) Groups each have a keypair (the private key is encrypted to group members with their public keys) Symmetric keys encrypted with user or group’s public key and stored in ACL Group manager removes a user by generating new group keypair and reencrypting the private group key with each user’s public key When update is sent to file, any groups are checked for changes If changes exist, new symmetric key used for update

8. Performing a read File 1 Group G User1 User2 User3 ACL User1 User2 Group1 Group2 IDEA keys encrpyted with public keys Group’s private key encrypted with users’ public keys

9. Performing a read File 1 Group 2 User1 User2 User3 ACL User1 User2 Group1 Group2 Read block from file 1 Lookup user’s entry in ACL consulting group lists if needed

10. Performing a read File 1 Group 2 User1 User2 User3 ACL User1 User2 Group1 Group2 Read block from file 1 Lookup user's entry in ACL consulting group lists if needed Encrypted key

11. Deleting a user from a group File 1 Group 2 User1 User2 User3 ACL User1 User2 Group1 Group2 Group manager generates new group keypair This new private key is encrypted to each users’ public key Group manager

12. Submitting new update File 1 Group 2 User1 User2 User3 ACL User1 User2 Group1 Group2 Update Check to see if any groups changed

13. Submitting new update File 1 Group 2 User1 User2 User3 ACL User1 User2 Group1 Group2 Update Generate new IDEA key, encrypt to all users and groups

14. Advantages Decouple group management from key management Fully distributed Storing keys in this fashion is relatively straighforward

15. Experimental Testbed Simulated above mechanism on Java-based, block-oriented filesystem with OceanStore assumptions Verified against two workload models (E-mail model based on IMAP traces and “Congressional Record” model) Testbed designed with OceanStore assumptions

16. Integration with OceanStore Inner ring verifies write requests Encrypted keys stored in ACL (as separate file) Group lists exist as independent files Any mechanisms introduced that restrict locations of files would decrease opportunity for revoked data to reach end users Cooperation from servers to delete data on request and aid in “hunt and destroy”

17. Additional Considerations A weakness of our system is that group members can deny access to other members of the group Group managers can determine if new members can see data written before their membership May be unwieldy for very dynamic groups

18. Future work Design of user-interface (Tcl/Tk or WWW) Expiring keys after certain time period/active servers to operate on files, including deletions Support for policies where new signed updates could imply the deletion of older data (streaming media, for example)