DRM for Linux?

by on April 10, 2006 · 10 comments

ZDNet Australia has a very confused article about the merits of supporting digital rights management technology in Linux.

Jeff Ayars, a vice president at RealNetworks, said in a talk at LinuxWorld in Boston on Tuesday that if Linux does not offer support for DRM, people will not be able to run restricted digital content on the operating system, which will damage its success in the consumer market.

“The consequences of Linux not supporting DRM would be that fixed-purpose consumer electronics and Windows PCs would be the sole entertainment platforms available,” Ayars said. “Linux would be further relegated to use in servers and business computers, since it would not be providing the multimedia technologies demanded by consumers.”

He pointed out that Microsoft Vista is implementing a number of digital rights technologies, such as Protected Media Path, Protected Video Path and Protected User Mode Audio. “I would like Linux to be able to do that as well,” he said. The support must be included in the Linux operating system, as a DRM system would not be able to trust drivers that were separately installed, according to Ayars.

The article continues with a garden variety back-and-forth about the merits of DRM, with the Free Software Foundation saying consumers don’t like it, and Ayers insisting they do. What neither side seems to understand is that it’s impossible to offer “DRM support” (in the sense Ayers means here) in an open source operating system.


Actually, we see a hint of this problem in Ayers’s last sentence, where he says that “a DRM system would not be able to trust drivers that were separately installed.” This points to the way in which DRM is fundamentally different from other features an operating system might have. Most features you might add to an operating system add new functionality, such as the ability to use a new device or support a new kind of network service. But adding “DRM support” to an operating system involves something different: fundamentally, it means giving the rights holder an assurance that the operating system won’t do a particular set of things, such as making unscrambled copies of the protected content.

Microsoft can make that guarantee because Windows is its proprietary product. It won’t release a version of Windows that breaks the rules of the DRM scheme. And by keeping its source code secret, it makes it difficult (though in practice not that difficult) for users to modify the software to provide the verboten functionality. Moreover, because it controls the operating system, it can restrict which device drivers can run on the OS, and refuse to grant permission to any device driver that breaks the rules.

Every DRM scheme needs a centralized authority like Microsoft to ensure that the rules will be followed. There needs to be someone with the legal authority to prevent unauthorized parties from modifying the software to provide the functionality that the DRM scheme has guaranteed will not be available to the user.

The problem is that the GPL, under which Linux is distributed, precludes anyone from playing the role of “DRM traffic cop.” Linux Torvalds is Linux’s benevelent dictator, but he governs only by consensus. He cannot make any sort of promise–and certainly not a legally binding guarantee–that no one will take his DRM-approved version of Linux and produce a spin-off version that provides the verboten functinoality.

Commercial Linux vendors like Red Hat face the same problem. The GPL requires that anyone who produces a modified version of GPLed software must release his source code on the same terms as the original program. So if Red Hat released a version of its OS with “DRM support,” they would be required to release the source, and others would be free to modify the software to undermine the copy restrictions.

In short, DRM is inherently proprietary. I think that failure to understand this point underlies a lot of confusion in the debate over DRM and the DMCA. A lot of reasonable people acknowledge that the current DRM has some problems, but have confidence that future generations of DRM technology will fix those problems, giving us flexible, interoperable DRM schemes that anyone is free to implement. Steve Wildstrom is one such commentator. But that hope amounts to a conceptual confusion. There’s no such thing as open source DRM and there never will be.

