Digital leakage is the loss, whether intentional or inadvertent, of confidential data in digital form. The loss might take the form of a trade secret sent to a competitor, the premature release of financial data to an analyst or market, or the leak of embarrassing information to the media. Digital leakage occurs from seven primary sources:

Digital leakage is costly. A survey published by PricewaterhouseCoopers and the American Society for in Industrial Security^[*] in 1999 found that on average, large organizations lost confidential or proprietary information 2.45 times in a year and each incident cost an average of $500,000. The survey estimated that the cost of digital leakage in the Fortune 1000 in a single year was $45 billion.

With those kinds of statistics, you’d think DRM would be a technology that everyone could love, but it has been at the heart of some of the most acrimonious debates of the digital age. The movie and recording industries are worried that electronic distribution of their works will result in violations of their copyrights and, as a result, diminish their bottom line.

This is a classical problem for digital rights management. The producers of the digital goods want to release them to people beyond their control and give them only specific rights (e.g., to listen to, but not copy, the music).

The problem is that the needs of the copyright holders are in direct conflict with the wants of their customers. Consumers of movies and songs want open access, open formats, and access to works no longer for sale in traditional distribution channels. Napster illustrated the powerful drivers in this market. People want to be able to share music and movies with others.

Needless to say, this is a complex issue. The reason for bringing it up here is that the battle over copying movies and music has colored many people’s view of DRM and created an atmosphere where any discussion of DRM creates strong feelings. DRM might be the right technology for solving critical access-control problems for your organization’s digital resources. Unfortunately, DRM has become synonymous with the battle over copyrighted music and movies. You can probably avoid the DRM battle and the emotions it engenders if your motive is to control activities on digital resources rather than to use DRM as part of a business plan that restricts customer actions.

Apple’s iTunes and its associated music store provide a real-world example of DRM in action. iTunes will play unprotected MP3 format audio files, but when a user purchases music form the Apple music store, the audio file is downloaded in a format called AAC. Apple wraps the AAC file in a DRM system called Fairplay. The standard rights allow a purchaser to listen to the song in an unlimited way on up to three computers and to burn the song to a CD.

This set of rights was chosen to try to match the value that user’s place on the audio file to the price Apple wanted to charge. For example, Apple could disallow burning AAC format songs to CD, because they control the client, but that would decrease the value of the file for many people.

Apple also has to be able to administer rights remotely to provide customer service. For example, if I purchased a song, installed it on three computers, and then sold one of those computers and bought another, I can contact Apple to have the rights reset on my music collection, allowing it to be installed on my new computer. Without this ability, audio files purchased on iTunes would quickly lose their value as people upgraded their computers.

This case study is a good example of the additional burden placed on a company in controlling access to content using DRM. Restricting rights for content costs real money, because the content has to be administered and it reduces the value of the content to users.

Digital rights management is, of course, about more than just protecting music and movies. DRM is a technology all of us would like to use in certain circumstances. For example, when I send my Social Security Number to my bank, I’d like to be able to control how it is used. As another example, wouldn’t it be nice to be able to send your credit card number to an online merchant and attach specific rights to it: the right to use it to facilitate a single purchase and not be stored or transferred. All of us have digital information that we’d like to be able to send to someone else without giving them unlimited rights.

SealedMedia, a DRM vendor, lists some important features that DRM systems should have to be effective.

A perfect DRM system with all of these features does not exist. You will likely have to prioritize these properties for your particular application and evaluate solutions on that basis. The next section describes a reference architecture that shows how some of these features can be accommodated.

Figure 10-1 shows a reference architecture for a digital rights management system. The reference architecture is by Bill Rosenblatt, et al., and is discussed in some detail in the book Digital Rights Management: Business and Technology (John Wiley & Sons). The reference architecture points out the key interactions in a DRM system and also exposes some of the weaknesses in current DRM schemes.

In Figure 10-1, there are three primary participants. The client is an application invoked on behalf of the entity wanting to access and use a digital resource. The content server is the application that is invoked on behalf of the entity supplying the digital resource. The license server is the application invoked on behalf of the person who owns or controls the rights associated with the good. The license server and content server might be operated by the same entity or they might not. For example, the owner of the goods may contract with multiple distributors to supply the good but control the licensing centrally.

In the reference architecture, the client, on behalf of the user, requests a specific resource from the content server (1). The content server uses a content repository along with product information to create a content package. The content repository might be part of the content server itself or a standalone content management system. The product information specifies price and other product-specific information. It makes sense to separate the product information from the content, because the same content may be sold as different products differentiated by customer class, additional services or warranties, and so on.

Figure 10-1. A DRM reference architecture

The content is delivered in an encrypted content package that contains both the content and metadata. Whether the content is streamed or delivered as a single package is inconsequential to our discussion. The metadata usually includes information such as title, author, rights holder, and other information about the content as well as information that uniquely identifies this content and transaction.

The DRM controller (2) contacts the license server (3) associated with the content package to retrieve a license for the content. The DRM controller sends the license server information about the content package and the identity credentials for the entity that invoked it.

