The MediaSnap© Digital Rights Management System 
 

Priti Sabadra and Mark Stamp

Department of Computer Science

San Jose State University

San Jose, California

 
 
 

ABSTRACT: A real-world digital rights management (DRM) system is discussed. This system was developed and deployed by MediaSnap, Inc., and is designed to protect digital documents. We present both the server and client sides of the application, but we focus most of our attention on the client side since that is where the majority of technical challenges lie. We briefly discuss several of the various technical measures employed by the MediaSnap DRM system. We include comments on the inherent limitations of DRM and conjectures on possible future directions for the technology. 

Keywords: digital rights management, digital content protection, tamper resistant software, anti-debugging 

1. Introduction

Digital rights management (DRM) can be viewed as an attempt to provide “remote control” over digital content. The required level of protection goes beyond securely delivering the bits since restrictions on the use of the content must be maintained after it has been delivered. The buzzword for this is “persistent protection.” 

Consider a digital book. Such a book can be securely delivered over the Internet using standard cryptographic techniques. But if the recipient can save the book in an unrestricted form, he can easily redistribute a perfect digital copy to a vast number of people. This reality has led publishers to forego the potentially lucrative sale of digital books over the Internet and has had a similar chilling effect on the legitimate distribution of other types of digital content. Without robust DRM, owners of digital content have little choice other than to rely on the honor system.1  

Most marketers of DRM products imply that their proprietary solution can provide unbreakable protection from unauthorized use. Even the opponents of such protection often talk in dark tones about the consequences of DRM which, they argue, would allow copyright holders to enforce excessive restrictions on “fair use” [3]. However, several DRM products that have been widely available—such as those from Adobe [4,5] and Microsoft [6]—have been spectacular failures. 

DRM products can, roughly, be divided into four categories. At the bottom rung on the security ladder are systems that rely on the honor system. In these systems, no real attempt is made at technical security protection. Instead, such systems rely on users (or programmers) to “do the right thing.” This model is somewhat analogous to the shareware distribution of software. Not surprisingly, these glorified honor systems have had limited success in the marketplace. 

At a slightly higher security level are systems that employ limited software-based technical means of protection. A user who is skilled enough to operate a screen capture program is likely to be able to defeat such a system. 

A very few software-based DRM systems aim for a higher level of security. Such systems try to attain a measure of “controlled execution”, whereby the user cannot easily do certain operations (e.g., screen capture) that might compromise security. In addition, such systems might employ tamper checking techniques, controlled rendering, and various other methods.  

At the highest security level are systems that rely on tamper-resistant hardware. This is not yet a viable option for systems intended for personal computers or similar devices. 

In this paper we discuss a specific DRM product from MediaSnap, Inc. This system clearly aims for the highest level of software-based security. Since this information is taken from an actual product, we cannot give specific details that might compromise its security. Instead, we attempt to present at a level of detail consistent with a semi-open design, as advocated by Anderson [7]. In the DRM marketplace, closed designs are the norm and hence this level of detail is highly unusual. Consequently, we believe that the completeness provided in this paper is far beyond that which is publicly available on any other functioning DRM system. The paper [8] contains more background discussion of DRM, as well as a plethora of references. 

2. MediaSnap DRM system

In this section we present an overview of the MediaSnap DRM system [9]. This system was designed to protect PDF documents, though most of the same principles could be applied to audio, video or any other digital media.  

On the client side, the system employs an email interface, with a pull-down menu to select the desired level of persistent protection. The resulting email and attachments are encrypted using standard techniques then sent to a Secure Document Server (SDS) where the recipient’s authentication information (password and/or certificate and/or biometric, etc.) is stored. The SDS applies the desired persistent protection to the document, including the appropriate authentication information. The protected document is then sent from the SDS to the recipient. 

Upon receipt, a protected document must be opened with an Adobe PDF reader equipped with a MediaSnap PDF plugin. The heart of the client-side DRM system lives in this PDF plugin.  
 

