Chapter 5 Implementation of MPEG-21 IPMP and REL with MPEG-4 IPMPX
5.3 Content protection mechanism
5.3.1 Add one condition, “ExerciseMechanism”
In the REL reference software, only two conditions and one right are supported. To demonstrate our designed system, we define a new condition, “ExerciseMechanism”. This condition provides a description of server which contains server’s URI and parameters. An example of this condition is described as follows:
<r:exerciseMechanism>
<r:exerciseService>
<r:serviceReference>
<sx:wsdlAddress>
<sx:kind/>
<r:serviceParameters/>
</r:serviceReference>
</r:exerciseService>
</r:exerciseMechanism>
Figure 5-16 Example of a condition, “ExerciseMechanism”
In Figure 5-16, a server is described by <sx:wsdlAddress>, which contains an URI to link to this server, and <r:serviceParameters>, the required information necessary to pass to this server. Here, “http://localhost/sxh/EMServer_v1.asp” is an URI to the server. This condition is fulfilled when the verification result parsed from the response of server is true. To adding this condition to our implementation, we write a condition validator,
“validateEMcondition()”, which is integrated into the “validateCondition” module. The dataflow is represented in Figure 5-17. First, the program retrieves the server’s URI and parameters. We use the server’s URI to link to server with server’s parameters. Then, server generates the response to the program according to these parameters. If the connection is successful, the program receives the response and analyzes the state of the response;
otherwise, an error message is returned. If the state is true, the program returns the message which represents successful verification; otherwise, the message that represents false verification or connection error is returned.
No
Figure 5-17 Dataflow of validating the condition, “exerciseMechanism”
The APIs associated with the condition “exerciseMechanism” are listed below.
Method:
HRESULT validateEMCondition(CComPtr<IXMLDOMElement> spEMConditionElt) This function checks to see if the user can exercise the right. This function contacts a web service to verify this. The spEMConditionElt object is content of an
“exerciseMechanism” condition. The method returns S_OK when succeed.
HRESULT accessEMServer(TCHAR *tszPath)
This function accesses the exercise mechanism and, depending on the input parameter of tszPath. The tszPath object is the path to the server. The method returns S_OK when the response of server is true.
Chapter 6 Application Examples
In order to demonstrate the functionalities of our implementation, we design three application examples as follows.
y Online Play: This application demonstrates how to manage the user’s “play” right in a real-time streaming system.
y Preview: This application demonstrates how to manage the user’s “preview” right in a real-time streaming system.
y Super distribution: This application demonstrates how to manage the user’s right in a distributed mobile environment.
Figure 5-8 shows our system. The client side has a DES Decryption Tool and an IPMP_Info_Engine Tool. There is a DES Encryption Tool at the server side. All the application examples have a similar system structure. We first describe the initialization settings in an Initial Object Descriptor for the client terminal of our implementation.
There are three main components in an IOD: IPMP Tool List, IPMP Tool Descriptor, and the IPMP Tool Descriptor in the Elementary Stream Descriptor (ESD). The attributes and settings of these components are shown as follows.
IPMP_ToolListDescriptor {
numTools = 2;
IPMPToolD[0]
{
IPMP_ToolID = [140,113,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1];
isAltGroup = 0;
isParametric = 0;
numURLs = 0;
ToolURL = NULL;
}
IPMPToolD[1]
{
IPMP_ToolID = [140,113,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4];
isAltGroup = 0;
isParametric = 0;
numURLs = 0;
ToolURL = NULL;
} }
There is an IPMP Tool List residing in an IOD. Because the client terminal has two IPMP Tools in our system, there must be two IPMPToolIDs on the IPMP Tool Descriptor List and thus numTools is set to 2. Each IPMPToolD has a unique IPMP_ToolID, because a unique mode is needed to describe the required IPMP Tools for content consumption.
IPMP_ToolDescriptor[0]
{
IPMP_ToolDescriptorID = 1;
IPMP_ToolID = [140,113,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1];
URLString = NULL;
IPMP_ToolID = [140,113,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4];
URLString = NULL;
Because there are two IPMP Tools instantiated in this demonstration system, we need two IPMP Tool Descriptors for them. Although different IPMP Tools can share the same IPMP Tool Descriptor, the IPMP Tools which appear in the demonstration system can be quite different. There are several parameters which can be set at the users’ will, such as IPMP_ToolDescriptorID. In both IPMP Tool Descriptors, the isInitialize is set to 1 to indicate that the IPMP Tools are newly instantiated. The controlPointCode, whose value is 0x01, means that this IPMP Tool are connected to the PreDecoderFilter, and the controlPointCode, whose value is 0x00, means that the other IPMP Tool is not connected to anyplace. And the sequenceCode indicates the order for processing the data. Finally, the IPMPX_data carried by IPMP_Initialize is set as IPMP_OpaqueData to carry the initialization information for IPMP Tools such as the duration for changing keys and initial keys.
ES_Descriptor[0]
The IPMP Tool Descriptor Pointers within the ES Descriptor indicate that the stream described by this ESD is protected by the IPMP Tools listed by the IPMP_ToolDescriptorID.
The relationship between the Tool Descriptor and the Tool Descriptor Pointer is shown in Figure 6-1.
Figure 6-1 Relationship among IPMP Tool Descriptor Pointer and IPMP Tool Descriptor
6.1 Application Example 1 --- Online Play
We design an example, “Online Play,” which demonstrates how to manage the “play”
right in a real-time streaming system. In this example, we want to send a request to a remote server if the principal has the right to play the video file. In addition to provide the result of authorization, the remote server is also a key server. Only the result of verification is true, the correct keys are sent back to the client. Therefore, we design a simple license that describes “the principal can play the resource when online verification is true.” To perform online verfication, the license contains the “exerciseMechanism” condition to store the server address and the server parameters. The “serviceParameters” element in the
“exerciseMechanism” condition contains the parameters that the remote server needs to verify the client’s right. In this example, the “keyholder” (principal) and the “mx:play” (right) are included. This license is shown below.
<license licenseId="Demo1">
<grant>
<keyHolder> … </keyHolder>
<mx:play/>
<digitalResource>
<nonSecureIndirect URI="foreman_qcif"/>
</digitalResource>
<exerciseMechanism>
<exerciseService>
<serviceReference>
<sx:wsdlAddress>
<serviceParameters>
<datum
<keyHolder licensePartId="Alice"/>
</datum>
<datum>
<mx:play/>
</datum>
</serviceParameters>
</serviceReference>
</exerciseService>
</exerciseMechanism>
</grant>
<issuer>…</issuer>
Server Side Network Client Side
Decoder
Play Play
Figure 6-2 System flowchart
The flow of execution is shown in Figure 6-2. First, the client sends a request of playing the video file to the server. Then the server accesses its IOD file, and resolves it to initialize the server’s IPMPX system. After sending the client’s IOD file to the client, the server performs encryption on the video file and sends these protected packets to the client. Before receiving the server’s packets, the client also has to access its IOD file for the initialization of the client’s IPMPX system, and the IPMP_Info_Engine tool gets a license file from an IPMP Tool Descriptor. When the client’s DES tool starts to decrypt data, the IPMP_Info_Engine tool sends a request to call the REL’s API for generating an authorization proof.
The flow of authorization is shown in Figure 6-3 and Figure 6-4. If the user is authorized to play this video, the remote server sends the decryption keys in a protected form to the client.
Then, the received keys are stored in a local file. After reading and decrypting the received keys with the client’s private key, the DES Tool can decrypt the received video packets. The user can now play this video file. Otherwise, if the user is not authorized, our program will halt and request the user for closing the window.
Decoder
Figure 6-3 Flowchart of authorization (request for verification)
Decoder
Figure 6-4 Flowchart of authorization (return the result of verification)
The result of unauthorized access is shown in Figure 6-5. The popup window shows an
error message, “Received IPMP_Info_Engine’s verification result: False.” The video display window is located at the lower left corner, and it does not show any video.
Figure 6-5 Screenshot when the validation result is false
6.2 Application Example 2 --- Preview
In e-commerce, it is popular to allow the consumers to preview video/audio clips in which they are interested. We design an example which demonstrates how to manage the
“preview” behavior in a real-time streaming system.
We assume that the consumers can preview a video clip without having any licenses among the first n macroblocks in our system. Instead of using a license to describe the
“preview” right, we use a counter in the DES Tool to check if all the first n macroblocks of a video file are processed. We add the counter’s information into the opaquedata of the DES Tool’s Tool Descriptor.
IPMPX_data[0]:IPMP_OpaqueData //DES Tool {
opaquedata
= {“number of preview macroblocks”, “duration to change the key”,”initial key”}
};
6.2.1 Procedure
The entire execution procedure is divided into two stages, preview and authorized play.
Their flowcharts are depicted in Figure 6-6 and Figure 6-7, respectively. At the first stage, the user is permitted to play the first n macroblocks freely, and the server sends the unprotected raw data to the client. The client directly plays back the video file without any IPMP process.
Entering the second stage, the server sends the protected packets encrypted by the server’s DES Tool. When the client receives these encrypted packets, the client pops up a window to ask the user to enter the correct license and the query file or to terminate the program. Here, our designed license file is identical to the one in the application example 1.
When both the license and the query file are accessed, the client’s IPMP_Info_Engine Tool is requested to perform authorization. The details of the correct license and the query file have been described in section 6.1.1. If the result of authorization is true, the client program continues to play back the video; otherwise, the program will halt itself, and ask the user to exit.
Server
Controller Client
Controller
Request Request Video, License
ToolDES
Server Side Network Client Side
First N Macroblocks
? Yes
No
Decoder
Play Play First N Macroblocks
Figure 6-6 Flowchart of stage 1 (preview)
Server
Server Side Network Client Side
First N
Figure 6-7 Flowchart of stage 2 (authorized play)
The screenshots are shown in Figure 6-8 and Figure 6-9. In Figure 6-8, the left small window is the video display window, which is playing back the first n macroblocks. The right side window is the “REL_Preview,” which sends requests for entering the correct license and query file. In Figure 6-9, because users choose not to continue watching this video, a caution message is shown in the “Decription tool’s receiving message window,” and the user is asked to close the window.
Figure 6-8 Screenshot_1 in application example 2 (“Preview”)
Figure 6-9 Screenshot_2 in application example 2 (“Preview”)
6.3 Application Example 3 --- Super-Distribution
We design an example, “super-distribution” scenario, which demonstrates how to manage the user’s right in a distributed mobile environment. The idea of this scenario is originated from the OMA DRM v2.0. Figure 6-10 shows that the system is divided into the content provider and the user. The protected content and the rights object can be delivered to the user separably. Each rights object is restricted to one user, and the protected content can be distributed without any constraint. When a user receives the protected content, he or she has to purchase his/her own rights object (license) for consuming the content.
Figure 6-10 Concept of OMA DRM v2.0 [3]
A mobile device may not be always connected to the network. To simulate this situation, we design a license that supports both online and offline verification. The online verification is achieved by a remote server, and the offline verification is achieved by local validation. In Figure 6-11, this license includes two grants, one is for online situation and the other is for offline situation. In this license, Grant 1 describes that “the principal can play back the resource when the online verification is true and within a specific time interval.” Grant 2 describes that “the principal can play back the resource when the offline verification is true and the playing counts doe not exceed five times.”
The condition elements in Grants 1 and 2 are encapsulated in the “allConditions”
element, an “and” logic operation, that every condition element inside has to be satisfied.
Each “allConditions” element represents two condition elements. In Grant 1, one requests the key server for verification and the other validates execution tine. In grant 2, one performs the offline verification and the other validates the counts of offline consumption. The verification flow of this license is drawn in Figure 6-12. Grant 1 is validated first. If one condition in this grant is not satisfied, Grant 1 is unauthorized. Then, Grant 2 is checked. If both Grants are unauthorized, the result of authorization is false.
License
Figure 6-11 Structure of the license of “Super Distribution”
False EL : limited counts
Validate EM2 False
True False
Figure 6-12 Verification flow of conditions in the License of “Super Distribution”
Because the online verification is more secure than the offline verification, we assume that the status of the online verification is a necessary condition of the offline verification. So, our program has to link to the remote server for the verification first, and the remote server returns the decryption keys if the client is authorized. This decryption keys exist only after the remote server has authorized client. We use the decryption keys as a certificate of the online verification. Therefore, the designed offline verification can check the existence of decryption keys to know the status of the online verification. However, this certificate has a finite time span. If Grant 2 is not granted, the online certificate will be deleted.
The designed license is shown as follows:
<license licenseId="Demo 3">
<grant>
<keyHolder> ... </keyHolder>
<mx:play/>
<digitalResource>
<nonSecureIndirect URI="foreman_qcif"/>
</digitalResource>
<allConditions>
<exerciseMechanism>
<exerciseService>
<serviceReference>
<sx:wsdlAddress>
<sx:kind> ... </sx:kind>
<sx:address>
<digitalResource>
<nonSecureIndirect URI="http://localhost/sxh/EMServer_v1.asp"/>
</digitalResource>
</sx:address>
</sx:wsdlAddress>
<serviceParameters>
<datum>
<keyHolder licensePartId="Alice"/>
</datum>
<datum>
<mx:play/>
</datum>
</serviceParameters>
</serviceReference>
</exerciseService>
<keyHolder> ... </keyHolder>
<mx:play/>
<digitalResource>
<nonSecureIndirect URI="foreman_qcif"/>
</digitalResource>
<allConditions>
<exerciseMechanism>
<exerciseService>
<serviceReference>
<sx:wsdlAddress>
<sx:kind> ... </sx:kind>
<sx:address>
<digitalResource>
<nonSecureIndirect URI="file://c:/DecryptedKeys.key"/>
</digitalResource>
</sx:address>
</sx:wsdlAddress>
</serviceReference>
</exerciseService>
</exerciseMechanism>
<sx:exerciseLimit>
<serviceReference>
<sx:wsdlAddress>
<sx:kind> ... </sx:kind>
<sx:address>
<digitalResource>
<nonSecureIndirect URI="file:///./RELExLimitService.dll"/>
</digitalResource>
</sx:address>
</sx:wsdlAddress>
<serviceParameters>
<datum>
<sx:stateDistinguisher>User_Alice</sx:stateDistinguisher>
</datum>
</serviceParameters>
</serviceReference>
<sx:count>5</sx:count>
</sx:exerciseLimit>
</allConditions>
</grant>
<issuer>
<dsig:Signature> ... </dsig:Signature>
<details>
<timeOfIssue>2006-01-27T15:30:00</timeOfIssue>
</details>
</issuer>
</license>
6.3.1 Procedure
To realize the “Super-Distribution” scenario, we modify the client’s computer program to read local files. The modified program structure is shown in Figure 6-13. When the user inputs the protected content (video file), the IOD file having an identical file name will be opened, and the program’s IPMPX system is initialized. The IPMP_Info_Engine Tool is requested for authorizing that the user can play this protected content or not. The details of the authorization process have been described at the beginning of section 6.3. In the following, we explain the run-time processing of our program with several screenshots.
Streamer Decoder Output buffer
Video
File Control
Point Control
Point
Screen
PreDecoder Filter
PostDecoder Filter
Figure 6-13 Modified program structure
First, the user has to choose a piece of local protected content to play. Figure 6-14 shows that “foreman_qcif_asp.enc” is selected. The “connect” button is pressed for starting playing this video. When the DES Tool starts to decrypt data, it has to check the result of authorization. In Figure 6-15, the result of authorization is true when the online verification is successful. Then, the DES Tool also gets decryption keys to decrypt data. Figure 6-16 shows that the user can successfully play back this piece of protected content.
Figure 6-14 Screenshot_1 in application example 3 (“Super-Distribution”)
Figure 6-15 Screenshot_2 in application example 3 (“Super-Distribution”)
Figure 6-16 Screenshot_3 in application example 3 (“Super-Distribution”)
When the network is temporally unavailable, the user wants to play this video again. But, he has been played five times already without connecting to the network. Although the result of the offline verification is true, the “exerciseLimit” condition is not satisfied. The execution result is shown in Figure 6-17.
Figure 6-17 Screenshot_4 in application example 3 (“Super-Distribution”)
Chapter 7 Conclusions
DRM is a critical element in many multimedia systems, such as mobile communications.
As various content delivery applications are getting popular, many DRM systems have been proposed. For example, Microsoft has a DRM system for the “wma” and “wmv” compression formats, and Apple creates a DRM system for its IPOD music player and Itunes software. But, these DRM systems are private and can not communicate with each other. Hence, in our project, we study the MPEG-4 IPMPX system, which is a Digital Rights Management interface defined by MPEG. Our goal is to design a DRM system that can provide functionalities of Content Protection and Rights Management.
Hence, we first study the MPEG-21 IPMP and REL. MPEG-21 IPMP provides a high level protection of Digital Items. MPEG-21 REL is able to describe various rights expressions, and to provide right authorization and control. Because both IPMP and REL are conceptual entities, we choose MPEG-4 IPMPX system as a set of concrete interface specifications for our system. We design MPEG-4 IPMPX compatible tools incorporated with characteristics of MPEG-21 IPMP and REL. We also design an encryption/decryption tool to perform content protection. In addition, we propose a content protection mechanism that combines with the key management for higher security.
Finally, we design three application examples to demonstrate the use of our DRM system.
The example shows the management of play right in a real-time streaming system. The
The example shows the management of play right in a real-time streaming system. The