1 / 84

Digital Rights Management

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/. Who Am I?. 1992: PhD, Texas Tech 1992-1993: WPI 1993-2000: NSA

mindy
Download Presentation

Digital Rights Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related