Protecting Audio and Video Content with Digital Rights Management

 

Jim Skinner
Microsoft Corporation

April 2004

 

Applies to:
   Microsoft® Windows Media® Rights Manager

 

Summary: You can use the Microsoft Windows Media Rights Manager Software Development Kit (SDK) to protect audio and video content served by your Web site. This walkthrough describes the process of protecting content by adding a digital rights management (DRM) sample application that uses the Windows Media Rights Manager SDK.

Contents

Introduction
The DRM Sample Application Overview
The DRM Sample Application Architecture
Database Objects Added to the Web Site Data Tier
Credential Generation and Management
The Content Encryption Process
DRM Metadata Management
Content License Management
Further Considerations
For More Information

Introduction

This paper describes the process of integrating a digital rights management (DRM) sample application based on the Microsoft® Windows Media® Rights Manager SDK into your Web site. This paper is aimed at Web developers who would benefit by adding content protection to existing Web sites.

To request the DRM sample application described in this article, send an e-mail message to wmla@microsoft.com. You must license the Windows Media Rights Manager SDK in order to use this sample application.

The DRM Sample Application Overview

There is the potential for security problems any time an organization places unprotected content on its Web site. As soon as the content is downloaded by a site visitor, it can be repurposed in any number of ways (none of which can be controlled by the original content owner). Additionally, once the URL of the content is revealed, other sites can deep link to the content. Sites that deep link to content may masquerade as the content provider while actually providing nothing more than a link to the content. If another site uses deep linking, it takes control of both the content and the bandwidth required to serve the content from the original Web site.

This type of security problem can be resolved by implementing the accompanying DRM sample application, which utilizes the interfaces, functions, and methods exposed by the Windows Media Rights Manager SDK. The DRM sample application can be added to a Web site to provide a layer of security without adding much complexity. The DRM sample application includes the following components:

  • DRM sample application database. A database that stores credentials associated with the protection process.
  • Four administration Web pages. Pages that enable you to perform administrative tasks, such as creating credential sets and encrypting content.
  • A pre-licensing Web page. A page to which your Web site redirects users during the pre-licensing process.
  • A post-licensing Web page. A page to which users are automatically sent by Microsoft® Windows Media® Player during the post-licensing process.
  • Tables and procedures. Tables and stored procedures that must be added to your Web site's database. The tables you add to your Web site can store and manage the content licenses generated by your Web site.

Although the DRM sample application runs under the Microsoft .NET Framework, your Web site only needs to redirect users to an .aspx page in order to license content. This redirection enables you to use the application to protect the content on your Web site without having to migrate your Web site to the .NET Framework.

The DRM Sample Application Architecture

There are two elements that make up the DRM sample application architecture:

  • The DRM Web site and database
  • The database objects added to your Web site's data tier

The design of each architectural element is described in the following section.

The DRM Web Site and Database

The DRM Web site and database require the following minimum software configuration:

  • Microsoft SQL Server 2000
  • Windows Media Rights Manager SDK version 7.1
  • Microsoft Internet Information Services (IIS) version 5.0 or later
  • Microsoft .NET Framework

You can use either a single server to meet this requirement or use separate database and Web servers. For even greater scalability, you can employ two instances of the DRM Web site and two instances of the database server. This implementation would require four servers.

Possible implementation of a single DRM site

Figure 1. Possible implementation of a DRM Web site and database

A single DRM Web site and database can meet the DRM sample application requirements; however, two DRM Web site and two database instances are recommended. When you use two DRM Web sites and two database instances, one should be located inside your organization's internal network (to encrypt content), and one should be located in the public-facing network (to service licensing requests). When two instances are employed, the database associated with the public-facing site should be a copy of the database associated with the internal network site.

Possible implementation of two DRM sites

Figure 2. Possible implementation of two DRM Web sites and databases

This architecture is due to the fact that database changes are only made during the credential creation and file encryption processes. Thus the database associated with encryption (the internal site) is the source for all data in a two-site implementation. In the two-site implementation, the database associated with licensing (the public-facing site) should be frequently refreshed in order to match the database associated with encryption.

Functionality

