Conclusions

We make a summary of the DRM switching scheme 2. This DRM switching scheme is similar to a recursive DRM system. In our design, the bootstrap must verify the package and derive the real rights object. We can view this as the first DRM system.

And then, the module uses the real rights object to access the content. We can view this as the second DRM system.

To avoid confusion, we provide two viewpoints. From a simple viewpoint, the bootstrap is mainly responsible for the verification of the package. Then, the bootstrap derives the sensitive information from the package and passes it into the module. We can define this information as a key and the module as a tool for the decryption of the encrypted contents. This mechanism is similar to the IPMP system. They both adopt the downloadable mechanism of the tool. Figure 5-8 shows the simple concept of DRM switching scheme 2.

Figure 5-8 Simple Concept of the DRM Switching Scheme 2

However, from the complicated viewpoint, the bootstrap is mainly responsible for

the verification of modules. The bootstrap derives the sensitive information from the package and passes it into the module. We can define the sensitive information as the real rights object associated with the content and the module as a DRM system. Thus, the bootstrap can load the module to access the content with the real rights object. In this architecture, we transfer the downloadable mechanism of the tool to the DRM system. Figure 5-9 shows the sophisticated concept of the DRM switching scheme 2.

Figure 5-9 Sophisticated Concept of the DRM Switching Scheme 2

Therefore, we give a simple concept to build the DRM switching system. Users do not need to understand which DRM system is valid for the content. They only need to choose the contents. Then, the bootstrap will automatically choose the valid DRM system. In other words, the bootstrap provides a DRM switching interface. Since the bootstrap is an interface, the format of the package and the content must be defined. But, we do not define the sensitive information of the package. Thus, all kinds of the DRM system can be adopted in this design. Besides, when the module uses the sensitive information to access the content, these process are invisible. This design also enhances the security of the DRM system.

Chapter 6 Implementation and Application Examples

In this chapter, we describe our implementation of our DRM switchable system on the embedded device. Because we choose the SPCE3200 embedded evaluation board, we make use of its nice properties in implementing our design. Here, we will describe our implementations in details. And, we give the execution flow in our design. Finally, we provide some application examples to demonstrate its usefulness.

6.1 Implementation

6.1.1 Cryptographic Algorithm

Any DRM system uses the cryptographic algorithms. Because we follow the OMA DRM system ideas in designing our DRM switchable system, we adopt some cryptographic algorithms used by the OMA DRM. The adopted algorithms in implementation are listed below.

(1) Hash algorithm : SHA-1

(2) MAC algorithm : HMAC-SHA-1 (3) Asymmetric algorithm : RSA-PKCS1 (4) Symmetric algorithm : AES, DES (5) Signature algorithm : RSA-PKCS1

Hash algorithm uses a mathematical transformation to irreversibly encrypt the binary information. MAC algorithm uses a similar function but it accepts an input as a secret key. Asymmetric algorithm uses one key for encryption and the other for decryption. On the other hand, symmetric algorithm uses a single key for both encryption and decryption. Finally, the signature algorithm uses the hash function and the asymmetric algorithm to verify a signature.

In our design, we port the symmetric algorithms (AES and DES) from the MPEG-21 Testbed [15] into our program. The other algorithms come from the XySSL [16]. The XySSL provides the free software including the hash function and public-key cryptographic. However, because we develop a DRM system on an embedded system, we must care about the problem of the limited resource environment. Therefore, we modify some functions to fill the bill. In order to reduce the complexness, we modify the length of the key. The length of our key is 36 bytes. In addition, we must care about the memory allocation. When the cryptographic algorithms are adopted by our system, it needs to allocate some memory. Thus, we must prepare for that requirement before we develop our design.

Here, we describe how to integrate these algorithms into our system.

z Hash algorithm

In our design, we need to confirm the relationship between the rights object and the content and verify the integrity of the content. We use the hash function to achieve this purpose. At first, the hash value of the content has been stored in the rights object. Thus, if we want to verify the relationship, we only need to use the hash function to get the hash value of the content and check it with the record of the rights object.

z MAC algorithm

