decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Some Safety and Reliability Questions About DRM, by Victor Yodaiken
Wednesday, January 11 2006 @ 09:46 PM EST

Some Safety and Reliability Questions About DRM
~ by Victor Yodaiken
President and CEO, FSMLabs

Digital Rights Management (DRM) technologies are supposed to protect digitized “content”, like movies and musical performances from being illicitly copied or used. DRM technology is sometimes described as security technology when it is really licensing technology –- something very different. In fact, DRM may decrease security and reliability.

Consider what might happen if a computer equipped with DRM technologies was also used for the primary telephone of some unlucky person who opened his email mail to find a spammer had sent him a pirated copy of a song. The song begins to play automatically just as our fictional victim recognizes that he is experiencing a heart attack and he desperately clicks the Skype window to dial emergency services. But all he sees on the screen is a big notice:


Is this a realistic scenario? Based on the recent Sony BMG fiasco, it is.

Sony BMG put DRM software onto CDs that broke the basic system security and made the entire system slower and less reliable. Imagine that your children put such a CD on your computer and opened an avenue for hackers to make copies of your business memos and personal email. Imagine what would happen to the PC running a safety monitoring system for a nuclear power plant that was also used by a technician who wanted to listen to CDs on the job.

We are entering the era of ubiquitous and safety critical computing, but the developers of DRM technologies seem to believe that computers are nothing more than personal entertainment systems for consumers. This belief is convenient, because creating DRM mechanisms that respect security, safety, and reliability concerns is going to be an expensive and complex engineering task.

Our company sells real-time control software that runs on standard platforms –- the combination of standard operating systems and processors and we have customers using Linux and PCs to control robots, telecommunications switches, electric power lines, and machine tools. We're worried about how DRM technology either built into the base hardware or into network services will interact with software that provides safety critical services or that manipulates confidential data or that has timing constraints.

Here are some issues:

  1. One goal of DRM developers is to prevent “digitization”. For example, they want to make sure it is hard to play a CD on one device in front of a microphone that records it, free of DRM, onto another device. But it would be bad if our poor heart attack victim had evaded his email-induced problem only to find the Skype call interrupted because a music CD playing in his office triggered an anti-copying DRM mechanism. Another example I like to bring up is an armed robber wearing a Mickey-Mouse t-shirt with some embedded DRM triggering patterns in it –- and a security camera that obligingly shuts down when it detects the pattern.

  2. If DRM is going to work, it will need to be enforced by a web of reinforcing mechanisms: the processor will have a hardware ID and a hardware locked key that will be inspected by the operating system which will have its own keys that will be required by databases and media players and network devices. What happens if a network card breaks and is replaced -– causing the DRM system to conclude hardware has changed? Do we need to wait for new keys?

  3. How will DRM-locked and DRM-free systems interact? The computer that controls a medical blood test machine should not have DRM mechanisms on it, but will that cause problems when it tries to transmit results to a DRM-locked server? It's certainly plausible that DRM mechanisms will be built into the network hardware/software combination on the server and it will be tempting to make servers that refuse messages from “unsafe” (DRM-free) sites.

  4. Who controls DRM authenticity keys? Can a record company in dispute with an artist deny that artist keys needed so that her new works can be published directly or by a second company? What happens if your company's design documents or advertising or spreadsheets get caught up in DRM controls –- who do you call to get a key? If you have data in one database or file system and you switch, can you export the data without permission of the vendor of the first system? Will DRM keys be under the control of companies with an interest in denying their competitors access to the market?

  5. If someone wants to develop a media player used in a manufacturing system, will a DRM-enforcing operating system or computer board refuse to allow the media player access to video ports without a DRM key? What about drivers for nonstandard devices -– will these trigger DRM issues?

  6. Will DRM actions interfere with system timing? If DRM mechanisms are built into the BIOS software or board or processor firmware, can the processor be diverted from controlling a robot arm or monitoring a valve on a nuclear power plant to check licenses?

  7. Will DRM-locked technology be clearly labeled and inform users of possible problems? Is it going to be easy for a technician upgrading software on a computer controlling an intensive care unit vent or an airplane communication system to inadvertently install DRM-sensitive software instead of the DRM-free software?

  8. If all commercially available notebook computers are DRM-locked how will we assure that a portable digital diagnostic unit carried around by visiting nurses doesn't start to misbehave when the nurse loads a photo of her family from a digital camera with DRM requirements?

  9. Will virus writers be able to trigger DRM falsely on infected computers? Can a virus that purposely tries to copy DRM-locked music cause the computer to shutdown or lose functionality? Once one machine on a network is detected as possibly insecure will other machines refuse to talk to it? How can a network that has been marked as compromised be reset?

  10. Will DRM mechanisms trigger if they are placed behind a firewall? Currently, DRM mechanisms appear to be being designed to allow remote checking from the “license owner”. If it is possible to defeat those mechanisms by blocking some network traffic, DRM will be easy to evade. If not, DRM will battle network security.

  11. Will DRM network hooks provide security holes for virus writers? This question has already been answered by SONY BMG and the answer is not reassuring.

To summarize, DRM is a potentially dangerous and intrusive licensing technology that is being pushed into production before safety and reliability issues have been addressed. The widespread use of standard computer products to control all sorts of important systems is being ignored and DRM is being introduced as if there was no role for computers except as personal entertainment devices and as if computer users were purely consumers of prepackaged “content”. This approach seems sure to create more problems as time goes by.

Victor Yodaiken is the creator of RTLinux and President and CEO of FSMLabs, a software development company headquartered in New Mexico. Yodaiken has been working on operating systems in both industry and academia since the early 1980s, when he was one of the developers of one of the first commercial distributed fault tolerant UNIX systems. In a technical article published in Linuxdevices in 2002, he argued that without a major attitude change digital rights management technologies would cause software security failures and generate safety problems for everything from medical equipment to military systems. There is an updated version of the article here. See also DRM Out of Balance at LinuxDevices.

© Victor Yodaiken 2006.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )