Our research uses the following architectures and approaches to accomplish this policy controlled DRM system.
3.1. System Architecture
Figure 3-1 shows that what are the components within our architecture and how these components are deployed in our architecture. Following this architecture, we will discuss the functions of each component in our research.
3.1.1. Content Server
This server maintains the digital content including documents, movies, music…etc. It receives the raw content from the content owner (producer) and protects the content by cipher mechanisms. It also processes the requests from clients to download the digital content regardless of the client having license or not.
3.1.2. License Server
This server maintains the digital license about the personal data and relative rights and limitation. It receives the user’s requests to set up and configure the personal data and the rights to generate the individual license. It may offer a friendly user interface to serve user, for example, a log-in web page and a web page for configuring.
3.1.3. License Proxy
This component is responsible for reading rights from License Server and processing the authenticating requests, such as, authenticating the rights holder, the COTS-Reader and the DRM actions it wants to execute from Helper. Furthermore, it performs in the role of communicating with other DRM or non-DRM license server by a license translator, it can translate XML-based license to our rights format as long as we know their standards.
3.1.4. Helper
This component is an important part of our research. The job of the Helper layer is to decrypt the encrypted digital contents received from Content Server and to function as a coordinator between content viewers and user wrapper by communicating with the License Proxy through sending the configure data about the user and un-authenticating actions information for authentication. Furthermore, the Helper will make a decision that if there is a requirement to do exclusive-or on the decrypted content or not by judging the content information which is sent from the User Wrapper. Then, it will instruct the User Wrapper to enforce the legal DRM actions.
3.1.5. User Wrapper
This component is the core part of our research. The User wrapper layer is responsible for content protection and rights enforcement. In order to archive these objectives, the first work is to do application layer interception. We do coding operations with certificate by creating built-in control policies in associated code segment for rights enforcement and program built-in methods, that is, we inject with source codes through complier support or inject from COTS wrapper. For example, we can restrict any operations pertained to ‘render’, ‘save’,
‘copy’, ’paste’, ’print’…etc by intercepting the Win32 API functions and then injecting generic codes for enforcing rights. So, we can apply the generic code segments with rights policies to enforce complicated rights, for example, we can add some restriction like render number of times or the date into the rights. The second work of this layer is to adapt for various content viewers. For this objective, we analyze many applications for viewing systematically, including the control flow monitor and the dataflow monitor to realize that which kind of the operations is the DRM operation and the DRM operation will call which Win32 API functions. Then,
achieve various combinations to let User wrapper fit various COTS readers.
3.1.6. Encrypted, Decrypted and Scrambled Data
Here we will introduce the meaning and usage of these items at our research.
Obviously, the encrypted and decrypted data is the production of the ciphering processing and all of them are in the client-side computer. There is an ordinary thing that using cipher mechanism in the DRM system and doing this will let the raw content lie in the client computer based on our implementation restriction (it will state later), but we think that is very dangerous, so we add a new state called Scrambled Data, that is, after decrypting, we will do exclusive-or operation on the raw content to let the raw content lie in the computer is more secret.
3.1.7. COTS Reader
This component represents the existing COTS rendering application. Unlike some DRM system, we don’t need to develop a dedicated content viewer, because of that we use the plug-in scheme so that we don’t need the source code’s support.
3.2. Working Flow
Our working flow scenery is that a user gets the encrypted digital content from the Content Server and sets up or configures his license (rights) at the License Server.
When the user does some DRM operations such as print and copy/paste, it will trigger the User Wrapper starting to work. The User Wrapper will detect and intercept any DRM operations immediately and get the information about each DRM operation for authenticating through communicating with the Helper. The procedure of the Helper processing the User Wrapper’s requests is that the Helper will request the DRM
will reserve the rights as a cache rights and the Helper can’t change it. The Helper changes this cache rights only when the user changes his license and the Helper will re-request the rights from the License Server. When the Helper gets the reply message from License Server, it will decrypt the encrypted content and pass the rights checking message to the User Wrapper to enforce or deny the DRM operation’s requests. Finally, the COTS reader can show the digital content to the user. Figure 3-2 shows the all working flow we descript above.
Figure 3-2 The working flow of our DRM architecture