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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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”

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

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)