In our design, we use the MAC hash algorithm to verify the integrity of <ro> and the key confirmation. Because the MAC algorithm is a kind of the hash algorithm, it can also verify the integrity. But this algorithm needs an input key. Thus, we use this algorithm to achieve those two purposes. The <mac> of the rights object stores the MAC hash value of the <ro>. Then, we can use the MAC hash algorithm to get the hash value of the <ro> and check it with the record of the <mac>. Only when the input key is valid and the <ro> is not modified, the check is passed. Therefore, this MAC algorithm can verify the integrity of <ro> and the key confirmation at the same time.

z RSA algorithm

The RSA algorithm is used by two schemes. One is the signature scheme. The other is the encryption scheme.

The signature scheme uses the hash function and the RSA algorithm to verify a signature. The RSA algorithm uses a pair of public and private keys. We first describe how to generate a signature. We get the hash value of the information to be transmitted by the transmitter. Then, we encrypt the hash value with the transmitter private key. This is the signature of the information. When a receiver wants to verify the signature, it must use the transmitter public key to decrypt the signature and check it with the information hash value. Therefore, this scheme is a mechanism of digital signature.

The encryption scheme uses also the RSA algorithm for the protecting the information. Here, we shall describe how to protect the information which will be transmitted by the transmitter. We encrypt the information with the receiver public key.

When the receiver wants to get the original information, it decrypts the encrypted information with its private key. Therefore, this scheme ensures that only the valid receiver can recover the information.

6.1.2 GUI Interface

Now, we introduce our GUI interface to users in our design. Because there is no operation system in the SPCE3200 board, we must use its libraries to implement our GUI interface. We first study its libraries. They support the joystick library and some application examples. We use those examples to design our GUI. And, we use the joystick library to control the input. Then, we combine them to design our GUI interface.

But, because our design focuses on the DRM system, we only implement a simply GUI interface for demonstration purpose.

We draw some symbols which represent the alphabets and the numbers. We control the TV encoder buffer and fill up it with our symbols. So we can implement the function of printing the string. Besides, because we use the library to control the joystick, we can

implement the function for the user to select choices. The following functions are examples.

♦ V_GUI_Show_Message(char* str);

This function can show a string on the screen.

♦ V_GUI_Check_Message(char* str);

This function can show the string and wait for users to check it. When the user wants to check this message, he/she must push the button. Then, the program can continue to execute.

6.1.3 Real-time Player

Now, we describe our implementation of the real-time player. We implement a player which can decrypt and decode the encrypted content at the same time. At the beginning, we study the example code provided by the Sunplus. In chapter 2, we know the software structure of the MPEG Codec. Here, base on the MPEG software structure and we modify it to achieve our goal. Now, the software structure is shown in Figure 6-1.

1. Read file to buffer D

2. Prepare to decode from buffer C 3. Start to decode buffer C

1. Read file to buffer C

2. Prepare to decode from buffer D 3. Start to decode buffer D

1. Control the interval Decrypt

Decrypt

Figure 6-1 Procedure of buffer control during decoding

There is a pair of parallel procedures for decoding the content in the software structure. In this procedure, we read the media objects and put into one buffer and then prepare to decode media objects from the other buffer. After all the registers related to decoding are set, we start to decode one frame. At this point, the interrupt (timer) controls the interval between frames. Only at the end of the interval, we can read media objects into the other buffer. In other words, the two parallel procedures take turns to be used for decoding the media objects. In our design, we insert the tool for decrypting the encrypted content before reading the file into the buffer. Therefore, we implement the real-time player which can decrypt and decode the media objects at the same time.

6.1.4 Download Mechanism

In our design, we adopt the download mechanism to implement the DRM switchable system. Now, we describe the implementation. Because the SPCE3200 is an embedded system without operation system, we must allocate the memory by hand.

First, we implement the bootstrap and store it in the nor-flash. So, when the SPCE3200 is set to free run mode, this bootstrap will be loaded to SDRAM and start to execute.

On the other hand, we implement the download mechanism in the bootstrap.

Before the bootstrap loads the module, we must allocate memory for the bootstrap and the module. The memory allocation is shown by Figure 6-2.

