Communications of the ACM

Digital rights management and fair use by design

Fair Use, Drm, and Trusted Computing

By John S. Erickson
Communications of the ACM, April 2003, Vol. 46 No. 4, Pages 34-39
10.1145/641205.641228
Comments

The migration of trusted computing principles into end-user systems promises to increase the practical application of and market demand for digital rights management (DRM) technologies. Trusted computing platforms and the integration of DRM components into the operating system will likely make controlled, conditional access to content and services attractive for providers of copyrighted resources, and an increasingly common—if not always popular or desirable—part of the end-user experience.

The ability of providers to reliably and deterministically impose rules on the end-user experience raises the question of who sets the rules dictating how users interact with digital information on their personal systems. Will the social policies and common practices that have traditionally influenced the copyright process be replaced by rules privately constructed by content owners and software providers? Will they be privately enforced by operating systems and DRM technologies? Conversely, can these emerging architectures help protect the limitations on copyright owners' exclusive rights, preserving the flexible fair use doctrine?

Here, I explore how access-control policies are evaluated, especially in the case of two rights expression languages—the eXtensible rights Markup Language (XrML; see xrml.org) and the eXtensible Access Control Markup Language (XACML; see www.xacml.org). Since the expression and interpretation of policies is but one layer of the general problem of asserting and protecting copyright with computer code, I emphasize the role of trusted systems in ensuring that computing agents interpret policies in reliable and deterministic ways. I also weigh the challenges inherent in expressing and enforcing policies that mimic social policies. Engineers often seek to simplify problems, but when the problem involves implementing legal statutes (such as copyright) with executable code, simplifications might actually do damage, especially if the solution gives either party more power to assert control than the law entitles.

Back to Top

Controlling Information Use

DRM includes a range of technologies that give parties varying degrees of control over how digital content and services may be used, including by whom and under what conditions. Since resources may be deployed in so many ways in the digital environment, policies may be enforced at many possible "control points" employing varying degrees of control or flexibility.

DRM taxonomy. At least one taxonomy for the "controlled dissemination of information" may apply to DRM [10]. Figure 1 shows that the categorization of DRM mechanisms ranges from very limited to very flexible to maintain originator control over specific uses of resources over time. The problem of controlling use can be broken down into four areas:

Use or action against an information resource by a user or an external system. Typically, uses are defined by an application's functions (such as view, print, and copy) that must be bound to policy-level terms, either directly or through some contextual filter. To control use, functions within an application must be forced to obtain authorization from policy-evaluating system components (the virtual machines in Figure 1) before proceeding.

Implementing control. A virtual machine may be a combination of system components that implement the control specified by policies (Control Sets in Figure 1). The virtual machine functions as an intermediary among user applications (such as viewers, rendering tools, printer drivers, and Web services) and policy-setting authorities; the virtual machine evaluates all applicable policies and permits or denies use.

A governing set of policies. For any given action against a resource, there may be a set of applicable policies that determine the conditions under which the requested application is authorized. These policies may take the form of conditions precedent or concurrent obligations; conditions typically include the presence of a particular identifying credential or environmental attribute.

Fixed or built-in policies. Policies may be fixed or built into the virtual machine; they may also be embedded or otherwise attached to the resource. Each method sets limitations; in the case of fixed policies, the originator cannot change the policies once the interpreter is distributed; in the case of embedded policies, a policy cannot be changed once the resource is deployed.

The most flexible architecture calls for the policies to be managed, since such management is external and separated (in time and space) from the virtual machine and deployed content. This architecture characterizes most DRM systems and is the basis for the DRM reference model discussed later.

DRM systems may implement a combination of embedded and external policy models; for example, when certain default or generic policies are attached to the deployed resource, a recipient may supplement them through a separate transaction [3]. Policies may be written for groups of resources and principals, possibly relating to roles within an institution, and may be issued in advance of use; most are available in the rights expression languages [4].

DRM reference model. A generalized DRM system can grant usage rights based on originator-controlled policies [11]. Since this model describes most commercially viable DRM solutions (the DRM reference model), it assumes the availability of standardized or proprietary infrastructure for identification, metadata, authentication, and cryptography. The model's process flow covers nine steps:

