The music industry is terrified of the Internet, which it perceives as a loosely controlled world where consumers freely distribute the content in which they have invested millions. The success of P2P piracy confirms that the public are aware of how difficult it is to successfully prosecute or prevent piracy or “free online media.” But eventually, content owners must learn how to use the Internet as a genuine business channel, and consumers must accept that they have to pay for their entertainment. The road towards realizing the possibilities of Internet distribution for digital media leads towards Digital Rights Management (DRM).

DRM lets content owners and distributors push their media securely to users, assured that the flexible DRM infrastructure will protect their assets from runaway distribution. DRM’s flexibility and security help open up digital distribution to all degrees of content ownership. No large hardware investments are required, and the software is free. The required components require only modest system resources and handle distribution via a web server. With such a small investment necessary to start digital media sales, large entertainment corporations and independent record labels can rapidly develop an Internet presence and compete on a level playing field.

Overview of Microsoft Digital Rights Management
Microsoft is leading the DRM charge in two areas. The first is the introduction of the Secure Audio Path (SAP) into the ME and XP operating systems kernel. With older Windows 2000 and 98 environments, the DRM client decrypts secured content before the Media Player receives the audio stream, meaning that it’s possible to intercept the stream after it’s decrypted, but before it’s played. However, a SAP-compliant operating system maintains media encryption until just before the stream reaches the sound card, making it virtually impossible to digitally route the stream to third-party applications. You can apply SAP settings using the DRM SDK.

The second area is the release of the adaptable Windows Media DRM COM components. These components work in two stages, packaging and licensing (see Figure 1). After the music or video is in a Windows Media format, you can program the components to package the media using a combination of keys and unique identifiers. After the securing the media, the distributor has the option of making the media available as is or adding user-specific attributes at run time, just before a user downloads a track. These user-specific attributes help identify individual instances of downloaded media. By combining this technique with business logic, distributors can restrict users from reacquiring licenses.

Figure 1: Flowchart of Packaging and Licensing

In the licensing stage, the distributor has two methods to consider. The most common method, as used in the sample code that accompanies this article, is to issue a license to users the first time they play a secured media file. The first usage triggers the Media Player to request a license from the license acquisition URL stored in the header of the encrypted content. The target server generates a license on demand, using machine and player-specific details known as a challenge. The unique qualities of the user’s challenge ensure that the license is created exclusively and its use is restricted to the requesting machine (and possibly any portable devices to which transfer might be permitted). Media Player stores this license in a .lic file that is verified each time the media is played, it’s not a simple one-time decryption of the secured media. This circumvents the potential for licensed content to be decrypted and passed freely onto friends or a P2P network. The second licensing method of licensing involves scripting the RMGetLicense object, included with Media Player 7. This object lets you to deliver licenses silently through a web site. However, I do not recommend this method of license distribution. It makes error handling extraordinarily difficult, and you must be able to guarantee your users will be browsing with Internet Explorer because RMGetLicense is an ActiveX control.

Creating an Online Music Store
To get the DRM SDK you must send Microsoft a digitally signed DLL to prove the validity of your company. Microsoft claims that a DRM license request will take only 5-7 business days. You can apply online at msdn.microsoft.com. After you receive your evaluation or redistribution license and install the SDK, you must enroll to get a DRM certificate from licenseserver.windowsmedia.com. Don’t worry; enrollment is only a five-minute step. You can also get the update to your SDK’s individualization details at this site. Individualization refers to the most current version of the DRM encryption ‘black-box’ being used by Media Player. See Figure 2 for more information on how clients can update their individualization settings.

Figure 2: Client Individualization

After initializing your server, you must prepare your content. The easiest way to do this is through the Windows Media player. Disable ‘Personal Rights Management’ and preferably set your encoding bit rate to 128Kb/sec. (see Figure 3).

Figure 3: Encoding Options in Windows Media Player 7

Included in the sample code includes a Visual Basic 6 client to assist in packaging your content. Using the sample application, you can specify the files you wish to package individually. The client application secures the media by calling the Secure class of the DRMStore DLL. The DRMStore DLL is the key business logic component included in the sample code. It handles packaging and licensing. The following code demonstrates how to obtain and specify the ContentID, a unique identifier for the package:

