The future of DRM

Perfect DRM is impossible, but it can be effective in the commercial sense--protecting the commercial distribution of copyrighted works against unfair and illegal competition from pirates.

If ever a technology was introduced prematurely, it was digital rights management (DRM). From the DVD Content Scramble System (CSS) to the Advanced Access Content System (AACS) in HD DVD and Blu-ray systems, millions of dollars have been invested in failed attempts to prevent piracy of digital content.

Security is difficult to do right. CSS failed because virtually every element of the system was poorly designed. It used weak 40-bit encryption and was vulnerable to break-once, break-everywhere attacks. CSS continues to be used because it's better than nothing, but it isn't much better than nothing.

AACS solved many of the problems of CSS, but was quickly compromised because the AACS administrators allowed AACS to be implemented in purely software-based systems for PCs. Without hardware security, there was no way to stop ordinary software-debugging tools from extracting the cryptographic key values used to decrypt AACS-protected movies.

But the weaknesses of these systems shouldn't be taken to mean that effective DRM is impossible, as some have claimed.

There's a closely related claim that I can agree with: perfect DRM is impossible. It's inherently impossible to plug the "analog hole," for example. Anything a person can hear or see, a microphone or camera can record.

Nevertheless, DRM can be effective in the commercial sense--protecting the commercial distribution of copyrighted works against unfair and illegal competition from pirates. The full details of an effective DRM solution are beyond the scope of a single blog post, but making DRM work requires at least four factors that aren't present in current systems--and probably aren't even practical right now.

1. The DRM system must use secure hardware components integrated into the playback devices (e.g., displays and speakers) so there is no accessible digital pathway carrying decrypted data. Playback devices must be able to communicate with an authentication server the first time it sees each protected work.

2. Playback devices must not be able to play full-quality unprotected content.

3. All copies of a given work must not be identical. When practical--with downloaded content, especially--each copy should be separately encrypted. When this can't be done--as with pre-recorded optical media--critical portions of the content should be distributed separately at the time of authentication. Even then, the number of copies sharing the same decryption keys should be limited as much as possible.

4. The authentication process must use a secure communication channel between the DRM hardware and the authentication server, and transfer only the information necessary to play that specific copy of the work on that specific presentation device.

With all of these requirements in place, even the most sophisticated pirate attack can only compromise one copy at a time. That's plenty bad, but without access to the authentication servers, the pirates can't create a new version that can be played on the protected players.

This point brings us to the key difference between perfect DRM and commercially practical DRM--a commercial solution merely requires that pirated content is clearly distinguishable from authorized content by ordinary users. Although many people are willing to play pirated content, most aren't.

But none of these technical requirements address the social drawbacks of DRM. No matter how well implemented, DRM will always annoy some people, and will always present one more potential source of problems. I think we'll find that some--and perhaps most--kinds of digital content can be profitable even without effective DRM. Just because something's possible doesn't mean it's necessary...but if DRM is necessary, at least it's possible.

About the author

    Peter N. Glaskowsky is a computer architect in Silicon Valley and a technology analyst for the Envisioneering Group. He has designed chip- and board-level products in the defense and computer industries, managed design teams, and served as editor in chief of the industry newsletter "Microprocessor Report." He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure.


    Join the discussion

    Conversation powered by Livefyre

    Show Comments Hide Comments