Before you can protect content files, you must create a "warehouse" of protection credentials. These credentials are used during the protection process and are stored in the DRM sample application database by using the SeedGenerator.aspx page. To protect a single content file, the following credentials are required:

  • Content identifier (CID). The CID is a unique number that identifies the encrypted content file. The DRM sample application ensures that a unique CID is generated for each piece of content; the Windows Media Rights Manager SDK itself does not enforce this uniqueness. The CID is ultimately encoded into the content header and is later retrieved during the license process in order to identify the file.
  • Seed and key ID. A two-part key is used to encrypt the content file. This key is a combination of a secret, cryptographically secure value known as the seed (or license key seed) and another value known as the key ID. The key ID is encoded into the content header and is later retrieved during the license process to recreate the full key. Although the seed and the key ID are stored in the credential warehouse, the full key itself is not. The Windows Media Rights Manager SDK must generate the full key when it is required.
  • Public key and private key. In addition to encrypting the content file, the Windows Media Rights Manager SDK signs the encrypted file to create an additional layer of security. The encrypted file is signed with a pair of signing keys that are referred to as the public and private keys. The public key is the signing key that is publicly available and is submitted to the signing authority (in this case, the DRM sample application) during the licensing process. The private key is known only to the signing authority (the DRM sample application). The private key is used to check the signed file at the time of licensing to determine if the file was tampered with prior to the licensing process.  

The credentials in the previous list are referred to collectively as a key set. Each encrypted content file has a single key set associated with it. Key sets should not be reused; therefore, the credential warehouse must have enough key sets for all of the content files that need to be encrypted.

In addition to the encryption and signing keys listed in the previous section, the following two values must also be stored in the credential warehouse for each encrypted content file. The following configuration values do not impact the encryption process in any way; they are simply elements of the DRM process that need to be managed. 

  • Individualization. The individualization value determines the level of individualization used to protect the content and is set at the time of encryption. Individualization is the process of making the DRM component in each consumer's Windows Media Player unique. This process is also known as obtaining a security upgrade. You may require consumers to have a certain security upgrade in order to play your content. You can enforce this requirement by setting the individualization level to the value associated with the required security upgrade. Windows Media Player automatically enforces the individualization level you set. When a user attempts to play content that has an associated individualization level in Windows Media Player, the Player requires that the user install the security upgrade before it attempts to play the file.
  • Seed domain. The seed domain is the value of a domain in which a number of credential sets are grouped. For example, you might receive content from two major suppliers: Producer A and Producer B. You could create one group of credential sets for the seed domain "ProducerA" and another group of credential sets for the seed domain "ProducerB." By maintaining two different seed domains, you can alter the way all the content within a single seed domain is handled without affecting the content within the other seed domain.

The values listed previously (the key set and the configuration values) make up the complete set of protection credentials stored in the DRM sample application database. The SeedManager.aspx page populates the DRM sample application database (or "credential warehouse") with the protection credential sets. The SeedManager.aspx page creates credential sets with a single button click and can add any number of protection credential sets to the credential warehouse. As additional credential sets are required, you can use the SeedManager.aspx page to add more credential sets to the credential warehouse.

One reason why protection credentials must be created in advance is the need to support a child encryption environment (also referred to as a "partner" encryption environment). The child encryption environment enables content providers and other partners to encrypt content themselves, without having to access the parent Web site. The next section describes how the first element of this child encryption environment (the partner credential file) is created.

Creation of Partner Credential Files

The Windows Media Rights Manager SDK presupposes that you have local access to the content files you wish to encrypt. However, many content providers and partners are hesitant to provide unencrypted content files to a Webmaster. Often partners would prefer to encrypt their content themselves. There is an offline version of the DRM sample application available so that partners can encrypt content themselves and then ship the encrypted content to be hosted on your Web site. The first element required by the offline version of the DRM sample application is the partner credential file.

The partner credential file is created by using the FileGenerator.aspx page. The file that is generated by this page contains a number of credential sets that were exported from the primary DRM sample application database. This file acts as an offline database. By using this partner credential file (and the application elements required to support the PartnerPackager.aspx page), partners can encrypt content at their locations without having to use the primary DRM sample application.

Encryption of Local Content

The process for encrypting local content is identical to the process documented in the Windows Media Rights Manager SDK (that is, a Web form is opened, content is selected, and encryption is performed). The Packager.aspx page performs the encryption of local content.

The Packager.aspx page provides two enhancements to the basic encryption process. The enhancements involve the retrieval of encryption credentials from the credential warehouse (by the seed domain) and the output of an Extensible Markup Language (XML) file containing DRM metadata. These enhancements make it possible to manage credential sets and to associate DRM metadata with an encrypted file as it is distributed.

