Condition

A condition specifies the terms, conditions and obligations under which rights can be exercised. A simple condition is a time interval within which a right can be exercised. A slightly complicated condition is to require the existence of a valid, prerequisite right that has been issued by some trusted entity. Using this mechanism, the eligibility to exercise one right can be dependent on the eligibility to exercise other rights.

MPEG REL defines a condition element that encapsulates the information necessary to determine whether the condition is met. Figure 4-7 presents constraint condition that identifies a right may be exercised only 3 times. The prefix sx: in this figure indicates that the elements (exerciseLimit and count) are defined in the MPEG standard extension schema namespace that will be introduced in section 4.3.

Figure 4-6 A constraint condition 4.2.7 Issuer

The issuer element identifies a license issuer who digitally signs a license and provides additional details about its issuance. By signing the license, a license issuer authorizes the grants contained in a license and it can facilitate reliable establishment of trustworthiness of the license.

A license may have any number of issuers, or the element may be omitted entirely. However, no additional semantics is associated with the joint signing; it is as

if each had signed a copy of the License independently. No collective meaning is implied by several issuer elements appearing in a license.

The following figure illustrates how this issuer information is represented in the MPEG REL expression.

Figure 4-7 Issuer

4.3 Extensibility and Profiling

MPEG recognizes that different applications require different levels of

complexity and flexibility in REL and that specific industries and user communities may need to modify the language to better meet their specific needs. To facilitate easy mapping of the REL to these industry-specific applications, MPEG has developed a process of extending and profiling of the language. [8]

The extension process, including developing new verbs and schematic elements, enables individuals to define new elements specific to their requirements to improve efficiency in a specific domain. The syntax of MPEG REL is defined using the XML Schema and Namespace Recommendations by W3C [9],[10], which enables the REL to offer a high degree of richness and flexibility in its extensibility. The following figure illustrates the MPEG REL architecture.

Figure 4-8 Extensibility structure.

These architectural parts: core, standard extension, multimedia extension, and their XML schemas are normative components of the overall MPEG REL

specification.

Core schema defines the general constructs which are essential and form the architectural basis for the language. The namespace for the MPEG REL Core is identified with the prefix “r:”. In some cases, this prefix is omitted.

Standard extension schema defines the concepts that are generally and broadly applicable to the DRM usage scenarios. It extends the condition type in the XrML core. The namespace for the MPEG REL standard extension is identified with the prefix “sx:”. Figure 4-6 is a simple example.

Multimedia extension schema extends the Core schema for concepts (e.g., rights, resources, and conditions) specifically related to the multimedia domain. As shown in Figure 4-4, the namespace for the MPEG REL multimedia extension is identified with the prefix “mx:”.

The extension process enables that the other parties can define their own (possibly domain-specific) extensions to the MPEG REL and its future extensions.

This is accomplished by using the existing, standard XML Schema and XML

Namespace mechanisms. More specifically, extensions to the MPEG REL can define:

1) principals appropriate to specific technical applications; 2) rights appropriate to using specific types of resource, such as play and print; 3) resources appropriate to specific business models and technical applications; 4) conditions appropriate to specific distribution and usage models, such as watermark, destination, and rendering application.

The profile process enables individuals to select only those language elements required to meet a specific application’s need. Many MPEG REL elements and attributes are optional, and their occurrences can be included or omitted in a profile to optimize payload of digital items and computation requirements of MPEG terminals.

For a specific purpose or different devices, this involves the creation of a subset of the language. For instance, the full power of the MPEG REL, which is required by a PC, may not be available for a mobile phone. So a down-size version of this language, a new profile, can be created for this application.

Extension and Profile can be used concurrently to optimize the applicability of the MPEG REL to one specific application.

4.4 Authorization Model

Figure 4-9 Authorization model [4]

The MPEG REL provides an authorization model, as shown in Figure 4-9, to determine if a principal has the right to perform an action on a resource according to the REL expressions in a set of licenses.

The authorization model makes use of an authorization request, an authorization story, authorization context, and an authorizer to create authorization proofs, which define the semantics of licenses for performing authorization requests. Figure 4-10 illustrates the relationship between the entities in the authorization model. An authorization request is permitted if there is one authorization story that provides an authorization proof for the request.