2.1 Client Side Overview

At a high level, the DRM system can be viewed as consisting of two layers of protection, with various other security features built around these layers. At the outermost layer, the compiled code is encrypted and an anti-debugging technique is employed. While not invincible, the combination of these two features provides significant protection against all but the most dedicated attackers. 

The second layer of protection includes a variety of obscurity mechanisms discussed below. These are designed to provide a challenging reverse-engineering problem once the outer layer of protection has been penetrated.

2.2 Encrypted Object Code

In the MediaSnap system, the object code is encrypted in blocks, where each block could be as small as a compiler “basic block” or as large as individual functionsor even larger units. There is some tradeoff between block size (smaller being somewhat more secure, since one compromised block does not necessarily imply that all blocks are compromised) and execution speed (smaller block size will tend to slow execution). The code is then decrypted as it executes, with only a single block in the clear at any given time. Tamper checking is employed at this point, yielding code that is somewhat fragile in the sense of [10, 11]. This process is intended to serve a similar purpose as that described by Aucsmith [12].

2.3 Debug Disrupter

An anti-debugger is used to detect programs that try to set breakpoints. If this debug disrupter finds that a breakpoint has been set, it will cause the DRM application to close. In this way, the decrypted segment of code is protected from inspection. Also, the decrypted code block calls the debug disrupter. These two interlocking mechanisms perhaps offer greater security in combination than the sum of the security provided by the two component parts. 

2.4 Content Encryption

The MediaSnap system employs the Advanced Encryption Standard (AES) for content encryption. Any other well-known, secure crypto algorithm would, of course, suffice.

2.5 Scrambling

In order to tie all of the content to an unknown algorithm (from an attacker’s perspective), the MediaSnap system employs a proprietary “scrambling” algorithm. The specific scrambling algorithm is chosen from a large family of related crypto-algorithms. The algorithms have been tested extensively and no obvious weakness has been found. However, the algorithms have not undergone the rigorous peer review necessary before they could be considered secure, in a cryptographic sense. But the purpose of the scrambling algorithm is not to provide additional cryptographic strength, since AES fulfills that requirement. Instead, the goal is to force an attacker to reverse engineer the scrambling algorithm. 

The attacker must defeat the scrambling in order to recover any plaintext. Since the scrambling algorithm is proprietary, recovering the scrambling keys without recovering the algorithm is insufficient to recover the plaintext. And since there exists a large family of scrambling algorithm, this is a place where uniqueness (discussed below) can easily be applied.

2.6 Authentication

The MediaSnap authentication mechanism allows for arbitrary boolean combinations of passwords, biometrics, digital certificates, etc. For example, a document could be protected so that it would open with either user A’s password or user B’s thumbprint and digital certificate.

2.7 Key Management and Caching

The key management problem is critical to any DRM system. Somehow, a secret must be shared between the creator of the protected content (the SDS) and the software that will render that content. Public key cryptography is one—though certainly not the only—way to share such a secret. 

Protecting a secret is the fundamental challenge of DRM. Caching is a closely related problem. Generally, we do not want to ask the user to re-authenticate each time the authentication result is required. The MediaSnap software employs a caching scheme where each time a piece of data is cached, different data values are stored into a different location in memory.

2.8 Anti Screen Capture

Perhaps the most obvious way to attack a DRM document protection system is to use a screen capture program to capture the image and save it to an unprotected file. The MediaSnap system employs a low-level utility that intercepts calls related to screen capture. In this way, it is possible to filter legitimate screen capture operations from those that attempt to access screen memory currently in use by the protected application. 

Of course, an attacker can always use a digital camera to capture the image (the so-called “analog hole” [13]). If this occurs—or the document protection is broken by any other means—the last line of defense lies in the realm of digital watermarking.

2.9 Digital Watermarking

