Chapter 5 MPEG-4 IPMP Extension System Implementation on MPEG-21 Test Bed
5.2 Design and Implementation of Software
5.2.4 IPMP Filter
The relationship between IPMP Filter and other modules is shown in Figure 23.
The IPMP Filters serves as the IPMP Control Points in the IPMP system within the MPEG-21 Testbed. It supports that the user could add or remove the IPMP Tool in the IPMP Filter. There are three IPMP Filters in MPEG-21 Testbed system, one at the server side, and the other two at the client side. At the server side, in order to perform the encryption on the media content bitstream, we allocate one IPMP Filter at the location between two modules, DIA and Streamer. It is called the PostDIAFilter in the Testbed system. However, the PostDIAFilter here allows user to add IPMP Tools, whose functions are other than encryption.
What kind of the IPMP Tool should be used is an application issue.
Since the encryption is performed at the server side, there must be one corresponding IPMP Filter to perform the functionality of decryption at client side. So, we locate an IPMP Filter between the Decoder and the Stream Buffer. It is called PreDecoderFilter. Because the output data of the module, DIA, is in the bitstream format, and we do the encryption at the
bitstream level, therefore, the PreDecoderFilter is located here to decrypt the data at the same level.
Figure 23 Relationship between IPMP Filter and other modules
There is another IPMP Filter, PostDecoderFilter, located between the Decoder and the Output Buffer. With this IPMP Filter, the functionality of extract watermarking from a decoded bitstream data can be implemented. Note that there is no corresponding IPMP Filter of the PostDecoderFilter at the server side because we assume that the insertion of the watermarking is done offline. There could be other possible use of the IPMP Filters in different combination, and it is an application issue. Here we will show one possible application of them.
Because the data before being processed by the Filter and the data after being processed may have different size, we design an API, ProcessData(), which has five parameters. The caller of the API specifies the size of the input data for processing and the data buffer. After processing the data the caller could get the processed data from the out_data_ptr with its size specified in out_size_ptr. For example, there is one DES decryption tool in the PreDecoderFilter, and the DES tool decrypts the data block by block. However, the size of the bitstream data may not be multiples of blocks, so there may exist blocks with zero padding.
When the DES tool decrypts a block with zero padding, it returns the data with the size differ from the original block size, which is the input data size, ProcessData(). In order to solve this problem, we need an API, ProcessData(), as described bellow.
The APIs associated with the IPMP Filter are listed bellow.
Method:
int AddTool(IPMPTool* tool, uint8 sequence_code)
Add the given IPMPTool to the filter. The tool object is an initialized IPMPTool, and the sequence_code specifies the priority of the tool. A higher value of sequence_code denotes higher priority when processing data. This method returns zero when succeed.
int RemoveTool(IPMPTool* tool)
Remove the specified IPMPTool from the filter. The parameter tool specifies the IPMPTool to be removed. This method returns zero when succeed.
int ProcessData(uint32 timestamp, uint8* in_data, uint32 in_size, uint8** out_data_ptr, uint32* out_size_ptr)
This method iterates through each contained IPMPTool and chained all data processing operations to produce the final result. The in_data is the input data buffer of length in_size. The created output buffer is returned in out_data_ptr with length out_size_ptr.
This method returns zero when succeed.
In the current implementation of IPMP system embedded in the MPEG-21 Testbed system, since the IPMP Filters are connected to the Streamer at the server side and to the Decoder at the client side, the caller of the API, ProcessData(), should be the Streamer and the Decoder. At the client side, the Decoder acquires the bitstream data from the Stream Buffer by calling the API, GetBitstreamData(). After receiving the bitstream data from the Stream Buffer, Decoder sends data to PreDecoderFilter before decoding the data. The data decoding process should take place after the data are returned by the PreDecoderFilter. Before the decoded data being sent to the Output Buffer, the Decoder sends them to the PostDecoderFilter first. After getting the returned processed data, Decoder sends them to the Output Buffer. The scheme of processing the bitstream data at client side is shown in Figure 24.
StreamBuffer Decoder
OutputBuffer PreDecoderFilter
PostDecoderFilter
1.1. GetBitstreamData()
1.2. ProcessData()
3.1. ProcessData() 3.2. WriteDecodedData() 2. Decode()
Figure 24 The procedure of processing data by IPMP Filter at client side
At server side, the Streamer gets the bitstream data from DIA by calling the API of DIA named GetNextResourceUnit(), and then sends the data to PostDIAFilter for processing right away. After getting the data returned by PostDIAFilter, the Streamer begins to process the bitstream data. The detail scheme is shown in Figure 25.
DIA
PostDIAFilter
Streamer
1. GetNextResourceUnit()
2. ProcessData()
Figure 25 The procedure of processing data by IPMP Filter at server side
There may be multiple IPMP Tools within one IPMP Filter, so we design an IPMPToolChain to record the IPMP Tools within the IPMP Filter. As described before, the order of processing data is specified by the sequence code, and the IPMP Tool with higher sequence code processes the data first. The procedure of processing the bitstream data could be written as the pseudo codes bellow.
for (sequence_code=255; sequence_code >=0; sequence_code - -) { IPMPTool* tool = GetIPMPToolChain()[sequence_code];
if (tool != 0) {
if (first_flag != 1) {
clear_the_buffer();
set_in_out_buffer();
} else {
first_flag = 0;
}
tool->ProcessData(timestamp, cur_in_data, cur_in_length, &cur_out_data,
&cur_out_length);
} }
5.2.5 IPMP Tool
The relationship between IPMP Tool and other modules is shown in Figure 26.
Figure 26 Relationship between IPMP Tool and other modules
In order to make the design and implementation of the IPMP Tools more flexible, here we design the IPMP Tool with the highest principle of simplicity. This class is designed as the basis interface of an IPMP Tool. An IPMP Tool, for instance, the DES decryption tool, may process the bitstream data in an ES. Thus, the ProcessData() API is a part of the basic
interface of an IPMP Tool. And, the concept of designing this function is the same with the one of the IPMP Filter.
An IPMP Tool should also have the capability to receive the message routed by the Message Router. However, the procedure of processing the received message is the implementation issue and hence we ignore it here.
The APIs associated the IPMP Tools are listed bellow.
Method:
int ReceiveMessage(IPMPToolMessageBase* msg)
This API is called by the MessageRouter to pass a message to the IPMPTool object. The parameter msg is the IPMP message to be handled by this tool. The function returns zero when succeed.
int ProcessData(uint32 timestamp, uint8* in_data, uint32 in_size, uint8** out_data, uint32* out_size)
This API is called by the IPMPFilter to process the given data. The parameter in_data, is the input buffer of length in_size. The indirect pointer **out_data returns a pointer to the processed data, and the size returned as out_size. The output buffer should be created during the invocation of the method, and should be released somewhere else. The IPMPFilter should take care of the release operations, except the last output buffer of the IPMP tool chain. The function returns zero when succeed.
void Initialize(IPMPToolDescriptorD* init)
Initialize the IPMPTool by the given init object. This method is called by the ToolManager after this tool object is instantiated.
IPMPContext* GetContext()
This API provides means to access the corresponding context. All IPMP objects can refer to each other by navigating through the context tree.
In the current implementation, we implement a pair of DES tool, one for encryption, and the other for decryption. The basic feature of DES algorithm is that it is the block cipher
cryptographic primitives. It provides many implementations of cipher algorithm such as AES (Rijndael), DES, and many other different algorithms in cipher. And the library provides both stream cipher and block cipher. However, in our implementation, because we focus on the IPMPX system design, not the design of encryption algorithm. We choose the one for easiest implementation, the DES block cipher.
Figure 27 Flow chart of IPMP DES Tool
The DES cipher algorithm has been implemented in the library, crypto++. Its default block size is 8 bytes, and the default key is also 8 bytes, too. Because these IPMP Tools are associated with DES block cipher algorithm, when the data are processed, the data have the size of multiples of block. Therefore, we design a simple buffer in the IPMP Tools to buffer the tailing data whenever the accumulated data have the size as multiples of a block. In order
to perform the real-time encryption at server side, we design the DES encryption tool with the ability to generate the new key and send the new key to the decryption tool.
The flowchart of the current implementation of the IPMP Tools with the DES block cipher algorithm is shown in Figure 27.
Chapter 6 Demo
In this chapter, we design an application example of MPEG-4 IPMPX system and implement it. Here we only describe the client side of the MPEG-21 Testbed as our testing environment and omit the server side and of network. Oenerally, to test the functionalities of IPMPX system, it is sufficient to look at the client side only.
6.1 Structure
Figure 28 System diagram of our application
In this demonstration, we build up the system as shown in Figure 28. This demonstration
is designed to test the functionality of IPMPX system for Conditional Access (CA).
The Decoder here is an active device. It acquires the bitstream data from the Stream Buffer and writes the decoded data to the Output Buffer. Before decoding data, the Decoder asks the PreDecoderFilter to process these data. After writing data to the Output Buffer, It first as the PostDecoderFilter to process these decoded data. In this application, there are two threads, the decoder thread and the thread for displaying the frame.
There are two IPMP Tools in the PreDecoderFilter, Key Tool and DES Decryption Tool.
The Key Tool is to read the key and send the key to DES Decryption Tool through IPMP messages. The DES Decryption Tool is to decrypt the data. It is empty in the PostDecoderFilter hence data processed by the PostDecoderFilter are unchanged.
6.2 Setup
We first offline encrypt a bitstream and store the bitstream in a media file. During the encryption of the bitstream, the encryption procedure changes the encryption key periodically, that is, one new key for a fix number of blocks. The key is generated by a random function.
The key list is stored in a key file for decryption. These jobs are done prior to testing the IPMPX system as shown in Figure 28.
Except for the key file and the media file, there is still one important piece of data that has to be prepared, the Initial Object Descriptor file. There are three main components in the Initial Object Descriptor: IPMP Tool List, IPMP Tool Descriptor, and the IPMP Tool Descriptor in the ESD. We must set up these three pieces of information. The attributes and parameters of these three components are shown bellow.
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;
There is one IPMP Tool List in the Initial Object Descriptor. Because there are two IPMP Tools in this demonstrating system, there must be two IPMPToolDs on the IPMP Tool Descriptor List and numTools is set to be 2. Each IPMPToolD has its own unique IPMP_ToolID within, which means that we use a unique mode to describe the required IPMP Tools for content consumption.
IPMP_ToolDescriptor[0]
opaquedata = {“duration to change the key”, “Initial Key”, “corr_tool”}
};
opaquedata = {“duration to change the key”, “Initial Key”, “corr_tool”}
};
}
numOfData = 0;
IPMPX_data = NULL;
}
Because there are two IPMP Tools instantiated in this demonstrating system, we need two IPMP Tool Descriptors for them. Although there may be multiple IPMP Tools sharing the same IPMP Tool Descriptor, the IPMP Tools appear in the demonstrating system are quite different. The IPMP_ToolDescriptorID could be set at the users’ will, so we assign the value to them as we wish. In both IPMP Tool Descriptors, the isInitialize is set to 1 to indicate that the IPMP Tools are newly instantiated. The controlPointCode here are set to 0x01, which
sequenceCode indicates the order for processing the data. Finally, the IPMPX_data carried in IPMP_Initialize is set as IPMP_OpaqueData to carry initialization information for IPMP Tools such as the duration for changing keys.
ES_Descriptor[0]
{
ES_ID = 0;
IPMP_ToolDescriptorPointer[0]
{
IPMP_ToolDescriptorID = 1;
}
IPMP_ToolDescriptorPointer[1]
{
IPMP_ToolDescriptorID = 2;
} }
IPMP Tool Descriptor Pointers within the ES Descriptor indicate that the stream described by this ESD is protected by the IPMP Tools indicated in the IPMP Tool Descriptors pointed by them. The relationship among these pointers is shown in Figure 29.
Figure 29 Relationship of various pointers in the demonstration system.
6.3 Execution
First, the Terminal accesses the Initial Object Descriptor in the IOD file, and resolves it.
Then it passes the IPMP Tool List Descriptor to the Tool Manager and passes the IPMP Tool Descriptor and ES Descriptor to the Message Router. Tool Manager parses the IPMP Tool List Descriptor to resolve the Tool IDs of the required IPMP Tools for content consumption and then build up the IPMP Tool map. Message Router parses the IPMP Tool Descriptor to get the information for initialing of IPMP Tools. Besides, Message Router parses the IPMP Tool Descriptor Pointer in ESD to connect the required IPMP Tools to the locations specified in the IPMP Tool Descriptor. During the procedure of setting up the IPMP system, the context tree is built for navigation in the following steps.
The behavior of these modules, Message Router, Terminal, and IPMP Tools, in the IPMP system after setting up the IPMP system is shown in Figure 30.
Figure 30 Messaging routine in the demonstration system
In order to enable passing messages between the key tool and the DES description tool,
the key tool generates an IPMP message with type GetToolContext and sends it to the Terminal for querying the IPMP Tool with the IPMP Tool Descriptor specified in the message.
Then, the Terminal processes the message and retrieves the context tree for the context ID of requested IPMP Tool. If found, the Terminal will generate the IPMP message with its type as GetToolContextResponse and send it back to the IPMP Tool, which requests the context ID.
After getting the context ID of the DES decryption tool, the key tool informs the DES decryption tool to change the key through the IPMP messages. The key tool inserts the key data into the IPMP opaque data as a message and sends it to the DES decryption tool. If the key is incorrect, the user can only view the video at very low quality or nothing at all.
However, if the negotiation of the IPMP Tools is not successful, the key tool will hold the bitstream such that the user sees nothing in the display window.
Figure 31 Screenshot_1 of demonstration system
As shown in Figure 31, the window with title “- ASP - Test” is the one for displaying.
And the message box shows the current status of processing. The main window of the entire system is the one at right side. Entire process begins when user clicks the “Play” button.
Figure 31 is the screenshot before displaying the media data. Hence, there is nothing in the displaying window.
Figure 32 Screenshot_2 of demonstration system
The screenshot during displaying is shown in Figure 32. And the processing steps are also shown in the message box. The message in the current message box indicates that the Key Tool sends the key data to the DES Decryption Tool. And the content of the key is “52 90 49 F1 F1 BB E9 EB”.
When the DES Decryption Tool decrypts data with incorrect key, the decrypted data are viewed as lost packets by the Decoder. Hence the Decoder does not decode these data and holds the process until the key is correct. When the key data is correct again, the Decoder decodes these data again. Because of the lost data, the frames shown in the window are fractured. We show this condition in Figure 33
Figure 33 Screenshot_3 of demonstration system
Figure 34 Screenshot_4 of demonstration system
If the key is continuously correct for a certain time, the frames will be reconstructed gradually as show in Figure 34. However there is only one “I frame” within entire sequence, hence the reconstructions of the frames are slow. That is, we can not get the perfect frame immediately when we get the correct keys.
Chapter 7 Conclusion
Because the issues of Digital Rights Management become more and more important, there are many companies that begin to develop their own Digital Rights Management systems, such as the Microsoft Media Digital Rights Management systems. However, the DRM systems come from different companies can not provide interoperable services among them. Therefore, it is a trend to standardize the Digital Rights Management interfaces and systems. The IPMPX system is an example of standardized Digital Rights Management systems with powerful functionalities.
The advantages of using the IPMPX system for industry and the end users are as follows.
Many DRM solutions use similar or same tools for a number of functionalities. For example, many different DRM systems use the same encryption algorithm. However, because there are no specifications on the interface of these tools, they can not be reused in another DRM system. Using the standardized IPMPX system could reduce redundant implementation and thus can facilitate the design and distribution of tools.
The MPEG IPMPX system provides a common ground for mutual authentication of IPMP Tools and Terminals such that the IPMP Tools and the Terminals can communicate with each other through the secure authenticated channel. The mutual authentication can also verify the trusty relationships between IPMP Tools and the Terminals.
In the MPEG IPMPX system, the IPMP messages are clearly defined and so are the interfaces. Thus, the points of non-interoperability are clearly specified allowing industry to further minimize incomparable issues.
From the application view point, the renewability of a DRM system must be provided.
The IPMPX system could verify the validity of certificates and credentials by using the
The IPMPX system could verify the validity of certificates and credentials by using the