12.2 Digital rights management

The goal of this section is to provide a technical introduction to the Microsoft Rights Management (RMS). I will explain the major RMS concepts and technologies and how MS makes these collaborate to provide enterprise-level digital rights management (DRM).

Microsoft released the RMS server software as a free add-on to Windows Server 2003 late 2003. The RMS server add-on will runs only on Windows Server 2003. RMS is not the first DRM software MS ever created: Windows Media Player has included DRM features for years.

12.2.1 Why digital rights management?

The goal of any DRM software can be summarized as follows: to provide persistent integrity protection of digital media. Let’s look in more detail at the different components of this goal statement.

• Persistent Protection: DRM protects digital information at any time and in any place. DRM access control data is attached to the digital information and cannot be bypassed. The protection is end to end: The information is protected while it is transmitted over a communication channel and when it is stored in a repository.

This means that the level of protection offered by a DRM solution goes far beyond what is currently provided by perimeter protection–based security solutions. Everyone certainly knows these security solutions that are in use today—to name just a few, firewalls, access control lists, encryption solutions (VPN software to protect communication channels, S/MIME-based solutions to protect e-mail messages), and so forth. None of these provides persistent protection. At one point in time or at a certain location, they all leave the information unprotected; for example, when the information leaves the internal network protected by a corporate firewall, when it leaves the communication channel protected by a VPN software, when it is retrieved from a file server (protected by ACLs) and copied to another repository (a Web site, an FTP site, and so forth), or when it is unencrypted and stored to the local system drive.

• Integrity Protection: DRM protects digital information from unauthorized access and unauthorized modification. From a security service point of view, DRM provides integrity, confidentiality, and user data authentication services.

• Digital Media: DRM only applies to digital media. DRM access control information is attached in a digital format to digital data. Because of its digital roots, it cannot be applied to analog data. Microsoft uses this excellent image of a computer screen that is put on a photocopier to illustrate this point. This underlines an important shortcoming of DRM and of all security technologies. A global security solution is not just about technology, but also requires a global solution approach that, besides technology, also incorporates procedural, policy-based, and social security measures.

Two important DRM features that make DRM unique and that can be used to promote the use of DRM solutions are the following:

• DRM provides a means of differentiating between content ownership and content possession. In other words, just because I have a legitimate copy of the content on my computer or device does not make me the“owner” in the sense that it really belongs to me in a copyright sense.

• DRM can provide a very fine level of granularity of access rights to digital information. Without it you either have access to the content or you don’t. But with DRM you can have the right to view, print, copy, forward, and so forth.

