Structure of DRM Switchable System

In our design, a DRM module is a downloadable set of data. Since a DRM module is critical to the subsequent DRM Content consumption, we have to design a mechanism to ensure that it is a legitimate one.

At first, we describe the two major entries of our switchable DRM. They are the bootstrap and the module provider. When requesting a module from the module provider, the bootstrap must be authenticated by the module provider. When getting the module, the bootstrap needs to verify its identification and confirm its integrity. This is achieved by using the standard Public Key Infrastructure (PKI) procedure. We show the procedure of requesting a module in Figure 4-7.

Figure 4-7 Procedure of Requesting a Module

4.2.3 Relationship among Components

Now, we describe the structure of our switchable DRM system. In our design, it consists of modules, bootstrap and platform. And a module includes the certificate and the DRM program. We draw a simply diagram as shown in Figure 4-8.

Certificate

Figure 4-8 Structure of the switchable DRM

In an analogy to the previously stated DRM model, the bootstrap program in this process is similar to the DRM Agent in the previous model. The module provider is similar to the Rights Issuer, and the DRM program is similar to the DRM Content. We design a module certificate, which is similar to a Rights Object. Then, a similar security model can be used and prevents invalid DRM program from being loaded into the device.

The function of the bootstrap is to control the module loading. It includes the necessary information of the platform. When the bootstrap wants to load the DRM program, it must verify the certificate according to the platform. This mechanism is similar to the previously stated DRM system but is simpler. This mechanism only needs to confirm the valid platform for loading DRM program. We do not need to protect the DRM program, so we integrate the certificate with the DRM program into one module.

4.2.4 Execution Procedure

After describing the relationship among components in our DRM switchable system, we describe the execution procedure of this system. Here, we draw a diagram to show its processing steps in Figure 4-9.

Figure 4-9 Execution procedure in the switchable DRM system

At first, the bootstrap unit provides the GUI interface to a user to select a module.

When the bootstrap wants to load a DRM program inside a module, it must verify the identification of the module and confirm its integrity. In addition, the bootstrap must confirm the relations of the module and the platform. The relations are described by the certificate in the module. Only after ensuring the module is valid for the platform, the bootstrap can load the DRM program into the embedded device. This implies the platform is a condition for accessing the module. This architecture is similar to that of the DRM system. In other words, the platform plays the role of the User and the DRM program is the Content. The difference is that the protection of the DRM program is unnecessary.

4.2.5 Method of Implementation

After describing the execution procedure of our DRM switchable system, we need to develop methods to implement it. Here, we list these methods and describe their functionalities.

♦ V_Show_and_Select_Module()

This function shows the modules to the user and it provides the GUI to the user to select a module.

♦ V_DRM_Module_Verify()

This function verifies a module. This function verifies the signature of the module. It confirms the identification and checks the integrity of the module. Also, this function confirms the relationship between the module and the platform. Because the relations between them are described by the certificate in the module, this function is responsible for the verification of the certificate in the module.

♦ V_DRM_Module_Load()

This function retrieves the DRM program from a module and loads the DRM program into the memory.

Chapter 5 DRM Switching Schemes

In this chapter, we describe our design of the DRM switching schemes. In chapter 4, we have described our DRM system and the concept of our DRM switchable system.

Here, we shall combine them to be a complete DRM switchable system. Therefore, we provide two DRM switching schemes and describe their approaches.

5.1 DRM Switching Scheme 1

Because we want to provide a DRM switchable system, we separate the DRM system from the embedded system. When the user wants to use different DRM systems, he/she can load and run it.

However, because we separate the DRM system from the embedded system, the management of the DRM system becomes the important issue. Therefore, we must provide the functionality of the bootstrap in the embedded device. In this design, the bootstrap must be built in the embedded device beforehand. And it is responsible for controlling the usage of the modules. After loading a module, the bootstrap transforms the control to the module. From this viewpoint, we can divide this DRM switchable system into two stages. The bootstrap becomes the first stage which controls the load of a module. And the module becomes the second stage, which controls the access of the content. We show this scheme in Figure 5-1. We call it scheme 1.