• The user obtains a resource via, say, file transfer or streaming. If the resource is requested from a remote service by the user, it may be cryptographically individualized to the user's environment.¹
• The user attempts some use of the resource; the rendering application determines that the requested action requires authorization.
• If the applicable policies are not found within the user's environment, attributes of the user's request (such as usage context) are packaged in a message and sent to a license server by a DRM client component.²
• The license server determines the applicable policies for the resource based on the submitted request attributes.
• A financial transaction may be conducted to satisfy the policies if no satisfactory evidence of such a transaction is on record.
• The license package is assembled, including: a rights specification or set of usage policies; identifiers or attributes; revocation information; and cryptographic keys to the content. They may be specific to the content and context of use.
• The license is securely packaged and transferred to the client.
• The DRM client authenticates the received policies, evaluates applicable policies, decrypts the content, and issues an authorization to the viewing component for the requested action.
• Finally, the content is rendered or otherwise used, as requested.

---

Policies that are subject to many exemptions or based on conditions that may be indeterminate or external are difficult or impossible to automate with DRM.

---

Most early DRM systems were characterized by a simple passing of content to the rendering application following its decryption by the DRM client, with no authentication of the receiving application or benefit of protected execution. More recent approaches use authenticated code and principles of trusted execution and take advantage of kernel-level support for handling unencrypted content [2, 5].

Expression and evaluation of usage policies. One important aspect of the DRM reference model is the transfer of policies from some authority (such as a license server) to an enforcing agent closer to the user.

Policies in DRM systems are explicit conditional statements specifying how to handle actions attempted on resources by authenticated actors. These policies generally express the relationship with an actor or principal to whom the policy applies. They also express: some right, or the ability to invoke the action being attempted; the object or resource to which the action applies; and some set of conditions that must be met before the action can take place. The norm is to express these policies in a syntax that is both human- and machine-readable; they can also be "expressed" in machine-interpretable binary formats and hard-coded in software and firmware.

Policy languages differ in how they express relations among these entities; for example, the DRM-oriented XrML 2.1 models rights as highly specific grants that define the relationship among a principal, a right, a resource, and a condition.³ Multiple grants may be bundled together in the same license. Several grants from a given issuer may be included within a license, along with several sets of grants from different issuers. XrML policies evaluate the request to determine whether to deny, permit, or report indeterminate.

Rights within XrML are specific verbs mapping to actions within an application domain and are defined through an XML schema known as "content extension." The definition of particular rights may be shared among applications within a domain; for example, the MPEG-21 Working Group is defining a set of verbs that will be common among a variety of multimedia applications implementing the MPEG-21 specification [7].

The policy-oriented XACML takes a more indirect approach that assumes a highly distributed environment in which all policies, attributes, and decisions may be remotely sourced.⁴ One notable difference between XACML and XrML is that a permit is accompanied by an optional specification of obligations that must be fulfilled by the enforcement point prior to allowing access [9].

XACML also introduces the notion of "request context" as a way to separate the policy language abstractions from the more specific application-domain attributes. This feature bridges the gap between specific code implementations and contexts and abstract notions of rights, as expressed in the policies.

Trusted policy enforcement. The expression and interpretation of policies is but one layer of a usage control system; policy writers must also have some assurance that computing systems will interpret issued policies in reliable and deterministic ways. Issuers must establish trust within this distributed system, at least insofar as it concerns their policies and the resources to which they have applied them; one approach is suggested by the Trusted Computing Platform Alliance (see www.trustedpc.org/home/Specification.htm).

A trusted system must undergo a process of authenticated boot, whereby only authenticated components that are to be part of the certified profile are loaded by an authenticating boot loader. These components have been tested and digitally certified by some appropriate authority; any component that is a candidate for loading is required to match the signature stored within the profile prior to loading. The profile generally functions like a signature for authenticating the configuration.

Components within trusted systems check the authenticity of components with which they interact [2]. In the future, as system developers adopt principles of trusted computing, components may refuse to interoperate with components they do not trust; the key is to realize that trust is inherently relative, and the decision about whether to accept a specific certification must be based on the needs and wishes of a particular application developer or domain administrator. Applied to policy enforcement, the notion of relative trust means that any two given policy domains may not necessarily trust each other, even if each is implemented with recognized principles of trusted systems.

