Jan Schaumann
`` `Do you ever read any of the books you burn?'
He laughed. `That's against the law!' ''
-- Fahrenheit 451, Ray Bradbury
On September 6, 2000, the Secure Digital Music Initiative (SDMI) initiated a
contest to "break" the technologies they developed to protect ``unauthorized
copying, sharing, and use of digital music''([2]). When a team
of researchers from Princeton University, Rice University and elsewhere, led
by Professor Ed Felten of Princeton succeeded in defeating these technologies,
they intended to publish the results of their research at a conference - yet
the SDMI threatened to sue them for violation of the 1998 Digital Millennium
Copyright Act (DMCA), causing them to withdraw this paper from the conference.
On July 16, 2001 Dmitry Sklyarov, a 27-year-old Russian software engineer, was arrested and charged with trafficking in and offering to the public a software program that could circumvent technological protections on copyrighted material, under section 1201(b)(1)(A) of the U.S. Copyright Act, which was made law by the DMCA.
Dmitry had given a talk entitled "eBooks security - theory and practice",
demonstrating flaws in Adobe's eBook Reader.
Taking these two examples in consideration, what might be the implications of the recently proposed ``Consumer Broadband and Digital Television Promotion Act'' (CBDTPA)1? How would this law, if passed, affect not only the average user but particularly a security administrator? The answers to these questions and the investigation of underlying factors will be the topic of this paper, and I will focus mainly on the impact this law would have on common security practices.
The ``Consumer Broadband and Digital Television Promotion Act'' (CBDTPA), is intended to develop a Security Systems Standard to which all future technologies must adhere. These technologies include, but are not limited to, actual physical devices (such as computer hard drives and CD drives) as well as any software component of a given product. In addition, this law, if passed, would apply to any as of today unknown technology that may arise.
The CBDTPA, as formulated and introduced to the US Senate at the time of this writing is a bill to ``regulate interstate commerce in certain devices by providing for private sector development of technological protection measures to be implemented and enforced by Federal regulations to protect digital content and promote broadband as well as the transition to digital television, and for other purposes.''[6] This formulation and the name of the bill do not seem to suggest outstanding implications upon people working in the field of Computer System Security; however, it is important to remember that the bill was first introduced under the name of ``Security Systems Standards and Certification Act''. Even though the bill deals primarily with copyright protection and consumer rights, the broad definitions given in this Act do have implications on Security Systems as is explained below.
The following are the noteworthy aspects of the CBDTPA with respect to System Security as discussed in [3], [4], [5], [7] and others, cited from the text of the actual bill[6].
``(d) SECURITY SYSTEM STANDARDS. - In achieving the goals of setting open security standards that will provide effective security for copyrighted works, the security system standards shall ensure, to the extent practicable, that - [...] (2) any software portion of such standards is based on open source code.''[6] (Section 3(d)(2))
This section, which has been added since the bill was first introduced under the name of SSSCA, intends to ensure that any software portion of the newly developed standard is freely available to any company or individual who wishes to develop such a device. Before we go into further discussion of this aspect (which we will do in Section 4.1), it is important to point out that the term ``open source code'' has not been given a definition within this act. This can only lead to the assumption that the generally accepted definition holds.2
``(a) IN GENERAL. - 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 medial device unless the device includes and utilizes standard security technologies that adhere to the security system standards adopted under section 3.''[6] (Section 5(a))
The importance of this section is as obvious as it is a necessity: Any law enacted must - if applicable - prevent circumvention thereof by way of international commerce. That is, if a product is illegal in the US, it may not be imported from a country where it could legally be sold. In today's networked world, and particularly in this market which is based upon the interoperability of open protocols and standards among all countries, the implications of this section grow exponentially.
``No person may -
(1) knowingly remove or alter any standard security technology in a digital media device lawfully transported in interstate commerce, or
(2) knowingly transmit or make available to the public any copyrighted material where the security measure associated with a standard security technology has been removed or altered, without the authority of the copyright owner. ''[6] (Section 6(a))
The authors of the bill clearly assume that the mere development of a Security Systems Standard would not be enough to ensure the preservation of the integrity of security. Instead of relying on the quality of the standard to speak for itself and convince people to adopt it and to abide by it, the very attempt to alter the provided technology is simply outlawed. It is important to point out that - again - the phrasing of this section is not as precise as it should be, nor does the bill allow for any exceptions.3
``(3) DIGITAL MEDIA DEVICE. - 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).''[6] (Section 9(3))
As mentioned in Section 2, the main focus on copyright protection is obvious. Less obvious but more crucial is the fact that the words ``reproduce'', ``convert'', ``retrieve'' and ``transfer'' include any action that can be taken with respect to a computer file. None of the basic operations necessary for a computer to utilize any device can work without at least one of them. This broadens the reach of this bill from mere copyright protection to the most general computer usage.
Before we debate the detailed implications of the CBDTPA, let us discuss some
of the approaches and techniques utilized by Security administrators and
Engineers in their attempts to secure their systems. As we know, the general
cycle of system security engineering follows a scheme much like in Table
1.
As explained in [3], ``Security threats include disclosure, change, blocking, or theft of resources. They are possible because systems have vulnerabilities.'' It is these threats that a Security Engineer must be aware of, it is the vulnerabilities that she needs to address. In order to achieve the goal of closing the vulnerabilities on a given system, one needs a profound and deep understanding of all the factors involved.
A good security engineer or system administrator not only knows the hardware installed on the machines and how the various components work together, but she also has detailed knowledge of the software running these components. The more advanced the software, the more security-relevant tasks managed or affected by the software, the bigger the need for the administrator to be able to configure it, to adjust it, to make it work as desired under the given circumstances.
Any piece of software that is being added to a system that is known to be in a secure state must undergo severe scrutiny; it is not uncommon for the administrator to modify the software to fit her particular needs.4 Similarly, any software installed may have bugs or other vulnerabilities that are only discovered after installation. If an administrator detects such a flaw in the program, she will often rectify the situation herself by making the necessary adjustments to the code, that is, she alters the software or removes the offending part of the software.
When a vulnerability has been detected in a given piece of software, it is common practice to inform the vendor or distributor of the software while at the same time5 releasing the information to other authorities such as CERT6and the general public on open Mailing Lists such as ``Bugtraq''. If the person who identified the vulnerability was able to fix the bug - be it by adjusting the environment in which the program is executed7, or be it by modifying the source code - she usually makes available the modifications that allowed her to secure her system and to prevent the exploitation of the detected flaw as well.
Since it is nearly impossible to secure a system to completely8, another essential part of maintaining a secure environment consists of creating backups of your data. This includes not only plain data (such as a users files, a crucial document containing a companies trade secrets, configuration files etc.) but also complex programs.
These backups are then used not only in the case of an emergency to restore the system, but also in everyday procedures to check the very integrity of the machine(s) in question. To determine if a given program has been tempered with, it is common practice to create a copy of the software immediately after it has been installed, so as to allow for bit-by-bit comparison of the binary image at a later point in time. A variety of intrusion detection programs9 consist of or include the ability to perform such a check.
While Section 3 can by no means be regarded as complete, it covers some of the most essential practices commonly used by security engineers and system administrators everywhere to ensure the maximum security of their systems. But what might be the implications of a law based on the CBDTPA, if it were passed?
From Section 3.1 and Section 3.2, it becomes obvious that the access to the source code for a given program is an important aspect. While in general proprietary software distributed by a vendor does not allow the end-user to modify or even see the underlying source code, most of today's industry standard software enabling the Internet is distributed in the form of ``Open Source Software''.10 While there does not exist an absolute definition of the term ``Open Source'', it is generally accepted that the user of such software not only gains access to the source code, but more importantly has the right to make any and all modifications to the program she sees fit. In addition, all Open Source Licenses (as accepted by the ``Open Source Initiative''11) grant the user the right to redistribute the software or a modified version thereof.12
The CBDTPA, as explained in Section 2.1.1, demands that any software portion of the Security Systems Standard to be developed be based upon ``open source code''. The very definition of ``Open Source Software'', however, leads this bill ad absurdum: How could one make a requirement the terms of a license that explicitly allow modification and redistribution of the software it covers of a law that outlaws these very acts13?
Furthermore, Open Source Software is generally the collaboration of various individuals that may be separated by great distances - often the various members of a project are not even located in the same country. As such, they are not bound by the same laws, and what is (or may become) illegal in this country, may not cause any legal problems in another country. By outlawing import of all ``devices'' as defined within the CBDTPA that do not follow the proposed standard, this bill might eventually outlaw a large variety of Open Source projects, thus damaging anybody relying on this software - yet at the same time, it demands that itself is based on Open Source software. This can at best be described as short-sighted and counter-productive.
In Section 2.1.3 we noted that the CBDTPA, in the attempt to prevent consumers from harming a producer's or artist's copyright, does in fact outlaw any modification to the device without exception. Not only would it be illegal to remove the copyright protecting part of the device or to alter it in such a way that it becomes dysfunctional, but at the same time would it be illegal to fix a bug discovered in the software or to add security enhancing functionality to the device.
If the user is not allowed to make any changes to a device that she obtained in a legal way, she is completely and utterly dependent on the distributing party. Should any vulnerabilities become known to the user (or the public), she would have to sit and wait for the distributor or vendor to supply her with a new updated version.14 This, however, may take a significant amount of time, during which the system that is known to have a vulnerability is exposed to anybody who can engineer an exploit.
In the previous sections, we have repeatedly seen that the loose phrasing of the bill could lead to severe difficulties when implementing this standard. Most notably the definition of a ``digital media device'' (as cited in Section 2.1.4) could be interpreted in such a way as to apply to the most basic computer tasks. Whenever a user views an image or a movie, reads the content of a document or merely executed a binary, the operating system will have to ``access'' or ``retrieve'' the file without being able to distinguish between copyrighted and non-copyrighted material. Whenever a file is copied from one physical location of the disk to another, it essentially ``reproduced'' the data. Even the simple act of renaming a file could conceivably fall into this category.15 Any physical device and any software that is involved in this process16, would need to comply with the CBDTPA or be outlawed.
Given the immense amount of software affected, it would be conceivable to consider a vulnerability the fix of which might actually disable the copyright-protection mechanism. As a result, this piece of software - even though it would now be secure - would be illegal: the user is left with the Hobson's Choice of whether to integrate a compromised or an illegal solution.
As debated in [4]17, ``Trust is the most important quality in computer security.'' Trusting a vendor to expedite the patching of an existing vulnerability is something that no Security Engineer prefers to do, which is why they need to maintain a complete backup of a secure and uncompromised system as well as the possibility to maintain their backup, as it's the only source they know they can trust.
The importance of creating backup copies of any new software to be installed has been explained in Section 3.3 - but would a law like the CBDTPA still allow for this practice? It is difficult to judge whether or not this would be the case, as this question touches other areas of the law (such as ``Fair Use'' rights), but the danger resulting from the loose definitions given in this act are obvious. As shown in Section 1, other laws have already been abused through their phrasing to not only harm consumers and end-users, but to stifle and cripple new and important research in the field of security.
``You've got Jail! Please wait while we contact the local authorities.''
-- AOL, circa 2004
This is the message one might hear on occasion if the CBDTPA (or a similar law under any other name) were to be passed. System administrators and Security Engineers, Intrusion Detection Specialists and Software Engineers alike would run the danger of performing illegal acts during their day-to-day work.
When the ``Security Systems Standard and Certification Act'' was introduced to the Senate, it was more restrictive and more precise in its definitions than now that it has been renamed into the ``Consumer Broadband and Digital Television Promotion Act'', yet the name was more accurate as it clearly identified the field upon which such a legislation would have an immense affect. After it has been edited and renamed, it appears as if it would only protect and promote security: a dangerous deception.
It would be outside the scope of this document to consider the implications such a law would have upon Fair Use laws, copyright protection in general or the software industry as a whole, but I hope to have demonstrated the dangers of this bill with respect to systems security.
While at the time of this writing, it is still unclear whether or not such a law will be passed, it is important to consider the impact it might have. As I have shown above, the nature of this bill could very well outlaw common security practices. Furthermore, such a law - in itself contradictory - would prevent free research and advances in the area of cryptography and systems security, so that the above quote might not seem that far-fetched.