Cobalt: Separating content distribution from

authorization in distributed file systems

Kaushik VeeraraghavanAndrew Myrick

Jason Flinn

University of Michigan

University of Michigan 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

University of Michigan 3

University of Michigan 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!

University of Michigan 5

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

University of Michigan 6

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

University of Michigan 7

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

University of Michigan 8

Cobalt goals

• Better usability

• Improved privacy

• Improved content protection

University of Michigan 9

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

University of Michigan 10

Store content in distributed storage

• Implemented on Blue File System– Ensemblue [Peek ‘06]

• Usable with other distributed storage

BlueFS Server

University of Michigan 11

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

University of Michigan 12

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

University of Michigan 13

Outline

• Motivation• Background• Implementation• Evaluation• Conclusion

University of Michigan 14

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

University of Michigan 15

Content Acquisition

Provider

BlueFS Server

Content Request

Policy

Policy

H{Policy}

• Phone delegated authorization responsibility

University of Michigan 16

File system layout

• Policy stored separately

Encrypted with content key

Encrypted with Phone’s KEK

University of Michigan 17

Restrict playback to trusted clients

• Verify media player before sharing content

Media Player 2Media Player 1

University of Michigan 18

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…

BlueFSIP address

University of Michigan 19

H{Policy}

Playback

• Authorization succeeds if phone is in proximity• Policy match ensures player won’t leak content

Song_1.mp3Song_2.mp3…

Media Player 1BlueFS Server

BlueFSIP address

Policy H{Policy}Policy

University of Michigan 20

Outline

• Motivation• Background• Implementation• Evaluation • Conclusion

University of Michigan 21

Evaluation goals

• Overhead of Cobalt for content acquisition

• Overhead of Cobalt for content playback

• Can Cobalt enable new applications?

University of Michigan 22

Evaluation setup

• Token: Motorola E680i cell phone• BlueFS server: Dell GX620 desktop

• Acquisition– Provider: IBM X40 laptop

• Playback– Ad hoc client: IBM X40 laptop

University of Michigan 23

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

Acquisition: 1.8 MB mp3

7.6

0.3

1.3

0.9Secure sessionestablished

Content encryptedby provider

Content fetchedand stored

Cobalt metadata(key, hash)updated

University of Michigan 24

Playback startup time

• One time cost: 12.4 seconds• Query creation, path resolution: 4sec (1500 mp3s)

Playback startup time (sec)

7.9

0.2

4.3

Secure sessionestablishment

Media playerselection and TPMverification

Path resolutionand playlistcreation

University of Michigan 25

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.mp3Song_3.mp3Song_4.mp3

Song_1.mp3Song_2.mp3Song_3.mp3

Adaptive Playlist

Song_2.mp3 Song_3.mp3

University of Michigan 26

Conclusion

• Cobalt: authorize people not clients– Better usability– Improved privacy– Improved content protection

• Reasonable overhead• Enables new applications

• Questions?