Figure 6-2 Memory allocation of loading Module

The bootstrap program contains a few sections, which include the text section, the data section and others. We must specify their address in the memory. Besides, the module must be pre-build and their allocation must be consistent with the bootstrap. We specify that the text section of the module follows the text section of the bootstrap and the data section of the module follows the data section of the bootstrap. Then the bootstrap, based on the specification, loads the module into the memory. Therefore, when the bootstrap wants to execute the module, it transfers the control to the module.

In other words, the program counter branches to the text section of the module, so the module can execute and access the contents.

6.2 Simulation

Our switchable DRM system is designed based on the OMA DRM. However, because of the limited resource environment of an embedded system, we can not implement all functions. In order to prove that our design is practicable, we modify some functions or provide substitutes for those functions. Now, we discuss the difference between the OMA DRM system and our DRM system.

In the OMA DRM standard, the Rights Object Acquisition Protocol (ROAP) is defined. It is used for registration of a Device with a Rights Issuer and to process the requests and acquirements of the Rights Object. In other words, the network transmits these messages according to the ROAP.

However, because we cannot use the network in the SPCE3200, we use SD card to get the packages, the modules and the contents for the moment. As regards to the acquirement of the package and the module, we omit the mechanism of the ROAP. In our scheme, we assume that a bootstrap and a package issuer can somehow identity each other in a trusted way. Similarly, we assume that a bootstrap and a module issuer can somehow identity each other in a trusted way. Therefore, we design a flow chart for requesting the package and the module as shown in Figure 6-3.

Figure 6-3 Simulation of execution flow

At the beginning, users insert the SD card containing the contents into the embedded device (SPCE3200). Then, if the bootstrap does not detect an associated package and module, it transfers the information of the platform to the SD card. Users can take the information of the platform on the SD card to request for the associated package and module from their issuers. After verifying the identification, the package and module issuers transfer the package and the module to the SD card. Finally, users

can insert the SD card into the embedded device. Then, because a bootstrap and those issuers have identified each other in a trusted way, a bootstrap can ensure that the package and the module are generated by valid issuers. Therefore, users can access the contents.

The foregoing is a substitute for the ROAP for the moment. In the future, when the embedded device is able to connect to the internet, we can supply those functions.

6.3 Application Examples

In this paper, we design a DRM switchable system and implement it. Now, we show five examples to demonstrate our design.

z Example 1

This example shows the normal access of the protected content. We create a content, an associated module and a associated package. Then, after verifying the package and the module, our DRM switchable system can normally load the DRM program into the device and run it. Then, after verifying the rights object, the DRM program decrypts and decodes the content at the same time. Figure 6-4 shows the result of this example.

Figure 6-4 Normal access of protected Content

z Example 2

This example shows the normal access of the original content. This example is the same with the example 1 except for the content data. We do not protect this content, so this content is not decrypted. Thus, the DRM program within the module only needs to decode it for content consumption. Therefore, the DRM program serves only as a player.

Figure 6-4 shows the result of this example.

Figure 6-5 Normal access of original Content

z Example 3

This example shows the message that our DRM switching system detects an invalid package. We create a content, a module and an invalid package. Then, our DRM switchable system can detect the error and show the error message to notify the users.

Figure 6-6 shows this example.

Figure 6-6 Message of invalid Package

z Example 4

This example shows the message that our DRM switchable system detects an invalid module. We create a content, a package and an invalid module. Then, our DRM switchable system can detect the error and show the error message to notify the users.

Figure 6-7 shows this example.

Figure 6-7 Message of invalid Module

z Example 5

This example shows that the message that the DRM program within the module detects an invalid rights object. We create a content, an associated module and an associated package. But, we create a invalid rights object. Then, after verifying the package and the module, our DRM switchable system can normally load the DRM program into the device. But, after the DRM switchable system transfers the control to the DRM program, the DRM program detects the invalid rights object and shows the error message to notify the users. Figure 6-8 shows this example.

Figure 6-8 Message of invalid Rights Object

Chapter 7 Conclusion and Future Work

7.1 Conclusion