Note   Although the Packager.aspx page could potentially locate files on a network drive and encrypt them, there is a performance issue associated with encrypting remote content files. It is recommended that files that undergo the encryption process reside on one of the local drives of the IIS server.

Encryption of Partner Content

In the offsite encryption scenario described previously, your Web site creates and manages the credential sets, but an external content provider performs the actual encryption of the content. The partner credential file and the PartnerPackager.aspx page work together to support this scenario. The PartnerPackager.aspx page encrypts content files by using the partner credential file, which enables the partner to encrypt content using credential sets from the DRM sample application database without actually being connected to the database.

Aside from the use of the partner credential file, the PartnerPackager.aspx page is functionally identical to the Packager.aspx page. The PartnerPackager.aspx page relies on the Windows Media Rights Manager SDK and.NET Framework. Thus the partner site must have a server that meets the DRM sample application system requirements and must also install the DRM sample application, with the exception of the database.

Pre-Licensing

In order to play back protected content, an end user must first acquire a license that dictates the terms of the playback experience. Once you integrate the DRM sample application into your Web site, your site will act as the licensing authority. Your site indicates which users should receive licenses, and the DRM sample application delivers the actual license to the user's computer.

The DRM sample application offers two ways to deliver a license to an end user. Licenses can either be delivered prior to playback (during a Web site visit) or be delivered when the end user attempts to play the content (through a challenge form generated by Windows Media Player). When a license is delivered prior to content playback, the process is referred to as pre-licensing. Pre-licensing can take place at any time during the end user's Web site visit. In order to deliver the license through pre-licensing, you simply need to know which content file the user wishes to access and the type of license the user requires.

When it is time to predeliver the content license, the Web site redirects the user to the PreLicenser.aspx page (found in the DRM sample application virtual directory). This page delivers a license to the end user's license store (a client-side storage system associated with Windows Media Player). After license delivery, the PreLicenser.aspx page redirects the user back to your Web site.

Since you are able to define the page to which the PreLicenser.aspx page redirects end users, it is possible that you can send end users back to the page they viewed immediately before the license was issued. And because the entire licensing process takes only a moment, it is possible that end users will not know that they left your Web site at all. In this way, you can integrate the pre-licensing process seamlessly with your Web site operations. (Sample code supporting this program flow can be found in the sample video-on-demand site provided with the DRM sample application.) 

There are a few content- and user-specific values that must be retrieved from the Web site database before a redirection to the PreLicenser.aspx page can take place. The values that must be retrieved from your Web site database are as follows:

  • Content identifier (CID). This value is generated when the content is initially encrypted. This value acts as a unique identifier for the encrypted content file. The DRM sample application uses this value to identify which credential set is associated with the encrypted content file. An XML file that contains this value, also known as the DRM metadata file, is created at the time of encryption. You must create a process for importing the CID value into your Web site so the value can be retrieved at the time of licensing. It is recommended that the CID value be stored in the table that identifies the content found on your site (since each piece of encrypted content has a single CID associated with it). This table is often referred to as the product catalog. 
  • SKU. This is an optional value that can be used to properly redirect users after the pre-licensing process is complete. The SKU can be a Web site-specific value that identifies the encrypted content (that is, the SKU from the product catalog), or it can be a value that identifies the page the user viewed prior to pre-licensing. When the end user is redirected back to your Web site after pre-licensing is complete, the site is passed this SKU value in a query string variable associated with the URL request. You must create a process for your Web site to identify this query string variable and properly redirect the user based on the value. If you want all users to be redirected to the same page after pre-licensing and not to the page they last viewed, you do not need to use this value.
  • Account identifier. This is an identifying value your Web site associates with the end user's personal account (if one exists). This value is used during the pre-licensing process to determine the authenticity of the licensing request (a call is made to your site to determine whether the user should receive a license). If your site has no way to identify users, you can use a default value instead; however, you must also make a modification to the stored procedure that performs the security check.
  • Account sub-identifier (or PIN). This is a second identifying value your Web site associates with the end user's personal account. This value can represent a child account related to primary account identifier. The account sub-identifier value is used during the pre-licensing process to determine the authenticity of the licensing request (a call is made to your site to determine whether the user should receive a license). If your site has no way to identify users, you can use a default value instead; however, you must also make a modification to the stored procedure that performs the security check.
  • Rights. There are two types of rights that can be associated with a license: predetermined and custom. With predetermined rights, both the Web site and the DRM sample application refer to a specific set of rights using a single integer. The rights associated with the listed values are as follows.

    Value Rights Definition
    1 Content never expires
    2 Content expires 2 days after first viewing or after 1 month
    3 Content expires 2 days after first viewing or after 1 week
    4 Content expires 2 days after first viewing or after 2 weeks
    5 Content expires 2 days after first viewing or after 3 weeks

    The DRM sample application licensing pages can be easily changed to use a different set of rights for the listed values. Each right set listed in the previous table has an associated code block in the DRM sample application pages PreLicenser.aspx.vb and Licenser.aspx.vb (the page that adds the rights set to the license). You can modify the code blocks in these pages to support the predetermined rights sets that you want to use. Note that you can easily create and employ a set of predetermined rights, thereby removing the human error associated with custom rights from the licensing process.