I’m not surprised that Ayars doesn’t get it. I’m more disappointed at the response of the FSF, because they ought to know better. Perhaps they did make the point to the reporter, but the reporter chose not to include it in the article.

  • http://sepfield.com/ Tom Dunstan

    While that’s true of current generation hardware, Tim, it may not be in the future. If your hardware restricts what you can run on it, that code can be Linux just as much as anything else. See here for a summary of what’s being discussed.

    Put simply, RedHat (or whoever) could create a blessed kernel which respects DRM and only runs programs which do, and the TCG could assert that you’re running an official kernel and not some custom one to a remote DRM server or whatever.

    For that to work, it requires locked hardware, probably right down to the BIOS level, so that you can’t impersonate the TCG or do some sort of man-in-the-middle attack against it. And we know what will be the next step after locked hardware: legislation to prevent people from tinkering with their own machines. The DMCA and Broadcast flag idiocy has shown us what the DRM advocates in the content industries would really like to do with our PCs: turn them into TVs.

  • http://sepfield.com/ Tom Dunstan

    While that’s true of current generation hardware, Tim, it may not be in the future. If your hardware restricts what you can run on it, that code can be Linux just as much as anything else. See here for a summary of what’s being discussed.

    Put simply, RedHat (or whoever) could create a blessed kernel which respects DRM and only runs programs which do, and the TCG could assert that you’re running an official kernel and not some custom one to a remote DRM server or whatever.

    For that to work, it requires locked hardware, probably right down to the BIOS level, so that you can’t impersonate the TCG or do some sort of man-in-the-middle attack against it. And we know what will be the next step after locked hardware: legislation to prevent people from tinkering with their own machines. The DMCA and Broadcast flag idiocy has shown us what the DRM advocates in the content industries would really like to do with our PCs: turn them into TVs.

  • http://www.techliberation.com/ Tim

    Well, OK, if Congress outlaws the general-purpose computer, then it’s conceivable that you could have “open source” DRM. But that’s just because you’ve effectively made it illegal to modify the software. I’m not sure that would qualify as “open source,” though.

  • http://www.techliberation.com/ Tim

    Well, OK, if Congress outlaws the general-purpose computer, then it’s conceivable that you could have “open source” DRM. But that’s just because you’ve effectively made it illegal to modify the software. I’m not sure that would qualify as “open source,” though.

  • http://daniel.benoy.name Daniel Benoy

    This scheme could work even without government mandate. Consider the following situation:

    -{CHIP MANUFACTURER X} puts a private media-decripting key on the CPU.
    -Code can only access the hardware decription functionality if it is cryptograpgically signed by a private key possessed only {INDUSTRY BODY Y}

    So any media player would have to be inspected and signed to be free of holes that would allow outputting of decrypted data anywhere but the screen. (Operating systems would have to be certified as well)

    Of course, it’d only be a matter of time before someone learns how to inject their own arbetrary code into one of the cryptographically signed media players or OSes, which then dumps unencrypted information. Such holes are impossible to avoid, but it would at least be a serious hinderance to copiers, and will require being ‘attached’ to commercial products, rather than being custom and seprately distributed cracks. (To say nothing of the fact that discovering the private key hard-wired into the CPUs would be very difficult, but by no means impossible)

    Concevably, if an OS or a media player chooses to forgo getting its signatures by undergoing the DRM review process, it’ll still work fine, and continue to be open-source, it just won’t be able to play encrypted copyrighted media.

  • http://daniel.benoy.name Daniel Benoy

    This scheme could work even without government mandate. Consider the following situation:

    -{CHIP MANUFACTURER X} puts a private media-decripting key on the CPU.
    -Code can only access the hardware decription functionality if it is cryptograpgically signed by a private key possessed only {INDUSTRY BODY Y}

    So any media player would have to be inspected and signed to be free of holes that would allow outputting of decrypted data anywhere but the screen. (Operating systems would have to be certified as well)

    Of course, it’d only be a matter of time before someone learns how to inject their own arbetrary code into one of the cryptographically signed media players or OSes, which then dumps unencrypted information. Such holes are impossible to avoid, but it would at least be a serious hinderance to copiers, and will require being ‘attached’ to commercial products, rather than being custom and seprately distributed cracks. (To say nothing of the fact that discovering the private key hard-wired into the CPUs would be very difficult, but by no means impossible)

    Concevably, if an OS or a media player chooses to forgo getting its signatures by undergoing the DRM review process, it’ll still work fine, and continue to be open-source, it just won’t be able to play encrypted copyrighted media.

  • http://www.techliberation.com/ Tim

    Daniel: OK, I can see how that would work in principle. I don’t think it has any chance of happening in the real world, though. The important point there is that the entire OS (at least the entire kernel and all relevant device drivers) would have to be inspected and cryptographically signed by the licensing authority. Which means you couldn’t make any changes to the code at all without running back to the licensing authority for another signature.

    There’s no way you could get the mainstream Linux kernel approved in a process like that, because the system is just too open. The certification body would insist on the removing a lot of functionality (like the ability to load unsigned device drivers), which would probably requiring forking the code base.

    So now you’ve got a forked, crippled version of the kernel that doesn’t work with a lot of existing software (since it relied on libraries that were disabled due to security problems). Chances are, most of the Linux community will want nothing to do with the project, because complying with the arbitrary whims of an industry bureaucracy isn’t any fun. Yet turning it back into a usable OS (by re-implementing all the drivers and libraries that were ripped for being insecure) will be a lot of work.

    I don’t think that’s likely to happen. And if it does happen, it’s unlikely to be anything like what we now recognize as “open source.” The finished product would be sufficiently different from mainstream Linux that you’d get very few of the synergistic benefits of a genuine open source project. Moreover, the inspection process is likely to cost thousands of dollars and take weeks. The “release early and often” mantra doesn’t really fly under those circumstances.

    The DRM certification process and the open source development process are fundamentally in conflict. The former involves a centralized authority dictating–in great detail–what features a product may or may not have. The latter allows anyone to make changes to fit his or her individual circumstances. Although it’s theoretically possible to imagine an industry body certifying an open source OS, there’s no chance of any real-world free software being approved by a real-world certification body.

  • http://www.techliberation.com/ Tim

    Daniel: OK, I can see how that would work in principle. I don’t think it has any chance of happening in the real world, though. The important point there is that the entire OS (at least the entire kernel and all relevant device drivers) would have to be inspected and cryptographically signed by the licensing authority. Which means you couldn’t make any changes to the code at all without running back to the licensing authority for another signature.

    There’s no way you could get the mainstream Linux kernel approved in a process like that, because the system is just too open. The certification body would insist on the removing a lot of functionality (like the ability to load unsigned device drivers), which would probably requiring forking the code base.

    So now you’ve got a forked, crippled version of the kernel that doesn’t work with a lot of existing software (since it relied on libraries that were disabled due to security problems). Chances are, most of the Linux community will want nothing to do with the project, because complying with the arbitrary whims of an industry bureaucracy isn’t any fun. Yet turning it back into a usable OS (by re-implementing all the drivers and libraries that were ripped for being insecure) will be a lot of work.

    I don’t think that’s likely to happen. And if it does happen, it’s unlikely to be anything like what we now recognize as “open source.” The finished product would be sufficiently different from mainstream Linux that you’d get very few of the synergistic benefits of a genuine open source project. Moreover, the inspection process is likely to cost thousands of dollars and take weeks. The “release early and often” mantra doesn’t really fly under those circumstances.

    The DRM certification process and the open source development process are fundamentally in conflict. The former involves a centralized authority dictating–in great detail–what features a product may or may not have. The latter allows anyone to make changes to fit his or her individual circumstances. Although it’s theoretically possible to imagine an industry body certifying an open source OS, there’s no chance of any real-world free software being approved by a real-world certification body.

  • http://daniel.benoy.name Daniel Benoy

    Yeah I think you’re right with all those points. But I also think that a big Linux company like RedHat, or maybe even Microsoft itself will release such a crippled kernel. Obviously you or I will want to have nothing to do with it, but as Linux pushes closer to being a mainstream OS, and after hardware decryption is put right on desktop CPUs, signed and crippled versions of Linux will become more common.

    My contention, though, is that a scheme like that wouldn’t work from a technical standpoint. For example, we’ve already found a way around the X-Box DRM, which uses a similar (but more primitive) crypto-signature method of DRM.

    The way that was done is that they found an officially signed piece of software that had a buffer overrun error in it when loading games from a memory card. When it loaded a specially crafted saved game, the signed software could be employed to violate copy protection (i.e. load other games which don’t have a signature, like Linux)

    Anyway… as far as your fundimental point goes, you’re right. Once it has DRM, it’s not really FLOSS anymore. Can’t be done.

  • http://daniel.benoy.name Daniel Benoy

    Yeah I think you’re right with all those points. But I also think that a big Linux company like RedHat, or maybe even Microsoft itself will release such a crippled kernel. Obviously you or I will want to have nothing to do with it, but as Linux pushes closer to being a mainstream OS, and after hardware decryption is put right on desktop CPUs, signed and crippled versions of Linux will become more common.

    My contention, though, is that a scheme like that wouldn’t work from a technical standpoint. For example, we’ve already found a way around the X-Box DRM, which uses a similar (but more primitive) crypto-signature method of DRM.

    The way that was done is that they found an officially signed piece of software that had a buffer overrun error in it when loading games from a memory card. When it loaded a specially crafted saved game, the signed software could be employed to violate copy protection (i.e. load other games which don’t have a signature, like Linux)

    Anyway… as far as your fundimental point goes, you’re right. Once it has DRM, it’s not really FLOSS anymore. Can’t be done.

Previous post:

Next post: