Digital Rights Management

1. Digital Rights Management the Good, the Bad and the Ugly Mark Stamp Department of Computer Science San Jose State University stamp@cs.sjsu.edu DRM resources at http://www.cs.sjsu.edu/faculty/stamp/DRM/ DRM 1

2. Who Am I? • 1992: PhD, Texas Tech • 1992-1993: WPI • 1993-2000: NSA • 2000-2002: MediaSnap, Inc. • 2002-Present: SJSU DRM 2

3. What was MediaSnap? • Silicon Valley startup company • Founded June 2000 • I joined in December 2000 • Maximum of 15 employees • Not a dot-com • Funded by In-Q-Tel (CIA VC fund) • Digital rights management (DRM) product DRM 3

4. Why MediaSnap? • NSA provided • Job security • “Tenure” after 1 year • Interesting work, good people, etc., etc. • Why leave NSA for startup company? • Three reasons… • Money • Money • Money (salary) (benefits) (worthless stock options) DRM 4

5. Outline of Talk • What is DRM? • Overview of MediaSnap DRM system • Overview of streaming media DRM model • MediaSnap’s competitors • TCG/NGSCB • Non-technical issues • Enterprise DRM • Conclusions DRM 5

6. DRM Overview DRM 6

7. What is DRM? • “Remote control” problem • Digital book example • Digital music, video, etc. • Enterprise document protection • Privacy-enhancing technology? DRM 7

8. Persistent Protection • Restrictions on use afterdelivery • For example • No copying • Limited number of reads/plays • Time limits: do not open until Christmas • No forwarding • Etc. DRM 8

9. What to Do? • The honor system? • Stephen King’s, The Plant • Give up? • Internet sales? HIPAA? SOA? etc. • If you can’t beat ‘em, join ‘em... • Lame software-based DRM? • The standard DRM system today • Better software-based DRM? • MediaSnap’s goal • Tamper-resistant hardware? • Closed systems: Game Cube, etc. • Open systems: TCG/NGSCB for PCs DRM 9

10. Is Crypto the Answer? • Attacker’s goal is to recover the key • In standard crypto scenario, attacker has • Ciphertext, some plaintext, side-channel info, etc. • In DRM scenario, attacker has • Everything in the box (if not more) • Crypto was not designed to solve DRM problem! DRM 10

11. Current State of DRM • At best, security by obscurity • A derogatory term in the security world • Secret designs • In violation of Kerckhoffs Principle • Crypto is king • “Whoever thinks his problem can be solved using cryptography, doesn’t understand his problem and doesn’t understand cryptography.” --- Attributed by Roger Needham and Butler Lampson to each other DRM 11

12. Rules to the DRM Game • The analog hole • When content is rendered, it can be captured in analog form • DRM cannot prevent attack via the analog hole • Human nature matters • Absolute DRM security is impossible • Want something that “works” in practice • What works depends on context • DRM lives in no man’s land • Somewhere between CS and MIS DRM 12

13. Software-based DRM • Strong software-based DRM is impossible • We can’t really hide a secret in software • To do so, we would have to prevent software reverse engineering (SRE) • User of system with full admin privilege can break anti-SRE protection • Bottom line: The killer attack on software-based DRM is software reverse engineering DRM 13

14. MediaSnap DRM DRM 14

15. MediaSnap DRM Overview • Server side • Secure Document Server (SDS) • Client side • PDF plugin (reader) DRM 15

16. Protecting a Document encrypt Sender persistent protection Recipient SDS DRM 16

17. Accessing a Document inTethered Mode Sender Request key key Recipient SDS DRM 17

18. Accessing a Document inUntethered Mode key Sender Recipient SDS DRM 18

19. Tethered vs Untethered • Tethered advantages • Server controls access • Document can be “shredded” (Authentica) • Key is less exposed • Untethered advantages • Can access data without network connection • Key is “more exposed” • MediaSnap implemented both modes DRM 19

20. Security Issues • Server side (SDS) • Protect keys, authentication data, etc. • Apply persistent protection • Client side (Reader/PDF plugin) • Protect keys, authenticate user, etc. • Enforce persistent protection • Remaining discussion concerns client DRM 20

21. Security Overview Tamper-resistance Obscurity DRM 21

22. Anti-debugger Tamper-Resistance Encrypted code DRM 22

23. Obscurity • Applied to • Key management • Authentication • Caching (keys, authentication, etc.) • Encryption and “scrambling” • Key parts (data and/or code) • Multiple keys/key parts • Obscurity can only slow down attacker --- the persistent attacker wins! DRM 23

24. Other MediaSnap Features • Code tamper checking (hashing) • Must know what code is executing • Anti-screen capture • Prevent most obvious attack on documents • Watermarking • In theory, can trace stolen content • In practice, watermarking is disappointing • “Unique-ification” (or metamorphism) • Break once, break everywhere (BOBE) resistant DRM 24

25. Other Measures/Concerns • General code obfuscation • Collberg and Thomborson • Questions concerning actual strength • Code “fragilization” (guards) • Code hash checks itself • Any change should cause code to break • Can we trust OS? • How can we protect ourselves? DRM 25

26. DRM for Streaming Media DRM 26

27. Attacks on Streaming Media • Spoof stream between endpoints • Man in the middle • Capture stream • Malicious software stealing stream at client end • Replay/redistribute data DRM 27

28. Design • Scrambling algorithms • Encryption-like algorithms • Many such algorithms avaliable • Negotiation of random algorithm • Server and client must share algorithm • Decryption at receiver end • Remove strong encryption • De-scrambling in device driver • Remove scrambling just prior to rendering DRM 28