Note   The rights set code blocks within the DRM sample application are configured to provide rights sets that require Windows Media Player version 7.1 or later. If you would like users with an older version of Windows Media Player to be able to view your content, you will need to modify these code blocks.

If the rights value is set to 0, a custom set of rights is specified in the licensing request. When a custom set of rights is specified, the following additional request values are examined in order to determine the exact set of rights that is required:

  • RightsExp. This value is part of the custom rights set. It denotes the expiration date of the content (in days).
  • RightsExpAfterUse. This value is part of the custom rights set. It denotes the expiration date of the content after the first playback attempt (in hours).
  • RightsPlay. This value is part of the custom rights set. It denotes the number of times the content can be played before it expires. 
  • RightsBackup. This value is part of the custom rights set. It determines whether the end user can back up the license. The possible values are as follows.

    Value Definition
    0 License cannot be backed up (recommended)
    1 License can be backed up (not recommended)

Once the pre-licensing values have been retrieved from the Web site database, a licensing request can be sent to the PreLicenser.aspx page. At this point, the licensing request is simply a redirection to the PreLicenser.aspx page with the pre-licensing values provided through a form submission associated with the page request.

An extremely simple version of the pre-licensing process is as follows:

  1. The end user selects the content he or she would like to play.
  2. The Web site first retrieves the user and content values to be associated with the license and then calls sp_testandinsertprelicense to insert the license values in the license tables. Sample license values are as follows:

    cid=1

    sku=1

    acct=1

    pin=1

    rights=2

    rightsexp=(not required)

    rightsexpafteruse=(not required)

    rightsplay=(not required)

    rightsbackup=(not required)

  3. The Web site provides the license values to a page in the DRM virtual directory (PreLicense.aspx) using query string variables: 
    prelicense.aspx?cid=1&sku=1&acct=1&pin=1&rights=2&rightsexp=