For many IT companies, an important driver behind the development of DRM software is the many legislative and regulatory requirements that have popped up in recent years in the area of digital information protection. Good examples are the requirements set forward by the Securities and Exchange Commission (SEC), the Healthcare Insurance Portability and Accessibility Act (HIPAA), and the Gramm-Leach-Bliley Act (GLBA— more information can be found at http://www.epic.org/privacy/glba/ and http://www.ftc.gov/privacy/glbact/). Properly implementing DRM solutions will enable organizations to better comply with these legislative and regulatory requirements.

12.2.2 RMS and XRML

In a DRM solution, the persistent protection of digital media is offered by persistent usage policies. A usage policy defines what can be done with a particular digital medium: who can do what, when this can be done, and under which conditions. Usage policies are created by the data creators or owners and remain with the data for their entire lifetime, independently of where or when the data is used or accessed.

To express these usage policies, RMS relies on the eXtensible Rights Markup Language (XrML) and more particularly on XrML licenses. An XrML license is a digital document that is linked to a digital medium. It tells the user of the medium what he or she is allowed to do with that particular medium. Linked to licenses are two key RMS processes:

• “Licensing,” or the process of generating and linking licenses to digital media

• “Enforcement,” or the process of ensuring that the use of the digital media adheres to the restrictions stated in the associated licenses

XrML provides a universal method for expressing licenses in a DRM environment. It is an open standard that is promoted by a company called

ContentGuard and endorsed by important IT industry players such as Microsoft and IBM. Microsoft uses XrML 1.2 in its current RMS software and plans to move to XrML version 2.0 in the next major RMS release. For more information on XrML (including the XrML version 2.0 specification), see the XrML Web site at http://www.xrml.org.

XrML is not the only DRM standard. An important competitor is the Open Digital Rights Language (ODRL)—which is very popular in the mobile world and promoted by the W3C (World Wide Web Consortium), the Open Mobile Alliance (formerly known as the WAP Forum), and companies like Nokia.

In an XrML license a usage policy is expressed in terms of trusted entities (or principals), resources (or digital media), usage rights, and usage conditions. Usage rights link certain operations on resources to trusted entities. Usage rights may be further constrained by usage conditions. A trusted entity can be a user defined in the RMS system who is allowed to read a document. It can also be a machine from which a document can be read.

A good example is a usage policy for a Word document that states that only Joe can read the document until June 2004, and that Paul is allowed to modify the document until June 2004. In this example, Joe, Paul and their respective PCs are the entitiles trusted by the RMS system. Joe’s right to reaad the document and Paul’s right to modify the document are examples of usage rights. These rights are further restricted by usage conditions: Joe can only read the document until June 2004; Paul can only modify it in until June 2004.

Figure 12.6 gives an example of what an XrML license looks like. This license statesthat a particular trusted entity (identified by its digital signature) can print an e-book (located at a particular URL) before December 25, 2001. The example clearly illustrates the different components of a license: trusted entity, usage right, resource, and usage condition.

Figure 12.6: XrML license example.

The Microsoft RMS and XrML are excellent examples of solutions using hybrid cryptographic technology: They combine the power of both symmetric and asymmetric encryption technology. An XrML license contains a secured symmetric encryption key, which key is used to encrypt the digital medium the license protects. The symmetric key can only be accessed if a user is authorized to read the content of the license. Access to the content of an XrML license is secured using public and private key technology.

12.2.3 RMS components

Microsoft’s RMS technology consists of the following components:

• A Microsoft server-side component: the MS RMS Enrollment and Activation Web Service. This component handles the enrollment and activation of trusted RMS servers, machines, and users. It is a web service hosted and managed by Microsoft.

• A customer server-side component: the the RMS server (code-named “Tungsten”). This component functions as a proxy server for the enrollment and activation of RMS servers, machines, and users. It also generates WRM certificates and licenses. In the future (2004) enterprises may have to option to add a secure server appliance to the RMS server setup: this appliance will handle the RMS activation of an organization’s RMS clients.

  The RMS server requires IIS 6.0 and thus only runs on top of Windows Server 2003. The RMS server engine and communication protocols are Web service–based: They make extensive use of SOAP, XML (and more particularly XrML), and SSL (HTTP over SSL) to secure the communication channels. The RMS server uses MS SQL Server 2000 with SP3 or the MS SQL Server 2000 Desktop Engine (MDSE) with SP3 to store the RMS configuration and usage policy information.

• A client-side component: This is a set of RMS dynamic link libraries (DLLs) and associated APIs. This component is downloadable via

Windows Update for legacy Windows platforms and will be made available in upcoming Service Packs (SPs) for MS OSs. In a first phase, Microsoft will support the following client platforms: Windows XP, Windows 2000 Service Pack 3 (and later), and Windows Server 2003.

• RMS-enabled applications: In order for an application to be capable of using RMS and enforce the RMS policies on the digital media with which it deals, the application must understand the RMS language. In other words, it must include extensions that allow it to talk to the RMS APIs and DLLs. All Office 2003 applications are RMS-enabled. Also, MS released an add-on to RMS-enable Internet Explorer (IE).^{[1 ]}Figure 12.7 shows how you can set RMS properties on a PowerPoint 2003 presentation.

  
  Figure 12.7: Setting RM on PowerPoint 2003 presentation.

  The IE add-on, for example, allows IE to interpret rightsprotected HTML files (files with *.rmh^[2] extensions) and enforce the rights inside IE. Figure 12.8 shows how the look of your IE toolbar changes when you have this add-on installed. Clicking the permissions button will bring up the RMS permissions that are linked to a particular *.rmh file.

  
  Figure 12.8: IE with RM add-on.

• An RMS server Software Development Kit (SDK): This SDK includes tools, documentation, and sample code to enable organizations to customize the RMS server.

• A RMS client SDK: This SDK includes tools, documentation, and sample code to enable organizations and software vendors to RMS- enable applications.

RMS has licensing requirements for each user or device that connects to an RMS server: it requires an RMS Client Access License (CAL).

12.2.4 RMS objects: About certificates, lockboxes, licenses, revocation lists, and exclusion lists

RMS deals with the following objects: certificates, lockboxes, licenses, revocation lists, and exclusion policies. All of them are structured using XrML syntax.

Just like the certificates that we know from the Public Key Infrastructure (PKI) world, XrML certificates are used to identify trusted WRM user and machine entities. Unlike PKI certificates, they do not use an X.509 format. One of the key differences with an X.509-based certificate is that XrML certificates can also be used to securely transport private keys (and not just public keys). This is one of the X.509 deficiencies that demonstrate X.509’s lack of flexibility and that explain why MS did not build on X.509 for its DRM solution.

Lockboxes are secured digital files (DLLs) that are used to securely store the private key of a RMS-enabled client machine and to provide a secure RMS execution environment on the client machine. Currently, all lock- boxes are generated by the central MS RMS Activation Service. In a future RMS release, MS may provide support for an enterprise-level lockbox generation server appliance. The latter will be secured using Microsoft’s Next Generation Secure Computing Base (NGSCB) technology (which was formerly known as Palladium).

Licenses are a special kind of certificate telling the users of digital data what can be done with the data, or, in other words, how they can consume the digital data. They are the most essential part of RMS: They reflect the persistent usage policies that are linked to digital data. RMS uses two types of licenses:

1. Publishing licenses: These are general licenses linked to digital media. They reflect the permissions as they were set by the author or the owner of the digital media. They can be generated by a RMS server or by a trusted machine possessing a Client Licensor Certificate (CLC) (explained later).

2. Use licenses: These are specific licenses linked to digital media. They reflect the permissions of one particular recipient or user of the digital medium. They can only be generated by an RMS server.

Revocation lists are—like certificates—very similar to the concept of a certificate revocation list (CRL) as we know it in the PKI world. It is a blacklist informing certificate users about bad certificates. A CRL tells the user of a certificate whether the certificate is still valid or still trustworthy. A certificate may end up on a CRL when its associated private key has been compromised. An exclusion policy is less restrictive than a revocation list: It only prevents entities from obtaining new licenses from a particular RMS server. Both revocation lists and exclusion policies are optional features— this is different from many PKI-enabled applications that require revocation checking.

Table 12.2 gives an overview of the concepts used in a RMS environment. The meaning of these different object types and their exact roles will become clearer in the following sections.

Table 12.2: WRM Objects

WRM Object Types	Goal
Machine Certificate	Identifies a trusted machine. Contains a unique public key for the machine. Is issued by a Microsoft-hosted RMS activation web service or by an enterprise level secure server applicance (the latter option will only be available in 2004) Is distributed together with a machine lockbox.
Lockbox	Provides secure storage of a trusted machine’s private key. Provides a secure RMS execution environment on a trusted machine. Consists of a set of DLLs that are stored on a trusted machine. Is issued by a Microsoft-hosted RMS activation web service or by an enterprise level secure server applicance (the latter option will only be available in 2004). Is distributed together with a machine certificate.
RM Account Certificate (RAC)	Identifies a trusted user entity. Contains a unique public-private key pair for the user. Its content is secured using a machine certificate. Is issued by a RMS server.
Client Licensor Certificate (CLC)	Identifies a trusted machine entity that is authorized to publish RMS-protected information offline (this means without contacting the RMS server). A machine possessing a CLC is referred to as an offline entity. Contains a unique public-private key pair for the user. Its content is secured using an RAC. Is issued by a RMS server
Publishing License	Defines the policy for obtaining a use license. Contains the symmetric key used to encrypt the RMS-protected information. Its content is secured using the public key of the RMS server or the offline user entity. Is issued by a RMS server or an offline user entity.
Use License	Grants a trusted entity the permission to consume RMS-protected information as defined in the publishing license. Contains the symmetric key used to encrypt the RMS-protected information. Its content is secured using the public key of the RMS server or the offline user entity. Is issued by a RMS server.
Revocation List	Names entities that are no longer trusted by the RMS system. On the list entities are identified using their RMS public key.
Exclusion Policy	Prevents entities from obtaining new licenses from a particular RMS server. Does not define an entity as “untrusted” (unlike a revocation list). Exclusion can be based on a user ID, RAC, or lockbox version.

12.2.5 RMS information flow

Now that we have learned about the basic RMS concepts and components, let’s look at how RMS information flows in a typical DRM usage example. The example in Figure 12.9 shows how an author can provide persistent protection for a document that he or she authored. This means that the author wants to make sure that only the intended recipient(s) can read the document, can forward it to other people, can print it, and so on. Note that RMS supports recipients that are outside of the organization (external) as well as recipients within the organization (internal).

Figure 12.9: WRM information flow.

In this example we need the following from a RMS component point of view:

• A corporate RMS server

• This RMS server will need to communicate with the MS RMS Enrollment and Activation web services (not shown in Figure 12.9).

• A set of clients that have the RMS APIs and DLLs installed (distributed via Windows Update or a Service Pack)

• Every client must have a RMS-enabled application: In this example we would need a RMS-enabled Word application that is capable of adding RMS data to documents and enforcing RMS restrictions on documents.

A WRM-secured document exchange would include the following information exchanges between the different components:

1. The author creates a document using a RMS-enabled application (e.g., MS Word 2003) and adds a set of document usage rights and conditions. To identify recipients, the author can use the recipients’ AD or MS Passport accounts. An interesting detail is that Passport accounts are not trusted by default.^[3]

2. The RMS-enabled application generates a symmetric encryption key to secure the document’s content and sends it together with the usage rights and conditions to the RMS server. The latter message also contains a publishing license request.

3. The RMS server generates a publishing license: It encrypts the symmetric key with its public key. It then returns the publishing license to the RMS-enabled application.

4. The RMS-enabled application encrypts the document with the symmetric key and links the publishing license to the document.

5. The author distributes the RMS-secured document to a recipient, who receives the document and opens it using a RMS-enabled application (e.g., MS Word 2003).

6. The RMS-enabled application sends a request for a use license to the RMS server. This use license request includes the publishing license and the recipient’s RMS Account Certificate (RAC). The latter is used to authenticate the recipient to the RMS server.

7. The RMS server checks the recipient’s identity, validates that the recipient is authorized to read the file, and creates a use license. During this process the RMS server extracts the symmetric encryption key from the publishing license (using its private key) and reencrypts it using the recipient’s public key (extracted from the recipient’s RAC). The RMS server then returns the use license to the recipient’s computer.

8. The RMS-enabled application renders the RMS-secured document and enforces the usage restrictions.

This example shows an online RMS information flow where the RMS client communicates in real time with a RMS server. RMS can also work in offline mode—at least to generate publishing licenses.

The offline operation mode is possible if the client’s computer has been issued a Client Licensor Certificate (CLC) by the RMS server. In that case the client’s computer will be capable of generating the publishing license. In this case the symmetric encryption key is stored twice in the publishing license: once encrypted with the RMS server’s public key, and once encrypted with the public key held in the CLC. When the recipient gets the publishing license, it will use it to request a use license to the RMS server that issued the CLC certificate (the publishing license issued by a CLC includes a URL pointing to its issuing RMS server). Note that working in offline mode only works for generating publishing licenses: Generating use licenses requires an online RMS server.

12.2.6 RMS setup and enrollment

RMS setup and enrollment differ for the different RMS components. Table12.3 gives an overview of the enrollment procedures. Two important setup details are the following:

Table 12.3: RMS Enrollment Procedures

WRM Entity	Enrollment Procedure
First RMS server	Contacts the MS RMS Enrollment web service for a RMS licensor certificate. Outcome of this enrollment process is a RMS licensor certificate.
Subsequent RMS servers	Takes existing configuration from first customer RMS server. Does not need to contact the MS RMS Enrollment web server.
Client computers	Gets RMS code (APIs and DLLs) via Windows Update or Service Pack. Contacts local RMS server for enrollment and activation. The local RMS server contacts the MS RMS Activation web service for client activation or, if an enterprise secure activation appliance is available, contacts the appliance (remember, the latter option will only be available in 2004). Outcome of this enrollment process is a RMS Machine Certificate.
Users	Requires availability of an activated RMS client computer. Talks to local RMS server for enrollment. Outcome of this enrollment process is a RMS Account Certificate (RAC).
Client computers authorized for offline publishing	Talks to local RMS server for enrollment. Outcome of this enrollment process is Client Licensor Certificate (CLC).

1. The setup of the first RMS Server for an organization requires communication with MS RMS Enrollment Service—which is a secure Web service Microsoft that makes available on the Inter- net. Subsequent enterprise RMS servers are configured based on the first RMS server’s configuration information. Their installation does not require additional communication with the MS Enrollment web service.

2. The setup of any RMS enabled client computer requires communication with the MS RMS Activation web service or with the enterprise-level secure activation appliance. Remember that the latter option will only be available in 2004.

Microsoft claims that during the enrollment and activation processes no information is persisted on the MS RMS servers. Also, the cryptographic keys involved in these exchanges are not used in subsequent licensing operations. In other words, if MS can never decrypt information protected by an organization’s RMS setup.

^{[1 ]}Minimum supported IE version is IE 5.5.

^[2]rmh stands for rights-managed HTML.

^[3]The accounts that are considered trustworthy in an RMS setup are configured on the RMS server. RMS also allows you to create RMS federations with other RMS installations or MS Passport.