29. Scrambling Algorithms • Server has a large set of scrambling algorithms: M = {1,2,3,4,…,N} • A client has a subset of algorithms, LIST = {12,45,2,37,23,31} • The LIST is stored on client, encrypted with server’s key: E(LIST,Kserver) DRM 29

30. Server-side Scrambling • On server side encrypted scrambled data scrambled data data • Server must scramble data with an algorithm the client supports • Server must securely communicate algorithm choice to client DRM 30

31. Scrambling Selection • Scrambling algorithm “database” distributed to clients • List is random subset of algorithms E(LIST, K) E(m,Ks) scrambled (encrypted) data using Alice’s m-th algorithm Bob (server) Alice (client) DRM 31

32. Client-side De-scrambling • On client side encrypted scrambled data scrambled data data • Keep plaintext away from attacker • Proprietary device driver • Scrambling algorithms “baked in” • Able to de-scramble at last moment DRM 32

33. Why Scrambling? • Uniqueness or metamorphism • If a scrambling algorithm is known to be broken, server does not choose it • If client has too many broken algorithms, server can force upgrade • Proprietary algorithm harder to reverse engineer • We cannot trust crypto strength of proprietary algorithms, sowe also encrypt DRM 33

34. Why Uniqueness? • The threat is reverse engineering (SRE) • Reverse engineering a standard crypto algorithm is easy (unnecessary) • Reverse engineering a scrambling algorithm is potentially much more difficult • We also encrypt so not violating Kerchoffs Principle (at least not too much…) • This is clearly security by obscurity and I’m not ashamed to admit it! DRM 34

35. Exploit Systems and DRM DRM 35

36. Exploit Systems • Exploit Systems (ES) management consists entirely of musicians • Not all of them are on drugs • They offered me a job with huge salary… • Payable as soon as the get funding • Exploit Systems international office? • A coffee shop in Palo Alto • Only in Silicon Valley… DRM 36

37. Exploit Systems • Exploit Systems is a “peer offering service” • Their web site is (purposely?) vague on the definition of “peer offering service” • But I happen to know what they are doing... • ES tries to gently coerce people into paying for content obtained from a peer-to-peer (P2P) network DRM 37

38. P2P File Sharing: Query • Suppose Alice requests “Hey Jude” • Black arrow: query • Red arrow: positive response Alice Bob Frank Dean Marilyn Carol Pat Pat Fred Carol Ted • Alice can select from: Carol, Pat DRM 38

39. P2P File Sharing with ES • Suppose Alice requests “Hey Jude” • Black arrow: query • Red arrow: positive response Bill Ben Joe Alice Bob Dean Marilyn Exploit Systems Carol Pat Pat Fred Carol Ted • Alice selects from: Bill, Ben, Carol, Joe, Pat • Bill, Ben, and Joe have legal content! DRM 39

40. Exploit Systems • Bill, Ben and Joe look legitimate • Goal is to have at least half of top 10 be Exploit Systems (ES) responses • If “victim” clicks on ES response • DRM protected (legal) content downloaded • Then small payment required to play • Victim can choose not to pay • But then must download again • Is it worth the hassle to avoid paying $0.25? • ES content also offers extras DRM 40

41. Exploit Systems • A very clever idea • Piggybacking on P2P network • Weak DRM works well here • Pirated content already exists • DRM only needs to be more hassle to break than hassle of clicking and waiting (a few times) • Current state of Exploit Systems? • Very little interest from the music industry • Lots of interest from the “adult” industry DRM 41

42. Enterprise DRM DRM 42

43. Why Enterprise DRM? • Health Insurance Portability and Accountability Act (HIPAA) • Medical records must be protected • Fines of up to $10,000 “per incident” • Sarbanes-Oxley Act (SOA) • Protect documents of interest to SEC • Also Draconian penalties • DRM required for regulatory compliance DRM 43

44. What’s Different in Enterprise DRM? • Technically, it is similar to e-commerce • But motivation for DRM is different • Regulatory compliance • Not to make money, but to not lose money! • Human dimension is also much different • Legal threats are far more plausible • Legally, corporation is probably off the hook provided active attack is necessary DRM 44

45. Enterprise DRM • Moderate DRM security is sufficient • Policy management issues • Easy to set policies for groups, roles, etc. • Yet policies must be flexible • Authentication issues • Must interface with existing system • Must prevent network authentication spoofing (authenticate the authentication server) • Enterprise DRM is a solvable problem DRM 45

46. Case Study I • Sarbanes-Oxley Act (SOA) • Requires retention/tagging of all documents related to SEC disclosure • DRM software • Tag new documents created by SOA authors • Allow any SOA author to modify tagged doc’s • Read-only access for non-SOA authors • Transparent to users --- comply by default! DRM 46

47. Case Study II • Access control without authentication • Example: A large automotive company wants to limit access to documents to • Company employees authoring documents • Partner company employees to whom documents are electronically distributed • Other partner company employees to whom the documents are purposely re-distributed DRM 47

48. Case Study II • Accomplished via simple shared password • Modest security requirement • Met with minimal complexity • Works with any partner’s system • Risk of unauthorized password sharing • Acceptable due to legal obligations • Deployment will reach 10’s of thousands • Modest DRM software suffices DRM 48

49. DRM Nonsense DRM 49

50. Silly DRM • We’ll only consider a few examples • Patently obvious • Crypto claims • Extremely silly stuff • Adobe’s “Respect” model • Microsoft’s MS-DRM DRM 50