Figure 5-1Two Stages of the DRM Switching Scheme 1

Now, let us describe the two stages of this scheme. In chapter 4, we have introduced the structure of our DRM system and the downloadable mechanism of the DRM module. Here, we use these basic components to design this scheme. We append some GUI interface to this system and provide the execution flow to build a complete DRM switchable system.

At the first stage, the bootstrap provides the GUI interface to the user to select a module (DRM system). After selecting one, the bootstrap must verify its identification.

Only after verifying it, the bootstrap allows the module to be loaded into the embedded device. Then, when a user decides to execute the DRM module, the bootstrap loads it in and transfers the execution to it. The execution flow of an example implementation is shown in Figure 5-2. Therefore, we complete the functionality of switching among different DRM modules.

Figure 5-2 Execution Flow of the DRM Switching Scheme 1

At the second stage, the DRM system starts to execute. We adopt our DRM system stated in chapter 4. Thus, the steps of stage 2 have been described in the chapter 4. In this design, the first stage can transfer the control to the DRM module at the second stage. Similarly, if the second stage terminates, it also transfers the control to the bootstrap at the first stage. Therefore, the user can arbitrarily select different DRM systems and switch it among them. In this design, we succeed in implementing a switchable DRM system.

5.2 DRM Switching Scheme 2

The foregoing is one possible type of DRM switching scheme. In that design, we expect that users know all kinds of DRM modules, the associated contents and have the ability to choose the suitable one. However, that design requires knowledgeable users

and becomes impracticable. Users only care about the selection of the content and they do not want to understand the relationship between the content and the module, so we modify our design for this purpose. In this design, the user select the DRM protected Content. And they do not need to know which DRM system is in use. We design our DRM switchable system has the ability to select the right module for users automatically.

5.2.1 Components

Before we redesign our DRM switching scheme, we state the desirable properties and functions. First, our system allows the user to select the content. And after selecting the content, the device can automatically find out the package of the rights object and its associated module.

z Content

In order to achieve the stated goal, we must record how to use this content in the content bitstream. Thus, we redesign the format of the content. Thus, we modify the header of the content [14]. It is to be used to specify the associated package and the DRM module. The components of the content are showed in Figure 5-3.

Figure 5-3 Modified Content Format of the DRM Switching Scheme 2 [14]

Originally the header of the content has described the identification of the rights

object. Now, we modify this item to be the identification of the package. This package is a container of the rights object. We shall discuss the package later. In addition, we append the identification of the DRM module in the content. Thus, this design not only can specify the associated package but it also can specify the associated DRM module.

z Bootstrap

Since the content bitstream describes how to use the content, we need a controller to manage it. Here, we redesign the bootstrap as a controller. It not only manages the DRM module but also provides a DRM switching interface. This is an abstract concept.

Before building this interface, we must analyze and organize each component. In this approach, we find the DRM Agent and the bootstrap have similar properties. They both need to verify something by using cryptographic algorithms. The DRM Agent must verify the identification of the Rights Object. The bootstrap must verify the identification of the module. Therefore, we integrate this property of the DRM Agent into the bootstrap. Then, the bootstrap will pass the security requirement and become an agent.

Base on these results, we design the bootstrap includes the User and the Platform.

Originally the bootstrap only includes the Platform, because it is only responsible for the verification of the module. Now, because we integrate this property of DRM Agent into the bootstrap, it includes the User. Thus, the bootstrap becomes the interface to process the DRM switching system. Here, we draw a diagram to show its structure in Figure 5-4.

In conclusion, the information in the User component is for the bootstrap to verify the package, which contains the real rights object. And the information in the Platform component is for the bootstrap to verify the module. Thus, the bootstrap is also an interface, which controls the complete DRM switchable system.

Figure 5-4 Modified Bootstrap in the DRM Switching Scheme 2

z Package

Now, we describe the package. Because the bootstrap is an interface which controls all components, these components include the module and the rights object. But, the rights object must be managed by the DRM program. Thus, we derive the identification from the original rights object and transfer it to the package. In addition, we encrypt the original rights object and pack it to the package. In other words, the package is a container of the rights object. And the package provides the identification of the rights object for the bootstrap. Here, we show the block diagram of the package in Figure 5-5.

