The MediaSnap©
Digital Rights Management System
Priti Sabadra and Mark Stamp
Department of Computer Science
San Jose State University
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.
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 functions─or 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].
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.
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.
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.
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.
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.
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.
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.
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.
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