Figure 4-10 The relationships between the entities in the authorization model [11]

Authorization Request

An authorization request contains the information that conceptually represents the question "is it permitted for a given Principal to perform a given Right upon a given Resource during a given time interval based on a given authorization context, a given set of Licenses, and a given trust root?"

Authorization Story

An authorization story is a structure created for the purpose of finding a grant to match the requested permission. An authorization story contains:

y A primitive grant containing no variables, derived from a grant that is authorized by an authorizer and is a part of the set of licenses provided in the authorization request.

y Optionally, an authorizer is a structure containing the information about issuance of the License.

Conceptually, an authorization story contains all the information necessary to state the following fact: “A given primitive grant (i.e., a grant with no variables) may be derived from a given grant authorized by a given authorizer, which identifies a principal from a license at a time instant based on an authorization context and supported by an authorization story.”

Authorization Context

An authorization context is a set of properties that are relevant to an authorization request. A property refers to a truth statement that is used in the evaluation of a Condition. A Condition, which is evaluated based on some authorization context properties, refers to those properties in its semantics. [11]

Authorization Proof

If all the relationships shown by the broken lines are valid in Figure 4-10, an authorization story is said to be an authorization proof for an authorization request.

More specifically, the request is permitted if the following are true: 1) the primitive grant in the story is equal to the principal, right, and resource in the request and its condition is satisfied with the authorization context in the request; 2) the primitive grant must be derived from the grant; 3) the issuance of the grant in the first

authorization story is recursively authorized via an additional authorization story in

the authorizer in the first authorization story; 4) the recursive authorization eventually terminates in one of the trust roots given in the authorization request. [6] When the request is permitted, there shall be at least one authorization story that supports an authorization proof for the authorization request.

4.5 The Relation with The Other standards in MPEG-21

The MPEG-21 REL [4] can declare rights and permissions using the terms as defined in the Rights Data Dictionary (RDD) [12]. The RDD specifies a dictionary of terms and provides a methodology for extending the dictionary to include new terms.

The MPEG REL also can use the Digital Item Identification (DII) [13] to identify digital items described in the language defined by the Digital Item Declaration (DID) [14] and hence specify rights over those digital items. The MPEG REL can also be included in digital item declarations. [6]

Chapter 5 Application Exapmples of the DRM system

In this chapter, we describe our implementations of DRM systems in which we use rights expression languages (REL) to implement an effective digital rights

management (DRM) scheme on a DVB-T platform. In the implementations, we insert the REL license into the service information tables (SI) of DVB and it is broadcasted along with the content carried by the MPEG-2 transport bit stream. When a new TV program begins, a new License is broadcasted.

In order to insert the license into SI, we define a descriptor, license_descriptor, as show in Table 5-1. This license_descriptor has a few attributes and their syntax are defined in Table 5-1. Then, the descriptor shall be inserted into the corresponding descriptor_loop field of the event information table (EIT) as shown in Table 5-2.

Table 5-1 License Descriptor

The descriptor_tag of license_descriptor is an 8-bit field. According to the specification of ETSI EN300 468 [2], the tag value from 0x80 to 0xFE could be defined by user. We define the descriptor tag value of the license_descriptor is 0x80.

The “reserved” bits shall be set to 1. The descriptor_length is a 12-bit field specifying the total number of bytes of the data portion of this descriptor following the bytes defining the value of this field. Note the descriptor_length shall not exceed 4063 so that the entire descriptor has a maximum length of 4066 bytes. The

descriptor_number gives the index of the descriptor. It is used to a license which is cannot be fitted into a single descriptor. The descriptor_number of the first

license_descriptor of an associated set of license_descriptors shall be “0x00”. Within each segment of a license the descriptor_number shall increment by 1 with each additional license_descriptor. The last_descriptor_number specifies the index of the last license_descriptor (that is, the descriptor with the highest descriptor _number) of the associated set of descriptor. A string of “text_char” field specifies the text of a license.

Two DRM applications using this mechanism, broadcasting license within SI tables of MPEG-2 transport stream, are implemented. The first application is Digital TV Conditional Access (CA). We will describe its architecture and the demo system implementation in the next section. In the second application, we use an MPEG-21 REL Reference software to interpret an REL license for managing the right of using the contents. And we will show a “Validity Interval” condition case.

