2. DRM 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/

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

4. DRM 3 What was MediaSnap?  Silicon Valley startup company o Founded June 2000 o 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

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

6. DRM 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

7. DRM 6 DRM Overview

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

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

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

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

12. DRM 11 Current State of DRM  At best, security by obscurity o A derogatory term in the security world  Secret designs oIn violation of Kerckhoffs Principle  Crypto is king o“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

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

14. DRM 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

15. DRM 14 MediaSnap DRM

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

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

18. DRM 17 Accessing a Document in Tethered Mode SDS Recipient Sender key Request key

19. DRM 18 Accessing a Document in Untethered Mode SDS Recipient Sender key

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

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

22. DRM 21 Security Overview Obscurity Tamper-resistance

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

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

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

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

27. DRM 26 DRM for Streaming Media

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

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

30. DRM 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,K server )

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

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

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

34. DRM 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, so we also encrypt

35. DRM 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!

36. DRM 35 Exploit Systems and DRM

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

38. DRM 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

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

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

41. DRM 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 o DRM protected (legal) content downloaded o Then small payment required to play  Victim can choose not to pay o But then must download again o Is it worth the hassle to avoid paying $0.25? o ES content also offers extras

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

43. DRM 42 Enterprise DRM

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

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

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

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

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

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

50. DRM 49 DRM Nonsense

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

52. DRM 51 InterTrust “…a company whose business model appears to rely entirely on legal filings against Microsoft.”

53. DRM 52 Absurd Crypto Claims Q: How does Atabok security compare to the competition? A: The majority of service providers offer the ability to encrypt at 128 bits. Atabok encrypts your content with 256-bit encryption, which is exponentially more secure.

54. DRM 53 Extremely Silly  SecretSeal’s five radical innovations o Hieroglyphic passwords o Variable-length encrypted keys o “Morphogenetic” encryption algorithm o No encryption formula in software o The use of public keys  Do these guys still exist?

55. DRM 54 Adobe’s “Respect” Model  Adobe eBooks and PDF protection  Adobe documentation: “It is up to the implementors of PDF viewer applications to respect the intent of the document creator by restricting access to an encrypted PDF file according to passwords and permissions contained in the file.”  Fail to “respect the intent” and goto jail! o First prosecution under DMCA

56. DRM 55 MS-DRM (version 2)  MS-DRM: an early Microsoft DRM attempt  MS-DRM employed o Weak proprietary block cipher (MultiSwap) o Multiswap used for hashing o No controlled execution o No obfuscation, no individualization, etc.  Hard to believe this was serious DRM effort!

57. DRM 56 Microsoft’s NGSCB

58. DRM 57 Next Generation Secure Computing Base  NGSCB pronounced “n scub” (the G pronounces like a U after migrating to the right)  Will be part of Microsoft’s Longhorn OS  TCG (Trusted Computing Group) o Led by Intel, TCG makes special hardware  NGSCB is the part of Windows that will interface with TCG hardware  TCG/NGSCB formerly TCPA/Palladium o Why the name changes? Why the name changes?

59. DRM 58 NGSCB  The original motivation for TCG/NGSCB was digital rights management (DRM)  Today, it is promoted as general security- enhancing technology o DRM just one of many potential applications  Depending on who you ask, TCG/NGSCB is o Trusted computing Trusted computing o Treacherous computing Treacherous computing

60. DRM 59 Motivation for TCG  Closed systems: Game consoles, smartcards, etc. o Good at protecting secrets (tamper resistant) o Good at forcing people to pay o Limited flexibility  Open systems: PCs o Incredible flexibility o Poor at protecting secrets o Poor at protecting their own software  TCG goal is to provide closed system security benefits on an open system  “A virtual set-top box inside your PC” --- Rivest

61. DRM 60 TCG/NGSCB  TCG provides tamper-resistant hardware o Secure place to store cryptographic key o Keys (or other secrets) secure even from a legitimate user with full admin privileges  TCG hardware is in addition to ordinary hardware, not in place of it  PC has two OSs --- usual OS and special “trusted” OS to deal with TCG hardware  NGSCB is Microsoft’s version of secure OS

62. DRM 61 NGSCB Design Goals According to Microsoft  Provide high assurance o High confidence that system behaves correctly o Correct behavior even if system is under attack  Provide authenticated operation  Protection against hardware tampering is not a design goal of NGSCB o Hardware tampering is the domain of TCG

