![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/main.png)
|
|
|
Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise
news for all interests
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Letters All in one big page
Other LWN stuff:
Archives/search
Recent features: Here is the permanent site for this page. See also: last week's LWN.
|
Leading items and editorialsThe SSSCA under any other name smells just as foul. U.S. Senator Ernest Hollings ("the Senator from Disney") has submitted his latest payback to the entertainment industry as the "Consumer Broadband and Digital Television Promotion Act," which goes under the awkward acronym of CBDTPA. This proposed law would have far-reaching effects for the free software community, and is thus worth a close look. For those wanting more information, a look at the full text of the bill is worthwhile. We'll go over the relevant portions here. The bill begins with a set of 23 "findings," intended to justify the new law. They talk about the plight of the poor content providers, who just can't bring themselves to make their wares available on the net (or via digital television) without guaranteed protection. Current protection schemes are inadequate because: ...those agreements do not prevent the continued use and manufacture of digital media devices that fail to incorporate such security measures.
In other words, we're being told that the government must step in and make content controls mandatory for all "digital media devices." And what benefit do they "find" we will get from this? The secure protection of digital content is a necessary precondition to the dissemination, and on-line availability, of high quality digital content, which will benefit consumers and lead to the rapid growth of broadband networks.
Many of our readers may have been unaware of the fact that any problems with the growth rate of broadband networks are due to the lack of mandatory copy protection schemes. Or that there is no high quality digital content on the net. All we have to do is to turn the net into another form of television, and these problems will go away. Of course, the DMCA, too, was brought in with promises that it would enable a flood of wonderful digital products for us to buy... The core of the CBDTPA is new restrictions on what a "digital media device" can do. According to the bill, a "digial media device" is (emphasis added): The term "digital media device" means any hardware or software that: (A) reproduces copyrighted works in digital form; (B) converts copyrighted works in digital form into a form whereby the images and sounds are visible or audible; or (C) retrieves or accesses copyrighted works in digital form and transfers or makes available for transfer such works to hardware or software described in subparagraph (B).
This is, of course, a very broad definition. Any computer, which has no trouble "reproducing copyrighted works in digital form," certainly qualifies. Importantly, a "device" can be software. A Linux distribution falls under this definition, and would be bound by the requirements of this law. The operative part of the CBDTPA falls into two phases: (1) the establishment of "security system standards," and (2) the requirement that all "digital media devices" follow those standards. The establishment of the standards is supposed to be done in the private sector, which will be given a year to accomplish the task. Should the private sector fail to get its act together, the government (in the form of the Federal Communications Commission) will jump in and set the standards instead. Either way, there's a set of criteria to be met, defined in these vague terms:
These terms are not further defined in the proposed law. There is one other, interesting requirement: "any software portion of such standards is based on open source code." Of course, "open source" is not defined for the purposes of this law either; still, in theory, it means that we should at least be able to see the code for the "security systems" that are being forced onto our computers. There is a token nod toward fair use, saying that security systems must not interfere with fair use rights. The penalties for noncompliance with this section, though, are very small - far smaller than those for selling a noncompliant device or stripping protective codes. It does not look like it is meant to be taken seriously. Once the standards are set, industry has one more year to implement them, then the enforcement stage begins. There is a section requiring ISPs to pass through protected content intact, but the core of the law is Section 5: A manufacturer, importer, or seller of digital media devices may not: (1) sell, or offer for sale, in interstate commerce, or (2) cause to be transported in, or in a manner affecting, interstate commerce, a digital media device unless the device includes and utilizes standard security technologies that adhere to the security system standards adopted under Section 3.
In other words, unless your Linux distribution (which is a "digital media device," remember?) implements the security standards, it is now illegal - at least, if you want to sell it or transport it over state lines. (The emphasis on "interstate commerce" is the hook that gives the federal government the authority to regulate the movements of "digital media devices"). So how can free software function in this legal environment? Given that the code implementing the security standards is supposed to be open source, it could conceivably be incorporated into a Linux distribution. (Note, however, that nothing in the proposed law requires a patent-free or royalty-free standard). Such work would have to be done by a distributor; it's hard to imagine the kernel maintainers willingly incorporating this stuff into the mainline code. Then Linux users could simply remove that code. Then again, maybe not; Section 6 says:
No person may knowingly remove or alter any security technology in a digital media device lawfully transported in interstate commerce...
So one of the fundamental freedoms of free software would be stripped away: you would not legally be able to modify your system to fit your needs. But then, can a system based on free software ever meet the standards being set by this law? A source-available system, where users can remove the corporate big brother code at will, can never be "reliable" or "resistant to attack" in the eyes of CBDTPA supporters. If that interpretation holds, Linux systems become illegal whether or not they include the security code. What about downloading a Linux distribution from a non-US server? The legality of such an act will depend on a court's interpretation: is a user, by virtue of having performed a download, an "importer"? If so, downloading Linux from outside the U.S. is not allowed; otherwise it is legal. Either way, people would be at risk of prosecution until the precedents had been set. The absurdity of this legislation stretches belief. It's not clear what chances it has to become law; the Senate seems well beholden to the entertainment industry, but the House seems to be less enthusiastic. We should not count on the House to put this one out of its misery, though; those of us who are in the U.S. need to let our Senators know what we think of this thing. See this EFF advisory for more information on how to do that. iSCSI and patented technology. The IETF IP Storage working group is charged with the task of defining standards for accessing storage devices (i.e. disks) directly over an IP network. This is an increasingly interesting area: as computing systems become more distributed over ever-faster networks, why not avoid expensive "storage area network" interconnects and use the existing, cheap technology? It may well be that, not too long from now, disk drives (and arrays) will just plug into your household gigabit Ethernet next to the printer. It will be desirable, of course, for Linux systems to be able to make use of these drives. Perhaps the most prominent standard coming out of the IPS working group is iSCSI, the encapsulation of SCSI commands within the TCP protocol. The draft iSCSI standard is nearing completion; it will go to the internet standards "last call" stage shortly. So, one would hope, there would not be any major outstanding issues with the standard at this point. Unfortunately, that is not quite true - there is a patent issue with iSCSI that has the potential to make free software implementations difficult or impossible. An important part of the iSCSI standard is authentication. Just because you have placed a disk drive on the network does not, after all, mean that you want to let anybody have access to it. Network drives need a strong and secure authentication protocol, and the working group has tried to provide one. The choice for authentication is the "Secure Remote Password" (SRP) protocol, which is described in RFC 2945. It looks like a reasonable protocol, providing both authentication and secure key exchange. There is only one problem: SRP appears to be covered by three separate patents, with three holders.
The uncertainty behind Lucent's position, in particular, has given the iSCSI working group cause to worry about the use of SRP. At a working group meeting last week, the decision was made to demote SRP from an implemention requirement to an option. Instead, another protocol (perhaps CHAP augmented by a key exchange protocol) will be made mandatory. That could all change, though, and not for the better. According to the SRP summary from the working group meeting: Lucent continues to be approached with requests to be more cooperative. Lucent's actions (or lack thereof) are the primary cause of this delay to iSCSI.
In other words, the working group is not bothered by the Phoenix patent, which would require the purchase of a license under RAND terms. If Lucent becomes "more cooperative," we could find ourselves faced with an iSCSI standard which is encumbered by patents. That would not be a good thing for the free software community. For more information, see the IPS working group's web page, which has pointers to the relevant draft standards and a mailing list for discussions. Inside this LWN.net weekly edition:
This Week's LWN was brought to you by:
|
March 28, 2002
|
Copyright © 2002
Eklektix, Inc., all rights reserved
Next: Security