The license server checks the identity credentials (4) using whatever identity infrastructure is available to it for authentication and then consults a rights database (5) for authorization. We’ll see an example of an XML language for expressing rights later in this chapter.

There may be a financial transaction (6) if the user is required to pay for the license. Alternately, the license server may require some other consideration such as registering and providing contact information. Once consideration for the license has been received, encryption keys (7) are retrieved based on the content package identity and these keys are used to generate a license that is sent back to the DRM controller (8) as an encrypted package containing a statement of rights and a set of keys for unlocking the content package. The license is encrypted to protect the keys used to unlock the content package and to ensure its integrity.

The DRM controller decrypts the license and uses the keys contained in it to unlock the content. The content can be sent to a rendering application (9) for display (10).

The client, in managing rights, may store information about usage in the content package. Usage data is stored with the package, rather than separately, to ensure that even if the content package and license are moved to another client, the usage restrictions are honored and audit trails are continuous.

The client application is a critical component in this scheme, because the client application, rather than the client, receives and processes the keys. This overcomes, in part, the problem of a user unlocking the digital content and then using it in an uncontrolled fashion, because the client application can ensure the permissions carried in the license are honored.

If you were applying a little creative thinking during the preceding discussion of the DRM reference architecture, you probably thought of several ways that the scheme could be defeated. That issue is the chief weakness of DRM. As we’ve seen, for the user to view or otherwise use the content, it has to be rendered in a usable format, and that allows ample opportunity for the content to be redirected to a use that wasn’t specifically authorized.

The iTunes example illustrates some of the problems :

These examples show just how hard it is to really protect content in a digital format. In addition to the tradeoffs made by Apple that were examined in the case study, Apple is inconveniencing their legitimate users while still allowing the rights of copyright holders to be undermined by determined crackers.

These problems have led to numerous calls for trusted computing platforms that would ensure that the DRM client was run in an environment that kept even determined attackers from gaining access to protected content illegitimately. The basic idea is to protect every component of the end-user system in a way that disallows illegitimate use. When we say “every component,” we’re being literal—right down to the keyboard. Building a trusted computing platform requires the cooperation and coordination of both hardware and software manufacturers in very sophisticated way.

The nature of trusted computing systems and the debate surrounding them is beyond the scope of this book, but they are being advanced by companies as powerful as Microsoft and Intel and countered by numerous user advocacy groups. Because trusted computing platforms are still in the future, DRM will remain an exercise in making the theft of unauthorized rights sufficiently inconvenient that most users will only access content legitimately.

One of the most important features of a DRM system is the ability to specify and manage rights. Rights are a special kind of authorization, and much of what we learned about authorization in Chapter 8 is applicable to DRM. The differences lie in the fact that DRM is meant to restrict actions on a much finer-grained scale than we typically deal with in a standard authorization system.

Authorization rights typically center around whether a subject is allowed to read, modify, or create objects. As we saw, we usually specify the rights for classes of users against classes of objects in order to make the task manageable. In DRM, we often want to give specific rights (for example, the right to view but not copy) to specific people (Ted in accounting or a particular customer) for specific time periods (for the next two hours or three more times). That makes the task much more difficult. The problem can be made tractable by being able to build general licenses and derive specific licenses from them automatically.

We also saw in Chapter 8 that separating authorization rights from the objects being protected increases the ability of operators to take protective action. Specifically, when rights are associated with objects, removing rights for a particular user means visiting each object the user might have had rights to. The goal of systems like RBAC is to specify rights separately, so we can remove access rights across the board with a single, reliable action.

In DRM systems, the nature of the problem does not make this solution possible. Since our problem statement is to protect content that is not directly under our control, the rights will generally be sent outside the systems we directly control to some other system that will enforce them. Offline access to protected content is usually a requirement, and so it is not practical for the client application to check back with the license server each time the content is accessed. Thus, rights can be difficult or impossible to revoke once they’ve been issued.

    <license>
      <grant>
        <keyHolder>
          <info>
            <dsig:KeyValue>
              <dsig:RSAKeyValue>
                <dsig:Modulus>Fa7wo6NYf...</dsig:Modulus>
                <dsig:Exponent>AQABAA=  =</dsig:Exponent>
              </dsig:RSAKeyValue>
            </dsig:KeyValue>
          </info>
        </keyHolder>
        <cx:print/>
        <cx:digitalWork>
          <cx:locator>
            <nonSecureIndirect
               URI="http://www.contentguard.com/sampleBook.spd"/>
          </cx:locator>
        </cx:digitalWork>
        <validityInterval>
          <notAfter>2005-12-24T23:59:59</notAfter>
        </validityInterval>
      </grant>
    </license>

The battle over DRM and many of the controversies surrounding it are unimportant to your organization, provided that your intent in using DRM is to control confidential and sensitive data rather than using it to control the actions of your customers. The key point to remember is that DRM is not usually effective against determined attacks. The more valuable the content, the more difficult it is to adequately protect. Consequently, the cost of DRM increases linearly with the value of the content. Because no DRM system is perfect, any DRM system should be carefully evaluated for its particular application and the trade-offs examined thoroughly.