Table 5-2 Event Information Section [2]

5.1 Application One – Digital TV Conditional Access

In general, conditional access system of digital TV follows the classical DVB Condition Access System (CAS) mechanism as described in section 2.3. The Entitlement Control Messages (ECMs) and Entitlement Management Messages (EMMs) are broadcasted. They carry the information for decrypting the content.

In this application example, we present how to use REL license to implement another conditional access scheme. This implementation uses cryptography and key management machine to protect content from illegal access.

5.1.1 Cryptography

We use two security techniques including symmetric and asymmetric cryptography to encrypt content in this implementation.

5.1.1.1 Symmetric Cryptography

Symmetric cryptography, also called secret key cryptography (SKC) or private key cryptography, is the most popular of cryptography method. With symmetric cryptography, a single cryptographic key is used for both encryption and decryption.

As shown in Figure 5-1.A, the sender uses a key to encrypt the plaintext and sends the cipher text to the receiver. The receiver must apply the same key to decrypt the

message and recover the plaintext. Symmetric algorithms generally can be divided into stream ciphers and block ciphers. Stream ciphers encrypt a single bit (byte or computer word) of the message at a time and implement some form of feedback mechanism so that the key is constantly changing. The most widely used stream cipher is RC4 (Rivest Ciphers) algorithm. In Block ciphers a key and algorithm are applied to blocks of data rather than individual bits in a stream. Data Encryption Standard (DES) and Advanced Encryption Standard (AES) are the common block encryption algorithm.

Here, we will introduce the RC4 algorithm we used in this implementation. RC4 was developed by Ron Rivest in 1987. It is a stream cipher. This means it essentially functions as a random number generator whose output is combined with the plaintext by using XOR.

Figure 5-1 Cryptography [15]

RC4 has two stages in the procedure of generating random numbers. The first stage is the key-scheduling algorithm (KSA). It initializes a permutation (denoted “S”

below) based on a variable length key. The algorithm is described below.

for i = 0 .. N-1 S[i] = i;

j=0;

for i = 0 .. N-1

j=j + S[i] + K[i % 1];

Swap (S[i], S[j]);

After initialization, the second step is the pseudo-random generation algorithm (PRGA). It actually returns a random byte. Here is the algorithm.

i = j = 0;

i = i+ 1;

j= j + S[i];

Swap (S[i], S[j]);

return S[ S[i] + S[j] ];

The return value is XORed with the plaintext to produce the ciphertext, or the ciphertext to produce the plaintext.

5.1.1.2 Asymmetric Cryptography

Asymmetric cryptography, also called public key cryptography (PKC), was invented by Diffie and Hellman in 1976 [16]. The essential difference to symmetric cryptography is that this kind of algorithm uses two different keys for encryption and corresponding decryption. As shown in Figure 5-2.B, public key cryptography allows users to communicate securely without having to share a secret key by using a pair of cryptographic keys, designated as public key and private key, which are related mathematically. One key is used to encrypt the plaintext and the other key is used to decrypt the cipher text. Which key is applied first is not important. Who has the private key can share the related public key to others, but the private key can not be known by anyone.

RSA is the best known and most frequently used reversible asymmetric algorithm. It is named for its inventors Rivest, Shamir and Adelman [17]. The algorithm is described below.

E is known as the public exponent or encryption exponent.

D is known as the secret exponent or decryption exponent.

2. Encryption

Let Pi is the block of plaintext message and its length is smaller than phi(n).

The encrypted text Ci is calculated from the equation Ci ≣ Pi^E mod(n).

3. Decryption

We calculate Pi = Ci^D mod(n).

5.1.2 Key Management

This section presents a key management mechanism which is used within the conditional access scheme. The key management mainly uses a trans-encrypting operation. The entire scheme of this conditional access application is composed of a service provider, receivers, and a license server, as shown in Figure 5-2.

Figure 5-2 General idea of the conditional access scheme

Service provider broadcasts a scrambled TV program and its associated REL license to receiver. The scrambling key used to encrypt the TV program is encrypted by the license server’s public key and put into the license. Here we use RC4 and RSA algorithms to scramble the program and encrypt the RC4 scrambling key, respectively.