&rightsexpafteruse=&rightsplay=&rightsbackup=
  4. The page inserts the query string values in a form, uses a client-side control to insert additional client information in the form, and then submits the form to the actual licensing page (PreLicenser.aspx).
  5. The PreLicenser.aspx page completes the licensing process and then redirects the user back to your Web site (calling a URL defined in the application's Web.config file).
  6. The Web site receives the URL request and uses the SKU query string variable value to determine which page to display.
  7. The end user sees the proper page of your Web site. He or she can play back the content, download the content, or continue browsing your site.

Note   The PreLicense.aspx page is included in the DRM sample application code. It uses query string variables so you can see the values that are passed between pages. This is a useful operational mode for development, but not for production. These values should not be visible to the end user when this application is put into use. If you can avoid using the PreLicense.aspx page (and instead employ the client-side control, determine the pre-licensing values, and submit everything as form values to the PreLicenser.aspx page through your Web site code), you can avoid passing all the pre-licensing values as query string variable values. By adding these work units to your Web site and bypassing the PreLicense.aspx page altogether, you remove the security vulnerability that is in the sample application code.

The sample video on demand site that accompanies the DRM sample application details the way in which the use of the PreLicense.aspx page can be avoided.

Post-Licensing

The DRM sample application is intended to enhance the security of your Web site without requiring you to make major changes to your site. There is one licensing scenario in which Web site changes may be avoided altogether by making use of the tight integration between Windows Media Player and the Windows Media Rights Manager SDK. It is possible for Windows Media Player to license the content at the time of initial playback in a process called post-licensing.

In this scenario, a small browser window opens when the user attempts to play a content file or view a content stream. The page displayed in this browser is hosted by the Content Protection server. The page asks the user if he would like to purchase a license for the file he is attempting to play. If the user provides the correct site credentials (such as a login ID), the page downloads the license to the user's License Store. After closing the browser by clicking a Play button that appears after a successful licensing attempt, the user continues with the normal playback experience. If the licensing attempt is not successful, the user is unable to play back the content. 

Database Objects Added to the Web Site Data Tier

Your Web site must use a SQL Server 2000 database to store user account data and data related to encrypted content files. The IIS server on which the DRM sample application virtual directory is located must be able to access this database.

The DRM sample application requires that your Web site's database respond to authentication requests made during the pre-licensing and post-licensing processes. So your Web site can support these calls, you must add a number of tables and stored procedures to your site. The tables that you must add to your site are as follows:

  • DRMlicensecurrent. This table is used for pre-licensing and post-licensing lookups. This table contains the CIDs that have been licensed by each end user.
  • DRMpostlicensecount. This table is used for fraud detection. This table contains the number of post-license requests for each subscriber for the month. (This table must be cleared out every month using the stored procedure provided with the application.)
  • DRMconfig. This table contains a configuration value used for fraud detection. The configuration value sets the number of post-licensing attempts a single account can make before the account is shut off.
  • DRMlicensehistorical. This table is used for pre-licensing and post-licensing lookups. This table contains all available information about the licenses that have been distributed. It lists CIDs that have been licensed by each end user along with the type of license and the expiration date.
  • DRMlicensehistorical_archive. This table is used for the storage of DRMlicensehistorical records after billing has taken place (or after a given time period if no billing is required). Records should be moved here by using the stored procedure sp_archive_drmlicensehistorical.
  • DRMrightsreference. This table contains a description of each predetermined rights value. This table is included for reference purposes only.

The stored procedures that you must add to your site are as follows:

  • sp_getcurrentlicenseexp. This stored procedure is included for test purposes only. It enables a developer to determine if an end user currently has a license for a given piece of content.
  • sp_testandinsertprelicense. This stored procedure must be called during the pre-licensing process (by your Web site). It inserts the license values into the license tables. This is the only stored procedure your Web site code must call during pre-licensing. An example of this call can be found in the sample video on demand site.
  • sp_checkDRMlicense. This stored procedure is called by the DRM sample application during the pre-licensing process. The DRM sample application uses this stored procedure to determine whether the user requesting a license is authorized to receive one.  
  • sp_attemptpostlicense. This stored procedure is the first stored procedure called by the DRM sample application during the post-licensing process. This stored procedure attempts to verify end user account data. At present this stored procedure checks the UserObject table (a standard Microsoft Commerce Server table) to determine whether the end user provided valid account data. You must modify this stored procedure to check the user account table in your Web site database instead. This stored procedure presupposes that the end user provided an account name, sub-account name, and password at the post-licensing challenge and that a corresponding account identifier can be found in the UserObject table. This stored procedure also calls sp_checkpostlicensecountout.
  • sp_checkpostlicensecountout. This stored procedure is called by sp_attemptpostlicense during the post-licensing process.
  • sp_attemptratingcheck. This stored procedure is the last stored procedure called by the DRM sample application during the post-licensing process. This stored procedure presupposes that the end user's content rating preference is located in the u_pref9_contentrating column of the UserObject table. This stored procedure also presupposes that information about the encrypted content file is located in the columns SiteContentRating, SiteRights, SiteRightsBackUp, SiteRightsExp, SiteRightsExpAfterUse, SiteRightsPlay, and SecurityCID of the VODCatalog_CatalogProducts table. You must modify this stored procedure to check the actual user account and product catalog tables in your Web site database instead. This stored procedure also calls sp_insertpostlicense. 
  • sp_insertpostlicense. This stored procedure is called by sp_attemptratingcheck during post-licensing.
  • sp_deleteexpiredcurrentlicense. This stored procedure deletes records that are more than 24 hours old. You should schedule this stored procedure to run each night.
  • sp_resetDRMpostlicensecount. This stored procedure resets all post-licensing counters back to 0. You should run this stored procedure once a month.
  • sp_archive_drmlicensehistorical. This stored procedure moves records from the DRMlicensehistorical table to the archive. You should run this stored procedure after all records in the DRMlicensehistorical table have been processed for billing.

Credential Generation and Management

The first step of the content protection process is the generation of credential sets. A single credential set is read at the time of encryption and each time a license request is received for the content with which that credential set is associated. Therefore, the management of credential sets is an ongoing process.

The primary management task that must be performed when credential sets are created is the creation of seed domains. Seed domains provide a way to group credential sets so they can be managed as a whole. Seed domains are created at the same time that credential sets are created and are nothing more than an additional attribute of a credential set.

The SeedGenerator.aspx page generates credential sets and populates the DRM sample application database with credential key sets. To use the SeedGenerator.aspx page, first decide which seed domain requires the credential key sets and the number of key sets you need. If you do not plan to manage groups of key sets, you can simply use one seed domain for all the key sets you create. You should use more than one seed domain if you are administering multiple Web sites that are using the DRM system or if you have multiple partners that are using the key sets. To create key sets for more than one seed domain, fill out the SeedGenerator.aspx page and click the Create Seeds button for each seed domain you need (changing the value in the Seed domain field each time). Each time you click the Create Seeds button, you create additional keys for the designated seed domain. You should clear the LOW SECURITY check box unless you want to be able to revoke all content by using a single revocation key. This setting makes it easier to revoke numerous content files at once, but it also decreases the security applied to each individual file because all the files are signed with the same signing key set.

Seed generator

Figure 3. The SeedGenerator.aspx page

The FileGenerator.aspx page is used to populate a flat file with credential sets.

FileGenerator.aspx is intended for use with the partner business model. This page is used by the Partner Packager page to create a file that contains a number of key sets taken from the DRM sample application database. The Partner Packager page then uses this file in place of the DRM sample application database. You must provide partners with this file, the Partner Packager Web site, and another file called Counter.txt to enable them to protect content themselves.

File generator

Figure 4. The FileGenerator.aspx page

The Content Encryption Process

The Packager.aspx page performs content encryption.

Packager.aspx retrieves a set of keys from the DRM sample application database and then uses those keys to encrypt a content file. This page searches the IIS server for content files, so you must move content files to the IIS server before encryption begins. This page creates the encrypted output file on the IIS server as well. The Packager.aspx page uses the individualization value contained within the DRM sample application's Web.config file. If you want to change the individualization value, you must edit the Web.config file.

Packager

Figure 5. The Packager.aspx page

The PartnerPackager.aspx page is used to perform offline content encryption.

PartnerPackager.aspx should be used only when a partner wants to encrypt files at a remote location. This page encrypts a content file by using a key set taken from a partner seed file, which must first be generated by the FileGenerator.aspx page on your DRM sample application server. Next, the partner must configure a DRM sample application server that has the Windows Media Rights Manager SDK installed, but does not have the DRM sample application database component. This remote server must also have the partner seed file generated by FileGenerator.aspx. Finally the remote server's Web.config file (located in the DRM sample application virtual directory) must be edited to include the name and location of the partner seed file and the counter file (which is included in the DRM sample application code and is only used during partner encryption). When this server configuration is completed, the PartnerPackager.aspx page on the remote server enables the partner to encrypt content files by using key sets for which your Web site acts as the licensing authority.

Partner packager

Figure 6. The PartnerPackager.aspx page

DRM Metadata Management

One of the products of the encryption process is an XML file that contains the credential set used to encrypt the content file. Since this XML file describes the DRM values used to perform the encryption, the file is commonly referred to as DRM metadata. This file should be submitted to your Web site at the same time the content is submitted. Your Web site should have some sort of system to import the DRM metadata found in this file. The file has a file name extension of .drm and is located in the same directory as the encrypted content file.

Note   At present the entire credential set is stored in the XML file. However, the only value that actually needs to be imported into your Web site is the CID value. You should determine which credentials you want to store in your Web site and then modify the Packager.aspx page to include only those credentials in the XML file. You may also want to implement file-level encryption on the XML file so that the credentials are encrypted and not in plain text.

The schema of this file is as follows:

  • MediaProfile. The MediaProfile dataset (DS) is a parent DS that has only one attribute, language. This attribute describes the language of the text in the child DS. At present the DRM sample application only produces .drm files with language attribute value of English.
  • MediaSecurity. This DS describes the DRM elements associated with the media instance. A naming convention dictates that the file containing the MediaSecurity DS use a .drm file name extension, that the source content use its original file name extension, and that any additional metadata files use an .xml file name extension. The naming convention further dictates that the same name precede each file name extension. For example, the full set of files associated with MyMovie.wmv would be: MyMovie.wmv, MyMovie.drm, and MyMovie.xml (if metadata for MyMovie.wmv previously existed). The MyMovie.drm and MyMovie.xml files could be merged into a single, complete MyMovie.xml file after the encryption process is complete (but before importation).
  • MediaIdentification. This is an identifier of the media instance and is the relative name of the file in most cases (for example, MyMovie.wmv).
  • Seed. This is the secret part of the two-part key used to encrypt the instance (for example, NXz4NVGzP1FiCUCLzzO0uU67eGNnupu21KuG5PcQ).
  • SeedDomain. This is the grouping to which the key set belongs.
  • CID. This is the content identifier, which is tied to the seed domain. This identifier is a numeric value (for example, 21).
  • PrivateKey. This is the private key used to sign the instance (for example. lqytDmYYTwwR!kDD5Vbwi*jpNDU=).
  • PublicKey. This is the public key used to sign the instance (for example, V!aO2f4iq*0LIfFMJrZEkmb5pR23DmHPUZ8o3GdUtW9*oqhwloiCVw==).
  • SecuritySiteURL. This is the site to which playback requests are automatically directed by Windows Media Player after all licenses for the instance have expired.
  • IndividualizationVersion. This value is the level of the individualization DLL that the Player must have installed in order to play the file (for example, 2.2).  

A sample of this schema is as follows:

<?xml version="1.0" encoding="iso-8859-1"?>
<mediaprofile language="english">
<mediasecurity mediaidentification="MyMovie.wmv" 
seed="NXz4NVGzP1FiCUCLzzO0uU67eGNnupu21KuG5PcQ" seeddomain="MYDRM" 
cid="21" privatekey="lqytDmYYTwwR!kDD5Vbwi*jpNDU=" 
publickey="V!aO2f4iq*0LIfFMJrZEkmb5pR23DmHPUZ8o3GdUtW9*oqhwloiCVw==" 
securitysiteurl="http://web1/drm/simple.asp" 
individualizationversion="2.2"/>
</mediaprofile>

Content License Management

When you implement a content protection system, your Web site must be able to manage the content licenses that are generated during the content protection process. As licenses are generated, additional rows are created in the DRMlicensecurrent and DRMlicensehistorical tables. In addition, as post-licensing requests are granted, the counters in the DRMpostlicensecount table are incremented. Proper management of these tables is extremely important. If any data in these tables is improperly deleted, all licensing requests associated with the deleted rows will be denied.

The recommended management regimen for the content license tables is as follows:

  • DRMlicensecurrent. This table lists all current licenses an end user has for a given content identifier (CID). Once a license in this table has expired it is no longer useful. Thus you should delete expired records on a regular basis by running the stored procedure sp_deleteexpiredcurrentlicense. This stored procedure deletes records that expired at least 24 hours before the procedure runs. It is recommended that you schedule this stored procedure to run each night.
  • DRMlicensehistorical. This table contains all license information for an extended period of time. Any billing process you use should retrieve license information from this table. You can move license information from this table after the license has expired and billing has been completed. The records that have expired and have been billed should be archived using the stored procedure sp_archive_drmlicensehistorical. This stored procedure moves records from the DRMlicensehistorical table to the DRMlicensehistorical_archive table. You should run this stored procedure after each billing cycle.
  • DRMpostlicensecount. This table contains the total number of post-licensing requests for each end user. The DRMconfig table contains a threshold value for the number of end user requests; once this limit is reached, post-licensing is no longer allowed. After you are able to identify how often attempts are made to improperly access the system, you can set a usable threshold value. Until you are able to determine these values for your site, it is recommended that your threshold value be equal to 1000 pieces of content a month (since license requests greater than 1000 per month are usually not coming from a single user). To reset the count associated with each user, you must run the stored procedure sp_resetDRMpostlicensecount. This stored procedure sets all post-licensing counts back to 0 by removing all the rows from the DRMpostlicensecount table. Before running this stored procedure, you should view the post-licensing count of the users who have the highest count values. If there is an obvious difference between heavy users and normal users, you might want to set your threshold accordingly. 

Your organization should make decisions about license management prior to the implementation of the DRM sample application. For example, your organization should decide how to handle multiple playback requests for the same file from the same user during a single license period. In this scenario, you need to determine which playback requests are billable after the first request.

For example, End User A has a computer in his living room and a computer in his bedroom. He purchases a seven-day license to view a streaming movie, receives the license, and then watches the streaming movie in his living room. The next day he attempts to watch the streaming movie in his bedroom. Your organization should decide whether End User A should be granted that license and whether he should be charged for it.

End User B has a single computer. He purchases a seven-day license to view a streaming movie, but when he is redirected to the licensing page, a network outage prevents him from receiving his license. He returns to your Web site the following day to watch the streaming movie. Your organization should decide whether End User B should be given a license the second time he attempts to watch the movie and whether he should be charged.

In these examples, both end users have a pretty good case for receiving a second license for the content without having to pay for the license again. To make the viewing experience pleasant, your organization might consider automatically providing the second license, allowing users like End User B to overcome any prior licensing problem. Automatically granting streaming licenses to currently licensed customers will most likely cut down on the support calls you receive.

At present, the DRM sample application stored procedure that records pre-licenses (sp_testandinsertprelicense) presupposes that a content file that is repeatedly pre-licensed by a single end user can be played back throughout the duration of the original license period at no extra cost. That is to say that if you provide a 30-day license for a streamed content file to an end user and that end user visits your Web site multiple times during those 30 days, he can access the content without incurring additional costs and there is only one licensing record inserted into the table. If you want the site to insert licensing records for every pre-licensing request, regardless of whether the end user has a current license or not, you will need to modify sp_testandinsertprelicense.

It is assumed that content files that have been downloaded (files that include a license acquisition URL and can be post-licensed by typing in the correct user account information) are frequently the target of illegal access attempts. A low-tech illegal access attempt could be to steal someone's account information and post both the downloaded file and the user name and password combination on a file-sharing network. To prevent this kind of illegal access, each attempt to post-license a file during an existing licensing period is considered a request for a new license, and each request adds a new license record to the licensing tables. The victim should notice the additional charges that are incurred as a result of this abuse and should then notify your organization of the theft. In addition to this safeguard, your site can turn off an account after a certain number of post-licensing requests have been granted.

To help guide you in your license management decisions, you should keep in mind that files that are streamed from your site are completely under your control. You can err on the side of good customer service and liberally distribute licenses for your streaming files, because you can ensure that you are providing licenses to the correct end user. In addition, the end user must use your Web site to access the files.

Another reason you may want to hand out licenses with each streaming request and not charge for multiple requests per user is that it is difficult to determine who has a license and who does not (when it comes to pre-licensing). The DRM sample application adds an error message to the query string value in the return URL when the licensing process fails, but there is no efficient way to match all error messages to all licensing requests. The amount of work required to track the status of all licenses far outweighs the benefits. To alleviate customer complaints, it is recommended that playback requests handled by your site receive a licensing redirection even if a current license exists.

Further Considerations

You must use a server that meets the DRM sample application system requirements. This server must have IIS, SQL Server 2000, and the Windows Media Rights Manager SDK installed. It is a good idea to read the documentation that accompanies the Windows Media Rights Manager SDK in order to familiarize yourself with the encryption process. Once the server meets the system requirements, run the DRM_Sample_Application.exe file on your server. This copies the application files to your server. Next, follow the installation instructions found in the DRM Sample Application Detailed Design.doc file, found in the target directory.

Note   The DRM sample application includes a SQL Server script file that adds tables and stored procedures to your Web site's database (named Samplevodsite.sql). Two of the tables created by this script file (VODCatalog_CatalogProducts and UserObject) are provided for demonstration purposes only. When you are ready to integrate the DRM sample application database objects into your Web site, you must replace references to these tables (in the scripted stored procedures) with references to your actual product catalog and user tables. 

In addition, the DRM sample application licensing pages (PreLicenser.aspx and Licenser.aspx) are configured to provide rights sets that require Windows Media Player version 7.1 or later. If you would like users with an older version of Windows Media Player to be able to view your content, you must modify the rights sets defined in these licensing pages.

For More Information

For more information about the Windows Media Rights Manager SDK, go to the Windows Media page.

Page view tracker