63. DRM 62 Disclaimer  NGSCB details are sketchy  Based on talk presented at RSA Conference 2004, Microsoft has not worked out all of the details  What follows are my best guesses  This should all become much clearer in the not-too-distant future

64. DRM 63 NGSCB Architecture  Nexus is the Trusted Computing Base in NGSCB  The NCA (Nexus Computing Agents) talk to Nexus and LHS Left-hand side (LHS)Right-hand side (RHS) untrusteduntrusted trustedtrusted Nexus NCA User space Kernel Regular OS Drivers Application

65. DRM 64 NGSCB  NGSCB “feature groups” 1. Strong process isolation oProcesses do not interfere with each other 2. Sealed storage oData protected (tamper resistant hardware) 3. Secure path oPaths to and from I/O protected 4. Attestation o“Things” securely authenticated oAllows TCB to be extended via NCAs r 1.,2. and 3. aimed at malicious code

66. DRM 65 Process Isolation  Curtained memory  Process isolation and the OS o Trusted OS protected from insecure OS o Isolate trusted OS from BIOS, device drivers  Process isolation and NCAs o NCAs isolated from software they do not trust o Trust determined by users --- to an extent… o User can disallow a trusted NCA o User cannot allow an untrusted NCA

67. DRM 66 Sealed Storage  Sealed storage contains secret data o If code X wants access to secret, a hash of X must be verified (must be sure X is trusted) o Implemented via symmetric key cryptography  Confidentiality of secret is protected since only accessed by trusted software  Integrity of secret is assured since it’s in sealed storage

68. DRM 67 Secure Path  Secure path for input o From keyboard to Nexus o From mouse to Nexus  Secure path for output o From Nexus to the screen  Details are vague

69. DRM 68 Attestation (1)  Secure authentication of things o Authenticate devices, services, code, etc. o Separate from user authentication  Public key cryptography used o Certified key pair required o Private key not user-accessible o Sign and send result to remote system  Nexus “extended” via attestation of NCAs o This is a major feature

70. DRM 69 Attestation (2)  Public key required to verify attestation o Verification (i.e., public key) reveals the user o Anonymity is lost  Trusted third party (TTP) can be used o TTP verifies signature o Then TTP vouches for signature to recipient o Anonymity preserved (except to TTP)  Claimed support for zero knowledge proofs o Verify knowledge of a secret without revealing it o Anonymity “preserved unconditionally”

71. DRM 70 NGSCB Compelling Apps (1)  Type a Word document in Windows  Move document to RHS o Trusted area  Read document carefully  Digitally sign the document  What you see is what you sign o Virtually impossible to assure this on your PC!

72. DRM 71 NGSCB Compelling Apps (2)  Digital Rights Management (DRM)  DRM problems solved by NGSCB  Protect secret --- sealed storage o Impossible without something like NGSCB  Scraping data --- secure path o Can’t prevent without something like NGSCB  Positively ID users --- attestation o Higher assurance with NBSCB

73. DRM 72 NGSCB Design Principles According to Microsoft  Everything in Windows must work in NGSCB  User is in charge of o Which Nexuses (Nexii?) will run on system o Which NCAs will run on system o Which NCAs allowed to identify the system, etc.  No external process can enable Nexus or NCA  Nexus does not block, delete or censor any data (NCA does, but NCAs must be authorized by user)  Nexus source code publicly available

74. DRM 73 NGSCB Critics  There are many critics --- we consider two  Ross Anderson o Perhaps the most influential critic o One of the harshest (extreme?) critics  Clark Thomborson o Lesser-known critic o More rational (IMHO)

75. DRM 74 Anderson’s NGSCB Criticism (1)  Digital object controlled by its creator, not user of machine where it currently resides  Why? o Creator can specify the NCA o If user does not accept NCA, access is denied o Aside: Such control is good in MLS applications  MS Word could encrypt documents with key only available to Microsoft products, then… o Very difficult to stop using Microsoft products!

76. DRM 75 Anderson’s NGSCB Criticism (2)  Files from a compromised machine could be blacklisted (e.g., to prevent music piracy)  Suppose “everyone in China uses same copy of Microsoft Word” o If you stop this copy from working on all NGSCB machines, Chinese users will not use NGSCB o Instead, make all NGSCB machines refuse to open documents created with this instance of Word!  I’m not convinced…