ContentID = oKey.GenerateKeyID oHeader.ContentID = ContentID

The preceding sample code generates a GUID for the ContentID value, but in production code, you should use meaningful identifier. For example, you might use an ID from a store’s database. To generate a packaged version of the media, you use the WMRMProtect object:

' A path to the source fileoProtect.InputFile = Filename    ' Encrypt File to the absolute filename & locationCall oProtect.ProtectFile(sOutputFile)

Make Your Packaged Media Available to Customers
Now that the media is packaged, you’ll need to make it available to your customers. The sample code contains a store called ‘World of Sound’ which I recommend installing under the Web application ‘DRMStore’ on your Web server (see Figure 4).

Figure 4: The ‘World of Sound’ Sample Store

The sample uses free tracks to avoid the unnecessary complexity of introducing a payment model. If a user chooses to download a track, the file opens in the preferred player, which should be Media Player by default. When other players (such as WinAmp) are registered to handle Windows Media file types, and you have opted not to support DRM v.1 licensing, problems may arise. I recommend that you demand your customers use Media Player 7, because DRM version.1 has significant drawbacks and the techniques required to bypass its security are widely known. Another noteworthy point is that Windows 95 and NT 4.0 do not support DRM 7.1. It would appear this important share of the market will not be addressed; Microsoft prefers to have its users upgrade to a more multimedia friendly OS such as Windows XP.

When you open a secured track in Media Player 7, the player reads the license acquisition URL to attempt to license its secured content. The request executes an ASP page on the server that forwards the ‘challenge’ onto our DRMStore component:

' Create the License Object Set oLicense = Server.CreateObject("DRMStore.License") ' Generate License / Pass the Challenge and Silent details onsLicense = oLicense.IssueLicense(cStr(sChallenge), cBool(bSilent)) 

The most significant problem you’ll encounter when creating a license programmatically is dealing with the WMRMRights object. The COM definition for any numeric property on the object demands the use of a DWORD, a non-compliant data type for COM. This makes it impossible to late-bind to the Rights object; Visual Basic will not compile and will throw an error (see Figure 5). The only workaround is to use CreateObject. In the example code, I have wrapped the Rights object to avoid some of the object’s common pitfalls.

Figure 5: Windows Media DRM Rights Object Invalid Interface

When you wish to pop-up a license acquisition screen on the client (non-silent delivery) you must format the license appropriately. The RMGetLicense.StoreLicense method, executed as a client-side COM object, completes license installation through a JavaScript function. Firstly, you must format the license so it will work in JavaScript syntax:

'Format for JavaScriptWMRMResponse.ReplaceQuotesWith = """" 

And on the client side, Media Player will detect the new license and allow the media playing operation to proceed:

If you prefer to distribute silently, you don’t have to format and store the license as shown above; however, to avoid a license pop-up window from appearing, you must not render any HTML into the license response (see Figure 6).

Figure 6: A License Acquisition Pop-up in Windows Media Player

When the media plays, you’ll see the words “Protected Content” rotating on the status bar. (see Figure 7).

Figure 7: Windows Media Player Playing DRM-secured Media

Forward-Thinking Design Despite Limitations
You’ve now seen a complete list of the basic steps required to develop a Windows Media DRM solution. It is also worth noting that the DRM media could be distributed using Windows Media Server as opposed to downloading. This would prevent your client from retaining a local copy of the media. For an insight into some of the possible business models you could employ for DRM, refer to “Implementing Different Business Models” in the SDK or view it online at msdn.microsoft.com.

The Windows Media DRM SDK is an adaptable set of components that effectively reduces the potential for digital piracy. However, the SDK is not without its pitfalls. I think the biggest oversight in the SDK is the inability to determine whether a license request is a renewal or a first attempt at acquiring a license. This makes license acquisition unnecessarily difficult for the distributor to control. Many of the limitations noted in this article hamper the SDK’s ease of use but, overall, the DRM concepts are well thought through. Microsoft’s forward-thinking design enables a small, automated security update to be applied with ease in the event that the black-boxed DRM logic is compromised. By future-proofing the software against security hacks, Microsoft proactively limits any long-term security exposures or major software fixes. This has proven to be the biggest benefit in Microsoft’s DRM deployment and single-handedly warrants a further investigation into the technology.