In addion to the encrypted scrambling key, this license also contains the license server information. Using the license information, the receiver send a request to the license

server for the scrambling key. This message includes both the encrypted RC4 key and receiver’s name. The license server will check if the receiver has the right to watch the program or not. If the receiver has the right to watch the program, the license server does two things. It first decrypts the RC4 scrambling key by using its own private key. In order to protect the RC4, the license server encrypts the scrambling key by using the receiver’s public key to ensure the receiver’s identity.

Figure 5-3 Key management procedure

Figure 5-3 shows how the keys are exchanged. According to our proposal, the content scrambling key is inserted into the license information carried by the content bit stream. Therefore, we can reduce the real-time synchronization requirement imposed on the communication between the service provider and the license server.

Typically, the scrambling key is changed very frequently, for example, once per second.

5.1.3 Architecture Design

Figure 5-4 is the overall architecture of this conditional access scheme. There are mainly three parts: Service Provider, Receivers, and License Server. We now

elaborate on their structures and operations.

5.1.3.1 Service Provider

The service provider part acts as a transmitter for transmitting the DTV broadcast and the related information. As shown in Figure 5-4, the service provider broadcasts a scrambled MPEG-2 video elementary stream and its associated REL license to

receivers. The scrambling key is encrypted by the license server’s public key and then is inserted into the REL license. The syntax of the license is based on the MEPEG-21 REL[4], Digital Item Declaration (DID) [14], and Digital Item Identification (DII) [13]. In addition to the encrypted scrambling key, the license also contains the license server’s information. In the service provider part, this license is inserted into the service information table (SI). The multiplexer takes in the encrypted MPEG -2 stream and converts it into a transport stream with the SI. Then, the consumers can use a DTV Card to receive the broadcast programs. The functionalities of each component are described below.

Scrambler: The Scrambler encrypts the data. Typically a cryptography is

adopted for its simple operation. The algorithm used to encrypt the data in this application is RC4 stream encryption algorithm. The key used to encrypt the content is called the scrambling key.

Figure 5-4 Architecture of the conditional access scheme on DVB-T system

RSA Encryption: It is responsible to encrypt the scrambling key by using an

asymmetric cryptography structure. The input, scrambling key, is encrypted by the license server’s public key. When the user contacts the license server, the scrambling key is encrypted by the user’s public key. The algorithm used in this application is the RSA asymmetric encryption algorithm.

SI Editor: The SI editor is responsible to edit the EIT tables. First, a REL license

is segmented into license_descriptors according the syntax in Table 5-1. Then, the descriptor is inserted into EIT as show in Table 5-2. Finally, in order to be multiplexed into a transport stream later, the EIT is packetized and the data is stored in the

transport packets.

Multiplexer:Multiplexer multiples MPEG-2 video bit stream with program service information (PSI) and service information (SI) and produces the MPEG-2 Transport (ISO/IEC 13818-1) streams.

DVB Modulator: It converts the transport stream to an analog signal so that we can broadcast it.

5.1.3.2 Receiver

The receiver part is responsible to receive and decode a digital video broadcast program transmitted by the service provider and render it by a display device such as a television or a monitor.

The architecture of the receiver is shown in Figure 5-4. Before descramble the MPEG-2 video stream, the license shall be parsed for generating a message to request for the content scrambling key. The request message includes the information

extracted from the received license. The message contains the receiver’s name for identification, the identifier of the MPEG-2 digital content, the right that the consumer wants to exercise, and the content scrambling key encrypted by the license server’s public key. For security reason, the license server will send the content scrambling key encrypted by the receiver’s public key if the consumer was authorized to consume the digital content by the license server. So, the receiver needs to decrypt the

scrambling key by the receiver’s private key after receiving the key from the license server. Finally, the consumer can descramble the TV program for decoding and displaying.

The functionalities of each component are described below.

Demultiplexer: It takes in the MPEG-2 transport stream from the server provider and demultiplexes the bit stream based on packet IDs (PIDs).

SI Parser: It retrieves the SI tables from an MPEG-2 transport stream and parses

SI Parser: It retrieves the SI tables from an MPEG-2 transport stream and parses