La carrera administrativa: El camino de reformas y conceptos constitucionales.

3. Separate Delivery (provides content encryption and supports legitimate

viral distribution by separating the rights definitions from the content)

Forward-Lockis DRM at its simplest. It allows for basic content such as news,

sports scores, ring tones, or images to be downloaded to a handset, but it prevents the content from being forwarded on to another user. Once a piece of media is downloaded, that is the end of it. It stays on that phone only or until it is deleted. Forward-Lock can be used on simple phones and is available today on several handsets. Typically, the end-user initiates the download of a media object from a server to a device (phone). The content is packaged in an unencrypted form in a mime-compliant format. Defaults usage rights/limitations include

• Enable the end-user to consume the content (e.g., play, print, or execute) • Prevent the content from being copied/transferred to another device Applications include phone ring tones, logos, and wallpaper.

Combined Deliveryallows for more complicated rules for usage to be set for

a given piece of media and is an extension of Forward-Lock. The usage rules or rights are expressed using OMA Rights Expression Language (REL), which is a subset of the XML-based Open Digital Rights Language (ODRL), a mobile profile of ODRL 1.1 [6]. For example, an image could be downloaded to a phone using Combined Delivery, and the user could view the image a pre-determined number of times before the usage rights expire. Or the usage rights could be set by a time limit instead. The content is wrapped inside of the DRM technology, and the two are inseparable. In other words, the rules of usage are actually embedded in the content. Typically, the end-user initiates the download of a media object from a server to a device (phone). The protected media object and the rights are carried together in a single DRM message. The rights are expressed in terms of specific permissions/restrictions in rendering (e.g., play, print, or execute) the content. In general, the content is prevented from being copied/transferred to another device. The rights are also prevented from being forwarded.

Separate Deliverymeans that the content itself and the rules for usage (same as

in Combined Delivery) are sent as separate and distinct information. In this case the user can download media content and forward it on to a friend, but the rights are not sent. In order for the friend to use the content, she/he needs to agree to a new rights agreement, whether that means making a small payment or something else. It is called “Rights Refresh,” and it allows for the kind of viral distribution of content that the wireless medium enables, referred to as “Superdistribution.” This tech- nology would give a user the ability to preview a piece of content before deciding whether to purchase it. In this mode the content must be encrypted and converted into DRM Content Format (DCF). DCF provides plaintext headers describing content type, encryption methods, etc. A unique content identifier is also included (ContentURI). A DCF content object cannot be used without a Content Encryp- tion Key (CEK) contained in the separately delivered rights. The rights include

a uid which equals the ContentURI. The media object is allowed to pass from mobile device to mobile device where the rights objects are obtainable from the rights issuer (superdistribution). Applications include music distribution services. The separate delivery mode is a precursor to the more sophisticated OMA DRM version 2.0.

2.4.2 OMA DRM version 2.0

OMA DRM version 2.0 was released in July 2004, and it extends version 1.0 in numerous directions [7]. As compared to version 1.0, version 2.0 is intended to provide a more complete DRM system for protecting premium content while giv- ing end-users more flexibility in their access to that content. Basic to the version 2.0 system is the idea that content and rights are separate entities that can be separately controlled. The content is encrypted using a symmetric key (known to the device enabled to consume the content). The DCF and PDCF (Packetized DRM Content Format) file formats are used for discrete media and streaming media, respec- tively. Licenses are created as Rights Objects (RO) and include header information (URLs, version, time stamp, etc.), security elements (decryption key, signature), and rights information (play, copy, execute, etc.). DCF and RO identify each other by using the information in headers. RO are communicated to the device by using the Rights Object Acquisition Protocol (ROAP). Public key encryption infrastruc- ture (PKI) is utilized to protect rights information. PKI-based key delivery and management are used to authenticate devices and rights issuers and to bind RO to devices.

An RO governs how DRM content may be used. It is an XML document speci- fying permissions and constraints associated with a piece of DRM content. DRM content cannot be used without an associated RO and may only be used according to the permissions and constraints specified in an RO. The digital REL selected for version 2.0 represents an extension of the ODRL subset defined in OMA DRM version 1.0.3 _{PKI technology is used by OMA DRM version 2.0, and the con-} tent decryption key is included in the RO so that content cannot be viewed in the absence of its RO.4

Version 2.0 provides new functionality so that content providers can offer the following additional capability to end-users:

• Storage and backup: users can move content and/or rights to remote or removable storage and later restore the rights and/or content to device