An invisible digital watermark potentially enables us to track the source of a stolen document. For this reason, each MediaSnap protected document includes such a watermark. Unfortunately, the current state of watermarking technology is such that if an attacker knows the watermarking technique, he can almost certainly remove the mark, or at least mangle it beyond recognition. It is therefore necessary that the MediaSnap watermarking scheme remain secret—see [14] for an account of the perils of using a known (or easily discovered) watermarking scheme.

2.10 Uniqueness

Several of the security features described in the previous sections can be made unique to each instance of the DRM player software. There are two different levels of uniqueness that are of interest. At one level, each player could have functionally unique features. In this case a piece of content must be processed differently for each player. For example, if a different scrambling algorithm is included in each player then a document protected for one particular player will not be readable by any other player. On the other hand, by varying only those functions internal to the DRM software a “weaker” level of uniqueness can be achieve. For example, the internal key management within each player could be unique. This level of uniqueness does not affect the functionality in any way, but it is nevertheless likely to create a more difficult problem for an attacker.

The potential benefits of uniqueness or “genetic diversity” in software have previously been noted [15, 16]. In the context of DRM, uniqueness creates a system where an attacker may be able to break one particular instance of the software without necessarily breaking the entire system. Strangely, within the DRM community software uniqueness appears to have had little impact outside of MediaSnap and Macrovision [17].  

In the MediaSnap DRM system each document reader includes both a generic (or universal) copy of the security functions as well as a set of unique functions. A document can therefore be protected so that it is readable by any MediaSnap software (provided proper authentication is provided) or so that it is only readable by one particular instance of the software. This offers both the benefits of a uniqueness and universality in a single package. 

2.11 Secure Document Server

The SDS contains a database of individual user authentication information that is required to open protected documents. The SDS must also store one or more private keys that are used to securely send content from the user to the SDS. Standard cryptographic protocols suffice for this part of the process. 

In addition, the SDS must be able to protect a document so that it can only be opened by the unique version of a specific client’s software (see the uniqueness discussion above). Each client stores a list of encrypted “uniqueness parameters” that are transmitted to the server if the unique level of protection is to be applied. In this way, the server need not maintain a database of uniqueness parameters. However, the server must be able to translate these parameters into (the functional equivalent of) the unique software contained in the client. The SDS can then process the document (encrypt, scramble, etc.) so that only the intended version of the client software can open the document. Of course, the correct user authentication information must also be available. 

The protected information stored on the SDS is stored in tamper-evident hardware. This level of protection is considered sufficient for the environment in which the SDS is expected to operate.

3 Conclusion

With any combination of current DRM technology, it is possible for a skilled attacker to defeat the persistent protection applied to a given piece of digital content. Certain combinations of techniques will provide more of a challenge than others. However, at the current evolutionary stage of DRM there appears to be no escape from the dubious concept of “security by obscurity.” Consequently, once a dedicated attacker has gone through the (perhaps tedious) process of removing the obscurity, the security vanishes as well. Furthermore, it appears that for nearly all systems currently on the market, a successful attack on one particular instance of the DRM software immediately applies to all instances of the software; see [4] and [5] for examples of such DRM systems. 

Tamper-resistant hardware is the most robust solution to the DRM problem. The TCPA/Palladium initiative [18] is an attempt to add such hardware to the next generation of personal computers for DRM purposes. Though such an approach clearly offers many security advantages, it also raises a set of troubling security issues [19]. For example, it threatens to remove considerable control from users and hand it to third parties. 

If DRM is to be done in software, perhaps the best hope lies in the realm of software uniqueness. If each instance of a particular DRM software product includes some degree of uniqueness then an attack that succeeds against one will not necessarily succeed against all. In fact, the problem of defeating all instances of unique software is likely many orders of magnitude more difficult than defeating a single instance. Of course, much depends on how and where the uniqueness is employed. 

