1. Cobalt: Separating content distribution from authorization in distributed file systems Kaushik Veeraraghavan Andrew Myrick Jason Flinn University of Michigan

2. 2 Accessing protected content is hard! Many opportunities to use ad hoc clients –Client I don’t own or regularly use –Play my songs at a friend’s party To access content from an ad hoc client, I –locate content –fetch content –DRM: do I trust the ad hoc client? Simplify access without sacrificing security

3. University of Michigan3

4. 4 What makes protected content special? User goal –Display content to friends and family –Pervasive – access content anytime, anywhere! Provider goal –Restrict access to paying users Users and content providers have opposing goals!

5. University of Michigan5 Problem with current systems Provider authorizes clients for playback Model breaks down for ad hoc clients –User: privacy loss, login credential abuse –Provider: revocation, impersonation Provider

6. University of Michigan6 What should we authorize instead? Provider should authorize people not clients Hard: how can we detect and authorize people? –Leverage small, personal mobile devices: cell, PDA Provider

7. University of Michigan7 Provider Cobalt: proximity-based access Physical proximity-based access: client on wireless network –We build on ideas introduced in ZIA [Corner ‘02] Challenge/response heartbeat ensures proximity When user departs, playback stops

8. University of Michigan8 Cobalt goals Better usability Improved privacy Improved content protection

9. University of Michigan9 Separate distribution from authorization User goal: pervasive access to content –Store content in distributed storage Provider goal: Restrict access to paying users –Encrypt content –Release key to phone –Playback requires phone Separate distribution & authorization channels

10. University of Michigan10 Store content in distributed storage Implemented on Blue File System –Ensemblue [Peek ‘06] Usable with other distributed storage BlueFS Server

11. University of Michigan11 Cobalt trust model What does the provider need to trust? –User’s cell phone and the ad hoc media player Rely on Trusted Computing to verify trust

12. University of Michigan12 Trusted Platform Module (TPM) Tamper resistant chip w/ crypto support Software attestation –Signed hash of loaded software –Verify against policy Sealed storage –Protects data –Detect tampering Entities can leverage TPM to verify client

13. University of Michigan13 Outline Motivation Background Implementation Evaluation Conclusion

14. University of Michigan14 Implementation Acquisition –Provider sends encrypted content to user –Phone approved as a proxy after verification Playback –Media player discovery –Provide access to selected content –Phone authorizes player after verification

15. University of Michigan15 Content Acquisition Provider BlueFS Server Content Request Policy H{Policy} Phone delegated authorization responsibility

16. University of Michigan16 File system layout Policy stored separately Encrypted with content key Encrypted with Phone’s KEK

17. University of Michigan17 Restrict playback to trusted clients Verify media player before sharing content Media Player 2 Media Player 1

18. University of Michigan18 Provide access to selected content Improve usability: semantically specify content Query result updated dynamically as content changes Phone restricts playback to specified content BlueFS Server Query: *.mp3 Song_1.mp3 Song_2.mp3 … Media Player 1 Song_1.mp3 Song_2.mp3 … BlueFS IP address

19. University of Michigan19 H{Policy} Playback Authorization succeeds if phone is in proximity Policy match ensures player won’t leak content Song_1.mp3 Song_2.mp3 … Media Player 1 BlueFS Server BlueFS IP address Policy H{Policy} Policy

20. University of Michigan20 Outline Motivation Background Implementation Evaluation Conclusion

21. University of Michigan21 Evaluation goals Overhead of Cobalt for content acquisition Overhead of Cobalt for content playback Can Cobalt enable new applications?

22. University of Michigan22 Evaluation setup Token: Motorola E680i cell phone BlueFS server: Dell GX620 desktop Acquisition –Provider: IBM X40 laptop Playback –Ad hoc client: IBM X40 laptop

23. University of Michigan23 Content acquisition time 10.1 seconds to acquire 1.8MB mp3 Cobalt adds less than 9 seconds of overhead –STS on cell phone: 7.56sec, laptop: 0.51sec

24. University of Michigan24 Playback startup time One time cost: 12.4 seconds Query creation, path resolution: 4sec (1500 mp3s)

25. University of Michigan25 Context-sensitive: adaptive playlist Cobalt enables new context-sensitive apps Playlist adapts as users leave player’s vicinity 1500 mp3s, 650 matches: adds 1 second Media Player Song_2.mp3 Song_3.mp3 Song_4.mp3 Song_1.mp3 Song_2.mp3 Song_3.mp3 Adaptive Playlist Song_2.mp3 Song_3.mp3

26. University of Michigan26 Conclusion Cobalt: authorize people not clients –Better usability –Improved privacy –Improved content protection Reasonable overhead Enables new applications Questions?