3_{By contrast, MPEG-21 [8] selected XML-based eXtensive rights mark-up Language (XrML)} originally developed by ContentGuard.

4_{It should be noted that the public-key encryption algorithm is not part of the OMA DRM spec-} ification. Presumably, this is to allow the standard to migrate to new encryption algorithms if the algorithms behind current implementations become hacked (as were the CSS system in DVDs and the system behind Adobe’s e-Book system).

Section 2.4: EXAMPLE: THE OMA DRM 31

• Multiple devices: users can move content and/or rights between several devices owned by the user (second phone, PC, music player, etc.), thus adding a “domain” concept for sharing between devices

• Copy to secure removable media for a mobile music player • Complementary preview

• Ability to preview superdistributed content before purchase • Export to other copy protection schemes

• Transfer music to DRM-enabled set-top box or computing device

It also provides the following additional protections/capability to content providers:

• Individually encrypted rights using a device’s public key to provide crypto- graphic binding

• Integrity protection for content and rights

• Mutual authentication between device and rights issuer

• Device revocation: rights issuer can identify device revocation status • Rights issuer revocation: device can identify rights issuer revocation status • Secure multicast and unicast streaming

• Metered time and usage constraints • Subscription rights for content bundles • Gifting

• Support for peer-to-peer and messaging

• Superdistribution: viral marketing and reward mechanism

(Please note that the functional requirements alone for version 2.0 are in a stand- alone document 22 pages long, so I am only summarizing some of the high points. Please also note that some functionalities, although allowed, are not described in detail in version 2.0.)

As stated above, the public key encryption technology (and other parts of the so-called “trust model”) used by OMA DRM version 2.0 is not defined in the standard. Four companies (Intel, Nokia, MEI/Panasonic, and Samsung) banded together (February 2004) and created an LLC called the Content Management Licensing Administrator (CMLA) to implement a trust model for OMA DRM version 2.0. Its tasks include

• Issuing, distributing, and management of keys • Issuing, distributing, and management of certificates • Revocation mechanisms

• Defining import/export digital outputs

The CMLA trust model defines a compliant implementation of this specifica- tion for use with a wide variety of digital client devices and applications (e.g., cell phones, PDAs, and PCs). Although the CMLA trust model is not a required part of the version 2.0 standard nor is the ability to provide a trust model for OMA DRM version 2.0 in any way limited to the CMLA alliance, it is not pos- sible to implement the standard without the type of technology provided by the

CMLA trust model. The CMLA technical specifications deal with issues related to distribution and management of keys and certificates issued by the CMLA. Key generation and provisioning must comply with the CMLA-specified secu- rity requirements and involve a compliant central facility for the root Certificate Authority, technical and administrative arrangements for the generation, and distribution of keys and certificates for use by the service providers and client manufacturers. CMLA will generate and distribute millions of keys and certifi- cates. CMLA also maintains a revocation mechanism which makes it possible to prevent further consumption of new content by devices whose keys have become compromised.

2.5 THE MPEG LA®DRM REFERENCE MODEL

My company, MPEG LA, LLC (MPEG LA), is involved with the licensing of technology. When we began looking into DRM applications, we saw that the mar- ket was developing a wide variety of technology systems for a wide variety of applications. Moreover, DRM technologies are covered by many patents owned by many patent owners which implies that a company like MPEG LA could pro- vide a useful market service by providing one-stop licensing for DRM systems. Since we were interested in being the license administrator for as wide a technol- ogy/application base as possible, we wanted to develop a common framework that could be used to cover as wide a set of potential DRM systems and applications as possible. Our hope was that a common framework would allow technology owners and patent licensors to develop license models for DRM technology that would be reusable across systems. Working with a variety of participants in the DRM market, MPEG LA facilitated the development of a “Reference Model” (RM) describing the various principles and functions of a DRM system to support the evaluation of patents for their essentiality and the creation of joint patent licenses for a wide variety of applications [9].

In general, while DRM has the potential to enable new markets, new prod- ucts and services, new revenue, and other growth opportunities, the use of the technology requires separate licenses. The development and deployment might be inhibited without convenient access to essential intellectual property(IP). There is a demand from everyone in the distribution chain who will benefit from these services—content providers, service providers, device manufacturers, and consumers—to address this issue. The DRM RM helps remove the uncertainty surrounding the “patent overhang” by providing the basis for convenient access to DRM technologies through alternative licenses. The terms of any license may be determined only by patent holders with essential IP as identified through a patent submission and evaluation process. Everyone in the distribution chain—content owners, service providers, device manufacturers, and consumers—may benefit.