Group Management, Permissions, and

Revocation in OceanStore

Barbara EngelhardtGeorge PorterNaveen Sastry

UC BerkeleyJanuary 2002

OceanStore:1Networking Day ©2001 John Kubiatowicz/UC Berkeley

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

ACLUser1

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

ACLUser1

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

ACLUser1

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

ACLUser1

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

ACLUser1

User2

Group1

Group2Updat

e

Check to see if any groups changed

Submitting new update

File 1

Group 2

User1

User2

User3

ACLUser1

User2

Group1

Group2Updat

e

•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 (E-mail

model based on IMAP traces and “Congressional Record” model)

Operation Blocks Read Blocks WrittenRead n blocks 1+G+n 0Write n blocks (no recent ACL or group deletion) 1+G+n 1+nWrite n blocks (recent ACL deletion) 1+G+n 2+nAppend n blocks (no recent ACL or group deletion) 1+G 1+nAppend n blocks (recent ACL or group deletion) 1+G 2+nGroup change 1 1ACL change 1 1

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)