Guest opinion: DRM out of balance
Jan 10, 2006 — by LinuxDevices Staff — from the LinuxDevices Archive — 1 views
In a Linuxdevices.com guest column back in 2002, I argued that without a major attitude change, digital rights management (DRM) technologies would cause software security failures and generate… safety problems for everything from medical equipment to military systems. (That article basically said that systems with built-in DRM would create security problems for non-target cases.)
The recent Sony BMG DRM fiasco, which resulted from a common failure of requirements management logic, shows that developers of DRM systems have not had that attitude adjustment.
DRM brings up engineering problems that stress the weakest points of both system security and reliable device control software. Essentially the DRM problem is the problem of adding a complex constraint about copy protection to a very wide range of existing software and standard platforms.
When this constraint is added, what other constraints will be violated and what will be the consequences of the failure of those constraints? Consider these interesting cases:
- If PC hardware and base software prevents digitizing of copyrighted images, can an armed robber turn off security cameras by wearing a T-shirt with a copyrighted image on it?
- Will DRM mechanisms be able to tell the difference between a teenager making a copy of music over the Internet and someone calling emergency services while a CD plays in the background?
- What guarantees that a physician accessing the network in the middle of the night won't see her computer shut down because her children watched a video with the wrong country code on it?
- Where are the security and confidentiality safeguards so DRM will not result in bank or medical records being exposed on the Internet?
- What mechanisms are in place to prevent false DRM violations from interfering with the operation of networked computer systems or from spreading.
- and …
And the obvious solutions won't work. For example, you cannot separate DRM locked “home” editions from DRM-free “industrial” software. If the DRM-free software is easily available, it will be used to circumvent DRM. If the DRM-free software is hard to get, DRM-locked software will be used in inappropriate devices.
Any ambiguity that allows DRM to be triggered on a supposedly DRM-free system will have unpredictable consequences. And worse, if DRM-locked software is near ubiquitous, the interactions between DRM-free and DRM-locked software will also be unpredictable. For example, will a DRM-locked database refuse to upload prescribing data to a DRM-free pharmacy computer?
The technical problem can be described quite concisely. A working computer system is a solution to a system of constraints. Often these constraints are informally specified or poorly understood, but they may be critical parts of a larger engineered system.
For example, think of a networked hospital integrated software management system in a hospital with the following constraints:
- Access to patient records requires explicit authorization
- Sensed data must be timestamped precisely and must arrive at monitors within 10 seconds of generation.
- Physicians must be able to download records to PDAs
- Physicians must be able to upload orders to PDAs
- Patients should be able to connect to the network and see their own records and get patient information
Now let's add constraint #6: Any download to a computer must be scanned by DRM software and without appropriate licenses it must be rejected.
Does imposing constraint #6 mean that the system is no longer a solution to the other five constraints? That's a tough question to answer with much assurance, particularly because DRM requires global constraints. That is, the DRM constraint is a constraint on total system behavior, not on the behavior of a known set of operations.
If the DRM constraint was “Windows Media will not play software lacking XYX credentials,” the constraint would be easier to bound. But DRM is not being developed in this bounded way. Adding a DRM constraint affects the entire operation of the system.
The safety and reliability implications of these constraints do not seem to have been addressed by DRM-developers. One possible answer is that DRM is not compatible with safety and confidentiality. But in that case, isn't it better to consider the consequences now, while they are still in the future?
Note: an updated version of Yodaiken's earlier article appears on his blog.
Victor Yodaiken, CEO and Co-Founder of FSMLabs, came up with the basic technology of RTLinux, a technology that adds hard-real-time performance to Linux. Yodaiken began his career in 1983 as one of the chief developers of Auragen's distributed fault-tolerant UNIX, and he had an active consulting business before starting FSMLabs. He has also worked in academia, as a professor and department chair at New Mexico Tech, and as a research professor and port-doctoral fellow at the University of Massachusetts in Amherst. Currently he is an adjunct faculty member at the University of New Mexico.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.