Back to Top

Challenge of Coding Copyright Law

Only those policies that can be reliably reduced to yes/no decisions can be automated successfully. Access-control policies that fit within narrow application domains (such as the handling of confidential documents within corporations) are well suited to automated policy enforcement⁵; policies that are subject to many exemptions or based on conditions that may be indeterminate or external are difficult or impossible to automate with DRM.

Mapping copyright onto this technology is difficult in part because the problem domain is so broad and because the proper evaluation of a policy requires human intervention. Note that some transactions between copyright holders and users may benefit from the reduced transaction costs technical mechanisms can provide (such as a permissions request pertaining to a use within the copyright holder's exclusive rights). On the other hand, a significant portion of the uses of copyrighted works are unregulated; those that are regulated may be subject to numerous exceptions based on context, user traits, user intentions, and other factors.

Since DRM can be used to enforce tighter restrictions on use than is afforded by copyright law, concern over DRM design and widespread implementation, especially on trusted platforms, is reasonable.

Focusing on fair use. The U.S. Copyright Act of 1976 (17 USC) imposes limits on the exclusive rights granted to "originators" of creative works.⁶ The limits are enumerated in the Act's 15 separate sections; librarians and others concerned about DRM's effect on copyright policy frequently point to the balancing test of fair use (17 U.S.C. 107) to illustrate the risks of strict DRM systems [8].

---

In the case of fair use, no explicit set of rules can be implemented and automatically evaluated by computing systems.

---

Section 107 states that the fair use of a copyrighted work, including by reproduction or by any other means specified by the section for such purposes as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, and research, is not an infringement of copyright. The section then lists four nonexclusive factors courts must balance in determining whether a particular use is fair:

• The purpose and character of the use;
• The nature of the copyrighted work;
• The amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
• The effect of the use on the potential market for or value of the copyrighted work.

Note that the fair-use exemption presents broad factors rather than specific rules. A fair-use determination thus requires consideration of facts on a case-by-case basis. In the case of fair use, no explicit set of rules can be implemented and automatically evaluated by computing systems. Moreover, a fair use is by definition unauthorized and therefore does not require interaction with or compensation to the copyright holder. Indeed, many legitimate fair uses, including criticism, commentary, news reporting, teaching, scholarship, and research, might well conflict with the interests of the copyright holder.

Approximating fair use. Figure 2 depicts an alternative distributed DRM model that attempts to address some of the deficiencies of the DRM reference model discussed earlier. In that model the client is able to obtain only applicable policies from a single source controlled by the originator; in the alternative model, third-party license-granting authorities are introduced, offering an impartial authorization authority while taking advantage of the architecture of the current generation of DRM systems. It also highlights the potential of the connection between a DRM client and a licensing server for rich dialogue beyond today's simple permission requests. (A similar architecture was suggested in [6].)

End-user privacy is an essential quality of the real-world usage experience typically lost in DRM systems [12]. When attempting to approximate fair use in these systems, usage policies should not require that user- or platform-identification attributes be passed along to the license server. If user role attributes are used at all, they should not be submitted as part of a more comprehensive identity certificate.⁷ The preferred architecture would accommodate a more freeform textual statement of the intended use, if exchange with a server is necessary.

Back to Top

Conclusion

The inevitable adoption of trusted computing principles in end-user systems (such as personal communication devices, consumer electronics, digital media players, and library PCs) promises to increase the commercial appeal and use of sophisticated DRM technologies. Trusted computing platforms and the migration of DRM components into the operating system are likely to make controlled, conditional access to content a more attractive alternative to information providers and an increasingly common aspect of the end-user experience.

My purpose here has been to consider where policy-enforcing trusted systems are headed, examine how the emergence of trusted computing environments will affect our personal use of information, and address some of the problems technologists will face as they implement public policy through computing systems. I have emphasized the challenges and potentially negative effects of using these emerging architectures to enforce copyright restrictions, especially how to ensure that fair use and the related limitations of copyright law stay accessible to users of information. Responsible development of DRM requires that technologists understand the legal and social contexts in which these systems will operate.

Back to Top

Back to Top

Back to Top

Back to Top

Back to top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2003 ACM, Inc.

---

No entries found