Pakage

<ro>

<mac>

Rights

Encrypted K

MAC hash of <ro>

Hash value of content

Encrypted RO ID

Figure 5-5 Structure of Package in the DRM Switching Scheme 2

This architecture is similar to that of the rights object. The purpose of the package is for the bootstrap to verify the identification of the rights object. Therefore, the bootstrap can process it by using the ID and the hash value of the content in the package.

We note that there are no permission and no constraint in the package, because these components are not necessary. Besides, we note that the package includes the encrypted rights object. The encrypted rights object is served as a black box. It will be used by the module. The module will use it to access the content.

5.2.2 Relationship

Since we have described the components of this DRM switching scheme (the module, the package, the content and the bootstrap), we draw a diagram to show it in Figure 5-6.

Figure 5-6 Relationship among components in the DRM Switching Scheme 2

Before we describe the flow of the execution, we should know their relationship.

There are six relationships between four components. To begin with, we describe the relationship between the bootstrap and the content. We design a GUI interface for the

users to select the content, so there is a simple relationship between them. Then, the header of the content records the associated package and module. In other words, these records represent the connection between them and the content. And this helps the bootstrap to find the package and the module. Furthermore, the bootstrap verifies their identification. Also, the bootstrap derives the real rights object of the package by using the user information. On the other hand, the bootstrap certifies the certificate of the module by using the platform information. These are also the connections between them and the bootstrap. Finally, we come to the relationship between the package and the module. Because the module provides the DRM system to the bootstrap and the DRM system uses the rights object to access the content, the bootstrap derives the real rights object from the package and delivers it to the DRM system.

5.2.3 Procedure

After we understand the relationship among the components in this DRM switching scheme, we describe its procedure of execution. We divide this system into five steps. In the first step, the bootstrap provides the GUI to the user to select the content. And, the bootstrap starts to manage the content and parse it to know how to access it. These include the information of the associated package and the associated module. Thus, the bootstrap can retrieve the identifications of the associated package and module from the header of the content.

In the second step, after the bootstrap gets the associated package, it must verify its identification and confirm the relationship between the package and the content.

In the third step, after the bootstrap gets the associated module, it also must verify its identification and confirm the certificate of the module. This will ensure the module is suitable for the embedded device.

In the fourth step, after verifying the package and the module, the bootstrap extracts the information from the package for the module to access the content. Thus,

the bootstrap starts to derive the real rights object from the package and delivers it to the module.

In the fifth step, the bootstrap loads the DRM program in the module into the embedded device and transfers the control to the DRM program. Then, the DRM program starts with the real rights object.

Then, the module executes to access the content with the real rights object. The procedure of this execution is invisible. Therefore, we can consider this DRM program is a black box. This design effectively prevents the hacker from invading. Finally, we draw the execution flow to show these steps in Figure 5-7.

Figure 5-7 Execution Flow of the DRM Switching Scheme 2

5.2.4 Method

The previous subsection describes the execution procedure. Now, we shall focus on the detail and steps of the procedure. Here, we list our functions to describe how to implement those steps.

z First step

V_Show_and_Select_New_Content()

This function lists the available contents and it provides the GUI interface to the users to select. Because we modify the format of the content, we create a new function for the users to select the content. In addition, this function can parse the content and retrieve the identifications of the associated package and module.

z Second step V_Verify_Singature()

This function verifies the signature. We use it to verify the signature of the package.

V_ConnectPAC()

This function is similar to the V_ConnectRO() in section 4.1.7. This function confirms the relationship of the package and the content.

z Third step

V_DRM_Module_Verify()

This function verifies the signature of the module and confirms the certification of the module.

z Fourth step V_VerifyPAC()

This function derives the K_REK from the package by using the information of the User.

V_Get_realRO()

This function uses the KREK to derive the real rights object from the package.

z Fifth step

V_DRM_Moudle_Load()

This function loads the DRM program into the memory.

5.2.5 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

6.1.1 Cryptographic Algorithm