|
|
Guest opinion: DRM out of balance
2006-01-10 Article Rating:  / 0
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:
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:
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. Do you have comments on this story? Join the discussion here.  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.
|
news feed
