Weekly Edition
Return to the Security page
| |||||||||||||
Enabling DRM in the kernel?Back in April, we looked at the Linux kernel patches for Intel's Trusted Execution Technology (TXT), a mechanism to verify the integrity of the kernel before booting it. Since that time, another version of the patchset has surfaced. The relatively few comments on the feature were largely concerned that there might be opposition to its inclusion—not because of technical considerations, but instead because of ethical concerns about what TXT could enable. Ted Ts'o had the most to say about what TXT (also known as LaGrande) enables, not necessarily in opposition to adding the feature, but outlining the concerns of those who might. He warned: "So we should expect a certain amount of controversy and people lobbying to resist the acceptance of this patch." The basic problem is that TXT can enable Digital Rights Management (DRM) systems that are largely uncrackable. Pointing to a "Trusted Computing" FAQ from 2003, Ts'o noted that five years ago, FAQ author Ross Anderson "was able to predict the emergence of the LaGrande Technology (see question 15 in the above FAQ)." But, Joseph Cihula, author of the TXT patch noted that some of the FAQ (and other Trusted Computing complaints) had been rebutted [PDF] in an IBM whitepaper by David Safford. But, as Ts'o pointed out, much of Safford's response was specific to the Trusted Computing Platform Alliance (TCPA) technology, which is essentially broken as a DRM lockdown solution:
However, it seems to me that TXT/LaGrande's main purpose for existence
was to repair the defects in TCPA that made it essentially [unusable]
for DRM purposes. With TCPA, any time you changed *anything* in the
boot path --- installed a new BIOS, upgraded to a new kernel to fix a
security vulnerability, updated to a new Nvidia proprietary video
driver slightly less likely to crash your [system] --- it would change
the trusted boot measurements, and would require an exchange to
"[Circuit] City DIVX hotline" (as a generic stand-in for whoever is
Hollywood's current monkey paw towards trying to implement DRM) to
approve a transfer of the TCPA trusted keys, which would be
essentially be a consumer support nightmare, and there would be no way
for "Circuit City" to know whether the kernel you are claiming was the
latest update from Fedora or Novell or Canonical was really an
authorized upgrade, or whether it was a custom kernel with patches to
tap into video and audio paths to steal Hollywood's precious bodily
fluids.
With TXT, however, all of these problems go away. What you end up booting is completely under "[Circuit] City's DIVX's" control, and may include a miniature Windows environment running in the trusted environment; it could then take over a portion of the screen for the video output, and the hardware would have special features set up to prevent the host OS from having any access to the video output of the movie player running in the TXT environment. Ts'o's message is worth reading in its entirety, but the basic point is that TXT enables Hollywood (or another DRM-happy entity) to take away some of the basic functionality of the hardware in order to preserve their "rights". Essentially, this takes away users' rights to protect companies' perceived or actual rights. The truly nightmarish scenario is one where one cannot do anything on a computer that isn't contained in a signed (presumably proprietary and closed source) application, running on a signed operating system. TXT could enable just that kind of functionality. But, there are some scenarios (Ts'o mentions medical record access) under which TXT could be beneficial to the user. Other devices (voting machines and ATMs are the standard example) could benefit from TXT as well. Should kernel hackers stand in the way of adding this code to the kernel simply because it can be used for ill? The consensus, from the extremely limited subset of the kernel development community participating in the discussion, seems to be "no". James Morris notes Linus Torvalds's famous "Flame Linus to a crisp!" message wherein he says: "I want to make it clear that DRM is perfectly ok with Linux!". Morris more-or-less agrees with that view:
I'm fairly neutral on the technology itself and feel that "market
pressure" from users as well as local regulatory policy (e.g. anti-trust
laws) should determine how the technology is used, rather than the views
of a few kernel hackers.
That sentiment is also shared by Ts'o: "That being said, it's not clear to me that stopping the technology from going into Linux really isn't going to help matters; realistically, the Linux desktop is miniscule[1], and whether or not we add support for TXT in the mainline Linux kernel isn't going to stop Hollywood's plans." His footnote refers to the potential risk of TXT being used in Moblin to lock down those devices, but "realistically, even if we don't let it into mainline kernel, it won't stop Moblin hardware vendors from shipping it". This is a social, not a technical problem, as Ts'o says. There are powerful interests that certainly want to have that kind of power over the actions of their customers. It will be up to those who value their hardware and software freedoms (and, very likely, the courts) to ensure that those freedoms are still available. Avoiding DRM is not something that has gotten onto the radar of most consumers, but the content providers are doing their best to raise its visibility. One wonders how many revoked features for Kindle books or how much music that expires because it is crippled with DRM it will take before consumers start to rebel. In the meantime, though, it seems likely that Linux will end up with TXT support somewhere down the road. The objections have been few—technical or ethical—at least so far, and the code obviously exists. There is no barrier to a hardware manufacturer (or distribution) incorporating it and enforcing whatever restrictions it wishes. Given that there are benign uses as well, the code is likely to improve from its inclusion in the mainline. When (almost certainly not "if") those uses turn towards total lockdown, it will be a social battle, on multiple fronts, to preserve the hardware and software freedoms we enjoy today. (Log in to post comments)
Enabling DRM in the kernel? Posted May 21, 2009 4:06 UTC (Thu) by PaulWay (✭ supporter ✭, #45600) [Link]
> as a generic stand-in for whoever is Hollywood's current monkey paw towards trying to implement DRM
Because it's Pedantic Thursday, I'd like to point out that the actual allegory would be "cat's paw"; in the Aesop's fable, the monkey asked the cat to fetch some chestnuts from the fire, and while the cat nursed its singed paw the monkey ate the chestnuts.
A monkey's paw is actually a gift that has unintended (terrible consequences), after he horror short story by W. W. Jacobs.
Have fun,
Paul
Enabling DRM in the kernel? Posted May 22, 2009 17:29 UTC (Fri) by shapr (guest, #9077) [Link]
Seemed to me that saying monkey's paw as a pun on cat's paw was in fact perfectly correct.
Today this company is doing Hollywood's bidding, tomorrow Hollywood owns them. Sounds scary to me.
Enabling DRM in the kernel? Posted May 21, 2009 4:21 UTC (Thu) by fuhchee (subscriber, #40059) [Link] ...The relatively few comments on the feature were largely concerned that there might be opposition to its inclusion...So in other words, the thread seems to be pretty free of controversy, except for speculation that controversy might some day erupt, but not from those doing the speculating (since they can live with DRM/TXT in the kernel)?
#CONFIG_DRM_NONSENSE is not set Posted May 21, 2009 6:05 UTC (Thu) by jimbo (subscriber, #6689) [Link] Who actually requires this apart Hollywood and its like? I submit that the rest of the kernel code will be immeasurably improved by
I think that including digital restriction management into the Linux kernel only panders to DRM's advocates, and serves only to restrict the freedom that we currently enjoy, including naive kernel developers. --J
#CONFIG_DRM_NONSENSE is not set Posted May 21, 2009 11:00 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
As the article (you read that, right?) said, an example would be voting machines, some independent authority says that version 1.4.26.8 of the software is OK, this type of technology ensures that every voting machine has 1.4.26.8 on it and isn't "upgraded" to a version that gives half the vote to whoever paid off the software vendor.
I don't happen to like voting machines, a pencil & paper works for me, but lots of US states want machines, and if you want people in those states to know their votes count, trust in the machines must be improved.
I'm sure there are other examples, but as a matter of /social policy/ I don't believe this technology is appropriate in devices sold to individuals (and not just because of DRM), and would cheerfully support a ban on retail sale of devices incorporating a technology which prevents the purchaser from reprogramming them.
#CONFIG_DRM_NONSENSE is not set Posted May 21, 2009 13:58 UTC (Thu) by anton (guest, #25547) [Link] some independent authority says that version 1.4.26.8 of the software is OK, this type of technology ensures that every voting machine has 1.4.26.8 on it and isn't "upgraded" to a version that gives half the vote to whoever paid off the software vendor.That's right, this technology could ensure that not only the software vendor, but also someone who signs the software gets a share of the spoils (but in practice it will probably all go to the vendor of the voting machine, as they do the software and the signing). Do the voters or the voting administration have any way to determine which software runs on the machine? Nope. So the voting machine scenario is just a red herring. And vice versa, treacherous computing will be used to muddle the waters in the discussion about the security of voting machines.
#CONFIG_DRM_NONSENSE is not set Posted May 21, 2009 16:06 UTC (Thu) by dw (subscriber, #12017) [Link]
I'd happily trust an electronic ballot if its source code and binaries were accessible, and the voting machine printed a hard copy signature based on my vote and the exact software version as recorded in the TXT state.
I don't think such a scenario is far fetched at all.
#CONFIG_DRM_NONSENSE is not set Posted May 21, 2009 17:19 UTC (Thu) by anton (guest, #25547) [Link] I'd happily trust an electronic ballot if its source code and binaries were accessible, and the voting machine printed a hard copy signature based on my vote and the exact software version as recorded in the TXT state.A fine demonstration of the water-muddling aspect I mentioned: How would you know that the software version on the voting machine corresponds to the available source code and binaries? The only way for you to be sure would be if you and only you held the keys that locked down the machine (and you would also need a way to know that the machine was not replaced with a lookalike, and that there is no hole in the lock-down mechanism). Otherwise this means that you just entrusted the vote to whoever holds the keys. Apart from that, if the signature is based on your vote, you have just done away with the secret ballot. I don't think such a scenario is far fetched at all.Unfortunately you are right. That is certainly one avenue that salespeople of voting machines will try to sustain their business model.
#CONFIG_DRM_NONSENSE is not set Posted May 21, 2009 17:21 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Do the voters or the voting administration have any way to determine which software runs on the machine? Nope.
As the people who have the key, the voting administration would in fact be the only people who'd decide this. Obviously such a system is useless if you give the key to people you don't trust, I can't believe I needed to write that explicitly.
treacherous computing for voting machines? Posted May 21, 2009 19:24 UTC (Thu) by anton (guest, #25547) [Link] As the people who have the key, the voting administration would in fact be the only people who'd decide this. Obviously such a system is useless if you give the key to people you don't trustSo you have replaced a system where any person can check that the votes are cast and counted correctly with one where we have to place blind trust in the voting administration. And if that was not bad enough, it's not the local administration that I had in mind, but some central agency (which makes any manipulation much more effective), and judging from the past, they will just delegate that power to the voting machine vendors. Note that checking the casting and counting by any person was even possible in East Germany, as I recently heard in a 20-years-after documentation; a few people did that in a few precincts and got a result that had more votes against the ruling party than the official result for the whole country. This embarrassment for the ruling party and the election would not have happened with voting machines (locked-down or not).
#CONFIG_DRM_NONSENSE is not set Posted May 21, 2009 12:49 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
I do.
I need to secure systems against _physical_ intrusion (i.e. someone walking-in and stealing the server). In essence, I need to do remote system integrity attestation.
Right now, I'm using a modified version of GRUB (trusted GRUB) to establish validity of the kernel (and I was flamed to a crisp when I offered to help to port it to GRUB2 on the GRUB mailing list :) ). TXT support in the kernel would help much.
#CONFIG_DRM_NONSENSE is not set Posted May 22, 2009 0:18 UTC (Fri) by jamesmrh (guest, #31622) [Link]
It's definitely useful, see BitLocker as an example:
http://theinvisiblethings.blogspot.com/2009/01/why-do-i-m...
#CONFIG_DRM_NONSENSE is not set Posted May 22, 2009 0:46 UTC (Fri) by njs (guest, #40338) [Link]
That's an article about a system that uses the old TPM stuff that the kernel already supports...?
Enabling DRM in the kernel? Posted May 21, 2009 12:13 UTC (Thu) by freemars (subscriber, #4235) [Link] Blu-ray encryption cracks appeared within a few months after the format was released into stores. The designers had anticipated this and had a mechanism in place to revoke keys. Will Intel (and/or Microsoft) be ready to brick a line of CPUs after someone pokes a hole in TXT?
Enabling DRM in the kernel? Posted May 21, 2009 21:12 UTC (Thu) by nix (subscriber, #2304) [Link]
They can expect enormous lawsuits if they try, so, probably not. Also it
would be insane from a security POV: if Intel can brick your CPU, one crack into the location where Intel stores their keys and crackers can brick all such CPUs. (Wherever the keys were stored would be a high-value target and might last as long as days before being cracked wide open. If need be a bit of custom theft would be carried out: criminal organizations would love this data.)
As Intel aren't insane, I doubt they'll ever implement such a hardware
Enabling DRM in the kernel? Posted May 24, 2009 12:54 UTC (Sun) by ras (subscriber, #33059) [Link]
Of course not. The MPAA's DVD player will refuse to run on your compromised CPU, but everything else will be fine. This is no different from a compromised Blue Ray player. It may not play new movies, but it will continue to play DVD's, CD's and whatever.
There are lots of uses this technology can be put to. I always think of the electricity meter in your house. Its a piece of the equipment on your property which you happily give up control over. You give it up the control because you like electricity. Ditto for a cable smart card, a SIM in your phone, your drivers license, your passport, the odometer in your car. All things you aren't allowed to tamper with.
When it comes to TXT, you would probably be happy to let you bank have a private corner on your computer in return for not charging you fees for small transactions. Perhaps you might like to give part of it to your favourite distro as a build machine. Maybe you want it to run P2P software will not allow snooping, and will only talk to valid copies of itself.
There are lots of good uses. Sadly there are also lots of nasty uses as well. We do live in interesting times.
reason to fork the kernel ? Posted May 21, 2009 12:25 UTC (Thu) by copsewood (subscriber, #199) [Link]
The culture war between those who want copying easy and those who want it difficult in specified cases isn't going to go away, because major industrial and commercial interests are on either side of it or, in some cases corporations e.g. Sony have divisions on both sides of this conflict of interests.
The kind of DRM support one kernel could provide can't fully support both sides of this war, in my view. If so, the solution may have to involve forking it. GPL3 enables DRM to be included but requires the end user to be provided with a copy of the keys, so the end user can still benefit from DRM, e.g. by helping secure their system for purposes agreed with by the end user, while retaining freedom to change things when and as required. GPL2 enables DRM to be included where no such requirement exists and freedoms to modify and study previously intended through the GPL license can be barred.
The problem will be with those intending to develop a GPL3 fork having to start pretty much from scratch based on parts of the kernel for which contributors are willing to make contributions available under GPL3 only, or BSD, or public domain or dual licensing compatible with the GPL3.
Enabling DRM in the kernel? Posted May 21, 2009 13:03 UTC (Thu) by fritsd (guest, #43411) [Link]
I'm fine with this as long as *BEFORE* it is in the mainline kernel, the developed world has laws forbidding the sale of a general purpose computer whose DRM keys are not under the control of the buyer.
Think about it: Hollywood could start selling "special-purpose video watching computers", medical companies could sell "special-purpose locked-down ISO-13485 compliant medical devices" but at least you'd know what you're buying.
At this moment, the purchase of a general purpose computer carries the unwritten assumption that this computer is for your own use and that you can do with it what you want (as long as you don't break any laws).
Voting computers are just a really, really bad idea in general, IMHO:
Enabling DRM in the kernel? Posted May 21, 2009 16:11 UTC (Thu) by copsewood (subscriber, #199) [Link]
I think the law proposed would make selling Vista illegal ? While such a law might be a good idea in principle, I don't see it happening in practice due to extensive corporate lobbying influence and very widespread public ignorance on the issue. Until then the best defence is likely to be the possibly future viral and indispensible nature of the GPL version 3.
Enabling DRM in the kernel? Posted May 22, 2009 5:13 UTC (Fri) by eru (subscriber, #2753) [Link] Think about it: Hollywood could start selling "special-purpose video watching computers"Hmm, isn't this already done? They are called "DVD players" (or "Blu-ray players"). Theoretically hardware, but much of the functionality in them is really implemented by a computer and software. The Blu-ray system even requires the player to be able to run Java bytecode programs from the disc, and some players include networking.
Enabling DRM in the kernel? Posted May 23, 2009 16:16 UTC (Sat) by DusteD (guest, #49423) [Link]
Voting machines: Voting machines are simple enough devices that they do not need any third party OS like Linux or Windows.
TXT could lead to much evil, even if it's optional. I could imagine non-free drivers that required TXT functionality to be enabled in order for them to be installed.
It does not make the kernel faster or better, throw it away.
Enabling DRM in the kernel? Posted May 29, 2009 0:59 UTC (Fri) by iamblue (guest, #58623) [Link]
To evaluate TXT you need ask only one question: Who has control of the keys?
|
|||||||||||||