77. DRM 76 Anderson’s NGSCB Criticism (3)  Going off the deep end?  “The Soviet Union tried to register and control all typewriters. NGSCB attempts to register and control all computers.”  “In 2010 President Clinton may have two red buttons on her desk --- one that sends missiles to China and another that turns off all of the PCs in China…”

78. DRM 77 Thomborson’s NGSCB Criticism  NGSCB acts like a security guard  By passive observation, NGSCB “security guard” can see lots of sensitive information  How to know NGSCB is not spying on you?  According to Microsoft o Nexus software will be public o NCAs can be debugged (for app development) o NGSCB is strictly “opt in”  But… release version of NCA not debuggable and versions have different hash values!

79. DRM 78 NGSCB Bottom Line (1)  TCG/NGSCB provides a trusted OS buried within an open platform  Without something similar, PC may lose out o Particularly in entertainment-related areas  With NGSCB it is claimed that users will lose some control over their PCs  But users must choose to “opt in” o If user does not opt in, what has been lost?

80. DRM 79 NGSCB Bottom Line (2)  NGSCB is a trusted system  Only a trusted system can break security o By definition, an untrusted system is not trusted with security critical tasks o If untrusted system does not perform as expected, security is not at risk o Also by definition, a trusted system is trusted with security critical tasks o If trusted system does not perform as expected, security is at risk

81. DRM 80 DRM Conclusions

82. DRM 81 My DRM Theories  My theories, which are mine…  DRM for e-commerce o Strong DRM in software is impossible o Moderate DRM is possible in some cases o Weak DRM is OK if business model supports it o Charging $1/song is not supportable given P2P, high speed Internet connections, etc. o NGSCB may tilt the balance somewhat  DRM in enterprise o Legal mandates driving adoption o Realistic legal threat enhances DRM greatly

83. DRM 82 Conclusions  Current DRM systems are weak o Ironically, weak systems have worked better than (moderately) strong systems, at least so far o Stronger systems more complex/cumbersome  Ideal software-based DRM… o Individual content is non-trivial to attack o Overall system survives repeated attacks o In other words, BOBE-resistant o Is this possible?

84. DRM 83 DRM References  M. Stamp, Digital rights management: The technology behind the hype, Journal of Electronic Commerce Research, http://www.csulb.edu/web/journals/jecr/issues/20033/paper3.pdf http://www.csulb.edu/web/journals/jecr/issues/20033/paper3.pdf  M. Stamp, Risks of digital rights management, Communications of the ACM, http://www.csl.sri.com/users/neumann/insiderisks.html#147 http://www.csl.sri.com/users/neumann/insiderisks.html#147  M. Stamp, Digital rights management: For better or for worse?, ExtremeTech, http://www.extremetech.com/article2/0,3973,1051610,00.asp http://www.extremetech.com/article2/0,3973,1051610,00.asp  E.J. Sebes and M. Stamp, Enterprise digital rights management: ready for prime time? http://www.bcr.com/bcrmag/2004/03/p52.asp http://www.bcr.com/bcrmag/2004/03/p52.asp  P. Biddle, et. al., The darknet and the future of content distribution, http://crypto.stanford.edu/DRM2002/darknet5.doc http://crypto.stanford.edu/DRM2002/darknet5.doc

85. DRM 84 NGSCB References  NGSCB: Trusted Computing Base and Software Authentication, http://www.microsoft.com/resources/ngscb/documents/ngscb_tcb.doc http://www.microsoft.com/resources/ngscb/documents/ngscb_tcb.doc  P. England, et al, A Trusted Open Platform, http://www.cs.cornell.edu/People/egs/syslunch-spring04/palladium.pdf http://www.cs.cornell.edu/People/egs/syslunch-spring04/palladium.pdf  E. Cram, Migrating Applications to NGSCB, http://www.intel.com/idf/us/fall2003/presentations/F03USSCMS22_OS.pdf http://www.intel.com/idf/us/fall2003/presentations/F03USSCMS22_OS.pdf  R. Merritt, Cryptographers Sound Warnings on Microsoft Security Plan, http://www.eetimes.com/sys/news/OEG20030415S0013 http://www.eetimes.com/sys/news/OEG20030415S0013