| Guest opinion: DRM out of balance |
a guest column by Victor Yodaiken (Jan. 10, 2006)
 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 ...
There are off-the-shelf PCs managing safety systems in nuclear power plants, guarding the confidentiality of medical records, controlling warehouse conveyor belts and factory assembly lines, and managing power load on transmission lines. It's totally irresponsible to develop DRM systems without taking these types of uses into account.
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.
Talk back!
Do you have comments on this story? Join the discussion here.
About the Author
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.
Related Stories
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Linux is a registered trademark of Linus Torvalds. All other marks are the property of their respective owners.
news feed