In chapter 4, we analyze and compare the OMA and the IPMP. Based on these techniques, we design our DRM system on the SPCE3200. This DRM system is designed according to OMA DRM with some concept of IPMP. Besides, we discuss how to implement a DRM switching system. During discussing this problem, we find that some concept of the DRM switchable system is similar to our DRM system.

Therefore, we design all necessary components of our DRM switchable system according to our DRM system.

In chapter 5, we combine those necessary components to be a complete DRM switchable system. Then, we provide two DRM switching schemes and describe their approaches. The DRM switching scheme 1 is a direct combination, so it can divide two stages. At the first stage, the DRM module is loaded into device by the bootstrap. At the second stage, the DRM module starts to manage the DRM tasks. As regards the DRM switching scheme 2, we design this DRM switching scheme has the ability to select the right module for users automatically. And this designed DRM switchable system is similar to a recursive DRM system. When the bootstrap verifies the package and derives the real rights object, we can view this procedure as the first DRM system. When the module uses the real rights object to access the content, we can view this procedure as the second DRM system.

In chapter 6, we describe the implementation of our DRM switchable system on the embedded device. And we provide some application examples to demonstrate our DRM switchable system.

7.2 Future Work

In our DRM switchable system, the bootstrap module must be implemented on the embedded device beforehand and it must be a universal loader. Therefore, it may be designed to be an interface of some other DRM standards.

References

[1] Jaime Delgado, Jose Prados, Eva Rodríguez,"A new approach for interoperability between ODRL and MPEG-21 REL", Second International ODRL Workshop 2005 (ODRL 2005), July 2005

[2] Sunplus, “SPCE3200 PROGRAMMING GUIDE v1.2.”

[3] Sunplus, “SPCE3200 MODULES USER MANUAL.”

[4] DRM Architecture V2.0 OMA-AD-DRM-V2_0-20060303-A, Open Mobile Alliance, March, 2006.

[5] DRM Specification V2.0 OMA-TS-DRM-DRM-V2_0-20060303-A, Open Mobile Alliance, March, 2006.

[6] Study of FPDAM ISO/IEC 14496-1:2001/AMD3, ISO/IEC JTC1/SC29/WG11 N4849, Klagenfurt, July 2002.

[7] Information Technology - Multimedia Framework (MPEG-21) – Part 12: Test Bed for MPEG-21 Resource Delivery, ISO/IEC 21000-12:2005, Apr. 2005.

[8] Information Technology － Multimedia Framework (MPEG-21)-Part 5: Rights Expression Language, ISO/IEC 21000-5:2004, May 2004.

[9] C.W. Fan, F.C. Chang, and H.M. Hang, “An MPEG-4 IPMPX Design and Implementation on MPEG-21 Test Bed”, ISCAS, Vol. 5, May. 2005.

[10] C.W. Fan, “MPEG-4 IPMPX Design and Implementation on MPEG-21 Test Bed,”

M.S. thesis, Dept. Electrical Engineering, National Chiao Tung University, Hsinchu, Taiwan, R.O.C., June 2004.

[11] J. Ming and S.M. Shen, “Study Text of ISO/IEC 13818-11/FCD,＂ISO/IEC JTC 1/SC29/WG11 N5469, Awaji, Dec 2002.

[12] Open Digital Rights Language (ODRL), Version 1.1, August, 2002.

[13] DRM Rights Expression Language V2.0 OMA-TS-DRM-REL-V2_0-20060303-A,

Open Mobile Alliance, March, 2006

[14] DRM Content Format V2.0 OMA-TS-DRM-DCF-V2_0-20060303-A, Open Mobile Alliance, March, 2006

[15] C.N. Wang, et al., “ FGS-Based Video Streaming Test Bed for MPEG-21 Universal Multimedia Access with Digital Item Adaptation, ＂ ISO/IEC JTC1/SC29/WG11 MPEG2003/M8887, October 2002.

[16] An Open-source Cryptographic Library. http://xyssl.org

自 傳

吳巧琳，西元1982 年出生於桃園縣。2005 年畢業於台灣新竹的國立

吳巧琳，西元1982 年出生於桃園縣。2005 年畢業於台灣新竹的國立