It is conceivable that the idea of software uniqueness could take software-based DRM beyond its current level—which is bound to disappoint as fielded systems continue to fail—to a level where a slow leak of protected content is an accepted fact, but complete and total collapse of DRM systems is a rarity.

References

  1.   P. Sayer, Stephen King’s ‘Plant’ withers, The Industry Standard, November 29, 2000 http://www.thestandard.com/article/display/0,1151,20433,00.html
  2.   J. Harkavy, King online experiment casts publishing doubts, The Age, http://www.theage.com.au/entertainment/2000/12/11/FFXPIB8LJGC.html
  3.   F. von Lohmann, Reconciling DRM and fair use: Preserving future fair uses?, Electronic Frontier Foundation, http://www.cfp2002.org/fairuse/lohmann.pdf
  4. B. Guignard, How secure is PDF?,  http://www.cs.cmu.edu/~dst/Adobe/Gallery/PDFsecurity.pdf
  5.   D. V. Bailey, Inside eBook security, Dr. Dobb’s Journal, November 2001, http://www.ddj.com/documents/s=1487/ddj0111d/0111d.htm
  6.   “Beale Screamer”, Microsoft’s digital rights management scheme — technical details,  http://jya.com/ms-drm.htm
  7.   Ross J. Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems, John Wiley & Sons, Inc., 2001 (see Chapter 23)
  8. Stamp, M., “Digital rights management: The technology behind the hype,” to appear in the Journal of Electronic Commerce Research, preprint available at http://home.earthlink.net/~mstamp1/papers/DRM.doc
  9. MediaSnap, Inc., http://www.mediasnap.com
  10.   B. Horne, L. Matheson, C. Sheehan and R. E. Tarjan, Dynamic self-checking techniques for improved tamper resistance, Workshop on Security and Privacy in Digital Rights Management 2001
  11. H. Chang and M. J. Atallah, Protecting software code by guards, Workshop on Security and Privacy in Digital Rights Management 2001
  12. D. Aucsmith, Tamper resistant software: An implementation, Proceedings of the First International Information Hiding Workshop, Lecture Notes in Computer Science 1174, Springer-Verlag, Cambridge, U.K., pp. 317-334 (1996)
  13. EFF consensus at lawyerpoint: Hollywood wants to plug the “analog hole”, http://bpdg.blogs.eff.org/archives/000113.html
  14. S. A. Craver, M. Wu, B. Liu, A. Stubblefield, B. Swartzlander, D. W. Wallach, D. Dean and E. W. Felten, Reading between the lines: Lessons from the SDMI challenge, Proceedings of 10th USENIX Security Symposium, August 2001,  http://www.cs.princeton.edu/~felten/
  15. F. B. Cohen, Operating system protection through program evolution,  http://all.net/books/IP/evolve.html
  16. S. Forrest, A. Somayaji and D. H. Ackley, Building diverse computer systems,  http://www.cs.unm.edu/~forrest/publications/hotos-97.pdf
  17. Software tamper-proofing deployed 2 year anniversary report,  http://www.cptwg.org/Assets/September presentations/ Software_Tamper-Proofing.ppt
  18. Electronic privacy information center, Microsoft Palladium: Hailstorm 2.0,  http://www.epic.org/privacy/consumer/microsoft/palladium.html
  19. R. Anderson, TCPA/Palladium frequently asked questions,  http://www.cl.cam.ac.uk/%7Erja14/tcpa-faq.html
Biographies

Mark Stamp has spent more than a decade in the field of security. Following academic work in cryptography, he can neither confirm nor deny that he spent seven years as a cryptanalyst at the National Security Agency. Most recently, he spent two years developing a DRM product at MediaSnap, Inc., a small Silicon Valley startup company. Currently, Dr. Stamp holds an academic position and does security consulting on the side. 

Priti Sabadra is a Computer Science professional from India. She has worked as a Network Engineer and she helped design the network infrastructure of a broadband ISP in India.  Priti’s researcher interest is in network security and she plans to pursue a PhD in the near future