DRM technology

Discuss digital rights management (DRM) with a group of people and you will most likely draw strong and opposing views. Unlike most engineering topics, the use of DRM is an emotive subject. On one side is a predominately younger group that abhors anything that obstructs the free sharing of content. On the other side are the content rights owners, who want fair payment to view their assets.

Whatever the philosophical issues, a broadcaster may be bound by contract to prevent the copying of content. The problem has existed since broadcasting was analog and copying used tape formats like VHS.

Conditional access (CA), DRM and copy protection are terms that are often used interchangeably. They each have separate roots. However, in the converged world of the connected home, they are being integrated into a unified system to protect the rights and revenues of content owners and distributors.

Traditional broadcast model

The traditional model used by broadcasters for revenue protection has been CA. It was designed to manage access to subscription services delivered via cable or satellite. The broadcaster scrambles all the pay channels. The set-top box (STB) is provided with the key to unscramble the channels that the viewer has chosen to pay for.

The problems for content owners started with the birth of the VCR. A viewer could make a copy of a program. Developments like Macrovision's analog copy protection (ACP) made copying to a VCR more difficult by distorting the sync signal. However, the generation loss of each VHS copy meant that many rights owners were content to put up with a certain leakage.

Digital television has changed all that. A clone of an HDTV broadcast is very good quality. It can be easily copied and distributed across the world, leading to substantial loss of market for subscription services and retail products such as Blu-ray and DVD.

Copy protection

With the introduction of HDTV, a solution to the problem of copying was devloped in the introduction of high-bandwidth digital content protection (HDCP). The STB forms a protected domain for the content. It can output downconverted SD through conventional connections, but HD signals are only available via a protected link, e.g., HDCP over HDMI or DVI. (See Figure 1.)

HDCP is a proprietary system, which is only licensed to trusted suppliers. An HD display manufacturer incorporates the technology to decrypt the link, extending the trusted domain to the display. Unlicensed devices cannot decode the video signal.

With the mass adoption of the DVR, viewers now expect to copy programs for later viewing at a convenient time. The DVR can also be designed as a trusted system, so that content can be recorded at will but not transferred to a third-party device.

The broadcast copy flag was intended to allow broadcasters to control redistribution of content, although currently the FCC has been deemed to be operating outside its remit in mandating that implementation.

New media

The broadcast landscape has been transformed with the introduction of new means to distribute and view video content. As streaming and progressive download became popular for the delivery of content to PCs, something equivalent to CA was needed to protect revenue. Unlike the controlled delivery of cable TV and the STB, streaming takes place over an open system, the public Internet. (See Figure 2, next page.)

In contrast to the service protection of CA, DRM was developed to protect the content. DRM provides a means of delivering paid-for content to a trusted media player on the PC. Where CA allows access to a number of defined channels, DRM allows access to a single item of content.

DRM operates by encrypting content on the media server, from where it is delivered over the Internet much like a Web page. In order to view the content, the viewer must obtain a decryption key. Bundled with the key is a set of business rules, which defines how the content can be viewed. It can allow a straight purchase or rental for a set period or number of plays. Content may be a live view only or it may be downloaded, again defined by the business rules.

Broadcasters on the Web use popular streaming platforms like Adobe Flash, Apple iTunes and Microsoft Silverlight to serve their content. All these systems offer DRM as an option with Flash Media Rights Management, FairPlay and PlayReady, respectively.

DRM does suffer the same problems as CA. Once the media is decoded in the player, it can potentially be copied. This is changing as operating system developers and chip manufacturers implement more trusted systems that will make it more difficult to copy to other devices.

Running a DRM system

For broadcasters looking to offer streams or downloads of programs from their Web sites, there are several ways to implement these systems. Assuming that the broadcaster already has Web servers, the additional requirements are a media server to host the programs and a license server to host the keys. The media server is akin to a Web server, but can manage the real-time delivery of the video streams.

The simplest way to offer protected content to viewers is to use a service provider. They can handle the complexities of issuing domain certificates and licenses to view content. Several content delivery networks (CDNs) have partnered with the software vendors to provide such managed services. The alternative is to purchase server licenses and set up your own systems, not a trivial undertaking.


With the convergence of media formats, the division between CA and DRM is blurring. The public are looking to a world where they can access content from their STB, via IPTV, the Web and mobiles devices. Not only that, once they have access to content, they want the ability to share the content across many media player, from their television to handheld devices. At present content can be protected in separate domains — one for pay TV, one for the Internet and one for mobile TV.

CA and DRM are developing to meet this converged world. CA manages delivery of pay TV, and DRM manages Internet and mobile delivery. The content can be viewed once it reaches the trusted player.

But the public wants to time shift, to share content across their many viewing devices. This requires a system to protect content and provide copy management across the media devices in the home. (See Figure 3.)

HDMI/HDCP was an early example of this, but it does not provide a complete solution. A father may want to copy a program from his DVR to a seat-back player in a car to entertain the children on a long drive. A financier may want to copy a financial program from a PC to watch on a PDA.

Such freedom to watch any content, anywhere, on any device presents many challenges for content distributors and broadcasters who must comply with the terms specified in contracts they signed when they acquired the rights to air content. DRM systems, by their very nature, are highly proprietary. To move content from one domain to another requires a DRM bridge. Implementing such bridges without compromising product security is difficult.

Forensic watermarking

Piracy will always exist. However, there are several ways to combat the theft of content. The first is to make it simple and affordable for the public to purchase what they want, and for them to be able to view on the device of their choosing.

The broadcaster can make it difficult for pirates to obtain quality copies through the use of robust CA and strong DRM for Internet and mobile delivery. CE device makers can incorporate secure hardware and link protection for interconnections like HDCP. And when all else fails, the final step is to use forensic techniques like watermarking to aid the legal enforcement of copy protection. However, the courts have not always been on the side of the content owners as the debacle of the broadcast flag has demonstrated.

The trio of technologies — DRM, CA and copy management — is there to protect revenues. It falls to the lawmakers to set where the divide between fair use and proper reward lies.

David Austerberry is editor of Broadcast Engineering World.

Send questions and comments to: editor@broadcastengineeringworld.com