Open Mobile Alliance (OMA) Digital Rights Management (DRM) distributes the media
objects (e.g., a movie, an MP3 music file, and so on) with secured business models that can control the usage of the content and manage the content lifecycle [1, 5, 6]. When a user attempts to access the content, he/she may choose a free preview version or a complete version with charge.
1.1 OMA DRM
OMA DRM allows a content issuer to manage DRM Content [2] to be delivered to the users with copyright protection. In the DRM architecture [3], the user can access DRM Content through a DRM agent (Figure 1 ①), where the DRM agent is installed in the mobile device to manage the usage of DRM Content. The content issuer (Figure 1 ③) is responsible for packaging the media objects into DRM Content and delivering DRM content to the users. A rights issuer (RI; Figure 1 ④) is responsible for producing the Rights Objects [4]. Each Rights Object is associated with a piece of DRM Content.
Figure 1. The DRM architecture.
DRM Content is accessed by the DRM agent under the control of the Rights Objects. A Rights Object specifies permissions, constraints and other features, which indicates how DRM Content can be used. Consider an example where DRM Content consists of a movie and two pictures, and DRM Agent 2 (Figure 1 ②) attempts to play the movie for two times and display the pictures for unlimited times. DRM Agent 2 may download DRM Content from the content issuer or another DRM agent (e.g., DRM Agent 1 in Figure 1 ①) who previously downloaded DRM Content through the DRM mechanism. DRM Agent 2 must utilize the Rights Object Acquisition Protocol (ROAP) to acquire a Rights Object from the rights issuer, and then accesses DRM Content according to the Rights Object. The format of the Rights Object in this example is illustrated in Figure 2. The asset field (Figure 2 ①) specifies the identity, the hash value and the key information of DRM Content. The hash value ensures the integrity of DRM Content. The key information identifies the encryption
method used to encrypt the content encryption key (CEK), and contains the Base64-encoded value of the encrypted CEK. The permission field (Figure 2 ②) specifies the permissions (e.g., to play the movie) and the constraints (e.g., to play the movie two times). If the permission field only specifies the permissions without any constraint (Figure 2 ○3 ), it means that the DRM agent is granted unlimited display rights.
Figure 2. The Rights Object format.
1.2 NTP-DRMT
Before a DRM application can be launched for service, it is essential to conduct testing to ensure that the DRM mechanism is correctly implemented in a mobile device. Although such tests can be done manually, it is more appropriate to automatically validate the DRM mechanism through a test tool. Under Taiwan’s National Telecommunications Program (NTP), we have developed an OMA service interoperability test platform [16] based on the Testing and Test Control Notation version 3 (TTCN-3) specifications [9, 10, 11, 12, 13, 14, 15].
Several OMA Push-to-talk over Cellular (PoC) test cases were deployed on this platform [17].
In this thesis, we implement a DRM conformance and interoperability test tool (called NTP–DRMT) on this platform. NTP-DRMT verifies the adherence to normative requirements described in the OMA DRM technical specifications [7, 8]. The conformance test cases verify whether the DRM agent follows the standard regulations described in [7]. The interoperability test cases verify whether the system under test (SUT; Figure 3 ②), which is implemented based on the specifications, works satisfactorily in various commercial mobile telecommunication networks [8]. Figure 3 shows the conformance and interoperability test environment for DRM. In this figure, NTP-DRMT (Figure 3 ④) acts as the DRM network entities (including the content issuer and the rights issuer) in all test procedures. It communicates with the SUT through a real cellular network or a cellular network emulator (Figure 3 ③) such as Anritsu MD8470A [18]. In the DRM conformance test procedures, NTP-DRMT waits for the SUT to request a Rights Object or DRM Content. This request is issued by a tester (Figure 3 ○1 ). After the SUT receives the response, the tester verifies if the results reported by the SUT are correct. The tester then reports the verdict (e.g., pass or fail) to NTP-DRMT. In the DRM interoperability test procedures, NTP-DRMT waits for the SUT to request DRM Content and the associated Rights Objects through different commercial mobile networks. The tester then verifies if the SUT is capable of executing the interoperability test cases and reports the verdict to NTP-DRMT.
Figure 3. Conformance and interoperability test environment for OMA DRM.
1.3 Test Procedure for the DRM Registration
The DRM registration procedure is illustrated in Figure 4. When a user attempts to access new DRM Content, the DRM agent first sends an HTTP_GET (Figure 4 ①) message to the rights issuer to request the Rights Object. The rights issuer verifies the HTTP_GET message.
Then the rights issuer replies a ROAP Trigger message (Figure 4 ②). This message is used to trigger the ROAP message exchange. The DRM agent then sends a Device Hello message (Figure 4 ③) to provide device information (such as the Device ID and the ROAP version) and initiate the registration procedure. The rights issuer verifies the Device Hello message and replies a RI Hello message (Figure 4 ④). The RI Hello message provides RI preferences and decisions according to the values provided by the DRM agent. The DRM agent then sends a Register Request message (Figure 4 ⑤). The rights issuer verifies the Register Request message and checks if the session ID, the device nonce, the request time and the signature in the Register Request message are correct. Then the rights issuer replies a Register Respose message (Figure 4 ⑥). Upon the receipt of this message, the registration procedure is complete, and the DRM agent can acquire the Rights Object.
Figure 4. The test case for DRM registration procedure.
In the remainder of this thesis, we will describe the design and implementation of NTP-DRMT. Then we use examples to show how the DRM test cases are developed in this test tool.